Периодически приходится видеть BPMN-диаграммы типа следующей:
Здесь изображен процесс «Оплата счетов», состоящий из взаимодействующих друг с другом «процесса бухгалтерии», «процесса финансового отдела бизнес-единицы» и «процесса финансового отдела концерна».
Формально это корректная диаграмма, по существу же это вообще не бизнес-процесс. «Бизнес-процесс бухгалтерии» – это нонсенс, так же как нонсенс – попытка изобразить «бизнес-процесс сотрудника», начинающийся каждый день с 9:00 утра. Аргумент «но мы же так работаем, это наш процесс as-is» несостоятелен. На нашу работу можно смотреть с разных точек зрения – можно как на функции, а можно как на процесс.
Людям, привыкшим мыслить функционально, бывает трудно объяснить, что же такое процессный взгляд. Регулярно такие сложности у меня возникают с ИТ-специалистами, которые привыкли автоматизировать функции. Их взгляд на мир примерно следующий:
- Вот сотрудник А, вот его компьютерное рабочее место (экран корпоративной системы), где он в течении дня регулярно нажимает F5, чтобы увидеть поступившие заявки и перевести их из состояния «поступившая» в состояние «одобрена» или «отвергнута».
- Вот сотрудник Б со своим рабочим местом, где он видит заявки в состоянии «одобрена». Его задача – перевести их в состояние «выполнена». Это его бизнес-процесс.
Как же перестроиться от функционального к процессному мышлению?
Расскажите нам «историю счета».
Взгляните на ту же самую деятельность не со стороны исполнителей, а со стороны бизнес-объекта. Например, в рассматриваемом процессе таким объектом является счет поставщика. Расскажите «историю одного счета»: что с ним происходит? Кто, что, в какой последовательности должен с ним сделать? Один счет соответствует одному экземпляру бизнес-процесса.
И тогда получится совсем другая диаграмма:
Парадокс заключается в том, что клинит на этом месте только продвинутых пользователей BPMN, имеющих представление о моделировании межпроцессного взаимодействия. Такое вот «горе от ума».
Люди бизнеса, изучившие только базовые элементы BPMN, интуитивно рисуют процессы именно как процессы, а не как взаимодействие пулов-функций. Первую диаграмму они даже не поймут, не говоря уже о том, чтобы ее нарисовать.
Мне кажется дело не в различии функционального и процессного подхода, а в том вы сравнили тёплое с мягким:
DFD диаграмму (разновидностью которой является 1я диаграмма)
и activity диаграммы (говорю по сути - не знаю точного термина в bpmn)
Для одних ситуаций хорош один тип диаграммы, для других - другой.
Первая диаграмма - это тоже activity, поскольку на ней изображены и потоки управления, и потоки данных, т.е. последовательность действий, чего нет в DFD.
А так DFD вещь конечно полезная, только на более высоком уровне - http://mainthing.ru/ru/item/531/
Анатолий, я думаю, все дело в том, что при первом варианте описания процесса более явно, когда кто-то должен запустить какую-то функцию, экранную форму, отчет, в которой он увидит указание выполнять свой очередной шаг бизнес-процесса. А второе представление требует неявного прописания этого внутри каждого шага (если в компании нет BPMS; если есть BPMS, то понятно, что она сама все эти задачи ставит, и каждый в единой форме видит все свои задачи, которые ему надо выполнять). Например, для исполнения шага процесса “Акцептировать счет” руководитель проекта _периодически_ (а с какой периодичностью?) открывает форму со счетами к акцептированию и, если в ней есть счет, то акцептирует или не акцептирует его. Вот эта неявность и сбивает с толку неокрепшие умы. Приходится приучать к тому, что все-таки правильна вторая схема, а первая - это из разряда микроменеджмента, когда мы рассказываем, как именно и в каком порядке надо открыть ящик стола, достать ручку, закрыть ящик стола и т.п., чтобы подписать счет.
Анатолий, помнится Вы в каком то из своих постов повествовали о том, что нужно разрывать сплошные процессы с целью оптимизации процесса, например, в узких местах… Думаю первая диаграмма может быть порождена в таких условиях
Про DFD:
первая диаграмма - типичная DFD, наличие в ней потоков управления и плавательных дорожек не меняет этого (Калянова можно, например, почитать на тему потоков управления в DFD). И , как вы верно заметили про DFD-диаграммы, она и получилась заметно более высокоуровневой, чем 2-я диаграмма.
В целом:
С посылом статьи абсолютно согласен - если мы хотим согласовать с заказчиком воркфлоу счёта, то рисовать ему DFD-диаграмму - это не самый подходящий метод.
Смутили, скорее, сделанные в посте обобщения про “бизнес-процесс бухгалтерии” и прочую “процессную перестройку мышления”. У Репина и Елиферова, например, можно почитать почему “бизнес процесс бухгалтерии” совершенно укладывается в процессный подход. Для затравки, нарисованное воркфлоу счёта - может и не являться бизнес-процессом с точки зрения менеджмента корпорации. Например, у такого процесса может не быть единого Владельца,и могут быть не установлены общие KPI. Зато в Бухгалтерии могут быть ясные Владелец и KPI на функции “проверить счёт” и “оплатить счёт”.
Анатолий, мне кажется, этот пост очень тесно перекликается с постом “дирижировать или реагировать” ( http://mainthing.ru/ru/item/613/ ) с вытекающими из него выводами о том, когда уместно обойтись оркестровкой, а когда необходимо межпроцессное взаимодействие.
Дмитрий, я думаю, что Анатолий изначально предполагает, что схема будет реализована в BPMS. Иначе мы придем к тому, что она вообще будет распечатана, и никто никаких форм открывать не будет.
А вот по второму предложенному варианту предлагаю решить задачку. Точнее - две.
1. Предположим, что дата оплаты может быть с отсрочкой. Например, счет акцептовали 1-го числа, а дату оплаты назначили на 14-е. И так же с другими счетами. И финикам нужно будет каждый раз, прежде чем назначить дату платежа, как-то проверять, сколько на эту дату платежей уже назначено.
2. И продолжим ту же ситуацию. По мере приближения к 14-му числу количество запланированных платежей приближается к некоторому лимиту. Но может возникнуть ситуация, что лимит уже достигнут, но появился счет, который необходимо оплатить 14-го числа. И в этом случае какой-то из ранее запланированных платежей необходимо будет перенести на более позднюю дату. Первая схема это сделать позволит, а вторая - нет.
Юля,
вопросы просто отличные!
Моё мнение такое:
по 1-вопросу - это просто лишняя проверка, которая “спрятана” в активности “Утвердить дату оплаты”
по 2-вопросу - эта ветка упущена на 2 схеме, а в 1й схеме, за счёт её высокоуровневости, нельзя определённо сказать - есть она там или нет.
dyadyalyonya,
в первом случае вы предлагаете “все в код”, но это не наш метод)
а насчет высокоуровневости первой схемы - это как раз нет. Это вполне себе уровень исполнения. Другой вопрос, что это избыточная “межпроцессность”, я бы так не делала.
Сергей Ладнич>> в каком то из своих постов повествовали о том, что нужно разрывать сплошные процессы с целью оптимизации процесса, например, в узких местах… Думаю первая диаграмма может быть порождена в таких условиях
Совершенно верно, говорил вот здесь - http://mainthing.ru/ru/item/403/. Но я следую правилу: “пока возможно, оставайся в рамках оркестровки”. Переход к межпроцессному взаимодействию должен быть обусловлен какими-то весомыми аргументами. А в данном случае просто “рисовали как видели”, одобрить не могу.
Юля>> Но может возникнуть ситуация, что лимит уже достигнут, но появился счет, который необходимо оплатить 14-го числа. И в этом случае какой-то из ранее запланированных платежей необходимо будет перенести на более позднюю дату. Первая схема это сделать позволит, а вторая - нет.
Вот как раз пример такого весомого аргумента. Да, в этом случае придется перейти к схеме с нескольми пулами. Но это будут процессные пулы, а не функциональные.
Алексей Громыко>> этот пост очень тесно перекликается с постом “дирижировать или реагировать” ( http://mainthing.ru/ru/item/613/ ) с вытекающими из него выводами о том, когда уместно обойтись оркестровкой, а когда необходимо межпроцессное взаимодействие.
Справедливо. Но та заметка несколько абстрактная, а здесь - конкретная таблетка для конкретного заболевания с четкими симптомами.
dyadyalyonya>> У Репина и Елиферова, например, можно почитать почему “бизнес процесс бухгалтерии” совершенно укладывается в процессный подход
Спасибо, но в процессном управлении есть и более весомые авторитеты. Например, Майкл Хаммер говорил, что если бизнес-процесс не доводит до белого каления по крайней мере трех человек, то это не бизнес-процесс.
Еще вдогонку к вопросу о том что является и что не является бизнес-процессом - цитата из ABPMP CBOK:
In the context of business process management, a “business process” is defined as end-to-end work which delivers value to customers. The notion of end-to-end work is critical as it involves all of the work, crossing any functional boundaries, necessary to completely deliver customer value.
Может это уже неактуально, но возник такой вопрос: счет подписал член правления, а потом рядовой бухгалтер нашел ошибку и завернул счет.
Вопрос: как вы будете объяснять члену правления, зачем ему нужно еще раз подписывать счет ? Также очень может быть, что к члену правления нет так просто попасть/положить счет на подпись (командировки, совещания) .
Я хочу сказать, что к руководителю должен попасть документ, который проверен и согласован всеми нижестоящими сотрудниками фирмы, которые согласно правил документооборота фирмы работают с данным документом(счетом), а то иногда будет как в анекдоте про поручика Киже.
Боюсь, вы не поняли смысла этой заметки. Последовательность обработки счета может быть любой - это вопрос к бизнесу и к аналитику. Тут речь о другом - что проектировать бизнес-процесс надо именно от процесса (или отбизнес-объекта, что почти то же самое), а не от функции или субъекта.
Объективности ради, по этому вопросу существуют разные мнения: например, есть нотация S-BPM, которая утверждает прямо противоположное.
Что касается финансового директора, к которому нелегко попасть, то это законный вопрос. Он подробно разбирался тут: http://mainthing.ru/ru/item/403/