1.1. Информатизация бизнеса и специфика ИТ-отрасли

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

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

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

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

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

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

1) работа предприятий и их экономическая деятельность находятся в прямой зависимости от работоспособности средств автоматизации и общего уровня ИТ внутри предприятия;

2) качество ИТ определяет оперативность управлением – скорость обмена актуальной информацией, верность расчетов экономических показателей, возможности быстро принимать стратегические и прочие решения под воздействием внешних факторов, влияющих на экономическую систему;

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

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

Решение об информатизации бизнеса и переходе на новую информационную технологию должно приниматься на основе эффективности использования ИТ в данной области. В мировой практике затраты на информационные технологии связываются с оборотами компании и оцениваются в пределах 10–30 % от оборота. Естественно, что такой подход не дает ответа на главный вопрос: какие выгоды получит предприятие от использования анализируемых ИТ, – и не освобождает специалистов от необходимости расчета стоимости внедрения.

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

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

Успех ИТ-проекта зависит от многих факторов. Но из их числа можно выделить три основных: время, качество, ресурсы. Сбалансировать их между собой всегда трудно, поэтому популярна поговорка «Выбери два из трех». Если во главу угла ставится высокое качество исполнения всех работ по проекту, то это потребует либо много времени, либо большого числа ресурсов. Главная задача руководителя проекта – уложиться в выделенный бюджет и заданные сроки и обеспечить требуемое качество имеющимися трудовыми ресурсами. Любое нарушение этих ограничений чревато различного рода рисками, которые могут также привести как к негативным, так и к позитивным последствиям.

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

Рынок ИТ подразумевает большую скорость изменений. Быстроизменяющиеся внешние обстоятельства и непредсказуемые нагрузки осложняют задачу соответствия уровню сервиса.

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

Учитывая специфику ИТ-проектов, можно сформулировать основные принципы управления при информатизации бизнеса, которые позволят минимизировать (или избежать) наиболее распространенные риски при внедрении ИТ:

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

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

 привлекать независимых экспертов (не включенных в проектную команду) для оценки рисков. Если все решения по рискам проекта принимаются только людьми, которые мотивированы на успех проекта, многие технические и технологические трудности могут рассматриваться как несущественные;

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

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

В основном риски ИТ-проектов рассматриваются без стандартизированной методики управления рисками и общей системы управления рисками проекта ИТ.

На фоне постоянно улучшающихся технологий, создания новых методик разработки ПО рост успешности проектов из года в год незначительный – динамика успешности проектов за последние 14 лет практически не изменилась. Согласно статистике по поводу проектов ИТ и автоматизации предприятий, собранной международным агентством ИТ-услуг The Standish Group. СHAOS Summary 2009 (рис. 3):

• 32 % проектов завершились успешно;

• 44 % испытали различные трудности (превысили бюджет, выпали из сроков и прочее);

• 24 % проектов просто провалились;

• во всех завершенных проектах только 61 % требуемых свойств были реализованы.

Рис. 3. Статистика ИТ-проектов. The Standish Group. СHAOS Summary 2009

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

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

Еще одной очевидной причиной неудач в области ИТ-проектов является недостаточное внимание руководства к задаче управления рисками. Плохо выполненные задачи по идентификации и оценке рисков, отсутствие плана управления рисками, плана действий в случае возникновения непредвиденных обстоятельств, ответственных за тот или иной риск – все это негативно сказывается на реализации проекта внедрения информационных технологий.

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

В действительности методологические ограничения могут стать еще одной причиной неудач ИТ-проектов. По статистике Standish Group, с нехваткой технических знаний связано не более 10 % проблем в ИТ-проектах, остальные 90 % сводятся к неправильно организованному производственному процессу. К организационным и методологическим ограничениям можно отнести следующие:

• не используются стандарты управления;

• нет общей системы понятий и терминов;

• процессы проектной деятельности не определены;

• нет четких правил распределения ответственности в процессах проектной деятельности;

• опыт проектного управления не обобщается и не сохраняется.

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

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

 

1.2. Риски в ИТ: термины и определения

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

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

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

На сегодняшний день существует множество определений риска. Наиболее часто риск понимается в нескольких различных аспектах: риск как возможность, риск как опасность или угроза, риск как неопределенность. Так, в частности:

• риск как возможность – концепция существования взаимосвязи между риском и доходностью. Чем выше риск, тем выше потенциальный доход, но также выше и вероятные убытки;

• риск как опасность или угроза – концепция, которая рассматривает негативные события, такие как финансовые потери, мошенничество, хищения, угроза репутации, ущерб или банкротство, участие в судебных процессах и т. д. С точки зрения риска, мы имеем в виду некоторое негативное событие, которое может повлиять на успешное выполнение нашего проекта. Мы не уверены заранее в том, что это событие произойдет, но твердо знаем, что его возникновение скажется на стоимости, сроках или качестве проекта, то есть снизятся качество управления и надежность проекта. Цель управления – распределение ресурсов для сокращения вероятности нежелательных событий;

• риск как неопределенность – концепция, связанная с возможностью возникновения в ходе реализации проекта неблагоприятных ситуаций и последствий, которые зависят от вероятностных распределений возможных исходов. Цель управления – сокращение разрывов между принятым и действительным исходом.

Согласно стандарту (PMBoK) Института управления проектами США, определением риска является неопределенное событие или условие, наступление которого может иметь как положительное, так и отрицательное влияние на проект, что представляет собой комбинацию вышеперечисленных концепций.

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

В различных источниках можно встретить несколько определений риска, так, например:

 риск – потенциальная, численно измеримая возможность неблагоприятных ситуаций и связанных с ними последствий в виде какого-либо ущерба, связанная с неопределенностью;

 риск – это вероятностное событие, связанное с неопределенностью, которое негативно влияет на проект;

 риск – это взвешенная линейная комбинация вариации и ожидаемой величины (математического ожидания) распределения всех возможных исходов;

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

 риск – это как вероятная опасность, действие наудачу в надежде на счастливый исход (словарь Ожегова) и др.

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

В классических работах по управлению проектами понятия «неопределенность» и «риск» отождествляются. Однако в ряде западных современных работ в этой области различают понятия риска («Risk»), неопределенности («Uncertainty») и неизвестности («Ignorance»).

Согласно концепции Института программной инженерии (SEI), «риск сам по себе не плох; риск необходим для прогресса, и неудача – часто ключевой момент для обучения. Но надо научиться соотносить возможные негативные последствия риска с потенциальными выгодами от возможностей, которые с ним связаны».

Обобщение различных точек зрения позволило выявить следующие отличия между понятиями «риск» и «неопределенность»:

• неопределенность существует в тех случаях, когда вероятность последствий определяется субъективно, исходя из ограничений лиц, принимающих решения; риск определяется на основании объективного признания потерь;

• неопределенность связана с отсутствием стохастических данных за предшествующие периоды; риск характерен для экономических систем с массовыми событиями или предсказуемой вероятностью;

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

Причинами неопределенности могут являться:

• недостаток информации об условиях реализации проекта (например, из-за ограниченного времени на этапе планирования или сложности получения информации);

• наличие элемента случайности в условиях реализации проекта (например, состояние погоды в конкретный день);

• сознательное противодействие (например, действия конкурентов, принимаемые с учетом хода проекта).

Справедливо говорить о многообразии рисков, возникающих в процессе реализации ИТ-проекта. Основные риски, как правило, характерные для любых ИТ-проектов, заключаются в несоблюдении сроков реализации проекта, превышении стоимости и несоблюдении параметров качества.

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

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

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

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

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

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

Согласно методологии MSF (Microsoft Solution Framework), существуют четыре основные категории рискообразующих факторов: «люди», «процессы», «технологии», «внешние условия».

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

Вторая категория «процессы» содержит такие рискообразующие факторы, как цели и задачи проекта, процесс принятия решений, характеристики проекта (бюджет, затраты, сроки, требования) и ключевые этапы проекта (проектирование, реализация, тестирование).

К третьей категории «технологии» относятся безопасность разработки, среда разработки и тестирования, инструментарий, операционная среда и прочее.

В последнюю, четвертую категорию попадают внешние условия: законодательство, индустриальные стандарты, конкуренция, экономические условия, бизнес-условия.

 

1.3. Классификация рисков в ИТ-проектах

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

Классификация рисков означает систематизацию множества рисков на основании каких-то признаков и критериев, позволяющих объединить подмножества рисков в более общие понятия.

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

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

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

• одни и те же риски могут немного отличаться по содержанию для разных видов деятельности и разных типов проектов;

• на практике существует очень большое число различных проявлений риска, зависящих от специфики конкретного проекта и различных факторов;

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

• зачастую оказывается весьма сложным разграничить отдельные виды риска и четко сформулировать требования к определению видов риска;

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

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

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

1. Функциональные. К функциональной разновидности рисков относятся риски, определяемые функциональной направленностью, – то есть финансовые риски, риски подрядчиков, проектные риски, прочие.

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

3. Структурные. Структурные риски характеризуются управленческой структурой и этапами ИТ-проекта. На основании анализа структуры проекта можно выделить риски программирования, тестирования, отладки, прочего.

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

5. По областям управления. За основу берутся наиболее типичные области управления проектом, и выделяются риски, связанные с этой областью: риски интеграции, финансовые риски, временные риски, риски персонала, коммуникационные риски, риски несоответствия качеству, риски поставщиков и прочие.

6. По метрикам качества. Риски, связанные с возможным снижением качественных характеристик ИТ-проекта, такие как риски безопасности, доступности, производительности.

7. По другим специфическим признакам, например:

• по типу источника риска;

• по степени влияния и характеру последствий (критические/допустимые);

• по степени управляемости (контролируемые/частично контролируемые);

• по степени предсказуемости (предсказуемые/непредсказуемые);

• по области происхождения (известные/неизвестные, внешние/внутренние риски).

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

Рис. 4. Пример классификации рисков ИТ-проекта по степени управляемости

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

Основные риски, как правило, характерные для любых ИТ-проектов, заключаются в несоблюдении сроков реализации проекта, превышении стоимости и несоблюдении параметров качества. Часто причиной возникновения этих рисков, особенно в ИТ-проектах, является неготовность предприятия к реализации подобных проектов.

Далее опишем риски, характерные практически для всех ИТ-проектов.

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

Технологические риски. Характеризуют способность интегрируемого решения «корректно накладываться» на имеющуюся инфраструктуру и информационные потоки и часто связаны с единоличным принятием менеджером проекта решений по рискам (идентификация, анализ, выбор метода реагирования). Чем больше и сложнее проект, тем выше данный риск, особенно в масштабах промышленной организации. Говоря о минимизации технологических рисков, следует инвестиции делать более «короткими», а проекты дробить на несколько взаимозаменяемых составляющих. Это поможет избежать неприятных последствий при ошибочном инвестировании на одном из этапов.

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

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

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

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

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

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

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

В отдельных случаях целесообразно применять технику структурирования рисков с использованием структурной декомпозиции риска (Risk Breakdown Structure, RBS), сформированной по аналогии, группирующей риски по источникам появления и служащей для определения суммарного воздействия рисков.

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

Таблица 1.

Классификация рисков в зависимости от типов внедрения 

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

Формулировка риска – это «выражение на естественном языке причинно-следственной связи между реально существующим фактором проекта (текущим положением дел) и потенциально возможным, еще не случившимся событием или ситуацией».

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

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

Рис. 5. Формулировка риска, согласно методологии MSF

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

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

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

Эффективность управления зависит от правильного и полного понимания тех рисков, с которыми сталкивается проектная группа.

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

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

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

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

 

2.1. Зачем нужны стандарты и методологии управления рисками

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

К сожалению, не существует очевидных правил, утверждающих, в каком конкретном случае следует применять ту или иную методологию управления ИТ-рисками, – нужно выбрать ту методологию, которая максимально отвечает задачам ИТ-проекта. Для этого при выборе методологии надо решить, какую степень формализма вы хотите обеспечить, исходя из масштаба ИТ-проекта, количества участников и прочих факторов. Чем больше команда ИТ-проекта и чем шире география членов команды проекта, чем выше неопределенность проекта (например, используется новая технология или нестабильны требования к проекту), тем детальнее и формализованнее должна быть методология.

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

Если вдруг разрабатываемое для конкретного заказчика ПО планируется через пару лет заменить новым, то вряд ли имеет смысл тратить много сил на документацию, которая могла бы значительно удешевить длительный процесс сопровождения ПО. В этом случае ключевым аспектом выбора методологии будет являться наличие подробной методики и рекомендаций по разработке ПО (например, методологии RUP, MSF).

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

• как эталон организации процессов, выполнения работ;

• для обоснования существующей практики управления;

• как руководство по достижению целей (методология);

• для использования определений, классификаций, шаблонов, инструментов и прочего;

• для получения требуемых компетенций и существующего опыта управления.

Использование методологий позволяет менеджеру ИТ-проекта действовать более эффективно, то есть экономить время и ресурсы, направляет внимание команды на актуальные или перспективные проблемы, решение которых позволяет повысить эффективность внедрения.

С практической точки, методология управления ИТ-проектами может включать следующие характерные компоненты: подходы, критерии, методы и средства управления, инструменты, шаблоны документов и прочее.

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

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

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

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

Методология подсказывает (в том числе на базе применяемых подходов, критериев и т. п.), какие именно подходы, инструменты, методы и средства, шаблоны целесообразно задействовать.

 

2.2. Обзор методологий: достоинства и недостатки

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

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

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

Среди всего многообразия стандартов принято выделять следующие основные типы стандартов.

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

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

Основными разработчиками международных стандартов являются организации ISO (International Organization for Standardization) – Международная организация по стандартизации, IEC – Международная электротехническая комиссия и PMI (Project Management Institute) – Международный институт проектного менеджмента (управления проектами).

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

К наиболее известным отраслевым стандартам для ИТ-индустрии можно отнести стандарты IEEE – Института инженеров по электронике и SEI (Software Engineering Institute) – Института программной инженерии.

Государственные стандарты (ГОСТы) принимаются государственными органами, имеют силу закона. Разрабатываются с учетом мирового опыта или на основе отраслевых стандартов. Могут иметь как рекомендательный, так и обязательный характер (стандарты безопасности). Для сертификации создаются государственные или лицензированные органы сертификации.

Для построения обобщенной классификации выделим следующие группы методологий управления и внедрения ИТ:

1) стандарты оценки и управления информационной безопасностью: ISO/IEC 27000/17799, BS 7799;

2) методологии ИТ-аудита: COSO, CobiT, SAC, SAS 55/78;

3) универсальные методологии: ГОСТ 34, PMI PMBOK, IPMA ICB, P2M, PRINCE2;

4) методологии внедрения ПО и управления в сфере ИТ: CobiT, SWEEBOK, MSF, RUP, CMM/CMMI (SEI), ORACLE AIM, ITIL, CRAMM, CORAS, OCTAVE.

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

1. Стандарты оценки и управления информационной безопасностью. Семейство международных стандартов по информационной безопасности в области информационных технологий ISO/IEC 27000/17799, основанное на Британском стандарте BS 7799, включает в себя требования к системам управления информационной безопасностью, управление рисками, метрики и измерения, а также руководство по внедрению. В стандарте описаны жесткие требования к разработке, внедрению и совершенствованию Системы управления информационной безопасностью (СУИБ) и рекомендации к внедрению мер контроля и управления рисками, основанные на «лучших практиках».

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

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

Управление рисками в жизненном цикле программных проектов специально регламентировано международными стандартами ISO 12207 «Процессы жизненного цикла программных средств» и ISO 15504 «Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем», которые целесообразно использовать при разработке комплексов программ. В стандарте ISO 15504 содержится специальный раздел «МАН.4. Процесс управления рисками», назначением которого являются регламентирование и планирование процессов выявления и устранения рисков на протяжении всего жизненного цикла программного продукта.

2. Методологии ИТ-аудита. Методология COSO является примером международной практики по управлению рисками на уровне всей организации. В основах COSO заложен принцип системы внутреннего контроля, позволяющий организации выявлять недобросовестное использование информации, злоупотребление данными, искажение финансовой отчетности. Функция аудита заключается в постоянном надзоре и контроле за деятельностью организации с целью обеспечения более высокой степени надежности и достоверности информации.

Методология CobiT предоставляет методологию для корпоративного управления ИТ с отдельно выделенной книгой по ИТ-аудиту. Усиленное внимание аудиту ИТ в методологии объясняется тем, что первоначально CobiT разработан Ассоциацией аудита и контроля информационных систем (ISACA). Методология содержит подробное описание этапов, принципов и правил проведения ИТ-аудита, описание того, у кого можно получить необходимую информацию, как ее проверить, какие вопросы задавать.

Методология CobiT предоставляет огромные преимущества при проведении ИТ-аудита и внедрении корпоративного управления ИТ за счет обобщения лучших практик и международных стандартов и постоянного совершенствования. Электронная версия методологии постоянно обновляется и доступна, в том числе на русском языке, на сайте ISACA.

3. Универсальные методологии: ГОСТ 34.X, PMI PMBOK, IPMA ICB, P2M, PRINCE2. ГОСТ 34 является универсальным стандартом в области информационных технологий и объединяет комплекс стандартов на автоматизированные системы. Эти стандарты широко используются государственными предприятиями и зачастую служат основой проектной документации при разработке и использовании ИТ. Масштабность стандарта позволяет разработчикам ПО получить формализованный ответ практически на любой вопрос, который может возникнуть при внедрении. Вопросу управления рисками также уделено внимание, однако из-за масштабности ГОСТа и отсутствия структурированного описания этапов и методов управления рисками могут возникнуть сложности с поиском требуемой информации.

Общие методы анализа рисков в сложных системах регламентированы стандартом ГОСТ Р 51901 – «Управление надежностью. Анализ риска технологических систем». Основной задачей стандарта является обоснование решений, касающихся анализа риска реализации проектов и технологий сложных систем. Хотя стандарт и не направлен исключительно на проекты разработки программного обеспечения, изложенные в нем рекомендации могут быть применены в ИТ-проектах.

Методология PMBoK (Project Management Body of Knowledge), разработанная американским Институтом управления проектами PMI, прекрасно описывает все ключевые области управления проектом: управление коммуникациями, качеством, персоналом и в том числе управление рисками. PMBoK является сводом знаний по управлению проектами и предоставляет детальные инструкции по каждой области управления. Раздел «Управление рисками» содержит подробное описание этапов управления рисками, входной и выходной информации, методов и средств по каждому этапу. Поскольку изначально методология рассчитана на управление универсальными проектами, ее нельзя назвать специфичной в области ИТ и ориентированной на управление рисками ИТ-проектов. Однако стоит отметить, что руководители охотно пользуются данной методологией, учитывая специфику ИТ-проектов и адаптируя методы и средства управления под конкретные нужды ИТ.

4. Методологии внедрения ПО и управления в сфере ИТ: CobiT, SWEEBOK, MSF, RUP, CMM/CMMI (SEI), ORACLE AIM, ITIL, CRAMM, CORAS, OCTAVE. SWEBOK (Software Engineering Body of Knowledge) – это руководство к своду знаний по программной инженерии, в котором собраны основные теоретические и практические знания, накопленные в отрасли программной инженерии. Наравне с идеями общего управления рисками SWEBOK предлагает управлять рисками, уникальными для деятельности в области программной инженерии. Например, тенденция добавлять в получаемый программный продукт функциональные и другие возможности, не определенные на уровне требований, или риски, заложенные в самой природе программного обеспечения, связанные в первую очередь с его сложностью и архитектурно-технологической новизной, присутствующей в той или иной степени в любом программном проекте. В части управления рисками SWEBOK рекомендует проводить идентификацию и анализ рисков, оценку критических рисков и что необходимо сделать, чтобы их избежать, – шаги по смягчению рисков и планированию непредвиденных обстоятельств.

Наиболее признанная методология Microsoft Solutions Framework (MSF) представляет собой пакет руководств по эффективному проектированию, разработке, внедрению, тестированию и сопровождению ИТ-решений ПО. Знания базируются на опыте Microsoft, методология популярна среди разработчиков. Благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена для широкого круга ИТ-проектов.

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

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

Согласно аннотации, приведенной в методологии: «После прочтения данного документа проектная группа, имеющая опыт применения MSF, должна быть способна превентивно управлять рисками ИТ-проектов. Тем же, кто не знаком с процессом управления рисками в ИТ-проектах, этот документ дает базовое понимание концепций, терминологии и принципов, необходимое для внесения собственного вклада в управление рисками во всем жизненном цикле ИТ-проектов». Огромным преимуществом является доступность методологии на сайте Microsoft, в том числе на русском языке.

Еще одна известная методология Rational Unified Process (RUP) представляет собой целостную модель организации процессов разработки программного обеспечения и успешно применяется в ИТ-проектах любых типов и объемов. Методология опирается на проверенные практикой методы анализа, проектирования и разработки ПО, методы управления проектами. RUP описывает итеративную схему процессов, разработанную в Rational Software. Итеративная разработка является ключевой особенностью методологии, поскольку позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта. Сокращение рисков является основной целью методологии RUP.

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

Группа стандартов CMM/CMMI была создана Институтом программной инженерии SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Основная идея стандарта состоит в использовании модели CMM/CMMI (Capability Maturity Model / Integrated – модель зрелости возможностей) для приписывания каждой организации определенного уровня, с тем чтобы организации можно было бы сравнивать по уровням. Деление на уровни позволяет последовательно внедрять CMM/CMMI, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки. Для достижения стандартов рекомендуется использовать специализированные процессы разработки программного обеспечения: Personal Software Process / Team Software Process. Последовательное применение модели PSP/TSP дает возможность сделать нормой в организации наиболее зрелый (пятый) уровень CMM. Акцент поставлен на непрерывное управление рисками, которое, согласно определению Института программной инженерии, представляет собой инженерно-техническую подготовку программного обеспечения с процессами, методами и средствами для управления рисками в проекте. Согласно методологии, существуют семь принципов, которые обеспечивают основу для эффективного управления рисками: Глобальная перспектива, Обзор вперед, Открытые связи, Комплексное управление, Непрерывный процесс, Коллективное видение продукта, Командная работа.

Помимо стандартов CMM/CMMI, Software Engineering Institute разработал модель управления рисками при разработке программного обеспечения, частично вошедшую в PMBoK Guide 2000, включающую в себя как требования упомянутых стандартов, так и известные «хорошие практики» (best practices) управления рисками. Подготовку управления рисками проекта эта модель рекомендует проводить в следующей последовательности:

• постановка целей управления рисками в соответствии с целями проекта;

• планирование и координация работ по оценке рисков проекта (выделение группы экспертов для оценки рисков, подготовка и планирование интервью с исполнителями с целью выявления рисков в результате их деятельности);

• идентификация и оценка рисков (обнаружение возможных рисковых ситуаций и оценивание влияния рисков на проект);

• подготовка к устранению рисков (разработка мероприятий по сокращению или устранению рисков и подготовка отчета с 235 рекомендациями для руководства проекта по анализу и управлению рисками);

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

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

К специфичным методологиям, уделяющим большее внимание управлению рисками ИТ-проектов, нежели процессу разработки программного обеспечения, можно отнести CRAMM и CORAS.

Методология CRAMM разработана британским Центральным компьютерным и телекоммуникационным агентством в 1985 году, применяется в области управления ИТ-рисками как для крупных, так и для небольших организаций правительственного и коммерческого сектора. CRAMM предполагает использование технологий оценки угроз и уязвимостей по косвенным факторам с возможностью проверки результатов. Для оценки рисков в методологии используется механизм моделирования информационных систем с позиции безопасности с помощью обширной базы данных по контрмерам. Компания Siemens предлагает программную реализацию методологии и представляет продукты CRAMM Expert и CRAMM Express.

Методология CORAS разработана в рамках программы Information Society Technologies. Ее суть состоит в адаптации, уточнении и комбинировании таких методов проведения анализа рисков, как Event-Tree-Analysis, цепи Маркова и прочие. В соответствии с CORAS информационные системы рассматриваются не только с точки зрения используемых технологий, но и с нескольких сторон, а именно как сложный комплекс, в котором учтен и человеческий фактор. Методология получила программную реализацию в виде Windows– и Java-приложений.

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

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

 

2.3. Риски при использовании методологий разработки ПО

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

В зависимости от назначения проектный менеджер выбирает наиболее подходящие для разработки и управления ПО модели зрелости и процессные модели, проектные методологии и индивидуальные и групповые практики. Универсальные концепции, а также управленческие стандарты, например серии ISO 9000, аккумулируют опыт и лучшие управленческие практики, которые стали основой методологий совершенствования деятельности компаний-разработчиков, таких как модели зрелости (CMM/CMMI), стандарты оценки и улучшения процессов (SPICE) и прочие. Объектами стандартизации в сфере ИТ являются:

• конструкторская документация (состав, структура, требования к оформлению);

• стандарты кодирования и оформления программных текстов;

• терминология и определения;

• модели процессов;

• модели жизненного цикла;

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

• качество программного обеспечения, характеристики качества, методы получения данных по качеству;

• графические и нотации и инструменты формализованного описания требований и технических решений;

• форматы хранения данных, обмена и передачи данных.

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

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

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

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

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

Для долгосрочных проектов, как правило, подходят «более тяжелые» и формализованные методологии, такие как MSF, RUP, CMM-SE. Тяжелые методологии дают наибольший эффект в крупных компаниях, занятых промышленным выпуском ПО и готовых на многолетние инвестиции в кардинальную перестройку организационной структуры. Такие подходы обычно дают очень хорошие результаты, но процесс внедрения растягивается на несколько лет. Стоимость использования подобной методологии достаточно высока. Для тяжеловесных методологий необходимо детальное планирование большого объема разработок, что является достоинством методологии. Однако в ряде случаев такая детальность планирования является излишней и не оправдывает затраченных ресурсов.

Методология RAD (Rapid Application Development) идеально подходит для быстрой разработки приложений (до 6 месяцев) с использованием ограниченной команды специалистов. Поскольку методология предполагает активное вовлечение пользователей в процесс разработки, отсутствие базовых навыков в области информационных технологий может стать ключевым риском в процессе разработки. Фаза построения и разработки приложения происходит крайне быстро, поэтому существуют определенные риски внесения изменений – дополнительных требований и пожеланий, которые практически невозможно реализовать из-за ограниченных сроков реализации. Также методологии быстрой разработки приложений и экстремального программирования (XP) характеризуются наличием сильного менеджера проекта. Его роль становится ключевой, поэтому крайне важно уделять внимание организационным аспектам, взаимодействию коллектива, компетентности команды.

По сравнению с монументальными методологиями, в гибких (Scrum, Crystal, Open Source, ASD) очевидно прослеживается меньшая ориентация на документацию, что выражается в меньшем ее объеме для каждой конкретной задачи. Легкие методологии дают возможность обрабатывать большие объемы информации, относящиеся к проекту, в процессе неформального, непосредственного, личного общения, а не с помощью документации. При этом отсутствие документации может быть ограничением использования методологии в государственных учреждениях или организациях, требующих высокой степени формализации и документирования. Поскольку практически все гибкие методологии ориентированы на максимально неформальный подход к разработке, зачастую возможны спорные вопросы при реализации тех или иных изменений, расстановке приоритетов.

При этом легкие методологии также отличаются друг от друга – Crystal призывает совмещать производительность и толерантность, в отличие от ХР, где продуктивность возрастает как раз за счет уменьшения толерантности. Методология «Adaptive Software Development» разработана специально для крайне нестабильных ситуаций в разработках, когда требования, проектирование и невозможно короткие сроки являются функциями друг друга и постоянно меняются (так зачастую происходит в веб-разработках). Scrum характерен активным воздействием внешних лиц по отношению к рабочей группе, при этом у заказчика сохраняется максимальный приоритет. Заказчик продукта сам решает, как оформить бэклог продукта, выбирает требования для следующей итерации. При этом несоблюдение базовых принципов, заложенных в Scrum, таких как самонаправляемые команды, обязательная расстановка приоритетов или еженедельные обновления, может привести к срыву проекта.

 

2.4. Риски в жизненном цикле программного обеспечения

Анализ методологий в области разработки ПО и опыт менеджеров ИТ-проектов подсказывает, что для эффективной реализации ИТ-проектов обязателен анализ жизненного цикла.

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

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

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

Существует множество видов моделей жизненного цикла ПО. Поскольку универсальной модели нет, разработчики нередко прибегают к комбинированию моделей, чтобы использовать возможные преимущества. Как правило, все модели включают все стадии ЖЦ ПО и связаны с методологиями проектирования (модель синхронизации и стабилизации – MSF, каскадная и спиральная модель – RUP и т. д.).

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

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

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

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

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

Рис. 6. Спиральная модель

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

 

3.1. Понятие качества и его многомерность

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

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

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

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

1. Готова ли компания запустить приложение в эксплуатацию и все ли бизнес-процессы работают так, как было запланировано?

2. Обеспечены ли прозрачность и контроль над изменениями в приложении?

3. При возникновении проблем в эксплуатации можно ли их быстро выявить и устранить?

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

Говоря о качестве ИТ-проекта, следует отметить, что не существует единой метрики качества. Это объясняется тем, что не всегда можно однозначно ответить на вопрос, какие характеристики важнее – применение ПО, его производительность, результаты использования, стоимость и время разработки или же удовлетворение коммерческим требованиям.

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

Рис. 7. Пример метрик качества ПО

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

• надежность (Reliability) – вероятность работы системы без сбоев в течение определенного периода времени. Надежность ПО включает такие элементы, как отказоустойчивость, то есть возможность восстановления программы и данных в случае сбоев в работе, безопасность и защищенность от случайных или преднамеренных внешних воздействий (защита от вирусов, спама);

• устойчивость к сбоям (Robustness) – уровень, до которого система продолжает корректно выполнять свои функции, несмотря на неверный ввод данных, недостатки подключенных программных компонентов или компонентов оборудования;

• производительность (Performance) – характеристика того, насколько быстро и качественно система должна выполнять определенные операции;

• взаимодействие (Interoperability) – каким образом система, приложение или сервис обменивается данными с другими системами, приложениями, сервисами;

• эффективность (Efficiency) – объем вычислительных ресурсов, необходимых для выполнения функций. ПО не должно впустую тратить системные ресурсы, такие как память, процессорное время, каналы связи. Поэтому эффективность ПО оценивается следующими показателями: время выполнения кода, загруженность процессора, объем требуемой памяти, время отклика и т. п.;

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

• доступность (Availability) – запланированное время доступности, в течение которого система действительно доступна для использования и полностью работоспособна;

• целостность и защищенность (Integrity) – возможность блокировки неавторизованного доступа, предотвращение потери или порчи информации, сохранение конфиденциальности информации.

Для разработчиков и ИТ-персонала, как правило, важны другие атрибуты качества:

• сопровождаемость (Maintainability) – означает, что программа должна быть написана с расчетом на дальнейшее развитие. Сопровождаемость включает такие элементы, как наличие и понятность проектной документации, соответствие проектной документации исходному коду, понятность исходного кода, простота изменений исходного кода, простота добавления новых функций и возможностей;

• легкость эксплуатации (Maintainability) – насколько удобно исправлять ошибки или модифицировать систему, то есть трудозатраты на эксплуатацию, устранение ошибок;

• переносимость (Portability) – усилия, необходимые, чтобы перенести систему из одной аппаратной или программной среды в другую;

• возможность повторного применения (Reusability) – насколько данный продукт может быть использован в другом применении;

• способность к тестированию (Testability) – усилия, необходимые, чтобы убедиться в соответствии выполняемых функций установленным требованиям и соответствующим трудозатратам;

• масштабируемость – насколько легко наращивать количество пользователей или объемы данных в системе.

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

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

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

 

3.2. Основные проблемы и ключевые факторы успеха ИТ-проектов

 

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

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

По статистике Standish Group, причины неудач ИТ-проектов заключаются в следующем:

1) неполные требования;

2) недостаточная вовлеченность пользователей;

3) нехватка ресурсов;

4) нереалистические ожидания;

5) недостаточная поддержка руководства;

6) изменение требований и спецификаций;

7) недостаточное планирование;

8) технологическая некомпетентность персонала;

9) нехватка квалифицированных менеджеров проектов.

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

Таблица 2.

Причины неудач ИТ-проектов и способы их предотвращения 

Рассматривая проблемы при внедрении ИТ-проекта, следует разделять проблемы:

• на этапе принятия решения о внедрении ИТ и выбора программного продукта;

• на этапе планирования ИТ-проекта;

• на этапе внедрения ИТ.

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

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

Эффективным способом устранения множества проблем на этапе принятия решения о выборе и целесообразности внедрения ИТ является проведение обследования предприятия на предмет выявления и документирования первоочередных задач, которые должна выполнять новая технология или система. Целесообразны определение структуры и исходного состояния объекта автоматизации, определение масштабов и сложности внедрения ИТ.

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

На этапе внедрения ИТ выявлено наибольшее количество проблемных областей, а именно:

• отсутствие упорядоченных, формализованных бизнес-процессов или их недостаточная формализация;

• отсутствие в компании единой нормативно-методологической базы;

• увеличение нагрузки на персонал (возрастание ответственности, появление новых обязанностей) в процессе внедрения или после его завершения;

• неучастие в проекте руководителей высшего звена, отсутствие поддержки внедрения со стороны отдельных ключевых участников проекта (финансового директора, главного бухгалтера, начальника отдела сбыта и прочих);

• сопротивление всего или значительной части персонала самому внедрению и сопутствующим нововведениям;

• несоответствие конкретных бизнес-процессов предприятия эталонным процессам, реализованным в учетно-управленческой системе;

• затрудненная интеграция ИТ-системы с уже имеющимися на предприятии системами автоматизации управления.

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

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

 

Вовлеченность сотрудников

Часто ответственность за ИТ-проект полностью перекладывается на ИТ-отдел, потому что заказчики находятся в плену иллюзии: «закончите полностью – тогда покажете».

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

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

 

Оценка рисков проекта

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

 

Измерение результативности проекта

Аккуратная отчетность по проекту – это звучит просто, но на деле оказывается немалой проблемой. Реальность такова, что отчеты о статусе ИТ-проектов чрезмерно оптимистичны. Главная проблема здесь в том, что приукрашенный отчет гораздо удобнее для всех отделов, так как дает чувство устойчивого прогресса. Однако большинство сложностей, с которыми сталкиваются ИТ-проекты, можно преодолеть различными управленческими решениями. По мере того как проблемы возникают, менеджмент будет искать способы уменьшить негативные последствия и устранить источник этих проблем, однако давление, которое развивается в эти моменты, чаще всего изменяет ход проекта.

Для обеспечения успеха проекта сформулируем критические факторы успеха (КФУ) ИТ-проекта, то есть факторы, реализация которых позволит выполнить ИТ-проект в срок, в рамках бюджета, с заданным качеством:

1) наличие четких целей внедрения;

2) обязательное участие высшего руководства заказчика в процессе разработки системы и ее внедрения;

3) все сотрудники должны четко осознавать необходимость внедрения ИТ, оказывать посильную помощь, обучаться работе с ИТ;

4) участие всех ключевых пользователей системы в формулировке требований, разработке, тестировании, внедрении системы;

5) управление качеством и введение системы изменения результативности на основе показателей эффективности;

6) управление рисками на всех этапах ЖЦ проекта и своевременная минимизация рисков;

7) формирование единого глоссария терминов в области управления ИТ-рисками и установление единого «языка» общения между ИТ и бизнесом.

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

 

3.3. Влияние изменений на риски ИТ

Главными источниками ИТ-рисков считаются большой объем изменений, возрастающая сложность систем, а также бреши в системах безопасности, которыми пользуются хакеры, – говорится в отчете HP за 2008 год по результатам глобального исследования, в котором приняли участие 1125 ИТ-специалистов из 20 стран. Один из четырех респондентов констатировал, что 50 % вынужденных простоев обусловлены изменениями. Это значит, что для многих ИТ-организаций жизненно необходимы предсказуемость их деятельности и управление изменениями. Добиться успеха смогут лишь те компании, которые, реагируя на перемены, быстрее других приспосабливаются к новым условиям – бизнес-процессам, технологиям, стандартам качества, способам коммуникаций и прочему.

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

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

Рис. 8. Зависимость изменений от ЖЦ проекта

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

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

Также изменения могут быть связаны с технологией работы и реализации проекта. ИТ-отрасль очень динамична и находится в постоянном развитии. Новые технологии и подходы, а также новое оборудование появляются стремительно, на порядок быстрее, чем в других более традиционных областях (например, строительстве). Таким образом, в ходе реализации ИТ-проектов часто меняются подходы к разработке – появляются новые технологии, языки программирования, платформы или принимается решение по использованию новых технологий. Обновляются версии базового программного обеспечения, операционных систем и сред, СУБД и прочего.

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

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

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

• создавать и поддерживать базу данных конфигураций основных компонентов ИТ-системы;

• писать запросы на изменения и заводить их в документе учета/автоматизированной системе на любые изменения;

• декомпозировать большие изменения до уровня «влияние на 1 компонент» или «выполняется одним человеком». Это позволит достаточно просто связывать задания на разработку с запросами на изменения;

• ввести сквозную классификацию изменений (например, «критическая ошибка», «ошибка», «усовершенствование», «новая возможность», «другое») и единое место хранения и учета;

• помимо менеджера ИТ-проекта и представителей заказчика, привлечь таких членов команды, как менеджер по качеству (Quality Assurance), главный аналитик (архитектор) проекта, ответственный за интеграцию.

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

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

 

3.4. ИТ-аудит как средство управления рисками

Аудит ИТ – это независимая аудиторская проверка функционирования ИТ с целью получения достоверных данных. Аудит ИТ представляет собой получение систематизированных и достоверных данных о текущем состоянии ИТ и оценку степени их соответствия «лучшим практикам». Задача аудита ИТ состоит в том, чтобы обнаружить риски и удостовериться в том, что риски, оставшиеся после применения соответствующих процедур контроля, приемлемы для руководства.

Можно выделить различные виды ИТ-аудита, которые отличаются по своим задачам и конечным результатам:

1) регулярный независимый внешний ИТ-аудит: необходим по требованию законодательства (ЦБ РФ, Гостехкомиссия РФ, закон Сарбсинса-Оксли);

2) регулярный внутренний ИТ-аудит: инициируется высшим руководством для повышения эффективности работы компании и оценки затрат на ИТ;

3) специальный ИТ-аудит: инициируется руководством и проводится перед важными организационными изменениями (IPO, слиянием и прочим).

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

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

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

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

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

1) риски информационной безопасности, которые определяются моделью бизнеса и заключаются в повышенных требованиях к конфиденциальности всей внутренней информации, находящейся в системах учета, электронной почте, пользовательских файлах;

2) риски хищения или искажения информации, с которой работает компания. Источниками этих рисков могут быть как собственные сотрудники, так и действия конкурентов;

3) технологические риски, влияющие на непрерывность бизнеса, которые связаны с доступностью ИТ-сервисов для сотрудников, а также возможностью восстановить конфигурацию систем и данные в случаях аварий, отказов оборудования, техногенных катастроф и действий третьих лиц;

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

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

Целью аудита информационной безопасности являются:

• оценка текущего уровня защищенности ИТ;

• выявление рисков и уязвимостей в системе защиты;

• анализ угроз, которые могут быть реализованы через обнаруженные уязвимости;

• оценка соответствия требованиям системы информационной безопасности;

• выработка рекомендаций по внедрению новых и повышению эффективности существующих механизмов безопасности, а также по приведению в соответствие требованиям системы информационной безопасности.

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

 

4.1. Планирование и идентификация рисков

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

Как и любая другая деятельность в проекте, управление рисками требует времени и затрат ресурсов. Поэтому эта работа обязательно должна планироваться. На этапе планирования рисков (первом этапе процесса управления рисками) происходят организация работ и планирование действий по управлению рисками с привязкой к жизненному циклу ИТ-проекта. То есть планирование управления рисками – это процесс определения подходов и планирования операций по управлению рисками проекта.

Во время этапа планирования необходимо ответить на следующие вопросы: как будет реализовываться процесс управления рисками? Из каких шагов состоит этот процесс? Какие именно действия, роли участников и их обязанности, результаты характеризуют каждый шаг? Кто будет осуществлять действия по управлению рисками? Какие для этого требуются навыки/квалификация? Какой инструментарий и какие методики будут применены? Какой терминологический аппарат будет использован для классификации и оценки? Какова процедура приоритезации рисков? Как будут строиться планы управления рисками и планы мероприятий по смягчению возможных негативных последствий? Какие действия будут предпринимать отдельные члены проектной группы для управления рисками? Как будет выполняться мониторинг управления рисками? Какая инфраструктура (базы данных, программные инструменты, хранилища данных) будет использована для обеспечения процесса управления рисками?

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

По статистике мировой консалтинговой компании IBM, занимающейся реализацией проектов в области ИТ в различных индустриях, на стадии предварительной проработки и планирования внедрения проекта (первые 10 %) закладывается более 90 % его полезности. Именно в это время закладываются наиболее болезненные последствия: срыв сроков, нереальный бюджет, ущербная функциональность. При этом консультанты и заказчики видят проблемы неодинаково, что приводит к различным методам управления рисками, которые планируются на ранних этапах. Каждая компания должна разработать собственный план управления рисками, содержащий общие регламенты и рекомендуемые методики.

Целью этапа планирования управления рисками является разработка плана управления рисками, который содержит:

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

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

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

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

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

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

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

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

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

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

В рамках процесса идентификации рисков ИТ-проекта необходимо:

• определить, какие риски могут повлиять на проект;

• обеспечить итеративный процесс выявления рисков;

• организовать методы идентификации и совещания по проекту;

• анализировать все возможные допущения и ограничения;

• анализировать сильные и слабые стороны, угрозы и возможности;

• обеспечить своевременное и полное документирование рисков проекта;

• обеспечить четкие и своевременные коммуникации.

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

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

1) обзор документации;

2) метод мозгового штурма;

3) метод Дельфи (Delphi);

4) SWOT-анализ;

5) интервью (опросы экспертов);

6) контрольные списки;

7) анализ предположений/сценариев;

8) причинно-следственные диаграммы;

9) структурирование рисков с использованием структурной декомпозиции риска.

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

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

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

Среди документов, которые могут быть эффективно использованы с целью идентификации рисков для максимально полного списка рисков, предлагаются следующие документы:

• устав проекта;

• структурная декомпозиция работ;

• описание продукта;

• расписание проекта;

• предполагаемые затраты и сроки;

• ресурсный план;

• план поставок;

• список предположений и ограничений.

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

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

Рис. 9. Процесс выявления рисков согласно методологии MSF

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

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

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

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

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

SWOT-анализ. SWOT-анализ (Strength, Weaknesses, Opportunities and Threats) – оценка качеств проекта ИТ с точки зрения сильных и слабых сторон, возможностей и угроз. SWOT-анализ обеспечивает анализ проекта с каждой из перечисленных сторон, чтобы сформулировать предположения об основных угрозах реализации проекта в целом.

Так, например, при проведении SWOT-анализа сильные стороны (Strength) описывают более развитые, проработанные составляющие проекта ИТ, такие как наличие опыта персонала в подобных проектах, наличие требуемых навыков и квалификаций, наличие бесперебойных технологий, обеспечивающих достижение целей проекта ИТ. Слабые стороны (Weakness) описывают составляющие проекта, представляющие угрозу своей неясностью, неполнотой, слабой проработкой или организацией, например нечеткая постановка целей или нежелание сотрудников переходить на новые технологии. Возможности (Opportunities) представляют возможности по стратегии реализации проекта, дополнительные преимущества, получаемые за счет минимизации затрат и максимизации результата, такие как уменьшение трудозатрат за счет использования более развитых информационных технологий, обеспечение безопасности данных или увеличение скорости обмена информацией между сотрудниками. Угрозы (Threats) определяют факторы, которые могут помешать выполнить проект с плановыми результатами либо вообще сделать его реализацию невозможной, бессмысленной, невыгодной и т. д., например несовместимость технологий, невозможность переноса данных из одной системы в другую, прекращение финансирования проекта в результате административной реформы и организационных изменений (рис. 10).

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

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

Рис. 10. Пример SWOT-анализа для идентификации рисков ИТ-проекта

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

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

Анализ предположений/сценариев. Анализ предположений (сетевые методы анализа) – метод, который исследует правильность предположений и затем идентифицирует риски, исходя из правильности, полноты и последовательности предположений. Данный метод идентификации направлен на определение областей, которые могут быть подвержены риску, исходя из правильности, полноты и последовательности предположений о данной области. Анализ предположений производится при аудите документов проекта и позволяет формулировать потенциальные риски, исходя из того, что выдвинутое предположение о проекте может оказаться неверным. Часто для анализа применяется гипотеза «что, если», при помощи которой можно исследовать правильность предположений о ходе выполнения проекта ИТ на каждом этапе жизненного цикла и идентифицировать риски, исходя из правильности, полноты и последовательности предположений. Например, если предположение, что «в ближайшие 5 лет в компании планируется увеличение данных в n раз и для передачи данных достаточно будет использовать сетевой кабель с пропускной способностью» неверно, то существует потенциальный риск невозможности обмена коммуникациями при увеличении информации более чем в n раз.

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

1) определить участников принятия решений и ответственных за возникновение риска (кто принимает решение?);

2) определить последствия неопределенности (на что влияет?);

3) определить характер изменений и способ реагирования на риски (что изменить и как?).

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

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

Для оценки сценариев изменений необходимо использовать классификацию изменений (социальные, политические, экономические, технологические, технические и прочие), которая может отличаться в зависимости от проекта внедрения и стратегических целей в программе ИТ-проекта.

Главный недостаток данного метода заключается в субъективности выбора сценария реализации проекта и отсутствии учета информационной неопределенности.

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

Рис. 11. Пример причинно-следственной диаграммы для идентификации ИТ-рисков

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

Структурирование рисков с использованием структурной декомпозиции риска (Risk Breakdown Structure, RBS) сформировано по аналогии со структурной декомпозицией работ проекта (WBS) и позволяет группировать риски по источникам появления для определения суммарного воздействия рисков.

Универсальный пример иерархических уровней структурной декомпозиции рисков ИТ-проекта представлен ниже в табл. 3.

Использование данного метода в области ИТ требует большого знания предметной области и наличия достаточной информации.

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

• дать наименование риску и присвоить ему уникальный номер;

• определить ответственного за данный риск;

• описать причины возникновения риска;

• описать последствия наступления риска;

• зафиксировать статус риска (новый/в работе/закрыт).

Таблица 3.

Структурная декомпозиция рисков ИТ-проекта 

 

4.2. Качественная и количественная оценка рисков

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

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

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

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

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

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

По результатам качественной оценки рисков:

1) фиксируются результаты оценки вероятности возникновения и влияния рисков;

2) производится ранжирование рисков;

3) составляется перечень приоритетных рисков;

4) распределяется ответственность по наиболее ответственным рискам;

5) определяется перечень рисков, которые требуют дополнительного анализа, оценки и управления.

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

Этап 1. Выбор ответственного/владельца риска. Обычно все идентифицированные риски распределяются между ответственными. За риск, как правило, отвечает тот, кто идентифицировал данный риск. Владельцы рисков (risk owners) наблюдают за признаками наступления риска, а также управляют ответными процедурами в случае возникновения данного риска. Сотрудники становятся владельцами рисков в силу специфических экспертных знаний или в связи с тем, что они обладают определенным контролем над специфическим риском. Обычно чем раньше в процесс управления рисками вводится владелец риска, тем лучше.

Этап 2. Анализ допущений. Анализ допущений (assumption testing), которые были сделаны в процессе идентификации рисков, необходимо выполнить, прежде чем непосредственно переходить к качественному и количественному анализам рисков.

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

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

Наиболее простая и удобная в использовании методика оценки заключается в выработке проектной группой коллективных оценок двух общепризнанных параметров каждого из рисков – вероятности возникновения (risk probability) и степени влияния риска (risk impact).

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

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

Существуют следующие шкалы измерения:

• номинальные: допустимое/недопустимое значение;

• качественные: вероятность очень мала/значительна/велика;

• количественные (0–1).

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

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

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

Математическая теория нечетких множеств была предложена профессором Л. А. Заде, она открывает большие возможности перед системными аналитиками в области управления рисками на основе применения нечеткой логики. Теория нечетких множеств Л. А. Заде описывает подход, который позволяет эксперту наилучшим образом формализовать свои нечеткие представления, трансформировав язык слов в язык количественных оценок. Этот подход применим всюду, где свидетельства о тех или иных проявлениях объекта научного исследования количественно ограничены и качественно разнородны. Если эксперт хорошо знает предприятие изнутри, то ему не составит никакого труда выделить именно те факторы, которые наиболее влияют на процессы потери платежеспособности (включая ошибки менеджмента), сопоставить этим факторам количественные показатели и пронормировать их. При этом если эксперт затрудняется с классификацией, он может в ходе нормирования успешно применять уже существующие нечеткие описания с последующим арифметическим анализом и оценкой рисков принятия того или иного решения.

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

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

Вероятность возникновения риска (risk probability) – это мера возможности того, что последствие риска, описанное в его формулировке, действительно наступит.

Вероятность возникновения риска является базовой составляющей риска и определяет отношения количества случаев, когда событие, связанное с риском, произошло, к общему количеству аналогичных проектов. Вероятность риска должна быть больше нуля, так как иначе он из себя ничего не представляет. Также вероятность риска должна быть меньше единицы, иначе риск не содержит неопределенности и представляет собой уже известную проблему. Если вероятность риска равна единице либо риск высоковероятен (более 0,8 наступления события) – такая вероятность выводит проблему из разряда рисков и переводит в разряд фактов. Оценку вероятности можно получить на основании метода экспертных оценок, опыта прошлых проектов и предположений участников проекта. В большинстве ситуаций проектные группы могут представить собственный опыт и/или имеющиеся в индустрии опытные данные в виде простых и понятных формулировок, которые затем могут быть превращены в числовые значения.

Для оценки вероятности применяются шкалы, позволяющие упростить работу эксперта по определению оценок с любой точностью. При упрощенной оценке вероятности возникновения малозначимых рисков зачастую риску присваивают вероятность либо 1, либо 0. Соблазнительно применить для оценки шкалы типы «данный риск имеет вероятность 0,65» или «риск оценивается как 0,48». Однако использование подобных шкал предполагает, что имеется модель для расчета и значение достоверно. Такая высокая точность спорна. Наиболее эффективной шкалой вероятности риска является простейшая градация «низко – средне – высоко», отображаемая в отдельно взятые численные значения (0,17 0,5 0,84), либо же сложные оценки таких выражений, как «почти невозможно», «маловероятно», «возможно», «почти наверняка» (семиуровневая градация), и прочие градации (табл. 4).

Таблица 4.

Пример шкалы для оценки вероятности риска 

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

Влияние/воздействие риска (risk impact) – представляет собой меру серьезности негативных последствий, уровень убытков или оценку потенциальных возможностей, связанных с риском.

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

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

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

Таблица 5.

Шкала для оценки влияния риска (пример) 

Как показано в табл. 5, степень влияния риска может выражаться в присвоении одного из значений степени влияния риска на различные показатели ИТ-проекта, например: очень сильное – 0,8, сильное – 0,4, среднее – 0,2, слабое – 0,1, очень слабое – 0,05.

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

Этап 5. Построение матрицы Вероятность × Воздействие и приоритезация рисков. Интерпретация качественных оценок в количественные показатели позволяет менеджеру риска построить матрицу количественных показателей с ранжированными по приоритетам рисками, которая будет основана на качественных показателях матрицы Вероятность × Воздействие.

Для построения матрицы используются полученные оценки «вероятность возникновения риска» и «воздействие/влияние риска». Произведение этих двух величин дает единую метрику риска, называемую ожидаемой величиной (Exposure), которая используется при ранжировании рисков (табл. 6) и заполняется в ячейки матрицы. Ранжирование для каждого риска происходит совместно на совещании рабочей группы. Определяется пороговое значение для критических рисков (например, значение >0,28).

Обычно те факторы, которые «вероятны» или «высоковероятны» и имеют «серьезные» или «средние» последствия, являются кандидатами на высокий приоритет. Факторы, которые «маловероятны» и имеют «незначительные» последствия, не являются кандидатами для управления. Однако они должны документироваться и включаться в процесс анализа. Отметим, что «маловероятные» факторы риска, но с «серьезными» последствиями должны быть предметом тщательного рассмотрения.

Таблица 6.

Матрица Вероятность × Воздействие 

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

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

Для наглядной визуализации рисков существует возможность преобразовать матрицу Вероятность × Воздействие в карту рисков (рис. 12). Преимущество графической формы представления уровней рисков заключается в том, что в отчетах для спонсоров и других заинтересованных лиц различные группы рисков могут быть выделены различными цветами с наглядным отображением порогового уровня. Такое разделение очень четко и легко понимаемо («красный риск» воспринимается легче, чем «большая ожидаемая величина Risk Exposure»).

Рис. 12. Карта рисков с приемлемым пороговым уровнем

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

Для приоритезации рисков специалисты компании Microsoft рекомендуют также использовать принятые формулировки риска, все возможные накопленные знания о рисках и рискообразующих факторах, корпоративные правила и инструкции, а также управленческие решения (рис. 13).

Рис. 13. Процесс анализа и приоритезации рисков согласно методологии MSF

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

Этап 6. Документирование незначимых рисков. «Легковесные», или незначимые, риски, не вошедшие в дальнейшее управление рисками, должны быть задокументированы, чтобы можно было по мере выполнения проекта быстро понять, как ведет себя данный риск. Некоторые риски могут быть незначительными в силу их неправдоподобности, то есть практически стабильной нулевой вероятности. Другие могут быть признаны незначимыми, так как имеют очень малую угрозу, то есть более выгодным оказывается принятие возможного ущерба, нежели затраты усилий на управление. Для таких рисков проектная группа сводит к нулю все затраты и усилия на мониторинг рисков. Фиксация незначимых рисков позволяет проектной группе сосредоточиться на других рисках, действительно требующих активного управления.

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

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

 

Количественная оценка ИТ-рисков

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

Как правило, переходить к количественному анализу имеет смысл, если:

• доступны инструменты количественного анализа рисков;

• количественный анализ стоит затрат времени и средств, потраченных на него;

• приоритет проекта очень высокий или же проект находится в центре внимания руководства;

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

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

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

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

Для реализации процедуры количественной оценки рисков ИТ-проекта предлагается использовать следующие основные методы.

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

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

3. Построение дерева решений – для выявления возможных альтернативных вариантов развития проекта и оценки вариации уровня риска и затрат; описывает рассматриваемую ситуацию с учетом каждой из имеющихся возможностей выбора и возможного сценария.

4. Анализ ожидаемой денежной стоимости (ОДС) – производится путем умножения значения каждого возможного денежного результата на вероятность его появления, а затем полученные значения суммируются.

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

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

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

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

Анализ чувствительности позволяет определить риски, имеющие наибольшее влияние на проект, и состоит в определении набора рисков, имеющих наибольшее влияние на значение параметров эффективности проекта. Основная идея метода исследования чувствительности состоит в анализе уязвимости, степени изменяемости коррелируемых показателей по отношению к изменениям параметров моделей: распределение вероятностей, областей изменения тех или иных величин (рис. 14). При этом рассчитывается воздействие изменения одного из входных параметров проекта на один из параметров эффективности. Пример: увеличение затрат на тестирование на 30 % приводит к увеличению стоимости проекта в 2 раза.

Рис. 14. Пример анализа чувствительности

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

Выделяют два вида анализа чувствительности:

• относительный анализ – результат выражается в процентах отклонения параметра от первоначального значения;

• абсолютный анализ – чувствительность выражается в единицах измерения исследуемого параметра.

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

2. Сценарный анализ. Методы, применяемые в настоящее время в сценарном анализе, используют конечное число сценариев, каждый из которых требуется предварительно подготовить. Более простым представляется подход с непрерывным числом исходных альтернатив-сценариев, когда их множество задается указанием его границ. Сценарий должен быть вероятным.

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

Пример: необходимо рассчитать вероятность, что количество сбоев в системе не будет превышать значение X. Для этого выберем ключевой фактор для построения сценариев – объем выполняемых операций. В качестве дополнительных факторов выберем количество пользователей и нагрузку на систему. Для расчета эффекта возьмем несколько сценариев – по полученному значению (накопленное нормальное распределение) определим расчетную вероятность. Расчетная вероятность может быть определена как с помощью специальных программных пакетов, так и программы Excel путем имитации с использованием генерации случайных чисел. Именно с этой вероятностью количество сбоев в системе не будет превышать заданное значение X.

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

Дерево решений – метод построения логически связанной цепи событий от текущего момента времени к будущему. Как правило, дерево решений используют, когда нужно принять несколько решений в условиях неопределенности и когда каждое решение зависит от исхода предыдущего или исходов испытаний. Составляя «дерево» решений, нужно нарисовать диаграмму, где «ствол» и «ветви» отображают структуру проблемы. Располагаются «деревья» слева направо или сверху вниз. «Ветви» обозначают возможные альтернативные решения, которые могут быть приняты, и возможные исходы, возникающие в результате этих решений. При построении соблюдаются хронология событий и логика принятия управленческих решений, выбирается наиболее оптимальное решение. Как показано в примере (рис. 15), расходы для первого варианта «новое оборудование» составляют $120, для второго варианта «модернизация» – $50. При этом вероятность востребованности расширенных возможностей составляет 0,65. Вероятность невостребованности этих возможностей составляет 0,35. Для нового оборудования востребованные возможности составляют доход $200, невостребованные возможности – доход $90. Для варианта установки нового оборудования при больших расходах получаем большую отдачу (которая может быть востребована или нет – варианты 1 и 2). Второй вариант – более дешевая модернизация оборудования с меньшими возможностями. Полученные результаты обеспечивают поддержку принятия решений при выборе оптимальной реализации проекта с точки зрения стоимости и вероятности наступления рискового события.

Рис. 15. Пример дерева решений

При построении дерева решений рассчитывается ожидаемая денежная стоимость для каждого из рассматриваемых вариантов (EMV – Expected Mone-tary Value). Если дерево содержит большое количество альтернативных решений, можно оценивать только наиболее приоритетные ветви. Ожидаемая денежная стоимость считается для одного или нескольких вариантов решений по следующей формуле:

EMV = Вероятность исхода1 × Стоимость исхода1 + Вероятность исхода2 × Стоимость исхода2 + … + Вероятность исхода(n) × Стоимость исхода(n).

Рассчитаем EMV для примера на рис. 13 по формуле EMV = (Доход – Расход) × Вероятность + (Доход – Расход) × Вероятность. Получим следующие значения:

EMV (Новое оборудование) = (200–120) × 0,65 + (90 – 120) × 0,35 = 41,5. EMV (Модернизация) = (120 – 50) × 0,65 + (60–50) × 0,35 = 49.

Далее выбирается вариант максимального EMV.

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

В результате построения диаграммы дерева решений:

• выявляются важные (узловые) события и представляются в графическом виде;

• отражаются вероятности и величины затрат и выгод каждой логической цепи событий и будущих решений;

• используется анализ ожидаемой денежной стоимости для определения относительной стоимости альтернативных операций.

Для анализа рисков стоимости и расписания рекомендуется применять моделирование, так как оно обладает большей мощностью и снижает вероятность неправильного применения по сравнению с анализом ожидаемой денежной стоимости.

5. Моделирование и имитация. Имитационное моделирование – техника численных экспериментов, с помощью которых можно получить эмпирические оценки степени влияния различных факторов – исходных величин, которые точно не определены, на зависящие от них результаты – показатели.

Имитационное моделирование часто используется для количественной оценки воздействия изменений значений параметров системы (например, в случае наступления рискового события) на выбранные показатели (группу показателей) успешности проекта. Для проведения моделирования критичным является выбор или разработка математической модели, наиболее точно имитирующей поведение оцениваемого показателя.

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

Упрощенный алгоритм моделирования Монте-Карло состоит из следующих шагов.

1. Задаются границы изменения параметра (факторов). При имитационных прогонах переменная выбирается случайным образом в соответствии с типом распределения и в границах заданного диапазона.

2. С помощью компьютерной программы, имитирующей случайность процессов, случайным образом выбираются значения параметра из заданного интервала и рассчитывается значение события. Значение рассчитывается исходя из выбранного распределения для ключевых параметров модели. Выбор распределения осуществляется либо по прошлой информации (статистические данные), либо по оценкам экспертов.

3. Проводится большое число прогонов, что позволяет получить множество случайных значений события, для которых могут быть рассчитаны среднее значение и стандартное отклонение (d). Каждый прогон происходит с вероятностью Р = 100/N (размер выборки). Для получения вероятности всех прогонов полученную величину Р умножаем на количество прогонов (с получением анализируемого результата).

4. Применяется правило трех сигм (при предположении о нормальности распределения вероятности), при котором значение окажется в трех интервалах:

• с вероятностью 0,68 в диапазоне ±1d);

• с вероятностью 0, 95 в диапазоне (±2d);

• с вероятностью 0, 99 в диапазоне (±3d).

Таким образом, обещая клиенту, что мы закончим проект в срок, соответствующий точке наиболее вероятного значения, мы имеем 50-процентную возможность окончить проект позднее обещанной даты (при выборе нормального распределения).

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

В результате моделирования получается диаграмма, показывающая вероятности всех возможных сроков завершения проекта и вероятности возможных затрат с четким изображением наиболее вероятных затрат по проекту (рис. 16, 17).

Рис. 16. Прогноз даты завершения проекта на основании количественной оценки риска

Рис. 17. Прогноз суммарной стоимости проекта на основании количественной оценки риска

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

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

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

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

 

Выводы по количественной оценке рисков

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

Количественная оценка рисков, проведенная в полном объеме, с использованием предложенных методик, позволяет компании определить:

• вероятность достижения конечных целей ИТ-проекта;

• прогноз степени воздействия риска на проект и оценку объемов непредвиденных затрат и материалов, которые могут потребоваться;

• риски, требующие скорейшего реагирования и повышенного внимания, а также количественную оценку влияния их последствий на проект;

• реалистичные прогнозы затрат и предполагаемые сроки завершения проекта.

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

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

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

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

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

 

4.3. Разработка реагирования на риски

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

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

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

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

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

Рис. 18. Процесс планирования реагирования согласно методологии MSF

Согласно другой методологии PMBoK, для осуществления выбора метода реагирования необходимо проанализировать следующую информацию:

• план управления рисками;

• приоритезированный список рисков;

• оценки рисков проекта;

• приоритезированный список рисков с оценками;

• вероятностный анализ проекта;

• вероятности достижения стоимостных и временных целей;

• список возможных реакций;

• пороги рисков;

• ответственные за риски;

• общие причины рисков;

• тенденции в анализе рисков.

В современном управлении рисками проектов существует множество методов реагирования на риск. В соответствии с планом реагирования на риски ИТ принимается решение об осуществлении или отказе от противорисковых мероприятий. При выборе метода реагирования всегда необходимо учесть стоимость метода реагирования (размер затрат на проведение мероприятий) и стоимость самого риска (затраты на устранение последствий риска в случае его наступления).

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

• определяется перерасход средств с учетом вероятности наступления неблагоприятного события;

• определяются затраты на реализацию возможных мероприятий по уменьшению опасности наступления риска;

• сравниваются требуемые затраты на реализацию предложенных мероприятий с возможным перерасходом средств вследствие наступления рискового события;

• процесс повторяется для следующего по важности риска.

Эффективность выбранного способа можно проверить по формуле

где RRL – эффект от снижения риска (способ приемлем при RRL > 1);

REbefore и REafter – подверженность риску до и после применения выбранного метода реагирования соответственно;

RRC – затраты, связанные с применением данного метода реагирования.

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

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

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

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

1. Избегание (Avoidance). Можем ли мы избежать риска, скорректировав наши действия?

2. Минимизация (Minimization). Может ли негативное воздействие риска быть уменьшено путем планирования реакции на риск?

3. Передача (Transfer). Можем ли мы перенести риск на третьих лиц либо другой проект?

4. Принятие (Acceptance). Можем ли мы принять последствия риска, если они все-таки наступят, и не предпринимать по этому поводу никаких дальнейших действий?

Рассмотрим каждый из подходов более подробно.

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

В качестве примеров можно привести: отказ от ненадежных поставщиков и партнеров, отказ от рискованных проектов, использование высокопроизводительного аппаратного или программного обеспечения.

Основные мероприятия, направленные на избегание возникновения рисковых ситуаций в ИТ-проектах, предполагают:

• обязательное документирование целей проекта, а также всех изменений в документации проекта, возникающих при его реализации;

• повышение мотивации рядовых сотрудников путем материального стимулирования;

• привлечение сторонних квалифицированных специалистов;

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

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

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

В качестве примера минимизации риска можно привести: увеличение ресурсов, уменьшение объема работ или снижение требований, сбор дополнительной информации, проведение повторной работы, перепроектирование.

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

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

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

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

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

В случае активного принятия риска, как правило, создается так называемый резерв на непредвиденные обстоятельства, который включает в себя время, деньги и ресурсы для управления рисками путем создания резерва (под конкретный риск), обычно определяются действия, которые должны быть реализованы в случае наступления риска. Разрабатываются резервные планы: «Что будет, если…».

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

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

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

Сводная таблица основных методов реагирования и необходимых действий представлена в табл. 7.

Таблица 7.

Сводная таблица методов реагирования 

Среди прочих «неосновных» методов реагирования некоторые методологии дополнительно выделяют:

• Исследование риска (Research) – стратегия, при которой собирается дополнительная информация и уточняются оценки риска, осуществляются дополнительное изучение предметной области, проверка гипотез, привлечение экспертов, дополнительного оборудования;

• Использование риска (Exploit) – устранение неизвестности, связанной с риском, при реализации возможности этого риска. Этот метод включает в себя привлечение лучших ресурсов для сокращения срока работ, а также обеспечение лучшего по сравнению с запланированным качества;

• Совместное использование или разделение (Share) – частичная или полная передача риска третьей стороне, способной использовать его к наибольшей выгоде проекта. Примеры – создание партнерств с разделенным риском, команд, специальных компаний или совместных предприятий, открытых с четко выраженной целью управления возможностями риска;

• Усиление (Enhance) – изменение «размера» риска путем увеличения его вероятности и позитивного результата.

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

• список рисков проекта, их описание, причины и степень воздействия рисков на проект;

• владельцы рисков и распределение ответственности;

• результаты качественной и количественной оценок рисков;

• выбор методов реагирования (избегание, передача, минимизация или принятие) для каждого вида рисков;

• уровень рисков (вероятность возникновения и влияние), который предполагается достигнуть вследствие применения стратегии;

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

• бюджет и время реагирования;

• план на случай неблагоприятных обстоятельств, план нейтрализации, антикризисный план;

• триггеры планов реагирования – критерии, используемые проектной группой для определения условий начала осуществления плана реагирования на риски.

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

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

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

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

 

4.4. Мониторинг, отчетность и контроль управления рисками

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

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

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

В процессе мониторинга рисков определяется:

• было ли осуществлено реагирование на риски в соответствии с планом управления рисками проекта;

• достаточно ли эффективны меры реагирования на риски, есть ли потребность в разработке новых стратегий;

• изменилось ли воздействие риска на проект по сравнению с ранее определенным, какова тенденция изменения;

• является ли воздействие риска запланированным или случайным результатом;

• появились ли новые/остаточные риски.

В процессе мониторинга определяются новые и остаточные риски (не вошедшие в первоначальный план управления рисками).

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

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

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

В процессе мониторинга и контроля возможно использование базы данных мониторинга проектов, хранилища исходного кода программ, систем регистрации времени реагирования и последствий, хранение накопленного опыта. Для этого методологией Microsoft рекомендуется формировать отчеты о состоянии риска с детальным описанием результатов реагирования, всю информацию сохранять в базе данных по рискам (рис. 19). Цель отчета о состоянии риска – информирование о происходящих изменениях в статусе риска и о прогрессе в осуществлении планов по его предотвращению.

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

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

Рис. 19. Процесс мониторинга согласно методологии MSF

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

 

5.1. Необходимость ИТ-аутсорсинга

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

Различают различные виды аутсорсинга в области ИТ-проектов:

• BPO (Business Рrocess Оutsourcing) – аутсорсинг бизнес-процессов;

• BSP (Business Service Provider) – провайдер бизнес-сервисов;

• ИТO (ИТ Outsourcing) – ИТ-аутсорсинг;

• ASP (Application Service Provider) – провайдер сервисов приложений.

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

Существует аутсорсинг программных проектов – проектов в области разработки, интеграции или поддержки программного обеспечения. Классический пример, происходящий в последние годы повсеместно в странах Западной Европы и США, – это вывод заказов на разработку программного обеспечения в аутсорсинговые компании-разработчики, расположенные на территориях стран с относительно низким средним уровнем заработных плат (Индия, Россия, Украина, Вьетнам и т. д.). Основная идея здесь – исключительно сокращение расходов на разработку: стоимость труда программиста в Индии очевидно дешевле, чем программиста в Силиконовой долине в США. Этот феномен получил название «оффшорного программирования», поэтому аутсорсинг в области разработки программного обеспечения почти всегда воспринимается как синоним оффшорного программирования (хотя это и неправильно). Оффшорное программирование характерно и для России. Так, в связи с ростом заработных плат в Москве заказы на разработку программного обеспечения все чаще передаются московскими компаниями-разработчиками полностью или частично (для создания отдельных компонентов программных систем) их коллегам из других городов или стран, где заработные платы исполнителей меньше.

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

Активное развитие ИТ-аутсорсинга во всем мире объясняется стремительным развитием информационных технологий, когда компаниям сложно самостоятельно отслеживать появление технологических новшеств и своевременно внедрять их, не имея большого штата технических специалистов. Становится выгоднее привлекать профильные организации со штатом высококвалифицированных специалистов в области информационных технологий, чем создавать и расширять собственные специальные подразделения.

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

Опыт компаний, предлагающих аутсорсинговые услуги, и данные аналитических исследований говорят, что передача ИТ «на сторону», как правило, выгодна компаниям, имеющим менее 100 или свыше 500 автоматизированных рабочих мест. Маленькой компании не по карману содержание собственного ИТ-штата, в большой появляются структурные проблемы.

Для определения наиболее эффективного решения необходимо подобрать тип ИТ-аутсорсинга и набор передаваемых функций.

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

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

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

Чтобы ответить на вопрос «зачем нужен ИТ-аутсорсинг», следует проанализировать деятельность и качество аутсорсинговой компании. Во-первых, аутсорсинговая компания обязуется поддерживать высокий уровень качества, который подробно оговаривается в договоре с заказчиком.

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

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

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

Наиболее актуальной задачей, особенно в промышленной области, является качество ИТ-услуг. Для этого аутсорсинг предлагает комплексные решения, которые уменьшают количество нескоординированных поставщиков, повышая качество предоставляемых услуг и уровень удовлетворенности пользователей.

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

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

Аутсорсинг ИТ-специалистов позволит снизить риски дефицита специалистов ИТ-служб и некачественных ИТ-решений. Решения в области услуг дата-центров и поддержки service-desk позволят избавиться от некачественного предоставления ИТ-сервисов, оптимизировать управление ИТ-запросами за счет системы мониторинга запросов. Все это поможет обеспечить гибкость и масштабируемость бизнеса за счет увеличения уровня поддержки основного бизнеса руководством компании.

Необходимость ИТ-аутсорсинга может быть обусловлена множеством факторов:

• увеличением или изменением ИТ-затрат;

• отсутствием квалифицированных ИТ-специалистов;

• снижением продуктивности, мощностей и качества ИТ и сервисов;

• снижением степени удовлетворенности пользователей;

• фокусом на области своей основной деятельности;

• доступом к ИТ-ресурсам глобального поставщика услуг;

• оптимизацией собственной конкурентоспособности.

Согласно российскому исследованию причин обращения к услугам аутсорсинга, проведенному компанией Aplana Software, экономический эффект уступает квалифицированным специалистам в области ИТ, срокам и качеству реализации ИТ-решений (рис. 20).

Можно сделать вывод, что российские компании ориентированы на качественный сервис, в то время как западная тенденция – это снижение затрат.

 Рис. 20. Причины обращения к услугам аутсорсинга в России

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

 

5.2. Риски и выгоды от использования аутсорсинга

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

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

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

• выполнить проверку согласованности инициативы аутсорсинга с ИТ-стратегией и направлением бизнеса (для «закрытых» оборонных предприятий, некоторых банков ИТ-аутсорсинг может быть частично или полностью неприменим);

• определить, какие процессы и для каких элементов ИТ-сервисов и инфраструктуры будут выполняться внешним подрядчиком;

• определить требования к процессам, передаваемым внешнему подрядчику, и показатели для контроля их выполнения;

• определить критерии выбора внешнего подрядчика;

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

• выработать стратегию развития ИТ и провести ИТ-аудит: консолидацию и виртуализацию серверных систем и систем хранения данных, стандартизацию рабочих мест пользователей, анализ, стандартизацию и оптимизацию процессов управления и поддержки ИТ;

• выполнить оценку ИТ-ресурсов (зарплаты ИТ-специалистов, программное обеспечение, стоимость аренды площадей и прочее), реальной стоимости предоставления ИТ-услуг и их влияния на бизнес.

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

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

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

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

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

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

• оптимизацию ресурсов, направленных на контроль непрофильных ИТ-активов и процессов;

• повышение качества ведения бизнес-процессов и отдачи от бизнес-активов за счет увеличения качества ИТ-сервисов;

• снижение бизнес-рисков за счет оптимизации и повышения надежности ИТ-сервисов.

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

Перечислим основные риски, с которыми может столкнуться компания при переходе на аутсорсинг ИТ-услуг.

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

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

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

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

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

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

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

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

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

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

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

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

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

 

5.3. Методы управления рисками аутсорсинга

Знание рисков, связанных с процессом передачи услуг на аутсорсинг, позволяет значительно минимизировать эти риски, а в отдельных случаях практически полностью их исключить. Чем точнее определен конкретный риск в ИТ-аутсорсинге, тем больше вероятность принятия эффективных мер для его устранения.

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

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

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

• объем работ (ПО и аппаратное обеспечение);

• политики, регулирующие предоставление услуг;

• информация по предоставляемым услугам, включая правила приоритезации, эскалации и т. п.;

• часы поддержки;

• ценовая политика по предоставляемым услугам;

• процедуры предоставления отчетности и ее рассмотрения: тип и частота отчетов, ключевые показатели эффективности (КПЭ), планы встреч по контролю эффективности;

• процедура рассмотрения/внесения изменений в договор.

Заключение такого контракта с поставщиком позволит четко прописать все условия и снизить риски потери контроля над ИТ-процессами и зависимости от сотрудников компании-аутсорсера, обеспечивая контроль за потребляемыми ИТ-услугами и обслуживанием в целом, а также выполнение условий для проведения аутсорсером прозрачной политики в сфере оказания ИТ-услуг.

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

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

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

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

Чтобы снизить риск выбора ненадежного поставщика, следует организовать:

• сбор информации об аутсорсере (проекты, отзывы, наличие отраслевого опыта и т. д.);

• тендер по критериям стоимость, сроки, результат, гарантии (наличие контракта SLA);

• взаимодействие с партнерами и представителем компании – разработчика программного обеспечения;

• контроль реакции и качества предоставляемых услуг;

• четко прописанные этапы работ в SLA;

• четко определенные показатели контроля результатов (KPI).

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

Рис. 21. Критерии выбора поставщика ИТ-услуг (по данным «Aplana Software»)

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

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

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

 

6.1. Понятие информационной безопасности

Зависимость бизнеса от современных информационных технологий огромна. Преимущества их использования очевидны – это хранение и обработка большого количества информации, скорость передачи данных, доступ к информации по всему миру. Развитие информационных технологий с каждым годом усложняет процесс защиты информации. Если в начале 80-х годов защита информации могла быть эффективно обеспечена при помощи специально разработанных организационных мер и программно-аппаратных средств шифрования, в настоящее время информационная безопасность требует более продвинутых средств защиты. Это обусловлено возрастающей сложностью и масштабами программных средств и компьютерных систем, сбором и хранением крупных информационных баз на электронных носителях, доступом к ресурсам компьютерной системы большого числа пользователей с различными правами доступа к системе. Так, например, активное применение Интернета практически во всех сферах бизнеса делает ИТ-структуру компании более уязвимой за счет возможности доступа пользователей извне.

Определений информационной безопасности множество. Согласно ГОСТу, защита информации (обеспечение информационной безопасности) – это деятельность, направленная на предотвращение утечки защищаемой информации, несанкционированных и непреднамеренных воздействий на защищаемую информацию. Многие определения охватывают аспекты, связанные с определением, достижением и поддержанием конфиденциальности, целостности, доступности информации или средств ее обработки. Негативные воздействия, как правило, осуществляются с целью нарушения конфиденциальности, целостности и доступности информации, поэтому для достижения цели информационной безопасности необходимо обеспечить точность и полноту информационных активов, доступных и пригодных для использования только уполномоченными лицами (организацией, процессом) в соответствии с их требованиями.

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

Существует целый ряд стандартов и подходов к обеспечению информационной безопасности компании и управлению информационными рисками. Наибольшую известность в мировой практике управления информационными рисками имеют такие международные спецификации и стандарты, как ISO 17799–2002 (BS 7799), CISA (Сертифицированный аудитор информационных систем), CISSP (Сертифицированный профессионал по обеспечению безопасности информационных систем), COSO, SAS 55/78, и некоторые другие, аналогичные им.

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

ISO/IEC 27001 представляет собой международный стандарт – «Система управления информационной безопасностью (СУИБ). Требования» – и позволяет организациям определять цели и процессы информационной безопасности, предпринимать шаги к увеличению эффективности.

Стандарт ISO/IEC 27002 представляет собой практическое руководство по созданию СУИБ, описывает механизмы контроля, необходимого для построения системы безопасности, определенные на основе лучших примеров мирового опыта в данной области.

Существует еще один международный стандарт ISO 15408, который был разработан на основе стандарта «Общие критерии безопасности информационных технологий» (рис. 22). В 2002 году этот стандарт был принят в России как ГОСТ Р ИСО/МЭК 15408–2002 «Информационная технология. Методы обеспечения безопасности. Критерии оценки безопасности информационных технологий», часто в литературе называемый «Общие критерии». Ранее в отечественных нормативных документах в области ИБ понятие риска не вводилось.

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

Рис. 22. Понятие безопасности в соответствии с ГОСТ Р ИСО/МЭК 15408–2002

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

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

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

• документирование информационной системы с позиции информационной безопасности компании;

• классификацию информационных рисков и профилирование пользователей;

• качественную и количественную оценку информационных рисков и их анализ;

• управление информационными рисками на всех этапах жизненного цикла информационной системы, возможно с применением специального программного инструментария;

• аудит в области информационной безопасности.

 

6.2. Основные риски в обеспечении информационной безопасности

По результатам регулярных исследований аналитической лаборатории Info-Watch, ежедневно в мире регистрируется от одной до двух утечек конфиденциальных данных, преданных публичной огласке. Только в 2008 году проблема утечки персональных данных затронула интересы более 100 миллионов человек во всем мире! Мировой финансовый кризис, сопровождающийся массовыми сокращениями рабочих мест, лишь обостряет проблему, поскольку ценность информации в момент кризиса возрастает.

Разные виды информации имеют разную цену для злоумышленников и порождают специфические риски для компании: финансовые, юридические, репутационные:

 финансовые риски – хищение финансовых данных, отчетов, ключевой информации и паролей для взаимодействия, получение информации о планируемых продуктах/услугах, хищение базы данных клиентов, поставщиков;

 юридические риски – хищение конфиденциальной информации, персональных данных, условий контрактов, трудовых договоров;

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

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

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

Компанией InfoWatch было проведено исследование основных каналов утечек информации за 2008 год. Как видно из диаграммы (рис. 23), значительный процент инцидентов приходится на сеть и переносные компьютеры, в то время как на электронную почту выпадает небольшой процент зарегистрированных утечек.

Рис. 23. Каналы утечки конфиденциальной информации

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

Одной из самых опасных инсайдерских угроз сегодня является несанкционированный доступ к конфиденциальной информации и ее кража. Несанкционированный доступ к информации может быть организован с помощью взлома ПО, копирования на внешние носители и передачи информации через Интернет, использования дополнительных устройств (Wi-Fi, BlueTooth, GPRS и прочего).

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

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

Согласно отчету Computer Crime and Security Survey, ущерб от неосторожных и неправомерных действий сотрудников в несколько раз превышает объем причиненного вреда от действий вирусов и хакерских атак. То есть наибольшая угроза ИТ-безопасности исходит изнутри организации. Сотрудники компании (инсайдеры) имеют намного больше возможностей нанести вред организации, в отличие от хакеров или внешних злоумышленников. Инсайдерские утечки данных через локальные порты компьютеров сотрудников, съемные носители и персональные мобильные устройства стали гораздо опаснее сетевых угроз. От внутренних «нарушителей порядка» нельзя защититься так же просто, как от вирусов: установить антивирус и регулярно обновлять сигнатурные базы, – потребуется выстроить гораздо более сложную, комплексную систему защиты. Растущая распределенность вычислительных процессов ведет к тому, что все большая часть корпоративных данных создается, обрабатывается и хранится на персональных компьютерах сотрудников, включая не только настольные, но и переносимые компьютеры – ноутбуки. Наиболее существенным по влиянию фактором стал резкий рост в последние годы размеров памяти съемных носителей при снижении их цены, габаритов и простоте инсталляции, что привело к общедоступности, удобству и высокой маскируемости (из-за малых размеров) этих устройств. Повсеместное распространение беспроводных сетей только усугубляет проблемы информационной безопасности.

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

При оценке решений для управления доступом ИТ-специалисты должны учитывать следующие требования:

• поддержка различных методов аутентификации;

• политики управления доступом на базе ролей и правил;

• интеграция возможностей аутентификации и авторизации с пакетными корпоративными приложениями;

• унифицированные политики управления доступом для различных платформ и организаций;

• контроль числа пользователей в системе и делегирование прав;

• аудит-системы безопасности и защита журнала протоколирования;

• надежные функции аудита и отчетности для всех событий доступа.

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

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

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

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

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

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

2. Непрерывная доступность служб. Как можно обеспечить непрерывную доступность служб, которые предоставляются сотрудникам, партнерам и клиентам, без падения качества или уровня обслуживания?

3. Соответствие нормам. Как внутренние или внешние аудиторы ИТ могут проверить, что организация на самом деле удовлетворяет требованиям законодательных норм, которым она должна соответствовать?

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

В настоящее время в компаниях сложилась тенденция фокусировки на внешних угрозах:

• защита от хакеров и внешних вторжений (межсетевые экраны);

• антивирусы, антиспам, контентные фильтры почты и др.;

• системы авторизации, токены, VPN для доступа пользователей к важной информации извне;

• контролируемые почтовые серверы, средства фильтрации контента;

• запрет альтернативных почтовых ящиков.

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

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

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

 

6.3. Методы управления рисками информационной безопасности

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

Процесс управления рисками ИБ может затрагивать только информационные риски либо может быть интегрирован с общим процессом управления рисками в организации, поскольку риски информационной безопасности затрагивают подразделения, ведущие основные направления ее деятельности, подразделение управления информационной инфраструктурой, ИТ-подраз-деление.

Процесс управления рисками информационной безопасности можно подразделить на следующие основные этапы:

1) выбор анализируемых объектов и уровня детализации их рассмотрения;

2) выбор методики оценки рисков;

3) идентификация активов;

4) анализ угроз и их последствий, определение уязвимостей в защите;

5) оценка рисков;

6) выбор защитных мер;

7) реализация и проверка выбранных мер;

8) оценка остаточного риска.

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

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

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

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

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

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

Политика безопасности является своеобразным фундаментом для программы безопасности компании. К этой политике нужно относиться серьезно с самого начала, в нее должны быть заложены идеи постоянной актуализации, обеспечивающие постоянное функционирование всех компонентов безопасности и работу по достижению целей, соответствующих целям бизнеса. Выработка собственной уникальной политики безопасности нужна только для тех организаций, чьи информационные системы и обрабатываемые данные можно считать нестандартными. Для типовой организации можно использовать типовой набор защитных мер, выбранный из наиболее распространенных рисков информационной безопасности в базе международных или локальных стандартов (ISO 27001). При использовании западных стандартов следует провести анализ на соответствие требованиям национального законодательства в области информационной безопасности.

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

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

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

 Интернет. Регламентация получения доступа, использования и контроля использования ресурсов сети Интернет, регламентация использования корпоративной и внешней электронной почты;

 дополнительные устройства. Регламентация самостоятельной установки/подключения дополнительных устройств, таких как USB, Fire-Wire, LPT, COM, IrDA, HDD, Floppy, DVD/CD-ROM, Tape, Modem, Bluetooth, Wi-Fi, мобильные устройства, прочее.

В некоторых компаниях используются так называемые «белые списки» устройств (например, USB, CD/DVD), доступных к использованию в соответствии с политикой безопасности, регламентированных по определенному производителю, модели, серийному номеру или по пользователям/группам пользователей.

Также в политике безопасности могут быть прописаны следующие ограничения:

• запрет/контроль использования личных мобильных телефонов, фото– и видеотехники, переносных компьютеров, дополнительных устройств передачи информации;

• контроль помещений и использование видеонаблюдения;

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

• ограничения использования факсов, модемов, телефонной связи;

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

• контроль каналов печати: локальных, сетевых, виртуальных;

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

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

Техническое разграничение доступа к ресурсам сети Интернет (выделенные компьютеры либо терминальный доступ) и предоставление доступа только к необходимым ресурсам либо разграничение специальным ПО позволяет осуществлять контроль использования сети Интернет, исключение взаимодействия с внутренней сетью организации и передачу данных. С помощью технических средств возможны отключение неиспользуемых устройств, постоянный контроль конфигураций компьютеров, а также аппаратное (либо программное) отключение возможности подключения дополнительных устройств. Дополнительно применяются регламентация использования переносных компьютеров и внешних носителей информации, обязательное шифрование всей критически важной информации. Существует техническое ограничение использования факсов, модемов (на офисных АТС), учет/аудиозапись использования телефонной связи, исключение возможности использования личных мобильных телефонов, контроль использования копировальной техники с помощью установки на открытых пространствах и видеонаблюдения.

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

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

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

• компьютерные программы для выявления, нейтрализации или устранения вредоносных программ (антивирусное ПО);

• системы обнаружения вторжений (СОВ), которые собирают и анализируют информацию из различных областей компьютера или сети для выявления возможных нарушений в системе безопасности;

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

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

К ключевым факторам успеха системы информационной безопасности можно отнести:

1) регулярный пересмотр политики информационной безопасности;

2) вовлечение всех сотрудников в процесс обеспечения информационной безопасности;

3) своевременность обнаружения и прогнозируемость развития проблем, оценку влияния проблем на бизнес-цели и управление непрерывностью бизнеса компании.

 

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

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

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

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

Рассмотрим основные риски, связанные с организацией проекта внедрения ИТ.

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

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

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

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

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

 Недоступность ресурсов для проектных работ. Как правило, «лучшие специалисты» уже заняты.

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

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

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

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

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

Также руководство должно открыто выявлять и разрешать конфликты, связанные с использованием системы, признавать, поддерживать, вознаграждать усилия по работе с новой системой. Команда управления проектом и команда по управлению персоналом должны разработать и внедрить систему стимулов за использование новой системы.

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

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

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

 

7.2. Как подобрать компетентную команду ИТ-проекта

Информационные системы часто охватывают практически всю деятельность предприятия, поэтому при внедрении ERP-системы большое значение приобретают задачи коммуникаций и совместной работы представителей различных и часто конкурирующих подразделений предприятия. Грамотно подобранная команда обеспечит большую часть успеха проекта.

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

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

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

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

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

Для правильного определения целей участников проекта и заинтересованных сторон желательно ответить на следующие вопросы:

• Кто является участником проекта?

• Имеет ли каждый участник проекта ясное представление о масштабах и целях проекта?

• Существует ли четкое распределение ответственности между участниками проекта?

• Кто в проекте является заинтересованными лицами?

• Каковы скрытые цели заинтересованных лиц?

• Как участники проекта могут способствовать достижению этих целей?

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

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

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

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

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

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

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

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

Компания Microsoft выделяет следующие основные принципы построения команды.

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

2. Представление интересов всех участвующих сторон, которые необходимы для успешной разработки ПО. Представление всех аспектов для управления и балансировки проекта в целях предотвращения неполноты, ошибок и однобоких решений.

3. Адаптация для соответствия характеру/масштабу проекта. Масштабируемость команд от небольших групп до сложных оргструктур.

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

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

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

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

Рис. 24. Матрица совмещения ролей для ИТ-проекта согласно PMbOK

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

Определить, насколько качественно подобрана команда проекта внедрения, помогут показатели эффективной деятельности команды, а именно:

• ясное понимание цели проекта и нацеленность на конечный результат всеми участниками проекта;

• четкое распределение функций и ответственности в команде;

• наличие плана развития команды;

• командная солидарность;

• взаимопонимание и бесконфликтность;

• посещаемость рабочих совещаний и активное участие в решении проблем.

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

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

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

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

• открытие новых проектов в кратчайшие сроки;

• контроль затрат на персонал и создаваемой добавочной стоимости;

• увеличение эффективности работы компании;

• сокращение затрат на фонд оплаты труда;

• сосредоточенность на основном бизнесе компании;

• снижение рисков.

 

7.3. Характеристики риск-менеджера

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

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

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

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

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

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

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

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

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

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

Основные функции управления рисками риск-менеджера (подразделения УР):

• разработка политики по управлению рисками;

• разработка, тестирование методов и моделей оценки рисков;

• разработка и/или выбор методологии;

• координация процесса управления рисками;

• взаимодействие с внутренними службами;

• управление портфелем рисков и оценка совокупного риска ИТ;

• создание и ведение базы данных и информационное обеспечение;

• доведение результатов оценки и управления рисками до высшего руководства компании.

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

Наличие риск-менеджера не исключает участия всех участников проекта в управлении рисками. Фактически каждый участник ИТ-проекта управляет рисками, связанными с ИТ. Риск-менеджер координирует и объединяет их усилия.

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

На специалиста в области управления рисками возлагается ответственность за каждодневную реализацию программы управления рисками и повышение уровня осознания важности вопросов риск-менеджмента внутри проекта. Он должен осуществлять не только ежедневный мониторинг состояния дел, но и обмениваться опытом и суждением с другими структурными подразделениями.

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

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

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

 

8.1. Требования к информационной системе управления рисками

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

При выборе систем следует учитывать широту охвата основных процессов управления рисками: идентификации рисков, оценки (качественной и количественной), выбора методов реагирования, мониторинга и контроля противорисковых мероприятий. Следует обратить особое внимание на функциональность обновления величин рисков, мониторинга эффективности используемых способов управления и способов управления остаточными рисками (например, перерасчет максимально допустимых величин рисков; процесс реагирования на инциденты и прочее), качества процесса реагирования на риски. Иногда инструмент оценки ИТ-рисков программных проектов позволяет отследить связи между выявленными рисками и причинами, которые ведут к ним, что является преимуществом выбранного решения.

Критериями выбора системы могут выступать следующие категории требований:

• информация о поставщике и продукте;

• функциональные требования;

• технические требования;

• цены и условия.

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

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

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

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

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

• технологичность решения;

• терминология и качество локализации системы;

• модульность;

• гибкость;

• масштабируемость;

• архитектура и техническая платформа;

• операционная среда и СУБД.

Цены и условия содержат оценку стоимости покупки (лицензии), внедрения и поддержки системы управления рисками с учетом приведенного примера количества пользователей.

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

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

Рис. 25. Пример портфеля критериев по выбору программного продукта

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

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

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

На верхнем уровне детализации веса определяются путем экспертной оценки (табл. 8).

Таблица 8.

Пример распределения доли критериев 

Требования могут отличаться по значимости и ранжироваться по приоритетности на три группы: «Критично», «Важно», «Желательно» (табл. 9). На основе этого каждому требованию присваивается вес в общей оценке (табл. 12). Для определения весов для оценки требований необходимо согласовать их приоритетность. Наименьший вес принимается за единицу, следующая категория присваивается группе критериев с условно в два раза большей значимостью и т. д. Веса рассчитываются на основе единиц относительной значимости. Сумма весов должна быть равна 100 %.

Таблица 9.

Приоритеты требований 

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

Среди функциональных критериев по выбору системы управления ИТ-рисками могут быть следующие:

• хранение данных в справочниках: риски, рисковые события, бизнес-процессы, классификаторы, статусы рисков;

• ведение единого реестра рисков;

• использование иерархии классификации;

• формирование отчетов и графических форм;

• открытость системы для дальнейшего развития и интеграции с другим ПО;

• разделение прав доступа к хранимой информации о рисках, рисковых событиях на основе ролевого подхода;

• механизм автоматической генерации уведомлений по электронной почте;

• возможность внесения изменений в систему с учетом пожеланий заказчика.

Могут существовать функциональные требования для связывания рисков и рисковых событий, факторов риска и бизнес-процессов.

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

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

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

Вне зависимости от выбранного типа решения программный продукт по управлению рисками в ИТ-проекте должен отвечать сформулированным требованиям и выполнять основные задачи управления рисками за счет:

• функций системного автоматизированного подхода в области управления рисками ИТ-проекта;

• механизмов анализа рисков с применением современных статистико-математических методов;

• функций контроля выполнения мероприятий по минимизации рисков и расчету экономического эффекта;

• механизмов автоматического мониторинга эффективности системы управления рисками;

• реализации сводной аналитической отчетности по управлению рисками в режиме реального времени.

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

 

8.2. Сравнение коробочного и собственного ПО управления рисками

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

При выборе следует обратить внимание на три фактора: сроки внедрения, качество внедрения, стоимость внедрения.

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

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

Таблица 10.

Критерии выбора заказного/готового программного продукта 

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

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

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

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

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

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

Процесс выбора поставщика программного решения по управлению рисками, как правило, происходит в соответствии с основными этапами: обзор рынка, формирование требований к системе и подготовка информационного запроса поставщикам (при необходимости), рассылка информационного запроса и анализ ответов поставщиков программного обеспечения, выбор системы (рис. 26).

На начальном этапе происходят определение требований к системе управления рисками, согласование требований внутри проектной команды. Далее происходят анализ рынка решений и предварительный просмотр систем, где определяются наличие требуемой функциональности, опыт внедрения, отзывы от предыдущих аналогичных проектов. На основе предварительного просмотра систем происходит выбор сокращенного списка поставщиков. Далее осуществляется более детальный анализ на соответствие функциональным, техническим и прочим требованиям на основе взвешенной модели оценки. Если поставщикам рассылался запрос на предоставление информации (Request for Information – RFI), проводится качественный анализ ответов. Вместе с анализом ответов составляются сценарии показа систем на соответствие требованиям. Демонстрации систем оцениваются с помощью балльной оценки, основанной на анализе сильных и слабых сторон продукта, впечатления от поставщика решения. По окончании анализа поставщиков на соответствие требованиям и демонстрации системы формируется решение по выбору поставщика системы управления рисками. После заключения контракта происходит внедрение выбранного решения.

Рис. 26. Этапы отбора поставщиков ПО

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

 

8.3. Обзор ПО: преимущества и недостатки

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

В качестве продукта поддержки процессов управления рисками при реализации программных проектов может использоваться как специализированная система, так и модули управления рисками многофункциональных систем управления проектами (Microsoft Project, Open Plan, Primavera) или же модули системы управления предприятием (Oracle, SAP, Microsoft Axapta и прочие). Как было описано выше, возможно создание собственной разработки в области управления рисками программных проектов.

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

1. Управление операционными/банковскими рисками на уровне всего предприятия реализовано в программных продуктах Egar Technology, SAS, IBM, прочих.

2. Поддержка рисков информационной безопасности (с привязкой к существующим стандартам, например ISO 17799) отражена в решениях Cramm, RiskWatch, Кондор+, Cobra, прочих.

3. Для управления рисками проектов (как один из инструментов Project Management Software) используются системы Primavera Project Planning, Spider Project, Open Plan, прочие.

4. Управление рисками программных проектов (на основе методологий разработки ПО) реализовано практически всеми крупными разработчиками программного обеспечения, наиболее известны продукты IBM Rational Portfolio Manager, OCTAVE-S.

Рис. 27. Рейтинг систем управления рисками, Standish Group Report, 2009 (RiskTech100TM)

Помимо перечисленных систем, на российском рынке также присутствуют такие многофункциональные системы в области управления рисками, как: @Risk Professional for Project, Dekker TRAKKER, Enterprise project, ER Project 1000, Intelligent Planner, Mesa/Vista Risk Manager, Risk Track, Open Plan. ERA by Methodware, NetRisk/RiskOps 2.3, Pacemetrics. Обзор наиболее популярных западных систем представлен на рис. 27.

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

1. IBM Rational Portfolio Manager (IBM). Система полностью поддерживает методологию COBИТ и предоставляет инфраструктуру для введения элементов управления, которые помогут обеспечить соответствие законодательным нормативам, таким как закон Сарбейнса-Оксли и соглашение Basel II, и устранить разрыв между потребностями управления, техническими проблемами, бизнес-рисками и требованиями показателей производительности и реализацией инструментов финансового контроля.

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

2. OCTAVE-S – Operationally Critical Threat, Asset and Vulnerability Evaluation System (SEI). Система OCTAVE-S разработана институтом Software Engineering Institute (SEI) при университете Карнеги Меллон для моделирования поведения оценки рисков в организации. OCTAVE спроектирована на основе методологии информационной безопасности и предусматривает высокую степень гибкости, достигаемую путем выбора критериев, которые предприятие может использовать при адаптации под собственные нужды, и позволяет поддерживать следующие процессы управления рисками:

• идентификацию критичных информационных активов;

• идентификацию угроз для критичных информационных активов;

• определение уязвимостей, ассоциированных с критичными информационными активами;

• оценку рисков, связанных с критичными информационными активами.

Особенность данной методики заключается в том, что весь процесс анализа производится силами сотрудников организации, без привлечения внешних консультантов. Для этого создается смешанная группа, включающая как технических специалистов, так и руководителей разного уровня, что позволяет всесторонне оценить последствия возможных инцидентов и разработать контрмеры. В качестве инструмента моделирования и оценки OCTAVE предлагает при описании профиля использовать «деревья вариантов». В доступной базе данных рассматриваются компоненты следующих классов: серверы; сетевое оборудование; СЗИ; персональные компьютеры; домашние персональные компьютеры «надомных» пользователей, работающих удаленно, но имеющих доступ в сеть организации; мобильные компьютеры; системы хранения; беспроводные устройства и связанные с ними риски.

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

3. Risk Watch (RiskWatch, Inc). Компания RiskWatch разработала собственную методику анализа рисков и семейство программных средств, в том числе для информационных рисков ИТ-проектов (RiskWatch for Information Systems), и является мощным средством анализа и управления рисками. Программное обеспечение охватывает физические методы защиты ИС, а также информационные риски и служит для оценки требованиям стандарта ISO 17799. В семейство RiskWatch входят программные продукты для проведения различных видов аудита безопасности, которые позволяют вводить в модель системы безопасности новые категории, описания, а также получать качественные и количественные ответы на вопросы безопасности, исходя из данных в системе.

В качестве критериев для оценки и управления рисками используются «предсказание годовых потерь» (Annual Loss Expectancy – ALE) и оценка «возврата от инвестиций» (Return on Investment – ROI). В части оценки рисков система дает возможность устанавливать связи между ресурсами, потерями, угрозами и уязвимостями, рассчитывать математические ожидания потерь с учетом частоты возникновения угрозы риска и стоимость ресурса, который подвергается риску. Дополнительно рассматриваются сценарии «что, если», которые позволяют описать аналогичные ситуации при условии внедрения средств защиты.

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

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

4. CRAMM (CCTA Risk Analysis and Management Method – CCTA UK). Система CRAMM создана на основе методологии управления рисками CRAMM и предполагает использование технологий оценки угроз и уязвимостей по косвенным факторам с возможностью проверки результатов. В основе метода CRAMM лежит комплексный подход к оценке рисков, сочетающий количественные и качественные методы анализа. В модель оценки заложен механизм моделирования информационных систем с позиции безопасности с помощью обширной базы данных по контрмерам. Для каждой группы ресурсов и каждого из 36 типов угроз/уязвимостей генерируется список вопросов, допускающих однозначный ответ. Уровень угроз и уязвимостей оценивается, в зависимости от ответов, как очень высокий, высокий, средний, низкий и очень низкий. Далее CRAMM объединяет угрозы и уязвимости в матрице риска. Система нацелена на детальную оценку рисков и эффективности предполагаемых к использованию комбинаций методов управления рисками. Помимо анализа рисков, CRAMM позволяет решать ряд параллельных задач, включая:

• проведение обследования используемой/внедряемой ИТ и выпуск сопроводительной документации на всех этапах его проведения;

• проведение аудита на основе стандарта безопасности информации BS 7799:1995;

• разработку политики безопасности и плана обеспечения непрерывности бизнеса.

CRAMM является универсальным методом и подходит как для крупных, так и для малых организаций, как правительственного, так и коммерческого сектора. Версии программного обеспечения CRAMM, ориентированные на разные типы организаций, отличаются друг от друга своими базами знаний (profiles).

5. КОНДОР+ (Digital Security). Программный продукт позволяет менеджерам ИТ-проектов проверить политику информационной безопасности компании на соответствие требованиям ISO 17799. КОНДОР+ включает в себя более 200 вопросов, ответив на которые специалист получает подробный отчет о состоянии существующей политики безопасности, а также модуль оценки уровня рисков соответствия требованиям ISO 17799.

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

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

6. Отечественные программно-инструментальные комплексы «Управление рисками», «Уязвимость», «Анализ безопасности» (в составе комплекса «Моделирование процессов в жизненном цикле систем – ноу-хау», свидетельство Роспатента № 2004610858) и «Программно-вычислительный комплекс оценки качества производственных процессов» (свидетельство Роспатента № 2010614145) – см. рис. 28–35. Дружественный пользовательский интерфейс делает работу с комплексами удобной и доступной практически любому пользователю.

Рис. 28. Заставка комплекса «УПРАВЛЕНИЕ РИСКАМИ»

Комплексы базируются на применении математических методов и моделей, согласно требованиям системообразующих стандартов (ГОСТ Р ИСО 9001 «Системы менеджмента качества. Требования», ГОСТ Р ИСО/МЭК 15288 «Системная инженерия – Процессы жизненного цикла систем», ГОСТ Р ИСО/МЭК 12207 «Системная и программная инженерия – Процессы жизненного цикла программных средств», ГОСТ Р ИСО/МЭК 16085 «Менеджмент риска. Применение в процессах жизненного цикла систем и программного обеспечения», ISO/IEC 31000 «Риск-менеджмент. Принципы и руководства» и др.), в том числе в процессе разработки проекта и системы, при проведении контроля, аудита и сертификации. Применение комплексов обеспечивает аргументированное решение следующих научно-технических задач: организация эффективных систем менеджмента качества на предприятиях; обоснование системотехнического облика и количественных требований технического задания к характеристикам систем, технологиям их создания и функционирования, к квалификации разработчиков и пользователей; оценка и обоснование технических решений, анализ и снижение рисков при управлении проектами; исследование вопросов защищенности систем от потенциальных угроз безопасности (в том числе информационной безопасности), выявление «узких мест» и уязвимостей систем и рациональных путей их устранения с указанием условий, когда это принципиально возможно, и др.

Рис. 29. Исходная форма для выбора моделей

Рис. 30. Заставка комплекса «УЯЗВИМОСТЬ»

Рис. 31. Исходная форма для выбора моделей

Рис. 32. Заставка комплекса «АНАЛИЗ БЕЗОПАСНОСТИ»

Рис. 33. Исходная форма для выбора моделей

Рис. 34. Заставка ПВК для оценки качества производственных процессов

Рис. 35. Исходная форма для выбора моделей

Десятки расчетных примеров, приведенные в монографиях [10], [11], доказывают практичность этих комплексов для управления качеством и рисками (при анализе безотказности функционирования сложных систем, конструируемых из ненадежных элементов; управлении своевременностью представления, полнотой и достоверностью информации; сравнении защищенности информации в открытой и закрытой сетях; прогнозировании качества функционирования информационных систем; выборе рациональных способов построения и модернизации систем теплоснабжения; оценке человеческого фактора; анализе технологических процессов, управлении рисками в опасном производстве и оценке эффективности методов неразрушающего контроля; анализе экологической безопасности; прогнозировании безопасности функционирования трубопроводов; анализе уязвимости морских нефтегазодобывающих систем; выработке рекомендаций по повышению защищенности важных наземных объектов и др.).

Рассмотрим сравнительные характеристики специализированных систем в области управления рисками для реализации программных проектов, которые представлены в табл. 11.

Таблица 11.

Сравнительный анализ систем по управлению рисками в области программных проектов 

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

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

В заключение приведем несколько наглядных примеров извлечения пользы для бизнеса на основе рационального применения систематизированных знаний в области управления рисками. Расчеты базируются на программно-инструментальных комплексах «Управление рисками», «Уязвимость», «Анализ безопасности» и «Программно-вычислительного комплекса оценки качества производственных процессов» – см. рис. 28–33.

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

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

Первая компания закупает продукцию, прошедшую контроль качества всеми рекомендованными видами (акустическим, магнитным, оптическим, проникающими веществами, радиационным, радиоволновым, тепловым и электромагнитным) и методами неразрушающего контроля, что подтверждено сертификатами соответствия на систему менеджмента качества по ИСО 9001 и на выпускаемую продукцию, а также протоколами испытаний продукции. В итоге при общем объеме контролируемой продукции в 100 000 условных единиц в месяц (например, погонных метров или тонн продукции) доля возможных дефектов до контроля составляет 5 %, частота ошибок при контроле – пропуск не более 2 дефектов в год (это скрытые дефекты, не выявляемые существующими методами или пропущенные при контроле).

Вторая компания довольствуется сертификатом на систему менеджмента качества по требованиям ИСО 9001. Причем у поставщика используется лишь радиоволновой метод неразрушающего контроля, позволяющий выявить такие дефекты, как расслоения и отклонения металлопродукции по толщине (то есть не более 10 % возможных дефектов). За счет этого доля возможных дефектов до контроля составляет уже 20 %, более того, при контроле возможен пропуск множества скрытых дефектов литья (шлаковых и флюсовых включений, усадочных раковин, газовых пузырей, трещин и др.), дефектов обработки давлением (внутренних и поверхностных трещин, разрывов, закалов, вмятин и др.), дефектов термообработки (перегревов, пережогов, трещин закалочных и водородных и др.) – суммарно около 30 дефектов в год.

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

Для решения используется модель «Риск ошибочных аналитических выводов» инструментария «УЯЗВИМОСТЬ» (также может быть использована модель «Оценка риска неадекватной интерпретации событий» комплекса «Управление рисками»). Исходные данные и результаты расчетов отражены на рис. 36.

Рис. 36. Сравнительная оценка эффективности систем контроля качества, пример 1

Сравнительный анализ полученных зависимостей показал:

1) риск ошибочных аналитических выводов для 1-й компании составляет 0,15, а для 2-й – 0,92 (!);

2) при изменении объема контролируемой продукции от 50 000 до 200 000 условных единиц в месяц риск ошибочных аналитических выводов возрастает для 1-й компании с 0,08 до 0,58, а для 2-й компании – с 0,71 до 0,96;

3) увеличение доли возможных дефектов вдвое принципиально не влияет на значение риска ошибочных аналитических выводов, то есть эффективность применяемых технологий контроля зависит существенно от других параметров, в частности от частоты возможных ошибок;

4) при увеличении частоты возможных ошибок контроля вдвое риск ошибочных аналитических выводов возрастает для 1-й компании с 0,08 до 0,28, а для 2-й компании – с 0,71 до 0,99.

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

2. Для 2-й компании предприятие-поставщик реализует откровенно бракованную продукцию (брак ежемесячно имеет место с вероятностью около 0,9), что негативно скажется в дальнейшем при эксплуатации системы.

Это – недвусмысленные выводы для дальнейшего ведения бизнеса.

Пример 2. В процессе длительной эксплуатации неизбежны аварии на трубопроводах. У первой из сравниваемых компаний их ожидается меньше за счет более эффективного управления качеством и рисками. Положим, на поддержание системы контроля качества на предприятиях-поставщиках ежегодные расходы 1-й компании, практикующей, в отличие от 2-й компании, различные виды проверок трубопродукции (акустические, магнитные, оптические, с проникающими веществами, радиационные, радиоволновые, тепловые и электромагнитные), оцениваются в 5 млн. руб., а 2-й компании – в 1 млн. руб., за 2 года расходы считаются вдвое больше. На мониторинг и контроль ситуации в процессе эксплуатации трубопровода 1-я компания, применяющая современные методы, включая комбинацию дистанционного зондирования интегральных и локальных методов инспекции, методов внутритрубной инспекции, расходует в течение 2 лет 50 млн. руб., а 2-я, использующая лишь вертолетное обследование и регулярные рентгенографические методы инспекции, – 10 млн. руб. Кроме этого, на меры противодействия рискам 1-я компания, применяющая в дополнение к мерам 2-й компании проверку качества выпускаемой продукции всеми рекомендованными видами и методами неразрушающего контроля и дистанционное зондирование (космический мониторинг и авиационную съемку), расходует в течение 2 лет 14 млн. руб., а 2-я компания – 12 млн. руб. Более детальные условия примера см. в монографиях [10], [11].

Требуется провести комплексный сравнительный анализ технической политики обеих компаний по показателям рисков и возможных ущербов с учетом затрат на систему контроля качества на предприятиях.

Для решения используются модели инструментария «УЯЗВИМОСТЬ». Комплексный сравнительный анализ технической политики обеих компаний по показателям рисков и возможных ущербов с учетом затрат на систему контроля качества на предприятиях, мониторинга и контроля при эксплуатации и принимаемых мер противодействия показал следующее (см. рис. 37, 38).

Рис. 37. Исходные данные и результаты анализа для 1-й компании, пример 2

Техническая политика 1-й компании характеризуется показателями: при суммарных затратах на меры ситуационного анализа, мониторинга и контроля и противодействия рискам в объеме 74 млн. у.е. риск негативного воздействия на компанию равен 0,334, а математическое ожидание (МОЖ) ущерба – 3,34 млн. у.е. Наибольший вес в уязвимость (риск равен 0,121 из 0,334) вносят неэффективные мониторинг и контроль. Если практически при разумных затратах принятые меры мониторинга и контроля неулучшаемы, то полученные риски и ущербы должны восприниматься 1-й компанией как неизбежные. Как интегральный результат показатели эффективности технической политики 1-й компании могут быть приняты в качестве положительного ориентира для аналогичного рода предприятий.

Рис. 38. Исходные данные и результаты анализа для 2-й компании, пример 2

Несмотря на существенно меньшие расходы 2-й компании (24 против 74 млн. у.е.), математическое ожидание ущерба 9,92 млн. у.е. в три раза превышает ожидаемый ущерб 1-й компании (3,34 млн. у.е.), при этом ущерб соизмерим с затратами. Наибольший вес в уязвимость (0,656 из 0,992) вносят неэффективные мониторинг и контроль и слабые меры противодействия рискам. Риск негативного воздействия на компанию, равный 0,992, свидетельствует о неизбежности реализации потенциальных угроз 2-й компании в течение ближайших 2 лет, несомненно, это отрицательно скажется на конкурентоспособности продукции и услуг компании. Более того, цифры говорят о том, что если даже принимаемые меры ситуационного анализа, мониторинга и контроля и противодействия рискам 2-й компании оформлены в виде документа «Техническая политика», приходится констатировать отсутствие таковой политики из-за ее неэффективности.

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

Предполагается, что различного рода угрозы безопасности возникают с частотой не более 1 раз в час, среднее время восстановления системы безопасности после случайного или умышленного выведения из строя составляет не более 30 минут. При этом подсистема 1 защиты головного предприятия использует модель нарушителя, характеризуемую комплексом преград из таблицы на рис. 39. Непрерывный мониторинг осуществляется лишь для 10-й преграды, то есть системы криптографической защиты, наработка на ошибку соизмерима со стойкостью и принята на уровне 2 лет. Наработка на ошибку средств непрерывного мониторинга подсистемы связи составляет 1 месяц. В каждом из подчиненных предприятий подсистемы 3 реализованы те же технические решения по системе защиты, что и в подсистеме 1, поэтому они характеризуются теми же табличными данными, что отражены на рисунке. Каждый из оставшихся компонентов (на рисунке это отдельные клеточки, соединенные последовательно) подсистемы 3 – это обеспечивающие средства сбора и хранения данных, а на предприятии сверху – еще и средства отображения в виде контролируемого табло коллективного пользования, причем все без непрерывного мониторинга их состояния. Пусть характеристики этих средств одинаковы, они отражены справа внизу на рис. 39. Требуется количественно спрогнозировать степень информационной безопасности такой системы при функционировании в течение месяца и года и выявить ее узкие места.

Рис. 39. Структура системы информационной безопасности холдинга, пример 3

Решение базируется на использовании модели «Анализ комплексной безопасности» комплекса «Анализ безопасности». Результаты расчетов комплексной безопасности отражены на рис. 40.

Рис. 40. Результаты анализа и прогноза уровня информационной безопасности холдинга, пример 8.4.3

Результаты анализа и прогноза информационной безопасности холдинга показали:

• 1-я и 2-я подсистемы приблизительно равномощны, при этом для 1-й подсистемы мониторинг криптографической системы защиты (10-й преграды) эффективен;

• 3-я подсистема – наиболее узкое место в системе, внутри нее узкими звеньями являются средства сбора, хранения и отображения данных;

• при реализации мониторинга и контроля в течение месяца преодоления всех преград исключены с вероятностью 0,9, а в течение года – с вероятностью 0,43, без мониторинга и контроля эти показатели снижаются до уровня 0,83 и 0,29 соответственно. Несмотря на высокую эффективность мониторинга и контроля для 1-й подсистемы, в целом они малоэффективны. Это говорит о том, что в течение года возможны случаи нарушения информационной безопасности холдинга.

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

Рис. 41. Сравнительная оценка безопасности авиаполетов в России и США до 11 сентября 2001 года

Полученные рекомендации, обоснованные количественными расчетами, несомненно, способствуют укреплению бизнеса.

Пример 4. Исследования эффективности мер повышения безопасности авиаполетов проиллюстрируем на исходных данных, полученных в результате анализа террористических акций на пассажирских авиалиниях (детальные исходные данные см. в монографиях [10], [11]). Многие из указанных рекомендаций, опубликованных сразу после 11 сентября 2001 года, уже реализованы.

В поисках ответа на вопрос «Насколько эффективной была существовавшая до 11 сентября 2001 года система обеспечения безопасности полетов в России и США с точки зрения противодействия террористам?» получены следующие результаты анализа рисков (см. рис. 41).

1. И в России, и в США существовавшая система обеспечения безопасности была весьма эффективной против необученного или неподготовленного террориста (риск нарушения безопасности за время полета не выше 0,002 – см. рис. 36 слева). Это достигалось за счет предполетного электронного досмотра и проверки пассажиров и багажа.

2. Риски нарушения безопасности авиаполетов в России и США с возможным проникновением в кабину пилотов при террористическом воздействии со стороны подготовленных террористов приблизительно одинаковы – около 0,5 (см. рис. 36 справа для преград с 1-й по 4-ю). А при оперативном оповещении земли о захвате и возможности за счет этого какого-либо существенного противодействия террористам эта вероятность снижается лишь до уровня 0,24. При этом в России существенной преградой являлись бронированная дверь самолета, а в США – более современная электронная система досмотра. Собственно, как для России, так и для США до 11 сентября 2001 года проведенные расчеты показали недопустимо высокую вероятность достижения террористических целей при соответствующей степени подготовки террористов к этому акту.

3. Полученные откровенно озадачивающие цифры (риск на уровне 0,47–0,48) означают, что время одиночных террористов «с улицы» практически ушло. Они могут сохраниться лишь на местных авиалиниях развивающихся стран, где отсутствуют средства электронного досмотра и проверки пассажиров. То есть расчеты позволяют с достаточной степенью уверенности сделать заключение о том, что практически все состоявшиеся террористические акты совершались подготовленными преступниками после тщательного планирования операции.

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

Рис. 42. Анализ эффективности дополнительных мер для снижения рисков, пример 5

Вывод: в России и США существовавшая до 11 сентября 2001 года система обеспечения безопасности авиаполетов являлась малоэффективной против планируемых действий со стороны подготовленных террористов, наиболее «узким» местом были слабая защищенность кабины пилотов и отсутствие мер активного противодействия на борту самолета.

Пример 5. Насколько реально может быть повышен уровень безопасности полетов и за счет чего?

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

Мера 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. То есть реализация вышеуказанных мер приводит к снижению риска нарушения безопасности на несколько порядков! Но это далеко не победа. Очевидно, что первые же неудачи заставят террористов анализировать их причины и искать новые недостатки системы безопасности, тем самым ожидается длительное противоборство. Успешным это противоборство может оказаться лишь тогда, когда будут приниматься упреждающие меры, эффективность которых может быть доказана или опровергнута с использованием математического моделирования.

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

 

1. Описание исходной ситуации

Руководство компании после трех лет достаточно успешного развития приняло решение о внедрении интегрированной системы управления предприятием «ИТ Solutions».

Компанией руководит директор А. Громыкин, который де-факто не является главным лицом компании. Основным руководящим звеном и правой рукой директора является зам. директора В. Доброхотов, он определяет стратегические планы развития компании и направления деятельности. ИТ-отделом руководит С. Удальцов, который присушивается к мнению ключевого сотрудника ИТ-отдела А. Мудрецова. Предполагается, что система ИТ Solutions будет отвечать потребностям сотрудников и помогать им решать каждодневные задачи.

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

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

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

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

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

Под проект выделен бюджет в 3 000 000 долларов США, который рассчитали и обосновали специалисты финансовой службы компании вместе с привлеченными внешними консультантами. Проект планируется закончить в течение 12 месяцев и окупить за следующие 12 месяцев.

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

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

 

Задание 1. Классификация рисков

Цель: разработать классификацию рисков ИТ-проекта.

В составе команды экспертов вы участвуете в определении классификации рисков проекта.

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

2. Зафиксируйте разработанную вами классификацию для ИТ-проекта в графическом виде.

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

 

Задание 2. Идентификация рисков

Цель: получить список идентифицированных рисков проекта.

В составе команды экспертов вы участвуете в идентификации рисков проекта.

1. Постройте причинно-следственную диаграмму (диаграмму Ишикавы) для рисков проекта.

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

3. Все идентифицированные риски внесите в экспертный лист. Заполните все графы.

 

Задание 3. Качественный анализ рисков

Цель: получить список идентифицированных рисков проекта, проранжированных по приоритетам.

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

2. Добавьте колонку «Вероятность» и проставьте в ней вашу оценку вероятности возникновения каждого риска – величину от 0.00 до 1.00.

Добавьте колонку «Важность» и внесите в нее произведение содержимого граф «Воздействие» и «Вероятность». По этой графе вы сможете определить наиболее важные и приоритетные риски проекта. Они будут иметь максимальные значения важности.

3. Распределите риски с учетом их приоритетов – от наиболее важного к менее важному.

 

Задание 4. Построение дерева решений

Цель: научиться производить количественный анализ рисков проекта путем построения дерева решений и расчета вероятностного NPV проекта.

1. Постройте «дерево решений» для проекта, учитывая, что:

• на начальном этапе проекта необходимо провести анализ существующих решений и выбрать удовлетворяющее нас. Стоимость исследования – 200 000 долларов США. Вероятность получения положительного результата – 0,9;

• в случае положительных результатов выбора решения необходимо будет произвести анализ технической реализуемости предлагаемого решения в данном конкретном случае. Анализ потребует привлечения специалистов и проведения целого комплекса работ стоимостью 200 000 долларов. Вероятность успеха – 0,7;

• в случае наличия технических и организационных возможностей для реализации выбранного решения на предприятии выделяется пилотная зона, по результатам внедрения в которой будет приниматься решение о продолжении проекта и распространении системы на все предприятие. Пилотное внедрение потребует 200 000 долларов США. Вероятность завершения проекта на этом этапе невелика, всего 0,1;

• дальнейшая реализация проекта потребует 2 400 000 долларов США. Моделирование денежных потоков в случае реализации проекта, по мнению аналитиков, обеспечит притоки наличности в течение всего проекта ежегодно в размере 5 000 000 долларов США.

2. Рассчитайте вероятностный NPV всего проекта после года эксплуатации системы. Для упрощения расчетов используйте три допущения:

• начало эксплуатации произойдет ровно через год после начала проекта;

• ставка дисконтирования в расчетах не учитывается;

• расходы и доходы, связанные с получением и возвратом кредита, не учитываются.

3. Дайте свою оценку полученным результатам.

(Правильный ответ: вероятностный NPV проекта – 968 200 долларов США.)

 

Задание 5. Планирование реагирования на риски

Цель: научиться создавать план реагирования на риски проекта.

1. Заполните предлагаемые формы, указав соответствующие мероприятия для каждого риска.

 

Задание 6. Отчетность по управлению рисками

Цель: научиться формировать базовую отчетность по рискам ИТ-проекта.

1. Заполните карточку риска для наиболее приоритетного риска проекта. Используйте образец заполнения.

 

Задание 7. Заполните анкету для проведения ИТ-аудита

Цель: научиться выделять категории для анализа ИТ-состояния, формировать опросники для проведения ИТ-аудита.

1. Разработайте собственные вопросы для проведения ИТ-аудита и оценки состояния ИТ в организации.

1.1. Категория «Качество организации управления ИТ». Предложите собственные вопросы для оценки качества организации управления ИТ, учтите в вопросах следующие факторы: структура службы ИТ и ее подчиненность; права и обязанности сотрудников; численность персонала, квалификация, стаж работы, текучка кадров, прочие.

1.2. Категория «Планирование развития ИТ». Предложите собственные вопросы для оценки планов по развитию ИТ, учтите в вопросах следующие факторы: планы работ по развитию ИТ; процедуры формирования ИТ-бюджета, контроль формирования и исполнения планов по ИТ; наличие KPI по оценке деятельности ИТ-службы, прочее.

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

2. Для оценки состояния ИТ в организации используйте образец опросника, приведенный ниже. В опроснике необходимо выбрать наиболее подходящий ответ по каждой из категорий:

Пример 1. Наличие документации по ИС (ТЗ, проектная документация, прочая).

• Организационно-техническая документация по системам присутствует в полном объеме. Есть вся необходимая информация.

• Организационно-техническая документация по системам присутствует в достаточном объеме. По мере необходимости обращаемся к разработчикам ИС.

• Организационно-техническая документация присутствует частично. Есть ТЗ, акты приемки, проектная документация, но системы документированы не полностью.

• Из организационно-технической документации присутствуют только ТЗ и акты приемки.

• Организационно-техническая документация отсутствует.

Пример 2. Пользователи информационных систем.

• Пользователь системы – все предприятие, все пользователи работают в одной системе.

• Различные подразделения используют разные системы, однако данные консолидируются.

• Часть подразделений использует систему/системы, однако на предприятии существуют участки, которые необходимо автоматизировать.

• Автоматизация на предприятии хаотична. Отсутствует стратегия по вопросам использования и развития систем. Данные систем не консолидируются.

• Автоматизация на предприятии отсутствует/присутствует в ограниченном объеме.

Пример 3. Качество использования ИС. Наличие актов приемки систем в эксплуатацию, программ и методик испытаний, приказов о внедрении систем.

• Существует стратегия ИТ, однако вопрос внедрения систем в ней не затронут. Статус и назначение систем определены. Существуют требования к документированию.

• Статус систем определен. Планы их внедрения не определены. К документации требования не определены.

• Статус систем не определен. Вопрос о внедрении поднимается по необходимости. Требования к документированию не определены.

• Статус систем на предприятии не определен. Документация определяется поставщиками.

 

Задание 8. Составьте план коммуникаций по ИТ-проекту

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

1. Проведите анализ участников проекта. Определите ключевых участников: владелец, заказчик, пользователи «ИТ Solutions», консерваторы, новаторы, советчики.

2. Идентифицируйте существующие проблемы на этапе инициации.

3. Разработайте план управления коммуникаций на основе следующих данных:

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

 частота прохождения информации: на главных вехах, ежедневно, еженедельно, при необходимости или изменениях;

 способ коммуникации: электронная почта, официальная встреча, совещание, бумажная копия, телефон.

 

Список литературы

1. Аалдерс Роб. ИТ-аутсорсинг: практ. руководство. – Сер.: Библиотека IBS. – Альпина Бизнес Букс, 2004.

2. Андон Ф. И., Суслов В. Ю., Коваль Г. И., Коротун Т. M. Основы инженерии качества программных систем. – Киев: Академпериодика, 2002. – 502 с.

3. Аникин Б. А., Рудая И. Л. Аутсорсинг и аутстаффинг: высокие технологии менеджмента. – Сер.: Высшее образование. – М.: Инфра-М, 2005.

4. Бабенко Л. П., Лаврищева Е. М. Основы программной инженерии: учебник. – Киев: Знання, 2001. – 269 с.

5. Боэм Б. У. Инженерное проектирование программного обеспечения. – М.: Радио и связь, 1985. – 511 с.

6. Брукс П. Мифический человеко-месяц. – М.: Мир, 1972. – 234 с.

7. Гультяев А. К. MS PROJECT 2002. Управление проектами. Русская версия: практ. пособие. – СПб.: КОРОНА, 2003. – 592 с.

8. ДеМарко Том, Листер Тимоти. Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения. – М.: Компания p.m.Office, 2005.

9. Джалота П. Управление программными проектами на практике. – М.: Лори, 2005.

10. Костогрызов А. И., Нистратов Г. А. Стандартизация, математическое моделирование, рациональное управление и сертификация в области системной и программной инженерии. – М.: Вооружение, политика, конверсия, 2004; 2005. – 395 с.

11. Костогрызов А. И., Степанов П. В. Инновационное управление качеством и рисками в жизненном цикле систем. – М.: Вооружение, политика, конверсия, 2008. – 404 с.

12. Макконнелл С. Остаться в живых: руководство для менеджеров программных проектов. М.: Питер, 2006.

13. Ньюэлл Майкл В. Управление проектами: руководство по подготовке к сдаче сертификационного экзамена РМР. – М.: КУДИЦ-Образ, 2006.

14. Ройс У. Управление проектами по созданию программного обеспечения. – М.: ЛОРИ, 2002.

15. Спарроу Элизабет. Успешный ИТ-аутсорсинг. – М.: КУДИЦ-Образ, 2004.

16. Уокер Ройс. Управление проектами по созданию программного обеспечения. – М.: Лори, 2007.

17. Фатрелл Р. Т., Шафер Д. Ф., Шафер Л. И. Управление программными проектами: достижение оптимального качества при минимальных затратах / пер. с англ. – М.: Вильямс, 2004.

18. Филлипс Д. Менеджмент ИТ-проектов. – М.: ЛОРИ, 2005.

19. Черников A. Теория и практика управления проектами // Компьютерное обозрение. – 2003. – № 10. – С. 24–39.

20. Boehm B. W. Software risk management. IEEE Computer Society Press. – Washington, 1989.

21. Charett R. Software engineering risk analysis and management. – N.Y.: McGraw – Hill, 1989.

22. Duncan B. A Guide to the Project Management Body of Knowledge // PMBOK GUIDE. – PMI, 2004.

23. Glib T. Principles of software engineering management. – Wokingham, England: Addison-Wesley, 1998.

24. IEEE Std 1058–1998. IEEE Standard for Software Project Management Plans.

25. ISO/IEC TR 16326:1999. Guide for the application of ISO/IEC 12207 to project management.

26. MSF, Microsoft, Microsoft Solutions Framework. – Отдел MSF, Microsoft, 2002.

27. Pfleeger S. L. Software Engineering. Theory and Practice. – Prentice Hall, 1998. – 576 p.

28. Reiter D. J. Software management. – IEEE Computer Society Press, Los Alomos. – 1993.

29. Software Risk Management / Ronald P. Higuera, Yacov Y. Haimes. – Software Engineering Institute, Carnegie Mellon University, 1996.

30. Sommerville I. Software engineering. – Lancaster University. Pearson Education Limited, 2001.

31. Thayer R. H., ed. Software Engineering Project Management. – 2nd ed. – IEEE CS Press, Los Alamitos, Calif. 1997. – 391 p.

32. The Guide to the Software Engineering Body of Knowledge, SWEBOK, IEEE Computer Society Professional Practices Committee («Руководство к своду знаний по программной инженерии»). – 2004.