Verhandeln als Organisationsprinzip oder was tun, damit IT- & KI-Lösungen nicht länger selbst die Transformations- und Digitalisierungsprozesse unterlaufen.

Gerade habe ich folgende E-Mail bekommen:

„Lieber Thomas, leider verzögert sich die Auslieferung deiner Bestellung (Auftragsnummer: ...) Wir bitten um etwas Geduld… Du kannst Dein Paket jederzeit hier verfolgen: <Sendungsverfolgung>….“. Nur beim Logistiker ist die Sendungsnummer unbekannt, obwohl mir gestern noch der morgige Tag vom Hersteller als Liefertermin verbindlich zugesagt wurde.

Offensichtlich haben die Prozesse des Logistikers und des Herstellers ein Eigenverhalten – jeder seins und dass zulasten des Gesamtsystems.

Ist das ein System- oder Architekturfehler?

Komplexität und Dynamik in Digitalisierungs- und Transformationsvorhaben

Die Summe zweier hoch effizienter KI-unterstützter Lösungen ergibt nicht zwingend ein neues hocheffizientes System. Im Gegenteil.

Beide IT-Lösungen arbeiten mit ihrem spezifischen Prozessmodell: einer individuellen, aufgaben- und ablaufspezifischen (deterministischen) Sicht auf den auszuführenden Prozess. Jeder hat seine individuellen Ziele. Dabei werden die Prozesse und Modelle zunehmend weiter ausdifferenziert, um den zur Lösung der Aufgabenstellung notwendigen Prozess vollständig abbilden und damit steuern zu können. Die Modelle entkoppeln die Informations- und Kommunikationsprozesse, von den physischen Prozessen, der Zeit und dem eigentlichen Systemverhalten. Der Bezug zum Kontext, zum System selbst, wird so immer weiter ausgeklammert. Oftmals bewusst, weil das Systemverhalten in einem separaten Management-prozess gesteuert werden soll. Die Prozesse und ihre Steuerung verselbständigen sich.

Die Modelle sind nicht das System. Und sie verhalten sich auch nicht wie das System. Wahrscheinlich ist es dem Prozessmanagement gar nicht bewusst, dass sie mit den Modellen die Steuerbarkeit „ihrer“ Prozesse und die Regelbarkeit des Systems unterlaufen. Zumal sie oft gar nicht mehr den Bezug zum System sehen und/ oder verantworten.

Anders als die aus dem System als Prozess herausgelösten Aufgabenstellungen mit ihren abgeschlossenen deterministischen Modellen, sind die realen Systeme in aller Regel komplexe dynamische Systeme. Das heißt, das System weist ein emergentes Eigenverhalten auf. Es ist nicht vollständig beobachtbar und nicht vollständig modellierbar und in der Folge, nicht (oder nur unter sehr eingeschränkten Bedingungen) steuerbar.

Mit anderen Worten, der Glaube, die Komplexität des Systems auf eine Menge von definierten Prozessen reduzieren und diese mit einem übergeordneten Managementprozess nach einem vorgegebenen Plan steuern zu können, ist ein Denkfehler. Ein Plan spiegelt das Verhalten eines Modells, eines Prozesses, nicht aber das tatsächliche Systemverhalten in seiner Komplexität.

Die Folgen sind bekannt: So erfolgreich die Implementierung / Digitalisierung einzelner Prozesse erfolgt, so sehr scheitern prozessübergreifende Digitalisierungs-/ Transformationsprojekte. Heute wird dieses Phänomen gern als Paradoxon bezeichnet.

Meines Erachtens ist das kein Paradoxon, sondern ein Architekturfehler, wenn man versucht, ein komplexes dynamisches System auf ein deterministisches Modell zu reduzieren und zu steuern.

Dabei spielt die Dynamik m.E. eine besondere Rolle. Das heißt, mit der breiten Verfügbarkeit von IT- und KI untergraben diese Technologien selbst die Beobachtbarkeit, die Modellierbarkeit und im Ergebnis die Steuerbarkeit der Prozesse und damit die Regebarkeit des Systems.

Durch die Entkopplung der Informationen und Prozesse von dem eigentlichen System und den physischen Prozessen, werden immer öfter bestehende Modelle und Pläne, die Planungen neuer Vorhaben oder auch die Vorhaben selbst in Frage gestellt, bevor sie modelliert, geplant und/ oder umgesetzt werden können. Nicht selten drohen, ganze Systeme, Teams, Unternehmen und Organisationen, unter den schnellen und umfassenden Datenmengen zu kollabieren. Immer öfter treten Situationen auf, in denen sich die Daten und Informationen der verschiedenen IT-Systemen widersprechen, nicht eindeutig oder gar nicht verfügbar sind.

Dynamisches Organisationsdesign

Nur, das war nicht immer so. Der prinzipielle Unterschied heutiger Lösungen zu denen „davor“, besteht wohl darin, dass die Kommunikation, der Daten- und Informationsfluss unmittelbar an den Prozess und damit an das System gekoppelt waren. Mit anderen Worten, es gab keine signifikante Differenz zwischen der Dynamik der Prozesse und der Dynamik des Systems. Der Ausgleich erfolgte durch einen implizit definierten „Feedbackprozess“. Die Folgen emergenter Ereignisse, unvorhergesehener Systemzustände, die auf die Komplexität des Systems zurückgeführt werden konnten, konnten so direkt dem Ereignis zugeordnet werden. Das System verhielt sich „quasi-deterministisch“/ kausal. Während die Zustandsinformationen aus dem Prozess als Feedback zur Regelung des Systemverhaltens genutzt werden konnten, konnte das Prozessverhalten im Sinne einer adaptiven Reglung durch die Impulse aus dem System nachgesteuert werden. Damit war eine robuste und weitestgehend ziel- und ergebnisgenaue Regelung der Systeme, ein „dynamisches Organisationsdesign“ möglich.

Damit ergibt sich die Frage, kann man die Architektur moderner Managementsysteme auch so gestalten, dass sie ähnlich zu den „früheren Managementsystemen“ das angestrebte System-verhalten dynamisch an mögliche Störungen und Veränderungen anpassen? Ist ein dynamisches Organisationsdesign auch heute möglich? Wie kann ich die Prozesse ins System „zurückholen“? Und, wenn ja, wie sieht es aus und welche Ergebnisse belegen seine Funktionsfähigkeit?

Verhandeln als Organisationsprinzip

Tatsächlich lässt sich das dynamische Organisationsdesign mit wenigen Schritten und ohne technologischen Eingriff in die Architektur der Managementsysteme umsetzen.

Der größte Unterschied zu den bestehenden Managementsystemen besteht wahrscheinlich darin, dass ein zusätzlicher Kommunikations- und Feedbackprozess in das System integriert wird. Der Vorteil: Sie können das Organisationsdesign unmittelbar, ohne Änderung, auf ihre bestehende Architektur und Infrastruktur aufbauen. Es reicht, ihre bestehenden Management-systeme mit einer zusätzlichen Kommunikationsebene zu ergänzen und auf dieser kontinuierlich „mögliche Störungen in der Motivation der Beteiligten zur Zielerreichung/ Zusammenarbeit“ zu messen und an das System, die anderen relevanten Prozesse, zu kommunizieren.

Anders als bisher, sind mögliche Konflikte in den Teams keine Störungen, sondern Impulse, die Prozesse zu überprüfen und ggf. das Handeln der Beteiligten an die Veränderungen anzupassen.

Im Ergebnis brauchen Sie „nur“ auf die Störungen zu achten, die die Zielerreichung im System potenziell in Frage stellen können. Wichtig dabei ist, dass Sie, wenn sie solche Störungen, Widerstände und Konflikte wahrnehmen, sofort intervenieren und (ver-)handeln.

Genau hier liegt das Problem: Dazu muss man sich auf die Menschen im System einlassen, auf deren Widersprüche und Konflikte. Man muss den Umgang damit lernen. Dabei ist die Technik dafür kein Hexenwerk: Unterscheiden Sie zwischen „Sein“ und „Handeln“ der Beteiligten. Während man das Sein nicht oder nur mit sehr viel Aufwand ändern kann, können Sie das Handeln mit den notwendigen Verhandlungs- und Konfliktlösungskompetenzen ad hoc ändern. Mit anderen Worten, Verhandlungs- und Konfliktlösungskompetenz werden zum Organisationsprinzip.

Wenn Sie mehr dazu wissen wollen, lesen sie dazu das Whitepaper „Dynamisches Organisationsdesign – Verhandeln als Organisationsprinzip, oder wie bleiben Unternehmen Teams und Organisationen trotz Komplexität und zunehmender Dynamik handlungsfähig?“

Schreiben Sie einfach „DynOrg“ in die Kommentare.