Помилки в управлінні поставили ERP-проект під загрозу зриву

Існують три фактори, які можуть призвести до провалу ІТ-проекту. Це недотримання термінів впровадження, недотримання бюджету проекту і неякісні послуги компанії-виконавця. У проекті зі створення єдиної системи автоматизації Департаменту транспорту Великобританії, як наголошується, мали місце всі ці причини.



У квітні 2005 року в Департаменті транспорту Великобританії приступили до реалізації масштабного проекту зі створення Об'єднаного Центру Обслуговування, який повинен був об'єднати служби, відповідальні за управління фінансами, кадрами та розрахунком заробітної плати в різних підрозділах і агентствах, а також у центральному офісі департаменту.

Основою створюваної системи повинна була стати платформа SAP, виконавцем – компанія IBM, а консалтингові послуги надавала компанія Deloitte.

За попередніми розрахунками, нова система повинна була забезпечити економію в 112 млн. фунтів. З урахуванням вартості впровадження, яка оцінювалася в 55 млн. доларів, підсумкова економія повинна була скласти порядку 57 млн. фунтів. Перші підрозділи департаменту повинні були почати роботу з системою в квітні 2006 року, а завершення проекту було намічено на квітень 2008 року.

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

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

У січні 2006 року, з метою скорочення коштів на реалізацію проекту, керівництво почало спробу перевести частину робіт на аутсорсинг (в Індії), що повинно було скоротити відповідні видатки дві третини. Однак на ділі були виявлені труднощі із забезпеченням безпечного доступу індійських фахівців. Укупі із стислими термінами, відведеними на реалізацію проекту, це призвело до того, що заощадити вдалося лише незначну суму в 44 тис. фунтів.

Для оцінки якості впровадження департамент виробив 18 ключових показників ефективності. Однак поки зібрані дані лише по чотирьох із них. Аналіз цих KPI свідчить про нестабільну роботу системи (Значення їх з місяця в місяць сильно розрізняються, причому як у велику, так і в меншу сторону). Почасти це пояснюється нестабільною (циклової) навантаженням на служби департаменту (наприклад, в січні навантаження істотно зростають, і система перестає справлятися з ними в повному обсязі, тоді як в більш спокійні місяці ефективність роботи системи збільшується). Тим не менш, поки ці KPI нижче аналогічних показників роботи окремих підрозділів департаменту у своїх колишніх системах.

Виниклі труднощі призвели до того, що до квітня 2008 року вартість впровадження системи оцінювалася вже в 121 млн. фунтів, а економія від неї – в 40 млн. фунтів. Таким чином, сукупні збитки оцінювалися в 81 млн. фунтів. У тому числі послуги консалтингової компанії Deloitte обійшлися департаменту в 4,6 млн. фунтів.

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

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






























Поточна ситуація

Рекомендації

Плани впровадження (за термінами і витратами) були надто оптимістичні і не враховували ризиків і труднощів Плани впровадження повинні бути детально опрацьовані, навіть якщо це потребуватиме додаткових початкових витрат
Навіть при виявленні додаткових складнощів і факторів ризику, розклад і бюджет проекту не були переглянуті При появі додаткової інформації терміни і бюджет проекту повинні коректуватися
Для прискорення проекту тендер з вибору виконавця не проводився. Був продовжений контракт з фірмою, яка вже надавала департаменту послуги з супроводу Проведення повноцінного тендеру дозволить ретельніше опрацювати вимоги до системи і до якості послуг компанії-виконавця
У департаменті не було фахівців, що володіють достатніми навичками в області управління проектами Керівники при необхідності повинні пройти курс навчання управління проектами
Отримана система поки не відповідає поставленим цілям, і не зрозуміло, коли вона вийде на заданий рівень ефективності Необхідно розробляти показники для вимірювання ефективності роботи системи і помісячно відстежувати і аналізувати їх значення, щоб своєчасно виявити слабкі ділянки та вжити заходів щодо їх оптимізації
Користувачі системи не довіряють їй, оскільки стикаються з великою кількістю проблем в рамках її експлуатації Необхідно навчати користувачів можливостей нової системи, а також прислухатися до їх зауважень і контролювати виправлення виявлених помилок
Ефективність роботи системи не може порівнюватися з аналогічними показниками в інших організаціях, через специфіку розв'язуваних завдань Необхідно і корисно порівнювати ефективність впровадженої системи з аналогічними рішеннями на підприємствах своїй галузі
Незважаючи на незадовільні результати, ніхто з керівників проекту не був притягнутий до відповідальності (деякі були позбавлені премії) Перед початком проекту слід розробити чітку систему заохочень і покарань, прив'язану до конкретних результатів впровадження. Покарання можуть бути досить жорсткими, аж до усунення від виконання своїх обов'язків і навіть звільнення

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*