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

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

Базовое допущение BPMN 2: У организации есть механизм назначения и передачи поручений

Базовые допущения BPMN:

  1. Вся информация сохраняется
  2. У организации есть механизм назначения и передачи поручений
  3. К каждой задаче прилагается инструкция
  4. У задач есть нормативные сроки, а у организации - механизм их контроля

2. У организации есть механизм назначения и передачи поручений

Раз за разом на тренинги по BPMN студенты приносят диаграммы типа такой:

Нет, формально тут все правильно. И вообще, BPMN не навязывает какую-то определенную методологию, поэтому вы имеете полное право выбрать такой стиль моделирования.

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

Поэтому я предлагаю принять следующее базовое допущение: когда мы просто и незамысловато изображаем поток управления между двумя задачами -

то это подразумевает, что

  1. В компании есть какой-то механизм передачи задач между исполнителями. Неважно какой именно - это может быть BPMS, электронная почта, телефон, курьеры и лотки входящие-исходящие… да хоть пневмопочта. Так или иначе, если есть утвержденная схема процесса типа приведенной выше и отдел продаж свою задачу выполнил, то мы можем быть уверены, что «эстафетная палочка» процесса перейдет к бухгалтерии.
  2. В компании наличествует исполнительская дисциплина, которая подразумевает, что если есть утвержденная схема процесса, согласно которой, например, отделу продаж назначена задача «Составить калькуляцию», то задача будет выполнена. Нет ни у кого ни права, ни возможности сделать вид, что он не увидел задачу, или не понял, что она назначена ему, или решить ее не выполнять. Если это условие не выполняется, то мы имеем дело с недееспособной организацией - о каком вообще процессном управлении в этом случае можно говорить?

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

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

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

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

Продолжение следует…

04.01.13 | Статьи | ,    

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

  1. Дмитрий Бацюро 04.01.13 14:46

    Анатолий, я бы явным образом выделил две ситуации:

    1) Когда кроме передачи самой “эстафетной палочки”, больше ничего делать не надо - вся необходимая информация для выполнения второй задачи уже сохранена где-то по итогам первой, откуда второй исполнитель сможет ее достать. Эта информация может храниться в контексте этого процесса в BPM-движке, на файл-сервере, в ECM- или ERP-системе. Но, главное, она уже там, откуда исполнитель второй задачи сможет ее непринужденно извлечь, как только это понадобится.

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

  2. Anatoly Belychook 04.01.13 15:33

    Дмитрий

    Спасибо за полезное уточнение.

  3. Дмитрий Бацюро 04.01.13 16:01

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

  4. Anatoly Belychook 04.01.13 16:13

    Справедливо. Чаще наверное в архив, а не в шредер. Причем желательно с пометкой “хранить до …”, чтоб он не остался до конца дней теперь уже в архиве.

  5. Дмитрий Бацюро 04.01.13 16:26

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

  6. Scott Francis 17.01.13 04:50

    In fact, if they’re using a BPMS, task assignation and transfer is built into the software- so quite literally you won’t have to write code for assignment in most cases.

  7. Anatoly Belychook 17.01.13 07:44

    Scott, the point is that they don’t need to model it even if there is no BPMS on the horizon.

Комментирование закрыто

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