Превратности современного управления безопасностью. Риски. Увертюра

А вы, друзья, как ни садитесь...

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

Собственно само по себе управление рисками является, на мой взгляд, грамотным и адекватным методом, как минимум, распределения приоритетов защитных мер и аргументации принятия решений при обеспечении безопасности информации. Однако, учитывая последнюю моду - а иначе это и не назвать, - его принято внедрять везде и всюду, в любую деятельность, во все организации и структуры. Не обошла стороной эта тенденция и нынешнего клиента организации, в которой я работаю. Клиент этот, надо заметить, организация финансовая, поэтому информатизация в ней является именно что обеспечивающей сферой деятельности, услугой для бизнеса в нынешнем понимании сервисного подхода. Встала передо мной задача описать группу процессов (именно так, ни больше ни меньше) управления рисками проектов для сферы информатизации этой организации. Исходя из приближенной процессной модели, управление рисками там предполагается, состоит из нескольких процессов, практически соответствующих стандартам и методологиям управления рисками, ну и вообще востребовано и желанно. Необходимо только описать входы и выходы для процессов, т. е. определить реальные документы, поступающие на вход и получаемые на выходе, их цели, задачи и практическую пользу. Вроде бы всего делов-то, однако, ключевое слово здесь - РЕАЛЬНЫЕ документы.

В большинстве методик управление рисками какой-то деятельности заключается в их (рисков) идентификации, описании, анализе, выработке ответных действий и дальнейшем контроле и совершенствовании. Для управления рисками в рамках проекта существует целый ряд методических руководств, некоторых из которых стали стандартами де-факто. Одним из таких стандартов является Руководство по использованию свода знаний по управлению проектами (Project Management Body of Knowledge Guide, PMBOK Guide), разработанное Институтом проектного управления (Project Management Institute, PMI). Управление рисками представлено в рамках данного Руководства группой процессов, описанных, например здесь или особенно подробно (а если быть откровенным, то полностью содрано, назло всем сторонникам интеллектуальной собственности) здесь. Как любой другой межотраслевой общий стандарт (хотя Руководство все же позиционируется как стандарт в области управления ИТ проектами), PMBOK содержит массу исчерпывающих рекомендаций, использование которых практически нереально без помощи интеграторов, внедряющих управления в соответствии с данным Руководством за совсем несимволическую мзду. Поэтому при попытке применить к жизни и суровой отечественной реальности, испытываешь некий когнитивный диссонанс. Но это вроде как нормально - иначе интеграторам просто не за что было бы платить, достаточно было бы один раз заплатить за сам стандарт. Но с рисками ситуация, по-моему, иная.
Во-первых, сложность и условность организации самих процессов. К примеру, идентификация рисков проекта должна осуществляться уже после того, как будут определены такие аспекты проекта как этапность, сроки выполнения (например, технологический график проекта) и стоимостные показатели проекта. Потому что основная суть управления рисками в данном случае (возможно, и в любом другом, но сейчас речь идет конкретно про эту область знаний) - проанализировать влияние неопределенностей проекта на его характеристики и минимизировать его, меняя требования к проекту (содержание, работы, операции) и ограничения, заявленные спонсорами (бюджет, сроки, возможности технологий и т. д.). Следовательно, после определения основных составляющих проекта необходимо идентифицировать возможные неопределенности и либо изменить текущие ограничения, либо заложить допуски для изменения в дальнейшем. То есть в дальнейшем существует перспектива, что вследствие какого-то вероятного события придется изменить стоимость выполнения работ по проекту, привлечь больше сотрудников, или половину прогнать, а может быть проект затянется на срок в три раза дольше. И все это выяснится уже после того, как будут согласованы с заказчиками и исполнителями сроки, затраты и ресурсы.
Во-вторых, какими реальными документами можно формализовать эти действия? В Руководстве PMBOK предлагается как минимум три основных документа этой группы процессов - реестр рисков, план управления рисками и план реагирования на риски. В некотором роде это не совсем документы, их можно рассматривать в качестве управленческих сущностей, источников информации соответствующего типа. Однако, каждый из этих документов крайне спорен. Реестр рисков - это перечень идентифицированных рисков, с их характеристиками, результатами анализов: количественного и качественного, а также предварительные меры обработки этих рисков. Кто должен формировать этот документ? Не мифический менеджер команды управления рисками, а кто из участников реального проекта - заказчик, исполнитель, со-исполнители, отдельные эксперты? Кто будет заинтересован в дальнейшей привязке этих документов к реальности проекта, да так, чтобы потом можно было использовать эту информации в будущем, скажем, как часть базы знаний? План управления рисками - это документ, регламентирующий методические подходы к управлению рисками в проекте. Составлять для каждого проекта такой документ - сущее самоубийство, только если вы не строите каждую неделю по Большому адронному коллайдеру. Ну и наконец план реагирования на риски, согласно логике Руководства PMBOK, должен содержать необходимые изменения аспектов проекта для обхода рисков, выявленных или свершившихся. При этом исполнители различных работ проекта (одной или нескольких) должны ориентироваться на собственные планы и графики, игнорируя всяческие общие документы по рискам, качеству и прочим модным прибамбасам. Это нормально, это практика. Таким образом, данный документ просто содержит обоснование для изменения фундаментальных показателей проекта и соответствующих документов. Кто будет это делать, кто увидит в этом практический смысл? И насколько это допустимо в условиях реального бюджетирования, выделения времени, ресурсов и т. д.?

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