Риски отказа от реализации ИТ-проектов: что делать в первую очередь

ИТ-проекты в инвестиционной программе

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

Коммерческие ИТ-проекты сравнить проще: у них есть экономический эффект, и его можно выразить в деньгах. Но сейчас большую часть нашего ИТ-портфеля составляют обязательные проекты, а у них такого эффекта нет. Как решить, какие из них финансировать первыми, когда на всё не хватает, а обязательно почти всё?

Опорой для такого выбора должны были стать “Риски отказа от реализации”. Такой раздел давно обязателен и в карточке проекта, и в материалах на защиту финансирования, и отвечает на вопрос, что будет, если проект не делать. Формально риски там были у всех. Мы их собрали, перечитали и схватились за голову.

“Потеря ранее понесённых затрат”, “Сохранение текущей менее эффективной практики планирования”, “Невозможность гибко реагировать на быстро меняющиеся условия внешней среды с учётом санкционного влияния”, “Нарушение требований действующего законодательства РФ” - это то, что было написано в материалах.

Ни одна из этих формулировок не лжёт, и каждая по-своему даже отвечает на вопрос, что будет без проекта. Но положите рядом два проекта с такими рисками и попробуйте решить, какой из них важнее, или объяснить комитету, почему один нужно профинансировать сейчас, а другой подождёт. Не выйдет. Первая формулировка говорит о деньгах, которые уже потрачены, и ничего не сообщает о том, стоит ли давать новые. Последняя звучит серьёзно, но не называет ни закона, ни требования, ни последствий.

Такие формулировки и есть заглушки, их пишут, чтобы обязательный раздел в документе был заполнен. Пока по рискам отказа ничего не решают, вреда от заглушек нет, но и отличить их от настоящих рисков нельзя, потому что ни те, ни другие ни на что не влияют. Риски отказа становятся инструментом в тот момент, когда по ним приходится принимать решение, на что выделять деньги, а на что - нет.

В октябре и декабре 2025 года я рассказывал на конференциях “Управление проектными офисами” и “Управление проектами”, как мы привели риски отказа в порядок, чтобы по ним можно было принимать решения. В этой статье делюсь ключевыми идеями того выступления, которые в текущем году пришлось проверить на практике.

Как сделать риски отказа сравнимыми

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

Сначала нужна цель. За основу мы взяли COSO ERM, где риск всегда угрожает конкретной цели компании. Без цели не сравнить даже два серьёзных риска: потерю денег и угрозу промышленной безопасности на одну шкалу не положишь, пока не ясно, какой цели угрожает каждый из них. Поэтому каждый риск отказа привязан к показателю влияния, а через него к одной из целей компании. Показатель влияния отвечает на вопрос, на что повлияет риск, если он реализуется.

Заодно цель делает риск ИТ-проекта понятным тем, кто распределяет деньги. Им не нужно разбираться в информационной системе, чтобы понять, какой цели компании угрожает отказ от проекта, будь то финансовый результат или соблюдение законодательства.

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

Третий шаг даёт общую шкалу. Вероятность и воздействие оценивают по критериям, описанным для каждого показателя влияния, и по матрице риск получает один из четырёх уровней: умеренный, значительный, высокий или критический. Так становятся сравнимыми риски, которые угрожают разным целям. Иначе каждое обсуждение начиналось бы со спора о том, чей риск страшнее. Методологию мы при этом сознательно не усложняли, потому что заполнять форму будут инициаторы каждого проекта и она должна быть им по силам.

Четвёртый шаг самый неприметный, хотя на нём держится всё остальное. Уровень подтверждает владелец риска, то есть руководитель или коллегиальный орган, в чьей зоне ответственности этот риск. Пока он не подтвердил, риск отказа не принимается. Молчаливое согласие здесь не считается. Владелец сам соглашается и с описанием, и с уровнем.

Зачем это нужно, видно из самой задачи. Каждый инициатор хочет получить деньги для своего проекта и заинтересован в том, чтобы проект выглядел как можно более критичным, и это естественно. Но если уровень ставит он сам, критическими окажутся почти все проекты, и уровни перестанут различать их так же, как перестало различать слово “обязательный”. Реестр превратится в архив деклараций.

Владелец риска смотрит на ту же угрозу со своей стороны: он управляет этим риском, выбирает, как на него реагировать, и отвечает за корректность оценки. Завысить уровень может и он, но тогда эту оценку ему придётся отстоять на защите проекта перед экспертами.

Риск впервые появляется в карточке инициативы, а потом обновляется на инвестиционном подкомитете и на управляющем комитете. Реестр, который не обновляют, быстро устаревает, ведь риск, актуальный при инициации, через год может стать менее критичным или, наоборот, вырасти. По каждому риску в реестре видно, кто его подтвердил и каким решением, так что на защите понятно, кто отвечает за оценку. После того, как мы начали системно заниматься рисками отказа, сейчас в реестре их более 700.

Как по рискам решают, что финансировать

Выбор начинается ещё до уровней, с фильтра на входе. Это набор критериев, каждый из которых связан с целями компании, и работает он у нас несколько лет. Проект попадает в портфель, если соответствует хотя бы одному критерию, иначе карточку отклоняют.

Фильтр решает, что вообще попадает в портфель, а риски отказа решают порядок, когда на всё не хватает. Не будь фильтра, давление лимита легло бы на все проекты подряд, включая те, которым в портфеле не место. А один фильтр не помогает, когда денег меньше, чем проектов, потому что через него проходит почти всё обязательное.

Внутри портфеля у проекта бывает несколько рисков отказа, и уровень риска проекта равен максимальному из уровней связанных с ним рисков. Мы не усредняем и не складываем. При усреднении проект с одним критическим риском затерялся бы среди умеренных, а при сложении вперёд вышли бы проекты, у которых просто много мелких рисков. Правило максимума ещё и легко проверить: достаточно найти у проекта самый серьёзный риск и посмотреть, кто его подтвердил.

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

Уровень, записанный при инициации, со временем может измениться: появляются другие меры защиты, меняются планы по самому объекту. Поэтому оценивают текущий уровень риска, с учётом всех альтернативных мер, которые могут его снизить, иначе деньги получит проект, от угрозы которого компанию уже защищает что-то другое. Например, если для оборудования доступны альтернативные каналы поставки запчастей, это может снизить текущий уровень риска и позволить перенести срок реализации.

Иногда пересмотр меняет картину целиком. Проект реновации системы управления очистными сооружениями инициировали, потому что существующая АСУ ТП зарубежного производства, а запасных частей к ней нет. В ходе разбирательства выяснилось, что сам объект очистных сооружений планируется к реновации в течение нескольких лет и существующая АСУ ТП будет выведена из эксплуатации. Угроза была названа конкретно, но с учётом планов по самому объекту она выглядит совсем иначе, чем в карточке.

Лимит редко проходит ровно по границе между уровнями, и проекты с высоким и значительным уровнем приходится подгонять под ограничения. Без этого у комитета остаются два ответа, дать деньги целиком или отказать, и проект, которому не хватило немного, теряет всё. В докладе 2025 года я перечислил четыре варианта, что делать в такой ситуации:

• прекратить или приостановить,
• начать позже,
• делать дольше (тогда я окрестил это мечтой проектного менеджера, но годится такой вариант, только если позволяют риски)
• поиграть объёмом.

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

Риски отказа в нашем случае - это тот инструмент, который работает и помогает решить, что финансировать в первую очередь. Попробуйте: возможно, это сработает и у вас.