Помилки управління поставили 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>

*

*