Инструменты управления проектами системной интеграции

Особенности управления проектами системной интеграции. Методология оценки рисков проектов системной интеграции в практике российских ИТ-компаний. Анализ инструментов и методов управления проектами для нивелирования рисков проектов системной интеграции.

Рубрика Менеджмент и трудовые отношения
Вид дипломная работа
Язык русский
Дата добавления 16.11.2015
Размер файла 888,0 K

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

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

Размещено на http://www.allbest.ru/

Содержание

  • Введение
  • Глава 1. Теоретический аспект управления проектами системной интеграции. Особенности управления проектами системной интеграции
  • 1.1 Теория управления проектами в области информационных систем
  • 1.2 Сущность, организационный уровень проектов системной интеграции. Специфика управления проектами системной интеграции
  • 1.3 Технические аспект проектов системной интеграции
  • Выводы по первой главе
  • Глава 2. Оценка рисков проектов системной интеграции в практике российских ИТ-компаний
  • 2.1 Методология оценки рисков
  • 2.2 Этап анализа рисков проектной деятельности
  • Выводы по второй главе
  • Глава 3.Анализ инструментов и методов управления проектами для нивелирования рисков проектов системной интеграции.
  • 3.1 Методы нивелирования рисков проектов системной интеграции
  • 3.2 Анализ инструментов для нивелирования рисков проектов системной интеграции
  • 3.3 Развитие инструментов для поддержки проектной деятельности
  • Выводы по третьей главе
  • Заключение
  • Библиографический список
  • Приложение 1. Результат проведения идентификации рисков методом Дельфи
  • Приложение 2. Результат оценки рисков экспертной группой
  • Приложение 3. Оценка решений унифицированных коммуникаций как услуги (CaaS) на мировом рынке
  • Приложение 4. Методы и инструменты нивелирования рисков, выявленных на этапе анализа

Введение

Российский рынок информационных технологий переживает непростой период, согласно публикации уточненного прогноза по мировой ИТ-отрасли 9 апреля 2015 года от исследовательской компании Gartner аналитики прогнозируют снижение объемов мирового ИТ-рынка на 1,3%. [30, стр. 3] На российском рынке это связано с трудной экономической ситуацией и девальвацией рубля. Снижение объемов ИТ-рынка также связано с падением продаж оборудования в России, Западной Европе и Японии. Однако, в рамках текущий ситуации происходит рост интереса российских компаний к ИТ-услугам.

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

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

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

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

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

Теория управления комплексными проектами проработана такими зарубежными авторами как Дункан В.Р, Верзух Э., Клиффорд Ф. Грей, Эрик У. Ларсон, Тернер Дж.Родни, Ньютон Р.

Среди научных трудов, затрагивающих управление проектами среди российских ученых можно выделить: Разу М.Л., Мазур И.И, Рогова Е.М, Алешин А.В., Аньшин В.М., Ковалев А.

Основополагающими стандартами по управлению проектами в мире являются руководство к своду знаний по управлению проектами - PMBOK, руководство к качеству при управлении проектами - ISO 10006-97, система знаний о процессах управления проектами- PRINCE 2.

Также необходимо выделить ряд основных стандартов, определяющих требования к компетенции руководителей проектов: международные требования к компетенции специалистов по управлению проектами (PM ICB), разработанных Международной ассоциацией управления проектами IPMA (Швейцария), а также основанный на них российский стандарт - Национальные требования к компетентности СОВНЕТ (Россия).

В рамках прохождения преддипломной практики был собран и проанализирован материал по проектам системной интеграции для типовых проектов системной интеграции в компании интеграторе ЗАО «СофтЛайн Трейд».

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

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

Задачами исследования являются:

1. Проанализировать проект системной интеграции и его характерные черты;

2. Выявить текущие риски проектов системной интеграции в рамках работы российской компании - интегратора (ЗАО «СофтЛайн Трейд») на основе экспертной оценки;

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

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

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

Глава 1. Теоретический аспект управления проектами системной интеграции. Особенности управления проектами системной интеграции

1.1 Теория управления проектами в области информационных систем

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

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

Исследовательская организация Standish Group выделяет 10 факторов, которые препятствуют своевременному завершению проекта по созданию и развитию информационных систем. Среди этих факторов можно указать три самых значимых и распространенных [19]:

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

· Неполные требования и незаконченная спецификация требований;

· Изменения в требованиях и в спецификации требований;

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

Свод знаний по управлению проектами PMBoK (Project Management Body of Knowledge) являющийся суммарным справочным материалом по группам процессов управления дает такое определение термину проект: «Проект» - временное предприятие, имеющее своей целью создание некоторого уникального продукта, услуги или достижение конкретного результата [1, стр. 97-102]. Если дать более развернутую формулировку, то «проект» представляет собой набор скоординированных и поэтапных действий, которые ограничены по времени, они имеют фиксированное начало и конец, требования к качеству и срокам, итогом выполнения которых будет уникальный результат.

Ключевые характеристики проекта:

· Время (у проекта всегда можно выделить начало и конец);

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

· Поэтапность (последовательность этапов проекта с промежуточными результатами);

В зависимости от характера деятельности можно выделить несколько типов проектов в ИТ-сфере:

· Разработка программного продукта;

· Внедрение программного продукта;

· Сопровождение/поддержка программных продуктов;

· Проекты, направленные на изменение/совершенствование ИТ-инфраструктуры;

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

· Инициация;

· Планирование;

· Реализация;

· Закрытие;

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

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

Рисунок 1. Структура уровней комплексного проекта

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

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

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

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

Стадии проекта системной интеграции укрупненно можно разделить на:

1. Анализ;

2. Разработка (Выбор решения);

3. Внедрение;

4. Сопровождение;

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

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

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

Типовой пример системной интеграции - это построение единой корпоративной информационной системы (КИС).

Подсистемами при этом являются:

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

· Информационные системы, которые используются в компании: ERP, CRM, СЭД, BPM и прочие. Целью построения единой КИС является интеграция этих информационных систем там, где это возможно. Например, можно обеспечить сокращение трудозатрат оператора Call-центра, построив интеграцию телекоммуникационного оборудования Call-центра и CRM.

· Системы управления технологическими процессами (SCADA).

· Прочие ИТ-компоненты.

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

Компания - системный интегратор в ИТ - это компания-подрядчик (по сути Value Added Reseller), которая извлекает прибыль из добавленной стоимости компании-заказчика. Добавленная стоимость получается за счёт интеграции продуктов и снижения издержек. Системный интегратор по специфике своей деятельности также оказывает консультационные услуги, услуги по настройке ПО и оборудования.

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

В качестве площадки для исследования мною была выбрана компания ЗАО «СофтЛайн Трейд» (торговая марка - Softline), которая является одним из крупнейших игроков на рынке системных интеграторов России.

Подразделение Softline Solutions внедряет решения для комплексной автоматизации бизнес-процессов и эффективного управления бизнесом (ERP - системы от SAP и Oracle) и решения по управлению отношениями с клиентами (CRM - системы), а также разрабатывает дополнительные отраслевые модули для CRM-систем, расширяющие их возможности. Основное направление - это комплексные проекты системной интеграции [24].

Подразделение Softline Consulting Services занимается построением полнофункциональной информационной структуры предприятий, внедряет технологии управления корпоративной информацией, бизнес-анализа и корпоративных коммуникаций с учетом индивидуальных потребностей заказчика. Компания ЗАО «СофтЛайн Трейд» осуществляет как отдельно проекты по оказанию консалтинговых услуг, так и как часть большого интеграционного проекта.

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

Далее представлены характерные особенности комплексных проектов системной интеграции ЗАО «СофтЛайн Трейд».

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

При построении проектной команды необходимо учитывать следующие характерные черты компании и проекта:

· Специалисты могут быть из разных городов/регионов/ стран;

· Компания-заказчик может быть из другого города/региона/страны;

· Разница во времени в зависимости от часовых поясов участников команды проекта и команды компании-заказчика;

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

· Специалисты параллельно ведут более одного проекта;

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

Организационные аспект управления и ведения проекта в компании:

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

· В компании применяется стандарт управления проектами PMBOKv5.

· Руководители проектов сертифицированы по стандарту PMBOKv5.

Техническая организация управления и ведения проекта в компании:

· Для управления проектами с компании используется платформа MS Project;

· Для постановки задач и оперативного взаимодействия также используется ПО, разработанное компанией, - Work Flow Soft.

· Специалисты используют современные средства для корпоративной коммуникации: MS Lync, Skype;

· Для обмена данными по проекту используется внутреннее хранилище, организованное при помощи портала Sharepoint, либо сторонние, например, Яндекс Диск, в случае если в команде проекта участвует субподрядчики из других компаний;

· Основным каналом взаимодействия является - корпоративная почта на базе MS Exchange;

Для более детального описания проекта системной интеграции рассмотрим заинтересованные стороны проекта (теория Э.Фримана) - рис.2.

Рисунок 2. Заинтересованные стороны проекта

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

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

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

Матрица стейкхолдеров проекта системной интеграции представлена на рис.3.

Рисунок 3. Матрица стейкхолдеров проекта

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

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

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

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

Далее рассмотрим внутренние и внешние факторы окружения проекта системной интеграции. К внутренним факторам окружения относятся:

· Организационная структура компании;

· Стиль руководства;

· Организация управления проектами;

· Компетенции участников проектной команды;

· Организационная коммуникация проектной команды;

· Доступность участников проектной команды;

· Заинтересованность участников проектной команды;

· К внешним факторам окружения относятся:

· Политический фактор;

· Экономический фактор;

· Лицензионная политика компаний-вендоров;

· Инфраструктура;

· Компании-партнеры / субподрядчики;

Выделяют следующие проблемные области в проектах системной интеграции [27]:

· Autonomy (автономность);

o Автономность систем;

· Heterogeneity (гетерогенность);

o Технический уровень: различные платформы аппаратного обеспечения, различные операционные системы, различные СУБД; использование различных языков программирования;

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

· Distribution (распределенность);

o Распределенность по серверам;

o Распределенность по приложениям;

o Распределенность по различным компаниям;

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

Рисунок 4. Проблемные области системной интеграции.

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

· Имеет разработанную методику ведения подобных проектов;

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

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

1.3 Технические аспект проектов системной интеграции

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

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

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

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

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

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

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

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

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

Подход 2: Интеграция «многие к одному». Данный интеграционный проект позволяет создать информационный для многих систем к одной условно центральной.

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

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

Объекты и методы интеграции систем.

Информационную систему можно рассмотреть с точки зрения её компонентов:

· Платформа системы: железо и системное ПО, то на чем функционируют остальные компоненты ИС;

· Данные: СУБД и базы данных;

· Приложения, которые реализуют бизнес-логику системы, они состоят из пользовательского интерфейса фреймворк, сервера приложений;

· Бизнес-процессы, в рамках которых используется ИС;

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

Интеграция платформ.

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

Для построения таких интеграций существует несколько решений:

· Виртуализация;

· Удаленный вызов процедур (RPC, CORBA, DCOM, Web-сервисы);

· ПО промежуточного слоя (Microsoft.Net, Java Runtime);

Интеграция данных.

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

· Универсальный доступ к данным (SQL-запросы, ODBC, JDBC);

· Хранилища данных (OLAP, OLTP, концепция ETL);

Интеграция приложений.

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

· Интерфейсы прикладного программирования (например, Windows API);

· Обмен сообщениями (Корпоративная шина сервисов);

· Сервис-ориентированная архитектура (публикация функционала корпоративных приложений в виде Web-сервисов);

· Интеграция пользовательских интерфейсов;

Интеграция бизнес-процессов.

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

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

· Операции взаимодействия с ИС должны быть детально описаны в терминах информационного обмена данными: формат, сервисы, приложения, события, политики безопасности, права доступа;

· ПО, в котором заложен сценарий взаимодействия подключаются посредством адаптеров интегрируемые ИС, участвующие в бизнес-процессе;

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

Можно выделить следующие классы продуктов для интеграции ИС:

· Реализующие идеологию SOA (IFS Applications, Flextera, IBM WebSphere);

· Реализующие идеологию Messaging (промежуточное ПО);

· Корпоративные шины сервисов;

· Средства интеграции на уровне бизнес-процессов (BPEL, Business Process Execution Language);

· Средства интеграции данных;

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

· Длительный срок проекта (в среднем 1-2,5 года);

· Мультивендорность;

· Изменение производятся от уровня инфраструктуры до уровня бизнес- процессов;

· Конечная потребительская ценность;

· Направленность на повышение эффективности бизнеса (включая консалтинг, бизнес-приложения и ИТ-инфраструктуру);

· Специфический порядок реализации (охватывает этапы от построения бизнес-процессов до инфраструктуры);

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

· Необходимость построения объединенных коммуникаций между участниками проекта;

· Сложность обеспечения доступности экспертов на протяжении всего проекта;

· Распределенность команды проекта;

Выводы по первой главе

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

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

Глава 2. Оценка рисков проектов системной интеграции в практике российских ИТ-компаний

2.1 Методология оценки рисков

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

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

Таблица 1. Методы управления рисками в различных проектах

Масштаб проекта

Число работ

Число подпроектов

Связность работ

Методы управления

Малый

До 50

Нет

Низкая

PMI 1 FMEA MSF, личный опыт руководителя

Средний

50-100

Единицы

Низкая, средняя

Стандартные методики (ASAP 2 PJM 3 PMI), SPICE4 COBIT

Крупный

100-1000

От нескольких десятков до нескольких сотен

Высокая

Проработаны слабо

Этапы управления рисками, согласно национальному стандарту Российской федерации ГОСТ Р ИСО/МЭК 31010-2011 [2] представлены на рис. 5.

Рисунок 5. Процесс управления рисками

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

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

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

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

· о необходимости проводить действия по нивелированию рисков;

· о способах максимально эффективного нивелирования рисков;

· об обработки риска;

· о приоритетности действий по обработке риска;

В рамках данной работы будут рассмотрены следующие этапы:

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

· Анализ рисков;

· Сравнительная оценка рисков;

Этап идентификации рисков управления проектной деятельностью.

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

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

Примеры методов к оценке рисков [1,2]:

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

· Подход, в соответствие с которым группа экспертов следует установленному процессу идентификации риска посредством структурированного множества подсказок или вопросов;

· Индуктивные методы, например, HAZOP.

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

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

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

Этапы проведения опроса методом Дельфи:

1) Сформировать группу проведения и мониторинга процесса;

2) Собрать группу экспертов (возможно формирование нескольких групп);

3) Разработать первоначальные опросные листы;

4) Тестировать опросные листы;

5) Отправить/передать опросные листы индивидуально каждому участнику-эксперту;

6) Проанализировать и обобщить ответы экспертов и распространить результаты среди участников дискуссии;

7) Провести повторный опрос участников дискуссии до тех пор, пока не будет достигнуто согласие по обсуждаемой тематике.

Результат проведения опроса по методу Дельфи для выявления рисков проекта, представлен в Приложении 1

2.2 Этап анализа рисков проектной деятельности

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

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

Различные методы анализа риска описаны в табл. 2.

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

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

К методам качественной оценки относятся, прежде всего, экспертные методы. Упрощённый алгоритм технологии экспертного оценивания рисков представлен на рис. 6.

Рисунок 6. Алгоритм технологии экспертного оценивания рисков

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

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

Для анализа рисков был выбран смешанный метод - «матрица последствий и вероятностей» из списка методов, рекомендованных национальным стандартом Российской федерации ГОСТ Р ИСО/МЭК 31010-2011 [2] и описанный также в своде знаний по управлению проектами PMBOK v5 [1] (табл. 2).

Таблица 2.Характеристики методов оценки риска

Наименование метода

Процесс оценки риска

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

Анализ риска

Сравнительная оценка риска

Последствие

Вероятностные характеристики

Уровень риска

Мозговой штурм

SA1)

NA2)

NA

NA

NA

Структурированные или частично структурированные интервью

SA

NA

NA

NA

NA

Метод Дельфи

SA

NA

NA

NA

NA

Контрольные листы

SA

NA

NA

NA

NA

Предварительный анализ опасностей (PHA)

SA

NA

NA

NA

NA

Исследование опасности и работоспособности (HAZOP)

SA

SA

A3)

A

A

Анализ опасности и критических контрольных точек (HACCP)

SA

SA

NA

NA

SA

Оценка токсикологического риска

SA

SA

SA

SA

SA

Структурированный анализ сценариев методом «что, если?» (SWIFT)

SA

SA

SA

SA

SA

Анализ сценариев

SA

SA

A

A

A

Анализ воздействия на бизнес (BIA)

A

SA

A

A

A

Анализ первопричины (RCA)

NA

SA

SA

SA

SA

Анализ видов и последствий отказов (FMEA)

SA

SA

SA

SA

SA

Анализ дерева неисправностей (FTA)

A

NA

SA

A

A

Анализ дерева событий (ETA)

A

SA

A

A

NA

Анализ причин и последствий

A

SA

SA

A

A

Причинно-следственный анализ

SA

SA

NA

NA

NA

Анализ уровней защиты (LOPA)

A

SA

A

A

NA

Анализ дерева решений

NA

SA

SA

A

A

Анализ влияния человеческого фактора (HRA)

SA

SA

SA

SA

A

Анализ «галстук-бабочка»

NA

A

SA

SA

A

Техническое обслуживание, направленное на обеспечение надежности

SA

SA

SA

SA

SA

Анализ скрытых дефектов (SA)

A

NA

NA

NA

NA

Марковский анализ

A

SA

NA

NA

NA

Моделирование методом Монте-Карло

NA

NA

NA

NA

SA

Байесовский анализ и сети Байеса

NA

SA

NA

NA

SA

Кривые FN

A

SA

SA

A

SA

Индексы риска

A

SA

SA

A

SA

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

SA

SA

SA

SA

A

Анализ эффективности затрат (CBA)

A

SA

A

A

A

Мультикретириальный анализ решений (MCDA)

A

SA

A

SA

A

1)SA - строго применим; 2)NA - не применим; 3)A - применим

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

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

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

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

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

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

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

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

· Менеджеры проектов, имеющие опыт реализации проектов системной интеграции от 3х лет;

· Работающие в компании численностью от 1000 человек;

· Работающие с территориально распределенными командами;

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

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

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

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

Для оценки риска необходимо вычислить класс вероятности риска (P) и уровень последствия (I).

Перечень критериев последствий и класс вероятности строится на основе рекомендаций cвода знаний по управлению проектами PMBOK v5. Перечень критериев последствий указан в табл. 3. Классы вероятности риска приведены в табл. 5.

Таблица 3. Таблица критериев последствий

СТОИМОСТЬ

СРОКИ

СОДЕРЖАНИЕ

КАЧЕСТВО

«1» - очень низкий

Незначительное

увеличение стоимости (не более 10% от маржи проекта)

Незначительное

увеличение сроков (не более % от планового срока)

Сокращение

содержания

едва заметно

Ухудшение качества

едва заметно

Анкета зеленая.

«2» - низкий

Увеличение

стоимости (более 10 % от маржи проекта)

Увеличение

сроков (более5 % от планового срока)

Воздействию

подвержены

незначительные

области содержания

Воздействию

подвержены только самые не требовательные области

Анкета зелёная.

«3» - средний

Увеличение стоимости (на 10-20 %)

Увеличение сроков

(на 5-10 %)

Воздействию

подвержены

значительные области содержания (до 50%)

Снижение качества значительно, но приемлемо Заказчиков.

Анкета желтая.

«4» - высокий

Увеличение стоимости (на 20-40 %)

Увеличение сроков

(на 10-20 %)

Изменение содержания

неприемлемо для одной из сторон (более 50%)

Снижение качества

неприемлемо

для спонсора

Анкета красная.

«5» - очень высокий

Увеличение

стоимости (более 40 %)

Увеличение

сроков (более 20 %)

Содержание работ не управляемо

Конечный

результат проекта

практически

бесполезен

Анкета красная.

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

За оценку последствий будем принимать наибольшую оценку по всем критерием данного риску. Например, для оценки Риска X (табл. 4).

Таблица 4. Пример оценки риска по критериям последствий.

Описание Риска

СТОИМОСТЬ

СРОКИ

СОДЕРЖАНИЕ

КАЧЕСТВО

Риск X

3

3

2

1

Итоговая оценка последствия Риска X будет равна max(3;3;2;1) = 3.

Далее рассмотрим классы возможные классы вероятности риска (p), табл. 5.

Таблица 5. Реализуемость риска

КЛАСС

РЕЙТИНГ

КРИТЕРИЙ

E

Вероятно

· Риск реализуется;

· Скорее всего произойдёт несколько раз течении одного проекта;

D

Возможно

· Вероятность наступления высока;

· Риск, скорее всего, проявится;

C

Маловероятно

· Происходит в подобных проектах, но не часто;

· Вероятность проявления и не проявления риска примерно равна;

B

Редко

· Может произойти случайно;

A

Невероятно

· Риск, скорее всего, не проявится;

В приложении 1 представлена анкета для оценки рисков в разрезе этапов жизненного цикла проекта по критериям последствий и классам вероятности рисков.

На основе сопоставления определенных выше критериев последствий и класса вероятности риска оценивается уровень риска. Уровни риска, установленные для ячеек таблицы, зависят от определений, применяемых для шкал вероятности и последствий. Матрица построена с преимущественным влиянием последствий. Матрица определения уровня риска приведена в табл. 6. Описание значений уровня риска, необходимых действий и методов управления риском представлены в табл.7.

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

· Отказ от чрезмерно рисковой деятельности (метод отказа от риска),

· Профилактика или диверсификация (метод снижения риска),

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

· Согласие с рисков и формирование резервов (запасов) ресурсов (метод принятия риска).

Таблица 6. Матрица уровней риска

Класс вероятности

5 Вероятно

III

II

II

I

I

4 Возможно

III

III

II

II

I

3 Маловероятно

IV

III

III

II

II

2 Редко

IV

IV

III

III

II

1 Невероятно

IV

IV

IV

III

III

1

2

3

4

5

Класс последствий

Таблица 7. Описание уровней риска

Уровень риска

Необходимые действия

Методы управления

Критичный

Отказ от риска или рассмотрение методов снижения риска

Высокий


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

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

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

  • Понятие и структура корпоративной системы управления проектами. Основные методы диагностики уровня зрелости управления проектами. Инициация и планирование, финансирование проектов. Управление программами, рисками, коммуникациями и портфелем предприятия.

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

  • Понятие, состав и виды проектов. Этапы управления проектами на предприятии. Организационно-экономическая характеристика ТОО "Казцинктех". Анализ экономических показателей работы предприятия. Основные проблемы в управления проектами и пути их решения.

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

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

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

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

    реферат [484,6 K], добавлен 29.09.2012

  • Характеристика этапов развития управления проектами в России. Понятие, роль и актуальность проектного управления. Основные формы планирования и контроля текущей деятельности фирмы. Особенности управления проектами в фирмах-партнерах "1С:Франчайзи".

    курсовая работа [1021,2 K], добавлен 23.10.2015

  • Стратегическое значение современных методов и средств управления проектами. Характеристика основных методов управления проектами. Фазы жизненного цикла проекта. Фаза разработки коммерческого предложения. Формальное и детальное планирование проекта.

    контрольная работа [30,3 K], добавлен 04.02.2010

  • Структура базы данных системы управления проектами (БД СУП). Пользовательский интерфейс (представление информации о проекте, панели инструментов). Настройка интерфейса (таблиц, форм). Состав компонентов, назначение шаблонов проектов Micrisoft Progect.

    контрольная работа [46,6 K], добавлен 27.05.2008

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

    магистерская работа [1,8 M], добавлен 30.01.2014

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

    реферат [18,7 K], добавлен 04.11.2015

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

    курсовая работа [692,2 K], добавлен 27.05.2014

  • Информационные системы управления проектами. Классификация и краткий обзор программного обеспечения управления проектами. Внедрение специализированного программного обеспечения при проведении автоматизации управления Фитнес-клубом с выкупом территории.

    курсовая работа [966,1 K], добавлен 01.12.2013

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

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

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

    научная работа [949,2 K], добавлен 05.10.2010

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

    лекция [1,1 M], добавлен 31.10.2013

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

    курсовая работа [151,2 K], добавлен 14.01.2014

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

    шпаргалка [1,2 M], добавлен 03.05.2012

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

    практическая работа [341,1 K], добавлен 07.04.2015

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

    курсовая работа [28,6 K], добавлен 26.01.2009

  • Проект и его характеристика. Управление проектом как одна из самых сложных и трудоемких задач управленческой деятельности. Виды организационных структур управления проектами. Анализ организационной структуры управления проектами в ООО "Ай-Ти Сервис".

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

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