какие данные включает матрица рисков и для чего она разрабатывается
«Матрица рисков» компании. Алгебраическое исследование
Мне доводилось принимать участие в упражнениях с Матрицей рисков компании.
Действие происходило в три этапа. Первый: мальчики и девочки анкетировали вопросами типа «перестал ли ты пить коньяк по утрам», на которые надо отвечать только «да» или «нет».
На втором этапе показывалась «научно-обоснованная» матрица рисков.
На перманентном третьем этапе все подразделения той компании пытались из года в год сдвинуться на более низкие позиции на матрице, но это удавалось только за счет личного обаяния. Те же, кто не смог сдвинуться становились крайними по любой неудаче бизнеса.
1. Матрица рисков: удобно заполнять, не удобно работать.
Вот типовая Матрица рисков, которую предлагает Google.
Для примера в Интернете найдена случайная Матрица рисков из очень старого отчета.
Числа внутри цветных прямоугольников означают содержательную интерпретацию риска, которая пока не очень нужна. Описание риска очень широко и размыто. Не верится, что все компоненты описания по отдельности и вместе дают единственное число в очень узком диапазоне.
Если следовать типовой матрицы Google, то всем содержательным описаниям «вероятность» и «влияние» можно поставить в соответствие конкретные числа.
Вот шаблон модернизированной матрицы Google с умноженными вероятностями, соответствующие горизонтальному и вертикальному шкалированию.
Она не очень удобна для применения стандартных матричных операций, так как симметрична относительно дополнительной, а не главной диагонали.
Возможно, что Матрица рисков в такой форме более удобна для менеджеров. Её перестройка с симметрией относительно главной диагонали не меняет сути матрицы. Кроме того, всегда можно сделать шаг назад и вернуться к исходному представлению.
Перестроение матрицы происходит путём замены порядка строк на обратный (симметрия относительно вертикальной центральной оси). В результате получена матрица симметричную относительно главной диагонали.
Эти же преобразования для исследуемой Матрицы рисков.
Числа, отличные от 0 — это номер риска, связанный в итоге с неким структурным подразделением. Эта кодировка имеет место только в связи с бюрократической иерархией в компании, а не с рисками. Например, для элемента <1,5>. В плане риска ситуация ничем не будет отличаться, если совместить описания риска1 и риска5. Если это разные риски, то можно уменьшить шаг матрицы и поместить риск в более подходящую позицию.
В итоге преобразования должны приводить к тому, что каждый различный риск является отдельным элементом.
Позиция [1,3] в стандартной системе нумерации матриц означает элемент, находящийся на пересечении 1-ой строки и 3-го столбца. Для рассматриваемой матрицы в позиции [1,3] стоит число 2. Это означает, что если имеет место шкала с максимальным значением «5 — почти произошло» (1.), то в [1,3] ожидаем «3 — среднее» (0.6) влияние. Пусть «влиянию» в шкалируемом промежутке соответствует определенный ущерб (damage): 5-d5, 4-d4, 3-d3, 2-d2,1-d1. Тогда, если за определенный период имело место 1 происшествие из группы 2, то ущерб составит 1.*0.6*d3*1, а если за этот же период произошло n происшествий из группы 2, то ущерб составит 1.*0.6*d3*n
Тогда исследуемая матрица примет вид.
Проводится еще одно преобразование: транспонирование путём перемены мест столбцов и строк.
Нижняя строка легенды становится излишней, так как соответствующая вероятность учтена в значениях матрицы. Первый вертикальный столбец также учтен в значениях матрицы, но он важен тем, что задает структуру событий, которые можно фиксировать или прогнозировать за некий период. Имея вектор-столбец из количества событий, относящихся к соответствующему типу (очень сильное, критическое,…) можно стандартным образом умножать матрицу на вектор-столбец и получать структурированный размер ущерба.
Без легенды матрица будет выглядеть так.
2. Матрица рисков: удобно вычислять, не удобно анализировать.
Первая основная задача.
Получив матрицу А можно приступать к решению первой основной задачи: при известном количестве и качестве произошедших событий вычислить размер ущерба.
Пусть за определенный период произошло 2 — «очень сильных» событий, 3 — «критичных», 1 — «среднее», 5 — «минимальных» и 7 — «незначительных». Умножив матрицу А на вектор количества событий получаем структуру ущерба.
Теперь можно проверять точность оценок, вносить коррективы, оценивать возможные варианты сокращения размера ущерба.
Приведенные трансформации исходной матрицы были проведены, чтобы получить простую вычислительную процедуру ущерба. От матрицы А всегда можно однозначно вернуться к исходной матрице.
3. Матрица рисков: какая теория за ней стоит?
Для любой невырожденной квадратной матрицы имеется однозначное линейное преобразование, соответствующее этой матрице. При обозрении матрицы сложно понять какое линейное преобразование стоит за ней. Кроме того, неизвестно в каком базисе произведено матричное представление.
Матрица риска — квадратная матрица и ей должно соответствовать некое линейное преобразование. Этот факт не зависит от способа получения матрицы и идей реализованных в конкретном способе получения матрицы.
Важно, чтобы определитель матрицы не равнялся нулю. Это требования метода, обеспечивающего каноническое представление матрицы.
Далее показывается, что это не просто ограничение метода, а требование отвечающее потребностям практики.
Рассматриваемая Матрица рисков имеет две нулевых строки и один нулевой столбец. В любом случае определитель этой матрицы будет равняться нулю. Ниже приведен рисунок, показывающий как компания намерена снижать риски.
Стрелками показано как будут снижаться риски. Каким образом — не важно, важно, что при этом новая ситуация опять представляется матрицей. Этой матрице соответствует некое линейное преобразование. Переход от «старой» матрицы к «новой» — это матрица и линейное преобразование.
Что означает ненулевой определитель? Это возможность шагать «вперед-назад». Если определитель нулевой, то шага «назад» сделать нельзя.
При этом матрица снижения рисков изначально связана со «старой» матрицей. То есть на картинке можно и нужно парить «вперед-назад», а в формализованном варианте шагать «вперед-назад» нельзя.
Следующая проблема связана с тем, что большой риск с малой вероятностью может быть сопоставим с риском от очень большого количества малых рисков с малой вероятностью.
В приведенном выше примере 7 незначительных событий формально не вызывают ни какого ущерба. Понятно, что это не так. Отсутствие малых рисков только подчеркивают недостаточную некорректность формирования Матрицы рисков.
Пусть определитель Матрицы рисков не равен нулю и это следствие преемственности работ по снижению рисков, а не искусственное для бизнеса требование математического метода.
Итак, имеются:
— Матрица рисков, которая соответствует неизвестному линейному преобразованию и неизвестному базису;
— определитель Матрицы, который не равен нулю.
Что можно сделать? Привести Матрицу рисков к каноническому виду с понятным ортонормированным базисом.
В работе Александра Емелина дается следующее аллегорическое описание преимуществ канонического вида. “Предположим, что есть листок бумаги, на котором написано некоторое слово. Но он сложен так, что слова не видно. После канонического преобразования листок разворачивается таким образом, что слово можно увидеть. Если используется ортонормированный базис, то листок бумаги останется того же размера.”
Никакие приведенные в работе операции и трансформации не меняют существа явлений, отраженных и содержащихся в Матрице рисков.
4. Матрица рисков как алгебраическая конструкция.
Вторая основная задача. Каноническое представление.
В рассматриваемую матрицу добавляются элементы так, чтобы определитель не равнялся нулю. Чтобы избежать слишком больших формул значения округляются.
Далее по стандартной схеме матрица приводится к каноническому виду.
Собственные значения Матрицы рисков.
Дальнейшая работа с символическими значениями будет тяжёлой при ортогонализации и результат будет невозможно визуализировать (очень громоздкие символические матрицы).
Пусть (для примера) d1=1, d2=2, d3=5, d4=8, d5=12.
Тогда Матрица рисков М в симметрическом представлении принимает вид.
Проверяется, что определитель М не равен нулю.
Вычисляются собственные значения.
Находится матрица из собственных векторов.
Она ортогонализируется. Получается матрица ORT ортонормированных векторов.
Для проверки первый вектор (столбец) умножается попарно на все остальные. Значения ненулевые, но близки к 0.
В новом базисе находится представление исходного линейного преобразования (определяющего Матрицу рисков) в переменных z1, z2, z3, z4, z5.
Если пренебречь очень маленькими слагаемыми, то получается каноническое представление линейного преобразования.
Причем коэффициенты при квадратах соответствуют ранее вычисленным собственным значением.
Новый вид Матрицы рисков в ортонормированном базисе.
Получается знакопеременная квадратичная форма.
5. Практическая польза канонического представления.
Что можно сказать про исходную Матрицу рисков?
Она представляет неизвестное линейное преобразование.
Её строки обозначаются (сверху-вниз) как x1, x2, x3, x4, x5. Строки Матрицы рисков представляют разложение по неизвестному базису.
Так
x1=10*d5*b1+0*b2+0*b3+0*b4+0*b5,
x2= 8*d4*b1+0*b2+4*d4*b3+0*b4+0*b5, и так далее.
Наличие ортонормированного базиса обеспечивает свободу хождения между переменными X и Z.
В переменных Z явно видна функция линейного преобразования в ортонормированном базисе. Поведение этого же линейного преобразования в исходной Матрице рисков было непонятным.
Явная польза от канонического вида состоит в возможности корректировки шкалирования для разных типов событий (происшествий). Если изначально шкалирование событий (очень сильное, критическое,…) шло по шагу в 20%, то теперь его можно пересмотреть, пересчитав значения концов диапазонов в новом базисе. Останется так же 5 типов событий (происшествий), но шаги между ними будут разными.
6. Матрица рисков: квадратичная форма определяет содержание.
Описанная практическая польза может показаться смешной на фоне сделанных перед этим не совсем простых манипуляций: «овчинка не стоит выделки».
Ясная, понятная и простая форма Матрицы рисков Google не совсем соответствует содержанию работе с рисками.
Что такое риск: рассчитываешь на одно, а по факту получаешь другое.
Матрица рисков Google сделана так, что компания всегда однозначно знает свои риски и последовательно работает над их снижением. Более того, все высокие риски с большим ущербом постепенно ликвидируются. Слава мудрым менеджерам.
Напротив, полученная в ортонормированном базисе Матрица рисков будет всегда показывать наличие непустых высоких рисков.
Сформированное в 4 разделе каноническое представление можно интерпретировать как ущерб, который получается, когда происходят те события, которые ожидаются: переменная в квадрате.
Есть еще одно немаловажное обстоятельство. Ущерб имеет место так же в том случае, если произведены затраты для предотвращения ситуаций, которые никак не происходят.
Следующая новая конструкцию.
Значения v[i,j] соответствуют ущербу (выгоде) при условии, что рассчитывали на событие f(j), а реально произошло событие f(i). Значения v[i,j] могут быть как положительными (ущерб), так и отрицательными (выгода).
Значение v[i,i] соответствует ситуации, когда фактически произошло то событие, к которому готовились: на что рассчитывали, то и получили.
В этом случае Матрица рисков принимает вид.
Вектор-столбец событий имеет вид.
При этом размер ущерба описывается квадратичной формой.
Приведенную новую конструкцию описания рисков можно связать со следующими вычислениями: оценка ущерба при фактическом наступлении события f(i), тогда как мероприятия ориентированы на событие f(j).
Тогда проясняется какие «мероприятия по снижению рисков» требуются:
— для тех рисков, к которым не готовились, но они часто проявляются;
— для рисков, выделенных как базовые.
Кроме того, все алгебраические манипуляции описанные выше становятся не просто уместными, а обязательными.
Задача минимизации рисков сводится к минимизации значения ущерба, задаваемого каноническим представлением квадратичной формы ущерба.
7. Матрица рисков как инструмент цифрового управления.
В общем случае можно использовать разные методы оценки и управления рисками: имитационное моделирование, системы массового обслуживания, оценку устойчивости структурных схем последовательно-параллельного соединения компонентов и другие.
В данном случае рассматривается «жанр» Матриц риска и его возможности для улучшения бизнеса.
Фактически новая форма позволяет Матрице рисков уйти от роли «жупела» и стать нормальным инструментом цифрового управления бизнесом. Одним из многих для современного бизнеса.
Для этого необходимо поменять методику исчисления ущерба, сделав упор на проверяемые количественные значения по сравнению с ориентацией на качественные экспертные оценки.
Как управлять рисками IT-проекта
Если какая-нибудь неприятность может произойти, она случится — гласит закон Мерфи. И сфера ИТ не исключение.
Команда SEBEKON рассказывает, как работать с рисками в IT-проекте, чтобы риски не стали управлять проектом.
В этой статье под IT-проектом подразумевается разработка сложного веб-ресурса — например, b2b-портала или интернет-магазина с множественными интеграциями с внешними системами.
Дилемма управления рисками любого IT-проекта простая: перестраховаться и заложить все угрозы в бюджет проекта, который вырастет до небес, или пропустить часть рисков — и тогда будет велика вероятность не завершить проект вовсе или получить неудовлетворительный результат.
Но даже если принять первый вариант как единственно верный, от рисков никто не застрахован.
Менеджер проектов компании SEBEKON
Генеральный директор компании SEBEKON
Как работать с рисками
Обычно ожидаемая реализация проекта не совпадает с реальной работой:
На практике управление рисками — это тонкий баланс между разумным и достаточным.
Существуют пять основных инструментов для работы с рисками:
Рассмотрим каждый из них подробнее.
Выявлять риски
Риски проекта определяются во время фиксации требований к проекту и отражаются в уставе или концепции проекта.
Устав проекта ― это документ, в котором зафиксирована основная информация о проекте: потребности заказчика, бизнес-задачи, высокоуровневые требования к проекту, критерии успешной реализации.
Концепция проекта ― документ, в котором собраны подробные характеристики проекта.
Выбор документа зависит от масштаба проекта.
Чтобы выявить риски, нужно проанализировать множество информации и сопоставить, как те или иные факторы влияют на возникновение рисков.
Рассказываем, что стоит сделать для этого.
Учесть опыт предыдущих проектов
Для примера возьмём согласование дизайна страниц сайта.
Дизайн всегда субъективная история, и нужно закладывать дополнительное время на решение вопросов в стиле «а давайте попробуем немного светлее или поиграем со шрифтами». Заказчик должен ещё до начала работ понимать, что любое изменение, требующее нескольких минут работы, в итоге выливается в часы и дни согласования.
Часто на стороне заказчика необходимо согласовать дизайн с несколькими департаментами — и не всегда сотрудники этих отделов могут быстро подтвердить изменения. Если речь идёт о крупной компании, то руководителю проекта придётся назначать собрание или созвон для обсуждения дизайна. И не всегда это получится сделать в ближайшие дни — часто согласование растягивается на недели, а то и на месяцы.
В нашей практике были разные проекты, но редко, когда удавалось согласовать дизайн в первой же итерации и по ходу работы не менять его. Гораздо чаще приходилось сдвигать сроки работ, потому что представители заказчика не смогли оперативно обсудить дизайн и согласовать его.
Оценить новизну критичных требований — как для заказчика, так и для исполнителя
Например, в проекте предполагается разработка нового функционала, которая требует совместной работы нескольких подразделений на стороне заказчика и дополнительных исследований на стороне исполнителя. Всё это увеличивает сроки согласований и влияет на срок проекта.
Принять во внимание особенности внутренней инфраструктуры заказчика
Самый очевидный пример ― требования к безопасности, которые могут существенно отодвинуть срок старта проекта. Это связано с необходимостью получения доступов в систему заказчика или требований по использованию определённого, разрешённого на стороне заказчика ПО, которые повлекут за собой дополнительную проработку архитектуры проекта.
Не забыть про покупку серверного оборудования или про согласование хостинга
Если про покупку хостинга заказчики обычно помнят, то про серверное оборудование в проектах могут забыть и не заложить в бюджет стоимость оборудования, лицензий, а также время на заключение договора с поставщиком оборудования и его доставку.
В зависимости от проекта серверное оборудование может быть стационарным — шкафы с оборудованием — или облачным, когда проект размещается в виртуальном пространстве.
Напоминание заказчику о закупке серверного оборудования на первых же обсуждениях проекта позволит избежать досадных простоев в работе.
Заложить внедрение интеграции проекта с внутренними системами заказчика
Об этом часто забывают, поскольку обычно в организации заказчика под проект выделяются не специально нанятые люди, а текущие сотрудники, у которых есть другая, основная работа. Они воспринимают новый проект как нечто второстепенное, что можно делать по остаточному принципу.
В итоге когда приходит время интеграций проекта с CRM-, ERP- и другими системами работа останавливается на неопределённый срок, потому что менеджер проекта со стороны заказчика не может оперативно подготовить необходимую документацию и доступы для интеграций.
Выявить заинтересованность в проекте ключевых стейкхолдеров
Стейкхолдеры ― это не только топ-менеджмент, но и будущие пользователи и эксперты, которые хорошо разбираются в вопросе и могут помогать с проектом или же оказывать негативное влияние.
На начальном этапе стоит понять, как взаимодействовать с так называемыми негативно настроенными стейкхолдерами, чтобы они не вредили реализации проекта. Под негативно настроенными мы понимаем не тех, кто намеренно вставляет палки в колеса, а тех, кто не понимает последствий от своих решений.
В нашей практике не раз случалось, когда некоторые стейкхолдеры не глядя согласовывали ТЗ, а на этапе тестирования готового проекта выяснялось, что всё должно быть совсем не так.
Например, руководитель департамента логистики должен был проверить сценарий по расчёту доставки товара. Но он был занят текущей деятельностью, мельком просмотрел ТЗ и отправил с пометкой «принято». В ходе тестирования этого сценария оказалось, что он должен быть реализован другим способом. В итоге пришлось откатить проект назад: пересмотреть внесение правок в сценарий, затем внести эти правки в ТЗ, согласовать это со всеми стейкхолдерами, переделать сценарий и заново его протестировать. На всё это ушло больше месяца, а кроме того, заказчику пришлось оплатить дополнительные работы.
Для наглядности можно составить матрицу влияния стейкхолдеров на проект и методы взаимодействия с ними. Например, такую:
Изучить соответствующее законодательство, поговорить с экспертами и опытными коллегами
У более опытных коллег за плечами больше реализованных проектов, они уже набили свои шишки и могут дать полезные советы. Эксперты помогут разобраться в отдельных нюансах относительно, например, сценариев пользователей или специфической функциональности.
При разработке ресурсов для государственных компаний изучение законодательства ― обязательный этап в работе над таким проектом. Например, сайты и порталы для государственных образовательных организаций должны быть сделаны с учётом требований Министерства образования.
Оценивать риски
Риски обязательно соотносятся с критичностью или некритичностью требований к проекту в целом.
Критичные требования отвечают за целевую функцию разрабатываемого продукта, включают необходимую инфраструктуру и возможности для разработки MVP.
К некритичным относятся остальные требования.
Для каждого риска выявляют следующее:
На базе этих параметров строится матрица рисков.
Остановимся подробнее на степени управляемости рисками.
Управляемые — риски, которые можно предугадать и акцентировать на них внимание уже на начальном этапе проекта, определив для них ответственных и держа под контролем.
Самый очевидный пример ― опять же дизайн сайта. Сразу понятно, что на этапе согласования могут возникнуть сложности, доработки, переделки и бесконечные правки. Поэтому мы на старте проговариваем этот момент с заказчиком, согласовываем, кто будет лицом, принимающим окончательное решение, и письменно фиксируем максимально допустимое количество дней на согласование макета — в среднем, по нашему опыту, это обычно 5.
Неуправляемые — возможные риски, появление которых мы не можем предотвратить.
Например, один из неуправляемых рисков ― более ранний выпуск конкурентами на рынок похожего продукта.
Другой пример — подключение платёжной системы. В описании API говорится, что в ответ на запрос придёт одна строка, а по факту приходит три. И платёжная система на своей стороне не готова вносить правку, потому что на это нужно время, при этом тысячи пользователей этой системы об этом не просили. Так как нужна именно одна строка, разработчику приходится самостоятельно решать этот вопрос, тратить больше запланированного времени на разработку и фиксацию данной ошибки.
Запланировать мероприятия по предотвращению рисков
Для предотвращения рисков нужно понимать, как от них защищаться.
Грамотно выстроенные коммуникации внутри проекта играют главную роль для защиты от рисков и оказывают огромное влияние на успех проекта. Это означает, что все процессы взаимодействия регламентированы, роли всех членов команды закреплены и всё это зафиксировано в понятном для участников формате.
Важно сразу выстроить коммуникацию с заказчиками проекта, создать большую команду из представителей обеих сторон и все вопросы решать совместно.Для этого фиксируем ответственных для каждого этапа проекта в матрице «Роли и зоны ответственности» (RACI Matrix).
В матрице предусмотрены четыре роли:
Однако просто зафиксировать ответственных мало — нужно проанализировать заполненную матрицу, чтобы не было перекоса в одну роль:
После того, как разобрались с матрицей ролей, проактивно управляем рисками — фиксируем их и то, что нужно сделать для предотвращения.
Вместе с этим определяем план и способ коммуникаций на протяжении всего проекта: сколько раз в неделю и месяц, каким составом и при наступлении каких событий будем проводить созвоны или очные встречи, какой формат отчётности примем для фиксации договоренностей на этих встречах.
Также определяем инфраструктуру проекта:
Профессия
Project
manager
Предусмотреть действия при наступлении рисков
Стоит предусмотреть резервный план (contingency plan) на случай непредвиденных обстоятельств.
Задача этапа — выполнить его наиболее эффективным образом, а также собрать и проанализировать информацию о наступившем риске на будущее.
Не стоит тратить время на поиск виноватых — лучше предпринять всё необходимое, чтобы двигаться дальше и продолжать реализацию проекта. На этом этапе главная роль принадлежит коммуникации и поиску оптимального решения.
В нашей практике был проект, когда нужно было разделить один сайт, реализованный на Bitrix, на два. Один из них надо было интегрировать со штатной версией 1С.
Заказчик предполагал, что на разработку на своей стороне их специалисту понадобится три недели. По факту оказалось, что ранее созданная интеграция полностью кастомная — комплекты, цвета, размеры, остатки — и на стороне заказчика нет эксперта, который смог бы выполнить задачу. Пришлось подключиться нам и помочь с решением по интеграции. Дополнительно были пересмотрены сроки проекта.
Мониторить риски
Ситуация на проекте постоянно меняется ― это нужно принять как аксиому.
Например, если работать по Agile, то перед каждым новым спринтом могут меняться параметры проекта, обрисованные на этапе обсуждения. Следовательно нужно отслеживать изменения параметров рисков, корректируя внутрикомандный перечень топ-10 рисков.
На этапе мониторинга — если возвратиться к примеру с Agile, то это нужно делать в начале каждого спринта — важно отслеживать новые риски, изменять статус выявленных рисков, корректировать планы. На протяжении проекта перечень может значительно измениться.
К примеру, на крупном проекте на финальном этапе в команде заказчика появляется эксперт, который задаёт много вопросов и предъявляет новые требования к проекту, которые подразумевают изменение архитектуры проекта и кода. Если инициировать эти изменения, то есть риск сорвать плановые сроки реализации проекта.
Как вариант — провести встречу, обсудить, что беспокоит эксперта в текущей архитектуре, объяснить, почему реализовано именно так и наметить дальнейшие шаги. При этом важно постараться не увеличить объём работ проекта и не выйти за временные и финансовые рамки.
Каждый участник команды должен понимать важность работы с рисками
Ключевой момент управления рисками — их постоянное отслеживание и предотвращение, в идеале согласованное с длительностью циклов разработки проекта.
Оценка рисков и работа с ними зависят от размера и длительности проекта. Рекомендуем возвращаться к работе над рисками один раз в 1‒2 недели, в некоторых крупных проектах периодичность может быть увеличена до месяца.
Лучше составить неполный перечень рисков, чем не составить его вовсе.
В процессе общения с разработчиками или заказчиком лучше забыть фразу «все и так всё понимают»:
Главное в работе с рисками ― донести до всех участников проектной команды необходимость работы с рисками. Прежде всего нужно стараться не допускать наступления рисков, анализировать прошлый опыт и причины наступления для составления перечня возможных рисков в новых проектах, предотвращать непредусмотренные риски.
Пример перечня рисков проекта с комментариями и статусами можно посмотреть здесь.
Этапы оценки проекта: понятия, методы и полезные инструменты
Кто такой проджект менеджер, чем он занимается и как им стать
Как компаниям общаться с клиентами: ключевые тенденции и полезные советы
Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.