Чтобы выяснить, как обстоят дела с применением риск-менеджмента на практике в российских ИТ-проектах, мы провели опрос в ведущих компаниях — системных интеграторах. По общему мнению экспертов, если под управлением рисками понимается анализ возможных проблем, то такая практика распространена повсеместно, а если говорить о применении методологии, то реально управлять своими рисками пытается не так много компаний.
Большинство
методологий разработки и внедрения информационных систем предполагают обязательные
процедуры управления рисками проекта. Однако российские компании явно не спешат
с выполнением этих правил. Александр Гришин, старший консультант IBM Global
Technology Services, считает, что хотя некоторые предприятия такую практику
не только применяют, но и имеют соответствующие регламентирующие документы на
этот счет, она пока не получила широкого распространения, а там, где применяется,
качество анализа и оценки рисков оставляет желать много лучшего. Многолетняя
практика работы в условиях постоянной нестабильности приводит к тому, что люди
следуют принципу «решаем проблемы по мере их поступления», считая бессмысленным
волноваться заранее именно потому, что список возможных негативных обстоятельств
слишком велик и от всего застраховаться невозможно. «В нашей стране практика
оценки рисков широко применяется в основном в российских представительствах
международных компаний, для которых риск-менеджмент представляет собой составной
элемент управления организацией в целом», — говорит Георгий Дунаев, начальник
отдела анализа и моделирования бизнес-процессов департамента консалтинга компании
«Ай-Теко». Анализируются риски и в больших проектах, когда бюджет большой или
проект для предприятия является инновационным либо политически значимым. Причем,
по мнению Владимира Новикова, директора департамента управления проектами компании
«Микротест», в первом случае необходимо анализировать и оценивать риски, оказывающие
влияние на стоимость проекта, во втором — на сроки и качество. Либо в комплексе,
если проект удовлетворяет обоим условиям.
Опыт важнее теории
Составление перечня возможных рисков — базовый этап риск-менеджмента. Как правило, стандартным методом составления такого списка является опрос собственных сотрудников компании, или «мозговой штурм». Гораздо реже российские предприятия используют технику «номинальной группы» (по сути двухуровневый «мозговой штурм»). Но все эти методы опираются только на собственный опыт компании (в редких случаях — на усредненный мировой опыт). «В основном компании основываются на теории, на собственном опыте и на опыте своих коллег, — говорит Александр Гришин (IBM Global Technology Services). — К помощи внешних экспертов прибегают редко, например в проектах (таких, как разработка ИТ-стратегии), где внешние консультанты разрабатывают различные стратегические инициативы. Для таких инициатив часто проводится высокоуровневая оценка и анализ рисков». Но даже в таких случаях, как правило, предполагается, что более детальной проработкой этого вопроса займётся сам заказчик. «Эксперты, как правило, выявляют реальные риски и предлагают комплексный подход к управлению ими, — добавляет Сергей Кошелев, директор департамента корпоративных информационных систем компании “Открытые Технологии”. — Но в некоторых случаях риски, выявленные экспертами, заказчиком расцениваются как несущественные. В качестве примера можно привести риск недостаточной степени участия руководства в проекте или риск отсутствия мотивации сотрудников заказчика, участвующих в проекте. В последнем случае исполнитель должен проявить смелость и настойчивость на самых первых шагах проекта, чтобы разъяснить смысл этого риска и суметь заставить заказчика предпринять упреждающие меры. И уж если речь зашла об экспертах, то нужно понимать, что экспертиза — это опыт. Опыт управления рисками ИТ-проектов в России только начинает формироваться, поэтому реальная экспертиза пока основывается на опыте зарубежных проектов».
Олег Зименков, первый заместитель генерального директора компании «Оптима-интеграция», обращает внимание на то, что привлечение внешних экспертов для составления списка проектных рисков может являться одним из обязательных условий инвестора, если проект масштабный и идет с привлечением крупных, в том числе западных инвестиций. «В одном из наших проектов, по построению единой сети цифровой связи для РАО ЕЭС, создание которой финансировалось мировым и европейским банками реконструкции и развития, такая оценка выполнялась», — рассказывает он. По мнению Олега Зименкова, проведение внешней экспертизы по оценке рисков, конечно, увеличивает срок подготовки к проекту. Но при этом как у заказчика, так и у поставщика услуг появляется возможность избежать глубоких системных ошибок с очень серьезными далеко идущими последствиями.
| Восемь наиболее опасных рисков | |
|
Опросив экспертов, мы попытались составить список рисков, наиболее актуальных при реализации ИТ-проектов. 1. Недостаточное внимание к проекту со стороны руководства компании. «Зачастую ожидания от ИТ-проекта и роли информационных технологий в целом со стороны руководства неправильные. Длинный цикл реализации проекта, а также небыстрый, как правило, возврат вложенных инвестиций приводят к угасанию интереса», — говорит Елена Шедова, директор по маркетингу компании «Стерлинг Интеграция». 2. Неконкретная постановка задачи или непонимание сторонами конечных целей проекта. Ситуации, когда исполнители и заказчики проекта не до конца понимают цели проекта, увы, случаются нередко. «Подобные риски ожидания весьма принципиальны, и особенно они важны в тех проектах, где, например, стоит задача внедрения целого комплекса сложных систем или систем “верхнего уровня” — финансово-расчетных, ERP, CRM, — говорит первый заместитель генерального директора компании “Оптима-интеграция” Олег Зименков. — Если для инфраструктурных проектов, например, риск несоответствия ожиданиям незначителен, поскольку результат можно как-то измерить, то для комплексных проектов или проектов по внедрению бизнес-решений эти риски выходят на первый план. Проект по внедрению ERP-системы с целью сокращения издержек предприятия нельзя назвать успешным, если эта цель не была достигнута». Разновидностью такого риска можно считать завышенные ожидания — переоценку руководством компании роли и возможностей готовых бизнес-приложений с одновременной недооценкой всего комплекса мероприятий по их внедрению. 3. Изменения, вносимые заказчиком в процессе реализации проекта. Это также очень часто возникающий риск. Александр Савинов, руководитель направления бизнес-приложений компании «Крок», приводит пример такой ситуации: «В ходе реализации проекта по внедрению автоматизированной системы бюджетирования компания приняла решение существенно изменить финансовую структуру, в результате чего проект остановился. И это не вина одной из сторон — это осуществившийся риск, который привел к потере средств, затраченных на первые этапы проекта». Частный случай такого риска — расширение рамок проекта, увеличение количества задач или функциональных областей, подлежащих автоматизации. 4. Недостаточная квалификация персонала. Повсеместно встречающаяся ситуация, когда заказчик переоценивает свои возможности и компетенцию. «Дефицит компетентных специалистов в штате заказчика осложняет ход проекта, и это прежде всего характерно для госсектора», — говорит Георгий Дунаев, начальник отдела анализа и моделирования бизнес-процессов департамента консалтинга компании «Ай-Теко». Но не стоит идеализировать и квалификацию исполнителя. Владимир Романов, и. о. руководителя дирекции системной интеграции компании «УСП КомпьюЛинк», напоминает, что ошибки исполнителя — это по сути своей универсальный риск, которому могут быть подвержены любые ИТ-проекты. 5. Отсутствие мотивации персонала компании, противодействие персонала. Этот риск ниже для предприятиий, переживающих в настоящее время экстенсивный рост, стремительную географическую диверсификацию и динамичное расширение клиентской базы: торговых сетей, автосалонов, сервисных центров, то есть для молодых, современных компаний, руководство и бизнес-процессы которых готовы к переменам. Сопротивление проекту могут оказывать и ключевые специалисты. «Бизнес-приложения делают все процессы, протекающие в компании, значительно прозрачнее. Существует риск, что проекту станет сопротивляться ключевой сотрудник, который не захочет делать информацию доступной, — рассказывает Александр Савинов. — Есть реальный пример, когда при внедрении системы финансового учета финансовый директор оказал существенное сопротивление проекту, поскольку в случае успеха финансовые потоки становились понятными другим топ-менеджерам, его внутренним конкурентам. В результате проект был остановлен после реализации пилотного макета». 6. Срыв сроков. По сути это комплементарный риск, являющийся следствием причинных рисков. Такой риск может реализоваться как по вине исполнителя проекта, так и по вине заказчика. Консультанты, правда, в один голос утверждают, что в основном виноваты заказчики. «Специалисты заказчика всегда заняты и не имеют достаточно времени для участия в проекте автоматизации, что приводит к срыву графиков проведения интервью, обучения и т. д., — считает Вадим Сидоренко, руководитель департамента систем управления предприятиями компании R-Style. — Чтение и согласование проектной документации практически всегда затягивается, особенно при выполнении проектов в госсекторе». 7. Технические проблемы. Тоже комплементарный риск — это могут
быть проблемы с аппаратным или программным обеспечением, на базе которого
реализуется проект, ошибки программирования (как технические, так и функциональные),
проблемы с интеграцией и т. д. Такие риски понятны, но важно, что эксперты
включили их в список наиболее опасных. |
Риски в цифровом формате
Классические западные методологии оценки рисков предполагают не только их описание (качественную оценку), но и количественные показатели. В каких случаях необходима количественная оценка риска, а в каких это не имеет смысла? У опрошенных нами экспертов нет однозначного ответа. Вадим Сидоренко, руководитель департамента систем управления предприятиями компании R-Style, уверен, что количественную оценку всех аспектов рисков ИТ-проектов сделать сложно, так в основном оценивается влияние рисков на сроки проектов. «Согласно теории чем выше степень неопределенности условий, в которых выполняется проект, тем выше степень необходимости количественного анализа рисков, — говорит Сергей Кошелев. — Что касается ИТ-проектов, то они, как правило, носят характер качественного улучшения и выполняются в условиях относительно низкой неопределенности. Другими словами, количественный анализ рисков для ИТ-проектов в большинстве случаев не является необходимым». Александр Гришин хотя и признает, что по некоторым рискам (например, из категории технических) можно с высокой точностью оценить объем финансовых и временных ресурсов, требуемых для их устранения (скажем, дополнительную оплату работы исполнителей в случае невыполнения графика работ; затраты на оборудование при несоответствии производительности параметрам, указанным в ТЗ), в целом скептически относится к перспективам такой оценки. «Количественную оценку большинства организационно-управленческих рисков для ИТ-проекта оценить так же трудно, как и его экономическую эффективность, — утверждает он. — Количественный анализ таких рисков требует значительного времени, а погрешность расчетов при этом будет очень велика. В целом можно сказать, что количественная оценка рисков для большинства ИТ-проектов не оправдывает потраченных усилий».
Однако у сторонников противоположного мнения тоже есть свои аргументы. Георгий
Дунаев обращает внимание на то, что количественный анализ рисков необходим для
оценки дополнительной трудоемкости проектных работ. «Не имеет смысла проводить
такой анализ при оценке внешних рисков, — советует Елена Шедова, директор по
маркетингу компании “Стерлинг Интеграция”. — Но для внутренних рисков мы рекомендуем
делать хотя бы приблизительные количественные оценки». Олег Зименков уверен,
что количественная оценка рисков необходима всегда. Даже проект, не преследующий
четко выраженных коммерческих целей, нужно выполнить в соответствии с принятой
спецификацией, вписать в рамки выделенного бюджета и уложиться в поставленные
сроки: «Бюджет, сроки и спецификация проекта — всё это вполне конкретные вещи,
которые могут изменяться в зависимости от возникновения того или иного риска.
И эти риски должны быть обязательно оценены». Владимир Новиков также считает
количественную оценку обязательной, поскольку она показывает стоимость риска
и помогает определить его значимость и важность.
Как правило, оценка делается в системе координат вроде «низкая — средняя — высокая».
Причем такую на первый взгляд качественную оценку очень легко перевести в качественно-количественные
показатели. Например, высокая вероятность проявления риска оценивается в 70
% и выше, или 3 балла, средняя — от 40 до 70 %, или 2 балла, низкая — менее
40 %, или 1 балл. Есть и другой критерий: если воздействие приведет к потере
менее 1 % бюджета или затянет сроки исполнения проекта менее чем на 5 % отведенного
времени, то его можно считать низким. Соответственно при 1—5 % бюджета и 5—10
% дополнительного времени — средним. Если бюджет превышен более чем на 5 %,
а сроки — более чем на 10 %, то высоким. Однако все эти оценки нельзя в полном
смысле слова назвать количественными, хотя для ранжирования рисков они дают
больше информации, чем чисто качественный анализ.
Следующий за этим вопрос — кто и каким образом должен оценить стоимость риска и шансы его возникновения? Стандартная практика российских предприятий здесь такова: это или собственный прогноз руководителя проекта, или обобщение мнений экспертов из числа сотрудников компании. Нередко на этом и останавливаются, однако не все эксперты такой подход считают достаточным. По мнению Олега Зименкова, наилучшего результата можно достичь, применяя комплексный подход. Например, эксперты компании на основании своего опыта могут получить вероятностный прогноз возникновения тех или иных рисков с оценкой конкретных последствий их наступления; потом на этот прогноз можно наложить оценку внешних экспертов.
Профилактика или лечение?
После оценки рисков предполагается составление плана ответа на них. Подобный план включает в себя способы реагирования на риски и пути их минимизации. Понятно, что чем больше вероятность возникновения риска или чем серьезнее его последствия, тем детальней должен быть проработан этот план. Но на что он должен быть ориентирован — на профилактику рисков или конкретные меры по реагированию на случившийся риск?
Елена Шедова обращает внимание прежде всего на профилактическую составляющую этого плана. «Наша компания проводила оценку рисков на одном из предприятий нефтегазовой отрасли перед началом проекта по внедрению mySAP Business Suite, — рассказывает она. — Наибольшим риском был вопрос низкой готовности компании к сотрудничеству. Мероприятия по снижению вероятности этого риска были запланированы следующие: создать рабочие руководящие комитеты, включающие представителей всех подразделений; сформировать координационную проектную группу из наиболее авторитетных представителей всех подразделений; довести цели и методику внедрения до заинтересованных лиц; вовлекать как можно больше пользователей на ранних этапах и на весь период осуществления проекта».
«Такой план представляет собой краткий перечень соответствующих мер, прежде всего профилактического характера, — соглашается Александр Гришин. — Однако для наиболее существенных рисков в него необходимо включать и меры, принимаемые в случае возникновения риска». По мнению Александра Савинова, руководителя направления бизнес-приложений компании «Крок», определить, что важнее — планировать профилактику или меры в случае наступления риска, — можно исходя из критичности непрерывности бизнеса. При внедрении информационных систем, поддерживающих критичные для бизнеса заказчика процессы (биллинг, банковские системы, логистика), вопрос обеспечения непрерывности их эксплуатации выходит на первый план. В таком случае разработать план мероприятий по реакции на случившийся риск недостаточно — риски надо предупреждать и действовать проактивно.
