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

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

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

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

2.3 Основные положения и ограничения предлагаемой методологии оценки риска проектов

2.3.1 Специфика проектов системной интеграции

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

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

Рисунок 7 Жизненный цикл проектов системной интеграции

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

· архитектура решения - принципы проектирования, используемые для создания хранилищ данных. 90% задач рассматриваемого проекта выполняются в рамках принятых в компании заказчика архитектурных стандартов хранения и обработки данных;

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

Классическая архитектура хранилищ данных состоит из четырех слоев:

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

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

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

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

И включает в себя:

· мастер-данные - данные, определяющие основные бизнес-сущности компании;

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

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

· метаданные - системные данные о данных (структуры, типы, доступы).

2.3.2 Основные положения предлагаемой методологии оценки проектных рисков

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

Для того, чтобы с большой точностью оценить значение фактора неопределенности, построение имитационной модели по методу Монте-Карло было выбрано в качестве основного инструмента количественного анализа проектного риска. Первое, что было сделано в рамках разработки предлагаемой методологии управления проектными рисками - автор работы попытался уйти от «неуверенной» оценки временных затрат на выполнение задач проекта. То есть превратить длительность выполнения каждой проектной задачи из интервальной величины в точечную. Так, в следующем разделе выпускной квалификационной работы, будет предложен подход к оценке трудозатрат исполнителя на выполнение единицы каждой работы по метрикам трудоемкости проекта. Неопределенность в такой модели учитывается так: на втором этапе проведения оценки проекта (после расчета трудозатрат), специалисты отвечают на вопросы рисковой анкеты, которая позволяет рассчитать текущий уровень риска проекта (подробнее данный подход также описывается в следующем разделе) - его верхнюю границу. Нижняя граница вероятности наступления риска стандартно устанавливается на уровне 0%, но по усмотрению руководителей, может быть скорректирована. Тогда имитационная модель строится следующим образом: каждая итерация запуска модели добавляет к начальной оценке трудозатрат по задаче случайную величину риска. Один прогон модели формирует новый показатель затрат по проекту: временных и стоимостных. Определенное количество запусков модели позволяет построить график распределения трудозатрат проекта с учетом вероятности наступления рискового события (см. Рисунок 8). На графике отмечается плановая длительность выполнения проекта: она может 1) совпадать с оценочным значением (полученным при метрической оценке трудозатрат проекта), то есть без учета риска, 2) устанавливаться на уровне среднего показателя распределения или 3) назначаться руководителем проекта. С учетом приемлемого уровня риска корректируется плановая длительность выполнения проекта. Обычно, приемлемым считается риск от 5 до 10%. Разница между плановой датой и скорректированной будет защищаться проектным буфером. В рамках данной методологии закладывается два буфера: 1) временной резерв, 2) стоимостной резерв.

Рисунок 8 Предлагаемая методологии оценки проектных рисков

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

Рисунок 9 Расположение в проекте защитных буферов

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

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

Основными преимуществами предлагаемой методологии можно считать:

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

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

2.4 Описание методики расчета трудозатрат проекта

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

Таблица 3

Структура работ исследуемого проекта