Оптимизация управления программами ИТ-проектов с применением облачных технологий в ЗАО "КонсОМ СКС" город Магнитогорск
Анализ методов управления программами ИТ-проектов. Предпроектное обследование компании ЗАО "КонсОМ СКС". Разработка механизмов управления программами ИТ-проектов. Рекомендации по эксплуатированию системы. Методика расчета экономических и других эффектов.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 30.04.2019 |
Размер файла | 5,5 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Процессу «Стадия-Проход» предшествует этап «Открытия» (Discovery), который был добавлен в более позднем варианте оригинальной модели, которая имела только 5 фаз (рисунок 12). Он содержит предварительный анализ, предназначенный для открытия возможностей и получения новых идей.
Рисунок 12 - Этапы модели «Стадия-Ворота»
В таблице 16 приведены описания процессов, представленные на рисунке 12.
Таблица 16 - Описание этапов модели «Стадия-Ворота»
№ п/п |
Стадия |
Описание |
|
1 |
Обзор данных (Scoping) |
Быстрое, предварительное исследование каждого проекта. Обеспечивает недорогую информацию посредством кабинетного исследования для оптимизации числа проектов. |
|
2 |
Моделирование бизнес ситуаций (Build the business case) |
Значительно более детализированное исследование посредством маркетингового и технического анализа. Бизнес ситуация должна включать определение, объяснение целесообразности и план проекта. |
|
3 |
Развитие(Development) |
Разрабатываются производственный план и план реализации. |
|
4 |
Тестирование и утверждение (Testing and validation) |
Обширное тестирование. |
|
5 |
Запуск (Launch) |
Начало полномасштабного производства, маркетинга и продаж. Запуск продукта на рынке, производство/операционная деятельность, дистрибуция, гарантия качества. |
|
Анализ стадии выпуска продукта на рынок. |
Перед началом каждой стадии стоят ворота, через которые должен пройти проект (рисунок 13). В воротах принимаются решения о судьбе проекта. Этот метод применим к портфелю и программе проектов.
Рисунок 13 - Прохождение проекта через «Ворота»
Существующие на сегодняшний день методы формирования портфеля или программы проектов в определенной степени учитывают следующие основные ограничения:
? обеспечение соответствия программы (портфеля) основным стратегическим целям компании;
? обеспечение необходимых взаимосвязей и взаимозависимостей проектов программы (эффекты синергии и каннибализма);
? обеспечение достаточности выделяемого бюджета на финансирование инвестиционных затрат по проектам программы.
Кроме того, в ходе решения данной задачи многие модели учитывают влияние факторов неопределенности. Однако, имеющиеся модели формирования программы проектов предназначены для поиска локального решения вне решения остальных задач управления программой (задачи эффективного распределения ресурсов и построения календаря проектов и ресурсов). Это, в свою очередь, снижает эффективность управления программой.
Другой центральной задачей управления программой является задача эффективного распределения ограниченных ресурсов по операциям программы проектов.
Анализ моделей и задач распределения ограниченных ресурсов по операциям программы проектов показал:
? основными учитываемыми неопределенностями в существующих моделях распределения ресурсов являются неопределенности в сроках выполнения отдельных операций проектов;
? критерием эффективности распределения ресурсов по проектам программы, как правило, является критерий минимизации срока завершения всех операций проектов (средневзвешенного срока завершения всех операций). Сокращая длительность инновационного цикла, компания может рассчитывать на усиление или удержание конкурентных преимуществ на рынке, что даст ей возможность обеспечить высокие темпы дальнейшего развития;
? задача распределения должна решаться одновременно для нескольких видов ресурсов (материальных, трудовых, финансовых). Распределение ресурса одного вида во многих случаях недостаточно;
? выделение дополнительных объемов ресурсов на операции проектов во многих случаях приводит к снижению продолжительности этих операций, что, в свою очередь, может привести к снижению продолжительности программы проектов. Однако такое снижение может произойти далеко не во всех случаях. Например, если выполняемая операция не принадлежит критическому пути, т.е. имеет временные резервы, то сокращение продолжительности проектов программы при выделении дополнительных объемов ресурсов, скорее всего, не произойдет. В этом случае имеющиеся временные резервы не позволят добиться снижения продолжительности проектов программы;
? сдвигая сроки запуска проектов (операций проектов) возможно получение других более эффективных распределений ресурсов. В этой связи, на наш взгляд, задача распределения ресурсов должна решаться одновременно с задачей календарного планирования проектов программы. Комплексное решение обеих задач позволит компании эффективно распоряжаться имеющимися ресурсами.
На сегодняшний день, наиболее обоснованными моделями, учитывающими влияние объемов выделяемых ресурсов на продолжительности операций проектов, являются модели, основанные на эластичностях продолжительностей операций по объему используемых ресурсов.
2.2 Разработка механизмов управления программами ИТ-проектов
ЗАО «КонсОМ СКС»
Успешная организация управления программами проектов требует наличие процессов, технологий, политик и стандартов для управления проектами, что также должно быть интегрировано с другими системами управления для более эффективной и производительной работы.
Каждый проект предпринимается для достижения определенного результата. Во многих случаях, причиной инициации того или иного проекта, является его необходимость в достижении какой-то важной цели, стоящей перед организацией. Выделим особенности управления программами проектов [42]:
1. Первая заключается в том, что цели, сроки выполнения и бюджет определяются для программы в целом и затем менеджер программы распределяет их дальше между входящими в программу проектами. То есть, планирование программ в большинстве случае осуществляется по методу «сверху вниз».
2. Вторая особенность заключается в том, что проекты, входящие в программу, взаимосвязаны между собой. Поэтому часто лишь по завершению одного проекта можно начинать выполнение следующего проекта или по завершению этапа одного проекта можно начинать этап в другом проекте и т.п. Обычный (не входящий в программу) проект, например, заключающийся в выполнении контрактных работ, пересекается с другими проектами только за счет используемых совместно ресурсов. Поэтому на него не так сильно влияют риски и проблемы других проектов. Если же проект входит в программу, то его успешное завершение намного сильнее зависит от результатов выполнения других проектов.
3. Наконец, последняя особенность заключается в отчетности и документировании программы. Организация ставит цели всей программы и выделяет ресурсы на всю программу, а не на отдельные ее проекты. Поэтому программа зачастую контролируется на верхнем уровне, а не на уровне отдельных проектов, и вся отчетность и документация должны консолидироваться на уровне программы для передачи заинтересованным сторонам в организации.
Эти особенно дают сложность в реализации программ проектов. В таблице 17 приведена успешность реализации проектов «КонсОМ СКС» за последние 3 года. Диаграммы представлена на схеме 1.
Таблица 17 - Статистика реализации проектов в ЗАО «КонсОМ СКС»
№ п/п |
Критерий |
% |
|
1 |
Успешная реализация проектов |
28 |
|
2 |
Частичная реализация проектов |
70 |
|
3 |
Нереализованные проекты |
2 |
За последние 3 года, все проекты, которыми занималась организация, должны были принести «КонсОМ СКС» более 50 млн. рублей. По данным таблицы 17 недополученная прибыль составила 30% = более 15 млн. рублей. Достичь 100% успешной реализации нереально, но минимизировать эти потери мы хотим за счет правильного управления.
Перед каждым проектом ставят n-количество целей, которые необходимо достичь в ходе его реализации. Если проект не достигает 100% реализации целей, а хотя бы выполнен на 80-90%, то его можно считать частичноуспешным, меньший процент ведет к тому, что проект становится нереализованный. Стоит обратить внимание на специфику ИТ-проектов, у которых цели могут быть размытыми.
Также частично реализованные и нереализованные проекты в «КонсОМ СКС», были связаны с недоступностью ресурсов в определенное время, в силу неправильного распределения. Это привело к замораживанию проектов.
Схема 1 - Статистика реализации проектов в ЗАО «КонсОМ СКС»
Для того чтобы увеличить процент успешной реализации проектов, и избежать проблем с перегруженностью ресурсов, необходимо внедрение общих механизмов по управлению проектами. Опираясь на специфику «КонсОМ СКС», можно разработать 2 механизма, которые помогут организации в освоении управления программами проектов.
1. Организационный механизм управления программами проектов.
2. Технологический механизм управления программами проектов.
Организационный механизм управления программами проектов состоит в создании нового отдела в «КонсОМ СКС» по управлению проектами - «Отдел проектного управления» (ОПУ), где каждый сотрудник отвечает за определенные функции. Это не «команда проекта», что подразумевает собой временное объединение людей, которые регулярно взаимодействуют друг с другом для достижения определенной цели проекта. Это постояннофункционирующий отдел, который занимается отслеживанием программ проектов и направленный на их поддержание.
В функции нового отдела будет входить:
? минимизировать риски, связанные с реализацией проектов;
? осуществлять управленческий контроль за выполнением проектов на всех фазах (от запуска до завершения);
? разграничить полномочия и ответственность участников проектной деятельности на различных этапах жизненного цикла проекта;
? ввести единые корпоративные правила исполнения проектов, тем самым обеспечив взаимопонимание и продуктивное взаимодействие всех участников проектной деятельности;
? воспользоваться эффективными методами управления проектами, взятыми из лучших мировых практик, и применить положения теории управления проектами к практической деятельности компании;
? облегчить обучение сотрудников методам управления проектами;
? внедрить мультипроектное управление и перейти от управления отдельными проектами к управлению всей проектной деятельностью компании;
? повысить эффективность контроля исполнения проектов со стороны руководителей компании;
? распределять бюджет в программе по приоритетам проектов;
? выносить управленческие решения касающиеся продолжительности проектов.
Все сотрудники должны быть подобраны руководителем отдела. Руководитель отдела, в свою очередь, назначается на должность приказом генерального директора компании. Сотрудники отдела также назначаются на должности и освобождаются от должностей приказом генерального директора, но по представлению руководителя отдела, руководствуясь Уставом компании и Настоящим положением о проектном отделе. Участвующие лица в процессе управления проекта приведены на рисунке 14.
В состав представителей отдела входят:
1. Руководитель отдела: временный менеджер, координатор проекта. Задачей руководителя проекта является определение целей проекта или их согласование с командой. Он должен убедиться, что все члены команды поняли цели проекта и могут их реализовать.
Рисунок 14 - Ответственные лица в процессе управления проектами
2. Аналитики - специалисты, занимающиеся изучением аналитических исследований и обобщений в определенной сфере деятельности, которые в совершенстве владеют методами анализа, обычно способны прогнозировать процессы и разрабатывать перспективные программы развития. Группа аналитиков объединяется в комиссию, когда решается судьба проекта (ов).
3. Финансист-контролер заботится об ознакомлении с экономическими результатами, а также контролирует финансовую часть программы проектов.
4. Риск-менеджер отвечает за выявление и предотвращение рисков по проектам.
Полезность отдел проектного управления будет очевидной для руководства организации, если оно увидит, что отдел способен помочь ему решать те задачи, по которым оценивается работа. Для того, чтобы ОПУ был полностью приемлемым для руководства, он должен обладать следующими характеристиками.
1. Отдел должен содействовать доведению до стадии завершения большего числа проектов без привлечения дополнительных ресурсов (например, количество завершенных проектов должно возрасти на 50%).
2. Большинство проектов должно завершаться в заметно сокращенные сроки (например, ОПУ должен обеспечивать сокращение средней продолжительности выполнения проектов на 25%).
3. ОПУ должен ощутимо и положительно влиять на практические результаты деятельности организаций, причем даже некоммерческих.
4. Весь руководящий состав организации должен видеть преимущества от внедрения ОПУ и те выгоды, которые внедрение офиса способно принести каждому руководителю.
На данный момент в организации нет подходящей структуры, которая бы могла отслеживать все проекты и видеть преимущества/недостатки отдельных проектов. На рисунке 15 показана нынешняя работа по проектам.
Рисунок 15 - Рабочие группы по проектам
При таком подходе каждый менеджер заинтересован в продвижении только своего проекта. Именно поэтому возникают сложности:
? с распределением ресурсов между проектами;
? с расставлением приоритетов между проектами;
? с рисками в реализации проектов;
? с продолжительностью и необходимостью проектов.
После внедрения отдел проектного управления таких сложностей не возникнет, так как ОПУ будет видеть целиком всю программу проектов организации (рисунок 16), и сможет выносить обоснованные управленческие решения.
Рисунок 16 - Рабочие группы по проектам после внедрения ОПУ
Мы предлагаем формировать отдел из имеющегося штата сотрудников. В целях достижения рядя преимуществ: сотрудники знают плюсы и минусы организации; минуем адаптацию новых сотрудников; минуем обучение новых сотрудников.
На рисунке 17 показано внедрение «Отдела проектного управления».
ЗАО «КонсОМ СКС» находится на регламентируемом уровне зрелости (таблица 19). Именно поэтому определение уровня зрелости предприятия играет важную роль. СММ - это общепризнанная модель зрелости, в которую включен набор соответствующих критериев (таблица 18). В силу близости к универсальным стандартам серии ISO 9000 ее вполне разумно применять и для оценивания уровня зрелости любых предприятий. Модель СММ была разработана в конце 1987 году Институтом программной инженерии США.
Рисунок 17 - Организационная диаграмма ЗАО «КонсОМ СКС» с ОПУ
Таблица 18 - Характеристики уровней организационной зрелости
Уровень |
Характеристики |
|
Начальный |
Хаотичность и непоследовательность |
|
Повторяемости |
Базовые процессы. Повторяемые операции. |
|
Уровень |
Характеристики |
|
Регламентируемости |
Стандартизация процессов. Интеграция, наличие процедур. |
|
Управляемости |
Контроль качества. Использование обратной связи. |
|
Оптимизируемости |
Постоянное развитие. Самоадаптация системы. |
Таблица 19 - Характеристики уровня организационной зрелости компании
Признак |
Проявления в компании «КонсОМ» |
|
Формализация основных и управленческих процессов и их документация. |
Управленческие в части подразделений процессы еще не устойчивы, активно протекающий процесс принятия регламентов и инструкций призван ускорить формирование стабильной системы управления. |
|
Появляется описание функций внутри компаний, которые должен выполнять сотрудник того или иного подразделения. |
Наличие должностных инструкций, процедур аттестации, описание ролевых функций сотрудников. |
|
Все процессы стандартизированы, документированы и объединены в общую систему. |
Наличие корпоративного регламента введения проектов и корпоративного стандарта разработки проектной документации. |
|
Возможность анализировать информацию по всем аспектам управленческой деятельности, а также получать оперативную информацию об использовании ресурсов. |
На данный момент в компании идет процесс внедрения автоматизированной системы учета трудовых ресурсов для целей организации информационных потоков в части организации работ. |
|
В планировании используется принцип «от показателей прошлого периода». В обработке информации преобладает ретроспективный анализ. |
При планировании используется опыт прошлых аналогичных проектов. |
|
У компании возникает потребность в управленческих информационных системах, так как для стандартизации процессов требуется их системная информационная поддержка. |
На данный момент в компании идет процесс внедрения централизованного репозитория для целей организации информационных потоков в части проектной документации. |
Для предприятий, находящихся на этом уровне, характерно формирование стратегии развития. Как только такие решения начинают приниматься на основе анализа, это означает, что предприятие переходит на следующий этап организационной зрелости. Документация и формализация основных процессов, в данном случае по управлению проектами, помогает организации координировать работу с клиентами.
Технологический механизм управления проектами подразумевает собой рекомендацию по внедрению системы на облачных технологиях типа SaaS для управления программами проектов, а также переход на новый стандарт по управлению программами проектов.
В целом сервисы «облачных» вычислений представляют собой приложения, доступ к которым обеспечивается через Интернет посредством обычного интернет-браузера или других сетевых приложений, например, FTPклиента. Это могут быть и развлекательные, и служебные, и специализированные бизнес-приложения. Главное отличие от привычного метода работы с ПО заключается в том, что пользователь использует не ресурсы своего ПК, а компьютерные ресурсы и мощности, которые предоставляются ему как интернет-сервис. При этом пользователь имеет полный доступ к собственным данным и возможность работы с ними, но не может управлять той же операционной системной, программной базой, вычислительными мощностями и т.д., с помощью которых эта работа происходит. Именно такое определение облачным вычислениям дал генеральный директор корпорации Microsoft Стив Балмер [51]. Также он объяснил почему именно «облако»: «Во-первых, традиционное изображение Интернета на диаграммах компьютерных сетей выполняется именно в виде облака. Во-вторых, облака - это символ удаленности от конкретного пользователя».
Подобный подход имеет целый ряд плюсов:
? пользователь может задействовать ПК практически любой конфигурации для выполнения ресурсоемких задач;
? облачные технологии позволяют работать в любом месте, пользователь не привязан к месту работы, и может использовать любой ПК, имеющий подключение к Интернету;
? пользователь застрахован от сбоев в работе в случае поломки машины, и может легко делиться результатами работы с другими людьми, либо же вести совместную работу.
Для компаний неоспоримым преимуществом выноса части работы в «облако» является снижение затрат на обслуживание, поддержку, модернизацию и администрирование «железа» и программного обеспечения на месте.
Конечно же, технологии облачных вычислений не ограничиваются сервисами Google Docs или Photoshop.com. В них есть целые подкатегории, отличающиеся по виду предоставляемых услуг (рисунок 18).
Рисунок 18 - Категории «облаков»
Модели работы с «облаком» для разных групп пользователей:
1. «Инфраструктура как услуга» (Infrastructure as a Service, сокр. IaaS) - Это предоставление клиенту разнообразной компьютерной инфраструктуры: серверов, систем хранения данных, сетевого оборудования и т.д.
2. «Платформа как услуга» (Platform as a Service, сокр. PaaS) - предоставление платформы с определенными характеристиками для разработки, тестирования, развертывания, поддержки веб-приложений и т.д.
3. «Программное обеспечение как услуга» (Software as a Service, сокр. SaaS) - это модель продажи и использования программного обеспечения, при которой поставщик разрабатывает веб-приложение и самостоятельно управляет им, предоставляя заказчикам доступ к ПО через Интернет. При этом все затраты на поддержку работоспособности приложения берет на себя поставщик, пользователь же (в случае, если сервис платный) оплачивает только сам факт использования «облачного» ПО (либо по факту использования, либо абонентской платой). Таким образом, пользователю не надо в одночасье выкладывать большую сумму денег на приобретение лицензии, а разработчик защищен от несанкционированного использования и распространения своего продукта.
Согласно отчёту «Competitive Landscape: SaaS Project and Portfolio Management Software, Worldwide», PPM (программы управления преоктами) является самой быстрорастущей категорией программного обеспечения SaaS, с ожидаемым увеличением среднегодового темпа роста на 41% в 5-летний период с 2009 по 2014 годы [52].
В 2013 году, все большее число организаций внедряет решения, основанные на интернет технологиях. Преимущества этого подхода по сравнению с традиционными приложениями будут включать в себя:
? быстрое развёртывание;
? возможности командного взаимодействия;
? снижение риска неудачного внедрения;
? более тесные отношения между производителем системы и клиентом;
? снижение затрат на внедрение и поддержку.
Именно SaaS-технологии отвечают требованиям «КонсОМ СКС». Для внедрения системы типа SaaS по управлению программами проектов организации необходимо перейти на программное управление проектами.
Для этого «КонсОМ СКС» нужно ознакомится и внедрить стандарт по управлению программами проектов «The Standard For Portfolio management».
В стандарте «The Standart For Portfolio management» процессы управления программами проектов разбиваются на 9 групп [31] (рисунок 19).
Рисунок 19 - Процессы управления программами проектов по стандарту
Последовательность и результаты выполнения процессов можно отследить по информативным входам/выходам [31], представленным в приложении 5.
В стандарте описана система управления программой проектов (рисунок 20).
Рисунок 20 - Система управления программой проектов
При этом рассматривается как операционный, так и проектный аспект деятельности. Эффективность с позиции управления программой оценивается как получение оптимальных результатов выполнения программ, проектов, работ, определяемых величиной прироста стоимости, с минимальными усилиями и ресурсами.
После ознакомления и внедрения стандарта по управления программой проектов необходимо выбрать систему типа SaaS.
Существует большое количество систем по управлению проектами, программами и портфелями. Их можно разделить, как на профессиональные, так и на онлайн системы (таблица 20).
Таблица 20 - Примеры систем по управлению проектами
№ п/п |
Тип |
Пример системы |
|
1 |
Профессиональные |
GanttProject |
|
Microsoft Project |
|||
OpenProj |
|||
TaskJuggler |
|||
Open Workbench |
|||
2 |
Онлайн системы |
Easy Projects .NET |
|
№ п/п |
Тип |
Пример системы |
|
Comindwork |
|||
qTrack |
|||
Worksection |
|||
ПланФикс |
|||
3 |
Многопользовательские |
Easy Projects .NET |
|
OpenProj |
|||
Project Kaiser |
|||
Redmine |
Учитывая специфику «КонсОМ СКС», для более эффективного управления программами проектов следует внедрить систему, которая отвечает требованиям, приведенные в таблице 21.
Таблица 21 - Требования к системе
№п/п |
Критерий |
|
1 |
Возможность формирования нескольких проектов. |
|
2 |
Многопользовательское управление. |
|
3 |
Многоязычность. |
|
4 |
Конвертация валют. |
|
5 |
Отсутствие ограничений. |
|
6 |
Таблица затрат. |
|
7 |
Формирование отчетов. |
|
8 |
Отслеживание. |
|
9 |
Документооборот. |
|
10 |
Коммуникации. |
|
11 |
Кроссбраузерность |
|
12 |
Интеграция с мобильными устройствами. |
|
13 |
Авторизация с помощью клиентских SSL сертификатов |
|
14 |
Импорт файлов MS Project |
|
15 |
Пул ресурсов. |
Это общие критерии по требованию к системе. Для каждого из управленца в «КонсОМ СКС» отдельно взятый критерий имеет свою значимость перед другими. Определенно это было путем ранжирования критериев. Результаты предоставлены в приложении 4.
Применение механизмов позволит «КонсОМ СКС» оптимизировать процесс управления проектами.
Внедрение нового отдела позволит «КонсОМ СКС»:
? минимизировать риски, связанные с реализацией проектов;
? осуществлять управленческий контроль за выполнением проектов на всех фазах (от запуска до завершения);
? разграничить полномочия и ответственность участников проектной деятельности на различных этапах жизненного цикла проекта;
? ввести единые корпоративные правила исполнения проектов, тем самым обеспечив взаимопонимание и продуктивное взаимодействие всех участников проектной деятельности;
? воспользоваться эффективными методами управления проектами, взятыми из лучших мировых практик, и применить положения теории управления проектами к практической деятельности компании;
? облегчить обучение сотрудников методам управления проектами;
? внедрить мультипроектное управление и перейти от управления отдельными проектами к управлению всей проектной деятельностью компании;
? повысить эффективность контроля исполнения проектов со стороны руководителей компании;
? распределять бюджет в программе по приоритетам проектов;
? выносить управленческие решения касающиеся продолжительности проектов.
? Введение единого стандарта по управлению программами проектов позволит компании достичь следующих преимуществ:
? балансирование программы, то есть достижение равновесия между краткосрочными и долгосрочными проектами, между рисками проектов и возможными доходами от их реализации, разработка новых и улучшение старых и так далее;
? мониторинг процессов планирования и выполнения выбранных проектов. В частности, принятие решений относительно выделения ограниченных ресурсов, обеспечение всех проектов необходимыми ресурсами в адекватном количестве при одновременном обеспечении выгодного и эффективного использования ресурсов;
? анализ эффективности программы проектов и поиск путей ее повышения. Принятие решений о введение в портфель новых проектов или о закрытии убыточных или малоэффективных проектов;
? сравнение возможностей новых проектов между собой и по отношению к проектам, уже включенным в портфель, а также оценка их взаимовлияния;
? согласование требований этих проектов с другой деятельностью, не имеющей отношения к проектам как таковым;
? обеспечение стабильного и эффективного механизма управления проектами.
Внедрение системы по управлению программами проектов типа SaaS позволит организации:
? улучшить контроль по выполнению проектов;
? повысит удовлетворительность клиентов, т.к. они смогут отслеживать ход выполнения проекта;
? добиться масштабируемости;
? улучшить коммуникации, т.к. SaaS решения идеально подходят для территориально-распределенных организаций. Выше было сказано о том, что «КонсОМ СКС» работает с проектами не только в городе Магнитогорске, но и за его пределами (например, в Уфе) ;
? добиться мобильности, т.е. возможность сотрудникам работать повсюду, где есть доступ в Интернет;
? значительно экономить время.
2.3 Обзор и выбор системы по управлению программами проектов
Программные обеспечения управления программами проектов сосредоточены на помощи в выборе проектов для исполнения и мониторинга выполнения проектов. То есть они исходят из того, что проектов более чем достаточно и надо выбрать оптимальный способ их выполнения, а от некоторых вообще отказаться.
В таблице 22 приведены достоинства и недостатки таких программных обеспечений.
Таблица 22 - Достоинства и недостатки систем управления проектами
Достоинства |
Недостатки |
|
Функциональность этих систем позволяет решить все вышеперечисленные задачи. И ещё много чего ещё, если вам это потребуется. |
Требует внедрения. Системы имеют мощную функциональность, и для их настройки именно для вашего подразделения потребуется выполнить проект по внедрению. |
|
Позволяет узнавать занятость сотрудников. В каких проектах участвуют и когда освободятся. |
Наверняка потребуют изменения уже используемых у вас методов выполнения проектов и замены используемого инструментария. |
|
Позволяет выделить ресурсы на новые проекты |
Цена. Как покупки лицензий, так и внедрения. |
|
Решение внештатных задач. Кого попросить заняться неожиданно возникшей проблемой: найти и исправить критическую ошибку, возникшую в самый неподходящий момент; поехать к заказчику, чтобы реанимировать упавшую систему; сопроводить решения технических вопросов с потенциальным заказчиком и т.п |
||
Просмотр состояния проектов. |
Опираясь на специфику управления проектами «КонсОМ СКС», и критериям, которым должна отвечать система (таблица 21), проанализируем программные обеспечения по управлению программами проектов. Под такими программными обеспечениями мы будет подразумевать такие системы, которые позволяют отслеживать ход выполнения проектов и их взаимное влияние друг на друга в процессе выполнения.
Project.Net
Web-приложение для управления проектами и программами проектов (рис 21).
Рисунок 21 - Отслеживание работ в Project.Net
Система позволяет:
? вести учет рабочего времени, затраченного на выполнение задач;
? обеспечивать коммуникации между сотрудниками;
? составлять планы проектов;
? группировать проекты в программы проектов и анализировать
их;
? следить за ходом выполнения проектов и загруженностью сотрудников;
? создавать отчёты.
Достоинства и недостатки Project.Net приведены в таблице 23.
Таблица 23 - Достоинства и недостатки Project.Net
Достоинства |
Недостатки |
|
Open source программа, может быть скачена и использована на основе GNU (General Public License). |
Для работы необходимо приобрести платную Oracle database. |
|
Подходит для использования в географически распределённых организациях. |
Потребует настройки под ваши нужды организации. |
|
Поддерживает облачные вычисления. |
Могут потребовать изменения уже используемых методов выполнения проектов и замены используемого инструментария. |
|
Программа на английской языке. |
Соответствие системы Project.Net критериям «КонсОМ СКС» (таблица 24).
Таблица 24 - Соответствие Project.Net критериям «КонсОМ СКС»
№п/п |
Критерий |
Соответствие |
|
1 |
Возможность формирования нескольких проектов |
+ |
|
2 |
Многопользовательское управление |
+ |
|
3 |
Многоязычность |
- |
|
4 |
Конвертация валют |
- |
|
5 |
Отсутствие ограничений |
- |
|
6 |
Таблица затрат |
- |
|
7 |
Формирование отчетов |
+ |
|
8 |
Отслеживание |
+ |
|
9 |
Документооборот |
+ |
|
10 |
Коммуникации. |
+ |
|
11 |
Кроссбраузерность |
+ |
|
12 |
Интеграция с мобильными устройствами |
- |
|
13 |
Авторизация с помощью клиентских SSL сертификатов |
- |
|
14 |
Импорт файлов MS Project |
- |
|
15 |
Пул ресурсов |
- |
Система Project.Net не соответствует требованиям «КонсОМ СКС». Система поддерживает возможность формирования нескольких проектов, но в ней отсутствует пул ресурсов.
GroupCamp
Система управления проектами онлайн (рисунок 22), включающая облачные решения и CRM-приложение для ведения малого и среднего бизнеса
[53].
Рисунок 22 - Сравнение данных в GroupCamp
Достоинства и недостатки GroupCamp приведены в таблице 25.
Таблица 25 - Достоинства и недостатки GroupCamp
Достоинства |
Недостатки |
|
Решает все задачи, которые перечислены в достоинствах таблицы 18. |
Громоздкий и путанный интерфейс. |
|
Легко внедрить, т.к. не требует изменения существующего порядка ведения дел. |
||
Подходит для использования в географически распределённых организациях. |
||
Поддерживает облачные вычисления. |
||
Приложение доступно для iPhone, Android и планшетников. |
Соответствие системы GroupCamp критериям «КонсОМ СКС» (таблица 26).
Таблица 26 - Соответствие GroupCamp критериям «КонсОМ СКС»
№п/п |
Критерий |
Соответствие |
|
1 |
Возможность формирования нескольких проектов |
+ |
|
2 |
Многопользовательское управление |
+ |
|
3 |
Многоязычность |
+ |
|
4 |
Конвертация валют |
- |
|
5 |
Отсутствие ограничений |
+ |
|
6 |
Таблица затрат |
- |
|
7 |
Формирование отчетов |
+ |
|
8 |
Отслеживание |
+ |
|
9 |
Документооборот |
+ |
|
10 |
Коммуникации. |
+ |
|
11 |
Кроссбраузерность |
+ |
|
12 |
Интеграция с мобильными устройствами |
+ |
|
13 |
Авторизация с помощью клиентских SSL сертификатов |
+ |
|
14 |
Импорт файлов MS Project |
- |
|
15 |
Пул ресурсов |
- |
Система GroupCamp не соответствует требованиям «КонсОМ СКС». Система поддерживает возможность формирования нескольких проектов, но в ней отсутствует пул ресурсов.
Projects Manager
Онлайн система Projects Manager предназначена для управления проектами. Она включает в себя удобный постановщик задач, баг-трекер, множество отчетов и является полнофункциональной онлайн системой управления проектами. Для работы в Projects Manager необходим только браузер. Создание и управление проектами и задачами, разграничение прав пользователей, формирование и экспорт различных отчетов, оповещения и обмен сообщениями, документооборот, индивидуальные настройки для пользователей [54].
Рисунок 23 - Проекты в Projects Manager
Достоинства и недостатки Projects Manager приведены в таблице 27.
Таблица 27 - Достоинства и недостатки Projects Manager
Достоинства |
Недостатки |
|
Решает все задачи, которые перечислены в достоинствах таблицы 18 (самое начало). |
Громоздкий и путанный интерфейс. |
|
Подходит для использования в географически распределённых организациях. |
||
Поддерживает облачные вычисления. |
Соответствие системы Projects Manager критериям «КонсОМ СКС» (таблица 28).
Таблица 28 - Соответствие Projects Manager критериям «КонсОМ СКС»
№п/п |
Критерий |
Соответствие |
|
1 |
Возможность формирования нескольких проектов |
+ |
|
2 |
Многопользовательское управление |
- |
|
3 |
Многоязычность |
- |
|
4 |
Конвертация валют |
- |
|
5 |
Отсутствие ограничений |
- |
|
6 |
Таблица затрат |
- |
|
7 |
Формирование отчетов |
+ |
|
8 |
Отслеживание |
+ |
|
9 |
Документооборот |
+ |
|
№п/п |
Критерий |
Соответствие |
|
10 |
Коммуникации. |
+ |
|
11 |
Кроссбраузерность |
+ |
|
12 |
Интеграция с мобильными устройствами |
+ |
|
13 |
Авторизация с помощью клиентских SSL сертификатов |
- |
|
14 |
Импорт файлов MS Project |
- |
|
15 |
Пул ресурсов |
- |
Данная система не полностью соответствует требованиям «КонсОМ СКС». Система поддерживает возможность формирования нескольких проектов, но в ней отсутствует пул ресурсов.
Мегаплан
Система для совместной работы в малой или средней компании любого профиля. Включает задачи, файлы, внутреннюю почту, форум, модуль для работы с персоналом компании (личные данные, зарплаты, отпуска, кто кому подчиняется и т.д.) (рисунок 24) [55].
Функциональность:
? учёт рабочего времени;
? организация коммуникации между сотрудниками;
? планирование;
? отслеживание хода выполнения работ.
Рисунок 24 - Дела в системе «Мегаплан»
Достоинства и недостатки Мегаплана приведены в таблице 29.
Таблица 29 - Достоинства и недостатки Мегаплан
Достоинства |
Недостатки |
|
Удобный, интуитивно понятный инструмент для создания планов нескольких одновременно идущих проектов. |
Могут потребовать изменения уже используемых методов выполнения проектов и замены используемого инструментария. |
|
Подходит для использования в географически распределённых организациях. |
||
Поддерживает облачные вычисления. |
Соответствие системы Мегаплан требованиям «КонсОМ СКС» (таблица 30).
Таблица 30 - Соответствие Мегаплан критериям «КонсОМ СКС»
№п/п |
Критерий |
Соответствие |
|
1 |
Возможность формирования нескольких проектов |
+ |
|
2 |
Многопользовательское управление |
+ |
|
3 |
Многоязычность |
+ |
|
4 |
Конвертация валют |
- |
|
5 |
Отсутствие ограничений |
- |
|
6 |
Таблица затрат |
- |
|
7 |
Формирование отчетов |
+ |
|
8 |
Отслеживание |
+ |
|
9 |
Документооборот |
+ |
|
10 |
Коммуникации. |
+ |
|
11 |
Кроссбраузерность |
+ |
|
12 |
Интеграция с мобильными устройствами |
+ |
|
13 |
Авторизация с помощью клиентских SSL сертифи- |
+ |
|
№п/п |
Критерий |
Соответствие |
|
катов |
|||
14 |
Импорт файлов MS Project |
+ |
|
15 |
Пул ресурсов |
- |
«Мегаплан» не полностью соответствует требованиям «КонсОМ СКС». Система поддерживает возможность формирования нескольких проектов, но в ней отсутствует пул ресурсов.
Wrike
Онлайн-инструмент для управления проектами и командной работы. Он позволяет пользователям планировать проекты, приоритизировать задачи и следить за графиком их выполнения, а также совместно работать со своими коллегами в режиме онлайн [56].
Достоинства и недостатки Wrike приведены в таблице 31
Таблица 31 - Достоинства и недостатки Wrike
Достоинства |
Недостатки |
|
Удобный, интуитивно понятный инструмент для создания планов нескольких одновременно идущих проектов. |
Могут потребовать изменения уже используемых методов выполнения проектов и замены используемого инструментария. |
|
Подходит для использования в географически распределённых организациях. |
||
Достоинства |
Недостатки |
|
Поддерживает облачные вычисления. |
||
Приложение доступно для iPhone, Android и планшетников. |
Рисунок 25 - Загрузка пользователей в Wrike
Соответствие системы Wrike требованиям «КонсОМ СКС» (таблица 32).
Таблица 32 - Соответствие Wrike критериям «КонсОМ СКС»
№п/п |
Критерий |
Соответствие |
|
1 |
Возможность формирования нескольких проектов |
+ |
|
2 |
Многопользовательское управление |
+ |
|
3 |
Многоязычность |
+ |
|
4 |
Конвертация валют |
- |
|
5 |
Отсутствие ограничений |
+ |
|
6 |
Таблица затрат |
+ |
|
7 |
Формирование отчетов |
+ |
|
8 |
Отслеживание |
+ |
|
9 |
Документооборот |
+ |
|
10 |
Коммуникации. |
+ |
|
11 |
Кроссбраузерность |
+ |
|
12 |
Интеграция с мобильными устройствами |
+ |
|
13 |
Авторизация с помощью клиентских SSL сертификатов |
- |
|
14 |
Импорт файлов MS Project |
+ |
|
15 |
Пул ресурсов |
+ |
В система «Wrike» присутствует пул ресурсов, по которому можно отслеживать загруженность ресурсов у нескольких проектов.
После анализ SaaS-систем по управлению проектами, которые поддерживают возможность формирования нескольких проектов, было принято решение о выборе системы.
Система, которая в большей степени соответствует потребностям ЗАО «КонсОМ СКС» является «Wrike». Схема работы с данным программным средством представлена в приложении 5.
В системе есть возможность создания пула ресурсов. На рисунке 26 показано совместное использование ресурсов нескольких проектов, где оранжевым выделена перегруженность.
Рисунок 26 - Перегруженность ресурсов
К задачам можно прикреплять документы, и ограничивать доступ к ним. В таком случае документы будут видны только тем ресурсам, которые используются в задаче (рисунок 27).
Рисунок 27 - Прикрепление файла
Есть возможность импортирования файлов формата .mpp - формат MS Project (рисунок 28). Импорт составляет не более 30 секунд. Это позволит перенести проекты в систему, при необходимости.
Рисунок 28 - Импортирование файлов MS Project
Система поддерживает кроссбраузерность и доступ через мобильные устройства, но в системе отсутствует конвертация валют и авторизация с помощью клиентских SSL сертификатов.
Таким образом, SaaS-система «Wrike» соответствует 13 выдвинутым критериям из 15. Два не соответствующих критерия: «Конвертация валют» и «Авторизация с помощью клиентских SSL сертификатов», по результатам экспертных оценок, имеют не высокую приоритетность. Поэтому было принято решение о внедрении этой системы.
2.4 Рекомендации по эксплуатированию системы
Участники и их роли
Участники системы, их компетентность и роли представлены в таблице 33.
Таблица 33 - Участники, компетентность и роли в ИСУП
№ |
Должность |
Компетентность |
Роль в системе |
|
1 |
Руководитель отдела |
Отвечает за организацию работы в системе; руководитель ОПУ несет ответственность перед генеральным директором за результаты деятельности; руководитель принимает оперативные решения. |
Администратор |
|
2 |
Аналитики |
Основной задачей аналитиков является мониторинг программы проектов, на основании данных которого принимаются |
Пользователь, занимающийся мониторингом ресур- |
|
№ |
Должность |
Компетентность |
Роль в системе |
|
предварительные управленческие решения, касающихся приоритета проекта, распределения ресурсов и судьбы проекта. |
сов и финансов |
|||
3 |
Финансистконтроллер |
Это специалист, который должен следить, чтобы при постановке целей, планировании и принятии решений менеджером прибыль была достаточной. Включая: процент оставшегося резерва; прогнозирование инфляции; совет по перераспределению денежных средств; изменения со стороны законодательства. |
Пользователь, занимающийся мониторингом финансовой стороны программы |
|
4 |
Риск-менеджер |
Риск-менеджер должен обнаруживать в ежедневной работе программы всевозможные риски, оценивать и снижать их негативные последствия. |
Пользователь, занимающийся мо-ниторингом рисков программы |
|
5 |
Менеджер проекта |
Несет ответственность перед руководителем отдела проектного управления за результат исполнения проекта |
Пользователь, с определенными правами, который отвечает за реализацию своего единичного проекта |
|
6 |
Проектная группа |
Временная структура, которая формируется на этапе инициации проекта и является координирующим центром управления отдельным проектом. |
Пользователиресурсы |
|
7 |
Стейкхолдеры |
Заинтересованные лица в реализациипрограммы или отдельно взятого проекта |
Гости, которым виден лишь ход отслеживания |
На рисунке 29 представлена общая схема взаимодействия между участниками.
Рисунок 29 - Смеха взаимодействия между участниками
Права доступа в системе приведены в таблице 34.
Таблица 34 - Матрица ответственности
№ |
Наименование |
Вид |
Описание |
Примечание |
|
1 |
Пользователи |
Внешние |
Могут просматривать задачи и отмечать их как завершенные, добавлять комментарии и прикреплять файлы, но видят контакты только тех пользователей, с которыми у них есть общий доступ к задачам и папкам. |
Могут видеть комментарии, прикрепленные файлы, задачи и изменения лишь у тех проектов, на которые они назначены. |
|
Обычный |
|||||
Администратор |
Может приглашать и удалять пользователей, предоставлять и отменять права администратору. Может устанавливать рабочие дни для пользователей аккаунта, редактировать имя аккаунта и создавать резервную копию информации, хранящейся в аккаунте. |
Может видеть все комментарии, прикрепленные файлы, задачи и изменения.Польный доступ. |
|||
2 |
Дополнительный пользова-тель |
Обычный |
Могут просматривать задачи и отмечать их как завершенные, добавлять комментарии и прикреплять файлы, но видят контакты только тех пользователей, с которыми у них есть общий доступ к задачам и папкам. |
Могут видеть комментарии, прикрепленные файлы, задачи и изменения лишь у тех проектов, на которые они назначены. |
В качестве обеспечения безопасности данных, в системе регистрация пользователей проходит путем приглашения через электронную почту (рисунок 30). Ресурс не будет добавлен в систему до тех пор, пока он не пройдет по ссылке в предложенном в письме. В случае, если права пользователя были изменены, его автоматически информируют об этом.
По схеме функционирования предложенной системы «Wrike» (приложение 5) составим матрицу ответственности участников ИСУП (таблица 35).
Рисунок 30 - Приглашение пользователя в систему
Таблица 35 - Матрица ответственности
№ |
Функция |
Размещено на http://www.allbest.ru/
4
2
Размещено на http://www.allbest.ru/
4
2
Размещено на http://www.allbest.ru/
4
2
Размещено на http://www.allbest.ru/
4
2
Размещено на http://www.allbest.ru/
4
2
Размещено на http://www.allbest.ru/
4
2
1 |
Сбор данных |
И |
- |
- |
- |
О |
У |
|
2 |
Регистрация проекта |
О |
И |
И |
И |
И |
И |
|
3 |
Указание приоритета проекта |
О |
- |
- |
- |
У |
И |
|
4 |
Расстановка задач |
О |
У |
У |
У |
И |
И |
|
5 |
Регистрация ресурса |
О |
- |
- |
- |
И |
И |
|
6 |
Выбор ресурса |
О |
- |
- |
- |
- |
И |
|
7 |
Ввод данных по проекту |
О |
У |
У |
У |
И |
И |
|
8 |
Мониторинг проектов |
О |
У |
У |
У |
У |
И |
где: О -- ответственный, И -- информируется, У -- участвует.
Проекты
Регистрация проекта в системе:
1. Менеджер проекта согласовывает «Устав проекта» со всеми заинтересованными сторонами.
2. Руководитель отдела проектного управления регистрирует проект в системе и указывает его приоритет.
3. По «Уставу» руководитель проектного отдела расстанавливает задачи и длительность.
4. Руководитель проектного отдела назначает ресурсы на задачи и указывает их загруженность.
Примечание:
1. Пересмотр приоритетов проектов должен происходить 1 раз в месяц. В некоторых случаях можно пересматривать чаще.
2. Пересмотр всех проектов в программе должен производиться не реже 4 раз в год, т.е. 1 раз в квартал. Как показала практика, многие приоритетные ИТ-проекты со временем теряют свою важность, но при этом удерживают статус «важного» проекта.
Задачи
Менеджер проекта должен согласовать задачи со всеми заинтересованными сторонами, в том числе с генеральным директором и руководителем проектного отдела.
Примечание:
1. Мониторинг выполнения задач должен происходить ежедневно.
2. Редактировать задачи может менеджер и руководитель проектного управления. Ресурсы
Руководитель отдела проектного управления после расстановки задач выбирает и назначает на них ресурсы.
Примечание:
1. Мониторинг ресурсов необходимо производить ежедневно.
2. Перераспределять ресурсы на задачи необходимо по результатам мониторинга, когда определяется их перегруженность.
Отчетность
Отчеты по реализации должны предоставляться не реже 2 раз в месяц (каждые 2 недели). В некоторых случаях можно предоставлять чаще.
Примечание:
1. Отчеты в системе доступны лишь администратору - руководителю отдела проектного управления.
Разногласия
? если между менеджерами проектов возникают разногласия на момент планирования, то им необходимо обратиться к руководителю отдела проектного управления. После обсуждения руководитель ОПУ примет управленческое решение;
? при решении судьбы проекта созывается совет, состоящий из отдела проектного управления, менеджера и генерального директора, по окончанию которого принимается управленческое решение.
Примечание по проектам:
ИТ-отдел рекомендует производить резервное копирование каждую неделю. В системе это возможно путем экспорта программы.
Вывод по главе 2
Результаты проведенного нами анализа позволяют сделать некоторые выводы, представляющие интерес для нашего исследования: компания разрабатывает и внедряет комплексные интеграционные решения для автоматизации промышленных предприятий, крупных государственных структур и банков. Является ведущим системным интегратором на Южном Урале в области построения, модернизации информационной инфраструктуры и реализации информационных систем предприятий, начиная с уровня первичного сбора данных и заканчивая уровнем управления предприятием.
Анализ финансовой устойчивости предприятия позволяет сделать вывод о том, что на данный момент ЗАО «КонсОМ СКС» является финансово устойчивой организацией. Об этом свидетельствует ее способность своевременно выполнять свои внутренние и внешние обязательства, финансировать свою деятельность на расширенной основе и поддерживать свою платежеспособность в любых обстоятельствах.
Проанализировав проектную деятельности ЗАО «КонсОМ СКС» можно сказать, что программа проектов включает в себя крупномасштабные, затратные, долгосрочные и сложные проекты. Управлять такими проектами трудно, так как они ориентированы на достижение конкретной цели и даже небольшие отклонения в ходе реализации могут привести к их срыву. Нами были выделены следующие узкие места:
? на данный момент организация ведет программу проектов по стандарту PMBOK, который ориентирован на управление единичными проектами, а не программой в целом;
? в организации имеются недостатки в управлении проектами, выявленные по результатам общения с генеральным директором;
? организация не имеет механизмов оптимизирующих проектную деятельность.
Как попытки преодолеть недостатки в проектного менеджмента в организации, наметились несколько направлений в поисках путей совершенствования: нами были проанализированы методы управления программами проектов, рассмотрены имеющиеся системы ведения проектов и в результате были разработаны механизмы оптимизации проектной деятельности организации:
1. Организационный механизм.
2. Технологический механизм.
В процессе внедрения комплекса механизмов необходимо учесть специфику организации и опыт ведущих мировых специалистов в области управления проектами.
Организационный механизм - комплекс мер по модернизации организационной структуры. Нами было принято решение в создании нового отдела в организации, который занимается ведением программы проектами - «Отдел проектного управления», где каждый сотрудник отвечает за определенные функции. Это не команда проекта, что подразумевает собой временное объединение людей, которые регулярно взаимодействуют друг с другом для достижения определенной цели единичного проекта. Это постояннофункционирующий отдел, который занимается отслеживанием программ проектов и направленный на их поддержание.
«Отдел проектного управления» позволит организации достичь следующих преимуществ в управлении проектами.
1. Отдел должен содействовать доведению до стадии завершения большего числа проектов без привлечения дополнительных ресурсов (количество завершенных проектов должно возрасти на 50%).
2. Большинство проектов должно завершаться в заметно сокращенные сроки (отдел должен обеспечивать сокращение средней продолжительности выполнения проектов на 25%).
3. ОПУ должен ощутимо и положительно влиять на практические результаты деятельности организаций, причем даже некоммерческих.
Технологический механизм - стандарт и система управления программами проектов.
Проанализировав существующие стандарты и системы удаленного управления программами проектов нами было принято решение о внедрении следующих компонент:
? стандарт для управления программой проектов «The Standard For
Portfolio management», подходящий под специфику организации;
? система на облачных технологиях «Wrike», отражающая требования организации.
Применение механизмов позволит «КонсОМ СКС» оптимизировать процесс управления проектами.
Глава 3. Комплексная оценка эффективности системы
3.1 Выбор методики расчета экономических и других эффектов
Для того чтобы определить эффективность внедренной системы «Wrike», рассмотрим несколько способ, предложенные Департаментом Системы Управления Проектами «ЛАНИТ».
Эффективность - свойство системы, характеризующее ее способность выполнять задачи по назначению. Эффективность системы - это свойство системы выполнять поставленную цель в заданных условиях использования и с определенным качеством. Показатели эффективности характеризуют степень приспособленности системы к выполнению поставленных перед ней задач и являются обобщающими показателями оптимальности функционирования ИС. Экономические показатели внедренной системы - это стоимость создания или приобретения системы, затраты на ее внедрение и эксплуатацию, а также эффект, получаемый от функционирования системы.
При оценке эффективности использования информационной системы управления проектами необходимо рассматривать обширный набор аспектов-критериев. Существуют различные подходы к оценке эффективности использования ИСУП (Project Management Value), основывающиеся на методиках различных организаций (как коммерческих, так и независимых научных), оптимизированных для использования в разных областях хозяйственной деятельности.
Оценка эффективности основывается на определении, выборе критериев для рассмотрения и оценки системы по этим качествам. Набор критериев может зависеть от сферы деятельности организации, характеристики проектов и состава системы.
Критерии, показатели и оценки можно условно разделить на две группы: качественные и количественные. Количественные оценки дают легко осязаемый, наглядный показатель эффективности, однако не всегда дают полное представление о всех преимуществах использования ИСУП. При оценке эффективности необходимо рассматривать набор показателей по различным аспектам проектной деятельности, таким как финансовые, временные, методологические, организационные и др.
Одна из методологий качественной оценки эффективности основана на экспертной оценке Критических факторов успеха (КФУ), выполнение которых необходимо для успешной реализации проекта.
Подобные документы
Описание структуры управления компании. Структура программно-аппаратных средств. Анализ технического задания. Расчет обобщенного критерия эффективности информационной системы ведения проектов строительной компании. Выбор языка программирования и СУБД.
дипломная работа [2,1 M], добавлен 29.06.2013Определение критериев для сравнения методик управления требованиями. Особенности создания заказного программного обеспечения. Разработка показателей эффективности процессов управления требованиями. Оценка текущих процессов реализации проектов компании.
дипломная работа [1,7 M], добавлен 31.10.2016Функциональное назначение системного, прикладного и инструментального программного обеспечения компьютера. Характеристика состава и командного языка операционной системы MS DOS. Интерфейс и структура окон в Windows 98; методы управления программами.
реферат [41,2 K], добавлен 18.12.2011Основные методологии адаптивных жизненных циклов IT-проектов. Внедрение системы автоматизации маркетинга Marketo для управления отношениями с клиентами торгового предприятия "Spirit". Доработка корпоративного сайта компании для учета данных о клиентах.
дипломная работа [1,4 M], добавлен 28.08.2016Возможности создания визитной карточки программами Microsoft Word 2003 и Microsoft Publisher 2003. Требования к оформлению визитной карточки. Основные версии возникновения визитной карточки. Выбор оптимального дизайна и форматирование визитной карточки.
курсовая работа [627,1 K], добавлен 06.03.2012Анализ проектной деятельности Администрации губернатора Пермского края. Программное обеспечение процессов управления государственными программами, роли и функции участников. Требования к информационной системе и средствам моделирования бизнес-процессов.
дипломная работа [2,9 M], добавлен 30.06.2017Основные понятия электронно-вычислительных сетей. Стандарты проектного управления. Электронный проектный офис как система поддержки принятия решений. SaaS-приложения для управления проектами. Факторы, воздействующие на оператора ПК. Диаграмма базы данных.
дипломная работа [1,5 M], добавлен 15.10.2013Подготовка к созданию интеллектуальной системы: определение проблемы, поиск эксперта, анализ расходов и прибыли. Стадии разработки прототипной системы, ее развитие до промышленной экспертной системы (ЭС). Оценка, стыковка с программами и поддержка ЭС.
презентация [79,0 K], добавлен 03.01.2014Внедрение системы управления проектами Microsoft Project 2003 в Московский институт экономики, менеджмента и права для автоматизации учета выполнения дипломных проектов. Сравнительная характеристика систем управления проектами в России и за рубежом.
дипломная работа [1,4 M], добавлен 25.10.2013История возникновения облачных технологий. Суть и задачи облачных технологий, их классификация, достоинства и недостатки. Исследование применения облачных технологий на примере Google диск. Сравнение Google диск с аналогом компании Apple(iCloud).
курсовая работа [573,1 K], добавлен 05.12.2016