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

Intelligent Enterprise: Разговоры об управлении рисками неизменно напоминают рассуждения о колдовстве: дело явно важное, но как работает — непонятно.

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

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

Каким образом действуете вы сами?

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

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

Затем идут проектные риски: соблюдение сроков и бюджета, реализация намеченной функциональности. За ними — функ­циональные: риск того, что в результате внедрения не будет реализован намеченный функционал. Может быть неверно оценен объем проекта изначально, а может уже в процессе внедрения потребоваться реализация какой-либо особенности. Система не будет делать то, что надо, в какой-то мере. Эту меру мы и пытаемся оценить. Кроме того, данный конкретный проект связан обычно с другими, и если в нем что-то не заработало, это может повлечь далеко и широко идущие последствия, которые тоже можно оценить.

Типовая ситуация известна: на проект А выделяется человек. Постепенно на него навешивают задачи проектов B, С, D, и очень скоро менеджер проекта А видит, что при 100%-ной загрузке этого специалиста он может располагать им всего на 20%. Это тоже надо учитывать. Людей очень трудно поделить.

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

Риски, связанные с заводом, в первую очередь касаются персонала. Любое внедрение — это что-то новое, а мы не всегда готовы это новое принять. В Западной Европе на заводах и забастовки, бывает, устраивают, если рабочим что-то не нравится. Именно забастовки — по любым поводам — рассматриваются в этом случае как основной опасный фактор.

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

Как вы классифицируете аварии?

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

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

Как же это случилось?

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

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

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

План, который вы разработали, действительно был известен исполнителям?

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

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

Все такие риски мы называем Project Common. Дальше делим по процессам — на ситуации, которые касаются только одной какой-либо области. Производство и склад, продажи и дистрибуция, финансы и контроллинг, HR. Это уже разбивка по командам и модулям SAP. В каждом модуле есть свои риски, но обычно они уже менее критичны и не столь затратны.

Как в целом в вашей компании выглядит управление рисками?

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

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

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

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

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

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

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

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

Какой реальный эффект вы наблюдаете от всей этой деятельности?

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

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

Насколько детально вы углубляетесь в своих оценках?

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

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