Agiles BPM – viele Fragen

Nach dem dritten Workshop zum Thema agiles BPM gibt es wieder neue Fragen, für die es eine Antwort zu finden gilt. Zum einen haben wir unseren Fokus erweitert. Wir betrachten jetzt nicht mehr nur Scrum. Wir werden nun einzelne Aspekte von Agilität auf ihre Anwendbarkeit in BPM-Projekten prüfen.

Die These, das agile Techniken, Vorgehensmodelle, Prinzipien und Glaubensansätze in BPM Projekten einen Vorteil gegnüber klassischer Methoden haben steht immer noch. Vor allem im Punkt Geschwindigkeit und Flexibilität unterstützt die “Agilität” dabei BPM-Projekten erfolgreich durchzuführen.

Um diese These zu prüfen haben wir (Jakob Freund von camunda, Christian Weiss von oose, Martin Bartonitz von Saperion und ich von Seven Principles) uns anhand der Strukturen, die Christian in seinem Video aufzeigt weiter mit dem Thema beschäftigt. Hierbei haben wir wieder einmal festgestellt, dass die Projekte zum Thema BPM sehr sehr unterschiedlich sein können. Selbst wenn wir uns auf einen einfachen sehr IT-nahen Prozess festlegen. Die heutigen Technologien gehen von einer immer noch sehr programmierintensiven Durchführung (z.B. mit jBPM) bis hin zum Zero-Code “Entwicklung” (z.B. Intalio oder  inubit). Diese Unterschiede spiegeln sich natürlich in der Betrachtung welche agilen Komponenten sinnvoll eingesetzt werden können wieder.

Die für mich aktuell spannenden Fragen sind:

  • Wie gehe ich mit Iterationen im Bereich Zero-Coding BPMS um?
  • Worauf muss ich bei den Iterationen achten wenn diverse Schnittstellen betroffen sind?
    • Sind hier Interface Contracts und ein Enterprise Service Bus sinnvoll?
  • Ist es ggf. sinnvoll im BPM 2.0 Ansatz Prototyping anzuwenden?
  • Worauf muss ich achten wenn ich in meinen Iterationen einen hohen Grad an Abhängigkeit zu “Drittsystemen” habe? (z.B. wenn man auch Schnittstellen angewiesen ist ,die man konsumieren möchte, aber auf den Zugriff, bz. die fertigstellen nur bedingten Einfluss hat)
  • Wie kann man Projekte sinnvoll zerlegen? Wenn zu meinem Prozess z.B. noch eine GUI entwickelt werden muss, dann ist diese GUI-Entwicklung doch wieder ein klassisches Entwicklungsthema im BPM-Projekt
  • Wie behandelt man Change Requests im BPM-Projekt? Vor allem wenn diese CRs einen erheblichen Einfluss auf den Prozessablauf haben.

Bei diesen ganzen Überlegungen befinde ich mich wieder sehr nah an IT-Projekten. Es ist aber immer wieder wichtig zu erwähnen, dass der IT Anteil in BPM-Projekten häufig nur 20% des Gesamtprojekts ausmacht.

Prozesse für Scrum zerlegen

Wie im Artikel “Kick-Off: BPM + Scrum” den Jakob Freund auf bpm-guide.de veröffentlicht hat wollten wir noch Beispiele für verschiedene “Schnittmuster” einbringen. Ein Sprint bei Scrum soll zwischen 1 und maximal 4 Wochen dauern. Daher ist es ggf. notwendig einen Prozess in kleinere Einheiten zu zerlegen um diese Einheiten in den Sprints bearbeiten zu können. Da das Ergebnis eines Sprints ein “auslieferbares lauffähiges Produkt” sein sollte, müssen große Prozesse so geteilt werden, dass diese Teilprozesse sinnvoll und möglichst eigenständig ausgerollt werden können. Im Anschluss folgt mein Beispiel für das Zerlegen von Prozessen mit mehreren parallelen Prozesssträngen. (weiterlesen …)

Agiles BPM mit Scrum

Ich habe häufiger Erfahrung mit sehr langen Projekten zum Thema Business Process Management gemacht. Vor allem durch die Zusammenarbeit vieler Abteilungen in einem End-to-End Prozess wird ein Prozess immer größer und das Projekt immer schwer-fälliger. Obwohl viele Aktivitäten im Prozess häufig schon komplett geklärt und ggf. sogar schon fertig entwickelt worden sind kann der Prozess nicht eingeführt werden weil irgendwo eine kleine Aktivität noch abgestimmt werden muss. Durch eine agile Vorgehensweise könnten alle klaren Aktivitäten schneller implementiert werden und der gewünschte Erfolg könnte sich auch schneller einstellen. Daher ist das Thema Scrum sehr interessant, aber nicht ganz einfach. Scrum war ursprünglich für die Softwareentwicklung gedacht und nicht für BPM-Projekte. Meine ersten Gedanken zu dieser Kombination habe ich hier im Blog schon beschrieben (siehe Teil 1 und Teil 2). Die selben Gedanken haben sich auch Dr. Martin Bartonitz von Saperion und Jakob Freund von camunda gemacht. Um uns Auszutauschen und die Kombination Scrum und BPM zu diskutieren haben wir einen kleinen Workshop bei Jakob in Berlin abgehalten. Die Ergebnisse unseres ersten Workshops können auf bpm-guide.de nachgelesen und im Forum des BPM-Netzwerk diskutiert werden. Ich bin gespannt auf das Feedback im Forum.

Agiles Business Process Management – Teil 2

Im ersten Teil zum Thema Agiles Business Process Management habe ich meine ersten Gedanken verfasst, wie man Prozesse mit Hilfe von Scrum analysieren und modellieren kann. Im zweiten Teil möchte ich mich etwas genauer mit dem Thema beschäftigen.

(weiterlesen …)

Agiles Business Process Management

Agiles Projektmanagement ist ja zur Zeit vor allem in IT-Projekten total angesagt. Immer mehr Unternehmen interessieren sich für Scrum, XP und Co. weil viele Projekte, die nach klassischen PM-Methoden, durchgeführt werden scheitern. Gründe hierfür sind häufig die Komplexität von Projekten und eine schlechte Kommunikation.

Die selben Probleme kenne ich auch aus BPM-Projekten. Man verliert sich bei der Prozessmodellierung, -analyse und -design im Detail. Diese Phasen dauern häufig mehrere Monate. Die Prozesse die nach der Analyse designed werden sind schon zu Beginn des Designs nicht mehr aktuell, werden aber im Anschluss noch in irgendeinem System realisiert. Im Endeffekt passen die Prozesse nicht mehr zu den schon längst geändertem realen Business.

Bietet sich in diesem Umfeld eine agile Vorgehensweise an?

(weiterlesen …)