Як скласти карту бізнес-процесу малого бізнесу

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

Карта бізнес-процесу допомагає описати послідовність дій та обговорити її з тими, хто справді виконує роботу. Почати можна з одного невеликого процесу в конструкторі карти FBD. Інструмент структурує введені дані, але правильність опису команда має перевірити сама.

Що таке карта бізнес-процесу

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

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

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

Для складніших схем існує стандарт нотації бізнес-процесів BPMN від OMG. Описана тут картка є спрощеним текстовим інструментом FBD; вона не заявляє відповідності BPMN і не створює виконуваної схеми процесу.

Крок 1. Визначте межі процесу

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

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

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

Крок 2. Зберіть фактичні кроки разом із командою

Запросіть людей, які виконують роботу або отримують її результат. Попросіть показати типовий приклад без персональних даних. Запитайте, що відбувається після кожної події, які відомості потрібні і кому передається наступна дія.

Для кожного кроку опишіть:

1. Назву дії зрозумілим дієсловом.
2. Відповідальну роль, наприклад менеджер з продажів.
3. Умову, яка запускає роботу.
4. Очікуваний результат.
5. Кому і що передається далі.
6. Спосіб перевірити, що крок завершено.

Роль і конкретна людина не обов’язково збігаються. Власник може виконувати кілька ролей, а одну роль можуть покривати кілька працівників. Опис ролей допомагає оновити процес без переписування карти після кожної зміни в команді.

Приклад карти: від звернення до замовлення

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

Крок 1. Прийняти звернення. Відповідальна роль фіксує канал і короткий опис запиту. Результат: команда знає, що звернення отримано, та бачить наступну дію. Передача: менеджеру, який уточнює потребу. Контроль: у запису є відповідальна роль і час наступного контакту.

Крок 2. Уточнити потребу. Менеджер з’ясовує очікуваний результат, обсяг, обмеження і строк. Результат: зрозумілий запит для підготовки пропозиції. Передача: відповідальному за розрахунок. Контроль: суттєві припущення узгоджені з клієнтом.

Крок 3. Підготувати пропозицію. Відповідальний формує обсяг робіт, ціну, межі й наступний крок. Результат: пропозиція, яку можна обговорити. Передача: менеджеру для супроводу. Контроль: усі умови перевірено перед надсиланням.

Крок 4. Виконати домовленість. Команда починає роботу після погодження умов. Результат: переданий клієнту товар або послуга відповідно до домовленості. Контроль: команда звіряє виконання з погодженим обсягом і фіксує завершення.

У реальному процесі можуть бути додаткові перевірки, повторні контакти або відмова клієнта. Запишіть ці варіанти окремо та перевірте, хто приймає рішення в кожному з них.

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

Крок 3. Знайдіть нечіткі передачі

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

Уточніть мінімальний склад передачі: опис потреби, погоджений строк, наступна дія та джерело підтверджених даних. Важливі домовленості потрібно перевірити, а не припустити. Якщо результат повертається на попередній етап, зафіксуйте умову повернення.

У відкритому онлайн-інструменті використовуйте знеособлені приклади. Не вносьте імена клієнтів, контактні дані, паролі, банківські реквізити або дані гостей. Для реальних документів використовуйте сховище компанії з належним доступом.

Крок 4. Перевірте сигнали можливого вузького місця

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

Вимірюйте показники за однаковий період і в однакових одиницях. Якщо за тиждень на етап надійшло 20 задач, а завершено 15, різниця становить 5 задач. Лише якщо інших вибуттів, повторних записів і коригувань немає, незавершений залишок міг зрости на 5.

Черга або довгий час очікування є сигналом для дослідження, а не доказом причини затримки. Робота могла чекати даних від клієнта, рішення іншого відділу або доступності спеціаліста. Попросіть команду пояснити винятки й перевірте якість вихідних даних.

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

Умовний приклад: черга з поверненнями та скасуванням

Майстерня аналізує етап підготовки пропозицій. На початку тижня в черзі було 12 запитів. За тиждень надійшло 20 нових, ще 2 раніше завершені запити повернулися на уточнення. Команда завершила 15 запитів, а 1 клієнт скасував запит до завершення. Кожен запит пораховано один раз у відповідній події, інших змін залишку немає.

Залишок на кінець тижня: 12 + 20 + 2 − 15 − 1 = 18 запитів. Він зріс на 6, хоча різниця між новими надходженнями та завершеннями становить 5. Якщо повернення і скасування не врахувати окремо, перевірити фактичну зміну черги не вийде.

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

Якщо з’ясовується, що на підготовку впливає час команди, зіставте завантаження з доступним часом за посібником про потужність відділу продажів. Сам розмір черги ще не показує, скільки додаткових працівників потрібно.

Крок 5. Погодьте невелику зміну і перевірте результат

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

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

Для регулярних командних оглядів використовуйте управлінські картки або шаблони для управління. Дані між ними й картою автоматично не переносяться: потрібну інформацію команда переносить самостійно.

Поширені помилки

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

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

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

Не оновлювати карту. Коли змінюються ролі, інструменти або порядок погодження, перегляньте опис разом із командою. Застарілий документ може створити більше плутанини, ніж допомоги.

Питання та відповіді

Чи потрібен окремий фахівець для першої карти?

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

Чи визначає інструмент причину затримки?

Ні. Він показує сигнали на підставі введених показників. Причину потрібно перевіряти з командою та за додатковими даними.

Чи зберігаються введені дані на сайті?

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

Оберіть одну повторювану задачу, опишіть її в конструкторі бізнес-процесу і перевірте кожну передачу разом із тими, хто виконує роботу.