Скрытые риски ИТ-проектов | Большие Идеи

・ Корпоративный опыт
Статья, опубликованная в журнале «Гарвард Бизнес Ревью Россия»

Скрытые
риски ИТ-проектов

На удивление много компьютерных проектов идут вкривь и вкось, увлекая на дно руководителей и всю компанию.

Авторы: Фливбьерг Бент , Будзиер Александер

Скрытые риски ИТ-проектов

читайте также

Как управлять людьми в разных часовых поясах

Ребекка Найт

Пекин готовится к прыжку: чьи теперь технологии?

Гемават Панкай,  Хаут Томас

Что у вас на полках?

Вайдьянатхан Рамнатх,  Маршалл Фишер

Как сплотить сотрудников, работающих в разных городах и часовых поясах

Антон Максименко

Руководители Levi Strauss решили, что настала пора радикально обновить информационную систему. Основанная в XIX веке выходцем из Германии, компания прошла огромный путь и к 2003 году работала более чем в 110 странах мира. Однако ее ИТ представляли собой клубок устаревших и не совместимых друг с другом региональных решений.

В качестве единой платформы выбрали SAP и обратились за помощью к консультантам Deloitte & Touche. Ничто не предвещало серьезных рисков, ведь на проект по расчетам требовалось менее $5 млн. Однако очень скоро дело приняло неожиданный оборот. Один из самых крупных клиентов, Walmart, потребовал, чтобы новая ИТ-система Levi Strauss была совместима с его ­собственной программой для управления поставками. Вдобавок неадекватные модули финансовых отчетов и планирования привели к тому, что компании приходилось корректировать свою квартальную и годовую статистику. В период перезагрузки компания не могла выполнять заказы, и ей пришлось на неделю закрыть три дистрибуторских центра в США. Ко второму кварталу 2008 года сумма недополученных из-за неудачного проекта доходов достигла $192,5 млн, а ИТ-директор Дэвид Берген был отправлен в отставку.

Ситуация, когда проект с расчетным бюджетом в $5 млн приводит к почти 200-миллионным убыткам, — это типичный «черный лебедь». С легкой руки Насима Талеба так называют события, которые априори кажутся маловероятными, а случившись, уже не выглядят такими уж странными.

И действительно, провал, который испытала Levi Strauss, случался у многих, и зачастую размеры катастрофы были еще значительнее. ИТ-проекты стали столь масштабными и затрагивают столько аспектов работы организации, что риски, связанные с их внедрением, всегда высоки. И расплачивается за неудачу всегда кто-то из топ-менеджеров: так, несовместимость ПО разрабатываемого самолета Airbus сломала карьеру гендиректора EADS Ноэля Форжара. Из-за провалов в ИТ ко дну шли целые корпорации. Угроза нависала над городами и даже странами. В 1998—1999 годах многомесячные сбои в информационной системе гонконгского аэропорта, вызвавшие ошибки на информационном табло и в базе данных грузовых перевозок, выразились в $600 млн упущенной выгоды. Мы не удивимся, если в ближайшем будущем какая-нибудь известная корпорация станет очередной жертвой вышедшего из-под контроля проекта. Более того, наверняка именно так и будет.

Мы пришли к этому выводу, проведя самое крупное в истории исследование предпринятых в разных странах ИТ-проектов. Рассмотрев 1471 проект, мы сравнивали запланированные расходы с фактическими и расчетную прибыль с реальной. Большинство проектов требовали больших вложений (в среднем $167 млн, а самый дорогостоящий — $33 млрд). У многих реализация заняла годы. Большую часть нашей выборки составили ИТ-проекты публичных компаний США, однако проекты, которые проводили государственные учреждения, частные компании и европейские фирмы, в целом являли ту же картину.

Главная угроза

Уровень перерасхода по проектам в среднем составил около 27%, но за этой цифрой кроется более тревожная статистика. График распределения обнаруживает «толстый хвост»: множество проектов далеко вышли за рамки бюджета и графика. Каждый шестой оказался классическим «черным лебедем» со средним перерасходом в 200% и с 70%-м превышением сроков. Они практически никогда не укладываются в бюджет (что давно известно управленцам), и, главное, многие растягиваются до бесконечности. Иными словами, среди ИТ-проектов непропорционально много «черных лебедей». Если смотреть на усредненные показатели, упускаешь из виду «экстремальные», но весьма нередкие случаи.

Некоторые проблемы известны давно. К примеру, десять с лишком лет назад кондитерская компания Hershey’s, переходя на новую систему прие- ма и выполнения заказов, не успела ­вовремя поставить конфеты к празднику Хэллоуин на сумму в $100 млн, из-за чего ее квартальная прибыль упала на 18,6%. Результаты нашего исследования говорят, что подобные сбои происходят регулярно. Сильнее всего страдают компании, и без того испытывающие трудности, к примеру, из-за катастрофического падения рентабельности, всевозрастающих расходов, необходимости выплачивать высокие проценты по кредитам и т.п. Провальный ИТ-проект может окончательно их добить.

Ритейлер Kmart уже сдавала позиции на рынке под натиском конкурентов — Walmart и Target, когда в 2000 году решила вложить $1,4 млрд в модернизацию ИТ. К 2001 году она поняла, что новая система очень специализирована и ее обслуживание обойдется слишком дорого. Тогда она решила потратить еще $600 млн, чтобы обновить ПО для управления закупками. В 2002 году этот проект провалился, и в итоге компания была вынуждена объявить о банкротстве. Позднее Kmart слилась с Sears Holdings. Ей пришлось закрыть 600 магазинов и уволить 67 тыс. сотрудников.

Не только в США компании терпели бедствие по вине неудачных ИТ-проектов. В 2006 году британская Auto Windscreens занимала почетное второе место на рынке автостекла, а ее чистый годовой доход достигал 63 млн фунтов. И тут руководство решило перевести­ систему заказов с Oracle на Metrix, а также начать внедрять ERP-систему на базе Microsoft. В четвертом квартале 2010 года совокупность факторов — падение продаж, проблемы со складском учетом и огромные затраты на реализацию ИТ-проекта — привела к краху: компания объявила себя банкротом. Несколькими годами раньше германская Toll Collect (консорциум DaimlerChrysler, Deutsche Telekom и Cofiroute of France) сама себе вырыла яму, задумав внедрить новую систему сбора дорожных пошлин с грузовых фур в Германии. Разработчики безуспешно пытались интегрировать разные системы программного обеспечения, и в конце концов на этом проекте, по некоторым подсчетам, государство потеряло $10 млрд.

Сегодня ПО стало неотъемлемой частью самых разных продуктов — от автомобиля до бытовой техники, однако ни их разработчики, ни менеджеры часто не имеют должного представления о том, как надо встраивать ИТ в общую разработку. Показательный пример  — самолет A380, который с самого начала был задуман как соединение достижения самых передовых технологий.

Проект аэробуса, завершенный к 2001 году, предполагал огромную электронную начинку: более 500 км проводов, 98 тысяч кабелей и 40 тысяч соединений. Вскоре, однако, обнаружилоcь, что партнеры в Германии и Испании используют более старую версию ПО, нежели их коллеги в Великобритании и Франции, что привело к проблемам с совместимостью. В 2005 го­ду­ компания объявила о переносе даты выпуска первого самолета на полгода. На следующий год история повторилась: выпуск был отложен еще на шесть месяцев, и тогда акции Airbus упали на 26% и ряд крупных фигур был отправлен в отставку. В 2010 году компании все еще не удавалось войти в график поставок, и бесконечные проблемы с самолетом A380 привели к дальнейшим финансовым потерям и изрядно подмочили ее репутацию.

Как обезопаситься от «черных лебедей»

Любой компании, замышляющей серьезный ИТ-проект, нужно для начала провести стресс-тест, ответив на два вопроса. Во-первых, располагает ли она достаточными средствами, чтобы справиться с убытками, если проект в четыре с лишним раза превысит бюджет, а поставленные задачи будут решены лишь на 25—50%? Во-вторых, сможет ли компания выдержать удар, если 15% ее самых обычных, «второстепенных» проектов превысят бюджетную планку на 200%? На первый взгляд эти цифры кажутся запредельными, однако на деле встречаются с пугающей частотой.

Если ваша компания успешно прошла стресс-тест, стоит предпринять меры, чтобы обезопасить себя от «черных лебедей». А именно: разбить крупный проект на более мелкие, простые и ограниченные во времени модули, разработать аварийный план на случай срыва и, наконец, применить эффективные способы оценки рисков, такие как «прогнозирование по аналогии». Этот метод, основанный на разработках нобелевских лауреатов Дэниеля Канемана и Амоса Тверски, заключается в анализе аналогичных проектов. Сегодня он широко используется в бизнесе, государственном управлении и консалтинге, а в Великобритании и Дании стал обязательным для крупных проектов с участием государства.

По мере того как компании будут все больше полагаться на количественные данные, им придется время от времени «перезагружать» свои информационные системы. Однако следует помнить, что риски, связанные с такими проектами, весьма высоки, и потому они требуют повышенного внимания руководства.

ИСТОРИЯ УСПЕХА: КАК УДАЛОСЬ УДЕРЖАТЬ ИТ-ПРОЕКТ В ЗАДАННЫХ ПАРАМЕТРАХ

В апреле 2006 года Еmirates Bank решил перевести некоторые функции на новые ИТ. Год ушел на подготовку. Руководство ставило перед собой две цели: не допустить сбоев в работе банка и запустить новую систему как можно скорее. Однако летом 2007 года банк объявил о слиянии с Национальным банком Дубая. Новая компания получила имя Еmirates NBD. Осуществлять и без того непростой проект стало еще сложнее: теперь система должна была обслуживать оба банка одновременно, при этом все должно было быть готово всего через 18 месяцев. Разные модули должны были начать работать по-новому сразу и одновременно: компьютеры в отделениях, банкоматы, интернет-банк и колл-центры. Угроза превышения бюджета была серьезной. К моменту успешного окончания проекта (ноябрь 2009 года) отставание от графика составило всего 7%, а превышение бюджета — 18%, несмотря на то что в связи со слиянием банков объем работ был вдвое больше запланированного. На общем фоне это можно считать выдающимся достижением.

ВОТ КЛЮЧЕВЫЕ МЕРЫ, ПРЕДПРИНЯТЫЕ РУКОВОДИТЕЛЯМИ ПРОЕКТА.

1. Они жестко придерживались намеченного графика даже после слияния.

2. Пресекали попытки расширить проект.

3. Разбили проект на отдельные модули.

4. Правильно подобрали проектную команду, включив в нее ИТ-специалистов из обоих банков, внешних экспертов и представителей подрядчиков.

5. Не допустили текучки среди членов команды.

6. Позиционировали начинание как бизнес-проект, а не технологическое усовершенствование.

7. Сконцентрировали все усилия на единственной цели — «готовность к запуску», оценивая все производимые работы по этому критерию.

Проблема не только в высоких технологиях

Жертвами распыления усилий и неспособности должным образом контролировать ход множества разных проектов могут стать руководители в самых различных сферах бизнеса. Группа исследователей из Берлинского технического университета во главе с Сашей Мескендаль изучала это явление на базе 200 немецких транснациональных компаний. В некоторых из них одновременно реализовывалось по нескольку тысяч мелких проектов. Результаты исследования были неутешительными: в общей сложности неудачи обошлись компаниям в круглую сумму — $14,3 млрд. По словам ученых, «просто хорошо управлять каждым конкретным проектом недостаточно, необходимо также правильно выбирать проекты для реализации, увязывать их между собой и вовремя прекращать неудачные начинания». Главный вывод: хотя основные правила управления проектами кажутся совсем несложными, большинство компаний на практике им не следует.