Процессы
Как сделать блок-схему процесса: пошаговая инструкция с примером
Блок-схема процесса отвечает на три вопроса: с чего всё начинается, кто что делает и чем заканчивается. Разберём, как собрать её за один вечер — от границ процесса до проверки на живом случае — на примере возврата товара в интернет-магазине.
На этой странице
- Зачем рисовать процесс
- Подготовка: что выяснить до первого блока
- Границы процесса
- Кто участвует
- Откуда брать информацию
- Пошаговая инструкция
- Пример: возврат товара в интернет-магазине
- Какие фигуры использовать
- Сколько подробностей нужно
- Одно действие — один блок
- Вложенные процессы
- Исключения: какие рисовать
- Типичные ошибки
- Чек-лист перед тем, как показывать схему
- Где нарисовать блок-схему
- Вопросы и ответы
Зачем рисовать процесс#
Любой процесс в компании живёт в головах: менеджер знает свою часть, бухгалтер — свою, а целиком его не видит никто. Пока всё идёт по плану, это не мешает. Мешает, когда что-то ломается: заявка висит неделю, клиент получает два разных ответа, новичок спрашивает «а что дальше?» и никто не может объяснить коротко.
Блок-схема переносит процесс из голов на один экран. На ней сразу видно, где заявка ждёт решения, где у шага нет хозяина и где ветка «нет» обрывается в пустоту. Текстовый регламент на пять страниц такого не показывает: в нём шаги идут подряд, а развилки и возвраты прячутся в придаточных предложениях.
- Договориться. Схема — общий предмет обсуждения: спорят о стрелке, а не о том, кто что имел в виду.
- Найти узкие места. Шаг, в который сходятся пять стрелок, или развилка без второй ветки видны с первого взгляда.
- Ввести новичка. Пять минут над схемой заменяют полдня расспросов.
- Подготовить автоматизацию. Прежде чем настраивать систему, нужно знать, что именно она должна делать.
Если вы впервые слышите слово «блок-схема» или хотите разобраться в фигурах и правилах оформления, начните со статьи что такое блок-схема. Здесь — практика: как нарисовать схему реального процесса так, чтобы ей пользовались.
Подготовка: что выяснить до первого блока#
Самая частая причина неудачной схемы — её начинают рисовать сразу. Через полчаса на доске сорок блоков, половина из которых относится к соседним процессам. Десять минут подготовки экономят час переделок.
Границы процесса#
Сформулируйте две вещи: событие-старт и результат. Старт — то, что запускает процесс: «клиент подал заявку на возврат», а не «работа с возвратами». Результат — состояние, после которого процесс закончен: «деньги вернулись клиенту» или «клиент получил обоснованный отказ». У процесса может быть несколько финалов, и все их стоит назвать заранее.
Всё, что происходит до старта и после финала, — другие процессы. Их можно обозначить одним блоком со ссылкой на отдельную схему, но не раскрывать.
Кто участвует#
Выпишите роли — не фамилии, а функции: клиент, поддержка, склад, бухгалтерия. Если роль появляется в процессе один раз, её всё равно стоит назвать: именно на таких стыках чаще всего теряются заявки. Роли потом станут дорожками схемы.
Откуда брать информацию#
- Люди, которые делают работу. Не руководитель, а исполнитель знает, что на самом деле происходит на шаге.
- Реальные случаи. Возьмите три-четыре недавние заявки и пройдите их путь: где они ждали, кто их передавал.
- Документы. Регламенты, шаблоны писем и формы подсказывают шаги, но описывают процесс таким, каким он задуман, а не каким он есть.
Пошаговая инструкция#
Поставьте старт и финиш
Две капсулы на разных концах холста: «Заявка на возврат» и «Готово». Если финалов несколько, поставьте все — так сразу видно, что схема должна к ним привести.
Выпишите шаги глаголами
Каждый шаг — действие в повелительной форме: «Проверить чек», «Принять товар», «Вернуть деньги». Не «Проверка», не «Склад». Глагол заставляет назвать, что именно делается.
Расставьте их по порядку
Сверху вниз или слева направо — выберите одно направление и держитесь его. Шаги, которые идут подряд, соедините стрелками. Пока без развилок: сначала основной, «счастливый» путь.
Добавьте решения
Там, где процесс может пойти по-разному, поставьте ромб с вопросом, на который отвечают «да» или «нет»: «Срок возврата не истёк?». Подпишите обе ветки. Ромб без подписей на стрелках — головоломка для читателя.
Проведите исключения и возвраты
Куда идёт ветка «нет»? Если заявку возвращают на доработку, проведите стрелку назад к нужному шагу — пунктиром, чтобы она не путалась с основным потоком. Каждая ветка должна закончиться финалом или вернуться в процесс.
Разложите по исполнителям
Если ролей больше двух, разделите схему на дорожки — полосы с названием роли. Шаг ставится в полосу того, кто его делает. Стрелка, пересекающая границу дорожек, — это передача работы, главное место для вопросов.
Проверьте на живом случае
Возьмите реальную заявку и проведите её пальцем по схеме. Если на каком-то шаге вы говорите «ну, тут обычно ещё…» — шаг пропущен. Повторите с заявкой, которая пошла не по плану.
Покажите участникам
Отправьте схему тем, кто работает в процессе, и попросите отметить, где она расходится с жизнью. Замечания у конкретного блока полезнее общего «в целом нормально».
Пример: возврат товара в интернет-магазине#
Пройдём по шагам на одном процессе. Клиент просит вернуть товар. Поддержка проверяет заявку: есть ли чек, не истёк ли срок, подходит ли товар под условия возврата. Если всё в порядке, склад принимает товар, бухгалтерия возвращает деньги. Если нет — поддержка объясняет причину отказа.
Первая версия — линейная: старт, проверка, решение, возврат денег, финал. Она уже отвечает на главный вопрос «что происходит с заявкой» и помещается на один экран. Именно такую схему удобно показывать руководителю или клиенту.
Вторая версия добавляет исполнителей. Здесь видно то, чего не было на первой схеме: заявка трижды переходит из рук в руки — от поддержки к складу, от склада к бухгалтерии и обратно к клиенту. Каждая такая передача — место, где заявка может застрять, и первый кандидат на вопрос «кто за это отвечает и в какой срок».
Какие фигуры использовать#
Для схемы бизнес-процесса хватает четырёх обозначений. Строгие нотации вроде BPMN предлагают десятки символов, но в обсуждении процесса внутри команды они чаще мешают, чем помогают. Подробно о том, когда без строгой нотации не обойтись, — в статье BPMN или блок-схема.
Цвет добавляет ещё один слой смысла, если договориться о нём заранее: например, зелёный — старт и успешный финал, оранжевый — исключения и отказы. Но цвет не должен быть единственным носителем информации: схему часто печатают в чёрно-белом виде или смотрят на ней только подписи.
Сколько подробностей нужно#
Хорошая схема процесса умещается на одном экране и читается за минуту. Если блоков больше двадцати пяти, скорее всего, в одну схему попали два процесса или слишком мелкие шаги. Слева — схема, которую трудно обсуждать, справа — та же логика, разложенная по правилам.
Так хуже
Так лучше
Одно действие — один блок#
Если в подписи блока есть «и», это почти всегда два шага. «Проверить и согласовать» скрывает вопрос: что, если проверка не прошла? Разделите блок — и развилка появится сама.
Вложенные процессы#
Шаг, внутри которого своя сложная логика, лучше вынести на отдельную схему. На основной оставьте один блок с понятным названием, например «Оформить возврат в учётной системе», и пометку, где искать подробности. Так основная схема остаётся обзорной, а детали не теряются.
Исключения: какие рисовать#
Рисуйте исключения, которые случаются регулярно или дорого обходятся: отказ, доработка, эскалация. Редкие случаи вроде «клиент передумал на середине» лучше описать в комментарии к блоку — иначе схема превратится в паутину ради ситуаций, которые бывают раз в год.
Типичные ошибки#
- Нет старта или финиша. Непонятно, где процесс начинается и когда его можно считать завершённым.
- Ветка, которая никуда не ведёт. Ветка «нет» обрывается, и читатель не знает, что происходит с отказом.
- Существительные вместо действий. Блок «Бухгалтерия» — это исполнитель, а не шаг. Что именно она делает?
- Стрелки во все стороны. Половина идёт вправо, половина — вверх и назад. Выберите основное направление, возвраты делайте пунктиром.
- Схема «как должно быть» вместо «как есть». Проблемы процесса остаются за кадром, и схема не помогает их решить.
- Схема устарела. Процесс поменяли, схему — нет. Назначьте хозяина схемы и сверяйте её при каждом изменении регламента.
Чек-лист перед тем, как показывать схему#
- Есть ровно один старт и все финалы подписаны.
- Каждый шаг начинается с глагола и описывает одно действие.
- У каждого ромба — вопрос и подписанные ветки.
- Каждая ветка заканчивается финалом или возвращается в процесс.
- Основное направление одно, возвраты отличаются стилем линии.
- Если ролей больше двух — шаги разложены по дорожкам.
- Схема проверена на реальном случае, включая неудачный.
- Схема помещается на один экран, детали вынесены на отдельные схемы.
- У схемы есть хозяин и дата последней проверки.
Где нарисовать блок-схему#
Первый набросок удобно делать на бумаге или маркерной доске — так быстрее спорить и стирать. Для схемы, которой будут пользоваться, нужен инструмент, где её легко менять и показывать: если перерисовка стрелки занимает минуту, схему перестают обновлять.
В NodePanel можно начать с шаблона блок-схемы процесса: старт, шаги, ромб с ветками «Да» и «Нет» и возврат на доработку уже стоят на местах. Клавиша Tab создаёт следующий шаг со связью, автораскладка выравнивает схему, а коллеги оставляют комментарии прямо у блока, с которым не согласны. Чем онлайн-доска помогает именно в работе с процессами, рассказано на странице блок-схемы процессов, а пошаговое руководство с кнопками интерфейса — в разделе схема согласования.
Если схема уже описана текстом в формате Mermaid, её можно вставить на доску и получить готовые блоки и связи. А попробовать редактор без регистрации можно в песочнице на главной.
Вопросы и ответы#
Чем блок-схема процесса отличается от регламента?
Регламент описывает процесс текстом: правила, сроки, ответственность. Блок-схема показывает порядок шагов, развилки и передачу работы между людьми. Они дополняют друг друга: схема даёт картину целиком, регламент — подробности каждого шага.
Сколько блоков должно быть на схеме процесса?
Жёсткого правила нет, но схема должна читаться за минуту и помещаться на экран. Если блоков больше двадцати пяти, проверьте, не смешались ли два процесса, и вынесите сложные шаги на отдельные схемы.
Нужно ли рисовать дорожки для каждой схемы?
Нет. Если в процессе один-два исполнителя, дорожки только добавят линий. Они нужны, когда работа переходит между отделами: тогда передача видна как стрелка через границу полос.
С чего начать, если процесс никто не может описать целиком?
Соберите на короткую встречу по одному человеку от каждого участка и пройдите вместе две-три реальные заявки. Каждый рассказывает свою часть, а схема собирается на общем экране. Пробелы обнаружатся сами — на стыках, где никто не знает, что происходит.
Как часто обновлять схему процесса?
Каждый раз, когда меняется процесс, и не реже раза в несколько месяцев для сверки с жизнью. Проще всего, когда у схемы есть хозяин и она лежит там, где её видят все участники процесса.