Как описать бизнес-процесс, если сотрудники делают его по-разному?

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

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

Почему «у нас каждый делает по-своему» — полезная находка

Эта фраза часто звучит как повод отложить автоматизацию. На самом деле она показывает, куда смотреть. Разные действия могут возникать по трём причинам.

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

Смешивать эти причины опасно. В первом случае нужна ветка процесса. Во втором — решение руководителя. В третьем — изменение инструмента. Если назвать всё «человеческим фактором», ничего из этого не станет понятнее.

Начните с одного живого объекта

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

Вопросы полезнее задавать в прошедшем времени:

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

Так разговор быстро уходит от общих слов. Вместо «мы согласовываем с руководителем» появляется конкретика: в каких случаях согласуем, чем подтверждаем решение, что происходит, если руководитель в дороге.

Найдите общий стержень

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

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

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

Не прячьте исключения под ковёр

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

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

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

Как не утонуть в деталях

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

Если ответа нет, добавляйте детали ровно там, где возникла неопределённость. Например, не надо рисовать все поля в карточке заказа, пока не стало ясно, что из-за одного пропущенного поля заказ уходит не тому сотруднику.

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

Что делать, если люди спорят о «правильном» пути

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

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

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

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

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

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

Короткий порядок действий

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

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

Связанные вопросы

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

Разная практика сотрудников — не помеха для описания процесса. Это исходный материал. Важно не усреднить реальность, а честно отделить правило, исключение и привычку. Тогда будущая система будет поддерживать работу, а не заставлять людей обходить её каждый день.