Какой процесс описывать первым

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

Сигнал

Что проверить

Решение

Разные люди получают разный результат

Одинаковы ли вход и критерий приёмки

Сначала определить результат и варианты

Задача застревает между ролями

Есть ли владелец, получатель и срок реакции

Описать handoff и escalation

Инструкция длинная, но её не открывают

Находится ли она в точке работы и отвечает ли на решение

Сократить до job aid и вынести справку

Редкое действие с высоким риском

Можно ли безопасно репетировать и кто подтверждает

Добавить checklist, second control и журнал

Процесс меняется каждую неделю

Стабильна ли хотя бы граница и цель

Зафиксировать minimum contract, не цементировать шаги

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

Шаг 1. Поставьте границы

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

  • Trigger: событие, после которого работа действительно начинается.

  • Input: минимально достаточные данные, материалы и полномочия.

  • Output: артефакт или состояние, а не действие исполнителя.

  • Acceptance: признаки, по которым получатель принимает выход.

  • Customer: внутренний или внешний получатель результата.

  • Out of scope: соседние задачи, которые документ не обещает покрыть.

Шаг 2. Снимите current state с исполнителями

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

Разведите наблюдение и предложение. В колонке current state храните факт; в improvement backlog — гипотезу улучшения. Иначе команда не сможет понять, что уже происходит, а что ещё предстоит проверить.

Шаг 3. Заполните шаблон процесса

Поле

Что записать

Проверочный вопрос

Название и цель

Глагол, объект и ценность результата

Зачем процесс существует?

Trigger и input

Событие старта и обязательный комплект

Можно ли отклонить неполный вход?

Output и acceptance

Результат и критерии приёмки

Кто подтвердит завершение?

Owner и роли

Один Accountable; Responsible, Consulted, Informed

Кто меняет правило и отвечает за итог?

Основной путь

Минимум шагов и decision points

Где меняется состояние?

Исключения

Известные ветки, stop и escalation

Когда исполнитель не должен импровизировать?

Controls и evidence

Проверка, запись, источник данных

Чем доказано выполнение?

Measure

Качество выхода, срок, возврат или дефект

Метрика помогает решению?

Версия

Дата, автор, причина и следующая проверка

Как узнать, что документ актуален?

Шаг 4. Разведите роли и полномочия

RACI полезен только на спорных передачах. Для каждой такой точки оставьте одного Accountable владельца результата. Responsible выполняет действие; Consulted даёт вход до решения; Informed узнаёт результат. Не назначайте каждого во все четыре колонки: это скрывает решение вместо того, чтобы его прояснить.

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

Шаг 5. Добавьте контроль без ритуала

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

  • Preventive control не допускает ошибочный вход или запрещённое действие.

  • Detective control обнаруживает отклонение до передачи результата.

  • Acceptance control подтверждает, что выход соответствует критериям получателя.

  • Monitoring показывает изменения процесса, но не заменяет разбор конкретного дефекта.

Шаг 6. Проведите три прогона

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

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

Как сделать описание используемым

  • Разместите краткий job aid там, где начинается работа: в карточке, форме или очереди.

  • Длинные определения и правовые справки вынесите по ссылке, не смешивая их с основным путём.

  • Назначьте owner, который принимает замечания и ведёт change log.

  • Дайте исполнителю простой способ отметить исключение или устаревший шаг.

  • После изменения системы, роли или входных данных запускайте повторный walkthrough.

  • Удаляйте шаг, если он не меняет состояние, не снижает риск и не создаёт evidence.

Мини-пример без вымышленного результата

Для процесса «подготовить ответ на входящий запрос» trigger может быть запись с обязательными контактными и предметными данными. Output — отправленный ответ и сохранённое основание решения. Acceptance — обязательные вопросы закрыты, обещание не выходит за полномочия, запись доступна следующей роли. Это только пример структуры: каналы, сроки и контроль компания подставляет из своего договора и фактической работы.

Ограничения

Статья не сертифицирует систему по ISO 9001 и не заменяет отраслевую, трудовую, финансовую или информационно-безопасностную проверку. RACI не передаёт юридические полномочия. Схема показывает договорённость команды; реальные права должны быть согласованы с уставом, договором, должностью и настройками систем.

Проверьте описание на трёх реальных входах

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

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

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

Версию процесса отмечайте датой и владельцем. Изменение вступает в работу только после короткого сообщения затронутым ролям, обновления job aid в точке использования и удаления устаревшей копии. Следующий review назначайте по событию: изменение продукта, системы, роли, требования или повторяющееся исключение, а не по случайному календарному ритуалу.

Практический следующий шаг

Выберите один поток с заметным handoff. За одну рабочую сессию заполните девять полей шаблона, затем проведите walkthrough по последнему реальному примеру. Запишите только три вида изменений: отсутствующая граница, неоднозначное решение и недоступное evidence. Назначьте owner и дату пересмотра.

  • BUS-19 — чек-лист передачи ответственности и полномочий.

  • BUS-18 — выбор KPI, OKR или обычного плана для управления изменением.

  • BUS-11 — карта стадий и evidence в B2B-продажах.

  • BUS-16 — матрица делегирования перед наймом первого сотрудника.

Что читать дальше

Источники и дата проверки

Источники проверены 26 июля 2026 года. ISO-материалы используются как process guidance; документы UK government — как методические источники, а не российские правовые нормы.

The process approach in ISO 9001:2015 — Официальный ISO guidance: inputs, outputs, activities, controls, measures, interactions и пропорциональная documented information.

ISO 9001 explained — Обзор process approach, responsibilities, monitoring and evidence-based improvement; не заменяет текст стандарта.

Guidance on Processes — Разъясняет objectives, inputs, outputs, activities, resources и отсутствие обязательного универсального формата.

Steps to create a process map — Практический официальный process-mapping guide: участники текущей работы, границы, inputs, outputs и baseline map.

Global HR Design Principles 2024 — Официальная HR process guidance с RACI и одним clear Accountable owner; применяется как методика, не российская правовая норма.

Guide to functional standards — Официальное guidance о ясных ролях, accountabilities, proportional assurance и stable basis for improvement.