УПРАВЛЕНИЕ РИСКОМ В ИНФОРМАЦИОННЫХ СИСТЕМАХ

 

Профессор Сергей Охрименко, МЭА

 

Как известно, прогноз риск-факторов в проектном менеджменте представляет сложную процедуру, конечные результаты которого не всегда совпадают с действительностью из-за невозможности учета влияния комплекса организационных, технических и других факторов, получивших название «подводных камней». На практике большинство руководителей ИТ-проектов сходятся во мнении, что недооценка данных «подводных камней» может привести к провалу проекта. Это означает, что необходимо прогнозировать сценарии с учетом разнообразных и разнонаправленных «опасностей», которые могут влиять на проект, определять их вероятность, средства и методы их устранения, время, необходимое для противодействия рискам и т.д.

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

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

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

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

Другим подходом может быть разделение рисков на две группы: оцениваемые и неоцениваемые. Именно неоцениваемые риски являются «подводными камнями» проектного менеджмента.

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

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

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

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

Основными фазами в управлении проектом выступают:

-         предложение-идентификация идеи или потребности;

-         первоначальное исследование и определение возможных требований и решений;

-         детальное исследование, изучение возможностей и определение выбранного решения;

-         развитие и тестирование предложенных решений;

-         испытание и апробация решений в реальных условиях;

-         окончание и ввод в действие решений.

Первые фазы управления проектом наиболее часто подвержены рискам.

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

На первом этапе важнейшей задачей является убежденность руководства и исполнителей в необходимости анализа и управления рисками (АУР). После этого приступают к выбору АУР-менеджера, который выполняет действия по планированию, руководит и координирует процессом анализа, готовит АУР-план в соответствии с условиями, временем и инвестициями в проект. Разработанная стратегия риск-анализа должна быть доведена до высшего управленческого звена и, по возможности, до каждого участника проекта. Именно осознание и сопричастность каждого участника проекта обеспечат успех в стратегии управления проектом.

В процессе идентификации рисков выдвигаются следующие задачи:

-         идентификация всех значимых типов и источников риска;

-         определение вероятности появления угроз;

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

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

В обязанности АУР-менеджера входит подготовка документации, которая включает список опасностей, их связей, ключевые параметры и действия, в результате которых создается «регистр» рисков. Данный регистр дополняется индикаторами степени опасности и строится «матрица-рисков», где каждому риску соответствуют этапы жизненного цикла проекта и, соответственно, возможные оценки (которые могут быть дополнены описанием конкретных случаев). Данная матрица является справочным материалом, но она должна быть дополнена другими средствами идентификации и управления рисками.

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

Для каждого риска необходимо подготовить оценку. Она может включать:

-         вероятность возникновения (для определенного интервала времени);

-         потенциальные последствия;

-         частоту появления во время жизненного цикла проекта и т.д.

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

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

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

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

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

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

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

Подобные изменения характерны при изменении условий технического обеспечения.

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

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

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

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

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

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

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

План управления рисками готовится и контролируется АУР-менеджером, в обязанности которого входит идентификация опасностей, определение их приоритетов, а также мер по их нейтрализации.

В тех случаях, когда фирма-проектировщик не разрабатывает ПУР (например, при реализации рутинных проектов), руководство обязано периодически проводить технические совещания для обсуждения вероятных опасностей провала проекта или отдельные проблемы должны сводиться к техническим задачам, решение которых передаются специалистам из команды, отвечающей за проект.

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

 

Литература

1.    Managing Information Security Risks: The OCTAVESM approach. Addison Wesley. 2002.

2.    Steve Purser. A Pracrical Guide to Managing Informational Security. Artech House Inc. 2004.

3.    Inside Network Perimeter Security. Sams Publishing. 2005.