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

↑ Описание Dynamics AX ↑ Решения Dynamics AX ↑ Обучение Dynamics AX

Проект внедрения ERP-системы может потребовать существенных ресурсов и времени. Чтобы минимизировать его риски и гарантировать успешное завершение, Microsoft разработал методологию внедрения бизнес-решений — Microsoft Dynamics Sure Step.

Microsoft Dynamics Sure Step

Методология Microsoft Dynamics Sure Step

Microsoft рекомендует разбивать проект внедрения решения на платформе Dynamics на следующие взаимосвязанные этапы:

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

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

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

Ниже подробно рассмотрены ключевые задачи каждого этапа проекта внедрения решения на платформе Microsoft Dynamics.

Этап 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 CRM и подписывает акт ввода в промышленную эксплуатацию.
  • Заказчик формально закрывает проект.
  • Заказчик подписывает договор поддержки.

В начало