Пример процедурыкорректировки фактического выполнения плана работ 4 страница

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

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

7. Руководители проекта получают данные о фактической стоимости проекта и обновленную диаграмму календарно-стоимостного планирования. В течение 0,5 дня руководитель проекта со стороны заказчика производит сравнение значения диаграммы календарно-стоимостного планирования с базовым планом по стоимости и с базовым планом управления расписанием проекта. Руководитель проекта со стороны заказчика производит расчет ключевых величин освоенного объема (EV, PV, AC) и коэффициентов (CV, SV, EAC), заносит значения в реестр освоенного объема и информирует руководителя проекта со стороны исполнителя;

8. В случае если значение CV или SV демонстрирует отклонение в одном и том же направлении свыше 10% в течение 3 отчетных периодов, руководители проекта на отчетном совещании информируют об этом спонсора проекта и управляющий орган проекта.

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

10. Решение об использовании резерва на непредвиденные обстоятельства принимается спонсором проекта.

11. Решение об использовании управленческого резерва принимается управляющим органом проекта.

12. Диаграмма календарно-стоимостного отслеживания проекта отражается в информационной системе управления проектами. Реестр освоенного объема ведется в электронных таблицах MS Excel.

12.5. Контроль качества проекта

На стадии контроля каждой стадии ЖЦ ИТ выполняются мониторинг, контроль и формирование отчетности о соответствующем этапе проекта.

Целями этапа являются [22]:

· осуществление контроля качества работ и результатов этапа;

· мониторинг состояния выполнения этапа, выявление отклонений и корректировка плана качества с целью устранения отклонений;

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

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

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

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

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

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

Таблица 11.5. Пример формы сводной таблицы сценариев тестирования
№	Наименование сценария	Описание сценария	Дата, время	Тестировщик	Приемщик	Успешно (да/нет)	Примечания
.
Комментарий к форме 1. №: Номер сценария тестирования бизнес-процесса. 2. Наименование сценария:Короткое наименование сценария тестирования бизнес-процесса. 3. Описание сценария:Описание сценария тестирования бизнес-процесса. 4. Дата, время:Дата и время проведения тестирования. 5. Тестировщик:Консультант от исполнителя, участвующий в тестировании. 6. Приемщик:Сотрудник функциональной группы от заказчика, участвующий в тестировании. 7. Успешно? (да/нет):Отметка об успешности прохождения сценария тестирования. 8. Примечания:Дополнительные пояснения к результатам сценария

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

Ошибки, выявленные при тестировании, фиксируют в специальном журнале. Пример формы журнала ошибок представлен в табл. 11.6.

Контроль качества обеспечивается руководителем проекта, менеджером по качеству, командой проекта. В табл. 11.7 собраны функции участников процесса контроля [22].

12.6. Контроль рисков проекта

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

Мониторинг рисков выполняется с помощью следующих методов.

1. Пересмотр рисков

Таблица 11.6. Пример формы журнала ошибок
Наиме-нование сценария	№ шага тестирования	Шаг процесса	Модуль	Описа- ние ошибки	Решение	Ответственный	Наме-ченнаядата
.
.
.
Комментарий к форме "Журнал ошибок" 1. Наименование сценария:Короткое наименование сценария тестирования бизнес-процесса. 2. № шага тестирования:Уникальный идентификатор шага тестирования в формате Z.P#.NN, где Z - номер сценария тестирования, Р# - 5-значный номер процесса и NN - уникальный 2-циферный код в рамках сценария. 3. Шаг процесса:Номер и наименование тестируемого шага бизнес-процесса. Номер шага бизнес процесса в формате P#.NN, где Р# - 5-значный номер процесса, и NN - уникальный 2-циферный код в рамках процесса. 4. Модуль: Модуль ИС, с использованием которого реализуется шаг бизнес-процесса. 5. Описание ошибки:подробное описание ошибки, выявленной в ходе тестирования, со ссылкой на файл, в котором находятся полные сведения об ошибке. 6. Решение:Планируемые мероприятия по устранению ошибки. 7. Ответственный:Сотрудник, назначенный ответственным за устранение ошибки в намеченный срок. 8. Намеченная дата:Планируемый срок устранения ошибки

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

o не выполняется процесс управления изменениями, в результате чего происходит "сползание" объема, или содержания, проекта;

o влияние спорных вопросов, изменений и проблем оценивается неадекватно;

Таблица 11.7. Функции участников команды проекта, обеспечивающих выполнение процесса контроля
Функция Результат выполнения функции
Руководитель проекта
Организация обзора результатов проекта и согласование выявленных замечаний	Обзор качества (результаты процесса обзора)
Организация аудита качества работ и согласование выявленных замечаний	Аудит качества (результаты процесса аудита)
Организация работы по сбору информации по показателям качества работ	Показатели качества (результаты процесса контроля показателей качества)
Менеджер по качеству
Анализ и согласование выявленных результатов	Обзор качества (результаты процесса обзора)
Анализ и утверждение результатов аудита	Аудит качества (результаты процесса аудита)
Анализ показателей качества	Показатели качества (результаты процесса контроля показателей качества)
Команда проекта
Участие в обзорах результатов проекта	Обзор качества (результаты процесса обзора)
Участие в проведении аудита качества работ, выполнении согласованных мероприятий	Аудит качества (результаты процесса аудита)
Участие в сборе информации по показателям качества работ.	Показатели качества (результаты процесса контроля показателей качества)

o обзоры состояния работ проводятся поверхностно и нерегулярно;

o стратегии по реагированию на риски не анализируют на предмет их эффективности;

o полученные результаты проекта не контролируются;

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

2. Аудит рисков

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

Таблица 11.8. Пример формы (интенсивного) мониторинга сотрудника
Тип риска	Описание риска	Проактивные мероприятия	Реактивные мероприятия	Пороговые состояния	Вероятность	Влияние	Фактор риска
Политический	Заказчик решил не внедрять систему	Плана нивелирования риска не существует. Заказчик решает либо внедрять систему, либо не внедрять	Если заказчик не представляет стратегической ценности для компании-исполнителя - не начинать проект
Политический	Ввиду того, что выбор системы (и подрядчика) проводился холдинговым руководством заказчика, сам заказчик на текущий момент не заинтересован в проекте и внедрении системы	0.. Проведение ряда заблаговременных семинаров, повышающих уровень заинтересованности заказчика во внедрении системы. 1. Организация референс-визи-тов к успешным клиентам. 2. Определение реальных лидеров в организации. Точечное повышение уровня их заинтересованности в успешном внедрении системы 3....	п/а
.

3. Анализ отклонений и трендов

Тренды в процессе выполнения проекта подлежат проверке с использованием данных о выполнении. Для мониторинга выполнения всего проекта применяют методику освоенного объема. Отклонения от базового плана могут указывать на вызванные рисками последствия.

4. Анализ резервов

При анализе резервов производится сравнение объема оставшихся резервов на непредвиденные обстоятельства с количеством оставшихся рисков.

5. Совещания по текущему состоянию

Периодические совещания команды проекта по вопросам управления рисками являются инструментом для отслеживания состояния рисков проекта.

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

Управление рисками на фазе проектирования производится аналогично управлению на предыдущей стадии.

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

13. Управление проектом в фазе разработки и внедрения

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

13.1. Детальное планирование стадии разработки и внедрения

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

· извещение менеджмента проекта, заказчика и персонал;

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

· документирование результатов процесса управления персоналом.

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

Для выполнения оценки работы персонала используют методики и процедуры, принятые компанией. Пример методики оценки персонала предложен В.Ильиным и изложен в книге "Руководство качеством проектов. Практический опыт " [13].

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

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

· принципы, методы урегулирования конфликтов и процедуры поощрения;

· специальные навыки и квалификацию определенных членов команды, обнаруженные в процессе исполнения проекта;

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

13.2. Подготовка инфраструктуры для фазы эксплуатации

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

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

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

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

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

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

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

13.3. Осуществление итогов контроля качества проекта

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

К задачам этого этапа относится:

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

· проведение аудита ключевых показателей.

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

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

13.4. Управление рисками настройки и внедрения

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

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

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

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

13.5. Подготовка к завершению проекта

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

1. извещение менеджмента проекта, заказчика и персонала.

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

2. подготовка оценки работы персонала.

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

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

o организационные диаграммы проекта, описания позиций и планы управления обеспечением проекта персоналом;

o принципы, методы урегулирования конфликтов и процедуры поощрения;

o специальные навыки и квалификацию определенных членов команды, обнаруженные в процессе исполнения проекта;

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

13.6. Организация тестирования

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

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

· Настройка рабочей среды.

· Настройка конфигурации (для системного тестирования).

· Настройка инфраструктуры, тестирование системы.

· Выполнение системного и пользовательского теста.

· Установка рабочей среды.

· Выполнение теста на запуск.

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

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

Согласно рекомендациям, типовой тестовый сценарий имеет следующую структуру и содержание.

1. Верхний колонтитул:

o заголовок тестового сценария;

o описание тестового сценария;

o цель выполнения данного тестового сценария;

o затрагиваемая функциональная область, процесс, организационная единица и роль;

o используемые системные транзакции;

o ожидаемая продолжительность выполнения тестового сценария и целевая продолжительность выполнения сценария в реальных условиях.

2. Содержание тестового сценария:

o пошаговая инструкция выполнения операций;

o ожидаемый результат выполнения каждой операции;

o комментарии тестера;

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

3. Нижний колонтитул:

o отметка о формальной приемке ("да"/ "нет");

o общие комментарии по исполнению сценария.

Реализация цикла тестирования

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

1. Функциональное тестирование

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

2. Первое интеграционное тестирование

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

3. Второе интеграционное тестирование

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

4. Первое пользовательское тестирование

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

o сформировать окончательное заключение о результатах;

o задокументировать все запросы на изменения;

o убедиться, что все тестовые сценарии утверждены;

o произвести окончательную оценку возможности перехода к продуктивной эксплуатации.

5. Окончательная настройка системы

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

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

Тестирование процессов, документов и отчетов

По ряду причин тестирование процессов следует реализовать отдельно.

· Возможность проверки шагов процесса на практике.

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

· Оценка готовности функционально-ориентированной организации осуществить переход к процессному управлению.

· Проверка целостности и непротиворечивости разработанных инструкций.

· Возможность протестировать новый процесс в пошаговом режиме.

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

Таблица 12.1. Шаблон документирования результатов процессного тестирования

Роли

Шаги процесса

Организационные единицы

...

...

...

...

...

...

...

...

...

...

...

...

...

.

.

.

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

· применимо (роль принимает участие в процессе);

· не применимо (роль не принимает участие в процессе).

В центральном столбце производится перечисление подпроцессов/шагов тестируемого процесса.

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

· сценарий тестирования пройден;

· сценарий тестирования пройден с обходным решением;

· выявлен дефект;

· сценарий тестирования неприменим;

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

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

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

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

13.7. Переход к продуктивной эксплуатации

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

Дата добавления: 2015-04-29