Ops · Processes

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

Простой формат документов и шаблоны, которые люди читают и применяют

Зачем вообще описывать процесс

Чтобы любой новый человек мог войти в задачу без часового онбординга.
Чтобы ошибки были предсказуемы, а не сюрпризом каждый день.
Чтобы можно было автоматизировать: без понятных шагов автоматизировать нечего.
Чтобы договорённости не жили “в голове у одного человека”.

Хороший документ по процессу — это не “регламент на полкомпании”, а 1–3 страницы, которыми реально пользуются.

Формат документа

Минимальный каркас, который закрывает 80% случаев:

Заголовок: название процесса + цель в одном предложении.

“Онбординг нового сотрудника: довести до продуктивности за 14 дней.”
Триггер: с какого момента процесс начинается.

“Подписан оффер”, “поступила заявка”, “клиент не платит 7 дней”.
Входы: что нужно, чтобы начать. Документы, данные, доступы, исходные артефакты.
Шаги: пошагово, 5–10 шагов. Каждый шаг: кто делает → что делает → чем результат считается “готов”.
Выходы: что должно быть на выходе, чтобы процесс считался завершённым. Документ, статус в системе, письмо клиенту, проведённый платёж.
Owner процесса: роль или конкретный человек, ответственный за результат. Не “все вместе”, а один.
SLA (Service Level Agreement): сколько времени нормальным считается.

“Ответ клиенту — до конца рабочего дня”, “онбординг — 14 дней”.
Метрики (по желанию): 1–2 числа, которые показывают, жив процесс или мёртв.

время цикла, % ошибок, % просрочек.

Фундаментальные принципы процесса, которым пользуются

Кратко > подробно Лучше 1,5 страницы, которые читают, чем 30 страниц, которыми машут на проверке.
Одна страница — один процесс Не смешивать “продажи”, “доставку” и “закупки” в одном документе.
Шаг = действие + результат Плохо: “Проверить заказ”. Хорошо: “Менеджер проверяет оплату и ставит статус Оплачено в CRM”.
Один owner Если “ответственны все” — не отвечает никто.
Процесс должен отражать реальность Не как “мы хотели бы работать”, а как фактически работаем сейчас. И уже потом улучшать.
Обновляемость важнее идеальности Процесс, который можно поправить за 5 минут, лучше, чем идеальная схема, которую все боятся трогать.

Параллельные точки зрения: как разные люди смотрят на один и тот же процесс

1. Точка зрения предпринимателя

“Процесс = деньги и риски”.

Задача: чтобы не терялась выручка и не рос бардак.
Важно видеть:
- где деньги “застревают”;
- где узкие места (узкие горлышки);
- где можно автоматизировать и сократить ручной труд.

Хороший документ для предпринимателя отвечает на вопросы: “Сколько это занимает времени, кто застревает и что будет, если этот человек уйдёт?”

2. Точка зрения операционного менеджера

“Процесс = управляемый конвейер”.

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

Менеджеру не нужны поэмы. Ему нужно видеть: “Кто? Что делает? С каким дедлайном? Где я увижу, что всё сломалось?”

3. Точка зрения исполнителя

“Процесс = как мне работать, чтобы ко мне не придирались”.

Задача: понимать, что именно от него ждут.
Важно:
- примеры (“готово — это когда…”);
- минимальная бюрократия;
- “если что-то пошло не так — к кому идти”.

Если после чтения документа исполнитель думает: “Окей, завтра я буду делать вот так” — процесс описан хорошо.

4. Точка зрения аналитика/автоматизатора

“Процесс = набор шагов и данных для автоматики”.

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

Хорошее описание процесса можно почти напрямую превратить в BPMN, n8n-сценарий или бота.

5. Точка зрения нового сотрудника

“Процесс = инструкция по выживанию”.

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

Если джун после документа может в первый же день выполнить задачу — процесс описан хорошо.

6. Точка зрения клиента (внешнего или внутреннего)

“Процесс = качество и сроки”.

Задача: получить предсказуемый результат в понятный срок.
Важно:
- чтобы SLA были реалистичными и выполнялись;
- чтобы не было бесконечных “мы уточним и вернёмся”.

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

Мини-шаблон документа процесса

# Название процесса

**Цель:**
Коротко: зачем существует процесс и какой результат считается успехом.

**Триггер:**
С какого момента процесс запускается (событие или условие).

**Входы:**
- Что нужно, чтобы начать (данные, документы, доступы).

**Шаги:**
1. Роль/человек — действие — результат шага.
2. Роль/человек — действие — результат.
3. ...

**Выходы:**
- Что должно быть на выходе (документ, статус, действие, уведомление).

**Owner процесса:**
- Роль/имя, ответственная за результат процесса целиком.

**SLA:**
- Нормальный срок выполнения процесса или ключевых шагов.

Его можно копипастить как базовый шаблон и заполнять под конкретный процесс.

Типичные ошибки при описании процессов

Слишком много текста. Когда процесс проще спросить у коллеги, чем найти в документе.
Нет триггера и выхода. Люди не понимают, когда начать и когда “можно считать, что всё сделано”.
Роли описаны размыто. “Менеджер”, “специалист”, “ответственный” — без имён и конкретики.
Нет SLA. Время выполнения — всегда “ну как получится”. Получается обычно плохо.
Процесс описан “по мечте”, а не по факту. На бумаге красиво, в реальности — никто так не делает.
Документ не живой. Его нельзя быстро поправить, нет ответственного за обновление.

Быстрый self-check: хороший ли у вас документ по процессу

Ответьте на три вопроса:

Может ли новый человек по этому документу выполнить задачу без дополнительного созвона?
Понятно ли, кто отвечает за результат, а не только “делает шаги”?
Можете ли вы, глядя в документ, понять, в каком месте сейчас “застревает” работа?

Если хотя бы на один вопрос ответ “нет” — процесс стоит пересмотреть.