Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Tell The Story

Occasionally I get BPMN diagrams like this:

Payment process BPMN diagram, incorrect

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:

Payment process BPMN diagram, correct

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.

07/15/13 | Articles |    

Comments (13)

  1. dyadyalyonya 07/16/13 03:04 AM

    Мне кажется дело не в различии функционального и процессного подхода, а в том вы сравнили тёплое с мягким:
    DFD диаграмму (разновидностью которой является 1я диаграмма)
    и activity диаграммы (говорю по сути - не знаю точного термина в bpmn)

    Для одних ситуаций хорош один тип диаграммы, для других - другой.

  2. Anatoly Belychook 07/16/13 07:58 AM

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

    А так DFD вещь конечно полезная, только на более высоком уровне - http://mainthing.ru/ru/item/531/

  3. Дмитрий Бацюро 07/16/13 10:07 AM

    Анатолий, я думаю, все дело в том, что при первом варианте описания процесса более явно, когда кто-то должен запустить какую-то функцию, экранную форму, отчет, в которой он увидит указание выполнять свой очередной шаг бизнес-процесса. А второе представление требует неявного прописания этого внутри каждого шага (если в компании нет BPMS; если есть BPMS, то понятно, что она сама все эти задачи ставит, и каждый в единой форме видит все свои задачи, которые ему надо выполнять). Например, для исполнения шага процесса “Акцептировать счет” руководитель проекта _периодически_ (а с какой периодичностью?) открывает форму со счетами к акцептированию и, если в ней есть счет, то акцептирует или не акцептирует его. Вот эта неявность и сбивает с толку неокрепшие умы. Приходится приучать к тому, что все-таки правильна вторая схема, а первая - это из разряда микроменеджмента, когда мы рассказываем, как именно и в каком порядке надо открыть ящик стола, достать ручку, закрыть ящик стола и т.п., чтобы подписать счет. :-)

  4. Сергей Ладнич 07/16/13 11:51 AM

    Анатолий, помнится Вы в каком то из своих постов повествовали о том, что нужно разрывать сплошные процессы с целью оптимизации процесса, например, в узких местах… Думаю первая диаграмма может быть порождена в таких условиях :)

  5. dyadyalyonya 07/16/13 12:41 PM

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

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

    Смутили, скорее, сделанные в посте обобщения про “бизнес-процесс бухгалтерии” и прочую “процессную перестройку мышления”. У Репина и Елиферова, например, можно почитать почему “бизнес процесс бухгалтерии” совершенно укладывается в процессный подход. Для затравки, нарисованное воркфлоу счёта - может и не являться бизнес-процессом с точки зрения менеджмента корпорации. Например, у такого процесса может не быть единого Владельца,и могут быть не установлены общие KPI. Зато в Бухгалтерии могут быть ясные Владелец и KPI на функции “проверить счёт” и “оплатить счёт”.

  6. Алексей Громыко 07/16/13 12:43 PM

    Анатолий, мне кажется, этот пост очень тесно перекликается с постом “дирижировать или реагировать” ( http://mainthing.ru/ru/item/613/ ) с вытекающими из него выводами о том, когда уместно обойтись оркестровкой, а когда необходимо межпроцессное взаимодействие.

  7. Юля 07/16/13 12:51 PM

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

  8. dyadyalyonya 07/16/13 01:19 PM

    Юля,
    вопросы просто отличные!

    Моё мнение такое:
    по 1-вопросу - это просто лишняя проверка, которая “спрятана” в активности “Утвердить дату оплаты”
    по 2-вопросу - эта ветка упущена на 2 схеме, а в 1й схеме, за счёт её высокоуровневости, нельзя определённо сказать - есть она там или нет.

  9. Юля 07/16/13 02:37 PM

    dyadyalyonya,
    в первом случае вы предлагаете “все в код”, но это не наш метод)
    а насчет высокоуровневости первой схемы - это как раз нет. Это вполне себе уровень исполнения. Другой вопрос, что это избыточная “межпроцессность”, я бы так не делала.

  10. Anatoly Belychook 07/16/13 09:36 PM

    Сергей Ладнич>> в каком то из своих постов повествовали о том, что нужно разрывать сплошные процессы с целью оптимизации процесса, например, в узких местах… Думаю первая диаграмма может быть порождена в таких условиях

    Совершенно верно, говорил вот здесь - http://mainthing.ru/ru/item/403/. Но я следую правилу: “пока возможно, оставайся в рамках оркестровки”. Переход к межпроцессному взаимодействию должен быть обусловлен какими-то весомыми аргументами. А в данном случае просто “рисовали как видели”, одобрить не могу.

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

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

    Алексей Громыко>> этот пост очень тесно перекликается с постом “дирижировать или реагировать” ( http://mainthing.ru/ru/item/613/ ) с вытекающими из него выводами о том, когда уместно обойтись оркестровкой, а когда необходимо межпроцессное взаимодействие.

    Справедливо. Но та заметка несколько абстрактная, а здесь - конкретная таблетка для конкретного заболевания с четкими симптомами.

    dyadyalyonya>> У Репина и Елиферова, например, можно почитать почему “бизнес процесс бухгалтерии” совершенно укладывается в процессный подход

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

  11. Anatoly Belychook 07/19/13 11:53 AM

    Еще вдогонку к вопросу о том что является и что не является бизнес-процессом - цитата из 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.

  12. Alexx 09/30/15 04:54 PM

    Может это уже неактуально, но возник такой вопрос: счет подписал член правления, а потом рядовой бухгалтер нашел ошибку и завернул счет.
    Вопрос: как вы будете объяснять члену правления, зачем ему нужно еще раз подписывать счет ? Также очень может быть, что к члену правления нет так просто попасть/положить счет на подпись (командировки, совещания) .
    Я хочу сказать, что к руководителю должен попасть документ, который проверен и согласован всеми нижестоящими сотрудниками фирмы, которые согласно правил документооборота фирмы работают с данным документом(счетом), а то иногда будет как в анекдоте про поручика Киже.

  13. Anatoly Belychook 10/03/15 07:41 PM

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

    Объективности ради, по этому вопросу существуют разные мнения: например, есть нотация S-BPM, которая утверждает прямо противоположное.

    Что касается финансового директора, к которому нелегко попасть, то это законный вопрос. Он подробно разбирался тут: http://mainthing.ru/ru/item/403/

What do you think?

Captcha

Copyright © 2008-2016 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments