ЗараменскихУЖЦИСмонография-148-272. Управление жизненным циклом информационных систем
 Скачать 3.15 Mb.
|
|
ПРИМЕР PMBoK рассматривает следующие процессы исполнения: ‒ Руководство и управление исполнением процесса. ‒ Подтверждение качества. ‒ Набор команды проекта. ‒ Развитие команды проекта. ‒ Управление команды проекта. ‒ Распространение информации. ‒ Управление ожиданиями заинтересованных сторон. ‒ Осуществление закупок ‒ Мониторинг и управление. ‒ Завершение проекта. При дальнейшей детализации могут становиться основой любых отрас- левых стандартов и в целом являются достаточно универсальными. Более интересны выделяемые PMBoK области знаний: ‒ управление интеграцией; ‒ управление содержанием; ‒ управление сроками; ‒ управление стоимостью; ‒ управление качеством; ‒ управление человеческими ресурсами; ‒ управление коммуникациями; ‒ управление рисками проекта; ‒ управление поставками; ‒ управление стейкхолдерами (область знаний, появившаяся только в 5-й версии PMBoK, опубликованной в 2013 году). УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 155 Этим областям знаний посвящены соответствующие разделы и для ка- ждой из них предлагается ряд активностей, методик, инструментов и других видов знаний, зарекомендовавших себя на практике. Рассмотрим пример структуры и содержания PMBoK на примере об- ласти знаний «Управление содержанием». По структуре остальные главы PMBoK аналогичны. ПРИМЕР 1. В первую очередь, PMBoK дает определение области знаний. «Управление содержанием проекта» включает в себя процессы, обеспечивающие включение в проект тех и только тех работ, которые необходимы для успешного завер- шения проекта. Управление содержанием проекта непосредственно связано с определением и контролем того, что включено и что не включено в проект» (PMBoK v4). 2. Приводится общая схема области знаний. На ней указываются все основные процессы, а также относящиеся к каждому из них «Входы», «Инструменты и методы», а также «Выходы». «Входы» обозначают необходимую для исполнения процесса информацию (на- пример, «Реестр заинтересованных сторон», на основании которого определя- ются основные лица, для которых организуется сбор требований). ГЛАВА 3. Особенности управления проектами по внедрению КИС 156 «Инструменты и методы» – основные активности и методы их осуществле- ния (семинары, анкеты, групповые творческие методы», при помощи которых определяются содержание и иерархическая структура работ). «Выходы» – ключевые результаты процесса (например, «документация по тре- бованиям» и «матрица отслеживания требований», сформированная на осно- вании осуществленных в ходе процесса активностей). Всего в данной области знаний выделяется пять групп активностей: «Сбор требований», «Определение содержания», «Содержание иерархической струк- туры работ», «Подтверждение содержания», «Управление содержанием». 3. Рассмотрим один из процессов выбранной области знанийподробнее. На этапе сбора требований в числе прочих предлагаются групповые творческие методы (пп. 4): мозговой штурм, метод номинальных групп (мозговой штурм го- лосование), метод Дельфи (ответы на анкету группы экспертов в течение не- скольких раундов), интеллект-карты (выявление сходств и различий в понимании среди идей мозгового штурма), диаграммы сходства (группировка идей). Для ка- ждого из этих методов приводятся формулы и инструкции по применению. PMBoK приводит также подробные описания процессов и формируе- мых в процессе работы с ними документов / результатов. ПРИМЕР Образец организованной по фазам иерархической структуры работ. УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 157 Каждая вновь издаваемая версия PMBoK учитывает наиболее важные тенденции опыта управления проектами. Пятая версия (изданная в 2013 го- ду) также содержит несколько нововведений: например, к ним относятся четыре новых процесса планирования (содержанием, расписанием, стоимо- стью и заинтересованными сторонами), которые развивают концепцию формирования плана управления проектом из нескольких вспомогательных планов. Также в ней произведены изменения содержания некоторых групп процессов и даже добавлена одна новая область знаний («управление заин- тересованными лицами»), по сути частично основанная на управлении ком- муникациями (концентрирующейся теперь исключительно на взаимодейст- вии внутри проектной команды). Однако несмотря на всю свою распространенность, PMBoK не является единственной доступной методологией и для предметной области ИТ-про- ектов применяются также PRINCE2, MSF, RUP и многие другие. Они могут оперировать такими параметрами, как число стадий и областей знаний, роли и процедуры управления в проектах, варьируя их в различной степени. ПРИМЕР В PMBoK критериями успешности можно считать соответствие треугольнику ограничений – составу работ, срокам, стоимости, а также качеству. PRINCE2 предлагает для оценки проекта фокусироваться на аспектах финансовой ус- пешности, положительном мнении конечного пользователя и косвенной пользе для исполнителя (три перспективы: заказчик, исполнитель и пользователь). В то же время SCRUM, будучи еще более ориентированным на заказчика, рас- сматривает единственный фактор: удовлетворенность клиента полученными результатами (проект успешен, если заказчик готов продолжать сотрудниче- ство с исполнителем и / или рекомендовать его другим). Переходя от эталонных рекомендаций PMBoK к более практической стороне управления проектами внедрения, отметим ряд особенностей/ принципов. ‒ Этапность. Масштабные проекты разбивается на этапы (подэтапы), продолжитель- ность выполнения которых не должна превышать 2-3 месяцев и суть кото- рых не обязательно должно однозначно соответствовать фазам жизненного цикла ИС. Более важно, что каждый этап работ должен иметь законченный результат, полезный для предприятия, независимо от хода и результата вы- полнения всего проекта. На каждом этапе проводятся работы, необходимые, в том числе, для реализации последующих этапов, однако некоторые из них должны выполняться строго последовательно, в то время как другие воз- можно реализовывать параллельно. Процесс планирования возможно осу- ществлять встроенными средствами MS Project либо любыми другими ин- струментами автоматизированного управления проектами и потоками работ. Это важно для поддержки таких активностей, как оперативный контроль ГЛАВА 3. Особенности управления проектами по внедрению КИС 158 хода выполнения проекта, оценка потребных ресурсов (человеческих, мате- риальных, временных и т.д.). ‒ Результативность. Каждый этап проекта характеризуется наличием ясно определяемых и оцениваемых результатов. Критерии оценки результатов определяются при планировании проекта. Если общий процесс внедрения занимает более по- лутора лет, проект планируется таким образом, чтобы первые результаты были получены уже через 5-7 месяцев после его начала. Это дает дополни- тельную мотивацию сотрудникам предприятия, которые видят конкретные результаты проекта. Внедрение выполняется помодульно и начинается с тех модулей, функционирование которых необходимо для внедрения других модулей (либо с тех, которые способны достаточно быстро принести реаль- ную отдачу). ‒ Постоянный контроль. Необходимо постоянно держать под контролем как сам процесс выпол- нения работ, так и достижение целей их выполнения. По окончании каждого этапа или подэтапа осуществляется анализ степени изменения внешних и внутренних факторов проекта и определяется необходимость корректиров- ки дальнейших планов. Контроль проводится посредством составления и анализа Графика выполнения работ по внедрению системы, а также перио- дических отчетов должностных лиц проекта на каждом его этапе. ‒ Сквозное документирование проекта. Все результаты выполняемых работ, а также возникающие в процессе работы дополнения, замечания, разногласия, предложения в обязательном порядке оформляются соответствующими документами, причем помимо их согласования / утверждения даже получение пакета документов должно фик- сироваться подписью ответственного лица. ‒ Активное вовлечение заказчика в проект внедрения. Как уже обсуждалось в предыдущем разделе, группа внедрения от за- казчика должна формироваться из руководителей среднего звена и ключе- вых специалистов предприятия. Функции специалистов группы внедрения от заказчика и команды подрядчика определяются при планировании проек- та и в дальнейшем могут корректироваться в начале работ по каждому этапу проекта. Без активного участия специалистов заказчика в процессе внедрения успешная реализация проекта внедрения практически невозможна. Работа консультантов подрядчика и сотрудников заказчика в одной команде значи- тельно повышает эффективность проекта внедрения системы. Для успеха проекта в целом группе внедрения необходимы общее видение проблемы, нацеленность на один и тот же положительный результат, заинтересован- ность каждого и группы в целом в достижении этого результата. УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 159 3.4.1.3. PRINCE2 Методология управления программами / проектами в организации PRINCE2 (PRojects IN Controlled Environments) – методология, концентрирующаяся на органи- зации, менеджменте и мониторинге хода ИТ-проектов с точки зрения продукта. Окружение методологии PRINCE2 состоит из трех основных типов элементов: 7 принципов, 7 тем (далее – элементов) и 7 процессов (для каж- дого из которых определяются входные и выходные объекты, цели и ключе- вые активности). Принципы PRINCE2, будучи процессно-ориентированной методологией проектно- го управления, базируется на семи основных принципах. Постоянное бизнес- обоснование Каждый проект должен быть целесообразен и обоснован с точки зрения соотношения затрат / выгод его реализации Обучение на собствен- ном опыте Проектные команды должны непрерывно обучаться, анализировать опыт предыдущих проектов (основные проблемы, риски, преимущества) и де- литься выводами Определение ролей и ответственности Организационная структура должна учитывать закрепление ответствен- ности за членами проектной команды в части учета интересов всех сто- рон: бизнес-заказчиков, пользователей, поставщиков / потребителей Управление по стадиям Планирование, мониторинг и контроль проектов на каждом этапе Управление исключе- ниями Для каждого проекта определены конкретные критические значения по- казателей и уровни / механизмы эскалации возникающих проблем Фокус на продуктах Определение требований к качеству результатов проекта и их характе- ристик Адаптация к условиям конкретного проекта Адаптация методологии в зависимости от масштабов / сложности / важ- ности / окружения конкретного проекта ГЛАВА 3. Особенности управления проектами по внедрению КИС 160 Роль проектной команды в данном случае может быть описана пятью ключевыми активностями: ‒ Адаптация семи элементов PRINCE2 к условиям проекта. ‒ Применение / адаптация специфической терминологии. ‒ Адаптация описаний продукта к условиям проекта. ‒ Адаптация описаний ролей в соответствии с PRINCE2. ‒ Адаптация процессов для соответствия вышеописанным принципам. Все эти активности и их особенности подробно описываются в тексте методологии. Элементы 1. Бизнес-кейс (Обоснование проекта) = «Почему?». Основная цель создания подобного бизнес-кейса состоит в создании механизмов оценки целесообразности (и возможности) реализации проекта. Этап инициализации Этап создания Завершающий этап Пре- проект Завершающий этап Разработка обоснования Реализация обоснования Проверка обновленного обоснования Проверка детального обоснования Проверка плана обоснования Подтверждение выгод Подтверждение выгод Подтверждение выгод 2. Организация = «Кто?». Определение и создание проектной структуры ответственности. 3. Качество = «Что?». Определение методов создания качественного продукта (включая аспект контроля качества). 4. Риск = «Что если?». Определение, оценка и контроль всех рисков. 5. Планы = «Как? Сколько? Когда?». Определение способов создания / распространения продуктов, прогно- зирование динамики спроса. 6. Изменения = «Какое влияние?». Определение эффекта от внедрения одобренных изменений проекта. 7. Прогресс = «Где мы сейчас? Куда направляемся?». Создание механизмов мониторинга и оценка реальных достижений для планирования целей проекта, в том числе ответ на вопрос «Стоит ли про- должать двигаться в выбранном направлении?». УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 161 Процессы И наконец, PRINCE2 предлагает собственную карту процессов управ- ления проектом. Руководство Управление Создание Запуск проекта Управление границами проекта Инициализация проекта Управление созданием продукта Управление созданием продукта Управление этапом Управление этапом Управление границами проекта Закрытие проекта Руководство проектом Этап инициализации Этап создания Завершающий этап Пре-проект Рассмотрим каждый из процессов подробнее. Запуск проекта Обоснование основных причин осуществления проекта, его задач и ожидаемого результата, при этом запуск проекта должен осуществ- ляться в очень короткие сроки Навигация проекта Координация проекта, определение ролей команды проекта, создание плана этапов Инициация проекта Обоснование необходимости проекта (например, технико-экономи- ческое обоснование), планирование ресурсов Управление границами этапа Мониторинг выполнения планами/ результатами, контроль ключевых показателей проекта, предоставление информации спонсорам / заказ- чикам проекта (управление коммуникациями) Контроль этапа Мониторинг и контроль, осуществляющийся лидером проекта (опре- деление подлежащих решению задач, сбора информации, предостав- ление отчетов, принятие необходимых корректирующих действий. Управление созданием продукта Обеспечение создания требуемых в ходе проекта продуктов Завершение проекта Обеспечение контролируемости стадии завершения проекта, контроль соответствия результатов документированным положениям при ини- циации проекта, подготовка финальных отчетов, обеспечение после- дующей поддержки и обучения Таким образом, PRINCE2 является достаточно гибким руководством проектного управления, которое обеспечивает четкую структуру, предос- ГЛАВА 3. Особенности управления проектами по внедрению КИС 162 тавляет общие методы и терминологию проектного управления. Методоло- гия PRINCE2 может быть адаптирована для любого типа проектов, индуст- рий. И наконец, возможность дополнительно получить сертификацию своих знаний по PRINCE2 делает ее популярной среди консультантов и компаний- подрядчиков. 3.4.1.4. ISO 21500:2012 Международный стандарт: ISO 21500 Guidance on project management. Российский аналог: Международный стандарт по Управлению Проектами. ISO 21500:2012 изначально создавался как стандарт, регламенти- рующий проектное управление на международном уровне. Разработка стандарта велась силами трех рабочих групп, ответственных за раз- личные направления: ‒ Разработка терминологии. ‒ Регламентация процессов управления проектами. ‒ Определение и описание в приложениях ключевых концепций про- ектного менеджмента. Один из самых «молодых» стандартов, он во многом схож с PMBOK, но уже за первые же годы использования стал достаточно популярен. В ISO 21500:2012 приведены описания понятий и процессов, форми- рующих управление проектами, однако детального руководства не приво- дится. Сам документ предназначен в первую очередь для топ-менеджеров и спонсоров проекта, а также менеджеру проекта и проектной команды. Бла- годаря ISO 21500 они получают знания о принципах и практиках управле- ния проектами, а также некое эталонное представление об актуальных прак- тиках управления. Структура ISO 21500 приведена ниже: 1. Общие положения. 2. Термины и определения (в т.ч. «операция», «запрос на измене- ния», «критический путь», «лаг», «лид», «кривая обучения», «сло- варь ИСР» и пр.). 3. Концепция управления проектами. Например, общий обзор, среда проекта (в т.ч. программы и портфели проектов), внешнее руководство проекта, заинтересованные стороны, ком- петенции участников проекта, ограничения проекта. ПРИМЕР Схема заинтересованных сторон проекта. УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 163 Деловые партнеры Руководство проектом Спонсор проекта Руководитель проекта Команда управления проектом Команда проекта Организационная структура проекта Сотрудники Акционеры Поставщики Финансовые организации Пользователи Проектный офис Специальные группы Общественность 4. Процессы управления проектами. Процессы управления проек- тами рассматриваются с двух ракурсов: с точки зрения управления проектом как групп процессов (применимых к конкретным фазам или проекту в целом), а также с точки зрения группировки процес- сов по предметным областям. Предметные области состоят из про- цессов, которые могут относиться к любой фазе проекта и не зави- сят от отрасли / специфики. Соответствие процессов управления проектами группам процессов и предметным группам приведено в Приложении. Схема взаимодействия группа процессов с основными входами и выхо- дами приведена в Приложении. |