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

А возник он потому, что я не в первый встречаю компанию-заказчика или потенциального заказчика, во главе которой стоит молодой, амбициозный, энергичный и - что самое главное - грамотный руководитель. Казалось бы, здорово! Действительно радует, что не приходится тратить время на рассказ о том, что такое бизнес-процессы и BPM - человек уже подготовлен, в том числе благодаря нашему bpms.ru.

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

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

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

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

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

Семинар получился оживленным - интересными были и сам доклад, и последующие выступления - и нестандартным по тематике. Если обычно на семинаре мы разбираем опыт конкретных проектов BPM, то в этот раз была доложена концепция, существующая пока только в теории. Доклад планируется опубликовать на bpms.ru. По существу доложенного, абсолютно правомерной мне представляется постановка задачи. Действительно, существуют проблемы 1) совмещения в организации элементов функционального и процессного управления (а вообще-то еще и проектного, для полноты картины) и 2) отторжения творческими личностями сильно формализованных процессов, в которых они чувствуют себя “винтиками”. Но предложенное решение, на мой взгляд, откровенно утопично. Сервисно-ориентированное управление вполне имеет право на жизнь, но в несколько ином виде - более авторитарном, чем было предложено автором. Попытался в своем выступлении вкратце изложить, как такая схема могла бы выглядеть, но боюсь получилось скомкано; эта тема заслуживает отдельного рассмотрения.

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

Больше всего меня конечно интересовало, будет ли стол на самом деле круглым - увы, обманули, он оказался П-образным Кофе на брейках был хорош, плохо только, что его не давали во время регистрации (наезд не по делу, см. комментарий 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 приведенные диаграммы вполне уместны.

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

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

3 ноября выступаю на конференции CNews “Перспективы BPM в России”.

Помните старый анекдот про Эйнштейна? Перед экзаменом ассистент у него спрашивает: “Как же так, профессор, у вас экзаменационные вопросы те же, что и в прошлом году? - Спокойно, все в порядке. Вопросы те же, но ответы в этом году другие!”. Да, было время в физике… Так вот, на подобных конференциях обычно бывает наоборот: вопросы разные, а ответы большей частью одни и те же - независимо от подзаголовка конференции доклады на 3/4 представляют собой презентации продуктов.

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

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

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

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

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

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-вендоров больше, чем требуется рынку. И тут появляется новый фронт для соперничества: динамические процессы. Фронт очень обширный, если рассматривать все аспекты динамичности, так что прикрыть его нелегко, и боюсь, в текущей экономической ситуации под силу это будет не всем. Зато те, кто в итоге смогут предложить всестороннюю поддержку динамических процессов, получат в глазах пользователей отчетливо видимое преимущество.

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

Бизнесмен: мы принимаем решения на основе предварительной оценки окупаемости или возврата на инвестиции (ROI).

Шахматист: конечно надо считать когда и сколько материала - пешек, фигур - ты выиграешь в результате того или иного хода. Мы тоже считаем комбинации. Только у нас партия состоит не из одних комбинаций. Бывают ходы вынужденные, когда думаешь не о том, чтобы побольше съесть чужих пешек и фигур, а о том, чтобы не съели твои. Бывают ходы, улучшающие позицию. Бывает, что жертвуют материалом, чтобы улучшить позицию  - “получить игру”. Ведь если позицию не развивать, то просто не будет возможности развернуть атакующую комбинацию и ни до какого ROI дело вообще не дойдет.

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

Бизнесмен: у нас тоже есть стратегия компании.

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

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

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

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

Бизнесмен: так, кажется я начинаю понимать что это за business agility, о которой в последнее время столько разговоров…

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

Кирилл Курышев рассказал о бизнес-процессе “Управление заявкой на предоставление услуги связи”, которым команда bpexpert занималась в одной крупной телекоммуникационной компании.

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

Почему я назвал доложенный проект образцовым: в нем все делалось как положено -

1. Отсутствие четко сформулированных требований на входе проекта. В настоящих проектах BPM по-другому не бывает. Начиная, ты никогда не знаешь какой процесс у тебя получится в результате. Выявление процесса (process discovery) в ходе проекта, пять итераций схемы процесса от старта проекта до запуска процесса в эксплуатацию - это классика.
2. Разработка в стиле agile: короткими циклами, с постоянной обратной связью с заказчиком. Говорим BPM - подразумеваем agile!
3. Добротный инструмент Oracle BPM Studio (aka BEA AquaLogic BPM). Бывает так, что основное содержание проекта - борьба с инструментом. Но не в данном случае. Докладчик отметил: были моменты, когда у них возникали затруднения с реализацией в Oracle требований заказчика. В этих случаях они поступали очень правильно: не насиловали инструмент, а пытались работать в том стиле, который он предлагает. В частности, им удалось обойтись “малой кровью” в решении задач, связанных с авторизацией, ролями, делегированием, замещением и т.п. (п.8 моей недавней заметки). Удалось заинтересовать заказчика возможностями имитационного моделирования (simulation), действительно неплохими в Oracle.
4. Удалось принести пользу “заказчику заказчика”, т.е. клиентам компании: среднее время обработки заказа уменьшилось с 5 до 3 дней. В рамках пилотного, по сути, проекта, этого добиться удается не часто.
5. Использование eTOM не как инструкции - “делай раз - делай два”, а как справочника. Т.е. живешь, все-таки своим умом, но время от времени сверяешься с образцом. Такая сверка позволяет существенно повысить ценность решения при незначительном расширении проекта, что и было наглядно нам продемонстрировано.
6. Стремление сделать протекание процесса если не полностью автоматическим (т.е. довести его до STP, straight-through process), то максимально гладким. Похоже, проектная команда интуитивно нашла известный, в общем-то, магистральный путь: направлять человеку только те задания, которые не удалось обработать автоматически. Т.е. использовать человека в качестве “обработчика бизнес-исключений”.
7. И главное: всего за 20 рабочих и 30 человеко-дней им удалось запустить процесс в промышленную эксплуатацию. Скептики посрамлены!
8. Причем есть одна пикантная подробность: на самом деле это была вторая попытка компании-заказчика чего-то добиться при помощи BPM. Причем в первой попытке BPM-система была та же самая, только исполнитель другой. Как я и говорил однажды на конференции: прежде чем критиковать BPM, убедитесь сначала, что то, что вы делаете - это действительно BPM. По-видимому, первая попытка как раз и не была попыткой BPM. И тем ценнее результат команды bpexpert, ведь добиться успеха после фальстарта вдвойне труднее.
9. И последнее - то, что стало предметом оживленной дискуссии после доклада: удалось не только успешно выполнить проект, доведя его до промышленной эксплуатации; по утверждению докладчика, им удалось передать заказчику и компетенцию, и интерес к тому, чтобы продолжать работать над процессом все в большей и большей мере самостоятельно. Этим могут похвастаться очень немногие проекты, а ведь без этого, положа руку на сердце, тоже нельзя говорить о BPM в полном смысле слова.

Должен признаться, у меня даже не получается как положено выдать порцию критики (хотя обычно с этим проблем нет). Ну разве что по мелочи:

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

Скачивая пробную версию или демо-ролик 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 (а любой вендор может предоставить десятки референсов), в итоге с этими проблемами справились. Однако представлять себе что ждет “за поворотом”, после успешного выполнения пилота, полезно, и стоит заранее задать соответствующие вопросы и себе самому, и своему поставщику.