Fall 2: Falsches Prototyping der SAP-Suite

In diesem Fall handelt es sich um ein großes, europaweit agierendes Handelsunternehmen mit einem Jahresumsatz von zirka zwei Milliarden Euro. Es beschäftigt eine kleine IT-Abteilung, die 1200 SAP-Nutzer betreut. Wie im ersten Beispiel stand auch hier eine umfangreiche Einführung von SAP mit den Modulen ERP, BI/PI, SCM und CRM plus Archivierung auf der Projektagenda. Die Feinkonzeption erfolgte durch einen SAP-Implementierungspartner. Da parallel zum SAP-Projekt der Betrieb der zukünftigen IT-Landschaft ausgeschrieben und verhandelt werden sollte, waren schon zu einem frühen Zeitpunkt verlässliche Aussagen über die Systemleistung erforderlich.

Redesign nach Explosion der Betriebskosten

Im Rahmen eines Prototypings kalkulierte der Implementierungspartner die Systemleistung mit rund 210.000 sogenannten SAP Application Performance Standards (SAPS, siehe Kasten "Das magische Dreieck"). Für rund 4000 SAPS wird ein Dual-Core-Server mit zwei Prozessoren veranschlagt. Die Systemlandschaft wurde also quantifiziert, ausgeschrieben, verhandelt und beauftragt. Doch schon deutlich vor dem "Go Live" kam die unangenehme Überraschung: Der Implementierungspartner scheiterte am Prototyping. SAP griff selbst ein und kalkulierte eine Größenordnung von 1.300.000 SAPS. Die Folge: Der jährliche Aufwand für den externen Betrieb explodierte von ursprünglich 800.000 Euro auf knapp 1,8 Millionen Euro. Was tun? Als Lösung blieb nur, unter großem Zeitdruck ein präzises sowie komplettes Redesign aufzusetzen.

Fehlerursachen und Projektrettung

Der Implementierungspartner konzentrierte sich in diesem Projekt nicht auf das Wesentliche, sondern ließ sich zusätzlich von den Anforderungen der Fachbereiche leiten. Das hatte zur Folge, dass nicht nur der Implementierungsaufwand in die Höhe schnellte, sondern auch die Abläufe und Prozesse komplexer wurden. Das hatte wiederum höhere Betriebskosten zur Konsequenz. Beim Redesign durch SAP lag die Systemleistung gegenüber der ursprünglichen Planung glatt um den Faktor sechs höher. Als Lösung blieb nur, den Grad der Komplexität deutlich zu verringern. Das ERP-Projekt wurde in überschaubare Teilschritte gegliedert. Mit realistischen Anforderungen und neuen Prozessen erarbeitete Gebhardt Sourcing Solutions ein angemessenes Sizing - mit geringeren Betriebskosten.

Server-Virtualisierung und Hosting nach Maß

Um die Kosten weiter zu senken, wurde auch das Betriebskonzept optimiert: Statt klassischer Unix/RISC-Systeme kommen heute virtualisierte Server zum Einsatz. Außerdem wurde mit dem Hosting-Partner ein flexibles und bedarfsorientiertes Wachstum der voraussichtlich benötigten Systemleistung verhandelt. Innerhalb dieser Leitplanken kann sich der Leistungsbedarf flexibel nach oben und nach unten ändern. Bezahlt wird nur der tatsächliche Verbrauch. Benchmarks brachten den Hosting-Partner auf ein marktgerechtes Preisniveau.

Unterm Strich steht die gesamte Implementierung nun auf Grün: Die Systemanforderungen wurden von 1.300.000 auf rund 700.000 SAPS reduziert. Dadurch sanken die jährlichen Betriebskosten von 1,8 Millionen Euro auf rund 950.000 Euro - ein akzeptabler Wert für den Kunden. (pg)

Prozesse der SAP-Suite berechnen

Das magische Dreieck

Eine Zahl von zwei Millionen Geschäftspartnern, wie in Fallbeispiel 2, ist zunächst nur für die Größe der Plattenspeicher relevant und weniger für das System selbst, da sie in Form statischer Stammdaten keine produktive Last erzeugen. Wenn diese Geschäftspartner in einer Stunde aber über 20.000 Bestellungen senden, dann kommt Bewegung ins Spiel. Und zwar in Form von Interaktionen, die Transaktionen auslösen und Systemleistung benötigen.

Optimal entworfene Unternehmensprozesse benötigen für ein und denselben Vorgang nur wenige Interaktionen und verursachen damit weniger Transaktionen - man kommt also mit einer geringeren Systemleistung aus. Was zur Frage führt: Sind die für das jeweilige Unternehmen optimierten Prozesse im Standardumfang von SAP enthalten oder müssen sie erst mit mehr oder weniger Aufwand per Customizing abgebildet werden?

Für die Bestimmung der erforderlichen Systemleistung wird bei SAP der Quicksizer herangezogen. Dieser bildet alle wichtigen Prozesse der SAP-Suite ab und bricht betriebswirtschaftliche Vorgänge als SAPS auf Objekte und Transaktionen herunter. Dabei werden die in SAP als Standard hinterlegten Prozesse zugrunde gelegt. Dieses Sizing basiert also auf Annahmen und eignet sich daher nur für eine erste Abschätzung. Bei einem Volumen von mehr als 300.000 SAPS oder einer hohen Anzahl kundenspezifischer Prozesse empfiehlt es sich daher dringend, die Kunden- und Kernprozesse des Unternehmens sorgfältig zu analysieren und mit den gewonnenen Daten ein exaktes Sizing auf Grundlage tatsächlicher produktiver Daten zu betreiben. Dies ist aufwendig und kostet Zeit, - hilft aber am Ende, böse Überraschungen wie in diesem Fall zu vermeiden.

Die Anpassung von Abläufen eines Unternehmens an SAP ist also nur bedingt erfolgreich. Dasselbe gilt natürlich, wenn ein Implementierungspartner fertig entwickelte Templates einsetzt. Denn ein effizienter Prozess im Unternehmen A ist in Unternehmen B nicht zwingend gleich effizient, auch wenn beide in derselben Branche tätig sind. Zudem bedeutet die Änderung von Abläufen immer auch einen Prozess, den Mitarbeiter tragen und umsetzen müssen. Der bestmögliche Betriebspunkt liegt also im magischen Dreieck zwischen den Anforderungen des Unternehmens - abgebildet in seinen Geschäftsprozessen, den Möglichkeiten der Software (Standard, Templates oder Customized) und den Mitarbeitern, die das System nutzen. Ein guter Berater und Implementierungspartner sucht und findet diesen Punkt gemeinsam mit dem Unternehmen.