Практика и проблематика моделирования бизнес-процессов

1. Описание (документирование) деятельности организации (процессы, производственные и информационные ресурсы, документы и данные, персонал и т. д.).

2. Анализ и совершенствование бизнес-процессов и деятельности организации в целом.

3. Описание деятельности организации при построении систем менеджмента качества.

4. Подготовка к внедрению систем управления предприятием.

5. Подготовка к внедрению систем класса Workflow.

6. Построение системы стратегического управления на основе сбалансированных показателей.

7. Проведение организационных изменений.

8. Управление операционными рисками и др.

Вне зависимости от типа проект по моделированию бизнес-архитектуры состоит из следующих основных этапов.

1. Подготовительный этап. На данном этапе определяются и утверждаются цели проекта моделирования и приоритеты, проблемные области организации, выбираются методология и средство моделирования. Также прикидывается общая архитектура процессов, выделяются ключевые бизнес-процессы и их взаимосвязи. Формируются план проекта, проектная команда, подготавливается документ «Соглашение о моделировании».

2. Описание и анализ процессов «как есть». На этом этапе осуществляются описание процессов «как есть» в выбранном средстве моделирования, выбор критериев оценки процессов, выявление и оценка «узких» мест и потенциала для совершенствования. Уточняется план работ по дальнейшим этапам.

3. Построение процессов «как должно быть». На этом этапе определяются и оцениваются альтернативные сценарии процессов, моделируются процессы «как должно быть» с новой организационной структурой и операционным окружением, планируются потребности в персонале и формулируются требования к их квалификации и знаниям. Уточняется план работ по дальнейшим этапам.

4. Подготовка к переходу к оптимизированной модели. На этом этапе разрабатывается план перехода от текущего состояния к целевому:

– создание новых должностных инструкций;

– разработка тренинг-курсов и выработка показателей (метрик) уровня квалификации исполнителей;

– описание временных решений и т. п.

5. Реализация. На этом этапе реализуются и/или автоматизируются необходимые процессы с помощью заказного или стандартного ПО, осуществляются перестройка организационной структуры, переквалификация персонала, а также мониторинг.

Общая логика организации разработки модели бизнес-архитектуры в самом общем виде представлена на рис. 7. Принципиально важно отметить наличие двух составляющих в проекте, а именно определения вида целевой бизнес-архитектуры и разработки стратегии достижения.

Общим фоном для построения модели бизнес-архитектуры является мониторинг существующих тенденций в предметной области деятельности организации, направления развития ИТ-сферы. В рамках определения современных требований по оценке состояния бизнес-процессов в организации формируются иерархия целей и система показателей, которые трансформируются в требования к основным компонентам – организационной, функциональной, информационной, технологической. В контексте бизнес-требований параллельно осуществляется системный анализ всех перечисленных основных компонент.

Результаты вышеперечисленных этапов являются основой для выполнения Gap-анализа, то есть выявления расхождений и различий между существующей и целевой бизнес-архитектурами. На основе Gap-анализа формируется план миграции, ориентированный на модернизацию ключевых компонент бизнес-архитектуры и конкретизирующий состав соответствующих проектов.

В ходе каждого из этапов (фаз) проекта складывается характерный набор документов и иных материалов, которые формируют информационную и методологическую базу модели бизнес-архитектуры и «фиксируют» пройденный маршрут по проекту.

Основным содержанием работы на этих этапах является эволюционный, итеративный процесс определения и описания текущего и желаемого состояния бизнес-архитектуры, совмещенный с процессом анализа результатов, идентификацией направлений и планов развития (Gap-анализ), который обеспечивает синхронизацию модернизации базовых компонент бизнес-архитектуры.

Вне зависимости от различных вариантов определения модели бизнес-архитектуры предприятия в конечном итоге обязательными составляющими методик описания модели являются такие принципы, как:

а) декомпозиция на различные представления архитектуры (предметные области): организационная, информационная, функциональная, технологическая компонента и т. д.;

б) различные уровни детализации и абстракции, а также средства формализации для описания каждой из компонент;

в) мониторинг существующих тенденций в области деятельности организации и тенденций в области развития информационных технологий;

г) мониторинг методической и нормативной базы по оценке бизнес-процессов в организации.

Выше отмечалось, что бизнес-архитектура является упрощенной моделью реальной организации. Необходимость получения практически значимого результата по моделированию в приемлемые сроки требует поиска компромисса не только в уровне детализации, но и на этапах его достижения.

Модель бизнес-архитектуры предприятия должна быть скорее гибкой, чем идеальной. Это нашло отражение в принципе, который был сформулирован как «достаточно хорошая» архитектура [15]. При этом принцип «достаточно хорошей» архитектуры противостоит стремлению создания «идеальной» архитектуры. Философия заключается в том, чтобы создать довольно гибкую и восприимчивую архитектуру, которая может модернизироваться в процессе своего жизненного цикла в ответ на изменения в моделях бизнеса и технологиях, и это гораздо важнее, чем создание теоретически правильной, идеальной архитектуры, представляющей полное и конечное видение [4].

В данных обстоятельствах целесообразно руководствоваться рекомендациями минималистского подхода по проектированию модели бизнес-архитектуры, то есть определять требования к бизнес-архитектуре самого высокого приоритета и затем делать минимально возможное, и не более того, чтобы удовлетворить этим требованиям [16]. Это позволяет иметь ограниченный и контролируемый набор бизнес-моделей высокого уровня (либо ключевых бизнес-процессов), но в то же время оставляет необходимую степень свободы для расширения состава бизнес-процессов, повышения детализации описания как самих бизнес-процессов, так и их компонент.

Базовый принцип минималистского подхода состоит в том, что если достижение некоторого требования по модели бизнес-архитектуры может быть реализовано за счет делегирования принятия решения на более низком уровне детализации, то соответствующее решение не является важным с архитектурной точки зрения (по крайней мере, для данного уровня).

Реализация минималистского подхода и подхода по «достаточно хорошей архитектуре» осуществляется в соответствии со следующими ключевыми принципами:

быть гибким и разграничивать уровни бизнес-архитектуры. Гибкость может, в частности, достигаться за счет разделения бизнес-архитектуры на составные компоненты: организационная, технологическая, информационная и т. д. Это позволяет «локализовывать» необходимые изменения в рамках соответствующих предметных областей, учитывать связь (влияние) изменений между предметными областями и таким образом исключать необходимость переделки всей архитектуры целиком;