Liebe BPM-ExpertInnen!

Wir haben tolle Neuigkeiten: ab Mai kommenden Jahres bietet oose für alle OCEB Fundamental Zertifizierten das langersehnte Vorbereitungstraining zum “OCEB Business Intermediate”-Zertifikat an (als offenes Training in Hamburg oder auch bei Ihnen im Haus).

Nähere Infos zu Terminen und Inhalten finden Sie hier: http://bit.ly/pGA4sV

Am besten rechtzeitig buchen. Wir rechnen aufgrund der jetzt schon vorhandenen großen Nachfrage mit voller Belegung.

Besten Gruß von den OCEB-Machern!
Christian Weiss

   

oose hat eine neue Analysemethode für Geschäftsprozesse namens BizMod entwickelt. Mit BizMod können Geschäftsprozesse mit Hilfe der Business Process Model and Notation (BPMN) und der Unified Modeling Language (UML) beschrieben werden. Die neue Methode zur Geschäftsprozessanalyse nutzt die Sprache BPMN, weil BPMN es erlaubt, den Ablauf eines Prozesses mit allen Finessen zu modellieren. Für eine vollständige Beschreibung werden aber auch Kontext, Produkt-, Organisationsstrukturen etc. benötigt, die nicht Teil der BPMN sind. Dafür gibt es andere Modellierungssprachen, wie zum Beispiel UML. Bei BizMod werden daher BPMN und UML kombiniert, um Prozesse umfassend zu modellieren. Dadurch ermöglicht diese Analysemethode eine konsistente Modellierung von Geschäftsprozessen inklusive Unternehmenskontext, Produktstrukturen und Zuständen, Organisationsstrukturen sowie Rollen. Ein BizMod Plug-In für Magic Draw ist auch in Planung und wird noch diesen Sommer veröffentlicht.

Weitere Informationen zu BizMod stehen unter www.bizmod.de bereit.
Die vollständige Presseinformation finden Sie hier.

   

Auf der REConf 2011 in München haben wir letzte Woche unsere BizMod-Methode vorgestellt:

BPMN + UML = BIZMOD -> eine Analysemethode für Ihre Geschäftsprozesse

Die BPMN ist im Kommen. Zur Modellierung von Prozessen ist sie unschlagbar. Was aber ist mit Kontext, Fachklassen, Organisationsstrukturen …? Diese Konzepte fehlen in der BPMN, und zwar mit Absicht. Es gibt dafür ja schon Modellierungssprachen: zum Beispiel die gute alte UML. Wie verbindet man nun beides zu einem zusammenhängenden Modell? Diese Frage beantwortet BizMod, die von oose entwickelte Methode zur ganzheitlichen Prozessanalyse mit BPMN und UML. Die Präsentation und weitere Informationen finden Sie auf der Seite www.oose.de/bm/bizmod.html.

Wir sind zur Zeit in der Abstimmung mit Toolherstellern, die ein BizMod Plug-In anbieten werden. Die Freigabe erwarten wir im April. Dazu werden wir dann auch einen Blogeintrag veröffentlichen.

   

Die Firma Norics GmbH aus Norden in Ostfriesland plant mit oose eine Veranstaltung zum Thema Geschäftsprozessmodellierung. Tim Weilkiens wird dort einen Vortrag halten, um über die aktuellen Trends aus der Welt der Geschäftsprozesse zu berichten.

Weitere Informationen zu der Veranstaltung finden Sie hier.

   

Letzten Montag (24. Mai) haben wir den Bericht der “Finishing Taskforce” für die BPMN 2.0 abgegeben. Es gibt zwei wichtige Änderungen an der Spezifikation, neben 178 eher kleineren Korrekturen: Davon ist die erste kosmetisch, die zweite hat ein komplettes Kapitel aus der Spezifikation gestrichen, nämlich das Konversationsdiagramm. Das Konzept gibt es natürlich weiterhin, es wurde nur einfach mit ins Kollaborationsdiagramm aufgenommen. Und da wächst zusammen, was zusammen gehört. Eine Konversation ist eine logische Gruppierung von Nachrichten, die zwischen Konversationspartnern ausgetauscht werden. Die Nachrichten in der Gruppe werden in einer Kollabaration explizit dargestellt. Beide Darstellungsformen sind also nur unterschiedliche Abstraktionsebenen des gleichen Sachverhalts. Konsequenterweise ist es daher jetzt auch wie bei Kollaborationen möglich, nicht nur Pools sondern auch Aktivitäten direkt mit Konversationen zu verbinden. Und da kommen wir zur kosmetischen Änderung: Damit Konversationslinks nicht mit Sequenzflüssen verwechselt werden können, werden sie jetzt mit Doppellinie gezeichnet.
Ein Beispiel: oose unterhält sich mit einem Kunden über einen Coachingauftrag. Statt die einzelnen Nachrichten anzuzeigen, wird nur die Konversation dargestellt.

Insgesamt haben wir in der Taskforce 374 offene Punkte bearbeitet. 180 davon führten auch wirklich zu einer Änderung, der Rest waren Dubletten, abgelehnte Vorschläge oder wurden einfach vertagt auf die folgende “Revision Taskforce”. Die aktuelle Version ist nun gespickt mit Änderungsmarkierungen. Der Eindruck, dass sich viel geändert hat, täuscht allerdings: Hauptsächlich handelt es sich um kleinere Änderungen, wie Tippfehler und Klarstellungen. Typisch ist zum Beispiel die Ersetzung  von “may” und “required” durch “can” und “needed”.
Der Termin an dem die Finishing Taskforce die Entscheidungsvorlage abgeben muss, wurde übrigens auf den 2. Juli verschoben. Daher dürfte die Verabschiedung als offizielle Spezifikation erst beim darauf folgenden Technical Meeting im September stattfinden.

   

Als Video:
In meinem letzten Beitrag habe ich aufgezeigt, warum wir damit beginnen sollten, das in agilen Ansätzen destillierte Wissen und Gedankengut auf BPM-Projekte zu übertragen, um sie damit erfolgreicher zu machen.
Und jetzt wollen Sie sicher wissen: Wie adaptiert man nun die agile Welt auf die BPM-Welt?
Lassen Sie uns hierfür zunächst schauen, was genau wohin genau adaptiert wird.

Der erste Schritt zu agilem BPM lautet: Welche Arten von BPM-Projekten sollten wir unterscheiden, damit klar wird, worauf wir die Abbildung von Agilität abzielen?

• Reden wir über große SOA-Projekte? Oder über eher kleinere Workflowautomatisierungen?
• Reden wir überhaupt über IT-Projekte oder über Organisationsprojekte, z. B. über die Optimierung rein organisatorischer Abläufe?
• Oder geht es vielleicht darum, ganz im Sinne des Business Process Reengineering völlig neue Prozesse für neue Produkte oder Märkte zu erschaffen?

Sie sehen schon: bei BPM-Projekten gibt es zwei relevante Unterscheidungsmerkmale

1. der Automatisierungsgrad und
2. das Veränderungsausmaß

Beide Merkmale stehen orthogonal zueinander und spannen auf diese Weise vier Kategorien von BPM-Projekten auf:

Vereinfachend unterscheiden wir demnach

• Organisationsprojekte mit hohem und
• mit geringem Veränderungsausmaß sowie
• IT-Projekte mit hohem und
• mit geringem Veränderungsausmaß

Diese Unterscheidung auf der Seite der BPM-Welt ist deswegen hilfreich, weil sich (wie Sie gleich sehen werden) je nach Projektkategorie andere Fragen stellen.
Auf der anderen Seite ist spannend „was genau aus der agilen Welt wollen wir eigentlich nutzbar machen?“

• Einzelne in agilen Projekten typische Praktiken, z. B. Timeboxing, Continuous Integration oder Test first?
• Oder komplette Agile Prozesse, z.B. SCRUM, APM oder XP?
• Oder wollen wir agile Prinzipien auf die BPM-Welt übertragen, also Leitlinien, die agile Überzeugungen wirksam machen, z. B. inkrementelle Entwicklung?
• Oder geht es uns gar um Werte und Geisteshaltungen, z. B. die Lean-Philosophie?

Sie sehen: eine Frage wie „Kann man SCRUM für BPM einsetzen?“ ist zu billig. Die Antwort kann nur lauten: „…kommt drauf an!“

So stellt sich für reinrassige IT-Projekte mit geringem Veränderungsausmaß, z. B. bei der viel zitierten Automatisierung der Rechnungsstellung (=B4), gar nicht die Frage, ob man dort eine bestimmtes agiles Vorgehen nutzen will, sondern allenfalls welches Vorgehen (=A2) und wie.
Wenn es aber am Ende gar darum geht, eine gesamte Organisation an stetige Veränderung zu gewöhnen (=B1), dann denken wir in Richtung Lean und Beteiligung von Mitarbeitern (=A4).
Jetzt haben wir geklärt, was genau wir worauf abbilden können. Und daraus lassen sich jetzt konkrete, spannende Fragen ableiten. Zum Beispiel:

• Wie sinnvoll ist Timeboxing (=A1) für reine Organisationsprojekte mit hohem Veränderungsausmaß (=B1)? Macht dort ein Customer on Site Sinn?
• Ist ein formaler BPMN-Workflow in IT-Projekten mit geringem Veränderungsanteil (=B4) nicht bloß eine andere Form einer Programmiersprache?
• Wenn man eine gesamte Organisation lean machen möchte (=A4), ist Prozessmodellierung dann nicht eher hinderlich (=B1)?
• SOA-Projekten betreffen wegen ihrer übergreifenden Natur oft mehrere Teams (=B2). Was können SOA-Projekte bzgl. der Steuerung mehrerer Teams von SCRUM (=A2) lernen?
• Wie kann man Story Maps (=A1) für die Optimierung rein organisatorischer Abläufe nutzen (=B3)?

Welche Frage ist es für Sie?
Die Botschaft lautet also: Klären Sie für sich bzw. ihr Vorhaben genau, welche Fragen Sie konkret beantwortet haben wollen.
Auf diese und einige andere Fragen möchte ich in folgenden Beiträgen eingehen.
Christian Weiss

   

Als Video:
Seit einigen Jahren bereichern agile Ansätze und Prinzipien die Welt der Softwareentwicklung, im Moment sind es SCRUM, APM, Lean und Kanban. Für mich Grund genug einmal zu schauen, ob agile Ansätze auch für BPM-Projekte nützlich sind und worum es bei agilem BPM überhaupt geht.
Mal ehrlich: wie laufen typische BPM-Projekte ab?
1. erstmal alle Ist-Prozesse aufnehmen und modellieren (Prozessmodellierung)
2. dann die aufgenommenen Prozesse durchdringen und Optimierungsideen aufspüren (Prozessanalyse)
3. anschließend ausgestalten, wie es besser gehen müsste (Prozessdesign).
Dann die so entstandene Soll-Prozessdokumentation über den Zaun werfen und
4. nun auf schnelle, fehlerlose, wunschgemäße Umsetzung hoffen (Prozessumsetzung und –einführung)
und am Ende wundern, warum das Projekt gescheitert ist…
So ein Wasserfall wäre ja gar nicht so schlecht, wenn er die Dynamik des Niagara-Wasserfalls entfalten würde. Leider mutet er in der Praxis aber an, wie ein tröpfelnder Wasserhahn. Und dass solche rein sequenziellen Ansätze selten erfolgreich sind, ist lange bekannt und nachgewiesen. Ich stelle das hier bewusst plakativ dar (und es trifft auf gar keinem Fall für Ihr BPM-Projekt zu), aber so erleben wir es draußen in der Realität.
Stattdessen wissen wir unlängst, wie es besser geht. Agile Ansätze sind dafür konzipiert,

• die eigene Arbeitsweise flinker und produktiver zu machen
• Anforderungen stetig und zügig an die bewegliche Marktdynamik anzupassen
• neue Produkte schneller als die Konkurrenz ins Regal zu legen
• Entwicklungskosten zu drücken
• und nicht zuletzt: höhere Qualität zu liefern.

Und das sind doch größtenteils dieselben Ziele wie wir sie mit BPM-Projekten erreichen wollen. Es macht also Sinn, sich zu fragen, ob man Elemente der agilen Softwareentwicklung irgendwie nutzen kann.
Der Gedanke, agile Ansätze für BPM-Projekte zu nutzen wirft allerdings noch etliche Fragen auf. Zum Beispiel:

• wie passen SCRUM-Rollen und BPM-Rollen zusammen? Entspricht der Process Owner dem Product Owner? Ist der Process Analyst ein SCRUM-Master?
• Lassen sich agile Praktiken wie Timeboxing auch in der Phase der kontinuierlichen Prozesssteuerung nutzstiftend einsetzen oder sind wir da bereits agil genug?
• Durch iteratives Vorgehen verändern sich nach jeder Iteration die Prozessschnittstellen. Wie verhindert man, dass sich Fachbereiche immer an neue Prozessabläufe gewöhnen müssen?
• Agile Ansätze wollen, dass man nach jeder Iteration etwas ausliefert. Das geht doch gar nicht mit komplexen Prozessen, oder doch?

Das sind alles richtig spannende Fragen!
Agiles BPM beantwortet diese und viele andere wichtige Fragen und zeigt auf, wie man erfolgreiche Praktiken, Vorgehen, Prinzipien und anderes wertvolles Gedankengut auf den Kontext der BPM-Welt abbildet. Lassen Sie uns also damit beginnen, den in agilen Ansätzen destillierten Erfahrungsschatz nutzbar zu machen!
Im nächsten Blog-Eintrag dieser Serie geht es darum, ob Agilität und BPM überhaupt zusammen passen.
Schönen Start in die Woche wünscht
Christian Weiss