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

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

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

Семинар получился оживленным - интересными были и сам доклад, и последующие выступления - и нестандартным по тематике. Если обычно на семинаре мы разбираем опыт конкретных проектов 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 приведенные диаграммы вполне уместны.

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

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