Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
УП (18-23) +2 доп. вопроса.doc
Скачиваний:
21
Добавлен:
21.11.2018
Размер:
182.78 Кб
Скачать

23.Методы анализа риска и неопределенности в управлении проектами

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

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

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

К качественным методам риска следует отнести экспертный анализ рисков

Процедура экспертной оценки риска предусматривает:

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

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

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

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

Недостаток: имеет определенную субъективность и не всегда позволяет дать независимую характеристику анализируемого события

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

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

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

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

Метод моделирования позволяет:

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

2) анализировать последствия накопления рисковых ситуаций;

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

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

Доп. Вопрос

Система управління проектами Trac

Trac — это система управления проектами разработки программного обеспечения, вкючающая в себя возможность отслеживания ошибок и просмотра репозитариев систем контроля версий (subversion «из коробки», mercurial, git, bazaar через плагины). Реализована средствами языка Python и распространяется в открытых исходных кодах.

Trac предоставляет такие функции, как:

  • разделение проекта на этапы (milestones)

  • план работ (roadmap) история изменений (timeline)

  • управление пользователями

  • учет задач на разработку (tickets) wiki

Tickets Стандартная функциональность - учет ошибок, замечаний, пожеланий с возможностью фильтрации и занесение соответсвенно в milestone, roadmap.

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

Управление пользователями Простая система - что могут делать пользователи, а что нет.

WiKi В trac встроена система WiKi с возможностью делать ссылки на milestone, roadmap, ticket. Органично вписывается и удобна в использовании при ведении проекта.

Оффшоринг в управлінні проектами.

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

Оффшоринг - перемещение компанией части производственного процесса или процесса оказания услуг за пределы страны

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

Onsite Subcontracting with Offshoring. (Субподрядный оффшоринг). Возможно, это наиболее простой тип аутсорсинга, когда фирма размещает своих квалифицированных сотрудников непосредственно рядом с клиентом. Эти люди становятся фактически частью команды заказчика. Эта модель также называется «прирост персонала». Большинство иностранных аутсорсинговых фирм прослеживают свою историю от оказания услуг по программному обеспечению и продолжают предлагать поддержку проекта. Эта модель аутсорсинга наиболее приспособлена к маленьким фирмам, имеющим отношения с заказчиком и условия нанимать и укомплектовывать штат персонала;

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

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

Global Delivery Onsite/Offshore Model. Это классический оффшоринг, осуществляемый большинством предприятий, где они берутся за проекты клиента, создают небольшую команду на месте, которая работает с менеджерами и командой заказчика и координирует работу с оффшорной командой, которая выполняет основную часть работы. Это наиболее зрелая ступень «оффшоринга индивидуальных проектов»;

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]