Von Prozessen zur zugrunde liegenden Architektur und zurück: Teil 1

Die meisten Serviceprobleme entstehen nicht dort, wo Kund:innen sie wahrnehmen. Sie beginnen früher – innerhalb des Prozesses, der den Service bereitstellt. Verzögerungen, Fehler und Frustration lassen sich meist auf eine Abfolge von Aktivitäten zurückführen, die nicht wie vorgesehen funktioniert hat.

Jeder Service basiert auf genau einer solchen Abfolge. Aufgaben müssen ausgeführt werden, Systeme müssen reagieren, Daten müssen verfügbar sein und Übergaben zwischen Menschen müssen zum richtigen Zeitpunkt erfolgen. Wenn eines dieser Elemente nicht funktioniert, leidet der gesamte Service – auch wenn das Problem zunächst nicht sichtbar ist.

Einen Service zu verbessern bedeutet daher, seinen Prozess im Detail zu verstehen. Einen Prozess zu verbessern bedeutet wiederum zu verstehen, warum bestimmte Schritte fehlschlagen oder sich verzögern. Dafür reicht es nicht, nur die Oberfläche zu betrachten – vielmehr müssen die zugrunde liegenden Systeme, Anwendungen, Daten und Rollen analysiert werden, die jede Aktivität ermöglichen.

Genau hier wird die Zusammenarbeit von Geschäftsprozessmanagement (GPM) und Enterprise Architecture Management (EAM) entscheidend. GPM zeigt, was passiert und wo Probleme entstehen (können), während EAM erklärt, warum sie entstehen. Wer beide Disziplinen getrennt betrachtet, schöpft ihr Potenzial nicht aus.

In diesem Beitrag zeigen wir, wie Sie vom Prozesseinstieg ausgehend tief in die zugrunde liegende Architektur eintauchen können. Dabei bleibt es jedoch keine Einbahnstraße: In einem Folgebeitrag betrachten wir auch die umgekehrte Richtung – wie Sie von der strategischen Ebene im EAM starten und daraus konkrete Verbesserungen für Ihre Prozesse ableiten.

Prozessverbesserungen beginnen selten mit einem klar benannten Problem. Meistens starten sie erst dann, wenn der Druck spürbar wird: Aufgaben dauern länger als geplant, Teams greifen zu Workarounds und passen Abläufe improvisiert an, damit es irgendwie weitergeht. Wenn das Problem schließlich offen zur Sprache kommt, ist es oft längst Teil des Prozesses geworden – statt wirklich gelöst zu sein.

Genau hier geraten viele Initiativen ins Stocken. Der Fokus liegt plötzlich auf dem, was schnell sichtbar und messbar ist. Doch das ist häufig zu kurz gegriffen. Das eigentliche Problem liegt tiefer – und bleibt unbeachtet. Wer nur das Symptom behandelt, schafft vielleicht kurzfristig Entlastung, versteht aber nicht die Ursache. Und genau deshalb taucht das Problem immer wieder auf.

Ein anschauliches Beispiel ist der Check-in am Flughafen. Lange Warteschlangen sind sofort sichtbar – aber sie sagen wenig darüber aus, warum es dazu kommt. Vielleicht ist eine bestimmte Aktivität nicht mehr skalierbar. Vielleicht reagiert ein System je nach Datenqualität unterschiedlich schnell. Oder eine Übergabe sorgt gerade zu Stoßzeiten für Verzögerungen. Nach außen sieht all das gleich aus – erfordert aber völlig unterschiedliche Lösungen.

Hier kommt GPM ins Spiel. Sobald ein Prozess strukturiert dargestellt wird, werden Annahmen greifbar. Aufgaben, Übergaben und Wartezeiten sind nicht mehr nur gefühlt, sondern klar sichtbar. Und genau das verändert die Diskussion: Statt über Eindrücke zu sprechen, können Teams konkret auf einzelne Schritte schauen und hinterfragen, warum sie so ablaufen, wie sie es tun. So wird es möglich, gezielt anzusetzen. Der Fokus verschiebt sich weg von schnellen, allgemeinen Maßnahmen hin zu den konkreten Aktivitäten, die tatsächlich für Verzögerungen oder Fehler verantwortlich sind.

GPM hilft uns dabei, Probleme sichtbar zu machen – aber das ist nur der erste Schritt. Die entscheidende Frage ist: Wie lösen wir sie tatsächlich?

Dafür müssen wir hinter die Kulissen schauen. Bleiben wir beim Beispiel des Check-ins: Eine Aufgabe, die Verzögerungen verursacht, steht nie für sich allein. Sie hängt von Anwendungen ab, von Systemsoftware, Daten, Schnittstellen und den Menschen, die damit arbeiten. Dieses Zusammenspiel kann uns bereits einiges verraten. Aber wir können noch einen Schritt weiter gehen.

Angenommen, wir stellen fest, dass eine unterstützende Anwendung die eigentliche Ursache ist. Dann lautet die nächste Frage: Warum funktioniert diese Anwendung nicht wie erwartet? Ähnlich wie Prozesse sind auch Anwendungen in ein Netzwerk von Abhängigkeiten eingebettet – etwa Schnittstellen, Systemsoftware oder zugrunde liegende Plattformen. Wenn eine Anwendung beispielsweise auf einer fehlerhaften Schnittstelle basiert oder auf veralteter Systemsoftware läuft, kann sie schlicht nicht die gewünschte Leistung bringen.

Genau hier kommt Enterprise Architecture Management (EAM) ins Spiel. EAM hilft dabei:

• die gesamte Architektur transparent abzubilden

• Abhängigkeiten zwischen Systemen und Komponenten sichtbar zu machen

• kritische Schwachstellen gezielt zu identifizieren

Mit diesem Verständnis, wissen wir genau wo das Problem existiert und wie es zu lösen ist. Und genau das verändert den Umgang damit: Ist eine Schnittstelle fehlerhaft, wird sie gezielt korrigiert. Ist die Systemsoftware veraltet, wird sie ersetzt. Der Unterschied ist entscheidend: Statt vager Aussagen wie „Wir müssen den Prozess verbessern“ treffen Sie konkrete, umsetzbare Entscheidungen – etwa: „Wir beheben die Anwendung hinter diesem Prozessschritt, indem wir die zugrunde liegende Schnittstelle anpassen.“

Wenn GPM und EAM wirklich ineinandergreifen, wird der Nutzen schnell deutlich. Besonders wirkungsvoll ist diese Zusammenarbeit, wenn beide Disziplinen auf eine gemeinsame Datenbasis zugreifen. So können Prozessmanager:innen und Enterprise Architects ihr Wissen teilen und eng zusammenarbeiten – was zu besserer Abstimmung, höherer Effizienz und mehr Transparenz führt. Die folgenden Punkte zeigen exemplarisch einige der praktischen Ergebnisse, die sich aus der Integration der BPM-Suite ADONIS mit der EAM-Suite ADOIT ergeben:

GPM zeigt, wo ein Prozess nicht wie gewünscht funktioniert. EAM liefert die architektonischen Gründe dafür. In Kombination sparen Sie Zeit bei der Suche nach Symptomen und gelangen deutlich schneller von einem sichtbaren Prozessproblem zur eigentlichen Ursache – sei es eine Anwendung, eine Schnittstelle oder ein Datenproblem. Das verkürzt die Lösungszeit erheblich.

Tipp: Sehen Sie, wie Process Mining echte Geschäftsdaten nutzt, um versteckte Ineffizienzen aufzudecken und Prozesse auf Basis von Fakten statt Vermutungen zu verbessern.

Mit Tools wie ADONIS für GPM und ADOIT für EAM können Prozesseigner:innen und Enterprise Architects auf einer gemeinsamen Grundlage arbeiten. Da beide auf dasselbe Repository zugreifen, werden Erkenntnisse aus dem Prozessmanagement direkt in die Architektur überführt, während Änderungen auf der Architekturseite transparent zurück in die Prozesse gespiegelt werden. Diese gemeinsame Sicht schließt die Lücke zwischen Business und IT.

Ein Problem zu erkennen ist der erste Schritt. Die tatsächliche Ursache zu finden, der zweite. Und die Definition eines konkreten nächsten Schrittes, der dritte. Mit den ADOIT Workspaces können Sie Roadmaps erstellen, Anforderungen priorisieren, Verantwortlichkeiten zuweisen und den Fortschritt verfolgen – alles an einem Ort. So werden Verbesserungen nicht mehr nur zu Ideen, sondern zu konkreten, nachvollziehbaren Maßnahmen mit klarer Verantwortung.

Die Suche nach der Ursache eines Problems endet selten bei einem einzigen Punkt. Eine fehlerhafte Schnittstelle einer Anwendung kann mehrere Komponenten betreffen und dadurch weitere Prozesse stören. EAM macht diese Kettenreaktionen sichtbar, sodass Risiken früh erkannt und Schwachstellen in Anwendungen, Schnittstellen oder Daten behoben werden können, bevor größere Störungen entstehen.

Wenn die tatsächliche Ursache eines Problems bekannt ist, lassen sich Investitionsentscheidungen viel gezielter treffen. Ressourcen werden genau dort eingesetzt, wo sie gebraucht werden und den größten Effekt erzielen.

Die Lösung der Ursachen statt nur der Symptome führt zu schnelleren, zuverlässigeren und konsistenteren Services – und damit zu einer besseren Kundenerfahrung und höherer Kundenzufriedenheit.

Jeder Service hängt von einem Prozess ab, und jeder Prozess benötigt unterstützende Infrastruktur. GPM zeigt, was in einem Prozess passiert und wo es hakt. EAM macht die Systeme, Anwendungen und Daten sichtbar, die jeden Schritt ermöglichen. Gemeinsam ermöglichen sie es, genau zu erkennen, was geändert werden muss und warum. Wenn GPM und EAM dasselbe Repository nutzen, können Prozessverantwortliche und Architekt:innen dieselben Objekte betrachten, Abhängigkeiten verstehen und an den tatsächlichen Problemen arbeiten – statt auf Annahmen zu reagieren.

Das ist jedoch nur eine Seite der Medaille. Im nächsten Blogbeitrag zeigen wir, wie Erkenntnisse von der strategischen Ebene (EAM) in operative Änderungen auf Prozessebene (GPM) übersetzt werden können.