Warum Digitalisierungsprojekte an den Übergängen scheitern

Wenn ein Digitalisierungsvorhaben scheitert, ist der Code fast nie der Grund.

Das lässt sich in Nachbetrachtungen erstaunlich zuverlässig beobachten. Die Software funktioniert weitgehend. Die Anforderungen waren nicht absurd. Das Team war nicht unfähig. Trotzdem ist am Ende weniger passiert als erwartet, es dauerte länger, und die Wirkung, wegen der das Vorhaben ursprünglich begonnen wurde, ist schwer nachweisbar.

Der Grund liegt an einer unauffälligen Stelle: an den Übergängen. Überall dort, wo Verantwortung von einer Gruppe zur nächsten wechselt, entsteht eine Lücke. Und Lücken haben keinen Verantwortlichen.

Diese Beobachtung ist die Grundlage unserer Arbeit. Wir entwickeln Software — und wir kümmern uns um die Übergänge, an denen Software sonst wirkungslos bleibt.

Übergang 1: Von der Entscheidung zur Fachlichkeit

Eine Geschäftsführung entscheidet, dass ein Prozess digitalisiert wird. Was danach passieren müsste, ist präzise Beschreibungsarbeit: Was geschieht in diesem Prozess tatsächlich, mit welchen Ausnahmen, und was davon ist wesentlich?

Was stattdessen häufig passiert: Die Entscheidung wird in ein Anforderungsdokument übersetzt, das die bestehende Arbeitsweise beschreibt statt der fachlichen Realität — inklusive aller Workarounds, die aus der Schwäche des alten Systems entstanden sind. Man automatisiert damit die Vergangenheit.

Was hier hilft: gemeinsame Modellierung mit den Menschen, die den Prozess verantworten, in einer Darstellung, die beide Seiten lesen können. Event Modeling ist dafür unser bevorzugtes Werkzeug, weil es Ereignisse zeitlich sortiert statt Datenstrukturen abstrakt.

Übergang 2: Von der Fachlichkeit zur Umsetzung

Hier entscheidet sich technische Qualität — aber weniger, als man annimmt, durch die Wahl der Technologie. Entscheidend ist, ob während der Umsetzung weiter gefragt wird.

Jedes Team stößt beim Bauen auf Fälle, die in der Analyse nicht vorkamen. Die Frage ist nur, was dann geschieht: Wird nachgefragt, oder wird eine plausible Annahme getroffen und weitergearbeitet? Vermutungen sind billig in dem Moment, in dem sie entstehen, und teuer, sobald sie sich in Datenstrukturen niedergeschlagen haben.

Deshalb halten wir Ownership für den wichtigsten Faktor in dieser Phase: eine namentlich benannte Person, die technisch entscheidet, Entscheidungen begründet und unangenehme Erkenntnisse früh ausspricht.

Übergang 3: Von der Umsetzung zur Nutzung

Das ist der am gründlichsten unterschätzte Übergang. Ein System geht live, es gibt eine Schulung, vielleicht eine Anleitung — und danach beginnt der eigentliche Wettbewerb: das neue System gegen die gewohnte Arbeitsweise.

Menschen wechseln nicht, weil etwas theoretisch besser ist. Sie wechseln, wenn ihre eigene Arbeit spürbar leichter wird, und zwar früh genug, um den Umstellungsaufwand zu rechtfertigen.

Praktisch bedeutet das:

• Für jede Nutzergruppe muss es einen frühen, konkreten Gewinn geben.
• Die Menschen, die intern gefragt werden, müssen überzeugt sein — nicht nur die Leitung.
• Es braucht eine benannte Verantwortung nach dem Go-live, sonst verwaist das System.
• Widerstand ist Information, keine Störung. Er zeigt oft auf einen realen Konstruktionsfehler.

Wo dieser Übergang misslingt, entsteht der klassische Befund: Das System läuft, aber daneben liegt eine Tabellenkalkulation, in der die eigentliche Arbeit stattfindet.

Übergang 4: Von der Nutzung zur Wirkung

Ein genutztes System ist noch kein wirksames System. Wirkung heißt: Etwas ist messbar anders geworden — Durchlaufzeiten, Fehlerquoten, Abschlussraten, Aufwand pro Vorgang.

Dieser Übergang scheitert meist an einem simplen Versäumnis: Es wurde vorher nie festgelegt, woran man Erfolg erkennen würde. Ohne Ausgangswert lässt sich Verbesserung weder zeigen noch bezweifeln — und damit fehlt auch die Grundlage, ein Vorhaben fortzusetzen oder zu beenden.

Es geht dabei nicht um ausgefeilte Kennzahlensysteme. Zwei bis drei ehrliche Größen, vor dem Start erhoben, reichen fast immer.

Warum vier Kompetenzen zusammengehören

An diesen Übergängen liegt der Grund, warum wir Software-Entwicklung, Marketing, Sales und Personal nicht als vier Angebote nebeneinander verstehen, sondern als eine zusammenhängende Aufgabe.

Entwicklung liefert das System. Marketing und Positionierung sorgen dafür, dass sein Wert erklärbar ist — nach außen wie nach innen. Sales schafft Zustimmung, intern bei Stakeholdern und extern am Markt. Personal und Kultur entscheiden, ob die Organisation die Veränderung überhaupt tragen kann.

Fehlt eine dieser Seiten, entsteht der bekannte Zustand: gute Software ohne Wirkung — oder große Wirkungsversprechen ohne tragfähige Technik.

Was daraus folgt

Prüfen Sie ein Vorhaben nicht nur an seinem Fortschritt, sondern an seinen Übergängen. Vier Fragen genügen für einen ersten ehrlichen Befund:

1. Ist die Fachlichkeit so beschrieben, dass die Fachabteilung sie bestätigen könnte?
2. Gibt es eine namentlich verantwortliche Person für den technischen Verlauf?
3. Weiß jede Nutzergruppe, was für sie konkret besser wird?
4. Ist vorher festgelegt, woran Wirkung erkennbar wäre?

Wo eine dieser Fragen unbeantwortet bleibt, liegt mit hoher Wahrscheinlichkeit das Risiko — unabhängig davon, wie gut der Code ist.