СОЗДАНИЕ УНИФИЦИРОВАННОЙ МЕТОДОЛОГИИ РАЗРАБОТКИ ERP-систем НА ОСНОВЕ СРАВНИТЕЛЬНОГО АНАЛИЗА РЕШЕНИЙ SAP и MICROSOFT Текст научной статьи по специальности «Компьютерные и информационные науки»

СОЗДАНИЕ УНИФИЦИРОВАННОЙ МЕТОДОЛОГИИ

РАЗРАБОТКИ ERP-систем НА ОСНОВЕ СРАВНИТЕЛЬНОГО АНАЛИЗА

РЕШЕНИЙ SAP и MICROSOFT

Э.А. Бабкин,

к.т.н., заведующий кафедрой информационных систем и технологий факультета бизнес-информатики и прикладной математики Нижегородского филиала Государственного университета — Высшей школы экономики [email protected] Е.О. Потапова,

студентка магистратуры факультета бизнес-информатики и прикладной математики Нижегородского филиала Государственного университета — Высшей школы экономики

Методологии интеграции информационных систем ориентированы на использование определенного инструментария конкретного производителя. В рамках данной работы построена нейтральная методология разработки ERP-систем. Основа такой методологии — результаты анализа решений компаний SAP и Microsoft.

Введение

Enterprise Resource Planning (ERP—системы) в настоящее время — привычный инструмент управления в крупных и средних компаниях. Цель их внедрения — повышение управляемости бизнеса, увеличение его эффективности. Однако статистика показывает, что успешными оказываются только 16% внедрений; в 30% случаев внедрение ERP-системы приостанавливается, а в 54% — существенно пересматривается бюджет и отодвигаются сроки.

Основные проблемы при внедрении ERP-систем: несогласованные действия участников проекта; ошибки планирования работ в проекте и технических аспектов интеграции с другими информационными системами; несоответствие результатов внедрения проектным требованиям. Трудности при внедрении могут быть обусловлены необходимостью адаптации структуры и процессов компании к требованиям, предъявляемым новыми средствами автоматизации, и сопротивлением сотрудников компании из-за необходимости изучать новые средства автоматизации и временного увеличения нагрузки в процессе внедрения. Преодоление указанных проблем

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

1. Методологии внедрения систем ERP-класса

На сегодняшний день основные производители ERP систем предлагают для успешного внедрения своих продуктов специализированные методологии интеграции. Компания SAP предлагает методологию Accelerated SAP (ASAP)[1,2], компания Microsoft — Microsoft Business Solution Partner Methodology (MBS Partner) [3,4], а компания Oracle — методологию Oracle Application Implementation Methodology. В данной работе рассмотрены две методологии: ASAP — одна из наиболее проработанных; MBS Partner — одна из самых популярных в России.

1.1 Методология Accelerated SAP

Методология внедрения Accelerated SAP предназначена для поддержки планирования, управления и ведения проектов по установке систем SAP. Её цель —оптимизация времени, ресурсов и процессов для наиболее эффективного внедрения SAP решений [5, 6]. ASAP разделяется на пять фаз:

подготовка проекта (project preparation);

^ концептуальное проектирование (business blueprint);

^ реализация (realization);

^ финальная подготовка (final preparation);

^ эксплуатация и поддержка (go-live and support).

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

Цели:

^ определить цели проекта, соответствующие стратегии компании;

^ уяснить область внедрения и определить стратегию внедрения;

^ определить предварительный план проекта и порядок внедрения;

^ определить соответствующие стандарты и процедуры;

^ организация проекта;

^ определить ресурсы.

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

^ инициация проекта;

^ разработка стратегии и стандартов;

^ планирование технической инфраструктуры; ^ планирование обучения.

Результаты:

^ проект подготовлен;

^ определена область проекта.

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

Цели:

^ создать концептуальный проект и будущую бизнес-модель;

^ определить схему управления изменениями для борьбы с рисками по изменению организационной структуры;

^ пересмотреть начальные цели и задачи проекта; ^ выделить основную область проекта;

^ пересмотреть расписание проекта и порядок внедрения элементов системы;

^ пересмотреть технический проект решения.

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

^ управление проектом;

^ обучение персонала и разработка документации;

^ определение требований;

^ управление организационными изменениями; ^ сбор детальных требований;

^ разработка изменений и расширений функциональности;

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

Результаты:

^ разработан концептуальный проект;

^ разработана бизнес модель;

^ определены требуемые конфигурация, модификации и расширения функциональности;

^ установлена система для разработки.

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

Цели:

^ провести требуемую конфигурацию;

^ реализовать изменения и расширение функциональности;

^ протестировать систему;

^ определить стратегию по сдаче решения;

^ установить роли и авторизации для всей компании заказчика.

Этапы:

^ управление проектом;

^ управление изменениями;

^ обучение и разработка документации;

^ разработка основных элементов;

^ конфигурация основных элементов;

^ инсталляция системы тестирования;

^ планирование сдачи системы;

^ внедрение средств безопасности;

^ финальная конфигурация;

^ интеграционное тестирование;

^ инсталляция производственной системы;

^ тестирование производительности.

Результаты:

^ решение построено и протестировано;

^ производственная система установлена.

Финальная подготовка. Цель данной фазы: завершить подготовку системы к промышленной эксплуатации; завершить тестирование, обучение пользователей, подготовку к сдаче системы и т.д.; разрешить все критические проблемы.

Цели:

^ завершить работу над системой;

^ установить системы и процедуры по технической и функциональной поддержке пользователей.

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

^ управление проектом;

^ завершение подготовки заказчика;

^ завершение подготовки производственной системы и установка системы поддержки;

^ сдача производственной системы.

Результаты:

^ производственная система готова к эксплуатации.

Эксплуатация и поддержка. Цель данной фазы — перейти к промышленной эксплуатации системы и наладить поддержку и усовершенствование рабочих операций. В данной фазе два отдельных периода:

^ завершение проекта. В первые дни эксплуатации должны быть разрешены все возникающие проблемы, команда по поддержке должна быть введена в курс дела, передача знаний завершена и проект подписан как завершённый;

^ усовершенствование. После завершения проекта команда по поддержке осуществляет мониторинг и разрешает возникающие проблемы.

Цели:

^ получить финальное согласие заказчика;

^ наладить систему поддержки;

^ завершить проект.

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

^ управление проектом;

^ осуществление поддержки на ранних стадиях; ^ закрытие проекта.

Результаты:

^ производственная система введена в эксплуатацию;

^ налажена система поддержки.

1.2 Методология Microsoft Business Solution Partner Methodology

Методология Microsoft Business Solutions Partner Methodology разработана на основании опыта, накопленного в течение последних почти 20 лет в ходе работы по реализации большого количества проектов на предприятиях разного масштаба, в различных странах и регионах, а также в разных отраслях. Основной акцент методология делает на нуждах бизнеса заказчика, которому, в конечном итоге, необходимо решение для эффективной работы бизнеса, т.е. система управления предприятием, обеспечивающая достижение его целей. Результат проекта, согласно Microsoft Business Solutions Partner Methodology, — это работающее решение для бизнеса заказчика, а не простая настройка программного продукта.

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

^ диагностика;

^ анализ;

^ дизайн;

^ разработка и тестирование;

^ развёртывание;

^ начальное сопровождение.

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

Цели:

^ обследовать существующие бизнес-процессы заказчика;

^ собрать информацию о нуждах заказчика, его требованиях к будущему решению;

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

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

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

сбор предварительной информации (письменное анкетирование, изучение документов);

^ обследование и описание структуры предприятия, бизнес-процессов, основных целей, потребностей и ожиданий заказчика;

^ проведение серии совместных совещаний с рабочей группой заказчика для уточнения и согласования результатов предыдущего обследования, установка критериев оценки результатов проекта;

^ подготовка отчёта о диагностике;

^ представление руководству заказчика результатов диагностики и предложения на разработку и внедрение решения.

Результат:

^ отчёт о диагностике, описывающий существующие структуры и бизнес-процессы предприятия, содержащий согласованные с руководством цели, потребности бизнеса, задачи и критерии успеха для необходимого решения.

Основываясь на результатах диагностики, заказчик может принять решение о путях дальнейшей работы. Если будет принято решение о реализации предложенного партнёром проекта, то результаты, полученные на стадии диагностики, позволят:

^ эффективно и точно планировать параметры проекта, основываясь на информации, полученной в ходе диагностики;

^ сократить сроки проведения проекта и его стоимость за счёт того, что большая часть информации о предприятии заказчика уже получена.

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

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

Цели:

^ организовать проект;

^ уточнить и детализировать требования;

^ подробно проработать функциональные требования и пути их реализации;

^ уточнить оценку параметров проекта по результатам анализа.

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

^ подготовка и открытие проекта, формирование управляющего комитета для проекта, формирование проектной группы;

^ организация проекта, подготовка и согласование его общего плана, создание и утверждение устава, порядка и принципов проектной отчётности, управления проектными изменениями и рисками, сдачи-приёмки проекта;

^ организация и проведение тренинга для сотрудников клиента по базовой функциональности продукта, используемого как основа для построения решения;

^ уточнение и детализация требований к решению, бизнес-процессов заказчика;

^ выработка решений относительно изменения существующих бизнес-процессов, модификации функциональности продукта и принципах построения интерфейсов с внешними системами;

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

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

Результат:

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

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

Дизайн. Стадия дизайна даёт ответ на основные вопросы — «Как?», «Каким образом?». В документах, которые разрабатываются, согласуются и утверждаются на этой стадии, описывается концепция реализуемого решения, изменения в бизнес-процессах, модификации и расширения функциональности.

Цели:

^ создать концептуальное описание реализации

решения на основании требований к нему, описанных на стадии анализа;

& создать детальное описание изменений и оптимизации бизнес-процессов;

& детально описать принципы реализации модификаций функциональности, интерфейсов с внешними подсистемами, механизмов преобразования данных;

& уточнить оценку параметров проекта по результатам дизайна.

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

& разработка концептуального дизайна (технического задания), описывающего в терминах предметной области концепцию реализации решения, изменения функциональности и бизнес-процессов, требования по отчётности;

& согласование и утверждение концептуального дизайна заказчиком проекта;

& разработка детального дизайна (программного дизайна), описывающего в терминах системы предполагаемые модификации функциональности, интерфейсы с внешними системами, порядок тестирования разработки, порядок приёмки работ;

& согласование и утверждение детального дизайна;

& планирование порядка, сроков и ресурсов для разработки и контроля качества;

& уточнение параметров последующих стадий проекта по результатам дизайна.

Результаты:

& концептуальный дизайн;

& детальный дизайн (программный дизайн).

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

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

Разработка и тестирование. На стадии разработки и тестирования создаётся несколько различных инсталляций продукта: где будет вестись разработка, тестирование; куда будут переноситься созданные и отлаженные объекты. После завершения разработки и тестирования спроектированных на стадии дизайна модификаций и интерфейсов, производится настройка рабочей системы, перенос в неё основных

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

Цели:

& провести разработку и тестирование необходимых элементов функциональности и интерфейсов, согласно детальному дизайну и плану разработки;

& настроить рабочую среду, установить в неё все разработанные модификации и интерфейсы; & осуществить перенос справочников и входя -щего сальдо в рабочую среду;

& внедрить процедуры управления изменения -ми в программе и реакции на программные инциденты;

& уточнить оценку параметров последующих стадий проекта по результатам разработки.

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

& настройка среды для разработки, тестирования, рабочей среды для проведения последующей разработки, тестирования и интеграции результатов в рабочую систему;

& реализация модификаций и интерфейсов согласно дизайну, первоначальное тестирование разработчиками;

& передача результатов разработки заказчику для тестирования, исправление обнаруженных ошибок, корректировка требований, повторная реализация и тестирование;

& комплексное тестирование заказчиком, исправление ошибок и корректировка требований;

& установка результатов разработки в рабочую среду, настройка системы, перенос основных справочников и сальдо;

& проведение финальных испытаний и подготовка к сдаче-приемке.

Результаты:

& приложение готово к развёртыванию;

& описание конфигурации системы завершено; & получены результаты тестирования.

В случае, когда нет разработки модификаций или создаётся небольшое количество модификаций и интерфейсов, возможно применение упрощённого порядка разработки тестирования. Помимо тестирования соответствия реализованной функциональности первоначальным дизайнам, проводится тестирование производительности и объёмов.

Развёртывание. На стадии развёртывания происходит переход системы в опытно-промышленную

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

Цели:

& осуществить официальную сдачу-приёмку системы. Подтвердить достижение целей проекта; & провести подготовку пользователей к промышленной эксплуатации;

& подготовить и осуществить запуск в промышленную эксплуатацию;

& завершить проект, произвести оценку проекта заказчиком;

& перейти к сопровождению системы.

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

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

& намечается дата запуска в промышленную эксплуатацию;

& подготовка системы к запуску, контроль готовности, заведение актуальных данных;

& организация и проведение тренинга для конечных пользователей;

& запуск ежедневной обработки в новой системе операций;

& осуществление первоначальной поддержки специалистами партнёра промышленной эксплуатации системы;

& официальное завершение проекта, оценка проекта заказчиком;

& переход к сопровождению системы.

Результат:

& система, принята и запущена в промышленную эксплуатацию.

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

Цели:

^ обеспечить ежедневную поддержку работы заказчика с продуктом;

^ предоставить обновления системы;

^ организовать периодическую оценку соответствия решения требованиям Заказчика;

^ обеспечить дальнейшее развитие системы у заказчика в случае необходимости.

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

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

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

Результат:

^ поддержка и сопровождение эффективного использования решения заказчиком.

Состав и конкретные условия поддержки и сопровождения могут быть разными у различных партнёров.

2. Сравнительная характеристика методологий Accelerated SAP (ASAP) и Microsoft Business Solution (MBS) Partner Methodology

Чтобы понять общий процесс внедрения и различия, вносимые разными разработчиками, в рамках исследования произведён сравнительный анализ. В его основу положены общие цели и этапы между следующими фазами со стороны ASAP и MBS Partners:

^ подготовка проекта — диагностика;

^ концептуальное проектирование — анализ + дизайн;

^ реализация — разработка и тестирование;

^ финальная подготовка — развертывание;

^ эксплуатация и поддержка — начальное сопровождение.

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

Таблица 1

Сравнительный анализ методологий ASAP и MBS Partners

Фаза ASAP Microsoft (MS)

Подготовка проекта/ Диагностика Общие черты

Цели: ♦ определить цели и область внедрения; ♦ организовать команду для работ. Этапы: ♦ инициация проекта; ♦ работа над инфраструктурой.

Различия

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

Работа над инфраструктурой направлена на разработку плана технической инфраструктуры Работа над инфраструктурой направлена на оценку существующей у клиента инфраструктуры.

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

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

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

Сильные стороны

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

Слабые стороны

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

Выводы

Фазы достаточно сильно различаются за счёт изначальной предпосылки: ASAP предполагает, что заказчик уже полностью согласен на внедрение; MS рассматривает ситуацию с клиентом, которому ещё требуется обоснование для внедрения системы. В реальности чаще встречается вторая ситуация, когда клиент не уверен в своём выборе. Однако в этом случае всегда существует вероятность, что после предоставления проекта, клиент откажется от предлагаемого решения и время будет потеряно. Если решение удовлетворяет клиента, требуется подробная проработка проекта с точки зрения управления.

см. продолжение

Продолжение таблицы 1

Фаза ASAP Microsoft (MS)

Концептуальное проектирование/ Анализ + Дизайн Общие черты

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

Предполагается использование инструментальных средств для описания бизнес-моделей. Процесс описания требований происходит через переход от бизнес-модели AS-IS к модели TO-BE. Требуется чётко определить требуемые модификации и расширения функциональности.

Различия

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

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

Отдельным этапом выделяется управление рисками

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

Отдельным этапом выделяется определение требований безопасности

Отдельным этапом выделяется подготовка системы для проведения разработок

Сильные стороны

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

Для описания модели TO-BE предоставляется набор предопределённых сценариев

Чётко определены категории требований, которые должны быть описаны

Слабые стороны

Очень загруженная фаза; необходимо пройти практически весь процесс бизнес-анализа Недостаточная конкретизация требований

Выводы

Фазы достаточно близки за счёт общей цели: разработать детальные требования и концептуальный проект требуемого решения. При этом используется один и тот же метод: реинжиниринг бизнес-процессов. Однако ASAP - более подробная методология и требует описать более широкий спектр требований, а также спецификацию конфигурации для всех бизнес-процессов и элементов. MS не требует описания необходимой конфигурации, а основной акцент ставит на получение чёткой TO-BE модели и описание расширений и модификации функциональности.

см. продолжение

Продолжение таблицы 1

Фаза ASAP Microsoft (MS)

Реализация / Общие черты

Разработка и тестирование Цели: ♦ провести разработку и тестирование; ♦ установить производственную среду. Общие шаги и этапы: ♦ управление проектом; ♦ реализация; ♦ тестирование компонентов; ♦ интеграционное (системное) тестирование.

Предполагается итерактивный подход к разработке и тестированию компонентов. Завершающее тестирование проводится с участием заказчиков. Выделяется две отдельных системы: для разработки и для тестирования. Обязательный шаг - установка производственной системы.

Различия

Проектирование конфигурации произведено в предыдущей фазе. В рамках данной фазы выделяется этап по проектированию конфигурации.

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

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

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

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

Выделяется отдельный этап по планированию сдачи проекта и поддержки.

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

Выделяется отдельный этап по интеграции конфигурации и расширению функциональности.

Сильные стороны

Итерационный подход. Итерационный подход.

Отдельные этапы по внедрению систем безопасности, интеграции конфигурации и расширению функциональности. Большее привлечение заказчика.

Слабые стороны

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

Интеграционное тестирование проводиться на производственной системе.

Выводы

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

см. окончание

Окончание таблицы 1

Фаза ASAP Microsoft (MS)

Финальная Общие черты

подготовка/ Развертывание Цели: ♦ завершить работу над системой; ♦ завершить подготовку пользователей; ♦ провести сдачу проекта;

Различия

Требуется транспортирование данных. Транспорт данных проводится на предыдущей фазе.

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

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

Обучение пользователей завершается. Обучение пользователей проводится и завершается.

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

Сильные стороны

Делается акцент на систему поддержки. Фаза представляет собой завершение проекта по внедрению.

Слабые стороны

Фаза может затянуться за счёт транспорта данных Фактически всё обучение пользователей проводится в данной фазе. Это может сильно затянуть работу.

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

Выводы

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

Эксплуатация Общие черты

и поддержка/ Начальное сопровождение Цели и этапы: ♦ обеспечить систему поддержки

Различия

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

Проводится ввод в эксплуатацию Ввод эксплуатацию проведён

Выделяется этап по завершению проекта Формально проект уже завершен

Сильные стороны

Ввод в эксплуатацию системы и системы поддержки осуществляется одновременно

Слабые стороны

Система поддержки вводится в работу позже, чем производственная система

Выводы

Фазы достаточно сильно различаются за счёт того, что в ДБДР на этой фазе проходит и ввод в эксплуатацию, и начало работы системы поддержки. Это логичнее и позволяет более чётко вести работу и осуществлять поддержку.

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

3. Унифицированный процесс внедрения систем ERP-класса

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

На этапе «Предварительный анализ» (рис.2) необходимо обработать запрос клиента, выполнив следующие действия:

& сформировать рабочую группу (требуется привлечь сотрудников клиента и компании-интегратора);

& определить предварительную область, цели и ожидаемые результаты проекта;

& определить высоко уровневые бизнес-требования;

& оценить инфраструктуру заказчика и сформи-

Этот подход подчёркивает основные активности и этапы, которые должны быть пройдены для успешного внедрения.

В процессе внедрения систем БКР-класса выделить шесть стадий:

& предварительный анализ;

& инициация проекта;

& концептуальное проектирование;

& реализация и тестирование;

& внедрение;

& эксплуатация и поддержка.

ровать предложение по её реорганизации (требуется для оценки сроков и стоимости проекта);

& определить концепцию предлагаемого решения и представить её заказчику (предоставить схему решения, оценку сроков и стоимости).

После этого клиент должен решить, подходит ли это решение его предприятию. В случае согласия необходимо перейти к этапу «Инициация проекта» (рис. 3). Особенность предлагаемого подхода в том,

Рис. 1. Стадии унифицированного процесса внедрения

Рис. 2. Предварительный анализ

Рис. 3. Инициация проекта

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

На этом этапе необходимо:

^ точно определить область, цели и результаты проекта;

^ определить стандарты и стратегии (внедрения, подготовки пользователей, миграции данных и т.д.);

^ подготовить инфраструктуру для концептуального проектирования (установить систему, создать пользователей);

^ спланировать обучение пользователей;

^ подготовить документы по управлению проектом (устав проекта, расписание, бюджеты, планы управления и т.д.);

^ утвердить все подготовленные документы.

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

^ построить А8-К бизнес-модель;

^ построить ТО-ВЕ-модель;

^ провести анализ несоответствий;

^ сформулировать требования;

^ определить требуемую конфигурацию;

^ определить требуемое расширение функциональности;

^ подготовить шаблоны документов и материалов для обучения пользователей;

^ подготовить инфраструктуру для разработки (установить систему, создать пользователей); ^ утвердить концептуальный проект.

После разработки и утверждения концептуального проекта (рис. 5) необходимо:

^ реализовать основную конфигурацию;

^ реализовать модификации и расширения функциональности;

^ реализовать финальную конфигурацию;

^ подготовить инфраструктуру для тестирования;

^ протестировать систему;

* подготовить инфраструктуру производственной системы;

* подготовить документацию и материалы для обучения.

Рис. 4. Разработка концептуального проекта

Рис. 5. Реализация и тестирование

Рис. 6. Внедрение в эксплуатацию

Протестированную систему можно внедрять в эксплуатацию (рис. 6). Для этого необходимо:

^ перенести конфигурацию и модификации в производственную систему;

^ перенести данные;

^ провести финальное тестирование;

^ утвердить финальный вариант системы;

^ провести обучение;

^ спланировать систему поддержки клиента.

Если все этапы пройдены без проблем, систему можно использовать (рис. 7). Предварительно необходимо:

^ установить систему по поддержке клиента;

^ провести сдачу системы;

^ провести первоначальную поддержку;

^ осуществить закрытие проекта.

Рис. 7. Эксплуатация и поддержка

Заключение

Рассмотрены методологии Accelerated SAP и Microsoft Business Solution Partner Methodology. Сравнительный анализ показал основные сходства и различия данных методологий. На основе полученных результатов построен унифицированный процесс внедрения систем ERP-класса.

Внедрение ERP-систем — не менее сложный процесс, чем разработка. Для успешного проведе-

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

Литература

1. Помощь по средству Solution Manager http://help.sap.com/saphelp_sm310/helpdata/en/index.htm.

2. Описание методологии ASAP http://service.sap.com/education/asap/index.com

3. Описание методологии Microsoft Business Solution Partner Methodology http://www.microsoft.com/Rus/Dynamics/Application/Default.mspx.

4. Описание методологии Microsoft Business Solution Partner Methodology http://www.microsoft.com/Rus/Dynamics/Applica-tion/Default.mspx.

5. Linda K. Lau, Managing Business with SAP: Planning, Implementation, and Evaluation.

6. Вивек Кале, Внедрение SAP R/3. Руководство для менеджеров и инженеров.