В задачи риск-менеджера входит постоянное наблюдение за организацией работы ИТ-проекта. Риск-менеджер идентифицирует рабочие процессы, устанавливает последовательность и взаимодействие, определяет критерии оценки и методы контроля деятельности, анализирует ход работ и проектные документы в целях идентификации рисков.
Основные функции управления рисками риск-менеджера (подразделения УР):
• разработка политики по управлению рисками;
• разработка, тестирование методов и моделей оценки рисков;
• разработка и/или выбор методологии;
• координация процесса управления рисками;
• взаимодействие с внутренними службами;
• управление портфелем рисков и оценка совокупного риска ИТ;
• создание и ведение базы данных и информационное обеспечение;
• доведение результатов оценки и управления рисками до высшего руководства компании.
Для риск-менеджера важно быть хорошим аналитиком, уметь быстро и правильно разобраться в ситуации, доверять своей интуиции и брать на себя ответственность за предложенное решение или действие.
Наличие риск-менеджера не исключает участия всех участников проекта в управлении рисками. Фактически каждый участник ИТ-проекта управляет рисками, связанными с ИТ. Риск-менеджер координирует и объединяет их усилия.
Так, руководство (управляющий комитет) обеспечивает создание контрольной среды и регулярную проверку статуса работ, осуществляет постановку целей, задание контрольных параметров, выполняет контроль наиболее важных рисков и общий контроль за эффективностью системы управления рисками. Усилия функциональных подразделений в процессе риск-менеджмента направлены на управление бизнес-рисками в своей области и следование общей методологии. Основные компетенции участников ИТ-проекта в области управления рисками – это реализация поставленных руководством целей, поддержание рисков в заданных рамках, участие в организации системы управления рисками, обеспечение руководства и заинтересованных лиц информацией по проекту. Внутренний аудитор выполняет оценку эффективности системы и формирует важные рекомендации по усовершенствованию системы.
На специалиста в области управления рисками возлагается ответственность за каждодневную реализацию программы управления рисками и повышение уровня осознания важности вопросов риск-менеджмента внутри проекта. Он должен осуществлять не только ежедневный мониторинг состояния дел, но и обмениваться опытом и суждением с другими структурными подразделениями.
Наиболее важными квалификационными составляющими для занятия должности риск-менеджера в ИТ-проекте являются такие качества, как способность управлять большим объемом информации, умение формализовать и структурировать данные, знание финансовых инструментов, математики и статистики, образование в области риск-менеджмента, аналитические способности, знание предметной области и связанных с ИТ рисков. К ключевым личным характеристикам можно отнести коммуникабельность, инициативность, уверенность в себе, умение убеждать, ясно выражать свои мысли, активность, энергичность, умение общаться, вести посредничество, объединять усилия, широкий кругозор, способность к обобщению, способность выявлять проблемы и принимать решения.
При выборе риск-менеджера нужно понимать, что управление рисками в ИТ несильно отличается от управления рисками в любой другой отрасли, поскольку законы менеджмента универсальны. Однако управление рисками в ИТ требует некоторых специфичных для ИТ знаний, навыков и опыта, без которых эффективное руководство и управление рисками невозможно, даже при наличии грамотного менеджера проекта, отлично владеющего ИТ-областью.
Если компания сделала свой выбор в пользу внутреннего риск-менеджера, можно посоветовать ориентироваться на международные стандарты и сборники методик в области управления рисками, на международные сертификационные программы, использовать их с учетом потребностей и возможностей.
Глава 8
Обзор информационных систем управления рисками
8.1. Требования к информационной системе управления рисками
При желании можно найти программные пакеты, реализующие те или иные средства управления рисками. Гораздо сложнее подобрать комплексную систему управления рисками, которая бы специализировалась на области информационных технологий и могла отслеживать риски проекта и контролировать проект.
При выборе систем следует учитывать широту охвата основных процессов управления рисками: идентификации рисков, оценки (качественной и количественной), выбора методов реагирования, мониторинга и контроля противорисковых мероприятий. Следует обратить особое внимание на функциональность обновления величин рисков, мониторинга эффективности используемых способов управления и способов управления остаточными рисками (например, перерасчет максимально допустимых величин рисков; процесс реагирования на инциденты и прочее), качества процесса реагирования на риски. Иногда инструмент оценки ИТ-рисков программных проектов позволяет отследить связи между выявленными рисками и причинами, которые ведут к ним, что является преимуществом выбранного решения.
Критериями выбора системы могут выступать следующие категории требований:
• информация о поставщике и продукте;
• функциональные требования;
• технические требования;
• цены и условия.
Информация о поставщике и продукте содержит контактную информацию о поставщике, опыт работы и финансовые показатели. Также в информации о поставщике, как правило, приведены масштабы деятельности, географический охват и направления деятельности компании-поставщика, его стратегические партнеры. С помощью такой информации можно оценить репутацию компании, успешный опыт по внедрению подобных систем, стаж пребывания компании на рынке, число продаж. Интересной информацией может быть количество работающих систем в России и отзывы пользователей/компаний, на которые поставщик услуг может предоставить ссылку.
Функциональные требования содержат требования к функциональности системы управления рисками в сфере ИТ. Функциональные требования включают также описания возможности настройки данной функциональности в системе (например, возможность настраивать поля, формулы, оформление графиков, шаблонов отчетов). Иногда в функциональные требования входят перспективы развития системы с учетом стратегических планов развития бизнеса. Поэтому в функциональных требованиях может рассматриваться либо только основная функциональность, либо основная и дополнительная – требуемая для будущего развития.
