Kassensystem wechseln: Daten, Prozesse und Schnittstellen richtig vorbereiten

1. Gewechselt wird ein Systemverbund, nicht nur eine Kasse

An der Kasse wird bezahlt, doch die Daten davor und danach leben oft in mehreren Systemen: Speisekarte, Warenwirtschaft, Reservierung, Dienstplan, Buchhaltung, Kartenterminal, Lieferplattform oder Küchenrobotik. Ein Kassenwechsel scheitert deshalb selten am neuen Bildschirm. Er scheitert an einer Artikelnummer, die zwei Bedeutungen hat, an einem Gutschein ohne Restwert oder an einer Schnittstelle, für deren Fehler niemand zuständig ist.

Zeichne den tatsächlichen Informationsfluss als einfaches Netz. Jeder Pfeil braucht vier Angaben: Welche Daten fließen, in welche Richtung, wie schnell und wer reagiert bei einem Fehler? Erst danach lässt sich entscheiden, was am Umstellungstag wirklich gemeinsam wechseln muss.

2. Eine Inventur, die auch Ausnahmen findet

Eine Geräteliste ist zu wenig. Die Inventur muss Hardware, Software, Verträge, Daten und gelebte Abläufe verbinden. Beobachte dafür mindestens eine ruhige und eine volle Schicht. Viele Umwege – handschriftliche Umbuchungen, gemeinsame Bediener oder nachträglich korrigierte Trinkgelder – stehen in keinem Handbuch.

3. Daten nach Zukunft, Historie und offenen Vorgängen trennen

„Wir übernehmen alle Daten“ ist keine prüfbare Zusage. Teile den Bestand in drei Klassen. Zukunftsdaten werden aktiv im neuen System benötigt. Historische Daten müssen auffindbar und auswertbar bleiben, gehören aber nicht zwangsläufig in die neue Bedienoberfläche. Offene Vorgänge brauchen eine einzelne, fachlich kontrollierte Übergabe.

Prüfe nicht nur, ob eine Datei vorhanden ist. Öffne sie mit einem zweiten Werkzeug, gleiche Summen und Stückzahlen ab und ziehe Stichproben vom Ursprungsbeleg bis zum Export. Die DSFinV-K definiert für Kassendaten eine einheitliche Struktur; sie ersetzt aber weder die fachliche Plausibilisierung noch die Dokumentation des betrieblichen Ablaufs.

4. Eigenfunktion oder Schnittstelle: pro Bereich entscheiden

Ein Systemwechsel ist eine gute Gelegenheit, historisch gewachsene Doppeleingaben zu entfernen. Er ist kein Grund, jede bewährte Fachlösung auszutauschen. Bewerte deshalb jeden Bereich separat nach Prozessabdeckung, Datenqualität, Ausfallsicherheit, Aufwand und Bindung an den Anbieter.

Für jede verbleibende Schnittstelle gehört ein kleiner Betriebsvertrag in die Projektdokumentation: führendes System, Feldzuordnung, Übertragungsrhythmus, Wiederholungsverhalten, Monitoring und verantwortliche Person. Ein grüner „verbunden“-Status beweist noch nicht, dass ein verlorener Bon erkannt und richtig nachgesendet wird.

5. Nicht Funktionen testen, sondern einen Geschäftstag

Ein Abnahmetest mit einem Kaffee und Barzahlung prüft fast nichts. Baue stattdessen einen kleinen Modelltag aus den häufigsten und riskantesten Abläufen. Jede Fallkarte nennt Ausgangslage, Handlung, erwartetes Ergebnis in allen beteiligten Systemen und den Beleg für die Prüfung.

6. Der Umstellungstag braucht Abbruchkriterien

Ein Go-live-Plan beschreibt nicht nur den Erfolgsweg. Er legt fest, bis wann welche Prüfung bestanden sein muss und ab welchem Fehler zurückgefallen wird. Das nimmt am Umstellungstag Druck aus Entscheidungen, die sonst mitten im Service improvisiert würden.

Der Wechsel ist nicht mit dem ersten erfolgreichen Verkauf beendet. Erst wenn Tagesabschluss, Zahlungsabgleich, Buchhaltung, Bestandsbewegungen und alle angebundenen Systeme über einen realistischen Zeitraum stimmen, ist die Migration fachlich abgeschlossen. Bis dahin bleibt jede Abweichung ein Projektpunkt – nicht die neue Normalität.