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

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

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

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

• Поддержка SAP

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

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

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

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

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

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

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

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

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

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

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

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

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

• Сервер

• Сеть.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В SAP предусмотрены средства определения атрибутов для придания Клиенту конкретных свойств