Mandanten und ihre Rollen

Die Anmeldung an ein SAP-System geschieht immer in einem Mandanten dieses Systems. Alle Aktivitäten, die im System ausgeführt werden, werden daher immer in einem Mandanten durchgeführt. Bei der Planung der SAP-Systemlandschaft muss daher berücksichtigt werden, welche Mandanten für welche Aktivitäten benötigt werden.

Durch die Zuordnung der Aktivitäten, die in einem Mandanten durchgeführt werden, bekommt jeder Mandant eine Rolle. In diesem Abschnitt werden die wichtigsten Mandantenrollen beschrieben.

Da die SAP-Software für die produktive Nutzung immer an die betriebswirtschaftlichen Anforderungen angepasst werden muss, wird in jeder SAP-Systemlandschaft ein Mandant benötigt, in dem Customizing-Einstellungen und gegebenenfalls auch Entwicklungen in der ABAP Workbench durchgeführt werden Dieser Mandant wird als Customizing- und Entwicklungsmandant oder kurz als Customizing-Mandant bezeichnet. Für diesen Mandanten wird die Abkürzung CUST verwendet.

Bevor die Customizing-Einstellungen und Workbench-Entwicklungen produktiv genutzt werden können, müssen sie umfassend auf Fehlerfreiheit und korrekte Funktionalität getestet werden. Fehlerhafte Einstellungen können den Produktivbetrieb erheblich stören und im schlimmsten Fall sogar zum Verlust produktiver Daten führen. Durch die hohe Integrität der verschiedenen SAP-Anwendungen gibt es ein hohes Maß von Abhängigkeiten zwischen den verschiedenen Customizing-Einstellungen, die selbst ein erfahrener Customizing-Entwickler nicht unbedingt auf Anhieb erkennt. Ohne umfassenden Test kann daher die Fehlerfreiheit der Einstellungen nicht garantiert werden. Der Mandant, in dem die Tests durchgeführt werden, wird als Qualitätssicherungsmandant bezeichnet und mit QTST abgekürzt.

Spätestens zum Produktivstart wird ein separater Mandant für die produktive Nutzung des SAP-Systems benötigt. Für den störungsfreien Betrieb dieses Mandanten ist es unbedingt erforderlich, dass hier keine Customizing-Einstellungen und Workbench-Entwicklungen vorgenommen werden und auch keine Tests durchgeführt werden. Dieser Mandant wird als Produktivmandant bezeichnet und mit PROD abgekürzt.

Die drei Mandanten CUST, QTST und PROD sind die zentralen Mandanten, die in jeder Systemlandschaft existieren. In Standardsystemlandschaften gibt es zu jeder dieser Mandantenrollen genau einen Mandanten.

Wir empfehlen, sämtliche Customizing-Einstellungen in einem einzigen Customizing-Mandanten durchzuführen und von dort mit Hilfe des CTS in die anderen Mandanten zu transportieren.

Wir empfehlen, im Qualitätssicherungs- und im Produktivmandanten keine Customizing-Einstellungen oder Workbench-Entwicklungen durchzuführen. Dies kann durch entsprechende Einstellungen der Mandanten sichergestellt werden.

Neben den zentralen Mandanten können noch weitere Mandanten für andere Aufgaben eingerichtet werden. Dabei ist allerdings zu beachten, dass jeder weitere Mandant zusätzliche Systemressourcen (Hauptspeicher und Datenbankplatz) beansprucht und vor allem auch höheren administrativen Aufwand bedeutet. So müssen beispielsweise Zugangsberechtigungen für die Benutzer eingerichtet und verwaltet werden, und Änderungen, die mit dem CTS verteilt werden, in einen weiteren Mandanten transportiert werden. Vor- und Nachteile von weiteren Mandanten müssen daher gegeneinander abgewogen werden.

Beispiele für weitere Mandantenrollen sind:

Entwicklungstestmandant (TEST)

In diesem Mandanten können Entwickler ihre Customizing-Einstellungen und Workbench-Entwicklungen testen, bevor die zugehörigen Änderungsaufträge freigegeben werden. In diesem Mandanten können zu Testzwecken Anwendungsdaten angelegt werden, um einen sinnvollen Test zu ermöglichen. Werden Fehler entdeckt, können diese direkt im Customizing-Mandanten behoben werden. Ein Entwicklungstestmandant wird immer im selben SAP-System wie der Customizing-Mandant eingerichtet. Dadurch sind Änderungen an mandantenunabhängigen Daten, die im Customizing-Mandanten durchgeführt werden, sofort auch im Entwicklungstestmandanten sichtbar. Änderungen an mandantenabhängigen Daten werden mit einer speziellen Funktion des Mandantenkopierers aus dem Customizing-Mandanten in den Entwicklungstestmandanten kopiert. Dazu verwendet der Mandantenkopierer die noch nicht freigegebenen Änderungsaufträge aus dem Customizing-Mandanten. Der Entwicklungstestmandant wird so eingestellt, dass hier keine Änderungen an Customizing-Daten und Repository-Objekten durchgeführt werden können.

Prototyp- oder Sandbox-Mandant (SAND)

In diesem Mandanten können mandantenabhängige Customizing-Einstellungen erprobt werden, wenn noch nicht sicher ist, ob sie in dieser Form genutzt werden können. Einstellungen, die sich dabei bewähren, werden anschließend im Customizing-Mandanten erneut eingegeben. Um Kollisionen zwischen Einstellungen aus dem Prototypmandanten und ernsthaften Einstellungen im Customizing-Mandanten zu verhindern, dürfen im Prototypmandanten keine Änderungen an mandantenübergreifenden Customizing-Daten und an Repository-Objekten gemacht werden. Änderungen an mandantenabhängigen Customizing-Daten dürfen nicht durch das CTS aufgezeichnet werden und nicht aus dem Prototypmandanten transportiert werden. Dies kann durch entsprechende Einstellungen des Mandanten sichergestellt werden.

Schulungsmandant (TRNG)

Um Endbenutzer auf neue Funktionalität vorzubereiten, die zukünftig in den Produktivmandanten transportiert wird, kann es erforderlich sein, einen Schulungsmandanten einzurichten, in dem die neue Funktionalität bereits verfügbar ist und mit Hilfe dort angelegter Anwendungsdaten demonstriert werden kann. Der Mandant wird so eingestellt, dass hier keine Änderungen an Customizing-Daten und Repository-Objekten durchgeführt werden können.