Существуют три фактора, которые могут привести к провалу ИТ-проекта. Это несоблюдение сроков внедрения, несоблюдение бюджета проекта и некачественные услуги компании-исполнителя. В проекте по созданию единой системы автоматизации Департамента транспорта Великобритании, как отмечается, имели место все эти причины.
В апреле 2005 года в Департаменте транспорта Великобритании приступили к реализации масштабного проекта по созданию Объединенного Центра Обслуживания, который должен был объединить службы, отвечающие за управление финансами, кадрами и расчетом заработной платы в различных подразделениях и агентствах, а также в центральном офисе департамента.
Основой создаваемой системы должна была стать платформа SAP, исполнителем - компания IBM, а консалтинговые услуги оказывала компания Deloitte.
По предварительным расчетам, новая система должна была обеспечить экономию в 112 млн. фунтов. С учетом стоимости внедрения, которая оценивалась в 55 млн. долларов, итоговая экономия должна была составить порядка 57 млн. фунтов. Первые подразделения департамента должны были начать работу с системой в апреле 2006 года, а завершение проекта было намечено на апрель 2008 года.
Как сообщается, уже после первых двух месяцев реализации проекта стало очевидно, что предварительное оценки сроков и затрат были слишком приблизительны и оптимистичны. Однако пересматривать план проекта не стали. Чтобы уложиться в составленное расписание, а также запустить финансовую систему к началу нового финансового года, руководство проекта приняло решение сократить сроки тестирования решения. В результате вместо выделенных ранее двух месяцев тестирование осуществлялось в течение всего двух недель, а нагрузочное тестирование, призванное выявить ограничения по числу пользователей и объему обрабатываемых документов, не проводилось совсем.
Такой подход почти сразу привел к нестабильной работе системы, особенно в периоды обновления и подключения к системе новых подразделений. Все дальнейшие модификации системы также производились на работающей системе, без предварительных испытаний. Кроме того, в процессе объединения в системе всех семи подразделений департамента, ранее работавших независимо друг от друга, выяснилось, что при разработке модели решения не была проработана единая схема взаимодействия бизнес-процессов, которая устроила бы всех пользователей.
В январе 2006 года, в целях сокращения средств на реализацию проекта, руководство предприняло попытку перевести часть работ на аутсорсинг (в Индию), что должно было сократить соответствующие затраты на две трети. Однако на деле были выявлены трудности с обеспечением безопасного доступа индийских специалистов. Вкупе со сжатыми сроками, отведенными на реализацию проекта, это привело к тому, что сэкономить удалось лишь незначительную сумму в 44 тыс. фунтов.
Для оценки качества внедрения департамент выработал 18 ключевых показателей эффективности. Однако пока собраны данные лишь по четырем из них. Анализ этих KPI свидетельствует о нестабильной работе системы (значения их из месяца в месяц сильно различаются, причем как в большую, так и в меньшую сторону). Отчасти это объясняется нестабильной (цикличной) нагрузкой на службы департамента (например, в январе нагрузки существенно возрастают, и система перестает справляться с ними в полном объеме, тогда как в более спокойные месяцы эффективность работы системы увеличивается). Тем не менее, пока эти KPI ниже аналогичных показателей работы отдельных подразделений департамента в своих прежних системах.
Возникшие трудности привели к тому, что к апрелю 2008 года стоимость внедрения системы оценивалась уже в 121 млн. фунтов, а экономия от нее - в 40 млн. фунтов. Таким образом, совокупные убытки оценивались в 81 млн. фунтов. В том числе услуги консалтинговой компании Deloitte обошлись департаменту в 4,6 млн. фунтов.
Текущая оценка, по мнению финансового руководства департамента, не может считаться окончательной и полной, поскольку в ней учтены только те выгоды, которые уже получены и измерены, и не учтены потенциальные выгоды, которые департамент рассчитывает получать до 2015 года. Кроме того, по мере обучения сотрудников департамента и более полного освоения ими возможностей системы эффективность от ее внедрения должна возрастать.
В целом по итогам внедрения были выработаны ключевые рекомендации, которые следует учитывать при проведении аналогичных проектов. По мнению TAdviser, эти рекомендации носят общий характер и будут полезны не только государственным, но и коммерческим организациям при планировании проектов автоматизации.
|
Текущая ситуация |
Рекомендации |
| Планы внедрения (по срокам и затратам) были чересчур оптимистичны и не учитывали рисков и сложностей | Планы внедрения должны быть детально проработаны, даже если это потребует дополнительных первоначальных затрат |
| Даже при выявлении дополнительных сложностей и факторов риска, расписание и бюджет проекта не были пересмотрены | При появлении дополнительной информации сроки и бюджет проекта должны корректироваться |
| Для ускорения проекта тендер по выбору исполнителя не проводился. Был продлен контракт с фирмой, которая уже оказывала департаменту услуги по сопровождению | Проведение полноценного тендера позволит тщательнее проработать требования к системе и к качеству услуг компании-исполнителя |
| В департаменте не было специалистов, обладающих достаточными навыками в области управления проектами | Руководители при необходимости должны пройти курс обучения управления проектами |
| Полученная система пока не отвечает поставленным целям, и не ясно, когда она выйдет на заданный уровень эффективности | Необходимо разрабатывать показатели для измерения эффективности работы системы и помесячно отслеживать и анализировать их значения, чтобы своевременно выявить слабые участки и принять меры по их оптимизации |
| Пользователи системы не доверяют ей, поскольку сталкиваются с большим числом проблем в рамках ее эксплуатации | Необходимо обучать пользователей возможностям новой системы, а также прислушиваться к их замечаниям и контролировать исправление выявляемых ошибок |
| Эффективность работы системы не может сравниваться с аналогичными показателями в других организациях, из-за специфики решаемых задач | Необходимо и полезно сравнивать эффективность внедренной системы с аналогичными решениями на предприятиях своей отрасли |
| Несмотря на неудовлетворительные результаты, никто из руководителей проекта не был привлечен к ответственности (некоторые были лишены премии) | Перед началом проекта следует разработать четкую систему поощрений и наказаний, привязанную к конкретным результатам внедрения. Наказания могут быть достаточно жесткими, вплоть до отстранения от выполнения своих обязанностей и даже увольнения |