Две таблицы, которые ведут по-разному
Кирилл — проджект-менеджер. Он внедряет интеграцию с внешней системой: подрядчик, четыре месяца, приёмка в конце. Его рабочая неделя — это статус, в котором подрядчик отвечает «идём по плану», и ощущение, что на приёмке всплывёт требование, о котором никто не говорил.
Марина — операционный менеджер производственной компании на сорок человек. Ничего не «внедряется», всё просто работает: закупка, склад, отгрузка, закрытие месяца. Её рабочая неделя — это один бухгалтер, который умеет закрывать месяц, и поставщик упаковки с единственным складом.
У Кирилла риск живёт до сдачи проекта. У Марины он не кончается никогда и пересматривается по календарю. Горизонт разный, повод для пересмотра разный — метод один. Поэтому дальше каждый пример идёт парой: проектный и операционный.
Третий адресат этой лекции — предприниматель, у которого нет ни проектного офиса, ни риск-менеджера. Хорошая новость: весь аппарат, который здесь разбирается, работает на одной таблице. Плохая: таблицу придётся вести самому, и умирает она не от сложности, а от отсутствия даты следующего пересмотра.
Она не обещает, что ведение реестра снизит вероятность провала. Ни одно из приведённых здесь исследований этого не измеряло: они измеряют смещение прогнозов и корреляции, а не эффект внедрения реестра. Фраза «ведите реестр — и проект не сорвётся» была бы ложью.
Она не даёт юридических советов по договорам, страхованию и форс-мажору. Передача риска упоминается как одна из пяти стратегий — без разбора оговорок и условий полиса.
И она не утверждает, что вы обязаны вести реестр по ГОСТу. Национальные стандарты в России применяются добровольно; откуда берётся обязанность — разбирается в четвёртой теме.
Территория лекции — процесс: как риск находят, как записывают, как оценивают, что с ним делают и когда к нему возвращаются. Начнём с границы, за которой управлять уже нечем.
Реестр, в который пишут случившееся, не управляет ничем
Марина открывает файл «Риски». В нём двадцать две строки, и первые семь начинаются со слов «сорвана», «просрочено», «не отгрузили». Это не реестр рисков. Это журнал инцидентов с неправильным названием.
Различие между риском и проблемой проходит по двум признакам сразу — по времени и по вероятности. Риск — возможное будущее событие, вероятность которого меньше 100 %. Проблема (её же называют issue, инцидентом) — то, что уже произошло. Вероятность у неё единица, обсуждать нечего, остаётся устранять последствия.
У Кирилла: подрядчик может не передать API в срок.
У Марины: бухгалтер, закрывающий месяц, может уйти на больничный в отчётный период.
Есть вероятность, есть время, есть выбор мер. Ведётся в реестре рисков.
У Кирилла: подрядчик не передал API, приёмка сдвинулась.
У Марины: бухгалтер на больничном, отчётность не сдана.
Вероятности нет, есть последствия. Ведётся в журнале проблем.
Реализовавшийся риск перестаёт быть риском. Он переезжает из одного документа в другой, меняет статус и — это важно — оставляет след в карточке: сработал триггер, оценка была такой-то, мера была назначена или не была. Без этого следа реестр и журнал инцидентов живут в параллельных вселенных и не учат ничему.
«Реестр операционных рисков и стратегии реагирования до того, как сбой стал инцидентом». Вся эта тема — про слово «до». Строка, написанная после, не даёт ни одного дополнительного варианта действий.
Проверьте свой файл прямо сейчас: сколько строк в нём сформулировано в прошедшем времени. Если больше трети — вы ведёте журнал, а не реестр, и первое действие не «дописать риски», а разнести содержимое по двум документам.
Дальше нужен аккаунт
Прогресс и монеты сохранятся.