Leider bleiben bei neuen Software-Produkten dabei aber oftmals das Verständnis für den grauen Implementierungsalltag und viele aktuelle Kundensituationen auf der Strecke. So verheißungsvoll viele Innovationen auch sein mögen, viele Anwender kämpfen noch mit den Implementierungen der Innovationen von gestern.
Unumstritten sind Innovationen prinzipiell gut und sie sichern ja auch nicht nur das Fortbestehen der Software-Anbieter allein, sondern bringen ganze Wirtschaftszweige nach vorne. Software-Anbieter sind daher wertvolle Impulsgeber, trotzdem müssen Neuerungen aber auch konsumierbar sein. Um dies zu erreichen, sind neue Implementierungs-Methoden zwingend erforderlich. Es muß schneller und kostengünstiger implementiert werden, dann wäre auch wieder schneller Budget für die nächste Innovation verfügbar und so weiter… - das wäre wirklich innovativ!
Leider zeichnet die erlebte Praxis jedoch noch ein anderes Bild. Das Verhältnis der Anschaffungskosten von gekaufter SAP-Software zu den entstandenen Einführungskosten beträgt immer noch nicht selten eins zu fünf und mehr. Dies übersteigt dann oft schnell den ursprünglich gesteckten Kostenrahmen. Deshalb möchte ich zunächst die aus meiner eigenen Erfahrung praktikabelsten Leitsätze zur Reduzierung der Implementierungs-Kosten von Heute zusammenfassen, um dann im Anschluß neue Wege zur effizienteren SAP-Einführung aufzuzeigen.
Leitsätze zur Kostenreduzierung bei SAP-Implementierungen Heute
Im vorhergehenden Teil dieses Artikels habe ich die Hauptrisiken für "aus dem Ruder laufende" SAP-Implementierungen aufgezeigt. Dabei wurde auch beschrieben, warum das Verhandeln zum Festpreis keine abschließende Maßnahme zur Kostendeckelung sein kann.
In der Theorie gibt es viele mehr oder weniger professionelle Erkenntnisse dazu. Nach meiner persönlichen Erfahrung aus dutzenden selbstgemachten und verantworteten SAP-Projekten, lassen sich einige wenige Leitsätze nach der 80-/ 20-Regel ableiten, die den größten Hebel zur Kostenreduzierung darstellen. Sie leuchten sicherlich schnell ein, werden aber leider allzu häufig als selbstverständlich abgetan und dann folgerichtig nicht professionell umgesetzt.
Investieren Sie in ein fundiertes Fein-Konzept auf Prozeßebene und die darauf aufbauende Ausschreibung. Wie im Teil I des Artikels beschrieben, birgt ein unklarer Projekt-Scope unkalkulierbare Risiken, die Sie unausweichlich im Projekt einholen werden. Je genauer inhaltliche Erwartungen von den Fachbereichen spezifiziert werden müssen, desto weniger Raum bleibt für spätere teure Fehlinterpretationen auf beiden Seiten. Die Erstellung eines Feinkonzeptes ist dabei keine Eigeninitiative der IT-Abteilung, nehmen Sie dazu die Fachbereichsverantwortlichen in die Pflicht! Es kommt dabei weniger darauf an, jede existierende Prozeßvariante des Unternehmens zu beschreiben, im Gegenteil, die Konzentration auf die wesentlichen Wertetreiber und Abhängigkeiten genügt. Dies dann aber detailliert und vor allem fachlich begründet. Dokumentieren Sie diese Begründungen!Manche Beratungsunternehmen bieten dazu unterstützend methodisches Prototyping der Prozesse an, so daß mögliche Prozeßalternativen visuell am Bildschirm durchlebt werden können. Dies hilft enorm. Jeder in dieser Phase investierte Euro ist gut angelegt.
Eine SAP-Einführung ist kein Projekt der IT-Abteilung, sondern ein Business-Projekt: Damit sind natürlich keine notwendigen technischen Upgrades gemeint, wohl aber betriebswirtschaftlich veranlaßte Einführungen. Übertragend gesagt, steht das Business zu häufig am Spielfeldrand, schaut dem Spiel zu, kritisiert den Trainer und pfeift am Ende die Mannschaft für das Erreichte aus. Konsequent übersetzt bedeutet dies, dass je nach Projektgröße die Geschäftsleitung, der Bereichsvorstand oder ein anerkannter Bereichsleiter als Projekt-Sponsor verankert werden muß, und nicht der CIO. Selbstverständlich, aber sicherheitshalber doch erwähnt, müssen im Projektverlauf die jeweiligen Milestones und Projektergebnisse auch vom Fachbereich abgenommen werden und nicht von der IT.
Prüfen Sie bei der Fein-Konzeption auf Machbarkeit im SAP-Standard: Selten sind fachliche Anforderungen so individuell wie man es als Kunde gern annimmt. Die SAP Business-Suite bildet als Ergebnis aus über 40-jähriger Arbeit mit Kunden tausende von Kern-Prozessen in dutzenden von Branchen und Sub-Branchen und damit nahezu jeden betriebswirtschaftlichen Ablauf im Standard ab. Gehen Sie mit dieser Annahme an den Start und lassen Sie sich nicht von unternehmens-eigenen oder an einer individuellen Anpassung zusätzlich verdienenden Instanz zu früh überzeugen. Jedes "geht nicht im Standard" gilt es intensiv zu hinterfragen und glauben Sie mir, es geht unglaublich viel im Standard! Individuelle Anpassungen sollten absolut restriktiv beschlossen werden und zwar nur dann, wenn dadurch ein nachvollziehbarer Wettbewerbs-Vorteil entsteht. Abweichungen vom Standard sind die wahren Aufwandstreiber und kosten zweimal: zunächst bei der Anpassung, später bei der Wartung. Lassen Sie sich den Business-Case dazu begründen und rechnen - und entscheiden Sie dann.
Leisten Sie sich einen starken Projektleiter mit exzellentem Verständnis für Methodik: Eine SAP-Implementierung macht man nicht nebenbei. Fachwissen ist gut, Projektmanagement-Kompetenz und Akzeptanz in der Rolle aber entscheidend. Ein Projektleiter darf keine Scheu vor unangenehmen Fragen und Wahrheiten haben. Darüber hinaus muß er fürs Projekt freigestellt sein und die Rückendeckung der Geschäftsleitung haben. Allzu oft habe ich erlebt, daß bei der Suche nach einem Projektleiter zunächst überlegt wurde, wer noch freie Kapazitäten hat und das führt selten zu den Besten!Die risikoreichsten Projekte waren für mich meist diejenigen, bei denen die Projekt-Ampeln so gut wie immer auf grün standen; ein untrügliches Signal für schwaches Projekt-Management und falsch verstandenes Eskalations-Management. Eskalations-Mechanismen müssen genützt werden, sie sind essentielle Instrumente zum Erfolg.
Diese Mechanismen sollten bestmöglich personenunabhängig, also nach vorab definierten Bemessungskriterien aufgesetzt werden, ansonsten sind sie durch Personen leicht beeinflußbar und damit nur noch die Hälfte wert.Es ist übrigens durchaus legitim, die Projektleiter-Rolle extern zu besetzen. Interim Manger bringen häufig dezidierte Erfahrung mit, sind unabhängig von Unternehmens-Politik und zu 100% für diese Rolle einsetzbar. Auch die entstehenden Kosten stehen in keiner Relation zu den Folgekosten schlecht gemanagter Einführungs-Projekte.Sorgen Sie für Transparenz: Projekte im Elfenbeinturm haben keine Erfolgsaussichten. Berichten Sie regelmäßig über Ziele, Verlauf, Erfolge und auch Herausforderungen. Machen Sie aus Betroffenen Beteiligte und holen Sie Ihre Mannschaft ins Boot. Kommunikation und Changemanagement sind dabei für mich untrennbar miteinander verbunden. Beides ist kein Abfall-Produkt, das nebenbei passiert, man muß es planen und nachhaltig umsetzen. Sparen Sie nicht am falschen Ende und benennen Sie klare Verantwortlichkeiten und Kanäle dazu. So gewöhnlich einem dieser Punkt auch vorkommen mag, so schlecht wird er oftmals in der Praxis umgesetzt. Leider, denn nicht selten scheitern interne Veränderungs-Prozesse und Chancen an "nicht abgeholten" und schlecht informierten Mitarbeitern, Lieferanten und Kunden!
Ich hoffe die beschriebenen Leitsätze sind verständlich und hilfreich - für mich haben sie sich jedenfalls bewährt, da sie einfach nachvollziehbar, überschaubar in der Anzahl und vor allem wirkungsvoll sind, wenn man sie ernsthaft umsetzt.
Wunsch-Szenario für die Implementierung von Morgen
Zum Schluß dieser kleinen Reihe über Implementierungs-Tipps rund um SAP, möchte ich meinen Blick in die Zukunft richten und die heute überwiegend übliche Vorgehensweise von SAP Beratungshäusern herausfordern.Es ist einsichtig, daß sich viele Beratungshäuser im SAP-Markt mit den beschriebenen, herkömmlichen Implementierungs-Methoden gut positioniert sehen und diese nicht unbedingt durch kürzere, für die Kunden kostengünstigere Vorgehensweisen ablösen wollen. Aber ähnlich, wie man Trends wie zum Beispiel mobile Prozeß-Bearbeitung oder automatisierte digitale Kommunikation in Prozeß-Ketten nicht aufhalten kann, genau so wenig kann man sich bei ständig verkürzenden Innovations-Zyklen der SAP-Software an alte Vorgehensweisen klammern. Das wird auf Dauer niemand mehr bezahlen.
Ausgehend von dem oben beschriebenen Prototypen-Gedanken und der Maxime so nah wie möglich am Standard zu bleiben, könnten sich Implementierer - oder die Kunden selbst - die zu implementierende SAP Business Lösung als Sandbox in der SAP Cloud (HEC) mieten. Dies ist nicht besonders teuer und zeitlich befristet machbar. Dann könnten alle heute schon in Frage kommenden, vorkonfigurierten Software-Pakete, die sogenannten Rapid Deployment Solutions (RDS), eingespielt werden. Nun könnte man den Prozeß zum Fein-Konzept visualisiert auf den Kopf stellen. Nicht der Berater bildet den Prozeß im System nach, sondern der Kunde muß erläutern, warum der eingespielte Standard-Prozeß nicht genügen soll. Daraus resultierende Change-Requests müßten dann über Business-Cases entschieden werden. Dies würde dazu führen, daß zwangsläufig mehr Standard implementiert werden würde und nur die Prozesse angepaßt werden, die nachweislich auch Unternehmens-Vorteile versprechen. Dies würde den Implementierungs-Aufwand nachhaltig senken, Wartungskosten einsparen und damit wieder Zeit und Geld für beispielsweise weitere Innovationen freisetzen.
Zugeben, das dargestellte Szenario zaubert eher dem Software-Anbieter, als dem Implementierer ein Lächeln ins Gesicht, aber letzten Endes entscheidet immer der Kunde und für ihn bedeuten neue Vorgehensweisen neues Potenzial für günstigere Einführungen und damit mehr konsumierbare Innovation. Deshalb wird es sich meiner Meinung nach so oder so ähnlich durchsetzen. Als Trost mag gelten, daß SAP Software auch in Zukunft nie ganz ohne Beratung implementierbar sein wird!