Mandantenübergreifendes Customizing

Kategorisierung nach Verwendungsart

Eine Objektliste kann toolgestützt im System ermittelt werden. Die beiden hierzu verfügbaren Tools werden unter Toolunterstützung zum Erzeugen der Objektliste beschrieben. Zu einer vorgegebenen Komponente (wahlweise Softwarekomponente oder Anwendungshierarchie-Komponente) wird eine Liste der zugehörigen mandantenübergreifenden Customizing-Objekte ausgegeben. Um eine schnellere Übersicht zu erhalten, welche der Objekte relevant sind, hilft eine Kategorisierung nach Verwendungsarten. Eine Verwendungsart gibt zu jedem Objekt auf sehr generische Weise an, ob es sich mehr um technische oder mehr um betriebswirtschaftlich relevante Merkmale handelt. Hierbei werden sechs unterschiedliche Verwendungsarten unterschieden.

Die beiden ersten Kategorien gehören zu den technischen Einstellungen, die das System selbst oder dessen Infrastruktur betreffen (Systemprofilparameter):

• Verwendungskategorie 1: System-Parameter (SYP)

  Bei dieser Kategorie handelt es sich um Einstellungen von Systemprofilparametern, d.h. um Einstellungen zur technischen Abstimmung des Systems auf die verfügbaren Ressourcen und auf die technische Infrastruktur. Die Parameter haben keinerlei Auswirkung auf betriebswirtschaftliche Funktionen der Anwendung.

  Technische Einstellungen sind beispielsweise erforderlich im Kontext von RFC-Destinationen, Client-Server-Konfigurationen, Puffereinstellungen sowie bei der Mandantendefinition selbst.

  Eine Sonderform nehmen diejenigen Systemprofilparameter ein, die vom Kunden zwar nicht geändert werden dürfen, auf die der Kunde aber bei der Systemeinführung via IMG explizit hingewiesen werden soll. Zur Kennzeichnung erhalten diese im Kürzel den Zusatz ro (read-only), haben also das Kürzel SYP-ro.

• Verwendungskategorie 2: Technische Organisationsunterstützung (ORG)

  Diese Einstellungen sind notwendig, um technische Prozesse zu steuern. Dazu gehört auch der Aufbau von Netzverbindungen im weitesten Sinne, aber auch die Steuerparameter für das Batch-job-scheduling.

Die beiden nächsten Kategorien sind schon sehr nahe verwandt mit Programmlogik. Hier finden wir einerseits Beispiele, in denen die Ablaufsteuerung aus Programmen herausgezogen und in Tabellen verlagert wurde. In dieser deskriptiven Form sind Modifikationen wesentlich einfacher durchführbar. Andererseits treffen wir auf Tabellen, die Metadaten zum Generieren von Repository-Objekten enthalten.

• Kategorie 3: Steuerdaten mit Programm-Charakter (PCH)

  Unter dieser Kategorie werden Ansätze zusammengefasst, bei denen Programmlogik in Customizing-Tabellen ausgelagert wird. Hierdurch werden Transaktionslogiken transparenter und auch für Nicht-Programmierer verständlich. Diese Daten werden dann zur Laufzeit von den Programmen interpretiert und steuern deren Verhalten. Dadurch werden nicht nur Modifikationen an der ausgelieferten SAP-Lösung vereinfacht. Durch die Trennung von modifizierter Ablauflogik und codierten Programmen wird auch der Aufwand zur Restaurierung von Modifikationen im Upgrade-Zyklus erheblich gesenkt. Dadurch können Kosten erheblich gesenkt werden.

  Solche Tabellen sind in der Regel mandantenunabhängig, weil sie unmittelbar in Bezug zu Repository-Objekten stehen. Nur in Ausnahmebereichen wie beispielsweise der Dynproablaufsteuerung oder der Dynprofeldsteuerung wird Steuerlogik in mandantenabhängige Tabellen verlegt, d.h. können Abläufe mandantenweise beeinflusst werden.

• Kategorie 4: Metadaten zur Generierung von Repository-Objekten (MGR)

  Bei einigen Anwendungen mit sehr kundenspezifisch ausgeprägten Funktionalitäten und Oberflächen lässt sich die gesamte Systemlösung nicht vollständig vordenken und ausliefern. Ein Beispiel hierfür liefert der Bereich Konditionstabellen der Preisfindung. Kennzeichnend für alle diese Anwendungen ist, dass lediglich eine Rahmen-Software ausgeliefert wird, zusammen mit den Werkzeugen zum Anpassen der Anwendung an die Bedürfnisse des Kunden. Letzteres geschieht über Generierungstechniken aus dem Customizing heraus. D.h. während des Customizings werden maschinell gestützt Arbeiten eines Software-Entwicklers ausgeführt, allerdings auf einer sehr hohen und anwendungsnahen Ebene. Mit diesem Ansatz ist es möglich, auf individuelle, nicht sinnvoll standardisierbare Anwendungen flexibel reagieren zu können und trotzdem komfortable Oberflächen mit guter Performance anzubieten. Das Generieren von Programmteilen erstreckt sich von einzelnen Funktionen (Reports, Programmbausteine) bis hin zu ganzen Teilanwendungen (Preisfindung: Konditionstabellen mit Dictionary-Objekten, Pflegeoberflächen und Auswertungsprogrammen).

  Je nach Sensitivität der Daten oder auch im Hinblick auf angepasste Oberflächen ist auch der Einsatz von Mandantenfiltern möglich, die unter Unterstützbarkeit individueller Kundenanforderungen beschrieben werden.

Die letzten beiden Kategorien repräsentieren global gültige Regeln und Eigenschaften:

• Kategorie 5: Basic Business Standards (BBS)

  Hierbei handelt es sich um fixe Parameter der für das installierte System etablierten Geschäftsprozesse. Diese komplettieren die installierte SAP-Lösung selbst und sind nicht pro Mandant änderbar.

• Kategorie 6: Globale Entitäten (GLO)

  Solche Einstellungen sind in der Regel unabhängig von einem speziellen Unternehmen und deshalb unabhängig von einem speziellen Mandanten. Beispiele hierfür sind Währungsdefinitionen oder Gemeindeschlüssel. Für den Betrieb eines Mehrmandantensystems bedeutet dies verminderten Pflegeaufwand, da die Pflege nur einmal pro physischem System und nicht redundant pro Mandant erfolgen muss.