Was vor der Anbindung von Restaurant-Technologie geklärt werden sollte

Integrationsprojekte scheitern selten daran, dass zwei Systeme keine Anfrage austauschen können. Schwieriger sind meist die Grenzen darum: Zuständigkeiten, optionale Felder, Mapping-Entscheidungen, Statusverhalten und der Support nach dem Start.

Ein kurzes Scope-Dokument macht diese Grenzen sichtbar, bevor die Entwicklung beginnt. Verwenden Sie die folgende Checkliste für ein Kassensystem, eine Bestellplattform oder ein Restaurant-Technologie-Produkt, das über MERGEPORT angebunden wird.

1. Systeme und Märkte benennen

Halten Sie die genauen Produkte, Versionen, Länder und Restaurant-Setups fest. Eine allgemeine Kategorie wie „alle Lieferplattformen“ ist kein ausreichender Implementierungsumfang.

Starten Sie mit dem Integration Explorer und bestätigen Sie die Zielkombination anschließend mit MERGEPORT. Ein gelistetes System belegt, dass ein Integrationseintrag vorhanden ist. Es verspricht nicht, dass jede Funktion in jeder Kombination verfügbar ist.

2. Jeden benötigten Datenfluss einzeichnen

Listen Sie Richtung und Verantwortlichen für jeden Datenfluss auf. Häufige Beispiele sind:

• Bestelleingang von einer Plattform in die Kasse;
• Annahme, Ablehnung und spätere Statusänderungen;
• Änderungen von Liefer- oder Abholzeiten;
• Artikel- oder Menüdaten aus dem festgelegten führenden System;
• Standortkonfiguration und Aktivierung von Kanälen.

Unterscheiden Sie bei jedem Datenfluss zwischen „für den Start erforderlich“ und „später sinnvoll“. So blockieren optionale Funktionen nicht den ersten funktionierenden Rollout.

3. Kennungen und Artikelmapping definieren

Dasselbe Produkt kann in Kasse, Plattform und Integration Layer unterschiedliche Kennungen haben. Legen Sie fest, wie Artikel, Varianten, Zusätze, Steuern und Standorte zugeordnet werden.

Definieren Sie außerdem, was bei einem unbekannten Artikel passiert. Ein sicherer Ablauf kann die Bestellung stoppen, eine manuelle Prüfung auslösen oder einen freigegebenen Ausweichartikel verwenden. Das ist eine Produkt- und Betriebsentscheidung, nicht nur ein technisches Detail.

4. Verantwortung für Bestellstatus zuordnen

Dokumentieren Sie, welches System welchen Übergang ausführen darf. Eine eingehende Bestellung kann in der Kasse, in einer operativen Oberfläche oder unter definierten Regeln automatisch angenommen werden. Spätere Änderungen müssen für die verbundene Plattform gültig bleiben.

Die API liefert die für eine Bestellung verfügbaren Übergänge. Ihr Produkt sollte trotzdem festlegen, welche Aktionen Anwender ausführen dürfen, was bei einer abgelehnten Aktualisierung geschieht und wie der aktuelle Status dargestellt wird.

5. Testfälle vor der Aktivierung planen

Ein sinnvoller Abnahmetest umfasst mehr als den Idealfall. Prüfen Sie:

1. eine normale Bestellung mit zugeordneten Artikeln;
2. eine Bestellung mit Zusätzen oder optionalen Daten;
3. Stornierung und Ablehnung;
4. Zeitänderungen, sofern unterstützt;
5. unbekannte Artikel oder unvollständige Mappings;
6. einen vorübergehenden Verbindungsfehler und die Wiederherstellung;
7. ob die beteiligten Systeme dasselbe operative Ergebnis zeigen.

Verwenden Sie einen definierten Teststandort und Testzugänge. Trennen Sie die Aktivierung im Produktivbetrieb von der technischen Verifikation.

6. Verantwortung für Start und Support klären

Benennen Sie die Person oder das Team für Zugangsdaten, Aktivierung, Monitoring und First-Level-Support. Halten Sie fest, welche Informationen bei einer Eskalation benötigt werden: Standort, Integration, Bestellkennung, Zeitpunkt, beobachteter und erwarteter Status.

Das Ergebnis sollte kurz genug sein, um tatsächlich verwendet zu werden. Eine Seite mit Zielsystemen, notwendigen Datenflüssen, Zuständigkeiten, Abnahmetests und Eskalationsweg ist wertvoller als eine breite Spezifikation, die niemand pflegt.

Sobald diese Entscheidungen klar sind, lässt sich die Umsetzung besser einschätzen und die Übergabe in den laufenden Betrieb leichter unterstützen.