ГЛАВА 12 Методология AcceleratedSAP
ГЛАВА 12
Методология AcceleratedSAP
В этой главе представлена новаторская методология внедрения, которую компания SAP разработала для сокращения длительности проектов внедрения в сравнении с методологией процедурной модели R/3 (см. раздел «Методологии внедрения SAP» в главе 5). Ускоренная методология в основном предназначается для малых и средних предприятий.
Принцип многократного использования всегда был одним из краеугольных камней философии SAP. Как уже упоминалось в главе 1, библиотека 800 лучших в своем классе практик и процессов, которая поставляется с каждой лицензией SAP, является воплощением этого принципа.
Несмотря на то, что универсальность и гибкость систем SAP позволяют удовлетворять требованиям самых различных отраслей, разумные временные рамки внедрения SAP — один из важнейших факторов, который должна принять во внимание компания при оценке возможности внедрения SAP R/3. По мере того, как сектор высокотехнологичных, дорогостоящих систем на рынке информационных технологий все более насыщался в 90-е годы, стал проявляться потенциал SAP в секторе малых и средних предприятий. Такого рода клиенты не располагают достаточными ресурсами и временем, чтобы предпринимать проекты внедрения ERP-систем, которые могут длиться от двух до трех лет.
В 1996 году компания SAP представила методологию AcceleratedSAP (ASAP), нацеленную на значительное ускорение проектов внедрения. Методология ASAP позволила новым клиентам воспользоваться опытом и профессиональными знаниями, благодаря огромному числу внедрений по всем миру. В этой главе представлена концепция и реализация методологии ASAP при внедрении SAP R/3.
Почему проекты внедрения SAP столь сложны?
Основная причина большой длительности проектов внедрения SAP кроется в высокой степени сложности этого программного продукта. Взаимоисключающие требования всеохватности и гибкости должным образом соблюдены в системах SAP благодаря их архитектуре, ориентированной на хранилище информации (в этой главе основной акцент будет делаться на функциональных аспектах такого хранилища, хотя технические аспекты не менее важны). В общем и целом эта архитектура не так уж чужда параметризованным системам, которые распространялись в составе пакетов прикладного программного обеспечения с 80-х годов. Однако степень параметризации абсолютно другая — системы SAP максимально параметризованы, что позволяет им быть достаточно гибкими и удовлетворять требованиям нескольких отраслей, для каждой из которых система может конфигурироваться особо.
Одна из трудностей при внедрении SAP — зависимость успеха проекта от правильного отслеживания бизнес-процессов и составления карт процессов для SAP, что подразумевает корректную конфигурацию всех процессов на самой ранней, начальной стадии внедрения. Как уже упоминалось выше, SAP решает задачу предоставления полноценного программного продукта, опуская весьма проблематичную стадию составления и анализа требований к системе, которая всегда была ахиллесовой пятой жизненного цикла разработки традиционных систем (см раздел «Концепция систем планирования ресурсов в масштабе предприятия» в главе 1). Однако из-за возникающей на самой ранней стадии проекта необходимости конфигурации, мы, по существу, сталкиваемся с той же самой проблемой.
Большинство факторов риска при реализации проекта также зависит от полного, согласованного и корректного отслеживания и составления карт бизнес-процессов в самом начале проекта. В отличие от традиционного жизненного цикла разработки программного обеспечения, которые подразумевает, что конечные пользователи осведомлены только о своих непосредственных требованиях; в новых условиях они должны достаточно близко ознакомиться с функциональностью SAP. Система SAP — очень гибкая, но для ее правильной конфигурации необходимо не только знать требования компании по бизнес-процессам, но и разобраться с функциональностью SAP еще до того, как приступать к конфигурации. В стандартных проектах SAP это справедливо для самых ранних стадий проекта, и именно здесь кроется причина того, что для составления карт процессов и конфигурации базовой системы SAP требуется столько усилий и времени. Хотя SAP может содержать в себе абсолютно всю необходимую функциональность, может потребоваться достаточно долгое время прежде чем все смогут с ней ознакомиться и начать использовать в работе.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКЧитайте также
1.2. Методология объектно-ориентированного программирования
1.2. Методология объектно-ориентированного программирования Со временем ситуация стала существенно изменяться. Оказалось, что трудоемкость разработки программных приложений на начальных этапах программирования оценивалась значительно ниже реально затрачиваемых
1.3. Методология объектно-ориентированного анализа и проектирования
1.3. Методология объектно-ориентированного анализа и проектирования Необходимость анализа предметной области до начала написания программы была осознана давно при разработке масштабных проектов. Процесс разработки баз данных существенно отличается от написания
1.4. Методология системного анализа и системного моделирования
1.4. Методология системного анализа и системного моделирования Системный анализ как научное направление имеет более давнюю историю, чем ООП и ООАП, и собственный предмет исследования. Центральным понятием системного анализа является понятие системы, под которой
Методология и ее автор
Методология и ее автор "Любая методология основывается на страхе", - написал как-то Кент Бек в одном из обсуждений методологий. Поначалу это замечание показалось мне малозначительным, но потом я понял, что в большинстве случаев, оно совершенно справедливо. Каждый элемент
Каждому проекту своя методология
Каждому проекту своя методология В предыдущих разделах статьи мы уже показали, что существует множество различных методологий (и это совершенно естественно) - см. рис. 5. Все они отличаются друг от друга с точки зрения количества занятых в проекте людей, критичности
ГЛАВА 1
ГЛАВА 1 Файлы и права доступа к нимЕсли вы не хотите, чтобы кто угодно получал доступ к вашим файлам, изучите назначение битов режима. Благодаря им можно управлять доступом к файлам и каталогам, а также указывать тип доступа к создаваемым файлам. Это лишь небольшая часть
Реинжиниринг бизнес-процессов и AcceleratedSAP
Реинжиниринг бизнес-процессов и AcceleratedSAP Если компания использует методологию ускоренного внедрения (AcceleratedSAP), крайне нежелательно, если BPR совпадает с внедрением SAP. Рекомендуется сначала внедрить SAP в стандартной комплектации.Когда компания использует методологию
Методология Реинжиниринга бизнес-процессов предприятия
Методология Реинжиниринга бизнес-процессов предприятия В этом разделе мы рассмотрим полный цикл методологии Реинжиниринга бизнес-процессов предприятия и определим ситуации, в которых SAP может способствовать проводимому на предприятии BPR, состоящему из 8
Методология проведения теста
Методология проведения теста Напомним, что качество эвристики определяется способностью антивируса распознавать модифицированный вредоносный код. Фактически, эвристика предполагает обнаружение вируса, которого нет в базах: по специальным алгоритмам и некоторым
Глава 4 Методология
Глава 4 Методология В этой главе обсуждаются следующие темы: • Суть методологии исследования уязвимости • Значение экспертизы исходного текста программы • Технологии реинжиниринга • Тестирование методом «черного ящика» · Резюме · Конспект · Часто задаваемые вопросы
12.4. МЕТОДОЛОГИЯ УПРАВЛЕНИЯ ПРОЕКТОМ
12.4. МЕТОДОЛОГИЯ УПРАВЛЕНИЯ ПРОЕКТОМ Взаимодействие в команде. Ответственность за проект несет разработчик, а не начальник отдела. Начальники являются членами команды — последнее слово в некоторых важных вопросах принадлежит им. Однако на самом деле проектом управляет