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

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

В BPM - и методологию, и технологию, и организационные принципы - понимание этих реалий заложено изначально.

“Но есть один момент” (c)

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

1. Что-то должно “болеть”. У бизнеса должна быть серьезная проблема, от решения или не решения которой существенно зависят конкурентоспособность и вообще перспективы компании. При этом проблема должна быть осознана и хотя бы приблизительно “оконтурена”. Просто попытка “сделать что-нибудь” ни к чему путному не приводит.
2. Должна быть воля к решению этой проблемы. С этим сложно в компаниях с размытой мотивацией - например, там, где собственник решил полностью удалиться от дел, доверив все наемным менеджерам, не имеющих доли в компании.
3. Должны быть ресурсы. Финансовые и интеллектуальные. Финансовые - на уровне постоянной оплаты труда минимум двух специалистов, из них минимум одного в своем штате. Интеллектуальные - выполнение топ-менеджерами функций владельцев бизнес процесса, в частности - участие в (пере)проектировании бизнес-процессов на уровне одного-двух часов в неделю.

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

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

Получается, мы, пусть и на новом уровне, возвращаемся к реинжинирингу. И кстати, к “as-is” и “to-be” - теперь они нужны, чтобы количественно замерить показатели процесса до и после проекта и потом дать спонсору проекта отчет - какую отдачу дали потраченные на него деньги.

Резюмируя: машина BPM “на ходу” - это непрерывное усовершенствование, но “стартером” этой машины служит однократное, достаточно радикальное усовершенствование в духе реинжиниринга.

Жаль, что допер я до этого только теперь, когда Майкла Хаммера уже не стало…

В связи с этой темой не могу не отдать дань уважения еще одному ушедшему в прошлом году титану - Гэри Раммлеру. В своем интервью (возможно, последнем) он сказал: 

“Я думаю, есть всего одно критичное условие - это наличие в организации критической бизнес-проблемы. Если такой проблемы нет (во что трудно поверить) или менеджмент пребывает в глубоком отрицании ее существования, то серьезный, трансформирующий BPM не состоится. Точка. Могут быть уводящие в сторону “демонстрации” и “концептуальные тесты”, но ничего существенного не произойдет. Да и как оно может произойти? Серьезный BPM стоит денег, занимает время и может перевернуть множество корзин с яблоками, и вам не удастся это сделать без равнозначного бизнес-обоснования. Я думаю, второе по значимости условие - или фактор - тот, кто занимается BPM внутри организации должен на 70% быть грамотным в бизнесе и на 30% экспертом в области BPM. Потому что ключ к их успеху - способность найти критическую бизнес-проблему, понять как BPM способен ее решить, и затем убедить высшее руководство сделать инвестиции. Я считаю, есть два условия: наличие возможности и кто-то способный эту возможность реализовать.”

Спасибо, Гэри, надеюсь мы идем верным путем.

Еще один часто задаваемый вопрос из форума.

Вопрос - В случае изменения шаблона бизнес-процесса (добавили/удалили активити) что происходит с реальными начатыми по этому шаблону (в предыдущей версии) бизнес-процессами? Что происходит в связи с этим с аналитикой?

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

Однако системы, которые позволяют модифицировать схему процесса “на лету”, существуют. Рекомендуемое чтение по теме:

• Статья Glen Smith из Appian на ebizq.net рассказывает почему важно иметь такую возможность с методологической точки зрения. Если над вами не довлеет жесткая необходимость выявить процесс до мельчайших деталей всех возможных исключений, то вы можете быстрее запустить его в эксплуатацию.
• Keith Svenson из Fujitsu обращает внимание на то, что изменение схему “на лету” принципиально очень сложно реализовать в системах, в которых для исполнения процесса используется BPEL. Fujtsu Interstage BPM позволяет вам отредактировать схему экземпляра процесса точно так же, как и схему шаблона, и при желании, сохранить полученную схему в качестве новой версии шаблона.

За информацией о последней версии конкретной BPMS обращайтесь к отчету BPTrends.

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

В Oracle BPMS (aka BEA AquaLogic BPM aka Fuego) выбран другой путь. В палитре этой системы есть специальный “магический” активити, который может забрать на себя управление с любого активити и/или передать на любой активити. Это решает большую часть проблемы - отсутствие на схеме необходимого перехода.

Но не стоит полагаться только на инструментарий - надо грамотно проектировать схему процесса.

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

Как в различных реализациях BPMN выглядит шаг процесса, выполняемый людьми? Чисто для иллюстрации возьмем процесс “От обращения до заказа” (Inquiry to Order) с шагами “Сделай это” (Do This, системный), “Согласуй договор” (Negotiate Contract, человеческий), “Сделай то” (Do That, системный) и смоделируем при помощи нескольких популярных инструментов.

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

25 февраля AHConferences проводит конференцию по BPM. Они провели три конференции по SOA, судя по отзывам, весьма успешным.

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

К слову о деньгах: если кто-то очень хочет посетить, но начальство говорит “нет бюджета” - есть некоторое количество ВИП-приглашений, обращайтесь и приходите вместе с начальством.

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

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

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

Такое асинхронное взаимодействие процессов подразумевает наличие между ними буферов, в которых накапливаются задания, передаваемые от процесса-заказчика к процессу-исполнителю. В рассматриваемом примере это “Производственные заказы” и “Плановые остатки сырья и комплектующих”. Технически буфер может реализовываться по-разному: очередью сообщений, записями таблицы базы данных или объектами ERP-системы, находящимися в определенном состоянии. Естественно, внутреннее устройство буфера желательно скрыть, создав сервисы для работы с ним - добавления, просмотра, извлечения.

Современные BPMS позволяют и моделировать, и исполнять подобные схемы, и в этом их коренное преимущество перед традиционными workflow-системами. Другое дело, что аналитики осваивают такие схемы с большим трудом - см. например Bruce Silver, “BPMN to Requester: Get Outta My Pool”. Основная сложность тут не в нотации, а в развитии “асинхронного мышления”. Вы должны научиться вычленять из того, что бизнес преподносит вам как единый процесс, отдельные асинхронные процессы. Помогают разобраться в этом ответы на два вопроса: 1) с каким бизнес-объектом связан экземпляр процесса и 2) с какими событиями связаны начало и завершение экземпляра процесса.

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

Интересно, что прием на работу - это классический пример бизнес-процесса, который BPM-вендоры любят использовать для демонстрации своих продуктов. Но при этом они пытаются обойтись одним процессом! Видимо, такие демонстрации делают разработчики, а не консалтеры.

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

Тема: “Бизнес-процессы, современный взгляд”.

Аудитория Школы Своего Бизнеса (www.shsb.ru) - состоявшиеся предприниматели и менеджеры, а также те, кто хотел бы ими стать. Соответственно, доклад будет рассчитан на бизнес-аудиторию: что такое бизнес-процесс и процессное управление, чего можно добиться с их помощью и как их организовать. ИТ-аспекты управления бизнес-процессов будут представлены в минимальном объеме.

Дата: четверг 15.01.09. Время: 19:00-21:00. Адрес: м. Электрозаводская, Семеновская наб. 3/1 корп.6 подъезд 6/1.  Схема проезда. Стоимость гостевого участия - 300 руб.

Точнее, это было очень смешно в 90-е; современные процессные дисциплины не доставляют так, как реинжиниринг и ISO 9000. В качестве иллюстрации - подборка комиксов “Dilbert” от Скотта Адамса на околопроцессные темы. » читать дальше

Вдогонку к прошедшему семинару и отчету о нем - ответы на вопросы:

Интересно у Unify есть какие-нить средства для сбора статистики по мониторингу БП?

Статистика в любой BPMS накапливается автоматически: информация обо всех событиях (старт процесса, переход к следующему шагу, изменение атрибутов и т.д.) записывается в журнал (т.е. в реляционную СУБД) вместе с отметками о пользователе и времени события. Дальше возможны варианты: практически все системы (включая Unify NXJ) предоставляют готовые и/или позволяют конструировать то, что называется dashboard - панели приборов для мониторинга в реальном времени; более развитые системы строят по оперативным данным аналитические кубы и стыкуются со средствами BI.

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

По идее, для этого в первую очередь нужна не столько статистика, сколько средства имитационного моделирования по методу Монте-Карло (simulation). Для оптимизации интересно ведь получить ответ не столько на вопрос “что мы имеем”, сколько на вопрос “что будет, если”. В идеале нужно иметь и то, и другое, и иметь возможность подать на вход Монте-Карло фактическую статистику, например, распределение продолжительности времени выполнения каждого шага, распределение входных параметров и т.п. А еще надо бы уметь запускать Монте-Карло не по одному процессу, а одновременно по нескольким - ведь они зачастую конкурируют за один и тот же ресурс, и поэтому моделирование изолированного процесса не будет реалистичным. Поиграться с этим рекомендую на Oracle BPM Suite (a.k.a. BEA AquaLogic) - он умеет и то, и другое.

Управление БП нужно только для некоторых “проблемных” БП, а не для всех БП предприятия. Но как тогда быть с остальными БП?

Есть операционные процессы, в которых мы хотели бы стать чемпионами - для них в первую очередь показан BPM. Есть процессы, которые мы готовы позаимствовать, например, вместе с ERP или HR-системой, потому что они для нас не критичны. Есть процессы типа “пересмотр миссии и стратегии”, для которых достаточно бумажного регламента. В общем, главное - этапность и прагматизм: отранжируйте процессы по соотношению эффект/затраты и двигайтесь вперед, соотносясь с располагаемыми ресурсами.

Почему Анатолий дает определение ВРМ как “сочетание управленческо методологии, информационных технологий и организационных принципов, направленных на реализацию процессного управления”, а потом ставит вопрос - “Существует ли BPM без BPMS? Бухгалтерия без бухгалтерских программ?”?

Это потому, что кое-кто опоздал к началу семинара Я ведь начал с того, что предупредил: в области процессного управления сегодня сосуществуют несколько парадигм. Я придерживаюсь той точки зрения, что BPM без BPMS - это абстракция пожалуй даже в большей степени, чем бухгалтерия без бухгалтерского софта. Но на этот счет есть и другие точки зрения, например, ISO 9000 - это тоже в некотором роде управление бизнес-процессами.

Не совсем понятно каким образом будет преобразовываться сквозные сложные БП уровня предприятия в исполняемое приложение.

Умеренной сложности пример реализации сквозного процесса опубликован на сайте Бизнес-Консоль.

BPMS - это вещь сама в себе, которая слабо\никак интегрируется с остальные проектными решениями (Системами Управления Требованиями, Средствами Разработки и т.д.)

Напротив, любая BPMS либо поставляется в комплекте, либо хорошо интегрирована с инструментарием разработки пользовательских и системных интерфейсов. Например, Unify NXJ идет в комплекте со средой разработки экранных форм и веб-сервисов. И все BPMS без исключения ориентированы на SOA.

…есть разрав между Целями\Стратегией\Архитектурой Предприятия (ИТ включаем) - Управления БП - Разработкой ПО

Реально существующая проблема - сегодняшние BPMS нацелены на управление отдельным бизнес-процессом. С другой стороны, есть средства Enterprise Architecture (например тот же ARIS), которые способны охватить сеть процессов компании. Но они не дотягиваются до исполнения процесса. Как будет решаться эта проблема? Брюс Силвер полагает, что BPMS будут развиваться в направлении EA.