It’s time to pay the debts - returning to cross-functional processes modeling as promised.
Remindment: the first part stated that it’s usually impossible to implement cross-functional processes by orchestration only (i.e. within a single BPMN pool). The borders betwen departments are material, they mark differences in manner and rhytm of different kinds of work. Because of these differences the fragments of a process belonging to each department are technically implemented by separate pools while the cross-functional process as a whole is implemented by a set of such pools communicating via messages and data.
In this article we’ll consider common cross-functional process patterns.
Let’s use the following example:
Under routine financial planning all bills received by a company are processed by the finance department first: they determine validity of the claim, check the amount and date, assign priority in accordance with established business rules. Then the bill is submitted for approval to CFO or some other manager who makes a decision about payment taking into account priority, amount and term.
The simplest process diagram may look like this:
Fig. 1. Synchronous Process
In reality companies use to establish different routines for different bills: e.g. the bills below certain amount or tax claims may pass without approvals. Besides some bills may be rejected by the first check and not get to the CFO but we’ll leave it apart.
1. Single Resource Planning
We are interested in another aspect: let’s suppose that company has limited working capital. So it may happen that the bills not disputable by either amount nor term can’t be paid in due time and the company postpones them.
The key point: it’s impossible to make a qualified decision regarding a single bill. The reasonable alogirthm for a decision maker is to collect all bills for the given period (e.g. for today or this week), analyze the situation as a whole - the amount available vs. the bills total - and decide which bills to pay and which to postpone.
Here is the process diagarm implementing this algorithm:
Fig. 2. Resource Planning
Comments for those who aren’t comfortable with BPMN:
- After passing the check the bill is placed into the database and bill processing waits first of three events: the income message that the bill is approved; the income message that the bill is rejected (we won’t pay) or timeout (added for generality).
- The bills are approved within a separate process which is launched periodically (e.g. daily or weekly). At the first stage the bills for the given period are selected from the database. A list of selected bills is then presented to CFO to choose from three options: “approve”, “reject”, “postpone”.
- When it’s done and the button is pressed the process instances corresponding to the bills marked as approved or rejected automaticallt get appropriate message and corresponding database records are marked as processed. Postponed bills remain untouched and the next run of the scheduling process selects them again.
- If the bill is approved then the financial transaction is made automatically.
Process diagrams like at the fig. 2 appear at this blog on a regular basis. If asked what is the single most useful process pattern I’d pick this one.
- Alexander Samarin calls it “CPP - Collect and Periodically Process”.
- I prefer “Resource Planning”.
- Yet another name for the same pattern:”Orders Buffer”.
It’s generally good to have several names for a single pattern: more names, more “pictures” of the outer world we associate with it, more often we utilize the pattern.
- Some use term “Group Processing” but I don’t like it: too general, may mean nearly anyting.
2. Optimistic Planning
Which of the diagrams depicted at fig. 1 and 2 is better? More correct? There is no definite answer because it depends on our priorities:
- if the priority is processing speed then the diagram at fig. 1 should be preferred
- if the priority is resource utilization then the diagram at fig. 2 should be preferred
Besides these options aren’t exclusive - here is a combined scheme:
Fig. 3. Optimistic Planning
Each bill is considered twice: first synchronously under the bill processing then - if necessary - within payments sheduling.
- The payments scheduling process checks if there is enough money to pay all preliminarily approved bills and assign the approval task to the CFO only at those presumably rare cases when there the balance would become negative.
This scheme is practical when the resource is not confining “almost always”. It benefits from the bills approved without delays yet when there isn’t enough money there is an option to reject some bills at the last moment.
- When the preliminary approval is received the process may perform some activities (not depicted at the diagram) like informing the supplier that the bill is scheduled for the payment.
- If the exception occurs and the payment was rejected at the last moment then the supplier must be informed about this event, too.
3. Multiple Resources Planning
Another possible development direction for the diagram is generalization for multiple resources case. For example the company may make payments using different accounts at different banks.
Fig. 4. Multiple Resources Planning
Now finance not only checks the bill but also figures out what bank account should be used (probably on the basis of defined business rules).
- CFO may agree with the plan or switch the bill to another account.
- When the decision about all bills is made the scheduling process creates a list of payments for each bank and initiate a payment process for each list - not an instance for every bill but an instance for all bills scheduled for a given bank at a given date.
At this diagram we separated bill processing, payments scheduling and payments per se. It makes possible to schedule either multiple resources or a single resource for multiple dates: for example, CFO would be able to schedule payments for today and tomorrow. The payment execution process will wait for the assigned time (note the timer at the diagram) and then pay all bills.
OK, this is a bit artifitial for payments but imagine scheduling of multiple production lines. The output of the scheduling process at this case are daily schedules for each line: each schedule lists all orders to be processed by the given line at the given date. It’s natural to consider the execution of each schedule as a separate process. The scheduling process launches the execution process for each line and exits. From Monday to Thursday the schedules are created for the next day while on Fridays the production may be scheduled for Saturday, Sunday and Monday.
Generally speaking, the example used isn’t a cross-functional because both finance and CFO are really the same department. But that’s not the point: the point is that there is a process utilizing some limited resource - working capital for the case.
- This is the case whenever the process crosses the boundaries between departments: the customer’s order needs an activity from the manufacturing, manufacturing depends on materials purchasing, new product development needs marketing research, claim processing needs the user manual to be corrected etc.
- But it’s the same at a smaller scale: e.g. the manager’s time may be a limited resources. Top managers are very busy all the time so if some process needs director’s approval or signature then be prepared that he’d prefer to approve a list at once rather than many separate requests.
From this point of view, we increased the efficiency of two resources at once: the working capital and CFO.
To Be Completed
In the final part I’m going to speculate about what should be taken into account when choosing one pattern or another.
Статья весьма познавательная. Можно использовать подобные подходы для оценки доступности и планирования денег и материальных ресурсов. Однако, меня в большей степени интересуют вопросы управления трудовыми ресурсами.
Давайте представим себе, что одна и та же операция в некотором бизнес-процессе может выполняться не одним человеком, а несколькими (например, работниками одного отдела). Каждый из них является пользователем BPMS и одновременно является трудовым ресурсом. Было бы очень неплохо, чтобы бизнес-процесс мог бы оценивать текущую загрузку каждого из них, чтобы выбирать, кому именно из этого назначить задачу. А для этого необходимо, чтобы во всех бизнес-процессах, которые попадают в данный отдел, для каждой операции существовала бы плановая оценка трудоемкости и критичные сроки завершения. Тогда BPM-система могла бы оценить остаток незавершенных операций каждым работником, оценить производительность каждого из них (учитывая исторические данные) и определить, кому именно адресовать задачу в конкретном экземпляре бизнес-процесса, чтобы она с наибольшей вероятностью была выполнена в срок. По сути, это задача автоматической диспетчеризации. Она может решаться разными способами. Могут, например, задачи валиться на наименее нагруженного из некоторого пула работников. Могут валиться всегда на одного работника, а когда он “переполнится” задачами, тогда уже “подключать” другого. Опять же нужно оценивать доступность трудового ресурса не только по загрузке задачами, но и по его выходу/невыходу на работу. Для чего нужно вести рабочий календарь по всем сотрудникам с вариациями отдельно для каждого (плановый отпуск, командировки и т.д.), а в идеале еще и кроме плана иметь факт в виде данных, поступающих, например, со СКУД. Если данные, накопленные в системе, говорят о том, что сроки решения какой-либо задачи могут быть сорваны с высокой вероятностью, то процессный менеджер должен получать об этом уведомление заранее, а не тогда, когда сроки уже окажутся сорванными.
В идеале эта задача должна решаться каким-то универсальным способом. Было бы крайне нежелательно изменять число кубиков в бизнес-процессе каждый раз, когда какой-то работник увольняется или когда выходит на работу новый. И было бы здорово, если бы BPM-системы имели бы встроенный функционал для оценки доступности ресурсов, чтобы не приходилось “городить огород” из вспомогательных кубиков-ромбиков, которые могут сделать схему БП более запутанной и менее понятной для бизнес-пользователей.
Кстати, формат даты комментария мог бы зависеть от выбранного интерфейса RUS/ENG…
Кстати, он таки зависит. Вы еще не успели пожелать, а мы уже сделали
Возвращаясь к первому комментарию, это уже не process management, а task management. Такие вещи не отображаются на схеме (”кубики” не переставляются), но любая BPMS имеет те или иные алгоритмы раздачи заданий в том случае, когда у нее оказывается больше одного возможного исполнителя. Может быть не столь изощренные, но раздача по очереди (первое задание сотруднику А, второе сотруднику Б и так далее, потом по кругу снова А), назначение тому, у кого меньше длина очереди задач в данный момент, назначение одновременно всем (кто взял задачу, тот молодец, остальные ее больше у себя не видят) - это все дело обычное. Автоматическое переназначение задач другому сотруднику на время отпуска - тоже не экзотика. Более сложные алгоритмы надо программировать - тут уже зависит от мощности библиотеки, предоставляемой той или иной BPMS.
В общем, пусть и не в полном объеме перечисленных “хотелок”, но все BPMS решают эту задачу, причем универсальным способом, не запутывая схему бизнес-процесса.
> это уже не process management, а task management
Не вижу причин, по которым process management, task management и project management не могут быть объединены в “united management”. Более того, разделение management на management вида1, вида2 и вида3, для каждого из которых используются разные инструментарии, ПМСМ, очень “не здорово”. На отрыве сферы ИТ от менеджмента я более подробно намерен остановиться на семинаре.
> Может быть не столь изощренные…
В том-то и дело, что слишком простые. В MES-, в ERP-системах, в системах управления проектами почему-то ведутся календари доступности ресурсов, причем, в некоторых не трудовых, но и оборудования (с учетом плановых ремонтов). Я не совсем понимаю, почему в BPMS они вдруг перестали быть нужны. Назначение ресурса должно учитывать приоритеты как задач, так и ресурсов, а также их трудоемкость. Длина очереди может заменить трудоемкость только в одном случае - если все задачи в очереди имеют примерно одинаковую трудоемкость. У одного работника может быть в очереди одна задача “построить дом”, у другого три “почистить картошку”, “вынести мусор” и “покормить Бобика”. Очевидно, что следующая задача “помыть посуду” должна быть назначена второму, а не первому. Однако, ни один из предложенных алгоритмов ее не решает, за исключением, разве что, “кто сам взял, тот и молодец”. Однако, что делать, если никто не взял? Кто конкретно в этом случае будет виноват? Начальник отдела? Ок, наварили ему по первое число, а он кому должен наварить, если каждый из его подчиненных считает именно себя наиболее перетрудившимся? Пропускать весь траффик через начальника тоже не всегда подойдет… В общем, объективно информация и критерии оценки есть, но воспользоваться ими затруднительно. И это как раз потому, что айтишники, разрабатывающие в том числе, BPMS, слишком увлекаются структурами вроде “стека”, “очереди” и прочих “рандомайзеров”. В то время, как для бизнеса требуется решать задачи несколько другого плана.
Кстати, по поводу пропуска траффика через начальника… Начальник все равно должен руководстваться трудоемкостью того, что осталось сделать, но еще не сделано. Если он будет назначать задания, руководствуясь ощущениями, то мы получим вместо процессного управления процессное отсутствие управления.
Уточню: речь шла не о разных продуктах, а о разных “слоях” одного продукта, в данном случае в BPMS есть слой управления процессами и слой управления задачами.
Я согласен, что управление задачами в BPMS можно было бы сделать лучше, хотя там не все так плохо, как тебе представляется. Например, рабочий календарь - это достаточно стандартная функциональность. Что можно сказать в оправдание: ребята стараются, работают, а им только претензии со всех сторон: кто-то требует ACM встроить в BPMS, кто-то разобраться с task management… дайте срок. А лучше помогите материально - купите продукт, сделайте хоть что-нибудь. Да, есть недоработки (а у кого их нет?), но не стоит представлять дело так, что пока разработчики не сделают работу над ошибками, пользоваться продуктами нельзя - можно!
А с точки зрения архитектуры предпочтительнее было бы рассматривать task management как отдельную задачу. В конце концов, какая разница откуда сыплются задачи - из процессов, из проектов или из CRM? Все вышесказанное относятся к ним ко всем в равной мере. Так что в идеальном мире я бы предпочел видеть единый список “мои текущие задачи”, в который ссыпают все кому не лень.
Впрочем, мы как-то отвлеклись - к данной статье эта дискуссия имеет очень мало отношения.
Anatoly,
I agree with your diagrams, but I would express the reason differently, and I think more broadly than whether it is cross-functional or not. The reason why these diagrams require two pools instead of one is that there is a 1:N correspondence of the instances. (You can use loop/MI activities to model 1:N correspondence within a single pool, but this imposes time sequence constraints that may not reflect reality.) When an instance of Process 1 is a customer transaction (message start event) and an instance of Process 2 is a periodic rollup or report across customer transactions (timer start event), it is very common that they cannot be combined as subprocesses within a single pool, but must be modeled as a collaboration. In BPMN 2.0 you can even show the 1:N relationship in the diagram via a multi-participant marker on the pool with “N” instances to the other pool’s one. The Hiring certification exercise in my bpmessentials training is an example of this, where the pools are not at all cross-functional; the performers are the same people in each… establishing clearly that a pool in BPMN really means a process not an organizational unit.
Bruce
Thank you for getting in, your opinion is always valuable.
I guess we look at the same diagram from slightly different perspectives. I’m trying to present patterns for typical business cases. In this particular case the logic is following: 1) cross-functional processes are important because they create value => 2) different functions within a cross-functional process utilize different resources and/or have different rhytms => 3) you’ll need different pools to model them. If there is a single resources try to use this pattern, if multiple than that one.
You consider it from academic point of view. I agree with you - it’s about process instances. And your scope is broader indeed. But if I was more from a business side - how would I know how many instances are there and how exactly do they relate to each other? I would barely know what’s the difference between pools and subprocesses.
It’s like induction (my) vs. deduction (your) and the question is which is easier to grasp.
“A pool in BPMN really means a process not an organizational unit.” - these words should be gold-plated. Sure it does but you know, the spec doesn’t say it with the same clarity as you do. And some popular BPMS vendors add to the mess. As the result many people do believe that a pool stands for a performer. Here is a fresh example: “BPMN pool is normally associated with a participant” - http://improving-bpm-systems.blogspot.com/ (Sorry Alexander if you are reading this, but I really can’t operate with this style of BPMN diagrams.)
So Bruce, do you see the issue here? If you do then let me ask you a question as a member of the BPMN committee - is there a chance to fix the standard?
Anatoly,
Nothing to sorry, process design is a creative work yet, so each person may have his/her own style. Actually I am surprised with your interpretation of my post about the FRAP process pattern. This post demonstrates that the popular association between pool and participant is NOT correct.
Thanks,
AS
Anatoly,
My perspective is intended also to be “business” not “academic.” An important business principle of BPM as a management discipline is conceiving the end-to-end (usually that means customer-facing) business process as a “single thing” not as a collection of things. For BPMN, that means making it a single BPMN process if that is possible. So task performers should be modeled as lanes not as separate pools. I agree with you (and AS it seems) that the widespread confusion between BPMN terms “participant” (pool) and “performer” (lane) is a bad thing, and the continued reference to both pools and lanes in the spec as “swimlanes” is legacy and plain idiotic.
Note I say above “if that is possible”. The usual case when it is not possible is when there is not a 1:1 correspondence of the instances of the “subprocesses” and make the subprocess a loop or MI does not work. Maybe this is what you mean by “different rhythms”. I think my formulation regarding what the instance represents is more precise, although admittedly it is a concept some business people may have trouble with at first. But, if a modeler can’t understand what a process instance means, maybe that person should not be doing BPMN.
Re “fixing” the business about pools and participants in the spec, no that will never happen. It was not accidental. I filed more than one JIRA bug against it in the drafting, and the dark forces of the “participant” view just ignored them. There is much that is counterproductive in the spec, and this is just one example. Anyway, BPMN 2.0 is finished, the team is exhausted, and I would not expect a revision anytime soon.
Keep up the good work, Very few people are writing about how to use BPMN correctly, and I applaud you for it.
Как человек, начинающий знакомиться с BPMN, хочу поблагодарить автора за то, что он поднял сложную тему планирования ресурсов и привел примеры модели возможной реализации. Последняя модель мне кажется более структурированной и понятной. Немного смущал автоматический шаг “Выполнить платеж”, мне кажется, что при использовании платежной системы эту операцию выполняет человек, обладающий определенными полномочиями. Но если на это смотреть, как на активизацию задания предоставить определенный ресурс, в определенном объеме, на определенную линию производства, то все становится на свои места.
Понятно желание Андрея Гордиенко решить задачу под названием “раздача заданий” универсальным способом, но это не из реальной жизни, в этой задаче слишком много параметров, причем слишком разных для каждой группы процессов.
Анаит
Спасибо за комментарий.
“Выполнить платеж” я сделал автоматической задачей (service task), предполагая, что у нас есть какая-то система клиент-банк, в которую мы отправляем заявки на платеж, успешно прошедшие через наш процесс. Как там дальше эта система работает - с участием оператора или автоматически отправляет поручения в банк - это уже не наше дело. Но можно было изобразить и ручную задачу, для данного примера это не принципиально.
еще этот паттерн называется “Вокзал”, и он очень распространен:
поезда ходят по расписанию, и пассажиры приходят на вокзал в соответствии с заранее известным расписанием.
это позволяет избавиться от большого числа “мелких” задач, сведя их к одной более крупной. соответственно весьма существенно снижаются потери времени на переключение между задачами, комфортность работы исполнителя растет, все улыбаются.
Алексей
Спасибо за комментарий, но боюсь это другой паттерн: планирование ресурса (поезда) осуществляется в момент покупки пассажиром билета. Вот если из схемы на рис.4 выбросить планирование и оставить только заказ и исполнение, то получится похоже на вокзал.
Производственные компании пока еще не продают клиентам свои мощности так же, как авиакомпании кресла или кинозал билеты. Хотя в принципе могли бы. Кстати, интересная мысль. Но достаточно революционная.
И с комфортностью не так однозначно: улыбаются не все, а именно что исполнители. Для пассажира комфортнее такси, которое везет когда надо пассажиру, а не по расписанию. Об этом подробнее в заключительной статье http://mainthing.ru/ru/item/417/
Anatoly:
Why you call patterns when these are templates?
What do you suggest to provide some persistence in order to template reuse?
Regards
Alberto.
Alberto
Here is my vision of templates and patterns: http://mainthing.ru/item/292/ Please also pay attention to the comments.
If I was going to present a BPMN diagram for a specific task e.g. accounts payable then it’d be a template. A pattern is something more generic, like resource planning in the post above. Whatever resources one is dealing with - machine, production line, budget, manager’s time etc. - he/she would hopefully find presented diagrams useful. Hence they are patterns for me, not templates.
Regarding template reuse - I believe Scott Francis answered your question at http://www.bp-3.com/blogs/2010/11/design-patterns-in-bpm-lost-cause/ “Of course, many people misunderstand the point of patterns. They wonder why there is still so much work to do! But patterns are not libraries of code – they’re patterns of design and code. Its like knowing how to tie a square knot. Although you know the pattern, you still have to tie the knot each time you want to use it. Design patterns are much the same way.”
Kind regards
Anatoly
Производственные компании пока еще не продают клиентам свои мощности так же, как авиакомпании кресла или кинозал билеты. Хотя в принципе могли бы. Кстати, интересная мысль. Но достаточно революционная.
—
Это уже происходит в некоторых отраслях - например производство карбона: заказчик выкупает у производителя 1 линию на 10 лет, чтобы обеспечить постоянство качества и непрерывность поставки в необходимых объемах
Я немного о другом. Кинозал демонстрирует полную открытость: вот сеанс, вот карта свободных мест. Нет свободных мест на эту дату - выбирай на другую. Авиакомпания - аналогично, с той только разницей, что места выбирать нельзя. Если же мы хотим, чтобы нам что-то произвели, то все не так прозрачно.