Das teuerste System ist das, das Ihre Leute nicht nutzen.

Ein typisches Szenario. Ein Unternehmen unterschreibt den Vertrag für ein neues System. Analyse, Datenmigration, Test, Schulung, Übergabe. Sechs Monate später verschickt der Vertrieb ein Angebot aus der eigenen Excel-Mappe, die Produktion führt ihren Plan auf einem geteilten Laufwerk und die Buchhaltung exportiert Daten, um sie anderswo weiterzuverarbeiten.

Dabei läuft das System, die Schnittstellen übertragen Daten, der Dienstleister hat das Lastenheft erfüllt. Und trotzdem ist es ein Scheitern, es zeigt sich nur nicht als Ausfall, sondern als Stille.

Die Einführung ist der Moment, in dem die Software läuft. Adoption ist der Zustand, in dem die Organisation sie nutzt. Zwischen diesen beiden Punkten liegt der größte Teil des Werts, den Unternehmen verlieren, und im Budget gibt es dafür selten eine Position.

Warum Ihre Leute nach einem halben Jahr immer noch in Excel arbeiten

Am Tag des Go-live schlägt Excel das neue System in allem, was für die Nutzer zählt: keine Lernkosten, sofortige Rückmeldung, beliebige Struktur, Fehler ohne Protokoll. Das neue System bietet konsolidierte Daten, Nachvollziehbarkeit und Überblick für die Geschäftsführung. Das sind Vorteile des Unternehmens, nicht Vorteile der Person, die bis zum Abend die Bestellungen herausschicken muss.

Das nützlichste Diagnosewerkzeug ist deshalb ein einziger Satz: Wenn ein Mitarbeiter neben dem System Excel braucht, um das System überhaupt nutzen zu können, liegt das Problem nicht zwingend beim Mitarbeiter. Eine Schattentabelle entsteht nicht aus Bequemlichkeit, ihre Pflege kostet Zeit und schafft Risiko. Wer sie trotzdem führt, behauptet damit, dass das System allein teurer ist als das System plus zusätzliche Tabelle. Jede solche Datei ist eine formalisierte Beschwerde über die Oberfläche und die günstigste Nutzerforschung, die ein Unternehmen bekommen kann.

Fred Davis schreibt in seiner Arbeit von 1989, auf der das Technology Acceptance Model beruht, dass Leistungsgewinne häufig daran scheitern, dass Nutzer verfügbare Systeme nicht annehmen und einsetzen wollen. In seinen zwei Studien mit 152 Nutzern erwies sich die wahrgenommene Benutzerfreundlichkeit als wahrscheinliche Ursache der wahrgenommenen Nützlichkeit: Was sich schwer bedienen lässt, wirkt nicht nützlich. Die Stichprobe ist klein und die Arbeit alt, das ist keine Prognose, sondern nur die Richtung des Zusammenhangs.

Adoption ist der Nenner der Rentabilität

Die Kosten sind fix und am Tag der Unterschrift bekannt. Der Nutzen entsteht erst, wenn tatsächlich jemand im System arbeitet. Ein System mit null Adoption hat null Rendite, unabhängig vom Preis. Ein System mit halber Adoption hat weniger als die halbe: Das Unternehmen zahlt Lizenzen und die Pflege der Schattenprozesse gleichzeitig und hat keine Single Source of Truth.

Das gleiche Bild zeichnet der ERP Report 2026 der Panorama Consulting Group, eine Befragung von 170 Organisationen mit einem Medianjahresumsatz von 200,5 Millionen US-Dollar. Probleme mit ERP hängen demnach am häufigsten mit unklarer Prozessverantwortung, schwacher Nutzeradoption und fehlender Zielabstimmung zusammen. Die eigentliche Herausforderung ist nicht die Auswahl des Anbieters, sondern dass die Organisation nach der Einführung anders arbeitet.

Den Preis dieser Stille berechnen Sie mit einem einfachen Produkt: Zeit mal Häufigkeit mal Anzahl der Personen mal Kostensatz. Nehmen Sie einen Vorgang, der im neuen System länger dauert als vorher, und multiplizieren Sie die Differenz mit der Zahl der Wiederholungen pro Tag, der Zahl der beteiligten Personen und dem Stundensatz. Das Ergebnis ist der Betrag, den das Unternehmen jeden Tag für eine einzige Entscheidung im Entwurf der Oberfläche zahlt, und zugleich die Obergrenze eines vernünftigen Budgets für deren Korrektur. Dieselbe Rechnung habe ich in dem Text aufgemacht, warum gutes Design keine Dekoration ist, sondern eine Methode, mit der ein Unternehmen Zeit und Geld spart.

Warum schlechte interne Software so lange geduldet wurde

Consumer-Software kämpft um jeden Klick, weil der Nutzer abspringen kann. Interne Software hat einen gefangenen Nutzer und wird von jemandem gekauft, der nicht damit arbeitet. Die Auswahlkriterien sind die Funktionsmatrix, der Preis, Referenzen und Schnittstellen. Niemand nimmt eine Zeile dafür auf, wie lange ein neuer Kollege für die erste Bestellung braucht, und der Anbieter optimiert auf das, was bewertet wird.

Die Nielsen Norman Group beschreibt komplexe Unternehmensanwendungen als Werkzeuge für unstrukturierte Ziele hoch qualifizierter Fachleute, die viel Aufmerksamkeit und Zeit in ihre Arbeit stecken und deshalb ein verlässliches Rückgängigmachen und eine Erholung von Fehlern brauchen. Sie erinnert außerdem an das Paradox des aktiven Nutzers: Menschen beginnen eine Sache zu nutzen, bevor sie versuchen, sie zu verstehen. Das ist ein Argument gegen die Schulung als wichtigstes Mittel der Adoption.

Change Management, Schulungen und kognitive Belastung

Change Management bereitet die Organisation auf eine veränderte Arbeitsweise vor, es ist keine Rundmail und keine zweistündige Schulung vor dem Start. Prosci hat in einer Studie mit mehr als 2.600 Praktikern die Qualität des Veränderungsmanagements mit dem Erreichen der Projektziele korreliert: Bei einem hervorragenden Programm erreichten oder übertrafen 88 % der Projekte ihre Ziele, bei einem schwachen 13 %. Das ist eine Korrelation, kein Experiment, aber der Abstand ist zu groß, um ihn abzutun. Laut Panorama Consulting Group gab zugleich weniger als ein Viertel der Organisationen einen intensiven Fokus auf Veränderungsmanagement an.

Die zweite Hälfte des Problems ist die kognitive Belastung, also die Menge an mentalen Ressourcen, die die Bedienung des Systems erfordert. Die Nielsen Norman Group unterscheidet die intrinsische Belastung, die zur Aufgabe selbst gehört, und die extrinsische, die Aufmerksamkeit verbraucht, beim Verstehen des Inhalts aber nicht hilft. Von der extrinsischen gibt es in internen Systemen reichlich: überladene Bildschirme, Felder ohne Sinn für die jeweilige Rolle, Begriffe aus dem Datenmodell statt aus dem Unternehmen. Eine Schulung beseitigt sie nicht, das Unternehmen zahlt sie bei jedem neuen Mitarbeiter erneut. Der Entwurf beseitigt sie einmal.

Die Harvard Business Review berichtet in einem Beitrag von Forschenden bei Gartner, dass ein durchschnittlicher Mitarbeiter im Jahr 2022 zehn geplante Veränderungen im Unternehmen erlebt hat, gegenüber zwei im Jahr 2016, und der Austausch eines veralteten Systems gehört zu den genannten Arten von Veränderung. Ihr Projekt konkurriert nicht mit dem Nichtstun, sondern mit neun weiteren Veränderungen.

Veränderungswiderstand oder legitim schlechte Software

Hier machen Unternehmen den teuersten Fehler des gesamten Projekts. Wenn die Leute das System nicht nutzen, wertet die Geschäftsführung das als Veränderungswiderstand und erhöht den Druck und die Zahl der Schulungen. Ist die Software tatsächlich schlecht, steigert Druck die Adoption nicht, er verschiebt die Schattentabellen nur außer Sichtweite, und das Unternehmen verliert zusätzlich die Information über das Problem. Diese beiden Situationen zu unterscheiden ist dabei nicht teuer.

• Wo der Widerstand konzentriert ist. Verteilt er sich dünn über das ganze Unternehmen, geht es eher um die Veränderung. Sitzt er in einer einzigen Rolle, geht es um den Entwurf: Genau deren Arbeitsablauf unterstützt das System nicht.
• Wie der Einwand klingt. „Ich will das nicht“ ist eine Haltung. „Ich weiß nicht, wo ich einen Auftrag erfasse, wenn der Kunde eine Anzahlung leistet und an eine dritte Firma fakturiert wird“ ist eine Fehlermeldung.
• Wer sich verweigert. Kehren Ihre leistungsstärksten Leute zu Excel zurück, also genau diejenigen, die von einer Beschleunigung am meisten hätten, ist die Haltungshypothese schwach.
• Was die Bearbeitungszeit sagt. Messen Sie denselben Vorgang vor und nach der Einführung. Dauert er länger, ist der Widerstand rational.

Die Nielsen Norman Group ergänzt einen kontraintuitiven Befund: Flüchtigkeitsfehler treffen vor allem Menschen, die eine Aufgabe routiniert erledigen, weil wir eingeübter Arbeit weniger Aufmerksamkeit widmen. Dazu kommt ein Satz, der in jedem Meeting über interne Systeme an die Wand gehört: Dafür, dass der Fehler so leicht zu machen war, ist der Gestalter verantwortlich. Eine steigende Fehlerquote bei erfahrenen Nutzern nach der Einführung ist kein Signal über deren Kompetenz, sondern über die Oberfläche.

In den Entwurf gehören die Nutzer, nicht nur ihre Vorgesetzten

Eine Führungskraft beschreibt den Prozess so, wie er aussehen soll. Der Nutzer weiß, wie er tatsächlich aussieht. Der Unterschied sind die Ausnahmen: der Kunde, der eine geteilte Rechnung will, der Lieferant, der ein PDF statt Daten schickt. Der Hauptpfad sieht überall ähnlich aus, Geld und Reibung stecken in den Ausnahmen, die eine Führungskraft nicht selbst bearbeitet und deshalb nicht kennt.

McKinsey liefert dazu eine Zahl aus einer Befragung zu digitalen Transformationen: Wenn Mitarbeiter selbst Ideen einbringen, wo Digitalisierung helfen könnte, berichten die Befragten 1,4-mal häufiger von Erfolg, und eine Neuverteilung von Rollen und Verantwortlichkeiten im Einklang mit den Zielen der Transformation erhöht die Erfolgswahrscheinlichkeit um das 1,5-Fache. Menschen einzubinden ist keine Geste der Unternehmenskultur, es ist eine Variable in der Gleichung.

Das Vorgehen ist günstig: einen halben Tag neben Menschen aus verschiedenen Rollen sitzen und beobachten, wo sie zögern und was sie umgehen. Im Workshop kommt das nicht zur Sprache, Umwege nimmt nach einiger Zeit niemand mehr bewusst wahr.

Die ehrliche Konsequenz ist für den Dienstleister meist unangenehm. Manchmal zeigt sich, dass gar nichts gebaut werden sollte: Der Prozess gehört abgeschafft, es genügt, das ohnehin bezahlte Werkzeug besser zu konfigurieren, oder es reichen zwei Module weniger. Ein Randprozess mit wenigen Fällen im Monat soll in der Tabelle bleiben, mit einem klaren Verantwortlichen, weil sich die Entwicklung dafür nicht rechnen würde. Die Reihenfolge der Schritte ist nicht zufällig: streichen, vereinfachen, automatisieren, erweitern. Individualentwicklung lohnt sich dort, wo ein Prozess ein Wettbewerbsvorteil oder ein Engpass ist, nicht dort, wo lediglich eine Tabelle existiert. Ausgeführt habe ich das in dem Text darüber, dass ein Unternehmen ein einziges Produkt ist und jeder schlechte Prozess zu seinen technischen Schulden zählt.

Vier Entwurfsentscheidungen, die über die Adoption entscheiden

• Schrittweises Offenlegen (Progressive Disclosure). Die Oberfläche zeigt zuerst die gängigen Optionen und macht die fortgeschrittenen erst auf Anforderung zugänglich. Jakob Nielsen beschreibt das als Technik, die drei von fünf Bestandteilen der Usability verbessert: Erlernbarkeit, Effizienz der Nutzung und Fehlerquote. Er ergänzt ein zweites Prinzip: Was auf dem ersten Bildschirm steht, ist für den Nutzer wichtig. Der erste Bildschirm ist eine Aussage über die Prioritäten des Unternehmens, und die meisten Systeme behaupten, alles sei gleichzeitig Priorität.
• Sinnvolle Voreinstellungen. Eine Voreinstellung ist eine Entscheidung, die das Unternehmen einmal trifft, statt sie jeden bei jedem Datensatz erneut treffen zu lassen. Ein guter Default ist kein leeres Feld, sondern der häufigste korrekte Wert. Die Nielsen Norman Group zählt dazu auch das erneute Anzeigen bereits eingegebener Daten und Bezeichnungen aus der Sprache des Unternehmens statt aus den Spalten der Datenbank.
• Fehlervermeidung (Error Prevention). Die Oberfläche soll so entworfen sein, dass ein Fehler nicht möglich oder zumindest nicht leicht ist. Die Nielsen Norman Group empfiehlt vier Strategien: hilfreiche Einschränkungen, Wertvorschläge, gute Voreinstellungen und eine nachsichtige Verarbeitung der Eingabe. Ein bei der Eingabe abgefangener Fehler kostet eine Sekunde, derselbe Fehler in der Fakturierung kostet Personenstunden und ein Stück Kundenbeziehung.
• Rollenbasierte Oberflächen (Role-based Interface). Eine Datenbank, unterschiedliche Bildschirme. Ein Lagerist muss die Marge nicht sehen, und jedes zusätzliche Feld ist eine Last für alle, die es nicht ausfüllen. Die Nielsen Norman Group weist darauf hin, dass jeder Nutzer irgendwann ein Effizienzplateau erreicht, auf dem weitere Nutzung die Leistung nicht mehr steigert. Über diese Grenze bringen ihn Beschleuniger: Tastaturkürzel, Makros, Gesten.

Wie Sie Adoption messen

Adoption misst man nicht am Gefühl im Meeting. Definieren Sie diesen Satz an Kennzahlen vor dem Start, damit es später etwas zum Vergleichen gibt.

• Adoption. Der Anteil der vorgesehenen Nutzer, die im betrachteten Zeitraum einen Kernvorgang im System ausgeführt haben. Nicht die Anmeldungen, eine Anmeldung ist keine Arbeit.
• Aktive Nutzer im Zeitverlauf. Ein Höhepunkt nach der Schulung und danach ein Abfall ist das Bild eines Systems, das die Leute ausprobiert und aufgegeben haben.
• Bearbeitungszeit pro Aufgabe. Für die häufigsten Vorgänge, gemessen vor und nach der Einführung. Direkter Eingangswert für die Rechnung weiter oben.
• Fehlerquote. Korrekturen, Stornos, manuelle Eingriffe, Belege, die neu erstellt werden müssen.
• Support-Tickets. Nicht die Anzahl, sondern das Verhältnis zwischen „Ich weiß nicht, wie“ und „Das System lässt es nicht zu“. Das Erste ist Onboarding, das Zweite Entwurf.
• Anzahl der Schattentabellen. Die ehrlichste Kennzahl: Eine Tabelle verschwindet erst dann, wenn das System schneller ist als sie.

Diese Zahlen stellen die Kosten einer Korrektur der Oberfläche den Reibungskosten gegenüber, die das Unternehmen jeden Monat zahlt. Mit derselben Rechnung habe ich verglichen, wann sich ein gutes internes System schneller bezahlt macht als ein neuer Mitarbeiter.

Management-Dashboard und Arbeitsoberfläche dürfen nicht gleich aussehen

Ein Dashboard beantwortet die Frage, wie es uns geht. Man liest daraus, und es verträgt ein paar Sekunden Ladezeit. Die Arbeitsoberfläche beantwortet die Frage, was ich jetzt mit dieser Bestellung tun soll. Sie wird dutzendfach am Tag geöffnet, es wird darin geschrieben, sie braucht Tempo, Tastatur und Fehlervermeidung. Werden beide gleich entworfen, entstehen zwei mittelmäßige Produkte.

Dahinter steckt auch ein politischer Mechanismus. In Präsentationen wird das Dashboard gezeigt, deshalb bekommt es gestalterische Aufmerksamkeit und Budget. Der Arbeitsbildschirm wird nie gezeigt, obwohl genau dort Geld entsteht und verloren geht. Das Designbudget sollte der Nutzungshäufigkeit folgen, nicht der Hierarchieebene derjenigen, die auf den Bildschirm schauen.

Was Sie mitnehmen sollten

• Schreiben Sie das Adoptionsziel und die Messmethode ins Lastenheft, bevor Sie den Vertrag unterschreiben. Ohne eine Nutzungskennzahl hat der Dienstleister keinen Grund, sich darum zu kümmern.
• Messen Sie die Bearbeitungszeit der häufigsten Vorgänge noch vor der Einführung. Ohne Ausgangswert lässt sich weder eine Verbesserung noch eine Verschlechterung belegen.
• Machen Sie eine Inventur der Schattentabellen. Jede davon ist ein Auftrag zur Korrektur eines Prozesses oder einer Oberfläche, präziser als alles aus einem Workshop.
• Fragen Sie sich vor der nächsten Schulung, ob Sie Menschen für die Arbeit schulen oder für das Umgehen einer schlechten Oberfläche. Das Erste ist eine Investition, das Zweite eine wiederkehrende Ausgabe.
• Prüfen Sie vor der Beauftragung einer Entwicklung, ob das Problem nicht durch das Streichen eines Schritts, eine Vereinfachung des Prozesses oder eine bessere Konfiguration des ohnehin bezahlten Werkzeugs verschwindet. Die Diagnose ist günstiger als die Umsetzung.