Чому цифрова трансформація зазнає невдачі: це проблема операційного розуміння, а не технологічна

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

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

У квітні 2018 року TSB мігрувала 1,3 мільярда записів клієнтів з застарілої платформи Lloyds на нову систему, створену її іспанським материнським банком Sabadell. За 48 годин 1,9 мільйона клієнтів були заблоковані від доступу до своїх рахунків.

БільшеІсторій

                                    Навігація волатильністю: аргументи на користь нігерійських акцій у другому кварталі 2026 року

11 травня 2026

                                    Чому ШІ дорожчий за людських працівників і шкідливий для навколишнього середовища

11 травня 2026

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

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

Що таке операційний інтелект?

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

Рівень даних

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

З чистого журналу подій інструменти процесного аналізу, такі як Celonis, UiPath Process Mining і SAP Signavio, відновлюють фактичні шляхи процесів, показують, де концентруються затримки, і порівнюють реальну поведінку з задокументованими моделями. Різниця між тим, що показує карта процесу, і тим, що показує журнал подій, рідко є тривіальною. Затримки, які виглядають автоматичними на діаграмі, можуть включати три ланцюги електронної пошти і таблицю, яку ніхто офіційно не санкціонував. Коли DHL застосувала процесний аналіз до своїх операцій митного оформлення, вона не виявила вузьких місць, яких очікували її менеджери. Більшість затримок не були у часі обробки. Вони були у латентності прийняття рішення, у різниці між моментом, коли справа доходить до точки прийняття рішення, і фактичним ухваленням рішення.

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

Операційний інтелект і готовність до ШІ

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

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

Послідовність перед вибором

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

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