 |
 |
Рубрикатор |
 |
 |
Облако терминов |
 |
 |
Опрос |
 |
|
 |
 |
 |
Библиотека |
 |
08.03.2011 12:10 |
 |
от автора
Кросс-функциональные паттерны
Оценки за материал: 5.00 (1)
Это продолжение исследования на тему моделирования и оптимизации кросс-функциональных бизнес-процессов. Перепечатка с блога автора.
В первой части речь шла о том, что кросс-функциональные процессы, как правило, невозможно реализовать, пользуясь только оркестровкой (иными словами, оставаясь в пределах одного пула BPMN). Границы между подразделениями существуют объективно, отражая различия в порядке и ритме работы, характерные для разных видов деятельности. Эти различия приводят к тому, что фрагменты процесса, выполняемые каждым подразделением, технически реализуются отдельными пулами, а кросс-функциональный процесс целиком - совокупностью пулов, взаимодействующих через сообщения или данные.
В данной статье мы рассмотрим паттерны, характерные для кросс-функциональных процессов.
Воспользуемся следующим примером:
В рамках текущего финансового планирования все счета, полученные компанией, сначала рассматриваются в финансовом отделе: определяется правомерность требования об оплате, уточняются сумма и срок платежа, в соответствии с установленными бизнес-правилами назначается приоритетность каждого требования. Затем требования на оплату поступают на утверждение финансовому директору, который принимает решение об оплате, сообразуясь с приоритетностью, суммой и сроком.
В простейшем виде процессная диаграмма может выглядеть так:

Рис. 1. Синхронный процесс
В реальной жизни компании зачастую устанавливают дифференцированный порядок для разных счетов: например, счета на сумму ниже какого-то предела или требования об уплате налогов проходят без утверждения. Также некоторые счета могут не пройти проверку и отвергаться, не поступая к финансовому директору. От всего этого мы абстрагируемся.
1. Планирование единственного ресурса
В данном случае нас интересует другой аспект: предположим, что компания ограничена в оборотных средствах. И возможна ситуация, когда счета, не оспариваемые ни по сумме, ни по срокам, тем не менее не могут быть оплачены вовремя, и компания принимает решение о задержке платежа - вынужденно или пользуясь терпением кредитора.
Принципиальный момент: невозможно квалифицированно принять такое решения по одному отдельно взятому счету. Разумный алгоритм действий лица, принимающего решение, следующий: собрать все счета к оплате за период (скажем, на сегодня или на наступающую неделю), проанализировать общую ситуацию - сколько у нас средств и сколько предъявлено счетов - и в зависимости от ситуации принять решение: какие счета оплачивать, а с какими повременить.
Схема процесса для такого алгоритма действий:

Рис. 2. Планирование ресурса
Для тех, кто не вполне владеет BPMN, даю пояснения к схеме:
- После проверки счет помещается в базу данных, а процесс обработки счета переходит в состояние ожидания наступления первого из трех возможных событий: приход сообщения о том, что счет одобрен; приход сообщения о том, что счет отвергнут (платить не будем) или таймаута (для общности).
- Одобрение счетов выполняется в рамках самостоятельного процесса планирования платежей, который запускается с определенной периодичностью (например, ежедневно или еженедельно). Первым шагом автоматически выбираются из базы накопившиеся счета с датой оплаты, попадающей в запрошенный период. Отобранные счета представляются в виде списка финансовому директору, и он может для каждого из них выбрать один из трех вариантов действий: “оплатить”, “отказать”, “отложить”.
- После того, как он это сделал и нажал кнопку “Готово”, экземплярам процесса процесса обработки счетов, для которых выбрано “оплатить” или “отказать”, автоматически шлется сообщение о том, что счет одобрен или отвергнут, а соответствующие записи в базе данных счетов помечаются как обработанные. Счета, для которых выбрано “отложить”, остаются неизменными, и они снова попадают в выборку при следующем запуске процесса планирования.
- Если счет одобрен, процесс обработки автоматически выполняет финансовую транзакцию.
Процессные диаграммы, похожие изображенную на рис.2, регулярно встречаются на практике. Если меня попросить назвать один самый полезный процессный паттерн, то я выберу этот.
В принципе, несколько названий для одного паттерна - это не только не плохо, а наоборот, очень хорошо: чем больше названий, тем с большим количеством «картинок» окружающего мира он у нас ассоциируется, тем шире мы его применяем.
- Некоторые используют также термин «Групповая обработка», но мне он не нравится: слишком общо, может означать все что угодно.
2. Оптимистичное планирование
Какая из диаграмм на рис. 1 и 2 лучше? Правильнее? Однозначного ответа нет - зависит от того, что для нас является приоритетом:
- если приоритет - скорость обработки (обработки счета в данном случае), то предпочтительна схема 1
- если приоритет - эффективное использование ресурса, то предпочтительна схема 2
Вообще, вопрос «или-или» не стоит - можно ведь реализовать и комбинированную схему:

Рис. 3. Оптимистичное планирование
В данной схеме каждый счет рассматривается дважды: сначала синхронно, в рамках процесса обработки счета, затем - если необходимо - в рамках планирования ресурсов.
- Процесс финансового планирования проверяет, достаточно ли средств, чтобы оплатить все предварительно одобренные счета, и назначает задание финансовому директору только в тех предположительно редких случаях, когда средств оказывается недостаточно.
Эту схему целесообразно использовать тогда, когда ресурса достаточно «почти всегда». Ее преимущество, с одной стороны, в том, что счета одобряются без задержки, а с другой - если средств на оплату всех счетов не хватает, то остается возможность в последний момент отменить оплату каких-то счетов.
- Получив предварительное одобрение, процесс обработки счета может совершить какие-то действия (на схеме не показаны) - например, уведомить поставщика о том, что счет направлен в оплату.
- Соответственно, надо предусмотреть обработку исключительной ситуации: если в итоге оплата счета была отменена, то нужно сообщить об этом поставщику.
3. Планирование нескольких ресурсов
Другое направление развития диаграммы - обобщение на случай нескольких ресурсов. Например, компания может производить оплату из денежных средств, размещенных в разных банках.

Рис. 4. Планирование нескольких ресурсов
В этой схеме финансовый отдел, проверяя счет, одновременно готовит решение о том, с какого из расчетных счетов его оплачивать (вероятно, руководствуясь при этом определенными бизнес-правилами).
- Финансовый директор, одобряя счет, может согласиться с предложением финансового отдела или перебросить счет на другой банк.
- После того, как решение по всем счетам принято, процесс планирования формирует ведомость для каждого банка и для каждой запускает процесс оплаты - уже не отдельного счета, а всех счетов по указанному банку на указанную дату.
Как видим, в этой схеме разделены процессы обработки счета, планирования оплаты и собственно оплаты. Это дает возможность планировать разные ресурсы или один и тот же ресурс, но на разные даты: например, финансовый директор может запланировать платежи на сегодня и на завтра. Процесс оплаты дождется наступления заданного времени (таймер на схеме) и произведет оплату всех счетов.
Для оплаты счетов это выглядит несколько искусственно, но представьте себе планирование нескольких производственных линий. На выходе процесса планирования - сменное задание для каждой линии, включающее последовательность выполнения поступивших заказов. Естественно трактовать выполнение сменного задания как отдельный процесс. Процесс планирования запускает процесс выполнения сменного задания для каждой линии и на этом заканчивает свою работу. Причем если с понедельника по четверг составляются задания на следующий день, то в пятницу планируется производство в субботу, воскресенье и понедельник.
Вообще, рассмотренный пример - это не кросс-функциональный процесс в полном смысле слова: ведь и финансовый отдел, и финансовый директор - это, в принципе, одно и то же подразделение. Но суть не в этом, а в том, что мы имеем дело с процессом, использующим некоторый ограниченный ресурс - в данном случае финансовый.
- Подобная ситуация возникает всегда, когда процесс пересекает границу между подразделениями: клиентский заказ требует активности от производства, производство требует закупки материалов снабжением, разработка новой продукции требует маркетингового исследования, обработка рекламации требует внесения изменений в инструкцию пользователя и т.п.
- Но и в более мелком масштабе происходит то же самое: например, ограниченным ресурсом может быть время руководителя. Люди на высоких должностях всегда очень заняты, поэтому если какому-то процессу требуется утверждение или подпись директора, то будьте готовы к тому, что он предпочтет утверждать списком, а не каждый запрос по отдельности.
С этой точки зрения, в рассмотренном примере мы за счет буферизации повысили эффективность использования сразу двух ресурсов: и оборотного капитала, и финансового директора.
Комментарии
Оценки:
/
 |
12.03.2011 10:21 |
 |
от автора
Спасибо автору за интересную статью!
Вопрос такой. Если процесс грамотно нарисован при помощи обычной кросс-функциональной схемы ("простая блок-схема" в MS Visio), насколько сложно и долго переделать схему в нотации BPMN 2?
Оценки:
/
 |
14.03.2011 19:45 |
 |
от автора
Перерисовать один-в-один недолго. Вопрос в том, что понимать под "грамотно". В блок-схеме, даже грамотной, всегда есть большие люфты. Один и тот же бизнес-процесс два разных бизнес-аналитиков никогда не нарисуют одинаково.
В случае BPMN все гораздо более строго и определенно. У меня на тренинге слушатель выходит к доске и говорит "я - движок бизнес-процесса. Начинаю исполнять представленную схему процесса." Тут нет места для волюнтаризма: что нарисовано, то и исполняем.
Возвращаясь к вопросу, мне еще не доводилось видеть "простую блок-схему", которая была бы грамотной с точки зрения BPMN: стрелки, означающие непонятно что; несколько процессов, прикидывающихся одним и т.д. и т.п. Резюмируя: если под BPMN понимать только нотацию, то легко и быстро. Если подход к процессному анализу, то тяжело и долго, но на выходе получается качественно другой результат.
Оценки:
/
 |
15.03.2011 18:32 |
 |
от автора
>>"я - движок бизнес-процесса. Начинаю исполнять представленную схему процесса." Тут нет места для волюнтаризма: что нарисовано, то и исполняем.
Да, но исполняем с точки зрения именно шагов процесса. Здесь нет никаких трудностей изобразить это и на блок-схеме. Но по какому принципу, например, финансовый директор одобряет платежи остается за кадром. Нужны дополнительные методические инструкции.
Я проблему предвижу в другой плоскости:
1. Не соответствие границ процессов при переводе их из любой нотации в BPMN для исполнения в BPM системе.
2. Не соответствие структуры шагов процессов. Имеется ввиду, блок-схемы, как правило, содержат избыточную информацию с точки зрения BPMN, т.к. часто касаются методических вопросов выполнения шагов. В BPMN, же с одной стороны, этого не нужно, поэтому в нем 3 шага могут схлопнуться в один, с другой - в BPMN схему встраиваются вспомогательные технические шаги.
Просто посадить человека именно работать, а не нажимать кнопки "Одобрить", "Отклонить" в BPM системе нельзя. Дополнительно нужны методические материалы - рабочие инструкции и т.п.
Оценки:
/
 |
08.04.2011 17:01 |
 |
от автора
Спасибо автору за хорошее описание ключевой проблемы процессной организации. Действительно, вопрос не столько в "правильно-неправильно", сколько в приоритетах и критериях эффективности.
По мере увеличения зрелости процесса он может усложняться.
Но так же растет и зрелость всего пула процессов (организации), для которой важны расходы на поддержку реорганизаций и наиболее эффективное и рациональное изменение используемых процессов (менять только то, что действительно нужно, закладывать такую гибкость, которая снижает потребность в изменениях, не увеличивая при этом совокупных издержек как на выполнение процесса, так и на развитие самой процессной модели)
Оценки:
/
 |
08.04.2011 17:05 |
 |
от автора
Дмитрий Пинаев, процессная модель не определяет сама по себе регламенты, которые функционально очевидны (не имеют отношения к организации взаимодействия процессов). В случае, когда необходимо регламентировать процесс одобрения, он так же может быть детализирован (или декомпозирован, в зависимости от парадигмы моделирования процесса).
Например, мы можем сказать, что процесс одобрения платежа происходит с использованием платежного календаря, контроля лимита по актуальному бюджету, визированию ответственными по ЦФО и по направлениям (что они согласны с необходимостью этого самого платежа в это самое время)
Паттерн (шаблон) предполагает сущностную информацию о процессе, он не ограничивает детали реализации отдельных процедур.
Добавить комментарий
Комментировать материалы могут только зарегистрированные пользователи.
Вы можете зарегистрироваться здесь.
|
 |