Методические принципы управления рисками в области автоматизации бизнеса часто заимствуются ИТ‑руководителями сразу из нескольких источников, многими из которых пользуются только в ИТ-подразделениях. В дополнение к этому содержательная специфика его работы может приводить к тому, что сама дисциплина Risk Management в ИТ и в бизнесе воспринимается несколько по-разному. О нюансах, возникающих вследствие этих различий, мы беседуем с директором департамента внутреннего контроля и управления рисками компании «Энергостройинвест-Холдинг» Константином Рычаговым.
Intelligent Enterprise: Прежде всего хотелось бы понять, что представляет собой управление рисками, если рассматривать эту дисциплину как кросс-функциональную, используемую во многих направлениях бизнеса, равно как и при управлении деятельностью компании в целом.
Константин Рычагов: Данная дисциплина на сегодняшний день уже довольно глубоко проработана методически и при этом широко используется на практике. У нас, как, впрочем, и во многих других компаниях, в качестве основы используется хорошо известная во всем мире методика COSO ERM. Глубоко вдаваться в нее в контексте нашего разговора вряд ли имеет смысл. Скажу лишь, что управление рисками — это некий универсальный инструмент, который можно применять на всех этапах цикла производства конечного продукта компании. Не менее важно, что процесс управления рисками включает в себя несколько видов деятельности. Это выявление рисков, их оценка, разработка и реализация мероприятий по снижению их влияния, мониторинг запланированной активности и, наконец, оценка результатов. По сути все это означает, что в сферу управления рисками действительно оказывается вовлечено множество подразделений компании. Некоторые их них имеют постоянное отношение к данным вопросам, и для них Risk Management — фактически непрерывный процесс. Некоторые подключаются на определенных этапах тех или иных проектов. Но все активности внутри компании неизменно связаны: скажем, наработки, сделанные каким‑либо подразделением на более раннем этапе, становятся входной информацией для другого подразделения и так далее.
Получая документацию для участия в проекте, наши маркетологи должны провести анализ основных его параметров: территориальное расположение будущего строительного объекта, проработанность технического задания на предмет ошибок, сроков реализации и пр. Сами сотрудники отдела маркетинга в данном случае выступают скорее некими драйверами процесса, привлекая к аналитической работе профильных специалистов тех или иных подразделений. В итоге такой коллективной деятельности для каждого тендера, в котором наша компания принимает участие, появляются некие профили рисков. Они, в свою очередь, являются исходной информацией для принятия принципиальных решений относительно участия в проекте, а также ориентиром для проактивной деятельности, направленной на минимизацию негативных с точки зрения бизнеса последствий и соответственно максимизацию экономического эффекта. Если тендер выигран и работы начались, менеджер проекта уже имеет входную информацию в виде некоторой предыстории вопроса и сложившегося перечня рисков. Вместе с тем он может расширять карту рисков, что фактически и делает.
Надо отметить также, что перечень рисков не являет собой нечто статичное. Некоторые из них по ходу работ снимаются, некоторые, наоборот, возникают. Соответственно меняется и состав специалистов, вовлеченных в соответствующую работу.
В среде ИТ‑специалистов часто звучит выражение «ИТ-риски». Насколько этот термин, по сути призванный отражать некую функциональную специфику рисков, с вашей точки зрения вообще имеет право на существование и насколько он важен для бизнеса?
Я думаю, к названию некоторых рисков вполне можно добавлять префикс ИТ-. По крайней мере это будет корректно. Но с другой стороны, их совокупность — это не какое‑то отдельное пространство, а те же риски, которые мы отображаем на карте и которые явным образом связаны с выполнением каких‑либо работ. На самом деле, я думаю, все очень просто: там, где в бизнесе становятся значимыми информационные технологии, сразу появляются и ИТ-риски. И чем более критичную роль играют ИТ в бизнесе в целом или на каких‑то этапах работ, тем более значимыми являются и ИТ-риски. Существуют, как известно, компании, чей бизнес очень зависит от ИТ. Там ИТ-риски оцениваются в первую очередь. В нашей ситуации, когда мы, допустим, говорим о проектировании какого‑то строительного объекта, все хорошо понимают, что само проектирование практически от начала и до конца ведется в информационной системе. Отсюда — серьезное внимание к функциям соответствующих ИТ‑систем, к оборудованию, на котором они работают, а также к осуществляемой поддержке и того и другого. Из анализа всего этого и складывается карта рисков.
Если же мы говорим непосредственно о строительных работах, то здесь на большинстве стадий строительства ИТ-риски могут вовсе отсутствовать. Но, напомню, карта рисков динамична, и они могут появляться (и действительно появляются) на этапе, когда строительный объект оборудуется некой инженерной инфраструктурой или системами безопасности. И возникают эти риски опять‑таки благодаря тому, что в проекте начинают явным образом присутствовать информационные технологии. В данном случае, скажем, в виде систем автоматического контроля и управления неким специализированным оборудованием.
Формально мы обязаны учитывать ИТ-риски и там, где речь идет, например, об электронном документообороте. Даже в том случае, если система электронного документооборота работает стабильно и уровень поддержки довольно высок, такой риск тем не менее также рассматривается и оценивается.
В качестве еще одного примера приведу внутренний для компании проект переезда в новый офис. В подавляющем большинстве случаев переезд означает и физическое перемещение (хотя бы частичное) ИТ-инфраструктуры. Здесь ИТ-риски оцениваются специфическим образом, но, как правило, оказываются очень значимыми.
Если, как вы сказали, различные специалисты динамично привлекаются к работе по управлению рисками на разных этапах проекта, то, очевидно, это относится и к ИТ-направлению. Интересно знать, насколько методически отлаженным является такое подключение. Ведь во многих ИТ-подразделениях компаний по сути нет выделенного направления в сфере Risk Management, а в тех, где оно существует, специалисты могут пользоваться совсем иными методиками, более популярными в ИТ‑среде…
Во-первых, я думаю, лучшим вариантом для любой компании будет тот, при котором в ней описаны процессы. А из этого описания, в свою очередь, становится ясной роль ИТ-подразделения и степень его участия на той или иной стадии проекта. Многое зависит также от типа проекта. Я уже говорил о двух типах, связанных со строительными работами и с работами в области проектирования. Они предполагают качественно различное участие ИТ, и степень значимости в них составляющей, связанной с информационными технологиями, также существенно разная. Таким образом, и подходы к оценке и управлению ИТ-рисками окажутся далеко не одинаковыми. Существуют внутренние по отношению к деятельности компании проекты, которые тоже можно подразделить на различные типы. Однако все это скорее некоторые предусловия, необходимые для того, чтобы грамотно вписать ИТ‑службу (как, впрочем, и другие подразделения) в общее направление Risk Management.
Что же касается стыковки работ непосредственно в области управления рисками, то во многих подразделениях нашей компании есть так называемые координаторы по управлению рисками, и именно через этих людей решаются соответствующие вопросы. Существуют такие сотрудники и в ИТ‑службе. Если на определенном этапе необходимо привлечь к участию ИТ-подразделение, то этим занимается либо сам ИТ-директор, либо эксперт ИТ‑департамента, если таковой имеется. Они анализируют проектную документацию и либо утверждают ее без изменений, либо вносят в нее мероприятия, необходимые для минимизации ИТ‑рисков и расходов на ИТ. И соответственно за вносимые изменения отвечают.
У нас в компании довольно четко регламентирована вся эта деятельность, от описания бизнес-процесов и классификации проектов до выделения центров финансовой ответственности в разных подразделениях (и в составе ИТ‑департамента в том числе). Соответственно мы можем говорить о технологичной процедуре подключения ИТ‑службы к работе по управлению рисками. То есть о такой процедуре, которая предполагает решение исключительно содержательных вопросов конкретного проекта.
Представляется, что в своей работе по оценке рисков, если таковая и проводится, ИТ-подразделение исходит из вполне определенного, довольно ограниченного и в общем стабильного набора параметров, таких как надежность функционирования ИТ-инфраструктуры или доступность информационных ресурсов. Можно предположить, что они далеко не всегда совпадают с целевыми показателями, с которыми работает бизнес. Не создает ли такая ситуация известных барьеров в совместной работе?
Да, действительно, направления развития, на которых часто фокусируется ИТ-подразделение, да и саму терминологию, принятую в этой связи в ИТ, можно признать специфичной. Работая в том числе и над вопросами минимизации рисков, оно часто делает заметный акцент на вполне определенных терминах и понятиях. Наряду с уже названными характеристиками надежности и доступности ИТ‑сервисов я могу, например, назвать выполнение требований регулирующих органов или, скажем, обеспечение непрерывности бизнеса. Характерно, что даже сами термины говорят о том, что заботы ИТ в данном случае безусловно сосредотачиваются на решении не технологических, а бизнес-проблем. Большим преувеличением было бы утверждать, что все эти понятия чужды бизнесу. Ничуть нет. Просто, во‑первых, объективная ситуация такова, что последствия ИТ-рисков не всегда понятны бизнесу, а во‑вторых, рассматриваются они иногда в несколько иной системе координат. Для наглядности приведу примеры. Если мы, скажем, говорим о нарушении лицензионных соглашений, то бизнесу далеко не ясны ответы на вопросы, что будет, если такое нарушение выявится. И кем оно будет обнаружено? И как фиксировать факт обнаружения? Как вообще его будут искать? А без ответов на них адекватно управлять рисками сложно.
Зрелые подходы в Risk Management безусловно предполагают работу со всеми рисками в неком едином пространстве, что позволяет корректно сравнивать их, в какой бы конфигурации они ни проявлялись совместно. Если в той или иной компании пока не наработана достаточная практика учета специфики ИТ-рисков, если работа с этим типом рисков не ведется вовсе или ведется обособленно, то бизнесу непросто бывает положить на одну чашу весов тот же лицензионный риск использования программных систем и риск сокращения портфеля заказов, скажем, на 20 процентов. И руководителей здесь вполне можно понять.
Еще один, может, не самый важный, но показательный пример разного понимания схожих факторов состоит в следующем. Для нашего бизнеса при оценке рисков по понятым причинам имеет значение территориальное расположение строительного объекта. От этого зависит, какие технологии будут применяться, какова стоимость строительства, как будут доставляться материалы и пр. Это соответственно отражается на структуре оцениваемых рисков. А для ИТ-подразделения, напротив, само по себе территориальное расположение инфраструктуры, которая служит основой для предоставления ИТ‑сервисов, вовсе не имеет никакого значения. Хотя существенную роль могут играть факторы, как правило, сопутствующие территориальному перемещению инфраструктуры.
Важно отметить, что очень часто тем проблемам, которые должна решать ИТ‑служба, присуща явная специфика, и направления Risk Management это тоже касается. Например, складываются ситуации, когда ИТ-риски не до конца понятны специалистам других подразделений. Иногда даже трудно подобрать корректные аналогии данных рисков из предшествующей практики работы компании. То есть те аналогии, на основе которых можно было бы объяснить ситуацию.
В результате сегодня могут, скажем, очень остро стоять проблемы оценки рисков, связанных с нелегальным использованием программного обеспечения, о которых я уже говорил. В силу вышесказанного бизнесу, может быть, далеко не очевидно и то, что уже, например, вполне созрела необходимость заменить часть ИТ-инфраструктуры, хотя сегодня она, казалось бы, вполне справляется со своими задачами. А замена ее на новую, мягко говоря, окажется для компании далеко не бесплатным удовольствием. Подобная позиция, кстати, хорошо иллюстрирует стойкую привычку бизнеса всё оценивать мерилом финансовых показателей, что, в общем, не всегда корректно. В области Risk Management уж по крайней мере.
И каким вам видится выход из этой ситуации?
Конфликт интересов возникает из‑за разности оценочных шкал. У ИТ‑службы эта шкала действительно во многом своя, и в самой общей постановке задача состоит в том, чтобы шкалы эти сблизить.
Я думаю, что по мере развития самого направления ИТ-поддержки бизнеса одинаковое понимание ряда вещей будет достигаться неминуемо. Из конкретных шагов к этому взаимопониманию мне представляется важным выход бизнеса за пределы пространства финансовых показателей. В некоторых производственных отраслях (например, в сложном машиностроении) нередко существуют участки, финансовый оборот от деятельности которых очень невелик. Иногда они могут быть и вовсе убыточными. Тем не менее на этих участках изготавливаются детали или производятся операции, которые абсолютно необходимы для создания конечного изделия. Возникают в бизнесе и такие ситуации, когда те или иные ресурсы, формально относящиеся к убыточному участку и согласно формальной оценке порождающие лишние расходы, в реальности обслуживают прибыльные направления бизнеса. И могут даже оказаться для них ключевыми.
Все это примеры той ситуации, когда одной финансовой оценки проекта оказывается недостаточно. Более того, игнорирование значимости того или иного фактора по существу и вовсе может приводить к катастрофическим последствиям. Мне представляется, что более глубокое осознание бизнес-руководством нефинансовых факторов по мере развития более сложной и разнообразной производственной деятельности просто неминуемо, и это сам по себе позитивный фактор. В том числе и в контексте упомянутой проблемы взаимопонимания при оценке рисков.
Важно также и повышение общей культуры ведения бизнеса. Мы можем снижать риски производственного травматизма, чтобы минимизировать число и размер денежных компенсаций работникам. А можем при той же постановке вопроса исходить из того, что человеческая жизнь бесценна, и пытаться создавать такие условия труда, при которых серьезные производственные травмы практически исключены. Если вопросы в компании рассматриваются в такой постановке, то гораздо более адекватно будут восприниматься и уже упоминавшиеся риски, связанные с непрерывностью бизнеса, с выполнением требований регуляторов или же с соблюдением лицензионных соглашений по использованию ИТ-продуктов. Они в свою очередь если и могут быть выражены в финансовых показателях, то эта оценка часто далеко не полная. К тому же данные риски, так же как и в приведенном примере с безопасностью условий труда, связаны скорее с превентивными мерами, с формированием позитивного имиджа предприятия, чем с расчетом вероятности возникновения конкретных событий, влекущих за собой штрафы и иные выплаты.
Подытоживая сказанное, отмечу, что в решении задачи сближения оценочных шкал бизнес и ИТ‑служба должны идти навстречу друг другу. Иными словами, речь здесь не только о том, чтобы ИТ-отдел научился лучше понимать бизнес, но и о некоторой трансформации взглядов самого бизнеса.
Если говорить о нынешней ситуации, то сегодня выгодно проведение таких ИТ-проектов, которые сочетают в себе получение комплексного результата. Результата, позволяющего минимизировать риски, объективное восприятие значимости которых со стороны бизнеса сегодня отчасти затруднено, — но при этом демонстрирующего выгоду в традиционных и абсолютно понятных бизнесу показателях. Так, в нашей компании некоторое время назад был успешно завершен внутренний проект в сфере оценки и классификации ИТ-активов. Благодаря этому на будущее по сути сняты риски, связанные с прямым нарушением или даже с некорректным применением лицензионных политик, и получен понятный и прозрачный бизнес-результат: сокращены затраты на ИТ.
Работа в сфере Risk Management очень тесно сопряжена с количественной оценкой событий, часто имеющих к тому же вероятностную интерпретацию. При этом известно, что проведение количественных оценок таких параметров, как доступность и надежность работы ИТ‑сервисов с технической точки зрения, часто не является сколь‑либо существенной проблемой. А вот как отобразить эти расчеты на некой шкале, характеризующей эффективность решения бизнес-задач, это уже представляется не столь тривиальным делом.Могут ли здесь быть скрыты какие‑то проблемы?
Проблема получения количественных оценок в практике управления рисками действительно стоит весьма остро. Могу сказать, что посчитать ущерб в результате невыполнения обязательств довольно просто. Наша компания (да и многие другие, разумеется, тоже) располагает квалифицированными и опытными специалистами, которые в состоянии оценить, скажем, сроки и стоимость строительства объекта, а также выделить все те независимые факторы, которые на это могут повлиять. Грозящие нам штрафные санкции при этом тоже известны, в том числе и количественно.
С вероятностной оценкой сложнее, по крайней мере в нашем бизнесе. Хотя такая оценка в принципе востребована. У нас, скажем, нет неких заранее заданных параметров, которые существуют в том же машиностроительном производстве и которые могли бы с успехом использоваться в сфере управления рисками. Речь, например, идет о выражаемых в часах известных параметрах наработки того или иного оборудования на отказ или о среднем времени между проведением профилактических ремонтов. По понятным причинам затруднена у нас и получающая все большее распространение практика, аналогичная оценке вероятности выхода оборудования из строя, основанная на реальном контроле его технического состояния. Поэтому в нашем бизнесе полный переход от экспертной оценки к модели неких математических расчетов по исходным данным очень сложен. Хотя сама подобная оценка, повторю еще раз, востребована, и технические параметры той же надежности работы информационных систем могут быть адекватно учтены в оценке рисков.
В нашем случае мы посчитали, что на нынешнем этапе управления рисками их можно оценивать на основе мнений экспертов. На базе этих оценок в свою очередь целесообразно производить количественные расчеты. Чтобы получать от экспертов ответы в желаемом формате, мы используем специально сформулированные вопросы, которые предполагают ответы не в виде общих (пусть даже продуманных и ответственных) заявлений, а в виде конкретных сообщений о возможности негативных событий и их причинах. Расхождение данных количественной оценки, полученной по результатам их ответов, с теми, которые характеризуют истинную вероятность, по нашим оценкам не превышает 20 процентов. Пока такой результат нас вполне устраивает.
Насколько система управления рисками сопряжена с другими управленческими методиками, развиваемыми в компании? В частности, хотелось бы услышать о культуре использования численных показателей (в том числе как раз и нефинансовых) в управлении бизнесом, которая, как известно, связана не только с Risk Management…
На мой взгляд для большинства российских компаний (за некоторым исключением) первым шагом внедрения системы управления рисками является построение и описание процессов. Выделение финансовой ответственности, система классификации проектов (о чем я говорил раньше) наряду с самой концепцией Project Management как таковой тоже по сути являются методиками, смежными с Risk Management. Что касается культуры работы с численными показателями, то опираясь по крайней мере на опыт работы нашей компании, я бы не сказал, что их развитие повышает зрелость использования методов управления рисками.
Практика показывает, что преждевременное внедрение ряда ИТ‑систем, работа с которыми явным образом предполагает довольно резкий переход к использованию количественных оценок, менеджерами на местах воспринимается в штыки. Скорее я бы даже говорил об обратном эффекте, когда зрелые подходы в сфере Risk Management становятся своего рода локомотивом для более широкого использования таких систем. А именно о том, когда при внедрении системы управления рисками в течение длительного периода времени накапливаемая информация становится открытым достоянием менеджмента компании, когда становится очевидно, что эта информация (в том числе представленная в формате количественных показателей) начинает служить основой для непрерывного улучшения ее деятельности, происходит и изменение профессионального менталитета руководителей. И соответственно возникает четко очерченная потребность в более точных, разнообразных и обоснованных показателях.
