Илья Евстафьев - Тотальный риск-менеджмент

Информационная система управления рисками

Вопрос об архитектуре, перечне и источниках данных достаточно сложен, подробное рассмотрение не входит в задачи данной книги. Ограничимся кратким описанием.

Причинно-следственная модель риска (рис. 4.8.) предполагает архитектуру хранилища данных, примерно соответствующую той, которая представлена на рис. 11.1. Важно учесть также взаимосвязи с другими автоматизированными системами управления предприятием и хранилищами данных. Например, наиболее ценным источником сведений об инцидентах может стать CRM – система или хранилище данных юридического отдела о претензиях и рекламациях. Хранение информации о мероприятиях и работах, проводимых для управления рисками, можно производить в системе управления основными фондами, техническим обслуживанием и ремонтами (EAM-системе).

Рис. 11.1. Архитектура хранилища данных

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

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

1. Развить систему управления рисками в систему управления улучшениями.

2. С информационной точки зрения связать систему управления рисками с другими системами управления бизнес-процессами и производством.

Для достижения первой задачи необходимо, чтобы:

1) цели в области качества были переформулированы языком рисков, как это говорилось в гл. 11.1;

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

2.1) описание рисков, на преодоление которых оно направлено, и величины ожидаемых потерь в денежном выражении;

2.2) прогноз состояния рисков и потерь после проведения изменений;

2.3) прогноз появления новых рисков, анализ изменения рисков других процессов и объектов в результате изменений;

3) полное единение всех составляющих системы.

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

1. Планируем сложный проект, состоящий из десятков работ. Вероятность и продолжительность задержки каждой из них оценена ответственными за эти работы специалистами. Сколько времени займет гарантированное исполнение проекта с 90 % степенью вероятности?

2. Технологический журнал цеха ведется в течение нескольких лет. Каков процент снижения выпуска годных изделий вносит внеплановая переналадка оборудования?

3. Какова при наличии риска прогнозируемая стоимость инвестиционного портфеля компании с вероятностью отклонения 3 %? (VAR, value at risk).

Многие из подобных расчетов вас крайне удивят. Большинство предприятий не представляют, сколько они теряют в результате действия рисков.

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

● что мы будем делать, если завтра дефолт, аналогичный 1998 году?

● что мы будем делать при изменении политической ситуации?

● поведение в случае землетрясения, наводнения, разрушения трубопроводов и т. д.

В подобных случаях все равно придется импровизировать, но методы и варианты поведения необходимо продумать заранее. Главное – понять, какими вообще средствами и ресурсами вы располагаете на такой случай.

Вооруженные твердыми знаниями, понимая, чем вы рискуете, вы сможете работать на сложных, но прибыльных рынках (табл. 11.1).

Таблица 11.1 СТАДИИ ВНЕДРЕНИЯ ТРМ

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

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

Организационная структура проекта приведена на рис. 12.1.

Рис. 12.1. Организационная структура проекта

Какого из этих элементов нет у любой компании?

Коротко остановимся на обязанностях подразделений и их изменениях в результате начала проекта ТРМ.

Его роль и обязанности подробно описаны в предыдущей главе и в целом понятны из материала книги.

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

Круг задач этих людей:

● анализ состояния бизнес-процессов компании;