Пора возвращать долги - как обещал, возвращаюсь к теме моделирования кросс-функциональных процессов.
Напомню: в первой части речь шла о том, что кросс-функциональные процессы, как правило, невозможно реализовать, пользуясь только оркестровкой (иными словами, оставаясь в пределах одного пула BPMN). Границы между подразделениями существуют объективно, отражая различия в порядке и ритме работы, характерные для разных видов деятельности. Эти различия приводят к тому, что фрагменты процесса, выполняемые каждым подразделением, технически реализуются отдельными пулами, а кросс-функциональный процесс целиком - совокупностью пулов, взаимодействующих через сообщения или данные.
В данной статье мы рассмотрим паттерны, характерные для кросс-функциональных процессов.
Воспользуемся следующим примером:
В рамках текущего финансового планирования все счета, полученные компанией, сначала рассматриваются в финансовом отделе: определяется правомерность требования об оплате, уточняются сумма и срок платежа, в соответствии с установленными бизнес-правилами назначается приоритетность каждого требования. Затем требования на оплату поступают на утверждение финансовому директору, который принимает решение об оплате, сообразуясь с приоритетностью, суммой и сроком.
В простейшем виде процессная диаграмма может выглядеть так:
Рис. 1. Синхронный процесс
В реальной жизни компании зачастую устанавливают дифференцированный порядок для разных счетов: например, счета на сумму ниже какого-то предела или требования об уплате налогов проходят без утверждения. Также некоторые счета могут не пройти проверку и отвергаться, не поступая к финансовому директору. От всего этого мы абстрагируемся.
1. Планирование единственного ресурса
В данном случае нас интересует другой аспект: предположим, что компания ограничена в оборотных средствах. И возможна ситуация, когда счета, не оспариваемые ни по сумме, ни по срокам, тем не менее не могут быть оплачены вовремя, и компания принимает решение о задержке платежа - вынужденно или пользуясь терпением кредитора.
Принципиальный момент: невозможно квалифицированно принять такое решения по одному отдельно взятому счету. Разумный алгоритм действий лица, принимающего решение, следующий: собрать все счета к оплате за период (скажем, на сегодня или на наступающую неделю), проанализировать общую ситуацию - сколько у нас средств и сколько предъявлено счетов - и в зависимости от ситуации принять решение: какие счета оплачивать, а с какими повременить.
Схема процесса для такого алгоритма действий:
Рис. 2. Планирование ресурса
Для тех, кто не вполне владеет BPMN, даю пояснения к схеме:
- После проверки счет помещается в базу данных, а процесс обработки счета переходит в состояние ожидания наступления первого из трех возможных событий: приход сообщения о том, что счет одобрен; приход сообщения о том, что счет отвергнут (платить не будем) или таймаута (для общности).
- Одобрение счетов выполняется в рамках самостоятельного процесса планирования платежей, который запускается с определенной периодичностью (например, ежедневно или еженедельно). Первым шагом автоматически выбираются из базы накопившиеся счета с датой оплаты, попадающей в запрошенный период. Отобранные счета представляются в виде списка финансовому директору, и он может для каждого из них выбрать один из трех вариантов действий: “оплатить”, “отказать”, “отложить”.
- После того, как он это сделал и нажал кнопку “Готово”, экземплярам процесса процесса обработки счетов, для которых выбрано “оплатить” или “отказать”, автоматически шлется сообщение о том, что счет одобрен или отвергнут, а соответствующие записи в базе данных счетов помечаются как обработанные. Счета, для которых выбрано “отложить”, остаются неизменными, и они снова попадают в выборку при следующем запуске процесса планирования.
- Если счет одобрен, процесс обработки автоматически выполняет финансовую транзакцию.
Процессные диаграммы, похожие изображенную на рис.2, регулярно появляются на этом блоге. И это не случайно: если меня попросить назвать один самый полезный процессный паттерн, то я выберу этот.
- Алексадр Самарин называет его «CPP - Collect and Periodically Process».
- Мне больше нравится название «Планирование ресурса».
- Еще вариант: «Буфер заказов».
В принципе, несколько названий для одного паттерна - это не только не плохо, а наоборот, очень хорошо: чем больше названий, тем с большим количеством «картинок» окружающего мира он у нас ассоциируется, тем шире мы его применяем.
- Некоторые используют также термин «Групповая обработка», но мне он не нравится: слишком общо, может означать все что угодно.
2. Оптимистичное планирование
Какая из диаграмм на рис. 1 и 2 лучше? Правильнее? Однозначного ответа нет - зависит от того, что для нас является приоритетом:
- если приоритет - скорость обработки (обработки счета в данном случае), то предпочтительна схема 1
- если приоритет - эффективное использование ресурса, то предпочтительна схема 2
Вообще, вопрос «или-или» не стоит - можно ведь реализовать и комбинированную схему:
Рис. 3. Оптимистичное планирование
В данной схеме каждый счет рассматривается дважды: сначала синхронно, в рамках процесса обработки счета, затем - если необходимо - в рамках планирования ресурсов.
- Процесс финансового планирования проверяет, достаточно ли средств, чтобы оплатить все предварительно одобренные счета, и назначает задание финансовому директору только в тех предположительно редких случаях, когда средств оказывается недостаточно.
Эту схему целесообразно использовать тогда, когда ресурса достаточно «почти всегда». Ее преимущество, с одной стороны, в том, что счета одобряются без задержки, а с другой - если средств на оплату всех счетов не хватает, то остается возможность в последний момент отменить оплату каких-то счетов.
- Получив предварительное одобрение, процесс обработки счета может совершить какие-то действия (на схеме не показаны) - например, уведомить поставщика о том, что счет направлен в оплату.
- Соответственно, надо предусмотреть обработку исключительной ситуации: если в итоге оплата счета была отменена, то нужно сообщить об этом поставщику.
3. Планирование нескольких ресурсов
Другое направление развития диаграммы - обобщение на случай нескольких ресурсов. Например, компания может производить оплату из денежных средств, размещенных в разных банках.
Рис. 4. Планирование нескольких ресурсов
В этой схеме финансовый отдел, проверяя счет, одновременно готовит решение о том, с какого из расчетных счетов его оплачивать (вероятно, руководствуясь при этом определенными бизнес-правилами).
- Финансовый директор, одобряя счет, может согласиться с предложением финансового отдела или перебросить счет на другой банк.
- После того, как решение по всем счетам принято, процесс планирования формирует ведомость для каждого банка и для каждой запускает процесс оплаты - уже не отдельного счета, а всех счетов по указанному банку на указанную дату.
Как видим, в этой схеме разделены процессы обработки счета, планирования оплаты и собственно оплаты. Это дает возможность планировать разные ресурсы или один и тот же ресурс, но на разные даты: например, финансовый директор может запланировать платежи на сегодня и на завтра. Процесс оплаты дождется наступления заданного времени (таймер на схеме) и произведет оплату всех счетов.
Для оплаты счетов это выглядит несколько искусственно, но представьте себе планирование нескольких производственных линий. На выходе процесса планирования - сменное задание для каждой линии, включающее последовательность выполнения поступивших заказов. Естественно трактовать выполнение сменного задания как отдельный процесс. Процесс планирования запускает процесс выполнения сменного задания для каждой линии и на этом заканчивает свою работу. Причем если с понедельника по четверг составляются задания на следующий день, то в пятницу планируется производство в субботу, воскресенье и понедельник.
Вообще, рассмотренный пример - это не кросс-функциональный процесс в полном смысле слова: ведь и финансовый отдел, и финансовый директор - это, в принципе, одно и то же подразделение. Но суть не в этом, а в том, что мы имеем дело с процессом, использующим некоторый ограниченный ресурс - в данном случае финансовый.
- Подобная ситуация возникает всегда, когда процесс пересекает границу между подразделениями: клиентский заказ требует активности от производства, производство требует закупки материалов снабжением, разработка новой продукции требует маркетингового исследования, обработка рекламации требует внесения изменений в инструкцию пользователя и т.п.
- Но и в более мелком масштабе происходит то же самое: например, ограниченным ресурсом может быть время руководителя. Люди на высоких должностях всегда очень заняты, поэтому если какому-то процессу требуется утверждение или подпись директора, то будьте готовы к тому, что он предпочтет утверждать списком, а не каждый запрос по отдельности.
С этой точки зрения, в рассмотренном примере мы за счет буферизации повысили эффективность использования сразу двух ресурсов: и оборотного капитала, и финансового директора.
Окончание следует
В завершающей части я собираюсь порассуждать на тему: чем следует руководствоваться, выбирая тот или иной из рассмотренных паттернов.
Статья весьма познавательная. Можно использовать подобные подходы для оценки доступности и планирования денег и материальных ресурсов. Однако, меня в большей степени интересуют вопросы управления трудовыми ресурсами.
Давайте представим себе, что одна и та же операция в некотором бизнес-процессе может выполняться не одним человеком, а несколькими (например, работниками одного отдела). Каждый из них является пользователем 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 лет, чтобы обеспечить постоянство качества и непрерывность поставки в необходимых объемах
Я немного о другом. Кинозал демонстрирует полную открытость: вот сеанс, вот карта свободных мест. Нет свободных мест на эту дату - выбирай на другую. Авиакомпания - аналогично, с той только разницей, что места выбирать нельзя. Если же мы хотим, чтобы нам что-то произвели, то все не так прозрачно.