В 2010 году Adaptive Case Management был одной из самых обсуждаемых тем в области BPM. В итоге за прошедший год из мутноватого маркетингового шума он превратился в более-менее цельную концепцию.

Почему “более-менее”? Потому, что даже авторы “Master the Unpredictable” - самой, пожалуй, авторитетной на сегодняшний день книге по теме ACM, в предисловии пишут, что консенсуса между ними нет, и поэтому книга представляет, по сути, сборник статей. Тем не менее, в их взглядах сходства больше, чем различий, поэтому говорить об оформившейся концепции уже можно.

Позитив концепции ACM

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

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

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

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

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

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

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

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

Что делать с непредсказуемыми процессами

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

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

Иванов Иван Иванович

Решаю проблемы.

Это люди натренированные на решении проблем, умеющие это делать и получающие за это зарплату.

Как пытались решать проблему изменчивых и непредсказуемых процессов до сих пор:

1. В лоб: редактированием схемы процесса “на лету” бизнес-пользователями.

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

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

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

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

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

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

Все бы хорошо, но у меня есть ряд сомнений в верности предлагаемого пути.

Сомнение 1: Технология вместо методологии?

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

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

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

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

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

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

Возвращаясь к ACM: складывается впечатление, что вместе с процессными диаграммами на свалку выкидывается процессная методология. Больше не нужны навыки процессного анализа, не нужны их носители - бизнес-аналитики. Зачем? “Умные работники” (knowledge workers) настолько умны, что сами лучше всех знают как лучше делать дело.

Возможно. Только для кого лучше - для компании или для них самих?

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

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

В последнем интервью аналитикам Гартнер процессный гуру Гэри Раммлер критиковал BPM за невнимание к бизнес-контексту:

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

Боюсь, пренебрежение к процессной методологии в ACM может привести к игнорированию этой технологии бизнесом.

Сомнение 2: Избавиться от программистов?

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

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

Снизить - да, но полностью избавиться?

Представляется, что просто заменить схему процесса в BPMS на список задач в ACM для этого недостаточно, ведь останутся:

1. Процессная архитектура.

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

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

2. Архитектура данных.

Проповедники ACM подчеркивают особую важность данных кейса. Утверждается, что в случае BPMS первичен процесс, а данные вторичны, а в случае ACM - наоборот.

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

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

Снова: не верю! Анализ и проектирование структур данных было и остается уделом профессионалов. Хотите отдать его любителям - получите не базу данных, а базар данных, аналогичный тому, который сейчас они создают с помощью Excel.

3. Интеграция с корпоративными системами.

Ну, с тем, что для этого понадобятся профессионалы, кажется все согласны.

Что же получается в итоге? Опять бюрократия, на этот раз ИТ-бюрократия. Зло, но неизбежное, потому что хаос еще хуже.

Сомнение 3: Две процессные системы?

Вопрос: сколько нам нужно процессных систем: две (BPMS и ACM) или одна? И если одна, то из чего ее строить: развивать ACM-функциональность в BPMS или пытаться решать все задачи при помощи ACM?

Сторонники ACM (по крайней мере некоторые) позиционируют ее как отдельную систему - они не желают иметь ничего общего с технологиями BPMS.

Их аргумент: BPMS пытается “запрограммировать” бизнес, но это невозможно в принципе, когда мы имеем дело с непредсказуемыми процессами, траектория которых определяется только в ходе их исполнения. Поэтому BPMS не годится, нужна другая система - ACM.

Что-то это мне напоминает… рекламу нового телевизора! “Посмотрите какие краски, посмотрите какое живое изображение! Разве вы видели что-то подобное на вашем старом телевизоре?!” Да, действительно, не видел… стоп! разве я смотрю эту рекламу, вижу эти хваленые краски и живое изображение не на своем старом телеке?

Так и тут: конечно, непредсказуемые процессы нельзя запрограммировать при помощи тупого линейного workflow. ACM предлагает более изощренный способ программирования, но все же это тоже программирование. И кто сказал, что BPMS способны моделировать и исполнять только тупой worflow?

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

“BPM-платформы, с которыми я работал, полны в смысле машины Тюринга. В том смысле, что в рамках BPM-платформы я могу “запрограммировать” все, что делает любая другая программа.”

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

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

Чего существующим BPMS не хватает, так это возможности одним кликом (помним: это должно быть не сложнее, чем отправить электронную почту) добавить в ad-hoc подпроцесс новую задачу. Ну так это ведь при желании достаточно легко реализовать! Наверное не сложнее, чем, например, компенсации транзакций в BPMN.

А еще в BPMS есть функциональность под названием “делегирование” и “заметки” - они тоже позволяют сделать процесс не столь жестким.

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

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

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

Какие бонусы можно было бы извлечь из BPMS с функциональностью ACM?

Бонус 1: BPM на всех стадиях жизненного цикла организации

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

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

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

Бонус 2: Искусственный интеллект

Я не верю, что бизнес-пользователи захотят и смогут организовать библиотеки шаблонов кейсов. Думаю, получится нечто подобное на свалку файлов Excel. А многие ли пользуются шаблонами Microsoft Word? Ведь полезная вещь, а что толку?

Поэтому более перспективным мне представляется встраивание в систему элементов искусственного интеллекта.

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

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

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

Заключение: Спасибо!

Энтузиасты ACM делают нужное дело: исследуют возможности расширения процессного управления на прежде недоступные для него области. И за это им искреннее спасибо!

Рыночные соображения заставляют их дистанцироваться от “родственников” - BPMS и ECM и позиционировать ACM как самостоятельный класс систем. Мне представляется, что это нерационально с точки зрения и технологической, и методологической, и это вряд ли получится.

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

Поэтому мой прогноз: ACM в итоге станет не новой парадигмой, а новой фичей BPM-систем, значительно расширяющей возможности их применения.

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

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

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

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

b) Появление на радаре обьекта пришельца регистрируется и реплицируется в систему слежения напарника - на основании этого каждая цель получает свой индивидуальный id. Потерянная обоими цель получает статус потеряна - средств идентификации старая потерянная или новая нет.

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

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

e) Если цель поражена, workflow для нее заканчивается, если нет - сохраняется статус, что была неудачная попытка поразить цель, и все продолжается. Для упрощения считаем, что поражение ведется лазерным лучом и интервал выяснения результата достаточно короткий.

Считается, что весь процесс постоянный и непрерывный.

Не совсем обычное применение для BPMN, не правда ли? В связи с этим вопросы залу:

• можно ли решить эту задачу средствами BPMN?
• стоит ли?
• ну и само решение, если есть.

По-моему, задача достаточно интересная; во всяком случае, меня самого она заинтриговала.

Мой вариант BPMN-диаграммы (кликните, чтобы открыть в отдельном окне):

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

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

“К сожалению” потому, что ответ, который новичку кажется очевидным, на самом деле неправилен. Это вот не развилка, это распараллеливание процесса:

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

Правильная BPMN-диаграмма выглядит так:

При этом подразумевается, что у процесса есть атрибут “Одобрено” типа boolean. Пользователь на шаге “Рассмотреть заявку” задает значение этого атрибута, а в развилке оно проверяется, и процесс продолжается по одной из ветвей.

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

Пользовательский интерфейс для шага, на котором принимается решение, выглядит примерно так:

По кнопке “Выполнено” форма закрывается, и задача считается выполненной.

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

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

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

Здесь к существующим типам потока управления Control Flow, Conditional Flow и Uncontrolled Flow добавлен еще один: Human Controlled Flow, помеченный двойной поперечной черточкой.

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

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

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

Впрочем, такой подход можно ведь практиковать и для стандартных BPMN-диаграмм:

Нужно убрать кнопку “Выполнено”, а вместо нее добавить кнопки “Одобрить” и “Отказать”, привязав к каждой по два действия: присвоить значение атрибуту и завершить задачу.

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

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

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

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

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

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

Кросс-функциональные бизнес-процессы обычно иллюстрируют примерно так:

Рис. 1. Функции и кросс-функциональные процессы.

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

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

1. Процесс начинается, когда отдел продаж получает заказ клиента.
2. Получив и оформив заказ, отдел продаж передает его в производство.
3. Производство приступает к выполнению заказа.
4. Изготовленный товар доставляется заказчику.
5. Финансовый отдел производит расчеты.

Рис. 2. Кросс-функциональный процесс «от заказа до оплаты», workflow-версия.

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

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

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

В графическом виде:

Рис. 3. Кросс-функциональный процесс «от заказа до оплаты», BPM-версия.

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

Та же история с доставкой и расчетами: их вряд ли удастся реализовать в рамках процесса «клиентский заказ». То есть технически процессов (пулов) тут не два, а больше.

Workflow, BPM и многопоточное программирование

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

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

Рис. 4. Кросс-функциональный процесс как координатор функций.

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

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

К сожалению, для многих это становится непреодолимым барьером.

• Кто-то этот барьер не видит. Бьется об него, набивает шишки, но не понимает, с чем столкнулся.
• Кто-то барьер инстинктивно обходит: выполняет пилотный проект BPM с процессом типа «Оформление заявление на отпуск». Пилот получается успешный, только какое он имеет отношение к бизнесу?

Отсюда, как мне кажется, проистекает большая часть разочарований в BPM: те, кто сводят его к workflow, терпят прогнозируемое поражение.

Технически, многопоточность – это то, что отличает BPM от worflow. Уберите из BPM взаимодействие асинхронно исполняющихся процессов через данные, сообщения и сигналы, и это будет не BPM, а «workflow на стероидах».

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

Но сказать «осваивайте многопоточное программирование процессов» легче, чем последовать этому совету. В ответ раздается стон: «какой же сложный этот BPMN, и кто только придумал в нем 50 разных видов событий!».

Сложен не BPMN – сложен бизнес!

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

Сложность BPMN не чрезмерна – она адекватна сложности бизнеса. У слушателей моего тренинга по BPMN не остается вопроса зачем столько событий: все нужны! И кстати, обратите внимание: в части workflow BPMN 2.0 практически не отличается от 1.x – стандарт развивается в направлении более изощренной поддержки многопоточного программирования: choreography, conversation.

Если бизнес и можно запрограммировать, то только как многопоточную систему.

BPM и ACM

Тут я сознательно ступаю на скользкую почву, так как предвижу реакцию адептов ACM (Advanced/Adaptive Case Management): «Ага! Мы всегда говорили, что бизнес в принципе нельзя запрограммировать!»

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

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

В свете вышеизложенного я хотел бы поинтересоваться у критиков BPM из числа адептов ACM: вы уверены, что критикуете BPM, а не wokflow? Не являются ли объектом вашей критики BPM-проекты, в которых либо пытались решать задачи бизнеса, не выходя за рамки workflow, либо бизнес-проблематика вообще отсутствовала?

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

Что касается ACM, то это безусловно вещь полезная, но только как дополнение к BPM, а не как замена. Плюс к этому, ACM на сегодняшний день вещь менее зрелая, чем BPM, и поэтому тот, кто наломал дров с BPM, с ACM скорее всего наломает дров еще больших.

Продолжение следует

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

• Часть 2: Кросс-функциональные паттерны
• Часть 3: Оптимизация кросс-функциональных процессов

Внимание, тест!

Вопрос: какие элементы BPMN позволяют моделировать межпроцессное взаимодействие (отметьте все правильные варианты ответа) -

1. поток управления (sequence flow)
2. сообщение (message flow)
3. сигнал (signal event)
4. триггер по данным (conditional event)
5. ассоциация (association)

Ответ: кликните, чтобы увидеть правильные варианты ответа

Комментарии к ответам:

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

Рассмотрим процессную диаграмму, позаимствованную мною (с некоторыми упрощениями) из книги Stephen White, Derek Miers, “BPMN Modeling And Reference Guide” (стр. 113):

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

Сложность тут в том, что мы не можем реализовать эту логику при помощи потока управления (sequence flow), так как он не может пересекать границы подпроцессов. (Оставим в стороне вопрос зачем нам тут понадобились подпроцессы; будем считать, что зачем-то они нужны.) Сообщения (message) использовать тоже нельзя, так как мы находимся в пределах одного пула.

Стандартная рекомендация - использовать в подобной ситуации механизм сигналов BPMN (signal event):

• когда концепция готова, первый подпроцесс шлет соответствующий сигнал
• второй процесс до этого момента находится в ожидании сигнала; получив его, он переходит к задаче “Разработать дизайн обложки”

Это так называемый процессный паттерн “этап” (milestone). Аналогичный пример использования сигнала BPMN приведен в книге Bruce Silver, “BPMN Method and Style” (стр. 98).

В чем тут подвох?

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

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

1. Первое, что приходит в голову - предусмотреть атрибут сигнала, который будет ограничивать его распространение границами данного экземпляра процесса. Но к сожалению, такого атрибута стандарт не предусматривает. Причем если в рамках BPMN 1.x еще можно сказать, что это вопрос реализации, то в BPMN 2.0 метамодель процесса специфицирована полностью. Смотрим страницу 281 документа OMG, датированного июнем 2010 г.: у сигнала есть единственный атрибут - имя. Значит, сигнал всегда будет распространятся по всем экземплярам процесса.
2. Что ж, раз у сигнала есть только имя, то будем использовать то что есть. Рассматриваемая схема сработает, если мы сможем динамически, т.е. в процессе исполнения процесса, задать его имя. Если имя сигнала будет не “Концепция готова”, а “Процесс 9999 Концепция готова”, то все будет в порядке. Но это, конечно, приемчик так себе, и рассчитывать на него сложно. Движки BPMS позволяют что-то менять в процессе исполнения (например, задавать время срабатывания таймера), но название - вряд ли.

Почему это важно.

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

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

Выводы:

1. В стандарте BPMN не хватает атрибута, ограничивающего распространение сигнала.
2. В отсутствии стандартного способа ограничить распространение сигнала для реализации процессного паттерна “этап” следует использовать сообщения.

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

Я рекомендую чуть более изощренную схему:

При этом содержание заданий “Сделать” и “Переделать” может не отличаться, т.е. разница только в названиях. В чем смысл:

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

Вот такой получился паттерн: почти тривиальный, но зато (или как раз поэтому?) потенциально широко применимый.

Небольшое дополнение к предыдущей заметке “Применение для сигнала BPMN“.

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

В случае стартового события (start event) все более спокойно: в одном процессе инициировали сигнал, в результате какой-то другой процесс стартовал. Правда, возникает вопрос: зачем тут использовать сигнал, когда то же самое можно сделать сообщением?

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

Во-вторых, у схемы с сигналом есть концептуальное преимущество:

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

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

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

Я бы выделил два уровня вопроса: 1) формальный и 2) содержательный. Одно дело - дать правильное определение, а другое - понимать, чем данный тип события отличается от других и в каких ситуациях им следует воспользоваться.

В этой заметке я остановлюсь на событии типа “сигнал”.

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

Я часто использую аналогию между системами управления базами данных (DBMS) и бизнес-процессами (BPMS):

1. Когда-то давным-давно компьютерные программы состояли из одних алгоритмов.
2. Потом в какой-то момент выяснилось, что алгоритмы и данные - это разные сущности. Профессор Вирт написал свою знаменитую книгу “Алгоритмы и структуры данных”, и появилось понимание, что для работы с данными нужен специальный инструментарий. Возник новый класс программного обеспечения под названием DBMS.
3. Аналогичным образом, в какой-то момент появилось понимание того, что процесс лучше не сводить к алгоритмам или данным, а рассматривать как самостоятельную сущность, требующую специального инструментария. Так появились BPMS.

Теперь вспомним, как прогрессировали пользовательские интерфейсы к базам данных:

1. Вначале каждая DBMS поставлялась со своим собственным инструментарием. Например, Informix 4GL для СУБД Informix или Oracle Forms для СУБД Oracle.
2. Затем стали появляться универсальные инструменты, позволяющие работать с различными СУБД. Например, в 80-е Unify создал Accell 4GL, функционально очень близкий с Informix 4GL и Oracle Forms, но отличавшийся от них тем, что мог работать и с собственной СУБД Unify, и со всеми ведущими на тот момент СУБД: Informix, Oracle, Sybase. На этом этапе универсальность достигалась просто: поставщик встраивал в свой продукт поддержку той или иной СУБД. Преимущество, которое получал клиент: с таким инструментарием он мог безболезненно сменить СУБД. И это не абстракция: так, Сбербанк в свое время смог сменить СУБД Unify на Oracle, безболезненно перенеся миллионы строк кодов, написанных на Accell. Причем если бы даже Сбербанк сразу сделал ставку на Oracle, то и в этом случае у него были бы сейчас серьезные проблемы, так как, в отличие от Unify, который продолжает исправно выпускать для Accell новые версии, Oracle прикрыл Forms. (Повторяю, речь идет о прикладной системе масштабом многих миллионов строк исходного кода.)
3. В конце концов появился поставщик инструментария настолько мощный, что он сумел заставить поставщиков СУБД стандартизировать программные интерфейсы: Microsoft предложил ODBC. Потом JDBC пошел уже по накатанной дорожке. Поставщикам СУБД пришлось на это пойти, чтобы не оказаться на обочине, но они делают все, чтобы их собственные проприетарные интерфейсы оставались более быстрыми или предоставляли доступ к нестандартным расширениям данной конкретной СУБД. Поэтому не является чем-то необычным инструментарий, который поддерживает, скажем, Oracle и MS-SQL по их собственным протоколам, а всех остальных - по ODBC.

Хотя Microsoft Studio и Oracle JDeveloper достаточно популярны, множество приложений для СУБД от Microsoft и Oracle разрабатывается не на них, а на Delphi, PHP и бог знает чем еще. Так что большинство прикладных разработчиков предпочитает вариант 3.

Как же обстоит дело с интерфейсами к BPMS? Очевидно, они сейчас находятся на шаге 1, и это печально.

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

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

Пусть для начала продукт следует варианту 2, т.е. работающий через адаптеры к конкретной системе. Если продукт окажется успешным, то производитель сможет предложить единый стандарт API для движка BPMS аналогичный ODBC и тем самым оттянуть на себя еще большую долю рынка.

По функциональности такой продукт должен поддерживать:

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

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