МЕТОДОЛОГИЯ ВНЕДРЕНИЯ MICROSOFT DYNAMICS SURE STEP

Методология управления проектами внедрения бизнес-решений ЦМД-софт основана на методологии Microsoft Sure Step Methodology (MDSS). MDSS предназначена для внедрения решений Microsoft Dynamics. Методология включает практический опыт, собранный по результатам внедрения Microsoft Dynamics во всем мире. MDSS призвана помогать партнеру Microsoft сокращать время, стоимость и риски внедрения, одновременно повышая эффективность работы консультантов и удовлетворенность заказчика. В одной из своих частей MDSS связана с методологией Microsoft Solutions Framework (MSF), которая представляет собой набор рекомендаций по успешной разработке программного обеспечения и технических проектов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключевые шаги на стадии Анализ:

  • Подготовка и планирование проекта (график интервью, график предоставления документов, график подготовки ФТТ);
  • Подготовка и согласование Устава проекта;
  • Инсталляция/обновление программного обеспечения на оборудовании Заказчика (при необходимости);
  • Обучение ключевых пользователей;
  • Анализ бизнес-процессов («как есть») и моделирование будущих бизнес-процессов («как будет») на развернутой системе;
  • Сбор сведений обо всех важных справочниках и данных;
  • Анализ используемых баз (электронных таблиц) для хранения бизнес-сведений;
  • Изучение регламентирующих (внутренних) документов, законодательных и нормативных актов;
  • Изучение входных/выходных документов (отчетов, печатных форм, каталогов продукции и пр.);
  • Изучение имеющихся ИТ-систем, с которыми планируется интеграция MS CRM (сайт, бухгалтерская система, учетная система и др.);
  • Изучение ИТ-среды заказчика, выявление требований к безопасности;
  • Сбор требований в ходе интервью и встреч с сотрудниками Заказчика (также может включать пробное выполнение в системе);
  • Подготовка и согласование документа «Функционально-технические требования».

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

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

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

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

Основными шагами стадии Дизайн являются:

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

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

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

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

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

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

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

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

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

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

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

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

Основными этапами для этой стадии являются:

  • Завершение разработки пользовательской документации;
  • Завершение настройки и модификации системы;
  • Ввод или перенос исходных данных;
  • Тренинги для конечных пользователей;
  • Опытная эксплуатация системы.

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

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

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

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

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

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

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

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

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

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

Истории успеха

История успеха

Клиенты о решениях



Rambler's Top100 Яндекс.Метрика