Информатизация бизнеса. Управление рисками

Глава 8 Обзор информационных систем управления рисками

8.1. Требования к информационной системе управления рисками

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

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

Критериями выбора системы могут выступать следующие категории требований:

• информация о поставщике и продукте;

• функциональные требования;

• технические требования;

• цены и условия.

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

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

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

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

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

• технологичность решения;

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

• модульность;

• гибкость;

• масштабируемость;

• архитектура и техническая платформа;

• операционная среда и СУБД.

Цены и условия содержат оценку стоимости покупки (лицензии), внедрения и поддержки системы управления рисками с учетом приведенного примера количества пользователей.

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

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

Рис. 25. Пример портфеля критериев по выбору программного продукта

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

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

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

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

Таблица 8.

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

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

Таблица 9.

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

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

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

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

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

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

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

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

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

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