Jun
16
2010

agiles BPM – Fortsetzung 2

Wir haben unsere Workshops zum Thema agiles BPM (für Jene mit Vorlieben zu Akronymen auch gerne ABPM) am 8.6.2010 fortgesetzt. Zur Erinnerung: wir sind Vertreter der Firmen camunda services, Oose, 7 Principles und SAPERION, die prüfen, ob Projekte mit Umsetzungen von BPM-Kontexten nicht auch mit agilen Methoden durchgeführt werden können und wie das konkret aussehen kann. Es geht also nicht um agiles Vorgehen während der Sachbearbeitung sondern um die agile Umsetzungen von Änderungen der Organisation oder Technik zum Zwecke der Prozessoptimierung.Zu Beginn haben wir folgende Wahrnehmungen aufgeschrieben

  • Sind Workflows auf Basis von BPMS/WMS zu starr? Siehe dazu u.a. den Post Wird die nächste Generation von Workflow-Systemen adaptiv? Würden Umsetzungen mit Workflow-Systemen zu starren Prozessen führen, sehen wir dies im Widerspruch zur Selbstorganisation bzw. zur Werkzeugkasten-Metapher. So werden ECM-Systeme mit der flexibleren Aktenbearbeitung scheinen deutlich mehr verkauft zu sein als BPMS/WMS. Allerdings ist dieser Widerspruch für die Art und Weise der Durchführung eines BPMS-Projektes selbst nicht relevant.
  • Wir sehen ein Zusammenwachsen von ECM, WfM/BPM und CRM zu neuen Systemen. Siehe hierzu auch den Post WfMC´s Vordenker proklamierten Ende 2009 in Maidenhead die nächste BPM-Revolution mit Adaptive Case Management
  • Abläufe ändern sich schneller als sie gemalt werden können. Daher könnten Systeme besser mit nach Relevanz sortierten Vorschlägen für die nächste auszuführende Aktivität arbeiten. Wird eine Aktivität mit bisher niedrigerer Relevanz vom Benutzer ausgewählt, erhöht sich ihre Relevanz und die der anderen wird erniedrigt. So justiert sich das System auf Basis der gerade typischen Verfahren adaptiv.

Anschließend haben wir uns für die weiteren Arbeiten die folgende Leitfrage gestellt: “Wie passen agile Werte zu einem Wf-Projekt mit geringem Änderungsausmaß?” (Beispiel Implementierung einer Eingangsrechnungsfreigabe).

Wir haben uns dazu an den Werten des SCRUM Manifestes orientiert.

Individuals & interactions over processes and tasks

  • Uns scheint, dass Unagilität nur in den Köpfen steckt. Es gibt bei Wf-Projekten kein dediziertes Vorgehensmodell oder eine Tool-Restriktion, die Agilität verhindern.

working software over comprehensive documentation

  • Wf-Modellierung auf dem für BPMS notwendigen Detaillierungsniveau ist dichter am ausführbaren Code als Geschäftsprozesse in klassischer Software-Entwicklung
  • Prozessarchitekturen (Wertschöpfungsketten der Ebene 1 + 2) sind in der Regel unnötig (siehe Prämisse: es wird nur der eine Prozess umgesetzt)
  • Beschreibungstiefe (Ebenen nach Bruce Silver): Ebene 1 + 2 kann mit Epen + User Stories gehandhabt werden
  • Noch zu klären: Behindert Zero-Code-Ansatz der BPMS die Agilität, sprich zwingt er ein Korsett auf?
  • BPMS können Agilität bzw. Rapid Prototyping fördern, vorausgesetzt sie sind evaluiert. Ein gutes hausinternes Framework leistet ggf. Ähnliches.
  • These: BPMS bilden jedoch oft ein engeres Korsett als hauseigene / quelloffene Frameworks, da schon Workarounds bei bereits normaler komplexität implementiert werden müssen.
  • These: BPMS werden öfter in “schwerfälligen” Organisationen eingesetzt wo noch das Wasserfallmodell in den Köpfen steckt (Wie viele “Blaue” Unternehmen setzen BPMS ein?).
  • These: In BPM-Projekten im unteren, rechtem Quadranten kann sehr gut agil vorgegangen weren. Es hängt eher am Ausmaß der organisatorischen Änderungen und an kulturellen Fragen, ob hier Agilität funktioniert.

customer collaboration overcontract negotiation

  • Empfehlung: der SCRUM Product Owner in einem BPM-Projekt solte derjenige sein, dern Wert empfängt. Dies ist in der Regel der Process Owner oder ein Bevollmächtigter.

responding to change over following a plan

  • Wie sehen die Änderbarkeit in BPMS-Projekten einfacher, weil der Prozess ständig transparent ist und weil das Tooling Änderungen gut unterstützt. Dabei sollte der Prozess nicht über den Zaun geworfen werden und nie wieder begutachtet werden. ggf. können in BPM-Projekten die Iterationen sogar kürzer sein als in “klasssich-agilen” Projekten

Ergänzung vom 19.08.2010:

Ich habe folgenden schönen Artikel mit dem Titel Interview: Wie agil ist BPM? gefunden. Tenor: auch in BPM-Projekten macht ein agiles Vorgehen Abwicklung des Projektes Sinn.

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to MySpace

Download PDF
Written by Dr. Martin Bartonitz in: deutsch,general | Tags: ,

No Comments »

RSS feed for comments on this post. TrackBack URL

Leave a comment


3 + = five

Theme: TheBuckmaker.com Web Templates | Bankwechsel Umschuldung, Iplexx IT Solutions