Риск-менеджмент. Информационная система

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

Не существует какой-то волшебной ИС, которая бы покрыла все потребности в Риск-менеджменте какого-то бизнеса, как это делает, допустим, 1С в бухгалтерии (потому что бухгалтерия очень сильно зарегулирована РСБУ от Минфина). Более того, нет какого-то единого функционала ИС, который бы покрывал Риск-менеджмент в разных отраслях экономики, например, инвестиционный риск-менеджмент очень сильно отличается от операционного. Стратегический отличается от инвестиционного и т.д.

Но тем не менее, можно разработать такую ИС, которая бы обладала всеми необходимыми базовыми свойствами.

Функциональность ИС

• ИС должна охватывать как можно большее количество людей, таких как
• учредители,
• акционеры,
• менеджеры разного уровня,
• нанятые сотрудники оргединицы,
• аутсорсеры и др.
• ИС должна хранить информацию о каждом риске: название, владелец и т.д.
• Идентификация рисков:
• Каждый риск должен иметь уровень, на котором интересен риск, допустим, финансовый риск не интересен ИТ-отделу и наоборот
• Начальник отдела может просмотреть все риски своего отдела и отделов, которые находятся в подчинении согласно иерархической структуре компании. Например, CEO может просмотреть все риски всех оргединиц, CFO может просмотреть риски всех финансовых отделов.
• Каждый сотрудник имеет право вносить риски, с которыми сталкивается на своем рабочем месте.
• Начальник отдела администрирует риски своего отдела.
• Риски должны классифицироваться по типам: внешние/внутренние, финансовые/операционные/человеческие и т.д.
• Если риск не случился, то его нужно сделать неактивным, но не удалять.
• Риски могут быть связаны между собой, например, риск неустановки сервера резервных копий к какому-то сроку связан с тем, что есть риск непокупки сервера, а также отсутствия сотрудника с необходимой компетенцией, который настроит сервер к какому-то сроку. При этом он должен освободиться от других дел или не находиться в стадии увольнения. При чем этом риск зависит от двух рисков как минимум. То есть риск может зависеть от разных рисков разных оргединиц.
• Риск должен иметь владельца. Как правило, это начальник отдела.
• Риски должны иметь дату создания, кто его создал и дату закрытия (необязательно).
• Оценка рисков
• Риск должен быть оценен, то есть ему должно быть дано 3 параметра:
• вероятность того, что может случиться риск
• ущерб при риске
• время, в которое может случиться риск.
• Риск может быть описан как набор троек параметров.
• Вероятность, ущерб, время может быть указано в промежутке, например, от 10% до 20%, ущерб от 1000 до 2000 рублей, сроки от через месяц до через 2 месяца. Таким образом, можно описать матожидание в промежутке, например 100-400 рублей. Время же позволит дать приоритет по хронологии решения проблем.
• Все риски должны быть ранжированы и показаны на диаграмме ущерб/вероятность. При чем это может быть отрезок, потому что мы рассматриваем промежутки. Время может быть выделено через цвет.
• Для решения рисков необходимы ресурсы. Ресурсы тоже могут быть выписаны и оценены, например, необходимо от 1 до 2 дней, необходимы такие-то компетенции. Если нет такой компетенции в отделе, то надо попросить их. То есть для решения риска необходимо описание способов решения и приблизительный список ресурсов.
• Если риск не случился, то должно быть описано что получит ("пряник") владелец риска и как он перераспределит этот "пряник" среди исполнителей.
• Администрирование рисков
• Риск может быть эскалирован на уровень выше.
• Риск может быть решен своими силами, то есть взят на себя.
• Риск может быть передан кому-то за какие-то ресурсы, например аутсорсер за какие-то деньги.
• Риск может быть передан нескольким субъектам. Но тогда нужно перераспределить ответственность, если он случается.
• Риск может быть игнорирован.
• Если риск не случается, то есть сделаны все необходимые мероприятия, которые привели к тому, чтобы этот риск не случился. Возможно, что не было сделано ни одного мероприятия. 
• Если риск не случится, то должно быть описано кто какой пряник получил.
• Если риск случился, то необходимо подробно описать причину, чтобы в дальнейшем понимать как с ним работать.
• ИС должна поддерживать все эти возможности.

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

Основные сущности

Здесь приблизительно описаны некоторые основные сущности

• Риск
• Название
• Дата создания
• Субъект
• Оргединица
• Дата закрытия
• Типы рисков
• Субъект
• Фамилия Имя
• Оргединица
• Компания, возможно внешняя
• Оргединицы компании
• Название
• Вышестоящая оргединица
• Руководитель оргединицы
• Контактная информация
• Внешние компании/ИП
• Название
• Руководитель
• Справочники по типам рисков.
• Название
• Значение
• Мероприятия пересмотров рисков
• Риск
• Дата
• Карты рисков
• Риск
• Процент (от и до)
• Ущерб (от и до)
• Время, в течение которого может случится риск
• Связи между рисками
• Доли распределения рисков между субъектами
• Пряники, которые получат субъекты, если риск не случится
• Доли распределения пряников между субъектами и т.д.

Стратегия разработки, внедрения и поддержки

Здесь я привожу приблизительные действия для того, чтобы разработать и внедрить ИС.

Методология разработки и внедрения - Agile / XP или Scrum.

Инициация

1. Провести интервью с заказчиком для того, чтобы определить scope функционала ИС по администрированию рисков.
2. Разработать необходимую документацию, инициирующую проект по разработке ИС.

Планирование

1. Разработать и согласовать план, этапы, риски разработки, внедрения, поддержки.
2. Согласовать бюджет и план оплаты и scope по каждому этапу.

Разработка / Контроль

1. Используя Google Таблицы внести информацию в таблицы основных сущностей. Согласовать значения таблиц с заказчиком.
2. Развернуть базу данных и IDE на сервере заказчика или внешнем сервере.
3. Разработка начальных интерфейсов на Windows.
4. Внесение в интерфейсы необходимых значений.
5. Разработка функциональности через функции базы данных.
6. Тестирование функциональности представителями заказчика.
7. Интеграция ИС с другими ИС бизнеса.

Завершение

1. Установка ИС на компьютеры сотрудников.
2. Разработка и согласование всей завершающей документации

Дополнительная разработка

• Разработка web-версии ИС (или ее части).
• Разработка мобильной версии ИС (или ее чести).

Поддержка

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

Преимущества

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

Можно, конечно, ограничиться таблицами Google, но они имеют ряд недостатков:

• ограниченность в общем количестве учеток (50) одновременного просмотра
• ограниченность в количестве учеток (10) одновременного изменения
• не более чем двумерное представление сущностей
• невозможность написать достаточно сложный функционал

MS Excel не подходит для работы с рисками, потому что он не работает многопользовательском режиме. На самом деле работает в последних версиях, но необходимо устанавливать сервер и администрировать это решение.