 |
Напомню, что кросс-функциональным называется процесс, в котором участвуют несколько подразделений верхнего уровня (по-английски «функций» — отсюда название). С точки зрения процессной методологии, именно на такие процессы в конечном счете должны нацеливаться инициативы BPM, поскольку именно здесь обычно кроются самые большие проблемы, а следовательно, наличествует самый большой потенциал улучшения. Ведь любая иерархическая организация, достигая определенного размера, сталкивается с тем, что собственные интересы подразделений начинают преобладать над интересами компании в целом.
Собственно, это не новая идея: «сломать стены между подразделениями» — это призыв еще реинжиниринга образца начала 90-х. Другое дело, что предложенный классическим реинжинирингом подход к реализации через однократное радикальное преобразование оказался не вполне удачным. Современный BPM принес новые взгляды на то, как это надо делать, но цель осталась та же самая.
Для иллюстрации кросс-функциональных проблем часто используют метафору силосной башни —«functional silo». Аналогия тут следующая: после того, как крестьянин заложил скошенное сено в силосную башню, добраться он может только до небольшой части этого богатства — до верхнего слоя. Точно так же ресурсы, информация, знания, процедуры в иерархически организованной компании оказываются погребены в недрах функциональных подразделений — большая часть этого богатства недоступна для потребителей из других подразделений и не работает на достижения целей компании в целом.
Чисто функциональный взгляд на вещи влечет за собой искаженное представление о том, что для того или иного подразделения «свое», а что «чужое». Так, например, для бухгалтерии естественно считать, что основное ее занятие — это учет и отчетность. А выставление счетов за поставленный товар нужно кому-то другому, например, отделу продаж; для бухгалтерии это досадная помеха ее основной деятельности. Но с точки зрения бизнеса ведь все наоборот: выставление счета — это часть важнейшего с точки зрения ценности для клиента процесса «от заказа до оплаты», а учет и отчетность — это вспомогательная деятельность. Необходимая, так как ее требует государство и она нужна для планирования собственной деятельности. Но все же она не создает ценность, а следовательно, это затраты, которые по возможности следует минимизировать.
Бухгалтерия — это только один пример. Разработка новой продукции, подготовка коммерческого предложения, выполнение клиентского заказа «от и до» —- в компании есть множество вещей критически важных для клиента, а следовательно для бизнеса, но про которые нельзя сказать, что за них отвечает какая-то одна служба.
Кросс-функциональные бизнес-процессы обычно иллюстрируют примерно так:
Рис. 1. Функции и кросс-функциональные процессы
Однако картинка типа приведенной выше создает совершенно ложное представление о том, как следует решать проблемы, возникающие на стыках между подразделениями. Она порождает вульгарное представление о бизнес-процессе как о простой последовательности шагов: «делай раз — делай два — делай три». Но бизнес так не работает.
Рассмотрим в качестве примера — процесс «от заказа до оплаты»: приняли заказ — произвели — отгрузили — произвели расчеты. Попробуем смоделировать его для случая производства на заказ, буквально следуя картинке на рис. 1:
- Процесс начинается, когда отдел продаж получает заказ клиента.
- Получив и оформив заказ, отдел продаж передает его в производство.
- Производство приступает к выполнению заказа.
- Изготовленный товар доставляется заказчику.
- Финансовый отдел производит расчеты.
Рис. 2. Кросс-функциональный процесс
«от заказа до оплаты», workflow-версия
Представьте себе: производственный цех стоит пустой, темный и безмолвный. Тут приходит заказ, мастер включает рубильник и все завертелось. Скажете, чушь? Конечно, чушь! Но наивная диаграмма, изображенная выше, предлагает именно такую картину деятельности предприятия.
Более правдоподобной выглядит следующая схема:
- Отдел продаж оформляет заказ клиента и размещает его в производстве.
- С определенной периодичностью (например, ежедневно) запускается производственное планирование, которое просматривает накопившиеся заказы и составляет производственный график.
- Выполнив очередной заказ в соответствии с составленным графиком, производство уведомляет процесс, связанный с клиентским заказом, о том, что товар готов к отгрузке.
В графическом виде:
Рис. 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 скорее всего наломает дров еще больших.
Об авторе:
|
|
