Книги, научные публикации

СОЗДАНИЕ УНИФИЦИРОВАННОЙ МЕТОДОЛОГИИ РАЗРАБОТКИ ERP систем НА ОСНОВЕ СРАВНИТЕЛЬНОГО АНАЛИЗА РЕШЕНИЙ SAP и MICROSOFT Э.А. Бабкин, к.т.н., заведующий кафедрой информационных систем и технологий факультета

бизнес информатики и прикладной математики Нижегородского филиала Государственного университета - Высшей школы экономики babkin Е.О. Потапова, студентка магистратуры факультета бизнес информатики и прикладной математики Нижегородского филиала Государственного университета - Высшей школы экономики Методологии интеграции информационных систем ориентированы на использование определенного инструментария конкретного производителя. В рамках данной работы построена нейтральная методология разработки ERP систем. Основа такой методологии - результаты анализа решений компаний SAP и Microsoft.

Введение лежит на путях построения нейтральной методоло nterprise Resource Planning (ERPЦсистемы) гии разработки или интеграции ERP систем, основ в настоящее время - привычный инструмент ные принципы которой рассмотрены ниже.

Eуправления в крупных и средних компаниях.

Цель их внедрения - повышение управляемости 1. Методологии внедрения систем ERP класса бизнеса, увеличение его эффективности. Однако На сегодняшний день основные производители статистика показывает, что успешными оказывают ERP систем предлагают для успешного внедрения ся только 16% внедрений;

в 30% случаев внедрение своих продуктов специализированные методологии ERP системы приостанавливается, а в 54% - суще интеграции. Компания SAP предлагает методоло ственно пересматривается бюджет и отодвигаются гию Accelerated SAP (ASAP)[1,2], компания Micro сроки. soft - Microsoft Business Solution Partner Methodolo Основные проблемы при внедрении ERP систем: gy (MBS Partner) [3,4], а компания Oracle - методо несогласованные действия участников проекта;

логию Oracle Application Implementation Methodolo ошибки планирования работ в проекте и техниче gy. В данной работе рассмотрены две методологии:

ских аспектов интеграции с другими информацион ASAP - одна из наиболее проработанных;

MBS ными системами;

несоответствие результатов вне Partner - одна из самых популярных в России.

дрения проектным требованиям. Трудности при вне дрении могут быть обусловлены необходимостью 1.1 Методология Accelerated SAP адаптации структуры и процессов компании к требо Методология внедрения Accelerated SAP пред ваниям, предъявляемым новыми средствами автома назначена для поддержки планирования, управле тизации, и сопротивлением сотрудников компании ния и ведения проектов по установке систем SAP.

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

БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г. подготовка проекта (project preparation);

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

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

blueprint);

обучение персонала и разработка докумен реализация (realization);

тации;

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

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

эксплуатация и поддержка (go live and sup управление организационными изменениями;

port). сбор детальных требований;

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

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

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

Важно учитывать цели управления и технические детали. Результаты:

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

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

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

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

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

тегию внедрения;

определить предварительный план проекта и Реализация. Цель данной фазы - реализовать порядок внедрения;

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

изменения в систему, провести все необходимое организация проекта;

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

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

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

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

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

реализовать изменения и расширение функ планирование технической инфраструктуры;

циональности;

планирование обучения. протестировать систему;

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

Результаты: установить роли и авторизации для всей ком проект подготовлен;

пании заказчика.

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

Этапы:

Концептуальное проектирование. Основная цель управление проектом;

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

системы - подробное описание всех требований обучение и разработка документации;

к решению и будущей бизнес модели системы. разработка основных элементов;

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

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

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

бизнес модель;

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

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

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

зационной структуры;

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

пересмотреть начальные цели и задачи проекта;

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

выделить основную область проекта;

пересмотреть расписание проекта и порядок Результаты:

внедрения элементов системы;

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

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

4 БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г.

Финальная подготовка. Цель данной фазы: 1.2 Методология Microsoft Business Solution Partner завершить подготовку системы к промышленной Methodology эксплуатации;

завершить тестирование, обучение Методология Microsoft Business Solutions Partner пользователей, подготовку к сдаче системы и т.д.;

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

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

екта, согласно Microsoft Business Solutions Partner завершение подготовки заказчика;

Methodology, - это работающее решение для бизне завершение подготовки производственной са заказчика, а не простая настройка программного системы и установка системы поддержки;

продукта.

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

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

Эксплуатация и поддержка. Цель данной фазы - анализ;

перейти к промышленной эксплуатации системы и дизайн;

наладить поддержку и усовершенствование рабочих разработка и тестирование;

операций. В данной фазе два отдельных периода: развёртывание;

завершение проекта. В первые дни эксплуата начальное сопровождение.

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

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

торинг и разрешает возникающие проблемы.

Цели:

Цели: обследовать существующие бизнес процессы получить финальное согласие заказчика;

заказчика;

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

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

предложить эффективное решение для удо Основные этапы: влетворения потребностей бизнеса заказчика;

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

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

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

Результаты:

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

тацию;

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

БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г. сбор предварительной информации (письмен Цели:

ное анкетирование, изучение документов);

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

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

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

бования и пути их реализации;

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

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

результатов проекта;

подготовка и открытие проекта, формирова подготовка отчёта о диагностике;

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

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

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

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

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

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

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

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

Если заказчик по каким либо причинам пред Результат:

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

дрения.

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

казчика, которые должны быть включены в проект.

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

определяется оптималь модификации и расширения функциональности.

ный способ реализации для каждого бизнес про цесса, принимается решение об объёме доработок Цели:

и модификаций, изменениях в бизнес процессах. создать концептуальное описание реализации 6 БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г.

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

опытно промышленной эксплуатации.

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

Цели:

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

разработки;

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

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

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

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

стадий проекта по результатам разработки.

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

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

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

порядок тестирования разработки, порядок реализация модификаций и интерфейсов со приёмки работ;

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

дизайна;

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

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

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

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

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

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

чик может принять решение о путях дальнейшей работы и о реализации предложенного партнёром Результаты:

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

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

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

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

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

ки и тестирования спроектированных на стадии ди зайна модификаций и интерфейсов, производится Развёртывание. На стадии развёртывания проис настройка рабочей системы, перенос в неё основных ходит переход системы в опытно промышленную БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г. эксплуатацию. Если должно быть произведено ти Цели:

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

правило, на этом этапе происходит официальное предоставить обновления системы;

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

Цели: обеспечить дальнейшее развитие системы у осуществить официальную сдачу приёмку си заказчика в случае необходимости.

стемы. Подтвердить достижение целей проекта;

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

шленной эксплуатации;

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

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

заказчиком;

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

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

ние и организация новых проектов.

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

Результат:

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

использования решения заказчиком.

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

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

партнёров.

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

Accelerated SAP (ASAP) и Microsoft Business официальное завершение проекта, оценка Solution (MBS) Partner Methodology проекта заказчиком;

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

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

Начальное сопровождение. На стадии сопровож концептуальное проектирование - анализ + дения осуществляется поддержка начального пе дизайн;

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

окончании начального сопровождения заказчик финальная подготовка - развертывание;

переходит на регулярное сопровождение;

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

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

8 БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г.

Таблица Сравнительный анализ методологий ASAP и MBS Partners Фаза ASAP Microsoft (MS) Общие черты Подготовка проекта/ Диагностика :

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

организовать команду для работ.

:

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

работа над инфраструктурой.

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

разрабатываются, но не в первую очередь.

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

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

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

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

Сильные стороны Подробное описание шагов по управлению проектом.

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

пользователей.

Разработка стандартов.

Слабые стороны Не просматривается вовлечение клиента.

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

без анализа среды заказчика.

Выводы Фазы достаточно сильно различаются за счёт изначальной предпосылки: ASAP предполагает, что заказчик уже полностью согласен на внедрение;

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

.

БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г. Продолжение таблицы Фаза ASAP Microsoft (MS) Общие черты Концептуальное проектирование/ :

Анализ + Дизайн уточнить и детализировать требования;

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

разработать будущую бизнес модель.

:

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

обучение участников команды;

определение функциональных требований.

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

Процесс описания требований происходит через переход от бизнес модели AS IS к модели TO BE.

Требуется чётко определить требуемые модификации и расширения функциональности.

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

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

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

.

10 БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г.

Продолжение таблицы Фаза ASAP Microsoft (MS) Общие черты Реализация / Разработка и :

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

установить производственную среду.

:

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

реализация;

тестирование компонентов;

интеграционное (системное) тестирование.

Предполагается итерактивный подход к разработке и тестированию компонентов.

Завершающее тестирование проводится с участием заказчиков.

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

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

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

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

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

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

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

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

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

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

Сильные стороны Итерационный подход. Итерационный подход.

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

и расширению функциональности.

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

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

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

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

.

БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г. Окончание таблицы Фаза ASAP Microsoft (MS) Общие черты Финальная подготовка/ :

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

завершить подготовку пользователей;

провести сдачу проекта;

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

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

фазе.

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

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

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

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

внедрению.

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

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

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

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

Общие черты Эксплуатация и поддержка/ Цели и этапы:

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

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

12 БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г.

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

работы. Методология Microsoft делает акцент на ра В процессе внедрения систем ERP класса выде боте с клиентами, которые должны быть переведе лить шесть стадий:

ны из клиентов в непосредственные заказчики. предварительный анализ;

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

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

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

В результате сравнения и с учётом достоинств и внедрение;

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

фицированный подход к внедрению ERP систем.

. 1. Стадии унифицированного процесса внедрения На этапе Предварительный анализ (рис.2) ровать предложение по её реорганизации необходимо обработать запрос клиента, выполнив (требуется для оценки сроков и стоимости следующие действия: проекта);

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

схему решения, оценку сроков и стоимости).

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

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

необходимо перейти к этапу Инициация проекта оценить инфраструктуру заказчика и сформи (рис. 3). Особенность предлагаемого подхода в том, БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г.. 2. Предварительный анализ. 3. Инициация проекта 14 БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г.

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

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

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

предварительную оценку проекта. определить требуемое расширение функцио На этом этапе необходимо: нальности;

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

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

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

данных и т.д.);

утвердить концептуальный проект.

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

ного проекта (рис. 5) необходимо:

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

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

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

планы управления и т.д.);

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

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

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

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

построить AS IS бизнес модель;

* подготовить документацию и материалы для построить TO BE модель;

обучения.

. 4. Разработка концептуального проекта БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г.. 5. Реализация и тестирование. 6. Внедрение в эксплуатацию 16 БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г.

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

необходимо:

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

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

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

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

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

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

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

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

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

. 7. Эксплуатация и поддержка Заключение Рассмотрены методологии Accelerated SAP ния проектов по внедрению недостаточно исполь и Microsoft Business Solution Partner Methodology. зовать чистые методологии, предлагаемые по Сравнительный анализ показал основные сходства ставщиками самих систем. Напротив, один из обя и различия данных методологий. На основе полу зательных этапов - адаптация данных методологий ченных результатов построен унифицированный и разработка методов поддержки процессов на ос процесс внедрения систем ERP класса. нове инструментальных средств, поставляемых Внедрение ERP систем - не менее сложный компаниями.

процесс, чем разработка. Для успешного проведе Литература 1. Помощь по средству Solution Manager 2. Описание методологии ASAP 3. Описание методологии Microsoft Business Solution Partner Methodology 4. Описание методологии Microsoft Business Solution Partner Methodology tion/Default.mspx.

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

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

БИЗНЕС ИНФОРМАТИКА №3(05)Ц2008 г.    Книги, научные публикации