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

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 28.08.2020
Размер файла 2,6 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Доля вакантных позиций и доля позиций, занятых лицами, исполняющими обязанности

Текучка кадров

Риски связанные с увольнением опытных специалистов

Рост скорости обновления штата

Средний коэффициент текучки кадров по каждому департаменту

Условия труда

Риски, связанные с низкой удовлетворенностью труда сотрудниками и последующее падение эффективности труда

Низкая зарплата сотрудников

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

Анализ рынка зарплат в данной отрасли

Средняя оценка опроса сотрудников на тему их удовлетворенности условиям труда

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

Также в рамках анализ литературы был рассмотрен кейс [21] по реализации подхода ERM и создания KRI-системы для компанииMidwestern Utilities, Inc.

Компания MidwesternUtilities, Inc. -- это крупное предприятие, занимающееся переработкой пищевых отходов. Компания располагается в США. Ежегодная выручка достигает 5 млрд. долл. Общая численность работников приблизительно равна 10 000 человек.

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

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

Этот инструмент позволяет определить, на что именно влияет тот или иной риск, из чего в последствии можно выделить измеримый критерий оценки [23].

Рисунок 2. Пример Bowtie Analysis

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

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

Далее был рассмотрен кейс по реализации подхода ERM и создания KRI-системы с использованием методов прогнозирования компании WimbledonInvestments [21]. Wimbledon Investments -- крупная международная финансовая компания. По данным на 2015 год, оборот компании достигает 100 млрд. долл. в год. Несколько лет назад компания перешла на использование методики KRI для управления рисками. В данном кейсе рассказывается об особенностях внедренной методологии.

Также как и в предыдущем примере, анализ рисков с применением KRI сопровождался процессом реализации ERM. В соответствии с ним в WI (Wimbledon Investments) проходит план мероприятий и ежегодной разработке портфелей проектов для инвестирования. Портфелей несколько, каждый из них разматывается отдельно под каждый из сценариев развития событий. Эти сценарии представляются на Комитете по рискам (ExecutiveManagementRiskCommittee) где проводится обсуждение этих сценариев и проводится выбор одного наиболее потенциального. После этого данный сценарий презентует на Совете Директоров. Таким образом, в рамках процесса ERM выделяются следующие этапы:

1. Core Drivers;

2. Identifying Risks to Core Drivers;

3. Assessing the Risks;

4. Responding to the Risks;

5. Monitoring &Communitcating.

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

На этапе мониторинга компании WI было необходимо внедрение KRI именно на этапе мониторинга. Одним из возможных методов формулировки KRI является метод трех С. Он состоит из трех формализованных аспектов:

1. Capacity;
Данный показатель отражает, насколько успешно клиенты компании работают со своим долгами. Если долг возвращается успешно, то это отражается на росте capacity. Для измерение данного аспекта в WI используют специальную метрику Debttoincome. Так, при анализе рисков и разработке мероприятий, прежде всего работа проводится именно с тему инициативами, которые отвечают на вопрос: «Что нужно сделать, чтобы оказать наибольший эффект на рост Debttoincome?».

2. Credit;
Данный аспект оценивает уровень кредитного доверия клиентов. Он также обладает своим KRI, это метрика creditscore. При принятии решений менеджеру руководствуются вопросом, сможет ли та или иная инициатива улучшить уровень кредитного доверия клиентов.

3. Collateral.
Collateral -- это дополнительный, побочный аспект. Он описывает внешние риски, которые на которые компания не имеет возможности повлиять. Одним из таких побочных критериев является кредитная дисциплина клиента и график его выплат. Вполне вероятно, что даже если клиент достаточно платежеспособен на нулевом этапе, могут возникнуть проблемы со своевременностью выплат в дальнейшем. Данная внешняя угрозы может зависеть от целого ряда факторов. Для подобных, сложно прогнозируемых факторов также можно вывести критерии оценки. Например, в данном кейсе компания выбрала в качестве индикатора показатель LTV (LoanToValue) -- отношение суммы кредита к рыночной (или оценочной) стоимости залога.

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

Рисунок 4. Процесс расчета KRI

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

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

Результаты анализа литературы

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

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

Далее были рассмотрены другие возможные подходы к управлению рисками. Прежде всего, стоит отметить, что даже при описании нестандартных методов анализа риска проекта авторы статей выстраивают свои подходы на основе PMBoK. В особенности связано с этапом индентификации рисков проекта и формирования реестра рисков. Однако в рамках литературного обзора удалось выявить несколько новых, уже ставших классическими подходов к анализу рисков. Этометодологияанализарисков «Risk diagnosis and management» (RDM) и «Enterprise risk management» (ERM). Также было определено понятие раннего выявления рисков.

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

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

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

Таблица 3. Ключевые этапы, запланированные для проведения исследования

Этапы разработки системы раннего выявления рисков

Запланированные к использованию методы

Идентификация рисков

Использование открытых источников, анализ практик проектов из других областей, Мозговой штурм, проведение экспертного опроса

Качественный анализ рисков

Группировка рисков, проведение экспертной оценки и определение важности рисков, формирование матрицы вероятностей и воздействия рисков.

Количественный анализ рисков

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

Контроль рисков

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

Глава 2

Введение

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

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

Для достижения поставленной цели планируется провести работу по реализации следующий задач:

1. Определить перечень рисков проекта, способных оказывать воздействие на реализацию проекта;

2. Определить приоритетность выявленных рисков в отношении их воздействия на проект и вероятности их возникновения;

3. Провести численного анализа воздействия идентифицированных рисков на цели проекта;

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

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

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

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

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

Методология проведения исследования

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

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

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

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

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

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

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

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

Анализ полученных результатов

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

Данные риски были классифицированы в соответствии со следующей

иерархической структурой.

Для каждого из выявленных рисков были определены причины и последствия.

??????? 5. ????????????? ????????? ??????

Результаты данного анализа представлены в таблице.

Таблица 4. Неранжированный реестр рисков

Тип риска

Наименование риска

Факторы риска

Последствия риска

1

Технический

Допущение ошибок при формировании технического задания на разработку ПО на этапе инициации проекта

Не выявленные до конца цели проекта и пути их реализации

Возникновение дополнительных работ по ходу проекта

2

Организационный

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

Не выявленные до конца цели проекта и пути их реализации

Возникновение дополнительных работ по ходу проекта

3

Рыночный

Неисполнение обязательств со стороны подрядчиков

Возникновение неопределённых системных ошибок на стороне подрядчика, некомпетентность подрядчика, поломка оборудования, некорректное ТЗ сформированное для подрядчика

Невозможность приступить к запланированным этапам работ увеличение бюджета проекта, увеличение сроков

4

Технический

Необходимость разработки или закупки дополнительного ПО для интеграции с действующими в компании ИТ-системами

Устаревшее корпоративное ПО без возможности интеграции с новыми сервисами

Необходимость в планировании дополнительных этапов работ, увеличение бюджета и сроков

5

Организационный

Увольнение ключевых сотрудников

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

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

6

Финансовый

Валютные риски при заключении договоров с иностранными подрядчиками

Нестабильность курсов валют

Превышение заложенного бюджета, невозможность оплаты запланированных работ

7

Финансовый

Повышение цен на закупку оборудования (ПО)

Нестабильность курсов валют, изменение ценовой политики компании-подрядчика, увеличение себестоимости производства закупаемого оборудования (ПО)

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

8

Технический

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

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

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

9

Рыночный

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

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

Неокупаемость проекта, невозможность достижения плановых показателей выручки и кол-ва пользователей ПО

10

Рыночный

Падение рентабельности отрасли розничной реализации нефтепродуктов

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

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

11

Рыночный

Опережение выхода на рынок конкурентных проектов

Поздний запуск проекта, долгий период разработки, утечка информации

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

12

Организационный

Недостаток сотрудников требуемой квалификации

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

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

13

Технический

Потеря данных из-за технологических сбоев

Ошибки в разработке ИТ-архитектуры, закупка некачественного ПО, ошибка технических специалистов

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

14

Технический

Непонимание правил работы сервиса со стороны персонала на АЗС

Отсутствие программ обучения сотрудников на АЗС, невозможность обеспечить достаточное обучение всех сотрудников сети АЗС

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

15

Технический

Технологическое отставание. По мере реализации проекта использованные технологии стали устаревшими

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

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

16

Технический

Ошибки при подключении АЗС к системе

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

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

17

Организационный

Выгорание сотрудников

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

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

18

Организационный

Утечка конфиденциальной информации (в том числе к конкурентам)

Ошибка технических специалистов, сбой в работе ПО и/или вредоносная атака (вирус)

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

19

Правовой

Ужесточение законодательства, регламентирующего правила обслуживания АЗС

Аварийное состояние действующих АЗС и аварии или происшествия, которые могут на них происходить

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

Далее была сформирована шкала оценки вероятности рисков.

Таблица 5. Шкала оценки вероятности рисков

Low

Medium

High

Upto 10%

10% to 40%

40% orhigher

А также шкала для оценки последствий рисков.

Таблица 6. Шкала оценки уровня воздействия рисков

Low

Medium

High

Schedule*

Upto 8 days

8 to 14 days

14 daysorhigher

Cost*

Upto 200,000 ?

200,000 ? to 400,000 ?

400,000 ? orhigher

Performance*

Upto 500.000 ?

500.000 ? to 1.000.000 ?

1.000.000 ? orhigher

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

Таблица 7. Ранжированный реестр - оценка экспертов

Общая оценка (среднее трех экспертов)

Тип риска

Наименование риска

Вероятность

Влияние на стоимость

Влияние на сроки

Влияние на эффективность

1

Технический

Допущение ошибок при формировании технического задания на разработку ПО на этапе инициации проекта

3

2

2

2

2

Организационный

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

2

2

2

1

3

Рыночный

Неисполнение обязательств со стороны подрядчиков

1

2

3

1

4

Технический

Необходимость разработки или закупки дополнительного ПО для интеграции с действующими в компании ИТ-системами

2

2

2

1

5

Организационный

Увольнение ключевых сотрудников

1

3

2

2

6

Финансовый

Валютные риски при заключении договоров с иностранными подрядчиками

2

3

1

2

7

Финансовый

Повышение цен на закупку оборудования (ПО)

1

3

1

3

8

Технический

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

2

2

2

1

9

Рыночный

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

2

1

3

2

10

Рыночный

Падение рентабельности отрасли розничной реализации нефтепродуктов

1

2

2

3

11

Рыночный

Опережение выхода на рынок конкурентных проектов

2

2

1

2

12

Организационный

Недостаток сотрудников требуемой квалификации

2

1

3

2

13

Технический

Потеря данных из-за технологических сбоев

1

3

3

2

14

Технический

Непонимание правил работы сервиса со стороны персонала на АЗС

2

2

3

2

15

Технический

Технологическое отставание. По мере реализации проекта использованные технологии стали устаревшими

2

2

2

1

16

Технический

Ошибки при подключении АЗС к системе

3

2

2

2

17

Организационный

Выгорание сотрудников

2

2

1

1

18

Организационный

Утечка конфиденциальной информации (в том числе к конкурентам)

1

3

3

3

19

Правовой

Ужесточение законодательства, регламентирующего правила обслуживания АЗС

1

3

1

3

В соответствии с оценками экспертов была составлена матрица вероятности и воздействия

Таблица 8. Матрица вероятностей и воздействия

Low

Medium

High

High

1

16

Medium

2

6

4

9

8

12

11

14

15

17

Low

3

5

7

10

13

18

19

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

Таблица 9. Скоринг рисков - группировка по типу риска

Группа рисков

Результирующий скор (по сумме рисков)

Технический

23

Организационный

20

Рыночный

13

Финансовый

8

Правовой

2

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

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

В соответствии с результатами данной модели уровень соответствия проекта с учетом риска своему базовому расписанию составляет 76%. Длительность проекта составляет 371 день, и при расчете даты старта проекта от даты расчета модели (23 декабря 2019 года), плановая дата его исполнения -- 22 декабря 2020 года. Минимальная дата исполнения проекта -- 06 октября 2020 года. Минимальная дата исполнения проекта -- 10 февраля 2021 года. Отклонение минимального и максимального значений от базовой даты составляет 2 месяца. Для данного проекта это не очень высокий показатель.

Рисунок 6. Распределение предсказаний сроков реализации проекта

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

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

Shedulesensitibityindex

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

Рисунок 7. Диаграмма торнадо - SSI

Crusialityrisk

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

??????? 8. ????????? ??????? - CR

Durationsensitivity

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

Рисунок 9. Диаграмма торнадо - DS

Рекомендации и выводы

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

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

На данном этапе возможно сформировать рекомендации касательно мероприятий по управлению рисками для данного проекта:

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

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

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

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

Глава 3

Введение

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

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

Система контроля рисков строится на четырех основных документах, которые описывают всю необходимую входную информацию:

1. План управления проектом;

2. Реестр рисков проекта;

3. Отчеты об исполнении работ;

4. Запросы на изменения.

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

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

Таблица 10. Индикаторы риска - методология расчета показателей

Тип риска

Наименование риска

Индикатор риска

Единица измерения

Методология расчета показателей

1

Технический

Допущение ошибок при формировании технического задания на разработку ПО на этапе инициации проекта

Число доработок ТЗ после его согласования

Количество

Количество доработок ТЗ за период от его согласования до финальной реализации описанной в нем работы

2

Организационный

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

Число доработок ТЗ после его согласования

Количество

Количество доработок ТЗ после его согласования

3

Рыночный

Неисполнение обязательств со стороны подрядчиков

Отставание от базового расписания

Количество

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

4

Технический

Необходимость разработки или закупки дополнительного ПО для интеграции с действующими в компании ИТ-системами

Превышение сметы проекта

Соотношение, %

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

5

Организационный

Увольнение ключевых сотрудников

Коэффициент текучести кадров

Соотношение, %

Число сотрудников, уволившихся за последние 12 месяцев, к общему числу сотрудников

6

Финансовый

Валютные риски при заключении договоров с иностранными подрядчиками

Изменение уровня цен, связанных с волатильностью валюты

Соотношение, %

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

7

Финансовый

Повышение цен на закупку оборудования (ПО)

Изменение уровня закупочных цен

Соотношение, %


Подобные документы

  • Описание структуры управления компании. Структура программно-аппаратных средств. Анализ технического задания. Расчет обобщенного критерия эффективности информационной системы ведения проектов строительной компании. Выбор языка программирования и СУБД.

    дипломная работа [2,1 M], добавлен 29.06.2013

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

    презентация [3,2 M], добавлен 19.09.2016

  • Методология концептуального проектирования баз данных для АИС "Учет Проектов". Построение концептуальной модели. Диаграмма "сущность-связь". Нотация диаграммы "сущность-связь". Спецификация сущностей. Построение логической модели. Формирование запросов.

    курсовая работа [524,4 K], добавлен 28.11.2008

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

    курсовая работа [1,8 M], добавлен 07.01.2014

  • Оценка финансовой, стратегической ценности и уровня рисков проекта. Классификация проектов: "свой" заказчик, продукт под заказ, тиражируемый продукт, аутсорсинг. Организация процесса разработки программного обеспечения, методологии его проектирования.

    презентация [82,8 K], добавлен 07.12.2013

  • Интерфейс системы онлайн-мониторинга стационарного аппарата. Интерфейс автоматизированного рабочего места мониторинга АПБ Московского метрополитена. Архитектура системы ProView, основные сферы применения. Структура графического интерфейса пользователя.

    курсовая работа [1,8 M], добавлен 21.03.2016

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

    дипломная работа [4,1 M], добавлен 30.09.2016

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

    контрольная работа [77,7 K], добавлен 23.01.2012

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

    дипломная работа [1,9 M], добавлен 12.03.2013

  • Анализ сред разработки для веб-проектов. Система учета работы элементов информационной инфраструктуры. Создание базы данных и каркаса системы на языке HTML и CSS. Технологии использования и демонстрация работы системы. Экономическое обоснование проекта.

    дипломная работа [2,1 M], добавлен 25.06.2014

  • Разработка тематических "онлайн-магазинов". Обоснование выбора информационных технологий. Архитектурное решение проекта. Разработка модели базы данных магазина. Схема базы данных на языке SQL. Интернет-магазины "ebay.com", "onliner.by", "eda.by".

    курсовая работа [1,1 M], добавлен 24.06.2013

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

    курсовая работа [2,8 M], добавлен 09.04.2012

  • Области применения и реализации информационных систем. Анализ использования Web-технологий. Создание физической и логической модели данных. Проектирование информационных систем с Web-доступом. Функции Института Искусств и Информационных Технологий.

    дипломная работа [3,8 M], добавлен 23.09.2013

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

    дипломная работа [1,3 M], добавлен 08.12.2013

  • Применение инновационных интернет-технологий при разработке проекта внедрения системы автоматизации продаж с целью повышения эффективности работы региональных представителей компании на примере ООО "Логистика". Особенности организации сбыта в Интернете.

    дипломная работа [1,6 M], добавлен 31.01.2015

  • Технологии управления доступом в помещение. Организационно-управленческая характеристика ООО "Новые информационные технологии". Анализ системы технического и программного обеспечения. Разработка проекта системы контроля и управления доступом "Кодос".

    дипломная работа [71,6 K], добавлен 16.01.2014

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

    дипломная работа [5,3 M], добавлен 29.06.2012

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

    курсовая работа [391,8 K], добавлен 16.02.2016

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

    дипломная работа [156,0 K], добавлен 20.02.2012

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

    курсовая работа [159,8 K], добавлен 26.01.2010

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.