Кейс: описываем процесс с помощью Flow Chart

Всем привет! Кто-то мог бы предположить, что я как та мышь, что плакала, кололась, но продолжала есть кактус, но я скорее чувствую себя как Чехов в своем письме Суворину: «если бы мне прожить еще сорок лет и во все эти сорок лет читать, читать и читать и учиться писать талантливо, т. е. коротко», потому что вряд ли мне хватит и сорока лет, чтобы написать что-то коротко. Но я пытаюсь (и много читаю). И пишу вам новую статью в нашем блоке про бизнес-анализ. Сегодня в номере:

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

(Process) Flow Chart (в русском используются слова блок-схема, карта процесса, технологическая карта, флоу процесса, диаграмма процесса и т. д.) — это инструмент визуализации процесса или определенной последовательности действий, принятия выборов и решений и результатов этих решений.

Одно из первых и достоверных упоминаний этого описательного подхода есть в статье Фрэнка и Лилиан Гилбрет «Технологические карты: поиск наилучшего способа выполнения работы» для членов Американского общества инженеров-механиков (ASME, American Society of Mechanical Engineers) в 1921 году, собственно так и появилась Process Flow Chart, как универсальная диаграмма описания инженерного процесса.

Почему же сейчас мы используем Flow Chart как способ для описания бизнес-процесса? Потому что элементы (блоки) этой диаграммы достаточно просты и понятны не только инженерам, но и бизнес-подразделениям, и позволяют на универсальном едином и однозначно понятном языке представить описание определенной последовательности действий в виде схемы. И, где-то с конца 1980-х, блок-схема используется для решения уже преимущественно менеджерских задач. Появились и разновидности этих блок-схем, свои для программ, систем, данных и документов.

Есть и стандарты: последнее обновление у стандарта ИСО 5807 «Символы и условные обозначения в документации для данных, программных и системных блок-схем, программных сетевых диаграмм и диаграмм системных ресурсов» было в 2019 году (точнее как, в 2019 был пересмотр, прочитали, всем все понравилось и действует редакция 1985 года). В этом стандарте представлены блок-схемы для систем, программ и данных, а не процессов в общем.

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

Разумеется, это не все элементы, которые есть для описания состояний / действий / событий, есть еще, например, соединители, комментарий, ИЛИ, подготовка, точка суммирования и т. д. Здесь показала базовые, которые могут пригодиться в нашем примере.

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

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

Давайте разберем на примере описание процесса с помощью блок-схемы.

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

Название процесса: Оформление и утверждение запроса на отпуск сотрудником

Владелец процесса: Руководитель отдела кадров

Потребители процесса:

Связанные процессы:

Ресурсы: Система управления кадрами (HRM-система)

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

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

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

Какие нам понадобятся элементы блок-схемы? Правильно: терминал, действие, выбор, стрелка, заданный процесс (у нас есть связанные процессы, в которые мы придем при выполнении шагов). Нужно ли нам использовать элемент Базу данных, если наш ресурс Система управления кадрами (HRM-система), где и будут вводиться / выводиться данные, связанные с процессом? Это необязательно, но можно использовать отдельные символы для Документа и для Базы данных. Посмотрим на примере оба варианта реализации.

Итак, вот оно, наше начало: мы в терминале указали начало процесса и событие, которое его ознаменовало. Первое действие внутри процесса: создание заявления на отпуск, при этом мы можем указать само название шага «Сформировать заявление», но не как именно оно должно быть сформировано, это подробное описание остается в текстовом формате, часто в приложении к диаграмме. Если мы решим не использовать в блок-схеме элементы Документ и База данных, то после шага 1 «Сформировать заявление» будет следующий шаг, сразу шаг 2 «Отдать заявление Руководителю» (я предпочитаю делать без этих элементов, использую только в крайнем случае, или когда такая детализация прям необходима).

Здесь я вам показала как раз, что использование данных и / или работа с системами / БД может быть отражена отдельным элементом, плюс, я показала, что некоторые шаги могут быть детализированы (то, как именно Руководитель рассматривает заявление, использует ли он для этого эти данные из HRM-системы) через отдельный шаг. Дальше у нас что? Правильно, Руководитель принимает решение.

Что может произойти при рассмотрении заявления на отпуск? Его могут принять или отклонить, и о том, и о том нужно уведомить сотрудника. Если решение отрицательное, то процесс подачи и рассмотрения заявления на отпуск закончен. Если решение положительное, то надо бы рассчитать ему отпускные, и отразить в учете рабочего времени и графике отпусков (а это самостоятельные, отдельно стоящие наборы последовательных действий или подпроцессы), верно же? Верно.

Тогда что я пропустила?

Я пропустила еще одно условие, мои наивнимательнейшие! Отпуск может быть как оплачиваемым, так и неоплачиваемым, а я никак это не показала. Исправляемся:

Сейчас получается, что если отпуск неоплачиваемый, мы только учитываем информацию о труде и отдыхе в рабочем времени, а если оплачиваемый, то инициируем оплату. Так, теперь надо посмотреть на картину в общем и целом, понять, нужны ли нам комментарии к этой схеме, чтобы она была понятной.

Мое мнение: достаточно понятно и просто, но без комментариев у меня нет дополнительной информации о том, как именно какие-то действия могут быть выполнены или в каких ограничениях. Давайте их добавим: то, что заявление оформляется в HRM-системе, и что решение принимается в течение 3 дней, и когда повторно подать можно заявление.

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

Где можно работать с блок-схемой? В сервисах типа Draw.io / Lucidchart / Miro / Figma / MS Visio, тут кому что больше нравится, удобно или приемлемо по цене.

Когда мы доберемся до блока статей по работе с требованиями, я покажу и расскажу, как с помощью блок-схемы можно отрабатывать ТЗ для разработки ПО. На самом деле так же просто: пошагово отобразить желаемую логику работы сервиса / приложения, определить ограничения и условия. Главное, чтобы было полное представление о процессе и всех его элементах.

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