Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Digital Directum

Опрос

Польза от регламентации процессов для бизнеса:

Библиотека

08.03.2011 12:10
  от автора
  bell

Кросс-функциональные паттерны

Оценки за материал: 5.00 (1)

Это продолжение исследования на тему моделирования и оптимизации кросс-функциональных бизнес-процессов. Перепечатка с блога автора.

В первой части речь шла о том, что кросс-функциональные процессы, как правило, невозможно реализовать, пользуясь только оркестровкой (иными словами, оставаясь в пределах одного пула BPMN). Границы между подразделениями существуют объективно, отражая различия в порядке и ритме работы, характерные для разных видов деятельности. Эти различия приводят к тому, что фрагменты процесса, выполняемые каждым подразделением, технически реализуются отдельными пулами, а кросс-функциональный процесс целиком - совокупностью пулов, взаимодействующих через сообщения или данные.

В данной статье мы рассмотрим паттерны, характерные для кросс-функциональных процессов.
Воспользуемся следующим примером:

В рамках текущего финансового планирования все счета, полученные компанией, сначала рассматриваются в финансовом отделе: определяется правомерность требования об оплате, уточняются сумма и срок платежа, в соответствии с установленными бизнес-правилами назначается приоритетность каждого требования. Затем требования на оплату поступают на утверждение финансовому директору, который принимает решение об оплате, сообразуясь с приоритетностью, суммой и сроком.

В простейшем виде процессная диаграмма может выглядеть так:


Рис. 1. Синхронный процесс

В реальной жизни компании зачастую устанавливают дифференцированный порядок для разных счетов: например, счета на сумму ниже какого-то предела или требования об уплате налогов проходят без утверждения. Также некоторые счета могут не пройти проверку и отвергаться, не поступая к финансовому директору. От всего этого мы абстрагируемся.

1. Планирование единственного ресурса

В данном случае нас интересует другой аспект: предположим, что компания ограничена в оборотных средствах. И возможна ситуация, когда счета, не оспариваемые ни по сумме, ни по срокам, тем не менее не могут быть оплачены вовремя, и компания принимает решение о задержке платежа - вынужденно или пользуясь терпением кредитора.

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

Схема процесса для такого алгоритма действий:


Рис. 2. Планирование ресурса

Для тех, кто не вполне владеет BPMN, даю пояснения к схеме:

  1. После проверки счет помещается в базу данных, а процесс обработки счета переходит в состояние ожидания наступления первого из трех возможных событий: приход сообщения о том, что счет одобрен; приход сообщения о том, что счет отвергнут (платить не будем) или таймаута (для общности).
  2. Одобрение счетов выполняется в рамках самостоятельного процесса планирования платежей, который запускается с определенной периодичностью (например, ежедневно или еженедельно). Первым шагом автоматически выбираются из базы накопившиеся счета с датой оплаты, попадающей в запрошенный период. Отобранные счета представляются в виде списка финансовому директору, и он может для каждого из них выбрать один из трех вариантов действий: “оплатить”, “отказать”, “отложить”.
  3. После того, как он это сделал и нажал кнопку “Готово”, экземплярам процесса процесса обработки счетов, для которых выбрано “оплатить” или “отказать”, автоматически шлется сообщение о том, что счет одобрен или отвергнут, а соответствующие записи в базе данных счетов помечаются как обработанные. Счета, для которых выбрано “отложить”, остаются неизменными, и они снова попадают в выборку при следующем запуске процесса планирования.
  4. Если счет одобрен, процесс обработки автоматически выполняет финансовую транзакцию.


Процессные диаграммы, похожие изображенную на рис.2, регулярно встречаются на практике. Если меня попросить назвать один самый полезный процессный паттерн, то я выберу этот.

  • Алексадр Самарин называет его «CPP - Collect and Periodically Process».
  • Мне больше нравится название «Планирование ресурса».
  • Еще вариант: «Буфер заказов».


В принципе, несколько названий для одного паттерна - это не только не плохо, а наоборот, очень хорошо: чем больше названий, тем с большим количеством «картинок» окружающего мира он у нас ассоциируется, тем шире мы его применяем.


  • Некоторые используют также термин «Групповая обработка», но мне он не нравится: слишком общо, может означать все что угодно.


2. Оптимистичное планирование

Какая из диаграмм на рис. 1 и 2 лучше? Правильнее? Однозначного ответа нет - зависит от того, что для нас является приоритетом:

  • если приоритет - скорость обработки (обработки счета в данном случае), то предпочтительна схема 1
  • если приоритет - эффективное использование ресурса, то предпочтительна схема 2


Вообще, вопрос «или-или» не стоит - можно ведь реализовать и комбинированную схему:


Рис. 3. Оптимистичное планирование

В данной схеме каждый счет рассматривается дважды: сначала синхронно, в рамках процесса обработки счета, затем - если необходимо - в рамках планирования ресурсов.

  • Процесс финансового планирования проверяет, достаточно ли средств, чтобы оплатить все предварительно одобренные счета, и назначает задание финансовому директору только в тех предположительно редких случаях, когда средств оказывается недостаточно.


Эту схему целесообразно использовать тогда, когда ресурса достаточно «почти всегда». Ее преимущество, с одной стороны, в том, что счета одобряются без задержки, а с другой - если средств на оплату всех счетов не хватает, то остается возможность в последний момент отменить оплату каких-то счетов.

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


3. Планирование нескольких ресурсов

Другое направление развития диаграммы - обобщение на случай нескольких ресурсов. Например, компания может производить оплату из денежных средств, размещенных в разных банках.


Рис. 4. Планирование нескольких ресурсов

В этой схеме финансовый отдел, проверяя счет, одновременно готовит решение о том, с какого из расчетных счетов его оплачивать (вероятно, руководствуясь при этом определенными бизнес-правилами).

  • Финансовый директор, одобряя счет, может согласиться с предложением финансового отдела или перебросить счет на другой банк.
  • После того, как решение по всем счетам принято, процесс планирования формирует ведомость для каждого банка и для каждой запускает процесс оплаты - уже не отдельного счета, а всех счетов по указанному банку на указанную дату.


Как видим, в этой схеме разделены процессы обработки счета, планирования оплаты и собственно оплаты. Это дает возможность планировать разные ресурсы или один и тот же ресурс, но на разные даты: например, финансовый директор может запланировать платежи на сегодня и на завтра. Процесс оплаты дождется наступления заданного времени (таймер на схеме) и произведет оплату всех счетов.

Для оплаты счетов это выглядит несколько искусственно, но представьте себе планирование нескольких производственных линий. На выходе процесса планирования - сменное задание для каждой линии, включающее последовательность выполнения поступивших заказов. Естественно трактовать выполнение сменного задания как отдельный процесс. Процесс планирования запускает процесс выполнения сменного задания для каждой линии и на этом заканчивает свою работу. Причем если с понедельника по четверг составляются задания на следующий день, то в пятницу планируется производство в субботу, воскресенье и понедельник.

Вообще, рассмотренный пример - это не кросс-функциональный процесс в полном смысле слова: ведь и финансовый отдел, и финансовый директор - это, в принципе, одно и то же подразделение. Но суть не в этом, а в том, что мы имеем дело с процессом, использующим некоторый ограниченный ресурс - в данном случае финансовый.

  • Подобная ситуация возникает всегда, когда процесс пересекает границу между подразделениями: клиентский заказ требует активности от производства, производство требует закупки материалов снабжением, разработка новой продукции требует маркетингового исследования, обработка рекламации требует внесения изменений в инструкцию пользователя и т.п.
  • Но и в более мелком масштабе происходит то же самое: например, ограниченным ресурсом может быть время руководителя. Люди на высоких должностях всегда очень заняты, поэтому если какому-то процессу требуется утверждение или подпись директора, то будьте готовы к тому, что он предпочтет утверждать списком, а не каждый запрос по отдельности.


С этой точки зрения, в рассмотренном примере мы за счет буферизации повысили эффективность использования сразу двух ресурсов: и оборотного капитала, и финансового директора.

Комментарии

Оценки: /
12.03.2011 10:21
  от автора
  Репин
Спасибо автору за интересную статью!

Вопрос такой. Если процесс грамотно нарисован при помощи обычной кросс-функциональной схемы ("простая блок-схема" в MS Visio), насколько сложно и долго переделать схему в нотации BPMN 2?
Оценки: /
14.03.2011 19:45
  от автора
  bell
Перерисовать один-в-один недолго. Вопрос в том, что понимать под "грамотно". В блок-схеме, даже грамотной, всегда есть большие люфты. Один и тот же бизнес-процесс два разных бизнес-аналитиков никогда не нарисуют одинаково.

В случае BPMN все гораздо более строго и определенно. У меня на тренинге слушатель выходит к доске и говорит "я - движок бизнес-процесса. Начинаю исполнять представленную схему процесса." Тут нет места для волюнтаризма: что нарисовано, то и исполняем.

Возвращаясь к вопросу, мне еще не доводилось видеть "простую блок-схему", которая была бы грамотной с точки зрения BPMN: стрелки, означающие непонятно что; несколько процессов, прикидывающихся одним и т.д. и т.п. Резюмируя: если под BPMN понимать только нотацию, то легко и быстро. Если подход к процессному анализу, то тяжело и долго, но на выходе получается качественно другой результат.
Оценки: /
15.03.2011 18:32
  от автора
  Дмитрий Пинаев
>>"я - движок бизнес-процесса. Начинаю исполнять представленную схему процесса." Тут нет места для волюнтаризма: что нарисовано, то и исполняем.
Да, но исполняем с точки зрения именно шагов процесса. Здесь нет никаких трудностей изобразить это и на блок-схеме. Но по какому принципу, например, финансовый директор одобряет платежи остается за кадром. Нужны дополнительные методические инструкции.

Я проблему предвижу в другой плоскости:
1. Не соответствие границ процессов при переводе их из любой нотации в BPMN для исполнения в BPM системе.
2. Не соответствие структуры шагов процессов. Имеется ввиду, блок-схемы, как правило, содержат избыточную информацию с точки зрения BPMN, т.к. часто касаются методических вопросов выполнения шагов. В BPMN, же с одной стороны, этого не нужно, поэтому в нем 3 шага могут схлопнуться в один, с другой - в BPMN схему встраиваются вспомогательные технические шаги.

Просто посадить человека именно работать, а не нажимать кнопки "Одобрить", "Отклонить" в BPM системе нельзя. Дополнительно нужны методические материалы - рабочие инструкции и т.п.
Оценки: /
08.04.2011 17:01
  от автора
  akabanov
Спасибо автору за хорошее описание ключевой проблемы процессной организации. Действительно, вопрос не столько в "правильно-неправильно", сколько в приоритетах и критериях эффективности.

По мере увеличения зрелости процесса он может усложняться.
Но так же растет и зрелость всего пула процессов (организации), для которой важны расходы на поддержку реорганизаций и наиболее эффективное и рациональное изменение используемых процессов (менять только то, что действительно нужно, закладывать такую гибкость, которая снижает потребность в изменениях, не увеличивая при этом совокупных издержек как на выполнение процесса, так и на развитие самой процессной модели)
Оценки: /
08.04.2011 17:05
  от автора
  akabanov
Дмитрий Пинаев, процессная модель не определяет сама по себе регламенты, которые функционально очевидны (не имеют отношения к организации взаимодействия процессов). В случае, когда необходимо регламентировать процесс одобрения, он так же может быть детализирован (или декомпозирован, в зависимости от парадигмы моделирования процесса).
Например, мы можем сказать, что процесс одобрения платежа происходит с использованием платежного календаря, контроля лимита по актуальному бюджету, визированию ответственными по ЦФО и по направлениям (что они согласны с необходимостью этого самого платежа в это самое время)

Паттерн (шаблон) предполагает сущностную информацию о процессе, он не ограничивает детали реализации отдельных процедур.

Добавить комментарий

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

Все права защищены. Частичное или полное копирование информации данного ресурса возможно только с разрешения владельца.

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений