Prozess-Architektur – Prozesslandkarten, Ebenen und Co.

2020-01-21 – Strebt man ein unternehmensweites Prozessmanagement oder zumindest das Management mehrerer Prozesse an, stellt sich irgendwann die Frage, wie diese im Zusammenspiel gestaltet und effizient verwaltet werden sollen. Bei unseren Kunden tauchen dann auf einmal Begriffe auf wie Ebenen und Levels und endlose Diskussion über Detaillierung und Abstraktion. Der nachstehende Beitrag soll einen pragmatischen, aber robusten Ansatz bieten. Und SPOILER-Alert: Er steht im Widerspruch zur herrschenden Lehrmeinung.

Es ist bemerkenswert, wie ein einzelner Wissenschaftler mal etwas von einem Prozesshaus erzählt hat und darin Prozessebenen zu erkennen glaubte. Von der obersten bis zur untersten Ebene sollen immer mehr Details sichtbar werden. Generationen versuchen sich einen Reim aus diesem Ansatz zu machen und scheitern doch in der Praxis – auch wenn sie es nicht immer zugeben.

Wir halten den Ansatz von Prozessebenen, trotz seiner Verbreitung, für Unfug. Wenn man die Prozesswelt im Unternehmen in seiner Gänze als Zusammenspiel begreift, kommt man zu der Erkenntnis, dass es sich um ein (Prozess-)System handelt. So können – gemäß Systems Thinking – durchaus Systeme aus Subsystemen bestehen, diese verteilen sich jedoch nicht gleichmäßig auf eine definierte Anzahl von Ebenen, sondern unterliegen einer anderen Form der Kopplung (die nicht einmal gleichartig sein muss).

Das Ebenenmodell scheitert

In der Praxis wird die ‚unterste‘ Ebene meist als Ebene mit den meisten Details definiert – und es gibt Unternehmen, die haben bis zu 7 Ebenen definiert! Jetzt zeigt sich aber in der Praxis, dass einige kurze Prozesse sich nicht auf 7 Ebenen aufteilen lassen und daher werden entweder künstliche Zwischenebenen definiert oder aber ein Bruch im Ordnungsmuster akzeptiert. Der Einsatz eines durchgängigen Ebenenmodells scheitert!

Die Erwartungshaltung der Prozess-Konsumenten (also derjenigen, die sich über Prozesse informieren wollen) ist, dass Prozess-Schnittstellen sowohl auf oberen Ebenen (abstrakter) als auch auf unteren Ebenen (detaillierter) kongruent und schlüssig zusammenpassen. Dummerweise kommt man immer wieder an eine Stelle, wo ein Einzelverarbeitungsprozess nicht so recht zu einem Massenverarbeitungsprozess passen will und die Kongruenz verloren geht. Es zeigt sich: Das Ebenenmodell scheitert!

Und dann gibt es noch die Situationen, in denen die Prozessdokumentation unterbrochen werden muss, weil IT-Systeme zum Einsatz kommen, deren Arbeitsweise der Abteilung Prozessmanagement nicht bekannt sind. Im besten Fall sind diese an anderer Stelle, nämlich in der IT (eigenes Tool, eigene Sprache, eigene Formate) dokumentiert. Aufgrund von Verständnis oder fehlendem Zugriff gelingt es nicht, all dies in einer (gemeinsamen) Ebenenstruktur abzubilden. Das Ebenenmodell scheitert!

Und dann sind da noch die Stakeholder! Mitarbeiter wollen in der Prozesswelt navigieren, wie sie es im Internet kennen. Click! und schwups bin ich im nächsten Prozess. Oder das Management will einen schönen Drill-Down-Ansatz, um von ‚abstrakt‘ nach ‚detailliert‘ navigieren zu können, wie sie es eben von ihren Dashboards und Reporting-Tools her kennen. Sie ahnen es: Alle diesen Anforderungen in einer Ebenenstruktur gerecht zu werden scheitert!

Warum überhaupt Prozess-Architektur?

Die Frage muss erlaubt sein im betrieblichen Kontext. Schließlich wollen wir ohne einen betrieblichen Nutzen keine Aktivitäten an den Tag legen. Also die Frage: Warum überhaupt Prozessarchitektur? Die Antwort klingt vertraut: Es kommt d’rauf an! Warum man sich mit dem Thema beschäftigen sollte, hängt stark von den Zielen ab, die mit dem Thema Prozessmanagement verbunden werden.

Wollen Sie sich nur mit einem Prozess beschäftigen, beispielweise im Zuge der Prozessautomatisierung, kann Ihnen das Thema recht egal sein. Verfolgen Sie allerdings das Ziel, mehrere, viele oder gar alle Prozesse im Unternehmen zu automatisieren oder zu managen, dann wird sich irgendwann die Frage stellen, ob man eigentlich bei jedem Prozess von Neuem anfangen muss, oder ob nicht vielleicht Vorhandenes genutzt werden kann. Und genau hier liegt ein Grund, warum das Thema relevant ist, nämlich die effiziente Bearbeitung des Themas Prozessmanagements. Als Prozessarchitekt sind dann Fragen zu klären, welche Prozessabschnitte zu kapseln und wiederzuverwenden sind und wie sie zu diesem Zweck gestaltet werden müssen. Die Prozessarchitektur erhöht also die Effizienz durch Wiederverwendung.

Wollen Sie das Thema Prozessmanagement eher aus einer Dokumentationssicht angehen, dann könnte ein Ziel sein, eine Zertifizierung (bspw. die ISO 9000ff für das Qualitätsmanagement) zu erreichen. Auch in diesem Fall wird das Thema Prozessarchitektur interessant, denn eine Forderung der Norm, neben einer Prozessorientierung im Allgemeinen, ist, dass Prozesse in Ihrem Zusammenspiel zu betrachten sind (Vgl. DIN EN ISO 9001-2015). Aus Sicht der Prozessarchitektur ist es eines der Handlungsfelder, festzulegen, wo der eine Prozess beginnt, der vorangegangene aufhört oder ein dritter unterwegs zuliefert. Um hierfür eine entsprechende Transparenz schaffen zu können, kommen häufig sogenannte Prozesslandkarten ins Spiel, die Prozesse in Form von Wertkettendiagrammen darstellen (siehe Abbildung 2). Die Prozessarchitektur verbessert die Orientierung und erhöht die Transparenz.

Wollen Sie das Thema Prozessmanagement nutzen, um Ihrer Organisationsverantwortung als Unternehmer gerecht zu werden, dann ist die effektive Gestaltung eines Prozesssystems in Abhängigkeit von Ihrer Aufbauorganisation von höchster Relevanz. Strategische Neuausrichtungen haben üblicherweise Auswirkungen auf die Unternehmensorganisation. Die Prozessarchitektur trägt somit dazu bei, die Unternehmensstrategie erfolgreich operativ umzusetzen (Effektivität der Organisation) indem sie Veränderungsbedarfe transparent macht.

Der Wert (in) der Prozesslandkarte

Oben haben wir bereits von einer Prozesslandkarte gesprochen und finden diese auch in zahlreichen Organisationen wieder. Aus unserer Sicht ist sie für ein unternehmensweites Prozessmanagement ein wertvolles Werkzeug. Es taucht jedoch auch immer wieder die Frage auf, ob denn die erstellte Prozesslandkarte nun richtig dokumentiert sei. Und diese Frage lässt sich in der Regel nicht so einfach beantworten, denn es hängt stark von den damit verfolgten Zielen ab. In jedem Fall soll aber eine Prozesslandkarte eine abstrahierte Sicht auf die organisationsinterne Prozesswelt bieten und dadurch Orientierung schaffen. Wie diese Orientierung hergestellt werden kann, hängt ganz maßgeblich davon ab, welches Geschäftsmodell verfolgt wird, in welcher Industrie sie genutzt wird, am wichtigsten aber davon, wer mit einer Prozesslandkarte arbeitet. Und so gilt ein alter Spruch hierzu:

„Eine Prozesslandkarte ist nie richtig oder falsch, eine Prozesslandkarte ist nützlich oder unnütz.“

Wir, die Berater von MINAUTICS, nutzen die Prozesslandkarte gerne zur Herstellung einer gewissen Transparenz und zur Orientierung. Außerdem definieren wir auf einer noch recht abstrakten Ebene hier a) Ziele des Prozesses b) den Anlass (die Startbedingungen) und das (bzw. die) mögliche/n Prozessergebnisse (Prozessende). Auf diese Weise ist die Prozesslandkarte für uns auch ein Zuschnitts-Muster – ähnlich wie ein Setzkasten, den sie ggf. aus ihrer Kindheit noch kennen – innerhalb dessen wir alle Einzelprozesse versuchen einzuordnen.

Nach welchen Kriterien die Prozesse innerhalb der Prozesslandkarte angeordnet (gegliedert) werden, unterscheidet sich häufig von Branche zu Branche. Die Differenzierung von Management, Kern- und Unterstützungsprozessen ist weitverbreitet. Darüber hinaus lassen sich aber auch Kriterien wie Vertriebskanäle, Verantwortlichkeiten, Produkten, Produktlebenszyklusphasen, Kundengruppen, IT-Systemen oder Wertschöpfungsketten finden (Vgl. Bayer/Kühn (2013)).

Aufgrund der oben beschriebenen Ebenen-Problematik wissen wir aber auch, was eine Prozesslandkarte nicht sein kann. Eine Prozesslandkarte kann nicht eine Ebene sein und somit eben auch kein Navigationsinstrument, von dem aus man in die Details der Prozesse navigieren kann (ähnlich wie man es auf Internet-Seiten tut). Widerstehen Sie also der Versuchung, Ihre Prozesslandkarte klickbar zu machen (wenngleich viele Toolhersteller hierzu Funktionalitäten bieten) um gleichzeitig ein abgestimmtes Prozesssystem verwalten zu wollen. Sie werden sehr schnell auf logische Brüche kommen, die sich allenfalls durch hartnäckiges Ignorieren lösen lassen.

Von Eltern und Kindern

Bei der Erstellung von Prozessdarstellungen mit informellen oder semi-formalen Prozessbeschreibungssprachen, wie beispielsweise Flussdiagrammen oder ereignisgesteuerten Prozessketten, sind architektonische Fehler nicht sehr ins Gewicht gefallen, denn die Darstellungsart war ausreichend ungenau, als dass dies aufgefallen wäre. Außerdem wurden diese Sprachen nicht durch Software verarbeitet bzw. ausgewertet, demnach fand auch keine technische Überprüfung statt. Mit der Business Process Model and Notion (BPMN) 2.0 ist dies anders. Als formale Modellierungssprache erfüllt sie alle Anforderungen an eine formale Syntax und ist eindeutig in ihrer Symbolik. Für jedes Symbol existiert aus technischer Sicht eine definierte Ausführungs-Semantik. Der damit einhergehende Zwang zur Genauigkeit macht nun also gewisse Dinge sichtbar. Und eins davon ist, dass Prozesse sich nicht in Ebenen einordnen lassen.

Aus Sicht der BPMN ist etwas ein Prozess oder es ist kein Prozess. Ein Prozess kann viele Details haben oder wenige, aber am Ende bleibt er ein Prozess (oder es ist eben keiner). In jedem Fall gehört ein Prozess keiner Detaillierungsebene an, die zueinander in Abhängigkeit stehen. Aus diesem Grund ist es sinnvoller sich seinem Prozesssystem mit einer anderen Geisteshaltung zu nähern.

Wenn Sie an die Summe ihrer Prozesse denken, stelle sie sich diese ähnlich wie einen Datenwürfel vor (ähnlich wie wir es in einem DataWarehouse tun würden). Und jetzt gibt es auf diese Daten (also die Prozesse sind gemeint), verschiedene Sichten, die ich bedarfsorientiert nutzen kann. Zum Beispiel könnte es eine Sicht geben, Prozesse durch die Brille des Managements anzuschauen (manche sprechen von strategischen Sichten). In dieser Sicht sind viele operative Details außen vor, denn es geht ja hier um Übersicht. Wiederum andere bewerten Managementsichten als unbrauchbar, denn als Mitarbeiter will man beispielsweise ‚all die dreckigen Details‘, also die Ausnahmen und Sonderfälle im Tagesgeschäft, sehen können. Hier wird dann manchmal von einer operativen (oder fachlichen) Sicht auf Prozesse gesprochen. Jetzt könnte man sich auch vorstellen, dass es Prozesse gibt, die automatisiert ablaufen. Folglich gibt es auch eine technische Sicht auf Prozesse, die implementierungsrelevante Details für den technischen Kontrollfluss darstellt.

All diese Sichten auf Prozesse lassen sich baumartig (im Sinne der Ebenen) nicht anordnen (wir wiederholen uns hier), denn eine Navigation von einer zur anderen Sicht funktioniert nicht durchgängig. Akzeptieren Sie lieber eine Eigenart von Prozessen, die Ihnen beim Aufbau einer funktionierenden Architektur behilflich sein kann:

Prozesse haben die Fähigkeit, andere Prozesse aufrufen zu können. Aus diesem Grund lassen sich in Prozessen sogenannte Eltern-Kind-Beziehungen herstellen und über diese lassen sich auch größere Sprünge in der Detaillierung erklären. Ein Prozess mit wenig Details kann einen Prozess mit vielen Details aufrufen. Und der aufgerufene Prozess kann wiederum einen anderen oder sogar theoretisch seinen eigenen Elternprozess aufrufen, und ihn so zu seinem Kind-Prozess machen. Es ergibt sich also eine Aufrufhierarchie. Als Prozessarchitekt sollten sie Aufwand investieren, dass diese Aufrufhierarchie logisch und stringent ist (Abbildung 1).

Abb. 1: Exemplarische Eltern-Kind-Beziehungen

Hinzu kommt eine weitere Fähigkeit, nämlich dass diese auch auf andere Arten (also nicht nur durch Aufrufe) miteinander gekoppelt sein könnten. Beispielsweise kann ein Prozess eine Nachricht senden, auf die ein anderer Prozess wartet, um zu starten. Oder ein Prozess startet aufgrund einer bestimmten definierten Bedingung. Diese verschiedenen Formen der Kopplung sind in der Prozessarchitektur zu berücksichtigen und erlauben es dann auch, ein durchgängiges Prozesssystem zu beschreiben und zu managen, welches fachliche Prozesse, genauso wie IT-Prozesse, technische Produktionsprozesse und andere umfasst (Abbildung 2).

Alles ganz nett, aber wie denn jetzt genau?

Für eine unternehmensweite und praktikable Prozessarchitektur empfehlen wir folgende Vorgehensweise:

1. Lernen Sie Ihre Prozesse zunächst einmal in der Übersicht kennen. D. h. leiten Sie aus Ihrem Geschäftsmodell Ihre Kern- und Unterstützungsprozesse ab, sammeln Sie, was Ihnen sonst so unterkommt und berücksichtigen Sie auch regulatorische Vorgaben, die manchmal eigene Prozesse begründen.
2. Sortieren Sie Ihre Prozesse in einer Prozesslandkarte. Achten Sie dabei darauf, dass Sie Ihre Prozesse im Kernbereich zu Wertschöpfungsketten verknüpfen (diese werden in der Regel vom Kunden oder Markt induziert und liefern ein Ergebnis an den Verursacher (Kunde oder Markt) wieder zurück. Hier spricht man häufig auch von Ende-zu-Ende-Prozessen. Einige Prozesse sind gedacht, um die Kernprozesse mit Ressourcen auszustatten. Diese werden häufig Unterstützungs- oder Supportprozesse genannt. Diese werden häufig nicht durch einen Kunden getriggert, sondern durch andere Umstände veranlasst. Dann existieren noch Management-Prozesse (i. d. R. gehören hierzu Themen wie Strategiefindung/Vision, Zielbildung, Planung, Umsetzung und Controlling). Managementprozesse sollen für das Prozesssystem sinnstiftend sein und seine Leistungsfähigkeit befördern.
3. Wenn Sie das Gefühl haben, eine Prozesslandkarte entwickelt zu haben, die alle Unternehmensprozesse darstellt, dann halten Sie nochmal kurz inne. Prüfen Sie für jeden einzelnen Prozess, ob dessen Existenz erforderlich für das Geschäftsmodell ist! Manchmal schlummern hier die sogenannten ‚heiligen Kühe‘, welche dann geschlachtet werden dürfen, außer es gibt regulatorische Vorgaben, die derer Existenz begründen (Abbildung 3). (Da muss man dann durch. Kann man nix machen, außer auf minimalen Ressourceneinsatz trimmen.) Anschließend überlegen Sie sich für jeden identifizierten Prozess, welches Verfahrensziel damit verfolgt wird. D. h. soll das Prozessdesign Zeit-, Kosten- oder Qualitätszielen folgen. Ferner legen Sie fest, wo die einzelnen Prozesse beginnen (Anlass oder Anlässe) und wo sie enden (Prozessergebnis(se)).

Abb. 3: Heilige Kühe schlachten – Existenzgründe identifizieren (in Porters Value Chain)

4. Prüfen Sie anschließend insb. im Kernbereich, ob das Prozessergebnis eines vorangegangenen Prozesses vielleicht der Anlass für den Folgeprozess ist. Wenn nicht, untersuchen Sie genauer deren Prozesskopplung und präzisieren Sie diese (vgl. Abbildung 2). Prüfen Sie ferner die Unterstützungsprozesse. Deren Ergebnisse müssen irgendwie relevant für die Kernprozesse und entsprechend gekoppelt sein.
5. Nun haben Sie das Schnittmuster (oder den erwähnten Setzkasten), indem sie die weitere Prozessdetaillierung eingliedern können. Wenn Sie jetzt in den ersten Erhebungs-Workshop gehen, sollten Sie als Vorgabe die ermittelten Prozessanlässe (Starts) und Prozessergebnisse (Enden) vorgeben. Die Fachexperten erhalten dann einen Rahmen, innerhalb dessen sie dann die Prozessdetails berichten sollen (i. d. R. ist das dankbar, denn sonst laufen erst Diskussionen wo Prozesse starten und wo sie enden).
6. Wenn Sie einige Prozesse aufgenommen oder ggf. automatisiert haben, werden Sie zügig erkennen, dass wahrscheinlich die gleichen Themen an unterschiedlichen Stellen erneut auftreten. Jetzt können Sie überlegen, ob sie solche sich wiederholende Prozess-Abschnitte nicht kapseln wollen, sprich auslagen wollen, so dass sie wiederverwendet werden können. Dies erfordert üblicherweise eine gewisse intellektuelle Leistung, da ein wiederverwendbarer Prozessabschnitt ja von mehreren Stellen aufgerufen werden kann und demnach auch entsprechend abstrahiert werden muss.

Ähnliche Überlegungen treten auf, wenn Sie sich Prozesse anschauen, die viele Schritte in einer gewissen Folge umfassen, aber auch immer wieder mal vorzeitig beendet werden können. Irgendwann stellt sich hier dann die Frage, inwieweit man eigentlich alle Prozess-Schritte standardisieren oder gar automatisieren will, wo doch 100% aller Vorgänge nur durch die ersten Aktivitäten laufen, im hinteren Teil des Prozesses aber nur noch kleiner Prozentsätze aller Vorgänge ankommt. Dann kommen Sie irgendwann zu der Überlegung, ob man einen solchen Prozess nicht sinnvollerweise auftrennen möchte in einen, der hochstandardisiert wird (und ggf. automatisiert) und einen, der aufgrund seiner geringeren Durchführungshäufigkeiten weniger stark standardisiert (oder gar automatisiert) werden soll.

Und zack, ist man mittendrin in der prozessarchitektonischen Arbeit, die eben nicht wie landläufig zu hören ist, einmalig am Anfang eines Prozessmanagement-Vorhabens auftritt, sondern eigentlich ein fortwährendes Unterfangen ist, welches im Lebenszyklus eines Prozesses immer wieder notwendig ist.

Werkzeuge

Die Wahrheit ist, Prozessarchitektur braucht Werkzeuge, denn die Anzahl der Prozesse, deren Varianten und fortlaufenden Anpassungen erzeugen eine Komplexität, die mit Hausmitteln nur sehr schwer, schon gar nicht effizient verwaltet werden kann. Welches Prozessmanagement-Tool Sie dazu verwenden, ist zweitrangig. Insofern haben wir beispielhaft nachstehend ein paar Modelle toolUNabhängig skizziert. Die oben beschriebene Vorgehensweise und die nachstehenden Beispiele sind unseres Erachtens nach aber in allen Tools umzusetzen.

Beispiel: Prozesslandkarte

Die nachstehende Prozesslandkarte zeigt die Prozesswelt eines (sehr) abstrakten Discount-Handelsunternehmens. Es ist aber hinreichend detailliert, um die Vorgehensweise nachzuvollziehen.

Abb. 4: Prozesslandkarte eines fiktiven Discounters

Die Prozesslandkarte ist klassisch unterteilt nach Management-, Kern- und Unterstützungsprozessen und beschreibt in Gänze die Wertschöpfung des Geschäftsmodells, welches sich aus dem Wareneinkauf, der Regelpräsentation und dem Verkauf ergibt.

Beispiel: Prozessverzeichnis

Aus der Prozesslandkarte (siehe Abbildung 4) lassen sich Prozesse ablesen, die wir extrahiert in separater Form (Tabelle) dargestellt und anschließend mit einigen Attributen (Spalten) ergänzt haben (Abbildung 5).

Abb. 5: Prozessverzeichnis mit Zielen, Schnittstellen und Verantwortlichkeiten

Diese tabellarische Darstellung erlaubt uns, Prozesszusammenhänge noch einmal anders zu prüfen. Wie im oben beschrieben Vorgehen erklärt, kann nun im Kernprozessbereich geprüft werden, ob vorgelagerte Prozesse Endereignisse liefen, die für nachgelagerte Prozesse einen Prozessstart verursachen. Sollte eine Einzelauftragsbearbeitung das Ziel sein, ist dies meist wünschenswert. Ggf. lassen sich aber auch Lücken erkennen, denen man nachgehen kann, um seine Landkarte zu vervollständigen. Auch werden alle Arten der Prozesskopplung ersichtliche, die ggf. noch mal abgestimmt werden können (Abbildung 6).

Abb. 6: Prozesslandkarte mit durch BPMN Ereignissen angedeuteten Schnittstellen und Übergaben

Wenn Sie auf dieser Ebene weitestgehend vollständig und abgestimmt Ihre Prozesse zusammengetragen haben, können Sie sich den Details widmen, die Sie dann entsprechend ‚einhängen‘, also abgestimmt auf Anfang und Ende, integrieren können (Abbildung 7).

Beispiel: Prozess-Kopplung

Abb. 7: ‚Einhängen‘ von Prozessmodellen in die Prozesslandkarte

Ihre Prozesslandschaft wird sich also zunehmen füllen und auch ‚blinde Flecke‘ verschwinden nach und nach. Sie werden erkennen, dass die Prozesse nicht immer nur in einer Sequenz ablaufen, sondern auch andere Formen der Kopplung aufkommen, welche Sie in bestimmten Sichten genauer untersuchen sollten. Auch werden Sie Erkenntnisse sammeln, dass gleiche Dinge immer wieder an unterschiedlichen Stellen passieren. Beispielhaft können Sie an das Pattern der Freigabe denken (Abbildung 8). Dass ein Mitarbeiter etwas beantragt/will und eine oder mehrere Freigabeinstanzen prüfen, werden Sie vielleicht im Bedarfsmeldeprozess oder beim Urlaubsantrag oder bei einer Dienstreise wiederfinden. Um in den drei genannten Prozessen nicht jedes Mal alles neu zu erfinden, kann der Prozessarchitekt darüber nachdenken, ob es Möglichkeiten der Abstrahierung und dadurch eine sinnvolle Wiederverwendung gibt. In diesem Kontext werden Sie auch über die Vergabe neuer Rollen nachdenken. Im Einkaufsbeispiel hatten Sie vielleicht bisher den ‚Einkaufsleiter‘ modelliert, der eine Aufgabe ‚Bedarfsmeldung prüfen‘ durchführte. Um das Freigabe-Pattern wiederverwendbar zu gestalten, definieren Sie nun vielleicht eine Rolle ‚Freigebender‘, um unternehmensweit damit arbeiten zu können.

Abb. 8: Gleiche Sequenzen in unterschiedlichen Prozessen – Prozess-Architektur erkennen

Die Abbildung 8 zeigt, dass in zwei Prozessen im Grunde dieselbe Sequenz von Aktivtäten stattfindet. Es erscheint also ein geeigneter Kandidat für Wiederverwendung zu sein. Im nachstehenden Modell (Abbildung 9) lagern wir diese Schritte daher aus und binden sie über eine BPMN Aufrufaktivität nur noch ein. Es fällt auf, dass die Rolle (Poolbezeichnung) abstrahiert wurde und nun von einem ‚Freigebender‘ gesprochen wird.

Abb. 9: Wiederverwendung gleicher Sequenzen – Bausteine für die Prozess-Architektur

Fazit

Der Aufgabenbereich der Prozessarchitektur wächst, je mehr Prozesse betrachtet und verwaltet werden. Wenn Orientierung und Transparenz am Ende aber für die Effizienz wichtig sind, wird man nicht umher kommen, sich dem Thema stärker zu widmen. Im Kontext eines unternehmensweiten Prozessmanagements braucht es einen Verantwortlichen für die Prozessarchitektur. Hier aber einen pragmatischen Ansatz zu fahren, der auch einen Nutzwert bietet, benötigt etwas Erfahrung.