Software eingeführt — das Problem ist noch da

Die Erwartung, die fast jede Softwareeinführung begleitet

Wer ein neues System einführt, tut das selten aus freien Stücken. Meistens steht ein Moment dahinter, in dem etwas nicht mehr funktioniert hat. Eine Anfrage, die niemand beantwortet hat, weil sie zwischen zwei Zuständigkeiten verschwand. Ein Dokument, das doppelt gepflegt wurde und beim dritten Mal trotzdem falsch war. Ein Übergabeprozess, der in manchen Wochen lief und in anderen nicht — ohne dass jemand hätte sagen können, warum.

Aus diesem Moment entsteht eine Erwartung, die selten laut ausgesprochen wird, aber fast immer da ist: dass das neue System das zugrunde liegende Problem löst. Nicht nur erleichtert — löst. Dass die Lücken geschlossen werden. Dass die Frage, wer zuständig ist, sich von selbst beantwortet. Dass Dinge nicht mehr vergessen werden können, weil das System aufpasst.

Diese Erwartung ist verständlich. Sie erklärt auch, warum eine Softwareeinführung fast immer mehr kostet als geplant — und warum das Ergebnis trotzdem enttäuscht. Nicht weil die Software schlecht war, sondern weil sie ein anderes Problem gelöst hat als das, das tatsächlich vorlag.

Was konkret erwartet wird

In Gesprächen vor einer Einführung zeigen sich immer wieder dieselben Erwartungen:

Kommunikationsprobleme sollen durch ein gemeinsames System verschwinden.
Fehler in der Übergabe sollen durch automatische Benachrichtigungen aufhören.
Verantwortung soll sichtbar werden, weil das System dokumentiert, wer was getan hat.
Der Aufwand für wiederkehrende Aufgaben soll spürbar sinken — sobald alles erst einmal eingerichtet ist.

An diesen Erwartungen ist nichts Falsches. Viele davon lassen sich erfüllen. Aber sie setzen etwas voraus, das vor dem Projekt selten geprüft wird: dass der Ablauf, den das neue System abbilden soll, als Ablauf überhaupt existiert.

Ein System, das eine Anfrage automatisch weiterleitet, braucht eine Regel, an wen sie weitergeleitet wird. Eine Benachrichtigung, die ausgelöst wird, wenn etwas nicht erledigt wurde, braucht eine Definition, was „erledigt" bedeutet. Ein Dashboard, das zeigt, wo ein Auftrag gerade steht, braucht Einigkeit darüber, welche Stationen ein Auftrag überhaupt durchläuft.

Diese Dinge klingen selbstverständlich. In der Praxis sind sie es meistens nicht. Nicht weil die Beteiligten sie nicht kennen würden — sondern weil sie bis dahin keine Rolle gespielt haben. Solange ein Mensch die Lücke überbrückt hat, musste niemand beschreiben, wie die Lücke eigentlich heißt.

Das Neue an einer Softwareeinführung ist nicht die Technik. Es ist der Zwang, Abläufe zu beschreiben, die vorher im Gedächtnis einzelner Personen lebten. Und dieser Zwang kommt meistens als Überraschung — auch dann, wenn das Projekt gut vorbereitet war.

Was nach dem Go-live tatsächlich passiert

Das System läuft. Die Zugangsdaten wurden verteilt, die Schulung ist absolviert, der Dienstleister hat abgeliefert. Und dann beginnt der eigentliche Teil — der, über den vorher kaum gesprochen wurde.

In den ersten Wochen nach einer Einführung zeigt sich, welche Annahmen im Projekt still mitgereist sind. Eine davon ist besonders hartnäckig: dass die Mitarbeitenden das neue System so nutzen werden, wie es gedacht war. In der Praxis tippen viele weiterhin Daten in Tabellen, die parallel zum neuen System gepflegt werden — nicht aus Bequemlichkeit, sondern weil sie dem neuen Weg noch nicht vertrauen. Wer jahrelang mit einer Methode gearbeitet hat, gibt sie nicht auf, weil eine Schulung stattgefunden hat.

Die stille Parallelwelt

In vielen Betrieben entsteht nach einer Softwareeinführung eine Phase, in der zwei Welten gleichzeitig existieren: das neue System, das offiziell gilt, und die alten Wege, die inoffiziell noch laufen. E-Mails, Notizblöcke, geteilte Tabellen. Diese Parallelwelt ist kein Zeichen des Scheiterns — sie ist eine normale Reaktion auf Unsicherheit. Sie kostet aber Zeit, erzeugt widersprüchliche Daten und macht es schwerer zu erkennen, wo das eigentliche Problem liegt.

Ein Beispiel: Ein Dienstleister führt eine neue Software für die Auftragssteuerung ein. Drei Monate später beschweren sich Kunden weiterhin über fehlende Rückmeldungen. Die Ursache liegt nicht im System — sie liegt darin, dass ein Teil des Teams Aufträge noch per Telefon entgegennimmt und diese nicht erfasst. Das System funktioniert einwandfrei. Es wird nur für einen Teil der Vorgänge genutzt.

Was die ersten drei Monate wirklich zeigen

Wenn nach dem Go-live Probleme auftauchen, folgt häufig die Suche nach dem Fehler im System. Das ist naheliegend, aber oft falsch. Was sich in dieser Phase zeigt, sind meistens keine technischen Fehler, sondern Reibungspunkte im Übergang: Abläufe, die im alten System über Umwege funktionierten und im neuen noch keinen Weg gefunden haben. Zuständigkeiten, die bisher implizit geregelt waren und die ein System nicht übernehmen kann, weil sie nie explizit formuliert wurden.

Wer trägt ein, wenn jemand krank ist?
Was passiert mit Anfragen, die über einen Kanal kommen, der nicht angebunden ist?
Wer entscheidet, wenn das System zwei Möglichkeiten anbietet und beide plausibel wirken?

Diese Fragen klingen organisatorisch, nicht technisch. Sie sind es auch. Ein System kann sie sichtbar machen — lösen muss sie der Betrieb.

Wo neue Systeme auf alte Abläufe treffen

Kein Betrieb funktioniert so, wie er auf dem Papier steht. Die wirklichen Abläufe sind über Jahre gewachsen: Handgriffe, die niemand aufgeschrieben hat, weil sie selbstverständlich sind. Ausnahmen, die ursprünglich einmal eine Ausnahme waren und jetzt zum Normalfall gehören. Absprachen zwischen zwei Kolleginnen, die schon so lange so arbeiten, dass beide den Schritt, der dazwischen liegt, gar nicht mehr bewusst wahrnehmen.

Neue Software kennt nichts davon. Sie kennt die Felder, die befüllt werden sollen, und die Reihenfolge, in der das passieren soll. Was sie nicht kennt, ist die Wirklichkeit des Alltags: dass der Auftrag manchmal schon beginnt, bevor das Angebot unterschrieben ist. Dass manche Kunden grundsätzlich per Telefon nachfragen, bevor sie etwas schriftlich bestätigen. Dass der Mitarbeiter, der das System eigentlich bedienen sollte, am Donnerstagnachmittag immer auf Besichtigungsterminen ist.

Die Lücke zwischen System und Alltag

Das Ergebnis ist meist dasselbe: Die Software wird halbherzig genutzt, weil der Alltag nicht in sie passt — oder der Alltag wird verbogen, damit er in die Software passt. Beides kostet. Im ersten Fall entstehen Doppelstrukturen: Excel-Listen neben dem System, WhatsApp-Nachrichten als Übergabe, Zettel auf dem Schreibtisch als Gedächtnis. Im zweiten Fall steigen die Fehlerquoten, weil Schritte übersprungen werden müssen, um überhaupt weiterzukommen.

Eine Maklerin hält Interessentennotizen weiterhin in einer eigenen Tabelle, weil das System keine freien Textfelder vorsieht.
Ein Verwalter trägt Eingangstermine manuell nach, weil die automatische Zuweisung bei Teilzahlungen nicht greift.
Ein Betriebsinhaber führt zwei parallele Kalender — einen für das System, einen für die Realität.

Das sind keine Fehler in der Nutzung. Das sind Orte, wo das System und der Betrieb aneinander vorbeigehen. Und diese Stellen entstehen nicht, weil schlechte Software gekauft wurde. Sie entstehen, weil jede Einführung eine Übersetzungsleistung verlangt, die häufig unterschätzt wird — nämlich: den eigenen Ablauf präzise genug zu kennen, um ihn einem System beizubringen.

Was dabei meistens herauskommt

In vielen Betrieben ist dieses Wissen nirgendwo aufgeschrieben. Es steckt in den Köpfen der Menschen, die schon lange dabei sind. Es steckt in eingeübten Handgriffen und in dem stillen Verständnis, wer was bis wann erledigt. Wenn eine Softwareeinführung beginnt, kommt die Frage „Wie läuft das bei Ihnen ab?" oft zum ersten Mal überhaupt auf den Tisch — und sie ist schwerer zu beantworten, als sie klingt.

Das Ergebnis: Das System wird auf einem Ablauf aufgebaut, der so nicht existiert. Entweder weil er zu idealisiert beschrieben wurde. Oder weil in der Beschreibung die Ausnahmen fehlten, die eigentlich die Regel sind. Beides lässt sich korrigieren — aber nicht ohne Aufwand, und nicht ohne die Bereitschaft, noch einmal von vorn zu beginnen.

Was Software grundsätzlich nicht mitliefert

Software kann sehr viel. Sie rechnet ohne Müdigkeit, sie vergisst nicht, sie verlegt keine Akte. Das sind reale Vorteile, und sie rechtfertigen den Aufwand, den eine Einführung verursacht.

Was sie nicht kann, ist strukturell bedingt — und wird in Gesprächen über neue Projekte fast nie erwähnt.

Zuständigkeiten

Wenn vor der Einführung nicht klar war, wer für eine Aufgabe die Verantwortung trägt, ist das danach immer noch nicht klar. Ein neues System bekommt das Feld „zuständige Person", aber niemand füllt es aus, weil die eigentliche Frage — wer entscheidet hier — unbeantwortet geblieben ist. Die Software zeigt das Problem als leere Spalte. Gelöst hat sie es nicht.

Bereitschaft zur Verwendung

Ein System, das niemand benutzt, verändert nichts. Dass Mitarbeiterinnen und Mitarbeiter eine neue Oberfläche annehmen, entsteht nicht durch die Einführung selbst. Es entsteht durch Erklärung, durch Überzeugung, durch eine klare Erwartung von Seiten der Führung — alles Dinge, die aus dem Unternehmen kommen müssen, nicht aus dem Produkt. Viele Betriebe stellen ein Jahr nach der Einführung fest, dass ein Teil des Teams noch immer die alte Tabelle führt. Nicht aus bösem Willen, sondern weil niemand den Übergang wirklich begleitet hat.

Wissen darüber, was gemessen werden soll

Mehr Auswertungsmöglichkeiten bedeuten nicht mehr Klarheit. Ein Dashboard zeigt, was man ihm aufträgt. Wer nicht weiß, welche Zahl für das eigene Geschäft tatsächlich entscheidend ist, bekommt durch ein neues Auswertungswerkzeug keine Antwort auf diese Frage — sondern mehr Auswahl zwischen gleichwertig bedeutungslosen Kurven.

Datenqualität

Veraltete Kontaktdaten, fehlende Einträge, doppelte Datensätze aus dem Vorgängersystem — all das wandert in das neue System mit, wenn es vorher nicht bereinigt wird. Bereinigen ist Handarbeit. Kein Importvorgang übernimmt das. Ein Unternehmen, das seine Bestandsdaten seit Jahren nicht gepflegt hat, trägt dieses Problem ins neue System weiter — schneller, als es der alte Ordner je erlaubt hätte.

Keines dieser Defizite ist ein Vorwurf an die Software. Es sind Grenzen, die zur Natur jedes Werkzeugs gehören: Ein Werkzeug verbessert das, was jemand damit tut. Was unklar ist, wird durch Automatisierung nicht klarer — es wird schneller unklar gemacht.

Welche Frage vor dem Projekt hätte gestellt werden müssen

Fast jede Softwareeinführung beginnt mit einer Entscheidung, die eigentlich noch keine ist: Man wählt ein System, bevor man das Problem beschrieben hat. Die Frage, die hätte gestellt werden müssen, lautet nicht „Welche Software passt zu uns?" — sie lautet: „Was genau passiert gerade, wenn dieser Vorgang bei uns schief geht?"

Diese Frage klingt einfach. Sie ist es nicht. Denn um sie ehrlich zu beantworten, müsste man den Ablauf kennen, den heute drei verschiedene Personen auf drei verschiedene Weisen erledigen. Und meistens weiß das niemand mit Gewissheit — nicht einmal die drei Personen selbst.

Was man konkret hätte fragen können

Was passiert heute, wenn eine Anfrage hereinkommt und niemand im Büro ist?
Wer entscheidet, welcher Auftrag als nächstes bearbeitet wird — und nach welchen Kriterien?
Wo liegt die Information, die man für diesen Schritt braucht — und in welcher Form liegt sie vor?
Was würde sich im Tagesablauf ändern müssen, damit das neue System tatsächlich genutzt wird?

Das sind keine technischen Fragen. Es sind Fragen über Abläufe, über Zuständigkeiten, über das, was täglich stillschweigend getan wird, ohne dass es je jemand aufgeschrieben hat. In einer Maklerei ist das die handschriftliche Liste auf dem Schreibtisch. In einem Handwerksbetrieb ist es der Monteur, der am Abend anruft und dem Büro sagt, was zu bestellen ist. In einer Hausverwaltung ist es die Kollegin, die seit zwölf Jahren weiß, bei welchen Eigentümern man besser erst nach dem dritten Brief telefoniert.

Software kann solche Abläufe abbilden — aber nur, wenn sie vorher sichtbar waren. Was nie benannt wurde, kann nicht abgebildet werden. Und was nicht abgebildet ist, bleibt auch nach der Einführung das, was es vorher war: ein mündlicher Schritt, ein Handgriff, eine Ausnahme, die zur Regel geworden ist.

Der Moment, in dem das Gespräch kippt

Wer Softwareprojekte von innen kennt, erinnert sich an den Moment, in dem die eigentliche Frage erstmals gestellt wird — meistens spät, manchmal erst nach dem Go-live. Ein Mitarbeiter fragt: „Aber wie machen wir das mit den Kunden, die gleichzeitig per E-Mail und über das Formular schreiben?" Oder jemand aus der Buchhaltung sagt: „Das klingt nach dem Sonderfall mit den Teilzahlungen, den wir immer von Hand erfassen."

Das ist nicht Unvorbereitetheit. Das ist, wie Abläufe im Betrieb entstehen: organisch, über Jahre, als Antwort auf reale Situationen. Sie werden selten aufgeschrieben, weil sie schlicht funktionieren. Für ein Softwareprojekt sind sie unsichtbar — bis sie es nicht mehr sind.

Die Frage, die vor dem Projekt hätte gestellt werden müssen, ist deshalb auch eine organisatorische: Haben wir verstanden, was wir täglich wirklich tun? Nicht so, wie es im letzten Konzept steht. Sondern so, wie es diese Woche tatsächlich passiert ist.