План управления изменениями

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

Процедуры управления изменениями Процедура управления изменениями

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

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

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

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

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

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

«Big&Co» в рамках данного проекта несет ответственность только за то, что явным образом описано в настоящем содержании проекта как задачи или ответственность компании «Big&Co».

Процедуры управления конфигурацией проекта

1. Идентификация объектов конфигурации

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

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

Каждому объекту конфигурации присваивается идентификационный номер ID. Схема наименования включает в себя следующие данные:

• Тип объекта

• Имя объекта

• Идентификация программы или проекта

• Номер версии

• Номер ревизии (ревизия для конкретной версии)

• Данные о готовности

2. Контроль конфигураций

В ответ на запросы членов команды проекта происходит передача последней конкретной версии того или иного объекта. Устаревшие версии архивируются.

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

3. Определение статуса конфигурации

Для определения статуса конфигурации автоматически генерируется отчет о статусе. Отчет включает в себя следующую информацию:

• время возникновения каждого изменения;

• время определения каждого объекта конфигурации;

• описательная информация о каждом объекте конфигурации;

• статус запросов на изменение (принят, отклонен, ожидает выполнения);

• описание статусов;

• описательная информация о каждом запросе на изменение;

• статус изменения;

• описательная информация о каждом изменении.

4. Аудит конфигураций

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

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

Форма отчета по результатам аудита конфигураций

Проведенные изменения	Спецификация изменений	Соответствие проведенных изменений спецификации	Объекты, связанные с изменением	Модифициро-ванные объекты	Модифицированы ли все связанные с изменением объекты конфигурации?
Рекомендации по устранению несоответствий
1.

Рекомендации по устранению несоответствий учитываются при проведении изменений.

Список использованной литературы

1. A Guide to Project Management Body of Knowledge, 4^th edition, American National Standard, ANSI/PMI 99-001-2008, 2008, pр. 495.

2. Chian-Son Yu, “Causes influencing the effectiveness of the post-implementation ERP system”, Industrial Management & Data Systems, Vol. 105 No. 1, 2005, pp. 115-132.

3. Deming W.E., Out of the Crisis, 2^nd edition, MI center for Advanced Engineering Study, Cmabridge, Massachusetts, 1986.

4. Esteves, J., Pastor, J. and Casanovas, J., “Organizational and technological critical success factors behavior along the ERP implementation phases”, International Journal of Technology and Human Interaction, Vol. 1 No. 4, 2005, pp. 1-16.

5. Galoppin L., Caems S. Managing Organizational Change during SAP Implementations – Bonn, Germany: SAP Press, 2007 – p.365.

6. Markus, M. L., Technochange management: Using IT to drive organizational change, Journal of Information Technology, 19, 2004, pp. 3-19.

7. Ward J., Daniel E., Peppard J., Building a better business case for IT investment // California Management Review, 2007, pp 78-97.

8. Арчибальд Р.Д., Управление высокотехнологичными программами и проектами – ДМК ПРЕСС, 2004 (перевод с англ. выполнен компанией АйТи). 698 стр.

9. Верзух Э., Управление проектами: ускоренный курс по программе MBA – Компьютерное издательство «Диалектика», 2008. 414 стр.

10. ГОСТ Р ИСО/МЭК 15288 —2005 Системная Инженерия. Процессы жизненного цикла систем.

11. Грекул В.И., Денищенко Г. Н., Коровкина Н.Л. Управление внедрением информационных систем – М.: Интернет-университет информационных технологий, 2008 – 223 стр.

12. Демарко Т., Листер Т., Человеческий фактор. Успешные проекты и команды – Символ-Плюс, 2005 г. 256 с.

13. Ильин В., Руководство качеством проектов. Практический опыт – Вершина, Санкт-Петербург, 2006.

14. Кале В., «Внедрение SAP R/3. Руководство для менеджеров и инженеров» – М.: «Компания АйТи», 2004 г., 470 стр.

15. Круглов М.Г., Козлов П.М., Управление качеством проектов корпоративных информационных систем. // Методы менеджмента качества. Режим доступа от 11 октября 2010 года: <http://www.stq.ru/riasite/index.phtml?page=18tbl=works&id=9>

16. Майстерс Д., Управление фирмой, оказывающей профессиональные услуги / – 223 с.

17. Методология Sure Step // Microsoft Corporation, 2010. Режим доступа от 11 октября 2010 года: <http://www.microsoft.com/rus/news/issues/2008/10/surestape.mspx>

18. Милошевич Д.З., Набор инструментов для управления проектами – Академия «АйТи», ДМК Пресс, Москва, 2006 – 714 стр.

19. Новичков А., Разработка плана управление конфигурацией, 10.04.2007, http://www.ibm.com/developerworks/ru/library/plan-uk/index.html

20. Ньюэл М., Управление проектами. Руководство по подготовке к сдаче сертикафиционного экзамена (PMP) – Кудиц-Образ, Москва, 2006.

21. Орлик С., Идентификация программных конфигураций (Software Configuration Identification)// Режим доступа от 11 октября 2010 года: <http://www.it4business.ru/lib/>

22. Попов Ю.И., Яковенко О.В. Управление проектами. Учебное пособие – Москва: Инфра-М, 2005.

23. Руководство к своду знаний по управлению проектам (руководство PMBOK), издание третье / Project Management Institute, Inc., 2004. – 388с.

24. Хайем А., 17 способов повысить мотивацию сотрудников// Режим доступа от 11 октября 2010 года: <http://www.ippnou.ru/article.php?idarticle=002596>

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

2 Авторы рекомендуют включать в проект руководителей и двух спонсоров проекта – по одному от заказчика и исполнителя.

3 От английского stakeholder – «заинтересованная сторона».

4 PMI (Project Management Institute) – методология управления проектами Института управления проектами, Pennsylvania USA.

5 ASAP (Acceler-ated SAP) – методология внедрения ERP-системы SAP R/3 компании SAP.

6 PJM (Project Management) – методология внедрения ERP-системы Oracle Appications корпорации Oracle.

7 SPICE (Software Process Improvement Capabilities and dEtermination) – оценка и улучшение процессов разработки ПО.

8 Грейдинг (от англ. grading ) – классификация, сортировка, упорядочивание. Грейдирование – это позиционирование должностей, то есть распределение их в иерархической структуре предприятия в соответствии с ценностью данной позиции для предприятия.

9 Вводимые допущения НЕ должны противоречить информации в описании ситуации и ДОЛЖНЫ быть озвучены во время выступления.

10 И (здесь и далее в таблице) – Исполнитель.

11 З (здесь и далее в таблице) – Заказчик.

12 Индекс легкости чтения по Флешу определяется по среднему числу слогов в слове и слов в предложении. Пределы изменения индекса – от 0 до 100. Чем выше величина индекса, тем легче прочтение текста и тем большему числу читателей он будет понятен.

101