Оригінальна версія статті німецькою мовою
Lidl, Deutsche Post, Deutsche Bank і Otto: список невдалих впроваджень SAP у великих корпораціях Німеччини довгий. Керівник Liqui-Moly Ернст Прост підсумував своє розчарування з приводу невдалого впровадження Microsoft AX в його компанії в дуже протверезний спосіб: "Це гірше, ніж Brexit, Трамп і торговельна війна", – розлютився він у Frankfurter Allgemeine 10 липня 2019 року. Отже, не має значення, яке програмне забезпечення ERP використовується – не воно є головним винуватцем проблем. Радше будь-яка з наведених нижче причин може призвести до невдалого впровадження системи планування ресурсів підприємства.
1. Кадри
Немає ключових користувачів (Key User) та експертів із процесів, або ж їх треба навчати і вводити в нову роль з усіма її складнощами. Нерідко доводиться роз'яснювати, хто такі ключові користувачі та експерти процесу і які їхні завдання. Це займає певний час, який в ідеалі слід інвестувати до початку проєкту, а не під час нього. Тому що потім може бути вже запізно. Якщо проєкт вже розпочався, то часу на навчання учасників проєкту не залишається, бо на той час ці працівники вже повинні натиснути на газ.
Ще одним важливим фактором у цьому контексті є абсолютна прозорість для керівників різних бізнес-підрозділів. Вони повинні знати, наскільки їхні співробітники, які перейшли на ERP-проєкт, все ще доступні. Чи вони на 100 відсотків задіяні в проєкті, чи їхня активність в проєкті змінюється.
Схема може бути, наприклад, такою: на початку 80% для фази розробки концепції/синього друку, потім 50 відсотків на етапі впровадження і потім 100 відсотків на етапі тестування і запуску в експлуатацію. Цей момент має бути дуже чітким, тому що часто виникає напруга або нерозуміння щодо часу, який витрачається між відділами та проєктом планування ресурсів підприємства.
2. Бракує внутрішніх проєктних ноу-хау
Хоча теоретичні інструменти для методології управління проєктами сьогодні здебільшого доступні, бракує тісної співпраці з (вищим) керівництвом. Часто бракує досвіду, а разом з ним і сміливості та відкритості визнавати помилки та повідомляти про проблеми на ранніх стадіях. Існують різні причини відбілювання ситуації; цілком зрозумілим, але навряд чи доцільним мотивом є кар'єрні можливості, що відкриваються, особливо для менеджерів проєктів. Хто захоче стати непопулярним у такій ситуації? Тим не менш, тут також має діяти наступне: чесність є найкращою політикою. Тут коуч може бути корисним для керівника проєкту.
3. Користувачі вимагають кастомізації замість того, щоб дотримуватися стандарту
Це класична причина затримок проєктів і подальшого ускладнення та збільшення вартості. Що можна зробити, якщо користувач знає лише свій попередній спосіб роботи і хоче, щоб звичні процеси працювали точно так само?
Класичний аргумент тут полягає в тому, що цей процес, зрештою, є особливістю компанії (без якої вона ніколи б не стала такою великою) і що зміна способу роботи несе в собі ризик того, що подальший рух зупиниться або загальмується. Якщо хай там що дотримуватися стандарту і не реагувати на побажання користувачів, виникає опір, який може призвести до того, що впровадження ERP буде навмисно заблоковано. Отже, тут потрібна велика чутливість, якість керівництва та управління змінами. Керівники користувачів повинні чітко усвідомлювати свою відповідальність, зайняти відповідну позицію і чітко визначити, як діяти далі, а також пояснити, що це означає для користувача в кінцевому підсумку.
4. Планування етапу тестування є недостатнім
Користувачам бракує часу на достатньо глибоке ознайомлення з системою або вони взагалі не в змозі опрацювати тестові кейси. Каталоги тестових кейсів часто не існують або про основні функції забули. Як наслідок, помилки або не розпізнаються, або (якщо розпізнаються) способи реагування на них не розглядаються на етапі тестування. Приймальні тести часто не проводять, тому що їх відкладають на "потім" з огляду на час. Як наслідок, важливих функцій немає в реальній експлуатації.
Ці нібито дрібні речі, які потім залишаються поза увагою, часто мають величезний вплив на загальний процес. Може статися так, що через прогалини в загальному процесі поставки товарів будуть неякісними. Щоб уникнути таких неприємностей, важливо стежити за дрібними деталями, незважаючи на складність проєкту планування ресурсів підприємства.
5. Тренінги
Навчання – ідеальна сцена для драм усіх видів. Це починається з витрат, які можуть зрости в найкоротші терміни, якщо є велика потреба в навчанні. Планування та координація навчальних курсів для кількох сотень користувачів потребує часу, як і саме навчання. Де знайти на це час? А що, якщо запланованих навчальних курсів недостатньо для ефективної роботи нової ERP-системи? Про це часто не думають заздалегідь.
Стає зрозуміло, наскільки важливим є завчасне і добре продумане планування – особливо для того, щоб менеджери розуміли, що їхні працівники будуть недоступні протягом періоду навчання. Тому, якщо ви заздалегідь простежите за часом і координацією тренінгів та навчання, це не позбавить вас сну.
6. Основні дані
Основні дані (master data) не рідко є трагедією. Коли справа доходить до якості основних даних, очікування часто доводиться тривожно зменшувати задовго до впровадження ERP-системи. У найгіршому випадку основних даних нема взагалі, або ж вони живуть своїм сумним життям у програмах Office чи у старій системі планування ресурсів підприємства. Рудиментарно підтримувані, застарілі основні дані приховують у собі ризик дублювання, різних версій і спричиняють подальший хаос. Значну частину основних даних, необхідних для нової ERP, треба створити та налаштувати наново, оскільки їх ще навіть не існує.
Якщо немає або не було особи, відповідальної за основні дані, ключовим користувачам доводиться дуже інтенсивно займатися темою основних даних і, таким чином, у них залишається менше часу для виконання своїх фактичних завдань в рамках проєкту ERP і своєї звичайної сфери відповідальності. Отже, дуже важливо, щоб організація основних даних була запущена в роботу дуже рано, бажано до початку проєкту. Відповідні ролі та обов'язки повинні бути чітко визначені. Оскільки ця робота не дуже популярна, не завжди легко знайти хороших працівників для неї. Однак вони мають вирішальне значення для успіху проєкту.
7. Стратегія впровадження ERP
Стратегія впровадження недостатньо проаналізована, а окремі сценарії недостатньо ретельно вивчені на предмет можливих ризиків. Часто це призводить до впровадження за принципом «великого вибуху» (запускаємо всі процеси відразу – прим. перекл.), яке, в найгіршому випадку, нещадно калічить компанію. Іноді доцільніше запускати нову систему частинами – короткі спринти та швидке знайомство з її підобластями. Звичайно, тут підстерігають проблеми складнішої архітектури, а також потреби створення інтерфейсів до застарілих систем, але воно може бути того варте. Зрештою, нерішучі дискусії та непродумані кроки часто призводять до того, що при ближчому розгляді стратегія впровадження не варта своєї назви.
8. Пріоритетність
Пріоритети змінюються. проєкт ERP може швидко сповзти до пріоритету 2-го або 3-го рівня, якщо, наприклад, з'являється новий великий клієнт або постачальник, постачальники або важливі клієнти відмовляються від співпраці або компанія розширюється через придбання іншої компанії. Така подія миттєво відволікає від проєкту, і впровадження ERP потрапляє в «довгу шухляду» як для топ-менеджменту, так і для ключових користувачів. Це призводить до затримки, яку відмовляються визнавати як факт. проєкт вимагають продовжити «паралельно» — зазвичай це закінчується погано.
Такі затримки спричиняють ще одну проблему: усім учасникам доведеться «повертатися» до проєкту, що, як правило, не додає мотивації. Топ-менеджмент повинен розуміти, що зниження пріоритетності сильно впливає на результати проєкту. Ресурси не можна просто так перекидати на інші завдання. Натомість керівництву, в інтересах компанії, слід виявити мудрість і особливу обережність в цьому питанні.
9. Процес внесення змін
Нерідко впровадження ERP бездумно відносять до "ІТ-проєктів". Це помилка, оскільки проєкт потребує участі всієї організації, адже йдеться про впровадження – частково – абсолютно нових процесів та процедур. У результаті співробітники можуть радикально змінити завдання і ролі. У найгіршому випадку роботи у них не буде зовсім – що тоді? Про ці сценарії треба говорити. Тут задіяні не лише керівництво та тренери (coaching), а й профспілка, яку також слід вчасно підключити до обговорення.
10. Завершення проєкту
Ну, й останній пункт: на жаль, часто не відбувається процес видимого закінчення проєкту – з передачею відповідальності у відділи, підписами топ-менеджменту та узгодженого списку недоробок. Тільки з такого документа стає зрозуміло, що проєкт завершено, у якому стані він перебував на момент передачі в експлуатацію, що ще належить зробити і хто за це відповідає. Ці завдання вже не належать до проєкту, за них відповідають відділи. Керівник та члени проєкту повертаються до своїх відділів – або одержують нові завдання.
Висновок
Ці десять пунктів ще раз дуже чітко показують, що впровадження ERP не є ІТ-проєктом (проєктом лише для підрозділу інформаційних технологій), це завдання для всієї організації. Якщо такий проєкт провалюється, то винна не ERP-система, а «пастки», згадані у цих десяти пунктах.
Сподіваюся, що ви візьмете ці десять пунктів до уваги перед початком проєкту і таким чином створите міцний фундамент для успішного впровадження ERP. Адже важливо добре та правильно підготуватися, а також мати глобальне бачення такого проєкту. Це надасть сенс проєкту ERP та мотивацію продовжувати його навіть на складних етапах аж до успішного запуску системи в експлуатацію.
Volker Johanning, експерт із тематики ІТ-стратегії, ІТ-організації та лідерства, а також стратегії діджиталізації; стратегічний консультант та автор книг "IT-Strategie" та "Car-IT"
