ноябрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

показать все 

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

Читать далее 

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

Читать далее 

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

Читать далее 

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

Читать далее 

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

28.09.2024

Чем страшен ИИ, и с чем его едят

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

показать все 

Главная / Архив номеров / 2016 / Выпуск №01 (54) / Риск-менеджмент, или Как управлять тем, что еще не произошло

Рубрика: Экономика ИТ-бизнеса

Алексей Лагутенков, MBA Kingston University UK, ITSM Manager, MCSE+I, MCSE:S:M, MCDBA, MCDST

Риск-менеджмент,
или Как управлять тем, что еще не произошло

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

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

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

Кроме этого, есть еще одна неприятность, о которой подробно рассказала г-жа Аншина [1]. ИТ-проекты отличает высокая степень изменчивости. В связи с этим руководитель отдела ИТ или CIO всегда находится под перекрестным огнем: с одной стороны, внедряемый проект необходимо довести до конца, дабы не прослыть неудачником и не поставить крест на своей карьере, с другой – высока вероятность, что проект к моменту завершения станет абсолютно бесполезен для бизнеса, поскольку могут измениться внутренние и внешние условия бизнес-среды.

Например, могут поменяться стратегия компании, структура бизнеса или даже состав лиц, заинтересованных в проекте. Поэтому даже в случае успешного внедрения CIO может стать «козлом отпущения», который виноват во всем. Еще бы: бизнес вложил в ИТ огромные деньги, а получил на выходе бесполезно-непонятную штуковину, которой вряд ли кто-то будет пользоваться. Кто виноват? Ясное дело – CIO, не CEO же.

Динамические методы управления ИТ-проектами, вроде SCRUM [2], хорошо работают на небольших и средних задачах. Если же проект слишком масштабный и подразумевает географическую протяженность, большой состав участников или долгий срок выполнения, то нужен воистину выдающийся лидер проекта, чтобы довести начинание до логического завершения.

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

Риск – это качественная или количественная оценка вероятности наступления некоего события, которое может произойти и причинить ущерб проекту или бизнесу. То есть риск – это не сама проблема или событие, а потенциальная угроза, которая может осуществиться, но точно так же может никогда и не осуществиться. Концептуальное отличие риска от проблемы заключается в том, что проблема возникает в настоящем, риск же всегда существует только в будущем.

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

Важно помнить, что вероятность возникновения неприятности в результате некоего изменения никогда не равна 100%. Если в результате каких-то действий с вероятностью 100% возникает прогнозировавшаяся проблема, то речь идет не о риске, а о том, что называют «ограничением» или «препятствием» для внедрения проекта. Ограничения и препятствия не имеют к риску никакого отношения.

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

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

Рисунок 1. Как изменяется вероятность и стоимость реализации рисков во время жизненного цикла проекта

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

Управлением рисками заведует стандарт ISO/IEC 31010:2009, а также разделы ITIL Continuity и Change Management. В этой статье мы будем отталкиваться в основном от определений, которые заданы стандартом ISO, по причине большего их соответствия теме разговора.

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

Чтобы научиться работать с рисками, можно действовать, например, в такой последовательности:

• Категоризировать, какие вообще бывают риски. Что и с какой стороны потенциально может угрожать проекту? Идентифицировать и проанализировать потенциальные риски в выбранных категориях.
• Разработать общую стратегию реагирования и конкретный план действий в ответ на каждый конкретный риск.
• На регулярной основе проводить анализ возникновения новых рисков, их влияния на проект и бизнес компании. На основании проведенного анализа вносить изменения в стратегию и план реагирования на риски.

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

Категоризация, идентификация и анализ рисков

Для того чтобы разделить риски на категории, обычно не требуется ничего, кроме здравого смысла. Категоризация нужна исключительно для того, чтобы понять, из какой предметной области проекту или бизнесу может что-либо угрожать и нанести ущерб. С точки зрения официального текста ISO/IEC 31010:2009, к этому этапу относят пункт 4.3.2 «Обмен информацией и консультации», а также пункт 4.3.3 «Установление области применения менеджмента риска».

Рисунок 2. Процесс управления рисками

Существует несколько подходов к категоризации.

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

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

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

Кроме того, стандарт ISO/IEC 31010:2009 рекомендует к использованию 24 различных методики идентификации рисков. Они отличаются прежде всего наличием или отсутствием возможности получения количественных данных, а также самим способом, с помощью которого происходит идентификация рисков. Например, «методы наблюдения» включают в себя заполнение контрольных листов (вопросников) и предварительный анализ опасностей. Другие методики оценки содержат «вспомогательные методы», «анализ сценариев» и «функциональный анализ». Все желающие получить более подробную информацию могут обратиться напрямую к тексту документа ISO/IEC 31010:2009.

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

• риск взаимодействия с клиентом – риск, связанный со сложностями общения разработчика и пользователя проекта;
• риск изменения среды внедрения – технологический риск, связанный с глобальным и масштабным изменением среды работы предприятия. Например, когда вместо продуктов Microsoft на предприятии планируется внедрить решения, основанные на Linux, или наоборот;
• риск чрезмерной новизны – внедряемый продукт имеет непривычные, непонятные для пользователей свойства или интерфейс;
• риск количества и квалификации персонала возникает в случае неправильной оценки требуемого количества или квалификации персонала, участвующего во внедрении проекта.

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

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

Допустим, нам удалось перечислить все возможные, с нашей точки зрения, риски для проекта. После этого согласно тексту ISO/IEC 31010:2009 и пункту 4.3.4 «Оценка риска» риски следует оценить.

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

• не принимаемые в расчет (англ. negligible);
• несущественные (англ. marginal);
• критические (англ. critical);
• катастрофические (англ. catastrophic).

Теперь можно приступить собственно к анализу. В качестве примера используем одну из рекомендованных ISO методик: «Анализ видов и последствий отказов» (англ. Failure Mode and Effect Analysis – FMEA)». Выбор в пользу этого инструмента сделан на том основании, что в случае оценки ИТ-проектов данная модель позволяет использовать визуально простое матричное представление рисков.

Предположим, мы трудимся над довольно простым проектом разработки и создания некоего программного обеспечения, которое предстоит внедрить у заказчика. Проведем анализ рисков по методике FMEA. Нам удалось установить, что рисками могут потенциально являться:

• нефункциональный интерфейс;
• отказ сервера или сетевого оборудования;
• зависания программы с потерей данных;
• неудобство пользования программой и недовольство пользователей по этому поводу.

Введем три фактора анализа:

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

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

 Таблица 1. Оценка риска по методике FMEA

Теперь, чтобы получить значения риска, просто перемножим значения в каждой строке таблицы 1, то есть (см. таблицу 2):

Таблица 2. Оценка серьезности рисков

Риск = Степень ущерба × Вероятность возникновения × Сложность обнаружения

Стратегии управления рисками

Итак, все риски выявлены и оценены. Что делать дальше? Наступает время разрабатывать стратегию реагирования на риски. Вообще говоря, существует всего два подхода к управлению чем-либо. Они называются «реактивный» и «проактивный».

Реактивный подход подразумевает реагирование на ситуацию post factum. То есть никто не предпримет никаких шагов по предотвращению риска, пока что-то не пойдет не так. Если же проблема случилась, то ответственные за принятие решений люди пытаются исправить негативные последствия быстро, так сказать «на лету». Большинство программных команд и менеджеров полагаются на этот подход.

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

Говорить о какой-либо стратегии в рамках реактивного реагирования на риски не имеет смысла. Все стратегические маневры сосредоточены преимущественно в проактивной области.

Всего существует четыре стратегии реагирования на риски:

• «снижение риска»,
• «устранение риска»,
• «передача риска»,
• «принятие риска».

Рассмотрим каждую из стратегий более подробно.

Снижение риска (англ. Mitigating Risk)

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

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

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

Устранение риска (англ. Avoiding Risk)

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

Передача риска (англ. Transferring Risk)

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

Принятие риска (англ. Retaining Risk)

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

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

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

План реагирования на риски

Специально для разработчиков программного обеспечения создан документ, называемый RMMM [3] или «Риск: снижение, мониторинг, управление» (англ. Risk Mitigation, Monitoring, and Management Plan). Однако этот документ можно смело применять к любому ИТ-проекту, не только к разработке программного обеспечения.

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

Как составляется RMMM? Жесткого стандарта, однозначно определяющего содержание документа, нет. Один из вариантов – это, например, таблица с пятью столбцами, где описаны источник риска, способ снижения или избегания риска, план действий на случай реализации риска, по какому событию следует запускать план реагирования на риск (триггер), а также указан конкретный человек, ответственный за исполнение плана реагирования.

Вернемся к примеру, рассмотренному ранее, и составим для него план реагирования на выявленные риски.

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

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

Таблица 3. План реагирования на риски

Поэтому третий шаг в управлении рисками – это регулярный анализ возникновения новых рисков и изменение RMMM в соответствии с новыми условиями бизнес-среды. Достаточно формализованный подход к такого рода деятельности подробно прописан в разделе «Управление изменениями» ITIL (англ. Change Management). К сожалению, в рамках этой статьи невозможно уделить достаточное внимание этой области знаний.

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

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

1. Аншина М. Не меняйте проекты, как перчатки. Часть 1. Определение проектов ИТ, их особенности и место в деятельности организаций. // «БИТ», №3, 2015 г. – С.46-49 (http://bit.samag.ru/archive/article/1472).
2. Scrum. Материал из Википедии – свободной энциклопедии – https://ru.wikipedia.org/wiki/Scrum.
3. Roger S. Pressman. Software Engineering a practitioner’s approach. – 2001, McGraw-Hill Higher Education, p.159.

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи