Neue Ausgabe des Kundenmagazins InnovateIT verfügbar

Seite 8 | InnovateIT | Ausgabe 03 | November 2013
Business & IT
Lieber agil oder klassisch?
Immer häufiger werden wir von Kunden gefragt, ob wir ein BPM/BRM-Projekt auch agil durchführen
können. Deshalb stellen wir in dieser Ausgabe der InnovateIT dar, was ein agiles BPM/
BRM-Projekt von einem „klassischen“ BPM-/BRM-Projekt unterscheidet und wann es sinnvoll
ist, eine agile Projektdurchführung zu etablieren.
Problemstellung
Klassische BPM/BRM-Projekte werden
durch einen einmaligen Durchlauf
der ersten vier Schritte des
BPM-Lebenszyklus „Modellieren-
Simulieren-Implementieren-Testen-
Ausführen-Analysieren-Verbessern“
durchgeführt. Hierbei wird davon
ausgegangen, dass die Anforderungen
an die Lösung bereits in frühen
Projektphasen vollständig verstanden
und dokumentiert werden können,
z.B. in Form von vollständigen
fachlichen Prozessmodellen.
In der Praxis hat sich jedoch gezeigt,
dass die tatsächlich benötigten Anforderungen
an die Lösung initial
nicht immer richtig eingeschätzt
werden können. Dies kann verschiedene
Ursachen haben. Typisch im
BPM/BRM-Umfeld ist der Erkenntnisgewinn,
den viele Unternehmen
während der Einführung einer BPM/
BRM-Lösung durchlaufen: Eine
neue Technologie ermöglicht neue
Wege der Problemlösung, generiert
aber auch Fragestellungen, die anfänglich
nicht ersichtlich
waren.
Lösungsansatz
In Software-Entwicklungsprojekten
sind „unscharfe“ Anforderungen
zu Projektbeginn seit längerem bekannt.
Erfolgreiche Lösungsansätze
adressieren diese Herausforderung
mit der Etablierung agiler Methoden,
wie z.B. Scrum. Diese Methoden
basieren auf den Prinzipien des
Agilen Manifestes (siehe auch http://
agilemanifesto.org/). Anhand ausgewählter
agiler Prinzipien möchten
wir diese vorstellen und reflektieren,
wie sich diese zum Vorteil auf Ihre
BPM/BRM-Projekte auswirken können.
Prinzip 1
„Unsere höchste Priorität ist es, den
Kunden durch frühe und kontinuierliche
Auslieferung wertvoller Software
zufrieden zu stellen.“ – Viele
„klassische“ BPM/BRM-Projekte
haben eine lange Analyse- und Designphase,
in welcher die Prozesse
modelliert und diskutiert werden.
Wie eine mögliche Umsetzung die
tatsächlich gelebten Prozesse beeinflusst,
kann oftmals erst
spät ermittelt werden
– in einigen Fällen
zu spät, um
eine breite Akzeptanz zu erzielen.
Im Gegensatz zu herkömmlichen
Applikationen sind die Vorteile
prozess- und regelgetriebener Anwendungen
oftmals nicht aus der
Arbeitspraxis bekannt und können
daher nur bedingt auf die mögliche
Lösung projiziert werden. Agile
BPM/BRM-Projekte machen diese
Komplexität handhabbar, in dem sie
die Erstellung der Lösung in viele
kleine Teillösungen, welche jede für
sich bereits nutzbar ist, zerlegen.
Das Projekt wird dazu in sogenannte
„Sprints“ mit einer Länge von 2 bis
4 Wochen aufgeteilt. Jeder „Sprint“
durchläuft den gesamten BPM-
Lebenszyklus um dem Anwender
Mehrwerte bereitzustellen und sein
Feedback zu berücksichtigen.
Prinzip 2
„Heiße Anforderungsänderungen
selbst spät in der Entwicklung willkommen.
Agile Prozesse nutzen
Veränderungen zum Wettbewerbsvorteil
des Kunden.“ – Durch die
Aufteilung in einzelne Sprints besteht
in kurzen Abständen die Möglichkeit,
Anforderungsänderungen
in das Projekt einzubringen. Fokussiert
wird dabei immer auf Anforderungen,
welche einen erhöhten Geschäftsnutzen
bringen – auch wenn
diese initial nicht vorgesehen waren
– ganz ohne teure und langwierige
Change Requests.
Prinzip 3
„Einfachheit - die Kunst, die Menge
nicht getaner Arbeit zu maximieren
- ist essenziell.“ – Zur Erreichung
des erhöhten Geschäftsnutzens geht
Qualität vor Quantität. Dabei werden
bereits in der Analyse- und De-