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

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

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

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

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

                                    У обережному захисті Air Peace

9 травня 2026

                                    Виправлення реальної проблеми системи переробки SIM-карт у Нігерії

7 травня 2026

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

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

Що таке операційна розвідка?

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

Рівень даних

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

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

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

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

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

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

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

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

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