Zusammenfassung: Der Blogbeitrag gibt einen Einblick in die persönliche Entwicklung des Autors und die Entstehungsgeschichte seiner Werkzeuge, die er im Projektmanagement einsetzt. Es zeigt, wie wichtig es ist, eine Leidenschaft und ein Interesse an seinem Arbeitsbereich zu haben, um innovative Lösungen zu entwickeln.
Im Folgenden lege ich den Schwerpunkt insbesondere auf die Stationen, die sehr wesentlich waren für die Ansammlung und Ausprägung meines methodischen Wissens und der dabei erfolgten Sammlung/Entwicklung des pragmatisch anzuwendenden Werkzeugkastens für eine erfolgreiche Projektleitung.
DIE ERSTEN SCHRITTE
1992 bin ich bei Andersen Consulting in die SAP-Beratung eingestiegen – damals noch die Version R/2 – und war 1994 einer der ersten Berater für SAP R/3 in Europa. Deshalb nennt man mich heute wohl einen Dino in der SAP-Beratung ;-).
SAP habe ich von der Pike auf gelernt. Ich bin über die Programmierung und technische Teamleitung zur Modulberatung im RM/RV (im R/2) bzw. MM/SD (im R/3) gekommen. Als einer der ersten R/3-ler in Europa war ich dann für Andersen in verschiedenen Projekten für Feuerwehreinsätze unterwegs und konnte dadurch das System SAP sehr früh end-to-end und mit allen seinen Tücken kennenlernen.
SPIRIT OF FACILITATION
Glücklicherweise (aus heutiger Sicht) waren die Leute von Andersen Consulting damals mit ihrer Einführungsmethode „Method/SAP“ die Methoden-Päpste. Das hat mir sehr geholfen – insbesondere, weil ich sehen durfte, was man alles falsch machen kann, wenn man eine Methode nicht zugeschnitten auf die jeweilige Projektsituation pragmatisch genug zum Einsatz bringt. Mein Dank gilt an dieser Stelle Rolf Moser, der in mir in dem Zusammenhang den „Spirit of Facilitation“ für den zielgerichteten und maximal nutzenstiftenden Einsatz von Methoden und Werkzeugen geweckt hat.
VON NICHTS KOMMT NICHTS
Meine erste SAP-Projektleitung übernahm ich 1995, nach meinem Wechsel zu Origin. Interessanterweise von einem Ex-Andersen, der nicht in der Lage war, jenes bei Andersen Erlernte kundenspezifisch genug anzuwenden. Im Rahmen dieser ersten Projektleitung habe ich gemeinsam mit Kollegen aus ganz Europa eine SAP-Einführungsmethode inklusive der notwendigen Werkzeuge entwickelt und an meinem Projekt sehr erfolgreich pilotiert; vielen Dank an dieser Stelle an Helmut Weber (damals Kundenprojektleiter), ein Controller, der mich mit seinen stetigen Nachfragen immer wieder ganz in die Tiefen der Zusammenhänge der Methode getrieben hat.
EVOLUTION
Leider kam diese Einführungsmethode bald darauf gar nicht mehr zum Einsatz, weil die SAP AG, gerade als wir soweit waren, selbst ihr AcceleratedSAP (ASAP) fertig-entwickelt hatte. Interessanterweise war ASAP fast genauso konzipiert, wie die Methode, die wir bei Origin entwickelt hatten. Und das war kein Wunder, denn mittlerweile hatte sich das evolutionäre Prototyping bei einer SAP-Einführung, die nah am Standard bleiben sollte, durchgesetzt. Als Konsequenz habe ich mich mit ASAP und allen darin befindlichen Werkzeugen befasst und mich für die unterschiedlichen ASAP-Varianten (Single-Site, GlobalASAP und Continuous Business Improvement (CBI)) von der SAP zertifizieren lassen. Nebenbei habe ich in dieser Zeit auch das Zertifikat für SAP-Integration erhalten, was ziemlich anspruchsvoll war, weil man sich dort in allen Modulen wie auch deren Integration untereinander sehr gut auskennen musste!
WAS LANGE WÄHRT …
Passenderweise übernahm ich danach eine meiner längsten und intensivsten Projektleitungen: das globale Template-Rollout nach GlobalASAP für die CCHBC. Dies bedeutete die Verwendung von ASAP von vorn bis hinten, in allen Details, Schritt für Schritt und mit intensiver Diskussion. Denn CCHBC hatte die beiden kundenseitigen Projektleiter ebenfalls auf GlobalASAP-Kurse geschickt, und so wurde alles intensiv und lange diskutiert. Ich denke heute, das hat uns allen im weiteren Berufsleben sehr geholfen. Danke dafür an Reinhard Meister und Kiril Topalov von CCHBC! Aus der Zusammenarbeit im ersten Template (R/3 Core) haben wir in der Folge den spezifischen, pragmatisch anzuwendenden GlobalASAP-Zuschnitt für die weiteren SAP-Rollouts der CCHBC entwickelt.
WEITERE STATIONEN UND ERFAHRUNGEN
Mittlerweile war ich Beratungsleiter bei der PLAUT (Schweiz) AG. Als solcher habe ich alle meine Berater in den technischen Grundlagen für SAP-Berater geschult, denn es gab tatsächlich welche, die kein ABAP lesen oder debuggen konnten und das ganz normale Handwerkzeug für SAP-Berater nicht kannten: Datenbankstrukturen im SAP, ABAP/4 Query oder die LSMW.
Unterschlagen möchte ich auch nicht, dass ich 1999 für die damalige Schmidt, Vogel & Partner (heutige Itelligence und damals immer Systemhaus des Jahres in Deutschland als erfolgreichstes Systemhaus für den Mittelstand) in die Schweiz gegangen bin und die SVP (Schweiz) AG gegründet und aufgebaut habe. Auch in der Schweiz ist es uns gelungen, gleich im Jahr der Gründung am erfolgreichsten im Mittelstand zu sein und Systemhaus des Jahres zu werden. Dabei geholfen haben uns damals die von der SAP (Schweiz) AG definierten KMU-Pakete (KMU = kleine und mittelständische Unternehmen) – SAP-Gesamteinführungen mit Aufwänden zwischen 150 und 250 Manntagen mit detaillierten Funktionslisten und einem wochengenauen Tätigkeits-/Aufwandsplan – ein wundervoller Werkzeugkasten, von dem ich später sehr profitiert habe.
METHODEN ZAHLEN SICH AUS
Unter Zugrundelegung der Erfahrungen aus den Projektleitungen mit ASAP und den KMU-Paketen habe ich dann für meine Projektleiter und Berater bei der PLAUT eine Projektleiter-CD erstellt. Darauf wurde der komplette Projektzyklus von Angebotslegung bis Projektnachkontrolle inhaltlich, qualitativ, zeitlich, budgetär und kommunikativ sehr pragmatisch und konsistent zusammenpassend mit einfachen Werkzeugen und einer beschleunigten ASAP-Version als Vorgehensweise dargestellt. Mit diesem Werkzeugkasten habe ich in den ersten Jahren verschiedene SAP-Projekte mit wenig Aufwand klar beschrieben und als Festpreis-Projekte kontrolliert von der Angebots- bis zur Nachbetreuungsphase sicher budget-, qualitäts- und zeitgerecht ins Ziel gebracht.
WARUM ES NICHT GLEICH RICHTIG MACHEN?
Insbesondere aber habe ich in den vergangenen zehn Jahren mit meinem Werkzeugkasten diverse schiefstehende SAP-Projekte als Projektleiter Nummer 3, 4 oder 5 neu aufgesetzt, restrukturiert und ins Ziel gebracht. Was mich ärgert, ist, dass man es auch von Anfang an hätte richtig machen können und der Kunde sich die Kosten für die erfolglosen Runden hätte sparen können. Mal ganz abgesehen davon, dass das richtige Neuaufsetzen des Projektes ungleich aufwändiger ist, wenn sich alle Beteiligten schon so herrlich an den Freestyle-Approach (nämlich der Abwesenheit von Methoden, Werkzeugen und Prinzipien) gewöhnt haben und die Änderung der Arbeitsweisen zum Übergang in geordnete Strukturen immer einen heftigen Kulturschock für das Projektteam bedeutet.
IN ALLER KONSEQUENZ
Im Verlauf all meiner Projekte wurde mein Werkzeugkasten mit der Zeit um gute, pragmatisch anzuwendende Tools ergänzt, so, dass er heute komplett ist.
Gelegentlich werde ich gefragt, weshalb einige dieser Werkzeuge noch auf so veralteten Technologien wie MS-Excel basieren und stattdessen nicht Cloud-Applikationen genutzt werden. Die Antwort ist einfach: es kommt gar nicht so sehr darauf an, welcher Einführungsmethode man in einem Projekt folgt oder welche Werkzeuge man anwendet – wichtig ist ganz einfach, dass man es tut und zwar in aller Konsequenz!
DAZU ZWEI INTERESSANTE ERFAHRUNGEN:
Die Erste: Ich war einmal als Rollout-Manager Central-Europe Teil des Programm-Mgt. eines weltweiten SAP-Rollout-Projektes. Das Projekt hatte rund 350 Mitarbeitende, und das PMO bestand aus fünf Personen und gab wöchentlich neue Richtlinien und Formate zum Budget-Reporting heraus. Dies bedeutete eine Sequenz, die es unmöglich machte, das Reporting im richtigen Format erstellen zu können, weil man immer wieder bei Null anfing. Ich habe dem PMO nach der dritten Änderung mitgeteilt, dass ich das Reporting jetzt komplett einstelle und es erst dann wiederaufnehme, wenn wir tatsächlich reporten. Nach ca. drei Monaten war es dann erstmalig soweit – als natürlich global schon alles aus dem Ruder gelaufen war!
Die zweite Erfahrung ist der Bericht eines Key-Users von vor wenigen Wochen. Als er sah, dass wir Testskripte in Excel machen wollten, sagte er, dass der Systemintegrator bei der Einführung von SAP eine „supertolle und fancy Cloud-Lösung“ hatte und das „richtig toll“ war; allerdings hätten sie nach ca. vier Monaten völlig den Überblick über ihre ToDos und OPs verloren, weil diese fancy Cloud-Lösung doch relativ kompliziert zu pflegen gewesen sei …
WERKZEUGE: BESSER ALT ALS CHAOTISCH
Da ist es mir doch allemal lieber, dass ich einfache und – aus der Sicht des einen oder anderen – vielleicht „veraltete“ Werkzeuge habe, die aber alle einfach anwenden können und bei denen auch alle Beteiligte den Überblick behalten. Unter Einsatz dieser Werkzeuge habe ich bislang in allen Projekten, die ich als kundenseitiger Projektleiter neu aufgesetzt habe, dem jeweiligen Kunden nachweislich mindestens das doppelte von dem, was er für mich als Honorar gezahlt hat, an veranschlagten Honoraren für den jeweils involvierten Systemintegrator eingespart – bei gleichem oder sogar besserem Erfolg in der SAP-Einführung. Ich finde das ist aus Ihrer Sicht, nämlich der Sicht des Kunden, ein erstrebenswertes Ergebnis. Wie das geht und wie auch Sie das bewerkstelligen können, möchte ich Ihnen im Rahmen dieses Blog-Projektes zeigen und beibringen.