Библиотека

Уровни зрелости процессного управления

В отчете за 2011 год «Исследование в области моделирования бизнес-процессов», авторами которого являются Пол Хармон и Селия Вулф (BPTrends), приводится модель зрелости организации в области процессного управления, (см. рис. 1).

Концепция уровней зрелости процесса (Process Maturity Levels) была создана в Институте программной инженерии (Software Engineering Institute, SEI)при Университете Карнеги-Меллон в 90-е годы прошлого века. В ее основу положена работа по качеству, первоначально осуществленная Уотсом Хамфри. Впервые разработанная для поддержки анализа зрелости процесса программирования (CMM), последняя версия, интегрированная модель технологической зрелости (Capability Maturity Model Integrated, CMMI), была обобщена для любого из широкого спектра процессов в различных организациях.
Есть основания полагать, что большая часть российских организаций находится на 1-2, и часть приближается к 3-ему уровню зрелости. Небольшая часть организаций перешла к 4-ому уровню.


Рис.1. Обзор основных уровней зрелости по модели СММI

Пример. Компания, в которой давно внедрена система бизнес-моделирования (BPA), создан и используется репозиторий бизнес-процесссов, контролируется исполнение регламентов по процессам, внедрена система управления эффективностью (Business Performance Management) для оперативного мониторинга и управления процессами относится, вероятно, к уровню 4. В такой компании (а это, скорее всего, достаточной крупный, устойчивый бизнес) в штате есть необходимое количество специалистов, профессионально владеющих методами моделирования бизнес-процессов, разработкой и анализом KPI и т.п. Такие специалисты могу осваивать и внедрять сложные методики и инструменты в области управления бизнес-процессами.

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

Для чего моделируют бизнес-процессы?

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


Рис. 2. Для чего моделируют процессы

Обратим внимание, что «Как подготовку к применению BPMS» моделирование процессов используют 32% опрошенных. Для реинжиниринга и совершенствования деятельности – 81% опрошенных. В целом, более половины всех опрошенных используют описание процессов для целей анализа и оптимизации, а 51% - для целей регламентации. Таким образом, можно сделать вывод, что на сегодняшний день главной целью моделирования бизнес-процессов является их анализ, реорганизация (оптимизация) и документирование (регламентация, передача знаний через web-портал организации).

На рис. 3 представлена еще одна диаграмма из упомянутого выше исследования.


Рис. 3. Наиболее важные свойства средств моделирования бизнес-процессов

Обратим внимание, что только 10% опрошенных считают важным способность легко переходить от модели к коду программного обеспечения. Для остальных более важны другие требования. Например, 36% указало на «Способность создавать простые модели процессов, а 56% на «Способность сохранять модели и данные о процессах в
репозитории». С моей точки зрения эти факты можно интерпретировать следующим образом. Компаниям, которые используют моделирование процессов для анализа, оптимизации и документирования (регламентации) нужны:
• простая, но стандартная нотация моделирования;
• надежный инструмент, позволяющий создавать сложные, многоуровневые модели процессов и хранить их в репозитории (базе данных).

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

Стоит отметить, что средства моделирования, встроенные в некоторые существующие «легкие» продукты BPMS как раз соответствуют указанным выше «приметам». Вполне вероятно, что разработчики таких систем постепенно будут вынуждены интегрироваться с продуктами класса BPA, которые «умеют» эффективно работать с репозиторием бизнес-процессов компании.
Работа пользователей с таким комплексом продуктов «BPA-BPMS», возможно, будет строиться примерно так:
1. моделируем процессы в среде BPA (например, в Business Studio);
2. выгружаем процессы, которые хотим автоматизировать, в средство моделирования BPMS (причем сохраняя нужные для идентификации процесса атрибуты);
3. дорабатываем модели в средстве моделирования BPMS;
4. далее используем полученные модели для автоматизации процессов средствами BPMS.

Какую модель бизнес-процесса можно назвать простой?

Рассмотрим деятельность подразделения коммерческой компании, основная задача которого заключается в получении и обработке заявок клиентов, выставлении счетов и т.п. Структура процессов этого подразделения может быть следующая:
1. получение заявок клиентов;
2. обработка заявки и выставление счета (процесс выполняется по одинаковой процедуре несколькими менеджерами отдела);
3. формирование графика доставки;
4. обработка «ждущих» (отложенных) заявок;      
5. контроль остатков, рассылка информационных писем клиентам;      
6. изменение статуса товара в базе      
7. обработка отказов.      

На следующем рис. 4 показана модель процесса «Обработка заявки и выставление счета», сформированная в нотации BPMN 2.0. Схема реального процесса была специально упрощена. Тем не менее, она содержит три объекта типа «Gateway» и восемь объектов типа «Event». Много это или мало? Можно ли как-то упростить схему?


Рис. 4. Фрагмент модели процесса в нотации BPMN 2.0

На рис. 5. показан тот же процесс, но построенный с использование т.н. conditional flow. Как видим, схема стала проще, но не на много.


Рис. 5. Фрагмент модели процесса в нотации BPMN 2.0 с использованием conditional flow.

Какая из схем процессов, показанных на рис. 4 и 5 является более «правильной»? Вероятно, ответить на этот вопрос можно только в контексте конкретной системы BPMS, в которой процесс будет исполняться. Это означает, что интерпретация схемы и механизм использования атрибутов объектов будут зависеть от конкретного программного кода.
      
Рассмотрим тот же процесс, но описанный при помощи нотации «Процедура» в среде моделирования Business Studio (см. рис. 6), причем без использования объекта «решение» (ромб).

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


Рис. 6. Фрагмент модели процесса в нотации «Процедура» Business Studio.

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

Используется два типа стрелок. Стрелки с одним наконечником показываются последовательность выполнения операций, стрелки с двумя наконечниками – информационные потоки. «Межпроцессное» взаимодействие на схеме показано при помощи стрелки с двумя наконечниками («Письмо с заявкой»), которая выходит из межпроцессной ссылки, устанавливающей связь с процессом «Получение заявок клиентов».

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

Не всю информацию можно показать на стрелках. Но это и не нужно. Если говорить о регламентации, то схема процесса, как правило, отдельно не используется. Регламент процесса содержит: краткое текстовое описание, графическую схему процесса, подробное табличное описание операций процесса (включая исполнителей и входы/выходы), формы используемых документов и проч. Значительное количество информации о процессе указывается в различных атрибутах его модели. Например, подробное текстовое описание может быть сделано для каждой операции процесса. Применительно к схеме рис. 4. информация о двух днях задержки может быть указана в текстовом описании операции «Запросить уточненные данные по заявке».

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

Чего НЕ дает «простая» схема?
• невозможно использовать ее в качестве «исполняемой» в BPMS;
• есть риск неоднозначной интерпретации схемы сотрудниками (на мой взгляд, незначительный).

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

К сложным нотациям можно отнести ARIS eEPC и BPMN 2.0, к простым – «Процедуру» в Business Studio или «Простую блок-схему» в MS Visio. На мой взгляд, к «простым» нотациям стоит относится серьезно. История в разных отраслях человеческой деятельности не раз доказывала, что относительно простые и дешевые решения при массовом использовании существенно эффективнее сложных и дорогих. Если «нотация» не подходит для решения сугубо специальной задачи, но хорошо подходит для решения общих задач в масштабе компании, что будем использовать? У некоторых специалистов возникает искушение упростить «сложную» нотацию до состояния «простой» без потери общности, так сказать. Но что из этого может получиться?

Можно ли упростить «сложную» нотацию моделирования?

Когда среду моделирования бизнес-процессов ARIS «выводили» на российский рынок, описание «методов ARIS» занимало около 1000 страниц текста. Наиболее «ходовая» на тот момент нотация ARIS eEPC содержала большое (несколько десятков) число условных обозначений. В реальных проектах при разработке «Соглашений по моделированию», как правило, создавались «методические фильтры», которые ограничивали количество графически объектов в нотации до разумного и практически нужного (6-8). Фактические никто не использовал все возможные условные обозначения нотации при формировании модели. Но если в ARIS eEPC эти условные обозначения служили скорее для полноты визуального представления процесса, то в BPMN 2.0 они носят более серьезный смысл. Объекты нотации и модели BPMN 2.0 дают возможность создавать «исполняемые» (т.е. автоматизируемые) схемы процессов.

Безусловно, BPMN 2.0 намного сложнее ARIS eEPC. Их даже некорректно сравнивать. Можно обоснованно утверждать, что на сегодня BPMN 2.0 (538 страниц спецификации) является самой «сложной» нотацией (и моделью процесса) в мире. В качестве примера, на рис. 7 приведена таблица с описанием различных вариантов использования событий (event) в BPMN 2.0. И это только события. Есть еще много других сложных объектов. Каково же количество возможных вариантов использования объектов модели? Каково количество возможных комбинаций? Кто из читающих эту статью специалистов по моделированию готов сходу объяснить правила использования каждого события, представленного на рис. 7, и показать практический пример его применения в процессе?


Рис. 7. События в нотации BPMN 2.0

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

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

Можно ли будет обмениваться моделями на сайтах или создавать «магазины» готовых моделей в BPMN? Сложно сказать. Вероятно, однако, что «сложная» нотация никогда не станет массовой, и не сможет использоваться всеми сотрудниками компании в качестве рабочего инструмента описания, анализа и документирования бизнес-процессов.

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

Есть ли альтернатива BPMN?
Приведу цитату с одного из сайтов в Интернете: «…Компания Metasonic AG разрабатывает платформу для динамических процессных приложений Metasonic Suite. В ее основу положен уникальный патентованный подход к субъектно-ориентированному управлению бизнес-процессами (S-BPM), разработанный создателем компании доктором Альбертом Флейшманом (Albert Fleischmann). С помощью всего 5 символов бизнес-пользователь Metasonic Suite может создавать собственные управляемые правилами процессные приложения, вносить изменения и немедленно выполнять их на процессном портале. Подход S-BPM ориентирован на субъектов, т.е. людей, принимающих непосредственное участие в процессе. Иными словами, в фокусе S-BPM находится обмен сообщениями между субъектами, а не жестко-централизованный поток работ, как в традиционном BPM. Такой подход, вкупе с возможностями простого и интуитивного описания процессов и их немедленного выполнения на процессном портале, а также гибкой интеграции в имеющийся ИТ-ландшафт, позволяет компаниям существенно повысить свою конкурентоспособность…»


В.В. Репин, к.т.н., доцент, Исполнительный директор и партнер ООО «BPM Консалтинг Групп»

www.finexpert.ru - всё о процессном управлении!

Январь 2012 г.