Шаблон документирования процессов: как описать процесс так, чтобы ему следовали (2026)

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

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

Что такое документ процесса и чем он не является

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

Карта — это картинка; документ процесса — текст, который делает картинку пригодной к использованию; SOP — детали под каждым блоком. Это различие определяет объём: документ процесса, объясняющий, куда нажимать на каждом шаге, превращается в инструкцию, которую никто не читает, а карта процесса без текста — в картинку, которую каждый толкует по-своему. SOP, его шаблон и цикл пересмотра описаны в шаблоне SOP и в статье как написать SOP; это руководство — об уровне выше: о том, который говорит, где нужны SOP и кто что кому передаёт.

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

Что включить: стандартный формат

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

Шапка — идентификация документа, пять полей в одной строке: ID, на который можно ссылаться («PR-HR-02»), версия («v1.3»), владелец — один названный человек, отвечающий за весь процесс, а не отдел, — дата вступления в силу и дата следующего пересмотра. Процесс без даты пересмотра пересматривают, когда что-то идёт не так.

1. Цель и результат. Одно-два предложения: что этот процесс даёт, кому и как выглядит хороший результат — с числом, если оно есть. «В первый день у нового сотрудника есть учётные записи, оборудование, план и назначенный наставник, а к 30-му дню проведена 30-дневная оценка».
2. Триггер и конечное состояние. Событие, которое запускает процесс, и результат, которым он заканчивается. «Начинается, когда подписанный договор попадает в папку HR; заканчивается, когда записана 30-дневная оценка». Всё между этими двумя предложениями — процесс; всё за их пределами — другой документ. Если у процесса нет чёткого конца, это два процесса.
3. Область применения. Когда процесс действует, а когда нет, с указанием соседних процессов по ID. «Сотрудники, работающие у нас по договору, в любой стране. Не относится: подрядчики (PR-HR-04); внутренние переводы (PR-HR-06)».
4. Роли. Каждая роль, которая встречается в этапах, с тем, за что она отвечает. Роли, а не имена, чтобы документ пережил найм нового сотрудника. Одна из ролей — владелец процесса, отвечающий за весь поток, включая передачи, за которые по умолчанию никто не отвечает.
5. Этапы и передачи. Сердце документа: этапы по порядку, для каждого — роль, которая его выполняет, что поступает (вход), что выходит и где это фиксируется (выход), кому передаётся и срок. Передача записывается явно — «кому: IT, к дню −5», — потому что именно на передаче процессы ломаются: обе стороны думают, что этим занимается другая.
6. Исключения и эскалация. Ветки вне штатного сценария: что происходит, когда разрешение опаздывает, проверка кредитоспособности не пройдена, владельца нет на месте. В каждом исключении указана роль или человек, который решает, — никогда не «спросите кого-нибудь». Последняя строка покрывает то, что вы упустили: «Всё, что здесь не описано: решает владелец процесса, а случай выносится на ближайший пересмотр».
7. Показатели. Два-три числа, за которыми следит владелец: время цикла от триггера до конечного состояния, число случаев в месяц, доля случаев с исключением. Не дашборд, а числа, которые сообщают владельцу, что процесс «уплывает», раньше, чем пожалуется человек.
8. Связанные документы и история изменений. SOP под каждым этапом, политика, которую реализует процесс, ссылка на карту; затем по одной строке на версию: дата, что изменилось, кто утвердил. История не даёт повторно внести ту же ошибку под новым номером версии.

Что остаётся за рамками: обоснование каждого правила (задача политики), подробности нажатий на этапе (задача SOP) и всё, на основании чего человек не смог бы действовать. «Мы ценим плавный онбординг» — это настроение, а не этап.

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

Три причины объясняют почти любой документ процесса, которому не следуют, и у каждой есть решение, относящееся к самому написанию, а не к какому-то последующему контролю.

Причина первая: документ описывает процесс, каким он задуман, а не каким он выполняется. Документ написали на воркшопе те, кто управляет работой, а у тех, кто её делает, своя версия — с таблицей «сбоку» и коллегой, которому звонят на этапе 3. Решение: восстановить процесс по фактам, прежде чем писать. Проследите три реальных случая от триггера до конечного состояния и запишите, что происходило на самом деле: письма, сообщения, формы, ожидания. Если процесс живёт в групповом чате — заказы от дистрибьюторов приходят в WhatsApp, обмен сменами договаривается в группе Telegram, — то чат и есть доказательная база, и прогон начинается с его истории: что даёт Export chat и где он заканчивается, описано в статье как экспортировать чат WhatsApp. Там, где три случая различаются, и есть причина существования документа; для каждого различия решите, это этап, который нужно исправить в тексте, или разговор, который нужно провести с командой.

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

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

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

Шаблон документирования процесса

[ID процесса] — [Название процесса]
Версия: [n.n] · Владелец: [имя, роль] · Действует с: [дата] · Следующий пересмотр: [дата]

1. Цель и результат
[Одно-два предложения: что этот процесс даёт, кому и как выглядит хороший результат, с числом, если оно есть.]

2. Триггер и конечное состояние
Начинается, когда: [событие] · Заканчивается, когда: [результат, который теперь существует]

3. Область применения
Охватывает: [случаи, площадки, клиентов, страны] · Не охватывает: [чем занимается другой процесс, с его ID]

4. Роли
Владелец процесса: [один человек, отвечающий за весь поток]
[Роль] — [за что она отвечает в этом процессе]
[Роль] — [за что она отвечает в этом процессе]

5. Этапы и передачи
5.1 [Этап] — [роль] — вход: [что поступает] — выход: [что выходит, где фиксируется] — кому: [следующая роль] — срок: [ограничение по времени]
5.2 [Этап] — [роль] — вход: … — выход: … — кому: … — срок: …
5.3 [Этап] — [роль] — вход: … — выход: … — кому: … — срок: …

6. Исключения и эскалация
Если [условие]: [что происходит, кто решает]
Если [условие]: [что происходит, кто решает]
Всё, что здесь не описано: решает [роль]; случай выносится на ближайший пересмотр.

7. Показатели
[Два-три числа, за которыми следит владелец, — время цикла, число случаев в месяц, доля случаев с исключением — и где их смотреть.]

8. Связанные документы и история изменений
SOP: [ID, по одному на этап, где нужно] · Реализует: [политика] · Карта: [ссылка на схему]
v[n.n] — [дата] — [что изменилось] — утвердил [имя]
v[n.n] — [дата] — [что изменилось] — утвердил [имя]

Шаблон — это простой текст с жирными подписями, поэтому он вставляется в файл Word, Google Doc, страницу вики, canvas в Slack или заметку в чате без переформатирования. Два раздела чаще всего остаются пустыми: передачи — «кому и к какому сроку» — и дата пересмотра; именно они определяют, будет ли процесс через год выполняться так, как сказано в документе.

Разобранный пример: онбординг нового сотрудника, от подписанного договора до 30-го дня

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

PR-HR-02 — Онбординг нового сотрудника
Версия: 1.3 · Владелец: руководитель операционного отдела, Inés M. · Действует с: 1 окт. 2026 · Следующий пересмотр: 1 апр. 2027

1. Цель и результат — В первый день у нового сотрудника есть рабочие учётные записи, оборудование, план на первый месяц и назначенный наставник, а к 30-му дню записана 30-дневная оценка — в какой бы стране он ни начинал.
2. Триггер и конечное состояние — Начинается, когда: подписанный договор попадает в папку HR. Заканчивается, когда: 30-дневная оценка записана в личное дело сотрудника.
3. Область применения — Сотрудники, работающие у нас по договору, в любой стране, в офисе или удалённо. Не относится: подрядчики (PR-HR-04); внутренние переводы (PR-HR-06).
4. Роли — Владелец процесса: руководитель операционного отдела. HR: личное дело, документы, расчёт зарплаты, приветственный пакет. IT: учётные записи, оборудование, доступы. Нанимающий менеджер: план, наставник, регулярные встречи. Финансы: настройка выплаты зарплаты.

5. Этапы и передачи
5.1 Открытие дела — HR — вход: подписанный договор — выход: запись об онбординге с датой начала, страной, менеджером, языком; приветственный пакет, отправленный на языке сотрудника — кому: IT и нанимающему менеджеру — срок: два рабочих дня после подписания
5.2 Учётные записи и оборудование — IT — вход: запись — выход: созданные учётные записи, ноутбук, отправленный на адрес сотрудника, доступы по профилю роли; подтверждение в записи — кому: HR — срок: за пять рабочих дней до даты начала
5.3 Документы и зарплата — HR, затем финансы — вход: запись, документы сотрудника (разрешение или регистрация, если этого требует страна) — выход: сотрудник в расчёте зарплаты, документы в деле — кому: нанимающему менеджеру — срок: дата начала
5.4 Планирование первого месяца — нанимающий менеджер — вход: запись — выход: 30-дневный план в деле, назначенный наставник, первая неделя в календаре сотрудника, приветственный звонок с командой забронирован — кому: сотруднику, в первый день — срок: накануне начала
5.5 Первый день — нанимающий менеджер и наставник — вход: план — выход: проведён приветственный звонок, пройден план, открытые вопросы сотрудника записаны в канале команды — кому: сотруднику — срок: конец первого дня
5.6 Регулярные встречи — нанимающий менеджер — вход: план, записанные вопросы — выход: встречи на 7-й и 30-й день, 30-дневная оценка записана в деле — кому: HR, для закрытия записи — срок: 30-й день

6. Исключения — Разрешение или регистрация не оформлены к дате начала: сотрудник начинает с задач, которые менеджер отметил как допустимые без них; HR отвечает за дальнейшие действия, а дата вносится в запись. Ноутбук не доставлен ко дню −2: IT отправляет временный из офисного запаса; руководителю операционного отдела сообщают в тот же день. Сотрудник в стране, где мы раньше не нанимали: этап 5.3 приостанавливается; руководитель операционного отдела в течение трёх рабочих дней решает вопрос о схеме с employer of record (PR-HR-05).
7. Показатели — Рабочие дни от подписания до готовых учётных записей (цель ≤ 7); доля сотрудников с записанной 30-дневной оценкой к 30-му дню (цель 100 %); вопросы, записанные в первую неделю, читаются на квартальном пересмотре, чтобы увидеть, какой этап постоянно их порождает.
8. Связанные документы — SOP-IT-03 «Новые учётные записи и доступы»; SOP-HR-08 «Настройка зарплаты по странам»; Политика онбординга, п. 2; карта: схема с дорожками в папке HR.
v1.3 — 1 окт. 2026 — приветственный пакет теперь отправляется на языке сотрудника; добавлена встреча на 7-й день — утвердила Inés M.
v1.2 — 3 июн. 2026 — отправка ноутбука перенесена на пять дней до начала после двух поздних доставок — утвердила Inés M.

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

Второй пример, покороче — форма процесса продаж для экспортёра с дистрибьюторами:

PR-SA-01 — От заказа до доставки · Владелец: руководитель экспорта · Начинается, когда: поступает заказ дистрибьютора · Заканчивается, когда: доставка подтверждена и счёт отправлен
1. Проверка заказа — владелец аккаунта — вход: заказ — выход: заказ подтверждён в системе или вопрос, возвращённый дистрибьютору — кому: финансам — срок: один рабочий день
2. Проверка кредитоспособности — финансы — вход: подтверждённый заказ — выход: разрешён или задержан с указанием причины — кому: складу — срок: один рабочий день
3. Комплектация и упаковка — склад — вход: разрешённый заказ — выход: упакован, с упаковочным листом — кому: логистике — срок: три рабочих дня
4. Документы и отправка — логистика — вход: упакованный заказ — выход: отправка забронирована, документы для страны назначения приложены, трекинг в системе — кому: финансам и владельцу аккаунта — срок: один рабочий день
5. Счёт и подтверждение — финансы, затем владелец аккаунта — вход: отправка — выход: счёт отправлен; доставка подтверждена у дистрибьютора и записана — Если кредит задержан: владелец аккаунта звонит дистрибьютору в течение одного рабочего дня; руководитель экспорта решает, разрешить отгрузку или потребовать предоплату.

Двенадцать строк — и новый сотрудник у дистрибьютора, и новый человек на складе знают, чьего хода они ждут.

Где живут документ процесса и его прогон в инструментах, которыми вы уже пользуетесь

Сам документ живёт там, где живут документы команды: файл Word в общей библиотеке, Google Doc, страница вики, canvas в канале. Прогон — это встреча, и у каждой платформы есть место для того, что прогон оставляет после себя; каждая останавливается в своей точке. Только задокументированное поведение, по страницам самих вендоров, с месяцем проверки каждой страницы:

Две вещи везде одинаковы. Документ процесса — это файл на одном языке, на котором он написан, и коллега, который читает на другом языке, читает именно его или копию, сделанную кем-то; а то, что изменил прогон, попадает в документ, только когда человек потом набирает это вручную, на том же языке. Перевод, который документируют эти пакеты, относится к звонку, а не к документу: Microsoft описывает живые переведённые субтитры во встречах Teams, когда у организатора есть лицензия Teams Premium или Microsoft 365 Copilot, а Google описывает переведённые субтитры в Meet на подходящих тарифах Workspace (оба проверены в августе 2026). Что именно охватывает каждый вариант и где он заканчивается, описано в статьях живой перевод в Microsoft Teams и живой перевод в Google Meet. Процесс, который новый сотрудник открывает во вторник, и прогон, который его изменил, — это объекты, отдельные от этих субтитров, и читаются они на том языке, на котором были набраны.

Как процесс, его прогон и его история остаются читаемыми для каждого участника

InterMIND — это пространство для общения, где работа команды живёт в канале, поэтому у готового документа процесса есть очевидное место: канал команды, которая ведёт процесс, — один канал для людей из HR, IT, финансов и нанимающих менеджеров, каждый из которых отвечает за свой этап. Опубликованный как заметка — сообщение с форматированным текстом, заголовками и нумерованными списками, которое потом редактируется из собственного меню, — документ читается каждым участником на его языке, а оригинал доступен одним переключением, и закрепляется, чтобы актуальная версия была первым, что находит новый коллега; при включённой истории правок прежняя формулировка изменённого этапа отображается над текущим текстом в виде диффа на уровне слов с отметкой времени. Загруженный как файл — PDF или документ Word — он получает на любом тарифе ИИ-сводку на языке читателя, где каждый пункт связан с абзацем, из которого он взят, так что одностраничное краткое изложение существует раньше, чем кто-либо его написал; на платных тарифах сам файл открывается переведённым на язык читателя (30 языков для документов). Если мастер-копия остаётся в инструменте для документов, её обновления попадают в канал по email: хост канала даёт ему собственный адрес, и отправленное туда письмо появляется как обычное сообщение с указанием отправителя и сохранёнными вложениями.

Прогон начинается из этого канала. Во время звонка актуальная версия выводится на экран у всех рядом с плитками видео через Share to conference — заметка либо документ Google Docs или OneDrive, ссылка на который есть в чате, — и каждый участник прокручивает её независимо и читает на своём языке; общую заметку живьём редактирует тот, кто ею поделился, пока комната наблюдает, как обретает форму изменённая передача. Когда звонок заканчивается, рекап пишется по самой встрече: сводка, пункты с отметкой «согласовано», «открыто» или «спорно», action items с владельцами, каждая строка с сохранённой отметкой времени, — а документы, показанные в ходе сессии, добавляют свои краткие изложения к тому, что было сказано. Он приходит по email, как сообщение в канале и как ссылка в событии календаря, и каждый авторизованный участник читает его на своём языке: запись переводится для каждого читателя, а не пишется один раз на языке, который случайно использовала комната. Любой участник может её редактировать, каждая правка сохраняет автора и историю версий, а канал хранит рекап каждой прошедшей сессии — так что прогон, который породил v1.3, находится в одном клике от заметки, которая и есть v1.3. Собственный ассистент участника — Claude, ChatGPT, Copilot или Gemini, подключённый через коннектор MCP, — ищет по рекапам, транскриптам, чатам и тексту общих файлов одним вопросом, например «почему ноутбук отправляют за пять дней до даты начала?», и читает сам документ; это работает для организаций с включёнными функциями ИИ. В сопоставлении с таблицей выше разница — простая констатация факта: субтитры, которые документируют эти пакеты, переводят звонок, пока он идёт; здесь процесс, его прогон и его история — это одна запись, которую каждый участник читает на своём языке.

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

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

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

FAQ

Что такое документирование процессов?

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

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

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

Как документировать процесс шаг за шагом?

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

В чём разница между документацией процесса и SOP?

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

Какие бывают примеры документации процессов?

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

Есть ли шаблон документации процесса в Word или Google Docs?

Шаблон в этом руководстве — простой текст с жирными подписями, поэтому он вставляется в документ Word, Google Doc, страницу вики, canvas в Slack или заметку в чате без переформатирования. Формат важнее файла: то, в чём хранится документ, должно содержать шапку с владельцем и датой пересмотра, триггер и конечное состояние, этапы, записанные как передачи между ролями со сроком, названного решающего для каждого исключения и историю изменений — и жить там, где люди, ведущие процесс, уже читают.

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

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

Как часто нужно обновлять документацию процесса?

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

Источники: Microsoft — Ведение заметок встречи в Microsoft Teams; Microsoft — Использование живых субтитров во встречах Microsoft Teams; Zoom — Использование Meeting Summary с AI Companion; Google — Настройки Calendar и Meet для «Take notes for me»; Google Meet — «Take notes for me» в Google Meet; Google Meet — Использование переведённых субтитров; Slack — Шаблон повестки встречи (canvas). Страницы Microsoft, Google и Slack о заметках встреч и шаблонах проверены в октябре 2026 года; страница Zoom о сводке встречи и страницы Teams и Meet о субтитрах проверены в августе 2026 года. Вендоры со временем меняют тарифы, функции и списки языков; актуальное состояние смотрите на их страницах.