BPM considered harmful: Warum Business Process Modeling nicht am Anfang einer Anforderungsdefinition stehen sollte

BPM considered harmful: Warum Business Process Modeling nicht am Anfang einer Anforderungsdefinition stehen sollte

„BPM wird in der Praxis falsch beziehungsweise zum falschen Zeitpunkt eingesetzt: zu viele Aspekte werden in der falschen Reihenfolge und mit falschem Fokus bearbeitet“, so Stefan Berner.

Business Process Modeling (BPM) spielt eine große Rolle in den frühen Schritten der Softwareentwicklung. Nach Meinung von Business Analyst & Modelling Expert Stefan Berner „eine zu große Rolle“. In diesem Artikel, veröffentlicht mit freundlicher Genehmigung des Autors, zeigt Stefan Berner die Nachteile des zu frühen Einsatzes von BPM auf. Er erläutert darüber hinaus, wie vor der Prozessmodellierung ein besseres Verständnis der zu modellierenden Welt erlangt werden kann. Der Originaltext ist erschienen Lecture Notes in Informatics: Modellierung 2016.

Mit seinem berühmten Letter to the Editor „Go To Statement Considered Harmful“ [2] lancierte Dijkstra eine kontroverse Diskussion, die am Schluss zur Akzeptanz strukturierter Programmierung führte. In diesem Sinne wurde der Ausdruck im Titel dieses Artikels übernommen. Die vorliegenden Betrachtungen aus Sicht eines Praktikers sollen die Diskussion anstoßen. 

Welche Rolle soll Business Process Modeling in einem Softwareprojekt spielen? Ist es wirklich der beste Einstieg und Zugang zu einer Softwarelösung? BPM (Business Process Model) weist einige Nachteile auf. Sein typischer Einsatz führt nicht zu bester Softwarequalität. Die aufgeführten Beobachtungen und daraus abgeleiteten Hypothesen haben sich in der jahrelangen praktischen Projektarbeit des Autors bestätigt. Ein unabhängiger Nachweis liegt außerhalb seiner Möglichkeiten. Dieser Beitrag soll Menschen aus der Forschung dazu anregen, die Aussagen und Hypothesen in neutralen Studien zu überprüfen.

Business Process Model

Das Business Process Model (Geschäftsmodell) dient dem Zweck, Geschäftsabläufe in einer für die Auftraggeber verständlichen Art zu beschreiben. Es soll gleichzeitig eine formale Vorlage für die Umsetzung in Software sein. Typischerweise sind die folgenden Aspekte in einem Business Process Model vereint.

  • Funktionen
  • DatenInformationen
  • Ereignisse
  • Zustände
  • Organisationseinheiten
  • AkteureTransportkanäleMedien
  • Datenspeicher und -kanäle
  • Schnittstellen

Das Business Process Model beschreibt aus fachlicher Sicht, was Akteure wie mit Informationen tun. Es beschreibt Geschäftsabläufe aus Sicht der Nutzenden. Beispiel:

Information Model

Ein Informationsmodell ist eine Beschreibung der in einer Umgebung benötigten Informationen (siehe [1]). Es beschreibt Entitäten mit ihren Attributen und ihren Beziehungen zu anderen Entitäten. Es wird normalerweise als konzeptionelles Datenmodell bezeichnet. Der Begriff Informationsmodell wird verwendet, um folgende Unterschiede zu einem Datenmodell hervorzuheben.

  • Sämtliche Namen (Entitäten, Attribute, Beziehungen) sind ausschließlich Begriffe der Geschäftswelt und werden von allen Beteiligten vorbehaltlos akzeptiert.
  • Sämtliche Verknüpfungen von Entitäten sind in beide Richtungen mit einem Verb beschrieben.
  • Es kommen keine technischen Begriffe (wie Datenbank, Tabellen, Data Types, Keys, Constraints, XML etc.) vor.

 

Das Informationsmodell beschreibt, was Dinge (Entitäten) fachlich miteinander zu tun haben. Wie sie strukturell zusammenhängen. Es beschreibt die möglichen, konsistenten und relevanten Zustände, die statische Struktur eines Systems.

Der Begriff Datenmodell wird im Zusammenhang mit Geschäftsmodellierung bewusst vermieden. Daten bilden Informationen in speicherbare, technisch verwaltbare Elemente ab. Datenwerte sind per se sinnlos. Anwenderinnen und Anwender nutzen nie Datenwerte. Sie nutzen Informationen, die durch Interpretation der Datenwerte entstehen. Das Informationsmodell ist die explizite Dokumentation der verbindlichen, fachlichen Interpretation der Daten einer Umgebung.

Kritik am BPM

Ein Prozess überführt ein System von einem konsistenten Zustand in einen anderen. Prozesse sind nie das Ziel, sie sind immer der Weg. Prozesse beschreiben, wie eine Zustandsänderung herbeigeführt wird. Sie beschreiben nicht die Zustände als solche. Das Business Process Model beschreibt, was Akteure wie mit den Dingen (Entitäten) tun. Es beschreibt, wie durch eine Aktivität, unter Einsatz von (technischen) Hilfsmitteln, das System von einem konsistenten Zustand in einen anderen übergeht.

Falsche Reihenfolge

Damit ein guter Prozess entworfen werden kann, müssen Start und Ziel bekannt sein. Einerseits sind das Auslöser (Ereignisse) und der Anfangszustand, andererseits der erwartete Endzustand der manipulierten Informationen. Ohne zu wissen, was das Ziel eines Prozesses ist, macht es wenig Sinn, diesen zu beschreiben. Konsistente Zustände werden durch das fachliche, statische Systemwissen – dem oben genannten Informationsmodell – beschrieben.

In der Praxis wird als erster Schritt einer Systembeschreibung meistens ein Prozessmodell erstellt. Warum das so ist, wird hier noch erläutert. Die darin verwendeten oder erzeugten Informationen werden in einem zweiten Schritt zu einem Datenmodell zusammengefasst. Eine vollständige, exakte Beschreibung der Informationsstruktur aus Sicht der Anwendenden und losgelöst von den Prozessen, ist in der Praxis kaum je anzutreffen. Diese fehlende Sicht auf die Begriffe und das mangelhafte Verständnis der Geschäftswelt führen in der Regel dazu, dass Datenmodelle zu stark die Struktur der Prozesse und die Sichtweise der Entwickler abbilden. Strukturelle fachliche Probleme und Inkonsistenzen werden mit diesem Vorgehen erst spät im Entwicklungsprozess (bei der Datenmodellumsetzung, der Modulerstellung oder im Test) erkannt. Weil die Prozesse zu diesem Zeitpunkt in der Regel bereits abgenommen und fixiert sind, will man diese nicht mehr ändern. Das führt dazu, dass Architekturprobleme auf Ebene der Daten und Programme „ausgeglichen” werden. Dieses Vorgehen ist mit Sicherheit suboptimal.

Zu komplex

Durch die Menge der Aspekte, die in einem Business Process Model kombiniert dargestellt werden, wird das Dokument und seine Erstellung sehr komplex. Es ist extrem schwierig, während der Modellierung einzelner Prozesse gleichzeitig eine stimmige Strukturbeschreibung des Gesamtsystems zu entwickeln. Eine solche Arbeit setzt eine überdurchschnittliche Abstraktionsfähigkeit voraus und ist für viele eine Überforderung.

Die Vielschichtigkeit des Modells schränkt zusätzlich seinen Nutzen als Übersichtsdokument ein. Es ist für die meisten Beteiligten schwer lesbar. Einzelne Aufgaben können gut verfolgt werden („was passiert mit einer Mahnung?”). Ein Überblick über das gesamte System kann mit einem Business Process Model aber nur schwer gewonnen werden.

„Legacy”

Prozessmodelle werden typischerweise gemeinsam mit den Nutzenden der bestehenden Systeme erstellt. Dabei wird in den meisten Fällen von bestehenden Prozessen ausgegangen und es wird versucht, diese zu verbessern. Die bestehenden Prozesse sind entstanden unter den Voraussetzungen der damaligen Umgebung (Organisation, Technologie, Kommunikationskanäle, Medienbrüche etc.). Viele Prozesse sind wie sie sind, weil es unter den damaligen Umständen die beste (pragmatischste) Lösung war. Diese Prozesse haben über die Jahre die Arbeitsweise von Personen geprägt. Viele Mitarbeitende haben diese Prozesse als Grundlage ihrer Arbeit kennengelernt und verinnerlicht. Diese Prozesse sind ihre Arbeit. Aus ihrer Sicht sind die Geschäftsabläufe das, was durch die bestehenden Prozesse vorgegeben wird. Ein gutes Beispiel dafür ist die schweizerische Postleitzahl. Sie wurde 1964 eingeführt, um die manuellen Prozesse der Postsortierung und -verteilung zu verbessern. Ihre (hierarchische) Struktur war auf geografische Regionen, wirtschaftliche Zentren und die Hauptverkehrsachsen (vor allem der Bahn) ausgerichtet. Bei der Einführung von der Bevölkerung bekämpft, wandelte sie sich mit der Zeit zu einem identitätsstiftenden Kulturgut. Bei der heutigen Technik der optischen Adresserkennung und automatischen Sortierung ist sie ein ineffizientes Überbleibsel. Trotzdem wird sie in Prozessen rund um die Adressierung weiterhin eingesetzt und verwendet.

Bessere Prozesse entstehen, wenn aus den bestehenden Prozessen die rein fachlichen Ziele (=Informationszustände) extrahiert werden und der Weg, diese zu erreichen, unter Einbezug der aktuellen Rahmenbedingungen neu entworfen wird.

Mehrdeutige Begriffsdefinitionen

Beim Modellieren von Geschäftsprozessen werden Geschäftsbereiche immer aus Sicht einzelner Prozesse und damit einzelner Akteure oder Organisationseinheiten betrachtet und modelliert. Die Begriffe, die verwendet werden, um die benötigten oder erzeugten Informationen (Entitäten) zu beschreiben, werden immer aus Sicht der momentanen Gesprächspartner interpretiert. Beispiel: Jeder und jede weiß, was ein „Produkt” ist. In einer Applikation, die den gesamten Produktzyklus abhandelt, ändert der Begriff von Abteilung zu Abteilung seine Bedeutung. Ein „Produkt” ist in der Herstellung etwas anderes (hat andere Eigenschaften und Beziehungen), als ein „Produkt” im Einkauf, im Marketing, in der Logistik oder im Verkauf.

Es benötigt eine von den Akteuren und Prozessbeschreibungen unabhängige Definition und Beschreibung aller gemeinsam genutzten Begriffe. Ohne diese Definitionen besteht die große Gefahr, dass unsaubere Benennungen und Definitionen übernommen werden. Es entsteht eine semantisch falsche Architektur.

Das zu frühe Modellieren der Prozesse erschwert die notwendige Diskussion um einheitliche Begriffe und Definitionen. Der jeweilige Fokus auf einzelne Abläufe impliziert eine bestimmte Interpretation der Begriffe. Missverständnisse in der Kommunikation zwischen Fach und IT aber auch zwischen verschiedenen Fachbereichen bleiben dadurch während der Business-Analyse häufig unentdeckt.

Ursachen und Lösung

Warum beginnen fast alle Entwickler und Entwicklerinnen in allen Stufen der Softwareentwicklung mit den Prozessen und leiten daraus die benötigen Daten ab? Warum ist diese falsche Reihenfolge so beliebt? Wir wissen spätestens seit Niklaus Wirth’s Algorithmen und Datenstrukturen (1975), dass eine gute Datenstruktur zu einfacheren Algorithmen führen kann.


Ursachen

Es scheint einfacher zu sein, Prozesse (Wege, Touren) zu beschreiben, als statische Strukturen (Karten). Eine überwiegende Mehrheit der Menschen beschreibt lieber Touren (siehe [4]). Interessanterweise ist es im Gegensatz dazu einfacher, sich ein Bild einer Umgebung anhand einer Karte zu verschaffen, als anhand der Beschreibung einer Tour durch diese Landschaft zu navigieren. Diese Asymmetrie erklärt sich damit, dass auf einer Karte mehr Information auf kleinerem Raum dargestellt ist und dass sich mit dem Verständnis der zugrunde liegenden Struktur die Touren fast von selbst ergeben. Information verdichtet zu dokumentieren ist aufwändig. Dieser Mehraufwand wird durch Einsparungen beim Lesen wettgemacht. Goethe hat diesen Sachverhalt so beschrieben: „Entschuldige die Länge des Briefes, ich hatte keine Zeit mich kurz zu fassen!”

Einheitliche Definitionen und Begriffsverwendungen sind schwierig zu finden und durchzusetzen. Sie setzen voraus, dass die Differenzen erkannt sind und dass die Beteiligten bereit sind, ihre Begriffsverwendungen und damit ihre Sprechweise anzupassen. Eindeutige Begriffe können nur in Diskussionen über Inhalte und Verständnis erarbeitet werden. Häufig braucht es fachliche Entscheidungen über die richtige beziehungsweise in dieser Umgebung sinnvollste Verwendung eines Begriffs. Diese Diskussionen werden in den Sitzungen mit Fachvertretern gern vermieden. Sie bedeuten viel Arbeit und der Aufwand für die möglichen Konsequenzen wird von Informatikern und Anwendenden gescheut. Es ist vordergründig einfacher (= mit weniger Arbeit verbunden), sich über Prozesse zu unterhalten. Der Kontext und die möglichen Interpretationen sind klarer und es finden weniger Diskussionen statt.

Es ist ein großer Aufwand, in bestehenden Prozessen die unterschiedlichen Aspekte zu identifizieren, zu extrahieren und zu ändern. Es ist eine intellektuelle Herausforderung und erfordert gute Fachkenntnisse. Es müssen oft Widerstände der Nutzenden und ihrer Manager überwunden werden (siehe das Beispiel PLZ weiter oben). Diese Vermeidung von schwierigen Aufgaben hat zur Folge, dass zu viele überflüssige und veraltete Anteile der bestehenden Geschäftsprozesse in die neue Lösung übernommen werden.

Der Versuch, (Denk-)Aufwand zu vermeiden sowie die Abneigung gegen eine Revision des eigenen Verständnisses der Dinge, führen zu unsauberen Begriffen und Datenstrukturen und damit zu suboptimalen, stark an die Vergangenheit angelehnten (legacy) Prozessen.

Lösungsansatz

Die Gesamtaufgabe des BPM muss unterteilt werden. Häufig werden strukturelle Kriterien (Systemgrenzen, Medienbrüche, Organisationseinheiten, Programmierumgebungen etc.) für die Unterteilung in Teilaufgaben angewendet. Diese haben den Nachteil, dass mit jeder Änderung der Umgebung die Modulstruktur der Lösung ineffizient oder falsch werden kann. Der stabilste Aspekt von Systemen ist die eigentliche Fachsemantik. Die Informationsstrukturen und fachlichen Grundabläufe einer doppelten Buchhaltung zum Beispiel haben sich seit ihrer Einführung im 14. Jahrhundert kaum verändert.

Am volatilsten sind Technologien und Medien. Eine Strukturierung der Lösung nach semantischen Aspekten führt zu langfristig stabilen Systemen. Für eine stabile und einfache Lösung müssen:

  • Aspekte mit unterschiedlicher Änderungsrate in gesonderten Arbeitsschritten und Dokumenten dokumentiert werden.
  • Prozessvoraussetzungen und Ergebnisse (Ereignisse, Start- und Zielzustände) vor den Prozessen modelliert und beschrieben werden.
  • Aspekte, die der Kommunikation mit den Auftraggebern oder Fachnutzern dienen, getrennt werden von Aspekten für technische Belange
(jedes Dokument darf nur Elemente enthalten, die das adressierte Zielpublikum als relevant betrachtet und verstehen kann).

Das folgende Vorgehen hat sich für BPM bewährt. Als erstes werden Geschäftsereignisse und die möglichen Systemzustände (Informationsmodell) erstellt. Als Voraussetzung für die Modellierung von guten Prozessen können und sollen diese beiden Dokumente unabhängig von Prozessbetrachtungen erarbeitet werden. Als nächster Schritt werden die stabilen, rein fachlichen Aspekte der Geschäftsprozesse beschrieben. Möglichst unabhängig von jeglicher Technologie, Organisation und Medien(-brüchen) etc.

Erst nach Vorliegen dieser Übersichtsergebnisse aus fachlicher Sicht, können gute betriebliche Prozesse erstellt werden, die alle Aspekte kombinieren. Dieser letzte Schritt bettet die fachlichen Anforderungen (Geschäftsereignisse, Informationsstruktur, fachliche Prozessbeschreibung) in die aktuelle Umgebung (Organisation, Technologie, Systemlandschaft) ein.

Abbildung 3 und 4 zeigen Informationsbedarf und Fachprozessschritte des Entwicklungsprozesses in rudimentärer Form.

Zusammenfassung

BPM ist nicht per se schädlich. Es wird in der Praxis falsch beziehungsweise zum falschen Zeitpunkt eingesetzt. Es werden zu viele Aspekte in der falschen Reihenfolge und mit falschem Fokus bearbeitet. Dies führt dazu, dass

  • Keine benutzertauglichen Übersichtsdokumente entstehen.
  • Viele Business-Analysten, Manager und Fachleute von ihren Aufgaben überfordert sind.
  • Die resultierenden Datenmodelle die Fachsemantik nicht optimal abbilden.
  • Zu viele legacy-Aspekte in die neue Lösung übernommen werden.
  • Viele Module zu komplex werden.

Neue Technologien, Organisationsformen und Medien nicht effizient genutzt werden können.
Der im vorherigen Abschnitt beschriebene Lösungsansatz wurde in vielen Projekten erfolgreich angewendet. Die Modellierung der Prozesse wurde massiv vereinfacht. Viele Prozesse wurden im Vergleich zur alten Lösung einfacher. Die obige Negativliste wurde aus Erfahrungen mehrerer Projekte extrahiert. Meine Hypothese ist, dass ein Wechsel von BPM zu Informationsmodellierung als erster Schritt im Entwicklungsprozess diese Mängel vermindert oder verhindert. Ich hoffe, dass die vorgelegten Überlegungen Menschen dazu motivieren, nach diesem Ansatz zu arbeiten beziehungsweise ihre Arbeitsweise und Ergebnisse zu kommunizieren und dass sich dadurch genügend Beispiele ergeben, damit die Vorteile des Vorgehens objektiver bestätigt werden können.

Literatur

[1] Berner, Stefan: Informationsmodellierung – Durch Verstehen zu besserer Software, Verlag der Fachvereine (vdf), Zürich 2016
[2] Dijkstra, Edsger W.: Go To Statement Considered Harmful, Communications of the ACM Volume 11 Issue 3, 1968, pages 147-148
[3] BPMN 2.0 by Example: Version 1.0, 2010, 
https://www.omg.org/spec/BPMN/
[4] Linde, Charlotte and Labov, William, Spatial Networks as a Site for the Study of Language and Thought, Language Vol. 51, No. 4 ,1975, pages 924-939



Weitere Magazinbeiträge