» — спрашиваете вы их. Они называют пожар, спортивные травмы, пищевые отравления, сексуальные домогательства со стороны учителей, обслуживающего персонала или посторонних взрослых людей, сексуальные опыты самих учащихся, наркотики, оружие, депрессию, ведущую к самоубийству, нападения на учителей и учащихся и т.п.
Среди перечисленных могут оказаться такие, которые не стоит пытаться включать в перечень рисков, требующих подготовительных действий («метеорит упадет прямо на здание школы, уничтожив ее вместе со всеми в ней находящимися»). Кроме того, будут и такие вопросы, где ваша ответственность далеко не очевидна. Например, «некоторые аспекты уроков по естествознанию могут подорвать религиозные устои учащихся». Относится ли это к рискам, с которыми вы должны справиться? Вы помечаете это отдельно и продолжаете вести мозговой штурм. После составления перечня вам нужно пройтись по списку и проделать следующий этап работы — качественный анализ рисков. Вам предстоит определить, какими рисками нужно управлять, а какими — нет, то есть провести ранжирование рисков. Для тех, которыми вы решили управлять, вам потребуется, по меньшей мере, выявить триггеры (симптомы наступления риска), составить план предварительных действий по ослаблению риска и оценить относительную значимость данного риска.
Когда мозговой штурм закончится, не стоит думать, что все готово. Вам захочется установить какой-нибудь постоянно действующий механизм (постоянный процесс выявления риска), чтобы выявлять новые риски, требующие контроля. Вам может понадобиться назначить кого-то ответственным за этот процесс (уполномоченный по контролю риска).
Составляющие управления риском
Абстрагируясь от этого конкретного примера, можно выделить пять основных составляющих управления риском:
• идентификация риска: первоначальный мозговой штурм по выявлению риска, последующая сортировка и определение какого-либо механизма для обеспечения постоянного действия данного процесса.
• анализ воздействия риска: количественная оценка каждого риска в терминах вероятности его наступления и потенциального ущерба.
• планирование реагирования на риски: что вы собираетесь делать, если и когда данный риск наступит.
• ослабление риска: меры, которые должны быть приняты предварительно, чтобы обеспечить возможность и эффективность проведения запланированных действий, если они потребуются.
• мониторинг и управление рисками: отслеживание рисков, выделенных в качестве объектов управления, выявление материализации рисков.
Первый пункт является действием общего характера, а остальные осуществляются по каждому из рисков.
Еще раз о том же
Управление рисками — то, чем большинство из нас занимается постоянно, причем везде, кроме своего рабочего места. В нашей личной жизни нам постоянно грозят болезни и ранняя смерть. Мы ослабляем риск, застраховав жизнь и здоровье и сделав распоряжения относительно того, кто позаботится о наших детях, если с нами что-то случится. Мы не притворяемся бессмертными и не делаем вид, что наша способность заработать себе на жизнь не может пострадать от какого-то несчастья. Каждый раз, когда мы взваливаем на себя новую ответственность (скажем, беря кредит под залог жилья), мы продумываем всякие возможные кошмары, которые могут приключиться, при этом надеясь, что ничего такого не произойдет, но заставляя себя продумать, что будет, если произойдет. Как мы увидим, управление рисками на рабочем месте включает несколько особых проблем.
Особая проблема немыслимых рисков
Некоторые риски, с которыми сталкивается проект, могут стать для него роковыми. Под этим мы понимаем крушение надежд и чаяний в первую очередь тех, кто дал жизнь этому проекту. Этими рисками особенно важно управлять, но разумное управление ими может привести к конфликту с установленными нормами корпоративной культуры. Ваш проект мог быть поставлен в жесткие временные рамки публичными, широко освещенными в прессе заявлениями первого лица компании о том, что продукт будет выпущен к определенной дате. Широко оповестив об этой дате, руководитель компании попытался сделать отставание от графика немыслимым.
Как известно, объявление нежелательного события немыслимым не делает его невозможным. Но это делает практически невозможным управление рисками. Рассмотрим пример в следующей главе…
Глава 3
Пересмотр истории международного аэропорта в Денвере
В городе Денвер (штат Колорадо) в 1988 году было принято решение построить новый аэропорт вместо существующего Стапльтонского аэропорта. Стапльтонский сочли неспособным к расширению, а в существующем виде он не отвечал потребностям растущего крупного города и способствовал все более очевидному загрязнению окружающей среды (а также был чрезмерно шумным). Новый аэропорт должен был стать более экономичным, покончить с загрязнением среды и задержкой рейсов и иметь возможности для необходимого роста. Новый Денверский международный аэропорт (ДМА) по графику собирались открыть 31 октября 1993 года. Так было запланировано.
Другая неприятность
Все было подогнано для того, чтобы поспеть к сроку: все шло отлично, но эти проклятые разработчики программного обеспечения опять подвели… 31 октября 1993 года весь огромный комплекс аэропорта был готов к пуску… по-честному готов. На самом деле. Можете поверить. Весь, кроме части программного обеспечения, и из-за нее аэропорт не мог открыться!
Точнее, не была готова вовремя злосчастная система автоматической обработки багажа. Аэропорт не мог открыться без работающего программного обеспечения для обработки багажа. Поскольку строительство аэропорта связано с огромными вложениями капитала, то весь этот капитал был заморожен, пока эти программисты второпях пытались играть в догонялки. А время — деньги. Это был прямой удар по налогоплательщикам. Тут не нужны замысловатые рассуждения, все просто, как на картинке:
И все это по вине тех самых отвратительных разработчиков программного обеспечения.
Такое упрощенное видение (деньги прямиком летят в контейнер для мусора) было характерно для освещения в газетах и журналах проблем ДМА с первого признака задержки в начале 1993 года до частичного открытия в 1995 году. Столько клеймили команду разработчиков, что и сегодня слова «система автоматической обработки багажа ДМА» — узнаваемый символ некомпетентного проекта по разработке программного обеспечения.
Статья в журнале «Scientific American» открыто возлагала ответственность за разочарования, связанные с ДМА, на всю отрасль разработки программного обеспечения с ее нечеткими стандартами и практикой:
«В сфере производства программного обеспечения годами (возможно, десятилетиями) ощущается нехватка зрелой технологической дисциплины, соответствующей требованиям информационного общества».
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Среди перечисленных могут оказаться такие, которые не стоит пытаться включать в перечень рисков, требующих подготовительных действий («метеорит упадет прямо на здание школы, уничтожив ее вместе со всеми в ней находящимися»). Кроме того, будут и такие вопросы, где ваша ответственность далеко не очевидна. Например, «некоторые аспекты уроков по естествознанию могут подорвать религиозные устои учащихся». Относится ли это к рискам, с которыми вы должны справиться? Вы помечаете это отдельно и продолжаете вести мозговой штурм. После составления перечня вам нужно пройтись по списку и проделать следующий этап работы — качественный анализ рисков. Вам предстоит определить, какими рисками нужно управлять, а какими — нет, то есть провести ранжирование рисков. Для тех, которыми вы решили управлять, вам потребуется, по меньшей мере, выявить триггеры (симптомы наступления риска), составить план предварительных действий по ослаблению риска и оценить относительную значимость данного риска.
Когда мозговой штурм закончится, не стоит думать, что все готово. Вам захочется установить какой-нибудь постоянно действующий механизм (постоянный процесс выявления риска), чтобы выявлять новые риски, требующие контроля. Вам может понадобиться назначить кого-то ответственным за этот процесс (уполномоченный по контролю риска).
Составляющие управления риском
Абстрагируясь от этого конкретного примера, можно выделить пять основных составляющих управления риском:
• идентификация риска: первоначальный мозговой штурм по выявлению риска, последующая сортировка и определение какого-либо механизма для обеспечения постоянного действия данного процесса.
• анализ воздействия риска: количественная оценка каждого риска в терминах вероятности его наступления и потенциального ущерба.
• планирование реагирования на риски: что вы собираетесь делать, если и когда данный риск наступит.
• ослабление риска: меры, которые должны быть приняты предварительно, чтобы обеспечить возможность и эффективность проведения запланированных действий, если они потребуются.
• мониторинг и управление рисками: отслеживание рисков, выделенных в качестве объектов управления, выявление материализации рисков.
Первый пункт является действием общего характера, а остальные осуществляются по каждому из рисков.
Еще раз о том же
Управление рисками — то, чем большинство из нас занимается постоянно, причем везде, кроме своего рабочего места. В нашей личной жизни нам постоянно грозят болезни и ранняя смерть. Мы ослабляем риск, застраховав жизнь и здоровье и сделав распоряжения относительно того, кто позаботится о наших детях, если с нами что-то случится. Мы не притворяемся бессмертными и не делаем вид, что наша способность заработать себе на жизнь не может пострадать от какого-то несчастья. Каждый раз, когда мы взваливаем на себя новую ответственность (скажем, беря кредит под залог жилья), мы продумываем всякие возможные кошмары, которые могут приключиться, при этом надеясь, что ничего такого не произойдет, но заставляя себя продумать, что будет, если произойдет. Как мы увидим, управление рисками на рабочем месте включает несколько особых проблем.
Особая проблема немыслимых рисков
Некоторые риски, с которыми сталкивается проект, могут стать для него роковыми. Под этим мы понимаем крушение надежд и чаяний в первую очередь тех, кто дал жизнь этому проекту. Этими рисками особенно важно управлять, но разумное управление ими может привести к конфликту с установленными нормами корпоративной культуры. Ваш проект мог быть поставлен в жесткие временные рамки публичными, широко освещенными в прессе заявлениями первого лица компании о том, что продукт будет выпущен к определенной дате. Широко оповестив об этой дате, руководитель компании попытался сделать отставание от графика немыслимым.
Как известно, объявление нежелательного события немыслимым не делает его невозможным. Но это делает практически невозможным управление рисками. Рассмотрим пример в следующей главе…
Глава 3
Пересмотр истории международного аэропорта в Денвере
В городе Денвер (штат Колорадо) в 1988 году было принято решение построить новый аэропорт вместо существующего Стапльтонского аэропорта. Стапльтонский сочли неспособным к расширению, а в существующем виде он не отвечал потребностям растущего крупного города и способствовал все более очевидному загрязнению окружающей среды (а также был чрезмерно шумным). Новый аэропорт должен был стать более экономичным, покончить с загрязнением среды и задержкой рейсов и иметь возможности для необходимого роста. Новый Денверский международный аэропорт (ДМА) по графику собирались открыть 31 октября 1993 года. Так было запланировано.
Другая неприятность
Все было подогнано для того, чтобы поспеть к сроку: все шло отлично, но эти проклятые разработчики программного обеспечения опять подвели… 31 октября 1993 года весь огромный комплекс аэропорта был готов к пуску… по-честному готов. На самом деле. Можете поверить. Весь, кроме части программного обеспечения, и из-за нее аэропорт не мог открыться!
Точнее, не была готова вовремя злосчастная система автоматической обработки багажа. Аэропорт не мог открыться без работающего программного обеспечения для обработки багажа. Поскольку строительство аэропорта связано с огромными вложениями капитала, то весь этот капитал был заморожен, пока эти программисты второпях пытались играть в догонялки. А время — деньги. Это был прямой удар по налогоплательщикам. Тут не нужны замысловатые рассуждения, все просто, как на картинке:
И все это по вине тех самых отвратительных разработчиков программного обеспечения.
Такое упрощенное видение (деньги прямиком летят в контейнер для мусора) было характерно для освещения в газетах и журналах проблем ДМА с первого признака задержки в начале 1993 года до частичного открытия в 1995 году. Столько клеймили команду разработчиков, что и сегодня слова «система автоматической обработки багажа ДМА» — узнаваемый символ некомпетентного проекта по разработке программного обеспечения.
Статья в журнале «Scientific American» открыто возлагала ответственность за разочарования, связанные с ДМА, на всю отрасль разработки программного обеспечения с ее нечеткими стандартами и практикой:
«В сфере производства программного обеспечения годами (возможно, десятилетиями) ощущается нехватка зрелой технологической дисциплины, соответствующей требованиям информационного общества».
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22