Напомню, что кросс-функциональным называется процесс, в котором участвуют несколько подразделений верхнего уровня (по-английски «функций» – отсюда название). С точки зрения процессной методологии, именно на такие процессы в конечном счете должны нацеливаться инициативы 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 скорее всего наломает дров еще больших.
Продолжение следует
В нем я планирую рассмотреть основные паттерны межпроцессного взаимодействияю, а также предостеречь от противоположной крайности – чрезмерного увлечения межпроцессным взаимодействием. Оставайтесь на связи.
- Часть 2: Кросс-функциональные паттерны
- Часть 3: Оптимизация кросс-функциональных процессов
Вероятно, под «критиками BPM из числа адептов ACM» подразумеваются Keith Swenson http://kswenson.wordpress.com/ и Max J. Pucher http://isismjpucher.wordpress.com/ Мне кажется, что эти уважаемые эксперты не возражают столько против BPM, сколько против дополнительной сложности (complexity) в управлении предприятием. И в этом их нельзя не поддерживать.
Теперь несколько замечаний по тексту сообщения.
Ассоциация workflow с оркестровкой, а BPM и с хореографией, возможно, имеет право на существование, но мне кажется, что отношения у них немного другие. Технологии BPMS, реализованные IBM, Oracle и др. убивают технологии workfllow. К концу 90-х годов все, более-менее, представляли что такое workflow. Не нужно имеет какой-то специальной подготовки, чтоб разработать набор состояний процесса, допустимые переходы и имеющие возможность осуществить такие переходы роли. Именно в тот момент надо было принимать простой стандарт и запускать технарей реализовывать движки и API. Если бы это случилось, то думаю очень скоро бы и обмен сообщениями между различными workflow-системами наладился бы. Т.е. можно было бы реализовывать и оркестровку и хореографию. Но вместо этого уважаемое экспертное сообщество принялось стандартизировать квадратики со стрелочками, на что уже потратило несколько лет и продолжает тратить их дальше. После появления нотации BPMN и языка BPEL решения класса workflow в продуктовых портфелях крупных поставщиков ПО начали куда пропадать и теперь место Oracle workflow на полке в магазине занял SOA Suite. Сложно, дорого, одним человеком не поднимается, т.е. требует консолидации экспертизы, создания отдела и т.п. Спасибо, конечно, старшему брату за повышение маржинальности ИТ-сервисов, но это отдельная тема.
Вернемся к оркестровке и хореографии. Каких процессов на современном предприятии больше? Честно говоря, я не берусь ответить на этот вопрос. Если взять отрасль телекоммуникаций, в которой я работаю, то есть и то и другое. Например, подключение к сети корпоративного клиента – это проект, запускаемый по событию. Т.е. приходит клиент показывает точку на карте и говорит: «Хочу сюда сеть!» и под клиента начинают эту сеть строить. А вот сети проводного широкополосного доступа в Интернет (FTTB) строятся иначе. Оператор сначала подключает дом, а потом начинает принимать заявки от жильцов, проживающих в этом доме. Наверное, в массовых услугах больше хореографии, а в создаваемых на заказ – оркестровки.
Причем здесь ACM и knowledge workers? Как правильно говорят АЦээМовцы количество людей непосредственно занятых в массовом производстве снижается, а количество управленцев, работающих в офисах, растет. И это не только в Америке. В Москве миллионы людей сидят за компьютерами, пишут друг-другу e-mail-ы и ходят на совещания. Материальных ценностей эти субъекты не производят, но предприятия как-то должны извлекать пользу из их деятельности. Зря им что ли зарплату платят? Бизнес-процессы в BPMN нарисовать для них как-то нереально. Да и ладно, пусть делают то, что делают. Выручку приносят и молодцы. ACM – это средство позволяющее контролировать что они делают, хоть в каком-то виде, а не отпускать процесс в локальные excel-я, синхронизируемые через электронную почту. Ну а производственные процессы, безусловно, нужно прописывать, формализовывать, унифицировать, а потом увольнять умных людей, которые их отстроили и нанимать на их место гастарбайтеров. (ссылка на этот комментарий в моём блоге: http://wp.me/pRljZ-9P )
Я очень уважаю Кейта - он стоит за разработкой одной из лучших BPM систем. Купил его последнюю книгу специально чтобы познакомиться с системой его взглядов на ACM. А Макс мне действительно кажется продавцом серебряной пули. Впрочем, каждый ведь имеет право на собственное мнение, правда?
Ваш пассаж относительно workflow меня удивил. Вы всерьез мечтаете вернуться в эпоху проприетарных workflow? И что значит “BPM убивает workflow”? Если под BPM понимать BPEL, то это я еще могу понять: “BPEL is not for people”. Но в случае Oracle надо смотреть не на SOA, а на BPM Suite, который собирает очень хорошие отзывы в части поддержки BPMN. IBM и SAP - два другие тяжеловеса - тоже сделали выбор в пользу BPMN. В BPMN есть все, что есть в workflow, поэтому я не понимаю, о чем тут можно сожалеть.
Массовое производство тут вообще не причем. Узнаю черный пиар Макса
К массовому производству не имеет отношения ни ACM, ни BPM. И то, и другое в первую очередь - как раз для тех самых “субъектов”, о которых Вы говорите. Для тех из них, кто занимается креативной работой - ACM, для остальных - BPM. И кого, по-вашему, больше среди работников офисного труда?
“Бизнес-процессы в BPMN нарисовать для них как-то нереально” - а вы пробовали? Подробностями не поделитесь?
Максим, чтение Вашего поста представило моему воображению страшную картину: потоки электронных писем, и менеджеры процессные в халате уборщицы, для каждого письма рисующие процесс :’ ( Я плАчу. По-моему, то, что Вы описываете - это попытка решить проблемы управления чисто средствами автоматизации. Не спасет тут ACM, имхо.
Сначала поделюсь подробностями “рисования” процессов на примере нашей компании. Есть линии бизнеса, для которых моделирование процессов является чем-то естественным и необходимым, например подключение корпоративных клиентов или обслуживание. Есть направления которые хронически этого не делают. И такая ситуация сохраняется годами. Думаю, что есть определенная зависимость между стабильностью процесса и нежеланием его рисовать. А вот меняющиеся процессы рисовать приходится, иначе может наступить хаос.
Теперь относительно “синих воротничков” склонившихся над чертежом в BPMN. Просто поделюсь ссылкой http://www.pcweek.ru/themes/detail.php?ID=127002 Не знаю как там идут дела у бухгалтеров и юристов, но ИТшники, действительно, дешевеют
“Подключение корпоративных клиентов” рассматривается как кросс- или как внутри-функциональный процесс? Наводящий вопрос: включает ли этот процесс, в вашем понимании, пресейл и финансовые расчеты или только непосредственно исполнение заявки на подключение?
То есть Вы , Максим, хотите сказать, что если РИСОВАТЬ процессы, то хаос не наступит? Ммммм….. это прямо тянет на Апокалипсис….
Анатолий, один из авторов [анти]научно-популярной литературы Роберт Уилсон в одной из своих книг упрекнул ученых в субъективности. Рассуждал он примерно так. Ученый проводит серию экспериментов, рассчитывая пронаблюдать повторяемость результатов. Если результаты повторяются он придумывает теорию, объясняющую выявленную закономерность. Если же результаты не повторяются, то экспериментатор их отбрасывает ссылаясь на погрешность измерений или некорректность эксперимента. Таким образом ученый полностью исключает из рассмотрения такой элемент как случайность. Если Вы хотите где-то найти многопоточность, то Вы её обязательно обнаружите
Безусловно, каждый сотрудник в компании, каждое ядро в микропроцессоре реализует независимый экземпляр процесса, взаимодействующий с другими экземплярами. Наверное, такое же утверждение верно для каждой элементарной частицы. Взаимодействия частиц в нашей вселенной описываются не оркестровкой, а хореографией. Ну и что с того? Время очередей в магазинах и в бизнес-приложениях закончилось в 90х годах прошлого века. Теперь я, так же как и многие остальные хочу предоставления сервиса “по запросу”. Я не хочу оставлять заявку на сайте и ждать пока ей обработают. Я хочу звонить по мобильному телефону тогда, когда мне это надо, а не ждать пока освободиться сеть. И мне достаточно все равно каким образом провайдер услуги организует свои ресурсы для предоставления необходимого мне сервиса непосредственно в момент моего обращения
Юлия, апокалипсис обязательно наступит. Все наши попытки противостоять хаосу обречены на неудачу
Максим
Я задал конкретный вопрос на две строки, а получил два абзаца, извините, не о чем. Я стараюсь быть конкретным: предлагать конкретные решения для конкретных задач, учиться на конкретных кейсах. К чему эти игры в аналогии и метафоры? Вы можете предложить метод познания более совершенный, чем научный? Ну давайте Тима Лири вспомним до кучи с Уилсоном, закинемся и займемся расширением сознания…
Дело-то вот в чем: то, что Вы называете BPM, я тоже не люблю. Но это не BPM - это workflow и микроменеджмент. Об этом собственно и была статья. Жаль, что не удалось достучаться.
Generally agree with this post which, in my interpretation, appeals to consider a _wider_ context than just business processes and/or workflows. This context is about architecture of the whole enterprise which is a dynamic set of process instances coordinated via different techniques: data-based, rule-based, event-based, etc. I prefer to concentrate on “process instances” rather than “multithreaded programming” because we need to make instances explicit and use them to express the business behavior (for example, http://www.slideshare.net/samarin/practical-process-pattern).
The absence of this context is pre-destined by the fact that BPM market (as well as workflow one) is the vendor-driver market. There is no interest to have a good set of standards as there is around HTML (or web browser) where all vendors want to benchmark their product against the acid3.acidtests.org to demonstrate their compliance with standards.
I think, that BPMN is a huge step to the right in comparison with many proprietary notations of workflow, especially with the explicit notion of events. Use of events allows us to have processes which are almost impossible with workflow-based systems. At the same time, I consider the “diversity” of BPMN events as overkill. From other side BPMN didn’t go far enough to have explicit _event queues_ (and thus penetrating the event processing area). The latter could make fig.3 more realistic (by separation of planning and execution).
Concerning BPM vs ACM – I think this is partially a marketing discussion, because BPM (as a discipline) covers what the ACM camp is arguing for (see http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html). But some existing BPM tools can’t do what ACM tools offer.
About “degradation of IT” – there is no such thing as an “IT specialist”. Fortunately, there is specialisation in the IT industry. And it is normal that people have to change their specialisation some time.
Thanks,
AS
Alexander
Thank you for the input. I’m not sure we should only blame vendors. After all, they just follow the money. It’s like egg and hen or media and masses: vendors provide what customers request and customers try to utilize what they got from vendors. “What customer says always differs from what he wants and what he wants differs from what he needs.”
I agree that cross-functional process problem roots in the wider context. There is a gap between BPM and business/performance consulting: most BPM people (both at vendor and customer sides) focus on HOW to do process things but have vague idea about WHAT FOR - how to connect process improvements to business issues. On the countrary, business consultants are able to define corporate targets, strategy, value chain and things like that but when it comes to implementation then it’s not their business. We are trying to close this gap in our projects and I believe core cross-functional processes are the key link that ties these two levels of competency - hence my interest to the matter.
About separating planning and execution in fig.3: you are reading my mind! I’m going to cover it in the follow-ups, didn’t want to overload this part with unnecessary details.
Regarding BPMN: could you please name the elements that are redundant from your point of view?
Thanks Anatoly.
Agree about the gap which I also would like to make explicit even for kids:
For want of a nail the shoe was lost.
For want of a shoe the horse was lost.
For want of a horse the rider was lost.
For want of a rider the battle was lost.
For want of a battle the kingdom was lost.
And all for the want of a horseshoe nail.
Will consider a BPMN redundancy list.
Thanks,
AS
Согласен с тем что приходится иметь дело с существенно параллеельными процессами и синхронизацией между ними
Согласен что workflow диаграммы не предназначены для эффективного представления исполнения синхронизированных параллельных процессов
Утверждаю что сложность задачи рассчитывается из количества параллельных процессов и точек синхронизации +логики обработки отказов и внешних управлений
Утверждаю что процессы (потоки - полосы можно выбирать из разных сообщений) например из соображений реальных подразделений или ресурсных подсистем
Утверждаю что тупое закладывание отрисованных бизнес процессов в workflow engine низкоэффективно примерно как написание программы на фортране и отладку через операцию принт
Это особенно относится к реализации процессов имеющих 50-100 тасков и 20-30 синхронизационных событий
Для реальных задач типа запуска ракеты с учетом взаимодействия подсистем все описанные средства уже практически не применимы и документирование wprkflow и взаимодействия таких процессов это high tech
Отметим что такие системы обязаны отрабатывать логику исключений и отказов и внешних управляющизх команд что накладвывает на задачу усложнение на порядок
Слава, все понятно, но при чем тут ракеты?! В моем представлении основная проблематика бизнес процессов - это координация между людьми, работающих в разных подразделениях, но над одной “сквозной” задачей, притом повторяющейся более-менее по одному шаблону. Людьми, а не механизмами и не программами.
Я об этом как-то уже писал: в телекоме/банках смотрят на бизнес-процесс так - интеграция больших систем и человек как сервис, который эти системы время от времени вызывают для того, чтобы разобраться с нештатной ситуацией. Идеал - Straight-Through Processing. Если где-то в процессе участвует человек, то это временная недоработка. “Слава роботам, убить всех человеков!” (с)
Во всех остальных отраслях бизнес - это дело человеческое, а системы - это бессловесные помощники: подай-принеси-запомни. Соответственно, задача в первую очередь ставится как программирование людей, а программирование систем рассматривается как задача подчиненная/смежная/сторонняя.
И тут возникает масса специфики. Например, просто отдать человеку команду недостаточно - чтобы он выполнил ее хорошо, ему нужно объяснить как, зачем и почему. Причем замечено, что графические объяснения он понимает лучше, чем текстовые. Отсюда трепетное отношение к диаграммам и к моделированию, которое у труъ программеров вызывает отторжение.
Хотелось бы уточнить вот какой момент. Я, по наивности своей, полагал, что процесс кросс-функционален по своему определению. Потому что описывает взаимодействие разных организационных единиц. Иначе это не процесс, а процедура, выполняемая в рамках одной орг. единицы.
Соответственно, пул - это одна организация, лэйны в пуле - это функциональные орг. единицы в рамках этой организации. Между пулами возможно только “слабое” взаимодействие (через сигналы и сообщения), между лэйнами возможна “жесткая” прямая передача управления.
Если мы изображаем т.н. X-process, т.е. процесс, “продленный” вовне организации, тогда на схеме появится более 1 пула. Если же одну организацию нужно представлять более, чем 1 пулом, то это какая-то странная, неорганизованная (и неуправляемая) организация.
В описанной ситуации с заказом, логично было бы процесс на стороне клиента изобразить в одном пуле, организацию, которая производит и продает продукт - во втором пуле, поставщика сырья и материалов - в третьем пуле. Но подразделения “производство”, “обработка заказов”, “бухгалтерия” и “АСУ в т.ч. BPM” в рамках одной организации должны быть представлены лэйнами, передача управления между ними - прямая жестка, но(!) с особым вниманием к буферам по времени, таймаутам и эскалациям.
Что я думаю (делаю) не так? Заранее признателен!
Андрей
Ваша точка зрения весьма распространена, но я считаю, что она не соответствует объективному положению дел. И об этом собственно моя заметка; рад, что она Вас зацепила.
Есть два взгляда на то, что такое пул. Первый (к сожалению, преобладающий): пул - это организация. Второй, которого придерживаюсь я и те, у кого я учился: пул - это процесс.
Теперь по существу: Вы просто попробуйте реализовать процессы клиентского заказа, планирования производства и собственно производство в рамках одного пула и “жесткой” прямой передачи управления. Если получится, я буду сильно удивлен.
Почему не получится: отдел продаж и производство живут в разных ритмах. Производство планирует не выполнение каждого конкретного заказа, а распределение имеющихся ресурсов на все накопившиеся заказы. Это объективно, и это требует отдельных пулов для того и для другого.
Если исходить из того, что в одной организации не должно быть больше одного пула, то вариантов два: либо это канцелярский процесс типа “заявление на отпуск”, либо просто ничего не выйдет.
Правда тут есть другая крайность - в пределе каждую задачу можно превратить в отдельный пул. Как этого избежать и где следует остановиться - об этом я планирую порассуждать в следующей заметке, продолжающей эту.
Еще раз: слова стоят дешево - просто покажите схему с одним пулом.
Использовать pools & lanes для моделирования функциональных структур участников - интуитивно и удобно. Пулы моделируют участников со “слабым” взаимодействием между собой, lanes - функциональные роли “внутри” участника с “сильным” (или “близким”) взаимодействием. Эта логика понятна “обычному управленцу”.
То, что говорите вы, не противоречит этому подходу. Вы описываете ситуацию, когда организационно-административные (и функциональные) вертикали управления “продажи” и “производство” живут как бы в параллельных измерениях, и между ними “слабое” взаимодействие даже в пределах одного предприятия. Вполне жизненная ситуация. И почему бы, действительно, не быть нескольким пулам в рамках одного предприятия? по-моему, нормально. Более того, комплекс BPMS и других задействованных автоматизированных систем и БД разумно рассматривать, как отдельный пул, вы не находите?
Рискну предположить, что задачей оптимизации процессов как раз и *может* являться переход от процесса со “слабым” взаимодействием к более эффективному процессу с “сильным” (”жестким”) взаимодействием.
Вызов ваш принимаю, беру 2-3 дня на подготовку схем.
Андрей
Насчет оптимизации угадали. Отдельный вопрос - в какой мере это возможно, где и как такую оптимизацию проводить.
На мой взгляд, тут ответ очевиден - “доработать напильником по месту”, т.к. а) корпоративная культура, и сказано было “в чужой монастырь…”, и б) человеческий фактор (личные мировоззрения и мироощущения stakeholders - ЛПР-ов организации(ий), да наложить еще их взаимоотношения внутри своего круга)… Что тут заранее можно угадать? да в принципе никак.
Вопрос не в том, удастся или нет воплотить в жизнь изменения и как их воплощать - это отдельная тема. Вопрос в том, какая схема оптимальна. Свести все к “жесткому взаимодействию” (в Вашей терминологии) просьба не предлагать, по крайней мере до тех пор, пока у Вас не получится обещанная схема.
У меня есть кое-какие системные предложения по этому вопросу, но надо найти время, чтобы их додумать и внятно изложить.
Anatoly,
Just one remark. According to BPMN2 specification, Data Objects exist only within a process. Data associations cannot cross pools and data exchange between processes is modelled with message flows only.
I assume the diagram in Fig. 3 is BPMN1.2 compliant.
Ivo
Thanks a lot for pointing this out. As you can see from other posts on this blog (e.g. http://mainthing.ru/item/332/) I’m relying heavily on data-based interprocess communications so this is very sensitive issue for me. Messaging isn’t a replacement because there are many cases when a receiving process instance just isn’t instantiated yet.
You are right that Data Object in BPMN 2.0 must belong to a process: “Data Object elements must be contained within Process or Sub-Process elements.” (p. 205). “The lifecycle of a Data Object is tied to the lifecycle of its parent Process or Sub-Process. When a Process or Sub-Process is instantiated, all Data Objects contained within it are also instantiated. When a Process or Sub-Process instance is disposed, all Data Object instances contained within it are also disposed. At this point the data within these instances are no longer available.” (p.207). So Data Object within BPMN 2.0 are similar to process attributes: they exist only as long as a process instance does.
The BPMN 2.0 Data Store is more suitable for interprocess communications: “A Data Store provides a mechanism for Activities to retrieve or update stored information that will persist beyond the scope of the Process.” (p. 208). I couldn’t find in the spec the explicit forbiddance for data associations to cross pools - could you please point it out? Besides, BPMN 2.0 distinguishes “data associations” which are used only with Data Objects and directed associations - I guess the latter should be used with Data Stores. So I hope that the diagram at fig. 3 would be BPMN 2.0 compliant if the Data Object was replaced by a Data Store. Unfortunately the spec doesn’t provide such an example but Bruces Silver in his “BPMN Method & Style” does (p. 33).
There is no Data Stores in BPMN 1.x so we use Data Objects for them, too. Luckily, BPMN 1.x is more flexible and doesn’t require a Data Object to belong to a process so the diagram at fig.3 should be valid BPMN 1.x.
Anatoly,
I’ll check later in the spec. about data associations crossing pools. At the moment, here’s one citation from another reliable source:
“Data objects only exist within a process; therefore data associations cannot cross the borders of pools. Direct data exchange with other processes is modelled with message flows. In order to specify that the content of a message is processed as a data object, a catching message event can have an outgoing data association. Conversely, a throwing message event can have an incoming data association”
BPMN2.0 - Introduction to the standard for Business Process Modeling, Prof. Thomas Allweyer, page 124.
I agree with the Data Store approach. I’m currently implementing something which uses this as a workaround.
Ivo
Well probably it doesn’t matter because Data Objects as defined by BPMN 2.0 can’t be used in interprocess communications anyway. E.g. at fig. 3 we need a collection of Purchase Orders created by multiple process instances to be read at once by Production process - it can’t be modelled by a Data Object because it can only represent data associated with a single process instance.
But please note that BPMN 2.0 defines data associations to be used exclusively with Data Objects and directed associations for everything else, including Data Stores I guess. The two associations use the same graphical representation - dotted arrow - meaning that even if data associations can’t cross the borders, something else looking exactly the same can.
The recomendation about using messages is irrelevant while the Data Store approach is a valid pattern for me, not a workaround.
I meant “workaround” in my case because I need to link Data Stores to data models in non-BPMN models for data management purposes. It’s natural to do it when it’s message or data object but for data store it looks strange. Imagine a Data Store (something at physical level) to be elaborated in a UML Class Diagram (logical level). Not nice but..
Agree. Implementing a Data Store by a modifier to the existing Data Object would be more BPMN flavour.
The Data Object vs. Data Store discussion continues at http://mainthing.ru/item/434/
Анатолий, здравствуйте!
Удалось Вам увидеть схему Андрея Стешина с одним пулом? Я понимаю, что диалог состоялся не вчера, но не затруднит ли Вас мысленно вернуться в 2011 год и вспомнить итог вашего диалога? Полагаю, что многим читателям это показалось бы ценным.
Алексей, безнадежное это дело, не получится. Вот и у Андрея дальше рассуждений дело не пошло.