Профессиональное управление рисками проекта

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

Немного о себе. Меня зовут Денис Беляев, я представляю компанию ТАБ (Технологии. Автоматизация. Бизнес). Мы специализируемся на оказании услуг по построению систем управления рисками, а также на консалтинге в области риск-менеджмента.

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

Но мы сейчас с вами начнем с самой базы, с фундамента.

Сам я по профессии программист, внедряю информационные системы около 15-20 лет, выступаю как руководитель проектов и эксперт. Именно объединение данных ключевых экспертиз позволяет посмотреть на проблему управления рисками в проекте значительно глубже.

 

Ключевые аспекты риска – непредвиденность и неблагоприятность. Закрепим на практике

 

Начнем с определения того, что такое риск.

Риск – это случайное непредвиденное событие, в результате которого возникают неблагоприятные последствия.

Формулировка простая, но очень важная. В ней есть два ключевых момента – это непредвиденность и неблагоприятность. Всегда, когда думаете о риске, помните про эти два аспекта.

 

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

Правильные ответы – первое, третье и пятое. Давайте кратко разберемся, почему именно они.

• ТЗ не полностью раскрывает реальные требования. Это классический риск: мы вроде бы все описали, но по факту в ходе проекта окажется, что что-то упущено. Вероятность этого риска – практически 100%. И это нормально, такие риски есть всегда, вопрос лишь в масштабе. Этот риск мы должны учитывать изначально, в том числе, закладывать его в оценку.

• Не прошел оперативный комитет проекта. Это не риск, а уже свершившийся факт. Он не в будущем, а уже произошел, поэтому не может считаться непредвиденным. А непредвиденное – это то, что может произойти или не произойти.

• Неполнота предъявленных в ходе обследования требований. По формулировке и содержанию очень похоже на ситуацию с ТЗ, потому что ни один из бизнес-пользователей нам никогда полностью на 100% всего не расскажет.

• Акт выполненных работ не подписан. Аналогично второму – это уже факт. Он может быть последствием риска, но сам по себе риском не считается.

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

• Заказчик согласился использовать типовой функционал, вместо привычного старого интерфейса. Не является риском, потому что он положительный – наш проект сократился в объеме, и риски самого проекта снизились, нам будет легче внедрить изменения в систему и перевести ее в эксплуатацию.

 

Стандарты управления рисками и их классификация

 

 

Для управления рисками есть два важных стандарта:

• ГОСТ 31000 строго регламентирует правила управления рисками – там для каждого конкретного названия рисков (например, операционный риск) четко указано, что и как с ним делать.

• А в стандарте COSO, актуальная версия от 2017 года – уже менее четко описаны общие принципы управления рисками.

Здесь можно провести аналогию с теми стандартами, которые есть для бухучета:

• ГОСТ 31000 похож на ФСБУ, потому что в ГОСТ 31000 четко описаны правила работы с рисками – по аналогии с тем, как в ФСБУ описаны правила, как учитывать те же основные средства;

• а COSO похож на МСФО, потому что в COSO описаны принципы управления рисками – так же, как в МСФО описаны принципы учета.

Запомнить просто: ГОСТ – это правила, а COSO – принципы.

ГОСТ 31000 имеет важную взаимосвязь с ISO 9001 (СМК).

• ISO 9001 о том, что если в компании есть инструкция или регламент, его нужно исполнять. Например, есть регламент о том, что кассир должен прийти на работу в 9 утра, сесть за кассу и пробивать чеки. ISO 9001 проверяет, что этот регламент исполняется.

• А ГОСТ 31000 задаёт более глубокие вопросы: а нужен ли вообще этот регламент? Нужно ли его исполнять? К чему приведет его неисполнение? Именно через эти вопросы мы управляем рисками.

Получается, что ISO 9001 – одна из подчастей в системе стандартов по управлению рисками. Важно, чтобы в дальнейшем у вас было это понимание.

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

• Допустим, что произойдет, если у нас не будет устава проекта? Проект обязательно провалится? Нет. Я реализовывал успешные проекты без устава. Возможно, мне просто повезло. Но в другой ситуации может не повезти – в этом и заключается непредвиденность риска. Каждый проект уникален, мы должны всегда задаваться вопросом, пригодится ли вам тот или иной документ.

• Или что будет, если не будет карты описания процессов «as is» и «to be»? Карту «as is» часто вообще не делают, и это тоже нормально. Да, без нее мы рискуем не выявить, что именно нужно доавтоматизировать по процессам, и можем что-то пропустить. Но мы понимаем, что эти детали можно будет выловить на этапе опытной эксплуатации. Поэтому «as is» мы не пишем, а делаем только карту описания процессов «to be». Но есть проекты, где мы понимаем, что опытная эксплуатация будет сложной или ее вообще не будет – значит, риски возрастают, и карту «as is» нужно сделать.

• То же самое с ТЗ. Можно без ТЗ.

• Можно без рабочих инструкций

• Можно без сценариев тестирования.

• Можно и без актов работать, если вы исполнитель, и у вас полное доверие с заказчиком.

Но все это – риски.

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

 

Виды методик управления рисками

 

Само понятие «риск» несет в себе некоторую неопределенность, которую нельзя измерить заранее, поэтому управлять рисками можно только через влияние на источники их возникновения.

Кстати, то, что мы с вами рассматривали раньше, когда определяли, какие примеры являются рисками – это были источники риска. Не путайте: риск – это событие, а источник – это причина, по которой это событие может возникнуть.

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

Первая классификация – по видам рисков. Видов рисков всего три: операционные, финансовые и регуляторные. Других видов рисков не существует. Все остальные виды, которые вы можете слышать – это просто частные случаи, подпадающие под эти три категории. Или это не виды рисков, это группы источников риска – например, иногда можно услышать термины вроде «организационные риски» или «технические риски».

А по видам классификация только такая, потому что у каждого из этих видов риска – свое свойство.

• Операционный риск связан с нарушением или сбоем в бизнес-процессе, у него свойство – бизнес-процесс. Например, сотрудник должен был передать ТЗ разработчику, но не передал. Или заказчик вовремя не согласовал проектную документацию. Это – сбой в процессе, а значит, операционный риск.

• Финансовый риск связан с оплатой. Он возникает, например, тогда, когда нам не заплатили деньги за проект – не достаточно заплатили или не вовремя заплатили.

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

Это самая базовая, самая верхнеуровневая классификация рисков. А далее в зависимости от вида у рисков могут быть разные свойства.

Причем риск может быть двойной и даже тройной. Например, мы получили штраф, потому что не сдали отчетность в налоговую – не смогли сдать, потому что сервер сломался.

• Сервер сломался – это операционный риск. С ним будут работать айтишники – почему он там сломался.

• Получили штраф – это регуляторный риск. С этим риском будут работать юристы и бухгалтеры – будут договариваться с налоговой и защищаться от этого штрафа.

• И если мы все-таки штраф получим, это будет еще и финансовый риск – потому что эту сумму придется списать с баланса.

В реестре рисков это будет три разных записи.

 

На слайде – источники риска, которые входят в типовой перечень проектных рисков внедрения информационных систем. Полный перечень – во вложении к статье.

При составлении этого перечня я взял за основу стандарт TKV-1-001 из технологии корпоративного внедрения (1С:ТКВ)

Опять обращу ваше внимание на терминологию: это не риски, а источники риска.

Фактические события, которые произошли в результате риска, записываются в «реестр рисковых событий» – его полную версию тоже можно скачать во вложении к статье.

И в зависимости от вида риска в этом реестре поля будут заполняться по-разному:

• Для финансового риска важно указать сумму.

• А для регуляторного риска – ссылку на законодательство, по какому Федеральному закону мы не сдали эту отчетность

Это нужно для того, чтобы у вас было общее понимание.

 

Оценка рисков

 

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

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

Согласно классификации из ГОСТ 31000 оценка риска бывает предварительная и по случившемуся событию.

• Предварительная оценка риска – это когда сидит наш мега-эксперт и говорит: «Я думаю, что это произойдет или не произойдет. Или вероятно, что это произойдет». Очень сложная работа. Чаще всего предварительной оценкой риска занимается руководитель проекта или какие-то ведущие специалисты, эксперты проекта – ведущий аналитик, ведущий разработчик и так далее.

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

 

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

В этой табличке перечислены 60 возможных источников риска. Наша цель – оценить вероятность и влияние для каждого из источников риска, заполнить для каждой строки три графы: вероятность, влияние и общая оценка, где общая оценка – это просто перемножение вероятности на влияние.

В результате получается цветная матрица – так называемая тепловая карта, где при повышении вероятности и влияния источник риска уходит в красную зону.

В качестве примера возьмем условный проект – внедряем ERP, переходим с SAP. Команда со стороны исполнителей и со стороны бизнеса – 40 человек. Нужно внедриться за полтора года.

Давайте сейчас попробуем спланировать оценку риска для этого проекта.

 

Во вложении к публикации выложено несколько файлов. Один из них – это «Шаблон карты рисков.xslm», где внесены все виды рисков, которые присущи проекту внедрения информационных систем.

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

В шаблоне на закладке «2. Данные с оценкой» перечислено 60 источников рисков. Для каждого из рисков нужно проставить баллы – вероятность и влияние.

Вы берете какое-то событие, например «ТЗ не полностью раскрывает реальные требования» – это произойдет на проекте со 100% вероятностью. Этот риск очень высокий, вопрос только в частоте его возникновения. Если учесть, что проект длится больше года, и у него может быть несколько ТЗ, вы проставляете этому риску соответствующую оценку – 30 или 40 баллов (раз в месяц или раз в квартал).

 

На примере заполнения можно посмотреть, как это работает.

Для риска «Квалификация участников команды проекта не соответствует поставленным задачам»:

• Вероятность высокая – скорее всего, раз в квартал, 30 баллов. Мы понимаем, что у нас, скорее всего, как со стороны бизнеса не соответствует квалификация. Так и со стороны исполнителя не соответствует квалификация.

• Понятно, что и влияние тоже очень высокое – если мы что-то сделаем неправильно, у нас будут потери. Например, мы разработали все по ТЗ, перенесли на прод, а там чего-то нет – потери составят, условно, миллион рублей, потому что придется дорабатывать, брать команду, финансировать ее. Причем потери будут в любом случае – все переделывать придется вне зависимости от того, как вы работаете – как инхаус или как внешний подрядчик. Обратите внимание, что потери здесь измеряются в рублях, и вы можете их менять в зависимости от масштаба проекта.

Также мне нравится тут четвертый риск: «Конечные пользователи не готовы к применению новой ИС».

• В данном случае я оцениваю вероятность в 100%, этот риск будет возникать ежемесячно.

• И влияние тоже максимальное.

И дальше в зависимости от условий своего проекта заполняем для всех рисков на закладке вероятность и влияние.

 

Тепловая карта – как основной инструмент формирования карты рисков

 

 

На закладке шаблона «4. Тепловая карта» находится тепловая карта – это ключевой инструмент для управления рисками. Недавно общался с коллегами из PricewaterhouseCoopers, они говорят, что у них при внедрении систем управления рисками в 100% случаев используются тепловые карты. То есть тепловая карта – это обязательное требование при внедрении систем управления рисками. Именно поэтому я сейчас вам про нее и рассказываю – ввожу вас в тему рисков именно с тепловой карты.

После того как мы проставим для рисков вероятности и влияния, мы нажимаем кнопку «Update chart data and labels», и оценки по каждому риску автоматически расставляются на тепловой карте.

• По оси X здесь измеряется вероятность – Likelihood.

• А по оси Y – влияние, Impact.

В нашем случае оценка производится в виде матрицы 4 на 4 – 10-20-30-40 на 10-20-30-40.

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

• Верхняя правая часть – это красная зона, Prevent. Эти риски мы должны смотреть в первую очередь – нам с ними нужно что-то сделать. Другие можно даже не смотреть.

• Нижняя левая часть – это зеленая зона, низкий контроль, Low Control. Мы этими рисками не занимаемся. Понятно, что это может произойти, но если это произойдет, у них влияние низкое. В этом и заключается суть зеленой зоны, что у нее одновременно и вероятность, и влияние – низкие.

• Все, что попадает в правую нижнюю часть – Monitor – мы должны мониторить, отслеживать.

• Все, что попадает в левую верхнюю часть – Detect – мы должны выявлять.

Мониторинг и выявление – это два очень важных термина в управлении рисками. Они прямо так и звучат. Если вы введете в поисковике «мониторинг рисков», он вам выдаст множество научных статей.

 

Немного подробнее о том, как работать с рисками в каждой зоне:

• Когда риск попадает в правый нижний угол тепловой карты, это означает, что у него высокая вероятность, но влияние низкое. Такие риски будут происходить постоянно, но ощутимого вреда проекту не наносят. Например, кто-то из сотрудников заболел или опоздал на работу на два часа. Это случается постоянно, и, конечно, влечет за собой некоторые затраты – мы платим человеку зарплату, а он временно не работает. Но на фоне бюджета проекта влияние этой проблемы незначительное. Эти риски нужно просто фиксировать – вести мониторинг. В этой зоне мы каждое проблемное событие фиксируем, но активных действий по ним не предпринимаем. В проектной документации или в статус-отчётах есть раздел «Риски» – туда и записываем все такие случаи: заболел сотрудник, не работал сервер, бизнес-заказчик опоздал на совещание и т.д. Чем больше таких мелких фактов вы будете фиксировать, тем больше данных у вас будет для последующего анализа.

• Верхний левый угол отвечает за риски, которые нужно выявлять. Это редкие, но серьёзные риски. Их сложно заметить, но при возникновении они могут нанести серьёзный ущерб. Например, изменения в законодательстве могут повлиять на реализацию проекта – чтобы их вовремя выявить, нужно назначить ответственного, кто будет следить за соответствующими источниками (например, за обновлениями в нормативных актах), чтобы не упустить важные изменения.

• А правая верхняя зона – самая «красная». Это риски с высокой вероятностью и высоким влиянием. Именно с ними нужно работать в первую очередь.

Наша задача – постараться переместить риски из красной зоны: либо снизить вероятность их наступления, либо минимизировать последствия.

Интересный момент – на тепловой карте сразу видно, куда ближе переместить риск, чтобы вывести его из красной зоны. Что проще снизить: вероятность или влияние. Часто уменьшить последствия бывает проще и эффективнее, чем пытаться полностью устранить вероятность наступления события. Это помогает нам сразу выбрать правильную стратегию управления риском.

Передвинуть риски по тепловой карте можно только двумя способами: первый способ – это мера; а второй – процедура внутреннего контроля. Других способов изменения рисков не существует.

• Мера – это конкретная работа, которая включается в план проекта. У нее всегда есть название работы, результат работы, ответственный исполнитель и срок исполнения.

• А процедура внутреннего контроля – это уже не разовая работа, а регулярно повторяемое действие, которое имеет периодичность: раз в день, неделю, месяц, квартал и т.д. У процедуры внутреннего контроля есть описание. Например, мы отслеживаем, что законодательство не изменилось – раз в месяц заходим на «Консультант Плюс» и отслеживаем изменения по такому-то федеральному закону.
  Результат процедуры внутреннего контроля может быть только положительный или отрицательный – как в программировании тип «Булево».
  Если закон изменился, значит, результат процедуры внутреннего контроля отрицательный. В этом случае это случившийся риск проекта – мы вносим его в раздел «Риски» статус-отчета, где фиксируются все сработавшие риски проекта: «Сотрудник опоздал на час», «Сервер не работал два часа», «Вышло обновление законодательства» и т.д.

Во вложении к докладу выложен, в том числе, пример статуса-отчета по проекту с правильной табличкой в разделе «Риски».

 

Теперь по каждому риску нужно продумать, как с ним работать – какие меры предпринять, какие процедуры контроля ввести.

Например, для риска: «Конечные пользователи не готовы к применению новой ИС» мы разрабатываем две меры и один контроль.

• Первая мера – выпуск приказа о начале проекта и внедрение KPI для рабочей группы со стороны бизнеса. Это дополнительная нагрузка для сотрудников, поэтому их нужно смотивировать, например, через премирование. Согласовываем такое решение с заказчиком и внедряем.
  Конечно, это повлияет не на всех, кто-то скажет: «У меня семья, дети, не собираюсь из-за вас ночью работать». Но на кого-то повлияет, человек согласится: «Ну да, мне это не нравится, но раз заплатят – сделаю». Значит, снизится и вероятность, и влияние этого риска.

• Вторая мера – добавляем в план проекта новую работу: демонстрацию новых интересных функций в рамках функционального моделирования. Мы их демонстрировать не планировали, они не особо нужны, но они современные и интересные. Например, мы используем искусственный интеллект, чтобы в выписке автоматически проставлялась статья ДДС. Пытаемся зажечь людей, чтобы им было интересно в проект войти – это тоже может сказаться на их вовлеченности.

• Третья мера – ставим процедуру контроля, которая раз в квартал проверяет наличие выплат по введенному KPI. Потому что мы придумали этот KPI, а на стороне заказчика могут забыть о начислении этой выплаты – мы контролируем, что выплаты действительно прошли.

И далее – оцениваем вероятность и влияние. Точно по той же схеме, как в начале было.

• Насколько реже произойдет риск в результате введения этой меры.

• И если риск все-таки произойдет, насколько влияние и вероятность этого события.

Формируем табличку с мерами и процедурами внутреннего контроля для каждого риска из «красной» зоны. В Excel-файле это закладка называется «3. Меры и ПВК». Там отмечаете эти работы – они должны соотноситься с вашей плановой декомпозицией работ в проекте.

И потом мы суммируем эффект от этих мер и вычитаем его от базовой оценки риска, которую делали ранее – у нас получаются новые значения.

На схеме это отображено как постепенное смещение точки риска: сначала немного, потом еще чуть-чуть, и в итоге риск переходит в зеленую зону – значит, мер принято достаточно.

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

Обратите внимание:

• Когда мы проработали меры для четвертого риска и вывели его в зеленую зону, с ним потом ничего делать не надо.

• А со вторым риском мы ничего не предприняли – он так и остался в критичной зоне. Это событие, которое происходит редко, но у него сильное влияние, его нужно обязательно выявлять.

 

Чтобы повторить это самостоятельно, заполните в шаблоне на закладке «Меры и ПВК» для каждого примера – что вы сделаете, чтобы снизить вероятность рисков.

Когда вы заполните меры, тепловая карта на четвертой закладке обновится автоматически – вы увидите, как изменилось положение каждого риска и сможете визуально проследить: насколько ваши меры были эффективны, и все ли вы учли.

Этот файл не нужно заполнять полностью самостоятельно – его нужно отдать всем своим экспертам, чтобы каждый заполнял отдельно. Потом вы данные по оценкам от каждого эксперта сводите – либо усредняете, либо вводите шкалу весов. Например, к кому-то из сотрудников больше доверия, к кому-то меньше. Вы можете сказать, что этот эксперт – гиперопытный архитектор, его мнение имеет вес 100. А аналитик менее опытный – его мнение имеет коэффициент 50, но мы его тоже учтем. И потом, когда этот файл сводите, просто через средневзвешенную формулу объедините и все, когда будете итоговый вариант оценки рисков делать.

 

Нужно ли вообще управлять рисками, платить деньги за управление рисками, добавлять в проект какие-то дополнительные работы?

Можно и не платить. Не хотите – не управляйте. Если у вас есть риск с высокой вероятностью и сильным влиянием (в «красной» зоне) – вы можете просто его зафиксировать и сознательно принять. Например:

• Мы выявили риск – видим, что у нас бомба.

• Оценили размер бомбы.

• И приняли этот риск – понимаем, что даже если «рванет», жить с этим вполне нормально.

В этом и суть – принимать риск можно. Главное – делать это осознанно.

• Если вы работаете на проекте у заказчика, я рекомендую заранее зафиксировать такие риски в договоре. Укажите список рисков и напишите: по этим рискам сторона не несёт ответственности, потому что решение о неуправлении ими принято совместно. Если риск сработал – все предупреждены, подрядчик свою работу выполнил, проект можно закрывать, никаких претензий.

• Если вы работаете на внутреннем проекте инхаус, лучше оформить это в виде служебной записки, протокола совещания или приказа, в котором перечислены все зафиксированные риски. Документ направляется спонсору или заинтересованным сторонам. Это ваша защита: вы всё рассчитали, предупредили – значит, свою ответственность выполнили.

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

 

Влияние рисков на бюджет проекта и договора

 

 

Что делать дальше, если риск принят

Важно понимать, что полностью избавиться от риска невозможно. Риск никогда нельзя уменьшить «в ноль» – у него всегда остается хоть какая-то вероятность и влияние. Даже если вы предпринимаете меры, риск может только сместиться, но не исчезает полностью.

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

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

Допустим, у нас риск – сотрудник заболел. Мы можем сразу заложить, что отсутствие одного человека обходится нам в 10 тысяч рублей в день. Это и будет часть планируемого бюджета на покрытие последствий.

Пример с болезнью – это упрощённый вариант, большинство расчетов сложнее, но мы их сейчас рассматривать не будем. А так – на слайде примеры приведены.

Когда риск срабатывает, важно сразу же фиксировать произошедшее в статус-отчёт – не раз в неделю, а каждый день, каждый час или полчаса. У вас должен быть шаблон отчета на неделю вперед, и как только что-то произошло – сразу заносите это в него.

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

Всегда что-то происходит, мы просто обо всем не знаем. Человек программировал, его отвлекли, позвали на совещание – из-за этого он не работал час, плюс на совещании пришлось кого-то ждать полчаса. А вы об этом просто не знаете. Или даже знаете, но нигде не зафиксировали. Поэтому фиксируйте всё.

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

Тезисно резюмирую все, что я уже упоминал насчет оценки:

• Первичную оценку рисков проекта мы проводим на этапе пресейла или при планировании проекта, если вы работаете инхаус.

• Затем при составлении договора или устава проекта – уточняем первичную оценку.

• И далее – каждый квартал переоцениваем. Это регулярная, обязательная процедура переоценки.

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

 

Управление рисками при еженедельных совещаниях на проекте

 

 

Запись статуса-отчета выглядит примерно так, как на слайде – просто чтобы вы понимали объем.

Слева – карточка одного произошедшего события у нас в программе по управлению рисками. В этой форме около 60 полей – когда люди уже более полноценно управляют рисками, они заполняют большие таблицы. Причем большинство событий выявляются автоматически – например, сервер не работал, а поскольку он к мониторингу Zabbix подключен, сюда события сразу же падают полностью автоматически. Такие инструменты уже встроены в современные программы по управлению рисками, это типовая функциональность. Мы сами разрабатываем такой продукт, и слайд как раз оттуда, чтобы вы понимали масштаб.

Если же вы работаете в Excel – там всё проще. В статус-отчёте я сделал упрощённую таблицу – всего 6–7 полей. Это самые базовые, обязательные для фиксации поля. Всё остальное – уже расширенная аналитика, которую можно добавлять по мере необходимости.

 

Следующий важный аспект – оценка потерь.

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

• Качественные – это когда точную сумму посчитать сложно или нецелесообразно. Например, команда простаивала час или день – чаще всего, это время простоя команды.

• Количественные потери – это те, что можно выразить в рублях. Например, мы кому-то заплатили, понесли прямые расходы. Такие потери можно разделить на потенциальные, чистые и косвенные.

  • Потенциальные потери – когда событие это не произошло, но произойдет. Например, юрист нашел, что у нас выходит новое законодательство. Оно еще не вышло, к последствиям еще не привело, но потенциально мы знаем, к чему примерно приведет ситуация, если мы ничего не предпримем.

  • Чистые потери – это когда мы реально заплатили деньги, и это документально подтверждено – есть акт, чек или платёжка о выплате ЗП.

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

Это нужно для того, чтобы вы понимали, как этим можно в будущем управлять.

 

Все данные по произошедшим событиям выводятся для анализа в отчетах. На слайде показан дашборд «Стакан риска» на 1С:Аналитика, который я разрабатывал с нашим методологом Петром Михайловичем Лансковым – можете об этом статьи почитать в интернете.

Красными столбиками на этом дашборде показаны события – сколько их происходило ежемесячно.

А зелеными столбиками – величина финансовых потерь. Здесь выделяется крупный инцидент, который фактически «съел» весь рисковый бюджет. На его фоне практически не видны другие маленькие потери, хотя их тут было множество.

И справа сверху здесь показан спидометр, который служит индикатором состояния проекта, подобно статусу «зеленый / жёлтый / красный» в статус-отчёте.

Общая сумма потерь, отображенная на спидометре – это израсходованный нами бюджет на риски. Сейчас спидометр показывает 1 467 000 рублей – это наши прямые чистые потери, то, что мы уже заплатили.

При этом общая сумма бюджета на риски – 5 200 070 рублей. Желтая зона на этом индикаторе показывает необходимость принятия управленческих мер. Например, если мы заложили бюджет на риски – 500 тысяч на один участок работы, 900 тысяч – на другой. Желтая зона показывает, насколько лимит превышен – это значит, что требуется пересмотр и и перепланирование бюджета.

Важно: в отличие от субъективных оценок «все нормально», этот график объективно показывает, когда проект входит в зону риска. Не нужно думать. Чтобы это работало, нужно просто регулярно фиксировать события – хотя бы по одному событию в день на каждого члена команды. Итоги потерь суммируются, и мы сразу видим, как это сказывается на бюджете.

Здесь нужно поговорить с командой и убедить их, что нужно фиксировать любые события, мешающие работе. Опоздание, сбой сервера, долгая загрузка dt-шника и прочее. Даже если кажется, что это мелочь – нужно фиксировать. Это помогает выявлять неочевидные риски и управлять простоем команды, т.к. простои – это зачастую самая значимая статья потерь, и фонд оплаты труда – одна из главных затрат проекта. Но это не единственное, что мониторится.

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

Вся эта отчетность обязательно должна быть представлена стейкхолдерам или спонсорам проекта – в частности, мы постоянно показываем им это в статус-отчётах. Более того, если проект в акционерном обществе, отчёты по 208-ФЗ – часть обязательной отчетности по закону, и спонсоры уже привыкли их видеть и анализировать.

Таким образом, вы заранее информируете их о развитии ситуации. Например, они видят: проект длится всего месяц, а треть рискового бюджета уже израсходована. И сами задают вопросы: «Что будем предпринимать?» – потому что для них это привычная часть бизнес-процессов.

Например, если мы заключили контракт на внедрение системы стоимостью 100 миллионов рублей, и 5 миллионов из этой суммы – это рисковый бюджет, он обязательно должен быть прозрачным и отслеживаемым. Если этот бюджет израсходован, несмотря на фикс-прайс и сроки, то вы как подрядчик можете это обосновать и перейти к обсуждению корректирующих действий.

 

То, что я сейчас показал – называется КИР, ключевой индикатор риска.

Когда он срабатывает, мы обязаны принять меры – здесь показаны примеры таких мер.

 

Ключевые действия в управлении рисками и порядок их применения

 

 

Этапы, которые здесь перечислены – обязательные, здесь нельзя ничего пропускать. Пропустили хотя бы один этап – и вся система управления рисками «посыпется».

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

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

Важно: если вы работаете в роли подрядчика по фиксированному договору – бюджет, предусмотренный на риски, можно «съесть» очень быстро. Особенно, если заказчик – это госструктура или крупная компания с медленными процессами. Простои, отмены совещаний, неготовность инфраструктуры – все это может сжечь заложенный резерв буквально за пару месяцев. А проект может длиться год.

Но команда же не будет работать бесплатно. И отказаться от проекта тоже нельзя, если договор подписан по Федеральному закону о закупках. Поэтому важно принимать меры – заранее включать в договор условия, позволяющие:

• пересматривать бюджет при наступлении определенных событий;

• пересматривать сроки;

• сокращать или пересобирать объем функциональности;

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

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

Есть термин «качественная оценка риска» – такую оценку можно проводить с помощью файла шаблона, который вы можете скачать во вложении к публикации. В акционерных обществах бизнес-заказчики уже привыкли заполнять такую форму. Применяйте и вы эту практику на своих проектах, чтобы они были более управляемыми и успешными.

 

Вопросы и ответы

 

Получается, мы оцениваем вероятность в самом начале проекта. Она остается статичной? Далее на протяжении жизненного цикла проекта мы ее не переоцениваем?

Обязательно переоцениваем. Периодичность переоценки зависит от размера проекта.

• Для того примера проекта, который я привел – полтора года проект с командой 40 человек – это ежеквартальная переоценка.

• Если проект более масштабный, можно проводить такую переоценку ежемесячно.

• А если проект более маленький, там можно переоценивать раз в полгода, например.

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

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

Ваш пример – это отрицательный риск, потому что у вас простой.

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

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

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

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

Но вообще есть конкретные методики расчета – они исходят из ГОСТ 31000.

Для начала просто экспертно оценивайте, как повлияет эта мера. В данном случае я субъективно оценил, что она даст минус 3, аля ежеквартально, но событие произойдет 2 раза за квартал, а не 3 раза.

И по влиянию на бюджет проекта тоже рассчитывайте от исходного значения. Если вы оцениваете, что мера даст результат -10 – было 40, а перейдет в 30 – это значит, что влияние будет сокращено с миллиона до 100 тысяч. Мероприятие уменьшит влияние на 900 тысяч. Но в баллах – на минус 10.

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

Получается, что совокупность этих цифр создаст нам буфер на борьбу с рисками? И главное, для чего мы это делаем – чтобы определить размер буфера на работу с рисками в проекте?

Не только. Главное – это определить работу, что мы должны сделать, чтобы снизить этот риск.

Безусловно. Мы понимаем объем риска, мы заложили в проект, дальше мы стараемся снизить риски, чтобы не исчерпать этот буфер, и за счет этого получить больше прибыли.

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

Этот буфер – это как раз часть этого мониторинга. Помните, что мы фиксировали риск, что у нас люди будут болеть – вопрос в том, сколько мы заложим туда денег.

Например, мы планируем, что кто-то из команды 10 недель точно не будет работать. Это большой, на самом деле, бюджет – 200-300 тысяч. И вы закладываете этот лимит на то, что будут люди болеть. Это факт просто. 100% будут болеть. Так формируется буфер.

А черные лебеди как-то закладываются в оценку рисков?

Черные лебеди никогда в риск-менеджменте не закладываются. Никогда. Это правило такое.

Если кто не знает, черный лебедь – это некое событие, очень редкое, но которое рушит проект полностью. Например, неожиданный уход главного заказчика из проекта посередине проекта. Мы делали в компании проект, а у нее поменялся владелец. Им теперь не нужно то, что мы делали, они будут свой ERP внедрять.

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

Как считается стоимость влияния? Откуда шкала берется? Как мы должны понять, что потеряем более одного миллиона рублей? Как мы считаем, сколько мы денег потеряем?

Например, мы работаем в SAP, оформляем в ней продажи, но у нас планируется проект – нужно перейти с SAP на ERP.

Мы понимаем, что когда наступит день X, и мы перейдем, может возникнуть риск остановки продаж – что-то пойдет не так, и мы не сможем оформить продажи.

Сколько наша компания оформляет продаж в день? Например, мы будем восстанавливать работоспособность контура продаж неделю. Сколько мы продаж делаем за неделю? Если у нас за неделю выручка миллиард, это значит, мы миллиард потеряем в выручке.

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

Получается, что мы здесь оцениваем ущерб заказчика, а не ущерб подрядчика. Т.е. даже если мы выступаем со стороны подрядчика, мы должны оценивать потери из-за нашего возможного «косяка» у заказчика?

Проект – это то, что заказчик и подрядчик делают вместе. И оценивается именно бизнес нашего заказчика.

Мы здесь думаем здесь о заказчике – о том, сколько заказчик потеряет в случае простоя, если система ERP не запустится.

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

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

А те риски, которые мы несем как подрядчик, оцениваются не на уровне отдельного проекта, а на уровне карты всей компании подрядчика.

Не отдельного проекта, а именно компании? Как тогда на уровне проекта рисками управлять?

Если мы подрядчик, у нас управление рисками – это отдельная карта вообще. Это такая же карта, только в рамках всего бизнеса подрядчика. Она может быть тоже разделена по проектам. Но риски там другие.

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

Все зависит от условий вашего договора. Редко между рисками заказчика и подрядчика есть прямая связь. Например, если из-за нашей ошибки на день остановился крупный завод, который на этом потерял миллиарды, это не значит, что нас автоматически оштрафуют на миллиарды. Что с подрядчика взять-то? Только обнять и поплакать с ним вместе. Я ни разу не видел, чтобы штрафовали. Не штрафуют.

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

Поэтому риски заказчика и риски подрядчика – это разные абсолютно карты.

Не очень понимаю целесообразность такого управления рисками. Как будто это больше нужно заказчику, а не мне, т.к. глобально эти риски как будто ко мне не относятся. Это заказчик должен быть в этом заинтересован, он свои деньги потеряет. Какая подрядчику выгода заниматься этой дополнительной работой для себя? По сути, мы включаем в бюджет проекта 5 дополнительных миллионов рублей на управление рисками, чтобы оказывать заказчику таким образом консалтинг?

Так и есть, проект внедрения – это консалтинг со стороны подрядчика. Подрядчику платят за то, что он делится опытом. Если бы заказчик мог бы сделать проект сам, он бы к подрядчику не обратился.

Например, заказчик 20 лет работает на старой системе, и сейчас переходит на ERP. Ему непонятно – делать ТЗ или не делать. А вы, как подрядчик, знаете: отсутствие ТЗ – это риск, потому что могут потеряться требования. Вы должны оценить, актуален ли этот риск для этого конкретного проекта, и принять решение.

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

Используете ли вы карту рисков как механизм влияния на стоимость проекта? Обсуждаете ли вы её открыто с заказчиком?

На рынке внедрения информационных систем карты рисков применяются редко. Это не столько ошибка, сколько уровень зрелости рынка – у нас риски часто не воспринимаются как ценность. Но в других отраслях всё иначе.

Например, один из наших клиентов – подрядчик по вывозу мусора – обратился к нам, потому что хотел участвовать в тендере, где в условиях было указано: участвовать могут только те, у кого внедрена система управления рисками (СУР). На некоторых рынках это уже обязательное требование.

Если аналогичные подходы доберутся и до ИТ-проектов, ценность управления рисками существенно возрастёт – и для заказчиков, и для подрядчиков. А с применением систем управления рисками будет увеличиваться вероятность успешности проекта.

А встречную карту рисков проекта вы от заказчика запрашиваете? Или это должна быть одна общая карта?

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

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

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

А кто участвует в ежемесячном или ежеквартальном пересмотре карты рисков? Нужно ли на эту встречу звать заказчика?

Это не встреча, это просто рассылка файла. Кому рассылать – решает команда проекта. Можно всем участникам, можно только экспертам.

Если хотите простоты, усредняйте оценки – и отправляйте файл только проверенным экспертам.

Если хотите более гибкую и точную модель, можно использовать взвешенные оценки: например, оценке эксперта присваивать вес 100, а менее опытному участнику – 10. Тогда его мнение тоже будет учтено. Возможно, один из участников что-то знает – например, юрист может знать про готовящийся законопроект, и внести высокий риск, который остальные просто не заметят. Его мнение может оказаться очень ценным.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.