Александр Подвойский
Эксперт, компания «АйТи»

По оценке разных экспертов перерасход финансовых средств при внедрении сложных решений (к примеру, класса ERP) в среднем составляет 90%, а перерасход времени и того больше — 120%. Безусловно, причин выхода за плановые рамки множество, и набор их в каждом конкретном случае индивидуален. Однако не будет большой ошибкой утверждать, что данная статистика не была бы столь грустна, если бы не безграмотное управление проектом и в частности — управление рисками.

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

Здравствуй, враг!

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

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

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

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

«Звездные» риски

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

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

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

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

Риски можно подразделить на общие, не зависящие от видов ИТ-проектов, и специализированные, которые имеют место при выполнении определенных видов задач.

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

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

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

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

Невидимые и злые

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

С этой точки зрения интересен опыт участия нашей компании в создании системы электронного документооборота. Беспрецедентно масштабный проект для нашего рынка реализовывался в крупной государственной организации и осложнялся тем, что система внедрялась во всех регионах страны. Еще на старте внедрения СЭД менеджер проекта следовал принятой методологии управления рисками: выполнил их формализацию, провел анализ, ранжирование и разработал план ответных действий. Поскольку система внедрялась в течение нескольких лет, изначально формализованный список в ходе проекта постоянно корректировался и принимался во внимание при организации всех проектных работ.

Один из самых серьезных рисков, с которым пришлось столкнуться в ходе проекта, — смена требований, произошедшая после разработки системы и ее развертывания в центральном аппарате ведомства. Когда СЭД уже была запущена в эксплуатацию, организация претерпела серьезную кадровую реструктуризацию со сменой заинтересованных в проекте лиц. Как известно, новая метла по-новому метет, и пришедшее руководство поставило перед проектной командой весьма амбициозные цели: выполнить пилотное внедрение в отдельных регионах не за девять месяцев, а максимум за квартал. В этих экстремальных условиях самым серьезным и вероятным риском оказалась неполная готовность системы к тиражированию. Но если технологическая проблема скоро была решена, то как вести внедрение в регионе с прежним бюджетом? Заказчик предложил тиражировать систему силами собственных ИТ-специалистов. И список рисков проекта пополнился еще одним пунктом: «непонятная» квалификация сотрудников заказчика. На проведение оценки компетенции новых членов команды внедрения не было времени, поэтому менеджер проекта взял за основу наихудшее предположение, допустив, что региональные специалисты обладают самой низкой квалификацией. В связи с этим отбор сотрудников заказчика для последующего обучения и ввода в команду проводился очень жестко. Однако опасность данного риска была преувеличена — в действительности региональные ИТ-подразделения оказались весьма квалифицированными.
Зная основные особенности работы с госструктурами, менеджер проекта в качестве отдельного риска выделил «непрозрачность управления проектом». Так, на вопрос сверху о проделанной работе вполне мог быть снизу получен оптимистичный рапорт: всё работает; в действительности же команда могла испытывать разные сложности. Чтобы владеть объективной информацией по реализации проекта, была разработана специальная система мониторинга, которая позволяла оценивать, сколько сотрудников ведомства в каждом регионе работает в СЭД.

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

Наука о неприятеле

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

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

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