Как описывать бизнес-процессы, которыми будут пользоваться сотрудники

Минимальная карта процесса

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

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

Подробности исходного материала

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

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

Третий раз до меня наконец дошло, в чём была ошибка. Я каждый раз описывал процесс так, будто его будет читать робот: формально, полно, без единого живого слова. А читать его должен был человек — уставший, в середине рабочего дня, которому нужно быстро понять, что делать прямо сейчас. И вот тогда я переписал всё заново, уже не для папки.

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

Почему регламент превращается в инструкцию для робота?

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

Я разбирал десятки таких регламентов на встречах с компаниями. Закономерность одна: чем подробнее документ, тем реже в него заглядывают. Сорок страниц про то, как принять входящую заявку, проигрывают одной странице, где написано просто и по делу. Мозг сотрудника защищается от стены текста — он закрывает файл и идёт спрашивать у соседа. А раз спрашивает у соседа, значит, ваш документ не работает, как бы полон он ни был.

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

И третье — язык. «Осуществляется приёмка», «производится согласование», «формируется заявка». Кто осуществляет? Кто формирует? В таком тексте нет людей, только безличные действия в воздухе. Сотрудник читает и не понимает, его это касается или нет. Я завёл себе простое правило: если в предложении не видно человека, который что-то делает руками, предложение надо переписать. «Заявка формируется» — кем? «Менеджер заводит заявку в CRM» — вот теперь понятно, кто и что.

Складывается всё это в один грустный итог: компания тратит недели на описание, получает толстую папку и ровно ничего не меняется в работе. Люди как дёргали руководителя по мелочам, так и дёргают. А вывод обычно делают неправильный: «регламенты у нас не приживаются, народ не тот». Народ нормальный. Документ плохой.

Что значит описать бизнес-процесс по-человечески?

Описать бизнес-процессы по-человечески — значит написать так, чтобы конкретный Петя из отдела продаж прочитал и понял, что ему делать в понедельник утром. Не «менеджер осуществляет квалификацию лида», а «ты смотришь, оставил ли клиент телефон, и если да — звонишь в течение пятнадцати минут». Живой субъект, живое действие, понятный результат. Человек должен узнать в тексте свой рабочий день, а не чужую отчётность.

Главный сдвиг в голове такой: вы пишете не документ о компании, а инструкцию для конкретного читателя в конкретной ситуации. Меняется всё — длина, язык, уровень детализации. Документ о компании хочет быть полным. Инструкция для человека хочет быть понятной. Это разные цели, и они часто противоречат друг другу.

С чего начинать — со схемы или с разговора?

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

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

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

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

Ровно такой, чтобы новый сотрудник справился без вас, и ни одной строчкой больше. Это главный критерий. Не «полнота», не «системность» — а проходимость для живого человека. Спросите себя про каждую строчку: если я это уберу, новичок ошибётся? Нет — значит, строчка лишняя.

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

Карта метро, а не чертёж завода

Вот метафора, которая мне помогла перестать городить простыни. Хороший процесс — это карта метро. Чертёж завода тоже точен, но по нему не доедешь до нужной станции: слишком много деталей, и все важные одинаково.

Карта метро врёт про реальную географию. Расстояния искажены, реки нарисованы условно, углы неправильные. И именно поэтому ей можно пользоваться. Она оставила только то, что нужно пассажиру: где я, куда мне, где пересадка. Всё остальное убрали сознательно. Дизайнер карты метро — это в первую очередь тот, кто решил, что выбросить.

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

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

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

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

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

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

Сначала — выбрать один процесс, который болит. Не описывать всю компанию сразу (это путь к той самой папке). Берёте то, что чаще всего ломается или чаще всего отвлекает вас лично. Обычно это приём заявок, передача между отделами или что-то на стыке «продажи — производство». Дальше — посидеть рядом с тем, кто его выполняет, и записать реальные шаги. Потом — выписать их крупно, семь-десять штук, человеческим языком с живыми субъектами. После — отдать черновик исполнителю и спросить: «Сможешь по этому работать, если меня не будет?». И последнее — выкинуть всё, на что он ответил «и так понятно».

Обратите внимание: четыре из пяти шагов — это не про написание, а про наблюдение, проверку и чистку. Само писательство занимает меньше всего времени. Большинство проваливает описание именно потому, что сразу садится писать, пропустив наблюдение, — и фиксирует не процесс, а представление о нём.

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

Какой формат выбрать: текст, таблицу или схему?

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

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

Что делать, когда процесс описан, а им всё равно не пользуются?

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

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

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

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

И третье, неудобное: руководитель сам должен перестать отвечать на вопросы, ответ на которые уже есть в документе. Пока вы по доброте душевной объясняете на словах то, что написано, команда не будет открывать регламент — зачем, если можно спросить у вас. В Тинькофф, когда масштабировали поддержку, именно дисциплина «ответ есть в базе знаний — отправляем в базу, а не пересказываем» позволила вырастить штат, не утонув в ручном обучении каждого. Жёстко, но работает.

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

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

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

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

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

Частые вопросы

Нужны ли специальные программы и нотации вроде BPMN?

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

Как часто обновлять описания процессов?

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

Кто должен описывать процессы — руководитель или сами сотрудники?

Лучше вместе. Сотрудник знает, как всё происходит на самом деле, руководитель — как должно быть и зачем. Если описывает только руководитель, выходит фантазия. Если только сотрудник, фиксируется в том числе и то, что давно пора менять. Истина рождается, когда они садятся рядом и сверяют картинку.

С какого процесса начать, если их много?

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

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

Константин Тарасов Автор

Предприниматель, бизнес-трекер, пишу о том, как развивать бизнес в условиях неопределенности