Описание бизнес-процессов: как описать процесс перед автоматизацией

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

Зачем описывать процесс до автоматизации

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

В стандарте ГОСТ Р ИСО 9000-2015 процесс определён как совокупность взаимосвязанных видов деятельности, которые используют входы для получения намеченного результата. Отсюда простой каркас любого описания: что приходит на вход, что происходит внутри и какой результат на выходе. Если хотя бы одна из трёх частей не ясна, автоматизировать ещё рано.

• Разработчик понимает задачу. Видно, какие экраны, поля, роли и уведомления нужны.
• Оценка становится точнее. Подрядчик считает работу по шагам, а не по ощущению.
• Есть с чем сравнить результат. После запуска понятно, всё ли перенесли и не потеряли ли важные ветки.
• Знания не уходят с сотрудником. Процесс живёт в документе, а не в голове одного человека.

Какие процессы описывать первыми

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

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

Если кандидатов несколько, выбирайте тот, что повторяется чаще всего. Описание одного частого процесса даст больше, чем десяти редких.

Карточка процесса: десять полей на одну страницу

Карточка процесса это короткая шапка описания, которая отвечает на вопросы «что за процесс, где у него начало и конец, кто за него отвечает». Её заполняют первой, ещё до шагов и схем. Ниже поля карточки с примером для условной компании, которая устанавливает кондиционеры.

Поле	Что писать	Пример
Название	Глагол и объект	Обработать заявку на установку
Владелец	Один человек, который отвечает за результат	Руководитель отдела продаж
Начало	Событие, которое запускает процесс	Клиент отправил форму на сайте или позвонил
Конец	Событие, после которого процесс завершён	Счёт отправлен или клиент отказался
Вход	Что нужно, чтобы начать	Контакт клиента, адрес, модель или площадь помещения
Результат	Что получает клиент или следующий процесс	Счёт и дата выезда монтажника
Участники	Роли, а не фамилии	Менеджер, замерщик, бухгалтер
Системы	Где хранятся данные и ведётся работа	Сайт, таблица заявок, учётная программа, мессенджер
Исключения	Что идёт не по основному пути	Нет нужной модели, нужен замер, клиент юрлицо
Показатели	Как понять, что процесс идёт нормально	Время от заявки до счёта, доля заявок без ответа

Начало и конец пишите событиями, а не действиями. «Клиент отправил форму» понятно и проверяемо. «Работа с клиентом» не говорит ни о чём, и с такой границей процесс расползается на половину компании.

Каким способом описывать: шесть форматов

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

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

Как описать бизнес-процесс за пять шагов

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

1. Задайте границы. Заполните карточку: событие начала, событие конца, владелец, результат. Договоритесь, что в этот процесс не входит.
2. Поговорите с исполнителями. По 20–30 минут с каждой ролью. Просите не «как положено», а «что вы делали с последней заявкой». Спрашивайте: откуда узнаёте о задаче, где берёте данные, кому передаёте, что бывает не так.
3. Запишите шаги в таблицу. Одна строка, один шаг: кто делает, что делает, в какой программе, какие данные использует или создаёт, в какой срок.
4. Добавьте исключения. Для каждого шага спросите: «а если…». Нет данных, клиент передумал, сотрудник в отпуске, сумма больше обычной. Запишите, что происходит в каждом случае.
5. Проверьте на трёх реальных случаях. Возьмите свежие заявки и пройдите их по описанию. Если какой-то шаг пришлось придумать на ходу, описание неполное.

Вопросы для разговора с исполнителем, которые помогают получить реальную картину:

• Откуда вы узнаёте, что пора браться за эту работу?
• Что вам нужно, чтобы начать, и где вы это берёте?
• Что вы делаете, если этого нет или оно неполное?
• Кому вы передаёте результат и как он узнаёт, что можно продолжать?
• Что в этой работе чаще всего идёт не так?
• Что вы делаете в обход правил, потому что так быстрее?

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

Пример: таблица шагов от заявки до счёта

Ниже условный пример описания процесса «как есть» для той же компании. Это иллюстрация того, насколько подробно писать, а не готовый процесс для копирования.

Шаг	Кто	Где	Данные	Срок	Если не так
Получить заявку	Менеджер	Почта, телефон	Имя, телефон, адрес	В течение часа	Нет телефона: ответить на почту
Внести в таблицу	Менеджер	Таблица заявок	Те же плюс источник	Сразу	Дубль клиента: дописать в старую строку
Уточнить задачу	Менеджер	Звонок	Площадь, модель, этаж	В тот же день	Нужен замер: шаг «замер»
Замер	Замерщик	Выезд, мессенджер	Фото, размеры, особенности	1–3 дня	Клиент не открыл: перенос
Расчёт	Менеджер	Таблица цен	Позиции, работы, сумма	В день замера	Нет модели: предложить замену
Счёт	Бухгалтер	Учётная программа	Реквизиты, позиции	В течение дня	Юрлицо: запросить карточку компании
Отправить счёт	Менеджер	Почта, мессенджер	PDF счёта	Сразу	Нет ответа 3 дня: напомнить

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

Что нужно разработчику кроме схемы

Схема показывает порядок шагов, но для системы этого мало. Разработчику нужны ещё правила, данные и роли. Обычно именно их не хватает в описаниях, и именно из-за них появляются доработки после запуска.

• Поля и справочники. Какие данные есть у заявки, какие обязательны, какие выбираются из списка.
• Правила и условия. «Если сумма больше X, нужно согласование», «если клиент юрлицо, нужны реквизиты».
• Статусы. Через какие состояния проходит заявка и кто может их менять.
• Роли и права. Кто что видит и кто что может редактировать.
• Уведомления. Кому и когда система должна напомнить.
• Объёмы. Сколько заявок в день и в месяц, сколько пользователей.
• Связи с другими системами. Сайт, учётная программа, телефония, мессенджеры.
• Отчёты. Какие цифры руководитель хочет видеть.

Объёмы стоит посчитать по факту, а не на глаз. Откройте таблицу заявок или почту за прошлый месяц и сосчитайте: сколько заявок пришло, сколько дошло до счёта, сколько человек с ними работали. Эти цифры помогут разработчику выбрать решение по размеру, а вам потом сравнить, как процесс шёл до системы и после.

Если вы выбираете между тем, чтобы настроить имеющуюся программу или заменить её, полезно сначала прочитать статью о том, что описать до решения о смене системы.

Проверьте, готово ли описание

Описание готово, когда по нему можно пройти любой свежий случай и не придумать ни одного шага на ходу. Пройдите по чек-листу перед тем, как отдавать описание разработчику.

Где хранить описание и как держать его живым

Описание хранят в одном месте, доступном всем участникам процесса, с датой и ответственным за обновление. Подойдёт общая папка, база знаний или раздел внутреннего портала. Главное, чтобы актуальная версия была одна и находилась по одной ссылке.

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

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

Ошибки при описании процессов

• Описывать «как должно быть». Получается красивый документ, который не совпадает с жизнью. Система по нему не взлетит.
• Только основной путь. Исключения встречаются каждый день, и если их нет в описании, сотрудники уйдут работать в мессенджер в обход системы.
• Слишком подробно. «Нажать кнопку, открыть вкладку» не нужно. Шаг это действие с результатом, а не движение мышью.
• Фамилии вместо ролей. Сотрудник уйдёт, а описание устареет. Пишите роли.
• Нет владельца и даты. Через полгода никто не знает, актуально ли описание. Ставьте дату и ответственного за обновление.
• Описание в голове аналитика. Документ должен быть понятен исполнителям. Если они его не узнают, он неверен.

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