Основи картування процесів: почніть без BPMN

Спочатку "as-is", потім "to-be"

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

Карта поточного стану («as-is») показує, як процес насправді працює сьогодні, а не лише те, що написано в документах. У багатьох МСП процеси приймання замовлень, виставлення рахунків або залучення нових клієнтів не змінювалися роками, але ніде не записані. Ця прогалина — головний ризик під час переходу до автоматизації: автоматизація незадокументованого процесу відтворює і його помилки.

Конкретний приклад для МСП у Туреччині: ви хочете автоматизувати електронне виставлення рахунків. Якщо не записано, хто створює рахунок, хто його схвалює, як він надходить до клієнта й що відбувається в разі заперечень, спочатку опишіть цей порядок. Достатньо стікерів, дошки Miro або таблиці Excel із чотирма стовпцями. Вивчати BPMN чи купувати Visio не потрібно.

Коли карта поточного стану готова, проєктувати цільовий стан («to-be») стає значно простіше. Видно не лише те, що зміниться, а й те, що залишиться. Рішення щодо оптимізації ґрунтуються на реальних даних, а не на інтуїції.

Складіть карту процесу за 1 годину: підхід з 4 стовпцями

Процес можна описати без складних інструментів: достатньо таблиці Excel із чотирма стовпцями або дошки в Miro. Кожен рядок — один крок. Стовпці:

1. Крок — що робиться? Коротка дієслівна форма: «створити рахунок», «дочекатися погодження», «внести в систему». 2. Хто виконує крок? Назва ролі, а не ім’я людини: бухгалтерія, менеджер із продажу, клієнт. 3. Вхідні дані — що потрібно для початку кроку: форма, лист, погодження, запис у системі. 4. Результат — що з’являється після кроку: документ, повідомлення, запис у базі даних.

Ці чотири стовпці нагадують просту діаграму з розподілом за ролями й не потребують знань програмування. За годинну робочу зустріч із двома-трьома учасниками, які знають процес, можна заповнити всю таблицю за допомогою стікерів.

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

Коли карту складено, поставте щодо кожного кроку три запитання: «Чи можна його автоматизувати? Прибрати? Об’єднати?». Вони допомагають усунути зайву складність.

Коли картований процес готовий до автоматизації

Не кожен картований процес готовий до автоматизації. Перед переходом до автоматизації процес має відповідати чотирьом критеріям:

1. Повторюваність і витрати: оцінюйте разом обсяг, час на випадок, винятки та супровід. Сама частота не доводить доцільності автоматизації.

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

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

4. Допустимість помилок: якщо помилка в процесі веде безпосередньо до втрати клієнта, правового порушення або фінансової шкоди, комплексне тестування перед автоматизацією обов'язкове.

Процеси, що відповідають усім чотирьом критеріям, найбільш готові до автоматизації.

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

Крок, який пропускає більшість команд: поговорити з тими, хто виконує роботу

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

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

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

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