Анализ подходов к управлению бизнес-процессами

Введение

Управление бизнес-процессами (Business Process Management, BPM) в крупных российских компаниях сталкивается с рядом системных трудностей, обусловленных как организационной, так и институциональной природой. В большинстве случаев характерна бессистемность и неупорядоченность протекания процессов, что препятствует построению эффективной модели управления. Особенно остро такие проблемы проявляются в региональных компаниях, где опыт внедрения западных стандартов управления недостаточен или отсутствует вовсе.

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

Основная часть

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

В общем виде процесс представлен на рисунке 1

Рис. 1. Последовательность совершенствования бизнес-процессов

Наиболее трудоёмким и значимым этапом считается диагностика компании: часто на него приходится до 40–50% общего объёма проекта (рис. 2). В зависимости от выявленного уровня зрелости организации и существующего состояния может потребоваться частичная или глубокая перестройка процессов.

Рис. 2. Структура затрат времени на совершенствование бизнес-процессов

Для описания, анализа и трансформации бизнес-процессов используют различные нотации (стандарты) и инструментальные среды. Ниже приведён обзор наиболее распространённых подходов:

1. IDEF0 (SADT) – метод функционального моделирования

Метод IDEF0 (происходящий из языка SADT – Structured Analysis and Design Technique) предназначен для построения функциональных моделей систем средней сложности. Входами процесса выступают информационные и материальные потоки, управляющие сигналы (управление), а выходом – преобразованные потоки. Механизмы отражают исполнители, ресурсы, технические средства и информационные системы.

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

2. DFD (Data Flow Diagrams) – моделирование потока данных

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

Преимущества метода:

• чёткое определение внешних сущностей и контроль потоков информации;
• возможность разработки сверху вниз, что упрощает построение модели «как должно быть»;
• детализация процессов – спецификации процессов нижнего уровня позволяют преодолеть логическую незавершённость.

Ограничения:

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

3. IDEF3 – метод сценарного моделирования процессов

IDEF3, как правило, используется на нижних уровнях детализации и часто дополняет IDEF0 (например, для декомпозиции блоков без дальнейшей детализации).

Основой IDEF3 является сценарий процесса – последовательность действий (units of work) и подпроцессов, отображаемых стрелками и логическими операторами (альтернативы, ветвления). Единицы работы могут быть декомпозированы, допускается многократное разложение.

Преимущества метода:

• возможность одновременного отображения альтернативных ветвей внутри одной модели;
• удобство для детального описания поведения процесса, особенно в разветвлённых сценариях;
• ясное выделение сценариев исполнения.

Недостатки:

• сложности при масштабировании: большое число сценариев усложняет модель;
• отсутствие средств выражения ресурсов и управляющих потоков – IDEF3 фокусируется на поведении, а не на ресурсах.

4. ARIS (Architecture of Integrated Information Systems)

Методология ARIS рассматривает систему через различные «виды» взглядов: организационный, информационный, функциональный, ресурсный и процессный. В ARIS допускается использование каких угодно нотаций (например UML), но основная модель – eEPC (extended Event-driven Process Chain – расширенная цепочка событий).

ARIS строит взаимосвязанные модели, позволяющие анализировать систему с разных точек зрения и поддерживать синхронизацию между ними. Модель eEPC отражает поток функций, событий и логических переходов (AND, XOR, OR), но не включает информацию о времени исполнения по умолчанию.

Преимущества метода:

• комплексный взгляд на предприятие – возможность связать различные модели и объекты;
• гибкость в выборе нотаций и способа моделирования;
• поддержка атрибутов объектов (например, стоимость, время, ответственность) для анализа.

Недостатки:

• высокая трудоёмкость и стоимость внедрения (как человеческие, так и финансовые ресурсы);
• сложности в визуализации – модели могут стать громоздкими и плохо читаемыми при большом числе объектов;
• ограниченная выразительность логики (особенно для сложных условий, вложенной логики или параллелизма), что порождает необходимость дублирования событий или дополнительных элементов.

5. Метод Ericsson-Penker

В методе Ericsson-Penker основным артефактом является диаграмма деятельности (Activity Diagram). Благодаря гибкости UML метод допускает адаптацию под нужды бизнеса. Однако ограничения связаны с природой языка UML: слабая типизация, меньшее количество встроенных средств семантики по сравнению со специализированными языками (IDEF, EPC и т. д.), а также ограниченный синтаксический контроль. На практике методы Ericsson-Penker применимы там, где уже используется UML и существует потребность интеграции бизнес-моделей с архитектурой ИТ-систем.

6. Метод бизнес-моделирования в рамке Rational Unified Process (RUP)

В технологии Rational Unified Process (RUP) компания IBM предложила подход к моделированию бизнес-процессов, интегрированный в жизненный цикл разработки программного обеспечения.

Преимущества метода:

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

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

• Уровень детализации и абстракции – возможность представлять процессы как на стратегическом, так и на операционном уровне.
• Поддержка логики, ветвлений и альтернатив – отображение условий, параллельных процессов, исключений.
• Выражение ресурсов и управления – способность моделировать исполнителей, средства, информационные и материальные потоки.

Сравнительные характеристики методов сведены в таблицу.

Таблица

Сравнительный анализ подходов к управлению бизнес-процессами

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

Для тактического и операционного планирования предпочтительнее IDEF3 (сценарный) и UML (diagrams – Activity) – они удобны для детализации последовательностей и альтернативных ветвей.

При необходимости интеграции с ИТ-системами выгодно использовать ARIS (с его гибкостью и поддержкой атрибутов) либо UML-подходы (например, в контексте RUP), особенно если проект уже ориентирован на разработку ПО.

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

На практике часто целесообразно сочетать методы: структурировать систему IDEF0, уточнять сценарии IDEF3, а затем интегрировать в ARIS или UML для дальнейшего анализа и автоматизации.

Для успешного применения выбранной методологии рекомендуется следующий поэтапный подход:

• Определение целей и границ проекта – что и почему моделируется, какие отделы и процессы участвуют.
• Навыковое обучение персонала – базовый курс по нотациям, проведение семинаров и пилотных моделей.
• Диагностика «as is» – сбор информации, интервью, анализ документов, визуализация текущих процессов.
• Построение моделей «as is» – формализация существующих процессов в выбранной нотации.
• Анализ узких мест и проблем – выявление резервов, избыточностей, неэффективностей.
• Проектирование моделей «to be» – построение усовершенствованных процессов с учётом ресурсных ограничений и стратегических целей.
• Оценка и анализ моделей – моделирование «что-если», симуляция, расчёт затрат и выгоды.
• Внедрение изменений – реализация выбранных решений, обучение исполнителей, настройка ИТ-среды.
• Мониторинг и адаптация – отслеживание показателей KPI, выявление новых проблем, корректировка процессов.
• Циклический пересмотр – постоянный процесс улучшения, повторение итераций.
• При этом важно соблюдение принци­па постепенности и управления изменениями: нельзя сразу реформировать всё, лучше начать с пилотных процессов и постепенно расширять сферу внедрения.

Заключение

Обзор методологий моделирования бизнес-процессов показывает, что ни один из подходов не может быть универсальным для любой организации. Выбор методологии зависит от целей, масштаба, зрелости компании и наличия технических ресурсов. Метод IDEF0 удобен для формализации функциональных моделей, IDEF3 – для описания сценариев и логики, DFD – для представления потоков данных, ARIS – для сквозного комплексного моделирования с учётом множества аспектов, а UML-подходы (Ericsson-Penker, RUP) полезны для интеграции бизнес- и ИТ-моделей.

В российской практике внедрение BPM требует особого внимания к этапу диагностики и управлению изменениями, поскольку на многих предприятиях отсутствует культура формализации и системного контроля. В таких условиях постепенный, итерационный подход с пилотными внедрениями наиболее рационален. Начало возможно с простых нотаций (IDEF0, DFD), а затем переход к более сложным (ARIS, UML) по мере развития компетенций и готовности предприятия.

Таким образом, успешное управление бизнес-процессами – не столько задача выбора «лучшего» метода, сколько создание зрелой методологической среды, способной адаптироваться к изменениям, интегрироваться с ИТ и поддерживать непрерывное улучшение.