Vor einem Fußballspiel wählt der Trainer die elf Spieler und die taktische Ausrichtung , die angesichts des Gegners, der Platzverhältnisse und anderer Faktoren den größten Erfolg versprechen. Ob seine Strategie aufgeht, zeigt erst das Spiel. Tut sie es nicht, bespricht sich der Coach mit dem Kapitän, verändert Positionen und wechselt aus. Er geht mit einem Plan ins Spiel und passt ihn flexibel den Umständen an, die er unmöglich alle voraussehen kann. Kurz gesagt: Ein guter Trainer vereint Strategie mit Pragmatismus.
Foto: Ismagilov - shutterstock.com
Diese einfache und einleuchtende Vorgehensweise lässt sich durchaus auf die prozessorientierte Einführung von SAP-Software übertragen. Die bislang eher für Entwicklungsprojekte genutzte Scrum-Methode kann dabei helfen. Denn Agilität und Business-Prozess-Management (BPM) schließen sich keineswegs aus.
Scrum für SAP - fünf Tipps
Nehmen Sie sich Zeit zur Definition der Geschäftsszenarien, die Sie mit SAP-Produkten unterstützen wollen. Beginnen Sie bei Ihren Geschäftsmodellen und den Strukturen Ihrer Geschäftsabläufe.
Mit professioneller Unterstützung beim Aufbau der Prozesslandkarte und beim Prozessdesign können Sie den Implementierungsaufwand möglicherweise um bis zu 30 Prozent verringern.
Nutzen Sie das volle Potenzial der Scrum-Methode: Jeder Entwicklungszyklus enthält Prozess- und Solution-Design, Umsetzung, Test sowie die Anpassung der Dokumentation.
Haben Sie keine Angst: Agil heißt nicht ungeplant. Projektumfang, Budget, Aufwände und Zeit sollten laufend mit dem Baseline-Plan verglichen und dann strukturiert durch das Projekt-Management angepasst werden.
Geben Sie Ihrer Organisation die Chance, die Methode und mit der Methode zu lernen. Klar definierte und formulierte Ziele im Einklang mit Ihrer Unternehmensstrategie sollten die Leitlinie vorgeben, um den dynamischen Transformationsprozess - und nicht nur eine technische SAP-Einführung - erfolgreich zu durchlaufen.
Komplexer als das Ideal
Werfen wir zunächst einen Blick auf SAP-Implementierungen nach klassischem Muster: Da sich Prozesse in unterschiedlichen Unternehmen zumindest ähneln, sind die SAP-Produkte weitgehend standardisiert. Das schließt auch die Anleitungen zur Einführung sowie die Schulung der Mitarbeiter ein. Diese vorgegebenen Strukturen bieten dem Management Vorteile: Neue Prozesse sind hinsichtlich Konzeption und Design schon fix und fertig, sie lassen sich im Voraus sowie en détail planen. Die Leitungsebene weiß also genau, wofür sie das Geld ausgibt. Zudem behält sie von Anfang bis Ende den Überblick sowie die Kontrolle über Zeiträume und Ressourcen.
Einem solchen Ideal folgen Entscheider gern. Tatsächlich erweisen sich SAP-Einführungen dann aber oft als weitaus komplexer: Auf der einen Seite steht der Wunsch nach klaren und stabilen Vorgaben für die Software-Implementierung und nach weitgehender Standardisierung aller Prozesse, welche die Komplexität mindert. Auf der anderen Seite gibt es den Anspruch auf Agilität - die Fähigkeit, Prozesse rasch und flexibel an Rahmenbedingungen und sich ändernde Kundenwünsche anzupassen.
Es kommt durchaus vor, dass die Zielvorstellungen der Unternehmensleitung nicht von vornherein klar umrissen sind; folglich werden Anpassungen während der Implementierung nötig. Zudem kann sich herausstellen, dass die standardisierte Software den Erwartungen und Bedürfnissen der Anwender nicht ganz entspricht. Auch dann sind Änderungen unumgänglich. In dynamischen Branchen mit hohem Innovationsgrad herrscht ohnehin der Druck, Unternehmensprozesse rasch an neue Marktentwicklungen anzupassen. Dort werden die Prozesse also ständig revidiert und optimiert.
Kontrolle und Flexibilität kombiniert
Wie lassen sich also die beiden Anforderungen Kontrolle und Flexibilität miteinander in Einklang bringen? Die Antwort heißt: Scrum BPM, allgemeiner auch Agiles BPM. In der Praxis erweist sich der Mix aus begleitendem Prozessdesign und kontrolliertem Kontrollverlust als erfolgversprechende Strategie.
Die "agile" Scrum-Methode hat sich nicht nur bei der Entwicklung, sondern auch bei der Implementierung von Software bewährt. Wie funktioniert sie? Im Kern gliedert sich die Entwicklung der Software in kurze Phasen ("Sprints"). Während der Sprints werden die bis dahin entwickelte Software und die Arbeitsprozesse gemeinsam mit den Anwendern getestet. Mit jedem Durchlauf kommt man dem künftigen System näher. Ein hemdsärmeliges, äußerst pragmatisches Verfahren.
Scrum bietet eine ganze Reihe von Vorzügen:
Das System wird quasi optimiert, während es funktioniert.
Der enge Austausch zwischen Softwarespezialisten und Anwendern sorgt dafür, dass sich sowohl der Wunsch der Führungsetage nach Kontrolle als auch die kreativen Impulse und Verbesserungsvorschläge der Nutzer berücksichtigen lassen.
Zudem nimmt die Vorgehensweise der Leitung die Last ab, alle notwendigen Anpassungen der Software an die unternehmensspezifischen Prozesse im Voraus planen zu müssen, was ohnehin selten gelingt.
Und wie soll nun der IT-Verantwortliche unter diesen Umständen die Kontrolle behalten? Schließlich trägt er gegenüber der Geschäftsführung die Verantwortung für die Entwicklung oder Implementierung. Hierbei hilft ihm eine Unternehmens-Prozesslandkarte (Process Repository), wie sie auch im klassischen BPM-Ansatz häufig erstellt wird. Sie gewährt den Überblick über alle "Baustellen", während Prozesseigner und Experten iterativ an der Transformation einzelner Prozesse arbeiten.
Purchase-to-Pay als Prozessbeispiel
Ein Beispiel soll das Zusammenspiel von prozessbasiertem Vorgehen und einer agilen Methode wie Scrum veranschaulichen: Der Prozesseigner von Purchase-to-Pay (P2P) definiert gemeinsam mit den Experten in seinem Team die End-to-End-Szenarien, basierend auf den Geschäftsmodellen und den damit zusammenhängenden Operating-Modellen der Firma. Die grundlegenden Charakteristika und Anforderungen finden - auf einem High-Level-Niveau - Eingang in ein "Product Backlog."
Während des ersten Sprints werden dann grundlegende Szenarien wie die Beschaffung von Zulieferprodukten ("Purchasing of supply chain materials"), der Einkauf von Dienstleistungen ("Purchasing of services") und der von Verbrauchsgütern ("Purchasing of consumables") angepasst sowie getestet. Dabei entstehen dann auch die Anwendungsdokumentationen. Und deshalb ist der Prozesseigner nachfolgend in der Lage, die künftigen Prozesse in diesem Bereich zu simulieren.
So lassen sich die Prozesse im Detail abstimmen. Zudem kann der Process Owner auf dieser Basis auch ausgefeiltere Prozesse entwerfen, in unserem Beispiel etwas das"Purchasing of subcontracting with materials".
Aus Sicht des Business erlaubt Scrum definitiv höhere Qualität und Genauigkeit in der Formulierung von Anforderungen. Es ermöglicht die Konzentration auf das wirklich Benötigte. Und damit ist das Fundament für eine erfolgreiche Implementierung bereitet.
Mehr als Rapid Prototyping
Ähnliche Ziele wie Scrum BPM verfolgt im klassischen prozessgetriebenen SAP-Ansatz die Funktion des Rapid Prototyping. Im Vergleich dazu bietet das agile BPM aber einen weiteren Vorteil: Indem es das Prozessdesign mit einer agilen Methode integriert, fördert es von Anfang bis Ende einen gemeinsamen Lernprozess von Anwendern, IT-Experten und Management.