 |
В предыдущей статье речь шла о том, что кросс-функциональные процессы, как правило, невозможно реализовать, пользуясь только оркестровкой (иными словами, оставаясь в пределах одного пула BPMN). Границы между подразделениями существуют объективно, отражая различия в порядке и ритме работы, характерные для разных видов деятельности. Эти различия приводят к тому, что фрагменты процесса, выполняемые каждым подразделением, технически реализуются отдельными пулами, а кросс-функциональный процесс целиком — совокупностью пулов, взаимодействующих через сообщения или данные.
В данной статье мы рассмотрим паттерны, характерные для кросс-функциональных процессов.
Воспользуемся следующим примером:
В рамках текущего финансового планирования все счета, полученные компанией, сначала рассматриваются в финансовом отделе: определяется правомерность требования об оплате, уточняются сумма и срок платежа, в соответствии с установленными бизнес-правилами назначается приоритетность каждого требования. Затем требования на оплату поступают на утверждение финансовому директору, который принимает решение об оплате, сообразуясь с приоритетностью, суммой и сроком.
В простейшем виде процессная диаграмма может выглядеть так:
Рис. 1. Синхронный процесс
В реальной жизни компании зачастую устанавливают дифференцированный порядок для разных счетов: например, счета на сумму ниже какого-то предела или требования об уплате налогов проходят без утверждения. Также некоторые счета могут не пройти проверку и отвергаться, не поступая к финансовому директору. От всего этого мы абстрагируемся.
1. Планирование единственного ресурса
В данном случае нас интересует другой аспект: предположим, что компания ограничена в оборотных средствах. И возможна ситуация, когда счета, не оспариваемые ни по сумме, ни по срокам, тем не менее не могут быть оплачены вовремя, и компания принимает решение о задержке платежа — вынужденно или пользуясь терпением кредитора.
Принципиальный момент: невозможно квалифицированно принять такое решения по одному отдельно взятому счету. Разумный алгоритм действий лица, принимающего решение, следующий: собрать все счета к оплате за период (скажем, на сегодня или на наступающую неделю), проанализировать общую ситуацию — сколько у нас средств и сколько предъявлено счетов — и в зависимости от ситуации принять решение: какие счета оплачивать, а с какими повременить.
Схема процесса для такого алгоритма действий:
Рис. 2. Планирование ресурса
Для тех, кто не вполне владеет BPMN, даю пояснения к схеме:
- После проверки счет помещается в базу данных, а процесс обработки счета переходит в состояние ожидания наступления первого из трех возможных событий: приход сообщения о том, что счет одобрен; приход сообщения о том, что счет отвергнут (платить не будем) или таймаута (для общности).
- Одобрение счетов выполняется в рамках самостоятельного процесса планирования платежей, который запускается с определенной периодичностью (например, ежедневно или еженедельно). Первым шагом автоматически выбираются из базы накопившиеся счета с датой оплаты, попадающей в запрошенный период. Отобранные счета представляются в виде списка финансовому директору, и он может для каждого из них выбрать один из трех вариантов действий: "оплатить", "отказать", "отложить".
- После того, как он это сделал и нажал кнопку "Готово", экземплярам процесса процесса обработки счетов, для которых выбрано "оплатить" или "отказать", автоматически шлется сообщение о том, что счет одобрен или отвергнут, а соответствующие записи в базе данных счетов помечаются как обработанные. Счета, для которых выбрано "отложить", остаются неизменными, и они снова попадают в выборку при следующем запуске процесса планирования.
Если счет одобрен, процесс обработки автоматически выполняет финансовую транзакцию.
Процессные диаграммы, похожие изображенную на рис.2, регулярно появляются на этом блоге. И это не случайно: если меня попросить назвать один самый полезный процессный паттерн, то я выберу этот.
В принципе, несколько названий для одного паттерна — это не только не плохо, а наоборот, очень хорошо: чем больше названий, тем с большим количеством «картинок» окружающего мира он у нас ассоциируется, тем шире мы его применяем.
- Некоторые используют также термин «Групповая обработка», но мне он не нравится: слишком общо, может означать все что угодно.
2. Оптимистичное планирование
Какая из диаграмм на рис. 1 и 2 лучше? Правильнее? Однозначного ответа нет — зависит от того, что для нас является приоритетом:
- если приоритет — скорость обработки (обработки счета в данном случае), то предпочтительна схема 1
- если приоритет — эффективное использование ресурса, то предпочтительна схема 2
Вообще, вопрос «или-или» не стоит — можно ведь реализовать и комбинированную схему:
Рис. 3. Оптимистичное планирование
В данной схеме каждый счет рассматривается дважды: сначала синхронно, в рамках процесса обработки счета, затем — если необходимо — в рамках планирования ресурсов.
- Процесс финансового планирования проверяет, достаточно ли средств, чтобы оплатить все предварительно одобренные счета, и назначает задание финансовому директору только в тех предположительно редких случаях, когда средств оказывается недостаточно.
Эту схему целесообразно использовать тогда, когда ресурса достаточно «почти всегда». Ее преимущество, с одной стороны, в том, что счета одобряются без задержки, а с другой — если средств на оплату всех счетов не хватает, то остается возможность в последний момент отменить оплату каких-то счетов.
- Получив предварительное одобрение, процесс обработки счета может совершить какие-то действия (на схеме не показаны) — например, уведомить поставщика о том, что счет направлен в оплату.
- Соответственно, надо предусмотреть обработку исключительной ситуации: если в итоге оплата счета была отменена, то нужно сообщить об этом поставщику.
3. Планирование нескольких ресурсов
Другое направление развития диаграммы — обобщение на случай нескольких ресурсов. Например, компания может производить оплату из денежных средств, размещенных в разных банках.
Рис. 4. Планирование нескольких ресурсов
В этой схеме финансовый отдел, проверяя счет, одновременно готовит решение о том, с какого из расчетных счетов его оплачивать (вероятно, руководствуясь при этом определенными бизнес-правилами).
- Финансовый директор, одобряя счет, может согласиться с предложением финансового отдела или перебросить счет на другой банк.
- После того, как решение по всем счетам принято, процесс планирования формирует ведомость для каждого банка и для каждой запускает процесс оплаты — уже не отдельного счета, а всех счетов по указанному банку на указанную дату.
Как видим, в этой схеме разделены процессы обработки счета, планирования оплаты и собственно оплаты. Это дает возможность планировать разные ресурсы или один и тот же ресурс, но на разные даты: например, финансовый директор может запланировать платежи на сегодня и на завтра. Процесс оплаты дождется наступления заданного времени (таймер на схеме) и произведет оплату всех счетов.
Для оплаты счетов это выглядит несколько искусственно, но представьте себе планирование нескольких производственных линий. На выходе процесса планирования — сменное задание для каждой линии, включающее последовательность выполнения поступивших заказов. Естественно трактовать выполнение сменного задания как отдельный процесс. Процесс планирования запускает процесс выполнения сменного задания для каждой линии и на этом заканчивает свою работу. Причем если с понедельника по четверг составляются задания на следующий день, то в пятницу планируется производство в субботу, воскресенье и понедельник.
Вообще, рассмотренный пример — это не кросс-функциональный процесс в полном смысле слова: ведь и финансовый отдел, и финансовый директор — это, в принципе, одно и то же подразделение. Но суть не в этом, а в том, что мы имеем дело с процессом, использующим некоторый ограниченный ресурс — в данном случае финансовый.
- Подобная ситуация возникает всегда, когда процесс пересекает границу между подразделениями: клиентский заказ требует активности от производства, производство требует закупки материалов снабжением, разработка новой продукции требует маркетингового исследования, обработка рекламации требует внесения изменений в инструкцию пользователя и т.п.
- Но и в более мелком масштабе происходит то же самое: например, ограниченным ресурсом может быть время руководителя. Люди на высоких должностях всегда очень заняты, поэтому если какому-то процессу требуется утверждение или подпись директора, то будьте готовы к тому, что он предпочтет утверждать списком, а не каждый запрос по отдельности.
С этой точки зрения, в рассмотренном примере мы за счет буферизации повысили эффективность использования сразу двух ресурсов: и оборотного капитала, и финансового директора.
Окончание следует...
Об авторе:
|
|
