Ein langer Tag geht zu Ende. Heute war ich Gast auf dem 5. PSD der gfo (www.gfo-kongress.de). In 3 parallelen Streams wurden diverse BPMS von den Herstellern vorgestellt. Jeder Hersteller hatte 45 Minuten Zeit zu einem von 3 Themen Stellung zu beziehen. Das erste Thema war Modellierung und Dokumentation. Thema zwei war SOA und Thema drei Human Workflows und Prozessportale. Ich habe mir hauptsächlich die Vorträge zum Thema Human Workflow angesehen.
Ich bin doch positiv Überrascht, wie weit die Toolhersteller mittlerweile sind. Alle vorgestellten Produkte waren ausschließlich Zero-Coding Lösungen. Im Kern der BPMS sind kaum noch Unterschiede auszumachen. Alle unterstützen Prozessversionierung, Rollen, Dokumentenanhänge und diverse Schnittstellen zu Drittsystemen. Im Detail steckt aber der Teufel. Einige der Tools kommen mit selbst entworfenen Modellierungsnotationen daher. Leider musste ich auch feststellen, dass einige der Präsentatoren von Prozessmodellierung an sich nicht viel Ahnung hatten (Wer nennt bitte eine Aktivität “Vorgesetzter”???). Generell waren die größten Unterschiede in der Modellierung zu finden. Während in einigen Tools die Prozessmodelle sehr technisch modelliert werden müssen (sind fast schon modell-view controller) sind andere Hersteller weiter und dort können sehr Business-nahe Prozesse an die Engine übergeben werden (z.b. bei Xpert.Ivy oder Appian) oder es werden sogar verschiedene Modellebenen berücksichtigt (wie bei inubit).
Zuerst muss ich jetzt erst mal die ganzen Eindrücke verarbeiten. Es gibt keine kompaktere Möglichkeit sich über eine so große Zahl an Produkten zu informieren. Einige der Tools werde ich mir in den nächsten Wochen auf jeden Fall noch mal genauer angucken.

In den folgenden Wochen möchte ich eine kleine Serie veröffentlichen mit nützlichen Tipps rund um das Thema Business Process Management. Dieser Artikel ist der erste dieser Serie, die insgesamt 20 Tipps beinhalten wird. Die ersten drei Tipps befassen sich mit den Themen Standards, Erfahrung und unvollständigen Prozessmodellen. (weiterlesen…)

Es existieren mittlerweile einige gute BPM-Systeme und -Suiten die es ermöglichen Prozesse komplett ohne Programmierung zu realisieren. In einigen Tools wird mehr modelliert und in anderen eher konfiguriert. Durch die stetige Verbreitung anerkannter Standards (von WebServices, über BPEL und auch BPMN) haben auch die Software-Hersteller eine immer breitere Basis auf denen ihre Tools aufgebaut werden können.

Doch wo liegen die Chancen und Risiken der auf dem Markt existierenden Zero-Coding-Lösungen? (weiterlesen…)

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.

Im Anschluss an einen BPM-Vortrag, den ich in München gehalten habe, kam es zu einer sehr interessanten Diskussion. Ein Teilnehmer sagte, dass das mit dem Business Process Management ja ganz schön ist, aber ihm war nicht klar, wie ein Unternehmen BPM jetzt einkaufen kann. Wie bekommt man all die schönen Vorteile die man mit BPM hat? Die Frage des Teilnehmers kam etwas unerwartet, aber dennoch zurecht.

Hierzu muss ich noch kurz erwähnen, dass ich unter anderem BPM als Ganzes vorgestellt habe und mich hierbei an das BPM CBOK angelehnt habe. Ich erläuterte die 9 Wissensgebiete und was jeweils in den einzelnen Gebieten für Tätigkeiten anfallen.

Ich denke man kann BPM an sich nicht kaufen. Business Process Management ist unverkäuflich! (weiterlesen…)