На блоге Gartner появилась заметка Janelle Hill “Do You Understand the Difference Between Workflow and BPM?“. Как замечено в комментариях, это хороший ответ тем, кто считает, что “BPM - это Workflow на стероидах”.

По мнению Gartner, идеальная BPMS реализует 10 технологий, из которых Workflow - всего лишь одна:

1. Процессный движок (Process Execution and State Management Engine) - компонента, реализующая Workflow.
2. Среда разработки, основанная на графических моделях (Model-Driven Development Environment). Но в workflow-системах тоже обычно есть графические средства моделирования. Менее мощные (обычно только оркестровка без хореографии), не следующие стандартам (BPMN), но есть. Получается не 1/10, а 2/10.
3. Управление документами и контентом (Document and Content Management). Спорно. На мой взгляд, есть структурированные данные, есть неструктурированный контент и есть процессы, и для управления ими придуманы, соответственно, DBMS, ECM и BPMS. Без необходимости границы лучше соблюдать, ничего не следует  делать “заодно” - ни управлять контентом в BPMS, ни управлять процессами в ECM. Мы же не включаем в BPMS управление данными, не дублируем DBMS - почему с контентом должно быть по-другому? 2/9.
4. Средства совместной работы пользователей и групп (User and Group Collaboration). Да, конечно, но рассматривать это как часть BPMS? А что, совместной работы вне процессов не бывает? Конечно бывает, например, в проектах. Получается, для процессов свои средства совместной работы, а для проектов - свои? Абсурд. 2/8.
5. Средства интеграции (System Connectivity). Действительно, в BPMS работа, выполняемая людьми, работа с документами и действия, выполняемые автоматизированными системами, трактуются единообразно, без перекоса в сторону первых (что характерно для систем human workflow) или вторых (системы docflow). Кстати, пункты 3 и 4 я бы поместил сюда - в виде средств интеграции с системами управления контентом и средствами совместной работы.
6. Бизнес-события, бизнес-аналитика и мониторинг (Business Events, BI and BAM). Строго говоря, к BPMS относится только последнее, а первые два могут использоваться независимо.
7. Имитационное моделирование и оптимизация (Inline  and Offline Simulation and Optimization). Похоже, только Gartner знает, что они имеют в виду под “inline and offline”, но по существу возражений нет.
8. Машина бизнес-правил (Business Rules Engine). В теории она может использоваться как единое хранилище глобальных переменных любой (лучше каждой) корпоративной системой. Но на практике в основном используется BPMS.
9. Средства управления и системное администрирование (System Management and Administration). В том или ином виде это есть в любой системе: 3/8.
10. Каталог-репозиторий процессных компонент (Process Component Registry/Repository). С одной стороны, в Workflow-системе тоже можно найти каталог процессов в том или ином виде. С другой стороны, репозиторий процессов в рамках BPMS, в отрыве от репозитория сервисов SOA, тоже не лучшая идея. 4/8.

Итоговый счет у меня получился не столь разгромный - 4:8, а не 1:10. Но сама идея подсчета очков порочна: на чашу весов BPM есть что положить кроме технологий. Прежде чем сравнивать BPMS с Workflow, надо сказать, что BPM != BPMS. BPM - это:

1. Методология: иерархия целей организации, цепочка создания ценностей, сквозные бизнес-процессы, выявление процессов, цикл непрерывного усовершенствования.
2. Реализация: программа, понимаемая как серия проектов; гибкая разработка (agile).
3. Технология (BPMS).

Если нет компетенции в методологии или реализации, проект BPM обречен даже с самой лучшей BPMS.

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

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

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

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

И поскольку Workflow - это только технология, то с ним им гораздо комфортнее, чем с непонятным, разрекламированным и переусложненным (с их точки зрения) BPM.

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

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

Возвращаясь к технологиям, я бы не сказал, что BPMS кладет Workflow на лопатки. Но это ему и не нужно, потому что тут есть еще один важный аспект: BPMS - это следующее поколение технологий. XML и Интернет, тонкий клиент, современные стандартные платформы (J2EE или .NET), стандартные нотации (BPMN, BPEL) вместо проприетарных. В быстро меняющемся мире ИТ даже относительно небольшое технологическое отставание фатально: если основная масса разработчиков начинает воспринимать какое-то направление как устаревшее, то оно достаточно быстро маргинализируется просто потому, что никто добровольно с ним работать не хочет. Поэтому нравятся вам Workflow-системы или нет - останутся жить только те из них, которые смогут влиться в мейнстрим: перейти на современную платформу, сменить нотацию, добавить недостающие функции из списка Gartner, т.е. превратиться в BPMS.

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

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

В цеху тоже есть процессы - производственные. Но у них несколько иная проблематика, иные методы и технологии: станки с ЧПУ, поточные линии, АСУТП… Зато здесь нет проблем кросс-функциональных процессов - ведь это одна служба. Тут требуется не BPM, а производственная автоматика и робототехника.

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

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

Поскольку одной автоматизированной системой обойтись не получается, и к тому же необходимо взаимодействовать с системами других банков, в банковском “цеху” появляются процессы, понимаемые как координация действий, выполняемых в различных системах. Человек в них или вовсе не участвует (STP - straight-through processing), или только разбирается с относительно редкими исключительными ситуациями.

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

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

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

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

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

Поэтому вникайте, разбирайтесь - что представляет собой конкретное внедрение конкретного вендора, есть ли в нем BPM или только BPMS.

Налицо путаница в классификации программных средств, используемых для управления бизнес-процессами:

• Инструментарий Enterprise Architecture (EA) предназначен для моделирования следующих аспектов корпоративной архитектуры:
  1. бизнес-архитектура - бизнес-цели, организационная структура, функции, процессы, роли и т.д.
  2. архитектура приложений - корпоративные системы и их интерфейсы
  3. архитектура данных - логическая и физическая
  4. технологическая инфраструктура - программно-аппаратное обеспечение и сети
• Инструментарий Business Process Analysis (BPA) в части моделирования является подмножеством EA, покрывая полностью или частично бизнес-архитектуру. Но, помимо моделирования, может содержать специализированные средства, например, имитационное моделирование бизнес-процессов или статистический анализ результатов исполнения.
• Business Process Management Suite (BPMS) в обязательном порядке включает моделирование бизнес-процессов, их исполнение (process engine, процессный “движок”) и мониторинг/анализ. Опционально может включать имитационное моделирование, движок бизнес-правил и многое другое.
• Некоторые вендоры используют для своих продуктов определение “BPM Software”. Обычно это означает, что система не дотягивает до BPMS - например, в ней нет исполняемого движка - но маркетинг хочет видеть в названии BPM.

Апологеты BPMS (я в том числе) верят в силу исполняемых бизнес-процессов, в принцип “what you model is what you run”. Соответственно, наличие процессного движка для них - необходимость, и EA инструментарием они обойтись не могут.

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

Как быть? Может это временные трудности, и через некоторое время либо BPMS дорастут до EA, либо EA включат функциональность BPMS?

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

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

1. изобразили BPMN-диаграмму средствами EA
2. дальше возможны два варианта:
   • если BPMS непосредственно исполняет BPMN, выполнили экспорт-импорт через XPDL
   • если BPMS поддерживает BPEL, выполнили трансляцию BPMN->BPEL

Например, нарисовали в ARIS - экспортировали в WebMethods. Или нарисовали в Casewise - транслировали в Oracle BPEL.

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

Что это означает на практике? После того, как схему процесса загрузили в BPMS, разработчик должен внести в нее правки и уточнения, необходимые для исполнения процесса движком. Но исходная схема процесса в EA тоже не остается неизменной - аналитик продолжает ее совершенствовать, ведь за это, собственно, мы и боролись! (Подробно эта проблематика рассмотрена в серии заметок на блоге Keith Swenson, начинающейся с “Model Strategy: Preserving vs. Transforming“. Русский перевод на bpms.ru.)

Таким образом, надо либо уметь передавать подробности физической реализации процесса в BPMS назад в EA и находить для них место в репозитарии (т.н. проблема “round-trip”), либо уметь объединять изменения, выполняемые в одной и в другой схемах (по образцу branch merging в системах контроля версий). Теоретически задача может быть и разрешима, но по факту за много лет решить ее не удалось. Будем ждать?

Предлагаю принять за аксиому, что:

1. водораздел между EA и BPMS есть и останется в обозримом будущем
2. удовлетворительной автоматической передачи артефактов между ними нет и в обозримом будущем не будет

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

Предложение: проводить его на уровне процесса -

• цепочка создания ценностей (value chain) и межпроцессное взаимодействие через события и/или данные моделируются средствами EA
• внутренняя логика процесса моделируется средствами BPMS

Тогда передавать из EA в BPMS придется только номенклатуру и интерфейсы процессов, а для этого автоматический экспорт-импорт не нужен, можно обойтись экспортом-импортом “через принтер”.

Бизнес-аналитик должен провести для себя красную черту: не использовать EA для моделирования бизнес-процесса при наличии BPMS.

Впрочем, для средств моделирования BPMN в EA тоже есть применение. Современные BPMS нацелены на моделирование внутренней логики процессов (оркестровка) и плохо подходят для моделирования межпроцессного взаимодействия (процессная хореография). Но одной оркестровкой можно решать только задачи уровня “автоматизации канцелярии”; как только вы поднимаетесь на уровень сквозных бизнес-процессов - т.е. процессов, за которыми стоят реальные деньги - вам не обойтись без хореографии. (См. на эту тему анти-паттерн “Оркестровка сквозного процесса”.)

Моделировать межпроцессное взаимодействие предлагается средствами EA, используя для этого т.н. “black box BPMN diagram” - технику моделирования, в которой каждый процесс отображается как пустой BPMN pool. Взаимодействие через сообщения моделируется при помощи message flow, взаимодействие через данные - при помощи association.

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

Для каждого процесса на диаграмме вверху средствами BPMS создается BPMN-диаграмма, раскрывающая внутреннюю логику процесса:

BPMS.ru планирует провести два семинара подряд:

1. В этот четверг 25.03.10 Игорь Федоров поделится опытом команды BPEXPERT в проектировании исполняемых бизнес-процессов. Регистрируемся.
2. В следующий четверг 01.04.10 к нам собирается Александр Самарин - наш человек в Швейцарии, автор книги “Improving enterprise business process management systems”.

График конечно получается напряженный, но я настоятельно советую посетить оба мероприятия, не пожалеете.

Пример:

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

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

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

В BPMN специально для такой ситуации предусмотрена конструкция под названием “исключающая развилка, управляемая событиями” (exclusive event gateway):

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

К большому сожалению, поставщики BPMS склонны относиться к event gateway как к излишеству. Мне известно несколько систем, разработчики которых декларируют приверженность BPMN, но не поддерживают эту конструкцию.

Боюсь, это ошибка с их стороны - ведь задача обработки альтернативных сообщений никуда не денется! В отсутствие event gatway единственный путь - использовать параллельную развилку (parallel gateway). Но тут возникает проблема “гашения” остальных путей при приходе одного из сообщений, которую приходится решать при помощи искусственных конструкций в диаграмме и/или написания программного кода. Конечно, ни о визуальной наглядности процесса, ни о следовании стандарту речь при этом уже не идет.

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

Пока конкретная BPMS не поддерживает event gateway, нормально работать с сообщениями (message flow) в ней невозможно. Оркестровка в ней поддерживается, хореография - нет. На мой взгляд, такая система - это старый добрый workflow вне зависимости от наличия на нем лэйбла BPMN.

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

Качество докладов было на высоте. Особенно мне понравились:

• Роман Ткачев (операционный директор БиАй Телеком, партнера Lombardi в России) рассказал про проекты в банке ВТБ-24 и в ритейловой компании. Отличный программный продукт, грамотный консалтер - мы вправе были рассчитывать на интересный доклад, и мы его получили. В кулуарах задал Роману пару ключевых вопросов. Во-первых, заплатили ли клиенты деньги за лицензию? Ответ - да. Вопрос, на мой взгляд, важный, так как проводит грань между инициативным пилотом, выполняемым поставщиком за свой счет и фактически без обязательств со стороны клиента, и следующей ступенью - продуктивным пилотом, выполняемым за деньги клиента и в условиях, когда клиент уже четко осознал, что ему это нужно. Второй вопрос - на каком уровне поддерживались проекты, конкретно - кто выступал в роли спонсора. Ответ - в ВТБ-24 проект поддерживался на уровне председателя правления банка. Это еще один ключик, позволяющий отличить “игрушечный” проект с сомнительными перспективами от реального. В общем, я рад за коллег из BI Telecom. Роман согласился, что ему стоило бы акцентировать эти моменты в презентации - что ж, так бывает, что самое интересное для аудитории для докладчика оказывается само собой разумеющимся.
• Алексей Будин (директор компании “Элевайз”, отечественного разработчика BPM-системы ELMA) живо и убедительно представил два взгляда на BPMS: со стороны заказчика и со стороны поставщика. Судя по презентации, система выглядит достаточно симпатично. А наличие интеграции с 1С (подтвержденной сертификатом “1С-совместимо”) является серьезным конкурентным преимуществом на отечественном рынке. Ведь поставщики импортных BPMS об интеграции с 1С не беспокоятся, а для среднего бизнеса в России 1С - практически стандарт. Поскольку мы тоже ориентируемся в основном на средний бизнес, сделал для себя вывод, что стоит познакомиться с этой системой поближе.
• Алексей Бойко (руководитель методического центра по проектированию бизнес-процессов КЭС-Холдинг) поделился опытом внедрения процессного управления в крупном энергетическом холдинге. Выдающееся достижение - то, что удалось заразить этой идеей высшее руководство. Причем видно, что для них это не увлечение, а систематическая работа по организации бизнеса сверху-вниз на принципах BPM. Для каждого бизнес-процесса верхнего уровня назначен владелец на уровне вице-президента, и в соответствии с утвержденным положением, владелец процесса отвечает в том числе за дизайн процесса. Наличие владельца процесса - это отличный критерий чтобы определить, является ли процессное управление для компании преходящим увлечением и поводом поговорить или же образом жизни. Алексей отдельно остановился на том, как повлиял на их планы кризис: они отказались от “ковровых бомбометаний” и перешли работе адресной, малыми силами, в сжатые сроки. Похоже, они сами не поняли как им повезло: кризис случился в самый подходящий для них момент, буквально заставив их начать работать так, как собственно и рекомендуется теоретиками BPM. Если бы не кризис, они бы наверное продолжали действовать в духе старого доброго реинжиниринга, и мы бы имели шанс услышать доклад из серии “как мы дошли до документирования четвертого уровня бизнес-процессов и поняли, что до шестого мы не дойдем никогда”. А так благодаря кризису получился такой “Lean поневоле”. С другой стороны, систематически пройти два уровня процессов сверху-вниз безусловно полезно. Из доклада осталось не до конца понятно как они расставляют приоритеты процессам - похоже, интуитивно-волевым способом. Если так, то им стоило бы подойти к этому более систематически - попробовать применить TOC, на основе экспертных оценок определить потенциал улучшения процессов. Да, и до использования BPMS (а следовательно, до детального моделирования и поддержки исполнения процессов в реальном времени) они еще не дошли. А я все-таки не очень верю в BPM без BPMS. Это как бухгалтерия без компьютера - теоретически возможно, в рамках обучения полезно, но в практической работе смысла не имеет.
• Самым солидным мне показался доклад Александра Башкова (менеджер бизнес-приложений компаний “Тетра Пак”). До этого я про компанию не знал ничего, кроме названия, теперь знаю - это один из лидеров в управлении бизнес-процессов в мировом масштабе. Александр очень хорошо рассказал как организовано процессное управление на уровне глобальной компании, и что особенно интересно, про кастомизацию на региональном уровне. Известно, что компании, достигшие выдающихся достижении в области управления бизнес-процессами, зачастую добровольно делятся своим опытом - я слышал такие истории про Toyota, Xerox, Motorolla. Поэтому я задал вопрос Александра после его доклада, и он подтвердил, что действительно, в их компании такое тоже практикуется. Так что если ваша компания вынашивает амбициозные планы в области BPM, я настоятельно советую попробовать обратиться к Тетра Пак за опытом. И пожалуйста напишите здесь в комментариях, что из этого вышло.

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

Аудитория производила впечатление подготовленной - и вопросы, и кулуарные разговоры были содержательными. Диссонировали, на мой взгляд, только вопросы представителя Академии при госслужбы при Президенте РФ: как-то странно на конференции по BPM спрашивать у докладчика чем BPMS отличается от Sharepoint.

Большой упрек организаторам - заявленная дискуссия фактически не состоялась. Даже те куцые 15 минут, которые были отведены в конце регламента, не были использованы. Складывается впечатление, что организаторам это просто не нужно. Вступительный доклад сделали? сделали. Спонсорам за их деньги выступить дали? дали. А дискуссия - какой от нее прок? Только аудиторию занимать, а ее аренда денег стоит. Неправильная, близорукая позиция. Причем, это становится тенденцией - конференции не только CNews, но остальные все больше становятся похожими не на конференции, а на шоу.

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

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

Пример 1: процесс заключения договора. Ближе к завершению процесса договор должен быть подписан с нашей стороны директором:

Хотя бы из уважения к директору дайте ему возможность не подписать договор - предусмотрите развилку (gateway) сразу за шагом “подписать договор”.

Пример 2: в процессе выполнения заказа клиента компания-посредник размещает заказ у партнера:

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

Тут возникает вопрос меры: с одной стороны, никто не отменял рекомендацию начать моделирование процесса с т.н. “happy path” - максимального гладкого варианта протекания процесса. И в happy path приведенные диаграммы вполне уместны.

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

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

BPM осваивает новую территорию, которую называют по-разному: dynamic processes, unstructured processes, knowledge worker processes, barely repeatable processes, case management. (На русский не перевожу - так как термины относительно новые, перевод только запутает дело.)

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

Но только “особо одаренные” считают, что жестко структурировать можно любой процесс:

Оставляя в стороне крайности - полностью структурированные и полностью ситуативные (ad-hoc) процессы - получаем два варианта сочетания тех и других. Либо структурированный процесс обращается к ситуативному, либо наоборот:

1. Паттерн “помощь зала”: структурированный процесс обращается к ситуативному подпроцессу. Пример: процесс “от обращения до заказа” в компании - системном интеграторе. Менеджер по продажам встречается с потенциальным заказчиком и предположим, встреча прошла удачно: удалось нащупать одну или несколько “болевых точек” клиента - проблем, за решение которых он в принципе готов заплатить. Следующий шаг процесса - поиск такого решения. Однако проблемы клиента могут лежать в очень широком диапазоне (заметим, что ценность интегратора как раз и заключается в том, что он способен решать широкий круг задач). Начиная от простейшей ситуации, когда нужен коробочный софт, и заканчивая сложными, комплексными проектами. В последнем случае процесс пойдет по извилистой, заранее неизвестной траектории, которая может вовлекать архитектора, разработчика, менеджера по продажам, системного инженера, техподдержку вендора и т.д. Средствами традиционной BPMS можно разве что назначить задачу одному ответственному исполнителю, а с остальными пусть он разбирается сам (см. пост “Процессный антипаттерн: Театр одного актера“). Решение не самое лучшее, так как неизвестно кто занимается проблемой в данный момент, что уже сделано и когда можно рассчитывать получить решение.
2. Обратная ситуация, паттерн “набор процессных инструментов”: на верхнем уровне процесс протекает  непредсказуемо, но на нижнем он сводится к набору достаточно хорошо формализуемых подпроцессов-инструментов. Пример: адвокатская контора. Процесс верхнего уровня - дело клиента. В какую сторону повернется дело предсказать абсолютно невозможно - например, в любой момент в нем может появиться новый документ, представленный противной стороной, который кардинально поменяет и ход дела, и наши планы действий. Но в то же время, в рамках дела ведущий его адвокат инициирует те или иные действия, которые большей частью стандартны, могут быть типизированы и формализованы в виде подпроцессов. В основном это подготовка исковых заявлений и других документов. Такие подпроцессы выполняются соответствующими специалистами, не привязанных к определенному делу в отличие от адвоката, который его ведет, а являющимися разделяемым ресурсом. С точки зрения компании интересно контролировать показатели эффективности на уровне не только дела в целом, но также подпроцессов и использования ресурсов.

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

• На конференции Гартнер BPM’2009 была озвучена следующая оценка: до 60% процессов в организации являются неструктурированными и как следствие, неконтролируемыми, неуправляемыми, невидимыми и не регулируемыми правилами. Эти 60% похожи на среднюю температуру по больнице, но “невидимость” этих процессов действительно может быть основной проблемой с точки зрения бизнеса.
• “Обращение к коллективному знанию будет двигать вперед неструктурированные процессы” - Джим Синур (Гартнер) предсказывает, что задействование технологий накопления знаний, отраслевых и социальных сетей приведет к новой волне фундаментальных изменений в BPM и BPMS. Еще один его пост на эту же тему: “Белые воротнички и неструктурированные процессы подходят друг к другу как сыр к вину“.
• То, как стремительно приобрели популярность социальные сети (те же “одноклассники”), подталкивает к мысли позаимствовать наработанные в них подходы для организации общения в рамках динамических процессов - см. доклад о спектре возможных применений social software в BPM на BPM-конференции в Ульме. Скажем, сталкиваясь с проблемой, я публикую вопрос в корпоративной сети (”помощь зала”). Его видят мои “френды” (в числе которых менеджер проекта и тим-лид). Автор лучшего ответа получает бонус.
• SAP предлагает использовать для совместной работы технологию Google Wave - но не для исполнения процесса, а для его проектирования. SAP Gravity представляет собой реализацию BPMN-редактора в среде Google Wave. Что касается исполнения, то надо понимать, что возможность проектирования процесса “на лету”, в ходе его исполнения, является важным аспектом динамичности, поэтому SAP создает задел не только для выявления, но и для исполнения динамических процессов.
• Oracle тоже говорит о collaborative BPM и dynamic BPM и при этом подчеркивает свою приверженность архитектуре SCA, позволяющей комбинировать различные процессные составляющие с бизнес-правилами, аналитикой и т.д. Что ж, учитывая, что за два года Oracle приобрел 50 компаний, продукты которых необходимо интегрировать, для них это особенно актуально.
• HandySoft, ActionBase и другие вендоры заявляют о поддержке динамических процессов в последних версиях своих продуктов.
• Самые авторитетные специалисты отрасли собираются, чтобы обсудить проблемы динамических процессов и в частности, их поддержку в BPMN.

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

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

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

1. Пользовательский портал - веб-интерфейс, позволяющий запускать процессы, работать со списком  назначенных пользователю заданий, отображать формы, соответствующие этим заданиям, а также контролировать и администрировать процессы. В промышленной системе он будет отличаться, как минимум, по внешнему виду, а скорее всего, и по функциональности. Если повезет, вам удастся обойтись кастомизацией “коробочного” портала, но будьте готовы к тому, что на каком-то этапе вам придется переписать его “с нуля”. Или, как вариант, вообще уйти от отдельно стоящего портала BPM, а тесно интегрировать процессную функциональность с корпоративной системой. Причина - пользователи обычно не готовы согласиться с мнением BPM-поставщика или интегратора, что BPMS должна быть центром его, пользователя, вселенной.
2. В частности, на каком-то этапе в вашей системе должна исчезнуть кнопка “запустить процесс”. С точки зрения пользователя, он не “запускает процессы”, а занимается конкретным делом: например, принимает поступивший заказ или составляет заявление на отпуск. Стартовать соответствующие процессы система должна автоматически.
3. Будьте готовы к тому, что на каком-то этапе экранные формы к шагам процессов, которые можно сгенерировать средствами BPMS в несколько кликов мыши, перестанут удовлетворять с точки зрения функциональности, юзабилити и дизайна. В связи с этим полезно с самого начала представлять себе, как вы будете разрабатывать эти формы: в какой среде, какими инструментами, силами каких программистов, с какими трудозатратами. Важность этого пункта трудно переоценить: например, что толку от того, что схема процесса рисуется за два дня, если (условно) разработка экранных форм к нему потом займет два месяца? (При этом я нисколько не преуменьшаю важность средств быстрого прототипирования экранных интерфейсов - в контексте BPM они абсолютно необходимы и без них ни до какой промышленной системы дело вообще не дойдет.) Кстати, скорее всего вы захотите воспользоваться этим же инструментарием и для переписывания портала.
4. Аналогично, на определенном этапе вам перестанет хватать штатных отчетов и средств мониторинга.
5. Демо- и пилотные версии процессов обычно хранят все необходимые данные в атрибутах процесса, процессных переменных или операндах (разные системы используют разную терминологию). В промышленной системе в таком виде хранятся только относительно малозначащие данные, представляющие интерес только в момент исполнения процесса. Большая же часть данных уходит в традиционную базу данных, а в контексте процесса хранится только первичный ключ соответствующей записи. Например, в процессе согласования клиентского заказа на покупку информация о клиенте и о позициях заказа скорее всего будет хранится в базе данных, а идентификаторы клиента и заказа и дата контрольного звонка клиенту по поводу заказа останутся в атрибутах процесса. Причина, по которой необходимо действовать именно так, очевидна: данные, представляющие интерес после завершения экземпляра процесса, должны храниться так, чтобы до них можно было добраться независимо от экземпляра процесса. Это, кстати, означает не только отдельное хранение, но и отдельные, не связанные с процессной функциональностью, экранные формы для доступа к этим данным. Соответственно экранные формы к шагам процессов должны будут работать “на два фронта”: и с атрибутами экземпляра процесса через API движка BPMS, и с полями базы данных через API СУБД.
6. Развивая предыдущий пункт, скорее всего для части долгосрочной информации (но обычно не для всей) уже есть место в какой-то из имеющихся у вас корпоративных систем. Соответственно, в атрибутах процесса будут храниться идентификаторы соответствующих бизнес-объектов, а формы к шагам бизнес-процессов должны будут уметь обращаться еще и к корпоративным системам. (Впрочем, последнее не является абсолютом - зачастую это оказывается очень трудоемким делом, что оправдывает компромисс в виде лишь частичной интеграции с корпоративными системами.)
7. Аналогично, если в демо- или пилотной версии процесса связанные с ним документы (обычно файлы Word или Excel) хранятся в виде приложений к экземпляру процесса, то в какой-то момент вам придется подумать о чем-то более солидном. Причина та же самая: если документ представляет интерес после завершения экземпляра процесса, значит, храниться он должен независимо от экземпляров процесса и доступ к нему должен предоставляться также независимо от процессной функциональности. Некоторым облегчением является то, что вам не нужна для этого тяжеловесная система документооборота - ведь задачу собственно документооборота вы уже решили при помощи BPM, вам нужно только хранение документов с соответствующими интерфейсами (пользовательским и программным) и сервисом (поиск, архивация, разграничение доступа).
8. В демо- или пилотной версии аутентификация и авторизация пользователей обычно делается через собственный, независимый каталог LDAP, базу данных или вообще статический список пользователей, хранящийся в XML-файле где-то на сервере. Понятно, что промышленная система должна работать с уже имеющимся у вас каталогом пользователей. Но неприятным сюрпризом зачастую оказывается то, как много усилий это требует. Начать с того, что таких каталогов зачастую оказывается несколько. Типичный пример: есть Active Directory, есть собственная система авторизации в унаследованной бухгалтерской системе и есть информация о пользователях удаленных подразделений и пользователях компаний-партнеров, которая хранится в базе данных. По мере развития проекта могут возникать дополнительные требования: учет планового отсутствия сотрудников, замещение обязанностей на время отсутствия, автоматическое перенаправление заданий и т.д. Известно, что для компании, в которой число пользователей превышает сотню, внедрение только Active Directory представляет собой нетривиальный проект, а тут мы сталкиваемся явно с более сложной задачей. В результате в проектах BPM трудоемкость, приходящаяся на решение вопросов авторизации и аутентификации, в некоторых проектах достигает 50%. Представьте себе на минуточку, что это произошло именно в вашем проекте, причем при планировании проекта вы эти сложности недооценили: в результате до 100% превышения сроков и бюджета!
9. Для демонстрации и для пилотного проекта обычно выбирают не самый сложный бизнес-процесс. Это бы ладно - хуже то, что и технически реализуют один бизнес-процесс. Но в реальности даже процесс приема на работу технически реализуется как несколько взаимодействующих друг с другом процессов (достаточно заметить, что рассмотрение присланных резюме не связано напрямую с публикацией вакансии). Тем более это справедливо по отношению к сквозным процессам, представляющим наибольший интерес с точки зрения бизнеса (см. анти-паттерн “Оркестровка сквозного процесса” и паттерн “Внутренний заказ”). Соответственно, вам довольно скоро придется расширить объем используемой функциональности вашей BPM-системы - освоить не только оркестровку, но и хореографию. Современные BPM-системы с этим нормально справляются, но для системы класса workflow или документооборота, встроенного в вашу учетную или бухгалтерскую систему, это может стать камнем преткновения.
10. Ну и наконец, промышленная система отличается от пилотной уровнем надежности, производительности, защищенности … но это стандартные требования, ничего относящегося именно к BPM в них нет.

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

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

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

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

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