Разделы

ИТ в госсекторе

Великобритания, США, Австралия: самые эпичные провалы зарубежных госпроектов в ИТ

Магия ИТ работает не всегда – некоторые проекты, увы, терпят фиаско. Это случалось и случается по всему миру – от неудач застраховаться невозможно. Не промахивается (как и не ошибается) только тот, кто ничего не делает. Как и почему проекты буксуют, что считать провалом и как его избежать – на опыте самых заметных и публичных историй в США, Великобритании и Австралии.

Масштабный ИТ-проект – это не только впечатляющий бюджет и амбициозность куратора, но зачастую сложный долгострой, сопротивление с самых неожиданных сторон и гигантские риски. Как экономические (конкретные суммы затрат и убытков), так и имиджевые – ведь чем мощнее проект, тем больше он на виду, и тем страшнее провал.

Что считать провалом? В первую очередь смотрят на серьезный перерасход средств и затягивание сроков. В некоторых случаях проект может не завершиться в принципе – его прерывают или замораживают. Более сложная ситуация – когда, даже уложившись в график и бюджет, не удается получить ожидаемых результатов. На успех в этом случае тоже не очень похоже.

По данным опроса Project Management Institute, проведенного в 2017 г. среди 3 тыс. руководителей проектов, 28% их инициатив оказываются провальными. Более трети респондентов видят причину фиаско в отсутствии четко определенных и достижимых задач для оценки степени завершения проекта. Еще 19% упоминают коммуникационные проблемы и дефицит информации, 18% – отсутствие необходимой вовлеченности топ-менеджмента и 14% – сопротивление сотрудников.

Если смотреть на ситуацию в динамике, то улучшений за последние 10 лет не заметно. В 2009 г. IDC оценивали долю неудачных ИТ-проектов в 25% от всех подобных инициатив. При этом около 50% условно успешных проектов требовали существенных доработок, а 25% не выходили на ожидаемые показатели возврата инвестиций. Причины провалов тогда указывались схожие – недостатки планирования и проблемы в коммуникациях, неэффективный обмен информацией и невовлеченность руководства.

Как показали аналогичные исследования PwC за последние три года, важный фактор проектных неудач – негибкие или медленные процессы, отсутствие квалифицированной команды на стороне заказчика, а также проблемы с подрядчиками.

Статистика успешности ИТ-проектов

1.jpg
Источник: The Standish Group, 2013

В оксфордской бизнес-школе 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 млн фунтов на соответствующий консалтинг, обеспечивающий переход к модели управления множеством подрядчиков. По мнению кабинета министров, многолетний контракт с одним генподрядчиком не может обеспечить достаточного уровня инновационности, с одной стороны, и оптимальной стоимости работ, с другой стороны. Целью дробления было увеличить конкуренцию всех возможных подрядчиков, включая средний и малый бизнес, чтобы в конечном итоге обеспечить существенное снижение цен – и значит, расходов госбюджета.

Основные причины провалов ИТ-проектов в организациях

graph.jpg
Источник: KPMG, 2017

Страсти по медицине

Судя по опыту стран-лидеров ИТ, самая «расстрельная» тема – это госпроекты в сфере здравоохранения. Они буксовали в той или иной степени практически везде. Австралия в 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%, также советует разбивать каждую такую активность на несколько подпроектов. Этот подход уже стал обязательным для крупных госинициатив, например, в Великобритании и Дании.

Помимо дробления работ, нужен трезвый взгляд на вещи в целом – без чрезмерного оптимизма, завышенных ожиданий или надежд «на авось». Успеху поможет корректная оценка затрат и необходимых ресурсов, а также строгий контроль сроков и качества работ на каждом этапе. Даже при идеальном планировании что-то всегда может пойти не так, и в проектной деятельности призывы к гибкости и адаптируемости – не прихоть, но обусловленная необходимость. Так же, как высокая стрессоустойчивость у руководителя проекта.

Мария Попова

Подписаться на новости Короткая ссылка