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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• гибкость;

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

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

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

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

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

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

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

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