Шаблон документації процесу: як описати процес, щоб його дотримувалися (2026)

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

Більшість процесів уже десь описані: на схемі з воркшопу дворічної давності, на вікі-сторінці, яку ніхто не відкриває, в голові єдиної людини, що виконує цю роботу з самого початку. Проблема рідко в тому, що документа немає. Проблема в тому, що його не дотримуються, а причин цього три, і в кожній організації вони однакові. Цей посібник спершу розповідає про саме ремесло: що таке документ процесу і чим він не є, стандартний формат, шаблон, який можна скопіювати, приклад із життя. Далі йдуть три причини та що виправляє кожну, де документ і його розбір живуть в інструментах, якими ваша команда вже користується, і що отримує колега, який читає його іншою мовою. Адже документ процесу оцінюють у той ранок, коли новий менеджер з роботи з клієнтами, нова медсестра чи співробітник нового дистриб'ютора має щось передати наступній людині й не знає, хто це.

Що таке документ процесу — і чим він не є

На рівні процесу те, як виконується робота, описують три документи. Їх часто плутають між собою та з процедурами, що лежать під ними:

Карта — це картинка, документ процесу — текст, що робить картинку придатною до користування, а СОП — деталі під кожним блоком. Саме це розрізнення визначає обсяг: документ процесу, що пояснює, як клікати кожен крок, перетворюється на посібник, якого ніхто не читає, а карта без тексту — на картинку, яку всі тлумачать по-своєму. Про СОП, його шаблон і цикл перегляду читайте в статтях SOP template та how to write an 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. Пов'язані документи та історія змін. СОП під кожним етапом, політика, яку реалізує процес, посилання на карту; далі один рядок на версію — дата, що змінилося, хто затвердив. Саме історія не дає повторно внести ту саму помилку під новим номером версії.

Що лишається поза документом: обґрунтування кожного правила (справа політики), покрокові дії всередині етапу (справа СОП) і все, що людина не може виконати. «Ми цінуємо плавний онбординг» — це настрій, а не етап.

Як задокументувати процес, щоб його дотримувалися

Три причини пояснюють майже кожен документ процесу, якого не дотримуються, і кожна має виправлення, що належить до самого написання, а не до якогось подальшого примусу.

Причина перша: він описує процес таким, яким його задумано, а не таким, яким він працює. Документ написали на воркшопі ті, хто керує роботою, а ті, хто її виконує, мають іншу версію — з таблицею збоку й колегою, якому телефонують на етапі 3. Виправлення — зніміть карту з фактів, перш ніж писати. Простежте три реальні випадки від тригера до кінцевого стану й запишіть, що насправді відбувалося: листи, повідомлення, форми, очікування. Якщо процес живе в груповому чаті — замовлення від дистриб'юторів надходять у WhatsApp, обміни змінами погоджують у групі Telegram, — то чат і є доказом, а розбір починається з його історії: що дає Export chat і де він закінчується, розповідає стаття how to export a WhatsApp chat. Там, де три випадки розходяться, і є причина існування документа; для кожної відмінності вирішіть, чи це етап, який треба виправити в тексті, чи розмова, яку треба провести з командою.

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

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

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

Шаблон документації процесу

[ID процесу] — [Назва процесу]
Версія: [n.n] · Власник: [ім'я, роль] · Чинний з: [дата] · Наступний перегляд: [дата]

1. Мета й результат
[Одне-два речення — що цей процес дає, кому і як виглядає «добре», із числом, якщо воно є.]

2. Тригер і кінцевий стан
Починається, коли: [подія] · Закінчується, коли: [результат, що вже існує]

3. Межі застосування
Охоплює: [випадки, майданчики, клієнтів, країни] · Не охоплює: [що обробляє інший процес, з його ID]

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

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

6. Винятки та ескалація
Якщо [умова]: [що відбувається, хто вирішує]
Якщо [умова]: [що відбувається, хто вирішує]
Усе, що тут не описано: вирішує [роль]; випадок виносять на наступний перегляд.

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

8. Пов'язані документи та історія змін
СОП: [ID, по одному на етап, де потрібно] · Реалізує: [політика] · Карта: [посилання на діаграму]
v[n.n] — [дата] — [що змінилося] — затвердив(ла) [ім'я]
v[n.n] — [дата] — [що змінилося] — затвердив(ла) [ім'я]

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

Приклад із життя: онбординг нового працівника, від підписаного контракту до дня 30

Компанія з шістдесяти людей і працівниками в трьох країнах; процес охоплює чотири ролі й закінчується, коли зафіксовано 30-денний огляд.

PR-HR-02 — Онбординг нового працівника
Версія: 1.3 · Власник: Керівниця з операційної діяльності, Інес М. · Чинний з: 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-й день — затвердила Інес М.
v1.2 — 3 черв. 2026 — відправлення ноутбука перенесено на п'ять днів до початку після двох запізнілих доставок — затвердила Інес М.

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

Коротший другий приклад — форма процесу продажів для експортера з дистриб'юторами:

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

Дванадцять рядків — і новий співробітник дистриб'ютора, і нова людина на складі знають, на кого вони чекають.

Де документ процесу та його розбір живуть в інструментах, якими ви вже користуєтеся

Сам документ живе там, де живуть документи команди: файл Word у спільній бібліотеці, Google Doc, сторінка у вікі, канвас у каналі. Розбір — це зустріч, і кожна платформа має місце для того, що розбір залишає по собі; кожна зупиняється в різній точці. Лише задокументована поведінка, зі сторінок самих вендорів, із місяцем перевірки кожної сторінки:

Дві речі однакові всюди. Документ процесу — це файл тією єдиною мовою, якою його написано, а колега, який читає іншою мовою, читає саме його або копію, яку хтось зробив; і те, що змінив розбір, потрапляє до документа лише тоді, коли хтось вносить це пізніше вручну, цією ж мовою. Переклад, який задокументовано в цих пакетах, належить до дзвінка, а не до документа: Microsoft документує живі перекладені субтитри в зустрічах Teams, коли в організатора є ліцензія Teams Premium або Microsoft 365 Copilot, а Google документує перекладені субтитри в Meet на відповідних планах Workspace (обидва перевірено в серпні 2026). Що саме охоплює кожен і де кожен зупиняється — у статтях Microsoft Teams live translation та Google Meet live translation. Процес, який новий співробітник відкриває у вівторок, і розбір, що його змінив, — це окремі об'єкти порівняно з цими субтитрами, і їх читають тією мовою, якою їх надруковано.

Як процес, його розбір та історія лишаються читабельними для кожного учасника

InterMIND — це простір для спілкування, де робота команди живе в каналі, тож готовий документ процесу має очевидний дім: канал команди, яка веде процес, — один канал для людей з HR, IT, фінансів і керівників найму, кожен з яких відповідає за свій етап. Опублікований як нотатка — розширене текстове повідомлення із заголовками й нумерованими списками, яке пізніше редагують із власного меню, — він читається кожним учасником його мовою, а оригінал лишається за один перемикач, і закріплений, щоб актуальна версія була першим, що знайде новий колега; із увімкненою історією редагувань попередня редакція зміненого етапу з'являється над поточним текстом як порівняння на рівні слів із позначкою часу. Завантажений як файл — PDF або документ Word — він на кожному плані отримує AI-резюме мовою читача, де кожен пункт пов'язаний з абзацом, з якого його взято, тож односторінкове читання існує ще до того, як хтось його написав; на платних планах сам файл відкривається перекладеним мовою читача (30 мов для документів). Якщо майстер-копія лишається в інструменті для документів, її оновлення потрапляють у канал електронною поштою: хост каналу дає йому окрему адресу, а надіслане туди повідомлення з'являється як звичайне, з указаним відправником і збереженими вкладеннями.

Розбір починається з цього каналу. Під час дзвінка актуальна версія виводиться на екрани всіх поруч з відеоплитками через Share to conference — це нотатка або документ Google Docs чи OneDrive, на який є посилання в чаті, — і кожен учасник прокручує її незалежно та читає своєю мовою; спільну нотатку наживо редагує той, хто нею ділиться, поки кімната спостерігає, як набуває форми змінена передача. Коли дзвінок завершується, підсумок складається зі самої зустрічі — резюме, пункти, позначені як узгоджені, відкриті чи спірні, action items із відповідальними, кожен рядок зі збереженою позначкою часу, — а документи, якими ділилися під час сесії, додають свої резюме до сказаного. Він надходить електронною поштою, як повідомлення в каналі та як посилання в події календаря, і кожен авторизований учасник читає його своєю мовою: запис перекладається для кожного читача, а не пишеться один раз тією мовою, якою випадково розмовляла кімната. Будь-який учасник може його редагувати, кожна правка зберігає автора та історію ревізій, а канал зберігає підсумок кожної минулої сесії — тож розбір, що породив v1.3, лежить за один клік від нотатки, яка і є v1.3. Власний асистент учасника — Claude, ChatGPT, Copilot або Gemini, підключений через конектор MCP — шукає в підсумках, стенограмах, чатах і тексті спільних файлів одним запитанням, наприклад «чому ноутбук відправляють за п'ять днів до дати початку?», і читає сам документ; це працює в організаціях із увімкненими функціями ШІ. Якщо порівняти з таблицею вище, різниця — просте констатування факту: субтитри, які документують ці пакети, перекладають дзвінок, поки він триває; тут процес, його розбір та його історія — це єдиний запис, який кожен учасник читає своєю мовою.

Люди, що беруть участь у процесі, не завжди є працівниками. Клерк дистриб'ютора, що приймає замовлення, постачальник зарплатних послуг в іншій країні, підрядник, який відповідає за один етап: зовнішній учасник каналу приєднується за електронною поштою з безкоштовним обліковим записом і читає процес та його історію, як усі інші; людина без облікового запису — гість однієї зустрічі: вона приєднується до розбору за посиланням, з телефона, безкоштовно, чує його наживо своєю мовою, а запису потім не отримує. Хост надає простір і, на платному плані, платить лише за учасників, активних за попередні 28 днів — тих, хто приєднався до зустрічі, написав у чаті чи звернувся до асистента; учасники, які притихли, зберігають доступ безкоштовно.

• Відкрийте повний підсумок — справжній запис, відрендерений тим самим кодом, що пише ваш.
• Спробуйте живу демонстрацію — без реєстрації; говоріть і чуйте, як кімнату перекладають для кожного слухача.

Документація процесу як ремесло переживе будь-який інструмент: хтось усе одно має простежити три реальні випадки, записати етапи як передачі, які може перевірити друга людина, і пройти все разом з однією людиною від кожної ролі. А от друга робота переживати не повинна — вручну вести перекладену копію кожної версії та перенабирати те, що змінив розбір, однією мовою для людей, які читають іншими.

FAQ

Що таке документація процесу?

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

Що слід включити в документацію процесу?

Шапку з ID, версією, власником, датою набуття чинності та датою наступного перегляду; мету й результат; тригер і кінцевий стан; межі застосування, зокрема що процес не охоплює; ролі з одним названим власником процесу; етапи по порядку, кожен із роллю, входом, виходом і місцем фіксації, наступною роллю та граничним строком; винятки й ескалацію з тим, хто вирішує кожен; два-три показники; а також пов'язані СОП, політику, яку процес реалізує, та історію змін.

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

Оберіть один процес із чітким тригером і кінцевим станом. Простежте три реальні випадки від початку до кінця й запишіть, що насправді відбувалося, зокрема відгалуження. Спершу складіть чернетку етапів за шаблоном, кожен як передачу — роль, вхід, вихід, наступна роль, граничний строк. Додайте винятки, які виявили випадки, із зазначенням, хто вирішує кожен. Заповніть мету, межі, ролі та шапку. Пройдіть документ з однією людиною від кожної ролі, кожна читає вголос свій етап і підтверджує передачі. Опублікуйте там, де команда вже читає, з видимими власником і датою перегляду, і внесіть дату перегляду в календар.

Чим документація процесу відрізняється від СОП?

Документація процесу описує, як робота рухається між ролями й командами — етапи, передачі, що кожен етап залишає по собі, — на рівні однієї сторінки на процес. СОП описує, як один із цих етапів виконує одна роль, крок за кроком, аж до результату кожного кроку. Документ процесу підказує, де потрібні СОП і хто кому що передає; один СОП підказує одній людині, що робити у вівторок зранку. Якщо написати СОП на цілий міжкомандний процес, вийде посібник, який ніхто не відкриває; якщо написати документ процесу з деталізацією СОП, вийде те саме.

Які є приклади документації процесу?

Будь-який повторюваний потік, що перетинає ролі й має чіткі початок і кінець: онбординг нового працівника від підписаного контракту до дня 30; замовлення від дистриб'ютора до підтвердженої доставки та рахунку; скарга клієнта від прийому до закриття; пацієнт від направлення до першого прийому; новий продукт від затвердженого брифу до внесення в каталог; закриття місяця від табелів до надісланих рахунків. Приклад із життя в цьому посібнику — онбординг працівника: шість етапів у чотирьох ролях, три винятки, історія з трьох версій, а за ним коротший приклад від замовлення до доставки.

Чи є шаблон документації процесу у Word або Google Docs?

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

Хто має писати документацію процесу?

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

Як часто слід оновлювати документацію процесу?

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

Джерела: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; Slack — Meeting agenda template (canvas). Сторінки Microsoft, Google і Slack про нотатки зустрічей і шаблони перевірено в жовтні 2026; сторінку Zoom про підсумок зустрічі та сторінки Teams і Meet про субтитри перевірено в серпні 2026. Вендори з часом змінюють плани, функції та списки мов; актуальний стан дивіться на їхніх сторінках.