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

• Инструментарий 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 и, в частности, процессные диаграммы занимают свое законное место.

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

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

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

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

По регламенту. Если время вышло, а докладчик закругляться не собирается, то председатель должен прервать его словами: “отведенное регламентом время закончилось, сколько еще вам надо?” и, получив ответ, обратиться уже к аудитории: “ну как, дадим?”. Это способствует атмосфере взаимного уважения.

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

Закрытость корпоративных систем ставит перед тяжелым выбором: либо использовать встроенные в них средства workflow и бороться с их ограничениями, либо использовать внешние BPMS и бороться с проблемами интеграции. Компания Руна сделала выбор оригинально: взяла на вооружение и то, и другое. В принципе, наверное, это правильно. Было бы совсем здорово, если бы они навели мосты между внешней и внутренней BPMS. Может быть, это сделать проще, чем интегрировать внешнюю BPMS на уровне функций?

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

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

Осталось у меня и несколько вопросов по докладу:

1. Использование Runa WFE с jBPM и вообще технологическим стеком jBOSS. Особенно с учетом того, что выходит 4-я версия jBPM, которая мне представляется весьма интересной. В частности, в ней jBPM переходит к нотации, близкой к BPMN.
2. Привязка к бумажным документам. Непонятно почему нельзя обойтись без них, непонятно даже - рассматривалась ли вообще безбумажная альтернатива. Вместо того, чтобы гонять в процессе бумажные документы, можно было собирать структурированную информацию, передавать электронные задания, а бумаги печатать на основе собранных данных только там, где это абсолютно необходимо (например, командировочное удостоверение, с которым сотрудник поедет  в чужую организацию). Но зачем в виде документов нужны заявление на отпуск или авансовый отчет - я не понимаю. Вроде мы рассматривали не колхоз “сорок лет без урожая”, а прогрессивную организацию! Естественно, в результате возникла масса проблем - ну не рассчитаны BPMS на такую работу.
3. Докладчик упомянул, что в какой-то момент возникли проблемы с масштабированием, которые были успешно решены. Хотелось бы получить подробности, но понятно, что все рассказывать в подробностях - никакого регламента не хватит.

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

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

Этот контент доступен на языках: English.