Anfang des Inhaltsbereichs

Komponentendokumentation Mandant und Mehrmandantenbetrieb Dokument im Navigationsbaum lokalisieren

Einsatzmöglichkeiten

Das Mandantenkonzept der SAP ermöglicht es, ein SAP-System in mehrere logische Subsysteme - Mandanten - zu unterteilen. Diese Subsysteme können wie eigene Systeme betriebswirtschaftlich voneinander unabhängig und isoliert genutzt werden. Im folgenden wird von dem Fall ausgegangen, dass jeder Kunde auf jeweils einen Mandanten abgebildet ist. Das vorliegende Papier ist ausschließlich auf die Rolle "Produktivmandant" fokussiert, und es werden nicht die weiteren Nutzungsmöglichkeiten eines Mandanten wie z.B. Testmandant, Schulungs- oder QA-Mandant betrachtet.

Mehrmandantenfähigkeit

In einem System mit mehreren Mandanten liegen alle Daten in einer gemeinsamen Datenbank. Eine mySAP.com-Lösung wird als mehrmandantenfähig bezeichnet, wenn bei einer Installation mit gemeinsamer Systemplattform, Datenbank und zentralen Services jeder Kunde über seine Daten exklusiv verfügen kann.

Integration

Daraus ergeben sich unmittelbar drei Hauptfragen:

  1. Welchen Einfluss hat die gemeinsame Speicherung der Kundendaten auf die Sicherheit und den Schutz der gespeicherten Geschäftsdaten? Können unerlaubte Einsichtnahme in die Daten durch andere Mandanten und vor allem versehentliche oder willkürliche Überschreibungen ausgeschlossen werden?

    2. Weitere Informationen finden sie unter Anforderungen an die Datenverwaltung.

  2. Welchen Einfluss hat eine größere Anzahl gleichzeitig aktiver Mandanten auf ablaufende Prozesse im Hinblick auf Antwortzeiten? Wie sehr belastet ein zusätzlicher Mandant die Performance?

    3. Weitere Informationen finden sie unter Einfluss auf Prozesse und Laufzeit.

  3. Welchen Einfluss hat ein Mehrmandantenbetrieb auf die Administration und die vom Service Provider garantierbaren Service Level Agreements (SLAs)?

Weitere Informationen finden sie unter Administration des des Mehrmandantenbetriebs.

Um eine Mehrmandantenbewertung für eine mySAP.com-Lösung vornehmen zu können, müssen diese drei Fragen geklärt sein. In den angegebenen Abschnitten wird jede dieser Fragen im Detail erörtert.

Da Bewertungen einzelner Fragestellungen oftmals von der strategischen Ausrichtung des zugrundeliegenden betriebswirtschaftlichen Szenarios abhängen, ist es zweckmäßig, zwei unterschiedliche Szenario-Typen voneinander zu unterscheiden:

Provider-Betrieb (auch „Rechenzentrum-Betrieb" genannt)

Der Provider stellt eine vorkonfigurierte Systemlösung bereit, d.h. mit einem für die jeweilige Industriebranche vollständig ausgeprägten Customizing. Seine Kunden kaufen damit fertige Lösungen ("Software von der Stange"). Sie sind meist nicht autorisiert, Customizing-Änderungen selbst einzubringen, allenfalls bzgl. einer sehr kleinen, explizit freigegebenen Menge an Einstellungen. Es kann mitunter auch zweckmäßig sein, hinsichtlich der Kunden nochmal zu differenzieren zwischen

Hierbei hat jede Tochter ihren fest zugeordneten Wirkungsbereich und es besteht kein direkter Wettbewerb unter den Konzerntöchtern.

IT-Servicebetrieb mit autarken Firmen (Konzern-Töchter Szenario)

Im Gegensatz zum ASP-Betrieb beschränkt sich das Serviceangebot des Providers hier im wesentlichen auf die technische Infrastruktur, während die Anwendung – wenn überhaupt – vom Provider nur teilweise vorkonfiguriert wird. Die Customizing-Pflege liegt demzufolge in der Verantwortung der Kunden-Firmen selbst. Dabei ist es unerheblich, ob sie dabei Dienstleistungen eines Hosting-Anbieters in Anspruch nehmen oder den Anwendungsbetrieb selbst organisieren. Customizing-Änderungen müssen hier also den Kunden erlaubt bleiben.

Natürlich sind dabei Spielregeln eines Mehrmandantenbetriebes zu beachten, die genau die mandantenübergreifenden Änderungen betreffen. Doch ist offensichtlich, dass bei einer derart heterogenen Kundenschar die Anforderungen an eine "friedliche Koexistenz" der Kunden höher sein dürften als bei Kunden mit standardisierten Profilen und mit nur minimalen Änderungsansprüchen.

Ende des Inhaltsbereichs