Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


 
Семь заблуждений из области исполнения бизнес-процессов

Литература:

Автор: Jean-Jacques Dubray

Оригинал статьи: «The Seven Fallacies of Business Process Execution»

После 8 с лишним лет интенсивных исследований отрасль программного обеспечения и ее заказчики уперлись в стену. Перспективы, намеченные BPM-стартапами эпохи доткомов, пока не материализовались: мы все еще далеки от возможности использовать модели бизнес-процессов, разработанных бизнес-аналитиками, для создания полного исполняемого решения (пусть даже с минимальным вмешательством разработчиков). Потребность в приложениях, работающих от процессов, реальна: гул от инициатив по совершенствованию бизнес-процессов слышен повсюду в компаниях G2000; однако несмотря на столь сильную потребность в непрерывном усовершенствовании процессов, в 2007г. рынок BPM все еще остается маргинальным, (по сравнению с тем, каким он мог бы быть). Это разительно контрастирует со словами некоторых вендоров, поспешивших заявить о себе в 2000г. как о «новом Oracle» на рынке Business Process Management Systems (BPMS).

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

На прошлой неделе Брюс Силвер (Bruce Silver) поднял критические вопросы своей статьей «Roundtripping revisited» (см. также наш перевод). Брюс посетовал на серьезное расхождение между двумя ключевыми стандартами в области BPM: BPMN (Business Process Modeling Notation) и BPEL (Business Process Execution Language). Он привел ссылку на выдающуюся работу команды исследователей (Ouyiang, Dumas, van der Aalst и ter Hofstede). Они решили создать компилятор из BPMN в BPEL, который, по часто высказываемому мнению, является недостающим звеном существующей архитектуры BPMS. В решении этой проблемы они добились выдающихся успехов, хотя их работа пока не закончена. Брюс также высказал аргументы за то, чтобы бросить BPEL и сфокусироваться на пути, который должен привести к успеху: создании стандарта исполняемого BPMN, как нижележащего по отношению к нотации слоя.

Я работаю над этой проблемой с 1997г., и в 2002г. я опубликовал две статьи (1,2), на которые ссылается спецификация BPMN 1.0 от OMG. Я хотел бы повторить аргументацию этих статей, по возможностью с большей ясностью и на другом примере. Я это делаю для того, чтобы исследовать непонимание, лежащее в основе архитектуры современных BPMS, и предложить эскиз новой архитектуры, на которой мог бы базироваться новый класс систем управления бизнес-процессами.

Заблуждение №1: бизнес-аналитики моделируют процессы с точки зрения систем.

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

Заблуждение №2: бизнес-пользователи легко могут изучить BPMN и пользоваться всеми его возможностями.

BPMN – это спецификация в 300 с лишним страниц. Думать, что хотя бы часть ваших бизнес-аналитиков сможет освоить все эти концепции – иллюзия. Михаэль цур Мюлен (Michael zur Muehlen) провел исследование наиболее используемых конструкций BPMN и пришел к выводу, что регулярно используется около 25 конструкций. Я лично написал учебник для бизнес-аналитиков на основе 10 ключевых конструкций, но даже в таком виде мне было трудно убедить принять BPMN «черных поясов» Lean Six Sigma, с которыми я работал.

Брюс Силвер на основе собственного опыта преподавания BPMN замечает:

BPMN содержит множество атрибутов, которые были введены только для генерации BPEL и которые как правило игнорируются.

Заблуждение №3: бизнес-аналитики должны иметь возможность создать исполняемое решение из модели процесса

Я не хочу сказать, что BPMS-вендоры лицемерно стремятся продать вам BPMS, обещая что она это делает. BPM начинался с благих намерений: перспективы большего взаимопонимания между бизнесом и ИТ, коротких циклов разработки… Возникла идея, что бизнес способен создавать модели, которые могут быть превращены в исполняемый код. В этом нет ничего плохого, это продолжение линии CASE-инструментария, MDA, MDD, DSL… Такая перспектива аппелирует к самым потаенным нашим мечтам: быстро, легко, дешево. Каждый раз, когда я слышу как вендор начинает эту тему, я вспоминаю песню Джона Леннона (John Lennon) «Imagine» (т.е. я хотел бы жить в таком мире, но в моей жизни это вряд ли случится). Вендоры увидели за этой идеей реальный (и огромный) рынок, и когда к этому добавились практически неограниченные денежные ресурсы венчурного капитала, то… мы получили то, что получили. Некоторые вендоры больше других преуспели в реализации части этих перспектив, но приходится признать, что перспектива в целом остается далекой. Никто не может утверждать, что у него есть универсальный движок, который позволяет бизнес-аналитику (даже при минимальном вмешательстве со стороны ИТ) создавать решение из модели процесса. Большие проекты проваливаются, использование BPMS маргинализируется и приносит мало пользы организациям.

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

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

Группа меньших по размеру компаний достигла успехов в привлечении как покупателей BPM, так и аналитиков, полностью игнорируя BPEL. Такие вендоры, как Lombardi, Appian и Savvion, сконцентрировавшиеся в большей степени на процессах, вовлекающих людей, чем на интеграции, открыли путь для новой разновидности BPMS, в которой детали исполнения накладываются прямо на модель процесса в виде свойств шагов BPMN-процесса, относящихся к исполнению.

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

Марлон Думас (Marlon Dumas), отвечая Брюсу, соглашается со мной:

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

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

Заблуждение №5: бизнес-процессы должны исполняться централизованно.

Давайте задержимся здесь на минуту. Брюс объясняет, что он сталкивается с новой проблемой:

На самом деле, если они [пользователи BPMN] и успели сделать выбор BPM для исполнения процессов, то в большинстве случаев это был BPEL. Он стандартен, широко распространен, доступен в виде open source. Именно его используют для исполнения бизнес-процессов IBM и Oracle. Все это – факторы в пользу BPEL. Но стандартизовать и BPMN, и BPEL? Нет, конечно это нелогично.

После того, как я около года был в лагере сторонников мнения «roundtrip мертв», я теперь столкнулся с необходимостью снова вернуться к этой теме. В частности, на моих курсах слушатели интересуются: какие стратегии или паттерны следует использовать в диаграммах BPMN, чтобы они хорошо стыковались с предполагаемой BPEL-реализацией? Не предполагал, что мне придется об этом задумываться.

BPMN/BPEL roundtrip был «чашей святого Грааля» этой отрасли. Эта перспектива первоначально была предложена BPMI.org – организацией, основавшей BPML и BPMN. И что же произошло? Как несколько компаний смогли создать успешный рынок для процессов, вовлекающих людей, при этом не испытывая потребности в промежуточном языке оркестровки, а просто добавив некоторую дополнительную семантику в BPMN? Другие высказали предположение, что проблема в том, что мы пока не выработали адекватного языка координации. Например, Арзул Хасни (Arzul Hasni) предложил GRAFCET в качестве лучшего чем BPEL кандидата с точки зрения достижения roundtrip. GRAFCET – это язык программирования, предназначенный для производственных автоматов. По существу, он довольно близок к BPEL.

Ouyaing, Dumas, vand der Aalst и ter Hofstede сделали замечательную работу по созданию маппинга между BPMN и BPEL. Для тех из вас, кто как я позабыл большую часть институтского курса математики, я опубликовал UML-диаграммы для BPMN и BPEL, они могут помочь понять расхождение семантик (т.е. того, что вы можете выразить при помощи того и другого) между двумя спецификациями. Вывод этой группы следователей очень прост:

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

Концепция централизованного движка процессов не нова. На этой основе с начала 90-х было выполнено 99.99% работ в этой области. Этот упор на централизованную архитектуру легче всего усвоить из превосходной презентации Кита Свенсона (Keith Swenson), вице-президента по разработке Fujitsu Computer Systems (которая серьезно инвестировала в XPDL, формат обмена для BPMN).

К несчастью, такой взгляд совершенно неверен и я бы хотел потратить некоторое время, чтобы объяснить почему. Подобный стиль мышления просто игнорирует самую суть бизнес-процесса: дать возможность организации создавать ценность путем преобразования ресурсов. Такие процессы, как «От сырья до изготовления» (Source-to-make), "От предложения до оплаты" (Quote-to-cash) – все они продвигают «нечто» вдоль потока работ, который в конце концов (надо надеяться) добавляют ценность к потребленным и преобразованным ресурсам. Информационные системы тут всего лишь для того, чтобы переходить от шага к шагу, отслеживая и сообщая о состоянии ресурсов и шагов. Действительно, вы можете взять любой бизнес-объект, имеющий физическое содержание – заказ на закупку, счет, складская позиция, сотрудник, заказчик – и у каждого есть жизненный цикл (который можно описать конечным автоматом – см. рис.2).

Я хотел бы привести в качестве примера бизнес-процесс рассмотрения Заявления о приеме на работу (процесс «от кандидата до сотрудника»), который принимает Заявление кандидата и обрабатывает его до тех пор, пока либо кандидат будет принят на работу, либо Заявление будет отвергнуто.

Вот типичная информационная модель Заявления о приеме на работу:

Рис.1. Модель данных Заявления о приеме на работу

Жизненный цикл Заявления (обратите внимание: модель данных Заявления о приеме на работу – контент – не зависит от жизненного цикла и наоборот):

Рис.2. Жизненный цикл Заявления о приеме на работу

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

Теперь вопрос: как вы реализуете компоненту, отвечающую за жизненный цикл Заявления? Я бы создал для этого сервис, реализующий все действия, которые приводят к изменению состояния:

Рис.3. Сервис для Заявления о приеме на работе

Все операции этого сервиса в итоге выполнят некую бизнес-логику, которая приведет к изменению состояния. Какой язык лучше всего подходит для реализации этого сервиса? Java/C#? BPEL? GRAFCET?

Я отдаю предпочтение ориентированному на сообщения языку оркестровки, такому как BPEL, потому что жизненный цикл ресурса длится долго (дни, недели, месяцы, годы). Для иллюстрации давайте рассмотрим ресурс «заказчик»: в качестве заказчика, я на этой неделе прекратил 12-летние взаимоотношения с компанией, выдавшей мне кредитную карту (что привело жизненный цикл моего экземпляра заказчика к завершающему состоянию), так как мне пришлось понести дополнительные расходы из-за того, что на мой взгляд являлось дефективным процессом выставления счета… Да, процессы имеют значение – они могли бы добавить шаг в свой процесс, не меняя жизненный цикл счета, и тем самым сделать меня счастливым, но они этого не сделали, а предпочли максимизировать сумму счета. BPEL – это идеальный язык для реализации таких долгоживущих жизненных циклов (не процессов), поскольку он понимает сообщения (принимает, посылает, порождает), корелляцию сообщений, и он умеет обращаться с параллельно протекающими потоками (да, состояние ресурса может быть составным).

BPEL-реализация (в вендор-нейтральной нотации) могла бы выглядеть так:

Рис.4. Реализация сервиса Заявления о приеме на работу

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

Итак, выбор в пользу принятия в качестве стандарта BPEL, который делает большинство,– правильный выбор… но только до этой точки. Учтите, что благодаря SCA (Service Component Architecture) ваш любимый язык программирования может с легкостью быть дополнен поддержкой семантики BPEL. В прошлом я бы отдал BPEL-J предпочтение перед BPEL, но сегодня, если вам надо выразить некоторую бизнес-логику в традиционном языке, при помощи SCA вы легко можете воспользоваться возможностями оркестровки в вашем любимом языке (Java, C++, COBOL, PHP, ABAP).

Между жизненными циклами ресурсов и языками оркестровки существует столь тесная взаимосвязь, что ведущие движки оркестровки предлагают парадигму конечного автомата в качестве пути к созданию оркестровки. Так обстоит дело с IBM Process Server и Microsoft Workflow Foundation. (Прошу прощения если я забыл кого-либо еще, если вы знаете – дайте мне знать.)

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

Прежде чем мы взглянем на взаимоотношения между жизненным циклом и процессом, надо подчеркнуть, что концепция жизненного цикла интуитивно очень понятна. Большинство бизнес-аналитиков с легкостью готовы описать жизненный циклы (например, в нотации UML). Я готов поспорить, что почти каждый в организации, вне зависимости от его роли, способен разобраться в таком жизненном цикле. Однако, я также готов спорить, что, с другой стороны, практически никто не способен разработать (например графически, используя BPMN) бизнес-процесс, который соответствовал бы жизненным циклам всех затрагиваемых ресурсов. Предположим, что вы создали такую модель, назовем ее вариантом процесса. Какую вы можете дать гарантию, что жизненный цикл ресурса не затронут? Какой объем тестирования и контроля качества необходим для верификации этого?

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

Теперь давайте взглянем на, то как бизнес-аналитик описал бы процесс Заявления о приеме на работу средствами BPMN:

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

Во-первых, в BPMN нет понятия «ресурс» и, следовательно, понятия «жизненный цикл», максимум что можно сделать в BPMN – это дать аннотации к определенным точкам процесса, указывающие на ожидаемое состояние (как показано выше). Все в порядке, так и должно быть в BPMN. Во-вторых, бизнес-аналитик совершенно не в курсе того, какие операции сервиса Заявления о приеме на работу должны быть вызваны для изменения его состояния. Это – часть взгляда со стороны систем. Большая ошибка – ожидать, что бизнес-аналитик добавит шаги «вызвать» между шагами, которые он моделирует как задания, выполняемые пользователями. К сожалению, люди стали руководствоваться неверными взаимоотношениями между BPMN и BPEL, что привело к добавлению к процессной нотации семантики посылки (Send), приема (Receive) и вызова (Invoke). Это совершенно искусственный прием, который не должен использоваться никогда, за исключением случая, когда сообщение отправленное или полученное – это бизнес-сообщение, а не вызов операции (как, например, Заявление о приеме на работу, поступившее на стол рекрутеру).

Как реализуется бизнес-процесс? Среда выполнения бизнес-процесса представляет собой сборку (assembly) сервисов, взаимодействующих друг с другом (но не набор сервисов с централизованной оркестровкой):

Рис.6. Реализация процесса рассмотрения Заявления о приеме на работу

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

И вот отличная новость: чтобы сделать эту перспективу реальностью, у нас уже есть все необходимые  технологии, включая технологию сборки в виде Компонентной сервисной архитектуры (Service Component Architecture). Все, что вы видите на этом рисунке, может быть реализовано комбинированием SCA 1.0, BPEL 2.0, Web Services (XSD и WSDL 1.1 – из-за BPEL 2.0), BPEL4People 1.0 и Human Tasks 1.0.

К BPMS с архитектурой, основанной на этом эскизе, сделанное Брюсом ранее утверждение

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

– больше не относится. WS-HumanTask и BPEL4People относятся к контейнеру задач и конечно отделены от BPEL как такового. Мы можем поспорить нужны ли BPEL «подпроцессы», но я бы сказал, что для языка реализации сервисов жизненного цикла это не критично: очень немногие элементы конечного автомата так уж целесообразно использовать повторно, они тесно связаны со своими ресурсами.

На сегодня – к сожалению – Microsoft не принимает участия в SCA и BPEL4People, так что вы не можете использовать Workflow Foundation в качестве альтернативы движку BPEL, хотя он отлично справился бы с работой. Однако вы можете использовать WCF в качестве контейнера сервисов, который будет реализовывать сервисы, вызываемые из SCA и из вашего любимого движка BPEL. У самого Microsoft нет механизма сборки, так что вам не удастся реализовать этот эскиз архитектуры в .Net. Что касается open source, то в нем имеется большинство компонент (SCA, BPEL и Service container), но не хватает контейнера BPEL4People. Это не критично, простой контейнер выполняемых людьми заданий сделать не так уж тяжело (правда, не до уровня BPEL4People и WS-HumanTask).

Чтобы разобраться с ролью разработчика в этой новой архитектуре, давайте сфокусируемся на шаге «Schedule Interview» (назначить собеседование) модели процесса (рис.5). Как видите, ему отводится важная роль в модели процесса (и это оправдано, потому что это то что нужно сделать пользователю, если система приема Заявлений отказала), но с целью оптимизации с бизнесом была достигнута договоренность, что задача назначения собеседования будет автоматизирована при помощи, например, сервера Exchange. Жизненный цикл Заявления о приеме на работу предусматривает, что собеседование назначается после того, как заявление кандидата сохранено. Заметим, что сервис Заявления о приеме на работу на знает как эта функция реализована. Вполне может случиться, что это тоже окажется заданием, выполняемым человеком. На этом уровне понимания попросту невозможно автоматически принимать подобные проектировочные решения. Вот почему модель процесса должна быть полностью отделена от какой бы то ни было семантики исполнения процесса. Еще одно проектное решение, не оказывающее влияния на схему процесса – тот факт, что заявление кандидата может появиться в другом контейнере заданий, выполняемых людьми. Мы вполне могли бы «собрать» (assemble) этот процесс с заявлениями кандидатов, размещенными на популярном сайте поиска работы. Как только заявление одобрено для собеседования, шаг процесса мог бы послать кандидату по электронной почте сообщение, которое направит его на выполнение задания в рамках процесса (ознакомиться с предложением, ввести информацию о своей работе). Могу поспорить, что вам не удастся (легко) это сделать с вашей BPMS сегодняшней архитектуры.

Замечание в скобках: теперь вы видите, что менеджер заданий, выполняемых людьми, в действительности не является подсистемой движка процессов. Конечно, сегодняшние BPMS спроектированы именно так, но в действительности это не так, они являются независимыми компонентами архитектуры, управляющей выполняемыми людьми заданиями (рис. 6). Естественно, такие выполняемые людьми задания всегда связаны с одним или несколькими бизнес-процессами, но у них есть свой собственный жизненный цикл и они напрямую взаимодействуют с сервисами жизненных циклов ресурсов. Как Доминик Ваке (Dominique Vauquier) написал в своей статье [1]: «Выполняемые людьми задания прививаются на жизненный цикл ресурса». Вдобавок, как мы рассмотрели в предыдущих абзацах, критически важно дать возможность процессу взаимодействовать с несколькими контейнерами заданий.

Я здесь не описываю роль правил или Управления мастер-данными (Master Data Management), хоть они и критически важны и требуют специальных контейнеров сервисов, известных как BRMS (Business Rules Management System), см. рис.6. Вопросы, поднятые Майклом цур Мюленом (Michael zur Muehlen) и Марком Проктором (Mark Proktor), теряют смысл благодаря SCA (с точки зрения времени исполнения). SCA позволяет выбирать наиболее подходящий механизм сервиса принятия решения (исполняясь в процессе вашего движка BPEL, если это технически возможно). SCA предполагает высокую степень независимости между элементами этой архитектуры, позволяя повторно использовать их в разных процессах, при этом выбирая наилучшую конфигурацию для исполнения каждого процесса.

Также я не говорю о роли B2B, о нем много сказано в двух моих собственных статьях (1,2). B2B в этом эскизе архитектуры поддерживается возможностью проведения произвольных границ в рамках сборки. Например, я могу «собрать» два взгляда на жизненный цикл заказа на покупку (со стороны покупателя и продавца). Это огромное преимущество. Традиционная «централизованная» модель исполнения создает искусственные разрывы на границе B2B и навязывает две разных модели исполнения: централизованную оркестровку на каждой стороне и сборку посередине. Некоторым образом, мое предложение просто базируется на оригинальной модели определения B2B процесса OASIS ebXML Business Process, но применительно к уровню ресурсов, а не только уровню бизнес-партнеров. Вот почему модели исполнения непрерывны как внутри организации, так и на ее периферии при взаимодействии с бизнес-партнерами.

Заблуждение №6: Семантика исполнения бизнес-процесса легко выводится из существующих концепций программирования

Практически все, с кем я встречался в рабочих группах, отвечающих за стандарты исполнения бизнес-процессов (таких как BPML, BPEL, WS-CDL), не являются практиками (включая меня). Это разработчики и архитекторы. Зачастую они концентрируются на сложных математических теориях (таких как пи-вычисления, Pi-Calculus), не убедившись в том, что семантика этих теорий действительно удовлетворяет потребностям исполнения бизнес-процессов. Как правило, при написании требований эти технические комитеты фокусируются на 3-5 use-case. Эти use-case часто тривиальны и редко отражают сложность бизнес-процессов реального мира.

Семантика исполнения бизнес-процессов плохо поддается концептуализации. Настолько плохо, что большинство исполняемых процессов в наших решениях все еще мучительно программируется, строка кода за строкой. Я уверен, что каждый выбрал бы альтернативный путь, если бы он был. Мне посоветовали почитать комментарии из дискуссии к статье «Почему Java-программисты  ненавидят BPM?» (Why Java Developers Hate BPM?) Ни один из комментаторов не пожаловался на неадекватность абстракции. Даже такой кодер, как главный архитектор JBoss Билл Бурк (Bill Burke), с которым я недолго вместе работал над контейнером исполняемых людьми заданий до того, как он присоединился к JBoss, пишет:

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

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

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

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

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

И еще: этот эскиз новой архитектуры не означает, что инвестиции в вашу любимую BPMS пропадут. Правда, вам понадобится добавить к ней контейнер композитных сервисов (Composite Service Container), такой как контейнер BPEL, и контейнер сборки (SCA) и использовать BPMS в основном в качестве контейнера выполняемых людьми заданий (каковым, в сущности, они в основном и являются). Контейнер выполняемых людьми заданий – это почетная и важная компонента архитектуры. Контейнеры заданий нынешних BPMS – это продукты весьма изощренные, и самим их сделать нелегко, так что деньги потрачены с пользой. Я вовсе не хочу умалять роль такого контейнера. На самом деле, я ожидаю, что в течение 2 лет все BPMS-вендоры примут взгляд, представленный в этой статье, и трансформируют свои системы так, что они смогут работать со SCA-сборками и BPEL-контейнерами на основе данного эскиза.

Я также заявляю, что в итоговой реализации станет возможным автоматически реконструировать «as-is» взгляд на операционные процессы. Пока я этого не доказал, возможно это станет темой исследования.

Заключение

После стольких лет поисков магической пули BPM, индустрия программного обеспечения уперлась в стену. Эта стена легко может быть преодолена при условии смены парадигмы и рефакторинга бизнес-логики на основе жизненных циклов ресурсов. Если мы сейчас свернем не туда и будем оставаться в плену рассмотренных 7 заблуждений, то мы сильно рискуем выкинуть программные продукты и стандарты из-за недостаточного ROI и вернуться к тому, что все будет программироваться вручную. Если же мы возьмем ту самую технологию, что у нас сегодня имеется, но станем использовать ее по-другому, то мы дадим очень привлекательную перспективу и бизнесу, и ИТ. Я бы не стал называть эту перспективу BPM, по существу это больше чем BPM, скорее я бы назвал ее «Композитными приложениями» (Composite Applications) или более точно «Композитными решениями» (Composite Solutions).

Перспектива Композитного решения прямо отвечает на потребности бизнеса по отношению к ИТ:

  1. Конструировать решения быстро в рамках проектов возможно меньшего масштаба (рассчитывать на многие итерации)
  2. Менять решения быстро и поддерживать итерационный подход Lean Six Sigma
  3. Уметь визуализировать бизнес-схему операций в реальном времени без сложных проектов «выявления текущего состояния»
  4. Уметь извлекать показатели операционной эффективности текущей бизнес-схемы без сложных проектов по их измерению

Я утверждаю, что способность «Уметь создавать/изменять решение напрямую путем создания/изменения схемы бизнеса» (вне зависимости от того, насколько это выглядит привлекательным) антагонистична по отношению к этим четырем требованиям. По той причине, что это ведет к чрезмерно упрощенным, жестким, ориентированным на задания моделям приложений (что мы наблюдаем в сегодняшних BPMS). Такие модели приложений не способны удовлетворить потребности бизнеса и обычно приводят к возрастанию стоимости проекта, поскольку создание реально работающих решений требует большого объема дополнительной (custom) разработки «вокруг» модели приложения BPMS. Дополнительно усложняет задачу то, что эти системы, как отмечается в дискуссии «Почему Java-программисты ненавидят BPM?» пока не предоставляют для такой дополнительной разработки достаточно устойчивой и пригодной для масштабных проектов среды.

Я утверждаю, что плодотворное направление – это Композитное программное обеспечение (Composite Software), основанная на двух моделях композиции: сборки (SCA) и оркестровки (BPEL). (Конечно, от хореографии это тоже недалеко, но это я объясню в другой статье.) Технология для реализации данного эскиза доступна уже сегодня. Вдобавок, BPEL и BPMN, в их нынешнем понимании, работают. Если что-то и надо менять в BPMN, то это удалить всю семантику исполнения, чтобы дать бизнес-аналитику возможность для самовыражения. Для тех, кого это интересует,– некоторые подробности того, как создавать композитное программное обеспечение используя эти стандарты и этот эскиз архитектуры, на прошлой недели опубликованы InfoQ в этой мини-книге.

Архитектура Платформ композитных решений (Composite Solution Platforms), описанная в этой статье, предлагает также более чистый интерфейс между SOA и BPM. С ним появляется возможность создавать в рамках SOA сервисы, которые являются по-настоящему повторно используемыми: сервисы жизненного цикла ресурса, которые могут быть повторно использованы различными группами и вариантами процессов. Поскольку сервисы жизненного цикла ресурсов становятся повторно используемыми между процессами, это также означает, что реализация любого процесса выполняется намного дешевле, быстрее и проще. Реализация сервисов жизненного цикла ресурсов – это «программный код» внутри процесса. Считать, что бизнес-аналитик (или кто-либо еще) обладает знаниями, необходимыми для создания или изменения программного кода этих жизненных циклов при помощи графической нотации в рамках схемы процесса просто означает толкать BPM в неверном направлении.

Для этого эскиза платформы композитных решений уже есть способная его поддержать Корпоративная методология (Enterprise Method): Praxeme. Praxeme Institute переводит свои работы на английский и добивается больших успехов в достижении этой цели.

И еще, я всерьез разделяю некоторую обеспокоенность Брюса и Марлона относительно вовлечения разработчиков в сегодняшние технологии (SCA, BPEL,…), поэтому я начал инициативу под названием wsper. Эта инициатива предлагает абстрактную среду программирования, упрощающую работу программистов и архитекторов над реализацией жизненного цикла и сборок процессов. Она также помогает создавать Платформу композитных решений из гетерогенных компонент – путем изоляции реализации бизнес-логики от этих компонент (и их будущего развития). Она также изолирует бизнес-логику от развития стандартов.

Я хочу выразить огромную благодарность Сэнди Кемсли (Sandy Kemsley) за ее столь многочисленные полезные ссылки и комментарии.

[1] Данная статья дополняет статью Доминика Ваке (Dominique Vauquier) «6 заблуждений из области усовершенствования бизнес-процессов» («The 6 Fallacies of Business Process Improvement»), фокусируясь на трансляции от модели бизнес-процесса к ее исполнению. Статья Доминика исследует как моделирование бизнес-процессов соотноситься с проектами усовершенствования бизнес-процессов. Я перевел статью Доминика с французского и она принята BPTrends.com к публикации на январь 2008г.

Комментарии
#1 Анатолий Белайчук, 25.12.2007 17:54

Коллеги

Мне кажется, у нас спонтанно образовалась очень удачная серия из трех статей: статья про то, что "Worflow не тянет", статья Силвера про round-trip и эта статья. Она может показаться мутноватой, тяжеловесной и затянутой (и наверное, действительно таковой является, во всяком случае переводить ее было тяжким трудом). Но если потратить на нее время, то можно найти ответы (пусть частичные) на вопросы, поднятые первыми двумя.

Например такой: между "бумажным" и "полупроводниковым" BPM нет противоречия, нужно просто использовать тот и другой по назначению. Бумажный (a.k.a workflow, human2human, pure-play) необходим для наведения моста между бизнесом и аналитиком и создания быстро адаптирующегося (agile) ИТ и предприятия в целом. Полупроводниковый (BPEL) идеально подходит для моделирования жизненного цикла разнообразных бизнес-объектов: контрагентов, контрактов, платежей и т.д.

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

То есть, с одной стороны, можно удачно спарить workflow и collaboration. С другой стороны, к BPEL-хребту уместно прицепить MDM: когда состояние конечного автомата бизнес-объекта меняется, это изменение надо протиражировать на все базы и унаследованные системы, в которых этот объект каким-то боком участвует.

Не знаю как вы, а я заметно подобрел по отношению к BPEL, взглянув на него под ракурсом, заданным Жан-Жаком. Спасибо ему за это.

Остается только добавить к этой картине среду, в которой все компоненты (workflow, collaboration, orchestration, MDM) будут уживаться и общаться друг с другом: SCA, ESB, JBI... что это такое пока мне лично пока не очень понятно, буду рабираться.

#2 Анатолий Белайчук, 25.12.2007 18:17

Для иллюстрации высказанного выше приведу аналогию. Есть такое сравнение: "workflow - это excel для процессов". На самом деле, он не сколько таковым является, сколько хотелось бы чтобы он им стал: чтобы люди бизнеса, которые без конца меняют взгляды на свои процессы и тем самым отравляют жизнь ИТшникам, могли бы сами перестраивать логику систем, которыми они пользуются. Не целиком конечно, но хотя бы в части схемы workflow. Аналогично тому, как они сами проводят какие-то свои маркетинговые вычисления в Excel - представляете, чтобы было если бы всю эту муру для них делал бы программист? Ужас, хоть увольняйся!

В случае с Excel это работает отчасти благодаря тому, что программист дал этим power users четко определенный доступ к корпоративным данным и процедурам через взгляды на таблицы, хранимые процедуры, odbc-соединения. И архитектор корпоративной системы может спать спокойно: пусть себе "юзеры" резвятся, ничего испортить они не смогут.

Применительно к процессам, если мы хотим чтобы workflow мог выступать в роли excel, мы должны на back-end поставить BPEL-процесс жизненного цикла, чтобы он нам гарантировал то же спокойствие, которое в случае excel дает ограничение доступа к информационным ресурсам.

#3 Alexander Samarin, 30.12.2007 23:31

Статья интересная. Я ее откомметировал в оригинале
improving-bpm-systems.blogspot.com/2007/12/this-blog-posting-is-reply-to.html

Thanks,
AS

#4 Максим Косенко, 16.01.2008 23:18

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

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

Также мне не кажется, что IT-шники страждут опереться на что-то большое, надежное и проверенное временем вроде BPEL.

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

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

Очень правильный довод - даже аналитики не знают толком BPMN. И надо сказать и не будут его знать. Если строить системы, которые основываются на предположении, что ты знаешь стандарт, то честно говоря, они обречены на исключительно профессиональное использование. Т.е. скажем J2EE это хороший стандарт (хотя бы потому что есть хоть какой-то). А еще есть его разные реализации. И произвольно взятый программист не осилит написание приложения на нем без того, чтобы кропотливо изучать, вникать, экспериментировать. Да, сделать что-то он может, а вот взять и просто начать работать основываясь на своем опыте как программиста - нет. К чему я привел пример этот - мое мнение, что рано хоронить BPMS как платформу для быстрого и надежного построения приложения автоматизирующего деятельность компании средним аналитиком самой компании (у которого нет такого опыта ранее).

Если он сможет справиться с помощью готовых заготовок, блоков, объектов и помощи обычного (не BPM-specific) программиста, подсказок в системе - то это большое дело.

Другой вопрос, что а) 95% систем либо отказались либо плюнули на эту тему (сосредоточившись на том, что это просто инструмент для интегратора) б) вот все вот такие соображения как в статье все больше помогают думать, что, ну да, это только для профессионалов, иначе это поделка и безделушка.

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

Потому что все эти темы это все то, что волнует только компании, подсевшие на огород систем, у которых уже IT специалисты по BPEL скоро на пенсию пойдут и т.д. Так мне кажется. Должно быть и то и другое - мое мнение. Но когда и pure-players все больше скатываются в дебри стандартов, методологий, взаимосвязей и возможностей, все больше уходя от того, чтобы просто дать приложение, которое работает сразу и подгоняется под нужды постепенно... Не знаю...

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

#5 Максим Косенко, 16.01.2008 23:28

Да, еще хотел не в тему сказать... Пока тут уведомлений не будут присылать об ответах - тут жизни толком на форуме не будет... А жаль (правда это не форум, а комментарии к статьям, но обсуждение присутствует).

#6 Анатолий Белайчук, 18.01.2008 23:31

Максим

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

Проблематика статьи - задачи, выходящие за рамки простого workflow, выполняемого "от сих до сих". Представьте себе сквозной end-to-end процесс "от заказа до оплаты" производственной компании:
- предпродажный процесс в случае удачи запускает процесс заключения договора
- если договор подписан, то на определенные моменты в будущем должны быть запланированы продление и закрытие
- в связи с договором, но асинхронно, запускаются отдельные сделки (предположим, что договор рамочный)
- каждая сделка распадается на несколько самостоятельных процессов по разным видам товаро/услуг
- процесс отгрузки вызывает процесс производства, но не непосредственно - производство запускается асинхронно, собирая заказы из разных сделок
- похожим образом производство инициирует закупки
- и т.д.

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

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

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

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

Насчет уведомлений об ответах Вы правы на 100%.

#7 Alexander Samarin, 19.01.2008 23:04

Сначала немного терминологии во избежании путаницы.

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

Чтобы это сделать в масштабах предприятия, нужны толковые наборы правил, моделей, и рекомендаций как создавать гибкие BPM системы с испольванием существующих технологий, включая BPM suites, SOA, ECM, BR, BI, EA и IT governance.

И общий комментарий насчет стандартов – многие из них довольно эклектичны. Поэтому вместо обучения стандарту (в частности, BPMN), я предпочитаю обучать как использовать стандарт для нужд клиента(аналогия с MS Word – обычно мы используем из него только 5% возможностей).

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

Трактуя BPMS как BPM suite. Мой личный опыт – это как использовать такой инструментарий для совместной работы аналитиков, программистов и интеграторов по постепенной реализации процессов. Сначала берутся довольно “короткие” процессы, например, из ECM или типичные batch. Затем они используются как сервисы в более “длинных” процессах и т.д. Важно видеть что должно быть построено (enterprise architecture) и знать как сохранять гибкость системы (agility).

От Анатолия: ... Представьте себе сквозной end-to-end процесс "от заказа до оплаты" производственной компании:...

Я думаю, что в таком случае наиболее необходим архитектор BPM систем для того, чтобы доходчиво объяснить всем вовлеченным лицам (от руководства до простого рабочего и системного администратора – практически любому сотруднику) как BPM система решает их проблемы и как она изменит их работу к лучшему. Обычно архитектор работает с BPM артефактам (я их уже упоминал) и распределяет "поиск", реализацию и компоновку этих артефактов среди аналитиков, программистов и интеграторов.

От Анатолия: ... BPM для малых компаний?

Если такая компания сильно зависит от внешне регламентированных правил (compliance, ISO 9000, etc.) то BPM система, например на основе открытого ПО, очень может пригодиться.

Thanks,
AS

#8 Максим Косенко, 20.01.2008 04:28

>Мне кажется, Вы сделали из статьи неправильные выводы.

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

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

>Представьте себе сквозной end-to-end процесс "от заказа до оплаты" производственной компании:

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

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

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

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

Этого я не очень опасаюсь, понятно, что подобные статьи и взгляды они доносятся до определенной аудитории, а для массового корпоративного клиента это просто рассуждения специалистов о квантовой физике. Другое дело, что попытка понять новому клиенту что есть BPM утыкается в 2 вещи - рассказы о том, что это серебрянная пуля и рассуждения о том как прикладывать один стандарт к другому так, чтобы реже болеть. Понятно, что 99% новых клиентов поищут что-нибудь попроще. Просто другую ERP/SCM/CRM/... С ними по крайней мере гора материалов, которые гораздо понятнее и не пестрят ворохом стандартов и новыми аббревиатурами типа BI/BAM и прочая.

>BPM для малых компаний? При всем моем личном энтузиазме - очень сомнительно.

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

Но это проблема. Мне нравится подход Александра в первом абзаце. Так и есть - каждая компания так или иначе управляет бизнес процессами. У каждой организации хоть какой-то менеджмент их да есть. Вопрос в том, что во всех процессах компании есть какие-то этапы, которые было бы удобно автоматизировать. Да, их можно автоматизировать массой продуктов и способов. Придумано множество различных названий для систем автоматизирующих разные виды подобных процессов. И BPM может быть той системой, которая не обязательно используется для того, чтобы отказаться от гибкости, а та система, которая эффективно подхватывает определенные процессы и помогает компании автоматизировать те места, которые нужно. Она может помочь связать системы с людьми. Помочь связать разные приложения воедино.

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

Теперь вот насчет цены вхождения. Я молчу про заоблачные цены на лицензии. Во-первых это по-разному, а во-вторых все мы давно знаем, что цена это то, за сколько выгоднее всего продавать. Если все-равно компания не справится сама с тем, чтобы понять как она работает, то при цене 200 у.е. за час консалтинга, реинжиниринга и девелопмента уже не важно сколько стоят лицензии. Я не призываю продавать дешевле - это не имеет смысла. Кроме того, есть Open Source и просто недорогие решения. И не сказать, что они хуже или не заработают у больших клиентов - очевидно у них другая аудитория. Я просто говорю про то, что, конечно, такие BPM соизмеримые по цене с SAP R3, они не для средних компаний.

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

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

Но мое мнение, что это подход производителей к продажам создал такие условия, а не сама концепция BPM.

>Что касается стандартов: к ним все же надо стремиться, хотя и без фанатизма.
Стандарты это хорошо. Когда в тему. А когда надо написать много статей, чтобы притянуть их за уши - это мне кажется не в тему. Для полноценной интеграции BPM и для исполнения своих задач им не нужен BPEL. BPMN это хорошая опция, потому что это стандарт на нотацию - если его кто-то уже знает, ему будет легче создавать модели, но следовать ему один в один, чтобы полностью поддерживать из принципа - вряд-ли это так важно. Т.е. я вовсе не против стандартов. Но то, что творится в области BPM это на мой взгляд фанатизм + личные интересы некоторых вендоров. Продукт может быть хорошим и без этого. Совершенно ничего он не теряет отказавшись от поддержки этих стандартов, кроме клиентов, которым нужны шашечки.

>Сравнение BPMN с J2EE на мой взгляд не слишком корректно: J2EE - это мета-стандарт, собрание из многих сотен API, BPMN по сравнению с ним гораздо проще.

Я гораздо более метафорически сравнивал. Т.е. я просто говорил к тому, что BPM преподносится как сложная вещь, которая требует специалиста по BPM. А это не должно быть так. Т.е. оно того не стоит. Мое мнение.

>Если такая компания сильно зависит от внешне регламентированных правил (compliance, ISO 9000, etc.) то BPM система, например на основе открытого ПО, очень может пригодиться.

Да, это частый пример. Но вот, Александр, вам не кажется, что вообще говоря, даже и те компании, в которых нет жестких процессов, а есть повторяемость - им тоже может быть нужен BPM, но не как средство жесткого регулирования, а как вспомогательный инструмент? В конце концов малые компании используют workflow, crm, scm, docflow системы. И вполне эффективно.

Но ведь BPM может делать тоже самое, только гибче и более целостно. Конечно готовые решения обладают в какой-то степени более проработанным набором инструментов. Но и куда более жестким и однобоким. Это уже вопрос к вендорам BPM - почему они не предоставят гибкие инструменты? Почему у них, скажем в массе своей GUI сводится к Dashboard + Portal + Designer + Admin и при попытке заменить готовые решения BPM откровенно проигрывают своими пользовательскими инструментами...

#9 Анатолий Белайчук, 20.01.2008 23:56

"Каждое предприятие имеет свою собственную BPM систему..." - простите, коллеги, какого цвета небо на вашей планете?! smile Я понимаю, Александр обретает в краях может быть более просвещенных. Максим, но Вы-то оперируете российскими реалиями?

Даже если под BPM понимать управленческую методологию, которая может применяться вообще без софта - и тогда это утверждение мне представляется сильно натянутым. По моим наблюдениям, московским и российским, 95% компаний находятся на нулевом уровне зрелости BPM по Gartner Maturity Model. Помнится, мой сын в свое время пытался доказывать, что "двойка - это тоже оценка". Вы считаете, нулевой уровень BPM - это тоже BPM?!

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

Александр - "в таком случае наиболее необходим архитектор BPM систем". Понятное дело, о нем и речь. Вы много знаете архитекторов с опытом решения сформулированной мною задачи? Есть ли вообще такой опыт в природе? Удалось ли хотя бы кому-нибудь загнать в BPM сквозной процесс подобного масштаба или все пока ограничивается относительно скромными workflow и/или интеграционными сценариями? Теоретически я и сам могу рассказывать что надо делать: постепенно "выращивать" сеть взаимодействующих процессов. На практике пройдут годы пока наберешь такой опыт самостоятельно, и не обойдется без ошибок по пути.

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

"BPM преподносится как сложная вещь, которая требует специалиста по BPM." Дело не в том, что она сложная или там дорогая. Она требует *выделенного* специалиста, и это проблематично для компании мастштаба десятков человек.

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

#10 Максим Косенко, 21.01.2008 03:16

>Помнится, мой сын в свое время пытался доказывать, что "двойка - это тоже оценка". Вы считаете, нулевой уровень BPM - это тоже BPM?!

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

>Максим, но Вы-то оперируете российскими реалиями?

Да, но я другое здесь понимаю под BPM. Я имею в виду, что какие то ключевые процессы у компаний как правило как-то но управляются. Могут и лучше. Иногда сильно лучше - и станет хуже. Здесь речь не идет даже про осознанную методологию или автоматизацию. Речь идет про словосочетание Управление Бизнес Процессами. А не про BPMS или про стандарты на это.

>Оптимизм внушает только одно: все без исключения думающие люди в бизнесе и ИТ проявляют к этой теме живой интерес.

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

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

Если присмотреться к форумам того же Intalio (или других доведенных до полезного состояния Open Source BPMS) - отчетливо видно, что там довольно много мелких и средних компаний. Т.е. их там заведомо большинство. И вполне видно, что многие успешно используют на практике самостоятельно. И многие совсем не потому, что им надо следовать неким жестким стандартам.

Касательно выделения. Вообще надо сказать, что по моему впечатлению средней и мелкой компании куда проще наладить BPM. И пользы от него больше и найти того одного человека, который этим займется, как не парадоксально, куда как проще, чем в большой компании, так как энтузиазм на местах еще может быть, а реальные процессы можно вполне окинуть взором за короткое время. Я не согласен, что этот специалист во всех случаях должен быть навсегда оторван от компании. Но вообще любая современная автоматизация это уже довольно существенная часть компаний. И компаниям уже давно вполне посилу иметь своего сисадмина, своего завхоза и т.д. Очевидно, что автоматизация это очень важно и иметь Начальника Отдела АСУ вполне логично и прибыльно для многих компаний. Пусть поначалу и "приходящего".

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

#11 Анатолий Белайчук, 21.01.2008 08:42

Пара уточнений:
1) Я говорил об интересе, проявляемом _когда_ты_им_о_BPM_рассказываешь_. Сплошь и рядом оказывается, что они о чем-то подобном мечтали. При этом я не имел в виду, что все они бросили свои дела и бегают в поисках BPM.
2) Я говорил о *выделенном* специалисте, т.е. штатном, а отнюдь не внешнем. Успешно практиковать BPM без такого специалиста на мой взгляд невозможно.

#12 Alexander Samarin, 24.01.2008 03:37

Извините, слегка выпал из дискуссии, т.к. сайт не был доступен для меня.

У меня небольшой вопрос – что подразумевается под « крепкой интеграционной основой » -- инфраструктура для SOA: ESB, registry, etc.?


От Максима ...Но вот, Александр, вам не кажется, что вообще говоря, даже и те компании, в которых нет жестких процессов, а есть повторяемость - им тоже может быть нужен BPM, но не как средство жесткого регулирования, а как вспомогательный инструмент? В конце концов малые компании используют workflow, crm, scm, docflow системы. И вполне эффективно.
Но ведь BPM может делать тоже самое, только гибче и более целостно. Конечно готовые решения обладают в какой-то степени более проработанным набором инструментов. Но и куда более жестким и однобоким. Это уже вопрос к вендорам BPM - почему они не предоставят гибкие инструменты? Почему у них, скажем в массе своей GUI сводится к Dashboard + Portal + Designer + Admin и при попытке заменить готовые решения BPM откровенно проигрывают своими пользовательскими инструментами...

По определению, хорошая BPM система нужна всем. Иногда на весь end-to-end процесс, иногда на его фрагменты, которые мы хотим контролировать в большей степени.
Strong coordination is used to guarantee that a promised outcome will be delivered with the expected customer satisfaction (quality, time, safety, etc.). This is obviously the case for automated control-oriented coordination, because many staff members, internal services and formal regulations are involved.

Исторически, небольшие фрагменты автоматизировались с помощью workflow, crm, scm, docflow. Но эти технологии сидели в своих silos и реализовали intra-application coordination. В тоже время, inter-application coordination реализовалось с помощью batch processing. В идеале, BPM система призвана реализовать единым образом intra-application и inter-application coordination. В реальности можно встретить смесь из новой BPM suite, которая использует как сервисы старые workflow.

“жестких процессов” вообще-то не существует, а есть бизнес потребности в эволюции процессов и ИТ возможности. Зачастую вторые определяют скорость реализации первых -- the tail wags the dog.

Насчет гибкости BPM систем – современные BPM suites (e.g. WebSphere, Oracle SOA) предоставляют очень широкие API. Если не нравятся или не подходит out-of-the-box Worklist manager, то он относительно легко переписывается. Как я уже говорил, проблема не в BPM suites, а в том как с их помощью построить конкретную BPM систему, которая будет довольно гибкой. Конечно с каждой BPM suite будет своя возня, но это проблемы другого порядка сложности.

Насчет готовых решений: Понимая это как off-the-shelf – они обычно ограничены, т.е. не реализуют end-to-end процесс. Понимая это как custom development – типично они не предназначены для эволюционного развития. Я видел как дорогие системы выбрасывались после года эксплуатации.

От Анатолия: ... "Каждое предприятие имеет свою собственную BPM систему..." - простите, коллеги, какого цвета небо на вашей планете?!

Но моему опыту BPM система – это логичная организация работы, которая очень много взяла из ISO 9000 особенно версии 2000 года. И хорошо известно, что ISO 9000 основывается на советской системе.

Правильная реализация BPM системы практически покрывает все основные требования ISO 9000. Я показывал наши исполняемые процессы внешним аудиторам и этого было достаточно для сертификации.

К сожалению многие существующие реализации ISO 9000 – это бумажное дублирование существующих систем.

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

Вся проблема в создании гибкой BPM системы. Сквозные системы есть но очень дороги в обслуживании. Даже использование индийских компаний уже не работает – слишком много тестирования после мелкой модификации. Другой пример, oil trader сделал свою систему на базе SAP/R3. После нескольких месяцев эксплуатации пользователи сказали, что система не соответствует их работе – рабочий процесс изменился.

Моя специализация – это практическое обеспечение гибкости BPM систем начиная со стадии их проектирования. Моя книга предназначена, в основном, для архитекторов BPM систем.

Так как книга еще не опубликована, она распространяется на соотвествующих условиях. Если хотите обсудить – пожалуйста звоните 0041 76 573 40 61.

Thanks,
AS

#13 Анатолий Белайчук, 24.01.2008 14:28

Александр - "что подразумевается под «крепкой интеграционной основой» -- инфраструктура для SOA: ESB, registry, etc.?"

Нет, это была отсылка к архитектуре, предложенной в статье. Бизнес-объекты, смоделированные через конечные автоматы и реализованные ИТ через BPEL, становятся фундаментом. Разнообразные и сильно изменчивые workflow создаются в основном усилиями аналитиков и служат "мостами" между объектами: они либо создают экземпляры одних объектов из других, либо меняют состояния каких-то объектов.

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

#14 Alexander Samarin, 25.01.2008 01:43

Спасибо, Анатолий, за уточнение. Хорошие бизнес-объекты - это вещь в хозяйстве полезная (я их использую на втором снизу уровне). Главное, чтобы эти бизнес-объекты были достаточно атомарные, с интерфейсом интеллекуальнее чем CRUD, и не содержали бизнес-логики. Подробнее в improving-bpm-systems.blogspot.com в комментарии на Fallacy #5.

Thanks,
AS

#15 Михаил Манылов, 20.05.2008 17:49

Да, Марлон Думас, вероятно, родственник Александра Думаса, написавшего, к примеру, Граф Монте-Кристо =)

Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права