В этой главе представлена новаторская методология внедрения, которую компания 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 благодаря их архитектуре, ориентированной на хранилище информации (в этой главе основной акцент будет делаться на функциональных аспектах такого хранилища, хотя технические аспекты не менее важны). В общем и целом эта архитектура не так уж чужда параметризованным системам, которые распространялись в составе пакетов прикладного программного обеспечения с 80-х годов. Однако степень параметризации абсолютно другая — системы SAP максимально параметризованы, что позволяет им быть достаточно гибкими и удовлетворять требованиям нескольких отраслей, для каждой из которых система может конфигурироваться особо.

Одна из трудностей при внедрении SAP — зависимость успеха проекта от правильного отслеживания бизнес-процессов и составления карт процессов для SAP, что подразумевает корректную конфигурацию всех процессов на самой ранней, начальной стадии внедрения. Как уже упоминалось выше, SAP решает задачу предоставления полноценного программного продукта, опуская весьма проблематичную стадию составления и анализа требований к системе, которая всегда была ахиллесовой пятой жизненного цикла разработки традиционных систем (см раздел «Концепция систем планирования ресурсов в масштабе предприятия» в главе 1). Однако из-за возникающей на самой ранней стадии проекта необходимости конфигурации, мы, по существу, сталкиваемся с той же самой проблемой.

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

Как и в более ранней методологии внедрения SAP, известной как «процедурная модель», в ASAP вся конфигурация осуществляется в среде, называемой «Руководство по внедрению» (Implementation Guide, IMG), которая не сильно отличается от модулей инициализации в традиционных компьютерных системах, хотя и значительно превосходит их по размерам. В SAP предусмотрено более 8000 таблиц конфигурации. Все бизнес-процессы компании могут внедряться в функциональность системы SAP посредством конфигурации параметров в IMG. Во время внедрения любого процесса необходимо идентифицировать параметры, которые нужно будет задать, прежде чем процесс сможет работать в системной среде. Например, при создании счета-фактуры необходимо сначала указать параметры налогообложения и задать их с помощью IMG. Общий процесс идентификации параметров, отвечающих требованиям компании, известен как внесение настроек и также осуществляется с помощью IMG. Впрочем, существенная проблема состоит в том, что в интегрированных системах, сходных с SAP, не существует систематизированного способа быстрой и исчерпывающей идентификации всех параметров, необходимых при внедрении.

Как станет ясно после прочтения раздела, «Руководство по внедрению (IMG)», IMG структурировано таким образом, что отражает последовательность, с которой должны задаваться параметры, но, по большому счету, этого недостаточно для быстрого внесения настроек в SAP. Для стандартной команды проекта SAP идентификация сотен параметров и их последовательности в довольно жестких временных рамках зачастую представляет весьма трудновыполнимую задачу. Это скорее не систематический процесс, а опыт открытий — при том, что количество параметров, которые необходимо идентифицировать и задать, весьма значительно. Во избежание ошибок, команды проектов обычно занимают оборонительную позицию, проверяя и перепроверяя каждый мелкий аспект перед тем, как сделать следующий шаг (хотя и это не гарантирует того, что ничего не будет упущено). Это увеличивает необходимые для завершения проекта затраты времени, попутно теряются все преимущества, которые дает концепция информационных систем как товаров на полках супермаркета (см. соответствующий раздел в главе 1). Очевидное средство преодоления этой проблемы и ускорения внедрения SAP — в решении двух вопросов:

• Сокращение разрыва между требованиями компании и технологией тех процессов компании, которые необходимо внедрить, с одной стороны — и функциональностью SAP и возможными IMG-настройками с другой стороны.

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

Как уже упоминалось в этой книге, такие ориентированные на хранилище информации системы, как SAP, продолжают традицию работы со средой автоматизированной разработки программного обеспечения (Computer-aided software engineering, CASE). Похожим образом второй из приведенных выше пунктов относится к среде автоматизированного внедрения программных продуктов (Computer-aided software implementation, CASI), которую мы рассмотрим в следующем разделе.

Методология ASAP — это классический пример CASE-среды, которая направлена на ускорение проекта внедрения с помощью опыта, накопленного за время предыдущих проектов SAP, и нацелена на дальнейший прогресс в этом направлении. Среда включает в себя два аспекта: во-первых, непосредственно CASE; во-вторых, интерактивная, «умная» помощь пользователю. В следующих абзацах мы вкратце рассмотрим контексты среды CASE и Экспертной системы (Expert System), чтобы понять их роль и развитие в рамках окружения ERP-систем в общем и ASAP, в частности.

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

Получившая развитие в последние годы технология CASE состоит из следующих компонентов:

• Методы

• Среда инструментов.

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

Такие компоненты среды SAP, как Базис, Хранилище R/3 (которые включают в себя современные инструменты — словарь АВАР/4, АРМ Разработчика, САТТ, Панель управления и т. д.) или Business Engineer (который включает в себя Справочную модель R/3, Бизнес-навигатор и Процедурную модель) в совокупности составляют среду CASE высочайшего уровня.

Как уже говорилось в главе 1, SAP — это не только лучшая в своем классе среда CASE, это хорошо проработанная, «обитаемая» среда CASE, потому что ее Хранилище заполнено подробной информацией о наиболее всеохватной системе приложений.

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

• База знаний

• Система предпосылок, которая «обучается» и становится все более и более точной, основываясь на степени достоверности полученных ранее результатов. Такое «обучение» могло выражаться в изменении приоритетов существующих, создании новых правил или даже в обновлении самой базы знаний.

В традиционном смысле ASAP — это не экспертная система, но она включает в себя основные составляющие базы знаний и системы предпосылок или предполагаемых действий. В некоторых случаях ASAP автоматически влияет на действия внутри системы SAP (см раздел «Инициализация IMG» в главе 14). База знаний ASAP продолжает обновляться на основе последних полученных эмпирическим путем данных и опыта внедрения SAP, хотя в настоящее время это не такое динамичное, автоматическое обновление, какое можно обнаружить в услугах SAP GoingLive Check или EarlyWatch Alert. Компания SAP регулярно выпускает CD-ROM с последними обновлениями этой базы знаний — однако вполне возможно, что уже в ближайшем будущем ASAP станет такой же электронной услугой, доступной в режиме он-лайн, или полноценной экспертной системой с характерными свойствами, возможностями и интерфейсами.

Представленная в 1996 году методология быстрого внедрения и постоянной оптимизации ASAP состоит из методологии Сетевого графика (Roadmap), который связан с такими инструментами, как IMG, причем ASAP задумывалась специально для средних и малых предприятий, которые не могут отводить на внедрение длительное время.

Как уже упоминалось выше, принцип многократного использования — это один из ключевых аспектов ASAP. Как и библиотека 800 лучших в своем классе процессов, ASAP — это хранилище лучшего опыта и рекомендаций, накопленных во время тысяч инсталляций за последние 5 лет. Более того — как говорилось в разделе «Информация как новый ресурс» в главе 1, обработанная ERP-системой информация выступает как полноценный ресурс, который ускоряет операционные процессы без необходимости расхода традиционных ресурсов. Так как ASAP аккумулирует технологию и опыт прошлых инсталляций, эта информация используется для ускорения самого процесса внедрения как бизнес-процесса!

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

Методология Сетевого графика также включает в себя задачи по управлению изменениями и акселераторы, необходимые для управления изменениями на предприятии, вызванными внедрением SAP. Эта методология предлагает мероприятия, которые улучшают осведомленность о возможных эффектах от внедрения SAP, а также подсказки и принципы для управления изменениями. Методология ASAP — это совокупность всех знаний и опыта компании SAP, ее клиентов и партнеров по внедрению. На рис. 12.1 представлена стартовая страница ASAP для версии 4.0В.

Рис. 12.1. Стартовая страница ASAP.

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

• Сетевой график ASAP — это пошаговая методология для успешного завершения проекта SAP.

• Инструменты ASAP — инструменты управления проектом, опросные листы для консультантов по бизнес-процессам, а также многочисленные руководства и списки контрольных вопросов.

• Услуги, поддержка и обучение R/3 — в том числе услуги по консалтингу, обучению и техподдержке — например, проверка перед пуском системы (GoingLive Check), удаленный апгрейд ПО или архивирование и т. д.

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

• Это проверенная методология, которая зарекомендовала себя в сотнях проектов в США и впоследствии во всем мире.

• Это процессовый компонент TeamSAP (остальные компоненты — люди и продукты)

• Это всеобъемлющая, монолитная методология, которая обеспечивает интеграцию всех стадий проекта.

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

• Эта методология поддерживает три основные роли для гарантии того, что ни один аспект быстро развивающегося проекта не будет обойден вниманием — а именно, управление проектом, консалтинг по приложениям и техническое внедрение.

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

• По всему миру насчитывается более 10000 сертифицированных консультантов по ASAP.

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

Подготовка проекта

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

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

Фаза Концептуального проектирования подразумевает окончательное определение и документирование требований компании. Консультанты и члены команды проекта проводят собеседования и собрания по разным областям деятельности для подтверждения требований компании относительно тех или иных бизнес-процессов. Демонстрируется функциональность R/3 с помощью системы IDES (Information and Design Education), причем демонстрация сопровождается заполнением опросных листов и диаграмм процессов из R/3 Business Engineer. Определяются пробелы между требованиями и предоставляемой функциональностью и вырабатываются соответствующие меры. Результатом этого этапа проекта должен стать документ под названием «Концептуальный проект» (Business Blueprint), с детализацией имеющих место процессов, письменного и графического представления структуры и бизнес-технологий компании. После утверждения этот документ становится основой для всего проекта.

Реализация

Цель данного этапа — конфигурация базовой системы с учетом требований Концептуального проекта посредством IMG. Для этого бизнес-процессы группируются в циклы связанных между собой процессов; система документируется с помощью R/3 Business Engineer. Подготовленная на данном этапе базовая система в дальнейшем становится основой рабочей системы.

Кроме того, на этапе Реализации команда проекта проходит обучение 3-го уровня. Система представляется команде главных пользователей, которые также изучают модули, относящиеся к сфере их деятельности. Базовая система окончательно отлаживается и утверждается главными пользователями с использованием математического подхода. Техническая команда организует системное администрирование, планирует интерфейсы и перенос данных. Определяются и тестируются интерфейсы, конвертеры, усовершенствования, отчеты, документация для конечных пользователей, сценарии тестирования и профили прав доступа. Результатом этого этапа должна быть полностью сконфигурированная, проверенная система SAP, которая отвечает всем требованиям компании.

Окончательная подготовка

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

Запуск и обслуживание

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

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

• Документ — План проекта

• Отчет о продвижении проекта

• База данных выпуска

• Классификатор (QuickSizer)

• Руководство по системному администрированию

• Система международного образования и демонстрации (IDES)

• База данных по вопросам и ответам

• Справочная модель R/3

• Структурная модель R/3

• Отчетная модель R/3

• Главный список бизнес-процессов (BPML)

• Руководство по внедрению (IMG)

• Ассистенты настроек

• Процедуры бизнес-процессов (Business Process Procedures, ВРР)

• Инструментальные средства для миграции прежней системы (LSMW)

• Руководство по переносу данных

• Рабочее место для переноса данных

• Руководство по авторизации

• Генератор профилей

• Справочник по интерфейсам.

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

• Консалтинг на месте

• Удаленный консалтинг

• База данных по информации и новым решениям в обучении (InfoDB)

• Проверка запуска (GoingLive)

• Проверка и обнаружение сбоев (EarlyWatch).

Использование методологии ASAP и предусмотренных в ней стандартных списков контрольных вопросов, опросных листов, шаблонов документов, руководств и рекомендаций дает следующие преимущества:

• Быстрота внедрения

• Оптимальное использование средств и ресурсов

• Высокое качество.

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

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

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

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

• Определение организационной структуры.

• Составление опросного листа по бизнес-процессам.

• Составление шаблона опросного листа мнений пользователей.

• Создание документа «Концептуальный проект».

• Компиляция списка транзакций бизнес-процессов.

• Подготовка документов ВРР.

• Создание основного списка бизнес-процессов (Business Process Master List, BPML).

• Использование объема проекта из базы данных вопросов и ответов (Q&Adb) на IMG R/3.

• Составление системной документации и документации для конечных пользователей.

Философия многократного использования общих элементов может распространяться и на разработку отраслевых решений. Независимо от степени параметризации системы (нацеленной на соответствие большему диапазону требований), изменяемость системы также имеет границы, которые можно конфигурировать в рамках таких решений. В разных отраслях бизнес-процессы сильно различаются, никакие усилия по стандартизации и рационализации не смогут представить их как варианты нескольких сотен основных, базовых бизнес-процессов. Отраслевые процессы могут варьироваться от непрерывного производства до разработки на заказ (см. раздел «Планирование производства» в главе 9), и способы внедрения, мониторинга, контроля и управления процессами также сильно различаются. Компания SAP поставляет системы с готовой конфигурацией для некоторых отраслей (см. описание самой общей системы с готовой конфигурацией — SAP R/3 RRR в разделе «Последние стратегические инициативы SAP» в главе 4).

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

Компания SAP осуществляет стратегию дополнения своих всеобъемлющих решений с общей функциональностью специфическими отраслевыми функциональными возможностями. Во время внедрения необходимо изменить специфические установки настроек в соответствии с требованиями конкретной компании. Система с готовой конфигурацией может создаваться на копии Клиента ООО, а затем транспортироваться с помощью запроса на перенос. В ASAP отраслевые структуры, сценарии и процессы можно найти в базе данных вопросов и ответов, а в SAP R/3 — с помощью Бизнес-Навигатора или другого совместимого инструмента моделирования. Отраслевые системы с готовой конфигурацией охватывают следующие отрасли:

• Автомобильная промышленность

• Химическая промышленность

• Фармацевтическая промышленность

• Целлюлозно-бумажная промышленность

• Металлургическая промышленность

• Банковское дело

• Товары народного потребления

• НИОКР

• Наукоемкая промышленность

• Розничная продажа

• Аэрокосмический комплекс.

Implementation Guide (IMG) SAP R/3 играет самую важную роль в настройке системы SAP R/3 под требования конкретной компании. Настройка осуществляется посредством конфигурации программных продуктов SAP в то время, как базовая система SAP остается в неприкосновенности. Как уже упоминалось в разделе «Среда внедрения» главы 5, в SAP предусмотрена среда под названием Business Engineer, которая помогает во внедрении и, в частности, в осуществлении конфигурации. Эта среда включает в себя такие инструменты, как Бизнес-навигатор, Руководство по внедрению, Бизнес-документооборот, IDES и т. д. Перед тем, как подробно рассмотреть различные этапы методологии ASAP в следующих главах, обратим более пристальное внимание на Руководство по внедрению.

Как уже упоминалось в разделе «Конфигурация через Руководство по внедрению», инструмент IMG похож на модули инициализации в традиционных системах, за исключением того, что количество изменяемых параметров в нем значительно больше. Фактически, IMG — это самый важный инструмент для успешной конфигурации SAP в соответствии с требованиями конкретной компании. Существуют следующие версии Руководства по внедрению:

• Справочное IMG (Reference IMG)

• IMG по предприятию (Enterprise IMG)

• IMG по проекту/проектам (Project(s) IMG).

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

IMG по предприятию — это сокращенный вариант Справочного IMG и представляет только ту функциональность, которая необходима конкретному предприятию. Относящиеся к исключенным модулям опции конфигурации отфильтровываются во время генерации IMG по предприятию.

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

Проектный IMG содержит множество транзакций конфигурации, которые являются средствами настройки различных процессов или функциональностей, предоставляемых SAP. Конкретный бизнес-процесс может настраиваться с помощью нескольких транзакций конфигурации. По сути, каждая транзакция конфигурации — это одна из 8000 таблиц параметров, предусмотренных в SAP. Это могут быть такие параметры, как коды компании, счета Главной книги, диапазоны номеров счетов, контрольные коды счетов дебиторской или кредиторской задолженности, коды записи, коды местоположений, категории поставщиков или потребителей, коды налогов, фискальные календари, валюты и факторы обменного курса, диапазоны номеров бухгалтерских транзакций и т. д.

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

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

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

Проектное IMG организовано по иерархическому принципу — различные транзакции конфигурации сгруппированы в иерархии директорий, которые отражают порядок внесений настроек в тот или иной модуль. На уровне модулей директории IMG упорядочены в соответствии с порядком внедрения модулей SAP. Впрочем, некоторые параметры или транзакции конфигурации не зависят от конкретных модулей, и затрагивают все (или почти все) модули и функциональности системы. Такие транзакции конфигурации, которые называются Общие установки, размещаются на верхнем уровне иерархии IMG. Таким образом, порядок размещения призван предотвратить появление громадного одноуровневого списка транзакций конфигурации, который был бы совершенно неуправляем. Иерархия директорий Проектного IMG показана на рис. 12.2.

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

• Клиент (Client) — самый высокий организационный уровень в SAP R/3, не имеющий ничего общего с потребителем или клиентом, которым оперирует среда SAP Базис.

• Код компании (Company code) — самое мелкое юридическое образование, необходимое для внешней отчетности, годового баланса, выписок из Книги закупок и т. д. Клиенту может быть присвоено несколько кодов компании, но никогда наоборот.

• План счетов (Chart of accounts) — необходим для внешней отчетности. У каждого клиента может быть только один план счетов, причем все коды компании внутри клиента должны использовать именно этот план счетов.

• Область контроля кредита (Credit control area) — организационная структура, которая используется для управления и контроля кредита, а также для отчетности.

• Области бизнеса (Business areas) — применяются для гибкой финансовой отчетности, в случае необходимости создания отдельного годового баланса или отчета о прибылях и убытках, обычно используется в США.

Рис. 12.2. Структура верхнего уровня IMG по предприятию.

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

• Единица учета результатов (Operating concern) — каждой области контроллинга присваивается только одна единица учета результатов, которая используется при наличии модуля анализа прибыльности. Не все клиенты SAP внедряют этот модуль.

• Завод (Plant) — единица хранения, учета, обработки или производства. Коду компании или закупающей организации может быть присвоено несколько заводов.

• Организация продаж (Sales organization) — высший уровень управления продажами и соответствующей отчетности.

• Канал продаж и дистрибуции (Sales distribution channel) — характеризует различные режимы поставок конечным клиентам (дистрибуторам, агентам, точкам розничной торговли, интернет-магазинам и т. д.). Организации продаж может быть присвоено несколько каналов продаж и дистрибуции.

• Подразделение продаж (Sales division) — используется для управления группой продуктов и отчетности по ним. Несколько подразделений продаж может быть присвоено нескольким организациям продаж или каналам продаж и дистрибуции.

• Область продаж (Sales area) — используется для гибкого управления и отчетности; это комбинация нескольких организаций продаж, каналов продаж, дистрибуции и подразделений продаж.

• Организация закупок (Purchasing organization) — организационная единица для осуществления закупок и создания заказов на закупку.

• Места хранения (Storage locations) — физическое место, где хранятся все учетные единицы компании, нескольким заводам может быть присвоено несколько мест хранения.

• Счет Главной книги (General Ledger account) — применяется для внешней (обязательной) отчетности с использованием плана счетов.

• Банк и Банковский счет (House Bank and Bank Account) — организационные структуры, которые отражают банковские отношения компании и ее банковские счета.

• Основные данные по поставщикам (Vendor Master) — важная информация о поставщиках. Например, название, адрес, номера телефонов и факсов, контактное лицо, информация о закупках, банковская и бухгалтерская информация. Эти данные сохраняются в полях транзакций, причем при выполнении транзакции эти данные могут использоваться по умолчанию.

• Основные данные по потребителям (Customer Master) — схожи с основными данными по поставщикам, содержат информацию о клиентах компании — такую, как название, адрес, покупательские предпочтения, маркетинговая и бухгалтерская информация. Когда выполняется транзакция, эти данные могут использоваться по умолчанию.

На рис. 12.3 — 12.11 показаны экраны, с помощью которых можно задавать указанные параметры.

Рис. 12.3. Внесение в IMG настроек в структуру предприятия.

Рис. 12.4. Определение в IMG параметров, относящихся к финансовой отчетности.

Рис. 12.5. Определение в IMG параметров, относящихся к продажам и дистрибуции.

Рис. 12.6. Присвоение в IMG параметров, относящихся к продажам и дистрибуции.

Рис. 12.7. Настройка в IMG финансовой отчетности.

Рис. 12.8. Настройка в IMG параметров, относящихся к документам SAP.

Рис. 12.9. Определение в IMG параметров, связанных с налогообложением.

Рис. 12.10. Определение в IMG счетов Главной книги.

Рис. 12.11. Настройка в IMG параметров, относящихся к транзакциям.

Системы SAP в основном предназначены для малых и средних предприятий с годовым оборотом в пределах 50 миллионов — I миллиарда долларов. В этой главе объяснялось, почему проекты SAP обычно довольно сложны; также рассматривался контекст ускоренной методологии внедрения SAP — Accelerated SAP и различные этапы цикла внедрения ASAP. В остальных главах части IV мы подробно рассмотрим каждую из этих стадий в деталях.

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

Примечание

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

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

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

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

Миссия проекта

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

Оценочные характеристики проекта

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

Документ Изменений

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

Необходимо отметить, что ASAP не означает автоматического проведения Реинжиниринга бизнес-процессов как такового, существующие бизнес-процессы не претерпевают значительных изменений. Однако SAP по своей природе (см. главу 1 «Предприятие нового тысячелетия» и главу 4 «Решение SAP») становится катализатором значительных перемен в практиках и процедурах компании. Для этого есть несколько причин:

• Принцип одноразового ввода транзакций — введенная в одном месте транзакция становится доступной всем модулям.

• Всеобъемлющее автоматическое отслеживание и аудит.

• Единая интегрированная база данных.

• Операции в режиме реального времени.

• Моментальная запись и обновление транзакций.

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

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

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

Стратегия внедрения

Существует две стратегии внедрения — по принципу «Большого взрыва» и «волнообразное». В первом случае все необходимые модули SAP внедряются одновременно, именно такой подход рекомендуется в данной книге. Другой подход — волнообразное внедрение различных модулей, когда по окончании одного внедрения начинается следующее.

Стратегия развертки

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

Внедрение систем с готовой конфигурацией

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

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

Определение ролей

Методология ASAP предусматривает четкое распределение ролей и соответствующие требования к знаниям для обеспечения успешного завершения проекта. В документации по ASAP подробно определяются следующие роли:

• Спонсор проекта

• Член организационного комитета

• Менеджер проекта SAP

• Менеджер проектов по клиентам

• Лидер команды бизнес-процессов

• Член команды бизнес-процессов

• Менеджер по консалтингу SAP

• Менеджер технического консалтинга

• Аудитор качества

• Консультант по приложениям

• Лидер команды изменений

• Член команды изменений

• Владелец бизнес-процесса

• Ключевой пользователь

• Разработчик документации

• Инструктор конечных пользователей

• Менеджер Справочной службы

• Внутренний аудитор

• Лидер технической команды

• Менеджер по разработкам

• Разработчик АВАР

• Разработчик-проектировщик

• Разработчик межфункциональных приложений

• Системный администратор SAP

• Администратор баз данных

• Администратор сети

• Администратор операционных систем

• Администратор авторизации

• Технический консультант

• Проектный инженер.

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

Организация команды

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

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

План работы по проекту

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

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

План бюджета проекта

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

План ресурсов проекта

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

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

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

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

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

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

Обмен данными в рамках проекта

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

Планирование и мониторинг проекта

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

Планирование проекта производится на основе Сетевого графика ASAP (Roadmap), IMG-операций и данных Ассистента по внедрению ASAP с помощью такого инструмента управления проектами, как MS Project. Планирование проекта позволяет обновлять расписание проекта согласно плановым работам, бюджетному плану и плану по ресурсам.

Стандарты документации проекта

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

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

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

План управления проблемами

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

План управления организационными изменениями

Организационные изменения — это важнейший аспект методологии ASAP, который рассматривается в совокупности с планом проекта SAP. План управления организационными изменениями нацелен на обнаружение и расчет возможных рисков, которые могут повлиять на успешное завершение проекта SAP как на уровне человека или команды, так и на уровне всей организации. Такой план упорядочивает поступающие во время Концептуального проектирования инициативы и служит основой для анализа последствий, оценки основных рисков, стратегии спонсорства и коммуникации, развития навыков и передачи знаний, а также процесса организационной оптимизации. Этот план включает в себя отчетность по статусу программы управления изменениями в компании, а также деятельность, методы, результаты и крайние сроки, предусмотренные этой программой.

План по организации группы

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

Стратегия использования услуг R/3

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

• Программа Центр Компетенции Клиента (Customer Competence Center, ССС)

• Услуга Быстрый Анализ (Quick Sizing)

• Услуги по обзору и оценке системы (Review Services)

• Услуги по обучению (Training Services)

• Услуга по преобразованию данных (Conversion Services)

• Услуга Раннее обнаружение (EarlyWatch Service)

• Удаленный консалтинг (Remote Consulting)

• Консалтинг на месте (Onsite Consulting)

• Удаленная модернизация (Remote Upgrade)

• Удаленное архивирование (Remote Archiving)

• Услуга Текущее наблюдение (GoingLive Check).

План проверки качества

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

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

Стандарты обзоров проекта

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

Стандарт конфигурации системы

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

Если компания выбирает систему Ready-to-Run R/3 (RRR) или другие системы с готовой конфигурацией, установление этого стандарта будет означать поддержку всех установок конфигурации и настроек для конкретной системы.

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

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

Стандарты тестирования

Методология ASAP придерживается итеративного (многократного) подхода к тестированию, что подразумевает возможность доступа к одним и тем же областям и функциональности на все более и более мелком уровне. Тестирование может начинаться на уровне конфигурации, затем переходить на уровень бизнес-процессов и далее, на уровень пользователей.

Эти стандарты определяют общую стратегию на всем протяжении жизненного цикла проекта. Тестирование проводится на следующих уровнях:

• Тестирование единиц

• Тестирование системы

• Тестирование интеграции

• Тестирование приемлемости для пользователей

• Нагрузочное тестирование

• Тестирование модернизаций и новых версий (после завершения проекта).

Ассистент внедрения ASAP устанавливает как минимум четыре рубежа тестирования:

• Тестирование базовой конфигурации

• Тестирование окончательной конфигурации

• Окончательное тестирование интеграции

• Нагрузочное тестирование.

Стандарты услуг и поддержки после внедрения

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

• Поддержка SAP

• Справочная служба SAP.

В данном случае под клиентом подразумевается сторона, заключившая договор с одним из Центров Компетенции Клиента (ССС) (см. соответствующий раздел в главе 18). Такие нормы согласовываются с общей стратегией поддержки SAP после завершения внедрения.

Стандарты системной авторизации

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

• Администратор пользователей

• Администратор профилей авторизации

• Администратор групп активности

• Команда по управлению изменениями.

• Команда разработчиков АВАР.

Стандарты отчетности по проблемам и устранению сбоев

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

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

• Рабочее место

• Сервер

• Сеть.

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

Стандарты контроля и управления изменениями

Даже если внедрение SAP проводится по принципу «без изменений» («no change»), все равно возникнет множество ситуаций, когда придется вносить изменения, обусловленные природой модификаций и дополнений программных продуктов SAP. Как правило, такие усовершенствования и модификации не должны затрагивать базовую конфигурацию SAP (см. раздел «Методологии внедрения SAP» в главе 5).

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

Стандарты программирования АВАР

Стандарты программирования АВАР затрагивают разработку, тестирование и внедрение программ АВАР, в том числе отчетов, динамических программ и т. д. Целесообразно не изменять рекомендуемые компанией SAP стандарты программирования на АВАР, наименования условных обозначений, специфические таблицы, руководства по оформлению экранов, объекты Хранилища и т. д.

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

Во время определения стратегии системной платформы необходимо учитывать, устанавливается ли предварительно сконфигурированная система Ready-to-Run SAP R/3.

Определение и идентификация необходимых систем

Обычно SAP рекомендует трехсистемную платформу со следующими компонентами:

• Система разработки

• Система качества

• Рабочая система.

У многих клиентов SAP также имеется система испытательного полигона (Sandbox или Play), которая используется для тестирования новых идей и настроек системы разработки без внесения реальных изменений в систему разработки — такой безопасный подход весьма желателен.

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

Примечание

Как уже упоминалось в разделе «Планирование и управление системной платформой SAP» главы 11, односистемная платформа в среде SAP фактически невозможна, только если компания не придерживается политики полного отказа от модернизаций и усовершенствований.

Каждой системе присваивается системный идентификатор ID или идентификатор основных данных SID.

Как уже отмечалось в разделе «SAP Ready-to-Run R/3 (RRR)» главы 4, готовая к использованию система (RRR) поставляется с заранее сконфигурированной двухсистемной платформой, в которой проверка качества объектов осуществляется в среде разработки. Заранее заданный ID системы разработки — R3T, ID рабочей системы — R3P.

Стратегия разворачивания Клиентов

Клиент — это независимая организационная единица в SAP R/3. Каждый клиент требует отдельной установки и обслуживания. Следовательно, для установки системной платформы необходима ясная и определенная стратегия.

В рамках отдельной SAP R/3 каждый клиент идентифицируется с трехзначным номером. Мы уже упоминали Клиента по умолчанию — ООО и Клиента 066, предназначенного для услуги «Раннее обнаружение». Одинаковые Клиенты на нескольких системах должны идентифицироваться одинаковыми номерами, эта мера необходима для транспортировки измененных объектов, потому что из одной системы измененный объект по умолчанию транспортируется в такого же Клиента системы назначения. У каждого Клиента есть своя среда данных, в том числе:

• Настройки (как общие, так и специфические для конкретного Клиента)

• Объекты Хранилища

• Данные приложений (основные и по транзакциям)

• Основные записи по пользователям.

В зависимости от предназначения Клиенты могут принадлежать одному из следующих типов:

• Клиент разработки

• Клиент тестирования

• Клиент проверки качества

• Клиент обучения

• Рабочий клиент

• Тестовый мандат (Sandbox)

• Подготовка производства.

В SAP предусмотрены средства определения атрибутов для придания Клиенту конкретных свойств (параметров), в том числе возможность или невозможность внесения изменений.

Стратегия версий

Эта задача определяет модернизации SAP R/3 в зависимости от выпуска новых версий с дополнительной функциональностью SAP. Методология ASAP рекомендует отложить модернизацию версий до окончания проекта внедрения.

Стратегия транспортной системы

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

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

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

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

Требования к компьютерному оборудованию и сопутствующей инфраструктуре оцениваются с помощью технического списка контрольных вопросов, предусмотренного в инструменте Быстрый Анализ (Quick Sizer), или эта услуга заказывается в компании SAP.

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

• Рабочие места

• Сеть

• Система (серверы приложений и баз данных).

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

Эта задача подразумевает заказ удаленного подсоединения к ближайшему в этом регионе серверу SAP, который выступает в качестве горячей линии связи с компанией SAP и является средством предоставления услуг на различных стадиях проекта — таких, как Онлайновая сервисная система (OSS), Раннее обнаружение (EarlyWatch) и Текущее наблюдение (GoingLive service). Горячая линия может сыграть решающую роль в случае возникновения непредвиденных проблем и нештатных ситуаций.

Это окончательное подтверждение выполнения всех задач на этапе подготовки проекта. Компания SAP рекомендует следующий перечень контрольных пунктов для данной стадии:

1. Рассмотреть Устав проекта и убедиться в его завершенности.

2. Убедиться, что была выбрана стратегия внедрения.

3. Убедиться в полной комплектации рабочих мест для членов команды проекта.

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

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

6. Рассмотреть план управления изменениями.

7. Рассмотреть план обучения членов команды проекта.

8. Подтвердить создание всех стандартов и процедур управления проектом.

9. Подтвердить создание всех стандартов и процедур внедрения.

10. Убедиться в том, что открытие проекта состоялось или запланировано.

11. Убедиться в том, что достигнуто соглашение в выборе стратегии системного ландшафта.

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

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

На этой стадии проекта основной задачей является создание Концептуального проекта SAP, в котором формулируются связанные с бизнес-процессами требования компании. Консультанты и члены группы проводят собеседования и семинары в различных подразделениях компании, чтобы составить полную картину требований к бизнес-процессам, демонстрируют функциональные возможности системы SAP R/3 с помощью системы International Demo and Education System (IDES), а также вопросников и диаграмм бизнес-процессов из модуля R/3 Business Engineer. Любые несоответствия функциональным требованиям компании анализируются и устраняются.

Примечание

Крайне важно использовать в работе оригинальный компакт-диск с документацией по методологии AcceleratedSAP (ASAP). В этой главе представлены только важнейшие аспекты стадии запуска и поддержки AcceleratedSAP, но их нельзя рассматривать как полноценную замену колоссального количества инструкций, указаний, рекомендаций, списков контрольных вопросов, шаблонов, образцов и вопросников, которые предоставляются компанией SAP. Эти инструменты отлично себя зарекомендовали, поэтому настоятельно рекомендуется обратиться к версии ASAP, которая соответствует версии внедряемой системы, и использовать ее на всем протяжении реализации проекта. Читателю может показаться, что содержание некоторых глав этой книги однообразно, и многие фрагменты ее повторяются, однако в результате тщательного изучения станет ясно, что такие виды деятельности, как управление проектом, организационными изменениями, оценка рисков, спонсорство, стратегия обмена информацией и технология внедрения во многом остаются неизменными на протяжении всех этапов внедрения, и упоминаются в начале каждого этапа. Похожим образом многие мероприятия проходят через стадии планирования и исполнения, поэтому они постоянно упоминаются на различных этапах проекта, и это не повторение одного и того же, а всего лишь часть контрольного списка процессов ASAP, рекомендованных компанией SAP.

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

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

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

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

Эта задача нацелена на выяснение статуса проекта в зонах ответственности различных команд проекта, в том числе:

• Команды бизнес-процессов

• Команды управления изменениями

• Технической команды.

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

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

• дополнительные ресурсы

• изменение графика проекта

• расширение рамок проекта.

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

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

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

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

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

• Подразделения и организационные единицы компании, которые будут затронуты внедрением SAP, и соответствующее планирование управления изменениями

• Мнения менеджеров об ожидаемых изменениях — как в рамках подотчетных им подразделений, так и за их пределами

• Своевременность, масштаб и значение тех или иных изменений.

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

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

• Руководство

• Команда

• Организация.

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

Создание инструментов оценки рисков

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

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

Управление инструментами оценки рисков

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

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

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

• Сотрудники, чьи обязанности и ответственность значительно изменятся в результате внедрения SAP

• Сотрудники, чьи обязанности и ответственность зависят от работы первых двух групп.

Создание профиля рисков

Необходимо создать один профиль рисков, общий для всех уровней, на котором проводится оценка рисков: руководство, команда и организация в целом (см. раздел «Управление рисками в проекте SAP» в главе 10).

Проведение семинаров по рискам

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

Использование результатов семинаров по рискам

На семинарах принимаются решения по мерам, направленным на устранение выявленных рисков: в дальнейшем эффективность принятых мер отслеживается и оценивается.

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

Уверенное управление проектами — это ключевой элемент всеобъемлющей программы изменений в организации. Команде лидеров необходимо выявить как позитивные, так и негативные факторы, которые влияют на успешное выполнение проекта: причем базовая оценка рисков в среде команды лидеров особенно важна для процесса спонсорства. Спонсор-организатор — это один из старших менеджеров, инициатор перемен на предприятии, который активно и коммуникативно формирует поддержку проекта на всех уровнях компании и удерживает движущую силу проекта на должном уровне. Инструменты оценки рисков в среде команды лидеров позволяют команде по изменениям добиться выполнения следующих задач:

• Измерить риски, связанные с предстоящим внедрением SAP.

• Понять возможные последствия этих рисков для проекта внедрения SAP.

• Разработать меры по минимизации этих рисков.

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

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

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

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

• Неофициальная обратная связь от естественных, неформальных лидеров коллектива

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

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

• Обучение, связанное с эффектом от внедрения SAP

• Обучение, связанное с бизнес-процессами

• Техническое и функциональное обучение SAP

• Обучение навыкам работы с SAP.

Команда по развитию навыков должна решить следующие вопросы:

• Содержание обучения — например, прототипы, IDES, индивидуальное обучение, семинары, разбор отдельных случаев, тестирование R/3, клиент «Обеспечения качества» (Quality Assurance, QA).

• Механизм достижения различных уровней навыков — обучение инструкторами или компьютерное обучение (Computer-Based Training programs, СВТ).

• Система дальнейшего распространения знаний и навыков.

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

В разделе «Знание как новый вид капитала» главы 1 уже упоминалось о явных и скрытых знаниях, и о том, как SAP превращает скрытые в глубинах компании знания в ценный ресурс. В следующем разделе, «Информация как новый ресурс» также обсуждалось, что информация может являться полноценным ресурсом, который ускоряет операционные процессы, не требуя дополнительных затрат. Именно в этой роли выступает методология ASAP относительно системы SAP R/3 — она использует всю значимую информацию для ускорения процесса внедрения SAP.

Внедрение процесса передачи знаний включает в себя следующие задачи:

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

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

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

• Обработка информации: исследование, сбор, подтверждение подлинности, рационализация и оценка информации, методик и технологии.

• Поставка информации: сохранение, оформление, совместное использование и применение информации.

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

Планирование и проведение обучения членов команды SAP позволяет им сопоставить требования к бизнес-процессам и функциональности R/3, чтобы в итоге составить Концептуальный проект. В основном это обучение 1-го и 2-го уровня. Компания SAP предоставляет своим клиентам возможность пройти обучение на 5-недельных курсах в Партнерской Академии, причем каждый курс нацелен на углубленное изучение того или иного модуля SAP — например, FI, СО, SD, MM, РР, HR, АВАР или Basis.

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

Компания SAP рекомендует документировать всю техническую инфраструктуру с помощью соответствующего шаблона под названием «Документ инфраструктуры» (IT Infrastructure Document). Эта задача включает в себя следующее:

• Подготовку структуры системы и ее дистрибуции

• Подготовку инфраструктуры печати

• Подготовку топологии сети

• Подготовку топологии интерфейсов

• Подготовку управления запросами на изменения

• Подготовку стратегии управления версиями и модернизациями

• Подготовку стратегии управления терминалами.

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

• Инсталляция первичного компьютерного оборудования

• Инсталляция первичного ландшафта системы

• Конфигурация и тестирование транспортной системы

• Инсталляция компьютеров и периферии для членов команды проекта

• Подготовка основных записей по пользователям и обеспечение безопасности системы

• Инсталляция первичных устройств печати

• Установка удаленного подсоединения к SAP.

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

• Провести семинар по Базису и системному администрированию

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

• На основе принятых решений провести конфигурацию Центральной управляющей системы (CCMS)

• Определить стратегию резервного копирования данных.

На этом этапе необходимо создать Руководство по внедрению (IMG), которое уже обсуждалось в одноименном разделе главы 12. Справочник IMG используется на более поздних этапах определения бизнес-процессов.

Создание Руководства по внедрению на предприятии

Для того, чтобы создать специфическое для конкретного предприятия Руководство пользователя, надо выбрать необходимые компоненты приложения allEnterprise IMG. Следует отметить, что выбор компонента подразумевает автоматический выбор всех элементов, подчиненных этому компоненту по иерархии. Однако если компания собирается использовать ссылку ASAP IMG, необходимо выбрать все компоненты Enterprise IMG.

Документ Enterprise Process Area Scope генерируется в базе данных «Вопросы и ответы» (см. рис. 14.1 и 14.2).

Рис. 14.1. Основной экран для базы данных «Вопросы и ответы» в ASAP

Рис. 14.2. Запись базовой информации о компании.

Создание Руководства по внедрению и название проекта

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

Ниже приведены возможные значения статусов, которые используются в административных целях в IMG:

• В процессе

• Завершено

• Проведена проверка качества

• Запланирован пересмотр

• Не имеет отношения

• За рамками проекта.

Для конкретного проекта IMG можно создать двумя способами:

• Традиционное создание IMG вручную.

• Автоматическая генерация IMG в рамках методологии ASAP, во время которой настройки базы данных «Вопросы и ответы» (ASAP Q&Adb) автоматически трансформируются в Руководство по внедрению.

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

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

В результате создается организационная бизнес-структура компании в рамках системы SAP, на основе организационных правил системы R/3. Для этих целей в методологии ASAP предусмотрена документация по моделированию структуры (Structure Modeler) и соответствующий шаблон в Visio. Создание организационной бизнес-структуры происходит на собраниях с участием спонсора проекта, управляющего проектом, лидера команды по бизнес-процессам и других ключевых членов рабочих команд. Можно организовать отдельные семинары для обсуждения финансовых процессов и процессов из области логистики с последующей интеграцией полученных результатов.

В методологии ASAP предусмотрен список контрольных вопросов по организационной структуре, который содержится в разделе «Общие вопросы бизнеса» (Business Overview Questions), (см. рис. 14.2 и 14.3) в базе данных (Q&Adb).

Рис. 14.3. Запись ответов на организационные вопросы компании

Дополнительная информация содержится на компакт-диске с документацией к системе SAP R/3 — в «Руководстве консультанта по моделированию предприятия».

Проведение собраний и семинаров позволяет решить следующие задачи:

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

• Выяснение организационных структур в SAP.

• Составление карты текущих и будущих требований к организационной структуре, как совокупности предусмотренных в SAP организационных элементов (см. рис. 14.4).

• Анализ затрат и прибыли, пробелов и несоответствий в заданной организационной структуре.

• Цикличная отладка и тонкая настройка организационной структуры SAP.

• Документирование организационной структуры SAP.

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

Рис. 14.4. Запись организационной структуры компании.

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

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

• Убедиться, что все бизнес-процессы охвачены рамками проекта.

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

• Обновить базу данных «Вопросы и ответы» (Q&Adb) на основе последних версий документов по объемам процессов на предприятии.

• Составить график участия ключевых пользователей.

Также необходимо назначить ответственных за бизнес-процессы сотрудников владельцами конкретных участков бизнес-процессов, а также соответствующих областей базы данных «Вопросы и ответы» (Q&Adb).

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

• План счетов

• Организационная структура предприятия

• Годовой баланс и анализ прибыльности

• Обновление и поддержка центральных и локальных основных данных

• Страны

• Валюты

• Единицы измерения

• Особенности календаря

• Нумерация документов.

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

Определение требований к бизнес-процессам

Определение требований к бизнес-процессам проводится с учетом следующих документов:

• Карта охвата областей бизнес-процессов

• База данных «Вопросы и ответы» (Q&Adb)

• Формуляр описания исходных данных клиента (Customer Input, CI).

В методологии ASAP предусмотрен список контрольных вопросов, который служит основой для проведения таких семинаров. Вопросы, связанные с организационной структурой содержатся в базе данных «Вопросы и ответы» (Q&Adb), в разделе «Вопросы по бизнес-процессам» (см. рис. 14.5).

К списку контрольных вопросов прилагаются подробные сведения о бизнес-процессах — для этого заполняются шаблоны опросов мнений потребителей, которые содержат 15 вопросов по каждому из процессов (см. рис. 14.6) и охватывают следующие темы:

• Ожидаемые требования

• Общие ожидания

• Объяснение функций и событий

• Особые организационные мнения

• Бизнес-модель

• Изменения существующей организации

Рис. 14.5. Вопросы, связанные с бизнес-процессами.

Рис. 14.6. Вопросы, связанные с транзакциями и бизнес-процессами.

• Описания усовершенствований

• Описания функциональных недостатков

• Подходы к устранению недостатков

• Заметки о возможности дальнейших улучшений

• Анализ системной конфигурации

• Рассмотрение интерфейсов

• Мнение по конвертации данных

• Обсуждение отчетов

• Рассмотрение авторизации.

Определение требующихся отчетов

В SAP предусмотрены сотни стандартных отчетов, многие из которых обладают достаточной гибкостью, причем один новый отчет SAP может заменить несколько отчетов в унаследованных системах. Каждое требование к тому или иному отчету необходимо сверить с иерархией отчетов в системе, чтобы убедиться в наличии соответствующей функции. На случай, если то или иное требование не удается удовлетворить с помощью стандартного отчета, в SAP предусмотрен шаблон записи нестандартных требований к отчету и широкий набор средств создания нестандартной отчетности, в том числе Report Writer/Report Painter, АВАР Query, АВАР Reporting и т. д.

Определение требующихся интерфейсов

В рамках этой задачи следует определить необходимость в будущем использовании специальных функций и возможностей SAP — таких, как прикладной Интернет-компонент (Internet Application Components, IAC), SAP Workflow, SAP Business Warehouse, Application Link Enabling (ALE) и т. д. На начальных этапах внедрения использовать эти функциональные возможности нельзя.

Определение требований к конвертации данных

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

Определение требований к модификациям

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

Определение возможных пробелов

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

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

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

Подробные обсуждения бизнес-процессов проводятся с целью выполнения следующих задач:

• Прояснение требований на основе результатов опросов клиентов и информации о бизнес-процессах

• Анализ прошедших внедрений бизнес-процессов SAP с целью обнаружения более гибких и/или эффективных версий того или иного процесса.

• Исследование различных недостатков и пробелов с целью нахождения решений.

• Пересмотр требований к бизнес-процессам на уровне оптимизации процесса, требований к авторизации и т. д.

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

Анализ организационной оптимизации

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

• Карты возможных последствий для бизнеса

• Карты возможных последствий для процессов.

Пересмотр организации проекта и распределение ролей

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

Составление Концептуального проекта

Эта задача включает консолидацию баз данных «Вопросы и ответы» (Q&Adb) в одну централизованную базу данных и составление Концептуального проекта. Концептуальный проект должен охватывать следующие аспекты:

• Управленческий конспект

• Рамки областей процессов предприятия

• Организационная структура

• Заполненные списки контрольных вопросов по бизнес-процессам и формуляры описаний исходных данных клиента (CI).

• Обоснование для использования усовершенствований, конвертации и интерфейсов

• Заполненный список технических контрольных вопросов.

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

Основной список бизнес-процессов

Эта задача нацелена на определение точных рамок бизнес-процессов, которые будут внедряться на этапе реализации. Основной список бизнес-процессов (BPML) — это описание всех областей, которые охватит проект SAP, причем конфигурация осуществляется в два этапа — базовая конфигурация и окончательная конфигурация (см. рис. 14.7 и 14.8).

Методология ASAP рекомендует — базовые рамки проекта должны охватывать около 80 % планируемой области проекта (см. рис. 14.9, 14.10 и 14.11), и включать в себя наиболее важные сценарии, процессы и функции компании. Оставшиеся сценарии и процессы рассматриваются во время окончательной конфигурации. Чтобы облегчить эту задачу, методология ASAP рекомендует сформировать несколько циклов конфигурации, каждый из которых состоит из набора бизнес-процессов, сгруппированных по принципу приоритетности.

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

Рис. 14.7. Подготовка основного списка бизнес-процессов.

Рис. 14.8. Дополнительная информация, зафиксированная в основном списке бизнес-процессов.

Рис. 14.9. Информация о графике.

Рис. 14.10. Информация о тестировании.

Рис. 14.11. Дополнительная информация о базовых рамках проекта.

Индикаторы колонок приведены ниже (см. рис. 14.6 и 14.8):

• SC — в полном объеме

• BL — включается в базовую конфигурацию

• С1 — включается в 1-й цикл конфигурации

• С2 — включается во 2-й цикл конфигурации

• С3 — включается в 3-й цикл конфигурации

• С4 — включается в 4-й цикл конфигурации

• L1 — включается в 1-й цикл интеграции

• L2 — включается во 2-й цикл интеграции.

Для генерации BPML надо открыть базу данных «Вопросы и ответы», раздел «Отчет», затем выбрать «Основной список бизнес-процессов» и нажать «Генерировать». Колонка «Ссылки» в BPML обеспечивает доступ к формулярам описаний исходных данных клиента, относящегося к данному бизнес-процессу, а также к процедурам бизнес-процессов (ВРР). Кроме того, в BPML содержится информация, полученная от описанных выше транзакций бизнес-процессов, которую в случае необходимости можно расширить.

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

• Рассмотрение описания охваченных бизнес-процессов предприятия

• Рассмотрение Концептуального проекта

• Рассмотрение рамок базовой конфигурации.

Примечание

В методологии ASAP этот этап является вторым важнейшим рубежом проекта.

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

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

• Анализ количества конечных пользователей и их функций

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

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

• Требования по ресурсам

• График обучения.

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

• Производственное планирование

• Продажи

• Разработка и маркетинг продуктов

• Планирование цепочек поставщиков

• Производство

• Управление основными средствами

• Кадры

• Контроллинг доходов и расходов

• Потребительские услуги

• Поставки

• Внешний бухучет

• Управление финансами

• Розничная торговля

• Модель дистрибуции ALE.

Это — заключительная проверка выполнения этапа Концептуального планирования. Компания SAP рекомендует следующий список контрольных вопросов для такой проверки:

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

2. Убедитесь, что все члены команды проекта прошли необходимое обучение.

3. Убедитесь, что состоялись все необходимые мероприятия по формированию рабочих команд.

4. Убедитесь, что обязанности и ответственности четко распределены между сотрудниками.

5. Подтвердите разработку технического проекта.

6. Подтвердите создание среды разработки и платформы системы разработки.

7. Убедитесь, что установлены все необходимые функции системного администрирования.

8. Подтвердите инициализацию Руководства по внедрению (IMG).

9. Подтвердите завершение и официальное одобрение этапа концептуального проектирования и определение базовых рамок проекта.

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

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

Официальное закрытие этапа Концептуального проектирования означает окончание второго этапа методологии ASAP.

Цель данного этапа — базовая конфигурация системы на основе составленного ранее плана Концептуального проектирования. Для этого бизнес-процессы делятся на циклы взаимосвязанных бизнес-процессов. Одновременно с этим команда проекта SAP проходит обучение в 3 уровня, а команда ключевых пользователей знакомится с системой и проходит обучение в зависимости от своих будущих обязанностей. В дальнейшем подготовленная на этом этапе базовая система станет основой для рабочей системы SAP. Настройка базовой конфигурации системы производится путем ратификации ключевых пользователей с применением итеративного метода.

Примечание

Крайне важно использовать в работе оригинальный компакт-диск с документацией по методологии AcceleratedSAP (ASAP). В этой главе представлены только важнейшие моменты этапа окончательной подготовки в рамках методологии ASAP, но их нельзя рассматривать как полноценную замену колоссального количества инструкций, указаний, рекомендаций, списков контрольных вопросов, шаблонов, образцов и вопросников, которые предоставляются компанией SAP. Эти инструменты отлично себя зарекомендовали, поэтому настоятельно рекомендуется обратиться к версии ASAP, которая соответствует версии внедряемой системы и использовать ее на всем протяжении реализации проекта. Читателю может показаться, что содержание некоторых глав этой книги однообразно и многие фрагменты ее повторяются, однако в результате тщательного изучения станет ясно, что такие виды деятельности, как управление проектом, организационные изменения, оценка рисков, спонсорство, стратегия обмена информацией и технология внедрения во многом остаются неизменными на протяжении всех этапов внедрения, и упоминаются в начале каждого этапа. Похожим образом многие мероприятия проходят через стадии планирования и исполнения, поэтому они также постоянно упоминаются на различных этапах проекта, и это не повторение одного и того же, а всего лишь часть контрольного списка процессов ASAP, рекомендованных компанией SAP.

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

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

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

• Управление проектом

• Техническое управление проектом

• IТ-инфраструктура

• Процесс управления изменениями

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

Эта задача направлена на выяснение статусов различных команд проекта:

• Команды, занимающейся бизнес-процессами

• Команды по управлению изменениями

• Технической команды.

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

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

• Выделение дополнительных ресурсов

• Изменений сроков и графика

• Расширение рамок проекта.

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

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

• Установка и запуск рабочей среды

• График конвертации данных

• Организация команды по переходу на новую систему

• Дезактивацию унаследованных систем, чье место занимает SAP

• План возврата к унаследованным системам в случае серьезных непредвиденных проблем

• Тестирование новой системы

• Список контрольных вопросов для всех мероприятий, связанных с переходом.

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

• Окончательное определение технической конфигурации

• Закупка необходимого оборудования

• Формирование команды запуска системы

• Формирование постоянной команды технической поддержки

• Определение процедур и инфраструктуры справочной службы

• Набор персонала для справочной службы (help desk)

• Набор персонала для команды технической поддержки

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

Формирование команд

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

• Совместные обеды или ужины

• Небольшие подарки

• Совместные праздники

• Пикники

• Рассылка информационного бюллетеня о проекте.

Подготовка к этапу реализации

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

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

Периодическая оценка рисков и проведение семинаров

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

Оценка рисков проводится в трех контекстах:

• Лидерство

• Команда

• Организация.

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

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

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

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

Проведение собраний по управлению рисками с участием ключевых сотрудников

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

Поддержка ключевых каналов обмена информацией

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

Управление постоянным процессом проектного спонсорства

Эта задача нацелена на поддержание эффективности процесса спонсорства, инициированного на этапе Концептуального планирования.

Управление постоянным процессом развития навыков персонала

Эта задача нацелена на поддержание движущей силы процесса развития навыков персонала, начатого на этапе Концептуального планирования.

Управление командой по передаче знаний

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

Обновление команды по управлению изменениями

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

Планирование и реализация обучения членов команд проекта SAP позволяет им конфигурировать и тестировать предусмотренные Планом концептуального проектирования бизнес-процессы.

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

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

Определение сценариев сбоев

Эта задача нацелена на создание сценариев событий, при которых работа системы R/3 могла бы быть частично или полностью парализована, например сценарии сбоев в работе:

• компьютерного оборудования

• компьютерных сетей

• отдельных терминалов

• серверов приложений

• серверов баз данных

• при передаче данных в системе R/3

• систем безопасности

• систем безопасности в компьютерных центрах.

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

Создание процедур по восстановлению данных в случае крупных сбоев

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

• Анализ допустимого времени простоя для различных приложений

• Скрипты процедур восстановления данных в случае масштабного сбоя

• Анализ соглашений с поставщиком о текущей техподдержке и дополнительных услугах

• Процедуры оповещения пользователей и каналы обмена информацией

• Промежуточные операции

• Процедуры перезагрузки

• Критерии успешного восстановления данных в случае масштабного сбоя

• Возврат к нормальной работе системы.

Создание базы соглашений для обслуживания системы

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

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

Разработка плана тестов на сбои

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

Разработка плана нагрузочного тестирования

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

Разработка плана функционального тестирования

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

Разработка плана тестирования системного администрирования

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

Разработка плана тестирования принтеров

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

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

Создание процедур копирования клиента

Создание процедур копирования клиента подразумевает использование утилит копирования клиента, а также отзыва (аннуляции) копии клиента.

Создание процедур ежедневных проверок

Ежедневные проверки должны охватывать следующие аспекты:

• Системный журнал

• Система управления очередностью печати

• График работ

• Анализ дампов

• Настройка и тестирование мониторов Центральной управляющей системы (CCMS)

• Настройка и анализ трассировки.

Создание процедур транспортировки

Эта задача нацелена на подтверждение эффективности транспортной системы, в том числе следующих ее аспектов:

• Выпуск запросов на изменения

• Импорт в систему обеспечения качества (Quality Assurance, QA) и в рабочую среду

• Процедуры «заморозки» кодов и тестирование качества (QA)

• Процедуры утверждения результатов обеспечения качества (QA) и запуска в рабочую среду.

Создание процедур резервного копирования и восстановления данных

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

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

Установка оборудования

Установленное оборудование, операционные системы и другие компоненты должны полностью соответствовать требованиям конкретной версии системы R/3. В том числе анализируется возможность подключения к онлайновой сервисной системе (OSS).

Инсталляция системы обеспечения качества

Инсталляция системы R/3 включает в себя следующие шаги:

• Запуск программы R3SETUP.

• Инсталляция основных копий.

• Инсталляция баз данных.

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

• Просмотр журнала R3SETUP.log для обнаружения возможных проблем.

• Проверка правильности совершенных действий посредством инсталляции и использования графического пользовательского интерфейса (SAPGUI) и электронной документации.

Создание основных записей

Создание основных записей и профилей по пользователям необходимо, чтобы пользователи смогли работать в среде «Обеспечение качества» (QA) и проводить нужное им тестирование. Профили доступа в систему QA являются частью среды разработки (Development, DEV).

Безопасность системы «Обеспечение качества»

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

Создание системы принтеров

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

Создание транспортной системы и системы управления клиентами

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

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

• Создание процедур поддержки безопасности рабочей системы

• Создание процедур рабочих операций

• Создание процедур администрирования рабочей системы

• Создание среды принтеров в рабочей системе

• Создание процедур администрирования баз данных в рабочей системе

• Создание руководства пользователя системы SAP.

Создание рабочей среды означает инсталляцию и конфигурацию системы, которая в основном будет использоваться в рабочей среде. Чтобы инсталлировать систему SAP R/3, следует обратиться к Руководству по установке SAP R/3 (Advanced Installation Guide). Создание рабочей среды включает в себя:

• Инсталляцию рабочего компьютерного оборудования

• Инсталляцию рабочей системы

• Инсталляцию и конфигурацию сетевого окружения

• Инсталляцию и конфигурацию настольных компьютеров и периферии

• Обеспечение безопасности операционной системы и баз данных

• Создание системы принтеров.

Основной список бизнес-процессов (Business Process Master List, BPML) — это самое полное представление рамок проекта внедрения SAP. Конфигурация делится на две части — базовая конфигурация и окончательная конфигурация.

Эти конфигурационные задания относятся к конфигурации и подтверждению параметров базовой настройки, что включает в себя сценарии, процессы и функции, которые затрагивают первостепенные требования компании (около 80 %). Оставшиеся 20 % сценариев и процессов настраиваются на стадии окончательной конфигурации и подтверждения.

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

Пересмотр рамок базовой конфигурации

Базовая конфигурация, подготовленная на этапе Концептуального планирования, подвергается пересмотру.

Создание базового плана конфигурации

Создание базового плана конфигурации происходит следующим образом:

1. Открыть Основной список бизнес-процессов (BPML) и выбрать лист «Базовая».

2. Добавить глобальные параметры в начале BPML.

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

4. Ввести запланированную графиком дату в колонке «План» раздела «Конфигурация».

5. Ввести информацию по тестированию и порядку следования взаимозависимых процессов. Для этого надо ввести номер ситуации и номер следования процесса в группу ассоциированных процессов в колонках «Конфигурация: Номер ситуации, Номер следования». Нажатие клетки «Просмотр» под колонкой «Конфигурация» позволяет отсортировать процессы по номерам.

6. Сохранить изменения в Плане базовой конфигурации в формате MS Excel.

Создание тестовых ситуаций

Создать контрольные примеры с помощью следующего:

1. Открыть План базовой конфигурации, выбрать лист «Базовая», измененный на предыдущем этапе.

2. Просмотреть предусмотренные в этом документе ситуации для тестирования «по умолчанию», которые можно принять для конкретного проекта.

3. Ввести информацию по тестированию и порядку следования взаимозависимых процессов, для этого надо ввести номер ситуации и номер следования процесса в группу ассоциированных процессов в колонках «Тестирование: Номер ситуации, Номер следования».

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

5. Для уточнения информации по тестированию, выбрать «Процедура тестирования» и добавить подробную информацию.

6. Сохранить изменения.

Создание плана тестирования

Создание плана тестирования для базисной конфигурации включает в себя следующие действия:

1. Открыть План базовой конфигурации, выбрать лист «Базовая», измененный на предыдущем этапе.

2. Ввести запланированную графиком дату в колонке «План» раздела «Тестирование».

3. Сохранить готовый план.

Распределение ресурсов

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

1. Открыть План базовой конфигурации и выбрать лист «Базовая», измененный на предыдущем этапе.

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

3. Ввести ФИО члена команды в колонке «Ответственность — Конфигурация и тестирование».

4. Сохранить изменения.

Одобрение плана базовой конфигурации владельцами процессов

На этом этапе обновляется Руководство по внедрению — в него вносится информация о ресурсах и назначениях. Данные вводятся вручную или, если компания использует функцию ASAP IMG (Руководство по внедрению), то автоматически (см. раздел «Инициация Руководства по внедрению» в главе 14).

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

Конфигурация общих параметров

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

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

Конфигурация организационной структуры

Это мероприятие зависит от документации и решений, утвержденных на этапе концептуального планирования, в рамках задачи формирования организационной структуры (см. раздел «Определение организационной структуры» в главе 14).

Создание и конфигурация организационных единиц производится с помощью ссылок или использования функции «копировать»; также необходимо обновлять соответствующую информацию в Руководстве по внедрению и в Плане базовой конфигурации.

Конфигурация заранее заданных параметров

В случае, если компания принимает заранее сконфигурированную систему (Predefined Configured System, PCS), необходимо использовать параметры предварительно заданного клиента (Predefined Client, РСС); хотя в случае необходимости эти параметры можно проверить на соответствие требованиям и изменить. В случае внесения изменений, следует обязательно внести соответствующие обновления в Руководство по внедрению и в План базовой конфигурации.

Это — основная, центральная стадия этапа реализации, в рамках которой производится изменение настроек конфигурации для сценариев и процессов. Измененные настройки транспортируются в среду «Обеспечение качества» (QA) для тестирования в соответствии с планами тестирования и тестовыми ситуациями, подготовленными ранее. Полученная в результате тестирования информация служит основой для изменения Плана базовой конфигурации, а также Концептуального плана.

Конфигурация процесса и функций

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

Транспортировка в систему обеспечения качества

Объекты базовой конфигурации необходимо транспортировать в систему обеспечения качества (QA).

Тестирование базовой конфигурации

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

Документирование проблем и их решение

Любые расхождения, проблемы или недочеты должны записываться и немедленно решаться; для записи используется «проблемная» база данных в рамках базы данных «Вопросы и ответы» (Q&Adb). Если проблема относится к области предварительного просмотра окончательной конфигурации, ее надо присвоить соответствующему циклу (см. раздел «Базовая конфигурация и подтверждение»).

Пересмотр Концептуального плана

На основе результатов конфигурации и подтверждения сценариев и бизнес-процессов Концептуальный план пересматривается и в нем отражается текущая информация.

Проверка полноты базовой конфигурации

Используя План базовой конфигурации, необходимо проверить все даты текущей и запланированной деятельности по конфигурации и тестированию процессов и сценариев, причем проблемные процессы должны быть отображены в базе данных «Вопросы и ответы». Убедиться в этом можно также с помощью Руководства по внедрению (IMG), запустив анализ проекта из меню «Настройки».

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

• Составление сценариев подтверждения

• Проведение подтверждения базовой конфигурации

• Подготовка программы сценариев подтверждения ответственными за межфункциональные процессы сотрудниками и назначение участников процесса подтверждения.

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

Примечание

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

Сценарии утверждения

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

1. Открыть План базовой конфигурации и выбрать «Базовая».

2. Ввести информацию по подтверждению и порядку следования взаимозависимых процессов — для этого надо ввести номер ситуации и номер следования процесса в группу ассоциированных процессов в колонках «Конфигурация: Номер ситуации, Номер следования».

3. Добавить информацию о процедурах подтверждения, выбрав шаблон процедуры и заполнив его подробными данными.

4. Сохранить изменения.

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

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

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

• Цикл 1: Цель этого цикла — тонкая настройка конфигурации бизнес-процессов для основных данных и наиболее важных процессов.

• Цикл 2: Тонкая настройка конфигурации оставшихся основных данных и элементарных транзакций.

• Цикл 3: Тонкая настройка конфигурации и основных данных посредством запуска наиболее важных процессов.

• Цикл 4: Настройка конфигурации через запуск бизнес-процессов (транзакций, отчетов, пользовательских профилей и т. д.).

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

• Пересмотр окончательных рамок конфигурации

• Создание плана конфигурации для окончательных рамок проекта

• Подготовка ситуаций тестирования

• Подготовка плана тестирования для окончательных рамок проекта

• Выделение ресурсов

• Получение одобрения плана конфигурации для окончательных рамок проекта.

Подтверждение окончательных рамок конфигурации (циклы от 1 до п)

На этом этапе происходит изменение параметров конфигурации для окончательных сценариев и процессов. Произведенные изменения транспортируются вереду «Обеспечение качества» (QA) для тестирования в соответствии с подготовленными ранее планами тестирования и тестовыми ситуациями. Полученные в результате данные используются для внесения изменений в Концептуальный план и в Основной список бизнес-процессов (BPML).

Примечание: количество циклов в названии и тексте этого раздела относится к количеству циклов конфигурации. Решение о количестве циклов конфигурации принимает компания.

Эта задача, как и на этапе базовой конфигурации, состоит из следующих шагов:

• Конфигурация процессов и функций.

• Транспортировка объектов в среду «Обеспечение качества» (QA).

• Тестирование окончательной конфигурации.

• Закрепление окончательной конфигурации.

Окончательное подтверждение (циклы от 1 до n)

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

• Подготовка сценариев окончательного подтверждения.

• Выполнение сценариев окончательного подтверждения.

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

1. Создать ID-номер для каждого члена команды разработчиков

2. Зарегистрировать каждого пользователя через Регистрацию изменений программного обеспечения SAP (SAP Software Change Registration, SCCR) в OSS и передать ключ доступа в систему разработки.

3. Создать запрос на изменения для каждого проекта разработки АВАР. Все участники конкретного проекта будут присвоены именно этому запросу на изменения.

4. Создать запрос на изменения для всех объектов АВАР, которые без изменений входят во все проекты АВАР.

5. Сгруппировать объекты Хранилища в иерархию объектов приложений, согласно которой каждый элемент иерархии будет присвоен классу разработки.

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

Разработка специфических для компании бланков и шаблонов документов производится в строгом соответствии с Концептуальным планом и включает в себя следующие задачи:

• Определение внешнего вида и технических спецификаций шаблонов с последующим внесением соответствующих изменений затронутых бизнес-процессов в Основной список бизнес-процессов (BPML).

• Создание шаблонов (если возможно, на основе стандартных шаблонов бланков и документов, предусмотренных в системе).

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

• Тестирование, анализ и одобрение результатов.

• Транспортировка шаблонов в среду «Обеспечение качества» (QA) для окончательного интеграционного тестирования.

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

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

• Определение спецификации отчета и обновление информации в соответствующих бизнес-процессах в BPML.

• Создание отчетов с использованием подходящих инструментов — таких, как АВАР/4 Query, SAP Report Writer/Painter, АВАР Reporting и т. д. По возможности, следует использовать стандартные отчеты в качестве шаблона; особое внимание стоит уделить возможному влиянию новых отчетов на общие и частные характеристики работы системы.

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

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

• Тестирование, анализ и одобрение результатов.

• Транспортировка отчета в среду «Обеспечение качества» (QA) для окончательного интеграционного тестирования.

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

• Природу объектов и данных, подлежащих конвертации

• Методы передачи данных: стандартные программы передачи данных SAP, ручной ввод данных с помощью транзакций в режиме он-лайн или программы пакетного ввода (batch input, BI).

• Объемы данных и качество данных в унаследованных системах.

• Наличие стандартных программ передачи данных в системе R/3, которые требуют, чтобы данные были в определенном формате, а также определенную последовательность загрузки данных. Требуемый формат структуры данных может быть необходим для генерации одномерных файлов.

• Установление связи между полями данных в унаследованной системе и соответствующими полями одномерного файла, который используют программы передачи данных системы R/3.

Если для конкретной ситуации нет стандартной программы передачи данных для загрузки в систему R/3, может возникнуть необходимость в разработке индивидуальной программы пакетного ввода. В SAP предусмотрено Руководство по передаче данных (Data Transfer Made Easy Guidebook) для облегчения передачи данных из унаследованных систем в SAP. Таким образом, в программе передачи и конвертации данных должны быть учтены следующие аспекты:

• Данные считываются с унаследованной системы в формате одномерного файла.

• Поля данных в унаследованной системе ассоциированы с соответствующими полями в системе R/3.

• Записи обработанных программой-конвертером данных сохраняются в другом одномерном файле, который используется программами пакетного (SAP BI) или прямого (direct input, DI) ввода данных в SAP.

В случае с индивидуально разработанной программой, вслед за ее созданием следует выполнить следующее:

• Подготовить процедуры тестирования программы конвертации.

• Тестирование, анализ и одобрение результатов.

• Транспортировка программы конвертации в среду «Обеспечение качества» (QA) для окончательного интеграционного тестирования.

При разработке интерфейсов для взаимодействия с системой R/3 необходимо рассмотреть следующие аспекты:

• Данные, которые будут проходить через указанный интерфейс

• Система, на основе которой интерфейс будет функционировать

• Возможные альтернативы данному интерфейсу

• Различные дополнительные технологии, которые можно использовать при создании данного интерфейса

• Документация по интерфейсу

• Возможные последствия использования данного интерфейса для других приложений.

Как и в случае с программами конвертации или с интеграцией различных приложений, предпочтение всегда стоит отдавать стандартным интерфейсам, предусмотренным в системах SAP. Эти стандартные интерфейсы разработаны на основе сценариев бизнес-процессов для импорта данных в систему R/3 или экспорта данных через выходы приложений. В таком случае сценарии бизнес-процессов точно заданы и определены относительно ассоциированных объектов, и их легко внедрять и поддерживать. Также в качестве альтернативы существуют программные продукты других разработчиков, которые уже сертифицированы для взаимодействия с системами SAP через дополнительные программы, и их всегда стоит иметь в виду.

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

Для передачи данных есть два метода; компания выбирает необходимый, руководствуясь внутренними требованиями. Первый — это файловый метод, когда перед передачей данные формируются в файлы, после чего файлы загружаются в другую систему, или могут использоваться другими системами. Такой пакетный метод передачи данных по принципу «сохранение, затем передача» работает только в синхронном режиме. Существуют следующие технологии внедрения пакетных интерфейсов:

• Пакетный ввод (Batch input, BI)

• Вызов транзакции (Call transaction, СТ)

• Промежуточный документ (Intermediate Document, IDoc)

• Интерфейс программирования бизнес-приложений (Business Applications Programming Interface, BAPI)

• Прямой ввод (Direct input, DI).

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

• Удаленный вызов функции (Remote Function Call, RFC)

• Обычный интерфейс программирования для обмена данными (Common Programming Interface for Communication, CPI–C)

• Технология компонентов OLE/ActiveX

• Компоненты графического интерфейса пользователя GUILIB/GUI

• Интерфейс IDoc для Electronic Data Interchange (EDI)

• Интерфейс IDoc для Application Link Enabling (ALE)

• SAP Business Workflow

• Интерфейс программирования бизнес-приложений (Business Application Programming Interface, BAPI)

• Сервер Интернет-транзакций (Internet Transaction Server, ITS)

• Компоненты Интернет-приложений (Internet Application Components, IAC).

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

• Подготовка процедур тестирования интерфейса.

• Тестирование, анализ и утверждение результатов тестирования.

• Транспортировка программ интерфейса в среду «Обеспечение качества» (QA) для окончательного интеграционного тестирования.

Примечание

Такие усовершенствования и интерфейсы, как SAP Workflow, Business Information Warehouse, SAP Business Framework, BAPI, IDoc, ALE и ITS/IAC подробно рассматриваются в главе 19.

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

• Использование индивидуальных пользовательских подключений к R/3

• Индивидуальные настройки и модификации стандартных объектов R/3

• Разработку индивидуальных настроек и объектов в среде АВАР/4.

Все модификации и усовершенствования должны быть зарегистрированы с помощью программы Регистрации изменений программного обеспечения SAP (SAP Software Change Registration, SSCR). Необходимо отметить, что модификация исходных кодов SAP и объектов словаря данных автоматически отменяет гарантийные обязательства компании SAP.

Внесение модификаций и усовершенствований состоит из следующих этапов:

• Формулировка модификации.

• Разработка модификации.

• Подготовка процедур тестирования модификации.

• Тестирование, анализ и одобрение результатов.

• Транспортировка модификации в среду «Обеспечение качества» (QA) для окончательного интеграционного тестирования.

Концепция авторизации определяет различные функции, которые могут исполнять пользователи, принадлежащие различным организационным единицам. Как уже упоминалось в разделе «Администрирование пользователей» в главе 11, концепция авторизации поддерживает баланс между управлением правами доступа и присвоением привилегий для выполнения тех или иных задач в системе, а также затратами усилий на само администрирование системы. Эта задача подразумевает создание концепции авторизации, которая отвечала бы всем необходимым требованиям.

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

Ответственность за различные процессы и функции точно определены в Концептуальном плане; такие определения ответственности используются для создания концепции авторизации. Для облегчения создания и внедрения такой концепции в системе SAP R/3 предусмотрено Руководство по системной авторизации (System Authorizations Made Easy Guide).

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

• Для каждого подразделения компании составить матрицу «Операции со всеми/некоторыми» и «Доступ ко всем/некоторым» (DO Some/All и SEE Some/All) чтобы составить профиль рисков в безопасности системы, причем это делается с участием ответственных за те или иные процессы и данные сотрудников под контролем отдела кадров. Четыре квадранта этой двумерной матрицы соответствуют следующим вариантам авторизации: Конечные пользователи могут запускать лишь некоторые определенные транзакции, и имеют доступ лишь к определенным данным в системе — «Операции с некоторыми, доступ к некоторым».

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

• Конечные пользователи могут запускать лишь некоторые определенные транзакции, и иметь доступ ко всем данным в системе — «Операции с некоторыми, доступ ко всем».

• Конечные пользователи могут запускать все транзакции и иметь доступ ко всем данным в системе — «Операции со всеми, доступ ко всем».

• На основе подробных консультаций с владельцами бизнес-процессов составить матрицу распределения ролей в системе (Job Role), с указанием различных функций и обязанностей каждого пользователя.

• Составить карту отношений между транзакциями и опциями меню системы R/3, функциональными обязанностями сотрудников и соответствующими данными. Это легко сделать, используя Концептуальный план.

• Задать группы операций. При отметке операции группируются вместе.

• Задать профили авторизации.

• Для каждого пользователя определить основные данные по пользователю (см. раздел «Администрирование пользователей» в главе 11).

• Присвоить пользователям авторизации и группы операций.

• С помощью генератора профилей создать профили пользователей на основе заданных в системе SAP авторизации и групп операций.

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

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

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

• Администраторы профилей авторизации: они создают или изменяют профили и авторизации, но не могут создавать пользователя или группу пользователей.

• Администраторы групп пользователей: они создают группы пользователей и определяют ассоциированные транзакции R/3, но не могут изменять пользователей или профили авторизации.

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

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

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

Подготовка процедур архивирования.

Внедрение процедур архивирования.

Утверждение процедур архивирования.

Проведение окончательного тестирования интеграции.

Эта задача включает в себя планирование и проведение окончательного тестирования системы на интеграцию. Тестирование проходит в системе «Обеспечение качества» (QA), в которой воспроизводятся реальные операции для функционального подтверждения возможностей рабочей системы.

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

План тестирования охватывает следующие аспекты:

• Рамки тестирования

• Сценарии тестирования

• Процессы тестирования

• Ресурсы.

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

Чтобы облегчить проведение тестирования, методология ASAP рекомендует сформировать совокупность циклов интеграционного тестирования, каждый из которых содержит набор бизнес-процессов, отсортированных по принципу приоритетности. Именно такие циклы интеграционного тестирования (L1 и L2) упоминались в разделе «Подготовка концептуального проекта» в главе 14. Циклы тестирования последовательно выполняются, пока не будут решены все проблемы и систему можно признать готовой для перехода к этапу окончательной подготовки перед запуском.

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

• Цикл 1: настройка бизнес-процессов для основных данных и высокоприоритетных транзакций с последующим тестированием важнейших бизнес-процессов.

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

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

Если нет возможности запланировать тестирование абсолютно всей системы, то можно определить приоритеты, основываясь на следующих критериях:

• Частота процесса

• Эффект от сбоя в данном процессе, количество процессов, которые зависят от данного процесса

• Вероятность того, что сценарий тестирования может случиться в реальной работе.

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

Подготовка плана окончательного интеграционного тестирования

Подготовка подробного плана интеграционного тестирования должна охватывать все процессы и компоненты, в том числе:

• бизнес-процессы

• отчеты

• интерфейсы

• конвертацию данных

• усовершенствования

• принтеры и факсы.

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

Транспортировка всех объектов в QA и «заморозка» системы

«Заморозка» системы подразумевает полную неизменность конфигурации и настроек системы до окончательного завершения полного цикла интеграционного тестирования, в том числе:

• параметров конфигурации

• настроек клиента

• данных приложений

• объектов Хранилища.

Проведение окончательного интеграционного тестирования

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

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

Примечание

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

Получение одобрения результатов тестирования на интеграцию и окончательное оформление системы

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

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

Создание плана документации для конечных пользователей

Создание такого плана требует выполнения следующих задач:

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

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

• распределение ответственности за подготовку материалов и составление графика.

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

Компиляция документации для конечных пользователей

Для облегчения этой задачи в SAP предусмотрены шаблоны процедур для конечных пользователей, которые подготавливаются на основе более шестисот заранее стандартных ВРР (см. раздел «Подготовка плана обучения пользователей и пользовательской документации»).

Подготовка плана обучения конечных пользователей

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

• идентифицировать методику обучения и необходимые материалы

• распределить ответственность и утвердить график составления обучающих материалов

• распределить ответственность и утвердить график составления материалов для инструкторов, которые будут проводить обучение

• распределить ответственность и утвердить график проведения обучения

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

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

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

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

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

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

Компания SAP рекомендует следующий список контрольных вопросов для окончательной проверки итогов этапа реализации:

• Убедитесь, что прошли все намеченные собрания по статусу проекта и совещания управляющего комитета.

• Убедитесь, что полностью составлен план перехода на новую систему.

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

• Убедитесь, что команда проекта получила адекватное обучение.

• Убедитесь, что разработаны планы тестирования системы.

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

• Проверьте подтверждение и официальное одобрение базовой конфигурации.

• Подтвердите создание системы обеспечения качества (QA).

• Подтвердите создание рабочей системы.

• Подтвердите рамки окончательной конфигурации и получите официальное одобрение.

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

• Подтвердите создание авторизации и получите официальное одобрение проектирования авторизации.

• Подтвердите создание управления архивированием

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

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

• Проконтролируйте подготовку к обучению пользователей.

Эта качественная проверка подтверждает, что окончательная конфигурация системы SAP R/3 полностью отвечает зафиксированным в Концептуальном плане требованиям компании.

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

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

Примечание

Крайне важно использовать в работе оригинальный компакт-диск с документацией по методологии AcceleratedSAP (ASAP). В этой главе представлены только важнейшие моменты этапа окончательной подготовки в рамках методологии ASAP, но их нельзя рассматривать как полноценную замену колоссального количества инструкций, указаний, рекомендаций, списков контрольных вопросов, шаблонов, образцов и вопросников, которые предоставляются компанией SAP. Эти инструменты отлично себя зарекомендовали, поэтому настоятельно рекомендуется обратиться к версии ASAP, которая соответствует версии внедряемой системы, и использовать ее на всем протяжении реализации проекта. Читателю может показаться, что содержание некоторых глав этой книги однообразно и многие фрагменты ее повторяются, однако в результате тщательного изучения станет ясно, что такие виды деятельности, как управление проектом, организационные изменения, оценка рисков, спонсорство, стратегия обмена информацией и технология внедрения во многом остаются неизменными на протяжении всех этапов внедрения и упоминаются в начале каждого этапа. Похожим образом многие мероприятия проходят через стадии планирования и исполнения, поэтому они постоянно упоминаются на различных этапах проекта, и это не повторение одного и того же, а всего лишь часть контрольного списка процессов ASAP, рекомендованных компанией SAP.

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

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

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

• Управление проектом

• Техническое управление проектом

• IТ-инфраструктура

• Процесс управления изменениями

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

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

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

• Команды, занимающейся бизнес-процессами

• Команды по управлению изменениями

• Технической команды.

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

Собрания Управляющего комитета проводятся для постоянного обновления общего статуса проекта и принятия решений по проблемам, которые невозможно решить на уровне управления проектом. На таких собраниях менеджеры проекта должны представить следующие данные:

• Статус проекта

• План следующего этапа проекта

• Сопоставление запланированных сроков и их фактическое выполнение

• Сопоставление запланированных затрат и фактические затраты

• Степень завершенности проекта в процентном выражении

• Текущая деятельность, а также предстоящие мероприятия

• Негативные и позитивные тенденции

• Принятие соответствующих мер

• Оставшиеся поставки

• Сроки и этапы

• Вопросы, требующие немедленного решения

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

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

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

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

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

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

• Пользователи транзакций

• Пользователи анализа и запросов

• Пользователи информации.

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

Подготовка к обучению конечных пользователей

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

Проведение обучения конечных пользователей

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

Обзор и оценка навыков после проведения обучения

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

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

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

Конфигурация CCMS для рабочей среды

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

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

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

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

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

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

• Конфигурацию графика резервного копирования для периодического и постоянного создания резервных копий данных.

Конфигурация администрирования печати и спулинга в рабочей среде

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

Обучение персонала системному администрированию

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

• Знакомство с системой SAP

• Навигация системы

• Мониторинг системы

• Резервное копирование системы

• Управление принтерами и печатью.

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

Тестирование администрирования системы

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

Проведение объемного тестирования

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

Проведение нагрузочного тестирования

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

Тестирование печати и факсимильной связи

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

Тестирование процедур резервного копирования и восстановления данных

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

Тестирование восстановления данных после серьезных сбоев

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

Проверка готовности системы к запуску

Этот тест осуществляет проверку конфигурации и характеристик работы системы перед фактическим запуском и переходом к этапу обслуживания системы. Услуга SAP GoingLive проверяет следующие элементы будущей рабочей системы:

• Сервер

• Базы данных

• Приложения

• Системную нагрузку

• Конфигурации.

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

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

Примечание

В методологии ASAP это пятый важный этап проекта.

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

Составление списка контрольных вопросов для перехода

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

• Данные, которые необходимо конвертировать

• Спецификации конвертации данных

• Программы конвертации

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

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

• Процессы и процедуры ручной (неавтоматической) конвертации данных.

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

• Конфигурации различных функциональных модулей, например Финансы (FI), Контроллинг (СО), Продажа и дистрибуция (SD), Планирование производства (РР), Управление материалами (ММ) и т. д.

• Все новые таблицы, экраны, программы АВАР и SAPScript

• Профили пользователей.

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

Для определения готовности системы к запуску в ASAP предусмотрен список контрольных вопросов для подтверждения того, что:

• CCMS сконфигурирован для рабочей среды.

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

• Все таблицы, программы, конфигурации и данные успешно конвертированы.

• Базы данных готовы к работе.

• Сеть готова к работе.

• Установлена система безопасности.

• Принтеры сконфигурированы для работы.

• Создано расписание фоновых задач.

• Стратегия резервного копирования и восстановления баз данных готова к работе.

• План восстановления данных после серьезных сбоев отлажен и готов к работе.

Одобрение перехода на новую систему

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

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

Определение ресурсов для справочной службы

В основном эта задача подразумевает создание процессов обмена информацией, в том числе для следующих целей:

• Регистрация проблем и отчетность по ним

• Передача и обработка сообщений о проблемах, нахождение нужного решения

• Передача сообщений о нерешаемых проблемах для рассмотрения на более высоком уровне

• Передача сообщений о нерешаемых проблемах для рассмотрения в компанию SAP

• Информирование о решениях проблем

• Демонстрация найденных решений.

Учреждение справочной системы

Эта задача подразумевает создание и организацию работы справочной системы (Help Desk), в том числе:

• Создание инфраструктуры офиса

• Создание технической инфраструктуры

• Назначение персонала и выделение необходимых ресурсов

• Обучение персонала справочной службы

• Создание пользователей OSS для соответствующего персонала службы.

Организация ресурсов и персонала для справочной системы

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

Долгосрочная стратегия поддержки рабочей системы SAP необходима для решения следующих вопросов:

• Системные изменения после внедрения

• Внедрение новых версий и модернизация

• Расширение рамок системы вследствие роста бизнеса

• Обучение новых сотрудников, необходимое из-за естественного обновления кадров.

Переход на новую рабочую систему включает в себя выполнение следующих задач:

1. Транспортировка всех установок настройки и объектов хранилища в рабочую среду.

2. Проведение конвертации всех основных данных и данных по транзакциям.

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

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

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

• Окончания обучения конечных пользователей.

• Окончания установки системного администрирования R/3.

• Окончания отладки технической инфраструктуры.

• Окончания конвертации установок настройки, основных данных и данных по транзакциям.

• Утверждения плана перехода на новую систему и ее дальнейшей поддержки.

Система запускается после того, как:

• Получено одобрение менеджеров

• Все пользователи системы готовы

• Система безопасности полностью отлажена и функционирует нормально.

Проверка качества — это завершение стадии окончательной подготовки. Для этого компания SAP рекомендует следующий список контрольных вопросов:

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

2. Убедитесь, что формирование команды, которая будет работать с SAP, уже проведено или намечено на ближайшее будущее.

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

4. Утвердите персонал и организацию администрирования системы.

5. Убедитесь, что тестирование системы R/3 принесло ожидаемые результаты.

6. Пересмотрите план поддержки рабочей системы и убедитесь в его правильности и полноте.

7. Проконтролируйте процесс перехода на новую систему.

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

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

Примечание

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

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

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

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

• Управление проектом

• Техническое управление проектом

• IT-инфраструктура

• Процесс управления изменениями

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

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

Система запускается и начинают выполнять все соответствующие функции.

Цель этой деятельности — поддержка пользователей системы SAP. План работы поддержки составляется на стадии окончательной подготовки к запуску, причем работа Справочной системы также отслеживается и отлаживается, в зависимости от результатов обратной связи с пользователями и анализа задокументированных проблем и вариантов их решения. Также проводится обучение ключевых пользователей работе с онлайновой сервисной системой SAP (Online Support System, OSS).

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

• Ежедневное отслеживание транзакций

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

Корректирующие меры могут включать следующие действия:

• Изменение бизнес-процесса

• Модификация кода (в среде АВАР)

• Изменение конфигурации

• Повторные обучающие курсы для персонала

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

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

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

Эта задача означает начало оценки преимуществ, которые дает предприятию внедрение SAP:

1. Обзор и решение всех оставшихся вопросов. Все позиции базы данных по проблемам идентифицируются, рассматриваются, решаются и закрываются.

2. Обзор бизнес-преимуществ. Результаты внедрения SAP сравниваются с целями и задачами, намеченными в начале реализации проекта. Это также подразумевает создание процедуры оценки полученных преимуществ, которая может использоваться в дальнейшем на постоянной основе.

3. Оценка процесса передачи знаний персоналу. Это подразумевает рассмотрение и документирование ключевых вопросов и выводов по результатам проекта с использованием созданной в процессе реализации проекта базы данных «Вопросы и Ответы» (Q&Adb). Эта информация имеет особую ценность, так как она максимально объективно отображает внутренние процессы, протекающие в недрах организации или предприятия.

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

Эта задача подразумевает официальное одобрение результатов проекта и закрытие проекта.

Первоначально концепцию «путей к успеху» изобрел Кристофер Александер во второй половине 70-х годов применительно к архитектуре. Эта концепция представляет собой совокупность часто используемых на практике решений, которые неизменно приводят к максимально успешному результату.

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

• Залог успеха 1: Прямое участие менеджеров высшего звена на всех стадиях реализации проекта.

• Залог успеха 2: Ясная, стройная организационная структура и эффективное управление проектом

• Залог успеха 3: Достаточная степень прозрачности и простота обмена информацией на всех участках проекта

• Залог успеха 4: План управления изменениями, охватывающий всю организацию.

• Залог успеха 5: Выделение достаточных бюджетных и других ресурсов для проекта

• Залог успеха 6: Делегирование опытных, успешных сотрудников и ключевых менеджеров для участия в проекте, но ни в коем случае не тех сотрудников, которые не играют важной роли в деятельности того или иного подразделения организации

• Залог успеха 7: Движущей силой проекта должны являться все подразделения организации, а не только отдел информационных технологий

• Залог успеха 8: Внедрение системы на пилотном участке с последующим разворачиванием проекта на остальные участки

• Залог успеха 9: Внедрение по принципу «Большого взрыва» как минимум, основных модулей

• Залог успеха 10: Четкость рамок проекта и предотвращение расползания рамок проекта в процессе работы

• Залог успеха 11: Полноценное обучение всех участников проекта SAP

• Залог успеха 12: Стандартизация бизнес-процессов и рекомендуемое внедрение стандартной функциональности SAP

• Залог успех 13: Использование внешних консультантов только для обучения собственной команды проекта, а не для выполнения всего проекта в целом

• Залог успеха 14: Планирование, мониторинг и управление расписанием проекта на всем протяжении проекта

• Залог успеха 15: Создание интерфейсов для взаимодействия с существующими (унаследованными) системами в низкоприоритетных или узкоспециальных областях функциональности

• Залог успеха 16: Готовая инфраструктура поддержки системы согласно расписанию проекта

• Залог успеха 17: Поддержка и управление инфраструктурой в масштабе всего проекта, доступная всем участникам проекта

• Залог успеха 18: Обучение всех конечных пользователей незадолго до фактического запуска системы.