Ирина Пирогова, «Илим Палп Энтерпрайз», Весомость риска – понятие скорее интуитивное.

В «Илим Палп Энтерпрайз» на опыте нескольких проектов внедрения информационных систем разработана своя схема анализа проектных рисков. О том, как ИТ-подразделение компании пришло к необходимости применения этой схемы, и об опыте ее использования рассказывает Ирина Пирогова, директор по информационным технологиям «Илим Палп Энтерпрайз»

Intelligent Enterprise: Как ваша компания пришла к необходимости анализа проектных рисков?

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

Следующим проектом у нас стало внедрение системы Scala, и мы окончательно осознали, что выделенные нами риски — это действительно те «грабли», на которые мы наступаем снова, они есть во всех наших проектах. Перед проектом мы пересмотрели приоритетность рисков. Помогло ли это нам? Да, помогло: «выстрелил» один очень серьезный риск — недостаточный уровень консалтинга со стороны компании Scala. Именно то, что мы «мониторили» основные возможные риски, в том числе и этот, и помогло нам вовремя принять необходимые меры — ещё до момента, когда он принес бы серьезные убытки. Таким образом еще раз подтвердилось, что вероятность возникновения риска — величина непостоянная и имеет смысл не просто на старте проекта взять и перечислить все возможные риски, отранжировав их по значимости и степени вероятности, но и, главное, вести оперативный контроль за ситуацией, точнее, за изменением вероятности наступления того или иного риска.

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

Какие риски, на ваш взгляд, являются наиболее серьезными при внедрении КИС?

Технические, связанные с выбором системы и поставщиков. Они наиболее серьезны и могут сказаться на всем ходе проекта и на его результатах, поэтому должны быть минимизированы на самой ранней стадии, еще при подготовке проекта. Хотелось бы отметить методологические риски — в том числе затягивание этапа описания бизнес-процессов, а также отсутствие четкости в постановке задач проекта и его основной цели. Влияние этих параметров на качество внедрения очень высоко. Большим риском является также отсутствие реальной методологии внедрения у компании-внедренца или, так тоже бывает, реального воплощения в жизнь декларируемой методологии: только в последнем проекте по внедрению ERP-системы SAP мы видели у консультантов не просто методологию, заявленную на бумаге, а действительно аккуратное следование ей, использование наработок. Предыдущие поставщики — Scala и Baan — к сожалению, сколь-нибудь серьезной методологии внедрения нам не предоставили. Увы, мы это осознали только в ходе проектов.

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

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

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

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

Сейчас мы ведем переговоры о привлечении к проекту третьей стороны — для независимого контроля качества исполнения. Эти люди нам нужны для того, чтобы представить независимое мнение о ходе проекта руководству. Кроме того, они могут в случае необходимости адекватно определить и донести, насколько высок риск опасного разрастания его рамок. Могут они выступить и третьей стороной в спорной ситуации между заказчиком и консультантом-внедренцем, например, решить спор, достигнуты ли цели проекта по его окончании. Подобные случаи, к сожалению, тоже бывают.

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

Имеет ли смысл при анализе проектных рисков применять количественные показатели — весовые коэффициенты, показатели вероятности?

Надо отдать должное консультантам, они ранжируют риски, расставляют коэффициенты, но на мой взгляд — это все «от лукавого». Сложность и весомость риска — понятия скорее интуитивные.

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

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

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

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

Насколько серьезным риском вы считаете потерю интереса со стороны топ-менеджмента?

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

С этим риском тесно связан другой — недовольство пользователей новой системой. ERP-система, как правило, сильно отличается от того, к чему привыкли пользователи. Раньше при работе с «самописными» системами ИТ-служба по первому требованию «подстраивала» систему под них. С ERP-системой все наоборот, это уже пользователям приходится подстраиваться под систему. Обычно, особенно в первое время, это вызывает недовольство, которое сотрудники обязательно будут доносить до руководства. Если топ-менеджмент заинтересован в результатах проекта и эти результаты достигаются, то временное неудовольствие пользователей для него отходит на второй план. Но если у руководителей нет особого интереса к проекту, они с удовольствием будут прислушиваться к крикам снизу. Так что эти два риска — потеря интереса менеджмента и проблемы адаптации пользователей — тесно связаны между собой.

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

Пути минимизации некоторых рисков при внедрении КИС, разработанные в «Илим Палп Энтерпрайз»

Кто в компании может проанализировать проектные риски? Надо ли привлекать к этой оценке представителей других отделов помимо ИТ-департамента?

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

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