Устав проекта

Управление документом

Согласование Замечания

Обработка замечаний

Бизнес-причины возникновения проекта

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

Потребность во внедрении ERP-системы связана со следующими причинами:

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

Цели проекта

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

Цели проекта:создание и внедрение ERP-системы с целью автоматизации основных бизнес-процессов "Client Company". Срок - до 01.10.2011. Качество - согласно спецификации (требования Заказчика, закрепленные в техническом задании).

Требования к проекту

• Создание интегрированного ИТ-решения на базе гибкой, тиражируемой и быстро реагирующей на изменения платформы с единым пользовательским интерфейсом.
• Поддержка совместного использования информации различными подразделениями "Client Company" и иерархически-ролевого доступа к ней.
• Повышение прозрачности функционирования и управляемости компании за счет обеспечения информации в необходимом аналитическом разрезе для принятия оперативных управленческих решений руководством компании.
• Повышение эффективности использования основных активов и ресурсов компании.
• Сокращение административно-управленческих косвенных затрат, в том числе на закрытие финансовой отчетности за период (месяц, квартал, год) и на ведение параллельного учета по МСФО.

Расписание контрольных событий

Дата начала выполнения проекта: 01.08.2010

Дата завершения проекта: 01.10.2011.

Участники проекта

Компания "Client Company" осуществляет данный проект совместно с компанией "Big&Co", выступающей генеральным подрядчиком по проекту.

Инициатор проекта (спонсор) - генеральный директор компании "Client Company" Большова Ю.Б.

Заказчик - компания "Client Company".

Руководители проекта, команда проекта - определены в п. 0.

Функциональные группы - будут определены в содержании проекта.

Генеральный подрядчик - "Big&Co".

Лицензоры - Microsoft.

Органы власти - Фонд социального страхования РФ, Пенсионный фонд РФ, Фонд обязательного медицинского страхования, налоговая инспекция, Правительство РФ.

Окружение проекта

• Факторы внешней среды
  • ? клиенты
  • ? партнеры
  • ? конкуренты
  • ? законодательство
  • ? экономические условия, такие как финансовые показатели и др.
• Факторы внутренней среды
  • ? политика руководства компании "Client Company"
  • ? отношение персонала компании "Client Company" к проекту
  • ? корпоративная культура "Client Company"
  • ? команда проекта

Допущения и ограничения

Допущения

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

Ограничения

Окружение проекта

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

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

Технологии

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

• Microsoft Dynamics AX;
• Microsoft SQL Server - СУБД, используемая для работы Microsoft Dynamics AX;
• Локальные ИС - локальные информационные системы Заказчика;
• Приложения Microsoft Office;
• Microsoft Visio, ARIS - графические системы для отражения бизнес-процессов ("Как есть" и "Как будет").

Стоимость проекта

Совокупная стоимость проекта внедрения ERP-системы для компании "Client Company" составит 2 000 000 евро (без НДС). Данный показатель состоит из стоимости прав пользования ERP-системы (лицензионная составляющая), стоимости консалтинговых услуг и стоимости обучения конечных пользователей.

Руководитель проекта

Инициатором (спонсором) проекта является генеральный директор компании "Client Company" Большова Ю.Б..

Руководителем проекта со стороны компании "Client Company" назначается ведущий специалист департамента информатизации компании "Client Company" Бахвалова Евгения Анатольевна.

Руководителем проекта со стороны "Big&Co" назначается Захарова Екатерина Павловна.

Полномочия команды управления проектом

В сферу общей ответственности руководителей проекта входит:

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

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

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

Описание содержания проекта будет представлено на рассмотрение управляющего комитета 10 сентября 2009 года руководителем проекта со стороны "Big&Co" Захаровой Е.П.

Приложение. Принятые термины и сокращения

Описание содержания проекта

Управление документом

Согласование

Замечания

Обработка замечаний

Цели и задачи проекта

Целью проекта внедрения Microsoft Dynamics AX в компании "Client Company" является спроектированная, разработанная и переданная в распоряжение Заказчика ERP-система на основе решения Microsoft Dynamics AX.

Требования к проектному решению

Продукт должен удовлетворять следующим требованиям:

• анализ и формализация стратегии. Анализ макрофакторов и внешнего окружения организации;
• анализ и применение референтных моделей лучших практик при проектировании бизнес-процессов;
• построение архитектуры ИТ-решения на основе характеристик выбранного ИТ-продукта и с учетом специфики организации;
• реализация единого пользовательского интерфейса;
• расширенные возможности внедряемого ИТ-продукта с точки зрения обеспечения стратегического развития ИС;
• поддержка функционалом системы сквозных бизнес-процессов;
• целевое обучение конечных пользователей на основе анализа их системных ролей;
• возможность формирования аналитических отчетов.

Границы проекта

Способ реализации проекта

Методология реализации проекта

Реализация проекта по внедрению информационной системы Microsoft Dynamics AX осуществляется согласно методологии Microsoft Dynamics Sure Step.

В соответствии с методологией Microsoft Dynamics Sure Step проект внедрения состоит из следующих стадий:

1. диагностика;
2. анализ;
3. дизайн;
4. разработка;
5. развертывание;
6. эксплуатация.

Материалы и инструментарий

• Вендор: Microsoft
• Название: Microsoft Dynamics AX
• Microsoft Dynamics AX (ранее Microsoft Axapta) - многофункциональная система управления ресурсами предприятия (ERP II) для средних и крупных компаний

Состав и функциональность модулей

1. Управление финансами

   Модуль	Описание
   Бухгалтерский и управленческий учет	Учет по российским и международным стандартам Мультивалютный учет, конвертация валют, расчет курсовой разницы Финансовое планирование, прогнозирование ликвидности и бюджетирования Сквозные финансовые аналитики Контроль всех операций - от первичного документа до бухгалтерской проводки Ведение налогового учета Формирование бухгалтерской и налоговой отчетности Инструмент для трансформации финансовой отчетности
   Управление финансами холдинга	Внутрихолдинговые расчеты между компаниями Построение системы управления финансами в целом Интерактивная консолидация данных компаний холдинга Консолидация путем экспорта/импорта Консолидация бюджетных данных Формирование консолидированной отчетности Управление дебиторской задолженностью Управление денежными потоками Анализ финансовых показателей
   Учет основных средств	Неограниченное число моделей учета амортизируемого имущества Начисление износа в соответствии с различными методами и справочником единых норм амортизационных отчислений Налоговый учет амортизируемого имущества Формирование регламентированной отчетности Учет операций внутреннего перемещения и перемещения между компаниями холдинга с передачей на баланс Инвентаризация и переоценка Бюджетирование основных средств и нематериальных активов
   Расчет заработной платы	Хранение сведений о сотрудниках и истории их изменений Расчет сумм оплаты труда и других выплат сотрудникам и совместителям Расчет удержаний из заработной платы в соответствии с законодательством РФ Расчеты с налоговыми органами по установленным формам отчетности

2. Управление персоналом

   Модуль	Описание
   Организаци онная структура	Поддержка иерархической, матричной и проектной структур организации Визуальное представление структуры организации Определение связей между подразделениями Администрирование должностей и обязанностей сотрудников Определение требований к ролям и рабочим заданиям Учет отсутствия сотрудников на рабочем месте Статистическое и графическое представление данных об отсутствии
   Подбор персонала	Управление подбором кадров Автоматизация переписки с соискателями, интеграция с Microsoft Office Word Автоматизация проведения собеседований, интеграция с Microsoft Office Outlook Статистические обзоры процессов подбора кадров Оценка соответствия кандидата предъявляемым требованиям
   Развитие персонала	Составление планов личного развития сотрудников, включая задания и сроки их выполнения Хранение данных о квалификации сотрудников Сопоставление фактических навыков с целевыми Графические средства анализа областей некомпетентности Анализ обратной связи от сотрудников путем анкетирования и построения отчетов Администрирование курсов Интеграция с корпоративным порталом
   Кадровый учет	Учет и хранение исторических данных о сотрудниках Формирование штатного расписания и ведение истории его изменения Движение кадров (проведение операций и формирование приказов о приеме, переводе и увольнении сотрудников) Продвижение по служебной лестнице (изменение должностных окладов и перевод на новую должность) Формирование графика отпусков Унифицированные формы кадровой отчетности Тесная интеграция с модулем "Расчеты с персоналом"

3. Дистрибуция

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

4. Производство

   Модуль	Описание
   Сводное планирование	Поддержка неограниченного числа сводных и прогнозных планов Возможность переноса прогнозных планов в главную книгу с целью получения прогноза движения денежных средств Расчет краткосрочных потребностей на основе существующих заказов и/или прогнозного планирования Использование при планировании групп номенклатур с различными принципами планирования Планирование с ограничением или без ограничения на мощности Использование восьми различных временных границ для каждого сводного плана Детализация спланированного заказа как с точки зрения потребностей самого заказа, так и с учетом целей его создания Наличие механизмов поддержки принятия решений Анализ чистых потребностей в материалах
   Управление производством	Создание производственного заказа как вручную, так и в результате сводного планирования или напрямую из заказа клиента Быстрый и удобный просмотр статуса производственных заказов Возможность назначения нескольких спецификаций и нескольких маршрутов для производимой продукции Автоматический расчет переменных и постоянных потерь Автоматический расчет плановой и фактической себестоимости по производственному заказу Автоматическое и/или ручное списание материального потребления и рабочего времени под производственный заказ Использование диаграммы Ганта как для графического представления производственных заказов, так и для ручного перепланирования заданий Возможность перепланировать задания при дефиците ресурса
   Конфигуратор продукции	Интерфейс пользователя настраивается индивидуально для каждой модели продукции Моделирование продукции любой сложности Быстрое конфигурирование номенклатуры из заказа клиента Автоматический расчет цены для вновь сконфигурированной номенклатуры Возможность настройки автоматической проверки создаваемых моделей Возможность использования в моделях кода на внутреннем языке разработки X++
   Управление цехом	Определение рабочего времени для каждого сотрудника и регистрация присутствия на работе Расширенные настройки профилей рабочего времени (смены, гибкий график, выходные) Регистрация начала и завершения работы над заданиями Отслеживание простоев и непроизводственных затрат времени Регистрация рабочего времени с помощью терминального оборудования либо вручную

5. CRM (управление взаимоотношениями с клиентами)

   Модуль	Описание
   Отношения с клиентами	Единый справочник деловых отношений различных типов Простой доступ к информации, связанной с деловыми отношениями (заказы, предложения, проекты, мероприятия, почтовые рассылки, контактная информация) Тесная интеграция предложений с заказами и сводным планированием Управление мероприятиями, синхронизация встреч и задач с Microsoft Office Outlook Отправка сообщений электронной почтой и SMS отдельным адресатам или группе адресатов
   Управление продажами	Определение планов продаж для менеджеров по продажам и групп менеджеров (отделов продаж) Управление процессом продаж Отслеживание статуса продаж, включая рассматриваемые предложения Графическое представление данных по продажам Прогнозирование продаж Создание отчетов о работе менеджеров по продажам

Первоначальная иерархическая структура работ (ИСР) до пакетов работ

1. Диагностика
   • Подготовка описания содержания проекта (отчета о диагностике).
   • Разработка предварительного плана проекта.
   • Оценка инфраструктуры.
2. Анализ
   • Разработка и утверждение устава проекта.
   • Проведение тренингов ключевых пользователей.
   • Детальный анализ бизнес-процессов:
     • ? анализ разрывов требований с базовой функциональностью;
     • ? оценка устранения разрывов;
     • ? описание интерфейсов.
   • Подготовка плана миграции данных.
   • Разработка и согласование плана проекта.
   • Утверждение функциональных требований:
     • ? инфраструктура, функциональность и безопасность;
     • ? интеграция.
   • Разработка требований к контролю качества и тестированию.
3. Дизайн
   • Спецификация дизайна решения:
     • ? функциональный дизайн;
     • ? техническая спецификация.
   • Дизайн интеграции с внешними системами.
   • Дизайн миграции данных и определение соответствий структур данных.
   • План и сценарии тестирования.
4. Разработка
   • Настройка решения Microsoft Dynamics.
   • Подготовка документации по решению Microsoft Dynamics.
   • Разработка дополнительной функциональности (кастомизация).
   • Настройка и тестирование миграции данных.
   • Интеграционное тестирование (в том числе интеграции с внешними системами).
5. Развертывание
   • План запуска и контрольный список.
   • План тестирования системы.
   • План обучения пользователей.
   • Тренинги для пользователей.
   • Рабочая система.
6. Эксплуатация
   • Приемка системы заказчиком.
   • Документы для закрытия проекта.
   • Соглашение о поддержке системы.

Потребность в ресурсах, штатное расписание и организационная структура проекта

Матрица ответственности

Укрупненный календарный план

Ключевые факторы успеха

1. Поддержка проекта топ-менеджерами компании
2. Сотрудничество конечных пользователей при внедрении системы
3. Обучение конечных пользователей
4. Жесткая регламентация всех процессов и этапов внедрения ERP-системы
5. Наличие квалифицированного персонала
6. Наличие корпоративных стандартов (организационно-штатная структура предприятия; бухгалтерские стандарты; кодификатор и классификатор продукции и других товарно-материальных ценностей; кодификатор и классификатор клиентов и партнеров, созданный с учетом целей анализа товарных и финансовых потоков; стандарты процедур основных функциональных операций (продажа, закупка, складирование и внутреннее перемещение товаров), а также других, например изложенных в виде процедур стандарта ISO 9000; стандарты принятия решений и разрешения противоречий (специфично для России))
7. Включение в группу внедрения сотрудников функциональных подразделений компании
8. Детальный план внедрения

Первоначально сформулированные риски

Смета расходов с указанием порядка величин

Ограничения проекта (со стороны исполнителя)

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

1. Настоящий документ подготовлен на основании информации, предоставленной Заказчиком. В случае изменения исходных требований параметры документа могут быть пересмотрены.
2. Изменения организационной структуры, а также существующей в компании процедуры управления персоналом в ходе проекта не предусматриваются планом проекта и могут быть приняты к исполнению как дополнительные работы по проекту в рамках дополнительных соглашений к договору.
3. Проект реализуется с использованием тех программных средств, которые документально зафиксированы Заказчиком и Исполнителем.
4. Заказчик является ответственным за полноту предоставляемой информации о существующих на момент начала проекта информационных системах. Дополнительные выявленные требования к поддержке внедряемым продуктом существующих систем могут быть отклонены Исполнителем.
5. Исполнитель своевременно согласовывает график заездов консультантов на объекты Заказчика с целью изучения существующей информационной среды Заказчика и максимально придерживается согласованного графика.
6. Заказчик своевременно выделяет квалифицированных сотрудников для выполнения работ по проекту. Руководитель проекта со стороны Заказчика, являющийся ответственным за взаимодействие Исполнителя с сотрудниками Заказчика, обладает достаточным уровнем полномочий.
7. Исполнитель обязуется выполнить все задачи по этапам проекта в течение 14 месяцев в срок, начиная с 01.08.2010 и заканчивая 01.10.2011. Увеличение сроков выполнения проекта влечет за собой санкции, предусмотренные договором между Заказчиком и Исполнителем.
8. Заказчик предоставляет Исполнителю необходимую информацию по нормативной базе взаимодействия с третьими сторонами, информацию по обмену данными с информационными системами третьих сторон. Полнота, непротиворечивость и достоверность предоставленной информации являются ответственностью Заказчика.
9. Заказчик должен обеспечить присутствие работников, входящих в состав рабочей группы, занимающейся формированием функциональных требований, на проводимых Исполнителем интервью в соответствии с согласованными планами проведения интервью.
10. Сотрудники Исполнителя, для максимально эффективного использования рабочего времени, придерживаются рабочего графика, установленного на объектах Заказчика.
11. Заказчик и Исполнитель устанавливают эффективную процедуру принятия решений.
12. При использовании ИТ-инфраструктуры Заказчика участники проектной команды Исполнителя соблюдают политику информационной безопасности Заказчика.

Допущения проекта (со стороны исполнителя)

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

1. Заказчик и Исполнитель согласовывают допустимую длительность рабочего времени у Заказчика для консультантов и руководителя проектов Исполнителя.
2. Сотрудники Исполнителя, для максимально эффективного использования рабочего времени, придерживаются рабочего графика, установленного на объектах Заказчика.
3. Заказчик и Исполнитель устанавливают эффективную процедуру принятия решений.
4. Приемка и подписание промежуточных проектных результатов происходит в течение одной недели с момента подачи или в другой, взаимно утвержденный период.
5. Заказчик самостоятельно принимает и согласовывает все промежуточные и выходные документы проекта.
6. Рабочие места для проектной команды будут предоставлены таким образом, что члены рабочей команды будут работать вместе в одном помещении.
7. Техническая инфраструктура, которая требуется на каждой стадии проекта, предоставляется в запланированные сроки согласно плану-графику проекта. Компания предоставляет стабильно работающую, полнофункциональную системную инфраструктуру, которая способна обеспечить исполнение запланированного объема работ по внедрению и позволяет проектной команде работать продуктивно.

Требования к управлению конфигурацией проекта

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

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

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

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

   • Тип объекта
   • Имя объекта
   • Идентификация программы или проекта
   • Номер версии
   • Номер ревизии (ревизия для конкретной версии)
   • Данные о готовности
2. Контроль конфигураций

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

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

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

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

   • Время возникновения каждого и изменения
   • Время определения каждого объекта конфигурации
   • Описательная информация о каждом объекте конфигурации
   • Статус запросов на изменение (принят, отклонен, ожидает выполнения)
   • Описание статусов
   • Описательная информация о каждом запросе на изменение
   • Статус изменения
   • Описательная информация о каждом изменении
4. Аудит конфигураций

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

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

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

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

   Требования к одобрению/ принятию документа "Описание содержания проекта"

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

   Помимо проектной документации в пакет документов для процедур приемки результатов проекта входят следующие первичные документы:

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

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

   В случае если по окончании отчетного периода запланированная работа участника проектной команды оказалась не выполненной, руководители проекта от Исполнителя и Заказчика проводят выяснение причины невыполнения запланированной работы. Если причина невыполнения запланированной работы не может быть устранена оперативно (т.е. в течение 1 дня), она вносится как проблема в журнал проблем администратором проекта и решается в соответствии с процедурой управления открытыми вопросами. По решении проблемы руководители проекта от Исполнителя и Заказчика производят установление нового срока выполнения работы.

   Акт сдачи-приемки услуг к договору на консультационные услуги, составленный в двух экземплярах (по одному для каждой из сторон), подписывается спонсором со стороны Исполнителя и спонсором со стороны Заказчика.

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

   После оформления акта о выполненных работах Исполнитель оформляет печатный экземпляр материалов, передает Заказчику и закрывает проект.

План управления проектом

Управление документом

Согласование Замечания

Обработка замечаний

Цели и задачи проекта

Целью проекта внедрения Microsoft Dynamics AX в компании "Client Company" является спроектированная, разработанная и переданная в распоряжение Заказчика ERP-система на основе решения Microsoft Dynamics AX. Цели проекта и критерии их достижения представлены в таблице П2.2.

Требования к проектному решению

Продукт должен удовлетворять следующим требованиям:

• анализ и формализация стратегии. Анализ макрофакторов и внешнего окружения организации;
• анализ и применение референтных моделей лучших практик при проектировании бизнес-процессов;
• построение архитектуры ИТ-решения на основе характеристик выбранного ИТ-продукта и с учетом специфики организации;
• реализация единого пользовательского интерфейса;
• расширенные возможности внедряемого ИТ-продукта с точки зрения обеспечения стратегического развития ИС;
• поддержка функционалом системы сквозных бизнес-процессов;
• целевое обучение конечных пользователей на основе анализа их системных ролей;
• возможность формирования аналитических отчетов.

Границы проекта

Границы проекта представлены в таблице П2.3.

Способ реализации проекта

Методология реализации проекта

Реализация проекта по внедрению информационной системы Microsoft Dynamics AX осуществляется согласно методологии Microsoft Dynamics Sure Step.

В соответствии с методологией Microsoft Dynamics Sure Step проект внедрения состоит из следующих стадий:

1. диагностика;
2. анализ;
3. дизайн;
4. разработка;
5. развертывание;
6. эксплуатация.

Материалы и инструментарий

Вендор: Microsoft

Название: Microsoft Dynamics AX

Microsoft Dynamics AX (ранее Microsoft Axapta) - многофункциональная система управления ресурсами предприятия (ERP II) для средних и крупных компаний.

Состав и функциональность модулей

Ключевые факторы успеха

1. Поддержка проекта топ-менеджерами компании.
2. Сотрудничество конечных пользователей при внедрении системы.
3. Обучение конечных пользователей.
4. Жесткая регламентация всех процессов и этапов внедрения ERP-системы.
5. Наличие квалифицированного персонала.
6. Наличие корпоративных стандартов (организационно-штатная структура предприятия; бухгалтерские стандарты; кодификатор и классификатор продукции и других товарно-материальных ценностей; кодификатор и классификатор клиентов и партнеров, созданный с учетом целей анализа товарных и финансовых потоков; стандарты процедур основных функциональных операций (продажа, закупка, складирование и внутреннее перемещение товаров), а также других, например изложенных в виде процедур стандарта ISO 9000; стандарты принятия решений и разрешения противоречий (специфично для России)).
7. Включение в группу внедрения сотрудников функциональных подразделений компании.
8. Детальный план внедрения.

Ограничения проекта (со стороны Исполнителя)

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

1. Настоящий документ подготовлен на основании информации, предоставленной Заказчиком. В случае изменения исходных требований параметры документа могут быть пересмотрены.
2. Изменения организационной структуры, а также существующей в компании процедуры управления персоналом в ходе проекта не предусматриваются планом проекта и могут быть приняты к исполнению как дополнительные работы по проекту в рамках дополнительных соглашений к договору.
3. Проект реализуется с использованием тех программных средств, которые документально зафиксированы Заказчиком и Исполнителем.
4. Заказчик является ответственным за полноту предоставляемой информации о существующих на момент начала проекта информационных системах. Дополнительные выявленные требования к поддержке внедряемым продуктом существующих систем могут быть отклонены Исполнителем.
5. Исполнитель своевременно согласовывает график заездов консультантов на объекты Заказчика с целью изучения существующей информационной среды Заказчика и максимально придерживается согласованного графика.
6. Заказчик своевременно выделяет квалифицированных сотрудников для выполнения работ по проекту. Руководитель проекта со стороны Заказчика является ответственным за взаимодействие Исполнителя с сотрудниками Заказчика и обладает достаточным уровнем полномочий.
7. Исполнитель обязуется выполнить все задачи по этапам проекта в течение 14 месяцев в срок, начиная с 01.08.2010 г. и заканчивая 01.10.2011 г. Увеличение сроков выполнения проекта влечет за собой санкции, предусмотренные договором между Заказчиком и Исполнителем.
8. Заказчик предоставляет Исполнителю необходимую информацию по нормативной базе взаимодействия с третьими сторонами, информацию по обмену данными с информационными системами третьих сторон. Полнота, непротиворечивость и достоверность предоставленной информации являются ответственностью Заказчика.
9. Заказчик должен обеспечить присутствие работников, входящих в состав рабочей группы, которая занимается формированием функциональных требований, на проводимых Исполнителем интервью в соответствии с согласованными планами проведения интервью.
10. Сотрудники Исполнителя, для максимально эффективного использования рабочего времени, придерживаются рабочего графика, установленного на объектах Заказчика.
11. Заказчик и Исполнитель устанавливают эффективную процедуру принятия решений.
12. При использовании ИТ-инфраструктуры Заказчика участники проектной команды Исполнителя соблюдают политику информационной безопасности Заказчика.

Допущения проекта (со стороны исполнителя)

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

• Заказчик и Исполнитель согласовывают допустимую длительность рабочего времени у Заказчика для консультантов и руководителя проектов Исполнителя.
• Сотрудники Исполнителя, для максимально эффективного использования рабочего времени, придерживаются рабочего графика, установленного на объектах Заказчика.
• Заказчик и Исполнитель устанавливают эффективную процедуру принятия решений.
• Приемка и подписание промежуточных проектных результатов происходит в течение одной недели с момента подачи или в другой, взаимно утвержденный период.
• Заказчик самостоятельно принимает и согласовывает все промежуточные и выходные документы проекта.
• Рабочие места для проектной команды будут предоставлены таким образом, что члены рабочей команды будут работать вместе в одном помещении.
• Техническая инфраструктура, которая требуется на каждой стадии проекта, предоставляется в запланированные сроки согласно плану-графику проекта. Компания предоставляет стабильно работающую, полнофункциональную системную инфраструктуру, которая способна обеспечить запланированный объем работ по внедрению и позволит проектной команде работать продуктивно.

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

Процедура верификации и приемки завершенных результатов поставки проекта

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

Помимо проектной документации в пакет документов для процедур приемки результатов проекта входят следующие первичные документы:

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

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

В случае если по окончании отчетного периода запланированная работа участника проектной команды оказалась не выполненной, руководители проекта от Исполнителя и Заказчика проводят выяснение причины невыполнения запланированной работы. Если причина невыполнения запланированной работы не может быть устранена оперативно (т.е. в течение 1 дня), она вносится как проблема в журнал проблем администратором проекта и решается в соответствии с процедурой управления открытыми вопросами. По решении проблемы руководители проекта от Исполнителя и Заказчика производят установление нового срока выполнения работы.

Акт сдачи-приемки услуг к договору на консультационные услуги, составленный в двух экземплярах (по одному для каждой из сторон), подписывается спонсором со стороны Исполнителя и спонсором со стороны Заказчика.

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

После оформления акта о выполненных работах Исполнитель оформляет печатный экземпляр материалов, передает Заказчику и закрывает проект.

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

Базовое расписание проекта

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

Процедура разработки расписания

1. Составление перечня операций, которые должны быть включены в расписание на основании нижнего уровня иерархической структуры работ.
2. Определение логической последовательности выполнения операций.
3. Определение длительности каждой операции.
4. Расчет раннего расписания для каждой операции.
5. Расчет позднего расписания для каждой операции.
6. Вычисление временного резерва для каждой операции.
7. Определение критического пути.
8. Внесение корректив в расписание в соответствии с датой обязательства.
9. Запрос ресурсов и определение ограничений на ресурсы.
10. Внесение корректив в расписание в соответствии с ограничениями на ресурсы.
11. Внесение корректив в расписание в соответствии с датой обязательства.
12. Согласование расписания.

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

Еженедельно ассистент руководителя проекта формирует отчет о ходе выполнения проекта и предоставляет его руководителю проекта.

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

В отчет о ходе выполнения проекта включается следующая информация:

1. завершенные задачи;
2. выполняющиеся задачи;
3. задачи, которые должны были начаться;
4. плановые затраты;
5. освоенный объем;
6. фактические затраты;
7. показатели CV, SV, CPI, SPI, EAC.

Процедура определения потребности во внесении изменений

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

Процедура внесения изменений

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

1. внесение корректив в расписание проекта на основе отчета о выполнении проекта;
2. внесение корректив в расписание в соответствии с датой обязательства;
3. запрос ресурсов и определение ограничений на ресурсы;
4. внесение корректив в соответствии с ограничением на ресурсы;
5. внесение корректив в расписание в соответствии с датой обязательства;
6. согласование со спонсором.

Процедуры управления стоимостью

Процедура оценки стоимости выполненных работ

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

Процедура контроля (мониторинг)

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

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

Процедура анализа показателей

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

Метод освоенного объема предусматривает сравнение плановых показателей эффективности с фактическими.

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

Процедура прогнозирования

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

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

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

Процедура внесения корректирующих мер

• В случае если значение CV или SV демонстрирует отклонение в одном и том же направлении свыше 10% в течение 3 отчетных периодов, руководители проекта на отчетном совещании информируют об этом спонсора проекта и управляющий орган проекта.
• В случае необходимости корректировки бюджета и базового плана по стоимости текущей фазы проекта руководители проекта по рекомендации спонсора проекта принимают решение о внесении изменений в бюджет и базовый план по стоимости текущей фазы проекта в соответствии с процедурой управления изменения.
• Решение об использовании резерва на непредвиденные обстоятельства принимается спонсором проекта.
• Решение об использовании управленческого резерва принимается управляющим органом проекта.
• Диаграмма календарно-стоимостного отслеживания проекта отражается в информационной системе управления проектами. Реестр освоенного объема ведется в электронных таблицах MS Excel.

План управления качеством

Для обеспечения соответствия фактического качества проекта запланированному качеству используется программа обеспечения качества.

Программа обеспечения качества

Для обеспечения соответствия требований заказчика требованиям проекта используется матрица "Соотнесение требований заказчика и требований проекта".

Матрица "Соотнесение требований заказчика и требований проекта"

Для обеспечения соответствия требований проекта характеристике ИТ-решения используется матрица "Соотнесение требований проекта и характеристик ИТ-решения" .

Матрица "Соотнесение требований проекта и характеристик ИТ-решения"

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

Процедура разработки плана тестирования

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

1. 1) № сценария - уникальный идентификатор сценария тестирования;
2. 2) сценарий - название сценария тестирования;
3. 3) предпосылки - перечень предварительных условий, которые должны быть выполнены перед тем, как приступить к прохождению сценария. Если таким условием является необходимость предварительного прохождения других сценариев, то приводятся номера этих сценариев;
4. 4) плановая дата - плановая дата проведения в формате ДД.ММ.ГГГГ;
5. 5) место проведения - предполагаемое место проведения тестирования (указывается полный адрес, и, по возможности, номер комнаты);
6. 6) ответственные - перечень сотрудников, ответственных за подготовку и проведение тестирования (в формате И.О.Фамилия);
7. 7) участники - перечень участников тестирования (в формате И.О.Фамилия). В тестировании в обязательном порядке должны участвовать координаторы соответствующих функций и процессов.

Сценарии в таблице упорядочиваются по плановой дате, далее - по номеру.

План тестирования подготавливает ассистент руководителя проекта, согласовывает с руководителем проекта. Руководитель проекта утверждает план тестирования.

Форма плана тестирования представлена ниже.

Форма плана тестирования

Процедура проведения тестирования

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

1. № - номер сценария тестирования бизнес-процесса; 2)
2. наименование сценария - короткое наименование сценария тестирования бизнес-процесса; 3)
3. описание сценария - описание сценария тестирования бизнес-процесса; 4)
4. дата, время - дата и время проведения тестирования; 5)
5. тестировщик - консультант от Исполнителя, участвующий в тестировании; 6)
6. приемщик - сотрудник функциональной группы от Заказчика, участвующий в тестировании; 7)
7. успешно (да/нет) - отметка об успешности прохождения тестирования; 8)
8. примечания - дополнительные пояснения к результатам сценария.

Форма тестирования представлена ниже.

Форма тестирования.

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

• Наименование сценария - короткое наименование сценария тестирования бизнес-процесса.
• № шага тестирования - уникальный идентификатор шага тестирования в формате Z.P#.NN, где Z - номер сценария тестирования, P# - 5-значный номер процесса, NN - уникальный 2-циферный код в рамках сценария.
• Шаг процесса - номер и наименование тестируемого шага бизнес-процесса. Номер шага бизнес-процесса в формате P#.NN, где P# - 5-значный номер процесса, NN - уникальный 2-цифер-ный код в рамках процесса.
• Модуль - модуль ИС, с использованием которого реализуется шаг бизнес-процесса.
• Описание ошибки - подробное описание ошибки, выявленной в ходе тестирования, со ссылкой на файл, в котором находятся полные сведения об ошибке.
• Решение - планируемые мероприятия по устранению ошибки.
• Ответственный - сотрудник, назначенный ответственным за устранение ошибки в намеченный срок.
• Намеченная дата - планируемый срок устранения ошибки. Форма журнала ошибок представлена ниже.

Форма журнала ошибок.

Процедура проведения аудита качества

Аудит качества проводится с целью выяснения, удовлетворяет ли качество проекта стандартам, установленным в плане обеспечения качества. Аудит качества проводится с помощью независимой экспертной оценки. Ответственным за проведение аудита качества назначается руководитель проекта со стороны Исполнителя. Результаты проведения аудита качества предоставляются спонсорам проекта и руководителю проекта со стороны Заказчика.

Процедура проведения аудита качества включает в себя следующие шаги:

• анализ исправления замечаний предыдущей проверки;
• проведение проверки проекта в соответствии с контрольными списками;
• оформление отчета о контроле качества;
• информирование команды проекта о появлении новых отчетных документов.

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

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

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

Форма представления результатов контроля качества

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

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

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

Процедура контроля качества документов проекта

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

Процедура разработки и согласования глоссария проекта

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

1. термин/ определение - используемые в документе термин или определение;
2. английское название - название на английском языке;
3. сокращение - принятое сокращение или аббревиатура;
4. объяснение - краткое объяснение смысла термина или определения;
5. область - указание, к какой области деятельности проекта относится данный термин:
   • техническая архитектура;
   • обучение;
   • поддержка;
   • приложение;
   • проектная терминология (в том числе методологическая);
6. документ - из глоссария какого документа поступили данные термин/определение.

Форма глоссария представлена ниже.

Форма глоссария

План управления обеспечением проекта персоналом

Потребность в ресурсах, штатное расписание и организационная структура проекта

Матрица ответственности

Ниже представлена матрица ответственности, где определена меры ответственности проектных ролей на этапах выполнения проектных работ.

Коды полей матрицы ответственности

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

Процедура набора персонала

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

1. Организовать встречу, посвященную началу проекта. Знакомство членов команды друг с другом. Тимбилдинги для развития взаимоотношений. Распределение работы таким образом, чтобы использовать имеющиеся ресурсы и сильные стороны членов команды лучшим образом. 2.
2. Определить роль команды внутри организации. Соотнести процессы и системы с другими проектами и системами. 3.
3. Построить рабочие взаимоотношения внутри команды. 4.
4. Установить и поддерживать общение (в т.ч. используя компьютерные технологии). 5.
5. Учитывать мнение всей команды. 6.
6. Соотнести цели, которые стоят перед каждым из членов команды, с личными предпочтениями и целями. 7.
7. Уменьшить привлечение аутсорсинга для выполнения разовых задач. 8.
8. Поощрять разрешение трудностей в конструктивной манере.

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

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

Процедура обеспечения безопасности

В соответствии с Трудовым кодексом регулируется обеспечение безопасности труда. Ответственным за обеспечение безопасности назначается руководитель проекта со стороны Исполнителя.

План управления коммуникациями

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

Взаимодействия по вертикали управления внутри одной команды: куратор (спонсор) проекта - руководитель проекта - команда проекта, - должны быть формальными и поддерживаться официальными документами. Взаимодействия руководителей проекта компании "Client Company" и "Big&Co" также являются формальными и должны оформляться официальными документами. Допускаются неформальные взаимодействия между кураторами проекта и членами команд проекта от компании "Client Company" и "Big&Co". Схема взаимодействия компаний "Client Company" и "Big&Co" в проекте представлена на рисунке.

Схема взаимодействия "Client Company" и "Big&Co".

Предмет коммуникации:Отчеты о проделанной работе

Цель:Контроль хода выполнения работ

Частота:Ежедневный, еженедельный и ежемесячный

Даты начала/завершения:Конец отчетного периода (дня, недели, месяца)

Формат/средство связи:По электронной почте и в бумажном виде

Ответственное лицо:Каждый участник команды

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

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

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

1. Сбор информации и формирование отчета участниками проекта.
2. Передача отчета участниками команды проекта как со стороны Исполнителя, так и со стороны Заказчика в электронном и бумажном виде вышестоящему руководству.
3. Передача отчета руководителю проекта со стороны Исполнителя или Заказчика.
4. Передача отчета от руководителя проекта со стороны Исполнителя руководителю проекта со стороны Заказчика и наоборот.
5. Формирование и предоставление отчетов руководителями проектов со стороны Заказчика и Исполнителя спонсорам проекта со стороны Заказчика и Исполнителя соответственно.
6. Формирование и предоставление отчетов руководителями проектов руководству своей компаний.

Процедура распространения информации

1. Своевременный сбор информации.
2. Обеспечение доступа к информации для совместного использования.
3. Применение различных способов передачи информации как в устной (при неформальном взаимодействии участников), так и в письменной (при формальном взаимодействии) форме, а также использование электронного оборудования для коммуникации, электронных инструментов для управления проектом.

Процедура анализа накопленных знаний

1. На протяжении всего жизненного цикла проекта основные участники должны выявлять накопленные знания, относящиеся к техническим, управленческим и процедурным аспектам проекта.
2. На всем протяжении проекта накопленные знания собираются, формализуются и размещаются в определенном месте.
3. Проведение совещаний по анализу накопленных знаний
4. Определение успехов и неудач проекта.
5. Выработка рекомендаций, направленных на улучшение выполнения проекта в будущем.
6. Обновление базы накопленных знаний.
7. Обновление правил, процедур и процессов, принятых в компании.
8. Приобретение дополнительных навыков ведения бизнеса.
9. Общее улучшение продукта или услуги.
10. Обновление плана управления рисками.

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

Ответственным лицом для организации работы с рисками назначается руководитель проекта со стороны компании "Big&Co".

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

Процедура планирования управления рисками

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

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

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

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

Шкала оценки влияния рисков

Итогом реализации процедуры планирования управления рисками является документ "План управления рисками".

Процедура идентификации рисков

Идентификация рисков предусматривает определение рисков (в соответствии с приведенной классификацией рисков), способных повлиять на проект, и документальное оформление их характеристик.

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

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

После коллегиального анализа сданных анкет назначенное лицо, ассистент руководителя проекта компании "Big&Co", заполняет реестр рисков проекта.

Форма реестра рисков

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

Вновь выявленные риски вносятся в реестр ассистентом руководителя проекта компании "Big&Co"

Риски, выявляемые на дальнейших этапах проекта, необходимо вносить в Реестр рисков.

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

Классификация рисков.

Процедура качественного анализа рисков

Качественный анализ рисков производится после процесса идентификации рисков.

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

Матрица вероятностей и последствий

Список рисков: вероятности и последствия.

Таким образом, стоит обратить внимание на риски, попавшие в красную зону. Эти риски требуют немедленного реагирования.

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

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

На основании информации, полученной от качественного анализа рисков, осуществляется обновление реестра рисков. Обновленный реестр рисков включает:

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

В рамках процедуры количественной оценки рисков строится диаграмма "Дерево решений" (см. рис.).

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

Составляется список приоритетных оцененных рисков, на которые обращается особое внимание.

На основании информации, полученной от количественного анализа рисков, осуществляется обновление реестра рисков. Обновленный реестр рисков включает:

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

Процедура планирования реагирования на риски

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

1. стратегия реагирования на негативные риски - уклонение, снижение, передача;
2. стратегия реагирования на позитивные риски - принятие;
3. стратегия реагирования на непредвиденные обстоятельства - передача, снижение.

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

Способы реагирования на риски, разработанные и утвержденные в процессе планирования реагирования, включаются в Реестр рисков.

Процедура мониторинга и управление рисками

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

Существующие и новые риски должны постоянно анализироваться: должна пересматриваться вероятность их появления и степень влияния на проект.

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

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

Руководителем проекта со стороны "Big&Co" к 5 числу месяца, следующего за отчетным, подготавливается отчет по результатам аудита рисков и анализа резервов для предоставления компании "Client Company".

По мере надобности обновляется матрица вероятностей и последствий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   • Тип объекта
   • Имя объекта
   • Идентификация программы или проекта
   • Номер версии
   • Номер ревизии (ревизия для конкретной версии)
   • Данные о готовности
2. Контроль конфигураций

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

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

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

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

• Время возникновения каждого изменения.
• Время определения каждого объекта конфигурации.
• Описательная информация о каждом объекте конфигурации.
• Статус запросов на изменения (принят, отклонен, ожидает выполнения).
• Описание статусов.
• Описательная информация о каждом запросе на изменение.
• Статус изменения.
• Описательная информация о каждом изменении. 4. Аудит конфигураций

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

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

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