Задать вопрос
Все поля, которые отмеченны * - обязательны к заполнению
Новое поле
  1. обязательное заполнение
  2. обязательное заполнение
  3. обязательное заполнение
Новое поле
  1. обязательное заполнение
 

cforms contact form by delicious:days

Заказать услугу
Все поля, которые отмечены * - обязательны к заполнению
Ваше имя|Ваше имя
  1. (обязательно)
  2. (обязательно)
  3. (корректный e-mail)
  4. (обязательно)
  5. (обязательно)
Новое поле
  1. (обязательно)
 

cforms contact form by delicious:days

Методология внедрения приложений AIM

Print Print

Если PJM-методология описывала, как правильно управлять проектом, то AIM – Application Implementation Method – описывает, что и как нужно делать в ходе проекта, чтобы успешно внедрить ERP–систему.

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

Процессы AIM представляют собой связанные наборы задач, требований к выполнению бизнес–шагов, а также входные данные и результаты. Одна задача может быть присуща только одному процессу. «Классический» AIM версии 3.2 состоит из 11 процессов:

  1. Архитектура бизнес-процессов (Business Process Architecture, BP) – включает задачи по построению текущей и будущей моделей бизнеса компании, наложению специфики компании на бизнес-модель и построению детальных бизнес-процессов. Целью BP является обеспечение среды для анализа, построения и изменения бизнес-процессов.
  2. Определение требований бизнеса (Business Requirements Definition, RD), - объединяет задачи по определению требований, бизнеса ко всей  новой системе,  к шагам бизнес-процесса, к объему данных и их атрибутам
  3. Сопоставление требований бизнеса (Business Requirements Mapping, BR) – проводится сравнение бизнес-требований со стандартной функциональностью системы управления предприятием, выявляются разрывы, проводится их классификация. По мере возникновения разрывов между требованиями и функциональностью, они удаляются с помощью использования и документирования обходных путей, альтернативных решений, расширений приложений или изменения основного бизнес-процесса.
  4. Прикладная и техническая архитектура (Application and Technical Architecture, TA) – в  этом процессе проектируется архитектура информационной системы, отображающая  цели бизнеса и позволяющая ими управлять. Будучи связанным с другими процессами, процесс создания архитектуры должен начинается уже на раннем этапе проекта внедрения
  5. Проектирование и построение расширений (Module Design and Build, MD) — подразумевает доработку программного обеспечения для покрытия пробелов в функциональности, выявленных в процессе отображения бизнес-требований. Расширения системы включают программные модули (формы, отчеты, расширения, триггеры баз данных и т.д.), которые должны быть спроектированы, запрограммированы и протестированы до того, как они будут включены в систему.
  6. Конвертация данных (Data Conversion, CV) – данный процесс включает подготовку и перенос наиболее важной бизнес информации из старых систем в новую, а также проверку правильности такого переноса и возможности использования данных в новой системе.
  7. Документирование (Documentation, DO) – целью этого процесса является стандартизация описания и выполнение документирования в процессе внедрения. Процесс документирования начинается с материалов, созданных в начале проекта или шаблонных документов. Используя подробную документацию проекта, специалисты  разрабатывают пользовательские и технические материалы, соответствующие описанным бизнес-процессам. Полный набор документов включает руководство по настройке системы, руководство пользователя, техническое справочное руководство, а так же текст контекстно-зависимой помощи. Вся документация ведется в согласованном стиле, формате и содержании.
  8. Тестирование решений (Business System Testing, TE) – процесс, направленный  на выполнение циклического тестирования всех элементов разрабатываемой системы, с целью полного устранения или минимизации риска возникновения проблем на этапе промышленного запуска системы. Тестирование решения начинается с момента первичной настройки системы, а заканчивается тестированием  конечными пользователями и конечным приемочным  тестированием перед запуском в промышленную эксплуатацию.
  9. Тестирование производительности (Performance Testing, PT) – дает возможность определить соответствие будущей системы целям и требованиям заказчика. Процесс тестирования должен учитывать полноту и объем операций не только в сдаваемой системе, но и ее плановый рост, хотя бы, на прогнозируемое будущее. Используя полученные результаты, необходимо принять решения о том, насколько приемлема производительность. Если полученные характеристики неприемлемы, необходимо внести корректировку в бизнес-решение или усовершенствовать производительность аппаратного и сетевого оборудования.
  10. Освоение и обучение (Adoption and Learning, AP) – подготовка пользователей  и администраторов к выполнению задач по работе с новой прикладной системой. Включает как теоретические занятия, обеспечивающие  понимание основ функций, целей и требований бизнеса в конкретной среде, так и практические, направлены на обучение продуктам Oracle и получение навыков работы с ними.
  11. Переход на новую систему (Production Migration, PM) — данный процесс контролирует и поддерживает эксплуатацию, а так же подготавливает основу и варианты развития системы в будущем. Состоит из проверки готовности к переходу, сам переход и последующую поддержку. Переход считается завершенным, только тогда, когда данные системы преобразованы и выверены, а пользователи начали ее эксплуатацию. Как только система стабилизировалась, начинается ее постоянное сопровождение и обновление, а руководство начинает первоначальное планирование будущих технических и бизнес- улучшений.

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

На рисунке ниже изображено деление проекта на фазы (по – вертикали) и процессы (по – горизонтали).

AIM выделяет в проектах шесть основных фаз:

  1. Определение (Definition) – на этой фазе создается план проекта, окончательно утверждаются его цели и границы, оценивается целесообразность достижения каждой цели и задачи проекта, учитывая ограничения по времени, ресурсам и денежным средствам. Так же в рамках этого этапа определяются все стратегии, задачи и подходы для каждого процесса AIM, обеспечивая основу для создания плана и единого понимания всеми участниками проекта последовательности задач. Проектная группа проводит моделирование текущих процессов компании для того чтобы  определить основные требования к будущей системе, текущую архитектуру приложений информационных потоков, а затем предложить будущую бизнес-модель.
  2. Анализ операций (Operations Analysis) – на этой фазе разрабатывается детальная модель будущих бизнес-процессов, с учетом результатов фазы определения и требований, собранных на текущей фазе, а также предварительная техническая и функциональная модель архитектуры системы. После выявления возможных разрывов функциональности проектная группа готовит решения по реализации каждого из них, а руководство утверждает каким именно образом будет выполняться реализация.
  3. Проектирование решения (Solution Design) – целью фазы является разработка детального описания решений, соответствующих бизнес-требованиям, собранным и утвержденным во время фазы анализа операций. Во время фазы проектирования происходит детальный анализ, формирование и уточнение технической и функциональной архитектуры, начинается разработка документации.
  4. Построение (Build) – выполняется программирование и тестирование всех настроек стандартной функциональности и программных доработок, включая преобразования данных и интерфейсы для интеграции. Одной из основных задач фазы является тест бизнес-системы, позволяющий максимально детально определить насколько решение соответствует целям проекта и бизнес-требованиям.
  5. Переход (Transition) – во время этой фазы реализуются окончательные изменения в решении. Проектная группа проводит обучение конечных пользователей в то время, как техническая группа конфигурирует среду эксплуатации и конвертирует данные. Фаза перехода завершается переходом к промышленной эксплуатации. К этому моменту конечные пользователи должны пройти обучение и тестирование и быть готовыми к выполнению своих должностных обязанностей в новой системе.
  6. Промышленная эксплуатация (Production) – начинается сразу же, после выполнения фазы перехода и является последней фазой внедрения и началом процесса поддержки системы. В последнюю фазу включен целый ряд задач: стабилизация системы, обеспечение поддержки ее организации на протяжении всего жизненного цикла, сравнение фактических результатов с задачами проекта, контроль обновления системы и первоначальное планирование будущих улучшений.

Методология Oracle AIM может применяться в двух вариантах: AIM Classic, при которой изменения прорабатываются методом продвижения от общего к частному, а каждая задача выполняется только один раз на протяжении проекта и AIM for Business Flows подразумевающий создание нескольких прототипов будущей системы (от 2-х до 4-х ), каждый из которых имеет определенные цели.