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

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

Схема бизнес-процесса с последовательностью этапов и возвратом к предыдущему шагу.

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

Для первого разговора об автоматизации полезнее описать один процесс в его текущем виде — AS-IS. Не весь бизнес и не идеальный порядок из регламента, а путь конкретной задачи: от события, которое запускает работу, до проверяемого результата.

В материалах ISO по процессному подходу предлагается смотреть на процесс через его цели, входы, выходы, последовательность действий, ресурсы, риски и измерения. При этом ISO не требует единственной формы документа: подойдут текст, чек-лист, таблица или схема. Для небольшой компании достаточно начать с двух простых форм — карточки процесса и таблицы шагов.

Коротко о главном

  • Описывайте один процесс с ясным началом и концом, а не работу компании целиком.
  • Фиксируйте фактический порядок AS-IS, включая чаты, повторный ввод данных, ожидания и действия «по памяти».
  • Отделяйте проблемы и открытые вопросы от функций будущей системы.

Что считать одним процессом

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

Для пилотного разбора лучше выбрать более узкий объект, например «обработка входящей заявки от поступления до исполнения и оплаты». Началом будет получение заявки по одному из рабочих каналов. Концом — не абстрактное «клиент доволен», а состояние, которое можно проверить: работа принята, сумма поступила, обязательные документы сохранены.

Граница зависит от задачи. Если автоматизируется только первичная обработка обращений, процесс может заканчиваться передачей квалифицированной заявки ответственному. Главное — записать это решение явно, чтобы участники не обсуждали разные процессы под одним названием.

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

Как собрать AS-IS без отдельного проекта по бизнес-анализу

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

Шаги

  1. 1. Выберите один завершённый случай

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

  2. 2. Зафиксируйте начало, конец и результат

    Назовите событие запуска, проверяемое условие завершения и получателя результата.

  3. 3. Восстановите основной путь

    Идите по времени и называйте конкретные действия: «менеджер переносит телефон из сообщения в таблицу», а не «обрабатываем заявку». Пока не улучшайте порядок.

  4. 4. Добавьте решения и исключения

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

  5. 5. Привяжите данные, инструменты и метрики

    Для каждого шага укажите входы, выходы, документы, каналы и системы. Добавьте доступные данные об объёме, времени, ожиданиях и ошибках; отсутствующие метрики пометьте как неизвестные.

  6. 6. Проверьте описание и соберите вопросы

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

Практический шаблон описания бизнес-процесса

Удобно разделить описание на два уровня. Карточка процесса задаёт границы и контекст. Таблица шагов показывает механику работы.

1. Карточка процесса

Скопируйте поля ниже в документ или таблицу. Заполняйте коротко; подробности действий будут на втором уровне.

Сравнение
ПолеЧто записать
НазваниеДействие и объект, без названия отдела
ГраницыСобытие запуска и условие завершения
РезультатПроверяемое состояние после завершения
ОтветственныеВладелец процесса и роли участников
Данные и инструментыВходы, выходы, системы и каналы
Объём и проблемыЧастота, сроки, ошибки и ручные обходы

Листайте таблицу вправо →

2. Таблица шагов

Одна строка должна описывать одно действие одного исполнителя. Если в строке есть «и», проверьте, нельзя ли разделить её на два шага.

Для каждого шага зафиксируйте:

Чеклист

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

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

Учебный пример: заявка → исполнение → оплата

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

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

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

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

  • как регистрировать обращения из разных каналов и сохранять исходную переписку;
  • какие данные обязательны для оценки и кто меняет статус;
  • где хранить актуальные файлы и какие события требуют уведомления;
  • как сверять оплату и какие исключения оставить ручными на первом этапе.

Ответы влияют на выбор готового продукта и объём заказной разработки, поэтому открытые вопросы нужно сохранить рядом с описанием AS-IS.

Как найти точки автоматизации, не проектируя систему заранее

Пройдите по шагам и сгруппируйте наблюдения, прежде чем предлагать функции.

Повторный ввод и разрозненные статусы. Найдите данные, которые копируют между каналами, и определите надёжный источник записи.

Ожидание передачи. Зафиксируйте событие, после которого следующий участник может начать работу, получателя и допустимое ожидание.

Решения без правила. Выясните критерии, допустимые исключения и владельца правила. Не каждое экспертное решение нужно автоматизировать.

Ручная сверка и возвраты. Запишите идентификаторы сопоставляемых объектов, допустимые расхождения, причину возврата и условие выхода из повторного цикла.

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

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

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

Чеклист

  • У процесса есть одно понятное начало, конец и проверяемый результат.
  • Названы роли, их действия и передачи ответственности на основном пути.
  • Для шагов понятны входы, выходы, источники данных, системы и каналы.
  • Записаны существенные исключения, решения без формального правила и ручные обходы.
  • Описание проверено на реальном случае; неизвестные метрики и спорные места собраны в список с ответственными.

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

Нужна ли схема и BPMN

Таблица удобна для данных, правил, времени и комментариев. Простая схема быстрее показывает последовательность, развилки, возвраты и передачи между ролями. BPMN — стандартизированная нотация Object Management Group; она полезна для согласования сложной модели аналитиками и разработчиками, но необязательна для первой оценки. Нотация не заменяет сведения о данных, исключениях и ручных обходах. Любой формат проверяйте на реальном случае.

Следующий шаг

Выберите одну-две проблемы, ради которых рассматривается изменение, и определите желаемый наблюдаемый результат и ограничения. Затем можно сравнивать организационные изменения, готовый сервис, интеграцию и отдельную разработку, формировать TO-BE и оценивать риски, сроки и стоимость.

Была ли статья полезна?

Atal Code

Разобрать процесс перед автоматизацией

Если фактический процесс уже описан или пока существует только в таблицах и переписке, Atal Code может помочь разобрать AS-IS, определить границы первого этапа и подготовить основу для оценки интеграции или разработки.

Обсудить проектЕщё статьи