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

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

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

• Генеральный директор (Chief Managing Director, CMD) или управляющий директор (Chief Executive Officer, CEO)

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

• Главный менеджер проекта

• Руководитель административной службы (Chief Operating Officer, COO) или вице-президент по деловым операциям

• Главный управляющий по информации (Chief Information Officer, СЮ) или вице-президент по системам

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

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

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

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

• Начальник проектного офиса

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

• Представители ключевых пользователей

• Все ключевые консультанты

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

• Представители высшего звена руководства

• Консультанты управляющего директора.

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

Роль и ответственность членов исполнительного и организационного комитетов состоит в следующем:

• Определение направления всего проекта

• Утверждение рамок проекта и стратегии внедрения с последующим контролем

• Утверждение обнаруженных рисков и принятие решений по мерам их минимизации

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

• Утверждение плана кадрового обеспечения для проекта SAP

• Утверждение бюджета и плана обучения для проекта SAP

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

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

• Решение вопросов, возникающих во время окончательного определения и стандартизации бизнес-процессов

• Решение административных вопросов, с которыми иногда сталкиваются консультанты.

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

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

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

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

Запуск проекта SAP подразумевает установление структур управления и назначение руководителя проектного офиса (Chief Project Officer, СРО), который должен будет сформулировать механизм отбора бизнес-процессов для членов команды внедрения и запустить его.

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

В этом разделе мы рассмотрим организационную структуру проекта SAP.

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

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

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

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

• Утверждение рамок проекта и стратегии внедрения, а также контроль над соблюдением стратегии и предотвращение расползания рамок проекта.

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

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

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

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

• Решение вопросов, возникающих во время окончательного определения и стандартизации бизнес-процессов

• Решение административных вопросов, с которыми иногда сталкиваются консультанты

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

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

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

• Обеспечение информированности компании SAP и ее партнеров относительно особых требований компании к системе.

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

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

Локальные менеджеры проекта (Site Project Managers, SPM) отвечают за внедрение SAP на различных участках, они работают под прямым руководством Руководителя проектного офиса. Эти менеджеры с самого начала должны быть членами команды внедрения на пилотном участке, что обеспечит им опыт работы с системой, необходимый для внедрения на их индивидуальных участках. Обязанности Локального менеджера проекта включают в себя:

• Контроль проекта на своем участке.

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

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

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

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

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

• Решение административных вопросов, с которыми иногда сталкиваются консультанты.

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

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

Локальный менеджер проекта также отвечает за поддержку руководства по внедрению на своем участке.

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

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

Успех любого проекта SAP в огромной степени зависит от предоставления необходимых ресурсов в полном объеме и в установленные сроки. По сравнению с аналогичными по масштабу и уровню инвестиций IT-проектами, внедрение SAP протекает гораздо быстрее. Именно поэтому необходим менеджер по ресурсам (Resource Manager), который имеет опыт закупок и несет ответственность за предоставление ресурсов для IT-проектов. Менеджер по ресурсам должен хорошо разбираться в процедурах закупок компании и ее политике в этом отношении, а также в процедурах отчетности об освоении средств в рамках проекта SAP.

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

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

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

Во время обучения функциональной и технической команд можно получить лицензии на Internet Demo and Evaluation System (IDES) и InfoDB с соответствующей инфраструктурой терминалов, сети и т. д. Подобным образом, перед началом обучения конечных пользователей необходимо полностью составить и утвердить обусловленную спецификой компании документацию для всех модулей, и в дальнейшем использовать ее для обучения.

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

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

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

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

• Составление бюджета и своевременное выделение средств на соответствующих этапах проекта.

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

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

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

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

Системы ERP в прямом смысле доносят компьютеризацию до рабочих мест непосредственных исполнителей деловых операций. Именно поэтому требования к обучению персонала в рамках проекта SAP столь обширны и могут потребовать участия 10–20 % кадрового состава компании. Обучение SAP может затрагивать три группы:

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

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

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

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

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

• Недостаток ресурсов

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

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

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

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

• Обучение различных групп пользователей работе с новой системой

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

• Загрузка всех необходимых данных в новую систему

• Параллельная работа старой и новой систем

• Переход на другую систему

• Превышение крайних сроков

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

• Несогласие пользователей, их нежелание принимать участие в проекте

• Сбои в инфраструктуре или программном обеспечении.

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

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

• Понимание того, что может обеспечить система SAP

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

• Правильная конфигурация системы SAP и корректное осуществление настроек

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

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

• Загрузка всех необходимых данных в новую систему

• Быстрое переключение на новую систему без периода параллельной работы.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Быстрое внедрение на пилотном участке.

• Быстрое разворачивание SAP на остальных участках производства и офисах.

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

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

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

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

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

На пилотном участке компания должна запланировать внедрение максимально всеобъемлющей функциональности, которая представляет собой централизованную справочную базу конфигурации (Centralized Base Reference Configuration, CBRC). В дальнейшем эту базу можно просто «пересаживать» на остальных участках. Такой подход значительно ускоряет процесс осуществления необходимых настроек, проведения обучения, тестирования на интеграцию и конечный запуск системы.

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

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

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

3. Реализация

4. Конечная подготовка

5. Запуск и поддержка.

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

Популярность, надежность и эффективность этого подхода берут начало от похожей методологии, применявшейся с огромным успехом при установке традиционных информационных систем в 80-е годы. Созданная Гейном и Сарсоном методология Structured Systems Analysis and Design (SSAD) пропускала общепринятую в то время практику анализа существующей системы, и сразу переходила к стадии анализа будущей системы. Поэтому, проект системы представлял собой абсолютно новую интерпретацию будущих требований организации, не подверженную влиянию таких затормаживающих факторов, как ограничения, практики и недостатки прошлых систем и процедур, принятых в компании.

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

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

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

• Боязнь сокращения штатов

• Страх потери ответственности и контроля над ситуацией

• Беспокойство по поводу своего возможного несоответствия нововведениям

• Страх провала

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

• Обыкновенная инерция и нежелание осваивать новые системы.

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

• В чем необходимость изменений?

• Какие изменения необходимы?

• Кто за что будет отвечать?

• Как будет измеряться прогресс и характеристики работы?

Вопросы, связанные с изменениями в результате внедрения SAP можно решить следующими средствами:

• Демонстрация поддержки со стороны старших менеджеров

• Оперативное распространение полной информации о проекте SAP

• Адекватное обучение и курсы повторения

• Ускорение развития и рост эффективности

• Смещение ответственности или замена сотрудников.

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

Команда проекта SAP имеет следующие обязанности:

• Изучение и рационализация бизнес-процессов.

• Стандартизация бизнес-процессов на всех участках.

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

• Создание необходимой документации.

• Подготовка учебных материалов.

• Определение ответственности, обязанностей и авторизации в системе SAP.

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

• Обучение пользователей.

• Выполнение задач, предусмотренных в плане внедрения.

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

• Поддержка пользователей после запуска системы.

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

Команда функциональных консультантов SAP имеет следующие обязанности:

• Обучение членов команды SAP работе с соответствующими модулями.

• Помощь при создании карт процессов в системе.

• Устранение пробелов, обнаруженных после составления карт процессов в системе.

• Управление командой во время тестов на интеграцию.

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

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

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

Техническая команда SAP имеет следующие обязанности:

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

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

• Написание программ АВАР, пользовательских расширений и отчетов с применением таких инструментов, как Report Painter, Report Writer, АВАР Query или АВАР-программирование.

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

• Детализация интерфейсов и загрузки данных.

• Программирование интерфейсов и программ загрузки данных.

• Единичное и интеграционное тестирование.

• Члены административной команды SAP должны обладать навыками работы в трех областях: администрирование Базиса, баз данных и операционных систем. Различные задачи в области Базиса SAP включают в себя:

• Пуск и остановка системы R/3

• Повседневное администрирование с помощью центральной управляющей системы (CCMS)

• Осуществление ежедневных проверок

• Мониторинг системных журналов

• Мониторинг предупреждений R/3 (системы и баз данных)

• Анализ дампов АВАР/4 и принятие корректирующих мер

• Мониторинг процессов

• Мониторинг модернизаций

• Мониторинг пакетного ввода

• Мониторинг записей блокирования

• Управление пользовательскими и системными фоновыми задачами

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

• Администрирование временного последовательного файла TEMSE для печати

• Администрирование и настройка буферизации

• Управление информацией о пользователях, авторизациями и профилями

• Импорт запросов

• Анализ и предотвращение сбоев с помощью записей журналов, трассирования и дампов

• Управление и оперативное использование онлайновой сервисной системы (OSS)

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

Другие задачи в области баз данных включают в себя:

• Регулярное резервное копирование данных в базах данных R/3 согласно стратегии резервного сохранения данных

• Осуществление администрирования баз данных SAP (SAPDBA) с помощью таких утилит, как BRBACKUP (для резервного копирования) и BRARCHIVE (для архивирования журналов)

• Регулярное резервное копирование архивов журналов

• Мониторинг и управление таблицами, указателями, размерами указателей и т. д.

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

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

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

• Мониторинг сетевых нагрузок и выявление узких мест.

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

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

Цель планирования инфраструктуры — обеспечение минимизации простоев и оптимизация оперативности реакции для достижения идеально сбалансированного отношения между затратами и рабочей производительностью системы. Благодаря трехуровневой архитектуре SAP, внимание можно сконцентрировать на центральном процессоре (Central Processing Unit, CPU), памяти и требованиях баз данных и серверов приложений R/3 относительно условий хранения данных.

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

• Примерное количество диалоговых шагов за 1 час

• Примерное количество финансовых и схожих с ними транзакций за 1 час.

Методология планирования инфраструктуры для систем SAP подразумевает использование следующих исходных данных:

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

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

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

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

Необходимо отметить, что в условиях трехуровневой архитектуры SAP, которая допускает существование одного сервера баз данных в сочетании с несколькими серверами приложений, характеристики работы сервера баз данных становятся ключевым элементом общей эффективности работы системы SAP. Может возникнуть необходимость добавления дискового пространства для складского хозяйства, информационных систем логистики, таких как Logistics Information System (LIS), Executive Information System (EIS) и т. д., а также для отраслевых решений (IS-Oil, IS Retail и т. д.), автоматизированного документооборота (Workflow), интерфейсов для взаимодействия с другими системами. Рабочее пространство требуется для других систем, файлов печати, зависимых операционных систем или специфических баз данных при организации, реорганизации и обновлении тех или иных баз данных. Такое прибавление дискового пространства необходимо проводить с учетом сроков хранения данных и перспектив роста нагрузки.

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

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

Результаты публикуются в SAP Benchmark Council, который составляет стандартные макросы, состоящие из заранее заданного набора функций модуля «Продажи и Дистрибуция» (Sales and Distribution, SD), указывает параметры конфигурации системы для рабочих циклов и задает предельно допустимую длительность времени реакции при выполнении конкретных функций. Оценка эффективности при выполнении функций SD считается стандартом оценки мощностей оборудования, так как в функциональности именно этого модуля к большинству характеристик работы предъявляются повышенные требования по скорости обработки и реакции.

Модуль SD включает в себя такие требующие оперативности процессы, как заказы на продажу, уведомления о поставках, составление расписаний и выписка счетов-фактур. Например, ввод заказа на продажу вызывает проверку запасов и расписания производства, создание расписания поставок, проверку и обновление данных о кредите потребителя, выписку счет-фактуры, обновление данных по дебиторской задолженности, заносит в журнал учета данные по затратам на поставленную продукцию и т. д. Сложность операций SD можно оценить в сравнении с транзакциями модуля «Финансы» (Finance, FI), которая состоит из четырех шагов (инициация транзакции, обновление транзакции, выполнение транзакции и статус результата), в то время как транзакции SD могут состоять из 15 и более диалоговых шагов.

В SAP предусмотрен список контрольных вопросов, которые выступают в качестве координатора требований к операционной системе и реляционной системе управления базами данных (RDBMS) для выбранной платформы оборудования. Например, для основной копии системы R/3 Release 4.0А требуется примерно 15 GB дискового пространства.

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

• Высокая пропускная способность и прозрачность сети

• Простота администрирования сети.

В любой рабочей системе SAP R/3 службы уровней интерфейсов, приложений и баз данных обычно работают на различных компьютерах. Пользовательские SAPGUI подключаются к серверам приложений через локальную (LAN) или глобальную сеть (WAN). В свою очередь, серверы приложений в силу своей высокой загруженности подключаются к серверам баз данных через LAN, причем они распределены среди нескольких серверов в целях безопасности и по другим причинам.

Серверная сеть

Серверная сеть соединяет все серверы приложений с серверами баз данных. Для каждого диалогового шага объем данных, которыми обмениваются сервера приложений и баз данных, не превышает 20 КВ.

Пользовательская сеть

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

Начиная с версии R/3 Release 4.0 работа программы инсталляции R3Setup направляется общей программой InstGUI, которая управляет R3Setup при установке на различные операционные системы — такие, как UNIX или NT и на различные RDBMS — такие, как Oracle, Informix и т. д.

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

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

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

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

• Система 1: Система разработки и тестирования.

• Настройки и разработки АВАР производятся в клиенте разработки. Измененные объекты передаются второму клиенту для тестирования.

• Настройки и программы АВАР тестируются и утверждаются в клиенте обеспечения качества. В рабочую среду выпускаются только прошедшие тестирование и одобренные объекты.

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

• Эта система принимает и использует измененные объекты от клиента обеспечения качества.

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

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

• Система 1: Система разработки — среда для разработки и настройки программ.

• Система 2: Система обеспечения качества — среда, в которой производится тестирование и подтверждение изменений.

• Система 3: Рабочая система — среда, в которой работают измененные программы.

Администрирование клиентов подразумевает копирование клиентов в пределах одной или нескольких систем в зависимости от целей и требований утилит. Некоторые стандартные клиенты приведены ниже:

• Демонстрация

• Разработка

• Настройка

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

• Обучение и образование

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

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

• Копирование клиента в рамках системы (локальное копирование)

• Копирование клиента из другой системы R/3 (удаленное копирование)

• Транспортировка клиента из одной системы в другую с использованием запроса на транспортировку (перенос клиента).

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

• Проверка статуса системы

• Отправка системных сообщений

• Мониторинг системы

• Просмотр протекающих процессов

• Проверка системного журнала

Рис. 11.1. Экран меню Системного администрирования.

• Обновление таблиц.

На рис. 11.1 представлен экран Системного администрирования. Многие задачи выполняются с помощью CCMS, как описано в соответствующем разделе главы 7, в то время как некоторые задачи полностью или частично выполняются операционной системой.

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

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

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

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

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

Рис. 11.2. Экран для создания фоновых задач.

Рис. 11.3. Экран для выбора фоновых задач.

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

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

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

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

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

• Тип пользователя: диалоговый пользователь (значение по умолчанию), пользователь пакетного ввода данных, пользователь пакетных процессов (фоновых заданий), внешних коммуникационных интерфейсов и Интернет-пользователь.

• Даты начала и окончания периода действительности записи

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

• Группа активности — заранее заданная группа активности, которая присваивается пользователю

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

• Адрес, в котором указывается полная контактная информация пользователя

• Значения «по умолчанию» для меню «Пуск», транзакций, языка, принтера по умолчанию, формата даты и цифровых значений и т. д.

• Значения «по умолчанию» для параметров пользователя. В зависимости от обусловленных должностными обязанностями требований, эти параметры позволяют задавать значения для тех полей, с которыми пользователь чаще всего работает — это нацелено на ускорение ввода данных. Для того, чтобы задать один из таких параметров, системе требуется только идентификатор параметра (PID-номер) соответствующего поля и вводимое пользователем значение. В дальнейшем при каждом обращении данного пользователя к этому полю на любом экране системы будет содержаться заданное значение по умолчанию. Это значение пользователи могут самостоятельно менять в любой момент.

Стандартная инсталляция SAP создает особых пользователей в системе — клиентов ООО, 001, и 066, которые соответствуют пользователям SAP, DDIC, EARLYWATCH, соответственно.

Компания SAP рекомендует: пользователь SAP может и не иметь ассоциированной с ним основной записи, но при создании этому пользователю стоит присвоить следующие профили авторизации: SAP_ALL и SAP_NEW. Пароль по умолчанию для этого пользователя 06071992, причем его права доступа неограничены. Когда с помощью копирования пользователя SAP создается новый клиент, ему по умолчанию присваивается пароль PASS.

Пользователь DDIC всегда создается с изначальным паролем 19920706 и основной записью, которая ассоциирует с этим пользователем профили авторизации SAP_ALL и SAP_NEW. Этот пользователь имеет специальные авторизации для инсталляции, логистики программного обеспечения и словаря АВАР/4; в новых релизах системы R/3 требуется апгрейд. Однако пользователь DDIC использует систему транспортировки и внесения изменений АВАР только в режиме чтения, и поэтому не может вносить какие-либо усовершенствования.

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

EARYWATCH и GoingLive Check, если через удаленное соединение к системе подключаются консультанты SAP. Первоначальный пароль пользователя EARYWATCH — SUPPORT, при создании основной записи ему присваивается профиль авторизации S_TOOLS_EX_A.

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

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

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

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

Поля авторизации

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

Объекты авторизации

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

Для облегчения управления все объекты авторизации группируются в классы авторизации в зависимости от областей их применения. На рис. 11.4 представлен экран Обновление авторизации.

Рис. 11.4. Экран Обновление авторизации.

Авторизации

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

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

Авторизация и составные профили

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

Рис. 11.5. Начальный экран профилей авторизации.

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

Профиль авторизации SAP_ALL дает права доступа в масштабе всей системы, в том числе к техническим функциям и функциям, связанным с приложениями. Профиль авторизации S A P N E W подразумевает, что к нему добавляются все новые объекты авторизации для существующих функций, введенные в новые релизы R/3.

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

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

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

• Администратор групп активности — создает группы активности и определяет соответствующие транзакции R/3, но не может изменять основные записи пользователей или профили авторизации.

Трассировка авторизации

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

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

• Системная трассировка — это инструмент общего назначения, который рассматривался в подразделе «Системные утилиты трассировки» в главе 7. Один из пунктов меню этого инструмента — проверка авторизации. Активизировать опцию и запустить сессию трассирования можно для любой транзакции или экрана. Имеется возможность записать на диск результаты трассировки для последующего исследования.

В SAP введен Генератор Профилей (Profile Generator) для автоматического присвоения профилей пользователям. Принцип его действия основывается на концепции авторизации, объектов авторизации и профилей авторизации, которая описывалась выше. В SAP предусмотрена обширная библиотека стандартных авторизации для различных областей деятельности.

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

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

Рис. 11.6. Начальный экран администрирования спула.

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

Рис 11.7. Экран запроса временного последовательного файла.

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

• Группирование принтеров для облегчения администрирования

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

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

Задачи по печати можно разделить на два класса:

• Печать больших объемов информации — списков, бухгалтерских книг и т. д.

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

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

• Специальная печать — штрих-коды и текст с использованием оптического распознавания символов (Optical Character Recognition, OCR).

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

• Принтеры для распечатки больших объемов информации

• Рабочие принтеры

• Настольные принтеры.

Каждому принтеру должен быть присвоен один из режимов доступа, список которых приведен ниже:

• С — локальный принтер на Windows NT или AS/400

• L — локальный принтер на UNIX

• S — удаленный принтер на LPDHOST через протокол SAP

• U — удаленный принтер на LPDHOST через протокол Berkley

• F — принтер пользователя

• Е — внешняя система управления выводом (Output Management System, OMS)

• P — локальный или удаленный пул устройств

• I — архиватор (например, ArchiveLink)

• X — SAPcomm (например, факс)

• Z — IBM AFP (например, IBM мейнфрейм S/390).

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

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

• Гибкость при переключении группы принтеров на другой сервер спула

• Гибкость и независимость ландшафта систем печати от особенностей конкретной системы R/3

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

Система SAP также обеспечивает интеграцию SAP R/3 с существующим принтерным окружением. Для этого принтеры в рамках одной системы управления выводом (OMS) могут группироваться в логические OMS (LOMS), которые в свою очередь могут подключаться с реальной OMS (ROMS), которая обеспечивает подключение к программным продуктам других фирм через интерфейс external Output Management (ХОМ).

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

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

• Целостность баз данных

• Безопасность баз данных

Рис. 11.8. Экран просмотра операций администрирования баз данных.

• Характеристики работы баз данных

• Реорганизации баз данных

• Резервное копирование баз данных

• Восстановление баз данных.

В SAP предусмотрен целый набор интегрированных инструментов для администрирования баз данных:

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

• BRBACKUP — инструмент для резервного копирования контрольных данных, данных приложений и журнальных записей о повторных действиях. Резервное копирование возможно как в пакетном режиме, так и в режиме он-лайн. На рис. 11.9 представлен экран обзора статуса резервного копирования.

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

• BRARCHIVE — этот инструмент осуществляет архивирование журнальных записей о повторных действиях в режиме офф-лайн.

Рис. 11.9. Экран обзора статуса резервного копирования.

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