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

Я спробую продемонструвати цей процес на деяких прикладах з реальної практики.

1) Web портал для приймання замовлень клієнтів. Це наочний і найпростіший приклад цифрової трансформації, який зрозумілий всім. Тобто об’єктом трансформації тут є група менеджерів які спілкуються з клієнтом телефоном і вводять в систему замовлення прямо під час цієї розмови. Суть трансформації – замість того щоби диктувати замовлення менеджеру телефоном клієнт набирає його власноруч в своєму особистому web-кабінеті і воно автоматично створюється в інформаційній базі ERP системи. Ще 3 роки назад мені особисто доводилось переконувати клієнтів-власників дистриб'юторських складів, що така трансформація можлива і доцільна. Залізним аргументом проти були побоювання, щодо зменшення обсягів продажу. Мовляв, людина під час спілкування може щось додатково «порекомендувати» клієнту. Реальна статистика така (конкретний кейс):
До початку цифрової трансформації:
12 менеджерів створювали 3700 рядків замовлень на день

Через 2 роки:
8 менеджерів + інтернет створюють 5800 рядків замовлень на день.
Загальна кількість клієнтів майже не змінилася, середня вартість одного рядка теж, через інтернет приходить 52% замовлень.
До речі, тут видно ще один вимір цифрової трансформації – зовнішній. Одним із суттєвих факторів стримування є неготовність клієнтів. Виявилось, що потрібна кропітка «роз’яснювальна робота», і я, все одно, вважаю, що цей показник (доля замовлень отриманих через інтернет) в будь-якому разі, в найближчі 5 років не сягне більше 80%. Тож менеджери все одно будуть.
  

2) Календар платежів. Збільшення загальної кількості замовлень неминуче призводить до зростання простроченої дебіторської заборгованості - клієнтам дають товар з відтермінуванням оплати на 7 днів, але це ж Україна, хто в нас рахує ті дні ? Виявляється, що треба збільшувати кількість працівників які спілкуються з клієнтами – нагадують про необхідність оплати. Ніякі сервіси SMS розсилок цьому ради не дадуть – марні сподівання. Кожний досвідчений автоматизатор має в своїх архівах з десяток варіантів звітів по аналізу дебіторки - цей «потужний» інструмент фахівця відповідального за взаєморозрахунки.
  

Рішення прийшло коли ми подивилися на проблему під іншим кутом зору, а саме: як повинен виглядати цей звіт щоби його читав «робот» ? Тепер мене навіть дивує навіщо контрольний механізм в типовому варіанті побудований круг кредитного ліміту і суми боргу, коли принциповим є тільки наявність простроченої заборгованості (тобто булєва функція – «так», чи «ні»). В нормальному фінансовому потоку, при незмінній кількості і якості клієнтів вартісний обсяг продажів кожного окремого клієнта є по суті константою (точніше «кардіограмою» сталої форми). Тут не тільки нема що контролювати, а й взагалі цей параметр мало що дає для потреби планування фінансового потоку. Бо без чіткої процедури контролю дотримання зобов’язань по термінам платежів достовірність цього плану невелика. Але це розуміння прийшло трохи згодом. 

Тож ми зробили регістр с сумами платежів, датами, по контрагентах, та декілька «роботів» які заповнювали цей регістр на підставі графиків платежів по кожному замовленню, враховуввали надходження. І нарешті зробили «робота» який читав цей регістр і блокував можливість створювати нові замовлення при наявності простроченої заборгованості (регістр актуалізовувався неоперативно, за розкладом, спочатку на ранок дня, потім 3 рази протягом дня, потім перестроїли на кожну годину). 

В політичному плані це було складне рішення, блокувати замовлення на 1000 гривень внаслідок простроченої заборгованості в 10 гривень здавалося геть безглуздим. Але результати перевищили всі сподівання – загальне зменшення дебіторки (тобто вивільнення обігових коштів) в абсолютному вимірі перевищило «інвестиції» в цифрову трансформацію на цій дільниці в 50 разів протягом перших 4-х тижнів. Додаткових бухгалтерів, зрозуміло, не знадобилося. Ба більше, виявилось, що наші «роботи» навіть частково виконують функцію фінансового директора і дають дуже достовірний прогноз надходжень (і виплат) на найближчі 4 тижня. Но то таке, випадковий збіг обставин.