Digitale Transformation beginnt nicht mit der Software

Ein neues Tool wird eingeführt, die Schulung ist gebucht, der Rollout-Plan steht – und trotzdem läuft es holprig. Nutzerzahlen bleiben hinter den Erwartungen zurück, alte Excel-Listen tauchen als Schatten-Lösung wieder auf, und in Retrospektiven heißt es: "Das Tool ist nicht intuitiv genug." Der Grund liegt fast nie am Tool selbst, sondern an dem, was davor hätte passieren müssen.

Die Reihenfolge, die selten passt

Software bildet ab, was in einer Organisation an Prozessen, Verantwortlichkeiten und Entscheidungswegen bereits existiert. Ist das unklar, widersprüchlich oder nur informell geregelt, macht das neue Tool die Unklarheit lediglich sichtbarer – und meist unbeliebter, weil sie jetzt an der Software "hängen bleibt". Ein System, das drei verschiedene Freigabe-Workflows gleichzeitig unterstützen soll, weil sich das Unternehmen nie auf einen geeinigt hat, wird zwangsläufig als kompliziert wahrgenommen. Nicht, weil das Tool schlecht gebaut ist, sondern weil es einen ungelösten organisatorischen Konflikt technisch nachbilden muss.

Die verbreitete Reihenfolge lautet: Tool auswählen, Tool einführen, Prozesse hinterher reparieren. Erfolgreicher – wenn auch unbequemer, weil er vor dem Kauf stattfinden muss – ist der umgekehrte Weg: Prozesse klären, dann das passende Tool dafür finden.

Rollen klären, bevor Rechte vergeben werden

Wer darf was freigeben? Wer ist bei Eskalationen zuständig? Wer verantwortet die Datenqualität in einem gemeinsam genutzten System? Diese Fragen sollten geklärt sein, bevor die ersten Berechtigungen im System vergeben werden – nicht danach, als nachträgliche Reparatur.

In der Praxis zeigt sich das oft an einem kleinen, aber symptomatischen Detail: Wenn in den ersten Wochen nach dem Rollout ungewöhnlich viele Supportanfragen zum Thema "Ich habe keinen Zugriff auf X" oder "Wer muss das eigentlich freigeben?" eingehen, ist das selten ein Tool-Problem. Es ist ein Indiz dafür, dass Rollen und Verantwortlichkeiten vor dem Rollout nicht sauber durchdacht waren.

Der Unterschied zwischen Abbilden und Verbessern

Ein häufiger Irrtum: Man geht davon aus, dass die Software-Einführung automatisch auch die Prozesse verbessert. Das stimmt nur teilweise. Ein neues Tool kann bestehende Prozesse effizienter machen – aber es macht schlechte Prozesse nicht automatisch gut. Ein Freigabeprozess mit sieben unnötigen Zwischenschritten bleibt ein Freigabeprozess mit sieben unnötigen Zwischenschritten, nur jetzt in digitaler statt in Papierform.

Deshalb lohnt sich vor jeder Tool-Einführung eine ehrliche Frage: Wird hier tatsächlich etwas verbessert, oder wird nur etwas Bestehendes digitalisiert, das eigentlich zuerst vereinfacht gehört? Diese Unterscheidung entscheidet oft darüber, ob eine Transformation als Erfolg oder als teure Umbenennung des Status quo wahrgenommen wird.

Ein typisches Beispiel

Ein mittelständisches Unternehmen führt ein neues CRM-System ein, weil Vertrieb und Kundenservice bisher mit getrennten Excel-Listen arbeiten und Informationen ständig verloren gehen. Das Tool wird sorgfältig ausgewählt, die Schulung ist gut vorbereitet – und trotzdem beschweren sich nach dem Rollout beide Abteilungen, dass das System "nicht richtig funktioniert".

Der eigentliche Befund: Vertrieb und Kundenservice hatten sich vorher nie darauf geeinigt, wer ein Kundenprofil aktuell halten darf und wer im Konfliktfall die Deutungshoheit über widersprüchliche Informationen hat. Das CRM zwingt diese Frage jetzt täglich sichtbar auf den Tisch, weil beide Abteilungen im selben Datensatz arbeiten – vorher konnte man sich in getrennten Excel-Listen bequem aus dem Weg gehen. Das Tool hat also nicht versagt. Es hat einen ungelösten Konflikt sichtbar gemacht, der vor dem Rollout hätte geklärt werden müssen.

Was das für die Praxis bedeutet

Vor jedem Tool-Rollout lohnt sich eine ehrliche Bestandsaufnahme in drei Schritten:

1. Prozesse dokumentieren, wie sie wirklich sind – nicht, wie sie laut Organigramm sein sollten. Die Lücke zwischen beidem ist oft größer als gedacht.
2. Rollen und Verantwortlichkeiten explizit klären, inklusive der unbequemen Fragen: Wer entscheidet im Konfliktfall? Wer trägt die Konsequenzen bei Fehlern?
3. Erst dann das Tool auswählen – mit dem Wissen, welche Prozesse es tatsächlich unterstützen soll, statt umgekehrt zu hoffen, dass das Tool die Prozessfragen von selbst löst.

Sind die Prozesse, die abgebildet werden sollen, überhaupt schon klar und von allen Beteiligten akzeptiert? Wenn nicht, ist genau das der eigentliche erste Schritt der Transformation – nicht die Software-Auswahl, so verlockend es auch ist, mit dem sichtbaren, greifbaren Teil des Projekts zu beginnen.