Pain Point Map (Карту побудови проблемних точок) не обов’язково починати з великого проекту. Для першої версії достатньо короткої робочої сесії на 60 хвилин.
Її мета – не вирішити всю проблему одразу. Мета – узгодити, що саме болить, де це виникає, який бізнес-вплив має проблема, що вже відомо, що є гіпотезою і який наступний крок варто зробити.
Якщо команда не встигає навіть сформулювати одну больову точку за 60 хвилин, це сигнал, що тема занадто широка і її треба звузити.
Хто має визначати проблемні точки в лінцюгах постачань
Не потрібен великий комітет. Для першої сесії достатньо 3-5 людей:
- власник процесу;
- людина, яка щодня працює з проблемою;
- представник IT / data team;
- за потреби – фінанси або клієнтський сервіс;
- фасилітатор, який тримає структуру розмови.
Головне – щоб у кімнаті були три перспективи:
- бізнес-вплив;
- реальний процес;
- дані або системи.
Якщо однієї з цих перспектив немає, карта буде перекошеною.
Роль фасилітатора – тримати фокус на одній больовій точці, відділяти факти від гіпотез, не дозволяти команді перескочити до рішення занадто рано і фіксувати незаповнені поля як “невідомо / треба перевірити”.
Бажано, щоб фасилітатор був нейтральним до конкретного рішення. Його роль – тримати процес, а не просувати AI, постачальника або версію однієї функції.
Що підготувати до сесії виявлення проблемних точок в ланцюгах постачань
Не треба готувати ідеальну аналітику. Достатньо принести:
- короткий опис больової точки;
- 2-3 приклади реальних випадків;
- приблизний бізнес-вплив;
- опис поточного процесу “як є”;
- список доступних джерел даних;
- відомі обмеження або сумніви щодо даних;
- гіпотези причини, якщо вони вже є.
Якщо частини інформації немає, це не причина скасовувати сесію. Просто треба позначити це як “невідомо” або “треба перевірити”.
Як розподілити 60 хвилин взаємодії
0-10 хвилин: зафіксувати одну больову точку
Почніть із формулювання проблеми. Не “покращити логістику”, а: “Термінові перевезення по критичних товарах повторюються майже щотижня.”
Не “покращити запаси”, а: “Дефіцит по критичних позиціях категорії А регулярно знижує рівень сервісу для ключових клієнтів.”
На цьому етапі важливо не дозволити розмові розповзтися на всі проблеми одразу.
Одна сесія – одна больова точка.
10-20 хвилин: описати бізнес-вплив
Далі команда має відповісти: Чому це важливо для бізнесу? Це можуть бути гроші, сервіс, час, ризик, клієнтський досвід або перевантаження команди. Якщо точних цифр немає, можна почати з якісного опису. Але його треба позначити як якісний, а не видавати за доведений фінансовий розрахунок.
20-35 хвилин: описати процес “як є”
Це ключова частина сесії. Потрібно описати, як проблема проявляється в реальній роботі:
- хто бачить її першим;
- де бере інформацію;
- які системи, Excel-файли або листування використовує;
- яке рішення приймає;
- що робиться вручну;
- де виникає затримка;
- які обхідні шляхи використовуються.
Тут важливо не описувати “правильний” процес із регламенту. Потрібно описати фактичний процес.
35-45 хвилин: відокремити факти від гіпотез
Після опису процесу команда має розділити:
- що ми знаємо;
- що ми припускаємо;
- чого не знаємо.
Наприклад:
Факт: За останні 8 тижнів було 14 термінових перевезень.
Гіпотеза: Причина може бути в пізньому виявленні ризику дефіциту або затримках постачальника.
Невідомо : Чи всі причини термінових перевезень зафіксовані в системі.
Цей крок захищає команду від помилки, коли припущення починають сприймати як доведений факт. Сильна думка керівника або експерта не замінює факт. Якщо версія причини не підтверджена, її треба записати як гіпотезу.
45-55 хвилин: обрати наступний крок
Після цього команда має вибрати один із варіантів:
- Foundation first – спочатку виправити основу;
- Proceed to AI – перейти до AI-дослідження;
- Narrow scope – звузити проблему;
- Run in shadow mode – перевірити AI в тіньовому режимі;
- Solve without AI – вирішити без AI.
На цьому етапі не потрібно погоджувати повний проект. Потрібно лише вирішити, який наступний крок є найбільш розумним.
Якщо команда не погоджується щодо наступного кроку, не треба витрачати решту сесії на суперечку. Зафіксуйте розбіжність і визначте, яку гіпотезу, дані або факт треба перевірити першими.
55-60 хвилин: зафіксувати відповідального і результат
Останні 5 хвилин потрібні для дисципліни. Команда має записати:
- який варіант обрано;
- хто відповідальний за наступний крок;
- що треба перевірити;
- до якого строку;
- який результат має бути після перевірки.
Якщо команда не погодилась щодо наступного кроку, це теж треба зафіксувати.
Наприклад:
“Бізнес вважає, що можна переходити до AI-дослідження. IT / data team вважає, що спочатку треба перевірити якість статусів поставок. Наступний крок – протягом 2 тижнів перевірити повноту статусів по критичних товарах.”
Це краще, ніж завершити сесію загальною фразою “треба ще подумати”.
Що не треба робити на Pain Point Map сесії
На 60-хвилинній Pain Point Map сесії не треба:
- вибирати модель;
- обирати постачальника рішення;
- погоджувати бюджет;
- запускати великий проект;
- обговорювати всі проблеми supply chain одразу;
- доводити, що AI точно потрібен;
- приховувати слабкі місця даних або процесу.
Це не сесія продажу AI-рішення. Це сесія узгодження проблеми.
Який результат має бути отримано
Після сесії у команди має залишитися:
- одна заповнена або майже заповнена Pain Point Map;
- список фактів;
- список гіпотез;
- список невідомого;
- обраний наступний крок;
- відповідальний;
- строк перевірки;
- розуміння, чи проблема рухається до AI, до підготовки основи, до звуження або до простого процесного рішення.
Якщо потрібна наступна зустріч, вона має мати конкретну мету: перевірити дані, уточнити гіпотезу або звузити проблему.
Незаповнені поля не є провалом сесії. Провал – це зробити вигляд, що відповідь є, коли її немає.
Якщо після 60 хвилин команда не отримала готовий AI-проект – це нормально.
Мета була іншою: зробити проблему достатньо ясною, щоб не стартувати неправильно.
Практичний артефакт: Supply Chain Pain Point Map Template
Нижче – робоча форма карти, яку можна використовувати під час 60-хвилинної сесії або після неї. Правило просте:
одна карта = одна больова точка = один узгоджений наступний крок.
Цю форму не потрібно заповнювати ідеально з першого разу. Її задача – зробити проблему видимою, відділити факти від гіпотез і зафіксувати, що команда робить далі.
Спочатку карта проблеми потім карта рішення
AI-проект у ланцюгу постачань не має починатися з демонстрації рішення, вибору постачальника, моделі або інструменту. Він має починатися з узгодженої карти проблеми.
Якщо команда не домовилась, що саме болить, де це виникає, який бізнес-вплив має проблема, як процес працює зараз і що треба перевірити першим, будь-яке AI-рішення стартує на слабкій основі.
Pain Point Map не гальмує AI. Вона захищає команду від неправильного старту: коли бізнес очікує результат, операційна команда говорить про щоденний біль, IT / data team бачить обмеження даних, а постачальник рішення вже пропонує готовий інструмент.
Іноді результатом карти буде AI-дослідження. Іноді – тіньовий режим. Іноді – перевірка даних, звуження проблеми або просте процесне рішення без AI. Це не відмова від AI, а ознака зрілого управління впровадженням.
Завдання карти – не довести, що AI потрібен. Її завдання – допомогти команді чесно вибрати наступний крок.
Якщо після заповнення карти команда не може назвати конкретну проблему, користувача результату, доступні дані, обмеження і наступний крок – до AI ще рано.
Тоді практична дія проста: взяти одну больову точку, провести 60-хвилинну сесію і заповнити першу версію карти.
Бо поганий AI-проект часто починається не з поганої моделі, а з погано узгодженої проблеми. Спочатку карта проблеми. Потім карта рішення.
Автор: Ярослав Степченков — Kaizen Practitioner, Lean Six Sigma Green Belt, IPMA (D).
Дізнавайтесь З чого почати та як запустити коректний АІ проект в логістиці.
Звертайтесь до автора за консультацією: Ярослав Степченков.
Доєднуйтеся до спільноти професіоналів