Инструменты управления проектами системной интеграции
Особенности управления проектами системной интеграции. Методология оценки рисков проектов системной интеграции в практике российских ИТ-компаний. Анализ инструментов и методов управления проектами для нивелирования рисков проектов системной интеграции.
| Рубрика | Менеджмент и трудовые отношения |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 16.11.2015 |
| Размер файла | 888,0 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
II
Требования
Ошибка в планировании объема работ и трудозатратах Исполнителей, т.к. не проводятся первичный анализ и оценка сложности проекта сотрудниками, которые станут непосредственными исполнителями по проекту
II
Процессные
Этап 3. Исполнение проекта
Риски, связанные с территориальной распределенностью проектной команды
Сложности в коммуникации в реальном времени между участниками проекта
II
Коммуникативные
Увеличение расходов на командировки Исполнителей
II
Коммуникативные
Риски, связанные с участием в проектной команде представителей нескольких компаний/региональных хабов компании
Конфликт интересов между проектами, в которых Заняты Исполнители
II
Политические
Смена участников проектной команды Исполнителя до завершения проекта
II
Процессные
Отказ от выполнения работ субподрядчиком (субподрядчик не заинтересован в результате проекта)
II
Процессные
Отсутствие единой точки коммуникации всех участников проекта как со стороны Исполнителя, так и Заказчика (ВКС, переговоры, демонстрации)
II
Коммуникативные
Невозможность ведения совместной работы участников проектной команды Исполнителя над разработкой документов (проектные, сопроводительные).
II
Коммуникативные
Невозможность удаленного подключения из-за политик безопасности участников проекта (со стороны Исполнителя и Заказчика)
II
Коммуникативные
В договоре и техническом задании нет четкого описания границ проекта
II
Требования
Завышенные ожидания по проекту и Заказчика
II
Требования
Сложный и продолжительный этап согласования на стороне Заказчика
II
Требования
Изменение требований со стороны Заказчика
I
Требования
Этап 4. Закрытие проекта
Процедура закрытия проекта слабо формализована в Договоре
II
Требования
Выводы по второй главе
Специфика проектов системной интеграции влияет на риски проектов. Методы управления рисками для малых и средних проектов достаточно проработаны и описаны, что позволяет эффективно уменьшать уровень рисков и управлять трудозатратами по проекту, а для ведения крупного технологичного проекта системной интеграции необходимо выявить и описать типовые риски таких проектов. Для решения этой задачи в исследовании был проведен опрос экспертной группы на базе компании ЗАО «Софт Трейд» с использованием метода Дельфи для идентификации и сбора рисков типовых проектов системной интеграции. Для анализа рисков был выбран смешанный метод - «матрица последствий и вероятностей» из списка методов, рекомендованных национальным стандартом Российской федерации ГОСТ Р ИСО/МЭК 31010-2011. В результате проведения этапа идентификации был сформирован перечень рисков, характерных для проектов системной-интеграции в компании. На этапе оценки удалось получить тепловую карту рисков с распределением рисков по уровням в зависимости от их последствий и вероятности возникновения.
Исходя из анализа рисков экспертной группой можно сделать вывод, что основные риски критичного и высокого уровня - это риски, связанные с управлением требованиями, изменениями и коммуникациями участников проекта.
Глава 3. Анализ инструментов и методов управления проектами для нивелирования рисков проектов системной интеграции
3.1 Методы нивелирования рисков проектов системной интеграции
Согласно результатам, большинство выявленных рисков проекта связаны с коммуникациями участников команды проекта и управлением требованиями на всех этапах жизненного цикла проекта.
Нивелирование коммуникативных рисков на методологическом уровне возможно с помощью согласование и ведения документов проекта [8]:
· Коммуникационный план проекта, где описываются каналы передачи информации, их периодичность и получение обратной связи между участниками команды проекта. Устав проекта, где описываются принципы ведения проекта, используемое ПО.
· Реестр заинтересованных сторон проекта, где описывается окружение проекта и лист стейкхолдеров проекта;
Большая роль в нивелировании коммуникационных рисков лежит на используемых инструментах коммуникации.
Как отмечают эксперты в области управления проектами, качество продукта существенно связано с умением команды работать с требованиями. Так же, как и оценка качества работы команды в значительной степени зависит от нетехнических навыков, а желания и умения понимать проблемы и потребности Заказчика, и затем транслировать эти знания в продукт [10].
Для анализа требований в рамках проектной деятельности для компании ЗАО «СофтЛайн Трейд» разработана модель управления требованиями и описан процесс управления требованиями.
Стандартно модель управления требованиями проектами состоит из трех этапов. На первом этапе происходит сбор бизнес-требований, которые затем фиксируются в документе «Реестр требований» и в проектном решении, на основе этих требований определяются рамки проекта. Решение о принятии или отклонении бизнес-требования необходимо принимать для каждого требования отдельно, принятого на этапе проектирования проекта системной интеграции. Бизнес требование необходимо оценить по следующим признакам:
· Выполнимость в рамках функциональности проектируемого решения;
· Гарантии и критерии успешного выполнения;
· Критичность в бизнес-процессе компании-Заказчика;
· Соответствие стандартам организации;
Также проставляется взаимосвязь требований и выстраивается иерархия требований.
Следующий уровень -это сбор и обработка требований пользователя. При обработке требования пользователя происходит их приоритезация на основе следующих признаков:
· Влияние автора требования,
· Актуальность;
· Критичность для работы системы;
· Риск порождения дальнейших ошибок;
Бизнес-требования связаны с требованиями пользователей, кроме того они связаны между собой, поэтому на втором этапе необходимо выстроить требования с использованием метода аналитических сетей.
Управлением бизнес-требованиями и требованиями пользователь занимается Бизнес-аналитик. Его задача максимально точно определить изначальные потребности Заказчика и ранжировать их. Он определяет, что пользователь хочет достичь, используя систему и насколько внедряемая решение может удовлетворить эти потребности.
На основе первого и второго уровня формируются требования к внедряемой системе.
Одно требование пользователя может быть решено с помощью одного или нескольких системных требований. Далее происходит ранжирование системных требований. При ранжировании системных требований учитывается вес пользовательского требования на основе которого было сформулировано это требований.
· Для определения приоритетов системных требований необходимо учесть признаки:
· Влияние на затраты ресурсов при реализации;
· Влияние на смежные функциональные блоки;
· Риск возникновения ошибок;
· Влияние на сроки;
На основе анализа системных требований формируются системные спецификации (архитектура решения), на этом этапе определяется как конкретная архитектура системы будет удовлетворять системным требованиям, выявленным ранее. Этим этапом управляет Архитектор проекта.
Модель управления требованиями для принятия решений строится от бизнес-требований с дальнейшей детализацией на следующие уровни. Поскольку при построении модели требований учитываются относительные веса требований более высоких иерархий, мы получаем приоритизированные системные требования на основе которых строится архитектура решения и план работ проекта.
Построение сложных логических связей между требованиями, а также использование различных признаков для их приоритизации требует использование специализированного ПО для составления моделей требований
[13, стр. 67-70].
Список ПО для составления моделей требований проекта:
· SuperDecisions;
· IBM Rational RequisitePro
· Telelogic DOORS
· Sybase PowerDesigner
· Borland Caliber RM
· Sybase PowerDesigner
· OpenSource Requirements Management Tool
· RequirementsWin
Укрупненно процесс управления требованиями представлен на рис.7.
Рисунок 7. Процесс управления требованиями, внедряемый в компании ЗАО «СофтЛайн Трейд»
Ещё одним аспектом управления требованиями является управление изменениями требований.
Как указано в анализе риск «Изменение требований со стороны Заказчика» имеет критичный уровень, т.е. он наиболее часто свершается в рамках реализации проектов, а также имеет серьезные последствия для стоимости, сроков, содержания и качества проекта.
Для управления изменениями в компании ЗАО «СофтЛайн Трейд» была предложена для внедрения модель управления изменениями.
Управление изменениями представляет собой совокупность процессов, включающих идентификацию, фиксацию, оценку, принятие решения, управление реализацией изменения, контроль [26].
Процесс управления изменениями функционируют на всем этапе проекта от инициации до закрытия проекта. Для проектной деятельности компании ЗАО «СофтЛайн Трейд» процесс управления изменениями в проекте осуществляется с момента подписания договора, до сдачи-приемки результатов работ и подписания акта.
Все изменения, которые влияют на итоговый продукт проекта, должны быть обязательно согласованы ЛПР в компании-заказчике. Для этого в текст Договора вносится статья, описывающая процедуру рассмотрения и утверждение изменений, а также сроки выполнения этой процедуры каждой из сторон.
Классификация изменений:
· Внешние (инициированы Заказчиком);
· Внутренние (инициированы Исполнителем).
· В свою очередь изменения делятся на типы
· Технические (связаны с реализацией проекта);
· Организационные (например, изменение состава команды);
· Контрактные (состав работ, сроки, стоимость).
Инициаторами изменений могут являться:
· Представители компании-заказчика (в том числе, ЛПР);
· Любой участник команды проекта из команды Исполнителя;
· Третья сторона (субподрядчик, фриланс, консультант по проектированию);
· Конечный пользователь, если конечный пользователь не в компании-заказчика.
Процесс управления изменениями представлен на рис.8.
Рисунок 8. Процесс управления изменениями
Этапы процесса:
1) Подача запроса на изменение.
Каждый запрос на изменение должен быть документирован, указаны все обновленные требования, которые будут производится в рамках этого изменения. На основе описанных требований осуществляется оценка возможности проведения изменения.
Форма запроса на изменение должна быть согласована и прикреплена к Договору или иным правоустанавливающие документам проекта, например, Устав проекта.
2) Оценка последствий.
Оценка степени воздействия предлагаемого изменения на проект производится коллегиально всеми участниками проектной команды. Для принятия решения о внесении изменений проект или их отклонении необходимо, чтобы предлагаемые изменения были правильно поняты, между ними расставлены приоритеты и оценена их стоимость и длительность. По результатам оценки документируются все степени воздействия (включая - сроки проекта, стоимость изменений).
Оценка последствий внесения изменений в проект решает следующие вопросы:
· Вызвано ли изменение недостаточной проработкой требований и неверным отражением модели требований;
· Какая выгода будет получена от внесения изменений участниками сторон;
· Риски, связанные с реализацией, отказом и принятием изменения;
· Влияние изменений на остальные уровни требований;
· На каком этапе жизненного цикла производится изменение;
· Как результат проведения изменения повлияет на сроки, стоимость, состав и качество проекта.
3) Принятие решения.
Решение о необходимости предложенного изменения или отказе от его реализации принимается следующими лицами:
· Руководителем проекта (при изменении сроков и стоимости проекта не более 10% от общей стоимости проекта),
· Куратором и спонсором проекта (при изменении сроков и стоимости более 10%, но не более 20%),
· Советом по управлению изменениями при величине изменений более 20%.
По запросам на изменения могут быть приняты решения:
· Утвердить;
· Отклонить;
· Отправить на доработку (Отложить);
Любое решение фиксируется РП в журнале Контроля изменений и в обязательном порядке доноситься до Заказчика.
4) Реализация изменения.
Если принято решение об утверждении изменения, работа над данными изменениями происходит:
· В рамках проекта;
· Только после подписания обеими сторонами дополнительного соглашения к договору;
В рамках реализации изменения руководитель проекта должен:
· Утвердить новые версии плана работ и всех остальных необходимых документов (Устав проекта, Риски проекта, Карточка проекта, План-график работ, Смета, Рабочие документы проекта);
· Принять решение о привлечении дополнительных ресурсов (внутри компании/ субподряд/фриланс);
o Инициировать запрос на оценку внутренних ресурсов;
o Инициировать заключение договора или дополнительного соглашения с субподрядчиком.
· Выделение дополнительного бюджета (при необходимости);
· Закрепляет новые сроки проекта;
5) Контроль изменения.
Когда изменение будет выполнено, вопрос может быть снят с контроля, следовательно, статус запроса на изменение должен быть изменен в журнале Контроля изменений
Необходимо оповещать участников проекта о произошедших изменениях в проекте для сохранения актуальности работ участников проекта. Это оповещение должно быть запланировано заранее, в плане управления коммуникациями.
Процесс управления требованиями в компании ЗАО «СофтЛайн Трейд» сейчас переживает переход со второго уровня зрелости процесса к третьему т.е. от детального документального оформления и учета к структурированию требований, ведению реестра требований, шаблонов для сбора и идентификации требований для всех проектов компании, ведение типов и атрибутов требований.
На этом этапе большое внимание уделяется обучению проектной команды новым методам работы, работы с новым программным обеспечением для управления требованиями и дополнительными проверкам спецификаций требований на полноту и проверяемость. В итоге требования становятся более качественными, что ведет к сокращению стоимости и сроков разработки.
Компании-интеграторы в России и странах СНГ еще не широко и не повсеместно используют методы проектного управления, что приводит к репетиционным рискам, срывам сроков проекта и судебным искам. Выстроенный процесс управления требованиями на высоком уровне зрелости позволит компании иметь серьезное преимущество на рынке ИТ-интеграторов России и СНГ в ситуации ужесточения конкуренции.
3.2 Анализ инструментов для нивелирования рисков проектов системной интеграции
Как отмечают руководители ИТ-компании, [10] большинство рисков проекта носят коммуникационный характер, и проявляются ещё на начальном этапе, а далее, в процессе проекта, зачастую происходит неверное выстраивание коммуникаций. Проблемы с коммуникациями на начальном этапе приводят к потере управления требованиями и неверным содержанием ограничения в договоре.
Зачастую коммуникационные риски возникают в общении участников команд проекта, особенно в рамках сложных интеграционных проектов. Часть таких коммуникационных рисков можно нивелировать организационно-методическими средствами: проработанный устав проекта, договор с субподрядчиком и т.д.
Часть коммуникационных рисков лежит в техническом оснащении компаний-участников проекта. Для построения современной среды коммуникации проекта рассмотрим требования к решениям со стороны участников проекта.
· Компания - интегратор (крупная распределённая компания):
o Телефония;
o Видео-конференц связь;
o Совместная обработка документов;
o Мобильность;
o Постановка задач;
o Отслеживание статуса участника;
o Безопасность передачи данных;
o Простота подключения нового участника;
o Приемлемая стоимость стоимость;
· Компания-Заказчик (крупная компания):
o Телефония;
o Видео-конференц связь;
o Безопасность передачи данных;
o Простота подключения нового участника;
o Приемлемая стоимость стоимость;
· Субподрядчик (ИП, малый-бизнес);
o Телефония;
o Видео-конференц связь;
o Мобильность;
o Простота подключения нового участника;
o Приемлемая стоимость стоимость;
Для реализации технических требований участников проектной команды возможно рассмотреть 2 сценария:
1. На основе передовых мировых решения корпоративного уровня (оценка Gartner);
2. На основе имеющихся решений компаний-участников и сторонних онлайн-сервисов;
Мировым трендом построения коммуникация является модель коммуникации как сервис (Communication as a Service - CaaS). Мировые CaaS - вендоры предоставляют готовую площадку для коммуникаций и выступают ответственными за управление аппаратным и программным обеспечением пользователей. Вендоры предоставляют гарантированное качество сервиса и обслуживание по SLA в рамках договора. Модель CaaS позволяет пользователям выбирать необходимый функционал решения и оплачивать его согласно тарифам вендора. Модель CaaS разработана на ценовой политике общего назначения, которая предоставляет пользователям сервисный план. Для оценки передовых систем унифицированных коммуникаций в рамках данного исследования был проанализированs отчеты Gartner «Critical Capabilities for Unified Communications as a Service» [29], «Magic Quadrant for Unified Communications as a Service» [28] за 2014 год.
В рамках отчета рассматриваются четыре возможных сценария использования UCaaS в различных типах компаний:
· SMB - возможность применения в компании малого (организации, в которых работают от 20 до 99 сотрудников) и среднего бизнеса (100 - 999 сотрудников);
· Крупные предприятия с небольшими требованиями к УК - возможность применения в крупных предприятиях (начиная от 1000 сотрудников и более), которые не выдвигают значительных требований к решению (помимо телефонии и мобильности) и представлены (работают) в одном регионе;
· Крупные предприятия, которым необходимо полнофункциональное УК-решение - возможность применения в крупных корпорациях (более 1000 сотрудников), работники которой централизованы в одном регионе. Требования охватывают полный спектр функционала, предоставляемого УК-решениями (например: телефония, мобильность, web - конференции, видеоконференцсвязь, обмен мгновенными сообщениями и прочие)
· Комплексные или международные требования к УК-решениям - интернациональные корпорации (более 1000 сотрудников), работники которых распределены по различным географическим регионам. Требования охватывают полный спектр функционала, предоставляемого УК-решениями (например: телефония, мобильность, web - конференции, видеоконференцсвязь, обмен мгновенными сообщениями и прочие).
Большинство предлагаемых UCaaS-решений имеет схожий функционал, поэтом для того, чтобы осуществить сравнительный анализ поставщиков услуг (решений) было идентифицировано несколько наиболее критичных функций:
· Телефония
Возможность предоставления функционала, схожего с функционалом традиционного IP PBX решения (телефонная станция на основе межсетевого протокола IP), например:
o Передача голоса по фиксированным (проводным) и мобильным каналам связи;
o Софтфон (программное обеспечение для ПК, позволяющее совершать телефонные или видео звонки);
o Возможность установления голосовых и видео сессий высоко разрешения посредством пиринговой (peer-to-peer) архитектуры.
Наиболее важные функции включают в себя инструменты, позволяющие осуществлять диагностику VoIP, интеграцию с локальными офисными АТС, возможность подключения филиалов, одновременную поддержку нескольких линий (возможность одновременной поддержки нескольких активных звонков) и возможность интеграции (или создания) с call-центром.
· Мобильность
Возможность использования УК-клиентов в различных мобильных средах, включая: ноутбуки, планшетные компьютеры, смартфоны. Базовая функциональность включает в себя возможность переадресации звонка с VoIP-телефона пользователя на его мобильное устройство (например, телефон). Расширенный вариант позволяет использовать fixed mobile convergence (решение, позволяющее создать единую сеть офисных и мобильных телефонов с общим планом короткой нумерации, создавая возможность созваниваться напрямую по коротким внутренним номерам сотрудникам из офисов в разных городах России, в т.ч. без использования реальной офисной АТС) и видеоконференцсвязь.
· Организация конференц-связи (Аудио/Видео/Веб)
Возможность использования широкого функционала по организации различных (аудио, видео, веб) конференций между широким спектром устройств: как фиксированных (проводных), так и мобильных. Для создания конференции необходимо реализовать интеграцию и поддержку различных технологий: «переговорных комнат», использования удаленных веб-камер, мобильных устройств и ПК-пользователей. Функционал конференций напрямую зависит от типа собраний: более простые решения используются для небольших (или неформальных) совещаний, в то время как более сложные и гибкие решения используются для собраний больших групп пользователей или для собраний, имеющих повышенные требования к возможностям управления.
· Портал самообслуживания пользователей
Функционал, позволяющий пользователям самим управлять настройками своей учетной записи. Более продвинутые решения позволяют применять ролевую, региональную, или структурную модель управления как расширенным, так и базовым функционалом, и отчетностью, при этом управление осуществляется через дружественный и интуитивно понятный веб-интерфейс. Отсутствие порталов самообслуживания побуждает использовать дорогие и весьма затратные (по времени) подходы для предоставления прав и изменению настроек учетных записей, а именно: ручные или полу автоматизированные.
· Установка и интеграция
Включает в себя набор профессиональных услуг, удаленную поддержку (по телефону и/или электронной почте) и различные веб-инструменты для добавления новых пользователей. Небольшие и простые внедрения могут осуществляться, в основном, удаленно. Большие и сложные внедрения требует очного присутствия профессионалов, при этом могут решаться такие задачи как:
o Управление проектной деятельностью;
o Проектирование сетевой архитектуры (или формирование перечня необходимых изменений текущей);
o Тестирование решение и прочее
Требования в этой области напрямую зависят от потребностей различных Компаний: от поставщика могут потребовать широкого функционала возможностей - долгосрочной поддержки; интернационального присутствия; поддержки различных языков, валюты и соответствия требованиям законодательства и регуляторов различных стран.
· Предоставляемые услуги и поддержка
Удовлетворенность Компании-заказчика во многом зависит именно от этого функционала. Более продвинутые решения предлагают порталы, позволяющие осуществлять мониторинг и отслеживать статус решения проблем. С технической точки зрения более сильные решения предлагают функционал, включающий в себя:
o Мониторинг производительности и отслеживание статуса решения проблем
o Предоставление качественных статистических данных
o Оповещения о приближении к пороговому значению возможного траффика
o Информацию о загрузке сети (мониторинг производительности сети) и показателях маршрутизаторов
o Возможность создания заявок (ticket) для решения возникающих проблем
o Предоставление доступа к детализированной платежной информации
o Возможность онлайн-оплаты услуг поставщика услуг
С точки зрения компаний-участников процесса коммуникации в отчете анализируются следующие типы компаний:
· Услуги для малого и среднего бизнеса (компания-субродрядчик)
Рынок SMB очень разнообразен и разделен на сегменты, при этом требования к унифицированным коммуникациям одного сегмента могу значительно отличаться от требований другого. Однако ограничения, накладываемые на возможные ИТ-ресурсы в SMB-сегменте значительно сильнее, чем у крупных корпораций, что в свою очередь формирует определенные тенденции при интеграции UCaaS-решений. Малый и средний бизнес отдает предпочтения UCaaS решениям, которые:
o Имеют простой и интуитивно понятный пользовательский порталом, которым легко пользоваться;
o Обладают прозрачной и простой схемой ценообразования и оплаты;
o Просты в интеграции (требуют минимальной настройки и доработки);
o Поставляются с легкодоступной поддержкой;
o Интегрированы в используемые приложения (например, salesforce.com) или в приложения, которые взаимосвязаны с существующими бизнес-процессы Компании;
В целом, SMB имеют множество потребностей в коммуникациях, аналогичных потребностям крупных корпораций (при этом их требования к настройке и/или модернизации решения существенно ниже), однако количество ресурсов (финансовых и ИТ), которыми они могут воспользоваться, не так велико.
· Услуги для крупного бизнеса (Компания -Заказчик, Компания-Интегратор)
Крупный бизнес имеет, как правило, более сложные требования к УК-решениям, которые часто должны быть интегрированы в существующую WAN-среду. Такие внедрение должны учитывать разнообразные потребности множества работников, большое количество сайтов и сложность процесса принятия решений. Корпорации ожидают от решения минимального времени простоя, высокой производительности и надежности, а также значительного уровня обеспечения безопасности. Из-за существующих инвестиций в точечные (локальные) решения крупные компании рассматривают UCaaS в долгосрочной перспективе как часть более крупной инициативы по переносу требуемого функционала в облако. Обычно, корпорации предпочитают работать с поставщиками, которые:
o Зарекомендовали себя на рынке и имеют опыт работ в аналогичных компаниях (по размеру и/или сектору экономики);
o Могут разрабатывать (или дорабатывать) и поддерживать решения «на заказ»;
o Могут предложить специальные услуги (в некоторых случаях), чтобы обеспечить необходимый уровень безопасности;
o Предоставляют легко и быстро масштабируемый сервис, который может поддерживать значительное количество пользователей.
· Международные, распределенные компании (Компания-интегратор, Вендор)
Возможность осуществлять поддержку международных компаний. Международные компании отличаются от крупных корпораций не столько размером, сколько тем, что они осуществляют и поддерживают свою деятельность в различных регионах, при этом соблюдая и выполняя локальные требования стран присутствия. По этой причине, при работе с международными компаниями, поставщики UCaaS-услуг должны предоставлять поддержку, с учетом нормативных, регуляторных и языковых требований. В большинстве случаев, поставщик UCaaS-услуг должен объединиться с региональными партнерами для того, чтобы оказывать полный спектр услуг.
Для каждого типа компании были определены веса, отображающие степень влияния каждой критичной функции на тот или иной сценарий в процентах. После чего каждое рассматриваемое решение (поставщик) было оценено по «5» бальной шкале, при этом считается, что:
· Оценка 1 = «Очень низкое соответствие» (почти все необходимые требования не выполняются решением (поставщиком));
· Оценка 5 = «Очень высокое соответствие» (решение (поставщик) значительно превышает необходимые требования);
Оценка по каждой из рассматриваемых критичных функций умножается на соответствующий для нее вес, в зависимости от сценария, после чего суммируются полученные значения («оценка по функции» * «вес»), что и формирует итоговую оценку решения (поставщика).
Результат оценки согласно отчету, Gartner представлен в Приложении 2.
По оценкам аналитического агентства лидерами этой отрасли являются решении вендоров: West, Thinking Phone Networks, Orange Business Services, HP, 8x8. Магический квадрант Gartner представлен на рис.9.
Рисунок 9. Магический квадрант Gartner CaaS - решений за 2014 г.
На российском рынке представлены следующие компании - лидеры: Orange Business Services, HP.
Данные решения способны максимально удовлетворить потребности участников коммуникаций, рассмотренных выше. Полная таблица оценки решений представлена в приложении 3. Сводная таблица представлена на рис.10.
Рисунок 10. Оценка CaaS решений
Для построения объединённых коммуникаций между участниками проектов системной интеграции наиболее подходящим решением является Orange Business Services. Компания-интегратор может выступать в качестве провайдера услуги, предоставляя лицензии на использование решения во время проекта.
Сценарий решения коммуникационных рисков с помощью построения решения на основе имеющегося у участников проекта ПО предполагает использование сторонних сервисов с ограниченным функционалом для удовлетворения тех или иных потребностей участников на время проекта.
· Телефония -Lync, Skype, мобильное подключение;
· Видео-конференц связь Lync, Skype, Cisco Webex;
· Совместная обработка документов - Яндекс Диск,Google Drive, Drobox;
· Постановка задач - MS Exchange,Workflow Soft, Wrike,Megaplan;
· Отслеживание статуса участника - Lync, Skype;
· Безопасность передачи данных - при использовании сторонних решений низкая;
· Простота подключения нового участника - да;
· Приемлемая стоимость - большинство функционала перечисленных решений бесплатно;
Сводный обзор сторонних облачных решений российского рынка представлен в табл.9.
Таблица 9. Обзор облачных коммуникационных решений для управления проектами
|
Функциональные требования |
Skype |
Workflow Soft |
Cisco Webex |
Яндекс Диск, Google Drive, Drobox |
Мегаплан |
Wrike |
Адванта |
Zoho Projects |
|
|
Телефония |
+ |
- |
+ |
- |
- |
- |
- |
- |
|
|
Мобильность |
+ |
+ |
- |
+ |
+ |
+ |
+ |
+ |
|
|
Организация конференц-связи (Аудио/Видео/Веб) |
+ |
- |
+ |
- |
- |
- |
- |
- |
|
|
Совместная обработка документов |
- |
- |
- |
+ |
+ |
+ |
+ |
+ |
|
|
Постановка и планирование задач |
- |
+ |
- |
- |
+ |
+ |
+ |
+ |
|
|
Отслеживание статуса участника |
+ |
- |
- |
+ |
+ |
- |
+ |
- |
|
|
Безопасность передачи данных |
-+ |
- |
+ |
- |
- |
- |
- |
- |
|
|
Простота подключения нового участника |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
|
|
Стоимость |
Условно бесплатно до 5 чел |
от $30/мес/чел |
Условно бесплатно до 5 чел |
Условно бесплатно до 2 ГБ |
от $50/мес/чел |
от $50/мес/чел |
от $75/мес/чел |
от $50/мес/чел |
3.3 Развитие инструментов для поддержки проектной деятельности
Распределенные проекты имеют большое количество участников разного типа: малый и средний бизнес, крупный бизнес, международные компании, частные лица: эксперты и фриланс. Проекты системной интеграции длятся в среднем около1,5-2 лет, а значит на протяжении всего срока проекта необходимо выстраивать и обеспечивать коммуникацию между участниками проекта. Компании-участники выдвигают ряд требований к техническим решениям для коммуникации: поддержка телефонии, мобильности, ВКС, совместная обработка документов и ведение проекта, защищенность каналов передачи данных, сложность внедрения и поддержки и т.д. Частные лица - эксперты и фриланс также должны быть подключены к этой платформе для коммуникации.
Необходимость построения единой платформы для коммуникаций на время проекта порождает появление новых сервисов на рынке ИТ-услуг и электронного бизнеса. Текущие онлайн-сервисы не перекрывают всех потребностей компаний, решения корпоративного уровня зачастую имеют высокую стоимость внедрения. В дальнейшем возможен рост компаний способных предоставить площадку для взаимодействия участников проекта как сервис по заданным требования заказчика.
Рассмотрим описание сервиса для ведения проектных коммуникаций (B2B).
· Предпосылки (проблемы, которые может решить предлагаемый сервис):
При построении коммуникаций для распределенных проектных команд не всегда достаточно использовать корпоративные решения объединённых коммуникаций:
o Разрозненные решения команд-участников;
o Высокая стоимость подключения;
o Недостаточен функционал решения;
o Большинство решений корпоративного уровня производятся иностранными вендорами;
o Большинство онлайн-сервисов имеют узкий функционал;
· Функциональные требования к сервису:
o Телефония
o Мобильность
o Организация конференц-связи (Аудио/Видео/Веб)
o Совместная обработка документов
o Постановка и планирование задач
o Отслеживание статуса участника
o Безопасность передачи данных
o Простота подключения нового участника
o Стоимость
o Хранение данных на территории РФ
· Решение:
B2B сервис, имеющий облачную архитектуру, которые позволяет организовать взаимодействие участников проекта по заданным требованиям.
· Потребительские сегменты
o Сервис ориентирован на распределенные компании среднего и крупного бизнеса, занимающихся проектной деятельностью с привлечение субподрядных организаций.
o Компаний малого бизнеса, ещё не выстроивших свою инфраструктуру.
· Ценностное предложение:
Ведение коммуникаций проекта на единой платформе для всех участников проекта, включая:
o Звонки;
o ВКС;
o Демонстрация и управление экраном;
o Работа над документами;
o Отслеживание статуса участника;
o Безопасность передачи данных;
o Хранение данных на территории РФ;
· Каналы-сбыта:
o Продажи через интернет;
o Партнерские подписки: Компании-интеграторы и прочие компании имеющие распределенные проекты;
· Модели продаж:
o Freemium - бесплатная версия до 5 пользователей;
o Field Sales - визиты в компании для продаж ЛПР (сегмент крупного и среднего бизнеса);
· Взаимоотношения с клиентами:
o Самообслуживание-индивидуальные настройки, инструкции, онлайн тех поддержка;
o Поддержка - продажа лицензий, обучение, поддержка в случае крупных сделок для построения коммуникаций между участниками среднего и крупного бизнеса на проекте;
· Потоки поступления дохода:
o Продажа лицензий;
o Поддержка проекта и кастомизация;
· Ключевые ресурсы:
o Разработчики ПО
o Специалисты по продажам;
· Ключевые виды деятельности:
o Платформа/сети;
o Разработка и развитие коммуникационной платформы;
· Ключевые партнеры:
o Компании -интеграторы;
o Компании-поставщики ПО;
o Телекоммуникационные компании;
· Структура издержек:
o Люди - заработная плата разработчиков;
o Содержание платформы - затраты на аппаратное обеспечение, хостинг, ЦОД;
o Маркетинг и продажи - продвижение продукта на рынке;
o Поддержка пользователей - поддержка пользователей платформы;
Выводы по третьей главе
В третьей главе рассмотрены и описаны методы и инструменты нивелирования рисков проектов системной интеграции. В рамках анализа методов были предложены модели управления требованиями и изменениями для использования в компании, на базе которого проводилось исследование рисков.
В Приложении 4 представлен свод методов и инструментов по нивелированию рисков, выявленных на этапе анализа. В данной работе подробно разработан вопрос нивелирования рисков управления требованиями, изменениями и риски коммуникаций.
Для оценки инструментов нивелирования коммуникативных рисков проекта были рассмотрены отчеты аналитического агентства Gartner по одному из самых популярных направлений систем коммуникации UCaS, - облачные решения корпоративного уровня для построения коммуникаций.
Также проведена оценка онлайн-сервисов для коммуникации. Анализ работы проектной команды показал потребность в построении единой платформы для коммуникации в проекте с распределенными участниками из разных компаний, а также при участии частных лиц.
Для разработки и развития таких сервисов в России на текущий момент есть все предпосылки. Решения-российских разработчиков, которые сейчас присутствуют на рынке могут быть доработаны и развиваться в другом потребительском секторе - корпоративном.
Заключение
Основной целью исследования было выявление рисков управления проектами системной интеграции и возможностей для их нивелирования с использованием современных методов и технологий.
Рассмотрев текущее состояние рынка ИТ-услуг России, была определена роль проектов системной интеграции: они занимают весомую долю на рынке ИТ-услуг (42%) и спрос на этот вид услуг будет лишь расти в ткущих условиях.
В информационных источниках теоретический аспект системной интеграции описан недостаточно.
В результате проведенной работы рассмотрены теоретические основы системной интеграции, дано определение проекта системной интеграции и описание специфики проектов системной интеграции на основе консолидирования информационных источников и мнения экспертов в управлении проектами.
Одной из основных задач в ходе исследования было проведение оценки рисков проектов системной интеграции в практике российских ИТ-компаний. Площадкой для проведения оценки рисков стала компания-интегратор ЗАО «СофтЛайн Трейд». В результате опроса экспертов был сформирован перечень рисков, характерных для проектов системной-интеграции в компании и получена тепловая карта рисков с распределением рисков по уровням в зависимости от их последствий и вероятности возникновения.
Основные риски критичного и высокого уровня - это риски, связанные с управлением требованиями, изменениями и коммуникациями участников проекта. На основе представленных рисков был сделан вывод о том какие потребности (методологические и технические) в управлении проектами системной интеграции существуют на данный момент.
Для нивелирования выявленных рисков на методологическом уровне в ходе работы были разработаны и описаны процессы разработки требований и управления изменениями для компании, на базе которой производилось исследование.
Коммуникативные риски проектов являются одними из самых высоких рисков, выявленных на этапе оценки. Наличие рисков такого типа говорит о потребности в техническом решении для нивелирования рисков. В ходе работы была проведена сравнительная характеристика решений корпоративного уровня для построения унифицированных коммуникаций, а также анализ онлайн-сервисов, существующих на рынке.
По итогам исследования был сделан вывод о необходимости разработки (доработки) сервиса объединенных коммуникаций, который смог бы удовлетворить текущие потребности участников проектов, таких, например, как проекты системной интеграции. В работе описана бизнес- модель B2B сервиса для построения коммуникации распределенных участников проектов.
В дальнейшем необходима более детальная проработка бизнес-модели: описание бизнес-процессов, более детальный обзор рынка и потребительских сегментов, архитектура системы.
Взяв за основу сегмент проектов системной интеграции, в ходе работы было проведено выявление основных рисков и потребностей для управления такими проектами, на основе чего был сделан вывод о существовании сегмента в котором может и должен появиться сервис способный удовлетворить технические требования пользователей.
Таким образом, удалось выявить специфику проектов системной интеграции и описать необходимые сервисы для поддержки управления проектами системной интеграции.
Библиографический список
1. A Guide to the Project Management Body of Knowledge ( PMBOK® Guide ) --Fifth Edition (ENGLISH) // PMI, 2013 589 pages.
2. Национальный стандарт РФ ГОСТ Р ИСО/МЭК 31010 --2011 [Электронный ресурс]: // URL: http://ivan-shamaev.ru/wp-content/uploads/2013/05/31010-2011_Russia.pdf (дата обращения 11.03.2015).
3. Агапов В., Яковлев С., Пратусевич В. Обзор и оценка перспектив развития мирового и российского рынков информационных технологий 2014 IDC Russia [Электронный ресурс]: // URL: http://www.rusventure.ru/ru/press-service/news/detail.php?ID=45815 (дата обращения 15.04.2015).
4. Атапина Н. В. Сравнительный анализ методов оценки рисков и подходов к организации риск-менеджмента [Электронный ресурс] / Н. В. Атапина // Молодой ученый. -- 2013. -- №5. -- С. 235-243.
5. Балашов, А. И. Управление проектами: учебник для бакалавров / А. И. Балашов,Е. М. Рогова, М. В. Тихонова, Е. А. Ткаченко; под ред. Е. М. Роговой. --М.: Издательство Юрай, 2013. -- 383 с.
6. Белов И., Нижникова Е «Рекомендации стандартов управления проектами не следует принимать как...» [Электронный ресурс] /И. Белов, Е. Нижникова // Директор информационной службы -- 2014 г -- №7. --с 14-19
7. Богданов В. Можно ли обойтись без автоматизации процессов управления проектами? [Электронный ресурс]: 12.06.2013 // URL: http://www.bogdanov-associates.com/rubrs.asp?rubr_id=534&art_id=563 (дата обращения 23.02.2015)
8. Говорков А. С. О некоторых проблемах управления проектами [Электронный ресурс] / А. С. Говорков // Молодой ученый. -- 2009. -- №3. -- С. 45-47.
9. Гринберг, А. С. Информационный менеджмент [Электронный ресурс]: Учеб. пособие для вузов / А. С.Гринберг, И. А. Король. - М. : ЮНИТИ-ДАНА, 2012. - 415 с. - (Серия «Профессиональный учебник: Информатика»). - ISBN 5-238-00614-4.
10. Зырянов М. Риск-менеджмент в ИТ-службе [Электронный ресурс]:/М. Зырянов.// «Директор информационной службы», . -- 2014. -- №9.
11. Кириллов И. От системной интеграции к Professional Services [Электронный ресурс]:/ Кириллов И. // «СЕТИ И БИЗНЕС» -- 2010 -- №4 (53).
12. Корепанов М.Б., Зиле И. А., Фунтов В. Н. Создание информационной системы управления проектами газодобывающего предприятия [Электронный ресурс]:/ М.Б. Корепанов // URL: УПРАВЛЕНИЕ ПРОЕКТАМИ № 4 (13) - 2008.
13. Кравченко Т.К. Управление требованиями при реализации ИТ-проектов [Электронный ресурс] / Н. В. Атапина // Бизнес-информатика. -- 2013. -- №3(25). -- С. 63-71.
14. Ладяев Д. Необходимость проведения предпроектного обследования [Электронный ресурс]: 06.08.2014 // URL: http://www.elma-bpm.ru/journal/2176/ (дата обращения 02.03.2015).
15. Русякова М. С. Обзор современных моделей оценки зрелости управления проектами [Электронный ресурс] / М. С. Русякова // Молодой ученый. -- 2014. -- №11. -- С. 230-236.
16. Симионова Н.Е. Интеграционные проекты: проблемы управления [Электронный ресурс] / Н. Н.Е. Симионова // Интернет-журнал «НАУКОВЕДЕНИЕ» -- 2013. -- №3.
17. Султанов Ф.Ф. Межкорпоративная информационно-аналитическая система мониторинга проектной деятельности предприятия менеджмента [Электронный ресурс] /Ф.Ф. Султанов // Электронный журнал «Труды МАИ» -- 2014 -- Выпуск №73.
18. Учитель, Ю. Г. Разработка управленческих решений [Электронный ресурс]: учебник для студентов вузов, обучающихся по специальности «Антикризисное управление» и другим экономическим специальностям, специальности «Менеджмент организации» / Ю. Г. Учитель, А. И. Терновой, К. И. Терновой. - 2-е изд., перераб. и доп. - М.: ЮНИТИ-ДАНА, 2012. - 383 с. - ISBN 978-5-238-01091-5.
19. Фролкина Е. С. Насколько часто и почему происходит перерасход бюджета в крупных инфраструктурных проектах / Е. С. Фролкина // Российский журнал управления проектами. М.: ИНФРА-М. V. 3. I. 1. C. 3-16. DOI: 10.12737/2689
20. Холодков А. Системная интеграция: технический аспект [Электронный ресурс]: 13.10.2014 // URL: http://www.ibs.ru/media/our-analytics/novaya-it-realnost-vyzovy-i-vozmozhnosti/ (дата обращения 15.04.2015).
21. Анализ методологий управления проектами [Электронный ресурс]: 17.01.2012 // URL: http://infostart.ru/public/296315/ (дата обращения 18.03.2015).
22. Обзор TAdvisor: Рынок ИТ России [Электронный ресурс]: Прогноз на 2015 год // 10.04.2015. URL: http://www.tadviser.ru/ (дата обращения 15.04.2015).
23. Новая ИТ-реальность: вызовы и возможности [Электронный ресурс]:13.10.2014 // URL: http://www.ibs.ru/media/our-analytics/novaya-it-realnost-vyzovy-i-vozmozhnosti/ (дата обращения 15.04.2015).
24. О компании Softline [Электронный ресурс]: // URL: http://softline.ru/about (дата обращения 01.02.2015).
25. Рейтинг консалтинговых компаний [Электронный ресурс]: 22.07.2014 // URL: http://infostart.ru/public/296315/ (дата обращения 10.04.2015)
26. Управление изменениями в организации [Электронный ресурс]:/ 27.04.2015 // URL: http://www.ibcm.biz/Konsalting-izmeneniy/upravlenie-izmenenijami-v-organizacii.html (дата обращения 01.05.2015).
27. CIS 8020 - Systems Integration, Georgia State University OECD [Электронный ресурс]: // URL: http://elite.polito.it/files/courses/02CIX/SystemIntegration.pdf (дата обращения 25.04.2015).
28. Gartner 2014 Magic Quadrant for Unified Communications as a Service, Multiregional [Электронный ресурс]// URL [Электронный ресурс]// URL: https://www.gartner.com/doc/2924518/critical-capabilities-unified-communications-service (дата обращения 09.05.2015).
29. Gartner: Critical Capabilities for Unified Communications as a Service, North America With Additional Regional Presence [Электронный ресурс]// URL: https://www.gartner.com/doc/2924518/critical-capabilities-unified-communications-service (дата обращения 09.05.2015).
30. Press Release Gartner: Gartner Says Worldwide IT Spending to Decline 1.3 Percent in 2015 [Электронный ресурс]: STAMFORD, Conn., April 9, 2015 // URL: http://www.gartner.com/newsroom/id/3025217 (дата обращения 15.04.2015).
31. System integration, definition [Электронный ресурс]: // URL: httphttp://en.wikipedia.org/wiki/System_integration (дата обращения 20.01.2015).
Приложение 1. Результат проведения идентификации рисков методом Дельфи
1.1 Анкета для опроса Экспертной группы ЗАО «ЗАО СофтЛайн Трей»
Опрос по теме технологичных проектов системной интеграции в нашей компании. Проекы, связанные с построением архитектуры с системами нескольких классов, проекты включающие в себя работы от этапы проектирования процессов до внедрения решения. Прошу вас вспомнить примеры таких проектов и ответить на вопросы:
1. В скольких проектах системной интеграции вы приняли участие?
2. Какая средняя длительность проектов?
3. Сколько участников проекта в среднем?
4. Сколько компаний-субподрядчиков, фрилансеров необходимо было привлекать для реализации таких проектов?
5. Каковы основные трудности в таких проектах?
6. Опишите риски проектов в свободной форме:
· При инициации проекта;
· При планировании проекта;
· При Исполнении проекта?
· При Закрытии проекта?
Таблица11. Перечень рисков, идентифицированных в ходе опроса экспертной группы
|
№ |
Наиболее распространенные риски при реализации проектов системной интеграции (экспертная оценка) |
|
|
1. |
Этап 1. Инициация проекта |
|
|
1.1. |
Отсутствие контакта с ключевыми стейкхолдерами проекта |
|
|
1.2. |
Неверное понимание потребностей заказчика |
|
|
1.3. |
Неверная постановка задач проекта и содержание работ |
|
|
1.4. |
Снижение оперативности взаимодействия участников команды проекта |
|
|
1.5. |
Анализ рисков не осуществляется на этапе планирования и подготовки продажи проекта |
|
|
1.6. |
Конфликт интересов внутри Компании-Исполнителя |
|
|
1.7. |
Конфликт внутри команды проекта при взаимодействии Исполнителей из разных компаний/подразделений, ввиду отсутствия единого подхода к реализации проекта |
|
|
1.8. |
Плохо проработана архитектура решения из-за отсутствия полных данных о инфраструктуре заказчика |
|
|
2. |
Этап 2. Планирование проекта |
|
|
2.1. |
Ошибка в планировании объема работ и трудозатратах Исполнителей,т.к. не проводятся первичный анализ и оценка сложности проекта сотрудниками, которые станут непосредственными исполнителями по проекту |
|
|
2.2. |
Недостаточная квалификация Исполнителей для осуществления проекта |
|
|
3. |
Этап 3. Исполнение проекта |
|
|
3.1. |
Риски, связанные с территориальной распределенностью проектной команды |
|
|
3.2. |
Отсутствие единой точки коммуникации всех участников проекта как со стороны Исполнителя, так и Заказчика (ВКС, переговоры, демонстрации) |
|
|
3.3. |
Увеличение расходов на командировки Исполнителей |
|
|
3.4. |
Проблемы с подключением к сети интернет |
|
|
3.5. |
Риски, связанные с участием в проектной команде представителей нескольких компаний/региональных хабов компании Softline |
|
|
3.6. |
Потеря контроля при ведении проекта из-за перегруженности руководителей проекта |
|
|
3.7. |
Конфликт интересов между проектами, в которых Заняты Исполнители |
|
|
3.8. |
Нарушение субординации/зон ответственности внутри команды проекта |
|
|
3.9. |
Конфликты внутри команды проекта |
|
|
3.10. |
Смена участников проектной команды Исполнителя до завершения проекта |
|
|
3.11. |
Отказ от выполнения работ субподрядчиком (субподрядчик не заинтересован в результате проекта) |
|
|
3.12. |
Невозможность ведения совместной работы участников проектной команды (Использование разных, порой несовместимых технологий для коммуникации (совместная обработка документов) |
|
|
3.13. |
Невозможность удаленной работы из-за политик безопасности участников проекта |
|
|
3.14. |
Риски, связанные с отсутствием ограничений по проекту |
|
|
3.15. |
В договоре и техническом задании нет четкого описания границ проекта |
|
|
3.16. |
Завышенные ожидания по проекту и Заказчика |
|
|
3.17. |
Нет понимания стейкхолдеров проекта на стороне Заказчика, не ведется управление стейкхолдерами |
|
|
3.18. |
Сложный и продолжительный этап согласования на стороне Заказчика |
|
|
3.19. |
Изменение требований со стороны Заказчика |
|
|
3.20. |
Частая недоступность ключевых работников Заказчика |
|
|
3.21. |
Не сформирована/лишь формально сформирована команда проекта на стороне компании-Заказчика |
|
|
4. |
Этап 4. Закрытие проекта |
|
|
4.1. |
Процедура закрытия проекта слабо формализована в Договоре |
|
|
4.2. |
Давления Заказчика, «репутационные риски» |
|
|
4.3. |
Реализации смежных (не имеющих прямого отношения к проекту) задач специалистами проектной команды |
Приложение 2. Результат оценки рисков Экспертной группой
Таблица 12. Оценка рисков проекта системной интеграции экспертной группой
|
Риски |
Уровень риска |
|
|
Этап 1. Инициация проекта |
||
|
Отсутствие контакта с ключевыми стейкхолдерами проекта |
III |
|
|
Неверное понимание потребностей заказчика |
II |
|
|
Неверная постановка задач проекта и определение содержания работ |
II |
|
|
Снижение оперативности взаимодействия участников команды проекта |
III |
|
|
Анализ рисков не осуществляется на этапе планирования и подготовки продажи проекта |
II |
|
|
Конфликт интересов внутри Компании-Исполнителя |
III |
|
|
Конфликт внутри команды проекта при взаимодействии Исполнителей из разных компаний/подразделений, ввиду отсутствия единого подхода к реализации проекта |
III |
|
|
Плохо проработана архитектура решения из-за отсутствия полных данных о инфраструктуре заказчика |
II |
|
|
Этап 2. Планирование проекта |
||
|
Ошибка в планировании объема работ и трудозатратах Исполнителей ,т.к. не проводятся первичный анализ и оценк... |
Подобные документы
Внедрение управления проектами в 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
