Die teuerste interne Software ist die, die technisch einwandfrei läuft und trotzdem nicht benutzt wird. Das neue Tool ist eingeführt, aber die Aufträge stehen weiter im Gruppenchat, die Stunden weiter auf Zetteln, und nach drei Monaten pflegt eine einzige gewissenhafte Person das System, dessen Daten deshalb nie stimmen. Aus unseren Projekten wissen wir: Ob ein internes Tool angenommen wird, entscheidet sich an wenigen, ziemlich konkreten Punkten, und die meisten davon liegen vor dem ersten Entwicklungstag.

Die eine Regel: Das Tool muss ab Tag eins schneller sein als der alte Weg

Menschen wechseln ihre Arbeitsweise nicht wegen einer Anweisung und nicht wegen einer Schulung. Sie wechseln, wenn der neue Weg im Moment der Nutzung weniger Aufwand ist als der alte. Ein Monteur, der einen Einsatz bisher mit einer Chatnachricht in zehn Sekunden gemeldet hat, wird keine Maske mit zwölf Feldern ausfüllen, egal wie sehr die Auswertung im Büro davon profitieren würde. Und die Routine mit Software ist dünner verteilt, als man im Büro annimmt: Laut EU-Kommission (Digitale Dekade, Stand 2026) verfügen nur 55,6 Prozent der EU-Bevölkerung über zumindest grundlegende digitale Kompetenzen. Wer ein internes Tool baut, baut auch für die andere knappe Hälfte.

Daraus folgt eine unbequeme Gestaltungsregel: Die Person, die Daten eingibt, muss selbst etwas davon haben, und die Eingabe muss mit dem alten Weg konkurrieren können. Drei Pflichtfelder statt zwölf, Vorschlagswerte statt leerer Felder, und im Gegenzug ein sofort spürbarer Nutzen, etwa dass der Monteur seine Wochenstunden sieht, ohne abends etwas zusammenzurechnen. Alles, was das Büro zusätzlich wissen will, muss diese Rechnung respektieren.

Holen Sie den größten Skeptiker ins Boot, bevor gebaut wird

In jedem Team gibt es die Person, die von neuer Software nichts hält, oft, weil sie schon zwei gescheiterte Einführungen erlebt hat. Der Reflex ist, sie zu umgehen. Der bessere Zug ist das Gegenteil: Genau diese Person gehört in die ersten Gespräche, denn sie kennt die Ausnahmen und Sonderfälle des Alltags am besten, und ihre Einwände sind meist verkleidete Anforderungen.

„Das funktioniert bei uns nicht, weil die Aufträge oft ohne Kundennummer reinkommen“ ist keine Ablehnung. Es ist eine präzise Beschreibung dessen, was das Tool können muss. Ein Skeptiker, dessen Einwand in der Software sichtbar berücksichtigt wurde, wird erstaunlich oft zum glaubwürdigsten Fürsprecher, glaubwürdiger als jede Ansage der Geschäftsführung.

Starten Sie mit echten Daten, nicht mit einem leeren System

Ein leeres Tool ist am ersten Tag ein Mehraufwand ohne Gegenwert: Man soll etwas eintragen, bekommt aber nichts heraus, weil noch nichts drin ist. Diese ersten Wochen entscheiden über den Ruf des Systems im Haus.

Deshalb gehört die Übernahme der Bestandsdaten in jedes Projekt: die laufenden Aufträge, die Kundenliste, die Artikel aus der alten Tabelle. Das ist Fleißarbeit und kostet ein paar Projekttage, aber ein Planungsboard, auf dem ab der ersten Minute die echte kommende Woche steht, erklärt sich selbst. Ein leeres Board erklärt niemand.

Die alte Excel-Datei muss ein Ablaufdatum bekommen

Der häufigste Tod interner Tools ist der Parallelbetrieb. Solange die alte Datei weiterlebt, „nur zur Sicherheit“, tragen die einen hier ein und die anderen dort, keine der beiden Quellen ist vollständig, und nach kurzer Zeit gilt das neue System als unzuverlässig, obwohl es korrekt tut, was man ihm gibt.

Eine Übergangsphase ist normal und richtig. Aber sie braucht ein angekündigtes Ende: Ab einem festen Datum wird die Datei schreibgeschützt, und der neue Weg ist der einzige. Diese Entscheidung kann kein Dienstleister treffen, sie ist Führungsarbeit. Wir sprechen das in Projekten früh an, weil wir Tools gesehen haben, die genau an diesem fehlenden Stichtag gescheitert sind, nicht an einer einzigen Zeile Code.

Planen Sie die Nachschärfe-Runde ein, sie ist keine Reklamation

Egal wie gut die Vorbereitung war: In den ersten Wochen echter Nutzung zeigt sich, dass ein Feld fehlt, eine Reihenfolge unpraktisch ist, ein Sonderfall öfter vorkommt als gedacht. Das ist kein Zeichen eines schlechten Projekts, sondern der normale Verlauf, und die wertvollste Rückmeldung, die Sie je zu diesem Tool bekommen werden.

Praktisch heißt das: Budgetieren Sie nach dem Start bewusst eine Anpassungsrunde, und sorgen Sie dafür, dass Rückmeldungen einen kurzen Weg haben, eine Nachricht, kein Formular. Ein Team, das sieht, dass sein Hinweis von Dienstag am Freitag umgesetzt ist, behandelt das Tool als seines. Genau dieses Gefühl, mehr als jede Funktion, entscheidet am Ende über die Nutzung.