Сергей Авдошин - Информатизация бизнеса. Управление рисками

Мера 1. Введение устройств для распознавания спецматериалов (в том числе керамики), идентификация пассажиров по отпечаткам пальцев, сканирование глазного яблока. Более тщательная проверка при регистрации путем использования общих баз данных предполагаемых преступников, ограничений на ручную кладь. Обозначим меру 1 как 6-ю преграду в дополнение к рассмотренным в предыдущем примере.

Мера 2. Подавление энергии взрыва на борту в багажном отделении. Это 7-я преграда.

Мера 3. Бронированная дверь в кабину пилота (или две двери, вторая открывается только после того, как будет заперта первая).

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

Мера 5. Специальная служба сопровождения полета. В то же время возможен обратный эффект – встретив сопротивление, угонщики могут детонировать взрывное устройство, а если террористам удастся разоружить охрану, у них появится дополнительное оружие. Практически это – 9-я преграда.

Мера 6. Специальные меры противодействия (временная разгерметизация, нелетальное воздействие). Реально это – 10-я преграда.

Все перечисленные меры кажутся на первый взгляд весьма внушительными, но насколько они эффективны? Действительно, их эффективность должна быть доказана количественно!

Результаты расчетов показали (см. рис. 42), что при реализации предложенных мер интегральный риск нарушения безопасности авиаполета в течение 5 часов террористических угроз равен 0,000004, а при возрастании длительности угроз до 5 суток риск повышается с 0,000004 до 0,002 (!). Даже с учетом существенной погрешности исходных предпосылок это – явный показатель эффективности дополнительных мер безопасности.

Проведенные расчеты позволяют сформулировать окончательный ответ на поставленный в примере вопрос. Итак, насколько реально может быть повышен существовавший до 11 сентября 2001 года уровень безопасности и за счет чего? Ответ: за счет реализации дополнительных мер противодействия террористам при контроле и на борту риск нарушения безопасности полетов может быть реально уменьшен с 0,47–0,48 до уровня ниже 0,002. То есть реализация вышеуказанных мер приводит к снижению риска нарушения безопасности на несколько порядков! Но это далеко не победа. Очевидно, что первые же неудачи заставят террористов анализировать их причины и искать новые недостатки системы безопасности, тем самым ожидается длительное противоборство. Успешным это противоборство может оказаться лишь тогда, когда будут приниматься упреждающие меры, эффективность которых может быть доказана или опровергнута с использованием математического моделирования.

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

За 50 лет развития программной инженерии накопилось большое количество моделей разработки программного обеспечения. Глава международной консалтинговой компании Atlantic Systems Guild Том Демарко в своей книге «Вальсируя с медведями: управление рисками в проектах по разработке ПО» пишет: «Проект без риска – удел неудачников. Риски и выгода всегда ходят рука об руку». Ведь проекты в области информационных технологий при информатизации бизнеса можно назвать одним из наиболее сложных типов проектов для управления. Для ИТ-индустрии характерны неопределенность при планировании, необходимость координации работ всех сотрудников во избежание конфликтов между менеджерами проекта, высшим руководством, главами вовлеченных в проект подразделений и персоналом предприятия.

Независимо от величины и масштабов бизнеса и ИТ-проекта руководство компании, планируя и достигая определенные цели, постоянно сталкивается с теми или иными управленческими проблемами – как спланировать работы во времени и успеть к определенному сроку, какие задействовать ресурсы и как добиться качественного выполнения в рамках бюджета. Обычно информация, используемая для управления программными проектами, берется из разрозненных приложений, а не из единого источника (например, отчетность из систем мониторинга ИТ-инфраструктуры, систем класса Service Desk, OSS-систем, систем управления проектами и т. д.). Кроме того, подобная информация зачастую представляет собой технические данные, которые еще необходимо преобразовать в бизнес-информацию, чтобы они могли быть понятны и использованы заинтересованными сторонами. Зачастую усилия по интеграции существующих инструментов, систем и источников данных для получения управленческой информации неосуществимы с точки зрения как ресурсов, так и капитальных вложений.