Organisationsübergreifend arbeiten

Wenn zwei Organisationen digital zusammenarbeiten wollen, verbinden wir in der Regel ihre Systeme. Wir vereinbaren, welche APIs verfügbar sind, welche Daten ausgetauscht werden und welche Nachrichten auf der anderen Seite etwas auslösen. Das funktioniert, bis die Zusammenarbeit enger wird. Dann muss Organisation A immer mehr über den Prozess von Organisation B wissen, und eine Änderung auf der einen Seite bringt auf der anderen etwas zum Erliegen.

Die Alternative ist, eine gemeinsame Plattform zu nutzen. Das nimmt einen Teil der technischen Arbeit ab, schafft aber eine andere Abhängigkeit: Beide Organisationen müssen sich an dieselbe Anwendung, dasselbe Datenmodell und oft auch dieselbe Arbeitsweise anpassen.

So oder so wird digitale Zusammenarbeit mit einem Stück Autonomie bezahlt. Das ist merkwürdig. Außerhalb von Software übergeben wir ständig eine Verantwortung, ohne vorzuschreiben, wie die andere Organisation intern arbeitet. Eine Gemeinde, die eine statische Prüfung in Auftrag gibt, steuert nicht den Prozess des Ingenieurbüros. Sie muss wissen, was sie anfragt, welche Informationen dazugehören, welche Anforderungen das Ergebnis erfüllen muss und was zurückkommt.

Organisationen delegieren Verantwortlichkeiten. Software verbindet in der Regel Systeme.

Nehmen Sie einen Antrag auf Baugenehmigung. Im Verlauf des Cases benötigt die Gemeinde eine statische Prüfung und übergibt sie an ein Ingenieurbüro.

Der Case bleibt bei seinem Eigentümer, der Gemeinde. Was die Organisationsgrenze überschreitet, ist eine Case-Rolle: eine definierte Verantwortung, mit Zugriff auf die Informationen und Aktionen, die sie in jeder Phase des Cases benötigt. Das Büro wirkt am Case mit, ohne den Case selbst zu übernehmen und ohne die Systeme der Gemeinde übernehmen zu müssen. Die Gemeinde wiederum muss nicht wissen, wie das Büro seine Prüfung organisiert.

Die Grenze zwischen den beiden Organisationen ist die Case-Rolle. Sie beschreibt, welche Verantwortung übergeben wird, welche Informationen dazugehören, was die Rolle dort tun darf, wo der Case gerade steht, und welches Ergebnis erwartet wird. Das ist weit weniger, als einen ganzen Prozess oder eine ganze Akte zu teilen, und weit mehr als ein API-Aufruf.

Heute führt der Partner die Rolle im Case des Eigentümers aus oder liest sie aus seinem eigenen System; sie als eigenen Caseflow auf der Seite des Partners auszuführen, ist der nächste Schritt.

Zusammenarbeit ist selten ein einzelner, einfacher Auftrag. Während der Prüfung braucht das Büro womöglich weitere Informationen. Später geht ein Gutachtenentwurf ein, der noch Fragen aufwirft. Sobald das Gutachten endgültig ist, sollten manche Aktionen überhaupt nicht mehr möglich sein.

Eine Case-Rolle ist also kein statischer Vertrag. Die Phase, in der sich der Case befindet, bestimmt, was die Rolle gerade sehen und tun kann. Wechselt die Phase, ändert sich auch, was zur Rolle gehört: andere Informationen, andere Aktionen. Der Server setzt das bei jedem Schritt durch: Es ist keine Vereinbarung auf dem Papier, sondern eine Schranke.

Sobald ein Partner die Rolle innehat, ändern sich seine Berechtigungen mit der Phase, während der Case voranschreitet; niemand muss sie bei jedem Schritt von Hand anpassen.

Weil die Grenze eine Rolle ist, werden drei Dinge, die sich üblicherweise verheddern, von vornherein getrennt gehalten:

• Wer die Rolle innehat. Die Gemeinde kann die Prüfung einem anderen Büro übergeben oder wieder selbst übernehmen, ohne den Case neu zu gestalten. Auslagern wird zu einer Entscheidung, nicht zu einer Neugestaltung.
• Wie die Rolle ausgeführt wird. Die Mitarbeitenden, Werkzeuge und Systeme des Büros sind Sache des Büros. Ändert es sie, ändert das nichts an der Verantwortung, die es übernommen hat.
• Der Caseflow. Der Eigentümer kann seinen Prozess verbessern. Eine neue Version verändert bereits laufende Cases nicht.

Wo eine Änderung die Vereinbarung zwischen beiden berührt, müssen beide Organisationen die neuen Bedingungen annehmen; auch ein neues Büro muss die Rolle annehmen, bevor es sie innehat.

Autonomie bedeutet nicht, ohne Vereinbarungen zu arbeiten. Sie bedeutet, die eigene Arbeit innerhalb der Verantwortlichkeiten und Grenzen, die man angenommen hat, frei organisieren zu können.

Die Organisationen vereinbaren, was die Rolle liefern muss, bis wann, welche Qualität sie erfüllen muss, welche Informationen sie nutzen darf und was geschieht, wenn die Zusammenarbeit endet.

CaseFlows verknüpft diese Vereinbarung mit dem Caseflow, der läuft. Eine vereinbarte Frist muss im Prozess vorhanden sein, zusammen mit dem, was nach ihrem Ablauf geschieht, etwa dass der Case an den Sachbearbeiter der Baugenehmigung zurückgeht; andernfalls wird die Rolle nicht verbunden. Und eine Änderung der Vereinbarung gilt erst, wenn beide Organisationen sie angenommen haben.

Zusammenarbeit wird nicht nur aufgeschrieben. Ihre Grenzen werden durchgesetzt.

Für die Gemeinde hat das Ingenieurbüro eine Case-Rolle inne und übernimmt die Verantwortung für ein definiertes Ergebnis. Das heißt nicht, dass eine einzelne Person im Büro alles erledigt. Eine Projektleitung nimmt den Auftrag an, eine Fachperson führt die Analyse durch, eine Kollegin oder ein Kollege prüft sie, und jemand unterzeichnet das Gutachten.

Schon heute kann das eigene System des Büros seine Rolle über die Grenze hinweg lesen, und zwar genau in dem Umfang, den diese Rolle sehen darf. Legt eine Phase nicht fest, was die Rolle sehen darf, verlässt nichts die Plattform.

Wohin wir gehen: Das Büro startet einen eigenen Caseflow, um die angenommene Rolle zu erfüllen. Dieser Caseflow organisiert die interne Arbeit des Büros, während der ursprüngliche Case bei der Gemeinde bleibt.

Eine Gemeinde arbeitet womöglich mit mehreren Ingenieurbüros. Ein Büro betreut womöglich mehrere Gemeinden und arbeitet mit eigenen Fachleuten und Zulieferern: etwa mit einem Labor für einen Teil einer Prüfung, dem es auf genau dieselbe Weise eine Rolle übergeben könnte.

Das Ziel ist, diese Kooperationen wachsen zu lassen, ohne für jede neue Beziehung ein neues Integrationsprojekt und ohne dass eine Partei die ganze Kette besitzen muss. Jede Organisation behält ihre eigenen Verantwortlichkeiten, Systeme und Arbeitsweise; offene Spezifikationen beschreiben, wie sie zusammenarbeiten.

Heute unterstützt CaseFlows die Übergabe einer Case-Rolle an eine andere Organisation. Dies zu Caseflows auszubauen, die in einem größeren Netzwerk unabhängig laufen, ist das, worauf wir hinarbeiten.

Das Ingenieurbüro kann KI einsetzen, um die Berechnungen auf Lücken zu prüfen oder einen Entwurf vorzubereiten, während eine Ingenieurin oder ein Ingenieur entscheidet. Wie es diese Arbeit organisiert, entscheidet es selbst.

Die Gemeinde hat weiterhin mit derselben Case-Rolle, demselben vereinbarten Ergebnis und derselben verantwortlichen Organisation zu tun. KI verändert, wie die Arbeit erledigt wird, nicht, wer für ihre Erbringung verantwortlich ist.

Läuft heute

• Case-Rollen mit eigener Phase, bei denen der Server zu jedem Zeitpunkt durchsetzt, was ein Beteiligter sehen und tun darf.
• Eine Rolle, die eine andere Organisation innehat, mit einer Vereinbarung, die beide Plattformen bestätigen, und einem Protokoll, das die Grenze absichert, durchgängig gemessen.
• Vereinbarungen über Ergebnis, Frist, Qualität und Beendigung, wobei die Frist im Caseflow stehen muss, bevor die Rolle verbunden wird.
• Das eigene System des Partners, das seine Rolle innerhalb der Grenzen dieser Rolle liest.
• Personen eines Partners, die sich mit dem Konto ihrer eigenen Organisation anmelden.

Wohin wir gehen

• Ein eigener Caseflow hinter einer Rolle, gestartet durch die eingehende Rolle.
• Ein Phasenwechsel, der die Plattform des Partners von selbst erreicht.
• Ein Testcase, der in der Entwicklungsumgebung die Grenze überschreitet und dort als eigener Testcase des Partners weiterläuft.
• Ketten, die sich weiter verzweigen, Organisation für Organisation.