Читать онлайн «Информатизация бизнеса. Управление рисками». Страница 47

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

Основные функции управления рисками риск-менеджера (подразделения УР):

• разработка политики по управлению рисками;

• разработка, тестирование методов и моделей оценки рисков;

• разработка и/или выбор методологии;

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

• взаимодействие с внутренними службами;

• управление портфелем рисков и оценка совокупного риска ИТ;

• создание и ведение базы данных и информационное обеспечение;

• доведение результатов оценки и управления рисками до высшего руководства компании.

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

Наличие риск-менеджера не исключает участия всех участников проекта в управлении рисками. Фактически каждый участник ИТ-проекта управляет рисками, связанными с ИТ. Риск-менеджер координирует и объединяет их усилия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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