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

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

Валентина Писанова, консультант компании DIRECTUM – российского вендора системы ECM-класса, поделилась с нами расхождениями собственного опыта моделирования и согласования бизнес-процессов с рекомендациями, приведёнными в письме.

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

• логотип системы означает, что пользователь в ходе работ выполняет какие-то действия в соответствующей системе;
• значок документа говорит о том, что работы выполняются в бумажном виде, без использования системы;
• золотой ключик свидетельствует о подписании документов электронной подписью;
• стрелки ВНИЗ/ВВЕРХ показывают интеграционное взаимодействие систем при выгрузке/загрузке данных;
• и так далее…

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

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

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

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

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

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

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

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

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

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

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

—  А можете какую-нибудь схему показать?

Извините, NDA =)