Что делать, если «хороший стиль» BPMN мешает согласовывать схемы

От редакции: Одно дело, как схему процесса видит аналитик, и совершенно другое - как воспринимает бизнес-пользователь, которому нужно понять суть и согласовать воплощение процесса в информационной системе. В ряде случаев проектный опыт моделирования и согласования автоматизируемых бизнес-процессов может расходиться с общими рекомендациями хорошего стиля в BPMN. На вопросы Дениса Котова о причине возникновения и сути подобных разногласий ответила консультант по внедрению DIRECTUM Валентина Писанова.

Какие схемы и каких бизнес-процессов вам приходится составлять и согласовывать?

Специфика ECM-систем такова, что схемы преимущественно отражают перемещение документов в рамках таких бизнес-процессов компании, как, например, внешнее и внутреннее делопроизводство, договорная работа, закупочная деятельность и так далее.

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

Отсюда моё первое дополнение к рекомендации «Happy Path»: если последовательность работ процесса рисовать строго слева направо, то размер схем значительно увеличится, а они и без этого могут измеряться человеческим ростом =)

Схема процесса в реальности

Рекомендация «Happy Path» в теории

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

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

Опять же, с учётом масштабности схем, процессы всегда рисуются только с дорожками. Без исполнителей схему никто не поймёт, она превратится в ужасного нежизнеспособного монстра =)

Более того, пару раз я оказывалась в ситуации, когда Заказчик при согласовании схем предъявляет требования к порядку следования дорожек с обязательным соблюдением иерархии и структуры компании – иногда это критически важно.

А что происходит со схемами, после того как они нарисованы?

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

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

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

Рекомендация «Один старт» в теории

А заказчик какие-то свои требования предъявляет к форме процессов?

Периодически, в ходе согласования, у Заказчика возникают пожелания по перерисовке, которые в том числе могут идти вразрез с правилами или логикой нотации. В большинстве случаев они учитываются, и схема корректируется, так как нет принципиальной цели настоять на корректном соблюдении нотации или научить Заказчика правильному видению моделирования. Главная задача – максимально быстро и корректно согласовать процесс.

Для улучшения понимания BPMN максимально упрощена – используется ограниченное количество самых простых элементов. Дополнительно на блоки работ могут добавляться различные пиктограммы, поясняющие контекст или специфику выполняемого действия, к примеру:

●    логотип системы означает, что пользователь в ходе работ выполняет какие-то действия в соответствующей системе;

●    значок документа говорит о том, что работы выполняются в бумажном виде, без использования системы;

●    «золотой ключик» свидетельствует о подписании документов электронной подписью;

●    стрелки ВНИЗ/ВВЕРХ показывают интеграционное взаимодействие систем при выгрузке/загрузке данных;

●    и так далее…

Заказчики понимают такие схемы?

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

Обычно клиенты хотят видеть полную картину, поэтому визуализация потоков данных нравится им куда больше, чем «чёрный ящик» блока с общим заголовком «Интеграция с 1С». К тому же, этими схемами в дальнейшем с удовольствием пользуются и архитекторы/разработчики интеграции.

А бывают какие-то особенные случаи?

Конечно. К примеру, вместо привычных символов, в шлюзы иногда приходилось вписывать буквы «И» или «ИЛИ», так как Заказчик не мог понять или запомнить в каких случаях используются «плюсики», а в каких «кружочки». Зато, к примеру, ни разу не требовали строгое следование каноническому BPMN. В целом, повторюсь, никто ни с кем не настроен бодаться за «чистоту» нотации – главное корректность процесса.

Иногда бывает, что на стороне Заказчика есть специалисты, которые сами рисуют схемы, как могут, кто в EPC, кто в IDEF0, кто в нотации собственного авторства. Эти схемы принимаются, как полноценный источник для исследования.

А вы перерисовываете потом, если прислали в EPC? Как заказчики реагируют?

Да, перерисовываем. Для этого есть несколько причин: во-первых, это неотъемлемая часть анализа и оптимизации процесса; во-вторых, наши внутренние технологии предъявляют требования в том числе к проектным документам, и в моих интересах пройти внутренний аудит; ну и в-третьих, разработчики привыкли к «корпоративной» нотации и им может быть сложно воспринимать схему, отрисованную иначе. Зачем мучать людей =)

Авторы оригинальных схем в большинстве своём реагируют нормально. Однажды произошёл забавный случай, когда Заказчиком была предоставлена верхнеуровневая простая схема в виде обычного алгоритма. После детализации и разрисовки с дорожками и альтернативными потоками схема безусловно прибавила в размерах и сложности. После пары кругов согласований от Заказчика прозвучало что-то вроде: «Если ты обещаешь, что эта схема полностью соответствует тому, что мы выдали изначально, то я тебе доверяю и знаю, что всё будет ок». =)

Получается вы проводите ликбез, чтобы заказчики понимали схемы?

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

Источник: Импелтех