Причины неудач внедрения информационных систем

Наличие сдерживающих факторов оказывает существенное влияние на потребность российских предприятий в ИС: большинство из них не желают тратить средства на поиск необходимой информации и не имеют соответствующей статьи расходов на создание информационной системы.

Итак, практика управления проектами рекомендует следующие, в целом очевидные, действия для достижения успеха проекта:

• Процесс внедрения должен контролироваться и поддерживаться руководителем того уровня, на котором предполагается получить значимый результат от внедрения. В различных ситуациях это может быть менеджер среднего звена, заместитель директора или генеральный директор. Важный момент – следует учитывать, что контроль над проектом отнимает значительное время. По этой причине часто такие задачи делегируются второму лицу компании, с привлечением ведущего руководителя только в наиболее ответственные моменты.
• Ключевые пользователи должны быть вовлечены в проект, чтобы их требования были реализованы должным образом.
• Заказчик и разработчик должны активно общаться для достижения общего понимания требований к разрабатываемой системе. Общение должно документироваться, т.к. в противном случае упускаются важные детали, возникают конфликтные ситуации и снижается общая успешность проекта.
• Проблема нестабильности требований может решаться только путем тщательной их проработки. Но во многих случаях избежать изменения требований невозможно, такие ситуации должны решаться оперативным согласованием изменений между заказчиком и разработчиком.

5.Провалы внедрения

1) Waste Management

В марте 2008 года компания Waste Management предъявила иск к SAP. В данном иске компания обвиняла SAP в провале внедрения отраслевого решения SAP Waste and Recycling. Как утверждают представители мусороуборочной компании, Waste Management понесла значительные убытки , так как на “неудачный” проект было потрачено более 100 млн долларов, еще 350 млн долларов компания бы получила, если бы внедрение программного обеспечения SAP было бы успешным.  

В свою очередь компания SAP, в ответ на обвинения Waste Management, утверждала, что клиент не смог своевременно и точно определить потребности своего бизнеса. А также, что клиент не обеспечил участие в проекте компетентных специалистов и руководителей.  

2) Public Health Foundation Enterprises

Согласно поданному  судебному заявлению, калифорнийская организация Public Health Foundation Enterprises, занимающаяся поддержкой и обслуживанием инфраструктуры в некоммерческих, общественных и правительственных организациях, приступила к поиску новой информационной системы в 2006 году. Система должна была заменить существовавшие в компании разрозненные приложения, использовавшиеся для управления финансами, персоналом и другими операциями. Основной целью проекта было объединить все эти процессы в единое информационное пространство.

В процессе поиска компания наняла консалтинговую фирму для постановки учета и разработки бизнес-процессов, удовлетворяющих потребностям организации. В ходе выбора ПО были направлены запросы в компании Lawson,  Microsoft,  SAP и другие.

В конечном итоге  заказчик выбрал компанию Lawson, для которой  автоматизация управления в сфере здравоохранения является одним из ключевых направлений работы, и в августе 2007 года заключил с ней договор более чем на 1,08 млн. долларов. Договор, судя по всему, был заключен несколько поспешно, чтобы воспользоваться предложенными вендором скидками.

Однако с самого начала реализации проекта у Lawson начали возникать проблемы, связанные с  внедрением комплексной ERP-системы  и обслуживанием клиента. Согласно жалобе заказчика, компания Lawson не смогла выделить для проекта необходимые  ресурсы, что сразу же привело к задержкам в его реализации.

Во-первых, как оказалось, установить программное обеспечение Lawson невозможно на имевшемся у клиента  оборудовании. Чтобы приступить к  обучению персонала, как это было оговорено по условиям сделки, заказчику сначала было предложено использовать для доступа к ПО сервера и логин самой Lawson, по цене примерно в 4,5 тыс. долларов в день. Позже Lawson все же отказалась взимать эту плату, и подготовка специалистов началась в октябре 2007 года. Однако этим проблемы не ограничились.

Следующей проблемой  стала недостаточная квалификация консультантов. В заявлении говорится, что консультанты Lawson не могли самостоятельно ответить на вопросы клиента даже о базовых функциях ERP-системы. За правильными ответами консультанты неоднократно обращались в Lawson, что приводило к дальнейшему затягиванию ERP-проекта.

В ноябре 2007 года заказчик начал обучение сотрудников своей  кадровой службы работе в новой системе, однако вновь возникла задержка, поскольку  консультант Lawson не смог правильно сконфигурировать ERP-систему для государственных учреждений. В дальнейшем для HR-департамента клиента были выделены три других консультанта. Согласно иску, Lawson не могла обеспечить постоянного консультанта до января 2008 года.

Согласно договору, Lawson также должна была продемонстрировать полный цикл выполнения всех операций в системе в ходе тестовой эксплуатации. Однако из-за постоянно возникавших технических проблем, тестирование системы так и не было завершено.

В результате заказчик потратил на реализацию проекта 1 млн. долларов, однако смог получить лишь разрозненные блоки программы, а не за комплексную ERP-систему, как было обещано. В настоящее время клиент продолжает эксплуатировать предыдущую информационную систему. 

По мнению Фрэнка Скаво (Frank Scavo), управляющего партнера консалтинговой компании Strativa (Калифорния), было бы несправедливо обвинять в данной ситуации только Lawson. Как можно судить по предоставленной заказчиком информации, организация поторопилась заключить сделку, чтобы не упустить обещанную скидку, и в дальнейшем требовала немедленно приступить к выполнению проекта. Возможно, это и привело к конфликту и к нехватке ресурсов – опытные консультанты Lawson были в тот момент заняты. По утверждению г-на Скаво, о работе с квалифицированными консультантами обычно договариваются за недели и даже за месяцы вперед. Кроме того, клиенты должны и сами проявлять должную осмотрительность, причем не только в отношении выбора разработчиков программного обеспечения, но и при заключении контракта с консалтинговыми компаниями, которые будут заниматься внедрением. Необходимо лично познакомиться с теми консультантами, которые будут выделены на проект, убедиться в их достаточной квалификации и указать в договоре, что именно этим сотрудникам заказчик готов доверить реализацию своего проекта 

3) Siemens AG , Германия

Мегапроект по внедрению системы управления кадрами и расчета зарплаты PeopleSoft от HRMS в германском концерне Siemens AG, который обошелся компании в 60 млн долларов и был остановлен на стадии ввода в промышленную эксплуатацию из соображений экономии.

4)Правительство  штата Квинсленд, Австралия

Правительство австралийского штата Квинсленд, опираясь на отчет  Генерального аудитора, обвинило подрядчика - компанию IBM в неправильной работе системы расчета заработной платы SAP.

По данным отчета, компания IBM была выбрана подрядчиком  правительством штата Квинсленд  для внедрения системы расчета  заработной платы SAP для своей системы  здравоохранения. Однако вместо запланированных восьми месяцев проект растянулся на 26 месяцев, и, когда, наконец, 14 марта 2010 система была запущена, появились основные проблемы.

Тысячам сотрудникам  системы здравоохранения была неправильно  выплачена заработная плата. Затраты  на проект увеличились с первоначальных $6,19 млн. до $64,5 млн. Информационная система до настоящего времени не может правильно произвести расчет заработной платы сотрудникам системы зравоохранения.

«Внедрение системы  длилось на 18 месяцев дольше, чем  было запланировано, и превысило первначальный бюджет, озвученный подрядчиком (IBM), примерно на 300%», говорится в докладе. В настоящее время сумма, выплаченная IBM для реализации проекта, составила более $21 млн. 

5) Провалы миллиардных  проектов ФБР и  АНБ

«Виртуальные  папки дел»

Примерно так можно перевести название компьютерной системы ФБР - Virtual Case File (VCF), которую безуспешно пытались создать и внедрить в Бюро на протяжении 2000–2005 годов. Истратив около 170 млн. долларов, к 2005 году руководство ФБР в конце концов было вынуждено объявить о полном фиаско этой затеи.

Но все пошло  не так, как было задумано. В начале осени 2001 года, всего за неделю до терактов 11 сентября, в ФБР пришел новый  директор Роберт Мюллер. По мнению нового руководства, события 9/11 продемонстрировали неудовлетворительное состояние дел по обмену важной информацией между смежными подразделениями Бюро. Поэтому в декабре того же года планы относительно VCF были радикально пересмотрены, а целью стала полная замена ранее созданных приложений и перенос всех существующих данных в среду СУБД Oracle (в свое время создававшуюся фирмой Ларри Эллисона под нужды ЦРУ). Кроме того, сроки реализации проекта сократили, перенеся время сдачи на декабрь 2003-го.  

Основой всей работы над спешным созданием VCF стал гигантский, на восемьсот страниц, талмуд техзадания, который разработчики SAIC составили на основе бесед с пользователями системы ACS. Эти пользователи (следователи), разумеется, не имели никакого опыта ни в программировании, ни в ИТ-разработках. А программисты, в свою очередь, очень смутно представляли себе специфику следственной работы ФБР. В довершение к этому руководство SAIC разбило программистов на восемь команд, нередко конкурировавших друг с другом и общавшихся мало и неохотно. Естественным результатом стало то, что уже в 2002 году все намеченные сроки безнадежно "поплыли".

В конце 2002 года ФБР, уже осознав перерасход средств, стало просить (и получило) дополнительные десятки миллионов на успешное завершение проекта. К концу 2003 года у программы  сменилось пять руководителей, и, несмотря на все трудности и проблемы разработки, к декабрю 2003 года SAIC представила-таки ФБР свой итоговый продукт - который тут же был расценен заказчиком как совершенно неадекватный и непригодный для реальной работы. SAIC в ответ заявила, что ФБР само во всем виновато, потому что по ходу разработки регулярно меняло собственные спецификации. После нескольких месяцев препирательств независимая арбитражная комиссия пришла к заключению, что в непригодности ПО виноваты обе стороны - и подрядчик, и заказчик.

В 2005 году от системы VCF отказались полностью, как от не поддающейся  исправлениям, а весной 2006 года ФБР  объявило о новой затее с "безбумажным  делопроизводством", теперь получившей название проект Sentinel. На сей раз  в качестве головного подрядчика выбрали ведущую аэрокосмическую корпорацию Lockheed Martin, на работу отвели шесть лет, а денег выделили 425 млн. долларов.

Марш  пионеров

В отличие от ФБР, где отсутствие высококвалифицированных  ИТ-кадров вполне объяснимо, АНБ США традиционно имеет репутацию наиболее продвинутого правительственного ведомства во всем, что касается компьютеров, сетей и информационных технологий вообще. Тем не менее и здесь с разработкой ИТ-систем  случались чрезвычайно дорогостоящие катастрофы .В частности, миллиардный проект Trailblazer, внешняя канва истории которого очень напоминает мучения с VCF.

Еще в 1999 году была запущена строго засекреченная поначалу программа  создания новейшей системы Trailblazer (что  переводится как "пионер" или "новатор"). Главной задачей системы было помочь аналитикам АНБ адекватно оценивать то гигантское количество информации, что ежедневно и ежечасно посты электронного перехвата по всему миру извлекают из Интернета, сетей мобильной связи, проводных телефонных и телеграфных линий, спутниковых коммуникационных систем, телевидения и радио. Понятно, что вся эта информация имеет не только гигантские объемы, но и представлена в самых разных форматах. А задача хоть и немалого, но все равно ограниченного числа аналитиков - разыскать в океане "мусора" перлы и алмазы, действительно важные для разведки и национальной безопасности.

В АНБ давно осознали, что нужны серьезные перемены в подходе к обработке и  анализу цифровых данных. К концу 1990-х была в общих чертах разработана  концепция того, что надо делать. Как предполагалось, система Trailblazer должна была прежде всего преобразовывать перехват из цифрового кодированного формата в тексты, речь и видеофайлы. В этом виде данные подлежали автоматизированному анализу для выявления признаков характерной активности или связей между людьми, состоящими под наблюдением. После анализа данные помещались бы в единую базу, снабженную поисковым инструментарием. Что же касается выявленных при этом наиболее важных коммуникаций, то они автоматически пересылались бы соответствующим аналитикам, которые впервые получали возможность самостоятельно искать нужную дополнительную информацию в базе накапливаемых данных.

Представлявшаяся  очень сложной с самого начала - уже исходный план подразумевал свыше  тысячи "приоритетных направлений" - система Trailblazer стала еще больше раздуваться по мере прохождения инстанций. Разведывательная структура АНБ состоит из трех крупных подразделений, каждое из которых имеет собственные приоритеты, поэтому ТЗ стало обрастать все новыми задачами, а руководители проекта не имели ни влияния, ни времени, чтобы более четко обозначить главные цели и удержать проект в реалистичных рамках.