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

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

Предпочтительный формат мастер-класса - живая демонстрация создания проекта “с нуля”. Что не удастся показать вживую - про то рассказать словами. Время на доклад - 1 час.

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

Первый мастер-класс пройдет в среду 14 декабря, начало в 19 часов, регистрация на bpms.ru. Обсуждать можно там же, а также на linkedin и facebook.

Желающих выступить с докладом и презентовать любимую систему BPMS у организаторов достаточно. На первом мастер-классе собиралась выступить компания Элевайз с системой Элма, но в последний момент они отказались, чем подвели организаторов и 100+ зарегистрировавшихся на мероприятие.

Вместо Элевайза 14 декабря выступлю я с демонстрацией системы BizAgi BPM Suite. Приходите, будет интересно. Я подобные демонстрации регулярно провожу для потенциальных заказчиков - равнодушных не бывает.

В планах - демонстрация Oracle, отечественной Runa, IBM (ex-Lombardi) и других систем. Оставайтесь на связи.

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

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

Так держать, ОСП!

Ссылки:

• Фотографии
• Презентации
• Видеорепортаж

Примеры:

• Закупка по конкурсу
• Прием на работу по конкурсу

Упрощенная схема иллюстрирует идею паттерна:

Полная схема:

Пояснения к схеме:

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

Пара замечаний общего характера:

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

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

Отзывы о круглом столе опубликованы на CNews и на BPMS.ru, там же ссылки на отзывы других участников и посетителей.

Видео-отчет о мероприятии на CNews TV:

Приятно снова увидеть знакомые лица.

Тирренское море, остров и вулкан Стромболи (Италия).

Эгейское море, окресности Мармариса (Турция).

Ионическое море, легендарный остров Итака (Греция).

Вот и редактор портала ebizQ Питер Шофф записал подкаст, представив меня в роли «modeling guy». Впрочем, если Питер считает, что сегодня актуально именно это, то у меня нет никакого желания с ним спорить. Оригинал подкаста на английском: «Process discovery and modeling done right» (расшифровка на английском).

Перевод на русский:

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

АБ: Здравствуйте Питер, рад снова Вас слышать. Спасибо за оценку моих усилий, с удовольствием с Вами побеседую.

ebizQ: Хорошо. Итак, читая Ваш блог в последнее время, я увидел, что вы подняли вопрос о классификации, которую можно использовать для BPM.

АБ: Позвольте мне сначала объяснить, почему я вообще озаботился всей этой классификацией. Как и большая часть того, что делаю на блоге, это не теоретическое упражнение или что-то вроде этого. На самом деле, это ответ на повторяющиеся вопросы от клиентов и потенциальных клиентов. Многих из них приводит в смущение широкий спектр самых разнообразных вещей, каждая из которых называется BPM. Чистое моделирование и документирование процессов многие сегодня называют BPM. Далее, автоматизация процесса тоже называется BPM, а если используется BPMS, то это точно BPM. И даже то, что в 90-е называлось реинжинирингом, сегодня называют BPM. Это очень странная ситуация. Тут я должен признаться, что до недавнего времени был немного экстремистом, потому что я убеждал людей, что все эти методы не есть «настоящий» BPM. Под настоящим, или полномасштабным, или современным BPM, я понимаю цельную и конкретную дисциплину, разработанную за последнее десятилетие, которая охватывает методологию, технологию и принципы реализация.

Это проверенный способ получить значительные бизнес-преимущества за счет улучшения критических бизнес-процессов. Но тут клиенты задают вопрос: «должны ли мы применять полномасштабный BPM ко всем нашим бизнес-процессам?» Ответ, очевидно, отрицательный. Потому что это не только самый мощный способ улучшить ваш бизнес-процесс, но также и самый дорогой способ, так что это будет просто не по карману. Реальное применение BPM - это относительно короткий список процессов, управляемых таким способом, и основная массам процессов, которые управляются не очень продвинутыми, но менее дорогостоящими технологиями и методами. Так я пришел к идее классификации BPM. Чтобы внести ясность, я предложил следующие уровни классификации. BPM уровень 1 - это чистое моделирование и документирование. BPM уровень 2 - это автоматизация изолированных процессов, или workflow. И BPM уровень 3 - это замкнутый цикл управления сетью процессов, составляющих сквозной бизнес-процесс. Можно еще сюда добавить уровень 0 - процессы, исполняющиеся неформально, так сказать, под ковром. Эта классификация напоминает хорошо известную модель компании Gartner, она соответствует первым трем уровням модели Gartner. Но мне кажется, она проще и ее легче объяснять, потому что мне никогда не удавалось объяснить модель Gartner потенциальным клиентам.

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

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

АБ: Я полагаю, что как раз сейчас очень интересный момент, когда BPMN становится мэйнстримом. Мы видим это по растущему числу вопросов о BPMN от клиентов. Мы видим это по росту числа заказов наших BPMN-тренингов. И мы видим, как во многих организациях BPMN дает новую жизнь процессным усилиям. Некоторые организации задумываются о переносе существующих схем и моделей в BPMN. Другие присматриваются к исполняемому BPMN, что для многих является новой и свежей идеей, и это путь прямо к BPM 3-го уровня.

Я верю, что это огромный шаг для всей отрасли BPM, и мы все являемся должниками ребят из комитета OMG, которые смогли достичь консенсуса и опубликовать стандарт BPMN 2.0. Он может быть не идеален, но это не имеет значения, потому что мы видим, что родился общепризнанный стандарт, а это в нашей отрасли происходит не часто.

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

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

ebizQ: Да, это звучит как большое преимущество. Теперь, как по-вашему, насколько важно получить взгляд на процессы «как есть», и как лучше всего это сделать?

АБ: Очевидно, есть две основные точки зрения на этот вопрос. Если вспомнить известные слова «не мостить коровьи тропы», то они говорят, что ключевой является оптимизация. Но на самом деле, всегда есть выбор. Либо мы начнем с оптимизации и внедряем оптимизированную версию процесса, либо мы сначала берем процесс под контроль, а затем улучшаем его, оптимизируем его в один шаг, в несколько шагов - как захотим. Я считаю, что путь BPM - это второй вариант. Мы всегда идем этим путем, поэтому процесс «как есть» является отправной точкой нашего проекта BPM, так что это, очевидно, очень важная вещь.

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

Современные BPMS настолько хороши в прототипировании, что этот цикл можно прокручивать за часы, если не за минуты. Удивительно, насколько это эффективный способ выявления процесса. Это происходит раз за разом: вы посмотрите на модель процесса, на диаграмму процесса, и она выглядит просто отлично, но как только вы пытаетесь ее запустить, вы сталкиваетесь с разнообразными проблемами в процессе. Например оказываются пропущены потоки управления, пропущены входные данные, не хватает исключений или наоборот есть лишние задачи, неверная последовательность задач. Вы прогоняете этот цикл 5, 6, 10 раз, и вы получите не просто процесс, а единственно верный процесс. Вы в нем уверены, вы знаете, что он может быть выполнен и что входы и выходы связаны между собой. Так что это лучший способ, который я знаю.

ebizQ: В это на самом деле есть большой смысл. А что по Вашему мнению является наилучшей практикой эффективного моделирования процесса?

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

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

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

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

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

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

ebizQ: Очень интересно. Это был разговор Питера Шофф из ebizQ с Анатолием Белайчуком, президентом Бизнес-Консоль. Большое спасибо за сегодняшнюю ценную информацию, Анатолий.

АБ: Спасибо за вопросы, Питер. С удовольствием поделился мыслями с Вами и с нашими слушателями.

Это был второй подкаст на ebizQ с моим участием. Предыдущий подкаст: «Avoiding BPM done wrong» (расшифровка на английском).

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

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

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

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

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

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

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

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

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

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

1) Прежде всего следует определиться: что нас не устраивает в существующем положении дел на уровне бизнеса?

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

На этом уровне могут ставиться такие, например, цели:

• за ближайшие полтора года увеличить объем продаж вдвое
• обеспечить рост партнерской сети на 50% в год

2) За какие бизнес-процессы надо взяться, чтобы добиться улучшений, заявленных на первом шаге? Что в этих процессах должно улучшиться?

Причем не в общих словах, а конкретно, например:

• сократить время подготовки коммерческого предложения с 10 до 3 дней
• уменьшить долю не отгруженных в срок заказов до 5%
• сделать так, чтобы руководители проектов не стояли в очереди у двери кабинета директора, «выбивая» дополнительные ресурсы под свой проект (кстати, случай из реальной практики)

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

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

3) Только после того, как ответы на первые два вопроса получены, можно задаваться третьим: какая функциональность должна быть реализована в процессном приложении?

Например:

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

Беда многих BPM-проектов в том, что в них во главу угла ставится автоматизация. Заказчик говорит: разработайте процессное приложение с такой-то и такой-то функциональностью. Это приводит к неправильной расстановке приоритетов в разработке и к неадекватной схеме процесса.

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

Как превратить BPM-проект в долгосрочную программу?

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

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

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

1. Процессное управление есть систематический ответ на разобщенность подразделений, присущую иерархическим организациям.
2. Процессное управление подразумевает а) управление компанией на основе формализованных бизнес-процессов и б) управление жизненным циклом самого бизнес-процесса – разработка, исполнение, мониторинг и анализ, доработка.
3. Усовершенствование бизнес-процесса – это не переход к идеальному «to-be», а бег за постоянно удаляющимся горизонтом.
4. Невозможно превзойти конкурентов, используя стандартные бизнес-процессы. Ключевые бизнес процессы – это ноу-хау.

Практические следствия из этих положений:

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

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

Очевидно необходимая составляющая этой компетенции – BPMN.

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

Почему за BPM надо обращаться в Бизнес-Консоль

Сегодня мы можем взять любой бизнес-процесс по выбору заказчика, «разобрать его по косточкам» и реализовать в виде процессного приложения в BizAgi BPM Suite, в котором будут пользовательский портал, бизнес-правила, мониторинг (BAM) и интеграция с корпоративными системами. Это стало для нас уже делом техники, рутиной. Но это можем не только мы.

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

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

Если заказчик сам знает, где у него «больное место» – хорошо, можно запускать проект BPM.

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

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

2. Мы эффективно учим BPMN.

Учим не просто нотации. Ключевой момент тренинга bpmntraining.ru – самостоятельная работа слушателей над бизнес-процессами, выбранными ими из собственной бизнес-практики.

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

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

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

Все доступно прямо сейчас

Если изложенное выше представляется вам разумным, то рассмотрите следующие предложения Бизнес-Консоль:

1. Пригласите нас провести научно-технический семинар на тему «Современное управление бизнес-процессами».

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

2. Бесплатно скачайте и установите программное обеспечение BizAgi: Modeler для моделирования бизнес-процессов и BPM Suite (Xpress или Enterprise .NET Edition) для моделирования, исполнения, мониторинга и анализа бизнес-процессов.

Поставьте и то, и другое на личный ноутбук (для BPM Suite желательны 2 ГБ памяти и процессор 2 ГГц). Никакой дополнительный софт не требуется. Теперь вы можете самостоятельно реализовать в BizAgi собственный бизнес-процесс на пробу.

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

3. Закажите тренинг на сайте bpmntraining.ru. Направьте одного или нескольких специалистов на публичный тренинг или, если их набирается четверо или больше, закажите корпоративный тренинг на своей площадке.

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

4. Запишитесь на вебинары Бизнес-Консоль, на которых мы демонстрируем продвинутые возможности BizAgi, такие как интеграция с 1С или мониторинг и анализ бизнес-процессов.

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

Мне лично ближе позиция тех, кто понимает 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.

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

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

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

Первая, наивная версия схемы процесса:

Рис.1. Документы клиента магическим образом попадают в «его» процесс.

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

Применим паттерн «Обработка входящих»:

Рис.2. Паттерн «Обработчик входящих»: к какому экземпляру процесса относятся эти документы?

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

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

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

Рис.3. Какие сообщения относятся к процессу A, а какие к процессу B?

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

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

Рис.4. Маршрутизация входящих документов.

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

Рис.5. Паттерн «Почтовое отделение»: централизованная обработка всех входящих и исходящих.

И еще: в коммуникациях между «почтовым отделением» и прикладными процессами вместо сообщений (BPMN message) предпочтительнее использовать сигналы (BPMN signal), как показано на рис.5.

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

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

И последнее. По опыту обсуждения предыдущей заметки, я жду комментаторов, которые скажут примерно следующее: “Давайте упростим все это дело, избавившись от традиционной почты. Электронное письмо попадет прямо к нужному адресату, а документы можно приложить к нему в отсканированном виде.”

Во-первых, не всегда и не везде можно заменить оригинал копией.

Но главное, вы не имеете права сказать бизнесу: “ваша процедура слишком сложная, я не могу ее реализовать при помощи BPMN/BPMS, поэтому вы должны ее упростить”. Да, вы можете и должны предупредить его, что реализовать его процедуру в том виде, в каком он хочет ее видеть, будет сложнее и дороже, но это не должно быть для вас непреодолимом препятствием!

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

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