oootisa. Методология внедрения

Методология внедрения

Компания Microsoft при внедрении Microsoft Dynamics CRM рекомендует использовать методологию Microsoft Dynamics Sure Step (MDSS). Данная методология предлагает разбивать проект внедрения решения на платформе Dynamics на следующие взаимосвязанные этапы:

Методология MDSS позволяет командам консультантов повышать уровень услуг, оказываемых клиентам, за счет снижения общей стоимости владения решением (TCO). MDSS применяется как в крупных и средних, так и в небольших проектах внедрения систем на платформе Microsoft Dynamics.

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

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

Более подробно с методолгией внедрения можно познакомиться на сайте компании Microsoft: http://www.microsoft.com/Rus/dynamics/howtointegrate/methodology.mspx.

Этап 1: диагностика

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

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

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

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

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

В завершение этапа диагностики необходимо оценить бизнес-требования, объем и рамки проекта, а также план проекта, и исходя из этого определить, что рационально в данном случае – быстрое или полное внедрение Microsoft Dynamics.

Основные результаты этапа

  • Предложение по работе над проектом:
    • описание содержания проекта (отчет о диагностике);
    • предварительный план проекта.
  • Оценка инфраструктуры.

Основные вехи этапа

  • Клиент принимает предложение на внедрение и контракт, включая предполагаемый объем и рамки проекта, а также предварительный план проекта.

Этап 2: анализ

Этап анализа начинается с действий, направленных в первую очередь на формализованное создание проектной команды – как со стороны консультанта, так и со стороны заказчика. Следует обратить особое внимание на совещание по запуску проекта (Kick Off Meeting), на котором должны быть представлены участники проектной команды и согласованы ожидания и взгляды на то, как будет протекать проект.

Следующая по важности задача после проведения kickoff-встречи — необходимость ознакомить ключевых пользователей с Microsoft Dynamics. Тренинг должен быть нацелен на пользователей, которые будут непосредственно участвовать в детальном анализе, а также на ключевых пользователей из бизнес-единиц компании-заказчика, вовлеченных в проект.

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

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

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

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

Основные результаты этапа

  • Устав проекта.
  • Тренинги ключевых пользователей.
  • Детальный анализ бизнес-процессов:
    • анализ разрывов требований с базовой функциональностью;
    • оценка устранения разрывов;
    • описание интерфейсов.
  • План миграции данных.
  • План проекта.
  • Функциональные требования:
    • инфраструктура, функциональность и безопасность;
    • интеграция.
  • Требования к контролю качества и тестированию.

Основные вехи этапа

  • Проведено совещание по запуску проекта.
  • Заказчик утверждает Устав проекта.
  • Проводится тренинг по Microsoft Dynamics AX для ключевых пользователей.
  • Заказчик утверждает «Функциональные требования», включая описания бизнес-процессов, интеграции и миграции данных.
  • Заказчик утверждает обновленный план-график проекта.

Этап 3: дизайн

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

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

Основные результаты этапа

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

Основные вехи этапа

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

Этап 4: разработка

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

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

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

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

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

Основные результаты этапа

  • Настройка решения Microsoft Dynamics.
  • Подготовка документации по решению Microsoft Dynamics.
  • Разработка дополнительной функциональности (кастомизаций).
  • Настройка и тестирование миграции данных.
  • Интеграционное тестирование (в том числе интеграции с внешними системами).

Основные вехи этапа

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

Этап 5: развертывание

На этапе развертывания все усилия проектной команды объединяются и направляются на успешную передачу заказчику решения Microsoft Dynamics. В рамках этого этапа есть несколько важных задач, которые должны быть выполнены для успешного достижения цели. Этап включает в себя все операции, связанные с завершающим тестированием (в том числе нагрузочным), тренингами пользователей и окончательным переходом на новую рабочую среду.

Основные результаты этапа

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

Основные вехи этапа

  • План запуска и контрольный список.
  • План тестирования системы.

Этап 6: эксплуатация

После успешного запуска системы и подписания акта приемки этапа развертывания могут быть запущены две параллельные группы задач.

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

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

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

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

Основные результаты этапа

  • Приемка системы заказчиком.
  • Документы для закрытия проекта.
  • Соглашение о поддержке системы.

Основные вехи этапа

  • Заказчик принимает Microsoft Dynamics и подписывает акт ввода в промышленную эксплуатацию.
  • Заказчик формально закрывает проект.
  • Заказчик подписывает договор поддержки.