Зачем нужны версии моделей в Business Studio?

На рис. 1 представлена актуальная архитектура бизнес-процессов некоторой компании (учебный пример). Обратите внимание на категорию процессов «Продажа», группу процессов «Управление заказами» и бизнес-процесс «Обработка заявок и выставление счетов» (А3.4.1.). Видно, что все объекты в группе «Управление заказами» показаны серым цветом. Это значит, что эти модели получили статус «Опубликована» и их нельзя изменить.

До выхода 5-й версии Business Studio эта задача довольно часто решалась следующим образом. Создавалась папка «Модели в работе», а в ней соответствующие папки по процессам, а уже в них путем простого копирования создавались различные версии моделей бизнес-процессов. Я встречал ситуации, когда таких версий было около тридцати для каждого процесса. На рис. 1, например, показаны три версии модели бизнес-процесса «Обработка заявок и выставление счетов».

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

Конечно, существует и другой способ – изменять схемы непосредственно в актуальной модели. Но если в компании используется BS Portal, то такие измененные, но еще не согласованные схемы могут попасть на всеобщее обозрение на внутреннем веб-портале, что плохо.

С выходом 5-ой версии Business Studio ситуация радикально изменилась. Теперь не нужно создавать бесконечное количество копий моделей «копи-пастом» в актуальной базе, а можно использовать инструмент «Ветки». Как это сделать? Рассмотрим ниже, но для начала обратите внимание на актуальную версию модели процесса, который мы хотим изменить. Она представлена на рис. 2.

Далее вы можете повторять представленные ниже действия на своей базе (для тренировки лучше создать отдельную базу Business Studio).

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

Создание ветки

Для того, чтобы создать новую версию модели процесса на основе уже существующей нужно создать новую ветку. На рис. 4 показан первый шаг. Нужно выйти из Business Studio, запустить его заново. Далее в окне выбора баз данных выбрать нужную базу (в нашем примере – это база «Версии моделей») и войти в режим создания веток. Для этого навести мышь на строку «Actual model», нажать правую кнопку мыши и выбрать «Управление ветками».

В открывшемся окне нужно создать новую ветку, нажав на кнопку «+» слева. На рис. 5 показано, что создана новая ветка под названием «Оптимизация процесса продаж». Затем нужно сохранить изменения.

Внесение изменений в модель бизнес-процесса в ветке

После того, как ветка будет создана, нужно открыть ее, выбрав в списке баз данных, как показано на рис. 6.

Представим себе, что над оптимизацией модели работает несколько человек. Каждый участник такой команды выполняет свою роль. В Business Studio 5 есть возможность есть возможность связать ветку с проектом и указать его участников.

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

Обратите внимание, что выбраны участники проекта – пользователь vvrepin и Ivanov Ivan. В данную базу я захожу как vvrepin. Физическое лицо, ассоциированное с этим пользователем Windows, – Репин Владимир Владимирович. Кроме того я являюсь пользователем BS Portal.

Обратите внимание, что задана проектная роль – «Эксперт проекта». Это означает, что пользователь будет получать уведомления на портале, например, при запуске опроса типа «Согласование». (Описание проектных ролей выходит за рамки этой статьи).

На вкладке «Ветки» нужно выбрать ветку, которую мы создали, как показано на Рис. 8. , а затем сохранить проект.

Далее в меню «Управление моделью» выберите пункт «Выбрать текущие проекты» и поставьте галочку напротив только что созданного проекта.

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

Далее нужно выделить мышкой процесс «Обработка заявок и выставление счетов» и все его операции и нажать Ctrl-Shift-V. В открывшемся окне нужно присвоить статус «В работе», как показано на Рис. 10. Затем открыть схему процесса на редактирование.

Обратите внимание, что напротив названий процессов в справочнике появился маркер карандаша. Он означает, что эти процессы были изменены в текущей ветке.

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

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

Для этого выделите процесс «Обработка заявок и выставление счетов» и все его операции в справочнике «Процессы». Нажмите Ctrl-Shift-V и выберите статус «Проект», как показано на Рис.12.

Теперь можно отправить опрос на портал (предварительно убедитесь, что портал «Портал Компании «Ветки» (условное название – у вас будет свой портал) запущен). В меню «Управление моделью» выберите «Запуск опроса». В открывшемся окне выберите тип опроса «Согласование» и соответствующий (ваш) портал (см. рис 13). Нажмите кнопку «ОК».

Через некоторое время (2-3 минуты) зайдите на портал или, если Вы уже там находитесь, нажмите F5 для обновления страницы. Вверху в разделе «Опросы» вы увидите цифру 8 на красном фоне. Нажмите на опросы. Вы увидите опрос «Согласование: Оптимизация процессов продаж» (см. рис. 14.). Кстати, уведомление о доступности опроса на портале приходит сотруднику на электронную почту.
Почему именно я стал участником опроса? Дело в том, что в рамках этого проекта я (пользователь vvrepin) являюсь экспертом проекта (см. выше).

Кликните по опросу, а затем по строке «Обработка заявок и выставление счетов». Вы видите схему процесса (рис. 15), с которой мы работали в ветке – вносили изменения. В окне справа можно выбрать ответ (статус согласования), например «Согласованно с замечаниями» и написать необходимый комментарий. Далее нажать кнопку «Сохранить».

Бизнес-аналитик увидит результат согласования так же на портале и сможет внести изменения в модель в ветке, запустить на согласование следующую итерацию и так далее.

Применение ветки

Допустим, что все изменения в модели выполнены и согласованы. Теперь нужно изменить статус модели бизнес-процесса «Обработка заявок и выставление счетов» и всех его операций на «Опубликована», как показано на рис. 16. Обратите внимание, что выбрана опция «Не изменять».

Перед тем, как применять ветку, нужно убедиться, что BS Portal остановлен, чтобы получить монопольный доступ к базе.

Далее в меню «Управление моделью» выберите «Применить ветку». Business Studio будет закрыто. В открывшемся окне нажмите «ОК» (комментарий можно не писать). После того, как ветка применится (появится окно «Применение ветки успешно завершено»), зайди в основную, актуальную модель (Actual Model – это название, кстати, можно изменить) и найдите в справочнике процесс, для которого была создана новая версия, как показано на рис. 17.

Видно, что версия модели в актуальной базе изменена на ту, которую мы сформировали в ветке.

Резюме

Итак, я кратко показал вам возможности нового функционала Business Studio 5 по управлению версиями модели. Обратите внимание, что версии создаются не только для моделей бизнес-процессов, но для объектов из других справочников, например: подразделения и должности, роли, документы, информационные системы и проч.

Использование веток для управления версиями в проекте и функционала опросов на внутреннем веб-портале (BS Portal) могут существенно повысить эффективность вашего проекта описания, анализа, регламентации и подготовки к автоматизации бизнес-процессов.

Если вы еще не перешли с версии Business Studio 4 на версию 5, то рекомендую это сделать. И прекратите мучить себя и заказчиков создавая бесконечное количество копий в папке «Модели в работе»!

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент»

Февраль 2021 г.

В статье Владимира Репина рассмотрены функциональные возможности по использованию программных продуктов при создании моделей бизнес-процессов в нотации BPMN в Business Studio 5. Обсуждаются преимущества и недостатки представленных способов. Материал может быть полезен при разработке Соглашения (стандарта) по моделированию бизнес-процессов вашей организации.

Зачем моделировать программные продукты в Business Studio?

В статье речь пойдет об использовании объектов справочника «Программные продукты» в моделях бизнес-процессов в нотации BPMN в Business Studio 5. Например, можно для каждой операции процесса указывать конкретный программный продукт, который используется при ее выполнении. Программные продукты являются элементами общей модели организации и хранятся в соответствующем разделе более общего справочника «Объекты деятельности».

Для чего нужна информация о программных продуктах на схемах типа Work Flow (eEPC, BPMN)? Конечно, в модели такого типа нас интересует, прежде всего, корректный (без логических ошибок) алгоритм выполнения процесса. Движение документов на схеме, взаимодействие по входам-выходам с другими процессами, описание используемого программного обеспечения, рисков и прочих объектов делают из графической схемы модель бизнес-процесса. Это дает нам возможность выполнять анализ процесса «как есть», находить проблемы и выявлять их причины, определять потенциал повышения эффективности процесса за счет реализации ряда мероприятий.

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

Формирование структуры программных продуктов в справочнике

В Business Studio 5 можно создать структуру используемых в компании программных продуктов в справочнике «Объекты деятельности/Программные продукты». На рис. 1 показан пример структуры программных продуктов компании.

В начале создается объект справочника «Информационная система», например «1С». Затем для нее может быть добавлен «Модуль ИС», например «1С: Бухгалтерия». Далее, при необходимости, внутри модуля можно создать «Функцию ИС». В целом, группировка по модулям и функциям может быть многоуровневая.

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

Три способа использования программах продуктов на схеме процесса в нотации BPMN

Способ № 1. Привязка через интерфейс

Рассмотрим три основных способа использования программных продуктов в моделях бизнес-процессов в нотации BPMN. На рис. 2 показана схема процесса (учебный пример). По правой кнопке открыты «Свойства» операции «Собрать информацию». Из справочника программных продуктов в список «Программные продукты» перетянут мышкой продукт «MS Word».

Далее нужно выбрать тип связи программного продукта и операции процесса. Можно использовать два типа связей: «поддерживает» и «выполняет» (вы можете создать любой новый тип связи при необходимости). Какой из них выбрать?

Зачем вообще указывать тип связи? Это нужно в том случае, если мы хотим в дальнейшем анализировать процесс и выгружать определенные аналитические отчеты. Например, мы хотим узнать, какие информационные системы (продукты) используются при выполнении бизнес-процессов, каковая степень автоматизации процессов с использованием систем определенного класса и т.д. Так же это может быть полезным при выполнении проектов развития ИТ-архитектуры компании и автоматизации процессов.

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

1. операция выполняется сотрудником, и при этом:
2. какие-то действия выполняются сотрудником в соответствующей информационной системе.

Тип связи «выполняет» можно интерпретировать следующим образом:

1. операция выполняется полностью автоматически в соответствующей информационной системе.

Действительно, что значит, что программное обеспечение что-то «выполняет»? Может ли MS Word что-то «выполнять» сам без участия человека? С моей точки зрения, нет. А вот например, антивирусная система может приступить к проверке автоматически, по расписанию, без участия человека. В этом случае операция «Проверить РС на вирусы» будет полностью автоматический и будет «выполняться» соответствующей информационной системой.

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

Способ № 2. Визуализация на схеме

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

На рис. 4 показан результат визуализации использования программных продуктов на схеме процесса. Для каждой операции процесса показаны программные продукты, которые поддерживают их выполнение.

Обратите внимание, что размеры и цвета значков изменены (вручную). Визуальный вид и цвет значков можно закрепить в Соглашении по моделированию. В следующей версии Business Studio будет добавлена функциональная возможность управлять цветами объектов в зависимости от значения параметров.

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

Более глубокий анализ указанных проблем дает возможность обосновать мероприятия по улучшению процесса и внедрению новых информационных систем, например iBPMS+RPA вместо тяжеловесной, неудобной и устаревшей СЭД.

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

Как быть в случае, если операция выполняется полностью автоматически? На рис. 6 показан один из допустимых вариантов. Можно одновременно использовать маркер автоматического выполнения («вызов внешней функции или сервиса») и тип связи «выполняет». По типу связи вы всегда сможете отфильтровать все операции процессов, выполняемые автоматически. Кстати, в Business Studio 5 можно настраивать визуализацию параметров для стрелок, используемых в модели. Это удобно.

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

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

Способ № 3. Представление в виде отдельной дорожки

В Business Studio 5 появилась возможность использовать программное обеспечение в качестве дорожки на схеме в нотации BPNN. На рис. 7 показана измененная схема процесса, на которой модуль «FI-CO» показан в виде дорожки. Дополнительно для наглядности использован маркер автоматического выполнения операции.
Обратите внимание, что тип связи программного обеспечения с операцией процесса – «выполняет». Таким образом, можно визуально показывать программное обеспечение в качестве полноценного участника процесса.

Способ представления программного продукта на схеме процесса (в виде отдельной дорожки) является весьма спорным.

Хотя, возможно, это будет удобно для описания алгоритмов выполнения процессов, полностью автоматизированных в различных системах: веб-сервисы, BPMS, RPA, ERP.

Преимущества и недостатки методов представления программных продуктов в моделях процессов в нотации BPMN

В следующей таблице представлено сравнение трех методов представления программных продуктов на схеме процесса в нотации BPMN.

Мы рассмотрели различные подходы к моделированию программных продуктов на схемах бизнес-процессов в нотации BPMN в Business Studio 5.

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент»

Январь 2021 г.

Методология или Методика

В Википедии вы можете найти следующее определение Методологии: «Методоло́гия (от греч. μεθοδολογία — учение о способах) — учение о методах, способах и стратегиях исследования предмета». Так же там приводится информация о том, что «Практическая… Методология… — это программа (алгоритм), набор приёмов и способов того, как достичь желаемой практической цели…».

Поскольку при внедрении СУБП нам необходим именно набор методик (методов), а не одна конкретная методика, то я считаю возможным называть представленный ниже набор связанных между собой методик именно Методологией внедрения системы процессного управления. При этом, конечно, не исключаю, что возможны другие мнения и понимания понятия «Методология».

С другой стороны, я бы мог не упоминать термин «Методология» вообще. Но разработка регламентов СУБП требует конкретной методической основы. Они не могут быть созданы без какого-либо обоснования.

В данной статье серии я рассмотрю группу работ «Разработка Методологии и регламентация процессов СУБП», причем в первую очередь речь пойдет об организации деятельности Процессного офиса.
Ниже представлена возможная структура рассматриваемой группы работ:

3. Разработка Методологии и регламентация процессов СУБП.
   3.1. Регламентация деятельности Процессного офиса.
   3.1.1. Разработка Положения о процессном офисе.
   3.1.2. Разработка формы Плана/отчета Процессного офиса.
   3.1.3. Разработка нормативов для Процессного офиса.
   3.1.4. Разработка индивидуальных форм отчетности сотрудников Процессного офиса.
   3.1.5. Разработка ИПР сотрудников Процессного офиса.
   3.2. Регламентация процессов СУБП.
   3.2.1. Разработка Положения о Процессном комитете.
   3.2.2. Разработка Положения о владельце сквозного процесса.
   3.2.3. Разработка формы Плана/отчета по описанию, анализу, оптимизации, регламентации и автоматизации процессов.
   3.2.4. Разработка формы плана/отчета развития СУБП.
   3.3. Регламентация процесса описания, анализа и оптимизации процессов.
   3.3.1. Разработка Соглашения по моделированию процессов.
   3.3.2. Разработка Регламента описания и анализа процесса.
   3.3.3. Разработка Регламента внедрения изменений в процесс.
   3.3.4. Разработка Регламента подготовки ТЗ на автоматизацию процесса.
   3.4. Регламентация процессов управления ВНМД.
   3.4.1. Разработка структуры и форм ВНМД.
   3.4.2. Разработка Регламента управления ВНМД.
   3.5. Разработка Регламента оценки уровня зрелости СУБП.

В данной статье я подробнее остановлюсь на подразделе «3.1. Регламентация деятельности Процессного офиса».

Процессный офис

BPM CBOK определяет «Процессный офис» (Business Process Management Office) и/или «Центр компетенции BPM» как подразделение, задачами которого являются:
• стандартизация процессов;
• унификация средств и методов работы с процессами;
• обучение принципам и методам BPM (Business Process Management);
• общий надзор за проектированием процессов и интеграция процессов на уровне предприятия;
• мониторинг и предоставление отчетов по показателям процессов для их владельцев и высшего руководства.

В российской практике функции Процессного офиса могут выполнять: отдел организационного развития (ООР), подразделение СМК, отдел стандартизации процессов и другие подразделения.
Довольно часто встречается ситуация, когда задачи Процессного офиса выполняет подразделение, находящееся в структуре управления персоналом, ИТ и др. Иногда подразделение называется «Департамент оптимизации бизнес-процессов», «Служба организационного развития («СОР» — лучше так не называть) или «Управление организационного развития». Один раз мне даже попался «Директор по управлению Бизнес-процессом (это не описка) и качеством» – ДУБП&К – только почувствуйте, как это славно звучит!

Нужно ли создавать именно Процессный офис? Убежден, что «Да». Тем самым руководство подчеркивает важность внедрения СУБП для компании и свою готовность выделять ресурсы на проект внедрения. Считаю, что Процессный офис – ключевой элемент Системы управления бизнес-процессами компании.

Положение о Процессном офисе

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

1. Общие положения.
2. Организационная структура Процессного офиса.
3. Цели и показатели деятельности Процессного офиса.
4. Выполняемые бизнес-процессы (функции).
5. Права.
6. Ответственность.
7. Требования к компетенции бизнес-аналитиков.
8. Нормирование труда бизнес-аналитиков.
9. Взаимодействие с другими подразделениями.
10. Оценка деятельности и стимулирование сотрудников Процессного офиса.
11. Приложения.
    a. Форма «План/отчет по работе Процессного офиса».
    b. Форма «План/отчет сотрудника за неделю».
    c. Форма «Индивидуальный план развития сотрудника».

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

Функции Процессного офиса

К основным функциям процессного офиса можно отнести:

1. Управление архитектурой процессов компании.
2. Организация и координация «процессной работы».
3. Описание и анализ процессов.
4. Планирование и внедрение изменений в процессах.
5. Регламентация и стандартизация процессов.
6. Участие в проектах автоматизации (роботизации) процессов.
7. Поддержка базы знаний по процессам (на web-портале компании).
8. Методология и контроль (схемы процессов, ВНМД).
9. Развитие процессных компетенций.
10. Предоставление аналитических отчетов руководству.

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

Планы, которые использует Процессный офис

В рамках СУБП может использоваться несколько различных видов планов, в том числе:
• План мероприятий по развитию СУБП на год (методология, инструменты, ВНМД, компетенции).
• План/отчет по описанию, анализу, оптимизации, регламентации и автоматизации процессов.
• Оперативный план/отчет по работе Процессного офиса.

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

В случае, если внедрение СУБП осуществляется в рамках развития СМК (Системы менеджмента качества) компании, то целесообразно использовать единый документ, например, «План развития СМК компании на год».

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

Второй план – это План/отчет по описанию, анализу, оптимизации, регламентации и автоматизации процессов. Форма этого плана разрабатывается при выполнении группы работ «Регламентация процессов СУБП». Это сводный план по всей компании. Он включает задачи и проекты по указанным направлениям, например, сколько процессов планируется описать и регламентировать, сколько автоматизировать и т.д. Опять же, исполнителями проектов могут быть структурные подразделения, а не только бизнес-аналитики Процессного офиса. Важно отметить, что при формировании плана необходимо оценивать трудоемкость всех задач в человеко-часах и учитывать ресурс времени руководителей и специалистов, которые реально может быть выделен для их выполнения.

С учетом мероприятий, сформулированных в указанных планах и попадающих в зону ответственности Процессного офиса, формируется оперативный план работы Процессного офиса на каждый месяц. Этот документ – «План/Отчет» Процессного офиса — должен иметь удобную форму. Как минимум, он может делаться в MS Excel, как показано на рис. 1. В идеальном варианте целесообразно использовать систему автоматизации (планирование, постановка и контроль исполнения задач, отчетность).

Нормативы для Процессного офиса

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

Указанные нормы определены для так называемого «Нормо-процесса». Это условный процесс, который включает до 15 шагов и умещается на листе формата А4. Если не вводить понятие «Нормо-процесс», то деятельность бизнес-аналитиков Процессного офиса будет сложно планировать.

Например, проектирование и регламентация сквозного процесса может включать 7 нормо-процессов. Это значит, что необходимо заложить, минимум, 210 человеко-часов. Это около 5 недель работы одного бизнес-аналитика «фулл-тайм» в идеальной ситуации.

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

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

Например, к числу причин фактического неисполнения норматива описания процесса можно отнести:
• нечеткое определение границ процесса и целей его моделирования;
• недостаточная квалификация бизнес-аналитика;
• отсутствие контроля качества схемы процесса перед передачей на согласование экспертам/ЛПР (лицам, принимающим решения);
• незнание нотации моделирования экспертами в предметной области и ЛПР;
• новые вводные по ходу работы от ЛПР (изменение границ процесса и/или целей моделирования и проч.)

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

Более подробно ознакомиться с этой темой вы сможете, посмотрев видео на моем канале:

Индивидуальные формы отчетности сотрудников Процессного офиса

Руководителю Процессного офиса важно понимать, сколько времени тратят бизнес-аналитики для получения конкретного результата. Например, была поставлена задача собрать информацию по процессу, провести одно интервью и сформировать графическую схему в нотации BPMN. На все было отведено 10 часов. В результате сотрудник представил схему из 4 шагов и в отчете указал фактическую трудоемкость 4 рабочих дня (32 часа). Что делать в этом случае? Десять часов на описание одного «Нормо-процесса» — достаточно много. Часто для этого хватает и 3 часов, если процесс простой. Для сложных случаев (4 интервью, 15 шагов, сложная логика) десяти часов может не хватить. В рассматриваемом примере схему из 4 шагов можно было сделать за 2-3 часа, включая интервью. Факт – 32 часа. Скорее всего, с данным бизнес-аналитиком придется расставаться (хотя бы потому, что он спокойно поставил в отчет 32 часа на решение простой задачи, завысив трудоемкость более, чем в три раза!).

Итак, чтобы видеть реальную картину Руководителю Процессного офиса нужен индивидуальный «План/Отчет» бизнес-аналитика за неделю. Он может быть подготовлен в MS Excel. Структура документа довольно проста: дата/день недели, задача, план и факт в часах, результат (ссылки на документы, модели и т.п.).

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

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

Индивидуальные планы развития сотрудников Процессного офиса

Бизнес-аналитик Процессного офиса является исключительный фигурой. Он должен обладать большим объемом знаний и разносторонними компетенциям в области организационного развития, процессного управления, автоматизации и инноваций. Но текущая загрузка рутинной работой, например, поиск несоответствий в проектах регламентов, подготовленных в функциональных подразделениях, может привести к полной потери интереса к работе. Каким образом «зажечь» бизнес-аналитика? Ответ – так же, как и любого другого сотрудника. Его внутренний статус мотивации по отношению к работе должен измениться. Как это сделать? Специалиста нельзя перегружать работой, и она должна быть для него интересной. Полученные результаты важно оценивать и предоставлять ему обратную связь… Но в данном контексте, я хочу сказать только об одном факторе – дайте возможность бизнес-аналитику профессионально развиваться. В противном случае он будет продолжать работать бизнес-аналитиком…, но только уже в другой компании.

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

Считаю весьма важным наличие индивидуальных планов развития сотрудников Процессного офиса. Индивидуальный план развития (ИПР) бизнес-аналитика может включать:
• список книг, которые он должен прочитать и поделиться с коллегами;
• программы тренингов (семинаров, мастер-классов и прочих учебных мероприятия), которые он должен посетить в течение года;
• подготовка и прохождение сертификации (например, по использованию среды проектирования бизнес-процессов или автоматизации процессов в Bizagi);
• индивидуальный проект (например, совершенствование методики анализа процессов с использованием …).

В частности, бизнес-аналитику можно поставить цель пройти сертификацию по Профессиональному стандарту «Специалист по процессному управлению» (утвержден приказом Министерства труда и социальной защиты Российской Федерации от «17» апреля 2018 г. № 248н.) или сертификацию OMG CERTIFIED EXPERT IN BPM™ 2 (OCEB™ 2), что несколько сложнее (нужно свободно знать английский язык и быть профи в BPM).

Очевидно, что для реализации ИПР нужны время и деньги. Компания может отправить сотрудника Процессного офиса на обучение, оплатить прохождение сертификации и проч. Руководитель Процессного офиса может выделить 2-3 часа в неделю каждому сотруднику на самоподготовку. Кроме того, если сотрудник заинтересован в развитии, то он всегда найдет на это время (например, чтение BPM CBOK по дороге на работу).

В целом, я считаю наличие системы работы с ИПР важной частью деятельности Процессного офиса.

Что дальше?

Далее в статьях серии я рассмотрю следующие аспекты разработки Методологии и регламентов СУБП:
• Регламентация процессов СУБП.
• Регламентация процесса описания, анализа и оптимизации процессов.
• Регламентация процессов управления ВНМД.
• Разработка Регламента оценки уровня зрелости СУБП.

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Директора АО «СО-ЕЭС», руководитель отдела Анализа и методологического обеспечения ПО № 8 ГБУ «Аналитический центр» Департамента экономической политики и развития города Москвы.

Август 2020 г.

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

Что такое СУБП и зачем она нужна вашей компании?

Начнем с определения:

Система управления бизнес-процессами (СУБП) — совокупность методов, инструментов, ресурсов и внедренных бизнес-процессов, направленная на эффективное развитие Компании на основе управления каждым значимым бизнес-процессом в рамках его жизненного цикла.

СУБП – это часть системы управления компанией, как например система управления финансами или система управления персоналом. Наличие СУБП означает, что в организации ведется практическая работа с процессами: оперативное управление, анализ, улучшение, стандартизация и автоматизация.

Ключевой результат СУБП – это бизнес-процессы с лучшим мировым уровнем эффективности и качества, основанные на инновационных, цифровых технологиях.

Главное условие успешного внедрения СУБП – наличие твердого желания собственников и руководителей верхнего уровня системно организовать работу с процессами.

В данной серии статей я предлагаю вашему вниманию подробный план внедрения СУБП «C нуля». Этот план вы можете адаптировать с учетом особенностей и конкретной ситуации в вашей организации.

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

План внедрения СУБП

План внедрения СУБП включает следующие этапы:

1. Подготовка к выполнению проекта.
2. Разработка документа «Концепция внедрения СУБП в компании».
3. Разработка Методологии и регламентация процессов СУБП.
4. Разработка Архитектуры бизнес-процессов.
5. Внедрение программного обеспечения СУБП.
6. Разработка системы развития компетенций по процессному управлению.
7. Разработка системы вовлечения персонала в деятельность по улучшению процессов.
8. Выполнение «пилотного» проекта по оптимизации сквозного процесса компании.

На рис. 1 показан ориентировочный график выполнения проекта внедрения СУБП.

Срок внедрения СУБП, то есть построения Системы работы с процессами около 6 месяцев. При желании, можно быстрее. Но есть определенные ограничения, связанные, в первую очередь, с недостатком ресурса времени руководителей и их мотивации выполнить проект. Крайне нежелательно растягивать проект на 1,5-2 года. За это время многие решения потеряют актуальность, результаты обучения будут забыты, регламенты устареют. То есть систему нужно строить достаточно быстро.

Руководство компании может принять решение об определении КПЭ по результатам проекта, которые будут стимулировать руководителей подразделений выполнять проектные задачи в срок и с высоким качеством. Это – один из ключевых факторов успеха проекта

1. Подготовка к выполнению проекта

Подготовка к выполнению проекта включает следующие группы работ.

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

1.2. Обсуждение видения и целей внедрения СУБП.
Обсуждение видения СУБП компании и конкретизация целей ее внедрения могут выполняться в рамках совещаний руководителей верхнего уровня с привлечением собственников. Результатом совещаний является предварительная формулировка видения и целей внедрения СУБП в компании. Координирует работу один из руководителей, либо внешний консультант. На данном этапе важно определиться с основными аспектами будущей системы, причем широкими мазками, эскизно, без детализации.

1.3.Поиск и подбор Руководителя Процессного офиса, Главного методолога и бизнес-аналитиков.
В рамках подготовки к проекту необходимо выбрать из своих сотрудников или привлечь со стороны специалистов, от которых во многом зависит успех внедрения СУБП. Необходимо подобрать Руководителя Процессного офиса, Главного методолога и одного-двух бизнес-аналитиков (на первое время).

Для подбора можно использовать проф. стандарт «Специалист по процессному управлению» и соответствующий тест, доступный на сайте ассоциации ABPMP Russian Chapter. Так же можно обратиться к лучшим экспертам в области процессного управления за помощью в подборе и тестировании кандидатов.

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

1.4. Назначение куратора проекта внедрения СУБП по стороны Руководства компании.
Одновременно с п. 1.3. выполняется выбор и назначение куратора проекта со стороны топ-менеджмента компании. Это может быть первый заместитель директора, директор, руководитель крупного департамента, представитель собственника.

1.5. Выполнение бенчмаркинга.
Куратор с сотрудниками Процессного офиса и ключевыми руководителями могут совершить 2-3 бенчмаркинговых поездки для ознакомления с опытом внедрения СУБП и практикой работы с бизнес-процессами в передовых компаниях. Если таких средств нет, то необходимо, как минимум, ознакомиться с опытом других компаний, доступным из открытых источников: сайта www.bpmaward.ru, www.finexpert.ru, www.tadviser.ru и др. Так же можно посетить специализированные конференции для обмена опытом с коллегами.

1.6. Разработка Плана проекта внедрения СУБП.
Процессный офис разрабатывает План внедрения СУБП. Если в компании развита культура проектного управления, то по всем правилам может быть создан Устав проекта.

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

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

Далее выделяются необходимые ресурсы: время руководителей и специалистов, инфраструктура, технические и финансовые средства, программное обеспечение. Сделать это нужно быстро, не затягивая на несколько месяцев.

2. Разработка документа «Концепция внедрения СУБП в компании»

2.1. Формирование Глоссария.
Система терминов в области процессного управления является важнейшим элементом СУБП. Процессный офис разрабатывает Глоссарий, используя общепринятые отраслевые практики, книги специалистов по BPM, доступные системы терминов, рекомендации BPM CBOK, опыт экспертов. Крайне нежелательно использовать сложные, запутанные термины.

По ходу проекта Глоссарий будет дополняться терминами с учетом используемых решений в области автоматизации СУБП.
Глоссарий должен быть доступен всем сотрудникам компании на внутреннем корпоративном web-портале.

2.2. Определение видения, целей и принципов СУБП.
Процессный офис формализует видение, цели и принципы СУБП в рамках проекта документа «Концепция внедрения СУБП в компании». В некоторых компаниях этот документ называют «Стандарт управления бизнес-процессами» и т.п. Это концептуальный, руководящий документ, скорее политика, чем регламент.

Руководитель проекта организует согласование видения, целей и принципов СУБП с руководством компании.

2.3. Архитектура бизнес-процессов компании
Процессный офис прописывает в проекте «Концепции» понятие архитектуры, как она должна формироваться, для чего и как будет использоваться.

Включать саму архитектуру в виде реестра или модели процессов в «Концепцию» нецелесообразно, так как она будет изменяться по ходу проекта. Необходимо определиться с базовыми аспектами построения и использования архитектуры процессов компании.

2.4. Определение структуры процессов для управления ЖЦ бизнес-процесса.
Процессный офис прорабатывает структуру процессов СУБП, которые необходимо спроектировать и внедрить для управления всеми значимыми бизнес-процессами в рамках их жизненного цикла.
Жизненный цикл любого процесса (см. рис 2) включает целеполагание, планирование и проектирование, внедрение изменений, выполнение процесса и оперативное управление, анализ.

Например, необходимо включить в структуру процессов СУБП «Процесс описания процессов». Это необходимо для четкой организации работы по проектированию бизнес-процессов с высоким качеством. Если пустить работу на самотек, то будут получены результаты весьма низкого качества, которые нельзя использовать. Данный процесс СУБП будет использоваться в рамках этапа ЖЦ «Проектирование процесса и планирование изменений».

Другой пример – «Разработка Технического задания на автоматизацию процесса» — то есть соответствующий бизнес-процесс и т.п.

В идеальной ситуации должны быть разработана общая модель процессов СУБП. Такая модель наглядно показывает взаимодействие процессов СУБП между собой и с другими процессами организации.

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

Важно не забыть про процессы управления самой СУБП: целеполагание, планирование работ по описанию, анализу, регламентации и автоматизации процессов, планирование проектов по совершенствованию СУБП, анализ ее эффективности и проч.

2.5. Определение методологии СУБП
Многие процессы СУБП должны базироваться на четко определенных методиках, в том числе:

1. Методика проектирования процессов.
2. Методика анализа процессов.
3. Методика автоматизации процессов.
4. Методика внедрения изменений.
5. Методика разработки целей и показателей для управления процессами.
6. Методика оперативного управления процессами.
7. Методика оценки уровня зрелости СУБП и проч.

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

2.6. Определение участников СУБП.
Процессный офис проектирует структуру будущей СУБП в части субъектов. Определяются органы управления и участники СУБП: Процессный комитет, Процессный офис, Процессный Методолог, владельцы процессов, менеджеры процессов, участники временных рабочих групп по проектированию процессов и проч. С учетом определенных процессов СУБП определяются функции, полномочия и ответственность субъектов СУБП. Готовый раздел включается в проект «Концепции».

2.7. Определение архитектуры информационных систем СУБП
В рамках «Концепции» целесообразно описать архитектуру информационных систем, которые будут использоваться в СУБП (см. рис. 3): состав, назначение и основные информационные потоки между ними. Для управления бизнес-процессами в рамках СУБП используются:

1. Среда проектирования и анализа процессов (например, Business Studio, ARIS и др.)
2. Система автоматизации процессов – BPMS (например, Bizagi, Elma и др.).
3. Внутренний web-портал.
4. BI-система.

Возможны различные комбинации систем. Например, модуль BI может быть реализован в рамках единого web-портала компании. Другой пример – использование среды проектирования и портала BPMS без отдельного программного обеспечения для проектирования процессов (Business Studio, ARIS).

Выбор архитектуры информационных систем СУБП определяется многими факторами:
• ИТ-стратегией компании;
• функциональными возможностями уже используемых в компании систем, в т.ч. web-портала;
• наличием средств для приобретения и внедрения ИТ-систем;
• ограничениями в области безопасности и проч.

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

2.8. Определение системы оценки зрелости и этапов развития СУБП компании.
В рамках «Концепции» желательно указать, что компания будет регулярно проводить оценку зрелости СУБП по соответствующим разделам.
Целесообразно показать перспективу развития СУБП на как, например, показано на рис. 4.

2.9. Презентация и утверждение Концепции внедрения СУБП.
После того, как проект «Концепции внедрения СУБП в компании» подготовлен, Процессный офис организует презентацию документа для руководства компании. Проводится обсуждение «Концепции» на совещаниях с руководством компании. «Концепция» утверждается и доводится до персонала.

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Директора АО «СО-ЕЭС», руководитель отдела Анализа и методологического обеспечения ПО № 8 ГБУ «Аналитический центр» Департамента экономической политики и развития города Москвы.

Июль 2020 г.

В статье Владимира Репина представлена методика оценки зрелости системы управления бизнес-процессами: структура разделов, примеры критериев, формулы для расчета. По представленной методике проводилась оценка в нескольких компаниях. Статья может быть полезной для сравнительного анализа и разработки собственной методики оценки зрелости в области процессного управления.

Объекты и цели оценки зрелости

Каждый объект, способный к изменению, может проходить через несколько этапов или уровней зрелости. Так же их можно назвать этапами жизненного цикла. Для чего нам нужно определять конкретный этап или уровень? Например, мы принимаем первое решение относительно возможности использования этого объекта для достижения наших целей. Второе решение – что нужно и как именно сделать, чтобы зрелось объекта соответствовала нашим целям. Например, вы наблюдаете, как созревают яблоки. Если сорвать их незрелыми, то мы не получим ни пользы, ни удовольствия. Если дать им перезреть, то есть риск снижения вкусовых качеств и повреждения птицами и проч.

Для чего собственнику оценивать зрелость его компании? Цели могут быть разные. Например, чтобы убедиться в том, что:
• создана система регулярного менеджмента и ей можно передать функции оперативного управления (уход от ручного управления);
• компания готова для привлечения стратегического инвестора/выхода на биржу/к продаже;
• создана культура инноваций и развития, которая обеспечит устойчивый рост в ближайшие годы;
• прочее.

Применительно к бизнесу, объектами оценки зрелости могут выступать:

1. компания в целом;
2. система управления компанией в целом;
3. различные подсистемы в рамках системы управления (например, подсистема управления персоналом);
4. отдельные бизнес-процессы (причем, различного масштаба).

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

Совокупность методов, инструментов, ресурсов и внедренных бизнес-процессов, направленная на эффективное развитие Компании на основе управления каждым значимым бизнес-процессом в рамках его жизненного цикла.

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

Может ли вообще существовать бизнес без целенаправленного управления деятельностью как совокупностью бизнес-процессов? Практика дает однозначный ответ — «Да». Причем такой бизнес часто бывает вполне успешным. Как это возможно? Вероятно, ответ надо искать в следующем – в уровне сложности продукта (услуги), в уровне сложности бизнеса, включая внешнюю среду организации (в широком смысле). Бизнес может быть успешным в силу внешних обстоятельств (отсутствие эффективных конкурентов) на определенном временном интервале. Кроме того, мало кто из собственников задумывается о системной работе с бизнес-процессами, если поставленные цели и так достигаются достаточно легко.

Я утверждаю, что Система управления бизнес-процессами нужна компании, которая:
a) достигла определенного уровня развития (этапа жизненного цикла);
b) находится в условиях конкуренции, требующей целенаправленного изменения бизнес-процессов для повышения их результативности и эффективности, сокращения сроков и повышения качества.

Короче говоря, если собственнику требуются стабильное качество, адекватные сроки выполнения и экономическая эффективность (снижение затрат), то ему нужна система работы с бизнес-процессами. Если собственник убежден, что использование СУБП целесообразно, то нужно ее создать и целенаправленно развивать.

Оценка зрелости СУБП может помочь понять текущий уровень развития практики работы с бизнес-процессами и наметить пути ее развития.

Далее в статье я буду говорить о методике оценки зрелости СУБП, как подсистемы общей системы управления организацией.

Хотел бы обратить внимание на следующий аспект. Использованная Методика не предполагает проведение оценки уровня зрелости каждого бизнес-процесса по отдельности. Уровень зрелости отдельного процесса – это результат приложения усилий руководства компании, владельца процесса (руководителя, ответственного за процесс) и, в определенной степени, — работы СУБП. Но оценка уровня зрелости всех процессов компании затруднена по нескольким причинам:

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

Рассмотрим простой пример. Оцениваемый процесс состоит из семи подпроцессов. Три из них оценены на максимальный балл, а четыре – на «0». Как оценить уровень зрелости процесса в целом? Можно ли считать зрелым процесс, у которого часть подпроцессов являются абсолютно незрелыми? Я считаю, что нет, нельзя. С какого уровня начинать оценку? Как агрегировать результаты оценки по иерархии процессов вверх до уровня категорий? Методика, дающая ответы на эти вопросы, была разработана мной (вместе с некоторыми коллегами) в рамках проекта на Челябинском трубопрокатном заводе (Группа ЧТПЗ), но оказалась слишком сложной.

Вернемся к аналогии. Можно оценивать каждого отдельного сотрудникам компании и потом делать какие-то усреднения и выводы, а можно оценивать зрелость системы управления персоналом. Это весьма разные вещи. Сотрудники приходят и уходят, а система остается. Бизнес-процессы развиваются от версии к версии. Поэтому я считают целесообразным оценивать зрелость именно СУБП, а не всех бизнес-процессов компании.

Существующие подходы к оценке зрелости

Известно множество подходов к оценки процессной зрелости, причем как отдельных процессов, так и процессной зрелости организации в целом. Например, модель PEMM Майкла Хаммера (см. статью – «Оценка уровня зрелости процесса по методике PEMM Майкла Хаммера») или ГОСТ Р ИСО/МЭК 15504 (см. статью – «Оценка уровня зрелости процесса по методике ГОСТ Р ИСО/МЭК 15504-2»).

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

Очевидно, что представленные выше формулировки сложно назвать адекватными задаче. Если задавать такие вопросы обычным руководителям обычной компании, то тебя просто не поймут.

Критерии оценки должны быть достаточно просты и понятны. Вопросы должны давать возможность четкого ответа «Да» или «Нет», основанного не на субъективном мнении, а на фактах.

Один и с коллегами (Виталий Елиферов и др.) я проводил оценку как отдельных процессов, так и системы управления для различных организаций. Применяемые нами методы варьировались от простой анкеты оценки процесса, до комплексной оценки системы управления. Однако, степень субъективности оценки меня не всегда удовлетворяла.

Например, если спросить любого руководителя, фиксирует ли он отклонения при выполнении процесса, то вряд ли кто-то осознанно скажет: «Нет». То есть ответ всегда будет «Да». Вроде бы, налицо элемент управления бизнес-процессом. Но это не так. Если сам процесс ни разу не был представлен в виде схемы? Если никто не знает, что такое правильный, корректный ход процесса, а что такое отклонение?

Если не определено, какое отклонение считать значимым? Как в этом случае нужно оценивать ответ руководителя? И так во всем… Нужен метод, который снижает уровень субъективности до приемлемого и измеряет реальную практику работы с бизнес-процессами, а не то, что руководители считают или выдают за таковую.

Результаты оценки по такому методу должны давать возможность анализировать динамику развития СУБП компании, сравнивать состояние СУБП различных компаний и делать практические выводы. Поэтому в какой-то момент я решил разработать собственную Методику оценки зрелости СУБП, и она была создана.

Методика оценки зрелости СУБП

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

1. Архитектура бизнес-процессов.
2. Управление бизнес-процессами по целям и показателям.
3. Система стимулирования руководителей на улучшение бизнес-процессов по КПЭ.
4. Практика описания и анализа бизнес-процессов.
5. Практика оптимизации бизнес-процессов и внедрения изменений.
6. Автоматизация бизнес-процессов (в BPMS).
7. Стандартизация бизнес-процессов.
8. Контроль и аудит бизнес-процессов.
9. Корпоративная система обучения персонала методам процессного управления.
10. Процессный офис.

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

Для каждого из десяти разделов определен состав подразделов. Например, вот структура для подраздела «Архитектура бизнес-процессов» (Таблица 1):

Для чего нужны веса? Для полноты и широкого охвата необходимо рассмотреть различные аспекты СУБП, как системы. Некоторые из них являются более важными, другие – менее. Тем не менее, все они характеризуют состояние СУБП. Если взять какой-то один критерий (подраздел), то оценка будет неточной. Использование нескольких критериев дает возможность повысить точность оценки. Веса вводятся для того, чтобы менее значимые, но тоже важные критерии, не искажали общий результат оценки. Выбор весов проводится один раз, например, путем опроса экспертов на стадии разработки методики. В последующем веса уже не должны меняться.

Приведу пример метода оценки по подразделу «Реестр процессов» (Таблица 2). Этот критерий характеризует полноту процессной архитектуры компании. В случае, если процессы соответствующего уровня определены в архитектуре бизнес-процессов компании, то указанное в таблице значение включается в общую сумму по каждому типу и по каждому уровню. Рассчитывается суммарное значение и, затем, оценка по подразделу.

Категории и группы – это почти стандартные названия, используемые при построении архитектуры процессов компании (полный глоссарий в статье приводить не планируется).
Приведу еще пример подразделов для раздела «Стандартизация бизнес-процессов» — см. Таблицу 3.

Например, оценка по подразделу «Наличие ВНМД по стандартизации бизнес-процессов» осуществляется при помощи следующей Таблицы 4 (ВНДМ – внутренний нормативно-методический документ компании – регламент, положение, инструкция).

Стоит отметить, что в данном случае уже имеет место некоторая субъективность. Что значит «фрагментарный стандарт»? Для меня это понятно – в нем отсутствуют или плохо проработаны необходимые фазы управления жизненным циклом ВНМД компании. Например, не описаны требования по вводу ВНДМ в действие и т.д. Для проведения оценки по данному критерию необходимо использовать соответствующий чек-лист.

Еще пример. Оценка по подразделу «Качество ВНМД» осуществляется следующим образом:

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

1. счетные критерии, например:
   a. N процессов из M обладают каким-то свойством;
   b. 25% < доля инструкций, формируемых автоматически ≤ 50%.
2. критерии, основанные на фактах, например:
   a. «Работа с корректирующими и предупреждающими действиями не автоматизирована» (все на бумаге, в MS Word и MS Outlook).
3. критерии, измеряемые при помощи чек-листов, например:
   a. контроль качества графической схемы процесса (с расчетом среднего количества ошибок на одну схему).
4. критерии, рассчитываемые как среднее значение субъективной оценки многими руководителями какого-то аспекта СУБП по простой шкале: низкая эффективность, средняя эффективность, высокая эффективность; очень высокая эффективность (практически в каждом разделе есть подраздел с субъективной оценкой руководителями).

Далее. Оценка по каждому разделу осуществляется по формуле:

Рассмотрим пример оценки по разделам и расчет общей оценки зрелости СУБП, представленный в Таблице 5.

Сумма баллов — 36.
Коэффициент неравномерности – 0,95.
Оценка зрелости СУБП – 34 балла.

Коэффициент неравномерности вводится для того, чтобы несколько занизить оценку в случае, если по каким-то разделам оценка высокая, а по другим — низкая. Например, практика описания процессов – 9, а практика внедрения изменения – 1. Так быть не должно. Какой смысл описывать процессы, если эта работа не сопровождается внедрением изменений? Коэффициент неравномерности можно сделать еще более жестким, например, используя размах вместо среднеквадратичного отклонения. Но это на усмотрение компании.

Общая оценка зрелости СУБП может составлять от 0 до 100 баллов. Предлагается использовать следующие уровни оценки СУБП компании (см. таблицу 6).

Пример результатов оценки зрелости СУБП

Результаты оценки зрелости СУБП целесообразно представлять визуально, например, при помощи следующих диаграмм. На рисунке 1 представлены результаты оценки в виде ползунковой диаграммы (шкалы) для вымышленной компании. С учетом коэффициента неравномерности, получено 13 баллов – уровень оценки СУБП компании «Очень низкий».

На рисунке 2 представлены диаграммы оценки процессной зрелости этой условной компании в N-ом году и план развития СУБП на N+1 год.

Для развития СУБП в N+1 году необходимо разработать план мероприятий как по каждому аспекту СУБП, так и по системе управления бизнес-процессами в целом. Мероприятия, включенные в план, получают определенные приоритеты. Определяется бюджет развития СУБП на следующий год.

Повторная оценка СУБП проводится через год по той же Методике. Сопоставление оценок позволяется сделать выводы о динамике развития СУБП компании.

Резюме

В статье представлена авторская Методика оценки зрелости Системы управления бизнес-процессами компании.

Основные принципы и критерии оценки, включенные в данную Методику, были применены автором при проведении аудита системы управления ГК «Сибпроект» и других компаний.

Далее методика была доработана в рамках проекта создания корпоративной системы оценки процессной зрелости Челябинского трубопрокатного завода (Группа ЧТПЗ). Частично Методика применялась при создании системы оценки организационной зрелости компании «Ярмарка».

Затем структура Методики была уточнена при проведении оценки зрелости СУБП компании «Пакер».

Законченный вид Методика приобрела в рамках проекта оценки зрелости СУБП «Иркутской нефтяной компании».

В настоящее время, по ходу практической работы, я вношу изменения и дополнения в Методику, в том числе в части форм чек-листов, состава и формулировок анкет и проч.

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Директора АО «СО-ЕЭС».

Январь 2020 г.

Компетенции для BPM-проекта

В 2013 году компания Gartner предложила модель компетенций, которые необходимы для успешного выполнения BPM-проекта в компании (BPM – Business Process Management). Для внедрения процессного управления, согласно этой модели, проектной команде необходимы компетенции по трем направлениям: трансформационные, операционные и технические. Рассмотрим их подробнее (см. таблицу 1).

Трансформационные компетенции

Успех проекта оптимизации бизнес-процесса во многом зависит от… выбора этого процесса. Выбрав процесс, эффект от оптимизации которого минимален, мы никогда не окупим потраченные ресурсы. Но как сделать выбор? Почему конкретный процесс должен быть выбран? Как такой выбор повлияет на достижение стратегических целей? Опыт и чутьё полезны, но кроме них необходимы четкие критерии выбора и подходящая методика. Процесс – узкое место. Процесс – ключевой фактор для цифровой трансформации. Процесс многократно повторяется и может быть тиражирован в регионы, филиалы и т.п. «Умение готовить бизнес-обоснование и наличие видения» — первая необходимая компетенция для руководителя.

Вторая трансформационная компетенция – это управление проектами. Можно просто описывать процессы, а можно описывать в срок с конкретным результатом и внедрением изменений. Это вполне очевидно. Но, к сожалению, довольно часто BPM-проект начинается и идет полупартизанским методом, потому что «… у нас очень сложно оформить что-то как проект…».

Третья компетенция «Знание организационной структуры и корпоративной культуры» является одной из ключевых, на мой взгляд. Понятно, что знание орг. структуры – это не столько знание схемы, сколько реальных людей с их возможностями и связями. Без этих знаний и умений в подборе союзников для проекта и нейтрализации оппонентов, определения реальных возможностей и скорости изменений, BPM-проект вряд ли состоится.

Еще две трансформационные компетенции тесно связаны с третьей. Это – коммуникации и методы управления изменениями. Если вы сформулировали проблему и выявили ее причины, собрали совещание, обсудили проблему, протоколом распределили задачи исполнителям, то можно сказать, что уровень коммуникаций и управления изменениями в компании… низкий. Дело в том, что наличие протокола и закрепления задач по отдельным исполнителям совершенно не означает, что:
• протокол содержит обдуманный план действий;
• задачи будут выполнены и проконтролированы (зависит от культуры исполнения);
• исполнители будут работать как единая команда;
• другие сотрудники компании будут уведомлены о планируемых изменениях;
• четко сформулированы и практически использованы критерии оценки результативности изменений.

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

Операционные компетенции

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

Вторая компетенция – это «Моделирование, анализ и проектирование бизнес-процессов». Одна довольная обширна. Нужно уметь моделировать процессы «как есть» в современных нотациях (например, eEPC или BPMN) с использованием различных программных продуктов (например, BizAgi или Camunda Modeler, ARIS, Business Studio и проч.). Нужно владеть методами анализа процессов, например: анализ ограничений, времени выполнения, потерь. Нужно знать принципы и методы оптимизации процессов, например: вертикальное и горизонтальное сжатие процесса, устранение узких мест и др. Рассматриваемая компетенция является ключевой.

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

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

Последняя компетенция в группе операционных компетенций – «Подбор инструментов, поддерживающих методологию BPM». Выбор адекватного инструмента важен для успешного выполнения проекта. Например, нецелесообразно долго выбирать и настраивать сложный инструмент, если проект короткий, а решение по масштабному внедрению в компании не принято. Есть риск, что «весь пар проектной команды уйдет в свисток». Можно полгода обосновывать покупку системы ARIS, а можно взять бесплатный Camunda Modeler и быстро решить поставленную задачу, показав хороший результат.

К сожалению, некоторые руководители считают, что покупка системы для описания процессов сразу даст результат – улучшения. Это не так. Описание процесса в каком-либо формате без анализа, расчетов и обоснования изменений не дает существенного результата с точки зрения повышения производительности, эффективности и времени. Давайте на примере. Принципиальная схема радиоэлектронного устройства содержит набор элементов. Наивно было бы думать, что путем их визуального расположения на схеме без расчета параметров работы мы получим нужный результат на выходе. Но для схемы бизнес-процесса это делают сплошь и рядом, выпуская регламенты на основе схем без каких-либо расчетов производительности и времени выполнения процессов, без учета взаимодействия с другими процессами и загрузки ресурсов в других процессах! Еще одна аналогия – это разработка печатной платы. Там детали нужно разместить в соответствии с принципиальной схемой, но с учетом их размеров, теплового режима работы и проч. Схема процесса на бумаге отличается от реально запущенного процесса также, как принципиальная электрическая схема от работающей печатной платы.

Технические компетенции

Допустим, вы описали процессы. Что дальше? Как проектировать новые, эффективные и цифровые процессы? С практикой 70-х годов далеко не уедешь. Проектная команда должна, как минимум, четко представлять себе возможности современных средств автоматизации и тенденции их развития. Первая техническая компетенция – это «Архитектура и дизайн решения». Сотрудники должны знать, как устроена типичная BPMS (возможно, даже Low-code система), что она может делать, а что — нет.

Вторая техническая компетенция – «Знание программного обеспечения BPM». Процессы можно проектировать по-разному. Для регламентов верхнего и среднего уровня будет достаточно довольно общего, аналитического описания. Но для настройки BPMS такие модели не годятся. Нужно проектировать исполняемые процессы, а для этого надо знать, как работает BPM-система.

Конечная цель почти любого BPM-проекта – это автоматизация процессов, поэтому компетенция «Разработка приложений от модели и по аджайлу» является крайне важной. Хотя бы кто-то из участников проектной группы должен ей владеть.

Для создания эффективного процесса недостаточно только сформировать его схему. Как будет работать процесс при реальной нагрузке на входе и недостатке ресурсов? Как обеспечить необходимые показатели производительности, времени и затрат? Для этого требуется компетенция под названием «Имитационное моделирование и оптимизация процессов». Ряд современных программных продуктов позволяют создавать и использовать имитационные модели процессов для расчета необходимых показателей до внедрения, что может помочь заметно сэкономить.

Для создания результата, который нужен потребителю, умение «Проектирование взаимодействия с пользователями» является весьма важным. Кроме того, команда проекта может использовать методы CJM (Customer Journey Mapping).

Структура компетенций по ролям

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

1. Бизнес-заказчик – руководитель верхнего уровня (ГД, Зам. ГД, директор департамента).
2. Владелец процесса — руководитель верхнего или среднего уровня. Он может быть так же бизнес-заказчиком, а для компаний среднего и небольшого размера – одновременно руководителем проекта.
3. Руководитель BPM-проекта – руководитель среднего уровня или нижнего уровня, ведущий специалист.
4. Эксперт в предметной области – руководитель среднего или нижнего уровня, ведущий специалист, специалист, внешний привлеченный отраслевой эксперт.
5. Процессный методолог – руководитель или ведущий специалист в структуре Процессного офиса (методически курирует проект).
6. Бизнес-аналитик – сотрудник Процессного офиса.

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

Рассмотрим необходимые уровни «прокачки» компетенций по каждой роли BPM-проекта. Ниже представлено экспертное мнение автора статьи. Еще раз хочу подчеркнуть, что нерационально требовать, например, от бизнес-аналитика уровня понимания бизнес-видения и знания организации, как от топ-менеджера. С другой стороны, странно было бы требовать от топ-менеджера детального знания нотации BPMN и т.п.

В статье я часто употребляю термин «компетенция». В Википедии приводится следующее определение: «Профессиональная компетенция — способность успешно действовать на основе практического опыта, умения и знаний при решении профессиональных задач». В Трудовом кодексе РФ термина «компетенция» нет, но определяется «квалификация», которая понимается как совокупность «знаний-умений-навыков».

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

Структура трансформационных компетенций представлена в следующей Таблице 1 и на Диаграмме 1. Уровни «прокачки» каждой компетенции показаны по шкале от 1 до 5 баллов и определены следующим образом:
• Уровень 1: Достаточный. Компетенции приближаются к базовым требованиям стандарта.
• Уровень 2: Удовлетворительный. Компетенции полностью удовлетворяют стандарту.
• Уровень 3: Хороший. Компетенции полностью удовлетворяют и по ряду аспектов превышают требования стандарта, четко выражены.
• Уровень 4: Очень хороший. Компетенции по многим аспектам превышают требования стандарта, четко выражены, сохраняются в течение длительного периода.
• Уровень 5: Отличный. Компетенции на уровне лучших отраслевых практик, существенно превышают требования стандарта, четко выражены, сохраняются в течение длительного периода.

Под стандартами в данном случае подразумеваются внутренние стандарты компании, полностью или частично основанные на внешних стандартах.

Структура операционных компетенций представлена в следующей Таблице 3 и на Диаграмме 2.

Структура технических компетенций представлена в следующей Таблице 4 и на Диаграмме 3.

Если коротко, то можно предложить для обсуждения следующее видение:
• у бизнес-заказчика (владельца процесса) должны быть очень хорошие (хорошие) трансформационные компетенции. При этом операционные могут быть удовлетворительные (достаточные), а технические – достаточные (ну не должен Зам. ГД уметь писать скрипты на C#);
• руководитель проекта должен обладать очень хорошими (хорошими) трансформационными, хорошими операционными и очень хорошими техническими компетенциями (особенно для проектов, ориентированных исключительно на автоматизацию бизнес-процессов);
• эксперту в предметной области (специалисту структурного подразделения) требуется удовлетворительные трансформационные, достаточные (удовлетворительные) операционные и технические компетенции (т.е. не обязательно его детально учить настройкам BPMS, если только он потом не будет лично настраивать систему в своем подразделении);
• процессный методолог должен обладать очень хорошими трансформационными компетенциями (местами хорошими), отличными и очень хорошими операционными компетенциями, очень хорошими и хорошими техническими компетенциями. Это самый сложный случай. Найти такого методолога весьма сложно, но он стоит своих денег;
• бизнес-аналитик должен обладать удовлетворительными (местами, хорошими) трансформационными компетенциям. Операционными компетенции должны быть очень хорошие. Технические – хорошие (удовлетворительные).

Из представленных выше таблиц видно, что набор компетенций и необходимая глубина их освоения разные. Как их оценить? Для решения этой задачи можно использовать шкалы оценки.

Шкалы для оценки компетенций

Рассмотрим шкалы оценки трансформационных компетенций (разработаны автором статьи). Шкала для первой компетенции «Умение готовить бизнес-обоснование и наличие видения» представлена на рис.1. Шкалу следует читать так: требования к компетенциям суммируются слева направо. Например, на втором уровне сотрудник не только «Умеет оценивать ROI, привлекательность для бизнеса», но и «Может определять и оценивать риски для бизнеса».

Шкала оценки по компетенции «Управление проектами» представлена на рис.2.

Шкала оценки по компетенции «Знание организационной структуры и корпоративной культуры» представлена на рис.3.

Шкала оценки по компетенции «Коммуникации» представлена на рис.4.

Шкала оценки по компетенции «Методы управления изменениями» представлена на рис.5.

Теперь перейдем к шкалам оценки операционных компетенций. На рис. 6 представлена шкала оценки по компетенции «Выявление бизнес-процессов».

На следующем рисунке 7 представлена шкала оценки по компетенции «Моделирование, анализ и проектирование бизнес-процессов».

Шкала для компетенции «Регулирование и организация процессной работы» представлена на рис. 8.

На следующем рисунке 9 представлена шкала оценки по компетенции «Управление эффективностью процессов».

На следующем рис. 10 представлена шкала оценки для компетенции «Подбор инструментов, поддерживающих методологию BPM».

Шкала для компетенции «Архитектура и дизайн решения» представлена на рис. 11.

На следующем рис. 12 представлена шкала оценки для компетенции «Знание программного обеспечения BPM».

На следующем рис. 13 преставлена шкала оценки для компетенции «Разработка приложений от модели и по аджайлу».

Шкала для компетенции «Имитационное моделирование и оптимизация процессов» представлена на рис. 14.

Шкала для компетенции «Проектирование взаимодействия с пользователями» представлена на рис. 15.

Для каждого уровня каждой шкалы должны быть разработаны контрольные вопросы (как минимум, 2-3), ответы на которые позволят подтвердить достижение соответствующего уровня сотрудником. Создание таких вопросов (критериев) сопряжено, как минимум, с рядом проблем:
• возможность неоднозначной интерпретации вопроса;
• субъективность оценивающего субъекта;
• недостаточная квалификация оценивающего субъекта (например, оценивать знание нотации BPMN не может человек, который никогда не видел ни одной модели в этой нотации);
• недостаточно четкие (противоречивые) стандарты, на основании которых могут быть сформулированы вопросы;
• неоднозначная и противоречивая «лучшая» отраслевая практика.

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

Чтобы перейти на соответствующий уровень по шкале оценки нужно набрать от 75% до 100% по текущему уровню и не менее 50% по следующему уровню.
Например, по Уровню 2 получено 78%, по Уровню 3 – 42%, а по Уровню 4 – 80% (см. Таблицу 7). В этом случае, в качестве подтвержденного может быть выбран только Уровень 2, так как хорошее знание принципов и/или лучших практик не является основанием для высокой оценки конкретных практических навыков базового уровня.

При разработке шкал и критериев целесообразно использовать доступные источники по этой теме.

Учебные программы и материалы для развития компетенций

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

Очевидно, что некоторые из указанных программ уже могут использоваться в компании (проводилось обучение). Необходимо выяснить несколько вопросов:
• кто и когда был обучен?
• каковы реальные полученные сотрудниками знания, навыки, умения?
• планируется ли включать этих сотрудников в команды по BPM-проектам?

Хотел бы обратить внимание, что программы по одной теме могут быть разные по длительности, сложности и содержанию в зависимости от того, кого мы будем учить. Для создания «достаточных» умений годится короткая обзорная программа и простые упражнения. Для «Хороших» — подробная программа со сложными упражнениями, «домашними заданиями» и тестами. То есть можно иметь несколько уровней сложности по конкретной программе и соответствующую систему заданий, тестов и аттестации (возможно с последующей выдачей внутренних сертификатов, значков и т.п.)

Глядя на количество курсов, представленных в таблице 7, можно подумать, что получилась программа MBA. Чтобы не измучить людей теорией, каждый курс должен быть максимально практическим – обязательно нужно в него включать:
• конкретные документированные методики;
• примеры;
• сложные и полезные практические задания (а не просто рефлексию после вопроса типа: «Посмотрите на лампочку – что вы чувствуете?»).

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

Для развития компетенций руководителей и сотрудников я провожу для компаний семинары и тренинги по различным программам, в том числе:

1. «Внедрение системы управления бизнес-процессами», 2 дня.
2. «Стандартизация бизнес-процессов», 2 дня.
3. «Моделирование бизнес-процессов в нотации BPMN», 2 дня.
4. «Описание, анализ и регламентация процессов в Business Studio», 2 дня.
5. «Имитационное моделирование и анализ процессов в Business Studio», 2 дня.
6. Прочие специальные программы, составленные по запросам заказчиков.

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

Одновременно с разработкой учебных программ необходимо создать систему подтверждения компетенций. Она может включать систему тестов для каждого уровня и роли в проекте. Частично можно подтверждать компетенции с использованием внешних сервисов. Рассмотрим два из них.

Подтверждение компетенций

Организация ABPMP Russian Chapter разработала профессиональный стандарт «Специалист по процессному управлению», который утвержден приказом Министерства труда и социальной защиты Российской Федерации от «17» апреля 2018 г. № 248н. Так называемая «Функциональная карта вида профессиональной деятельности», представленная в Стандарте, включает следующие «Обобщенные трудовые функции»:
• A. Регламентация процессов подразделений организации или разработка административных регламентов подразделений организации, уровень квалификации 6.
• B. Проектирование и внедрение кросс-функциональных процессов организации или административных регламентов организации, уровень квалификации 6.
• C. Проектирование и внедрение системы процессного управления организации, уровень квалификации 7.
• D. Проектирование и трансформация процессной архитектуры организации, уровень квалификации 7.

Для подтверждения компетенции Процессного методолога и бизнес-аналитика можно использовать тест, разработанный ABPMP Russian Chapter в соответствии с требованиями профессионального Стандарта. Пройти тест «на здравом смысле» не получится – для правильных ответов на многие вопросы нужно не просто знать теорию, но иметь опыт практического использования соответствующих методик и инструментов.

Рассмотрим другой сложный, но полезный путь развития и подтверждения компетенций в области BPM – это прохождение сертификации OMG CERTIFIED EXPERT IN BPM™ 2 (OCEB™ 2). Структура тестов представлена на следующем рисунке 16.

К числу участников BPM-проектов относятся и представители бизнеса, и технические специалисты. Очевидно, что они используют на практике различные наборы методов и инструментов, поэтому программа OCEB 2 разделена на два направления после базового. Это сделано для того, чтобы была возможность проходить сертификацию среднего и продвинутого уровня в зависимости от вашей профессиональной ориентации. Сертификация на каждом уровне требует сертификации на нижестоящих уровнях.

Базовый уровень OCEB 2 требует от участника BPM-проекта определенных знаний и умений. Экзамен этого уровня, в первую очередь, охватывает базовые концепции и термины бизнеса в целом, целеполагания и планирования, управления бизнес-процессами. Далее тест включает область моделирования бизнес-процессов с использованием нотации BPMN 2 (40% теста). Экзамен завершается темами качества процессов, организации процессной работы, разработки системы показателей для управления процессами.

В случае успешной сдачи экзамена вы получаете сертификат, который действует в течение 5 лет. Это вполне разумно и справедливо, так как знания забываются, а не используемые каждый день навыки могут быть потеряны.

Для чего проходить тесты OCEB 2? Для меня лично важны следующие возможности:
• получить признание профессионализма в области BPM;
• систематизировать свои знания в области BPM и узнать что-то новое;
• понять и использовать структуру вопросов для построения внутрикорпоративной системы тестирования;
• ознакомиться с лучшей литературой по теме (на английском языке);
• подтянуть свой английский.

Кроме сертификации по проф.стандарту и OCEB 2, можно пройти учебные курсы и сертификацию у поставщиков различных BPM-систем. Конечно, желательно изучать ту систему, которую предполагается использовать в компании. Но если решение пока не принято, то можно использовать свободно (бесплатно) распространяемые BPM-системы и методические материалы к ним (например, российская RUNA WFE и др.). К сожалению, пока в книжных сетях практически нет учебных курсов (методических пособий) для самостоятельного изучения современных BPM-систем.

Итак, можно отметить следующие возможности по подтверждению компетенций для BPM-проекта:
• внутрикорпоративная система сертификации;
• сертификация по специальности «Специалист по процессному управлению»;
• сертификация OMG OCEB 2;
• сертификация у поставщиков программного обеспечения для BPM;
• сертификация специализированных тренинговых компаний.

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Зам. Председателя Правления АО «СО-ЕЭС».

Декабрь 2019 г.

В статье Владимира Репина обсуждаются вопросы использования нотации BPMN в качестве корпоративного стандарта проектирования бизнес-процессов компании. Рассматриваются аргументы «За» и «Против» применения. Представлены предложения по организации обучения сотрудников. Приводится практический пример внедрения нотации на крупном предприятии. Обсуждаются «подводные камни» использования нотации BPMN на первых этапах проекта.

Какие нотации используют компании для описания процессов сегодня?

Многие успешные компании, внедряющие технологии автоматизации бизнес-процессов, используют нотацию BPMN. Многие, но не все… Более того, в РФ существует огромное количество средних и крупных предприятий, на которых вообще отсутствует принятый корпоративный стандарт проектирования бизнес-процессов. Какими средствами они «рисуют» процессы? Чаще всего в MS Visio используют набор объектов для «Простой блок-схемы». Бывают ситуации хуже, когда в компании одновременно применяют 3-4 разных подхода к описанию процессов, причем все они нестандартные и реализованы в различных «нотациях» и программных продуктах, включая MS Excel и Power Point.

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

К чему приводит такая практика проектирования бизнес-процессов? Во-первых, схемы процессов понятны весьма узкому кругу лиц, а не всем сотрудникам компании. Во-вторых, такие схемы, чаще всего, носят аналитический характер. Это означает, что процесс описан весьма укрупненно, без деталей. Таки схемы нельзя «исполнить». Если попытаться выполнить работу как указано на схеме, то сразу возникнут вопросы, ответов на которые схема не дает. Это звучит странно – как схема, предназначенная для описания алгоритмов, дает сбои при описании процессов для бизнеса? Конечно, ответ заключен не в наборе используемых значков нотации. Причина — в идеологии формирования схемы.

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

Ситуацию с использованием устаревших подходов частично усугубляет наличие в крупных компаниях действующих систем электронного документооборота. То, что в них творится, назвать автоматизацией бизнес-процессов можно весьма условно. Большинство руководителей это понимает, но не знает возможностей современной BPMS (Business Process Management System) в части автоматизации процессов и, особенно, применения концепции «Документ без документа». Вообще, относительно недавно вступил в стадию умирания бумажный документооборот, а теперь и электронный документооборот должен умереть, оставив вместо себя автоматизированные процессы с нужным набором данных. В BPMS, если потребуются, документы можно формировать автоматически, так сказать, «налету».

Использование нотации BPMN в качестве корпоративного стандарта дает возможность не только проектировать процессы, но и внедрять в массы идеологию исполняемых процессов в купе с новыми ИТ-технологиями, такими как PM (Process Mining), RPA (Robotic Process Automation) и проч. Рассмотрим аргументы «За» и «Против» использования нотации BPMN в качестве корпоративного стандарта.

Почему нотация BPMN: «За» и «Против»

Руководителям компании нужно объяснить, что BPMN – это не просто значки другого, незнакомого вида и цвета. Это – инженерный стандарт проектирования исполняемых бизнес-процессов, обладающий следующими преимуществами (плюсами):
• наглядность, понятность и красота схем;
• после базового обучения можно начинать с использования ограниченного набора объектов;
• BPMN — стандарт ISO с 2013 года;
• BPMN де-факто использует большинство разработчиков BPMS.

Да, BPMN – сложный стандарт. Однако, даже начинающие при использовании ограниченного набора объектов и понимания сути метода (исполняемый процесс, токен, экземпляр) могут проектировать вполне качественные схемы. Более того, применение сложных семантических конструкций без действительной практической необходимости может только осложнить работу, привести к созданию неоправданно сложных схем или вообще исказить смысл процесса до неузнаваемости. С чем бы сравнить? Это как неопытный спортсмен, не освоивший базовую технику бросков, начинает пытаться применять сложные и опасные приемы. Я уверен, что можно обучить сотрудников, так сказать, использовать верхушку айсберга. Этого на первых порах будет достаточно. Крайне важно, чтобы сотрудники компании научились формировать наглядные, понятные и красивые схемы. Много раз на практике наблюдал ситуацию, когда запутанная, уродливая схема после соответствующей доработки становится красивой, а главное, понятной участникам процесса и внутреннему заказчику – руководителю.

Что важно донести до руководителей?

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

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

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

По ходу вовлечения, руководителям обязательно нужно показывать возможности, ограничения и условия эффективного использования современных решений класса BPMS, PM, RPA, AI и проч. Но надо четко понимать, что передаваемая и, можно сказать, культивируемая в умах менеджеров идеология исполняемых бизнес-процессов является базой для пропаганды новых информационных технологий.

Как обучать сотрудников нотации BPMN?

Это не так уж и сложно. Нужно:

1. найти хорошего специалиста, который умеет преподавать тему, и обсудить с ним учебную программу;
2. подготовить учебные и методические материалы;
3. выбрать инструмент моделирования;
4. разработать внутренний стандарт применения нотации BPMN для проектирования бизнес-процессов;
5. организовать обучение;
6. организовать работу по практическому закреплению навыков моделирования процессов.

В настоящее время специалистов, хорошо знающих BPMN, на рынке уже достаточно много. Но важно, чтобы такой специалист мог научить использовать нотацию на простых и понятных примерах, без использования «птичьего языка» (сленга ИТ-специалистов – профессиональных внедренцев BPMS). Кстати, я категорически против так называемого «каскадного» обучения, когда одного сотрудника отправляют на тренинг, а он потом пытается учить всех остальных. Результат – множество ошибок, а главное, — искаженное понимание темы.

Обучение проектированию процессов в нотации BPMN я провожу по книге «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I». Как правило, в течение 4-6 часов слушатели делают практические задания, осваивая элементы нотации от простого к сложному. Затем, они выполняют комплексное практическое задание по проектированию трех связанных между собой процессов. Проводится презентация результатов, анализ схем по чек-листу и разбор ошибок. Для такого обучения достаточно одного дня.

Далее выдаются практические задания, которые слушатели делают в течение недели. Затем проводится рабочая сессия по представлению и разбору схем процессов («домашние задания» я проверяю заранее). После 2-3 сессий участники приобретают навык формирования вполне адекватных схем в нотации BPMN.

На следующем этапе развития можно использовать книгу Игоря Федоров «Нотация BPMN 2.0. Стандарт ISO/IEC 19510:2013 для создания исполняемых моделей бизнес-процессов», сам стандарт и множество практически полезных материалов в сети Интернет.

Идеальным вариантом освоения BPMN является практикум с использованием, собственно, BPMS (например, такой практикум проводит А.А. Белайчук, Президент ABPMP Russian Chapter, с использованием системы BizAgi). Однако, в ряде случаев это сделать технически и организационно сложно. Приходится начинать с простого. Но, как минимум, демонстрацию движения токенов вдоль схемы исполняемого процесса сделать крайне полезно.

Внедрение нотации BPMN как корпоративного стандарта проектирования процессов в Иркутской нефтяной компании

В качестве примера рассмотрим кейс внедрения нотации BPMN в «Иркутской нефтяной компании» («ИНК»), в которой я уже более 1,5 лет сопровождаю проект создания и развития Системы управления бизнес-процессами. Информацию любезно предоставил Юрий Андреевич Федосеев, начальник отдела оптимизации бизнес-процессов и стандартизации ООО «ИНК» (ОБПиС).

За время проекта в «ИНК» удалось сделать многое:
• разработан и внедрен стандарт «Моделирование бизнес-процессов»;
• установлен и настроен инструмент проектирования и анализа процессов (Business Studio 4.2);
• обучено 259 руководителей и специалистов;
• сформировано более 226 схем в BPMN;
• внешние подрядчики (в т.ч. крупные консалтинговые компании) обязаны представлять результаты работы в виде схем BPMN с учетом требований стандарта компании;
• внедрены регламенты сквозных процессов, разработанные на основе схем процессов в нотации BPMN;
• внедряется система оценки процессной зрелости компании;
• проект на стадии выбора BPMS.

Самое главное, что в «ИНК» активно формируется процессное мышление у руководителей и специалистов. Высокая практическая оценка используемых методов и инструментов подтверждается большим количеством запросов от подразделений в ОБПиС с просьбой провести анализ и оптимизацию их процессов. Юрий Федосеев отмечает: «В проектах оптимизации мы преимущественно используем базовый набор элементов нотации (стартовые и конечные события, события отправки и приема сообщения, таймеры, шлюзы и/или… Несмотря на сложность, базовые элементы и логика нотации хорошо воспринимается сотрудниками на обучении. Освоение происходит быстро. Все бизнес-аналитики отдела прошли подготовку по программе Внутренних тренеров, что позволило организовывать качественное обучение для небольших групп на постоянной основе. Мы не ставим перед собой цель описать все процессы Компании. Ценность нашей работы – в помощи, внутреннем консалтинге. Наши клиенты – подразделения, которые хотят разобраться в своей работе и в том, как лучше взаимодействовать с другими в рамках сквозных процессов. И моделирование – это наш основной инструмент в этом деле…».

«Оптимизация процессов Электроснабжения» — так назывался один из проектов «ИНК», в рамках которого использовалась технология описания и анализа процессов в нотации BPMN. По ходу проекта было сформировано 59 процессов в нотации BPMN. Описание и анализ процессов позволил выявить 10 критичных зон безответственности и последствия, к которым наличие этих зон может привести. Прогнозный экономический эффект от устранения зон безответственности составляет около 78,6 млн. рублей в год.

Второй проект с использованием BPMN, как корпоративного стандарта проектирования процессов «ИНК», — это «Оптимизация процессов Капитального строительства». В рамках данного проекта в условиях жестких ограничений удалось выстроить слаженную и эффективную работу подразделений. Основные результаты моделирования процессов на текущей фазе проекта: прозрачный процесс капитального строительства, оперативный доступ сотрудников к схемам процессов и регламентам через корпоративный портал.

Подводные камни внедрения нотации BPMN в качестве корпоративного стандарта

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

Резюме

Хочу отметить, что навык проектирования процессов в нотации BPMN – это только один из многих навыков второй группы компетенций («Операционные») модели Gartner 2013 года, которые необходимы для успешного выполнения BPM-проекта в компании. Это означает, что руководители не должны ожидать «процессно-цифрового чуда» только от того, что они заставили необученных сотрудников с низким уровнем внутренней мотивации «рисовать» схемы процессов. Другими словами, внедрение Системы управления бизнес-процессами компании – это не только проектирование процессов, но их активное улучшение и внедрение изменений, создание методов и инструментов управления бизнес-процессами.

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Зам. Председателя Правления АО «СО-ЕЭС».

Ноябрь 2019 г.

В статье Владимира Репина представлен пример описания бизнес-процесса и настройки среды моделирования Business Studio для создания технического задания на автоматизацию бизнес-процесса в BPMS. Обсуждаются вопросы вовлечения руководителей и сотрудников подразделений компании в работу по проектированию исполняемых процессов и формированию ТЗ на автоматизацию.

Возможная постановка задачи

Довольно распространенной является ситуация, когда в компании есть много схем бизнес-процессов, созданных в MS Visio. Беглый анализ показывает, что они явно неисполняемые, содержат логические ошибки, операции разного масштаба и проч. На рис. 1 представлен пример такой схемы процесса, предоставленный заказчиком.

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

Постановка задачи. Необходимо с использованием Business Studio:
а) перевести все подготовленные схемы в универсальный формат, при этом:
б) создать архитектуру бизнес-процессов компании;
с) сделать процессы исполняемыми;
д) подготовить ТЗ на автоматизацию процессов в BPMS.

Поставленная задача может быть решена путем использования программного продукта Business Studio и нотации BPMN.

В данном случае, я привел пример только одной схемы. Если бы речь шла об автоматизации одного процесса, то не было бы никакого смысла переводить схему из MS Visio сначала в Business Studio, а потом в BPMS. Но совсем другое дело, когда нужно подготовить сначала модели нескольких процессов, взаимосвязанных с точки зрения технологии и входов-выходов.

Если рассматривать/автоматизировать N процессов, не продуманных в единой архитектуре, можно упустить ряд важных деталей и не получить решение бизнес-задачи в целом. Поэтому роль среды моделирования при разработке и автоматизации нескольких взаимосвязанных процессов кардинально возрастает.

Специалист по Business Studio Иван Глебов, считает, что «дополнительным положительным результатом использования среды моделирования Business Studio для формирования ТЗ является документирование функциональной архитектуры информационных систем, используемых для автоматизации бизнес-процессов. Архитектура информационных систем формируется в разделе «Программные продукты» среды моделирования Business Studio».

Перевод схемы в нотацию BPMN в Business Studio

Схему, представленную на рис. 1, можно было бы разделить на три-четыре части и сформировать отдельные модели. Но я не пошел на этот радикальный шаг, а просто перерисовал диаграмму в Business Studio в нотации BPMN, устранив логические ошибки и некоторые, на мой взгляд, лишние операции. Полученная схема представлена на рис. 2.

Замечу, что можно использовать полученную схему для создания имитационной модели процесса. Такая модель в Business Studio применяется для валидации процесса, то есть проверки, будет ли процесс на практике стабильно выдавать результат с установленными характеристиками по стоимости, времени и качеству. К слову, практически в каждой BPMS можно тестировать подготовленные схемы (т.е. запускать токены и смотреть, дойдет ли процесс до конца), но вот запускать имитацию и получать статистические параметры процесса для его анализа и оптимизации – нельзя.

Фрагмент схемы показан на рис. 3. Использованы маркеры операций, чтобы показать, какая операция будет выполняться пользователем в интерфейсе BPMS (Business process management system), а какая может быть выполнена скриптом (соответствующий маркер и серая заливка).

Не все операции процесса при переводе в исполняемый формат сохраняются в том виде, как на оригинальной схеме в MS Visio. При разработке модели процесса для BPMS многие действия рационально объединить в рамках одной операции.

Так же показаны информационные системы, которые в текущий момент используются для выполнения операций процесса, например, «АИС «Управление планом ПИР». Кроме того, в качестве примера, показана возможность отобразить документооборот на схеме процесса и используемые для хранения документов базы данных компании.

Стоит упомянуть, что возможен импорт схем, созданных в MS Visio, в Business Studio. Но в данном случае было быстрее нарисовать «правильную» схему заново, чем редактировать схему, полученную после импорта. Но этот пример не говорит о том, что так поступать нужно всегда. Функция импорта полезна.

Настройка аналитики по бизнес-процессу и формирование ТЗ на автоматизацию

Для того, чтобы схему процесса можно было передавать для настройки BPMS, процесс должен быть исполняемым. Это означает, что токен, запустивший процесс, «добежит» до конца процесса при любом возможном сценарии. Важно, чтобы при формировании схемы процесса соблюдалась семантика нотации BPMN. В противном случае, схема не будет универсальной и пригодной для настройки исполняемого процесса в любой BPMS.

Кроме того, для настройки BPMS требуется дополнительная информация, которая не представлена на схеме. Необходимо определить, какие аналитические данные нужны автоматизации процесса в конкретной исполняемой системе. Затем настроить Business Studio путем расширения объектной модели с использованием модуля Meta Edit так, чтобы можно было удобно вносить данные через интерфейс системы. На рис. 4 показан пример возможной настройки. Для каждой операции процесса доступна закладка «ТЗ на автоматизацию», которая содержит ряд полей (атрибутов), которые необходимо заполнить.

Например, можно выбрать тип операции процесса: «в интерфейсе BPMS», «сценарий», «ручная операция» и т.д. Можно указать, что требуется настройка нормативного времени выполнения операции и указать это время. Можно добавить, что нужно измерять фактическое время выполнения т.п. Так же есть атрибут, показывающий необходимость интеграции с другой системой и проч.

После занесения информации по всем операциям процесса, можно автоматически сформировать готовое Техническое задание на автоматизацию бизнес-процесса. Для этого в Business Studio настраивается специальный шаблон отчета. Возможна выгрузка в MS Word или в MS Visio в зависимости от требований проекта. На рисунках 5 и 6 показаны фрагменты такого ТЗ. В данном случае, ТЗ сформировано в весьма упрощенной, демонстрационной форме.

Какая еще аналитика может и должна быть собрана при подготовке к автоматизации процесса в BPMS? В своей статье Андрей Чепакин предлагает следующую структуру:

1. Схема инициации процесса.
   1.1. Роль «Инициатор бизнес-процесса».
   1.2. Мотив инициации бизнес-процесса.
   1.3. Способы запуска бизнес-процесса.
2. Схема создания ценности.
   2.1. Типизация клиентов/заказчиков бизнес-процесса.
   2.2. Составляющие ценности, формируемой процессом, по типам клиентов.
   2.3. Сценарии использования процесса его клиентами.
3. Схема работы процесса.
   3.1. Спецификация входов процесса.
   3.2. Спецификация выходов процесса.
   3.3. Определение единицы потока и ее состояний.
   3.4. Ролевая модель процесса.
   3.5. Спецификация метрик и показателей процесса.
4. Схема данных процесса.
   4.1. Спецификация данных процесса.
   4.2. Определение источников данных для процесса.
5. Схема контроля процесса.
   5.1. Спецификация контролируемых метрик и показателей.
   5.2. Способы сбора и обработки данных.
   5.3. Способы доставки информации владельцам процесса.
6. Схема обратной связи процесса.
   6.1. Способы доставки обратной связи участникам процесса.
   6.2. Способы получения обратной связи от клиентов процесса.
   6.3. Способы доставки обратной связи высшему руководству.
7. Схема компетенций процесса.
   7.1. Требования к перечню участников процесса.
   7.2. Требования к компетенциям участников процесса.
   7.3. Реестр возможностей снижения требований к компетенциям.

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

Интересные мысли по аналитике высказывает Денис Котов в своей статье. Он рекомендует включать в ТЗ на автоматизацию процессов в BPMS (кроме схемы) следующую информацию:
• Модель данных.
• Объекты системы (например, договор, закупочная процедура или клиент).
• Данные процесса (информация, относящаяся к конкретному экземпляру процесса).
• Отчеты.
• Автоматизации: эскалации руководителям, расчеты («математика»), бизнес-правила, проверка из базы данных, триггеры, интеграции.

Многие специалисты считают, что модель данных, кроме схемы, является ключевой для эффективного решения задачи автоматизации процесса в BPMS. В текущей версии Business Studio, к сожалению, нельзя создать графическую модель структуры данных, как это можно быть сделать, например, в ERWin (ER модель — entity-relationship model, модель «сущность — связь» — модель данных, позволяющая описывать концептуальные схемы предметной области). В Business Studio можно только описать атрибуты для всех документов, которые используются в моделях бизнес-процессов, как показано на рис. 7.

Иван Глебов отмечает, «что хотя в настоящий момент в среде Business Studio нет возможности графически моделировать структуру данных для ТЗ, но зато в ней есть возможность давать детальное описание атрибутов документов, используемых в процессах, что позволяет достаточным образом смоделировать необходимую структуру данных в «текстово-табличном» виде. При этом, посредством MetaEdit, таблицу атрибутов документа можно дополнить колонкой, в которой, при необходимости, можно указать другой документ в бизнес-модели, с которым атрибут документа должен иметь связь при автоматизации документа в информационной системе».

Кто будет настраивать BPMS?

Настройка любой BPMS включает, как минимум:

1. создание модели организационной структуры компании;
2. создание графической модели процесса;
3. определение участников процесса и их прав;
4. определение необходимых данных;
5. настройка показателей для контроля и управления процессом;
6. создание экранных форм;
7. проверка процесса и публикация на исполняемом сервере.

К более сложным задачам настройки относятся такие задачи, как: написание скриптов, создание различных плагинов, создание сложных экранных форм и, наконец, интеграция со внешними системами.

Можно ли научить руководителей и сотрудников подразделений всем указанным выше аспектам? Да, можно. Но это, на мой взгляд, нерационально. Сотрудники компании должны понимать, что означает исполняемый процесс, и знать основные функциональные возможности конкретной системы BPM. Но учить их нюансам настройки системы долго и дорого.

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

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

На рис. 8 показано возможное видение организации работы различных команд в рамках проекта описания, оптимизации и автоматизации бизнес-процессов компании.

Может быть создано несколько команд, состоящих из сотрудников разных подразделений, которые проектируют бизнес-процессы в Business Studio, проводят анализ и формулируют требования и пожелания (например, автоматизировать выполнение конкретных операций или применить RPA). Участникам рабочих групп не нужно знать нюансы настройки BPMS, поэтому они могут сосредоточиться на проектировании эффективных бизнес-процессов. Такой подход может существенно ускорить работу по оптимизации и автоматизации бизнес-процессов компании.

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

Сравнение двух подходов. Таблица.

В случае Варианта I (столбцы 3-4) руководители и специалисты подразделений владеют компетенциями:
• по описанию и анализу бизнес-процесса;
• по использованию базового функционала BPMS на уровне пользователей.

При этом бизнес-пользователей не нужно учить несвойственным и ненужным им аспектам.
Например, менеджера по продажам, цель которого продавать товар компании, не нужно учить программировать скрипты на C# или создавать ER-модель.

В свою очередь ИТ специалистов не нужно специально учить методам анализа и оптимизации процессов (TOC, Lean, KPI).

В случае Варианта II (столбцы 5-6) руководители и специалисты подразделений должны овладеть специальными компетенциями (см. красный шрифт) на весьма глубоком уровне.

Могут ли бизнес-пользователи проектировать процессы сразу в графическом редакторе BPMS? Да, могут. При этом они, в любом случае, должны в какой-то форме фиксировать требования к дальнейшей, более сложной настройке исполняемого процесса. Вопрос – где именно? На клочке бумаги, устно или все-таки в формализованном, структурированном виде?

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

Приведу пример. В моей книге «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» представлены модели трех процессов. Первый процесс называется «Подача заявки на оплату». В компании может быть одновременно инициировано несколько экземпляров этого процесса. Второй процесс – «Согласование графика платежей на неделю». Он запускается по таймеру и выполняется один раз в неделю. Третий процесс называется «Оплата счетов». Он инициируется процессом «Согласование графика платежей на неделю». Модели процессов были созданы в Business Studio в нотации BPMN. Используя семантику BPMN, я показал на схеме, что каждый экземпляр процесса «Подача заявки на оплату» должен получить сообщения из процессов «Согласование графика платежей на неделю» и «Оплата счетов». Далее эти три схемы были переданы в качестве ТЗ специалисту по Elma, который быстро настроил исполняемые процессы в этой системе (большое спасибо!). При настройке нужно было решить несколько задач, явно выходящих за пределы компетенций бизнес-пользователя, а именно: дополнение структуры данных, создание переменных процессов, создание скриптов на C#, управляющих отправкой сообщений, доработкой модели процесса с учетом технологических особенностей работы скриптов.

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

Стоит отметить, что компетенции участников проекта должны в разумной степени пересекаться, как показано на рисунке 9.

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Июнь 2019 г.

В статье Владимира Репина рассмотрена методика формирования модели сквозного процесса масштаба компании в среде Business Studio. Приводится пример модели в нотации IDEF0. Рассматриваются сценарии выполнения сквозного процесса. Представленная методика может быть использована при работе с любым программным продуктом, предназначенным для проектирования архитектуры бизнес-процессов организации.

Введение

С точки зрения повышения эффективности бизнеса важно уметь строить и использовать для оптимизации модель сквозного процесса масштаба компании.

В качестве примера я выбрал процесс «Разработка нового изделия: от идеи до постановки на производство» и создал его модель в Business Studio.

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

Модель сквозного процесса в нотации IDEF0

На рис. 1 представлена контекстная модель этого процесса. Видно, что стрелки приходят «ниоткуда» и уходят в «никуда». Понятно, что у сквозного процесса есть внутренние поставщики и потребители (процессы). Но на контекстной диаграмме Business Studio, увы, нельзя показать междиаграммные ссылки на другие процессы модели (техническое ограничение). С этим придется мириться. С другой стороны, в данном случае важно разработать модель отдельного сквозного процесса, а не всей компании.

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

На модели А0 сквозного процесса можно использовать блоки (процессы), которых нет в функциональной модели (реестрах функциональных процессов подразделений). Почему так?

Дело в том, что видение сквозного процесса масштаба компании, его структуры является предметом для обсуждения и согласования топ-менеджеров, например, в рамках проведения Процессного комитета (создание которого рекомендует BPM CBOK).

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

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

Очевидно, что процесс такого уровня сложности невозможно представить в виде какой-то одной цепочки операций (Work Flow – поток работ, в нотации eEPC или BPMN), выполняемых конкретными сотрудниками. (Теоретически, это сделать можно, но модель будет включать несколько тысяч шагов и сотни шлюзов, что сделает ее абсолютно нечитаемой и практически неприменимой).

Если мы декомпозируем, например, «Выполнение НИОКР», то, скорее всего, на диаграмме увидим процессы, которые тоже нерационально представлять в виде диаграмм Work Flow.

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

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

Пример. Внутри блока «Разработка технологии производства нового продукта» находятся следующие подпроцессы:
• Управление разработкой технологии производства.
• Разработка НТД по продукту.
• Тестирование новых видов сырья и упаковки.
• Разработка нормативов по новому продукту.
• …

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

На рис. 3 показана диаграмма процесса «Разработка требований к новому продукту».

Семь процессов, представленные на диаграмме, выполняются последовательно только в идеальном случае (кроме блока «Анализ необходимости внесения изменений в существующий продукт»).

В реальности часть из них может работать одновременно, с разными задачами. Видно, что возможны возвраты и переделки, например, «Анализ возможности и необходимости создания нового продукта», «Разработка ТЗ на новый продукт» и «Принятие решения по новому продукту».

Если рассматривать блоки деятельности, представленные на схеме 3, как Work Flow (т.е. на следующем уровне), то для каждого такого процесса возможные различные условия:
• старта в части запуска предыдущими процессами;
• завершения в части запуска других процессов.

Сценарии выполнения сквозного процесса

На рис. 4 цветом показаны различные сценарии последовательного запуска процессов. На практике, конечно, их гораздо больше, чем три.

Желтый сценарий – «идеальный», когда всё делается с первого раза и продукт получается удачный.

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

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

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

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

Часто бывает, что при построении модели выхватывают какой-то один сценарий или микс 2-3 сценариев. При этом забывают о том, что возможны и другие сценарии. Результат – рыхлая, фрагментарная модель, которая никуда не годится (процесс не может быть выполнен).

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

Для анализа некоторых возможных сценариев выполнения сквозного процесса можно построить соответствующую матрицу – см. пример ниже.

Таблица. Сценарии выполнения сквозного процесса. Пример.

Некоторые процессы в этой таблице требуют декомпозиции еще на один уровень, прежде чем их можно будет описать в формате Work Flow (например, в нотации BPMN).

Анализ сценариев

Далее, если все процессы будут описаны в формате Work Flow, можно будет для каждого процесса рассчитать показатели выполнения одного экземпляра:
• минимальное, нормативное, максимальное время выполнения;
• затраты на выполнение.

(Кстати, для целей анализа времени выполнения и затрат можно использовать функционал имитационного моделирования в Business Studio).

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

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

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

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

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

Резюме. Если цель проекта – повышение эффективности сквозного процесса, то можно и нужно сразу браться за его описание и анализ, не пытаясь создать полную, комплексную архитектуру процессов в Business Studio. Используя функциональные возможности системы, можно:
• построить архитектуру сквозного процесса;
• описать всего его подпроцессы в нотации BPMN и увязать их по входам/выходам и условиям запуска;
• провести анализ процессов с использование движка имитационного моделирования (или без него), определить время выполнения процессов и соответствующие затраты;
• построить матрицу сценариев выполнения сквозного процесса;
• выполнить анализ и оптимизацию сквозного процесса;
• регламентировать сквозной процесс;
• разработать систему целей и показателей для управления сквозным процессом (для основных сценариев);
• разработать техническое задание на автоматизацию сквозного процесса.

В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Март 2019 г.

В статье Владимира Репина рассмотрены три нотации моделирования бизнес-процессов, при помощи которых можно создавать графические диаграммы с использованием продукта Business Studio: «Процедура», eEPC, BPMN. Обсуждаются преимущества и недостатки каждой нотации. Приводится сравнительный анализ и рекомендации по выбору нотации для описания бизнес-процессов компании.

Введение

Многие компании используют программный продукт Business Studio для описания бизнес-процессов на операционном уровне с целью их последующего анализа и оптимизации, регламентации и автоматизации.

В Business Studio представлено три нотации, которые можно для этого использовать: «Процедура», eEPC, BPMN.

Цель статьи – кратко рассмотреть ключевые преимущества и недостатки каждой нотации, а также сравнить их между собой при помощи ряда критериев.

Такой анализ и сравнение может быть полезен при выборе нотации моделирования бизнес-процессов для использования в проекте построения системы управления бизнес-процессами компании.

Нотация «Процедура»

На рис. 1 представлен пример диаграммы бизнес-процесса, сформированной в нотации «Процедура». В этой старой нотации (1974 г.) используется весьма ограниченный набор графических элементов, в том числе: стартовое и завершающее события – овал, операция процесса – четырехугольник, операция принятия решения или шлюз типа «исключающее «ИЛИ» (кто как использует) – ромб, стрелка с одним наконечником («Связь предшествования») – для отображения потока работы, стрелка с двумя наконечниками – для отображения потока объектов (в первую очередь, документов).

Рассмотрим ключевые преимущества и недостатки нотации «Процедура».

Преимущества:
• внешняя простота;
• интеграция с IDEF0 по потокам объектов;
• возможность использования междиаграммных ссылок для интеграции моделей в архитектуре.
Недостатки:
• морально устарела;
• примитивная семантика, в т.ч. отсутствие нормального аппарата шлюзов и событий;
• отсутствие визуальных значков для моделирования движения документов и статусов;
• нельзя использовать промежуточные события;
• некорректная работа имитации;
• невозможность экспорта моделей в BPMS для автоматизации.

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

При использовании «Процедуры» весьма удобно, что стрелки с диаграммы в нотации IDEF0 мигрируют на диаграмму в «Процедуре» автоматически. Кроме того, на «Процедуре» можно использовать междиаграммные ссылки, напрямую увязывая процессы между собой по входам/выходам и условиям старта/завершения.
На этом преимущества «Процедуры» заканчиваются. Семантика этой морально устаревшей нотации не позволяет удобно моделировать сколько-нибудь сложные ситуации, которые возможны в реальных бизнес-процессах. В «Процедуре» нет логических операторов (кроме «ромба»). Нельзя использовать промежуточные события. Нет значков документов. Имитация в нотации «Процедура» работает некорректно. Это значит, что невозможно адекватно анализировать процесс и обосновывать решения по его оптимизации. Так же следует отметить, что из «Процедуры» невозможен корректный экспорт в BPM-системы для последующей автоматизации.

Нотация eEPC

На рис. 2. представлен пример диаграммы процесса в нотации eEPC. Это тот же процесс, который был описан в «Процедуре» выше.

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

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

Диаграммы в нотации eEPC всегда занимают намного больше места, чем диаграммы в нотациях «Процедура» и BPMN. Кроме того, моделирование в eEPC занимает в несколько раз больше времени, чем в других нотациях.

Нотация eEPC имеет весьма ограниченную семантику. Это приводит к тому, что для сложных практических случаев приходится искать обходные пути для того, чтобы показать нужные аспекты на диаграмме.

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

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

В целом, конечно, нотация eEPC, как и «Процедура», безнадежно устарела. Особенно с точки зрения использования моделей процессов для настройки BPM-систем.

Нотация BPMN

На рис. 3. представлена схема процесса в нотации BPMN.
Это тот же самый процесс, который был представлен выше в нотациях «Процедура» и eEPC.

Рассмотрим преимущества и недостатки нотации BPMN вообще, и с точки зрения моделирования процессов в Business Studio, в частности.

Преимущества:
• международный стандарт ISO с 2013 года;
• «де факто» принята всеми разработчиками BPMS;
• семантика, позволяющая описывать сложные практические ситуации;
• возможность отображения потока объектов (документов) со статусами;
• возможность импорта диаграмм из MS Visio;
• возможность экспорта для автоматизации в BPMS.
Недостатки:
• сложная семантика;
• неадекватное межпроцессное взаимодействие в части информационных потоков (задача решается);
• не вся семантика BPMN поддерживается при имитационном моделировании.

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

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

В Business Studio можно импортировать схемы процессов в нотации BPMN, разработанные в MS Visio. Из Business Studio возможен экспорт моделей для настройки исполняемых процессов в BPMS.

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

В текущей версии Business Studio проблемой является интеграция моделей процессов в нотации BPMN между собой и с моделями вышестоящего уровня (в IDEF0). Стыковку моделей между собой по входам/выходам и синхронизацию по событиям приходится делать исключительно вручную без какой-либо автоматизации. Это ведет к риску потери важной информации и дезинтеграции модели. Возможно, в следующих версиях Business Studio эта проблема будет решена.

Отдельно стоит подчеркнуть, что нотация BPMN, реализованная в текущей версии Business Studio, позволяет достаточно корректно (с точки зрения реальных практических кейсов) выполнять имитацию процессов. Более того, можно использовать граничные события типа «Системная ошибка» и другие в рамках имитации. Так же можно имитировать прерывание операции процесса по граничному событию-таймеру (правда, для этого приходится пока создавать несколько искусственную конструкцию на схеме соответствующего подпроцесса).

Попробуем сравнить рассматриваемые нотации по набору критериев.

Сравнительный анализ нотаций

Сравнение нотаций можно сделать по трем группам критериев:

1. Внешний вид диаграмм.
2. Интеграция.
3. Семантика и имитация.

В следующей таблице 1 представлено сравнение по группе критериев «Внешний вид диаграмм». Максимальный балл -10.

В таблице 2 представлена оценка нотаций по критерию «Интеграция».

В таблице 3 представлено сравнение нотаций по группе критериев «Семантика и интеграция».

Выводы

Итоговая оценка нотаций в баллах представлена на следующей диаграмме:

Диаграмма. Итоговая оценка нотаций в баллах.

По совокупности критериев, я рекомендую использовать нотацию BPMN для описания, анализа и регламентации бизнес-процессов на операционном уровне. На сегодня — BPMN – лучшая нотация!

Если, всё-таки, по каким-то причинам вам придется делать выбор между «Процедурой» и eEPC, и если не нужна имитация, то лучшим выбором станет нотация «Процедура». Но если предполагается серьезно заниматься имитацией процессов, то лучше выбрать нотацию eEPC, чем «Процедуру».

Успехов вам при описании и оптимизации бизнес-процессов!

В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»

Январь 2019 г.