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

• Всеобъемлющая функциональность

• Внутренняя гибкость

• Всеохватная стратегия модернизации.

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

Один из важнейших моментов внедрения — развертывание системы SAP на другие подразделения и участки производства после завершения внедрения системы на пилотном участке. Как уже упоминалось в главе 5 «Цикл проекта внедрения SAP» и в главе 10 «Инициация проекта SAP», развертывание системы SAP становится гораздо проще, если принять приведенные ниже меры еще во время внедрения системы на пилотном участке:

• Рационализация бизнес-процессов

• Стандартизация бизнес-процессов

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

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

Фаза развертывания системы включает в себя следующие шаги:

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

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

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

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

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

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

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

• Продолжение обучения персонала

• Мониторинг характеристик работы системы, ее дальнейшая отладка

• Управление модернизацией и внедрение новых версий SAP.

Деятельность по управлению изменениями также позволяет обратиться к вопросам, которые были оставлены за кадром при первоначальном определении рамок проекта. Необходимо отметить, что подразумевается не расширение функциональности системы SAP как таковой, а усовершенствование модулей и процессов, внедренных на начальных этапах. Например, такие вспомогательные модули, как Управление производством (РМ), Управление качеством (QM), Система проектов (PS) или даже модуль HR (Человеческие ресурсы) могут быть инсталлированы только на второй «волне» проекта. В методологии ASAP предусмотрен отдельный компонент для управления этим этапом цикла внедрения SAP. Такая деятельность также может быть направлена на внедрение функциональностей или систем, увеличивающих ценность таких базовых модулей, как:

• Автоматизированный поток операций SAP (Workflow)

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

• SAP Business Information Warehouse

• Система SAP в сети Интернет

• Системы автоматического сбора данных (Automatic Data Collection, ADC)

• Системы отслеживания мобильных данных

• Системы управления цепочками поставщиков (Supply-chain Management, SCM)

• Системы управления отношениями с потребителями (Customer Relationship Management, CRM)

• Приложения интеграции предприятий (Enterprise Integration Applications, EAI)

• Системы стратегического управления предприятием (Strategic Enterprise Management, SEM)

В других главах этой книги мы еще рассмотрим некоторые из указанных систем.

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

• Исправления — небольшие патчи, которые выпускаются SAP для устранения обнаруженных проблем в системе.

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

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

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

• Модернизация всех программ в системном ландшафте

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

• Планирование необходимых для модернизации навыков и меры по их получению.

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

• Тестирование интеграции бизнес-процессов, отчетов и интерфейсов

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

• Конфигурация и тестирование новой функциональности.

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

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

В рамках программы Центров компетенции клиента (Customer Competency Centers, ССС), компания SAP поддерживает создание таких центров у клиентов компании SAP, что позволяет SAP напрямую взаимодействовать со своими клиентами. Такие центры служат следующим целям:

• Поддержка Справочной системы (Help Desk)

• Обучение

• Информационные услуги

• Внедрение и поддержка проекта

• Координация запросов на разработку

• Бизнес-поддержка

• Техническая поддержка

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

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

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

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

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

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

• Определение и внедрение методов регистрации проблем

• Определение стандартов и процедур для диагностики проблем и нахождения решений

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

• Определение стандартов и процедур сообщений о решении проблем

• Определение стандартов и процедур для отслеживания текущих и нерешенных проблем

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

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

• Внедрение системы приложения справочной службы

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

• Назначение и обучение команды справочной службы.

В итоге все нерешенные проблемы направляются в службы поддержки компании SAP, например, в онлайновую сервисную систему (Online Service System, OSS).

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

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

Даже если удержание команды SAP приведет к значительным расходам, это будет оправдано тем, что компания сможет быстро укрепить свою конкурентоспособность, внедрив дополнительные, смежные с SAP системы, например:

• Функциональность SAP в сети Интернет

• Системы Workflow

• Системы SCM

• Системы CRM

• Системы EAI

• Программы улучшения характеристик работы (например, реинжиниринг бизнес-процессов), активный менеджмент, сбалансированная карта оценок (Balance Scorecard) и т. д.

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

• Обучение работе с Application Link Enabling (ALE)/ldoc и с такими системами электронного обмена данными (Electronic Data Interchange, EDI), как Mercator.

• Обучение внедрению Интернет-функций SAP и работе в среде «Сервер Интернет-транзакций» (Internet Transaction Server, ITS) и «Интернет-компоненты приложений» (Internet Application Components, IAC)

• Обучение проектам разработки работающих в сети World Wide Web приложений с использованием HTML, XML, ASP, EJB, Java, JavaScript, VisualBasicScript и т. д.

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

• Обучение проектам складирования данных с использованием решения SAP Business Information Warehouse, которое использует данные системы SAP.

• Обучение управлению потоками операций через работу в модуле Workflow и проектам управления документами, если компания планирует эти проекты.

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

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

• Обучение разработке продуктов на языке АВАР

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

• Обучение и работа с проектами по Интернет-инфраструктуре

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

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

• Смежное обучение по различным модулям. Консультанты по ММ и РР могут пройти смежное обучение по обоим модулям, а также по таким модулям, как QM, РМ, PS и SM. Похожим образом, консультанты по FI и СО могут пройти смежное обучение по обоим этим модулям, а также по таким модулям, как AM, TR, FM, IM, CCA, PA и EIS.

• Изучение систем SCM

• Изучение систем CRM

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

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

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

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

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

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

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

Как описывалось в главе 1, за последнее время природа организаций и предприятий кардинально изменилась. Если в эпоху индустриализации организации были независимыми единицами со своими структурами управления и контроля, то сейчас, в эпоху информации, они превратились в тесно сотрудничающие единицы; на смену многоярусной иерархии пришли рабочие команды, выполняющие различные функции. В результате этих изменений появился новый, неиерархический тип компании с сетевой организацией, прозрачными структурами обмена информацией и децентрализацией полномочий для принятия решений, в котором особое значение приобретает постоянный обмен информацией между различными командами или функциональными группами. Система SAP R/3 как раз обеспечивает такую информационную среду с помощью модулей SAP Office, SAP Workflow и SAP Business Warehouse.

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

Офисные и административные системы часто сталкивались со многими проблемами, включая:

• Задержки при передаче документов

• Обработка поступающих материалов

• Утомительная запись информации на разных этапах

• Содержащие ошибки дубликаты перезаписи информации в различных местах

• Повторные запросы

• Отслеживание документов

• Локализация документов в несоответствующих местах

• Замедление принятия решений из-за присваивания регистрационного номера

• Усилия по поддержанию рабочего задания, проходящего через различные стадии бизнес-процессов.

Системы Workflow отвечают за бизнес-процессы внутри компании, а также позволяют наладить сотрудничество и координацию действий персонала в соответствии с нуждами организаций постиндустриальной эпохи, являя собой прекрасный пример того, как технология может стать инструментом реинжиниринга бизнес-процессов всего предприятия (см. раздел «Управление изменениями на предприятии» в главе 1).

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

• Тщательное отслеживание бизнес-процессов на различных этапах

• Прямая поддержка бизнес-процессов

• Быстрый доступ к необходимой информации

• Мониторинг выполнения отдельных этапов бизнес-процесса

• В случае обнаружения «узких мест» и мелких сбоев, инициация соответствующих процедур и уведомление пользователя

• Значительное сокращение сроков передачи документов между исполнителями или функциональными подразделениями

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

Системы Workflow поддерживают и значительно ускоряют исполнение различных бизнес-процессов. Это лучший пример того, как технология делает возможным реинжиниринг процессов в масштабе всего предприятия (см. раздел «Управление изменениями на предприятии» в главе 1). Таким образом, системы управления потоком операций обеспечивают выполнение следующих функций:

• Определение списка задач и его исполнение

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

• Мониторинг и контроль потоков документов.

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

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

Модель объекта (Object Model) определяет следующие компоненты бизнес-объекта:

• Идентификация объекта

• Имя (название) объекта

• Место объекта в иерархии

• Подтип

• Ограничения объекта

• Правила

• Методы

• Атрибуты

• Событие на входе

• Событие на выходе.

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

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

Приложение SAP Business Workflow состоит из трех частей (см. рис. 19.1).

Рис. 19.1. Компоненты SAP Business Workflow.

Инструменты определения

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

• Расчленение потока операций на составляющие.

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

• Определение типов объектов потока операций в Хранилище бизнес-объектов (Business Object Repository). Объекты потока операций определяются в терминах соответствующих типов объектов, методов, признаков и событий.

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

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

Исполняющая система

Исполняющая система состоит из следующих компонентов:

• Менеджер потоков операций, который контролирует и координирует статус потоков операций.

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

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

Информационная система

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

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

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

• Мониторинг, распознавание и диагностика отдельных потоков операций.

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

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

Хранилище бизнес-информации (SAP Business Information Warehouse, BW) — это сквозное решение, основанное на последних разработках, которое обеспечивает персоналу компании быстрый доступ к данным в любой их комбинации, в любом порядке и с любой степенью детализации, причем источником данных может быть система SAP, другая система или даже внешняя среда. Это универсальное решение включает в себя средство реляционной аналитической обработки в реальном, времени (Relational Online Analytical Processing, OLAP), а также инструменты автоматического извлечения данных, хранилище мета-данных с заданной конфигурацией, удобный для пользователя интерфейс с мощными инструментами для анализа и составления отчетов, а также рабочее место администратора для управления этой средой. Решение BW включает в себя различные компоненты, которые в значительной степени автоматизируют большую часть задач и позволяют провести быстрое внедрение с минимальной необходимостью в последующей поддержке.

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

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

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

• Создание хранилищ данных на уровне подразделений компании, ведущих к единому хранилищу информации предприятия.

• Получение полных, корректных и надежных данных.

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

• Определение и построение моделей мета-данных.

• Преобразование (перенесение) данных из информационных складов R/3 в мета-данные информационного хранилища.

• Заполнение информационного хранилища из информационных складов R/3.

SAP BW имеет также следующие преимущества:

• Подход к данным с точки зрения бизнес-процессов; интеграция такого подхода в масштабе всего предприятия

• Обширные возможности и функции отчетности в SAP R/3

• Многочисленные открытые системные решения SAP для взаимодействия с различными внешними системами

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

SAP BW — это исчерпывающее решение, которое использует все преимущества системы R/3, однако вовсе не ограничивается ее пределами.

Наиболее выдающимися характеристиками SAP BW являются следующие:

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

• Использование бизнес-процессов и мета-данных, которые являются неотъемлемой частью систем SAP.

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

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

• Готовые отчеты предоставляются в формате MS Excel, что позволяет легко и быстро настраивать отчеты в соответствии с конкретными пожеланиями и требованиями.

• Для удобства работы пользователи могут группировать часто используемые отчеты.

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

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

• В BW предусмотрена эталонная модель предприятия для применения к данным делового регламента.

• Использование всех преимуществ стандартизованной технологии Базиса R/3 — таких, как масштабируемость, легкость доступа, безопасность, интеграция и возможность взаимодействия сетей.

В следующих разделах рассматриваются основные компоненты архитектуры BW, представленные на рис. 19.2. На рис. 19.3 представлены соответствующие карты решений.

Рис. 19.2. Компоненты SAP BW.

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

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

Администрирование данных

Рабочее место администратора обеспечивает обслуживание и управление всех ключевых аспектов работы BW. Во многом этому способствует Хранилище SAP, которое приспособлено и к среде SAP R/3, и к среде BW. Компании также могут создавать и поддерживать склады данных на уровне подразделений компании. Дизайнер схем позволяет пользователям создавать ИнфоКубы (InfoCubes) и структуры передачи данных (InfoSources), задавать правила отслеживания и трансформации данных для отображения сегментов рабочей информации BW в ИнфоКубах (InfoCubes и InfoSources подробно рассматриваются в последующих разделах).

Рис. 19.3. Карта решения SAP BW.

После создания исходных и конечных структур и установления правил маршрутизации, администратор может контролировать и управлять операциями BW посредством Планировщика, а также с помощью загрузки данных (Data Load) и доступа к данным (Data Access). Data Load контролирует процессы загрузки, трансформации и записи данных, а также предоставляет статистику по текущим, завершенным или прерванным задачам с указанием причин. Data Access предоставляет статистику по использованию BW — например, по частотности запросов или доступу к итоговой информации.

Извлечение данных

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

Полученные данные представляют собой точный снимок данных OLTP из всех стандартных модулей и приложений SAP; во время первоначальной записи данных (на этапе создания BW), все данные OLTP передаются в BW. Однако в случае с BW, в отличие от обычных складов данных, записываются только изменения в данных, что значительно снижает объем передачи данных во время рутинных операций.

Преобразование и загрузка данных

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

Хранение и представление данных

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

По сути ИнфоКубы — это набор реляционных таблиц, организованный по звездообразной схеме с одной большой таблицей фактов с центре, окруженной несколькими пространственными таблицами. В таблице фактов хранятся упомянутые выше ключевые значения, в то время как в многомерных таблицах содержатся характеристики, которые используются для анализа ключевых значений и составления отчетов; измерения независимы друг от друга — их объединяет только центральная таблица. Основные данные (Master data) состоят из общей (неизменной) информации о потребителях, поставщиках и продуктах — эти данные легко загружаются из R/3. Также BW позволяет задавать иерархию характеристик, причем иерархические отношения не зависят от ИнфоКубов, которые в основном используются для запроса данных и составления отчетов на различных уровнях.

Примечательно, что в BW нет необходимости в создании хранилища метаданных, которое содержало бы описания данных, хранящихся в ИнфоКубах, передаточных структурах и BW. Причина в том, что в системе SAP R/3 уже есть базовая среда для этой цели — хранилище R/3. Такое устройство обеспечивает единообразие данных как во всех подсистемах BW, так и в источниках OLTP в системе R/3. Ниже приведены различные классы мета-данных (в форме каталогов), которые поддерживает BW:

• Каталог InfoObject: предоставляет стандартное описание всех характеристик и ключевых данных, используемых в InfoSources и ИнфоКубах, поддерживает определения производных (вторичных) ключевых данных, которые рассчитываются на основе базовых ключевых значений во время составления отчета.

• Каталог InfoSource: содержит описание каждого InfoSource с точки зрения InfoObjects, а также относительно их связи с ИнфоКубами.

• Каталог InfoCube: содержит описание каждого ИнфоКуба — составляющие характеристики и ключевые значения.

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

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

Бизнес-анализ

В BW предусмотрена полноценная аналитическая машина OLAP, которая поддерживает несколько типов анализа; OLAP анализирует данные в Инфо-Кубах и представляет различные срезы как базовых данных, так и проанализированных данных через Бизнес-Навигатор (Business Explorer).

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

Кроме того, в OLAP предусмотрены следующие обширные возможности анализа данных, содержащихся в ИнфоКубах:

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

• Функции сравнения: возможности подсчета отклонений, изменений, соотношений и т. п.

• Функции очередности служат для сортировки, вычисления итоговых сумм элементарного арифметического анализа и т. д.

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

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

Система отчетности

Для создания отчетов в BW предусмотрен Бизнес-Навигатор — не только для составления стандартных отчетов, но и для специального анализа данных в ИнфоКубах. Отчеты создаются следующим образом:

• Отбираются и высчитываются соответствующие характеристики и ключевые значения

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

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

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

Представление

Пользовательский интерфейс BW — Business Explorer выводит результаты на экран в формате MS Excel, что позволяет задействовать обширные возможности Excel в области форматирования и дизайна. Система также позволяет, в случае необходимости, рассмотреть данные в BW с нестандартных точек зрения.

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

Бизнес-структура SAP (SAP Business Framework) имеет всеохватывающую структуру, позволяющую интегрироваться и работать с другими системами R/3, а также с программными продуктами других производителей; она обеспечивает максимальное взаимодействие сетей и гибкость, необходимую для быстрого внедрения изменений в интерфейсы, а также постоянную поддержку различных компонентов структуры без помех для работы системы в целом. Кроме того, бизнес-структура распространяет принцип ориентации на объекты также и на функции бизнеса (см. раздел «Ориентация на объекты» в главе 8). В целом Business Framework структура, основанная на компонентах приложений и бизнес-объектах функциональности SAP R/3. Компания SAP представила технологию ориентации на объекты, придав бизнес-процессам и данным в системе R/3 роль бизнес-объектов; любые внешние приложения и системы могут взаимодействовать с этими объектами через стандартизованные, независимые от платформы и операционной системы интерфейсы, которые называются BAPI (Business Application Programming Interfaces).

В основе бизнес-структуры лежит иерархия компонентов, которые мы обсудим подробней в следующих подразделах. Преимущества SAP Business Framework перечислены ниже:

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

• компоненты от разных поставщиков также можно комбинировать

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

• компоненты можно внедрять централизованно или локально

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

Бизнес-компоненты

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

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

Бизнес-объекты

Бизнес-объекты — это уникальные функциональные единицы, которые представляют собой обычно опознаваемые, тесно взаимодействующие виды деятельности, связанные с заказами на закупку и поставку, счетами-фактурами и т. п.

То, что SAP определяет их как отдельно опознаваемые бизнес-объекты, дает возможность управлять ими и осуществлять повседневную поддержку и доработку полуавтономно, не влияя на операции других объектов. SAP R/3 3.0 имел более 200 BAPI.

Как и любой другой типичный объект, бизнес-объект определяется по его типу (или CDO), методам (BAPIs), атрибутам, и т. д. Основная выгода от объектной ориентации состоит в возможности повторного использования программного обеспечения и функциональных возможностей. Повторное использование программного обеспечения — это возможность получения новых объектов из уже существующих: полученные объекты называются подтипами, а те, что легли в их основу — супертипами. Подтип наследует все признаки и методы супертипа, хотя он дополнительно может иметь и свои собственные. В уже упоминавшемся примере про автомобиль, подтип Грузовик имеет все свойства супертипа — Автомобиля.

Бизнес-объекты SAP инкапсулируют данные R/3 и бизнес-процессы, скрывая структуру и детали исполнения лежащих в основе данных. Это достигается за счет того, что модули бизнес-объектов SAP имеют многоуровневую структуру, состоящую из:

 Ядра: этот внутренний слой представляет принадлежащие объекту данные.

 Уровня целостности: на этом уровне представлена бизнес-логика объекта, которая состоит из делового регламента, а также ограничений на объем и границ, применяемых к бизнес-объектам SAP.

 Уровня интерфейса: этот уровень обеспечивает независимое от платформы описание внедрения бизнес-объекта SAP для внешних систем. Это достигается через BAPI.

 Уровня доступа: этот уровень идентифицирует и определяет технологии, которые дают внешним системам доступ к уровню ядра, то есть к данным объекта. Это могут быть COM/DCOM, RFC(Remote Function Call) и другие технологии.

Рисунок 19.4 показывает разные уровни бизнес-объекта.

Интерфейс программирования бизнес-приложений

Business Programming Interfaces (BAPI) — это методы или процедуры, которые присваиваются бизнес-объекту. Они являются инкапсуляциями различных операций, которые могут быть проделаны с этими бизнес-объектами. Например, в случае со счетом-фактурой покупателя, различные BAPI дают возможность выполнить проверку достоверности (ратификацию), подсчет налогов, стоимости перевозки и т. п.; определение находящихся на рассмотрении и просроченных счетов-фактур; проверку оплаты, анализ амортизации и т. д. Стандартная лицензия SAP уже имеет библиотеку из более чем 200 BAPI, которая регулярно пополняется.

Репозитарий бизнес-объектов (BOR) хранит и управляет бизнес-объектами и соответствующими им BAPI как отдельными единицами. Это практическое проявление бизнес-компонентов на самом низком уровне деятельности. SAP уже имеет библиотеку из более чем 200 BAPI, которая регулярно пополняется. В настоящий момент BAPI внедряются в качестве функциональных модулей, которые создаются и управляются в Построителе функций (Function Builder). BAPI имеют следующие характеристики:

• Они связаны с бизнес-объектами SAP

• Они поддерживают протокол RFC (Remote Function Call) для сообщения с внешними системами

• Они вызывают программы через диалоговые экраны.

BAPI обеспечивают важные преимущества объектной ориентации, такие как:

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

• Поддержка стандартных интерфейсов

• Совместимость с различными технологиями коммуникации

• Автономное усовершенствование и техническое обслуживание. Бизнес-объекты с соответствующими им BAPI точно указывают направление будущих усовершенствований в системе SAP.

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

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

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

• в комплексе самостоятельных систем, которые можно внедрять по отдельности. Application Link Enabling (ALE) является базовым компонентом бизнес-структуры SAP, при помощи которого осуществляется обмен и интеграция компонентов программного обеспечения SAP и других производителей. Стандартная лицензия SAP имеет заранее скомпонованный набор бизнес-процессов ALE, наряду с механизмами для развития и тестирования приложений ALE.

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

• Централизованные продажи и планирование производства и децентрализованное планирование необходимых материалов (Material Requirements Planning, MRP)

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

• Централизованная финансовая система и децентрализованная система логистики

• Централизованный анализ прибыльности и децентрализованное ценообразование.

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

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

Важнейшие преимущества ALE — это:

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

• Лучшие входные интерфейсы, в сравнении с пакетной передачей данных (batch data communications, BDC) и вызовом транзакций (call transactions, СТ)

• Возможность коммуникации между различными версиями SAP

• Соединение с иными (не SAP) приложениями без нарушения данных и последовательности бизнес-действий

• Несинхронная интеграция компонентов бизнес-структуры, включая бизнес-компоненты, бизнес-объекты и BAPI.

Основной принцип, стоящий за ALE — это гарантия полной интеграции SAP R/3. Каждое приложение является автономным и существует в распределенной среде со своим набором данных. Использование автономных систем подразумевает некоторую степень избыточности данных, а это предполагает, что данные должны быть распределены и синхронизированы во всей системе. Это достигается при помощи асинхронной коммуникации. Архитектура механизма сообщений ALE состоит из трех уровней.

Сервисы приложений

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

Сервисы дистрибуции

Этот уровень, способствующий интеграции бизнес-приложений, включает:

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

• Фильтрацию и перекодировку сообщений

• Сжатие сообщений для уменьшения объема передаваемой информации.

Сервисы коммуникации

Обмен сообщениями ALE происходит при помощи асинхронного удаленного вызова функции (RFC) или электронного обмена данными (Electronic Data Interchange, EDI). Для использования функции информационного поиска может быть применен синхронный RFC.

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

Логическая модель

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

Тип сообщений

Этот компонент применяется для обмена между различными системами. Тип сообщения определяет сообщение и устанавливает его отношение к типу промежуточного документа (IDoc). MATMAS, например, является стандартным типом сообщения для основных записей материалов. ALE поддерживает более 200 типов сообщений.

Промежуточные документы и их типы

Тип IDoc представляет структуру и формат данных для типа сообщения. IDoc состоит из следующих записей:

• Управляющие записи: однозначно определяют IDoc через тип IDoc, тип сообщения, отправителя и получателя.

• Записи данных: содержат данные приложений. Каждая запись содержит раздел с описанием содержания данных. IDoc может состоять из одной или более записей данных. Количество данных определяется в каждом конкретном случае и зависит от структуры сегмента, идентификации, последовательности и иерархии. При обработке исходящих документов функциональные модули ALE/EDI заполняют эти сегменты данными приложений.

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

Клиентская модель распределения

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

Объект фильтра и его тип

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

Классификационные списки

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

Указатель изменений

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

Порты

Это логическое представление коммуникации, которое применяется ALE (например R/2, tRFC, File, Интернет) для отправления IDoc. EDI использует большинство портов на базе файлов.

Контроль сообщений и тип вывода

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

Коды операций

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

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

Профиль партнеров определяет систему, используемую для создания сообщений. Существует четыре типа профилей: KU — для клиентов, LI — для производителей, В — для банков, LS — для логических систем. ALE использует только LS, остальные три — для интерфейсов EDI. Профили партнеров содержат все необходимые параметры, включая типы сообщений, типы IDoc, функции партнеров, коды обработки, идентификаторы приложений, функции сообщений, типы вывода и порты.

Сценарии ALE

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

• Контрольные данные: включают данные настройки R/3 IMG, контрольные данные сценариев распределения IMG и контрольные данные модели распределения между клиентами.

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

• Данные транзакции: счета-фактуры, заказ клиента, заказ на поставку, уведомление о перевозке и т. п.

В качестве примера возьмем сценарий ALE-распределения основных данных между разветвленными системами R/3, показанный на рисунке 19.5. Например, центральный офис несет ответственность за основные данные о материалах. Допустим, что они рассредоточены в системах двух разных заводов: 5001 и 6001. ALE дает возможность отфильтровывать и рассылать только важную информацию в соответствующие системы. Типом объекта фильтра, используемого для сообщения MATMAS (material master — основные данные о материалах) является WERKS (наименование завода). Как упоминалось ранее, данные о материалах полностью передаются из центрального офиса в соответствующие системы, после чего нужно отслеживать только изменения в информации и рассылать их в заводские системы.

Рис. 19.5. Передача IDoc при помощи ALE.

Компании тесно взаимодействуют со своими клиентами и производителями. Для многих крупных компаний эти отношения влекут за собой непосредственную связь между их компьютерными системами. Electronic Data Interchange (EDI) это система, предназначенная для автоматической передачи бизнес-документов. EDI также можно рассматривать в качестве BPR (Business Process Reengineering) для процессов внутри компании. В отличие от традиционных BPR, такой обмен не ограничивается одной компанией, а распространен за ее пределы. С этой точки зрения, помимо сокращения объема работ по внутренней и внешней обработке сообщений, перепроектирование процессов внутри компании путем внедрения EDI существенно уменьшает время ожидания, снижающее ценность.

Архитектура EDI

Электронный обмен данными (EDI) состоит из приложения, поддерживаемого EDI, интерфейса IDoc и подсистемы EDI. Приложение, поддерживаемое EDI, способно обрабатывать бизнес-операции, полученные через EDI, подобно SAP R/3. Интерфейс IDoc соединяет приложения и подсистему EDI. Подсистема EDI конвертирует сообщения EDI с международных стандартов (EDIFACT или Х.12) в IDoc и наоборот, и передает их обычно через сеть VAN. Подсистема EDI, имеющая трехчастную структуру, также выполняет множество других функций, среди которых:

• Передача и получение сообщений EDI

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

• Подтверждение доставки и функциональное подтверждение

• Повторная передача в случае помех

• Присвоение сообщений EDI IDoc и наоборот

• Перевод сообщений EDI в IDoc и наоборот

• Специфическая обработка в зависимости от партнера

• Ведение профилей партнеров

• Обмен полученными IDoc с системой R/3.

Поток данных в исходящей обработке

Как говорилось в разделе посвященном ALE, коммуникация IDoc у ALE и EDI довольно схожа. Сценарий отправки сообщения EDI через интерфейс IDoc включает следующие шаги (см. рис. 19.6):

1. Подключение интерфейса IDoc к подсистеме EDI.

2. Определение порта

3. Подготовка профиля партнера

4. Если это логистическое приложение, то по умолчанию источником сообщения будет либо модуль приложения, либо Контроль сообщений (Message Control). В последнем случае все параметры Контроля сообщений должны быть определены.

5. Настройка расписания программы RSNAST00.

6. После того, как сформируется новый заказ на поставку (Purchase Order, PO), он будет внесен в расписание коммуникаций, зависящий от настроек Контроля сообщений (Message Control).

7. Запуск программы RASNASTED для подготовки сообщения EDI.

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

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

10. В зависимости от выбранного режима вывода в профиле партнера, IDoc отсылается.

11. Используя номер IDoc в качестве идентификатора, система EDI посылает соответствующие сообщения о получении в интерфейс IDoc.

Рис. 19.6. Поток данных в исходящей обработке.

Значение системы Интернет не в том, что она увеличивает сферу действия предприятия и его маневренность. Скорее, значимо то, что Интернет сам стал важнейшим компонентом рыночной среды и все мировые компании должны адаптироваться к этому новому окружению. Разумное использование Интернет-технологий для бизнес-операций стало важнейшим фактором успеха для многих предприятий. Это справедливо для всех ERP включая SAP R/3.

Web-поддержка SAP R/3 осуществляется достаточно просто благодаря следующему:

• Обработка данных Интернет-версии и версии клиент-сервер SAP используют одинаковый протокол передачи (TCP/IP).

• Интернет-технология на основе браузера во многом совпадает с вариантом «тонкого» клиента SAP в трехуровневой архитектуре клиент/сервер.

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

Вообще говоря, принципы, по которым работает Интернет, не сильно отличаются от принципов работы SAP R/3. В системе SAP R/3 сервер приложений функционирует в качестве сервера, а графический интерфейс пользователя SAP (SAPGUI) выступает в качестве клиента. Точно также, в случае с Интернет, браузер выступает клиентом, а Web-сервер — сервером, который предоставляет все документы и сервисы, требующиеся клиенту Web-браузера.

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

Подход «снаружи внутрь»

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

Этот подход обычно использует RFC для вызова функций SAP через RFC APIs. Но для доступа к данным через RFC пользователь должен уметь программировать на АВАР/4.

Другой вариант — использовать SAP Automation, что позволяет напрямую задействовать функции SAPGUI для внешних программ. Вдобавок, это не требует знания АВАР/4, но SAP Automation применим только для доступа к существующим транзакциям SAP.

Нужно отметить, что написание Ваших собственных программ доступа к данным возможно только в том случае, если ни один BAPI не доступен. К тому же, прямые вызовы RFC — дело прошлого; SAP позволяет очень рационально вызывать BAPI через соединитель DCOM.

Подход «изнутри наружу»

Сервер Интернет-транзакций (Internet transaction server, ITS) стал доступен в SAP R/3 с выпуска версии 3.1. Это решение обеспечивает доступ к SAP через сеть Интернет. ITS обеспечивает доступ к функциям системы R/3 и одновременно служит шлюзом для преобразования HTML и интерфейсом Web-сервера. Сначала ITS моделирует SAPGUI, ожидаемую системой R/3; канал коммуникации SAPGUI создает действующую связь с сервером приложений R/3. Интерфейс Dynamic Information and Action Gateway (DIAG) на уровне SAPGUI организует прозрачный двухсторонний обмен данными с системой SAP, позволяя ему выполнять несколько Интернет-транзакций одновременно.

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

Примечание

ITS мы обсудим в следующем разделе, но уже сейчас следует отметить, что еще одним преимуществом четырехзвенной архитектуры R/3 является то, что она полностью отделяет конструирование и разработку Интернет-приложений R/3 на базе АВАР/4 от конструирования пользовательского Web-интерфейса. Последнее требует особых навыков и по большей части выполняется опытными визуализаторами и эргономистами.

Система R/3 и Интернет используют различные протоколы коммуникации и форматы данных. Это происходит оттого, что в Web отсутствует информация о статусе, в отличие от ориентированной на транзакции и сессии системы SAP. ITS обеспечивает интерфейс взаимодействия между Интернет и системой R/3 для доступа к ней с Web-браузера или серверной программы HTTP.

Когда сервер HTTP получает запрос от пользователя, он запускает программу ITS для преобразования содержимого HTML-страниц в данные на экране R/3. Эти данные передаются между ITS и R/3 при помощи интерфейса DIAG, что позволяет ITS работать как обычный SAPGUI при коммуникации с системой R/3. Это инициирует транзакцию в системе R/3; данные на экране, предоставленные системой SAP, преобразуются при помощи ITS обратно в HTML страницу, которая затем переправляется через сервер HTTP на Web-браузер, где и отображается. Транзакция, происходящая в R/3, выполняет следующий шаг, в зависимости от действий пользователя; при этом пользователь вводит необходимые данные через страницу HTML.

Помимо того, что ITS служит шлюзом между сервером HTTP и системой R/3, он также выполняет другие функции, например администрирование Web-пользователей, ресурсов системы и Web-транзакций.

Использование этого подхода для связи сервера HTTP и системы R/3 имеет следующие преимущества:

• Web-транзакция может быть разработана и протестирована в системе R/3.

• Соединения используют только стандартные протестированные интерфейсы R/3.

• Все компоненты транзакции могут храниться в системе R/3, включая те, которыми ITS пользовался за пределами системы R/3 во время работы.

• Различные компоненты Web-транзакций могут быть включены в рабочее место Workbench Organizer. Как и любые другие, Web-транзакции сначала могут быть разработаны в тестовой системе, и потом перенесены в производственную систему.

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

• Защита транзакций R/3 может быть применена и к Web-приложениям.

• Доступность и масштабируемость R/3 может распространиться на Web-транзакции.

• Система R/3 предоставляет Web-приложениям динамически извлекаемую или текущую, последнюю информацию.

• Поддержка всех распространенных браузеров.

• Поддержка интеграции со всеми лидирующими Web-серверами, в том числе с Microsoft IIS, Netscape Enterprise server и любыми другими серверами с использованием общих межсетевых интерфейсов (Common Gateway Interface, CGI).

Выбор сервера приложений SAP R/3 в качестве платформы для развития Web-приложений позволяет SAP использовать преимущества этой проверенной среды, такие как:

• Рабочее место разработчика АВАР/4

• Концепция управления и полномочий пользователей

• Система проведения изменений и переносов (Change and Transport System, CTS)

• Поток операций (Workflow)

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

• Буферизация базы данных

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

• Поддержка различных языков

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

• Масштабируемость.

ITS предоставляет возможность готовой конверсии транзакций R/3 в Web-транзакции. Большая часть стандартных бизнес-приложений SAP используют HTML 4 и такую возможность, как каскадная таблица стилей (Cascading Style Sheets, CSS).

Архитектура ITS

ITS составляют два независимых компонента: Web-шлюз (WGate) и Шлюз приложений (AGate), которые сообщаются через TCP/IP. Это позволяет им работать на различных компьютерах, что является целесообразным с точки зрения надежности и масштабирования.

WGate обеспечивает интерфейс для Web-сервера и доступен для загрузки в качестве DLL (Dynamic Link Library) во время рабочего цикла для Windows NT 4.0 на MS IIS и сервере Netscape Enterprise.

AGate обеспечивает интерфейс для приложений R/3, используя протокол DIAG. В данный момент этот шлюз доступен в Windows NT 4.0. Несколько Web-серверов и соответствующие им Web-шлюзы могут сообщаться с одним AGate. Первый вызов нового соединения на Web-сервер начинает новое соединение в ITS. Во время передачи данных система накапливает данные в контекстовых структурах AGate, что помогает сделать ITS доступным для транзакций R/3, а также облегчает контроль сеанса ITS.

AGate отвечает за управление соединением, включая отображение экранов R/3 или функциональных модулей в HTML, управление временным лимитом Web-соединения, управление соединением R/3, создание страниц HTML. Связь обрывается только по причине отключения пользователя или из-за временного лимита. Статус соединения позволяет повторно синхронизировать ситуацию в Интернете и в соответствующей транзакции R/3.

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

Файлы ITS

Вне системы транзакция R/3 определяется не по коду транзакции, а по имени сервиса, как Интернет-приложение или сервис. Файлы описания сервисов играют большую роль при создании прикладных Интернет-компонентов (Internet Application Component, IAC) и они запрашиваются при запуске IAC:

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

 Специфический сервис: для каждой R/3-транзакции есть один файл специфического сервиса. Информация файла специфического сервиса накладывается на информацию глобального сервиса. Этот файл содержит такую информацию, как обязательное имя транзакции, имя соответствующего сервера приложений R/3 и дополнительную информацию о логине, пароле, клиенте, языке и т. п. Сервисы разработаны в SAP@Web Studio.

 Шаблоны HTML: ITS использует многоступенчатый (многошаговый) процесс разработки финальных страниц HTML, применяя заранее определенные шаблоны, доступные с ITS. Как и другие сервисы, шаблоны HTML могут быть двух типов: системные и специфические. Шаблоны HTML содержат метки-заполнители для соответствующих областей экранов R/3, и это позволяет шлюзам приложений (AGate) размещать информацию с HTML в области экрана и наоборот. Системные шаблоны, которые не распознаются или не существенны для транзакции R/3, создают сообщения об ошибке, отображаемые на Web-браузере.

Бизнес-HTML

Бизнес-HTML состоит из формулировок, специфичных для каждого ITS, содержащихся в шаблонах HTML. Эти формулировки не являются частью стандартного HTML и не распознаются Web-браузерами. Они только контролируют интерфейс ITS в системе R/3.

Шаблоны HTML разработаны в SAP@Web Studio; каждый шаблон HTML соответствует только одной транзакции R/3 и присвоен только одной теме сервиса. Они также могут содержать URL для бинарных объектов типа графических и звуковых файлов, используемых Web сервером, несмотря на то, что они прозрачны для функций ITS. Шаблоны HTML не содержат бизнес-логики, только визуальные элементы для ввода и вывода транзакций R/3; вся логика продолжает оставаться внутри системы R/3.

• Языковые ресурсы: шаблоны HTML могут содержать метки-заполнители для текстовых элементов, которые заполняются из файла языковых ресурсов в соответствии с языком, выбранным во время входа в систему. Перевод производится путем определения ключей в шаблоне и запоминания отображения ключей в фактической строке языкового ресурса. Языковые ресурсы могут быть созданы в SAP@Web Studio для каждого сервиса и для каждой команды сервиса. Каждый сервис может содержать один или несколько файлов языковых ресурсов, чтобы предоставить различные языки специфической Web-транзакции.

• Команда: позволяет сервису иметь различный внешний вид с помощью использования различных тем.

Инструменты ITS

SAP@Web Studio используется для создания Интернет-транзакций; позволяет создавать и поддерживать различные файлы описанных ранее сервисов, что необходимо для запуска Интернет-приложений IAC.

ITS Отладчик (Debugger) позволяет создавать параллельное соединение между Web-транзакцией и соответствующей R/3-транзакцией через SAPGUI одновременно. Это делает возможным переключение между транзакциями, которые видимы в обеих средах, что чрезвычайно помогает при отладке.

Прикладной Интернет-компонент

Прикладные Интернет-компоненты (Internet Application Components, IAC) — это Интернет-приложения, состоящие из транзакций АВАР и соответствующих им шаблонов HTML, о которых говорилось ранее. Они также включают описания вышеупомянутых сервисов. IAC выполняют бизнес-процессы, используя BAPI, хотя могут также применять и традиционные функциональные модули. Объектно-ориентированная природа BAPI позволяет IAC легко поддерживать и обеспечивать независимость своих версий.

Тем не менее, ITS не может использовать стандартные транзакции R/3 без каких-либо модификаций. Характеристики Интернета запрещают применение следующих экранных характеристик в обычной транзакции R/3:

• Строка меню

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

• Диалоговые окна (для сообщений, предупреждений и т. п.)

• F1 (Помощь) и F4 для кода поиска и справки по допустимым значениям

• Элементы управления окном (например, бегунок или экранная кнопка).

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

ITS может также вызывать функциональные модули, используя RFC-интерфейс SAP. Модель программирования основанная на RFC называется WebRFC. Она запрашивает функциональный модуль к каждой странице HTML. Эта модель удобна для приложений, где соответствующий Web-пользователь не должен следовать четкому диалоговому режиму. Примером таких приложений может быть быстрый просмотр списка источников или отбор в корзину объектов, каталогов и т. п. Система запускает базирующийся на RFC-интерфейс без программирования доступа в Интернет на языках типа С или С++.

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

Цикл запроса/ответа ITS

Цикл запроса/ответа ITS, как показано на рисунке 19.7, работает следующим образом:

1. Пользователь выбирает страницу HTML, соответствующую IAC на Web-браузере.

2. WGate создает соединение с AGate. AGate загружает соответствующий сервис и интерпретирует описание сервиса, при этом специфические настройки заменяются на более общие настройки.

3. AGate открывает соединение SAPGUI с системой R/3 и стартует транзакцию R/3, определенную в файле сервиса в системе R/3.

4. Система передает основной экран в AGate через интерфейс DAIG. AGate накапливает необходимые контекстные поля в ITS.

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

6. AGate передает заполненную страницу HTML в WGate, который возвращает эту страницу на браузер пользователя через Web-сервер.

Рис. 19.7. Цикл запроса/ответа ITS.

В этой главе мы рассмотрели возможности модернизации и взаимодействий, предоставляемые SAP, для расширения этих областей как внутри, так и вне организации. В первой части главы мы обсудили корпоративные решения SAP — автоматизированный поток операций (SAP Business Workflow), информационное хранилище SAP (SAP Business Information Warehouse, BW) и бизнес-структуру SAP (SAP Business Framework); а во второй части мы рассмотрели решения для коммуникационных приложений — Application Link Enabling (ALE), Electronic Data Interchange (EDI) и SAP ITS/IAC. Однако, бизнес требует увеличения функциональности приложений для расширении сотрудничества с партнерами и с клиентами. В последней части этой книги мы рассмотрим различные типы решений, которые необходимы для предприятия, основанного на сотрудничестве (Extended Collaborative Enterprise, ЕСЕ) и соответствующие им стратегии и решения, предоставляемые SAP.