АВТОМАТИЗАЦИЯ · ПОДГОТОВКА · ШАБЛОН · 13 МИНУТ
Как описать процесс без готового ТЗ
Достаточно начать с события, участников, действий и результата.
Короткий ответ: опишите один реальный случай от события до результата
Не начинайте с перечня функций будущей системы. Возьмите один объект — например, обращение клиента, заявку на согласование или входящий документ — и последовательно опишите, что происходит с ним сейчас.
Событие → входные данные → реальные шаги → участники и системы → решения → исключения → проверяемый результат.
Такое описание ещё не является техническим заданием. Зато оно позволяет увидеть границы задачи, задать предметные вопросы и не проектировать решение вокруг предположений.
РАБОЧИЙ ОБРАЗЕЦ / ДЕМОНСТРАЦИОННЫЕ ДАННЫЕ
Карточка процесса без готового ТЗ
| Поле | Заполненный демонстрационный пример |
|---|---|
| Кто | Диспетчер принимает заявку |
| Что получает | Объект, описание и контакт |
| Что делает | Проверяет комплект и назначает специалиста |
| Что передаёт | Задание с ответственным и сроком |
| Когда ошибка | Нет объекта → очередь уточнения |
Один абзац: «Диспетчер получает заявку, проверяет объект и назначает специалиста; неполная заявка остаётся на уточнении». Дальше нужны источник полей, частота и реальные исключения.
Как описать один рабочий случай
- Возьмите завершённый реальный случай, а не идеальную схему.
- Запишите событие, участников, действия, данные и подтверждение результата.
- Добавьте ошибку или возврат и отметьте вопросы, на которые пока нет ответа.
Что учесть
Не нужно заранее выбирать стек или рисовать все экраны. Если результат и ответственный не определены, описание ещё рано превращать в техническое задание.
Подробный разбор, подготовка и вопросы
Сначала фиксируйте «как есть», а не идеальный будущий процесс
Распространённая ошибка — сразу рисовать аккуратную схему будущей работы. В ней исчезают ручные обходы, спорные статусы и реальные исключения. В результате разработка опирается не на фактический процесс, а на его желаемую версию.
Сначала запишите, как команда действует сегодня, включая неудобные участки. После этого отдельно обозначьте, что должно измениться. Разделение текущего и целевого состояния помогает не автоматизировать лишние шаги и не маскировать организационную проблему новой системой.
Определите границу одного процесса
Граница отвечает на два вопроса: с какого события начинается работа и какой наблюдаемый результат означает её завершение. Формулировки «автоматизировать продажи» или «навести порядок в документах» слишком широки для первого релиза.
| Слишком широко | Рабочая граница | Проверяемый результат |
|---|---|---|
| Автоматизировать заявки | От отправки формы на сайте до назначения ответственного в CRM | Карточка создана, источник сохранён, ответственный уведомлён |
| Ускорить согласование | От загрузки документа до решения согласующего | Статус решения и комментарий доступны инициатору |
| Сделать отчётность | От закрытия рабочего дня до готового сводного отчёта | Отчёт собран из согласованных источников и отмечены ошибки данных |
Это иллюстративные границы, а не обещание конкретной реализации. Для своего процесса используйте фактическое начало и завершение.
Соберите короткий паспорт процесса
До описания каждого шага полезно зафиксировать контекст. Паспорт помещается на одной странице и помогает участникам одинаково понимать предмет обсуждения.
- Название. Один конкретный поток, а не функция отдела целиком.
- Цель. Зачем процесс существует и кому нужен его результат.
- Владелец. Кто отвечает за итог и может принимать решения об изменениях.
- Событие запуска. Что именно начинает очередной экземпляр процесса.
- Результат. Как проверить, что работа действительно закончена.
- Участники. Роли людей и внешних сторон без привязки только к фамилиям.
- Системы. CRM, почта, таблицы, мессенджеры, кабинеты и другие источники данных.
- Частота и объём. Реальные значения, если они известны; иначе пометка о необходимости измерения.
- Ограничения. Доступы, регламенты, чувствительные действия и обязательные проверки.
Опишите шаги глаголами и укажите место работы
Для каждого шага достаточно ответить: кто выполняет действие, что получает на входе, что делает, в какой системе и что передаёт дальше. Не объединяйте в одну строку несколько решений или передач между людьми.
| Поле | Что записать | Зачем это нужно |
|---|---|---|
| Исполнитель | Роль человека или система | Показывает ответственность и точки передачи |
| Вход | Событие, документ или набор данных | Определяет условие начала шага |
| Действие | Один понятный глагол: проверяет, создаёт, назначает, согласует | Отделяет правило от общего описания |
| Инструмент | CRM, таблица, почта, мессенджер или ручной канал | Показывает точки интеграции и дублирование |
| Результат | Изменённый статус, созданная запись, решение или уведомление | Даёт проверяемый итог шага |
| Следующий шаг | Кому и при каком условии передаётся работа | Выявляет разрывы и ожидание без ответственного |
Исключения важнее идеального основного пути
Основной сценарий обычно описать несложно. Стоимость и устойчивость решения сильнее меняют ситуации, когда данных не хватает, сервис не отвечает, найден дубль, сотрудник не согласен с автоматическим решением или действие нельзя продолжать без проверки.
- Нет обязательных данных. Кто уточняет сведения и где фиксируется ожидание?
- Объект уже существует. Как обнаруживается и обрабатывается дубль?
- Система недоступна. Нужен ли повтор, уведомление или ручной маршрут?
- Правило неоднозначно. Кто принимает решение и видит контекст?
- Срок нарушен. Кому приходит сигнал и кто отвечает за следующий шаг?
- Нужна отмена. Какие действия можно откатить и что остаётся в журнале?
Если исключения пока неизвестны, соберите несколько недавних реальных примеров и спросите исполнителей, где им приходилось отходить от обычного порядка.
Шаблон, который можно заполнить перед разговором
Название: …
Владелец: …
Начальное событие: …
Конечный результат: …
Участники: …
Системы и каналы: …
Основные шаги: 1) … 2) … 3) …
Данные и документы: …
Известные исключения: …
Что сейчас выполняется вручную: …
Что нельзя выполнять без человека: …
Как проверяется результат: …
Что хотелось бы изменить в первом этапе: …
Необязательно заполнять каждый пункт идеально. Отметка «не знаем» полезнее выдуманного ответа: она показывает, что нужно проверить до оценки.
Что не нужно готовить заранее
- формальную BPMN-схему, если команда ею не пользуется;
- полное техническое задание с экранами и технологиями;
- список функций будущего решения без связи с процессом;
- точную архитектуру интеграций и выбор конкретного стека;
- обещанные показатели экономии без исходных измерений;
- описание всех процессов компании вместо одного первого потока.
Если процесс ещё не выбран, сначала используйте матрицу выбора первого процесса. Если участвуют внешние сервисы, после описания потока потребуется проверить API, доступы и ограничения интеграции.
Когда описание готово к содержательному разбору
Документ готов не тогда, когда выглядит профессионально, а когда другой человек может пройти по процессу без догадок и задать конкретные вопросы.
- видно начало и завершение одного процесса;
- у каждого шага есть исполнитель или система;
- указаны места хранения и передачи данных;
- отделены факты текущей работы от пожеланий;
- названы известные исключения и ручные решения;
- понятно, кто принимает спорные решения;
- первый этап можно ограничить одним проверяемым потоком;
- неизвестные сведения отмечены как вопросы для проверки.
После этого можно обсуждать формат решения, проверять техническую осуществимость и сопоставлять границу проекта с факторами стоимости автоматизации.
FAQ
Частые вопросы
Нужно ли рисовать BPMN-схему?
Нет. Для первого разговора достаточно последовательности шагов обычным языком: что запускает процесс, кто что делает, в каких системах и какой результат считается завершением.
Насколько подробно нужно описывать процесс?
До уровня, на котором видны передача ответственности, изменение данных, решения, ошибки и ручные действия. Детали интерфейсов и технической реализации уточняются позже.
Что делать, если сотрудники выполняют процесс по-разному?
Не скрывать различия. Зафиксируйте основной вариант и несколько реально встречающихся отклонений. Так станет понятно, какие правила устойчивы, а где сначала нужно договориться о порядке работы.
Можно ли описать процесс в таблице или обычном документе?
Да. Формат менее важен, чем ясные границы, участники, системы, данные и исключения. Таблица, документ или простая схема одинаково подходят для первичного разбора.
Что делать, если неизвестны объёмы и частота операций?
Укажите, что данные пока неизвестны, и договоритесь о коротком периоде наблюдения. Не заменяйте отсутствующие факты вымышленными средними значениями.
Достаточно ли такого описания для точной оценки разработки?
Обычно нет. Оно позволяет провести содержательный разговор и определить границу проверки. Для точной оценки дополнительно изучают системы, доступы, примеры данных, ограничения и критерии готовности.
СЛЕДУЮЩИЙ ШАГ
Хотите проверить границу процесса до разработки?
Принесите описание в любом удобном виде. На первичном разговоре определим, каких данных не хватает и какой следующий шаг реалистичен. Готовое техническое задание не требуется.