Чому ІТ-системи не працюють так, як ми мріємо

При кожному новому впровадженні ІТ-системи (далі по тексту – «система»), бізнес може висувати дуже різні вимоги, побажання до роботи і процесів, які повинна підтримувати ця система.
І тут не завжди враховуються наступні фактори:

1. Які існуючі можливості обраної системи?

Тут ситуація часто має декілька сторін:● бізнес не розуміє альтернативи або просто не хоче враховувати існуючі можливості, бо вони якось відрізняються від поточної реальності;● консультанти, які займаються впровадженням, не знають про всі можливості системи та/або не можуть донести бізнесу, що стандартний функціонал дозволяє працювати по-іншому.Як результат – відмова від конкретної системи, або значні доробки, що потребують додаткових ресурсів.

2. Заради якої мети впроваджується система?

Зазвичай, відповідь від бізнесу – ведення обліку, формування бізнес-процесів, автоматизація, звітність для аналізу поточної ситуації, планування і прогнозування.І саме тут на перший план виходять приховані «пастки»:● для цілей обліку необхідно вчасно і дискретно вести всі документи й операції, а не «в кінці декади агреговано зробимо запис»;● для формування бізнес-процесів потрібно їх дотримуватися, як не дивно 😉;● для автоматизації потрібні вже усталені процеси, повнота та актуальність необхідних даних, інакше постійних помилок не уникнути;● якісна звітність ставить достатньо високі вимоги до процесів і якості даних, а без виконання попередніх пунктів це малоймовірно;● будь-яке планування повинно ґрунтуватися на чомусь більш-менш реальному – попередніх замовленнях, контрактах, прогнозних даних;● прогнозування, у свою чергу, може спиратися на накопичені якісні дані минулих періодів та тренди на їх основі, враховуючи змінні чинники. 

Тут, до речі, часто випливає нерозуміння різниці між планом і прогнозом. Через специфіку звичної термінології все називають планом. 
Наприклад: ● план для SAP TM – це коли клієнт замовляє на наступний рік перевезення 10 тис. тонн вантажу;● прогноз для SAP TM – це коли компанія-перевізник, на основі перевезень минулого року, робить припущення, що і цього року вони будуть перевозити 10 тис. тонн.
Для першого є конкретні підстави, а для другого – тільки очікування. І саме тому для планування SAP TM підходить, а для прогнозування необхідне або інше рішення, або значні доробки поточного функціоналу.

3. Чи відповідають можливості системи очікуванням і побажанням бізнесу? І чи дійсно їм це треба?

Тут зустрічається дихотомія між побажаннями бізнесу й функціоналом системи. Наприклад, типовою при впровадженні SAP TM є ситуація, коли бізнес хоче бачити такий документ як Наряд, що повинен включати в себе декілька Рейсів. Але це прояв аналогової, доцифрової, паперової логіки. Раніше так було легше вести облік перевезень на паперових носіях і тому використовувались згадані методи групування. Для цифрової системи такий підхід не несе ніяких плюсів, тому усталеною практикою є: одне перевезення – один документ. Бо система на загубить папірець, якщо їх буде багато, не заплутається у безлічі документів, не втомиться від створення додаткового документу.

4. Наскільки заявлені вимоги та реальна потреба бізнесу співпадають?

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

5. Чи готовий бізнес додатково інвестувати у розробку функціоналу, що відсутній у стандартному рішені?

Усі хочуть, щоб рішення «із коробки» закривало всі потреби. Зазвичай відбувається наступне: під час вибору системи бізнес стверджує, що має стандартні процеси перевезень, проте вже на етапі впровадження SAP TM виявляються «певні особливості».
Про це, бажано, за можливості, думати наперед. Або розробити пріоритетність – що потрібно першопочатково, а що можна доробити потім. Як показує практика, частина «дуже необхідного» з часом так і не знадобиться. 😊

Різні очікування від системи

До та під час впровадження будь-якої системи можуть існувати різні очікування результату. І, в залежності від посади людини, ці очікування можуть серйозно відрізнятися. Більше того – навіть бути протилежними.
Погляньмо детальніше.
Для власників компанії та менеджерів С-рівня метою впровадження може бути (на прикладі SAP Transportation Management):
-підвищення капіталізації компанії (через факт впровадження відомої перевіреної ІТ-системи);
-систематизація бізнес-процесів відповідно до Best Practices;
-формування сталих бізнес-процесів, системи роботи, яка менше залежить від особливостей співробітників, їх компетенції, фактору людських помилок;
-прозорі та зрозумілі, наскрізні процеси;
-чітка й повна аналітика, яка створюється без «ручного» формування звітності, без суб’єктивного фактору бізнес-аналітика.

Для керівників середньої ланки і рядових співробітників цілі можуть бути іншими:

І, найцікавіший момент, – ці побажання можуть бути несумісними між собою, особливо, коли мова про цілі С-рівня і рядових користувачів.

Різні способи використання системи

Будь-яку ІТ-систему можна використовувати декількома способами, в залежності від потреб і розуміння:

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

Пошук більш правильного способу використання

Будь-яку систему, як і мікроскоп, можна використовувати різними способами: за призначенням і як молоток. І другий спосіб не завжди неправильний. Хоча, об’єктивно, купувати щось складне і дороге заради цього – дивне рішення.Тому при виборі системи для впровадження і визначення способу її використання важливо враховувати контекст. Невеликій компанії з трьома простими операціями на день не потрібна складна система. Для трохи більшої кількості операцій можна використовувати повноцінний облік і розрахунок результатів роботи. Але складна і дорога автоматизація та модуль для прогнозування і планування будуть, скоріше за все, недоречними.Винятком може бути ситуація, коли компанія хоче послідовно впроваджувати функціонал системи, рухаючись від простого до складного. І приклад SAP TM тут може бути достатньо показовим: спочатку впровадити тільки Order Management для обліку операцій, потім – трекінг перевезень, далі – автоматичне планування оптимізатором, потім – використання BNL (Business Network for Logistics) для взаємодії з перевізниками. І, як логічне продовження, впровадити функціонал управління суперечками.І лише після всього цього можна подумати про спробу оптимізувати транспортну мережу на історичних даних, чи спробувати зробити прогноз на майбутні перевезення. Але це вже буде «мікроскоп-молоток».

Еволюція у використанні систем

При ідеальному рівномірному розвитку компанії на шляху якісного та кількісного збільшення, бізнес може пройти всі еволюційні етапи використання інформаційних систем – від ведення записів операцій у Excel до автоматичного планування перевезень у SAP TM. Це обумовлюється збільшенням компанії, геометричним ростом кількості операцій, які не можливо контролювати адекватною кількістю персоналу. І тоді компанія стає перед вибором: зупинити ріст або використати мультиплікатор у вигляді ІТ-системи для росту ефективності. Спочатку – для створення контролю виконання операцій, потім – для зменшення ручної роботи спеціалістів й отримання нових аналітичних даних для прийняття управлінських рішень. Стеля розвитку, теоретично, не має обмежень, але кожне наступне покращення, зазвичай, коштує більше, а користі приносить менше. Тому гранична користь помітно зменшується. А «біль» при переході на нову систему – збільшується. Але, нажаль, без цього ніяк. Бо не буває системних досягнень, які здобуваються легко.

Висновки

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