Neue Ausgabe des Kundenmagazins InnovateIT verfügbar

Weitere Magazine

Empfehlungen

Info

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-
November 2013 | Ausgabe 03 | InnovateIT | Seite 9 Business & IT Die BPM+ Modulation im Überblick signphase jedes Sprints nur so viele Anforderungen wie nötig detailliert ausgestaltet. Wichtig ist nicht die Umsetzung möglichst vieler Features (beschrieben als „User Stories“), sondern die erfolgreiche Umsetzung der Dinge, die am meisten Nutzen bringen. Kriterien für agile BPM/BRM-Projekte Neben den notwendigen Grundlagen im Bereich agiler Methoden, wie z.B. Scrum und einer ganzheitlichen BPM/BRM-Projektmethodik, wie z.B. IBPM (http://enterprise-bpm. org), müssen verschiedene Kriterien vor der Entscheidung bezüglich einer klassischen oder agilen Projektdurchführung berücksichtigt werden. Für die Zusammensetzung des Teams stellen sich u.a. die folgenden Fragen: Welche Mitarbeiter sollen das Projekt durchführen? Sind diese eher offen gegenüber Neuerungen oder konservativ eingestellt? Wie verfügbar sind die Mitarbeiter? Können sie nur zeitweise oder ständig mitarbeiten? Sind die Mitarbeiter über mehrere Standorte verteilt oder zentral an einem Ort? Arbeiten die Mitarbeiter an mehreren Projekten gleichzeitig? Haben diese bereits Erfahrungen mit agilen Methoden? Für den Projektleiter stellen sich u.a. diese Fragen: Wie ist die Kundenbeziehung? Langfristig etabliert oder neu? Gibt es ein feststehendes Go- Live? Welches Vertragsmodell soll zugrunde gelegt werden? Festpreis oder Zeit und Material? Wie groß ist das Projekt? Wie viele Abhängigkeiten gibt es? Worum geht es in dem Projekt? Ist es eine Neuentwicklung oder die Ablösung einer komplexen Anwendung? Erst wenn diese Fragen geklärt sind, sollte die Entscheidung für oder wider einer agilen Projektdurchführung getroffen werden. Autoren: Frank Puhlmann, Christian Thiemich Bosch Software Innovations bietet mit der wissenschaftlich fundierten, agilen BPM-Projektmethodik eine agile Erweiterung der erprobten IBPM- Projektmethodik sowohl zur Durchführung von Projekten als auch zum Coaching an. Neben den im Artikel aufgezeigten Aspekten für oder wider einer agilen Projektdurchführung gibt es eine vollständige Methodik, bestehend aus verschiedenen Artefakten, Aktivitäten und Methoden (siehe Abbildung).
Seite 1 und 2: Bosch Software Innovations | Kunden
Seite 3 und 4: November 2013 | Ausgabe 03 | Innova
Seite 7: Info von 6,5 Mrd. Menschen sind 15%

Neue Ausgabe des Kundenmagazins InnovateIT verfügbar

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?