Методология очень сильно привязана к MS Dymnamix
Преимущества | Недостатки |
Методологию можно переносить, т.к. она привязана к ГОСТ 12207 | Сильно привязана к производителю |
Позволяет консолидировать опыт между проектами (из-за документации) | «Тяжеловесность» с точки зрения документации (с точки зрения конечного пользователя) |
Компоненты модели внедрения Microsoft Dynamics Sure Step
Модель внедрения, образующая основу методологии Microsoft Dynamics Sure Step, включает следующие компоненты:
- этапы;
- процессы;
- предложения;
- конечные результаты;
- межэтапные процессы;
- процедуры управления проектами;
- роли консультантов и клиентов.
Схема этапов представлена в предыдущем ответе, рассмотрим подробно каждый из них.
Диагностика
Задача: получить завершённые результаты, которые будут содержать предложения по проекту, предварительное планирование, описание проекта и оценку инфраструктуры.
Завершение: подписание документа, который определяет объёмы и рамки проекта и ресурсы, которые необходимы. Этот документ – соглашение о том, «что хочется сделать». Также необходимо формально перечислить все возможные трудности.
Рекомендация к этапу: максимальная формализация.
Анализ
Начинается с формирования проектной команды, формализуется её состав, роли и точки зрения на проект, происходит погружение команды в программный продукт для того, чтобы сотрудники клиента взглянули на ПО со стороны MS Dynamics AX. Происходит параллельное диагностирование всех подразделений, детальный анализ всех бизнес-процессов и их формализация.
Также производится новый анализ инфраструктуры с учётом новых требований, а также анализ и планирование миграции данных.
Завершение: документ с функциональными требованиями, который дополнительно содержит требования к контролю качества и тестированию; устав проекта (все соглашения внутри проекта) и план-график проекта.
Дизайн
Создание спецификации дизайн-решения, интеграция с внешними системами и миграция данных.
Завершение: техническая спецификация проекта (конкретные сроки, исполнители, ПО и т.д.)
Разработка
Параллельная разработка всех модулей, выполнение формального соответствия работы с документами. Сложность – в тестировании.
Развёртывание
Происходит объединение команды, при этом усиливается нагрузка на сотрудников заказчика. Осуществляется запуск системы и контролирование валидности её реализации, тренинг и обучение персонала, нагрузочное тестирование, тестирование конечными пользователями.
Эксплуатация
Приёмка системы заказчиком, формирование пакетов документов по закрытию проекта, обучение (знакомство с платформой – обучение конкретному решению – помощь сотрудников друг другу).
Завершение: внутренние и внешние конечные документы.
Методология Sure Step представляет процессы по каждому этапу двумя способами:
- иерархический список операций, задач и подзадач, представленный в древовидной структуре методологии Sure Step;
- схемы процессов в виде схем Microsoft® Visio®, являющиеся графическим изображением операций каждого этапа методологии.
Предложения определяют различные варианты продажи и поставки внедрения решения Microsoft Dynamics. Предложения, определенные в методологии Sure Step, поддерживают различные сценарии внедрения. Они соответствуют различным этапам или сочетаниям этапов модели методологии, и позволяют партнеру выбрать подход внедрения, наилучшим образом удовлетворяющий конкретные потребности клиента.
Методология Microsoft Dynamics Sure Step поддерживает следующие предложения услуг:
- диагностика;
- подробный анализ;
- анализ;
- внедрение;
- полное внедрение;
- быстрое внедрение;
- оптимизация;
- обновление.
Межэтапный процесс — это группа связанных операций, охватывающих несколько этапов внедрения в конкретном сценарии проекта. Методология Sure Step содержит следующие межэтапные процессы:
- анализ бизнес-процесса;
- настройка;
- миграция данных;
- инфраструктура;
- установка;
- интеграция;
- тестирование;
- обучение.
Ниже представлены примеры основных ролей, поддерживаемых методологией Sure Step.
Роли консалтинга
- Руководитель проекта
- Менеджер по контактам
- Архитектор решений
- Консультант по приложениям
- Консультант по разработке
- Технический консультант
Роли клиента
- Руководитель, принимающий решения
- Руководитель проекта
- Руководитель отдела ИТ
- Ключевой пользователь
- Конечный пользователь
Документирование при внедрении по модели внедрения Microsoft Dynamics Sure Step
Этап 1: диагностика
Этап начинается с подготовительной деятельности, основная цель которой — сформировать команду для проведения диагностики. Как только команда собрана и проинструктирована, первой ее задачей станет высокоуровневый анализ бизнес-требований.
В некоторых компаниях имеются бизнес-процессы, заключающие в себе высокие риски в силу большой доли неопределенности в них. Для таких процессов рекомендуется более детальный бизнес-анализ. Задачи детального анализа на этапе диагностики сводятся к получению достаточной информации для точного определения рамок проекта и объема предполагаемых работ. В некоторых случаях могут потребоваться отдельное коммерческое предложение и контракт на проведение детальной диагностики.
Как только анализ бизнес-процессов будет завершен, у проектной команды появится достаточно информации для высокоуровневого определения границ и рамок проекта.
Отдельная часть предложения на внедрение системы посвящена инфраструктуре. Клиент хочет понимать, каковы будут суммарные инвестиции в проект развертывания Microsoft Dynamics. Задачи инфраструктурного анализа определяются на этапе диагностики, но их выполнение можно перенести на этапы анализа или дизайна, в зависимости от конкретного клиента.
Финальный набор задач заключается в планировании проекта – определении ресурсов, времени и бюджета для развертывания решения.
В завершение этапа диагностики необходимо оценить бизнес-требования, объем и рамки проекта, а также план проекта, и исходя из этого определить, что рационально в данном случае – быстрое или полное внедрение Microsoft Dynamics.
Основные результаты этапа
- Предложение по работе над проектом:
o описание содержания проекта (отчет о диагностике, рабочая тетрадь бизнес-процессов);
o предварительный план проекта (включая идентификацию и рамки проекта).
- Оценка инфраструктуры.
Основные вехи этапа
- Клиент принимает предложение на внедрение и контракт, включая предполагаемый объем и рамки проекта, а также предварительный план проекта.
Этап 2: анализ
Этап анализа начинается с действий, направленных в первую очередь на формализованное создание проектной команды – как со стороны консультанта, так и со стороны заказчика. Следует обратить особое внимание на совещание по запуску проекта (Kick Off Meeting), на котором должны быть представлены участники проектной команды и согласованы ожидания и взгляды на то, как будет протекать проект.
Следующая по важности задача после проведения kickoff-встречи — необходимость ознакомить ключевых пользователей с Microsoft Dynamics. Тренинг должен быть нацелен на пользователей, которые будут непосредственно участвовать в детальном анализе, а также на ключевых пользователей из бизнес-единиц компании-заказчика, вовлеченных в проект.
Далее запускается ряд параллельных операций, набор которых зависит от объема проекта и доступных ресурсов. В первую очередь проектная команда должна продолжить детальный анализ бизнес-процессов, начатый на этапе диагностики.
Как только завершится анализ разрывов, рекомендуется провести ревизию требований к инфраструктуре с целью удостовериться, что ни одно из новых требований не повлияет на изначально предложенную инфраструктуру.
Анализ и планирование миграции данных также следует проводить на стадии анализа. Проектная команда должна идентифицировать существующие источники информации и оценить, что потребуется для миграции данных.
Когда анализ всех требований будет завершен, собранная информация агрегируется и на ее основе создается документ «Функциональные требования», который заказчик проверяет, одобряет и подписывает.
Основные результаты этапа
- Устав проекта.
- План и тренинги ключевых пользователей.
- Детальный анализ бизнес-процессов:
o анализ разрывов требований с базовой функциональностью;
o оценка устранения разрывов;
o описание интерфейсов.
- План миграции данных.
- План проекта.
- Функциональные требования:
o инфраструктура, функциональность и безопасность;
o интеграция.
- Требования к контролю качества и тестированию.
Основные вехи этапа
- Проведено совещание по запуску проекта.
- Заказчик утверждает Устав проекта.
- Проводится тренинг по Microsoft Dynamics AX для ключевых пользователей.
- Заказчик утверждает «Функциональные требования», включая описания бизнес-процессов, интеграции и миграции данных.
- Заказчик утверждает обновленный план-график проекта.
Этап 3: дизайн
Основа этапа дизайна закладывается еще на этапе анализа и регламентируется порожденными на ней артефактами, в частности, результатом анализа бизнес-процессов и планом миграции данных. Цели этапа дизайна включают следующее (но не ограничиваются этим):
- Создать или обновить целостный дизайн решения и соответствующие документы, которые потребуются для того, чтобы решение соответствовало функциональным требованиям.
- Создать верхнеуровневую спецификацию для каждой модификации системы, настраиваемой обработки, специфичных отчетов и интеграций, определенных в документе «Функциональные требования».
- Создать детальное описание требований к преобразованию данных в соответствии с тем, что было определено в ходе анализа и планирования миграции данных на этапе анализа.
- Получить одобрение от заказчика верхнеуровнего плана миграции данных и спецификации дизайна решения, прежде чем приступать к созданию детальной спецификации дизайна и проведению финальных оценок.
- Создать детальную спецификацию дизайна решения на основе верхнеуровневой структуры дизайна, одобренной клиентом.
- Провести и представить заказчику окончательные оценки разработки, создания модификаций, настройки, интеграции и миграции данных.
- Получить утвержденные заказчиком дизайн решения, спецификации модификаций системы, дизайн миграции данных и оценки всех перечисленных операций.
Основные результаты этапа
- Спецификация дизайна решения:
o o функциональный дизайн;
o o техническая спецификация.
- Дизайн интеграции с внешними системами.
- Дизайн миграции данных и определение соответствий структур данных.
- План и сценарии тестирования.
Основные вехи этапа
- Заказчик утверждает спецификацию дизайна решения, дизайн интеграции с внешними системами и дизайн миграции данных.
- Заказчик утверждает время разработки и оценку расходов.
Этап 4: разработка
Планирование этапа разработки включает просмотр требований к разработке, расстановку приоритетов и распределение ресурсов. Затем настраивается среда разработки и тестирования, а план тестирования, работа над которым была начата на стадии дизайна, окончательно прорабатывается для каждого настраиваемого процесса.
Текущие операции разработки протекают параллельно в зависимости от того, какие ресурсы имеются в распоряжении проектной команды. Например, можно параллельно разрабатывать дополнительную функциональность системы, способы интеграции и миграции данных. Операции разработки включают тестирование разработанных модулей. Кроме того, необходимо функциональное тестирование, проводимое командой консультантов. В идеале тестирование должно выполняться не самими разработчиками, а кем-либо еще, и проводиться по согласованному ранее плану тестирования.
Как только завершится цикл разработки какой-либо дополнительной функциональности, можно приступать к подготовке как технической, так и пользовательской документации на эту функциональность, включая дополнительные тренинги для пользователей. Заказчик начинает тестирование процессов согласно критериям, сформулированным на этапе дизайна. Такое тестирование подтверждает корректность настройки функциональности, интеграции и миграции данных.
Циклы разработки и тестирования продолжаются до тех пор, пока результаты тестирования не будут отвечать определенным ранее критериям тестирования и не удовлетворят заказчика. На данном этапе проекта важны такие процессы, как управление объемом и рамками проекта и управление изменениями.
Реализация отдельных функций, интеграция и миграция данных могут быть перенесены на другие этапы разработки в зависимости от их масштаба, сложности и доступных ресурсов.
Основные результаты этапа
- Настройка решения Microsoft Dynamics.
- Подготовка документации по решению Microsoft Dynamics (технической и пользовательской).
- Разработка дополнительной функциональности (кастомизаций) (дополнения и модификации).
- Настройка и тестирование миграции данных.
- Интеграционное тестирование (в том числе интеграции с внешними системами).
- Результаты тестирования
Основные вехи этапа
- Выполняется миграция данных.
- Выполняется интеграционное тестирование.
- Заказчик принимает созданное решение, результаты тестирования и документацию.
Этап 5: развертывание
На этапе развертывания все усилия проектной команды объединяются и направляются на успешную передачу заказчику решения Microsoft Dynamics. В рамках этого этапа есть несколько важных задач, которые должны быть выполнены для успешного достижения цели. Этап включает в себя все операции, связанные с завершающим тестированием (в том числе нагрузочным), тренингами пользователей и окончательным переходом на новую рабочую среду.
Основные результаты этапа
- План запуска и контрольный список.
- План тестирования системы.
- План обучения пользователей.
- Тренинги для пользователей.
- Рабочая система.
Основные вехи этапа
- План запуска и контрольный список.
- План тестирования системы.
Этап 6: эксплуатация
После успешного запуска системы и подписания акта приемки этапа развертывания могут быть запущены две параллельные группы задач.
Первый набор задач — различные завершающие операции проекта, связанные с окончательной передачей знаний от проектной команды заказчику. Некоторые проектные операции остаются открытыми после запуска системы — это вполне обычное явление. Очень важно пройти по всем этим открытым операциям и получить согласие заказчика на их закрытие. Закрытие проекта также включает поставку оставшейся документации, опциональные дополнительные тренинги пользователей и финальную передачу знаний.
Второй набор задач представляет собой важные «пост-запускные» операции, которые подразумевают присутствие участников проектной команды у заказчика на протяжении определенного периода времени с целью удостовериться в том, что рабочая среда корректно функционирует, и оказать помощь при возникновении непредвиденных ситуаций. Это потенциально объемный набор задач, которым необходимо управлять, и он имеет фиксированную дату завершения.
После закрытия проекта, передачи знаний и пост-запускной поддержки рекомендуется провести совместный анализ проекта. Это отличная возможность обсудить проект и вынести из него соответствующие уроки.
На этой точке взаимодействие с заказчиком ведется в рамках предварительно согласованной поддержки продукта (с подписанием соответствующего контракта). Команда консультанта переключается на следующий проект.
Основные результаты этапа
- Приемка системы заказчиком.
- Документы для закрытия проекта (техническая и пользовательская документация).
- Соглашение о поддержке системы.
Основные вехи этапа
- Заказчик принимает Microsoft Dynamics и подписывает акт ввода в промышленную эксплуатацию.
- Заказчик формально закрывает проект.
- Заказчик подписывает договор поддержки.