Описание бизнес-процессов: с чего начать и как не утонуть в деталях

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

Зачем описывать процесс и когда этого делать не стоит

У описания есть три практических применения, и у каждого свой заказчик внутри компании.

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

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

Шаг 1. Выберите один процесс

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

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

Шаг 2. Обозначьте границы

До сбора шагов ответьте на четыре вопроса и запишите ответы вверху листа.

  1. Что запускает процесс. Пришла заявка, позвонил клиент, наступило первое число месяца. Если запусков несколько, перечислите все: заявка с сайта, звонок и сообщение в мессенджере это один старт с разными каналами.
  2. Чем процесс заканчивается. Концов почти всегда несколько: счёт оплачен, клиент отказался, заявка оказалась спамом. Каждый конец нужен на схеме, иначе половина реальных заявок не найдёт себе выхода.
  3. Что получается на выходе. Подписанный договор, отгруженный заказ, закрытая задача. Результат должен быть проверяемым: «клиент доволен» результатом не считается, «получен акт с подписью» считается.
  4. Кто внутри компании ждёт этот результат. Бухгалтерия ждёт документы, склад ждёт заявку на отгрузку. Этот человек первым скажет, что в описании упущено.

Шаг 3. Соберите шаги у исполнителей, а не у руководителя

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

С каждым, кто участвует в процессе, хватает разговора на двадцать-тридцать минут. Вопросы одни и те же:

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

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

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

Шаг 4. Запишите шаги в таблицу

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

Пример описания процесса «Заявка с сайта до выставленного счёта» для небольшой торговой компании. Условный, но собран из типичных ситуаций.
№ШагКтоВходВыходИнструментСрокЧто ломается
1Получает заявку с сайтаМенеджерПисьмо с формыСтрока в таблице заявокПочта, Excel—Письмо уходит в спам, заявка теряется
2Звонит клиенту, уточняет объём и срокиМенеджерСтрока в таблицеЗаполненные поля: объём, срок, адресТелефонВ тот же деньНе дозвонился, второй попытки нет
3Проверяет наличие на складеМенеджерСписок позицийОтвет «есть / под заказ»Чат со складом—Ответ ждёт до нескольких часов, менеджер переспрашивает
4Считает стоимостьМенеджерПозиции, объёмСметаExcel-шаблон—Старая версия прайса в шаблоне
5Согласовывает скидку, если она больше стандартнойРуководительСметаСогласованная сметаЧатНе заданСогласование теряется в переписке
6Готовит КП по шаблонуМенеджерСогласованная сметаPDF с КПWord—Позиции переносятся руками, ошибки в суммах
7Отправляет КП и назначает дату следующего контактаМенеджерPDFПисьмо клиенту, напоминание себеПочта, ежедневник—Напоминание не ставится, клиент забывается
8Выставляет счёт после согласияБухгалтерРеквизиты и КП от менеджераСчёт1С1 рабочий деньРеквизиты присылают в чате частями

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

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

Шаг 5. Найдите ручные участки и разрывы

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

  • Перенос данных руками из одной системы в другую: из письма в таблицу, из таблицы в Word. В примере это шаги 1 и 6.
  • Ожидание без срока. Кто-то ждёт ответа, а сколько ждать, не договорились. Шаги 3 и 5.
  • Согласование в чате. Решение принимается, но нигде не фиксируется, и через месяц его не найти. Шаг 5.
  • Память вместо системы. Следующий контакт с клиентом зависит от того, вспомнит ли менеджер. Шаг 7.
  • Один человек знает, как надо. Шаг умеет делать только он, и в его отпуск процесс останавливается.

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

Шаг 6. Нарисуйте схему по таблице

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

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

Шаг 7. Согласуйте с командой и зафиксируйте версию

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

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

Пять правил, которые удерживают описание на одном листе.

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

Что обычно всплывает в первый день

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

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

Что делать с описанием дальше

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

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