Компания SAP является ведущим производителем стандартного прикладного программного обеспечения, предназначенного для промышленных предприятий. За последнее десятилетие компания заявила увеличение объемов продаж и прибыли на 40 % в год. Объемы продаж в 1998 году составили 8,47 миллиардов долларов. По заявлению SAP, в мире насчитывается более 10,000 клиентов SAP и более 19,000 успешных инсталляций продуктов SAP. По всему миру с системами SAP работает более 1 миллиона пользователей. Согласно любому стандарту эти цифры впечатляют, прекрасно характеризуя дальновидность компании, а также значительную роль компании на стремительно развивающемся, благодаря появлению Интернета, рынке информационных технологий.

Двумя основными разработками компании SAP являются программные продукты, именуемые R/2 и R/3. Система R/2 функционирует на мейнфреймах таких производителей, как IBM, Siemens и т. д. Система R/3, которая является вариантом предыдущей версии системы клиент-сервер, анонсирована в 1992 году. Однако, после внесения ряда усовершенствований в версии 3.0 и 3.1, она стала ведущим продуктом компании, прибыли от которого составляют львиную долю общего годового дохода SAP. В этой книге термин «SAP» будет использоваться как в отношении компании, так и ее продуктов R/2 и R/3. Это не должно привести к путанице, потому что, контекст подскажет, какое именно значение имеется в виду в каждом конкретном случае. Также, если не будет иных оговорок, продукт SAP будет означать клиент-серверный продукт R/3.

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

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

SAP представляет собой одно из лучших системных ERP-решений, представленных на рынке на сегодняшний день, наряду с немногочисленной группой других программ подобного рода. За последние несколько лет характеристики систем, носящих имя ERP (Enterprise Resources Planning — планирование ресурсов предприятия) приобрели довольно ясные очертания. В этой главе мы подробнее рассмотрим сущность ERP-систем и причину их доминирующего положения в настоящее время.

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

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

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

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

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

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

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

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

• Процент прекращения эксплуатации систем был очень высок.

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

Одной из главных причин вышеперечисленных проблем являлась наследуемая слабость стадии приема и анализа требований. Считалось, что на данной стадии невозможно собрать корректные и полные требования. В результате, завершенные проекты не предлагали всей обещанной полноты функциональных возможностей, вынуждая возвращаться к стадии дополнительного анализа и доработки. Процесс сопровождения и усовершенствования был практически бесконечным, и с течением времени все труднее реализовывался. Вследствие того, что индивидуумы меняются как со стороны разработчиков, так и пользователей, системные требования менялись соответственно, продлевая весь процесс практически до бесконечности. Основная причина этого состоит в фундаментальном разрыве между людьми бизнеса и работниками IT/IS. Несмотря на попытки обеих сторон сократить этот разрыв, существует огромное расхождение между восприятием бизнес-пользователя и тем, что подразумевается системным персоналом; оба класса людей говорят на абсолютно разных языках. Даже при использовании системным персоналом методологий и инструментов для дополнительных спецификаций и описаний, пользователи не в состоянии в полной мере ратифицировать документированные требования вследствие неосведомленности о таких инструментах.

Судя по проводимым исследованиям, от 50 до 80 % ресурсов IT/IS расходуются на сопровождение приложений. Прибыли по отношению к инвестируемому капиталу в IT-отрасли были крайне низки в соответствии с любым стандартом и уровнем ожиданий. При бюджетах IT/IS, значительно превышающих возможности большинства организаций, существовала настоятельная необходимость в радикально новом подходе, результатом которого явились бы удобные и простые в использовании функциональные средства, разработанные на высоком профессиональном уровне и в установленные временные рамки. Это является своеобразной постмодернистской версией понятия «двух культур», введенного Ч.П.Сноу в середине прошлого столетия для обсуждения мира искусства и мира науки.

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

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

• Более позднее разрешение рисков.

• Более позднее обнаружение ошибок.

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

• Большой процент отбраковки и необходимости дальнейшей доработки.

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

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

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

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

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

• Большая работа в области контроля и управления изменениями.

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

• Выполнение планов в авральном режиме.

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

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

• Слабая интеграция между системами.

Многие альтернативные стратегии были задуманы как Автоматизированная Разработка Программного Обеспечения (Computer Aided Software Engineering, CASE) и прототипы, однако, ни одна из них не оказалась в состоянии преодолеть эти основные барьеры. В случае с CASE, существовали более точные условия для анализа и проектирования требований, и последующий процесс написания исходного кода, тестирования и создания документации был в значительной степени автоматизирован. Большее количество времени, посвященное проработке и определению требований с участием конечного пользователя, имело своей целью получение системы, максимально удовлетворяющей действительным требованиям пользователя. С другой стороны, прототипы разрабатывались для адресного сбора требований путем прямого участия конечного пользователя в процессе их определения. В основном такое участие фокусировалось на внешнем дизайне экранов и проектировании отчетов, поскольку данные элементы могли быть непосредственно визуализированы пользователем. Но ни одна из этих стратегий в действительности не разрешила проблему. ERP-системы оперируют абсолютно иным подходом, предоставляя наиболее полный и всеобъемлющий спектр функциональных возможностей внутри системы. При использовании системы персоналу компании нужно лишь отбирать то, что требуется на данный момент. Таким образом, ERP-системы способствуют значительному сокращению всего процесса приема требований. Традиционный жизненный цикл проекта, состоящий из анализа, проектирования, разработки, тестирования и реализации, трансформировался в цикл реализации ERP-программы, включающий стадии определения требований, анализа расхождений, конфигурации и адаптации, тестирования и реализации. На рис. 1.1 приведен сравнительный анализ затрат на разработку ERP-программ и традиционного программного продукта.

Рис 1.1. Сравнение затраченных усилий на разработку ERP и традиционного способа разработки программных продуктов.

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

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

Эти перемены, в основном вызванные информационной революцией последних десятилетий, характеризуются доминирующей тенденцией к интеграции различных областей ведения как внутренних, так и внешних дел компании. Лейтмотив этой новой системы менеджмента — сотрудничество, что подразумевает изменения в организационной структуре. Обобщенно эту плеяду новых концепций и практик я называю «Менеджмент через сотрудничество» (Management by Collaboration, МВС). Такие ERP-системы, как SAP R/3, являются главными инструментами для создания новой организации работы, где такой менеджмент является основной движущей силой.

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

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

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

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

С другой стороны, рабочим командам, напротив, присуща гибкость, приспособляемость, динамизм и сотрудничество, в них поддерживается дух новаторства, предпринимательства и оперативной реакции. За последние десятилетия даже в промышленных компаниях, традиционно приверженных бюрократическим принципам, появились и успешно работают рабочие команды разных видов — сверх-команды, самостоятельные рабочие команды (self-directed work teams, SDWT), кружки качества и т. д. Конкуренция и непрерывные изменения на мировом рынке, с которыми сталкиваются компании, приводят к упрощению и гибкости организации, в которой доминирующую роль играют динамичные рабочие команды.

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

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

Поэтому, в течение нескольких последних лет выделился новый, не иерархический тип сетевой организации со свободным обменом информацией и децентрализацией полномочий для принятия решений. Это влечет за собой необходимость наличия канала для постоянного и унифицированного коммуникативного обмена между различными командами или функциональными группами. Такая ERP-система, как SAP R/3 предоставляет прекрасную операционную среду, которая обеспечивает этот процесс посредством следующих модулей: SAP Office (Офис), SAP Workflow (Автоматизация потока операций) и SAP Business Warehouse (Хранилище информации).

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

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

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

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

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

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

Таким образом, Менеджмент через сотрудничество не только признает значение различных технологий и методологий, связанных с процессами — таких, как Инновация процесса (Process Innovation, PI), Улучшение бизнес-процесса (Business Process Improvement, BPI), Реконструирование бизнес-процессов (Business Process Redesign, BPRD), Реинжиниринг бизнес-процессов (Business Process Re-engineering, BPR), но и считает их фундаментальными, долгосрочными, неотъемлемыми функциями менеджмента компании как такового. С внедрением ERP основанное на сотрудничестве предприятие получает возможность провести улучшение бизнес-процессов, что является неотъемлемой частью усилий, направленных на тотальный контроль качества (TQM). Вопросы улучшения процессов буду рассмотрены подробнее в главе 6 «SAP и реинжиниринг предприятия».

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

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

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

Если следовать этой формулировке, становится понятно, какой пробел существует в конкурентоспособности предприятия при отсутствии такой, основанной на процессах, нацеленной на потребителя ценности, какую обеспечивают связанные с продуктами или услугами компании процессы. Я буду называть такие определяемые потребителем характеристики ценности Критическими Определителями Ценности (Critical Value Determinants, CVD). Таким образом, мы можем разделить рынок для тех или иных продуктов и услуг, или групп продуктов, на основе наиболее значимых потребительских ценностей и соответствующих CVD.

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

Начало изменений и реакция предприятия на их введение — вот две самых важных проблемы, с которыми сталкиваются современные предприятия. Способность менять бизнес-процессы является непосредственной частью сущности инновации. Традиционная концепция управления изменениями обычно понимала под изменением однократное событие. Но если предприятие стремится развить способность управлять изменениями как постоянной деятельностью, то без такой ERP-системы, как SAP R/3, не обойтись.

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

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

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

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

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

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

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

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

Большинство крупных производственных компаний мира в значительной степени стали «сборщиками систем». Самостоятельно они производят лишь некоторые специфические детали и узлы, а сборку готовой продукции осуществляют с использованием основных узлов и деталей (подсистем), которые закупаются у сети поставщиков. С точки зрения экономики, функция этих компаний — дизайн, маркетинг и обслуживание, а вовсе не производство как таковое. Для успешного существования и развития таких «виртуальных» компаний очень важно непрерывно справляться со сложностями управления этими отношениями на ежедневной основе. Система ERP предусматривает соответствующую функциональность и процессы, необходимые для управления и контроля над производством со значительной зависимостью от внешних ресурсов. Что еще более важно, только ERP-система дает возможность такому, основанному на сотрудничестве предприятию, существовать и развиваться в таких масштабах, какие были бы невозможны при традиционной организационной структуре. Подробнее об этом в последнем разделе этой главы: «Предприятие, основанное на сотрудничестве, или влияние организационной структуры на конкурентоспособность».

Внедрение ERP дает следующие преимущества в технологии и ведении бизнеса:

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

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

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

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

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

• Функционирует как интерактивное средство стандартизации производства и улучшения качества продукции, в том числе использует методики «Контроль качества», «Тотальное управление качеством», «Кружки качества» (QC, QA, TQM).

• Ориентируется на процесс, и вследствие этого является идеальной средой для внедрения «Менеджмента, основанного на деятельности» (Activity Based Management, ABM) независимо от того, направлены ли усилия на управление бюджетом, затратами, повышение эффективности работы или улучшение качества.

• Обеспечивает бесперебойный канал информации для измерения прибыли, получаемой организацией, посредством мониторинга «Прибыли на инвестированный капитал» (Return on Investment, ROI), причем не только инвестиций как вложений денег, но и инвестиций в рабочую силу, материалы, время и информацию. Результат может выражаться как затраты, качество, эффективность взаимодействия, время, затраченное на цикл работы и т. д. Так, ERP может содействовать внедрению, например, балансовых табелей оценки в рамках предприятия.

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

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

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

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

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

• Позволяет вносить и обновлять данные в режиме он-лайн.

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

• Значительно снижает стоимость обслуживающих систем.

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

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

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

Такие ERP-системы, как SAP, трансформируют знания в головах управляющего и подчиненного персонала, профессионалов, в выраженную, открытую форму. Это напрямую относится к скрытому знанию, о котором говорят И.Нонака и Х.Такеучи в своей книге «Компания, создающая знание». Таким знанием могут быть идеи, интуиция, познавательный опыт, практический опыт, деловой опыт, концепции или концептуальные модели, аналогии и т. д. Авторы книги убеждают компании превратить иллюзорные, бессистемные, необработанные, пропадающие знания корпорации в открытую форму, когда знание можно закодировать, упорядочить и управлять им, как любым другим капиталовложением. Это может иметь форму документов, социологических исследований, аналитических отчетов, описаний концепций, внутренних предложений и т. д. Что особенно важно, знания в такой форме доступны для исследования и могут постоянно углубляться и развиваться дальше. Система SAP выступает как бесценное средство для придания знанию ясной, четкой формы.

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

Традиционно, преимущество в конкуренции обеспечивала стратегия, основанная на следующих факторах:

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

• Время — время цикла, время между принятием решения и внедрением и т. д.

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

• Гибкость — изменения по желанию заказчика, дополнительные возможности, комплектация и т. д.

• Качество — переделка, брак, выход продукции и т. д.

• Инновация — новые потребности, интерфейсы, дополнения и т. д.

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

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

Например, метод «Точно в срок» (JIT) позволяет заказать и получить нужный материал в нужном месте в нужное время. Следовательно, это снижает расход рабочего времени, необходимого для того, чтобы сделать заказ, принять и хранить материалы и другие связанные с этим действия. Также снижается объем учета материалов, стоимость складирования, стоимость блокированных денег и т. д. Доступность свежайшей, подробной информации, к примеру, о производственных циклах, может использоваться для получения другой свежей и подробной информации о:

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

• Требованиях к материалам для следующего цикла

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

• Запасах на складе для следующего цикла

• Материалы, которые надо заказать для следующего цикла и т. д.

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

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

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

Можно продолжить эту аналогию. В любой отрасли, как и в случае с материалами для производства, компании необходимы огромные объемы заранее обработанной информации, причем информации точной, актуальной и цельной. Только полностью интегрированные ERP-системы, такие, как SAP R/3, могут обеспечить этот «материал» в необходимом объеме. Надо отдельно отметить, что только интегрированная ERP-система позволяет добиться эффективного превращения в ресурс и оптимального использования такой неосязаемой вещи, как информация, то есть превращение эфемерного ресурса во вполне осязаемый коммерческий продукт.

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

Выживание и успех предприятия зависят от того, насколько его продукция будет отличаться от продукции конкурентов. В эпоху ориентации производства на нужды потребителя, предприятиям нужна не стандартизация и освоение общепринятых процессов, а способность динамично меняться, быть гибким, уникальным, индивидуальным. Так как ERP-системы включают в себя основы «теории бизнеса» по Питеру Друкеру, они также должны отражать различия в стратегиях и процессах предприятий. Это идет вразрез с общей тенденцией к обобщению процессов и стандартизации. Чтобы укрепить профессионализм, использовать преимущества, особенно конкурентные преимущества, компании не должны отказываться от соответствующих специфических процессов, эти важные варианты процессов надо включить во внедряемую ERP-систему, или интегрировать с ней посредством интерфейса (см. раздел «Интеграция приложений предприятия» в главе 21). Понимание этой основополагающей необходимости, а также того, что SAP не может быть «панацеей от всех болезней», легло в основу разработок Специальных Отраслевых продуктов SAP. После основания сайта mySAP.com, компания SAP окончательно отошла от единообразного, монолитного подхода к разработке систем и освоила комбинированную стратегию на рынке программного обеспечения.

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

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

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

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

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

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

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

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

В этой главе, я представил Менеджмент через Сотрудничество как объединяющую силу в рамках предприятия. Реальный потенциал этой концепции станет еще более очевидным, если мы выйдем за рамки предприятия. В последней главе данной книги, мы обращаем взгляд за пределы фирмы, чтобы представить партнеров по бизнесу (таких, как дистрибьюторы и потребители) как продолжение нашей организации на более высоком уровне, который я называю «Расширенным предприятием, основанном на сотрудничестве» (Extended Collaborative Enterprise, ЕСЕ). В этой главе я также представил емкое понятие «Компания, ориентированная на клиента» (Customer Triggered Company), в такой компании любая деятельность начинается после сигнала, который клиент подает с помощью щелчка компьютерной мышки в своем персонализированном Интерфейсе Интернет-пользователя предприятия (Web user-interfaces, WUI), — таком, как разработанный компанией SAP «mySAP.com — Рабочее Место». С запуском этого проекта компания SAP освоила симбиотическую стратегию, выходящую за рамки простой интеграции сотрудничества между предприятиями.

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

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

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

Система хранения приложений

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

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

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

Система управления графическим интерфейсом пользователя

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

Система управления меню

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

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

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

Система управления базами данных

Этот модуль отвечает за хранение информации, востребованной или предоставленной всеми остальными модулями ERP-системы. Обычно эта система — одна из стандартных систем управления реляционными базами данных, таких, как Oracle, DB2 и т. д.

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

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

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

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

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

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

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

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

Система управления дистрибуцией программного обеспечения

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

Система управления конфигурацией

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

Система управления изменениями

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

Система управления версиями

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

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

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

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

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

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

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

Система управления архивами

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

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

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

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

Application Programming Interface (API) включает в себя стандартизованные интерфейсы для обмена данными между ERP и традиционными системами, с целью взаимодействия со специфическими приложениями, такими, как «Управление цепочками поставщиков» (Supply-Chain Management, SCM), «Управление отношениями с клиентами» (Customer Relationship Management, CRM), «Обмен электронными данными» (Electronic Data Interchange, EDI) и т. д., а также с системами управления проектами или научными и промышленными системами приложений. Эти интерфейсы могут работать как в пакетном, то есть асинхронном режиме, так и в синхронном режиме, например, с текущими операциями. Эти интерфейсы будут незаменимы, даже если ERP-система охватит все подразделения компании, расположенные в разных местах, кроме того, они необходимы для успешной работы таких технически изощренных процессов, как репликация данных, зеркальное отображение базы данных и т. д.

Система электронной документации

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

Система печати документации

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

Система управления электронным обучением, пособиями и демонстрациями

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

Система автоматизации офиса

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

Система электронного документооборота

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

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

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

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

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

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

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

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

Общие характеристики исследуемых ERP-систем:

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

• Простота использования

• Возможность внесения специфических изменений

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

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

• Эффективность операций с системой

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

• Открытая структура системы

• Открытые системные интерфейсы

• Свободный переход на евро

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

• Возможность модернизации и дополнения

• Технологии обучения работе с системой

• Требуемые навыки пользователей.

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

Таблицы 2.1 — 2.8 прилагаются для справочных целей:

• Вопросы, связанные с поставщиками ERP-систем, приведены в таблице 2.1.

• Вопросы, связанные непосредственно с продуктами ERP, приведены в таблице 2.2.

• Технические вопросы, затрагивающие ERP приведены в таблице 2.3.

• Вопросы по установке и работе с ERP приведены в таблице 2.4.

• Вопросы интеграции ERP и использования интерфейсов приведены в таблице 2.5.

• Вопросы техподдержки и обновления ERP приведены в таблице 2.6.

• Вопросы проверки и контроля ERP приведены в таблице 2.7.

• Вопросы ERP-стандартов и документации приведены в таблице 2.8.

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

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

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

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

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

В этом разделе описываются различные ситуации, имеющие значение при оценке той или иной ERP-системы.

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

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

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

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

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

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

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

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

• Законы и правила, принятые в конкретной стране

• Законы и правила, принятые в конкретном регионе

• Требования к ведению дел, принятые в конкретной стране

• Стратегия и тактика бизнеса, принятая в конкретной компании

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

Поддержка исключительных процессов

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

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

Надежность поставщика системы

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

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

Трехслойная архитектура

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

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

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

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

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

Графический интерфейс пользователя

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

• Структурирование и размещение меню

• Облегчение движения курсора по экрану

• Навигация между разными экранами

• Предоставление справки (помощи) в контексте конкретной ситуации

• Вывод на экран сообщений о сбоях и ошибках.

Существует пять вариантов трехслойной архитектуры в сочетании с режимом «Клиент-Сервер»:

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

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

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

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

• Распределенное представление: операции, связанные с представлением, осуществляются приложениями и на терминале пользователя, и на сервере; система управления представлением работает на терминале пользователя, а сервер программ представления распределен между сервером и клиентом.

Рис. 2.1. Типы архитектуры клиент-сервер.

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

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

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

• Улучшение отношений с клиентами и управление этими отношениями

• Сокращение времени циклов

• Улучшение качества

• Увеличение объемов продаж

• Увеличение прибыльности

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

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

• Усиление присутствия на рынке.

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

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

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

Использование для этих целей списков контрольных вопросов оказалось очень полезным. В главе 2 «Оценка ERP-систем», уже обсуждались некоторые перечни контрольных вопросов. Списки вопросов должны дополняться или изменяться в зависимости от требований конкретной организации. Кроме того, в процессе обсуждения такие списки играют далеко не последнюю роль, так как они помогают сконцентрировать внимание на действительно важных вопросах. Далее в этой главе обсуждается роль математического подхода при сравнении ERP-систем.

Процесс выбора ERP-системы для предприятия включает в себя следующие этапы:

• Создание команды для выбора ERP-системы (подробнее см. в соответствующем разделе этой главы).

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

• Поиск и отбор подходящих ERP-систем.

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

• Отбор тех доступных ERP-продуктов, которые больше всего соответствуют установленным требованиям по утвержденным критериям. Компания может также вступить в партнерские отношения с поставщиками, предоставив им списки контрольных вопросов.

• Оценка конечного списка ERP-продуктов с точки зрения требований, описанных в главе 2 «Оценка ERP».

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

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

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

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

• Подготовка отчета с рекомендациями для менеджеров.

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

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

Функциональная команда — главная составляющая команды, ответственной за выбор. Она должна включать руководящих работников, осведомленных о деловых операциях компании, производственных технологиях, профессионализме компании и слабых местах в ее конкурентоспособности. Так как движущей силой проектов внедрения ERP-систем являются пользователи, то можно порекомендовать включить в отборочную команду представителей всех функциональных подразделений, которые впоследствии будут участвовать во внедрении системы. Желательно, чтобы все они имели опыт внедрения других, более ранних систем, таких, как Тотальный Контроль Качества (TQM), Реинжиниринг Бизнес-Процессов (BPR) и т. д.

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

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

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

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

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

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

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

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

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

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

• Предлагаются изменения для достижения этой функциональности и они соответствующим образом конфигурируются.

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

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

• Разрабатывается желаемая функциональность в ERP-системе в среде 3GL/4GL, которая использовалась при создании ERP-системы.

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

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

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

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

В следующем подразделе я рассмотрю математический подход к сравнению ERP-систем.

В таблице 3.1 представлен шаблон, который можно использовать при сравнении систем ERP. Команда по выбору ERP-системы может использовать этот шаблон в следующем порядке:

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

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

3. Принять решение, какие характеристики необходимы.

4. Принять решение, какие характеристики желательны.

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

Жизненно важно = 10

Необходимо = 9

Крайне важно = 8

Очень важно = 7

Важно = 6

Имеет значение = 5

Требуется = 4

Весьма полезно = 3

Желательно = 2

Необязательно = 1

Решения по оценке той или иной характеристики должно приниматься с общего согласия.

6. Далее необходимо составить рейтинг различных ERP-систем по каждой из характеристик, по 5-балльной шкале, где 5 — отлично, 1 — неприемлемо. Хороший практический прием: определить, какая из систем лучше всего отвечает конкретной характеристике, и только этой системе присвоить 5 баллов относительно данной характеристики, а потом оценить оставшиеся системы:

Отлично = 5

Хорошо = 4

Посредственно = 3

Приемлемо = 2

Неприемлемо = 1

7. Поочередно подсчитать количество баллов, набранное каждой из систем по каждой из характеристик, умножив фактор важности характеристики (см. п. 5) на рейтинг системы в отношении этой характеристики:

Оценка = Фактор важности * Рейтинг

8. Подсчитать общее количество баллов для каждой ERP-системы.

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

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

• Преимущества и недостатки выбранной ERP-системы на основе информации, собранной на основе критериев оценки, как описано выше в этой главе.

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

• Сравнительная таблица ERP-систем.

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

• Расписание проекта внедрения, с указанием дат основных этапов. Обзор проекта внедрения для SAP R/3 подробно обсуждается в главе 5 «Цикл проекта внедрения SAP».

• Рекомендации для принятия решения.

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

В следующих главах я расскажу о компании SAP AG и ее продукте — системе R/3, работающей по принципу «клиент-сервер». Я подробно рассмотрю архитектуру системы SAP R/3, ее структуру и дизайн, чтобы показать всю сложность и всеохватность этой системы. Главы 4–9 ясно показывают, почему SAP на протяжении последнего десятилетия остается лидером на рынке ERP-систем, а также предоставят доказательства моего предположения, что и в XXI веке SAP R/3 будет пользоваться самым большим спросом среди предприятий нового тысячелетия.

Компания SAP является ведущим поставщиком стандартного программного обеспечения для бизнеса. На протяжении последнего десятилетия компания сообщала о ежегодном росте продаж и прибыли более 40 % в год. В 1998 году компания отчиталась об объемах продаж в размере 8,47 миллиардов долларов. Согласно отчетам компании, количество ее клиентов по всему миру превысило 10 000, для которых было произведено 19 000 установок системы с общим количеством пользователей более 300 000. С любой точки зрения, эти цифры впечатляют, прекрасно характеризуя дальновидность и доминирующую роль компании на стремительно развивающихся, благодаря появлению Интернета, рынках информационных технологий.

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

Компания SAP предлагает два основных продукта: R/2 и R/3. Система R/2 используется на таких мейнфреймах, как IBM, Siemens и др. Система R/3, представляющая собой модификацию предыдущей системы, основанную на принципе «клиент-сервер», была представлена в 1992 году. Однако, благодаря значительным усовершенствованиям, предусмотренным в версиях 3.0 и 3.1, эта система стала флагманом среди продуктов компании SAP, обеспечивая ей львиную долю годовой прибыли. Схема системы SAP R/3 представлена на рисунке 4.1.

Далее в этой книге под термином «SAP» я буду подразумевать и компанию SAP и ее продукты — системы R/2 и R/3. Надеюсь, что это не приведет к путанице, поскольку значение слова всегда будет понятно из контекста. Также, кроме специально оговоренных случаев, под «продуктом SAP» будет подразумеваться система R/3, построенная по принципу «клиент-сервер».

Рис. 4.1.Строение SAP.

Краткая хронология истории компании SAP AG выглядит так:

 1972 г. Пятеро системных аналитиков покидают компанию IBM и основывают Systemanalyse and Programmentwicklung («Системный анализ и разработка программ») в г. Маннхейм. Новая компания разрабатывает и представляет систему для ведения бухгалтерского и финансового учета, которая использует данные в режиме реального времени в масштабе интегрированного предприятия. Концепция системы основывалась на общности функциональных требований различных предприятий в пределах одной отрасли, выбранной создателями системы.

• 1973 г. Компания SAP представляет Систему «Управления материалами» (Material Management), вслед за которой появляются модули «Закупки» (Purchasing), «Управление запасами» (Inventory Management) и «Выписка счетов-фактур» (Invoice Verification). В соответствии с философией компании, модуль ММ напрямую, в режиме реального времени обменивается данными с модулем FI (Finance), что дает неоспоримые преимущества в работе.

• 1977 г. Компания получает новое название Systeme, Anwendungen, Produkte in der Datenverarbeitung («Системы, Приложения, Продукты для Обработки Данных») и из Маннхейма переезжает в новую штаб-квартиру в г. Валльдорф, где и располагается по сей день.

Компания SAP представляет модуль «Учет Активов» (Assets Accounting). У компании SAP появляются первые иностранные клиенты из Австрии. Компания SAP разрабатывает французскую версию бухгалтерского модуля. С этого времени интернациональность продуктов SAP становится отличительным признаком компании.

• 1978 г. Компания SAP представляет свою первую систему, охватывающую все предприятие, а именно R/2, работающую на мейнфреймах. Компания SAP разрабатывает модуль «Расчет затрат» (Cost Accounting).

• 1980 г. Продукты SAP занимают 50-е место в списке 100 лучших продуктов Германии.

• 1984 г. Компания SAP получает первого покупателя системы планирования и контроля производства. Начинается работа над созданием модулей «Управление персоналом» (Personnel Management) и «Обслуживание и ремонт» (Plant Maintenance).

• 1985 г. Компания SAP представлена в большинстве европейских стран и начинает наступление на рынки за пределами Европы, в частности, в Канаде, США, ЮАР и Кувейте.

• 1986 г. Компания SAP впервые представляет свой продукт R/2 на крупнейшей международной выставке информационных технологий «СеВIТ».

• 1987 г. Компания IBM объявляет о создании Системной архитектуры прикладных программ (Systems Application Architecture, SAA), которая представляет собой концепцию трехслойной структуры программных приложений, что влечет за собой возможность создания приложений, независящих от типа платформы, на которую они устанавливаются. С этого времени графические интерфейсы пользователя (GUI) выходят на первый план, в то время как стандартные системы управления базами данных (DBMS) отходят на второй план. В целом это соответствует эталонной модели открытых компьютерных сетей OSI Reference (Open Systems Interconnection Reference), появившейся в начале 1980-х годов.

Компания SAP принимает решение о разработке всех приложений для бизнеса в среде АВАР/4, хотя рабочая среда остается в языке С (Си).

• 1988 г. Компания SAP становится корпорацией, акции которой доступны широкой публике.

SAP открывает международный учебный центр в г. Валльдорф.

• 1989 г. Компания SAP представляет систему приложений R/3 на конференции CeBIT в г. Ганновер и организует первую конференцию SAPPHIRE в США.

 1992 г. Годовая прибыль SAP достигает 831 миллиона немецких марок, половина прибыли получена за пределами Германии. Система R/2 становится доступной во всем мире на 14 языках, включая русский.

Компания SAP представляет систему R/3, для платформы UNIX, работающую по принципу «клиент-сервер» в масштабе всего предприятия. Это важнейшее в истории компании событие приводит к взрывному росту прибылей.

 1993 г. Компании SAP и Microsoft (MS) начинают совместную работу по интеграции таких PC-ориентированных продуктов Microsoft, как Word, Excel, Project, Access с бизнес-приложениями, выпускаемыми компанией SAP. Компании SAP и MS адаптируют систему R/3 к среде Windows NT. Система SAP R/3 становится доступной на платформе Windows NT. Компания SAP America основывает центр по программным разработкам в г. Фостер Сити, в Силиконовой долине в США. Компания SAP представляет версию «Kanji» системы R/3.

 1994 г. Количество покупателей системы SAP R/3 достигает 1000. Разработка SAP R/3 получает сертификат ISO 9000.

Релиз 2.2 системы SAP R/3 содержит значительные усовершенствования в области логистики.

 1995 г. Количество пользователей системы SAP R/2 достигает 2000, пользователей системы R/3 во всем мире — 4000.

Компания SAP выпускает релиз 3.0 системы R/3, который знаменует настоящий прорыв в области функциональности, особенно в модуле «Планирование Производства» (Production Planning).

Компания SAP делает возможной установку системы R/3 на широко распространенной платформе IBM AS/400.

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

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

Для облегчения установки систем Компания SAP представляет полноценную среду внедрения, состоящую из Справочной модели R/3 (Reference Model), Бизнес-Навигатора R/3 (Business Navigator), Модели процедур (Procedure Model) и Руководства по внедрению (Implementation Guide). Компания SAP открывает центр сервиса и техподдержки в г. Валльдорф.

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

Компания SAP представляет приложения, работающие в сети Интернет. Компания SAP представляет методологию «Accelerated SAP» для ускорения процесса внедрения. Эта методология создана на основе опыта, накопленного за время тысяч установок систем SAP.

Компания SAP становится поставщиком номер один в области создания комплексных систем для производств.

 1997 г. Компания SAP приобретает до 750 новых клиентов в месяц. Компания SAP представляет TeamSAP.

Компания Motorola внедряет модуль SAP HR «Человеческие ресурсы» на 25 тысяч пользователей.

 1998 г. Компания SAP выпускает карты решений (SAP Solution maps) для девятнадцати отраслей.

Компания SAP выпускает SAP R/3 релиз 4.0

Компания SAP представляет программу EnjoySAP, нацеленную на облегчение изучения и понимания систем SAP, настройку системы под индивидуальные требования и удобную работу с системой в целом. Компания SAP объявляет о создании таких новых направлений, как SAP Customer Relationship Management (CRM), SAP Business Intelligence (BI), SAP Supply Chain Management (SCM), SAP Advanced Planner and Optimizer (APO), Management Cockpit, SAP Strategic Enterprise Management (SEM), SAP Business Information Warehouse (BW) и EnjoySAP.

 1999 г. Компания SAP в сети Интернет создает сайт mySAP.com, который расширяет возможности системы SAP.

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

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

В оставшейся части этой главы я опишу выдающиеся свойства и преимущества системы SAP R/3 как ERP-системы. Хотя это и не было предметом обсуждения в главе 2 «Оценка ERP» и главе 3 «Выбор ERP», после тщательной оценки и выбора ERP-системы станет ясно, что по всем критериям системы SAP превосходят все остальные программные продукты на рынке информационных технологий. В этой главе описываются наиболее значимые характеристики системы SAP R/3, а также сопутствующих услуг, предоставляемых SAP. Некоторые аспекты, такие, как легкость запросов, удобства отчетности, электронная справка, документация, обучение и т. д. описываются в следующих главах книги. Передача необходимых навыков и знаний персоналу заказчика, вовлеченному в проект внедрения SAP, а также средства такой передачи — исчерпывающие учебные пособия, программы и сертификация, обсуждаются в главе 5 в разделе «Управление проектом».

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

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

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

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

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

Модули приложений системы

Стандартные модули приложений SAP обеспечивают функциональность, общепринятую и использующуюся в широком спектре отраслей. Эту функциональность можно примерно разделить на три основные группы: финансы, логистика и кадры. Финансовый блок SAP включает в себя такие модули, как «финансовая отчетность» (Financial Accounting), «Контроллинг» (Controlling), «Управление активами» (Assets Management), «Управление инвестициями» (Investment Management) и «Касса» (Treasury). Логистика SAP включает в себя такие крупные модули, как «Управление материалами» (Materials Management), «Планирование производства» (Production Planning), «Управление качеством» (Quality Management), «Обслуживание и ремонт» (Plant Maintenance), «Система проектов» (Project System), «Продажи и дистрибуция» (Sales and Distribution), «Управление услугами» (Service Management), «Управление складами» (Warehouse Management) и т. д. Кадровые модули SAP включают в себя «Планирование и развитие персонала» (Personnel Planning and Development), «Администрирование персонала» (Personnel Administration) и «Расчет заработной платы» (Payroll Accounting). Подробнее эти модули мы рассмотрим в главе 7 «Программный пакет SAP R/3».

Межфункциональные модули

Межфункциональные модули (Cross-application modules, СА), как и предполагает их название, не привязаны к каким-либо из упомянутых модулей, но при этом участвуют в самых различных аспектах работы системы во всем ее объеме. В число таких важных модулей входят:

• Модуль SAPOffice обеспечивает работу почты и интерфейсов в пределах системы SAP

• Модуль SAP Business Workflow обеспечивает функциональность потока операций, а также интерфейсы с системой SAP

• Модуль SAP Business Information Warehouse обеспечивает функциональность хранилища данных и взаимодействует с базой данных SAP через программный интерфейс

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

Модуль SAP Business Engineer тоже считается межфункциональным модулем. Среди других модулей этого типа — «Сбор данных по заводу» (Plant Data Collection, PDC), «Системы контроля процессов» (Process Control Systems, PCS), интерфейсы IDoc для EDI, Application Link Enabling (ALE), интерфейсы автоматизированного проектирования CAD, «Системы управления документами» (Document Management Systems) так далее. Подробнее мы обсудим эти моду, ли в главе 19, «Усовершенствования и интерфейсы SAP».

Отраслевые решения

Существуют специфические требования, характерные для работающих в той или иной отрасли компаний. Система SAP предоставляет обширную совокупность специальных отраслевых вертикальных решений (Industry Solutions, IS), которые отвечают особым требованиям отрасли и прилагаются к основной системе R/3. Например, нефтегазовая компания может внедрить сочетание SAP R/3 и IS-Нефть, получив систему, которая удовлетворяет всем стандартным и специальным отраслевым требованиям. При разработке и усовершенствовании отраслевых решений компания SAP поддерживает партнерские отношения с консалтинговыми кампаниями, другими разработчиками программного обеспечения и со своими клиентами посредством отраслевых центров экспертизы (Established Industry Centers of Expertise, ICOE).

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

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

Модуль SAP Business Engineer представляет собой полноценную среду для быстрого и эффективного анализа, дизайна и конфигурирования персональных бизнес-процессов. Здесь представлены 800 лучших деловых практик и сценариев, которые уже много раз упоминались в данной книге. Модуль Business Engineer предусматривает различные модели процессов и подходы к ним, причем в различной форме (в том числе, и в форме графического представления) для облегчения выбора нужных процессов. Выбор процессов автоматически встроен в соответствующее Руководство по внедрению (Implementation Guide, IMG), с помощью которого последовательно конфигурируется и настраивается система.

В разделе «Что такое ERP?» главы 1 упоминается среда разработки приложений, которая в системах SAP называется Business Engineering Workbench и функционирует как полноценное приложение, в состав которого входят:

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

• Бизнес-Навигатор R/2.

• Анализатор R/3. Использует Справочную модель и матрицы выбора процессов для записи и анализа требований с целью нахождения оптимального решения.

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

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

• Модель Компании — полное внедрение SAP для модели компании «Международные Демонстрационные и Обучающие Системы» (International Demo and Education System, IDES), которая используется, главным образом, для демонстрации технологий и возможностей SAP, тестирования взятых из реальной практики сценариев, а также для обучения пользователей работе с системой.

Эти компоненты обсуждаются в разделе «Среда внедрения» главы 5 и разделе «Руководство по внедрению» главы 12.

Модификации функциональности не меняют систему SAP как таковую; SAP также обеспечивает модернизацию программы благодаря пользовательским наработкам с использованием АВАР/4 Development Workbench.

Система SAP включает в себя хранилище 800 лучших в своем роде практик, которые доступны для ознакомления и использования. Эти практики собирались компанией SAP на протяжении нескольких лет в процессе разработки хранилища R/3 с целью удовлетворения требований нескольких отраслей. Ценность этой библиотеки процессов можно понять по тому факту, что одно время компания SAP серьезно занималась внедрением упрощенных версий R/3, предназначенных для средних и малых предприятий. Однако работу над этой версией, которая называлась R/3 Lite, пришлось прекратить после того, как стало ясно, что требования малых и средних предприятий практически идентичны требованием больших корпораций. Более того, успех компании, не в последней степени обеспеченный внедрением SAP, может привести к быстрому росту малого или среднего предприятия и расширению его Деловой активности, что, в свою очередь, может потребовать усовершенствования функциональности, доступной лишь в полновесной версии системы R/3.

Интегрированность и операции в реальном времени

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

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

На рис. 4.2 представлены компоненты SAP как с точки зрения функциональности, так и инфраструктуры. С функциональной точки зрения самый верхний уровень — это уровень презентации, он состоит из графического интерфейса пользователя (GUI). Средний уровень — это уровень приложений, в котором протекает работа самих приложений, кроме того, по сути, это совокупность программных средств (middleware), обобщенно называемая Базис, от которой зависит интеграция всех приложений. Эта система включает в себя такие компоненты, как Рабочее место разработчика АВАР/4 (Development Workbench), инструменты администрирования системы и управления системой, системы авторизации и безопасности, а также общие для всех приложений компоненты. Нижний уровень состоит из сети, базы данных и операционной системы.

Рис. 4.2. Архитектура SAP.

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

Документ SAP

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

Запись по образцу

Дизайн систем SAP ориентирован на взаимодействие через экраны при безусловном соблюдении принципа однократного ввода данных (после которого данные становятся доступны всем модулям и компонентам). Система признает важность момента ввода данных, и в еще большей степени способствует быстрому исполнению этой операции посредством устройства, которое называется Запись по образцу (Recording by Example, RBE).

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

Варианты

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

Детализация отчетности по принципу погружения

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

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

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

TeamSAP

Идеология «TeamSAP» была создана для максимального использования ресурсов компании SAP и ее партнеров в трех ключевых областях — люди, процессы и продукты, с целью обеспечения максимальной выгоды для клиентов SAP. Эта идеология позволяет устанавливать системы SAP быстрее и с меньшими затратами, однако без малейшего ухудшения качества и преимуществ, которые дают системы SAP (см. главу 12, где описывается методология ускоренного внедрения SAP).

Методология внедрения AcceleratedSAP

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

SAP Ready-to-Run R/3

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

Компания SAP имеет несколько RRR-систем, которые поддерживают системную среду R/3 с масштабом от 12 до 200 пользователей. Дополнительно, программа RRR может предусматривать заранее подготовленные персональные компьютеры, или даже сетевые серверы и сетевое программное обеспечение. Многие процедуры, связанные с системными операциями, также поставляются уже готовыми; они задаются заранее, во время инсталляции.

Компания SAP также представила специальный инструмент под названием «Ассистент по системному администрированию» (System Administration Assistant) для помощи пользователю в осуществлении функций администрирования системы. Весьма полезно иметь уже установленную и работающую систему без задержек для того, чтобы обеспечить правильное определение и отладку функции администрирования.

EnjoySAP

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

MySAP.com

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

В этой главе мы рассмотрели различные аспекты SAP, доказывающие, что SAP — это лучшее ERP-решение на рынке информационных технологий. Хотя мы не во всем следовали критериям оценки ERP-систем, описанных в главе 2 «Оценка ERP», по прочтении этой главы превосходство SAP по всем этим критериям становится очевидным.

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

Миссия проекта SAP должна быть точно согласована с миссией и целями предприятия, определенными на ближайшие 3–5 лет. Проект внедрения SAP может сам являться миссией, которую можно сформулировать так:

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

• Увеличение пропускной способности процессов на 30%

• Сокращение сроков инвентаризации на 30%

• Увеличение оборота товаров и финансов на 100%

• Увеличение выработки от 1 % до 3%

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

Поводы для внедрения SAP

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

• Существующие приложения имеют слишком много ограничений.

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

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

• Приложения должны осуществлять все деловые операции в режиме он-лайн.

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

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

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

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

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

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

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

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

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

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

Успех проекта внедрения SAP зависит от самых различных факторов, каждый из которых рассматривается в этой главе.

Прямое участие топ-менеджеров

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

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

Точно очерченные рамки проекта

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

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

Как уже упоминалось, чем обширнее интеграция функций, чем больше процессов исполняется в режиме реального времени, тем выше конкурентоспособность организации. Именно поэтому очень важно, чтобы в систему SAP было включено максимальное количество функций. Такая стратегия «Большого взрыва» должна браться на вооружение в самом начале проекта внедрения SAP, например, во время составления схем бизнес-процессов. Из этого следует, что на пилотном участке проекта надо установить все базовые модули SAP — такие, как «Финансы и Контролинг» (FI–CO), «Управление материалами» (ММ), «Планирование производства» (РР) и «Продажи и дистрибуция» (SD).

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

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

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

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

Выделение необходимых средств и ресурсов

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

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

Делегирование ключевых менеджеров всех подразделений компании на полный рабочий день

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

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

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

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

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

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

Обучение членов команды SAP

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

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

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

Настройка и управление интерфейсом между SAP и другими системами

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

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

План перехода на SAP

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

В этом разделе мы рассмотрим, какую стратегию должно освоить предприятие нового тысячелетия для проекта внедрения Системы ERP, «как товара на полках супермаркета».

Внедрение модулей SAP по принципу «Большого взрыва»

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

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

Приоритет внедрения базовых модулей

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

Внедрение стандартной функциональности SAP

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

• Использовать стандартную функциональность SAP

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

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

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

Внедрение SAP на пилотном участке с последующим разворачиванием на других участках

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

• Установку SAP

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

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

• Загрузку имеющихся данных

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

Использование внешних консультантов для обучения своих функциональных и технических консультантов

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

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

Централизованная или децентрализованная конфигурация SAP

Обычно инсталляции SAP проходили на централизованном сервере баз данных, однако у предприятий нового тысячелетия с распределенными серверами баз данных может возникнуть необходимость в децентрализованной конфигурации. Как уже отмечалось в главе 4 «Решение SAP», система R/3 также допускает распределение уровня презентаций и уровня приложений среди нескольких компьютеров. Возможность внедрить многослойную концепцию «клиент-сервер» без потерь при интеграции данных и процессов в масштабе всей системы является огромным достижением таких интегрированных систем, как SAP. Компания SAP смогла добиться этого с помощью технологии Application Link Enabling (ALE), разработанной в 1995 году.

Пользователь как движущая сила функциональности

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

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

Подобно функции «Список материалов» (Bill of Materials) в модуле «Планирование и контроль производства» (Production Planning and Control), можно дать определение общей версии этой функции — «Список ресурсов» (Bill of Resources, BOR), применительно к проекту внедрения SAP. Эта функция позволяет задать иерархию начальных данных, ресурсов и затрат как единую структуру. В данном разделе мы рассмотрим, какие ресурсы нужны для проекта внедрения SAP.

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

Финансы

Хотя делать какие-либо обобщения трудно, средняя стоимость проекта SAP для средних и малых предприятий может колебаться в рамках от 3 до 7 млн. долларов. Примерный расклад расходов выглядит так:

Инфраструктура — оборудование 30%

Лицензии на программное обеспечение 30%

Услуги по внедрению (внешние и внутренние) 40%

Материалы

Материальные затраты включают в себя:

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

• Объединение в сеть: оборудование и программное обеспечение

• Программное обеспечение: ERP, пользовательский интерфейс GUI, операционная система, системы автоматизации офиса и т. д.

• Инфраструктура Project Office и SAP Center.

Кадры

Необходимые кадровые ресурсы:

• Топ-менеджеры

• Старшие менеджеры

• Технический персонал

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

• Персонал администрации офиса

• Привилегированные пользователи

• Конечные пользователи.

Время

Сроки завершения проекта SAP для средних и малых предприятий в среднем составляют от 4 до 9 месяцев.

Информация

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

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

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

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

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

• Функциональная модель

• Модель процессов

• Модель данных

• Организационная модель

• Модель потока информации

• Коммуникационная модель

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

Бизнес навигатор R/3

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

• Процессовый вид

• Компонентный вид.

На рисунках 5.1 — 5.7 представлены образцы экранов для процессового и компонентного вида.

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

Процессовый вид в основном описывает подробности, относящиеся к тому или иному процессу.

Рис. 5.1. Процессовый вид справочной модели.

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

• Моделирование бизнес-процессов: компания определяет желаемые или обязательные бизнес-процессы.

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

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

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

• Настройка системы SAP: компания конфигурирует базовые параметры SAP с помощью Руководства по внедрению, чтобы удовлетворить ранее установленным требованиям (см. раздел «Конфигурация через Руководство по внедрению» в главе 12). Все настройки осуществляются в клиенте 001.

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

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

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

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

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

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

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

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

В системе SAP предусмотрена полноценная среда R/3 Business Engineer для помощи при внедрении SAP. При моделировании бизнес-процессов SAP возможно использовать любой из следующих инструментов: IDS Sheer ARIS, Microsoft VISIO, IntelliCorp LiveModel и Enterprise Charter. Они базируются на Справочной модели R/3 и обеспечивают прямой интерфейс для взаимодействия с функциональностью системы R/3. Это значительно облегчает понимание системы, потому что позволяет начинать специфические транзакции SAP прямо из среды моделирования: с другой стороны, предоставленные этими системами модели процессов, обеспечивают полноценный контекст той или иной транзакции SAP.

Справочная модель R/3 и упомянутые выше инструменты используют рекомендованную SAP технологию моделирования, которая называется «Управляемая событиями последовательность процессов» (Event-Driven Process Chain, ЕРС). В своей основе эта технология моделирует процессы как упорядоченный набор процедур, которые запускаются событиями внутри системы. Эти события могут происходить в базах данных (например, обновление) или на экране — когда, например, пользователь выбирает пункт меню или нажимает ссылку на Web-странице.

Процедурная модель SAP

Это традиционная модель внедрения SAP, она полностью интегрирована с системой SAP. Эта модель была представлена в 1995 году, одновременно с системой SAP R/3 3.0. Иногда использование Процедурной модели SAP ставится под вопрос: возникает ощущение, что эта модель устарела, и от нее надо отказаться в пользу AcceleratedSAP. Однако надо учитывать, что методология AcceleratedSAP в основном рассчитана на средние и малые предприятия, в то время как для крупных компаний Процедурная модель SAP остается лучшей методологией внедрения SAP. Так как в этой книге мы в основном рассматриваем внедрение SAP для средних и малых предприятий, здесь я представлю краткое описание Процедурной модели SAP, которая идеально подходит для компаний с доходами от 1,2 млрд. долларов.

На рис. 5.8 схематически представлена Процедурная модель SAP.

Рис. 5.8. Процедурная модель SAP.

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

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

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

Запись времени

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

Собрания

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

• Рамки проекта

• Стратегия проекта

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

• Расписание проекта, контрольные сроки

• Требования и бизнес-процессы

• Пробелы в функциональности

• Ликвидация пробелов в функциональности

• Вопросы, которые не удалось решить

• Решения по стандартизации

• Подготовка данных для тестирования, назначение дат

• Отчеты о тестировании

• Устранение ошибок, варианты устранения ошибок

• Документация и модернизация

• Модернизация программного обеспечения

• Расписание программ обучения

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

• Доступность ресурсов, их использование

• Конфликты и их разрешение

• Профили пользователей, права доступа, авторизация

• Эффективность работы

• Поставщики сетевого программного обеспечения и оборудования

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

• Оплата счетов

• Отпуска и отставки.

Мониторинг проекта

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

Обзоры проекта

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

В отличие от традиционных проектов по разработке программного обеспечения, внедрение SAP делится на три фазы: предвнедрение, внедрение и поствнедрение. Фаза предвнедрения рассматривается в главах 10 и 11. Внедрение с использованием методологии AcceleratedSAP (ASAP) рассматривается в главах с 12 по 17. Фаза поствнедрения обсуждается в главах 18 и 19.

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

Обучение

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

• Уровень 1 — Одно-двухдневные курсы, знакомство с технологией R/3

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

• Уровень 3 — Трех-пятидневные курсы, обеспечивающие глубокие познания в области, которая изучалась на уровне 2.

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

Компания SAP также предлагает Академические курсы для партнеров SAP, которые длятся 5–7 недель и включают в себя интенсивное изучение того или иного модуля (FI, СО, HR, SD, АВАР, Basis и т. д.). На этих курсах рассматриваются самые важные аспекты того или иного модуля, начиная от знакомства с модулем и заканчивая тщательным изучением конфигурации и работы на примере торговой компании. Выпускники этих курсов получают звание «Сертифицированный консультант» по тому или иному модулю. Раньше эти курсы были открыты только для консалтинговых партнеров SAP, сейчас они открыты для всех клиентов SAP.

Инсталляция SAP

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

Малым и средним предприятиям компания SAP рекомендует ускоренную методологию внедрения AcceleratedSAP, которая состоит из пяти этапов:

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

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

• Реализация

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

• Запуск и техподдержка.

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

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

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

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

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

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

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

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

• Провести тесты на интеграцию

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

• Запустить систему.

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

• Интерес и вовлечение в проект топ-менеджмента оказались незначительными

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

• Внедрение процессов SAP, которые не были оптимизированы

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

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

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

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

• Поддерживающая инфраструктура и системы были установлены беспорядочно или с задержками

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

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

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

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

• План по управлению изменениями в масштабе всего предприятия не был выполнен

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

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

— Сотрудники чувствуют, что система внедряется слишком поспешно, что она не отвечает их требованиям и нуждам, и воспринимают все с недоверием

— Сотрудники чувствуют, что их недостаточно хорошо обучили

— Сотрудники с опаской относятся к своей будущей роли в системе

— Сотрудники боятся, что не смогут хорошо понять систему и научиться с ней работать

— Сотрудники обеспокоены отсутствием иерархических отношений в системе

— Сотрудники чувствуют, что их роль будет снижена до простых операторов ввода данных

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

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

• Консультантам не хватило профессионализма

• Слишком медленное принятие решений, относящихся к проекту

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

Способы решения этих проблем могут быть разными в зависимости от специфики компании. Подходы к преодолению таких препятствий описываются в разделе «Управление организационными изменениями» в главе 14.

В этой главе представлен обзор полного цикла внедрения SAP. Вопросы пред-внедрения будут обсуждаться в части III. В части IV будут обсуждаться различные фазы методологии AcceleratedSAP на этапе непосредственного внедрения. Вопросы, связанные с этапом после внедрения, рассматриваются в части IV — в главе 18 «Поддержка SAP» и главе 19 «Усовершенствования и интерфейсы SAP».

Хотя BPR в большей степени относится к сфере информационных технологий, в своей основе это — бизнес-инициатива, нацеленная на максимальное удовлетворение как внешних, так и внутренних клиентов компании. Майкл Хаммер, который в 1990 году начал BPR-революцию, считает BPR «радикальной переменой в жизни предприятия», причем информационные технологии являются главным инструментом таких перемен. В широком смысле, BPR можно определить как переосмысление и изменение бизнес-процессов с целью достижения впечатляющих улучшений таких характеристик, как затраты, качество, обслуживание и быстродействие. Ниже приводятся некоторые из принципов, выдвинутых М.Хаммером:

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

• Передача контроля и принятия решений, а также всей сопутствующей информации в руки исполнителя.

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

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

Как становится ясно после прочтения этих принципов, внедрение SAP по принципу «большого взрыва» обладает почти всеми характеристиками, упомянутыми М.Хаммером.

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

Когда речь идет о корпоративном управлении изменениями, среди всего диапазона методологий, от ISO 9000, TQM и ABM до BPR, внедрение SAP определенно ближе к BPR.

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

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

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

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

Как уже упоминалось в разделе «Информация как новый ресурс» главы 1, в рамках ERP-систем, подобных SAP, информация не только становится полноценным заменителем традиционных ресурсов — таких, как деньги, рабочая сила, материалы и время — она становится ресурсом, который можно использовать многократно. Это дает ясное объяснение, почему график, представляющий работающие на SAP организации (рис 6.1) взлетает вверх почти вертикально. Также из графика видно, что система начинает использовать информацию как ресурс, что дает огромные преимущества в производительности после того, как все базовые модули SAP запущены и полностью интегрированы. До этого момента система действует просто как очень эффективное средство записи информации (см. подраздел «Внедрение модулей SAP по принципу „Большого взрыва“» в главе 5).

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

Если компания использует методологию ускоренного внедрения (AcceleratedSAP), крайне нежелательно, если BPR совпадает с внедрением SAP. Рекомендуется сначала внедрить SAP в стандартной комплектации.

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

В этом разделе мы рассмотрим полный цикл методологии Реинжиниринга бизнес-процессов предприятия и определим ситуации, в которых SAP может способствовать проводимому на предприятии BPR, состоящему из 8 этапов:

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

2. Определение сопутствующих бизнес-процессов предприятия.

3. Отбор бизнес-процессов для реинжиниринга.

4. Составление карты отобранных процессов.

5. Анализ карты процессов и определение возможностей для реинжиниринга.

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

7. Внедрение измененных процессов.

8. Оценка и отладка внедренных процессов.

Восемь этапов методологии BPR представлены на рис. 6.2.

Рис. 6.2. Цикл методологии BPR.

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

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

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

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

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

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

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

Инициаторы изменений — ядро команды

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

Проводники изменений — привилегированные пользователи

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

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

Действующие лица изменений — конечные пользователи

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

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

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

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

Транзакции в системе SAP

Работа системы «Базис» основана на нескольких концепциях, таких, как SAP-транзакция и Логическая Единица Работы (Logical Unit of Work, LUW). Перед тем, как мы обсудим различные сервисы Базисного уровня, рассмотрим эти концепции.

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

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

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

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

Логическая Единица Работы в SAP

SAP дает определение Логической Единицы работы (LUW), ориентированной на приложения, в которых может содержаться несколько динамических программ и соответствующих изменений в базах данных. Таким образом, одна LUW в системе SAP может включать в себя несколько LUW на уровне баз данных, но никогда наоборот. LUW на уровне баз данных в SAP ничем не отличаются от принципа работы таких стандартных баз данных, как Oracle, Informix и т. п.

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

Причина, почему необходимо задать общую LUW в системе SAP заключается в том, что различные динамические программы в рамках отдельной транзакции SAP могут управляться различными процессами (см. раздел «Диспетчер и рабочие процессы»), в то время как в системах управления базами данных (DBMS), напротив, логической единицей работы управляет только один процесс. Кроме того, транзакции SAP позволяют осуществлять как синхронное (то есть в режиме реального времени), так и асинхронное внесение данных (которое используется для экономии времени работы с системой), даже с разных компьютеров в рамках одной транзакции SAP.

Исполняющая система R/3 следит за многими функциями — такими, как управление памятью, управление полномочиями и т. д., то есть тем, что обычно осуществляет операционная система. Но система SAP сама осуществляет эти функции, чтобы обеспечить мобильность и контроль над производительностью системы. Исполняющая система R/3 написана на языке C/C++, в то время как SAP 4.0 и более поздние версии модулей приложений SAP были написаны на АВАР или АВАР/4.

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

Рис. 7.1. Диспетчер SAP и рабочие процессы.

Computing Center Management System (CCMS) — это удобный в использовании полноценный централизованный инструмент системного администрирования и управления R/3, ориентированный на графическое представление. Его возможности включают в себя инструменты для выполнения системных операций, осуществления контроля, мониторинга и оптимизации. Достижение этих целей стало возможным благодаря полной интеграции CCMS не только с системой R/3, но также с операционной системой, управлением сети и системой управления базами данных.

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

• Стандартный вид

• Вид статуса сервера

• Вид буферной памяти

• Вид предупреждений

• Вид характеристик работы системы

• Вид диспетчера

• Вид системного журнала

• Управление памятью.

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

Рис. 7.2. Диалоговое окно Computer Center Management System.

Панель управления — это часть АРМ Разработчика АВАР/4, но в этом разделе мы обсудим тесно связанную с ней транспортную систему. Панель управления предоставляет инструменты для программирования на АВАР.

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

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

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

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

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

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

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

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

1. Запустить панель управления с помощью транзакции SE06.

2. Запустить программу управления переносами (transport control program, tp).

3. Начать импорт фоновых задач.

4. Создать действительный класс разработки, начинающийся с Y или Z.

5. Создать новый объект разработки или модифицировать существующий.

6. Деблокировать и экспортировать транспортный запрос.

7. Импортировать в систему назначения.

8. Осуществить мониторинг файлов журнала.

В дополнение к панели управления, панель настроек (ТА SE10) отслеживает настроечную деятельность клиента, которые необходимы для конфигурации SAP во время внедрения.

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

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

Рис. 7.4. Диалоговое окно Системного журнала.

Основная задача интерфейса базы данных — перевод языка SQL, который используется в АВАР, на язык SQL базы данных, на которой работает SAP в данной инсталляции.

Система R/3 Basis поддерживает все стандартные (или считающиеся таковыми) сетевые и коммуникационные протоколы:

• На уровне операционной системы — протокол TCP/IP.

• На уровне баз данных коммуникация осуществляется через Remote SQL.

• На уровне приложений коммуникация осуществляется через CPIC, RFC, ALE, EDI и т. д.

С помощью интерфейса Удаленного вызова функций (Remote Function Call, RFC), стали возможны удаленные вызовы между двумя системами SAP, или между системой SAP и другими системами, например, приложениями Microsoft Windows.

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

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

• Простоту обучения и использования

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

• Портативность.

Представление состоит из двух компонентов: SAPGUI и Управление сессиями.

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

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

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

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

Язык программирования АВАР/4 появился в 80-е годы, и с тех пор он развивается и совершенствуется с каждым релизом SAP R/3. Все приложения R/3 разрабатывались на АВАР/4. Зародился этот язык как язык программирования, созданный для генерации отчетов в системе R/2, потому что позволял создавать простые списки печати. Со временем этот язык развился в полноценную среду разработки под названием «Advanced Business Application Programming language» (АВАР), хотя изначально эта аббревиатура означала «Allgemeine Businessprozess Aufbereitungsprogramme».

Язык АВАР/4 во многом напоминает языки COBOL и Pascal, особенно в аспектах составления отчетности. Впрочем, АВАР/4 сильно отличается от обычных языков третьего и четвертого поколений (3GL и 4GL) тем, что это не только язык программирования, но и полноценная среда разработки «клиент-сервер», состоящая из Базиса R/3 и АРМ Разработчика АВАР/4. Ниже проведены важные характеристики среды АВАР/4:

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

• Это язык, управляемый событиями, особенно в аспектах диалогового программирования, что является неотъемлемой характеристикой системы R/3.

• Это интерпретативный язык; это делает возможным прототипирование приложений.

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

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

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

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

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

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

АРМ Разработчика АВАР/4 — это полноценная среда для создания полномасштабных приложений «клиент-сервер». Она поддерживает полный жизненный цикл разработки программного обеспечения (SDLC) — определение данных, дизайн пользовательского интерфейса, внутреннее устройство, составление отчетов, тестирование и устранение сбоев, а также документирование и управление программированием по принципу «проект в ходе разработки» (work-in-process, WIP). В этой среде предусмотрена совершенная среда управления мета-данными, которая называется «словарь данных АВАР/4», а также библиотека функций многоразового использования. Программы, разработанные на АВАР/4 могут работать без дополнительных настроек на любой операционной системе, с любым графическим интерфейсом пользователя, системой управления базами данных, сетевыми интерфейсами и т. д., причем работать как в централизованной, так и в децентрализованной среде «клиент-сервер».

Язык АВАР — это уже не просто язык четвертого поколения, особенно после внедрения Объектов АВАР; он обладает многими характеристиками объектно-ориентированной среды. Компания SAP уже поставляет браузер для просмотра объектов и библиотеку классов, которые мы рассмотрим ниже. В следующем разделе мы познакомимся с концепцией объектной ориентации и ролью этой концепции для будущего использования приложений. Затем мы рассмотрим различные компоненты интегрированного АРМ Разработчика АВАР/4 и различные аспекты программирования на АВАР.

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

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

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

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

Так как между методами различных объектов есть много общего, объекты с одинаковой внутренней структурой и одинаковыми методами группируются в класс, который называется Определяющий класс объекта (Class Defining Object, CDO), в рамках которого объекты называются экземплярами этого класса. Класс может содержать в себе экземпляры других классов; однако каждый экземпляр принадлежит только одному CDO, и ассоциирован только с ним. Таким образом, вычисления производятся путем обращения к объекту с помощью сообщения; объект унаследует метод своего CDO. Этот метод, в свою очередь, может обратиться к другим объектам и т. д. Цепочка может прерваться, когда вызывается простейший объект, который изменяет переменную величину экземпляра или затрагивает внешние устройства — такие, как принтер, жесткий диск и т. д. Например, автомобили с бензиновым или дизельным двигателем можно рассматривать как случаи (подклассы) объекта «четырехколесное транспортное средство», который в свою очередь является подклассом в классе автомобилей.

Класс — это шаблон, с помощью которого можно быстро генерировать новые объекты. Это логически объясняет многие важные характеристики ориентированной на объекты среды — такие, как унаследование и инкапсуляция. На рис. 8.1 представлены подклассы и классы случаев Определяющего класс объекта (CDO) под названием «Автомобиль».

В примере с автомобилями, унаследование можно понимать как некие стандартные характеристики и компоненты — такие, как топливо, бензобак, колеса, коробка передач, двигатель и т. д., которые считаются составными частями автомобилей с бензиновым или дизельным двигателем. Эти свойства унаследованы от класса «четырехколесное транспортное средство», который в свою очередь унаследовал их от класса «Автомобиль». Нетрудно представить себе прослеживание явления объектификации в любом порядке — например, от движущихся объектов до деталей двигателя внутреннего сгорания через Список материалов (ВОМ). Фактически, ВОМ — тоже полноценный объект! Общий результат — это иерархия, или лестница с классами и объектами на каждом уровне. Примерно по такому же принципу организована классификация животных в биологии.

Рис. 8.1. Подклассы и классы случаев Определяющего класс объекта (CDO) под названием «Автомобиль».

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

Все объекты АРМ Разработчика АВАР/4 — такие, как модели данных и процессов, словарь АВАР/4, отчеты, динамические программы, библиотеки функциональных процессов, объекты авторизации и прочие записаны в хранилище АВАР/4.

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

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

На рис. 8.2 представлен стартовый экран АРМ Разработчика АВАР/4.

Рис. 8.2. Стартовое окно АРМ Разработчика АВАР/4.

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

• Операторы определения данных — описывают данные, которые обрабатывает программа АВАР/4 — например, DATA, TYPES, TABLES.

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

• Операторы манипуляций с данными — выполняют стандартные операции сданными, например ADD, SUBTRACT, MOVE, COMPUTE.

• Операторы контроля данных — подают сигнал структурам контроля (таким, как цикл, решение, стандартные подпрограммы и т. д.) — например DO, WHILE, IF, CASE, PERFORM.

• Операторы событий с данными — запускают выполнение некоторых стандартных подпрограмм в зависимости от наступления определенных событий — например Pfnn, GET/SET, END-OF-PAGE, AT USER-COMMAND, AT LINE-SELECTION.

Язык АВАР/4 поддерживает почти все стандартные типы данных. На основе этих базовых типов данных АВАР/4 позволяет разрабатывать более сложные структуры или типы данных. Именно в этой области ярко проявляется влияние таких языков программирования, как COBOL.

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

Язык АВАР/4 предусматривает возможность доступа к таблицам данных в словаре АВАР/4 с помощью SAP OpenSQL, а также, через SQL к любой стандартной базе данных: Oracle, DB2, Informix и т. д. Для обеспечения независимости системы R/3 от лежащей в основе базы данных, OpenSQL внедряет только необходимый минимум команд и возможностей SQL. Операция соединения отношений, хотя и недоступна в рамках OpenSQL, может использоваться с помощью команд, заданных в словаре АВАР/4.

Внутренние таблицы

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

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

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

Отчетные транзакции

Отчетные транзакции — это программы SAP, которые осуществляют сбор параметров в экране выбора, на выходе получаются так называемые списки (lists).

Диалоговые транзакции

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

Как и любой другой язык программирования, АВАР/4 поддерживает стандартные подпрограммы для обеспечения модуляризации программ. Это расширяет возможности повторного использования подпрограмм и ведет к улучшению производительности и качества работы системы, а также к облегчению ее поддержания и документирования. В АВАР/4 предусмотрена возможность задания стандартных подпрограмм с помощью элемента FORM, и вызывать их из внутренних или внешних программ с помощью оператора PERFORM.

Другие характеристики стандартных подпрограмм:

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

• Вызовы могут генерироваться динамично во время обработки

• Вызовы могут быть повторными, вкладываться друг в друга и т. д.

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

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

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

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

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

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

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

• Один или несколько экранов динамических программ

• Логика исполнения.

Динамическая программа управляет только элементами ввода и их поведением на экране. Как уже упоминалось в разделе «Редактор меню», такие средства управления, как меню и кнопки управляются интерфейсом представления.

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

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

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

Рис. 8.13. Банк модулей.

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

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

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

Перед запуском системы в нее необходимо загрузить огромные объемы данных. В системе R/3 4.0 для этого предусмотрена утилита, которая называется «Инструментальные средства для миграции прежней системы» (Legacy System Migration Workbench, LSMW). Принцип действия этой утилиты основан на отображении структуры исходных данных в структуре данных R/3. Впрочем, в более ранних системах было три метода достижения этой цели:

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

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

 Быстрый ввод: Этот подход является равномерно-ускоренным, потому что данные, которые необходимо загрузить, сначала импортируются во внутренние таблицы со структурами, соответствующими структурам транзакции назначения. Затем данные передаются из внутренних таблиц в R/3 с помощью команды CALL TRANSACTION языка АВАР.

Программы, созданные на языке АВАР/4 и в связанных с ним средах разработки, таких, как АРМ Разработчика АВАР/4, Панель управления АРМ Разработчика и Базиса R/3, приспособлены для работы с любой операционной системой, графическим интерфейсом пользователя, системой управления базами данных, сетевыми интерфейсами и т. д., причем как в централизованной, так и в децентрализованной среде «клиент-сервер».

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

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

В этом разделе речь пойдет о модуле Финансы и Контроллинг (Finance and Controlling, FI–CO). Финансы — это одна из областей, где SAP как интегрированная система дает целый ряд преимуществ. Система SAP обеспечивает множество крайне важных функций и возможностей интернационализации — в том числе не только многовалютность и поддержку иностранных языков, но и гибкость, необходимую для адаптации к законам и предписаниям, действующим в разных частях земного шара. Модули можно легко и беспрепятственно конфигурировать в соответствии с различными налоговыми режимами и установками, правилами импорта, экспорта и т. д. Модуль Главная Книга (General Ledger) обладает значительной гибкостью для составления бухгалтерской отчетности как на уровне отдельной компании, так и на уровне группы компаний. В области расчета затрат ярко проявляются преимущества свойственной SAP ориентации на процессы; в дополнение к традиционному методу расчета центров затрат такой подход позволяет ассоциировать затраты с конкретными бизнес-процессами в соответствии с затратами ресурсов. На рис. 9.1 представлено подменю Финансовый учет.

Рис. 9.1. Подменю Финансовый учет.

Модуль SAP Sales and Distribution (SD) позволяет эффективно управлять деятельностью по продажам и распространению своей продукции. Прилагающиеся к этому модулю сценарии бизнес-процессов обеспечивают управление продажами, поставку, выписку счетов, поддержку продаж и информацию по продажам. На рис. 9.2 представлено подменю Продажи/Дистрибуция.

Рис. 9.2. Подменю Продажи/Дистрибуция.

Модуль SAP Materials Management (ММ) функционирует в полной интеграции с другими модулями — такими, как логистика или финансы. Бизнес-процессы в модуле ММ включают в себя RFQ заказов на покупку, получение товаров и подтверждение счетов-фактур, платежи поставщикам. Модуль ММ — это система управления учетом материалов на всех местонахождениях и участках производства, она может управлять как запасами произведенной продукции, так и обработкой субдоговоров и заказов. На рис. 9.3 представлено подменю модуля Управление Материалами.

Рис. 9.3. Подменю Управление Материалами.

Модуль SAP Production Planning (РР) демонстрирует реальные преимущества такой интегрированной, ориентированной на процессы и работающей в реальном времени системы, как SAP R/3. Анализируя свежайшую информацию, полученную от различных функций, система рационализирует и ускоряет принятие решений и эффективность производственной логистики в целом. Система SAP также приводит к одному знаменателю методологию MRP II и необходимость ориентации на потребителя одновременно с поддержанием гарантий качества. Выдвигаемые потребителем требования интерпретируются в управление спросом, которое является основой для планирования производства; планирование ведущих позиций (Master Production Scheduling, MPS) балансируется относительно примерного плана мощностей. Цикл MRP приводит к автоматической генерации производства и созданию требований или заказов на поставку материалов. Выполненные заводские заказы-наряды запускают реальную производственную деятельность, в конечном итоге заказ подтверждается и закрывается. На всех стадиях в режиме реального времени производятся записи соответствующей бухгалтерской информации в модули финансов и контроля. На рис. 9.4 и 9.5 представлены подменю Основные Данные (Master Data) (в подменю Производство) и подменю Генеральный план (Master Planning).

Рис. 9.4. Подменю Основные Данные (в подменю Производство).

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

Рис. 9.6. Подменю Управление Качеством.

Модуль SAP Plant Maintenance (РМ) обеспечивает средства для применения полного производственного технического обслуживания и ремонта (Total Productive Maintenance, ТРМ) на производстве и производственном оборудовании компании. Этот модуль дает такие преимущества, как:

• Мониторинг наличия и доступности ресурсов, затрат, материалов и рабочей силы

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

• Снижение затрат на проверки

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

На рис. 9.7 представлено подменю модуля Обслуживание и Ремонт.

Рис. 9.7. Подменю модуля Обслуживание и Ремонт.

Модуль SAP Human Resources (HR) обеспечивает полномасштабную оптимизацию использования персонала компании. Функции, которыми управляет этот модуль, включают в себя организационные единицы, их обязанности и задачи, требования к навыкам сотрудников, набор и комплектацию персонала, развитие персонала, управление временем, окладами, льготами и т. д. Модуль HR обеспечивает неоценимую помощь при наборе персонала и предотвращении текучести кадров, а также при повышении квалификации персонала. На рис. 9.8 представлено подменю «Планирование» меню HR.

Ключевые бизнес-процессы

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

• Организационный менеджмент

Рис. 9.8. Подменю Планирование в меню Кадры.

Довольно давно компания SAP поняла, что каждая отрасль имеет специфические требования, характерные для компаний в этой отрасли. Компания SAP поставляет широкий спектр вертикальных отраслевых решений (Industry-Specific Solutions (IS)), которые могут прилагаться к базовому решению R/3. В 1998 году компания SAP представила Карты Решений SAP для 19 отраслей и продолжает модернизировать эти решения, а также постоянно добавлять новые отраслевые решения. Ниже приведены некоторые из отраслей, охваченных решениями SAP:

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

• Нефтегазовая промышленность

• Фармацевтика

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

Рис. 9.9. Отраслевые решения.

Компания SAP разработала и представила исчерпывающие карты решений (SAP Solution Maps), которые описывают созданные для различных отраслей решения, а также соответствующую технологию и услуги, необходимые для обслуживания этих решений. Карты Решений SAP описывают необходимые бизнес-функции в рамках одной отрасли. Они дополняются Картой Технологий Бизнеса SAP (SAP Business Technology Map), которые описывают технологическую инфраструктуру SAP, а также Картой Услуг SAP (SAP Services Map), которая описывает услуги компании SAP и ее партнеров в планировании, конфигурации, внедрении и использовании отраслевого решения. Применяя ясное, четкое оформление и краткие, емкие названия, эти карты решений значительно облегчают оценку и принятие решений по внедрению совместимых или комплексных IТ-решений.

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

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

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

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

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

На рис. 9.10 — 9.12 представлены карты 1-го уровня, на рис. 9.13 — 9.18 представлены карты 2-го уровня. На этих рисунках использованы следующие значки:

Второй атрибут указывает, произведен ли продукт компанией SAP или партнерами SAP:

• Sn — продукт SAP

• Pn — продукт партнера SAP

• Vn — услуга SAP

• Bn — услуга партнера SAP

Рис. 9.10. Карта решения SAP — Химия.

В этой главе мы произвели обзор базовых модулей SAP. Эта книга рекомендует предприятиям нового тысячелетия внедрить такие базовые модули, как FI–CO, MM, SD, РР и т. д., в зависимости от отрасли и области деловой активности, причем внедрение рекомендуется проводить по методу «Большого взрыва», когда компании внедряют стандартный пакет модулей в сочетании с одним из отраслевых решений.

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

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

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

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

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

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

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

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

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

Следующим логическим шагом после инсталляции 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. Экран Обновление авторизации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Методы

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

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

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

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

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

• База знаний

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• НИОКР

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Поддержка SAP

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

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

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

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

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

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

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

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

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

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

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

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

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

• Сервер

• Сеть.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Сеть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Команда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Конвертация и обработка скрытых в глубинах организации знаний, придание им интегрированной, логически последовательной формы для ускорения внедрения SAP.

• Предотвращение повторения проблем во время внедрения SAP посредством обработки и распространения знаний, накопленных за время реализации проекта; также рекомендуется использовать знания и опыт других организаций, внедривших SAP.

Ценный опыт и знания, накопленные членами команды по внедрению, не должны быть потеряны для остального персонала компании — ведь это ресурс и его необходимо превратить в капитал. Процесс передачи знаний ASAP выступает в качестве средства накопления информации и опыта как внутри организации, так и за ее пределами; база знаний помогает команде проекта и персоналу компании в целом значительно ускорить внедрение SAP. В соответствии с методологией ASAP, процесс передачи знаний состоит из следующих аспектов:

• Обработка информации: исследование, сбор, подтверждение подлинности, рационализация и оценка информации, методик и технологии.

• Поставка информации: сохранение, оформление, совместное использование и применение информации.

За администрирование и управление процессом передачи знаний отвечает команда по управлению изменениями.

Планирование и проведение обучения членов команды SAP позволяет им сопоставить требования к бизнес-процессам и функциональности R/3, чтобы в итоге составить Концептуальный проект. В основном это обучение 1-го и 2-го уровня. Компания SAP предоставляет своим клиентам возможность пройти обучение на 5-недельных курсах в Партнерской Академии, причем каждый курс нацелен на углубленное изучение того или иного модуля SAP — например, FI, СО, SD, MM, РР, HR, АВАР или Basis.

Создание среды разработки включает в себя инсталляцию и конфигурацию тестового мандата и системы разработки.

Компания SAP рекомендует документировать всю техническую инфраструктуру с помощью соответствующего шаблона под названием «Документ инфраструктуры» (IT Infrastructure Document). Эта задача включает в себя следующее:

• Подготовку структуры системы и ее дистрибуции

• Подготовку инфраструктуры печати

• Подготовку топологии сети

• Подготовку топологии интерфейсов

• Подготовку управления запросами на изменения

• Подготовку стратегии управления версиями и модернизациями

• Подготовку стратегии управления терминалами.

Среда разработки создается на основе технического проекта и включает в себя инсталляцию и конфигурацию системы тестирования клиентов и разработок, которая симулирует условия рабочей системы (тестовый мандат). На этом этапе необходимо выполнить следующие задачи:

• Инсталляция первичного компьютерного оборудования

• Инсталляция первичного ландшафта системы

• Конфигурация и тестирование транспортной системы

• Инсталляция компьютеров и периферии для членов команды проекта

• Подготовка основных записей по пользователям и обеспечение безопасности системы

• Инсталляция первичных устройств печати

• Установка удаленного подсоединения к SAP.

На этом этапе следует определить, протестировать и утвердить процедуры системного администрирования для среды разработки. Необходимо выполнить следующие задачи:

• Провести семинар по Базису и системному администрированию

• Определить системное администрирование для среды разработки

• На основе принятых решений провести конфигурацию Центральной управляющей системы (CCMS)

• Определить стратегию резервного копирования данных.

На этом этапе необходимо создать Руководство по внедрению (IMG), которое уже обсуждалось в одноименном разделе главы 12. Справочник IMG используется на более поздних этапах определения бизнес-процессов.

Создание Руководства по внедрению на предприятии

Для того, чтобы создать специфическое для конкретного предприятия Руководство пользователя, надо выбрать необходимые компоненты приложения allEnterprise IMG. Следует отметить, что выбор компонента подразумевает автоматический выбор всех элементов, подчиненных этому компоненту по иерархии. Однако если компания собирается использовать ссылку ASAP IMG, необходимо выбрать все компоненты Enterprise IMG.

Документ Enterprise Process Area Scope генерируется в базе данных «Вопросы и ответы» (см. рис. 14.1 и 14.2).

Рис. 14.1. Основной экран для базы данных «Вопросы и ответы» в ASAP

Определение бизнес-структуры предприятия подразумевает создание концепции организационной структуры, состоящей из таких элементов SAP, как клиент, код компании, область контроллинга, область бизнеса, организация закупок и продаж и т. д. Такая структура упорядочивает процессы в области логистики и финансов в SAP, а также управление кадрами.

В результате создается организационная бизнес-структура компании в рамках системы SAP, на основе организационных правил системы R/3. Для этих целей в методологии ASAP предусмотрена документация по моделированию структуры (Structure Modeler) и соответствующий шаблон в Visio. Создание организационной бизнес-структуры происходит на собраниях с участием спонсора проекта, управляющего проектом, лидера команды по бизнес-процессам и других ключевых членов рабочих команд. Можно организовать отдельные семинары для обсуждения финансовых процессов и процессов из области логистики с последующей интеграцией полученных результатов.

В методологии ASAP предусмотрен список контрольных вопросов по организационной структуре, который содержится в разделе «Общие вопросы бизнеса» (Business Overview Questions), (см. рис. 14.2 и 14.3) в базе данных (Q&Adb).

Рис. 14.3. Запись ответов на организационные вопросы компании

Следующей задачей после определения организационной структуры является определение бизнес-процессов компании, которые поддерживает SAP. Эта важнейшая информация станет основой для Концептуального проекта. В следующих подразделах рассматриваются связанные с этим этапом задачи.

При подготовке семинаров необходимо выполнить следующие условия:

• Убедиться, что все бизнес-процессы охвачены рамками проекта.

• Определить ответственных за бизнес-процессы сотрудников как внутри команды проекта, так и в соответствующих рабочих областях.

• Обновить базу данных «Вопросы и ответы» (Q&Adb) на основе последних версий документов по объемам процессов на предприятии.

• Составить график участия ключевых пользователей.

Также необходимо назначить ответственных за бизнес-процессы сотрудников владельцами конкретных участков бизнес-процессов, а также соответствующих областей базы данных «Вопросы и ответы» (Q&Adb).

Семинары по общим требованиям охватывают глобальные параметры и стандарты, которые едины для всех областей деятельности организации или предприятия — это немаловажно в первую очередь для компаний, имеющих отделения в различных странах мира. В Руководстве по внедрению указаны следующие глобальные установки:

• План счетов

• Организационная структура предприятия

• Годовой баланс и анализ прибыльности

• Обновление и поддержка центральных и локальных основных данных

• Страны

• Валюты

• Единицы измерения

• Особенности календаря

• Нумерация документов.

Такие семинары необходимо проводить, чтобы собрать информацию по требованиям к бизнес-процессам и связанным с ними вопросам. В конечном итоге собранная информация формулируется в Концептуальном проекте.

Определение требований к бизнес-процессам

Определение требований к бизнес-процессам проводится с учетом следующих документов:

• Карта охвата областей бизнес-процессов

• База данных «Вопросы и ответы» (Q&Adb)

• Формуляр описания исходных данных клиента (Customer Input, CI).

В методологии ASAP предусмотрен список контрольных вопросов, который служит основой для проведения таких семинаров. Вопросы, связанные с организационной структурой содержатся в базе данных «Вопросы и ответы» (Q&Adb), в разделе «Вопросы по бизнес-процессам» (см. рис. 14.5).

К списку контрольных вопросов прилагаются подробные сведения о бизнес-процессах — для этого заполняются шаблоны опросов мнений потребителей, которые содержат 15 вопросов по каждому из процессов (см. рис. 14.6) и охватывают следующие темы:

• Ожидаемые требования

• Общие ожидания

• Объяснение функций и событий

• Особые организационные мнения

• Бизнес-модель

• Изменения существующей организации

Рис. 14.5. Вопросы, связанные с бизнес-процессами.

Это — заключительная проверка выполнения этапа Концептуального планирования. Компания SAP рекомендует следующий список контрольных вопросов для такой проверки:

1. Убедитесь, что состоялись все необходимые заседания управляющего комитета и заседания команд по статусу проекта.

2. Убедитесь, что все члены команды проекта прошли необходимое обучение.

3. Убедитесь, что состоялись все необходимые мероприятия по формированию рабочих команд.

4. Убедитесь, что обязанности и ответственности четко распределены между сотрудниками.

5. Подтвердите разработку технического проекта.

6. Подтвердите создание среды разработки и платформы системы разработки.

7. Убедитесь, что установлены все необходимые функции системного администрирования.

8. Подтвердите инициализацию Руководства по внедрению (IMG).

9. Подтвердите завершение и официальное одобрение этапа концептуального проектирования и определение базовых рамок проекта.

Этап концептуального проектирования гарантирует полное понимание всеми сотрудниками компании окончательных рамок проекта, что включает в себя организационную структуру, бизнес-процесс и техническое устройство системной среды.

Закрытие этапа включает в себя получение одобрения от руководства проекта, причем крайне важно получить официальный отказ от претензий до перехода к следующему этапу. На этапе Концептуального проектирования закладывается фундамент проекта внедрения SAP в целом, поэтому необходимо, чтобы все ясно понимали рамки и направление проекта перед началом следующих этапов проекта.

Официальное закрытие этапа Концептуального проектирования означает окончание второго этапа методологии ASAP.

На данном этапе задача управления проектом мало отличается от других этапов — в основном она по-прежнему состоит из управления и контроля за прохождением данного этапа проекта. Анализ требований новой организационной структуры и новых бизнес-процессов позволяет определить случаи, когда необходимо непосредственное управление отношениями между организационной структурой и бизнес-процессами; такое исследование является одним из главных инструментов окончательной детализации плана внедрения.

Эта задача подразумевает анализ потенциальных рисков, обнаруженных на стадии подготовки. В результате на этапе реализации внедряются различные инициативы — например, процесс управления организационными изменениями на основе периодической оценки рисков как на уровне команды проекта, так и на уровне всей организации. Цель этой задачи — гарантия продвижения внедрения по направлению к основной цели. Анализ включает следующие аспекты:

• Управление проектом

• Техническое управление проектом

• IТ-инфраструктура

• Процесс управления изменениями

• Приверженность персонала своему делу.

Эта задача направлена на выяснение статусов различных команд проекта:

• Команды, занимающейся бизнес-процессами

• Команды по управлению изменениями

• Технической команды.

Такие собрания обеспечивают сопоставление и упорядочение информации с целью определения общего статуса проекта и принятия решений по координации действий тех или иных команд, причем рекомендованные меры потом также рассматриваются и в случае необходимости корректируются. Все это оказывает прямое влияние на расход ресурсов, бюджета и соблюдение графика проекта, а также определяет окончательную дату запуска системы. Кроме того, на таких собраниях постоянно рассматривается и дополняется общий план проекта.

Проведение собраний Управляющего комитета необходимо для постоянного обновления общего статуса проекта и быстрого принятия решений по связанным с проектом вопросам, которые невозможно решить на уровне управления проектом, например:

• Выделение дополнительных ресурсов

• Изменений сроков и графика

• Расширение рамок проекта.

Все принятые решения фиксируются с дальнейшими дополнениями по тому или иному вопросу.

Методология ASAP рекомендует раннее планирование завершающего этапа проекта. Планирование перехода на новую систему гарантирует своевременное выполнение всех мероприятий перед началом перехода, причем с разумным расходом ресурсов и рабочего времени. Такой план должен охватывать следующие аспекты:

• Установка и запуск рабочей среды

• График конвертации данных

• Организация команды по переходу на новую систему

• Дезактивацию унаследованных систем, чье место занимает SAP

• План возврата к унаследованным системам в случае серьезных непредвиденных проблем

• Тестирование новой системы

• Список контрольных вопросов для всех мероприятий, связанных с переходом.

Планирование поддержки рабочей системы нацелено на удовлетворение требований техподдержки после фактического запуска системы. Такой план должен охватывать следующие аспекты:

• Окончательное определение технической конфигурации

• Закупка необходимого оборудования

• Формирование команды запуска системы

• Формирование постоянной команды технической поддержки

• Определение процедур и инфраструктуры справочной службы

• Набор персонала для справочной службы (help desk)

• Набор персонала для команды технической поддержки

• Создание плана восстановления данных в случае серьезных сбоев, а также соответствующих процедур и инфраструктуры.

Формирование команд

Эта задача нацелена на упорядочение событий и мероприятий, связанных сформированием команд и командного духа. Мероприятия по формированию команд позволяют сделать сотрудников более сплоченными, мотивированными и укрепить их способность к работе в тандеме с другими командами и отдельными сотрудниками на пути к успешному завершению проекта. Для этого организуются следующие мероприятия:

• Совместные обеды или ужины

• Небольшие подарки

• Совместные праздники

• Пикники

• Рассылка информационного бюллетеня о проекте.

Подготовка к этапу реализации

Подготовка к этапу реализации подразумевает составление плана и предупреждение рисков, которые могли бы поставить под сомнение успех проекта на данном этапе, вследствие чего особое значение приобретает процесс управления изменениями.

Как уже упоминалось в предыдущей главе, организация управления изменениями включает в себя совокупность процессов, которые позволяют команде по управлению изменениями определять возможности и принимать решения в целях оптимизации организационных процессов и поддержания на должном уровне движущей силы для успешного применения методологии ASAP, вплоть до закрытия проекта. Во избежание возможных рисков методология ASAP рекомендует поддерживать всю совокупность процессов, в том числе оценку рисков, стратегию спонсорства, обмена данными, развитие и передачу навыков и знаний, а также процесс организационной оптимизации. Поддержка организации управления изменениями позволяет команде устранить организационные риски, ускорить внедрение SAP и оптимизировать организационные процессы.

Периодическая оценка рисков и проведение семинаров

Оценка рисков проводится примерно раз в два месяца и нацелена на выяснение того, в какой степени операционная среда компании облегчает или, наоборот, затрудняет внедрение SAP. Результаты такой оценки являются важнейшими данными, на которых основывается процесс управления изменениями.

Оценка рисков проводится в трех контекстах:

• Лидерство

• Команда

• Организация.

В каждом из этих случаев команда управления изменениями создает соответствующий инструмент для той или иной группы сотрудников. Результаты оценки рисков компилируются в профиль рисков; затем проводятся оценочные семинары, на которых принимаются рекомендации для создания или изменения различных программ спонсорства и обмена информацией, а также по другим аспектам процесса управления изменениями. На основе результатов оценки рисков также составляются информационные сообщения, которые распространяются среди сотрудников организации (иногда эти сообщения необходимо приспосабливать к условиям той или иной рабочей команды или функционального подразделения компании).

Крайне важно документировать тип и степень рисков, которые рассматриваются на семинарах, потому что эти данные имеют прямое отношение к динамике выполнения проекта внедрения в целом. Более того, эти записи могут служить свидетельством эффективности ранее принятых в процессе управления изменениями мер и стать основанием для корректировки будущих мероприятий.

Обеспечение обратной связи с функциональными руководителями

Отчетность, предоставляемая функциональными руководителями, может включать сведения по ключевым мероприятиям, срокам, оставшимся невыполненными задачам и т. д.

Проведение собраний по управлению рисками с участием ключевых сотрудников

Эта часть рабочего задания подразумевает ознакомление ключевых участников команд проекта с последними сведениями о статусе проекта и результатами семинаров по оценке рисков. Кроме того, необходимо убедиться, что все занятые на тех или иных участках менеджеры проекта ознакомлены с самыми свежими результатами анализа ситуации и тенденциями развитии проекта (относительно области ответственности конкретного менеджера).

Поддержка ключевых каналов обмена информацией

Результаты оценки рисков необходимо учитывать при изменении ключевых каналов обмена информацией с целью поддержания их максимального соответствия изменчивым обстоятельствам на оставшихся этапах проекта.

Управление постоянным процессом проектного спонсорства

Эта задача нацелена на поддержание эффективности процесса спонсорства, инициированного на этапе Концептуального планирования.

Управление постоянным процессом развития навыков персонала

Эта задача нацелена на поддержание движущей силы процесса развития навыков персонала, начатого на этапе Концептуального планирования.

Управление командой по передаче знаний

На этапе реализации команда по передаче знаний должна продолжать поддерживать процесс управления изменениями.

Обновление команды по управлению изменениями

В случае, если в команду по управлению изменениями приходят новые люди, необходимо убедиться в том, что они быстро знакомятся с методами создания и администрирования инструментов оценки рисков. Кроме того, новые члены команды обязательно должны ознакомиться с историей деятельности этой команды с самого начала проекта.

Планирование и реализация обучения членов команд проекта SAP позволяет им конфигурировать и тестировать предусмотренные Планом концептуального проектирования бизнес-процессы.

Цель этой задачи — подготовка системной среды к реальной работе, что подразумевает определение системных требований к инфраструктуре, допустимых значений характеристик работы системы, системное администрирование и окончательное создание рабочей среды системы SAP.

На этом этапе необходимо четко определить условия соглашений об обслуживании и заключить такие соглашения.

Определение сценариев сбоев

Эта задача нацелена на создание сценариев событий, при которых работа системы R/3 могла бы быть частично или полностью парализована, например сценарии сбоев в работе:

• компьютерного оборудования

• компьютерных сетей

• отдельных терминалов

• серверов приложений

• серверов баз данных

• при передаче данных в системе R/3

• систем безопасности

• систем безопасности в компьютерных центрах.

С помощью таких сценариев необходимо выработать меры по предотвращению подобных случаев или минимизации возможного ущерба. В случае реального сбоя принятые меры должны обеспечить выполнение процедур по оповещению о произошедшем сбое и управлению ситуацией.

Создание процедур по восстановлению данных в случае крупных сбоев

Создание процедур по восстановлению данных в случае крупных сбоев осуществляется на основе подробного анализа сценариев сбоев относительного каждого из приложений и минимального времени, которое необходимо для возврата приложения к нормальной работе. Помимо прочего, такой анализ позволяет упредить возможные сбои и максимально отразить такие возможности в заключенных с поставщиком соглашениях об обслуживании. Процедуры восстановления данных в случае крупных сбоев должны охватывать следующие области:

• Анализ допустимого времени простоя для различных приложений

• Скрипты процедур восстановления данных в случае масштабного сбоя

• Анализ соглашений с поставщиком о текущей техподдержке и дополнительных услугах

• Процедуры оповещения пользователей и каналы обмена информацией

• Промежуточные операции

• Процедуры перезагрузки

• Критерии успешного восстановления данных в случае масштабного сбоя

• Возврат к нормальной работе системы.

Создание базы соглашений для обслуживания системы

Эта задача подразумевает создание точно определенных, поддающихся измерению критериев обслуживания у различных поставщиков, в том числе взаимозависимых. Это относится не только к поставщикам оборудования, операционных систем, сетевой инфраструктуры и периферии, но и к компании SAP.

Эта задача подразумевает определение планов тестирования для этапа окончательной подготовки. Различные тесты описаны ниже.

Разработка плана тестов на сбои

План тестов на сбои моделирует сбой в одном из компонентов системы с целью оценки последствий такого сбоя, влияния на зависимые компоненты, ожидаемые результаты, а также содержит инструкции пользователю — как вести себя в такой ситуации, процедуры исправления ошибок, обучение и т. д.

Разработка плана нагрузочного тестирования

План нагрузочного тестирования составляется в рамках окончательного интеграционного тестирования. Такое тестирование позволяет убедиться в том, что при вводе основных бизнес-транзакций, а также их копировании или составлении отчетности пропускная способность системы находится на должном уровне.

Разработка плана функционального тестирования

Это тестирование нацелено на выяснение способностей системы справляться с возрастающими нагрузками в случае подключения новых пользователей. В плане функционального тестирования фиксируются параметры тестов, график резервного копирования, сохранение и мониторинг результатов. Также предусматривается выполнение рекомендуемых изменений конфигурации и модернизация системной конфигурации.

Разработка плана тестирования системного администрирования

Это тестирование моделирует повседневную деятельность системного администрирования, чтобы убедиться в ее адекватности и полноте.

Разработка плана тестирования принтеров

Тестирование принтеров в основном нацелено на подтверждение того, что все срочные документы и данные распечатываются в срок, а также проверку процедур перезагрузки и переключения между принтерами, нагрузочное тестирование печати больших объемов документов и т. д.

Это тестирование проверяет работоспособность инструментов и утилит администрирования в системе SAP.

Создание процедур копирования клиента

Создание процедур копирования клиента подразумевает использование утилит копирования клиента, а также отзыва (аннуляции) копии клиента.

Создание процедур ежедневных проверок

Ежедневные проверки должны охватывать следующие аспекты:

• Системный журнал

• Система управления очередностью печати

• График работ

• Анализ дампов

• Настройка и тестирование мониторов Центральной управляющей системы (CCMS)

• Настройка и анализ трассировки.

Создание процедур транспортировки

Эта задача нацелена на подтверждение эффективности транспортной системы, в том числе следующих ее аспектов:

• Выпуск запросов на изменения

• Импорт в систему обеспечения качества (Quality Assurance, QA) и в рабочую среду

• Процедуры «заморозки» кодов и тестирование качества (QA)

• Процедуры утверждения результатов обеспечения качества (QA) и запуска в рабочую среду.

Создание процедур резервного копирования и восстановления данных

Тестирование резервного копирования баз данных подразумевает создание процедур восстановления баз данных и журналов, а также проверку полноты и правильности восстановленных данных.

Система QA используется для проведения окончательного интеграционного тестирования, эту систему необходимо инсталлировать и сконфигурировать.

Установка оборудования

Установленное оборудование, операционные системы и другие компоненты должны полностью соответствовать требованиям конкретной версии системы R/3. В том числе анализируется возможность подключения к онлайновой сервисной системе (OSS).

Инсталляция системы обеспечения качества

Инсталляция системы R/3 включает в себя следующие шаги:

• Запуск программы R3SETUP.

• Инсталляция основных копий.

• Инсталляция баз данных.

• Инсталляции программного обеспечения сервера представления на серверах приложений и центральных копиях.

• Просмотр журнала R3SETUP.log для обнаружения возможных проблем.

• Проверка правильности совершенных действий посредством инсталляции и использования графического пользовательского интерфейса (SAPGUI) и электронной документации.

Создание основных записей

Создание основных записей и профилей по пользователям необходимо, чтобы пользователи смогли работать в среде «Обеспечение качества» (QA) и проводить нужное им тестирование. Профили доступа в систему QA являются частью среды разработки (Development, DEV).

Безопасность системы «Обеспечение качества»

Безопасность системы обеспечения качества заключается в контроле доступа к операционной системе и базе данных для исключения возможности случайных или намеренных изменений системы QA. Доступ к внутреннему устройству системы QA позволен лишь небольшому числу технических сотрудников и только после прохождения строгой процедуры создания такого доступа.

Создание системы принтеров

Эта задача подразумевает инсталляцию, конфигурацию и тестирование всех устройств печати.

Создание транспортной системы и системы управления клиентами

Эта задача подразумевает инсталляцию и конфигурацию системных клиентов, в том числе клиентских ролей, перекрестных клиентов и автоматической транспортировки объектов.

В рабочей системе задачи системного администрирования должны быть точно заданы и задокументированы, в том числе должна быть распределена ответственность за следующие задачи:

• Создание процедур поддержки безопасности рабочей системы

• Создание процедур рабочих операций

• Создание процедур администрирования рабочей системы

• Создание среды принтеров в рабочей системе

• Создание процедур администрирования баз данных в рабочей системе

• Создание руководства пользователя системы SAP.

Создание рабочей среды означает инсталляцию и конфигурацию системы, которая в основном будет использоваться в рабочей среде. Чтобы инсталлировать систему SAP R/3, следует обратиться к Руководству по установке SAP R/3 (Advanced Installation Guide). Создание рабочей среды включает в себя:

• Инсталляцию рабочего компьютерного оборудования

• Инсталляцию рабочей системы

• Инсталляцию и конфигурацию сетевого окружения

• Инсталляцию и конфигурацию настольных компьютеров и периферии

• Обеспечение безопасности операционной системы и баз данных

• Создание системы принтеров.

Основной список бизнес-процессов (Business Process Master List, BPML) — это самое полное представление рамок проекта внедрения SAP. Конфигурация делится на две части — базовая конфигурация и окончательная конфигурация.

Эти конфигурационные задания относятся к конфигурации и подтверждению параметров базовой настройки, что включает в себя сценарии, процессы и функции, которые затрагивают первостепенные требования компании (около 80 %). Оставшиеся 20 % сценариев и процессов настраиваются на стадии окончательной конфигурации и подтверждения.

Методология ASAP рекомендует сначала включить в базовую конфигурацию процессы, которые можно настроить, не модифицируя систему. Для этого необходимо выполнить следующие задачи:

Пересмотр рамок базовой конфигурации

Базовая конфигурация, подготовленная на этапе Концептуального планирования, подвергается пересмотру.

Создание базового плана конфигурации

Создание базового плана конфигурации происходит следующим образом:

1. Открыть Основной список бизнес-процессов (BPML) и выбрать лист «Базовая».

2. Добавить глобальные параметры в начале BPML.

3. Добавить задачи по конфигурации в организационную структуру, вслед за глобальными параметрами.

4. Ввести запланированную графиком дату в колонке «План» раздела «Конфигурация».

5. Ввести информацию по тестированию и порядку следования взаимозависимых процессов. Для этого надо ввести номер ситуации и номер следования процесса в группу ассоциированных процессов в колонках «Конфигурация: Номер ситуации, Номер следования». Нажатие клетки «Просмотр» под колонкой «Конфигурация» позволяет отсортировать процессы по номерам.

6. Сохранить изменения в Плане базовой конфигурации в формате MS Excel.

Создание тестовых ситуаций

Создать контрольные примеры с помощью следующего:

1. Открыть План базовой конфигурации, выбрать лист «Базовая», измененный на предыдущем этапе.

2. Просмотреть предусмотренные в этом документе ситуации для тестирования «по умолчанию», которые можно принять для конкретного проекта.

3. Ввести информацию по тестированию и порядку следования взаимозависимых процессов, для этого надо ввести номер ситуации и номер следования процесса в группу ассоциированных процессов в колонках «Тестирование: Номер ситуации, Номер следования».

4. Добавить информацию по тестированию к базовым требованиям, примечаниям и ожидаемым результатам.

5. Для уточнения информации по тестированию, выбрать «Процедура тестирования» и добавить подробную информацию.

6. Сохранить изменения.

Создание плана тестирования

Создание плана тестирования для базисной конфигурации включает в себя следующие действия:

1. Открыть План базовой конфигурации, выбрать лист «Базовая», измененный на предыдущем этапе.

2. Ввести запланированную графиком дату в колонке «План» раздела «Тестирование».

3. Сохранить готовый план.

Распределение ресурсов

Распределить ресурсы для базовой конфигурации и протестировать их можно следующим образом:

1. Открыть План базовой конфигурации и выбрать лист «Базовая», измененный на предыдущем этапе.

2. Задать необходимые навыки, подтвердить наличие ресурсов и распределить ответственность среди сотрудников, которые работают с тем или иным процессом, среди членов команд и ключевых пользователей.

3. Ввести ФИО члена команды в колонке «Ответственность — Конфигурация и тестирование».

4. Сохранить изменения.

Одобрение плана базовой конфигурации владельцами процессов

На этом этапе обновляется Руководство по внедрению — в него вносится информация о ресурсах и назначениях. Данные вводятся вручную или, если компания использует функцию ASAP IMG (Руководство по внедрению), то автоматически (см. раздел «Инициация Руководства по внедрению» в главе 14).

Конфигурация общих параметров системы и организационной структуры абсолютно необходима как для базовой, так и для окончательной конфигурации системы SAP.

Конфигурация общих параметров

Конфигурация общих параметров зависит от информации, полученной во время семинаров по общим требованиям к бизнес-процессам, которые проводились на этапе концептуального планирования (см. главу 14), в том числе от таких параметров, как страна, ее валюта, единицы измерения, особенности календаря и т. д.

Для каждого элемента конфигурации необходимо ввести соответствующие данные в Руководство по внедрению (IMG) с помощью документации IMG Notes. Подобным образом также обновляется План базовой конфигурации, намеченная дата конфигурации и ее статус.

Конфигурация организационной структуры

Это мероприятие зависит от документации и решений, утвержденных на этапе концептуального планирования, в рамках задачи формирования организационной структуры (см. раздел «Определение организационной структуры» в главе 14).

Создание и конфигурация организационных единиц производится с помощью ссылок или использования функции «копировать»; также необходимо обновлять соответствующую информацию в Руководстве по внедрению и в Плане базовой конфигурации.

Конфигурация заранее заданных параметров

В случае, если компания принимает заранее сконфигурированную систему (Predefined Configured System, PCS), необходимо использовать параметры предварительно заданного клиента (Predefined Client, РСС); хотя в случае необходимости эти параметры можно проверить на соответствие требованиям и изменить. В случае внесения изменений, следует обязательно внести соответствующие обновления в Руководство по внедрению и в План базовой конфигурации.

Это — основная, центральная стадия этапа реализации, в рамках которой производится изменение настроек конфигурации для сценариев и процессов. Измененные настройки транспортируются в среду «Обеспечение качества» (QA) для тестирования в соответствии с планами тестирования и тестовыми ситуациями, подготовленными ранее. Полученная в результате тестирования информация служит основой для изменения Плана базовой конфигурации, а также Концептуального плана.

Конфигурация процесса и функций

Эта задача подразумевает изменение настроек конфигурации в соответствии с Планом базовой конфигурации: соответствующая информация в Руководстве по внедрению (IMG) и Плане базовой конфигурации должна обязательно обновляться.

Транспортировка в систему обеспечения качества

Объекты базовой конфигурации необходимо транспортировать в систему обеспечения качества (QA).

Тестирование базовой конфигурации

Тестирование базовой конфигурации проводится с использованием тестовых ситуаций и планов, предусмотренных Планом базовой конфигурации. Для каждой тестовой ситуации параметры и данные тестирования обязательно документируются — позднее эта информация пригодится во время подтверждения базовой конфигурации.

Документирование проблем и их решение

Любые расхождения, проблемы или недочеты должны записываться и немедленно решаться; для записи используется «проблемная» база данных в рамках базы данных «Вопросы и ответы» (Q&Adb). Если проблема относится к области предварительного просмотра окончательной конфигурации, ее надо присвоить соответствующему циклу (см. раздел «Базовая конфигурация и подтверждение»).

Пересмотр Концептуального плана

На основе результатов конфигурации и подтверждения сценариев и бизнес-процессов Концептуальный план пересматривается и в нем отражается текущая информация.

Проверка полноты базовой конфигурации

Используя План базовой конфигурации, необходимо проверить все даты текущей и запланированной деятельности по конфигурации и тестированию процессов и сценариев, причем проблемные процессы должны быть отображены в базе данных «Вопросы и ответы». Убедиться в этом можно также с помощью Руководства по внедрению (IMG), запустив анализ проекта из меню «Настройки».

На этом этапе необходимо сформулировать сценарии подтверждения успешной конфигурации системы, что включает в себя следующие задачи:

• Составление сценариев подтверждения

• Проведение подтверждения базовой конфигурации

• Подготовка программы сценариев подтверждения ответственными за межфункциональные процессы сотрудниками и назначение участников процесса подтверждения.

• Обзор подтверждения базовой конфигурации, получение официального одобрения и закрытие стадии базовой конфигурации.

Сценарии утверждения

Сценарий утверждения (т. е. группа процессов) является полным бизнес-процессом, который можно разделить на подпроцессы. Последние проще утвердить как серию последовательных шагов сценария. Процедура контрольного примера (business case) представляет собой жизненно важный поток информации, ассоциированные с ними условия и исключения. Составление контрольного примера требует следующих действий:

1. Открыть План базовой конфигурации и выбрать «Базовая».

2. Ввести информацию по подтверждению и порядку следования взаимозависимых процессов — для этого надо ввести номер ситуации и номер следования процесса в группу ассоциированных процессов в колонках «Конфигурация: Номер ситуации, Номер следования».

3. Добавить информацию о процедурах подтверждения, выбрав шаблон процедуры и заполнив его подробными данными.

4. Сохранить изменения.

Как уже упоминалось в разделе «Базовая конфигурация и подтверждение», не все включенные в рамки базовой конфигурации сценарии и бизнес-процессы отлаживаются на этом этапе.

Чтобы облегчить задачу проведения конфигурации, методология SAP рекомендует сформировать серию циклов конфигурации, в зависимости от приоритетности бизнес-процессов. Эти циклы конфигурации уже упоминались в главе 14. Циклы последовательно конфигурируются до тех пор, пока не будут устранены все неполадки и неясности, после чего система готова для окончательного тестирования на интеграцию.

Каждый цикл представляет собой повторяющийся процесс, который нацелен на систематизацию окончательной конфигурации. Циклы задаются, исходя из следующих критериев:

• Цикл 1: Цель этого цикла — тонкая настройка конфигурации бизнес-процессов для основных данных и наиболее важных процессов.

• Цикл 2: Тонкая настройка конфигурации оставшихся основных данных и элементарных транзакций.

• Цикл 3: Тонкая настройка конфигурации и основных данных посредством запуска наиболее важных процессов.

• Цикл 4: Настройка конфигурации через запуск бизнес-процессов (транзакций, отчетов, пользовательских профилей и т. д.).

Процесс окончательной конфигурации и подтверждения схож с аналогичным процессом на базовом уровне, за исключением того, что в Основном списке бизнес-процессов (BPML) упоминались только ассоциированные с одним из вышеназванных четырех циклов. В случае с окончательной конфигурацией необходимо решить следующие задачи:

• Пересмотр окончательных рамок конфигурации

• Создание плана конфигурации для окончательных рамок проекта

• Подготовка ситуаций тестирования

• Подготовка плана тестирования для окончательных рамок проекта

• Выделение ресурсов

• Получение одобрения плана конфигурации для окончательных рамок проекта.

Подтверждение окончательных рамок конфигурации (циклы от 1 до п)

На этом этапе происходит изменение параметров конфигурации для окончательных сценариев и процессов. Произведенные изменения транспортируются вереду «Обеспечение качества» (QA) для тестирования в соответствии с подготовленными ранее планами тестирования и тестовыми ситуациями. Полученные в результате данные используются для внесения изменений в Концептуальный план и в Основной список бизнес-процессов (BPML).

Эта задача, как и на этапе базовой конфигурации, состоит из следующих шагов:

• Конфигурация процессов и функций.

• Транспортировка объектов в среду «Обеспечение качества» (QA).

• Тестирование окончательной конфигурации.

• Закрепление окончательной конфигурации.

Окончательное подтверждение (циклы от 1 до n)

На этом этапе необходимо сформулировать сценарии подтверждения для гарантии успешной конфигурации системы. Эта задача сходна с подтверждением базовой конфигурации, но основное отличие в том, что она выполняется на цикличной основе:

• Подготовка сценариев окончательного подтверждения.

• Выполнение сценариев окончательного подтверждения.

В главе 7 уже описывались Рабочее место разработчика и система транспортировки. Однако дополнительно к этому, каждый член команды разработки программ должен быть зарегистрирован как легитимный пользователь среды разработки. Для этого необходимо:

1. Создать ID-номер для каждого члена команды разработчиков

2. Зарегистрировать каждого пользователя через Регистрацию изменений программного обеспечения SAP (SAP Software Change Registration, SCCR) в OSS и передать ключ доступа в систему разработки.

3. Создать запрос на изменения для каждого проекта разработки АВАР. Все участники конкретного проекта будут присвоены именно этому запросу на изменения.

4. Создать запрос на изменения для всех объектов АВАР, которые без изменений входят во все проекты АВАР.

5. Сгруппировать объекты Хранилища в иерархию объектов приложений, согласно которой каждый элемент иерархии будет присвоен классу разработки.

Разработка на языке АВАР охватывает создание шаблонов, отчетов, программ конвертации данных, интерфейсов и функциональных усовершенствований, как описано далее в этом разделе.

Разработка специфических для компании бланков и шаблонов документов производится в строгом соответствии с Концептуальным планом и включает в себя следующие задачи:

• Определение внешнего вида и технических спецификаций шаблонов с последующим внесением соответствующих изменений затронутых бизнес-процессов в Основной список бизнес-процессов (BPML).

• Создание шаблонов (если возможно, на основе стандартных шаблонов бланков и документов, предусмотренных в системе).

• Подготовка процедур тестирования шаблонов — определение функций и последовательности тестов и используемых данных.

• Тестирование, анализ и одобрение результатов.

• Транспортировка шаблонов в среду «Обеспечение качества» (QA) для окончательного интеграционного тестирования.

Разработка специфических для компании отчетов производится в строгом соответствии с Концептуальным планом и включает в себя следующие задачи:

• Идентификация процессов, чьи требования по отчетам и анализу не могут быть удовлетворены стандартными отчетами, предусмотренными в системе. Определение периодичности составления таких отчетов, их содержание, источники необходимых данных и т. д.

• Определение спецификации отчета и обновление информации в соответствующих бизнес-процессах в BPML.

• Создание отчетов с использованием подходящих инструментов — таких, как АВАР/4 Query, SAP Report Writer/Painter, АВАР Reporting и т. д. По возможности, следует использовать стандартные отчеты в качестве шаблона; особое внимание стоит уделить возможному влиянию новых отчетов на общие и частные характеристики работы системы.

• Анализ отчетов, чтобы убедиться в том, что они созданы на основе правильных таблиц, используют правильные индексы и в целом функционируют эффективно. Создание неэффективных отчетов увеличивает нагрузку на систему и может привести к ухудшению характеристик ее работы.

• Подготовка процедур тестирования новых отчетов, определений функций и последовательности тестирования, а также данных, которые будут использоваться в тестировании.

• Тестирование, анализ и одобрение результатов.

• Транспортировка отчета в среду «Обеспечение качества» (QA) для окончательного интеграционного тестирования.

Эта задача охватывает разработку программ и процедур ручной передачи данных из унаследованных систем в систему SAP. Во время разработки программ конвертации необходимо учитывать следующие аспекты:

• Природу объектов и данных, подлежащих конвертации

• Методы передачи данных: стандартные программы передачи данных SAP, ручной ввод данных с помощью транзакций в режиме он-лайн или программы пакетного ввода (batch input, BI).

• Объемы данных и качество данных в унаследованных системах.

• Наличие стандартных программ передачи данных в системе R/3, которые требуют, чтобы данные были в определенном формате, а также определенную последовательность загрузки данных. Требуемый формат структуры данных может быть необходим для генерации одномерных файлов.

• Установление связи между полями данных в унаследованной системе и соответствующими полями одномерного файла, который используют программы передачи данных системы R/3.

Если для конкретной ситуации нет стандартной программы передачи данных для загрузки в систему R/3, может возникнуть необходимость в разработке индивидуальной программы пакетного ввода. В SAP предусмотрено Руководство по передаче данных (Data Transfer Made Easy Guidebook) для облегчения передачи данных из унаследованных систем в SAP. Таким образом, в программе передачи и конвертации данных должны быть учтены следующие аспекты:

• Данные считываются с унаследованной системы в формате одномерного файла.

• Поля данных в унаследованной системе ассоциированы с соответствующими полями в системе R/3.

• Записи обработанных программой-конвертером данных сохраняются в другом одномерном файле, который используется программами пакетного (SAP BI) или прямого (direct input, DI) ввода данных в SAP.

В случае с индивидуально разработанной программой, вслед за ее созданием следует выполнить следующее:

• Подготовить процедуры тестирования программы конвертации.

• Тестирование, анализ и одобрение результатов.

• Транспортировка программы конвертации в среду «Обеспечение качества» (QA) для окончательного интеграционного тестирования.

При разработке интерфейсов для взаимодействия с системой R/3 необходимо рассмотреть следующие аспекты:

• Данные, которые будут проходить через указанный интерфейс

• Система, на основе которой интерфейс будет функционировать

• Возможные альтернативы данному интерфейсу

• Различные дополнительные технологии, которые можно использовать при создании данного интерфейса

• Документация по интерфейсу

• Возможные последствия использования данного интерфейса для других приложений.

Как и в случае с программами конвертации или с интеграцией различных приложений, предпочтение всегда стоит отдавать стандартным интерфейсам, предусмотренным в системах SAP. Эти стандартные интерфейсы разработаны на основе сценариев бизнес-процессов для импорта данных в систему R/3 или экспорта данных через выходы приложений. В таком случае сценарии бизнес-процессов точно заданы и определены относительно ассоциированных объектов, и их легко внедрять и поддерживать. Также в качестве альтернативы существуют программные продукты других разработчиков, которые уже сертифицированы для взаимодействия с системами SAP через дополнительные программы, и их всегда стоит иметь в виду.

Компания должна разрабатывать свои решения и интерфейсы для взаимодействия с системой SAP только в самом крайнем случае, если требования Концептуального плана невозможно удовлетворить другими средствами.

Для передачи данных есть два метода; компания выбирает необходимый, руководствуясь внутренними требованиями. Первый — это файловый метод, когда перед передачей данные формируются в файлы, после чего файлы загружаются в другую систему, или могут использоваться другими системами. Такой пакетный метод передачи данных по принципу «сохранение, затем передача» работает только в синхронном режиме. Существуют следующие технологии внедрения пакетных интерфейсов:

• Пакетный ввод (Batch input, BI)

• Вызов транзакции (Call transaction, СТ)

• Промежуточный документ (Intermediate Document, IDoc)

• Интерфейс программирования бизнес-приложений (Business Applications Programming Interface, BAPI)

• Прямой ввод (Direct input, DI).

Второй метод — это обмен данными между программами, при котором для каждой участвующей системы требуется отдельный интерфейс; соединение устанавливается той системой, которая пытается передать данные другой системе. Такой метод позволяет только синхронную передачу и обработку данных; для внедрения такого рода интерфейсов существуют следующие технологии:

• Удаленный вызов функции (Remote Function Call, RFC)

• Обычный интерфейс программирования для обмена данными (Common Programming Interface for Communication, CPI–C)

• Технология компонентов OLE/ActiveX

• Компоненты графического интерфейса пользователя GUILIB/GUI

• Интерфейс IDoc для Electronic Data Interchange (EDI)

• Интерфейс IDoc для Application Link Enabling (ALE)

• SAP Business Workflow

• Интерфейс программирования бизнес-приложений (Business Application Programming Interface, BAPI)

• Сервер Интернет-транзакций (Internet Transaction Server, ITS)

• Компоненты Интернет-приложений (Internet Application Components, IAC).

В случае с индивидуально созданными интерфейсами после разработки программы-конвертера необходимо выполнить следующие задачи:

• Подготовка процедур тестирования интерфейса.

• Тестирование, анализ и утверждение результатов тестирования.

• Транспортировка программ интерфейса в среду «Обеспечение качества» (QA) для окончательного интеграционного тестирования.

Цель этой задачи — разработка модификаций, усовершенствований и дополнительной функциональности для системы SAP в соответствии с Концептуальным планом. Такие усовершенствования могут включать в себя:

• Использование индивидуальных пользовательских подключений к R/3

• Индивидуальные настройки и модификации стандартных объектов R/3

• Разработку индивидуальных настроек и объектов в среде АВАР/4.

Все модификации и усовершенствования должны быть зарегистрированы с помощью программы Регистрации изменений программного обеспечения SAP (SAP Software Change Registration, SSCR). Необходимо отметить, что модификация исходных кодов SAP и объектов словаря данных автоматически отменяет гарантийные обязательства компании SAP.

Внесение модификаций и усовершенствований состоит из следующих этапов:

• Формулировка модификации.

• Разработка модификации.

• Подготовка процедур тестирования модификации.

• Тестирование, анализ и одобрение результатов.

• Транспортировка модификации в среду «Обеспечение качества» (QA) для окончательного интеграционного тестирования.

Концепция авторизации определяет различные функции, которые могут исполнять пользователи, принадлежащие различным организационным единицам. Как уже упоминалось в разделе «Администрирование пользователей» в главе 11, концепция авторизации поддерживает баланс между управлением правами доступа и присвоением привилегий для выполнения тех или иных задач в системе, а также затратами усилий на само администрирование системы. Эта задача подразумевает создание концепции авторизации, которая отвечала бы всем необходимым требованиям.

Клиенты компании SAP должны понимать, что в системах SAP авторизации могут существенно отличаться от авторизации в более старых системах, в том числе относительно распределения функций и ответственности пользователей. Бизнес-процессы могут быть гораздо более децентрализованы, некоторые шаги процессов устранены, и в некоторых случаях доступ к интегрированным данным может быть шире, чем в унаследованных системах. Системы SAP ориентируются на концепцию открытого доступа к информации и отчетности, прозрачности интегрированной системы; однако это может вызвать проблемы на уровне управления изменениями в области авторизации и прав доступа к тем или иным данным.

Ответственность за различные процессы и функции точно определены в Концептуальном плане; такие определения ответственности используются для создания концепции авторизации. Для облегчения создания и внедрения такой концепции в системе SAP R/3 предусмотрено Руководство по системной авторизации (System Authorizations Made Easy Guide).

Для контроля использования сети индивидуальными пользователями требуется структура профилей и авторизации, или концепция авторизации, которую можно составить следующим образом:

• Для каждого подразделения компании составить матрицу «Операции со всеми/некоторыми» и «Доступ ко всем/некоторым» (DO Some/All и SEE Some/All) чтобы составить профиль рисков в безопасности системы, причем это делается с участием ответственных за те или иные процессы и данные сотрудников под контролем отдела кадров. Четыре квадранта этой двумерной матрицы соответствуют следующим вариантам авторизации: Конечные пользователи могут запускать лишь некоторые определенные транзакции, и имеют доступ лишь к определенным данным в системе — «Операции с некоторыми, доступ к некоторым».

Конечные пользователи могут запускать все транзакции, но имеют доступ лишь к ограниченным областям данных — «Операции со всеми, доступ к некоторым».

• Конечные пользователи могут запускать лишь некоторые определенные транзакции, и иметь доступ ко всем данным в системе — «Операции с некоторыми, доступ ко всем».

• Конечные пользователи могут запускать все транзакции и иметь доступ ко всем данным в системе — «Операции со всеми, доступ ко всем».

• На основе подробных консультаций с владельцами бизнес-процессов составить матрицу распределения ролей в системе (Job Role), с указанием различных функций и обязанностей каждого пользователя.

• Составить карту отношений между транзакциями и опциями меню системы R/3, функциональными обязанностями сотрудников и соответствующими данными. Это легко сделать, используя Концептуальный план.

• Задать группы операций. При отметке операции группируются вместе.

• Задать профили авторизации.

• Для каждого пользователя определить основные данные по пользователю (см. раздел «Администрирование пользователей» в главе 11).

• Присвоить пользователям авторизации и группы операций.

• С помощью генератора профилей создать профили пользователей на основе заданных в системе SAP авторизации и групп операций.

Некоторые группы операций задаются только для общих авторизации — таких, как печать, факсимильная связь и использование модуля SAPOffice, которые доступны всем пользователям. Однако чем больше риск от открытия информации, тем строже должны быть ограничения к просмотру и изменению данных, что, в свою очередь, значительно облегчит внедрение систем безопасности.

На этом этапе необходимо внедрить среду авторизации. Компания SAP рекомендует разделить ответственность за обновление основных данных по пользователям и ответственность за авторизации между тремя администраторами с целью обеспечения максимальной безопасности, а также для упрощения процедур. Ниже приведены три типа администраторов:

• Администраторы пользователей: они создают и обновляют основные записи по пользователям и приписывают пользователей к тем или иным группам.

• Администраторы профилей авторизации: они создают или изменяют профили и авторизации, но не могут создавать пользователя или группу пользователей.

• Администраторы групп пользователей: они создают группы пользователей и определяют ассоциированные транзакции R/3, но не могут изменять пользователей или профили авторизации.

Эта задача состоит в утверждении права каждого пользователя на выполнение тех или иных бизнес-процессов, транзакций и отчетов. Что подразумевает проверку: насколько тот или иной бизнес-процесс связан с обязанностями конкретного сотрудника, устранение несоответствий или расхождений, и, в случае необходимости, пересмотр концепции авторизации в зависимости от обстоятельств. Авторизации обязательно утверждаются владельцами бизнес-процессов.

Эта система управляет архивами и архивированием данных, так как данные, в которых нет надобности на текущий момент, должны удаляться из рабочей системы. Большие объемы такой информации не только затрудняют управление базами данных, но и влияют на характеристики работы системы. Создание системы управления архивами состоит из следующих действий:

• Пректирование системы управления архивами. Такая система должна сохранять баланс между увеличением объемов данных, которые появляются в результате повседневных транзакций и операций, и уменьшением объема данных, в результате их архивирования. В настройке циклов архивирования обязательно должны участвовать владельцы бизнес-процессов. Подготовка системы управления архивами включает:

Подготовка процедур архивирования.

Внедрение процедур архивирования.

Утверждение процедур архивирования.

Проведение окончательного тестирования интеграции.

Эта задача включает в себя планирование и проведение окончательного тестирования системы на интеграцию. Тестирование проходит в системе «Обеспечение качества» (QA), в которой воспроизводятся реальные операции для функционального подтверждения возможностей рабочей системы.

Рамки тестирования интеграции системы определяются, исходя из проектирования бизнес-процессов и определения рамок областей бизнеса, проведенного на этапе Концептуального планирования. Как и задача по окончательной конфигурации системы, окончательное тестирование интеграции ориентируется на бизнес-процессы.

План тестирования охватывает следующие аспекты:

• Рамки тестирования

• Сценарии тестирования

• Процессы тестирования

• Ресурсы.

Сценарий теста (или группы процессов) полностью соответствует сценарию бизнес-процесса или другому четко определенному сценарию; сценарий теста можно разделить на тестовые процессы, чтобы упростить задачу пошагового подтверждения сценария. Сценарий процедуры контрольного примера представляет собой жизненно важный поток информации, ассоциированные с ними условия и исключения. Подход к выполнению этой задачи во многом аналогичен подходу к окончательной конфигурации и подтверждению рамок проекта.

Чтобы облегчить проведение тестирования, методология ASAP рекомендует сформировать совокупность циклов интеграционного тестирования, каждый из которых содержит набор бизнес-процессов, отсортированных по принципу приоритетности. Именно такие циклы интеграционного тестирования (L1 и L2) упоминались в разделе «Подготовка концептуального проекта» в главе 14. Циклы тестирования последовательно выполняются, пока не будут решены все проблемы и систему можно признать готовой для перехода к этапу окончательной подготовки перед запуском.

Каждый цикл представляет собой повторяющийся процесс, направленный на систематизацию окончательного тестирования, причем циклы определяются, исходя из следующих критериев:

• Цикл 1: настройка бизнес-процессов для основных данных и высокоприоритетных транзакций с последующим тестированием важнейших бизнес-процессов.

• Цикл 2: тестирование бизнес-процессов, в которых предусмотрены транзакции, отчеты, пользовательские профили, а также исключения из правил или условий выполнения процесса и т. д.

Процесс окончательной интеграции весьма схож с процессом окончательной конфигурации, за исключением того, что в BPML отбираются только те процессы, которые связаны циклами 1 и 2 интеграционного тестирования.

Если нет возможности запланировать тестирование абсолютно всей системы, то можно определить приоритеты, основываясь на следующих критериях:

• Частота процесса

• Эффект от сбоя в данном процессе, количество процессов, которые зависят от данного процесса

• Вероятность того, что сценарий тестирования может случиться в реальной работе.

В методологии ASAP предусмотрена формула для вычисления приоритетности тестирования сценариев; по мере возрастания важности того или иного теста важность его включения в интеграционное тестирование также возрастает.

Подготовка плана окончательного интеграционного тестирования

Подготовка подробного плана интеграционного тестирования должна охватывать все процессы и компоненты, в том числе:

• бизнес-процессы

• отчеты

• интерфейсы

• конвертацию данных

• усовершенствования

• принтеры и факсы.

Рамки такого тестирования определяются в соответствии с проектированием бизнес-процессов и областей бизнеса, заложенным на этапе концептуального планирования. План тестирования подтверждает отношения зависимости между бизнес-процессами и гарантирует проверку всего Концептуального плана предприятия. В этом случае в методологии ASAP также предусмотрены стандартные процедуры тестирования для минимизации затрат времени на эту задачу.

Транспортировка всех объектов в QA и «заморозка» системы

«Заморозка» системы подразумевает полную неизменность конфигурации и настроек системы до окончательного завершения полного цикла интеграционного тестирования, в том числе:

• параметров конфигурации

• настроек клиента

• данных приложений

• объектов Хранилища.

Проведение окончательного интеграционного тестирования

Окончательное интеграционное тестирование проводится на основе плана интеграционного тестирования, что подразумевает стандартные стадии: введение начальных параметров настройки, выполнение сценариев тестирования, запись полученных результатов и их сравнение с ожидавшимися результатами, оценка результатов, документирование и разрешение проблем, и, наконец, окончание тестирования. Интеграционное тестирование проводится теми сотрудниками, в чьи будущие обязанности входит работа с тестируемыми процессами, а также ключевыми пользователями.

Нельзя недооценивать важность интеграционного тестирования, ведь SAP — глубоко интегрированная система, и внесенные в различные модули изменения и настройки могут стать весьма запутанными, вследствие чего изменения в одной области системы могут привести к неожиданным результатам в других областях. Поэтому интеграционное тестирование должно быть тщательным, и охватывать все возможные сценарии работы бизнес-процессов.

Получение одобрения результатов тестирования на интеграцию и окончательное оформление системы

На этом этапе необходимо решить все нерешенные вопросы, связанные с окончательным тестированием системы на интеграцию, чтобы еще до запуска убедиться в том, что система с данной конфигурацией полностью отвечает требованиям компании.

Эта задача состоит в определении необходимых различным пользователям курсов обучения, которые будут проводиться перед запуском системы.

Создание плана документации для конечных пользователей

Создание такого плана требует выполнения следующих задач:

• идентификация конечных пользователей и определение с помощью матрицы Job Role необходимого каждому отдельному пользователю объема обучения

• определение требований к пользовательской документации.

• распределение ответственности за подготовку материалов и составление графика.

Все эти действия выполняются на основе плана документации, подготовленного на этапе концептуального планирования.

Компиляция документации для конечных пользователей

Для облегчения этой задачи в SAP предусмотрены шаблоны процедур для конечных пользователей, которые подготавливаются на основе более шестисот заранее стандартных ВРР (см. раздел «Подготовка плана обучения пользователей и пользовательской документации»).

Подготовка плана обучения конечных пользователей

Обучение конечных пользователей имеет огромное значение для успешного запуска системы, причем деятельность по подготовке обучения в первую очередь связана с созданием пользовательской документации, для чего необходимо выполнить следующие задачи:

• идентифицировать методику обучения и необходимые материалы

• распределить ответственность и утвердить график составления обучающих материалов

• распределить ответственность и утвердить график составления материалов для инструкторов, которые будут проводить обучение

• распределить ответственность и утвердить график проведения обучения

• организовать оповещение конечных пользователей об обучении и их регистрация.

Обучение в зависимости будущих обязанностей пользователя можно организовать, используя Информационную базу данных (Information Database, InfoDB), в которой содержится список курсов и соответствующие роли пользователей системы.

Подготовка материалов для инструкторов, которые будут проводить обучение конечных пользователей

Подготовка материалов для обучения включает в себя создание обучающих слайдов, распечатку экранов, подготовку упражнений и буклетов и т. д.

Подготовка обучающего материала для конечных пользователей

Для конечных пользователей необходимо подготовить полный комплект дополнительных материалов, подсказок, сборников часто задаваемых вопросов и т. д.

Компания SAP рекомендует следующий список контрольных вопросов для окончательной проверки итогов этапа реализации:

• Убедитесь, что прошли все намеченные собрания по статусу проекта и совещания управляющего комитета.

• Убедитесь, что полностью составлен план перехода на новую систему.

• Убедитесь, что сформированы все необходимые команды, или этот процесс намечен на ближайшее будущее.

• Убедитесь, что команда проекта получила адекватное обучение.

• Убедитесь, что разработаны планы тестирования системы.

• Убедитесь в правильности конфигурации глобальных параметров, организационной структуры и рамок базовой конфигурации.

• Проверьте подтверждение и официальное одобрение базовой конфигурации.

• Подтвердите создание системы обеспечения качества (QA).

• Подтвердите создание рабочей системы.

• Подтвердите рамки окончательной конфигурации и получите официальное одобрение.

• Убедитесь в правильности протестированных программ конвертации, интерфейсов приложений, усовершенствований, отчетов и т. д.

• Подтвердите создание авторизации и получите официальное одобрение проектирования авторизации.

• Подтвердите создание управления архивированием

• Подтвердите окончательное создание системы и ее интеграцию по результатам интеграционного тестирования.

• Убедитесь в создании пользовательской документации и обучающих материалов

• Проконтролируйте подготовку к обучению пользователей.

Эта качественная проверка подтверждает, что окончательная конфигурация системы SAP R/3 полностью отвечает зафиксированным в Концептуальном плане требованиям компании.

Эта задача подразумевает получение официального одобрения результатов данного этапа проекта и переход к следующему этапу. Это также означает окончание третьей фазы методологии ASAP и этапа разработки и тестирования в рамках проекта SAP.

Цель управления проектом на этом этапе мало отличается от остальных этапов и состоит в том, чтобы обеспечивать проекту направленное и поступательное движение, координировать усилия по выполнению расписания проекта в масштабе всей компании. Также необходимо поддерживать мотивацию среди сотрудников компании, особенно среди будущих пользователей системы, которые играют решающую роль в момент перехода на установленную систему, и особенно на этапах, следующих за внедрением SAP.

Задача этого этапа — анализ потенциальных рисков, которые могут поставить под сомнение достижение поставленных при запуске проекта целей. Обзор этапа окончательной подготовки охватывает следующие вопросы:

• Управление проектом

• Техническое управление проектом

• IТ-инфраструктура

• Процесс управления изменениями

• Приверженность персонала своему делу.

Этот обзор дает оценку различных рисков и является движущей силой для различных мер, направленных на завершение проекта в предусмотренные сроки — таких, как процессы организационных изменений, основанные на оценке специфических рисков как на уровне команды проекта, так и на уровне всей организации в целом.

Эта задача обеспечивает координацию и интеграцию статусов различных команд проекта, в том числе:

• Команды, занимающейся бизнес-процессами

• Команды по управлению изменениями

• Технической команды.

Такие собрания обеспечивают сопоставление и упорядочение информации с целью определения общего статуса проекта и принятия решений по координации деятельности в случае выявления разного рода расхождений или даже стратегического замедления реализации всего проекта. Менеджеры проекта принимают решения, необходимые для выполнения расписания проекта, например, о выделении дополнительных ресурсов для нужд проекта или дополнительных средств для своевременного обучения конечных пользователей.

Собрания Управляющего комитета проводятся для постоянного обновления общего статуса проекта и принятия решений по проблемам, которые невозможно решить на уровне управления проектом. На таких собраниях менеджеры проекта должны представить следующие данные:

• Статус проекта

• План следующего этапа проекта

• Сопоставление запланированных сроков и их фактическое выполнение

• Сопоставление запланированных затрат и фактические затраты

• Степень завершенности проекта в процентном выражении

• Текущая деятельность, а также предстоящие мероприятия

• Негативные и позитивные тенденции

• Принятие соответствующих мер

• Оставшиеся поставки

• Сроки и этапы

• Вопросы, требующие немедленного решения

• Необходимость изменений в выделении ресурсов для наиболее важных мероприятий в рамках проекта.

Такие действия укрепляют сплоченность и мотивацию рабочих команд и увеличивают их трудовой потенциал, способность координировать действия, как среди членов команды, так и между разными рабочими командами в стремлении к успешному завершению проекта внедрения SAP.

Как видно из обзора предыдущих этапов проекта, эта задача включает в себя совокупность процессов, которые помогают команде управления организационными изменениями диагностировать и управлять вопросами таких изменений с целью оптимизации организационных процессов и поддержания движущей силы методологии ASAP на должном уровне вплоть до успешного завершения проекта.

Также сюда относятся самые различные процессы — такие, как оценка рисков, стратегия спонсорства, развитие навыков персонала, передача знаний и процесс организационной оптимизации, которые были инициированы на этапе концептуального планирования. Эти усилия приобретают еще большее значение, потому что именно на этом этапе происходит масштабирование внедрения SAP относительно предприятия в целом. Эта задача обеспечивает развитие навыков персонала, передачу знаний и обмен информацией с целью увеличения количества участвующих в проекте сотрудников, как на последних этапах проекта, так и после завершения внедрения SAP.

Эта задача состоит в том, чтобы обеспечить адекватное обучение всех конечных пользователей перед запуском системы, причем обучение должно проходить в соответствии с планом и расписанием проекта, подготовленными на этапе реализации проекта.

Основой такого плана служит список бизнес-процессов (BPML), составленный на этапе концептуального планирования, а также матрица должностных ролей, подготовленная на этапе реализации проекта. Как следствие, план обучения обеспечивает адекватный охват всех типов пользователей, и в то же время позволяет избежать излишнего обучения, в котором те или иные пользователи не нуждаются. Излишнее обучение — это не только растрата ресурсов, но и потеря драгоценного времени, которое на данном этапе проекта может быть в дефиците. Классифицировать типы конечных пользователей можно таким образом:

• Пользователи транзакций

• Пользователи анализа и запросов

• Пользователи информации.

Ниже приведены различные задачи, необходимые для успешного обучения конечных пользователей.

Подготовка к обучению конечных пользователей

Эта задача включает в себя приведение в порядок логистики и среды SAP перед обучением, в том числе транспортировку и фиксацию клиента обучения, а также загрузку специфических для компании данных в среду обучения.

Проведение обучения конечных пользователей

После обучения конечных пользователей они должны уметь уверенно выполнять свои повседневные задачи в среде SAP.

Обзор и оценка навыков после проведения обучения

Эта задача подразумевает оценку эффективности проведенного обучения и получения конечными пользователями навыков, необходимых для выполнения своих повседневных задач. Инициативные предложения и обратная связь должны использоваться для соответствующей модификации будущих циклов обучения. Кроме того, в зависимости от результатов такой оценки может быть принято решение о проведении дополнительных курсов обучения для всех конечных пользователей с целью углубления знакомства с системой SAP; причем такие курсы могут быть направлены на специфические области работы с системой — например, составление отчетности или работу с запросами.

Управление системой подразумевает подготовку технической инфраструктуры и организацию системного администрирования для рабочей системы SAP.

Организация системного администрирования подразумевает установку Центральной управляющей системы (CCMS). Верно подобранная инфраструктура в сочетании с подходящими установками администрирования значительно улучшает характеристики работы системы и увеличивает ее прозрачность.

Конфигурация CCMS для рабочей среды

Конфигурация CCMS для рабочей и завершающей фазы проекта необходима для воплощения стратегии, определенной на этапе реализации. Как указывалось в главе 7, конфигурация CCMS включает в себя:

• Конфигурацию групп регистрации (logon), необходимую для планирования и балансировки требований пользователей по оперативности реакции системы одновременно с обеспечением достаточной оперативности для высокоприоритетных транзакций.

• Конфигурацию профилей системы, которая необходима для установки подходящих режимов работы.

• Конфигурацию режимов работы, которые необходимы для предоставления достаточных ресурсов в тот или иной период для определенной операции; например, предоставление дополнительных диалоговых или фоновых процессов.

• Конфигурацию системы составления графиков работ, которая необходима для корректного выполнения фоновых задач в подходящие сроки, независимо от текущих задач.

• Конфигурацию предупреждающего мониторинга, что подразумевает установку предельно допустимых значений для различных устройств мониторинга в различных областях системы.

• Конфигурацию графика резервного копирования для периодического и постоянного создания резервных копий данных.

Конфигурация администрирования печати и спулинга в рабочей среде

Эта задача включает создание процедур и правил, необходимых для эффективного администрирования процессов спулинга и печати. Составление расписаний задач по распечатыванию не должно противоречить ни решениям, ни соответствующей инфраструктуре, определенной на этапе реализации проекта. Логика инфраструктуры печати рассматривалась в разделе «Администрирование печати» в главе 11.

Обучение персонала системному администрированию

Члены технической команды проекта внедрения могут и не быть системными администраторами рабочей среды. Поэтому, совершенно необходимо объяснить политику, процедуры и правила системного администрирования будущим системным администраторам. Обучение системному администрированию должно охватывать следующие аспекты:

• Знакомство с системой SAP

• Навигация системы

• Мониторинг системы

• Резервное копирование системы

• Управление принтерами и печатью.

Проведение системных тестов необходимо для того, чтобы убедиться в правильности конфигурации системной инфраструктуры и процедур администрирования, предназначенных для управления системой.

Тестирование администрирования системы

Тестирование администрирования системы нацелено на обеспечение корректности и полноты административных процессов и процедур, перечисленных в SAP Operations Manual. Такое тестирование обеспечивает полное соответствие данного руководства реально выполняемым должностным обязанностям (областями ответственности) системных администраторов.

Проведение объемного тестирования

Такое тестирование проводится, чтобы убедиться в способности системы в текущей конфигурации успешно функционировать с полным объемом транзакций и данных, ожидаемых в реальной работе. Это тестирование также позволяет обнаружить возможности для дополнительного улучшения рабочих характеристик системы.

Проведение нагрузочного тестирования

Такое тестирование проводится, чтобы убедиться в способности системы в текущей конфигурации успешно работать с полным объемом бизнес-операций, обработок транзакций, бухгалтерских проводок и печати, с которыми ей придется справляться в реальных условиях. Это тестирование также позволяет обнаружить возможности для дополнительного улучшения рабочих характеристик системы.

Тестирование печати и факсимильной связи

Это тестирование позволяет проверить правильную работу всех устройств печати и факсимильной связи, а также эффективность настроек печати и правильность всех заданных типов и объемов печати.

Тестирование процедур резервного копирования и восстановления данных

Позволяет проверить правильную работу всех процедур создания резервной базы данных и восстановления данных с помощью резервных копий, которые во многом зависят от особенностей самой базы данных а также поддерживающих ее операционных систем и инфраструктуры. Это тестирование позволяет проверить скорость восстановления данных и убедиться в минимальности потерь рабочего времени в условиях различных сценариев повреждения и утраты данных.

Тестирование восстановления данных после серьезных сбоев

Позволяет убедиться в правильности процессов и процедур восстановления данных, а также в полноте восстановления данных, причем такое тестирование должно охватывать все компоненты технической инфраструктуры, в том числе сети, диски — хранилища информации, базы данных, авторизации пользователей и т. д. Кроме того, эти тесты должны продемонстрировать минимум затрат времени на восстановление данных, адекватность соглашений с поставщиком о сервисном обслуживании и дополнительных услугах, эффективность путей обмена информацией и промежуточных процедур, а также процедур перезагрузки системы и окончательного возврата к нормальной работе после сбоя.

Проверка готовности системы к запуску

Этот тест осуществляет проверку конфигурации и характеристик работы системы перед фактическим запуском и переходом к этапу обслуживания системы. Услуга SAP GoingLive проверяет следующие элементы будущей рабочей системы:

• Сервер

• Базы данных

• Приложения

• Системную нагрузку

• Конфигурации.

В рамках этой услуги SAP позволяет получить отчет о результатах проверки и список рекомендуемых улучшений характеристик работы системы.

Эта задача подразумевает самую детальную проработку и утверждение плана перехода на новую систему и последующей поддержки ее работы, который был создан на этапе реализации.

Подготовка подробного плана перехода нацелена на проверку готовности системы и всей компании в целом к запуску системы SAP. Как уже говорилось ранее, при внедрении SAP невозможен переходный этап, когда старая и новая системы работают параллельно. Поэтому очень важно убедиться не только в том, что администрирование системы и сама система SAP полностью готовы к запуску, но и в готовности всех данных к своевременной конвертации согласно графику.

Составление списка контрольных вопросов для перехода

Эта задача подразумевает составление подробного списка контрольных вопросов по всем процессам и процедурам, которые связаны с конвертацией данных. При этом следует охватить следующие области:

• Данные, которые необходимо конвертировать

• Спецификации конвертации данных

• Программы конвертации

• Результаты тестирования программ конвертации

• Результаты тестирования программ конвертации на уровне характеристик работы и на уровне конвертированных данных.

• Процессы и процедуры ручной (неавтоматической) конвертации данных.

Для успешного выполнения своей функции, список контрольных вопросов должен также содержать исчерпывающий перечень всех внесенных в рабочую систему изменений, в том числе:

• Конфигурации различных функциональных модулей, например Финансы (FI), Контроллинг (СО), Продажа и дистрибуция (SD), Планирование производства (РР), Управление материалами (ММ) и т. д.

• Все новые таблицы, экраны, программы АВАР и SAPScript

• Профили пользователей.

Определение готовности системы к запуску

Для определения готовности системы к запуску в ASAP предусмотрен список контрольных вопросов для подтверждения того, что:

• CCMS сконфигурирован для рабочей среды.

• Операционная система и базы данных отлажены, обеспечена их безопасность.

• Все таблицы, программы, конфигурации и данные успешно конвертированы.

• Базы данных готовы к работе.

• Сеть готова к работе.

• Установлена система безопасности.

• Принтеры сконфигурированы для работы.

• Создано расписание фоновых задач.

• Стратегия резервного копирования и восстановления баз данных готова к работе.

• План восстановления данных после серьезных сбоев отлажен и готов к работе.

Одобрение перехода на новую систему

Одобрение перехода на новую систему необходимо при создании отчета о готовности системы к пуску, а также получение одобрения от старших менеджеров для инициации процесса перехода на новую систему.

На этом этапе должен быть подробно проработан и окончательно утвержден план поддержки рабочей системы, составленный на этапе реализации как совокупность процессов и процедур, а также распределена ответственность среди сотрудников Справочной службы.

Определение ресурсов для справочной службы

В основном эта задача подразумевает создание процессов обмена информацией, в том числе для следующих целей:

• Регистрация проблем и отчетность по ним

• Передача и обработка сообщений о проблемах, нахождение нужного решения

• Передача сообщений о нерешаемых проблемах для рассмотрения на более высоком уровне

• Передача сообщений о нерешаемых проблемах для рассмотрения в компанию SAP

• Информирование о решениях проблем

• Демонстрация найденных решений.

Учреждение справочной системы

Эта задача подразумевает создание и организацию работы справочной системы (Help Desk), в том числе:

• Создание инфраструктуры офиса

• Создание технической инфраструктуры

• Назначение персонала и выделение необходимых ресурсов

• Обучение персонала справочной службы

• Создание пользователей OSS для соответствующего персонала службы.

Организация ресурсов и персонала для справочной системы

Эта задача подразумевает назначение и обучение персонала справочной системы, а также определение и распределение ответственности. Информацию об обязанностях сотрудников справочной системы необходимо довести до сведения всех конечных пользователей организации.

Долгосрочная стратегия поддержки рабочей системы SAP необходима для решения следующих вопросов:

• Системные изменения после внедрения

• Внедрение новых версий и модернизация

• Расширение рамок системы вследствие роста бизнеса

• Обучение новых сотрудников, необходимое из-за естественного обновления кадров.

Переход на новую рабочую систему включает в себя выполнение следующих задач:

1. Транспортировка всех установок настройки и объектов хранилища в рабочую среду.

2. Проведение конвертации всех основных данных и данных по транзакциям.

3. Ручное введение тех унаследованных данных, которые из-за своей сложной структуры трудно поддаются конвертации или достаточно малы по объему.

Эта задача подразумевает принятие окончательного решения о готовности системы и ее запуске. Решение принимается после выполнения следующих требовании:

• Окончательного составления документации для конечных пользователей.

• Окончания обучения конечных пользователей.

• Окончания установки системного администрирования R/3.

• Окончания отладки технической инфраструктуры.

• Окончания конвертации установок настройки, основных данных и данных по транзакциям.

• Утверждения плана перехода на новую систему и ее дальнейшей поддержки.

Система запускается после того, как:

• Получено одобрение менеджеров

• Все пользователи системы готовы

• Система безопасности полностью отлажена и функционирует нормально.

Проверка качества — это завершение стадии окончательной подготовки. Для этого компания SAP рекомендует следующий список контрольных вопросов:

1. Убедитесь, что были проведены собрания организационного комитета и встречи команд по статусу проекта.

2. Убедитесь, что формирование команды, которая будет работать с SAP, уже проведено или намечено на ближайшее будущее.

3. Убедитесь, что все пользователи прошли адекватное обучение.

4. Утвердите персонал и организацию администрирования системы.

5. Убедитесь, что тестирование системы R/3 принесло ожидаемые результаты.

6. Пересмотрите план поддержки рабочей системы и убедитесь в его правильности и полноте.

7. Проконтролируйте процесс перехода на новую систему.

Эта задача подразумевает получение официального одобрения результатов этого этапа проекта и переход к следующему этапу. Это также означает окончание четвертой фазы по методологии ASAP.

Цель этой деятельности — обеспечение поддержки пользователей SAP и поддержание оптимальных характеристик работы системы, что является крайне важным, особенно в первые недели после запуска.

Цель этой деятельности — анализ потенциальных рисков, которые могут вызвать проблемы в будущем. Обзор должен охватывать следующие вопросы:

• Управление проектом

• Техническое управление проектом

• IT-инфраструктура

• Процесс управления изменениями

• Приверженность персонала своему делу.

В обзоре рассматриваются различные риски, ставящие под вопрос успешное завершение проекта.

Система запускается и начинают выполнять все соответствующие функции.

Цель этой деятельности — поддержка пользователей системы SAP. План работы поддержки составляется на стадии окончательной подготовки к запуску, причем работа Справочной системы также отслеживается и отлаживается, в зависимости от результатов обратной связи с пользователями и анализа задокументированных проблем и вариантов их решения. Также проводится обучение ключевых пользователей работе с онлайновой сервисной системой SAP (Online Support System, OSS).

Эта задача нацелена на получение подтверждения того, что на реальных данных система SAP работает корректно. Одобряется правильность внесенных настроек и основных данных. Эта задача подразумевает следующее:

• Ежедневное отслеживание транзакций

• Решение спорных проблем, подтверждение того, что все проблемы разрешены эффективно с применением всех необходимых корректирующих мер.

Корректирующие меры могут включать следующие действия:

• Изменение бизнес-процесса

• Модификация кода (в среде АВАР)

• Изменение конфигурации

• Повторные обучающие курсы для персонала

• Дополнительные обучающие курсы по другим модулям и функциональным возможностям.

Конечной целью этой задачи является получение официального одобрения по рабочей среде системы, то есть официального подтверждения успешного завершения проекта.

Эта задача подразумевает официальное закрытие проекта, а также рассмотрение и окончательное решение любых оставшихся вопросов.

Эта задача означает начало оценки преимуществ, которые дает предприятию внедрение SAP:

1. Обзор и решение всех оставшихся вопросов. Все позиции базы данных по проблемам идентифицируются, рассматриваются, решаются и закрываются.

2. Обзор бизнес-преимуществ. Результаты внедрения SAP сравниваются с целями и задачами, намеченными в начале реализации проекта. Это также подразумевает создание процедуры оценки полученных преимуществ, которая может использоваться в дальнейшем на постоянной основе.

3. Оценка процесса передачи знаний персоналу. Это подразумевает рассмотрение и документирование ключевых вопросов и выводов по результатам проекта с использованием созданной в процессе реализации проекта базы данных «Вопросы и Ответы» (Q&Adb). Эта информация имеет особую ценность, так как она максимально объективно отображает внутренние процессы, протекающие в недрах организации или предприятия.

4. Завершение процесса управления организационными изменениями. Ключевые преимущества, полученные в результате управления организационными изменениями, подвергаются тщательной оценке, любые оставшиеся нерешенными вопросы рассматриваются и закрываются.

Эта задача подразумевает официальное одобрение результатов проекта и закрытие проекта.

Первоначально концепцию «путей к успеху» изобрел Кристофер Александер во второй половине 70-х годов применительно к архитектуре. Эта концепция представляет собой совокупность часто используемых на практике решений, которые неизменно приводят к максимально успешному результату.

На этой стадии логично суммировать опыт, полученный от предыдущих проектов внедрения SAP в форме списка контрольных вопросов, к которому в дальнейшем следует обращаться за информацией. Необходимо отметить, что концепция «путей к успеху» в наибольшей степени применима к внедрению SAP на средних и малых предприятиях с годовым оборотом в пределах 50 млн. — 1 млрд. долларов. Ниже приведен список путей к успеху для проектов внедрения SAP:

• Залог успеха 1: Прямое участие менеджеров высшего звена на всех стадиях реализации проекта.

• Залог успеха 2: Ясная, стройная организационная структура и эффективное управление проектом

• Залог успеха 3: Достаточная степень прозрачности и простота обмена информацией на всех участках проекта

• Залог успеха 4: План управления изменениями, охватывающий всю организацию.

• Залог успеха 5: Выделение достаточных бюджетных и других ресурсов для проекта

• Залог успеха 6: Делегирование опытных, успешных сотрудников и ключевых менеджеров для участия в проекте, но ни в коем случае не тех сотрудников, которые не играют важной роли в деятельности того или иного подразделения организации

• Залог успеха 7: Движущей силой проекта должны являться все подразделения организации, а не только отдел информационных технологий

• Залог успеха 8: Внедрение системы на пилотном участке с последующим разворачиванием проекта на остальные участки

• Залог успеха 9: Внедрение по принципу «Большого взрыва» как минимум, основных модулей

• Залог успеха 10: Четкость рамок проекта и предотвращение расползания рамок проекта в процессе работы

• Залог успеха 11: Полноценное обучение всех участников проекта SAP

• Залог успеха 12: Стандартизация бизнес-процессов и рекомендуемое внедрение стандартной функциональности SAP

• Залог успех 13: Использование внешних консультантов только для обучения собственной команды проекта, а не для выполнения всего проекта в целом

• Залог успеха 14: Планирование, мониторинг и управление расписанием проекта на всем протяжении проекта

• Залог успеха 15: Создание интерфейсов для взаимодействия с существующими (унаследованными) системами в низкоприоритетных или узкоспециальных областях функциональности

• Залог успеха 16: Готовая инфраструктура поддержки системы согласно расписанию проекта

• Залог успеха 17: Поддержка и управление инфраструктурой в масштабе всего проекта, доступная всем участникам проекта

• Залог успеха 18: Обучение всех конечных пользователей незадолго до фактического запуска системы.

Один из важнейших моментов внедрения — развертывание системы 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 в коллективе компании.

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.

Как уже упоминалось в разделе «Знание как новый капитал» главы 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.

Бизнес-структура 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 автоматически использует доступные в системе возможности для организации защиты, управления передачей, целостности данных, масштабируемости, управления сеансом и так далее.

Система 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.

Организация определяется через совокупность совместного сотрудничества. Все отношения сотрудничества — это отношения между партнерами; таким образом, компания представляет собой совокупность отношений сотрудничества между партнерами. Корпорация вовлечена в сеть взаимно и динамически установленных взаимодействий независимых партнеров. Конкурентоспособность организации является результатом всех этих отношений и сотрудничеств. Одним из первых сторонников того, что называется «stakeholder theory» является Р.Е. Фриман, написавший книгу «Стратегии управления: подход к организации совместной деятельности». К партнерам причисляются инвесторы, владельцы, менеджеры, политические группы, клиенты, общество, сотрудники, профсоюзы, поставщики, партнеры, правительство, конкуренты и т. д.

Существует два класса партнеров: первичные и вторичные. Первичные — это те, на чьи интересы успехи и неудачи компании влияют непосредственно. Это инвесторы, финансовые учреждения, клиенты, поставщики, сотрудники и т. п. На вторичных партнеров, типа СМИ, правительства и органов государственного регулирования, финансовое состояние компании влияет только косвенно. Но сами они несомненно оказывают влияние на работу компании. Иногда это влияние может не только превосходить влияние первичных партнеров, но даже иметь решающий характер для компании. Для предприятия в целом, важнейшими являются следующие партнеры:

• клиенты

• инвесторы

• поставщики

• менеджеры

• сотрудники.

Сотрудничество (кооперация) отражается в контрактах, которые могут варьироваться от внешних до внутренних. Эти контракты уточняют или указывают на то, что компания может ожидать от каждого партнера для достижения собственных целей, и что каждый участник процесса может получить в ответ от организации. Например, внешние контракты — это те, по которым клиент выплачивает заранее определенную сумму денег за право доступа к товарам и сервисам компании. По внутренним контрактам сотрудник получает продвижение по службе в зависимости от результатов своего труда и прогнозов, составленных в начале периода работы.

В зависимости от контракта, внешнего или внутреннего, каждый участник вкладывает капитал в будущий успех компании. Этот вклад может быть финансовым, организационным, интеллектуальным, социальным, относящимся к окружающей среде и т. д. Непрерывная вовлеченность в процесс, заинтересованность и приверженность участников совместной деятельности зависит от получения ими достойной прибыли на инвестированный капитал (Return Of Investment, ROI). Эта прибыль может быть разной для каждого из участников. Для клиентов она может выражаться в товарах, сервисах, услугах поддержки и усовершенствованиях в будущем. Для поставщиков — в гарантированных выгодных контрактах на поставку. Инвесторы могут получать ее в виде будущих дивидендов. Для менеджеров эта прибыль в гарантии подъема по служебной лестнице, а для сотрудников — в стабильности, профессиональном росте и развитии карьеры.

С точки зрения предприятия, основанном на сотрудничестве, очевидно, что один из партнеров не может обеспечивать себе достойную прибыль (ROI) за счет других участников. Например, нельзя безгранично увеличивать прибыль за счет снижения качества товара или обслуживания, произвольно уменьшив расценки поставщиков или сократив зарплату работникам. ROI для разных участников не должно быть противодействием друг другу, ведь выигрывая в одном, проигрываешь в другом. Вы уже видели серьезное доказательство этому в прошлом веке, когда качество и цена были ошибочно поставлены в оппозицию друг другу. Как показали 90-е, предприятие может добиться прекрасного качества по низкой цене.

Несмотря на то, что все компании стремятся дать прибыль всем своим партнерам по совместной деятельности, эти усилия не могут быть направлены на всех одновременно. Предприятие обычно не имеет возможности отслеживать информацию, необходимую для поддержания перекрестной функциональности по:

• совершенствованию деятельности, приносящей прибыль на определенных участках

• сокращению убыточной деятельности на тех же участках.

Достижение этих целей должно быть отслежено по всему предприятию по всем функциям и составляющим. Это необходимо потому, что прибыльность и убыточность локального уровня могут и не быть столь полезными для компании в целом. В настоящее время все уже признают, что производительность организации не может быть увеличена только путем увеличения производительности каждого составляющего ее подразделения или деятельности. Для общей результативности и эффективности подразделению подчас приходится выполнять действия, которые считаются убыточными на уровне подразделения. SAP R/3 предоставляет такую систему, которая создает, поддерживает, анализирует и предоставляет отчеты по параметрам, которые могут измерять уровни активности показателей производительности, доходов и затрат. Более того, SAP выявляет межфункциональные зависимости процессов, происходящих на всем предприятии.

Клиенты — это одна из самых важных ценностей компанией. Клиенты оценивают товары и сервисы не только с точки зрения использования, но также по конкурентоспособности их цены. Это, в свою очередь, ведет к другим сопутствующим критериям, которые, в конечном счете, приводят к приверженности клиентов к продукции компании. Клиенты обращают внимание на:

• Цену

• Качество

• Гибкость

• Практичность

• Разнообразие или богатство возможностей

• Способность к реагированию

• Надежность

• Стандартные интерфейсы и дополнительные системы

• Долговечность

• Возможность усовершенствования

• Поддержка пользователей

• Сервис

• Нововведения.

Некоторые из этих качеств, характеризующих продукт или сервис, могут противоречить друг другу; совокупность оценок может варьироваться в зависимости от продукта. Более того, по прошествии времени ценность конкретного продукта или близких продуктов может измениться. Как упоминалось в разделе «Подход к бизнес-процессам с точки зрения прибавления ценности» главы 6, оценки могут меняться под влиянием продуктов-конкурентов, изменений в технологии или при регулировании условий. В действительности, в отсутствии других причин, изменения критериев происходят просто из стремления к чему-то новому и потребности в новом опыте. Плюс к этому возникает проблема подвижности клиентуры, которая постоянно меняется, в зависимости от изменений в Критических определителях ценностей (Critical Value Determinants, CVDs).

Как правило, способом определения относительной важности определителей ценности являются опросы удовлетворенности клиентов с последующим анализом потенциальных клиентских ценностей. Таким образом вычисляются среднестатистические индексы удовлетворенности клиентов. Эти индексы могут различаться в зависимости от целей анализа клиентских ценностей.

Акционеры ожидают в будущем получить достойную прибыль в расчете на инвестированный капитал (ROI). Однако необходимо заметить, что большие прибыли, хотя и являются основным мотивом любого инвестирования, акционеры также ценят свой вклад в создание материальных ценностей и рабочих мест для общества, в котором они живут. Они получают огромное удовлетворение, делясь полученным богатством с обществом через сотрудников компании. Если компания показывает, что использует этот капитал разумно, ее стратегия жизнеспособна, она обеспечивает соответствующую норму прибыли и улучшит ее в будущем, акционеры продолжат удерживать свои материальные интересы в компании.

С точки зрения оценки эффективности, ставшей традиционной, инвесторы промышленных предприятий, вовлеченных в массовое производство, заинтересованы в: возврате по оборотному капиталу (Return-on-Capital-Employed, ROCE), прибыли на акцию (Earnings per Share, E/S), возврате по вкладам (Return on Assets, ROA) и т. п. с точки зрения полноты и качества учета следующей информации:

• Значимости

• Надежности

• Нейтралитетности

• Точности

• Проверяемости

• Сравнимости

• Непротиворечивости.

Однако, сосредоточение на эффективности — не очень надежный индикатор оценки компании. Она ориентирована на нынешние и прошлые оценки, но не приспособлена для работы с «кривыми» в будущем. Прибыль — это статическое понятие, в котором используется линейная аппроксимация, исходя из результатов последнего финансового года. В основе этого традиционного подхода лежит допущение, что оценку деятельности компании можно спрогнозировать, основываясь на отчетах о прибылях. Ошибочность этого предположения подтверждается тем фактом, что рыночные стоимости успешных компаний всегда более чем вдвое выше их балансовой стоимости.

С другой стороны, планирование денежных потоков рассматривает прибыль как функцию денежных потоков в ожидаемом будущем, что отражает стоимость компании в долгосрочном плане с учетом сопутствующих рисков. В отличие от расчетного подхода, в движении денежных потоков выявлено существование строгой зависимости между рыночной ценой одной акции и прогнозируемой стоимостью на акцию, основанной на прогнозах движения денежных средств.

Инвесторы заинтересованы в:

• Увеличении добавочных денежных потоков в будущем

• Гарантированных дивидендах в наличных

• Росте стоимости акций.

Для компаний со сравнительно небольшим капиталом оценка эффективности и движение денежных потоков могут дать близкие результаты, а фактические выплаты и результаты инвентаризации дадут две сильно различающиеся картины.

По традиции, при обсуждении участников совместной деятельности, ведущих менеджеров причисляют к владельцам/инвесторам, что не совсем верно. Менеджеры, в задачи которых входит управление ростом и прибыльностью компании, имеют свои взгляды на ценности, отличающиеся от тех, которые важны владельцам/инвесторам.

Интерес для ведущих менеджеров представляют:

• Свобода высказывать свое видение перспектив развития организации и претворять их в жизнь

• Самостоятельность в фокусировке на выбранном наборе стратегий и тактик.

• Самостоятельность в формировании команды, которая доверяет такому видению и подходу.

• Возможность определять критерии эффективности функционирования предприятия в целом, а также отдельных бизнесов и менеджеров компании.

• Полномочия для распределения и использования системы и ресурсы для выполнения планов.

• Полномочия для создания и внедрения системы оценки, составление отчетов по эффективности функционирования различных видов деятельности и уровней организации за определенные периоды времени или в зависимости от определенных характеристик.

• Свобода создания корпоративной политики и процедур, соответствующих видению перспектив развития компании.

• Свобода проводить научно-исследовательские и опытно-конструкторские работы по вопросам производства и управления, которые, по их мнению, будут важны в будущем.

• Оплата, соизмеримая с рисками и намеченными целями.

С увеличением темпа и оборотов коммерческой деятельности свобода действий управляющего директора и других ведущих руководителей постоянно уменьшается. Допустимые отклонения за невыполнение квот или несоблюдение времени выполнения корректирующих стратегий становятся все меньше. В подобных обстоятельствах, топ-менеджеры осознают ценность, которую они приносят предприятию и отдачу, которую получают. Величайшая ирония нашего времени состоит в том, что, несмотря на растущую власть и престиж, управляющего директора и членов его команды чаще других увольняют из-за отсутствия результатов.

Сегодня все большее признание получает вклад поставщиков в ценность, которую они вносят не только в окончательную продукцию предприятия, но и в его рентабельность. Поставщики играют ведущую роль в улучшении производительности всей организации по отношению к качеству, входным расходам, издержкам, способности реагирования на рыночные изменения и т. д. Теперь их все чаще рассматривают как партнеров, а не традиционных противников, из которых требуется выбить низкие цены.

Поставщики, в свою очередь, заинтересованы в следующем:

• Постоянство заказов

• Оптимальное время выполнения нового заказа

• Оперативное сообщение о доставках, отказах, возвратах и т. п. в единицах количества и точности информации (таких как номера накладных на поставку и номера партий)

• Систематическая проверка (подтверждение) счетов-фактур

• Своевременная оплата по проверенным и принятым счетам-фактурам

• Интерфейсы с корпоративной системой предприятия, подобной SAP

• Доступ к изменениям в графике производства

• Доступ к изменениям в позициях наличных запасов в соответствии с заказами на производство и т. п.

• Участие в разработке новых продуктов, моделей, технологий и процессов производства.

Как уже упоминалось в разделе «Виртуальная организация» первой главы, только такие высокоорганизованные ERP-системы как SAP R/3 могут обеспечить надежную основу для поддержания виртуальной цепочки, охватывающей все аспекты сотрудничества с поставщиками.

Как описано в разделе «Менеджмент через сотрудничество» первой главы, динамические изменения рынка и всеобщая конкуренция, с которыми сталкиваются компании, создали более гибкую модель организации. Такие организации состоят из сотрудников с мульти-квалификацией и расширенными обязанностями. Ни одна организация не сможет обеспечить высокий уровень накопления ценности в течение длительного периода без соответствующего увеличения ценности для своих сотрудников.

Сотрудники ценят следующие факторы:

• Возможности участия и внесения личного вклада в деятельность предприятия

• Достойная оплата труда

• Возможности получения опыта, развития навыков и управления сложными задачами

• Доступ ко всей необходимой информации и ресурсам для принятия решений и качественного выполнения своих обязанностей

• Возможности признания заслуг и вознаграждения

• Возможности продвижения по службе

• Возможности обучения.

Прямой и прозрачный доступ к необходимой информации в режиме реального времени, который предоставляет SAP, позволяет членам организации принимать необходимые своевременные решения и обеспечивать процветание компании.

Во многих случаях, значимость сотрудников во многом схожа со значимостью клиентов. Как и у клиентов, эффективность оценки сотрудников определяется при проведении регулярных опросов удовлетворенности.

Крайне важно определить корректные меры для оценки эффективности компании, ее способности в достижении намеченных целей. Система SAP в значительной степени способствует мониторингу и управлению мерами по улучшению эффективности (Measures of performances, МОР). Такие черты SAP, как доступность оперативных данных в реальном времени и их интегрированность делает SAP идеальной средой создания, отслеживания и управления ценностью предприятия. SAP является надежной платформой для малых и средних предприятий, стремящихся к соответствию постоянно меняющимся условиям рынка, причем показатели успеха могут быть самыми различными:

• Улучшение отношений с потребителями, более эффективное управление этими отношениями

• Снижение затрат времени

• Улучшение качества

• Рост продаж

• Рост прибылей

• Снижение затрат времени на разработку новых продуктов

• Сокращение потребности в рабочей силе для рутинной, повседневной деятельности

• Укрепление позиций компании на рынке.

Процесс мониторинга характеристик эффективности во многом ориентирован на выявленные определители ценности компании, которые имеют различную приоритетность и поддаются изменению в зависимости от деятельности компании. Вполне вероятны добавления и удаления характеристик (и соответствующих мер), в зависимости от ситуации на рынке или в зависимости от эффекта или направленности мер, принятых ранее.

В приведенных ниже списках перечисляются факторы эффективности компании, которые необходимо учитывать при оценке процессов в SAP.

Факторы в области продаж и дистрибуции:

• Количество новых клиентов

• Количество бывших клиентов

• Количество клиентов, которые стали постоянными клиентами компании

• Количество и тип повторных заказов

• Затраты времени от приема заказа до получения заказа клиентом

• Количество нестандартных заказов

• Количество ошибок и сбоев в выполненных заказах

• Невыполненные заказы в процентном отношении к общему количеству заказов

• Вовремя выполненные заказы в процентном отношении к общему количеству заказов.

Качественные факторы успешной работы компании:

• Количество случаев брака и их типы

• Затраты времени на переделку и их типы

• Количество и типы жалоб клиентов

• Время, потребовавшееся для первоначального ответа на жалобу

• Время, потребовавшееся для окончательного удовлетворения жалобы

• Среднее количество контактов с клиентом в случае возникновения проблем, типы таких обращений.

Факторы успеха в области финансов:

• Возврат по оборотному капиталу (Return on capital employed, ROCE)

• Прибыль в расчете на акцию

• Средневзвешенные затраты на капитал (Weighted average cost of capital, WACC)

• Отдача от основных средств

• Динамика роста оборота компании

• Производственная прибыль

• Валовая прибыль

• Движение денежной наличности

• Количество продаж из расчета на одного работника

• Прибавление ценности из расчета на одного работника

• Затраты энергии из расчета на одну единицу произведенного продукта.

Факторы успеха в области бухгалтерии:

• Количество дней, требующееся для закрытия книг в конце месяца или квартала

• Количество ошибок из расчета на единицу учета

• Количество расхождений в балансе.

Факторы успеха в области работы с поставщиками и закупщиками:

• Затраты времени, необходимые поставщикам для выполнения заказа

• Количество сертифицированных поставщиков относительно общего количества поставщиков

• Количество запоздалых поставок

• Количество долгосрочных соглашений с поставщиками

• Количество и процентное отношение заказов, обрабатывающихся системой электронного обмена данными (Electronic data interchange, EDI).

Факторы успеха в области управления материалами:

• Модернизация

• Время между заказом и фактической поставкой.

Факторы успеха в области производства:

• Время, необходимое для организации производства в процентном отношении к общей длительности цикла производства

• Затраты на текущее обслуживание как процент от объема продаж

• Средняя частота сбоев, типы сбоев

• Средние затраты времени на ремонт.

Факторы успеха в инженерно-технической области:

• Затраты времени на разработку и дизайн новой продукции

• Затраты времени от появления концепции до запуска серийного производства

• Количество случаев, когда приходится устранять ошибки инженеров.

Факторы успеха в области управления персоналом:

• Количество и причины прогулов

• Текучесть кадров, её причины

• Расходы на обучение в процентном отношении к доходам компании.

В условиях сложных взаимоотношений зависимости и влияния факторов друг на друга, выбор правильных корректирующих мер становится весьма трудной задачей — возникает потребность в структуре, которая объединяла бы все эти меры, и позволяла бы их рассматривать как единый комплекс, где ни одно мероприятие не противоречит другому. Более того, необходимо найти баланс между финансовыми и нефинансовыми мерами — этому вопросу посвящен раздел «Сбалансированная карта оценок».

Чтобы оправдать ожидания акционеров и повысить ценность компании, менеджеры компании должны не только уметь сформулировать стратегию, но и претворить ее в жизнь. Управление в стоимостном отношении (Value-based management, VBM) гарантирует внедрение корпоративной стратегии путем установления прямых связей между стратегией, финансами и операциями внутри компании. Когда распределение ресурсов и управление компанией напрямую зависят от стратегических целей, процесс принятия оперативных решений также направлен на достижение поставленных стратегических целей.

Чтобы управление в стоимостном отношении было эффективным, оно должно сочетать внутреннюю и внешнюю точки зрения, учитывать историю, прогнозы на будущее и обладать не только финансовой мотивацией. Укрепление VBM подразумевает следующие этапы:

1. Понимание того, какие именно факторы увеличивают ценность

2. Нахождение моментов создания или ликвидации ценности

3. Возведение ценности в ранг одного из основных критериев при принятии решений

4. Внедрение понятия ценности в корпоративную культуру.

Ориентированные на финансы VBM последнее время вошли в моду. Такой тип менеджмента нацелен на «операционализацию» управления в стоимостном отношении, чтобы сотрудники компании воспринимали и идентифицировали акционерную стоимость, которая возникает в результате различный действий и функций компании. Но необходимо иметь в виду, что признанной нормой стало подкрепление финансового подхода пониманием ценности компании в том смысле, как она описана в данной книге. Системы ERP по существу претворяют в жизнь нисходящую стратегию массового производства, которое управляется поставками.

Подход с точки зрения прибавления ценности полностью согласуется с приведенными ниже факторами:

• спрос отражается на изменениях в заказах

• поток производства приспособлен для быстрой адаптации к переменам.

Как и в случае с описанным ниже мониторингом характеристик работы корпорации (Corporate Performance Monitor, СРМ), можно предвидеть появление мониторинга характеристик производства (Manufacturing Performance Monitor, МРМ), который отслеживает процессы производства в реальном времени с точки зрения технического и экономического прибавления ценности.

Сбалансированная карта оценок (Balance Scorecard, BSC) — это система в рамках VBM, которая базируется на четырех главных перспективах оценки характеристик работы компании: финансы, отношения с клиентами, внутренние отношения, усвоение новой информации. Таким образом, Balance Scorecard нацелена на достижение баланса между внешними и внутренними характеристиками работы компании, между долгосрочными и краткосрочными целями, между финансовыми и нефинансовыми рычагами воздействия, между индикаторами отставания и прорыва вперед; причем это не просто система измерения контроля, а полноценная система управления для успешного внедрения стратегий компании.

Как уже упоминалось в разделе «Знание как новый капитал» главы 1, в информационную эру постиндустриализма и постмодернизма направления инвестиций капитала претерпели значительные изменения. В индустриальную эпоху все управленческие оценки и усилия были направлены на увеличение эффективности, на попадание в тенденции макроэкономики с целью получения максимальной отдачи от инвестированного капитала. Однако в компьютеризованную эру постмодернизма, залог конкурентоспособности компании заключается в сотрудничестве систем, процессов и людей, которые придают своей компании достаточную гибкость и способность приспосабливаться к меняющимся условиям мирового рынка.

Необходимо отметить, что освоение новейших технологий само по себе не является залогом успеха компании — ведь технологии так же быстро сменяются. Основной упор необходимо сделать на использовании технологических средств для оперативного создания стратегий, которые при переменах на рынке удерживали бы постоянных потребителей и привлекали новых, и, что еще более важно, подчеркивали бы индивидуальность продуктов компании, их неповторимость. Именно по этим причинам компания «Дженерал Моторс», стремясь обогнать японских конкурентов по производительности и качеству, несколько лет назад принялась активно внедрять робототехнику на своих конвейерах, однако, в конечном счете, успех был весьма и весьма скромным.

Таким образом, компаниям необходима управленческая система, которая могла бы осуществлять оценку будущих стратегий компании. Причем, не менее важна способность компании проводить постоянный, динамичный мониторинг прогресса и эффективности выполнения этих стратегий, так как от этого зависит принятие корректирующих мер на основе полученной от системы информации. Сбалансированная карта оценок является именно таким инструментом стратегического управления, который позволяет компании эффективно отслеживать и управлять выполнением стратегий по созданию и увеличению ценности. Кроме того, возникает необходимость в информационной системе, которая позволила бы им внедрить Balance Scorecard. SAP SEM как раз и является решением для внедрения Balance Scorecard в организации, что и описано ниже, в разделе «Стратегическое управление предприятием SAP».

Balance Scorecard (BSC) — это структура, позволяющая компании трансформировать стратегию и взгляды в согласованный, упорядоченный комплект мер по улучшению характеристик своей работы. Сбалансированная карта оценок воспринимает цели и критерии как производные от определителей ценности или соответствующих движущих сил, определяющих характеристики работы компании при учете ее стратегии. Как показано на рис. 20.1, структура BSC состоит из четырех компонентов:

• Финансы

• Отношения с потребителями

• Внутренние бизнес-процессы

• Освоение информации и рост.

Рис. 20.1. Структура Balance Scorecard.

Впервые представленная на конференции SAPPHIRE '98 в Мадриде, SAP Strategic Enterprise Management (SEM) представляет собой полный набор программных функций и процессов, которые позволяют компании внедрить и использовать процедуру стратегического управления. На основе концепции BSC, SAP SEM позволяет компаниям претворять стратегию в реальные действия быстрее и гораздо эффективнее, а также обеспечивает интегрированное представление информации о характеристиках работы корпорации в режиме реального времени в масштабе всей структуры бизнеса, что ведет к увеличению ценности компании со всех четырех перспектив. SEM является частью SAP Business Intelligence Initiative.

Процесс SEM включает в себя следующее:

• Анализ ожиданий организаторов компании

• Автоматический выбор источника внешней и внутренней информации

• Моделирование и разработка бизнес-стратегий

• Планирование и анализ решений по инвестициям

• Выделение ресурсов и интеграция стратегической, финансовой и оперативной информации

• Обеспечение работы таких интерпретационных моделей, как BSC, иерархий ценностей и т. д.

• Мониторинг и управление показателями

• Распространение информации о статусе характеристик работы компании среди организаторов компании (в особенности — среди акционеров).

На рис 20.3 представлена архитектура SAP SEM.

Рис. 20.3. Процесс стратегического управления предприятием SAP (SEM).

В этой главе ценность предприятия рассмотрена с различных точек зрения — в том числе с точки зрения клиентов, инвесторов, поставщиков, менеджеров и сот рудников. Ценность можно отслеживать и управлять ею, что выражается в виде мер, направленных на улучшение характеристик работы компании. Этими мера ми можно эффективно управлять с помощью структуры Balance Scorecard в рамках решения SAP «Стратегическое управление предприятием» (Strategic Enterprise Management, SEM).

В 90-х годах ERP-системы фокусировали внимание на улучшении внутренней производительности предприятия, тем не менее, более 50 % переменных издержек, влияющих на качество работы организации, диктуется решениями, принятыми за ее пределами. Выиграв за счет модернизации и реинжиниринга, предприятия направят силы на получение наиболее высоких прибылей от происходящих между компаниями процессов. Однако почему цепь поставок считается такой важной для следующего прорыва в работе предприятий? Между партнерами в цепи поставок существуют обширные возможности для повышения эффективности, равно как и потенциал, необходимый для более полного удовлетворения клиентов.

Как и пререкания внутри организации, недоразумения и споры между партнерами не улучшают качества работы, а резко снижают ее эффективность и отнимают время. В итоге все неулаженные конфликты, внутренние проблемы или неэффективность цепи поставок зачастую съедают до 25 % текущих расходов компании.

Будущее ERP тесно связано с попытками произвести реинжиниринг внешних контактов и простимулировать более тесное сотрудничество между предприятиями. Это довольно сильно контрастирует с традиционными отношениями соперничества, которые, как известно, до недавнего времени существовали между поставщиками, изготовителями и розничными торговцами. Истинная экономия на производстве может быть достигнута лишь при экономии совместной. Предполагаемая организация, о которой говорилось в подразделе «Системы ERP фундаментально моделируют процессно-ориентированные предприятия», охватывает всех членов традиционной цепи поставок; предполагаемая цепочка начисления стоимости включает всех участников, каждый из которых повышает ценность товара. ЕСЕ по-настоящему воплощается в полнофункциональных системах e-SCM, о которых я расскажу позже, в разделе «Электронное управление цепочками поставщиков».

Цепь поставки включает в себя все действия, имеющие отношение к транспортировке и трансформации сырья и материалов, получаемых от поставщиков, в готовую продукцию, которая доставляется покупателю. Туда включены обработка заказов, снабжение, управление запасами, производственное календарное планирование, производство, упаковка, транспортировка, складское хранение, доставка, работа с покупателями. Управление цепочками поставок (SCM) занимается интеграцией, координацией и соединением всех этих действий в единый процесс, связывающий всех партнеров в «цепи», к которым относятся не только внутренние организации, но и внешние партнеры, например, поставщики, оптовые продавцы, перевозчики, логистические компании, являющиеся третьими сторонами (3PL), складские компании, оптовики, производители технического обслуживания и т. д. Для компаний, ищущих долговременной выгоды, система SCM — это ключевая платформа, необходимая для того, чтобы поддерживать быстро появляющиеся на основе Интернета бизнес-модели. Обычно SCM следит за тем, чтобы нужный продукт был в нужном месте по хорошей цене, в хорошем состоянии и вовремя.

Существуют три основные модели построения цепи поставок:

 Прямой канал, который можно сравнить с привычными оптовыми продуктовыми магазинами. За счет широкого диапазона товаров и низкой маржи, этот канал обеспечивает хорошие результаты на рынке и качественное выполнение заказов клиентов.

 Непрямой канал, например, продажа электронной техники; с меньшим ассортиментом товаров и более высокой маржой. Сроки выполнения заказа по этому каналу зависят от географического положения.

 Виртуальный канал — продажа через Интернет, со средней маржой. Этот канал удобен тем, что доступен с любого персонального компьютера вне зависимости от его местонахождения.

Комплексность операций в цепи поставок возрастает по причине все более интенсивной конкуренции, результатами которой являются:

• массовое изготовление с учетом индивидуальных пожеланий и требований заказчика