Der Abnahmetest (UAT — User Acceptance Testing) ist der letzte Moment, in dem du dem Anbieter sagen kannst: „Das funktioniert nicht, bessere nach." Sobald das Abnahmeprotokoll unterschrieben ist, wird jede Korrektur zu einem Gespräch über eine weitere Rechnung. Die meisten KMU verschwenden diese Chance auf ein einstündiges Meeting, in dem sie eine schöne Demo anschauen.
Wir kennen das Muster auswendig. Der Anbieter kommt mit dem Laptop, zeigt 4-5 Anwendungsfälle an sorgfältig ausgewählten Datensätzen, alles klickt in 2 Sekunden. Der Chef nickt, sagt „sieht gut aus", unterschreibt. Einen Monat nach dem Go-live braucht derselbe Bildschirm in der Produktion 40 Sekunden, weil in der Datenbank 8 000 Datensätze stehen statt fünf, und die Außendienstler im Feld können keinen Rabatt eintragen, weil die mobile Ansicht dieses Feld nicht hat.
Bei einem unserer Kunden — ein 22-Personen-Distributor für Autoteile in Schlesien — bestand die UAT für ein neues CRM aus zwei einstündigen Terminen. Der Geschäftsführer hat die Demo gesehen und unterschrieben. Einen Monat nach dem Start stellte sich heraus, dass die Außendienstler das System überhaupt nicht nutzten — die mobile Ansicht zeigte das Feld für den individuellen Rabatt nicht, also schrieben sie die Angebote weiter in Excel und schickten sie aus privaten Postfächern. Drei Monate Arbeit und rund 45 000 PLN Beratungskosten waren futsch. Nachträgliche Korrekturen kosteten weitere 18 000 PLN, und das Rollout musste faktisch wiederholt werden.
Das ist der Preis einer verkürzten UAT. Und es ist noch ein milder Preis — es gab keinen Ausfall, nur eine leise sterbende Investition. Deutlich schlimmer ist das Szenario, in dem eine Firma ein ERP mit angebundenem WMS abnimmt und eine Woche später merkt, dass die Kommissionierung 3× langsamer läuft als vor dem Rollout.
Eine Demo ist kein Test
Eine Anbieter-Demo zeigt, dass das System das kann, worum du es bittest. Ein Abnahmetest prüft, ob das System mit dem zurechtkommt, was deine Firma ihm am Montagmorgen auf die Tastatur wirft.
Der Unterschied ist enorm. Eine Demo nutzt 3 vorbereitete Datensätze. Deine Produktion hat 15 000. Eine Demo zeigt einen Nutzer. Deine Produktion hat 12 Leute, die gleichzeitig klicken. Eine Demo zeigt den „Alles-lief-gut"-Pfad. Deine Produktion produziert Ausnahmen: einen fehlenden Datensatz, einen doppelten Kontakt, eine CSV-Datei mit BOM am Anfang, ein Netz, das für zwei Minuten wegbricht.
Wenn ihr in der UAT dieselben Daten, dieselben Szenarien und denselben Nutzer wie in der Demo verwendet — dann ist es kein Test. Es ist eine weitere Demo, und ihr redet euch nur ein, ihr hättet etwas geprüft.
Szenarien aus dem echten Leben, nicht aus dem Angebot
Gute Testszenarien kommen nicht aus der Dokumentation des Anbieters. Sie kommen aus dem, was deine Firma jeden Tag tatsächlich tut. Der klassische Fehler: Der Anbieter liefert eine „Testfall-Liste" mit 30 Positionen, die Leute klicken sie brav durch, alles besteht. Niemand merkt, dass in der Liste kein Szenario „Vertriebler stellt eine Korrektur zu einer Rechnung von vor drei Monaten aus, auf die der Kunde eine Anzahlung in EUR überwiesen hat" steht.
Sammel 15-20 echte Szenarien aus den letzten 30 Tagen:
- 5 typische Alltagsfälle (die häufigste Bestellung, die häufigste Rechnung, ein standardmäßiger Wareneingang).
- 5 untypische, aber reale Fälle (Korrektur, Retoure, Anzahlungsrechnung in Fremdwährung, Bestellung an einen Kunden mit Kreditsperre).
- 5 Grenzfälle (Kunde ohne Steuernummer, Bestellung mit 200 Positionen, Produkt mit Preis null, Kommissionierung aus zwei Lägern).
- 5 „irgendetwas ist schiefgegangen"-Fälle (Internet fällt beim Speichern aus, zwei Nutzer bearbeiten denselben Datensatz, in der Preisliste steht ein negativer Preis).
Diese Szenarien schreiben deine Leute, nicht der Anbieter. Das sind 1-2 Tage Arbeit für zwei Personen, die die Prozesse kennen — Buchhaltung, Lager, Vertrieb — nicht die IT. Die IT weiß nicht, was jeden Tag auf der Fläche passiert. Die anderen wissen es.
Teste mit echtem Volumen, nicht mit einer Stichprobe
Eine ganze Fehlerklasse zeigt sich erst bei echter Datenbankgröße. Die Suche nach einem Kontakt anhand eines Namensfragments ist blitzschnell bei 50 Datensätzen und hängt 15 Sekunden bei 8 000. Ein Monatsumsatzbericht braucht 2 Sekunden für 100 Dokumente und 4 Minuten für 12 000. Ein Preislisten-Import mit 500 Positionen läuft durch; mit 30 000 gibt es ein Timeout.
Bevor du dich zur UAT hinsetzt, fordere eine Testumgebung mit echten Volumina. Keine Stichprobe, keine 100 Demo-Datensätze. Importiere die produktive Kunden-, Produkt-, Bestands- und Transaktionshistorie — mindestens 12 Monate. Der Anbieter wird vielleicht protestieren, das sei kompliziert. Gut — genau deshalb soll er es vor der Abnahme machen, nicht danach an deinen Produktivdaten.
Führe die Tests unter normaler Last aus: 6-8 Personen loggen sich gleichzeitig ein und klicken eine Stunde lang ihre typischen Aufgaben. Das fängt 80 % der Probleme mit Performance und gleichzeitigem Zugriff ab — und das sind genau die Probleme, die sich nach dem Go-live nicht mit einem Klick beheben lassen.
Prüfe, was passiert, wenn etwas kaputtgeht
Gut umgesetzte Systeme unterscheiden sich von schlecht umgesetzten nicht dadurch, dass sie nie Fehler haben — sondern dadurch, wie sie sich verhalten, wenn ein Fehler auftritt. Zerstöre gezielt etwas in der Testumgebung:
- Zieh das Netzwerkkabel mitten im Speichern raus — kommen die Daten zurück oder verschwinden sie?
- Reiche eine CSV in falscher Kodierung ein — gibt das System eine sinnvolle Meldung oder „unknown error"?
- Erzeuge zwei Dokumente mit derselben Nummer — blockiert das System oder erzeugt es ein Duplikat?
- Schalte eines der angebundenen Systeme (z. B. das WMS) ab — wartet das ERP, versucht es erneut oder hängt es sich auf?
- Wirf einen Nutzer mitten in der Bearbeitung raus — was passiert mit seinen ungespeicherten Daten?
Sind die Antworten unangenehm, ist das der Moment, Korrekturen zu fordern. Nach der Unterschrift wird jeder solche Fehler zu einem „neuen Ticket", abgerechnet nach Stunden.
Abnahmeprotokoll mit Kriterien, nicht per Handschlag
Das letzte, was KMU regelmäßig falsch machen: Sie unterschreiben das Abnahmeprotokoll ohne schriftliche Kriterien. „Das System funktioniert vertragsgemäß" ist kein Kriterium — das ist eine Glaubenserklärung.
Schreibe vor Beginn der UAT eine Liste konkreter, messbarer Abnahmekriterien:
- Eine Rechnung wird in weniger als 5 Sekunden bei 10 000 Kundenstammsätzen ausgestellt.
- 8 Nutzer gleichzeitig können Dokumente erzeugen, ohne merkbare Verlangsamung.
- Ein Preislisten-Import mit 30 000 Zeilen läuft in unter 10 Minuten durch.
- Alle 20 aus dem Leben gesammelten Szenarien laufen ohne kritischen Fehler durch.
- Ein Datenbank-Backup läuft im Nachtfenster und lässt sich in 2 Stunden zurückspielen.
Häng die Kriterienliste und das Ergebnis jedes Tests ans Protokoll. Das sind zwei Seiten mehr. Sie schützen dich vor dem Worst-Case, in dem ein halbes Jahr später „aber bei der Abnahme lief es doch" die Verteidigung des Anbieters wird.
Teile Defekte in drei Kategorien: kritisch (blockieren die Arbeit, müssen vor der Abnahme behoben werden), mittel (behindern die Arbeit, Zeitplan der Korrekturen im Anhang zum Protokoll) und Kosmetik (Backlog). Ohne diese Aufteilung endet jedes Nachbesserungsgespräch mit „das war nicht kritisch".
Wie geht es weiter
UAT ist langweilig. Sie erfordert, mehrere Personen 3-5 Tage aus dem Tagesgeschäft zu ziehen, Szenarien aufzuschreiben und mit dem Anbieter über Themen zu sprechen, über die der Anbieter lieber nicht sprechen würde. Aber diese Woche ist die günstigste Versicherung, die du im ganzen Projekt kaufst — mehrfach günstiger als eine einzige Korrektur nach dem Go-live.
Wenn eine Abnahme eines ERP, WMS, CRM oder einer individuell entwickelten Lösung vor dir liegt und du nicht sicher bist, wie du sie strukturieren sollst, um keinen Murks zu übernehmen — lass uns reden. Das erste Gespräch ist kostenlos und dauert eine halbe Stunde.
Ein unterschriebenes Abnahmeprotokoll ist das Ende deiner Verhandlungsmacht. Alles, was du vom Anbieter willst, musst du davor bekommen.