Январь 11

О задании по моделированию бизнес-процессов

В прошедшем семестре я давал вот это задание практически всем группам, от бакалавров до магистров и не получил ни одного ответа, который мог бы считаться приемлемым. Как обещал ранее, привожу подробное объяснение ошибок и мой подход к решению задачи такого рода. Напоминаю, что как я неоднократно подчеркивал, единственного верного решения у задачи нет, Возможно несколько правильных вариантов. При разборе ошибок я буду приводить схемы, присланные студентами без указания авторства.

Разберем задачу.

В интернет-магазин поступает заказ. При получении заказа, если товар есть, то выписывается счет. Если товара нет, то предлагается зарезервировать товар. Если товар зарезервирован, то по поступлению товара на склад выписывается счёт.  После оплаты счета товар отгружается, если оплаты нет 10 дней, то заказ аннулируется.

Для начала, определимся, что является событиями, что действиями, а что условиями (пока только явно описанные в задаче):

События (Events):

  • поступление заказа;
  • поступление товара;;
  • оплата счета;
  • отсутствие оплаты 10 дней.

 

Действия (Actions)

  • выписать счёт;
  • предложить зарезервировать товар;
  • отгрузить товар;
  • аннулировать заказ;
Обратите внимание, что действия начинаются с глагола в повелительном наклонении и заканчиваются существительным.

Шлюз/условие (Gateway)

  • товар имеется в наличии?

Вроде все просто, правда ведь? А теперь посмотрим на детский рисунок на заданную тему…

Рисунок 1 – Пример схемы, в которой перепутаны действия и события

Сразу видно, что события перепутаны с действиями. Крайне распространенная ошибка, в большинстве представленных схем она присутствовала, просто не так явно. Например, другая схема:

Рисунок 2 – Пример ошибочной схемы

Как видим, “Поступление заказа” в ней трактуется как событие. Сложнее с другими ошибками, разберем их, пока не придираясь особо к тексту на рисунке 2. Представьте себе мысленно муравьишку, который бежит по нашей бизнес-схеме. Муравьишка запускается по первому событию, спускаем его с цепи и он побежал.

Вариант 1. Товар есть.

Рисунок 2а – Теперь с муравьишками

На предложенной схеме товар никогда не будет отгружен. Мы будем выписывать счета и практически мгновенно их аннулировать. Возникает вопрос, что не так с условием “Счет оплачен в течение 10 дней”? Дело в том, что для условий по событию нотация BPMN предусматривает несколько иную конструкцию, которая правильно показана на схеме ниже, а именно, т.н. “шлюз, управляемый событиями”. Если мы берем в данном случае обычную развилку типа “или”, то она обрабатывается без задержки, а в момент визита на развилку муравьишки счёт гарантировано не оплачен, поскольку мы его выписали секунду назад и даже еще не направили покупателю, поэтому наверх к действию “товар отгружается” (кстати, в таком написании текста это однозначно событие, а не действие, еще одна ошибка) муравьишка никогда не попадет. Посочувствуем скотинке.

Рисунок 3 – Почти правильная схема

Спрашивается, а что не так с рисунком 3. Вроде же все хорошо, если не придираться к тексту. А вот и нет. Начнем с самого начала. Два события подряд, первое лишнее. Убираем. Но это так, мелкие придирки. А вот дальше мы проверяем наличие товара и нам оказывается, согласно схеме, всё равно: готов клиент ждать или не готов. Мы в любом случае резервируем товар.  Т.е. действие “Предложить зарезервировать товар” из списка выше просто опущено, а это грубая ошибка и нарушение условий задачи. Ну, а дальше считается, что клиент согласен ждать вечно, когда товар поступит, поскольку событие “Товар поступил” в реальной жизни может наступить очень поздно, либо вообще не наступить. Соглашусь, что это не описано в условиях, но кто обещал, что будет легко? Тем более, что на лекции я несколько раз это рассказывал, что в реальной жизни никто вам подробно все не расскажет. В этом и состоит задача бизнес-аналитика, выявить все такие моменты. Кстати, очень перекликается с управлением рисками, не находите?

Были отдельные граждане, которые умудрились предусмотреть вроде всё, но в процессе наделали другие ошибки.

Рисунок 4 – Крайне подробная схема

Во всяком случае, из схемы видно, что разум кипел в процессе рождения этого шедевра.

Перечислю тезисно ошибки схемы, в соответствии с красными цифрами на ней.

  1. Дубликат события. Лишняя сущность. Ошибка не грубая, но некрасиво.
  2. Развилка. А куда когда идем? Непонятно
  3. Условие управляемое событиями. Можно, конечно, и так, но это как в окно выходить при наличии двери. Достаточно было обычного условия “или” в данном случае и не выпендриваться.
  4. Такие события очень коварны на схемах. Что тут не так, я описал в предыдущем примере.
  5. Действие “выписать счет” должно быть всего одно. Это одно и то же действие, с одним и тем же ответственным и исполнителем. Дубликат в данном случае просто методически неверен с точки зрения нотации.
  6. Нотация не предусматривает такое использование шлюза, управляемого событиями. К тому же совершенно лишний элемент на схеме.
  7. И снова дубликат действия. Теперь “Аннулировать заказ”
  8. Событие “оплата счета” между двумя условиями, с последующей проверкой оплачен ли счет. Полная ерунда.

Итак, как надо было действовать, при решении этой задачи

  1. Изучить нотацию и примеры, ссылка на которые была в задании.
  2. Определить начало и конец процесса. С этого начинается моделирование любого процесса. Так мы обозначаем рамки, в которых будем работать. Все начинается с события и заканчивается событием.
  3. Для начала лучше всего описать линейную последовательность действий: шаг за шагом движение от начала к финальному результату, то, что называется “happy path”. Постепенно добавляются ветвления. В таком порядке работать намного проще, чем ставить две или более ветвей одновременно и путаться в стрелках, что откуда и куда идет.
  4. Подпроцессов должно быть столько, чтобы избежать ненужной детализации, но не более того. Помните о чувстве меры. Если подпроцессов будет слишком мало, то действия, которые стоило бы спрятать в них, будут находиться в общем процессе, создавая дополнительные объекты, стрелки, ветвления и, как следствие, путаницу. Если вы перестараетесь с желанием убрать все в подпроцессы, то диаграмма потеряет свою информативность, а какие-то изменения в подпроцессе начнут ненаглядно влиять на результаты всего процесса.
  5. Все названия процессов должны быть максимально информативны и понятны. Иначе читабельность диаграммы также будет крайне низкой. По методике названия см. выше.
  6. Определяем ответственных лиц. До этого мы работали с событиями «в чистом виде». Теперь у них появляются исполнители и ответственные.
  7. Добавляем данные, сноски, комментарии, если это необходимо.

Я сознательно не привожу правильную схему, поскольку не все еще выполнили это задание, но, думаю, того что я написал должно хватить для понимания, как не надо делать.

Sapienti Sat.