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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• гибкость;

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

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

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

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

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