На правах рекламы

В 2005, когда мы запускали сайт bpms.ru, и в 2006, когда участвовали в первых конференциях по BPM, в России BPM предлагали буквально единицы.

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

Но основные проблемы BPM-проектов сегодня не в разработке приложений и вообще не в ИТ. По общению с потенциальными заказчиками, дискуссиям на форумах, выступлениям на конференциях просматриваются две общие проблемы: 1) как получить от BPM реальную, измеримую выгоду и 2) как сделать так, чтобы BPM не остался однократным проектом, а стал частью культуры организации.

Как добиться эффекта от проекта BPM?

Этот вопрос часто поднимается в форме - как «продать» BPM внутри организации. Спонсор проекта не дает себя увлечь голым энтузиазмом, а просит объяснить, как успех проекта отразится на строке прибылей и убытков компании.

» читать дальше

Не секрет, что разные люди понимают под BPM очень разные вещи. Некоторые называют BPM старый добрый реинжиниринг с его «as-is» и «to-be», другие - регламентацию бизнес-процессов и/или внедрение Системы менеджмента качества, третьи - автоматизацию бизнес-процессов в ERP-системе, четвертые - покупку и внедрение BPMS, пятые - workflow в ECM-системе и т.д.

Мне лично ближе позиция тех, кто понимает BPM в духе книги Смита и Фингара «Business Process Management: The Third Wave» - как цельную дисциплину, включающую в себя методологическую и технологическую (BPMS) составляющие, а также (добавляю я от себя) принципы реализации проектов Agile. Ключевые классифицирующие признаки BPM в этой трактовке - 1) управление изменением бизнес-процессов в замкнутом цикле и 2) устранение разрыва между бизнесом и ИТ. Такая трактовка мне больше нравится по той простой причине, что я считаю расточительством вводить новый термин для обозначения практик, существующих уже добрый десяток лет. (Аббревиатура BPM стала широко распространяться примерно с 2003 г., в то время как реинжиниринг существует с начала 90-х, а идеи TQM относятся к 80-м.)

BPM в широком и узком смысле слова

Таким образом, мы имеем две основные трактовки BPM:

1. BPM в широком смысле слова, или BPM как имя нарицательное, или BPM как зонтичная концепция - управление бизнес-процессами (business process management) во всех его проявлениях.
2. BPM в узком смысле слова, или BPM как имя собственное, или BPM как целостная дисциплина (методология плюс технология плюс принципы реализации), сложившаяся в первом десятилетии XXI века.

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

Конечно, такое положение дел не способствует росту рынка BPM (в любой из трактовок этого термина). Ведь что должен думать потенциальный спонсор проекта BPM, слыша эту разноголосицу? «Если вы все такие умные и беретесь учить меня, то что же вы друг с другом договориться не можете?!»

Доходит до курьезов: недавно на семинаре bpms.ru один из участников, представлявший крупную российскую страховую компанию, говорил, что BPM-а у них нет, а другие участники семинара убеждали его, на основе его же собственных слов, что есть. Что же такое этот BPM, если мы даже не можем решить, есть он в нашей собственной компании или нет?!

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

Но желательно было бы позиционироваться более точно.

Трехуровневая классификация BPM

За основу классификации я предлагаю взять шкалу зрелости BPM по Гартнеру (Gartner BPM Maturity Model).

В 2006 г. Гартнер предложил 6-уровневую (от 0 до 5) модель зрелости BPM, которую, дабы не нарушать авторские права, я перескажу своими словами:

• Фаза 0. Функциональное управление. Организации еще только предстоит осознать, что ее эффективность как целого зависит не только от того, как выполняются те или иные функции, но и от того, насколько хорошо выполнение этих функций координировано друг с другом, т.е. от качества связывающих их бизнес-процессов.
• Фаза 1. Осознание бизнес-процессов. Организация познает саму себя через призму бизнес-процессов. Выделяются сквозные бизнес-процессы, им назначаются владельцы. Все увлеченно рисуют схемы бизнес-процессов. Разрывы и явные узкие места выявляются и устраняются, причем без привлечения средств автоматизации процессов (BPMS).
• Фаза 2. Автоматизация исполнения и контроля отдельных бизнес-процессов. Организация учится управлять процессами в непрерывном цикле моделирование - исполнение - анализ, добиваясь повышения их эффективности, пока на уровне отдельных бизнес-процессов.
• Фаза 3. Исполнение и контроль сквозных бизнес-процессов. Расширяя границы процессов, находящихся под управлением BPMS, и налаживая межпроцессное взаимодействие, компания выстраивает управление сквозными процессами, пронизывающими организацию насквозь и замыкающимися на внешних заказчиков/партнеров и/или взаимодействующими с их бизнес-процессами.
• Фаза 4. Явная и автоматическая связь между бизнес-целями и бизнес-процессами, в том числе на основе имитационного моделирования и динамических бизнес-правил. Изменение целевых показателей бизнеса влечет за собой автоматическое перестроение сети бизнес-процессов.
• Фаза 5. Адаптивная бизнес-структура. Способность быстро реагировать на происходящие в бизнес-окружении изменения, а также предвидеть такие изменения и самим создавать благоприятные возможности благодаря глубокой интегрированности в различные рынки и партнерские экосистемы.

Последние две фазы я бы отнес к разряду научной фантастики. Подозреваю, их до сих пор никто, включая аналитиков Гартнер, в глаза не видел, и не факт что когда-нибудь увидит. Нулевая фаза - непроцессная. Итого остается три:

BPM-1: Описание и моделирование бизнес-процессов

BPM-2: Управление отдельными бизнес-процессами

BPM-3: Управление сетью сквозных бизнес-процессов

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

При желании можно выделить подуровни:

• На уровне BPM-1 некоторые ограничиваются текстовыми регламентами, более продвинутый вариант - графическое моделирование бизнес-процесса, из которого текстовый регламент генерится автоматически, и единый репозитарий бизнес-процессов.
• На уровне BPM-2 не всегда реализуется цикл усовершенствования, зачастую дело сводится к однократной автоматизации.

Если бы и заказчики, и вендоры/консультанты формулировали свои запросы и возможности, ссылаясь на эту шкалу, то это способствовало бы лучшему между ними взаимопониманию. Например, заказчик мог бы для себя определиться так:

Мы сейчас находимся на уровне BPM-1, в основном пользуемся текстовыми регламентами. Для регулярной сертификации по ISO9000 нам нужна собственная компетенция в полном объеме BPM-1, с графическими моделями и единым каталогом процессов.

Для вспомогательных процессов в области управления персоналом нам нужен внешний консультант с подтвержденной отраслевой компетенцией и квалификацией BPM-2.

Для операционных процессов «от заказа до оплаты» нам нужен внешний консультант с квалификацией BPM-3. Помимо работы над процессами, он должен помочь нам создать собственный центр компетенции, который через 12 месяцев сможет взять на себя 80% работ.

После этого можно подбирать исполнителей среди консалтинговых компаний, работающих на уровнях BPM-1, BPM-2 и BPM-3, и присматриваться к инструментарию:

• для уровня BPM-1 необходим моделер/дизайнер процессов, для целей каталогизации полезным также будет инструмент класса Enterprise Architecture
• для уровня BPM-2 достаточно workflow-движка, встроенного в ECM или CRM-систему
• уровень BPM-3 требует полноценной BPMS, причем задачи уровней BPM-1 и BPM-2 она тоже сможет решать

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

Ключевые слова - «для всех процессов». Пытаться равномерно поднимать зрелость всех процессов - это верный путь к краху. Закон Парето никто не отменял - условно говоря, 20% процессов отвечают за 80% эффективности компании. Не лучше ли сфокусироваться на этих 20%?

Конечно, BPM-3 обеспечивает намного более полный контроль над процессами по сравнению с BPM-1. Но он ведь и обходится намного дороже! Полноценная реализация сквозного бизнес-процесса в BPMS - это, помимо всего прочего, заказная ИТ разработка. А заказная ИТ разработка дешевой не бывает.

Консультант BPM-3 может добиться более глубокого контроля над бизнес-процессом, но это не дает ему права смотреть свысока на коллег, работающих на уровне BPM-1, так как он способен добиться результата только на относительно узком фронте, а они могут охватить, пусть и не со столь глубоко, деятельность компании в широких границах.

Вторая моя претензия к шкале зрелости Гартнер: она создает представление, что ее надо проходить последовательно, ступень за ступенью. Совершенно не обязательно!

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

BPMN как связующая нить

Все, что относится к бизнес-процессам, принципиально изменчиво. Например, мы должны быть готовы к тому, что через полгода мы придем к выводу, что какие-то процессы, для которых мы определили достаточным уровень BPM-1, требуют уровня BPM-3. Естественно, хотелось бы видеть преемственность: чтобы результаты работы на уровне BPM-1 были бы использованы при переходе на уровень BPM-3.

Рецепт прост: используйте BPMN.

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

• чтобы рисовать аналитические диаграммы BPM-1, используйте минимальное подмножество элементов BPMN
• на уровне BPM-2 понадобится BPMN-оркестровка в полном объеме
• уровень BPM-3 потребует полной палитры BPMN - сообщений, сигналов, обработчиков событий, транзакционных подпроцессов и т.д.

Что ценно - между этими, достаточно разными, диаграммами будет сохраняться преемственность: превратить аналитическую BPMN-диаграмму уровня BPM-1 в исполняемую BPMN-диаграмму уровня BPM-2 будет проще и намного надежнее, чем, скажем, перерисовывать IDEF0 в BPMN. На уровне BPM-3 альтернативы BPMN практически нет, поэтому лучше придерживайтесь его на всех уровнях.

Да, и чуть не забыл - мы (Бизнес-Консоль) специализируемся на BPM-3.

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

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

Рассмотрим процесс выдачи банковской карты клиенту:

Рис. 1. Выдача банковской карты с «пассивной» задачей «Выдать карту».

Обратим внимание на задачу «Выдать карту». Бизнес-сценарий: после того как карта изготовлена, клиент в течение 45 дней должен прийти в отделение банка и получить ее. Если считать, что в среднем клиент приходит за картой через 10 дней, и что отделение выдает по 100 карт в день, то у банковского клерка скопится очередь из 1000 задач. » читать дальше

Напомню, что дорожки (lane в BPMN 2.0, swimlane в BPMN 1.x) изображают исполнителей процесса.

Правила для дорожек:

1. Дорожки опциональны – диаграмма может обходиться без них.
2. Дорожки могут быть вложенными (иерархическими).
3. Семантика дорожек может быть любой, на усмотрение автора диаграммы – подразделение, роль, должность…
4. Встроенные подпроцессы (embedded subprocesses) не имеют пулов и, следовательно, не могут иметь дорожек.
5. Дорожки имеют отношение только к задачам, исполняемым людьми (user task) – автоматическим задачам (service task, script task), подпроцессам, развилкам, событиям все равно на какую дорожку вы их поместили.
6. Даже для задач, назначаемых людям, дорожки по сути является комментариями – реальный исполнитель задается в атрибутах модели для данной задачи.

Начинающие пользователи BPMN любят дорожки и с энтузиазмом рисуют их в своих первых  диаграммах:

Рис.1. BPMN-диаграмма с дорожками.

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

Рис.2. BPMN-диаграмма, на которой показан магистральный путь процесса.

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

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

Рис.3. “Плоская” диаграмма с большим числом активностей сложна для понимания.

Соответственно, если процесс состоит из большего числа задач, его следует подвергнуть структурной декомпозиции – разбить на подпроцессы:

Рис.4. С помощью подпроцессов сложный процесс можно изобразить в виде простой диаграммы.

Однако в этом стиле моделирования для дорожек не остается места:

• На верхнем уровне остаются только подпроцессы, а дорожки относятся только к задачам, исполняемым людьми (правило 5).
• На схеме подпроцесса нет ни пула, ни дорожек (правило 4).

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

Если вам так уж необходимо показать исполнителей на схеме встроенного подпроцесса, используйте BPMN-артефакт «группа»:

Рис.5. Исполнители во встроенном подпроцессе изображены группами.

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

Рассмотрим в качестве примера процесс заключения договора, состоящий из трех фаз:

1. согласование содержательных условий договора
2. согласование текста договора
3. подписание договора

Зачастую приходится встречать наивные процессные диаграммы типа следующей:

» читать дальше

Мы (Бизнес-Консоль) решили больше не предлагать потенциальным заказчикам пилотные проекты. Сразу говорюсь: идет о проектах PoC (Proof of Concept), которые мы в своей бизнес-практике называем «демонстрационными пилотами».

Сначала расскажу почему, потом – что взамен. » читать дальше

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

Примечания:

• Синонимами оркестровки являются поток работ (workflow) и, собственно, процесс.
• В BPMN оркестровка моделируется развернутым пулом (white-box pool), при этом на диаграмме могут опционально присутствовать внешние сущности, моделируемые свернутыми пулами (black-box pool).
• Формулировка “координируемых из одного центра” означает, что, даже если процесс на каком-то шаге распараллеливается, исполнение разных ветвей процесса остается координированным: они могут в дальнейшем синхронизироваться в сходящейся развилке, а процесс в целом завершится тогда, когда завершатся все ветви.

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

Примечания:

• В BPMN 1.x межпроцессное взаимодействие называлось хореографией (choreography). В BPMN 2.0 хореографией стал называться новый, отдельный вид диаграммы, а то, что раньше называлось choreography, теперь называется collaboration. Такие дела.
• На диаграмме межпроцессного взаимодействия отображается больше одного развернутого пула (white-box pool).
• Межпроцессное сообщение иногда сводят к обмену сообщениями (message), но в общем случае процессы могут взаимодействовать при помощи сообщений (message), сигналов (signal) и/или данных (data store, conditional event).
• Отдельные процессы на диаграмме межпроцессного взаимодействия исполняются в целом независимо, за исключением явно обозначенных точек синхронизации - отправки и получения сообщения/сигнала, записи/чтения данных.

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

Тут встречаются две крайности:

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

Рис.1 Антипаттерн “Сообщения вместо подпроцесса”

Обычные аргументы в пользу такой схемы:

• “Вызываемый процесс выполняется другим подразделением.” - Чтобы показать исполнителя, пользуйтесь дорожками (swimlane), а не пулами.
• “Вызываемый процесс можно использовать где-нибудь еще.” - Как и повторно-используемые (reusable) подпроцессы.
• “Явно видна связь между вызывающим и вызываемым процессом.” - Во-первых, развернутый подпроцесс не менее нагляден:

Рис.2 Развернутый подпроцесс

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

Рис.3 Свернутый подпроцесс

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

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

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

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

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

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

Иво Величков заставил меня обратить внимание на разницу между BPMN 1.x и BPMN 2.0 в части моделирования обмена данных.

Обмен данными в BPMN 1.x моделируется при помощи объектов данных (Data Objects):

Рис. 1 Объекты данных в BPMN 1.x

Объект данных в рамках BPMN 1.x  - это артефакт, помогающий описывать процессы. При помощи ассоциации (association) его можно связать с задачей (task), потоком управления (control flow) или сообщением (message flow), при этом никакого воздействия на них он оказывать не будет.

Объектом данных можно изображать самые разнообразные объекты, физические или электронные. Например, мы имеем право изобразить объект данных вне пула и назвать его “база данных заказов”, чтобы смоделировать таким способом межпроцессное взаимодействие через данные.

Однако, как справедливо указал Иво, в рамках BPMN 2.0 приведенная выше диаграмма становится некорректной!

Дело в том, что в BPMN 2.0 объект данных привязан к контексту процесса: он изображается внутри процесса или подпроцесса и существует только в интервале времени от момента запуска экземпляра процесса  (подпроцесса) до его завершения. Соответственно, доступ к ним из другого внешнего процесса невозможен.

Для изображения персистентных данных, не привязанных к жизненному циклу процесса, в BPMN 2.0 служит хранилище данных (Data Store). Его и надо использовать для моделирования межпроцессного взаимодействия через данные в BPMN 2.0:

Рис. 2. Объекты и хранилища данных в BPMN 2.0

BPMN 2.0 различает единичные объекты данных и коллекции (collection) - последние помечаются специальным маркером. В нем также введены специальные обозначения для данных-входов и данных-выходов (Data Input, Data Output) и новые элементы - наборы входных и выходных данных (Input Sets, Output Sets).

BPMN 2.0 также определяет ассоциацию по данным (Data Association) в добавок к обычной ассоциации (Association), унаследованной из 1.x. Если обычная ассоциация, как и в BPMN 1.x, служит чисто для целей документирования, то ассоциация по данным является “исполняемой”: вы можете определить для нее на уровне атрибутов модели процесса входные и выходные данные и, опционально, трансформацию. Таким образом можно на уровне диаграммы описать манипуляции с данным при старте и завершении активности, отправке или получении сообщения. Изображаются на диаграмме ассоциации по данным так же, как и обычные - точечным пунктиром с V-образной стрелкой.

В спецификации BPMN 2.0 есть небольшое противоречие, относящееся к ассоциации по данным:

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

Так что я все же полагаю, что схема на рис.2 является корректной.

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

Максим Смирнов и ваш покорный слуга уже высказывались на тему ACM в своих блогах. Также эта тема была одной из центральных на неконференции BPMS.ru в прошлом году. За это время утекло много воды, и созрела идея посвятить ей целиком очередной семинар BPMS.ru. Приходите, будет интересно:

Тема: “Adaptive case management - недостающее звено BPM”
Дата: 16 марта 2011 г.
Время: с 19:00 до 21:00.
Место: РОСНОУ, г. Москва, ул.Радио, 22.
Докладчик: Максим Смирнов
Оппонент: Анатолий Белайчук
Регистрация: livents.ru