Сергей Авдошин - Информатизация бизнеса. Управление рисками

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

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

На верхнем уровне детализации веса определяются путем экспертной оценки (табл. 8).

Таблица 8.

Пример распределения доли критериев

Требования могут отличаться по значимости и ранжироваться по приоритетности на три группы: «Критично», «Важно», «Желательно» (табл. 9). На основе этого каждому требованию присваивается вес в общей оценке (табл. 12). Для определения весов для оценки требований необходимо согласовать их приоритетность. Наименьший вес принимается за единицу, следующая категория присваивается группе критериев с условно в два раза большей значимостью и т. д. Веса рассчитываются на основе единиц относительной значимости. Сумма весов должна быть равна 100 %.

Таблица 9.

Приоритеты требований

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

Среди функциональных критериев по выбору системы управления ИТ-рисками могут быть следующие:

• хранение данных в справочниках: риски, рисковые события, бизнес-процессы, классификаторы, статусы рисков;

• ведение единого реестра рисков;

• использование иерархии классификации;

• формирование отчетов и графических форм;

• открытость системы для дальнейшего развития и интеграции с другим ПО;

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

• механизм автоматической генерации уведомлений по электронной почте;

• возможность внесения изменений в систему с учетом пожеланий заказчика.

Могут существовать функциональные требования для связывания рисков и рисковых событий, факторов риска и бизнес-процессов.

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

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

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

Вне зависимости от выбранного типа решения программный продукт по управлению рисками в ИТ-проекте должен отвечать сформулированным требованиям и выполнять основные задачи управления рисками за счет:

• функций системного автоматизированного подхода в области управления рисками ИТ-проекта;

• механизмов анализа рисков с применением современных статистико-математических методов;

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

• механизмов автоматического мониторинга эффективности системы управления рисками;

• реализации сводной аналитической отчетности по управлению рисками в режиме реального времени.

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

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

При выборе следует обратить внимание на три фактора: сроки внедрения, качество внедрения, стоимость внедрения.

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