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.
- Retrospektive und Feedback in Scrum-Projekten
Scrum Manager haben die Möglichkeit, den Projekterfolg durch die Analyse des Sprints zu verbessern. Zielführend sind dabei die Retrospektive und das Feedback der Teammitglieder - ein Vorgang, den der Scrum Manager mit Diplomatie moderieren muss. Folgende Methodik mit Arbeitsblättern hat sich bewährt. - Feedback - Schritt 1
Für die Retrospektive erhält jedes Teammitglied ein vorbereitetes Blatt mit seinem Namen und zwei Fragen: "Was kann man von mir erwarten?" und "Was erwarte ich vom Team?" - Feedback - Schritt 2
Der Feedback-Bogen wird um zwei Bereiche ergänzt: "Was ich an Deiner Arbeit schätze ..." und "Was ich Dir wünsche, das Dir besser gelingt ..." - Feedback -Schritt 3
Der Feedback-Bogen wird an den Tischnachbarn weitergegeben, von diesem ausgefüllt und so lange weitergegeben, bis jeder Teilnehmer wieder sein persönliches Blatt vor sich liegen hat – jetzt mit dem schriftlichen Feedback aller beteiligten Teammitglieder. - Selbstreflexion
Zwei weitere Bereiche kommen hinzu – sie dienen der eigenen Reflexion des erhaltenen Feedbacks: "Darauf bin ich stolz ..." und "Das nehme ich mit ..." - Vorgehensmuster
Nach diesem Grundmuster lassen sich Retrospektiven zu einem späteren Zeitpunkt erneut wiederholen.
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.
- Schneller als Plan-Build-Run
Die Anforderungen an Software verändern sich im Laufe der Entwicklung oft erheblich - anders als bei einem Auto zum Beispiel. Dem tragen agile Methoden wie Scrum Rechnung. - Besseres Ineinandergreifen
Bei traditioneller Softwareentwicklung greifen Zahnräder oft nicht ineinander, sondern sie rotieren nebeneinander vor sich hin. Scrum sorgt für nahtlosere Prozesse. - Jeder spricht mit jedem
Bei vielen Softwareprojekten mangelt es an gelungener Kommunikation, bei Scrum ist regelmäßiges Feedback für alle Beteiligten Pflicht. - Mehr Qualität
Mit Hilfe von Scrum entwickelte Software ist in der Regel besser als andere, weil hier frühzeitig das Feedback der Kunden integriert wurde. - Chaos führt nicht zu Panik
Chaotisch ist Scrum insofern, als sich der damit verbundene Prozess nicht einfach mit einem Pfeil beschreiben lässt, der links auf dem Blatt Papier anfängt und irgendwo rechts aufhört. Sondern er ist mehrdimensional. Wenn sich alle an bestimmte Regeln halten, läuft trotzdem nichts aus dem Ruder. - Im Mittelpunkt: Der Mensch
Scrum heißt Gedränge. Und es bedeutet, den Menschen in den Mittelpunkt zu stellen in dem Sinne, dass ihm die Methode ermöglicht, effizient und gleichzeitig kreativ zu arbeiten. - Automatisierte Tools statt Selbstgestricktes
Oft verwendet jede Abteilung eigene Anwendungen, um Entwicklungsschritte zu dokumentieren, zum Beispiel Excel. Automatisierte, vor allem einheitliche Tools beschleunigen hier die Abläufe erheblich. - Nicht nur am Ende testen
Zeitgemäße Entwicklungsumgebungen erlauben es, auch einzelne Module zwischendurch zu testen, um immer auf dem neuesten Stand zu sein.
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.
- Kleines Scrum-Glossar
Was meint eigentlich Scrum, Product Owner oder Backlog? Wir stellen Ihnen die wichtigsten Begriffe und ihre Bedeutung vor. - Scrum
Der Begriff stammt aus dem Rugby und bedeutet wörtliche "Gedränge". In der Softwareentwicklung bezeichnet er ein Vorgehensmodell der agilen Softwareentwicklung, das 1995 von Ken Schwaber, Jeff Sutherland und Mike Beedle veröffentlicht wurde. - Das Scrum-Team
Aufgabe des Teams ist es, die Anforderungen der Fachabteilung umzusetzen. Es bietet drei Rollen: - 1. Rolle: Product Owner
Er vertritt den Auftraggeber, also die fachliche Seite. Also zeichnet er für die Priorisierung der Anforderungen verantwortlich und letztlich auch für den Nutzen, den das Projekt dem Unternehmen bringt. - 2. Rolle: Scrum-Master
Er ist quasi der Herr über die Prozesse. Er sorgt dafür, dass die Scrum-Regeln im Projekt eingehalten werden, er fördert die Transparenz, unterstützt das Team bei der Beseitigung von Hindernissen und sucht ständig nach möglichen Verbesserungen. - 3. Rolle: Die Entwicklergruppe
Sie besteht idealerweise aus sieben Entwicklern. - Sprint
Mit diesem Begriff bezeichnet Scrum einen Iterationszyklus, innerhalb dessen ein Scrum-Teams eine Anforderung umsetzt. Ein Sprint dauert mindestens zwei Wochen und maximal einen Monat. - Backlog
So heißt in Scrum die priorisierte Anforderungsliste für das zu entwickelnde Produkt. Sie wird vom Product Owner verantwortet und gepflegt. - Definitionen von fertig
Dabei handelt es sich um die Kriterien, unter den ein Produkt als umgesetzt akzeptiert wird.
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. (qua)