Komplexität meistern – Wie Prozessautomatisierung gelingt

Als ich vor knapp zehn Jahren in mein erstes großes Projekt zur Prozessautomatisierung gestartet bin, war ich voller Enthusiasmus. Ich war fest davon überzeugt, dass wir jede Herausforderung mit dem richtigen Prozessdesign und der passenden Technologieplattform lösen können – egal wie komplex das Vorhaben ist. BPMN-Tools, Automatisierungsframeworks, moderne Workflow-Engines – das war meine Welt.

Was soll ich sagen: Heute sehe ich viele Dinge anders. Denn nicht alles lief so wie geplant. Viele Projekte blieben hinter den Erwartungen zurück und manche Roadmaps führten in Sackgassen.

Was ich in all den Jahren gelernt habe: Es geht nicht nur um Tools, Plattformen oder Prozesse. Es geht vor allem um den Kontext, in dem diese eingesetzt werden – um Teams, um Reifegrade und um die Fähigkeit, Komplexität zu verstehen und zu meistern.

In diesem Beitrag möchte ich meine Erfahrungen teilen – ehrlich, praxisnah und mit dem Ziel, dass ihr euch auf eurem eigenen Weg ein paar Umwege ersparen könnt.

Mein persönlicher Aha-Moment

Angefangen hat alles mit meinem ersten Projekt im Jahr 2016: voller Elan, als Camunda-Enthusiast, war ich Teil eines ambitionierten Vorhabens, ein umfassendes Prozessframework im Bankingumfeld zu entwickeln. Die Erwartungen waren hoch – doch nach drei Jahren waren gerade einmal vier Prozesse produktiv umgesetzt. Das Projekt blieb weit hinter seinen Zielen zurück.

Nach einigen Erfolgen in späteren Projekten schöpfte ich neuen Optimismus. Ende 2020 war ich überzeugt, endlich verstanden zu haben, wie eine funktionierende Plattform aussehen muss – skalierbar, flexibel und effizient. Mit diesem Selbstverständnis startete ich in mein drittes Plattformprojekt. Doch die Realität holte mich ein: Das Projekt wurde Ende 2022 eingestellt – das Budget war aufgebraucht, die Ergebnisse enttäuschend, der Frust groß.

Der Wendepunkt kam für mich Anfang 2024, als ich auf die Konzepte von Wardley Mapping und Team Topologies stieß. Plötzlich wurde mir klar, dass es nicht ausreicht, nur auf Prozesse und Technologien zu setzen. Es geht vielmehr darum, den Kontext zu verstehen, in dem diese eingesetzt werden – und insbesondere darum, wie Teams strukturiert und befähigt werden.

Dabei ist es essentiell, die Fähigkeiten und Kompetenzen der jeweiligen Organisation zu berücksichtigen. Erst als ich begann, diese Perspektiven einfließen zu lassen, ergab vieles endlich Sinn: Erfolgreiche Prozessautomatisierung braucht nicht nur gute Werkzeuge, sondern die richtige Einordnung und die passenden Strukturen.

Die Sackgassen, die uns blockieren

Rückblickend habe ich viele typische Fehler gemacht:

1. Eigenentwicklung statt Produkt: Warum individuelle Lösungen entwickeln, wenn bewährte Produkte am Markt existieren?
2. Digitalisierung anstatt echter Transformation: Häufig fehlte der Mut für echte Veränderung, stattdessen wurden bestehende Prozesse nur digital abgebildet – starre und komplizierte Lösungen waren die Folge.
3. Der große Wurf: Wir planen zu groß, wollen sofort eine umfassende Plattform und verlieren dabei an Agilität und Geschwindigkeit.
4. Blockierte Teams: Entscheidungen brauchten unzählige Abstimmungen, keiner fühlte sich verantwortlich.
5. Fachbereich vs. IT: Die Hoffnung, BPM würde die IT überflüssig machen, führte zu unrealistischen Erwartungen und Frustration.
6. Die eigenen Fähigkeiten nicht im Blick behalten: Was in anderen Organisationen funktioniert hat, lässt sich nicht einfach übertragen. Zu oft kopieren wir Best Practices, ohne zu prüfen, ob unsere Teams, unsere Kultur und unsere technische Basis dazu überhaupt passen.

Vielleicht erkennt ihr einige dieser Situationen auch aus eurer Praxis?

Wenn ja, stellt sich die entscheidende Frage: Wie treffen wir in solchen komplexen Umfeldern bessere Entscheidungen? Wir brauchen einen Kompass, der uns durch die Unsicherheiten der digitalen Transformation navigiert. Und dieser Kompass beginnt mit einem besseren Verständnis unseres Kontexts – und mit einem klaren Blick auf die Landschaft, in der wir agieren.

Der Kompass für bessere Entscheidungen

Eines ist klar: Der Blick nach außen hilft nicht automatisch weiter. Es reicht nicht auf einer Konferenz zu hören: “Unternehmen X hat Camunda erfolgreich eingeführt – und übrigens mit SCRUM gearbeitet.“ Und diese Erfolgsstory dann blind zu kopieren, ohne den Kontext zu hinterfragen. Simon Wardley nennt dieses Verhalten “Blindes Schachspielen”. Wir kopieren Züge, ohne das Spiel zu verstehen oder gar zu wissen, dass wir ein Spiel spielen.

Was uns fehlt, ist Situational Awareness – das Bewusstsein für unsere eigene Ausgangssituation. Und genau hier setzt Wardley Mapping an.

Was genau ist Wardley Mapping?

Wardley Mapping ist ein strategisches Werkzeug, das hilft, fundierte, kontextabhängige Entscheidungen zu treffen. Es ist eine Art Landkarte, die unsere Ressourcen sichtbar macht – und das auf zwei Achsen:

• Die Y-Achse beschreibt die Sichtbarkeit oder den Nutzen für den Kunden – oben das, was direkt im Kundenfokus steht, unten die internen Strukturen.
• Die X-Achse beschreibt den Reifegrad der Komponente – von Genesis (etwas völlig Neues) über Custom (maßgeschneiderte Lösung), Product (ein fertiges Produkt) bis zu Commodity (eine standardisierte und austauschbare Komponente).

Jede Phase hat ihre eigenen Eigenschaften, Risiken und Anforderungen. Fehler entstehen, wenn wir Technologien oder Lösungen in einer falschen Phase einsortieren.

Ein besonders anschauliches Beispiel ist das Thema Dienstreiseantrag – ein Prozess, den viele Unternehmen kennen. In einem meiner Projekte wurde dieser Prozess mittels BPMN digitalisiert. Die Begründung: “Unsere Anforderungen sind speziell, wir brauchen dafür eine maßgeschneiderte Lösung, kein Standardsystem ist geeignet.” Die Konsequenz war, dass wir nicht nur den Prozess individuell modellierten, sondern auch ein eigenes Tool für das Formulardesign entwickelten, weil angeblich keine bestehende Lösung passte.

Genau hier zeigt Wardley Mapping seinen Wert. Auf der Map lässt sich klar erkennen: Ein Dienstreiseantrag ist ein Prozess mit sehr niedriger Kunden-Sichtbarkeit und hohem Reifegrad – also Commodity. Auch das Formulardesign für diesen Anwendungsfall gehört in denselben Bereich. Der Markt bietet unzählige ausgereifte und kostengünstige Lösungen – warum also selbst entwickeln?

Natürlich kann es gute Gründe geben, ein eigenes Formulardesign zu bauen – etwa wenn man wirklich in einem Umfeld agiert, in dem extrem hohe Anforderungen an Usability, Accessibility oder dynamische Logik gestellt werden, die kein Produkt am Markt erfüllt. Aber dann sollte auch klar sein: Wir verlassen bewusst den Commodity-Bereich und begeben uns in Custom oder sogar Genesis. Das bedeutet mehr Verantwortung, mehr Risiken und mehr langfristigen Pflegeaufwand.

In unserem Fall jedoch war das nicht gerechtfertigt. Wir verschwendeten wertvolle Monate und interne Ressourcen auf ein Problem, das längst gelöst war – und damit meine ich nicht nur das Thema Formulardesign, sondern den gesamten Prozess. War es wirklich notwendig, diesen individuell aufzubauen, anstatt auf eine bewährte Lösung zurückzugreifen?

Ein Beispiel zur Verdeutlichung: Angenommen, unsere Dienstreisen stehen hauptsächlich im Zusammenhang mit Workshops, die wir für Kunden anbieten. Wie entscheidend ist in diesem Fall das Reisemanagement für unseren eigentlichen Wertbeitrag? Trägt eine individuelle Abbildung des Dienstreiseprozesses tatsächlich zur Verbesserung unserer Beratungsleistung bei? Oder wäre es sinnvoller, den Prozess zu vereinfachen und ihn in ein Standardsystem zu überführen, um unsere Energie auf das zu richten, was uns als Unternehmen wirklich differenziert?

Hier hilft Wardley Mapping dabei, blinde Flecken aufzudecken und diese Diskussionen im Team offen zu führen.

Wardley Maps zwingen uns, unbequeme Fragen zu stellen – und genau das ist ihr größter Wert. Sie helfen, knappe Ressourcen gezielt einzusetzen und Klarheit über technologische und organisatorische Entscheidungen zu schaffen.

Die Komplexität im Griff behalten – Wir brauchen eine Bewertungsgrundlage für Entscheidungen

Nachdem wir mit Wardley Mapping einen ersten Kompass gefunden haben, stellt sich die nächste zentrale Frage: Wie bewerten wir unsere Vorgehensweise in komplexen Automatisierungsvorhaben richtig?

“The most fundamental problem in software development is complexity.” — Bjarne Stroustrup

Die Antwort liegt in einem besseren Verständnis von Komplexität – denn sie ist der ständige Begleiter jeder Digitalisierung. Und zwar in zwei Spielarten - der essentiellen und der akzidentellen Komplexität:

• Essentielle Komplexität ist die Komplexität, die dem eigentlichen Problem innewohnt. Sie gehört zur Domäne, zum Prozess oder zur Geschäftstätigkeit. Diese Komplexität können und sollen wir nicht wegrationalisieren – sie ist Teil der Wertschöpfung.
• Akzidentelle Komplexität hingegen entsteht durch unsere Entscheidungen: durch zu ambitionierte Plattformstrategien, unnötige Individualentwicklung, technische Fehlgriffe oder Missverständnisse zwischen IT und Fachbereich.

Ein konkretes Beispiel: Beim Dienstreiseantrag aus meinem früheren Projekt war die essentielle Komplexität minimal. Es geht im Kern um ein simples Regelwerk: Wer darf wann, wohin, mit welchem Transportmittel reisen. Doch statt diesen Prozess pragmatisch und mit einer vorhandenen Lösung am Markt zu digitalisieren, hielten wir am bestehenden Ablauf fest – mit all den Sonderfällen, Genehmigungsschleifen und historischen Ausnahmen.

Der Wille, den Prozess im Zuge der Transformation zu hinterfragen und bewusst zu vereinfachen, fehlte schlichtweg. Stattdessen begannen wir, den Status quo digital nachzubauen. Schnell entstanden Sonderfälle wie “Genehmigung über drei Hierarchieebenen”. Anstatt den Prozess zu transformieren, haben wir ihn zementiert – nur eben digital.

Diese Anforderungen führten dazu, dass der Prozess nicht nur komplexer wurde, sondern dass wir meinten, eine eigene BPM-Lösung, ein individuelles Formulardesign und eine umfassende Integrationsplattform zu benötigen. Das Ergebnis: massive akzidentelle Komplexität, die wir selbst erzeugt hatten. Rückblickend war das überdimensioniert und hätte vermieden werden können, wenn wir den Mut gehabt hätten, den Prozess zu vereinfachen und auf vorhandene Standards zu setzen.

Der Einsatz einer fertigen Low Code Plattform wäre auch ein möglicher Lösungsweg gewesen. Aber dafür müssen die verantwortlichen Personen bereit sein, die eigenen Anforderungen und Wünsche an die Funktionen der Plattform anzupassen. Sonst laufen wir Gefahr die Vorteile einer solchen Lösung zu verspielen und wundern uns dann, warum der gewünschte Geschwindigkeitsvorteil ausbleibt.

Wenn wir verstehen, welche Prozesse im Unternehmen tatsächlich geschäftskritisch und einzigartig sind – und welche nicht –, können wir bewusst entscheiden: Was rechtfertigt Individualaufwand? Und was ist schlichtweg Commodity, das wir zukaufen oder standardisieren sollten?

Komplexität lässt sich nicht vermeiden, aber sie lässt sich gestalten. Die wichtigste Leitfrage dabei lautet: Wie viel von unserer Komplexität ist wirklich notwendig – und wie viel davon haben wir selbst verursacht? Eine kluge Automatisierungsstrategie fokussiert sich darauf, die akzidentelle Komplexität systematisch zu reduzieren.

Plattform – Fluch oder Segen?

Ein weiterer Stolperstein der auf uns wartet, ist die Bereitstellung und Weiterentwicklung einer zentralen Plattform. Der Gedanke klingt zunächst nachvollziehbar - schließlich verspricht eine Plattform Wiederverwendbarkeit, Konsistenz und Skaleneffekte. Sie erscheint wie das ideale Schweizer Taschenmesser: Ein Tool, das für jeden Prozess, jedes Team und jede Situation gewappnet ist.

Doch genau hier lauert die nächste große Falle: Der Versuch, zu früh eine Plattform zu bauen, endet häufig nicht bei einem eleganten Werkzeug, sondern bei einem überdimensionierten Multifunktionsgerät, das unhandlich, schwer wartbar und kaum mehr zu verwenden ist.

Plattformen machen dann Sinn, wenn sie sich auf standardisierte, gut verstandene Funktionen konzentrieren – also dort, wo wir uns im Wardley Mapping im Bereich Product oder Commodity befinden. Eine Plattform für Authentifizierung oder Dokumentengenerierung kann extrem wertvoll sein, weil sie technische Grundlagen effizient bereitstellt.

Problematisch wird es jedoch, wenn wir mit dem Bauen eigener Plattformen beginnen, noch bevor wir den tatsächlichen Bedarf und die Prozesse wirklich verstanden haben – oder noch schlimmer: Wenn die Plattform selbst noch im Custom- oder sogar Genesis-Stadium ist. In diesen Fällen zementiert die Plattform Annahmen und Anforderungen, die sich noch im Fluss befinden. Damit erschwert sie Anpassungen, verlangsamt die Entscheidungswege und erhöht massiv die kognitive Last aller beteiligten Teams.

Ein zu früher Plattformansatz bedeutet in der Praxis: Man muss Entscheidungen vorwegnehmen, Abhängigkeiten managen, Schnittstellen definieren und gleichzeitig sicherstellen, dass alles stabil und flexibel bleibt. Das funktioniert selten – vor allem nicht mit einem Team, das gerade erst am Anfang der Automatisierung steht. Die Konsequenz ist, dass man mehr mit der Pflege der Plattform beschäftigt ist als mit dem eigentlichen Ziel: Prozesse sinnvoll zu automatisieren und den Fachbereichen echte Mehrwerte zu liefern.

Kurz gesagt: Eine Plattform ist kein Allheilmittel – sie ist ein Werkzeug für die richtige Phase, aber kein Startpunkt für jede Initiative.

Die richtigen Teams finden und organisieren

Nach dem Blick auf technologische Plattformen stellt sich eine weitere Frage: Wie müssen wir eigentlich organisiert sein, damit wir die Herausforderungen der Digitalen Transformation erfolgreich bewältigen können? Denn eine gute technologische Grundlage alleine genügt nicht – es braucht die passenden Menschen in den passenden Strukturen.

Conways Law bringt es auf den Punkt: Die Struktur von Software-Systemen spiegelt die Kommunikationsstrukturen der Organisation wider, die sie hervorgebracht hat. Wenn Teams fragmentiert arbeiten, unterschiedliche Ziele verfolgen oder stark voneinander abhängig sind, wird sich genau das in den Systemen und Plattformen widerspiegeln – mit allen bekannten Problemen.

Und hier setzt das Konzept von Team Topologies an – ein Modell, das uns hilft, Teams so zu strukturieren, dass sie eigenverantwortlich und effektiv arbeiten können.

Team Topologies unterscheidet dabei in vier Teamtypen und drei Interaktionsmodi, mit dem Ziel, kognitive Last zu reduzieren, schnelle Veränderungen zu ermöglichen und klare Verantwortlichkeiten zu schaffen:

• Stream-Aligned Teams sind das Herzstück: Sie sind entlang eines fachlichen oder wertschöpfenden Flusses ausgerichtet – z.B. eines Prozesses – und sollen möglichst autonom agieren können. Sie tragen Verantwortung von der Anforderung bis zum Betrieb.
• Enabling Teams unterstützen Stream-Aligned Teams durch Coaching, Schulung oder methodische Beratung, z.B. bei der Einführung neuer Technologien oder Praktiken.
• Complicated Subsystem Teams kümmern sich um komplexe technische Domänen, bei denen tiefes Spezialwissen erforderlich ist – wie z.B. Machine Learning oder Process Engines.
• Plattform-Teams stellen wiederverwendbare Services und Tools bereit, welche die Arbeit der Stream-Aligned Teams erleichtern. Sie minimieren kognitive Last durch gute Developer Experience und klar definierte Schnittstellen.

Diese Struktur ist nicht nur ein theoretisches Konstrukt – sie hilft ganz praktisch dabei, Verantwortlichkeiten sauber zu trennen und Blockaden zu vermeiden. Statt langwierigen Abstimmung zwischen IT und Fachbereich gibt es ein gemeinsames Ziel: schnelle, fachlich getriebene Veränderungen, die durch autonome Teams realisiert werden.

Gerade in der Prozessautomatisierung ist diese Struktur Gold wert. Denn dort treffen häufig klassische Fachbereichslogik, technische Anforderungen und organisatorische Veränderungen aufeinander. Nur wenn Teams in der Lage sind, fachliche Anforderungen direkt umzusetzen – ohne permanent auf zentrale Plattform-Teams oder Gremien angewiesen zu sein – entstehen schnelle Innovationszyklen.

Team Topologies liefert dafür den passenden Bauplan. Man kann klein anfangen. Ein einziges gut aufgestelltes Stream-Aligned Team reicht, um erste Automatisierungserfolge zu erzielen. Skaliert wird erst, wenn nötig – und zwar bewusst aufgrund der kognitiven Last, nicht aufgrund abstrakter Organigramme.

Ein Vorgehen könnte vereinfacht dargestellt wie folgt aussehen:

• Zu Beginn sollten Methoden und Technologien gewählt werden, die es erlauben, in einem Lighthouse-Projekt mit einem einzigen Stream-Aligned Team zu starten. Dieses Team sollte den gesamten Lebenszyklus eines Automatisierungsvorhabens abbilden können – von der Fachanforderung bis zum Betrieb.
• Wird die kognitive Last bei weiteren Use Cases für ein einzelnes Team zu hoch, sollte anhand klarer fachlicher Grenzen aufgeteilt werden. An diesem Punkt lohnt es sich, über den Einsatz von Enabling Teams nachzudenken, die methodisch, technisch oder organisatorisch unterstützen können – etwa durch Schulungen, Frameworks oder gezieltes Coaching.
• In einer weiteren Ausbaustufe wird es sicherlich zu einem Punkt kommen, an dem verschiedene Funktionalitäten oder Prozessartefakte zwischen Teams geteilt werden sollen – etwa Komponenten für Integration, Formulargenerierung oder Monitoring. Das Ganze ergibt dann eine Plattform – idealerweise in Form eines dedizierten Plattformteams mit klaren Schnittstellen und einem Fokus auf Developer Experience.

Wichtig ist, die richtige organisatorische Komplexität zur richtigen Zeit zu schaffen. Wer zu früh zu viel will, überfordert Teams und bremst Innovation.

Erfolg messbar machen

Nach der Teamstruktur stellt sich unweigerlich eine weitere zentrale Frage: Woher wissen wir eigentlich, ob wir auf dem richtigen Weg sind? In vielen Organisationen kommt dieser Gedanke oft zu spät. Dabei ist es essenziell, Erfolg nicht nur zu vermuten, sondern ihn gezielt zu messen – und das möglichst frühzeitig.

Wie messen wir also den Erfolg unserer Initiativen? Diese Frage taucht in fast jedem Transformationsprojekt irgendwann auf – und sie ist absolut berechtigt. Denn ohne ein gemeinsames Verständnis davon, was “Erfolg” überhaupt bedeutet, kann es auch keine gezielte Verbesserung geben. Wir brauchen ein gemeinsames Vokabular, um Fortschritt greifbar zu machen.

Ein bewährter Rahmen dafür sind die DORA-Metriken, die aus der DevOps-Forschung stammen und in vielen erfolgreichen Unternehmen eingesetzt werden. Sie helfen, die Leistungsfähigkeit von Teams und technischen Systemen messbar zu machen:

• Lead Time for Change – Wie lange dauert es vom ersten Commit bis zur produktiven Auslieferung einer Änderung?
• Deployment Frequency – Wie oft werden Änderungen in die Produktion gebracht?
• Failed Deployment Rate – Wie häufig führen Deployments zu Störungen oder Rollbacks?
• Mean Time to Recovery (MTTR) – Wie schnell können Systeme nach einem Ausfall wiederhergestellt werden?

Diese Metriken liefern ein objektives Bild darüber, wie gut Teams in der Lage sind, Änderungen effizient, stabil und sicher umzusetzen. Gerade bei der Automatisierung von Prozessen im Gensis und Custom Bereich – wo Fachgebiet, IT und Betrieb ineinandergreifen müssen – sind sie eine wertvolle Orientierungshilfe.

Wenn wir den BPM Lifecycle ernst nehmen und wirklich leben wollen, bedeutet das auch, den Cost of Change zu reduzieren. Es reicht nicht, Prozesse einmal zu automatisieren – sie müssen auch kontinuierlich angepasst und verbessert werden können. Genau deshalb brauchen wir Teams und Strukturen, die veränderungsbereit und agil sind. Der Fokus verschiebt sich weg vom einmaligen Projekterfolg hin zur dauerhaften Wandlungsfähigkeit einer Organisation – und hier helfen die DORA-Metriken, diese Fähigkeit messbar und transparent zu machen.

Doch genauso wichtig ist die Einsicht: Diese Metriken sind ein guter Startpunkt – aber sie sind nicht das Ende der Diskussion. Jede Organisation darf und sollte ihre eigenen Metriken entwickeln. Denn vielleicht ist für euch nicht die reine Deployment-Frequenz entscheidend, sondern eher, wie schnell ein digitalisierter Prozess dem Endanwender spürbaren Nutzen bringt. Oder es ist die Durchlaufzeit eines Geschäftsprozesses – etwa vom Eingang eines Antrags bis zur finalen Genehmigung. Das kann eine wertvolle Metrik sein, um den Erfolg einer Automatisierung auf fachlicher Ebene zu bewerten.

Aber all diese ergänzenden Metriken haben eines gemeinsam: Sie müssen in einen übergeordneten Rahmen eingebettet sein. Und genau hier liegt der Wert der DORA-Metriken. Sie fokussieren nicht auf das Ergebnis eines einzelnen Prozesses, sondern auf die Fähigkeit eines Teams, Veränderungen überhaupt zuverlässig und schnell umzusetzen. Genau das ist essenziell für jede digitale Transformation.

Denn Transformation ist mehr als nur Technologie oder Prozesse – sie ist ein kontinuierlicher Wandel. Und dieser Wandel gelingt nur, wenn Teams in der Lage sind, iterativ zu arbeiten, Feedbackzyklen zu verkürzen und Verantwortung zu übernehmen. Deshalb ist DORA so wichtig: Die Metriken messen nicht nur Output, sondern sie zeigen auf, wie gut die Organisation als Ganzes auf Veränderung eingestellt ist.

Nimm deine Transformation selbst in die Hand!

Wenn wir uns nun die Frage stellen, wer eigentlich für die Umsetzung der Transformation verantwortlich sein sollte, stoßen wir auf einen der sensibelsten Punkte in jedem Projekt: Make or Buy?

Nach all dem, was wir über Prozesse, Teams, Technologien und Metriken gelernt haben, ist klar: Diese Entscheidung sollte nie pauschal, sondern stets kontextbezogen getroffen werden. Und genau hier kommt Wardley Mapping ein letztes Mal zum Tragen.

Wardley Maps helfen uns zu erkennen, welche Fähigkeiten wir intern aufbauen und bewahren müssen, und wo es sinnvoll ist, auf externe Partner zu setzen. Die Grundregel lautet:

• Genesis und Custom: Hier seid ihr im Innovationsbereich. Es geht um neue, noch unausgereifte oder stark an eure Organisation angepasste Lösungen. Diese Komponenten sind eng mit eurer Strategie verbunden – hier braucht ihr Teams, die eure Fachlichkeit verstehen, eng mit euren Stakeholdern arbeiten und schnell reagieren können.
• Product und Commodity: In diesen Bereichen ist die Lösung ausgereift, vergleichbar und am Markt verfügbar. Hier macht es absolut Sinn, externe Dienstleister einzubinden oder ganze Aufgabenpakete auszulagern – zum Beispiel Hosting, Standardintegrationen oder Infrastruktur.

Das bedeutet auch: Nicht jede Leistung, die ein externer Partner anbietet, sollte blind beauftragt werden – besonders nicht im Genesis- oder Custom-Bereich. Dort braucht ihr Teams, die eng in eure Geschäftsprozesse eingebunden sind, Verantwortung übernehmen und strategische Entscheidungen treffen können. Und diese Teams bestehen idealerweise aus internen Mitarbeiter:innen, unterstützt durch gezielte externe Expertise.

Ich selbst bin Berater – und genau deshalb weiß ich, wo meine Rolle aufhört. Ich kann euch helfen, Geschwindigkeit aufzunehmen, unnötige Fehler zu vermeiden und Struktur zu schaffen. Aber ich würde euch niemals empfehlen, die Verantwortung für eure Transformation in meine Hände zu legen.

Denn Transformation bedeutet Wandel – und Wandel gelingt nur gemeinsam. Nur wenn ihr selbst versteht, warum ihr etwas tut, welche Prinzipien euch leiten und welche Ziele ihr verfolgt, kann nachhaltiger Fortschritt entstehen.

In diesem Sinne: Nimm deine Transformation selbst in die Hand – mit den richtigen Methoden, mit dem passenden Team und mit der Klarheit darüber, was wirklich zählt.

Survival-Tipps

Nach all den Erfahrungen, Erkenntnissen und auch Rückschlägen der letzten Jahre möchte ich euch zum Abschluss noch einige Kernpunkte mitgeben – meine “Lessons Learned”. Wenn ich heute eine Automatisierungsinitiative starte, sind es genau diese Prinzipien, auf die ich Wert lege.

• Schaffe Situational Awareness für bessere Entscheidungen.
• Sei bereit für Transformation, nicht nur für Digitalisierung.
• Definiere KPIs und Messe deinen Erfolg.
• Halte die akzidentelle Komplexität so gering wie möglich.
• Stelle deine Teams auf Wandel ein.
• Behalte die Hoheit über die wichtigen Ressourcen deiner Transformation.

Letztendlich gilt: Die beste Technologie und Methode nutzt nichts ohne Klarheit über den Kontext und Teams, die wirklich autonom arbeiten können.

Ich hoffe, meine Erfahrungen helfen euch, einige meiner Fehler zu vermeiden und eure Automatisierungsprojekte nachhaltig und erfolgreich zu gestalten. Lasst uns gemeinsam Komplexität meistern!