В течение каких этапов проекта выполняются работы процесса ввод в эксплуатацию по методологии oracle aim

Обновлено: 04.07.2024

Внедрение корпоративной информационной системы класса ERP – сложный и продолжительный процесс, затрагивающий все подразделения предприятия. Часто в процессе внедрения требуется производить реинжиниринг, автоматизируемых бизнес процессов. Для обеспечения выполнения проекта внедрения в заявленные сроки, в рамках определенного бюджета проекта, с высоким качеством и полнотой проведения необходимых работ, подразделением корпорации Oracle ответственным за консалтинг, была разработана методология внедрения AIM (Application Implementation Method).

Этапы Application Implementation Method

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

Строится грубая модель явления.

Выявляются детальные требования к разным аспектам явления.

Модель и детальные требования отображаются в приложении (приложение настраивается и демонстрируется).

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

Стоимость реализации новых возможностей приложения оценивается, и если она "слишком" велика, то происходит возврат к перестройке модели или изменение требований.

Если стоимость реализации новых возможностей оправдана, то новые компоненты приложения разрабатываются (и интегрируются в приложение).

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

Новая модель внедряется в жизнь.

Работы, выполняемые для решения этих задач, по принципу общности результатов сгруппированы в процессы. Проект делится на шесть фаз (см. рис. 2.1).

Основные цели, которые должны быть достигнуты в соответствующих фазах проекта

В фазе Определение сформулированы совокупные бизнес-требования Заказчика. Впоследствии они могут уточняться и видоизменяться в ходе отображения на функциональность Oracle E-Business Suite, но появления новых бизнес-требований не происходит.

В фазе Анализ операций зафиксированы будущие бизнес-процессы и определено, как они будут реализованы с помощью Oracle E-Business Suite; установлено, какие бизнес-требования не могут быть удовлетворены с помощью стандартной функциональности и какая дополнительная разработка необходима.

В фазе Дизайн решения получены детальные спецификации для дополнительной разработки (функциональный и технический дизайн) и разработаны сценарии тестирования.

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

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

В фазе Эксплуатация - обеспечение поддержки Заказчика в работе с системой; устранение выявленных недостатков в работе системы.

Рис. 2.1. Организация проекта внедрения согласно AIM

Каждый из выделенных процессов подразумевает выполнение определенного комплекса работ.

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

Отображение бизнес-требований (BR). В ходе выполнения задач этого процесса выясняется, какая функциональность Oracle E-Business Suite и каким образом может применяться для реализации необходимых Заказчику функциональных возможностей информационной системы. Окончательно определяются бизнес-процессы "как должно быть" и состав используемой в системе информации. Фиксируются значения параметров настройки программных модулей Oracle E-Business Suite и перечень необходимых доработок.

Разработка архитектуры (TA). В ходе этого процесса происходит построение технической архитектуры, необходимой для работы системы, а также определяются значения ключевых параметров настройки Oracle E-Business Suite, касающихся архитектуры.

Разработка дополнительной функциональности (MD). В рамках этого процесса разрабатывается программное обеспечение, которое необходимо для реализации функциональности, отсутствующей в Oracle E-Business Suit.

Конвертация данных (CV). Процесс охватывает задачи, связанные с переносом данных из унаследованных систем в новую. Выявляются объекты, содержащие необходимые данные, определяются методы преобразования и загрузки этих данных в систему. Разрабатывается вспомогательное программное обеспечение.

Документирование (DO). В этом процессе создается документация на систему.

Тестирование функциональности (TE). На основе бизнес-требований разрабатываются сценарии тестирования и проводится проверка реализации этих требований в системе.

Тестирование производительности (PT). Проверяется работоспособность системы в условиях реальной нагрузки (по количеству пользователей, документов, транзакций и пр.).

Обучение (TR). Процесс включает в себя две основные задачи: обучение проектной группы (с него начинается проект по внедрению) и обучение конечных пользователей (им проект заканчивается).

Ввод в эксплуатацию (PM). В ходе этого процесса рассматриваются все вопросы, связанные с организацией промышленной эксплуатации системы и ее сопровождением.

Все вышеперечисленные процессы полностью охватывают все стороны создания системы и при скоординированном выполнении позволяют создать систему в соответствии с требованиями заказчика. Для обеспечения скоординированной работы команды проекта AIM рекомендует использовать в ходе всего проекта группу процессов управления проектом (PJM). Группа процессов управления проектом (Project Management) состоит из 5 процессов:

Контроль и отчетность (Control & Reporting)

Управление работами (Work Management)

Управление ресурсами (Resource Management)

Управление качеством (Quality Management)

Управление конфигурацией (Configuration Management)

Шаблоны Application Implementation Method

Использование всего комплекса методологии Oracle Application Implementation Method позволяет сократить сроки внедрения, гарантированно достичь заявленных целей проекта и не превысить отведенного бюджета. AIM представляет собой пошаговое руководство по внедрению Oracle E-Business Suite. Выполнение каждой задачи процесса в каждой фазе заканчивается каким-либо результатом. Для документирования каждого результата предусмотрены специализированные документы, отражающие специфику каждой задачи. Шаблоны этих документов входят в AIM и могут быть использованы при внедрении в исходном виде или могут быть изменены в соответствии с особенностями проекта.

Примеры проектов:

Внедрение Oracle e-Business Suite (РМС-1) в 9 региональных филиалах и Генеральной Дирекции ОАО «Северо-Западный Телеком».

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Методика компании Oracle внедрения готовых приложений пакета Oracle E-Business Suite , называемая Application Implementation Method (AIM), является составной частью методического комплекса Oracle Method , который охватывает различные аспекты развития ИТ-инфраструктуры компании. Методология Oracle AIM представляет собой детальное описание задач, выполняемых в ходе проекта, с указанием последовательности их выполнения и ответственных ролей проектной группы [ 7 ] .

Общая схема исполнения проекта согласно AIM описывается следующей последовательностью действий:

Строится грубая модель явления.
Выявляются детальные требования к разным аспектам явления.
Модель и детальные требования отображаются в приложении (приложение настраивается и демонстрируется).
Если какие-то аспекты модели или требований не реализуются приложением, то формируется подход к их реализации.
Стоимость реализации новых возможностей приложения оценивается, и если она "слишком" велика, то происходит возврат к перестройке модели или изменение требований.
Если стоимость реализации новых возможностей оправдана, то новые компоненты приложения разрабатываются (и интегрируются в приложение).
Составляются инструкции по использованию приложения, объединяющие стандартные и новые возможности приложения и базирующиеся на модели явления и на детальных требованиях к нему.
Новая модель внедряется в жизнь.

Основные цели, которые должны быть достигнуты в соответствующих фазах проекта

В фазе Определение сформулированы совокупные бизнес-требования Заказчика. Впоследствии они могут уточняться и видоизменяться в ходе отображения на функциональность Oracle E-Business Suite, но появления новых бизнес-требований не происходит.
В фазе Анализ операций зафиксированы будущие бизнес-процессы и определено, как они будут реализованы с помощью Oracle E-Business Suite; установлено, какие бизнес-требования не могут быть удовлетворены с помощью стандартной функциональности и какая дополнительная разработка необходима.
В фазе Дизайн решения получены детальные спецификации для дополнительной разработки (функциональный и технический дизайн) и разработаны сценарии тестирования.
В фазе Разработка завершены все дополнительные разработки, проведены приемочные тесты, разработана пользовательская документация для эксплуатации решения.
В фазе Переход завершено обучение конечных пользователей, проведена конвертация данных, система введена в эксплуатацию.
В фазе Эксплуатация - обеспечение поддержки Заказчика в работе с системой; устранение выявленных недостатков в работе системы.

Рис. 2.1. Организация проекта внедрения согласно AIM

Каждый из выделенных процессов подразумевает выполнение определенного комплекса работ .

Определение бизнес-требований (RD). Результатом выполнения задач, входящих в данный процесс, является описание требований Заказчика к развертываемой системе. В ходе этого процесса создаются детальные описания выполнения бизнес-процессов Заказчика в заданной области автоматизации (модели "как есть"). Затем разрабатываются модели бизнес-процессов Заказчика, которые будут реализованы после развертывания системы (модели "как должно быть"). Последние затем детализируются до уровня конкретных функций, выполняемых системой для каждого элементарного шага бизнес-процесса.
Отображение бизнес-требований (BR). В ходе выполнения задач этого процесса выясняется, какая функциональность Oracle E-Business Suite и каким образом может применяться для реализации необходимых Заказчику функциональных возможностей информационной системы. Окончательно определяются бизнес-процессы "как должно быть" и состав используемой в системе информации. Фиксируются значения параметров настройки программных модулей Oracle E-Business Suite и перечень необходимых доработок.
Разработка архитектуры (TA). В ходе этого процесса происходит построение технической архитектуры, необходимой для работы системы, а также определяются значения ключевых параметров настройки Oracle E-Business Suite, касающихся архитектуры.
Разработка дополнительной функциональности (MD). В рамках этого процесса разрабатывается программное обеспечение, которое необходимо для реализации функциональности, отсутствующей в Oracle E-Business Suit.
Конвертация данных (CV). Процесс охватывает задачи, связанные с переносом данных из унаследованных систем в новую. Выявляются объекты, содержащие необходимые данные, определяются методы преобразования и загрузки этих данных в систему. Разрабатывается вспомогательное программное обеспечение.
Документирование (DO). В этом процессе создается документация на систему.
Тестирование функциональности (TE). На основе бизнес-требований разрабатываются сценарии тестирования и проводится проверка реализации этих требований в системе.
Тестирование производительности (PT). Проверяется работоспособность системы в условиях реальной нагрузки (по количеству пользователей, документов, транзакций и пр.).
Обучение (TR). Процесс включает в себя две основные задачи: обучение проектной группы (с него начинается проект по внедрению) и обучение конечных пользователей (им проект заканчивается).
Ввод в эксплуатацию (PM). В ходе этого процесса рассматриваются все вопросы, связанные с организацией промышленной эксплуатации системы и ее сопровождением.

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

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

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

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

RD.020 - RD.030 - RD.070 - BR.020 - BR.080 - MD.020 - MD.060 - DO.070 - TE.110 - PM.050 - CV.140 - PM.080, где

Application Implementation Method (AIM) — методика внедрения готовых приложений, разработанная компанией Oracle для внедрения пакета готовых приложений Oracle E-Business Suite. Методика AIM практически не использует специфических особенностей Oracle E-Business Suite, поэтому она с одинаковым успехом может быть применена при внедрении любой ERP-системы и любого готового приложения, ориентированного на автоматизацию бизнес-процессов. Суть методики заключается в адаптации бизнес-процессов к применению информационных технологий и одновременно адаптации этих информационных технологий к конкретным бизнес-процессам.

Основные понятия AIM

Методика AIM представляет собой описание задач, выполняемых в ходе проекта, с указанием последовательности выполнения и ответственных ролей проектной группы.

Задача в терминах методики — это элементарный (неделимый) объем работ, который заканчивается формально фиксируемым результатом.

На рис. 1.1 показано разбиение задач по процессам и фазам внедрения: по горизонтали указаны процессы, по вертикали — фазы.

Все задачи сгруппированы в процессы по принципу общности результата. Выделяются следующие процессы внедрения:

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

Рис. 1.1. Методология внедрения Oracle

2) отображение бизнес-требований — анализируются функциональность Oracle E-Business Suite и то, каким образом она может использоваться для реализации возможностей, необходимых заказчику. Окончательно определяется, каким образом будут осуществляться хозяйственные процессы (бизнес-процессы) заказчика после развертывания системы, какая информация будет храниться в системе и какие доработки необходимо сделать, а также значения параметров настройки Oracle E-Business Suite;
3) функциональная и техническая архитектура — осуществляется построение технической архитектуры, необходимой для работы системы, определяются значения ключевых параметров настройки Oracle E-Business Suite, касающихся архитектуры;
4) разработка дополнительной функциональности — разрабатывается программное обеспечение, необходимое для реализации функциональности, отсутствующей в Oracle E-Business Suit;
5) конвертация данных — анализируются задачи, связанные с переносом данных из существующих систем (возможно, в бумажном виде) во внедряемую систему. Выявляются объекты, содержащие необходимые данные, определяются методы загрузки этих данных в систему. Разрабатываются и выполняются программы переноса;
6) документирование — создается документация на систему;
7) тестирование — на основе требований к функциональности системы, собранных и детализированных в ходе процессов определения и отображения бизнес-требований, разрабатываются сценарии тестирования и производится проверка системы на реализуемость требований;
8) тестирование на производительность — выполняются задачи, связанные с тестированием системы на узкие места по производительности;
9) обучение — процесс разбивается на две части: обучение проектной группы, с которого начинается проект по внедрению, и обучение конечных пользователей, которым проект заканчивается;
10) ввод в эксплуатацию — рассматриваются все вопросы, связанные с вводом в эксплуатацию системы и ее последующим сопровождением.

Работы по проекту разбиваются на временные фазы:

• определение — по окончании выявляются совокупные бизнес- требования заказчика. Впоследствии они могут уточняться и видоизменяться в ходе отображения на функциональность Oracle E-Business Suite, но новые бизнес-требования не появляются;
• анализ операций — по окончании фазы будущие бизнес-процессы зафиксированы и определено, как они будут реализованы с помощью Oracle E-Business Suite. Точно также фиксируется, какие бизнес-требования не могут быть удовлетворены с помощью стандартной функциональности и какая дополнительная разработка необходима;
• проектирование решения — создаются детальные спецификации для дополнительной разработки (функциональный и технический дизайн) и сценарии тестирования;
• разработка — по окончании фазы все дополнительные разработки завершены, приемочные тесты проведены, пользовательская документация разработана;
• переход к эксплуатации — завершается обучение конечных пользователей, производится конвертация данных и система вводится в эксплуатацию;
• эксплуатация системы — начало фазы поддержки системы. Выявляются и исправляются все недочеты в работе системы. Поскольку ход работ по развертыванию системы строго разделен на отдельные задачи, это дает возможность отслеживать и контролировать весь процесс по фазам внедрения. В случае возникновения проблем они четко локализуются по месту и причине появления, что позволяет вовремя и адресно принимать меры по их устранению.

В ходе проекта все фазы внедрения накладываются одна на другую и, более того, итеративно повторяются. Это происходит по следующим причинам:

AIM – Application Implementation Method – методика внедрения готовых приложений, разработана компанией Оракл для внедрения пакета готовых приложений Oracle E-Business Suite. Методика AIM практически не использует специфических особенностей Oracle E-Business Suite, поэтому она с одинаковым успехом может быть применена при внедрении любой ERP-системы и, вообще говоря, любого готового приложения, ориентированного на «автоматизацию» бизнес-процессов. Основную суть методики составляет адаптация бизнес-процессов к применению информационных технологий и, одновременно, адаптации этих самых информационных технологий к конкретным бизнес-процессам.

На настоящий момент не существует отечественных методик и/или стандартов (ГОСТов) в области внедрения готовых приложений. Учитывая современную мировую интеграцию в области стандартизации, а также ненаверстываемое в ближайшем будущем отставание отечественной индустрии сложных программных разработок, теперь уже нет никакого смысла в разработке отечественных методик.
При внедрении готовых приложений в бизнес-областях, обусловленных специфическим регламентом, или наоборот, четко не регламентированных, применение AIM не имеет смысла. В самом деле:

· в узкоспециализированной деятельности бизнес-процессы обычно не поддаются изменению, а потому само приложение должно быть написано точно под бизнес (и не нужно методики, чтобы его внедрять),

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

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

Когда по тексту будет важно понимать, идет ли речь о «стандартном» AIM или модифицированной методике, для модифицированной будет применяться термин AIM-M.

Существует детальная фирменная документация на Oracle AIM версии 3 и версии 2.5 (на английском языке). В данном тексте используется структура задач по версии 2.5, поскольку эта версия кажется менее перегруженной не основными задачами, а в целом методика обоих версий одинакова.

Основные понятия AIM

При внедрении готовых приложений пакета Oracle E-Business Suite используется ноу-хау методика, выработанная и апробированная компанией Oracle в ходе внедрения пакета собственным подразделением консалтинга. Данная методика - AIM(Applications Implementation Method, Метод внедрения приложений) - представляет собой детальное описание задач, выполняемых в ходе проекта, с указанием последовательности выполнения и ответственных ролей проектной группы.

Задача в терминах методики AIM представляет собой элементарный (неделимый) объем работ, который обязательно заканчивается формально фиксируемым результатом.

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

· Отображение бизнес-требований- в ходе выполнения задач, входящих в данный процесс, проводится анализ того, какая функциональность Oracle E-Business Suite и каким образом может использоваться для реализации функциональных возможностей, необходимых заказчику. В этом процессе окончательно определяется, каким образом будут осуществляться хозяйственные процессы (бизнес-процессы) заказчика после развертывания системы, какая информация будет храниться в системе и какие доработки необходимо сделать, а также значения параметров настройки Oracle E-Business Suite.

· Функциональная и техническая архитектура – в ходе этого процесса происходит построение технической архитектуры, необходимой для работы системы, а также определяются значения ключевых параметров настройки Oracle E-Business Suite, касающихся архитектуры.

· Разработка дополнительной функциональности – в рамках этого процесса разрабатывается программное обеспечение, необходимое для реализации функциональности, отсутствующей в Oracle E-Business Suit.

· Конвертация данных – процесс охватывает задачи, связанные с переносом данных из существующих систем (возможно в бумажном виде) во внедряемую систему. Выявляются объекты, содержащие необходимые данные, определяются методы загрузки этих данных в систему. Разрабатываются и выполняются программы переноса.

· Документирование – в этом процессе создается документация на систему.

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

· Тестирование на производительность- в ходе этого процесса выполняются задачи, связанные с тестированием системы на «узкие» места по производительности.

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

· Ввод в эксплуатацию- в ходе этого процесса рассматриваются все вопросы, связанные с вводом в эксплуатацию системы и ее последующим сопровождением.

Все работы по проекту разбиваются на временные фазы. Выделяются следующие фазы:

· Определение – по окончании данной фазы определяются совокупные бизнес-требования заказчика. Впоследствии они могут уточняться и видоизменяться в ходе отображения на функциональность Oracle E-Business Suite, но появления новых бизнес-требований не происходит.

· Анализ операций – по окончании данной фазы будущие бизнес-процессы зафиксированы и определено, как они будут реализованы с помощью Oracle E-Business Suite. Так же точно определено, какие бизнес-требования не могут быть удовлетворены с помощью стандартной функциональности и какая дополнительная разработка необходима.

· Проектирование решения - в ходе данной фазы в частности производится создание детальных спецификаций для дополнительной разработки (функциональный и технический дизайн) и разработка сценариев тестирования.

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

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

· Эксплуатация системы – это начало фазы поддержки системы. В это время выявляются и исправляются все недочеты по работе системы.

Изучение и моделирование бизнеса

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

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

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

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

Как вы понимаете, методология американская и известна как AIM (Application Implementation Method), затем была усовершенствована до AIM for Business Flows. Если пока не вдаваться в детали, то в первом случае мы поступательно шли к результату, собирали требования, описывали процессы и впервые как следует знакомились с внедряемой системой только к концу проекта, когда уже бывало поздно исправлять ошибки. Во втором случае подход значительно изменился, стал гораздо ближе к реальной практике внедрения благодаря многократному тестированию системы на различных этапах ее готовности.

А какие роли от консалтинга обычно задействованы и чем им предстоит заниматься:

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

Обязательные разделы Плана управления проектом (еще его иногда называют Уставом):

Границы Проекта
Цели Проекта
Подходы и методы
Задачи Проекта, Результаты и Контрольные Точки Проекта.
Роли и обязанности участников проекта
Организацию управления проектными работами
Процедуры управления рисками и спорными вопросами.

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

В любом варианте методологии проект делится на пять этапов или фаз (названия привожу на русском языке, этот перевод наиболее точно отражает содержание):

Определение. По завершению данной фазы определяются планы и процедуры управления проектом, проведено обучение проектной команды (CRP 1), декомпозированы границы проекта в терминах цепочек будущих бизнес-процессов, предварительно определена функциональная и техническая архитектура системы, определены стратегии и подходы к тестированию и конвертации данных.
Анализ операций. По завершению данной фазы будущие бизнес процессы и цепочки бизнес процессов компании зафиксированы и определено, как они будут реализованы с помощью выбранных бизнес-приложений. Так же зафиксированы основные требования к реализации шагов бизнес процессов в системе.
Уточнение / Проектирование решений. В ходе данной фазы в частности производится настройка прототипа промышленной системы и проводится тестирование на прототипе системы будущих бизнес-процессов по согласованным сценариям. Так же определено, какие бизнес требования не могут быть удовлетворены с помощью стандартной функциональности, и какая дополнительная разработка необходима. Выявленные в результате CRP 2 требования могут впоследствии уточняться и видоизменяться, но появления новых требований на последующих фазах не происходит.
Построение. По завершению данной фазы все разработки завершены, в ходе данной фазы производится окончательная настройка прототипа промышленной системы, разработаны наиболее критичные для бизнеса расширения и проведено тестирование на прототипе системы расширений и будущих бизнес-процессов в целом по согласованным сценариям (CRP 3), пользовательская документация разработана.
Переход. В ходе этой фазы проводится обучение конечных пользователей, производится конвертация данных и система вводится в эксплуатацию.

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

CR.010.План управления проектом.

WM.020.План работ.

BF.015.Высокоуровневая бизнес модель. Диаграммы процессов верхнего уровня будущей модели в формате MS Power Point. Описание будущей архитектуры, точек интеграции с внешними системами.

2 Анализ операций

BF.020.Бизнес процедуры. Детальное описание шагов исполнения процессов, определение зон ответственности за исполнение процесса по ролям в формате Tutor.

BF.040.1.Каталог расхождений теста. Документ фиксирует отклонения и требования возникшие в результате проведения как локальных так и сквозных тестов.

3 Уточнение / Проектирование решений

BF.160.1.Определение параметров настройки системы.

TE.040.2.Сценарий 2-го сквозного системного теста. Сквозной сценарий 2-го тестирования бизнес-модели на основе детальных бизнес процедур. Включает в себя тестирование проведенных настроек системы согласно выявленным на предыдущей фазе требованиям.

TE.035.Сценарии тестирования. Сценарии тестирования различных возможностей использования системы на конкретных примерах.

BF.040.2.Каталог расхождений теста. Документ фиксирует отклонения и требования возникшие в результате проведения как локальных так и сквозных тестов.

MD.021.Реестр разработок. Перечень расширений, которые будут реализованы в рамках проекта, сформированный на основе Каталога расхождений после CRP2. Перечень предполагает расстановку приоритетов для расширений, согласно которым будет выстроена очередность разработки.

MD.070.Технический дизайн расширения. Документ описывает технические подробности создания расширения. Указываются источники данных для разработки отчета, алгоритмы обработки.

TE.040.3.Сценарий 3-го сквозного системного теста. Сквозной сценарий 3-го тестирования бизнес-модели на основе детальных бизнес процедур. Включает в себя также сквозное тестирование расширений и интерфейсов с внешними системами.

BF.170.1.Определение уровней доступа. Детальное описание пользовательских меню для различных полномочий, особенностей персональных настроек.

TE.110.Протокол тестирования системы. Документ, подготовленный на основе сценариев тестирования и содержащий результаты прохождения шагов тестов и выявленные недостатки.

BF.160.1.Определение параметров настройки системы. Завершение настройки системы и документирование финальных настроек.

BF.170.2.Определение уровней доступа. Завершение настройки полномочий и ролей и документирование финальных настроек.

DO.070.Инструкции пользователя. Инструкции создаются на основе BF.020.Бизнес процедур.

CV.040.Определение данных и правил конвертации. Приложениями идут файлы с данными.

Читайте также: