Occasionally I get BPMN diagrams like this:
This is the “Payment process” composed of interacting “Accounting department process”, “Business unit finance department process” and “Corporate finance department process.”
Formally it’s a correct BPMN but in essence, it isn’t a business process. “Accounting department business process” is nonsense. Another nonsense is the “Employee daily business process” starting at 9:00 am. The argument “but we’re working this way so it’s our as-is process” doesn’t work. Our activities can be considered from different perspectives - there is functional view and process view.
It’s difficult to explain what is a process view to people who are accustomed to think functionally. I have this issue rather often with IT people whose job is automating functions. They view the world around like this:
- Here is an employee A and here is an application screen for his/her job. He/she should pressed F5 regularly throughout the day to see submitted bills and transfer them from “received” to “approved” or “rejected”.
- And here is employee B and an application screen where he/she can see the approved bills. They should be transferred to “accomplished” - it’s the business process.
How to switch from functional to process thinking?
Tell us “the story of the bill.”
Forget about performers for a while and take a look at the same set of activities from business object perspective. For the process under consideration the bill is such a business object. Tell us the story of a single bill: what happens to it? Who, what, in what sequence should do with it? One bill is one instance of the business process.
And then you’ll get quite different diagram:
It’s a paradox that only advanced BPMN users who’ve got the idea of modeling inter-process communication become the victims of functional mindset. Business people knowing only basic BPMN elements intuitively get the true process view; they’d hardly understand the first diagram, let alone drawing something like this.
Мне кажется дело не в различии функционального и процессного подхода, а в том вы сравнили тёплое с мягким:
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/