Поделиться
Великобритания, США, Австралия: самые эпичные провалы зарубежных госпроектов в ИТ
Магия ИТ работает не всегда – некоторые проекты, увы, терпят фиаско. Это случалось и случается по всему миру – от неудач застраховаться невозможно. Не промахивается (как и не ошибается) только тот, кто ничего не делает. Как и почему проекты буксуют, что считать провалом и как его избежать – на опыте самых заметных и публичных историй в США, Великобритании и Австралии.
Масштабный ИТ-проект – это не только впечатляющий бюджет и амбициозность куратора, но зачастую сложный долгострой, сопротивление с самых неожиданных сторон и гигантские риски. Как экономические (конкретные суммы затрат и убытков), так и имиджевые – ведь чем мощнее проект, тем больше он на виду, и тем страшнее провал.
Что считать провалом? В первую очередь смотрят на серьезный перерасход средств и затягивание сроков. В некоторых случаях проект может не завершиться в принципе – его прерывают или замораживают. Более сложная ситуация – когда, даже уложившись в график и бюджет, не удается получить ожидаемых результатов. На успех в этом случае тоже не очень похоже.
По данным опроса Project Management Institute, проведенного в 2017 г. среди 3 тыс. руководителей проектов, 28% их инициатив оказываются провальными. Более трети респондентов видят причину фиаско в отсутствии четко определенных и достижимых задач для оценки степени завершения проекта. Еще 19% упоминают коммуникационные проблемы и дефицит информации, 18% – отсутствие необходимой вовлеченности топ-менеджмента и 14% – сопротивление сотрудников.
Если смотреть на ситуацию в динамике, то улучшений за последние 10 лет не заметно. В 2009 г. IDC оценивали долю неудачных ИТ-проектов в 25% от всех подобных инициатив. При этом около 50% условно успешных проектов требовали существенных доработок, а 25% не выходили на ожидаемые показатели возврата инвестиций. Причины провалов тогда указывались схожие – недостатки планирования и проблемы в коммуникациях, неэффективный обмен информацией и невовлеченность руководства.
Как показали аналогичные исследования PwC за последние три года, важный фактор проектных неудач – негибкие или медленные процессы, отсутствие квалифицированной команды на стороне заказчика, а также проблемы с подрядчиками.
Статистика успешности ИТ-проектов
В оксфордской бизнес-школе Saïd Business School изучили более 1470 ИТ-проектов, сравнив их бюджеты и ожидаемые эффекты с реальными затратами и результатами. Как оказалось, многие из исследованных инициатив длились несколько лет вместо запланированных изначально месяцев. При этом выяснилось, что степень «пробуксовки» примерно одинакова для правительственных организаций и частных компаний. Не было обнаружено и особых различий в эффективности по географическому признаку – и в Европе, и в США каждый шестой ИТ-проект оказывался провальным. Это подразумевало разрастание изначального бюджета (чуть ли не до 200%) и затягивание сроков (почти на 70%).
Большие неудачи
Наиболее крупный ИТ-замах обычно отличает госсектор – соответственно, и промахи здесь фиксируются чаще и более значительные. Самые «громкие» из них приходятся на развитые с точки зрения информатизации и цифровизации страны, включая США, Великобританию, Канаду, Швецию и Австралию. В каждой из них, так или иначе, сталкивались и с ИТ-долгостроями, и с критическими ситуациями при внедрении госинформационных систем. Даже пионер в области развития цифрового правительства – Южная Корея – признавала неудачи первой фазы реализации проекта G4C (government for citizens) в 2002 г., что повлекло в последующие два года перепланирование второй фазы, с новыми акцентами на мультиканальность и интероперабельность.
В Великобритании после плотного сотрудничества с Microsoft в 1990-х, на начальном этапе сформировавшей архитектуру электронного правительства, предпринимали несколько попыток перейти к менее масштабным, менее дорогим и менее длительным проектам без единого подрядчика. Менее длительным – по британским меркам значит хотя бы менее 10 лет. Например, программа построения электронной границы обошлась с 2003 г. до 2015 гг. в 830 млн фунтов (и еще 275 млн требовалось проинвестировать до ее запуска в 2019 г.). Новая система работала параллельно со старой, которую предполагалось отключить в 2011 г., однако позже срок сдвинулся до конца 2018 г. Прежний подрядчик (Raytheon) был отстранен от работ в 2010 г., после чего начал судиться с заказчиком – департаментом внутренних дел. Полноценный запуск системы в срок затормозили слишком амбициозные, но плохо проработанные технические требования, которые не учитывали необходимый объем трансформации бизнес-процессов для организации межведомственного взаимодействия. В числе главных причин провала аудиторы указали слабый менеджмент, отсутствие полноценной стратегии внедрения, а также отсутствие необходимых инструментов для интеграции всех собираемых данных. Система должна была аккумулировать данные более 600 авиа-, ж/д и морских перевозчиков, а также около 30 правительственных агентств. Дополнительные сложности возникли в ходе проекта, при смещении фокуса на обеспечение въезда в страну гостей олимпиады. За время реализации программы сменилось пять ее руководителей до 2010 г. и еще двое – с 2010 до конца 2014 г. Впрочем, отставки провинившихся кураторов британских проектов e-government не мешали впоследствии их продвижению в других регионах. Например, основатели службы GDS (Government Digital Service) и ее бывший директор Майк Брэйкен открыли глобальное консалтинговое агентство, чтобы оказывать услуги по цифровой трансформации другим странам, начав с сотрудничества с правительственными организациями США и Австралии. Их уход пришелся на период серьезного сокращения бюджетов и штата GDS осенью 2015 г., с целью минимизации расходов госаппарата и ужимания бюджета.
Другой пример британской неспешности – проект налогового управления (HM Revenue and Customs), более 10 лет реализующего цифровую программу Aspire, изначально при участии двух подрядчиков – Capgemini и Fujitsu. При бюджете более 11 млрд фунтов работы должны были завершиться в 2017 г. К 2015-му стало понятно, что этого не произойдет, если не разорвать контракт и не перераспределить работы между 400 менее крупными поставщиками (чтобы доля каждого не превышала 100 млн фунтов). Правда, оказалось, что такой маневр тоже затратен – нужно потратить около 600 млн фунтов на соответствующий консалтинг, обеспечивающий переход к модели управления множеством подрядчиков. По мнению кабинета министров, многолетний контракт с одним генподрядчиком не может обеспечить достаточного уровня инновационности, с одной стороны, и оптимальной стоимости работ, с другой стороны. Целью дробления было увеличить конкуренцию всех возможных подрядчиков, включая средний и малый бизнес, чтобы в конечном итоге обеспечить существенное снижение цен – и значит, расходов госбюджета.
Основные причины провалов ИТ-проектов в организациях
Страсти по медицине
Судя по опыту стран-лидеров ИТ, самая «расстрельная» тема – это госпроекты в сфере здравоохранения. Они буксовали в той или иной степени практически везде. Австралия в 2013 г. пересматривала программу внедрения электронных медицинских карт для пациентов национальных больниц (Personally Controlled Electronic Health Record, PCEHR) ввиду недостижения результатов в сроки. В проект, который стартовал с бюджета около $500 млн под контролем Минздрава, в результате было вложено более $1 млрд. Реализация длилась три года – предполагалось, что к 2013 г. будет внедрено 500 тыс. электронных медицинских карт, однако по факту было зафиксировано около 400 тыс., при этом не все были заполнены информацией о здоровье пациентов. В результате разразившегося скандала ряд участников проекта потеряли свои посты, а причиной неудачи министр здравоохранения страны назвал недостаточную вовлеченность врачей и отсутствие необходимой обратной связи от разных сторон.
Еще хуже сложилась ситуация для инициаторов создания национальной системы здравоохранения Великобритании NHS Connecting for Health. Это один из самых эпичных провалов – проект стартовал в 2005 г. с бюджета в £2,3 млрд. Не уложившись в запланированные 3 года, британцы потратили более 12 млрд, но в результате все равно признали проект создания единой системы хранения медицинских данных пациентов провальным. Члены Парламента Великобритании охарактеризовали проект, как «худшее и самое дорогое фиаско» за всю историю. Главной ошибкой считается слабо продуманная концепция и несогласованность ее деталей с пользователями, слабый уровень осведомленности о ее преимуществах, а также неэффективный менеджмент.
В США за провал запуска портала HealthCare.gov пришлось извиняться лично Бараку Обаме. Хотя еще в марте 2013 г. Генри Чао, главный ИТ-архитектор администрации Обамы, озвучивал обеспокоенность в связи с запуском нового страхового маркетплейса. Беспокоиться было о чем – ведь до той самой весны даже не начиналась разработка софта. Подрядчики ждали уточнений по спецификациям от госзаказчика, которые запаздывали почти на год. Затем полгода ушли на обсуждение функциональности и дизайна портала, долго решали, нужно ли пользователям регистрироваться, стоит ли заводить для них аккаунты с доступом по паролю и пр. Дедлайны срывались по каждому этапу. Параллельно высказывались осторожные сомнения в достаточности бюджета, человеческих ресурсов и компетенций на стороне заказчика. Ведь именно на него «повесили» ответственность за координацию интеграционных работ и тестирование связанности всех разрозненных компонентов системы и баз данных. Было понятно, что задача и сама по себе технически очень сложная, а при этом вести ее нужно параллельно с менеджментом 55 вовлеченных в проект подрядчиков.
Как будто для усиления эффекта «самоубийцы», было решено запускать систему целиком и сразу – вместо вроде бы проверенного метода поэтапного старта, который позволяет быстрее выявлять «косяки» и почти сразу их «фиксить». Представители со стороны заказчика продолжали настаивать, что проект движется по плану и уже к 1 октября 2013 г. порталом смогут воспользоваться все граждане. Для привлечения максимального внимания прошло две волны рассылок по электронной почте – в августе и сентябре. В итоге количество запросов к сайту в назначенную дату его открытия зашкаливал. Однако за первую неделю работы лишь 1% посетителей смогли хотя бы завершить процесс регистрации.
На фоне разразившегося скандала подрядчики включились в борьбу за сохранение своей репутации, публично дистанцируясь от выявленных проблемных компонент. Глава разработчика Development Seed подчеркивал, что его компания отвечала только за дизайн HealthCare.gov и не имеет никакого отношения к тому, что происходит после нажатия кнопки «Подать заявление» (Apply Now). А руководство Oracle, отвечавшей за систему идентификации, утверждало, что софт корпорации работает корректно (и в принципе всегда успешно используется в сложных системах). Руководство проекта признало, что подрядчики действительно сделали все, что могли в сложившихся условиях. Ну, или почти все. Штрафы все же были наложены, но в существенно меньшем размере.
Кто виноват и что делать
Анализируя крупнейшие ИТ-провалы, можно выделить ряд общих слабых мест. Главный критерий фиаско – это неполучение ожидаемых результатов, и причина тут может быть не только в затягивании сроков, неверной изначально оценке сложности работ или дефиците экспертизы, но и в изменении приоритетов по ходу реализации проекта. Долгострои чреваты, в том числе, тем, что не успевают за темпами рынка, и выбранная пять лет назад технологическая траектория может просто на глазах устареть, потерять былую эффективность и, очевидно, не дать адекватного текущему моменту результата или качества. Помимо технологического, делу вредит еще и процессное отставание – именно на негибкие или медленные процессы в PwC списывают причину большинства провалов. Причем чем более они «ручные», чем ниже уровень автоматизации – тем выше риск. Ну, и в контексте ИТ не стоит забывать о собственно технических рисках. Чем масштабнее проект, чем больше систем он вовлекает, тем сложнее обеспечить необходимый уровень интеграции. Не говоря уже о том, что в любом оборудовании в принципе возможны (и случаются в самый неподходящий момент) сбои.
«Казнить» виновных в провалах крупных проектов госзаказчики в мировой практике часто начинают с себя, видя причину неудач в отсутствии компетенций или опыта, который позволил бы на старте оценить масштабы требуемых изменений (организационных и регуляторных), а также оценить и масштабы сопротивления этим изменениям. Человеческий фактор остается ключевой проблемой для успеха большинства начинаний. Только во вторую очередь возникают вопросы собственно к технологиям и предложенным решениям.
Впрочем, человеческий же фактор может стать и спасением проекта – когда нужные люди оказываются на нужном месте в нужное время (кадры, по-прежнему, решают все). Важны квалифицированные ресурсы и хорошее планирование – чтобы с самого начала были четко определены цели и распределены зоны ответственности. Второй «столп» ожидаемого результата – настроенные коммуникации между всеми участниками проекта. Они позволят и отслеживать актуальный статус работ, и быстро вносить необходимые коррективы, и «удерживать» границы проекта, не давая ему «обрастать» бесконечными дополнениями и новыми вводными. Подстраховать может действительно «работающее» партнерство, когда все команды работают слаженно, а изменения вносятся «на лету». Специально организованные среды – «песочницы», а также быстрые пилоты могут помочь в предотвращении или хотя бы ограничении ущерба.
Благодаря болезненным, подробно разобранным ошибкам, многие страны теперь стремятся уйти от мега-проектов и мега-подрядчиков (единых поставщиков). Дополнительный инструмент контроля за сроками – agile-подход, как раз подразумевающий дробление проектов на обозримые по бюджету и сроку составляющие. В частности, переходить на такие небольшие проекты, которые проще контролировать, рекомендует Saïd Business School. В свою очередь, Standish Group, оценивая вероятность для крупных ИТ-проектов уложиться в сроки и бюджет в 35–40%, также советует разбивать каждую такую активность на несколько подпроектов. Этот подход уже стал обязательным для крупных госинициатив, например, в Великобритании и Дании.
Помимо дробления работ, нужен трезвый взгляд на вещи в целом – без чрезмерного оптимизма, завышенных ожиданий или надежд «на авось». Успеху поможет корректная оценка затрат и необходимых ресурсов, а также строгий контроль сроков и качества работ на каждом этапе. Даже при идеальном планировании что-то всегда может пойти не так, и в проектной деятельности призывы к гибкости и адаптируемости – не прихоть, но обусловленная необходимость. Так же, как высокая стрессоустойчивость у руководителя проекта.
Мария Попова
Короткая ссылка
