Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Расскажите историю

Периодически приходится видеть BPMN-диаграммы типа следующей:

BPMN-диаграмма процесса оплаты счетов, неправильно

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

Формально это корректная диаграмма, по существу же это вообще не бизнес-процесс. «Бизнес-процесс бухгалтерии» – это нонсенс, так же как нонсенс – попытка изобразить «бизнес-процесс сотрудника», начинающийся каждый день с 9:00 утра. Аргумент «но мы же так работаем, это наш процесс as-is» несостоятелен. На нашу работу можно смотреть с разных точек зрения – можно как на функции, а можно как на процесс.

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

  • Вот сотрудник А, вот его компьютерное рабочее место (экран корпоративной системы), где он в течении дня регулярно нажимает F5, чтобы увидеть поступившие заявки и перевести их из состояния «поступившая» в состояние «одобрена» или «отвергнута».
  • Вот сотрудник Б со своим рабочим местом, где он видит заявки в состоянии «одобрена». Его задача – перевести их в состояние «выполнена». Это его бизнес-процесс.

Как же перестроиться от функционального к процессному мышлению?

Расскажите нам «историю счета».

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

И тогда получится совсем другая диаграмма:

BPMN-диаграмма процесса оплаты счетов, правильно

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

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

15.07.13 | Статьи |    

Комментарии (13)

  1. dyadyalyonya 16.07.13 03:04

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

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

  2. Anatoly Belychook 16.07.13 07:58

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

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

  3. Дмитрий Бацюро 16.07.13 10:07

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

  4. Сергей Ладнич 16.07.13 11:51

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

  5. dyadyalyonya 16.07.13 12:41

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

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

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

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

  7. Юля 16.07.13 12:51

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

  8. dyadyalyonya 16.07.13 13:19

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

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

  9. Юля 16.07.13 14:37

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

  10. Anatoly Belychook 16.07.13 21:36

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

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

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

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

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

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

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

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

  11. Anatoly Belychook 19.07.13 11:53

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

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

  13. Anatoly Belychook 03.10.15 19:41

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

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

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

А что вы думаете?

Captcha

Copyright © 2008-2016 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии