УПРАВЛЕНИЕ РИСКАМИ В КОМПАНИИ

Недавно делали для одного из курсов Eduson модуль по управлению рисками. И там было 2 интересные темы, которыми хочу поделиться. Про риски.

Как управлять рисками на проектах, в целом, понятно. PMBOK нам все про это рассказал: идентифицируем, оцениваем, приоритезируем, митигируем. Дальше контролируем. А как работать с рисками на уровне всей компании?

Во-первых, есть специальные стандарты. Их очень много. Есть общие и универсальные. Есть локальные. Есть специфические для отрасли, например, целая куча стандартов есть в банкинге. Наиболее интересные и популярные:

- ISO 31000
- FERMA
- COSO
- …

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

Во-вторых, есть совершенно классная модель “3 линий защиты”. Как понятно из названия, мы делаем 3 уровня работы с рисками:

1. Уровень функций – реализуется в каждом подразделении, выполняется мониторинг, контроль и реагирование на риски. Например, тимлид следит за исполнением требований ИБ своими сотрудниками.

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

3. Уровень внутреннего аудита – какой-то орган, чаще всего комитет, реже – прям выделенное подразделение, которое оценивает общее качество риск-менеджмента в компании, постоянно адаптирует процессы под стратегию компании. Например, изменение политик ИБ, если появились изменения ФСТЭК.

Чем интересен подход? Как по мне, он хорошо определяет не только управление рисками, но и общую методологию построения процессов в любой компании и любом отделе. Чтобы все работало, нужно 3 вещи:

1. Люди или команды, которые выполняют работу согласно процессу

2. Специальные роли, определяющие, как именно работать в рамках процесса, и контролирующие это

3. Дополнительный механизм пересмотра работы процесса и его согласованности с текущей реальностью

Вспоминаю, как мы внедряли Scrum. Тимлиды на местах и команды реализовывали фреймворк. Delivery Manager-ы определяли, как адаптировать Scrum к проекту, как его внедрять и как мониторить потом. Ну а топ-менеджмент давал добро или недобро на всякие изменения, когда того требовали новые цели компании или конкретный проект не мог раскатать тот процесс, который был нужен нам. Эдакие “3 линии внедрения Scrum”. Интересно 🙂

Вот такие мысли. И такие инструменты. Надеюсь, будет полезно.