Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Записи с ключевым словом ‘workflow’

Вульгарное представление о кросс-функциональных бизнес-процессах

Напомню, что кросс-функциональным называется процесс, в котором участвуют несколько подразделений верхнего уровня (по-английски «функций» – отсюда название). С точки зрения процессной методологии, именно на такие процессы в конечном счете должны нацеливаться инициативы BPM, поскольку именно здесь обычно кроются самые большие проблемы, а следовательно, наличествует самый большой потенциал улучшения. Ведь любая иерархическая организация, достигая определенного размера, сталкивается с тем, что собственные интересы подразделений начинают преобладать над интересами компании в целом.

Собственно, это не новая идея: «сломать стены между подразделениями» – это призыв еще реинжиниринга образца начала 90-х. Другое дело, что предложенный классическим реинжинирингом подход к реализации через однократное радикальное преобразование оказался не вполне удачным. Современный BPM принес новые взгляды на то, как это надо делать, но цель осталась та же самая.

Для иллюстрации кросс-функциональных проблем часто используют метафору силосной башни –«functional silo». Аналогия тут следующая: после того, как крестьянин заложил скошенное сено в силосную башню, добраться он может только до небольшой части этого богатства – до верхнего слоя. Точно так же ресурсы, информация, знания, процедуры в иерархически организованной компании оказываются погребены в недрах функциональных подразделений – большая часть этого богатства недоступна для потребителей из других подразделений и не работает на достижения целей компании в целом.

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

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

Кросс-функциональные бизнес-процессы обычно иллюстрируют примерно так:

Рис. 1. Функции и кросс-функциональные процессы.

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

Рассмотрим в качестве примера – процесс «от заказа до оплаты»: приняли заказ – произвели – отгрузили – произвели расчеты. Попробуем смоделировать его для случая производства на заказ, буквально следуя картинке  на рис. 1:

  1. Процесс начинается, когда отдел продаж получает заказ клиента.
  2. Получив и оформив заказ, отдел продаж передает его в производство.
  3. Производство приступает к выполнению заказа.
  4. Изготовленный товар доставляется заказчику.
  5. Финансовый отдел производит расчеты.

Рис. 2. Кросс-функциональный процесс «от заказа до оплаты», workflow-версия.

Представьте себе: производственный цех стоит пустой, темный и безмолвный. Тут приходит заказ, мастер включает рубильник и все завертелось. Скажете, чушь? Конечно, чушь! Но наивная диаграмма, изображенная выше, предлагает именно такую картину деятельности предприятия.

Более правдоподобной выглядит следующая схема:

  1. Отдел продаж оформляет заказ клиента и размещает его в производстве.
  2. С определенной периодичностью (например, ежедневно) запускается производственное планирование, которое просматривает накопившиеся заказы и составляет производственный график.
  3. Выполнив очередной заказ в соответствии с составленным графиком, производство уведомляет процесс, связанный с клиентским заказом, о том, что товар готов к отгрузке.

В графическом виде:

Рис. 3. Кросс-функциональный процесс «от заказа до оплаты», BPM-версия.

У нас появилось два процесса, взаимодействующих через данные (БД заказов) и сообщения (уведомление о выполнении заказа). Реализовать эту схему в рамках одного пула (одного процесса) принципиально невозможно, так как у процессов «клиентский заказ» и «производство» разные триггеры: поступление заказа от клиента и таймер, соответственно.

Та же история с доставкой и расчетами: их вряд ли удастся реализовать в рамках процесса «клиентский заказ». То есть технически процессов (пулов) тут не два, а больше.

Workflow, BPM и многопоточное программирование

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

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

Рис. 4. Кросс-функциональный процесс как координатор функций.

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

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

К сожалению, для многих это становится непреодолимым барьером.

  • Кто-то этот барьер не видит. Бьется об него, набивает шишки, но не понимает, с чем столкнулся.
  • Кто-то барьер инстинктивно обходит: выполняет пилотный проект BPM с процессом типа «Оформление заявление на отпуск». Пилот получается успешный, только какое он имеет отношение к бизнесу?

Отсюда, как мне кажется, проистекает большая часть разочарований в BPM: те, кто сводят его к workflow, терпят прогнозируемое поражение.

Технически, многопоточность – это то, что отличает BPM от worflow. Уберите из BPM взаимодействие асинхронно исполняющихся процессов через данные, сообщения и сигналы, и это будет не BPM, а «workflow на стероидах».

К большому сожалению, это относится ко многим современным программным продуктам с агрессивным маркетингом, позиционирующим их как BPMS. Для меня главный критерий полноценной BPMS – это наличие в продукте поддержки сообщений в стиле BPMN. Есть и другие критерии, но этот на практике оказывается самым полезным, так как со всем остальным – графическим моделированием, workflow-движком, веб-порталом, бизнес-аналитикой – лучше или хуже справляются все разработчики, а с поддержкой межпроцессного взаимодействия – единицы. Скорее всего не потому, что это так уж сложно, а потому, что никто не объяснил насколько это важно.

Но сказать «осваивайте многопоточное программирование процессов» легче, чем последовать этому совету. В ответ раздается стон: «какой же сложный этот BPMN, и кто только придумал в нем 50 разных видов событий!».

Сложен не BPMN – сложен бизнес!

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

Сложность BPMN не чрезмерна – она адекватна сложности бизнеса. У слушателей моего тренинга по BPMN не остается вопроса зачем столько событий: все нужны! И кстати, обратите внимание: в части workflow BPMN 2.0 практически не отличается от 1.x – стандарт развивается в направлении более изощренной поддержки многопоточного программирования: choreography, conversation.

Если бизнес и можно запрограммировать, то только как многопоточную систему.

BPM и ACM

Тут я сознательно ступаю на скользкую почву, так как предвижу реакцию адептов ACM (Advanced/Adaptive Case Management): «Ага! Мы всегда говорили, что бизнес в принципе нельзя запрограммировать!»

Может быть можно, может быть нельзя… Скорее всего, в каких-то случаях можно, а в каких-то нет.

Вот говорят, что доля knowledge work постоянно растет. Но где именно она растет? В США, активно выводящих всю рутинную деятельность в Азию. Вот и сообщают нам сидящие в США аналитики о своих вполне прогнозируемых наблюдениях. Но ведь насколько выросла доля knowledge work в одном месте, ровно настолько же выросла доля routine work в другом. А управлять рутинными процедурами, исполняющимися на другом конце глобуса – это ведь самая подходящая для BPM задача.

В свете вышеизложенного я хотел бы поинтересоваться у критиков BPM из числа адептов ACM: вы уверены, что критикуете BPM, а не wokflow? Не являются ли объектом вашей критики BPM-проекты, в которых либо пытались решать задачи бизнеса, не выходя за рамки workflow, либо бизнес-проблематика вообще отсутствовала?

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

Что касается ACM, то это безусловно вещь полезная, но только как дополнение к BPM, а не как замена. Плюс к этому, ACM на сегодняшний день вещь менее зрелая, чем BPM, и поэтому тот, кто наломал дров с BPM, с ACM скорее всего наломает дров еще больших.

Продолжение следует

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

Различие между BPM и Workflow: не только технологии

На блоге 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.

Copyright © 2008-2017 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии