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

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

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

Что такое описание бизнес-процессов и зачем оно перед автоматизацией?

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

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

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

1. Где работа ждёт. Сам шаг занимает пять минут, а заявка лежит сутки, потому что руководитель согласует пачкой по вечерам.
2. Где данные вводят дважды. Менеджер переписывает заказ из мессенджера в таблицу, потом из таблицы в 1С.
3. Где решение принимает только один человек. Он в отпуске - процесс стоит.

Именно эти три места потом и становятся задачей для автоматизации. Раздел про аудит процесса до выбора инструмента в большом разборе автоматизации даёт карточку процесса целиком. Здесь я иду на уровень ниже: как расписать процесс по шагам так, чтобы по записи можно было что-то строить.

Чем процесс «как есть» отличается от регламента и схемы «как должно быть»?

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

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

В методиках процессного управления это называют моделью AS-IS («как есть») и моделью TO-BE («как будет»).

«Работа с любым процессом начинается с его описания в текущем состоянии (AS-IS, «как есть»). Цель - беспристрастно зафиксировать реальность, а не попытаться сразу что-то улучшить или подогнать под идеальные регламенты.»

• блог Нетологии, «Бизнес-процессы: как описать и оптимизировать»

Порядок работы с двумя моделями простой:

1. Сначала снять «как есть» - честно, со всеми костылями.
2. Отметить на ней потери: ожидание, двойной ввод, пересылки, ручные проверки.
3. Только после этого рисовать «как будет» - уже с системой, ботом или интеграцией.

Консультанты описывают ту же ловушку со стороны команды:

«Если вы описали то, как «должно быть» - команда скажет: «Мы так не работаем». И будет права.»

• Systemmatica, «Описание бизнес-процессов»

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

Какой процесс описывать первым и где у него границы?

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

Хороший первый кандидат отвечает хотя бы на два вопроса «да»:

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

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

Границы задают событиями. Плохая граница: «работа отдела продаж». Хорошая: «от момента, когда клиент оставил заявку в любом канале, до момента, когда ему отправлен счёт». Стартовое событие отвечает на вопрос «что запускает работу», финальное - «что считается готовым результатом».

Запишите эти два события одной строкой вверху описания. Каждый раз, когда сотрудник на интервью уходит в соседнюю тему («а потом ещё бывает возврат...»), эта строка помогает вернуться. Возвраты - отдельный процесс, его опишете следующим.

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

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

1. Поговорите с каждым участником процесса

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

2. Пройдите один реальный случай от начала до конца

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

3. Запишите шаги в таблицу «как есть»

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

4. Отметьте потери

   Пройдите по таблице и пометьте четыре вида мест:

   1. Ожидание - работа лежит без движения.
   2. Двойной ввод - одни и те же данные набирают второй раз.
   3. Пересылка - задачу передают из рук в руки через мессенджер или почту.
   4. Единственный исполнитель - шаг умеет делать только один человек.

   Отдельно пометьте шаг, где заявка может потеряться без следа.

5. Сверьте таблицу со вторым участником

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

По оценке Systemmatica, первая версия простого процесса вроде обработки заявки занимает 2-4 часа, сложного вроде полного цикла продажи - 2-3 рабочих дня вместе с интервью. По моему опыту, дольше всего тянется поиск времени на разговоры с людьми.

Одного руководителя для описания мало. Он расскажет, как процесс задуман. Как заявка движется на деле, знают исполнители, поэтому разговаривают с каждым из них.

По такой таблице ClaudeLab и начинает работу над чат-ботами, ИИ-агентами и связками с CRM: для любой автоматизации описание бизнес-процессов служит входным документом. Как из него получается задание исполнителю, разобрано в разделе про ТЗ.

Какие поля записать по каждому шагу: шаблон таблицы

Для первой версии описание бизнес-процессов состоит из двух частей: шапки процесса и таблицы шагов. Шапка отвечает на вопрос «что это за процесс», таблица - «как он идёт».

Записывать всё подряд, без оценок и исправлений на ходу. В блоге Stormbpmn эту мысль формулируют так:

«Цель - честно зафиксировать, как устроено сейчас, со всеми "странностями", "двойным учетом", "промежуточными Excel-таблицами" и так далее.»

• Stormbpmn, «Что такое бизнес-процесс и как его описать»

ШАПКА ПРОЦЕССА
Название процесса:
Стартовое событие (что запускает работу):
Готовый результат (что считается концом):
Владелец (кто отвечает за результат целиком):
Как часто повторяется (раз в день / неделю / месяц):
Сколько случаев в месяц (примерно):
Какие программы и каналы участвуют:

ТАБЛИЦА ШАГОВ
№ | Кто | Что делает | Где | Вход | Выход | Время действия | Ожидание перед шагом | Проблема

Что писать в каждом поле:

Если шаг бывает разным в зависимости от условия (оплата картой или по счёту, клиент новый или старый), запишите развилку отдельной строкой: «если клиент новый - шаг 4а, если постоянный - шаг 4б». Развилки потом станут правилами в системе, и их лучше увидеть заранее.

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

Шапка: стартовое событие - клиент оставил заявку на сайте, в Telegram или позвонил. Готовый результат - клиенту отправлен счёт. Владелец - руководитель отдела продаж.

Даже такое короткое описание бизнес-процессов показывает потери без всяких нотаций. Само действие по всем шагам занимает около 37 минут, а работа до счёта может ждать почти целый рабочий день. Основное время уходит на ожидание в шагах 1, 3 и 6. Данные клиента проходят через три места - чат, CRM и 1С, и дважды их набирают руками заново, хотя они уже есть в заявке. У заявки нет владельца до шага 3, и если оба менеджера заняты, она лежит в чате без движения.

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

Как нейросеть превращает расшифровку разговора в таблицу шагов?

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

С такой раскладкой нейросеть справляется за минуты. Порядок такой:

1. Записать разговор на диктофон или в видеозвонке с согласия участника.
2. Получить текстовую расшифровку сервисом распознавания речи. Как это устроено для совещаний, я показывал в статье про протокол совещаний нейросетью.
3. Убрать из текста имена клиентов, телефоны, суммы конкретных сделок.
4. Отдать нейросети расшифровку и промпт ниже.
5. Проверить черновик таблицы вместе с тем же сотрудником.

Ты помогаешь описать бизнес-процесс компании в состоянии «как есть» перед автоматизацией.
Ниже расшифровка разговора с сотрудником. Разложи его рассказ в таблицу строго по тексту расшифровки.

Процесс: <название процесса>
Начинается, когда: <стартовое событие>
Заканчивается, когда: <готовый результат>

Правила:
1. Одна строка - одно действие одного человека.
2. Колонки: №, Кто, Что делает, Где (программа или канал), Вход, Выход, Время действия, Ожидание перед шагом, Проблема.
3. Если в расшифровке нет данных для колонки, пиши «не сказано». Ничего не додумывай.
4. Развилки («если... то...») оформляй отдельными строками с номерами 4а, 4б.
5. После таблицы дай два списка: что в рассказе противоречит само себе и какие вопросы задать сотруднику, чтобы закрыть пробелы.

Расшифровка:
<текст>

Без правила «пиши "не сказано", ничего не додумывай» промпт не работает: модель аккуратно заполнит пустые клетки правдоподобными догадками, и таблица будет выглядеть законченной, хотя половина в ней выдумана. Список вопросов в конце - полезный побочный результат: это готовый план второго разговора с сотрудником.

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

Нужны ли BPMN и другие нотации?

Нотация - это договорённость, какими значками рисовать процесс. Самая известная - BPMN, стандарт консорциума OMG с фигурами для событий, действий, развилок и участников. На странице спецификации BPMN 2.0.2 OMG называет её фактическим стандартом схем бизнес-процессов: нотация рассчитана на тех, кто проектирует и ведёт процессы, и при этом достаточно точна, чтобы схему можно было перевести в программные компоненты.

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

Мой порядок: сначала таблица, потом, если нужно показать процесс людям, схема по дорожкам из той же таблицы. Нейросеть умеет собрать её код для программ рисования схем, если попросить. BPMN - уже на стороне исполнителя, если он работает с BPM-системой.

Какой уровень детализации достаточен?

Две крайности встречаются одинаково часто.

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

Слишком мелко. «Открывает браузер, заходит в CRM, нажимает "новая сделка", заполняет поле "имя"». Такая таблица на 80 строк нужна только тому, кто будет писать инструкцию по работе в программе. Для автоматизации такое описание бизнес-процессов избыточно.

Рабочее правило: шаг заканчивается, когда меняется человек, программа или результат. Менеджер перешёл из почты в CRM - новый шаг. Задача ушла от менеджера к руководителю - новый шаг. Внутри одной программы у одного человека серия кликов - один шаг.

Если таблица разрослась на несколько десятков строк, скорее всего, в описание попали два процесса, и их стоит разделить.

Как из описания получить ТЗ на автоматизацию?

Окупается описание бизнес-процессов тогда, когда по каждой строке с проблемой принято решение. В Нетологии связь с ТЗ формулируют коротко:

«Опираться на техническое задание без описанных процессов - как строить дом без проекта.»

• блог Нетологии, «Бизнес-процессы: как описать и оптимизировать»

Для каждой строки с пометкой в колонке «Проблема» есть четыре варианта:

1. Убрать шаг. Пересылка в общий чат не нужна, если заявка сразу попадает в CRM с ответственным.
2. Отдать системе. Перенос данных из заявки в карточку, выставление счёта из сделки, напоминание клиенту.
3. Отдать ИИ-агенту. Первый ответ клиенту, разбор входящего письма, заполнение карточки из свободного текста. В таких шагах мало переложить данные: нужно понять, о чём пишет клиент.
4. Оставить человеку. Согласование нестандартной скидки, спорный возврат, переговоры. Система здесь только ставит задачу и напоминает.

Из этих решений собирается ТЗ. Минимальный состав:

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

Если автоматизация выливается в сайт, личный кабинет или приложение, такому документу нужны ещё страницы, роли и критерии приёмки. Как его собрать, разобрано в статье про ТЗ на разработку сайта.

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

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

Какие ошибки делают при описании бизнес-процессов?

1. Описали регламент. Документ совпадает с правилами, и только с ними: реальной работы в нём нет. Лечится проходом одного реального случая по следам.
2. Спросили только руководителя. Он описывает, как должно быть. Исполнители знают обходы и костыли.
3. Взяли всё сразу. Описание всей компании не заканчивается никогда. Один процесс, одна таблица, потом следующий.
4. Начали с нотации. Время уходит на спор о значках, сотрудники не узнают свою работу на схеме.
5. Не записали ожидание. Без колонки «ожидание» кажется, что процесс быстрый, а клиент между тем ждёт счёт до вечера.
6. Не назвали владельца. Если за результат процесса целиком не отвечает конкретный человек, описание не с кем согласовать, и автоматизацию некому принять. В блоге Comindware это правило сформулировано так: «У процесса должен быть владелец, а на переходах между подразделениями - явный результат передачи, получатель и срок.»
7. Описали один раз и забыли. Процесс меняется: новый канал заявок, новый сотрудник, новая программа. Описание бизнес-процессов стоит сверять хотя бы раз в квартал и обязательно перед любой автоматизацией.

Где вы сейчас

• Процессы нигде не записаны, работа держится на людях: начните с выбора одного процесса, на котором теряются заявки или часы, и с порядка шагов в статье про автоматизацию малого бизнеса.
• Регламенты есть, но работа идёт иначе: снимите «как есть» по пяти шагам этой статьи и сравните с регламентом строка за строкой.
• Таблица «как есть» готова, нужно выбрать инструмент: переходите к разделу про выбор между интеграцией, RPA, низким кодом и ИИ в разборе автоматизации бизнеса.
• Процесс описан, и в нём видны шаги для ИИ: посмотрите, какие задачи можно отдать агенту, в статье про ИИ-агента для бизнеса.

Чек-лист: описание готово к автоматизации

• Вверху записаны стартовое событие, готовый результат и владелец процесса.
• Каждая строка таблицы - действие одного человека в одной программе, описанное глаголом с объектом.
• У каждого шага заполнены поля «где», «время действия» и «ожидание».
• Хотя бы один реальный случай пройден по следам от начала до конца.
• Таблицу проверил второй участник процесса, расхождения согласованы.
• Потери помечены: ожидание, двойной ввод, пересылки, единственный исполнитель.
• Записаны цифры «до»: время от старта до результата и число потерянных случаев за месяц.