Die Verbindung einer KI-Software mit Oracle OPERA Cloud über OHIP ist mechanisch gut dokumentiert. Oracle veröffentlicht die API-Spezifikationen, der Authentifizierungsfluss ist Standard-OAuth 2.0 und die meisten Anbieter können einen Sandbox-Aufruf erhalten, der innerhalb eines Tages Daten zurückgibt. Die Probleme, die diese Projekte tatsächlich zum Scheitern bringen, tauchen in diesem Stadium selten auf. Sie tauchen zwei bis sechs Wochen später auf, sobald echte Reservierungen, echte Tarifpläne und echtes Personal an der Rezeption beteiligt sind.
In diesem Artikel geht es um diese Probleme: diejenigen, die auftauchen, nachdem die Demo funktioniert, nicht davor.
Scope Creep, getarnt als technisches Setup
Der OHIP-Zugriff wird nicht als pauschale Erlaubnis gewährt. Oracle vergibt Berechtigungen pro API-Familie, pro Eigenschaft und häufig pro Anwendungsfall, der in der App-Registrierung beschrieben wird. Ein Anbieter könnte Zugriff auf Reservierungs- und Profildaten anfordern, eine Genehmigung erhalten, die Integration aufbauen und dann mitten im Projekt feststellen, dass er auch Folio- oder Housekeeping-Statusdaten benötigt, um die Funktion bereitzustellen, nach der das Hotel tatsächlich gefragt hat.
Jede weitere Berechtigung kann eine erneute Zertifizierungsüberprüfung bedeuten, und die Zertifizierungsfristen werden in Wochen und nicht in Tagen gemessen. Eigenschaften, die davon ausgehen „Wir sind bereits verbunden, das Hinzufügen eines weiteren Felds ist trivial“, sind normalerweise falsch. Die Lösung besteht darin, jedes Datenelement abzubilden, das die KI-Ebene jemals berühren wird, bevor die Berechtigungsanfrage gesendet wird, nicht danach. Wenn die Intelligence-Schicht einen Workflow zur Servicewiederherstellung auslösen muss, umfasst dies den Reservierungsstatus, das Gästeprofil und manchmal auch Rechnungsdaten. Alle drei sollten im Voraus festgelegt werden.
Datenzuordnung, die identisch aussieht, es aber nicht ist
Zwei OPERA Cloud-Eigenschaften im selben Kettencode können unterschiedliche Reservierungsstatuswerte, unterschiedliche Preiscode-Taxonomien und unterschiedliche Block- oder Gruppencodes verwenden, insbesondere wenn eine Eigenschaft von einem älteren PMS migriert und die alte Konfiguration geerbt hat. Eine Integration, die anhand der Daten einer Eigenschaft erstellt und getestet wurde, kann bei der nächsten heimlich fehlschlagen.
Häufige Beispiele:
- Ein „Fällig eingegangen“-Status, der etwas anderes bedeutet, sobald eine Unterkunft Split-Stay-Reservierungen ermöglicht
- Tarifcodes, die Paketeinschlüsse in der Codezeichenfolge selbst kodieren, die eine KI-Ebene möglicherweise buchstäblich analysiert, anstatt die verknüpfte Paketdefinition nachzuschlagen
- Die Logik zum Zusammenführen von Gastprofilen verhält sich unterschiedlich, je nachdem, ob der Treueabgleich in dieser Unterkunft aktiviert ist
Nichts davon ist ein Fehler in OHIP. Es handelt sich um Konfigurationsvarianzen, die die Integrationsschicht Eigenschaft für Eigenschaft explizit berücksichtigen muss, anstatt davon auszugehen, dass überall ein einziges Schema gilt. Teams, die eine dünne, eigenschaftsspezifische Zuordnungsschicht zwischen den PMS-Rohdaten und ihrem eigenen internen Modell aufbauen, neigen dazu, dies zu vermeiden. Teams, die Annahmen aus der ersten Eigenschaft, die sie verknüpft haben, fest kodieren, neigen dazu, dies auf die harte Tour bei Eigenschaft zwei herauszufinden.
Synchronisierungs-Timing und was passiert, wenn das PMS kurzzeitig nicht verfügbar ist
OHIP unterstützt sowohl Umfragen als auch ereignisgesteuerte Benachrichtigungen, und die Wahl ist wichtiger als es aussieht. Das Abfragen in einem festen Intervall ist einfach, führt jedoch zu einem Verzögerungsfenster, in dem die KI-Ebene auf veraltete Daten reagiert. Ereignisbenachrichtigungen reduzieren diese Verzögerung, erfordern jedoch, dass die Integration nach einer unterbrochenen Verbindung mit der Zustellung außerhalb der Reihenfolge, doppelten Ereignissen und der Wiederverbindungslogik umgehen kann.
Die Gefahr besteht nicht darin, das falsche Muster auszuwählen. Es ist nicht geplant, dass das PMS während eines Wartungsfensters oder einer Netzwerkstörung auf der Grundstücksseite auch nur kurzzeitig nicht erreichbar ist. Eine Gastanfrage, die über eine KI-Ebene weitergeleitet wird, die davon ausgeht, dass das PMS immer erreichbar ist, kann stillschweigend fehlschlagen, als ungelöst protokolliert werden oder, schlimmer noch, dupliziert werden, sobald die Verbindung wiederhergestellt ist.
Die Frage, die sich jeder Anbieter vor dem Go-Live stellen sollte, ist nicht „Stellt er eine Verbindung her“, sondern „Was macht er in den neunzig Sekunden, nachdem er nicht mehr funktioniert?“.
Dies ist einer der Gründe, warum Hermes, die Hotelbetriebsebene von GadgetMall, jeden PMS-Anruf als etwas behandelt, das fehlschlagen kann, und Aktionen mit Idempotenzschlüsseln in die Warteschlange stellt, anstatt sie einmal auszulösen und dann weiterzumachen. Es handelt sich zwar um eine kleine Designentscheidung, aber sie macht den Unterschied aus, ob eine Gastanfrage stillschweigend verschwindet oder automatisch erneut versucht wird, sobald die Verbindung wiederhergestellt ist.
Nach dem Go-Live gibt es keinen klaren Eigentümer
Der letzte häufige Fehlerpunkt ist überhaupt nicht technischer Natur. Sobald eine Integration live ist, wer ist verantwortlich, wenn eine Zuordnung nach einem OPERA Cloud-Update unterbrochen wird oder wenn Oracle eine API-Version veraltet? Häufig lautet die Antwort „Niemand“, da der IT-Kontakt des Hotels davon ausgegangen ist, dass der Anbieter der Eigentümer ist, und der Anbieter davon ausgegangen ist, dass der PMS-Administrator des Hotels Konfigurationsänderungen melden würde.
Oracle führt eine Versionierung seiner OHIP-Endpunkte durch und informiert vorab über veraltete Funktionen. Diese Benachrichtigung geht jedoch an denjenigen, der die App registriert hat, und Gruppen mit mehreren Eigenschaften verlieren nach der Personalfluktuation manchmal den Überblick darüber, wer das ist. Eine einfache Abhilfemaßnahme besteht darin, beim Go-Live einen benannten Eigentümer auf beiden Seiten zuzuweisen, jede Berechtigung und API-Version in einem gemeinsamen Dokument zu protokollieren und es bei der Erneuerung erneut zu prüfen, nicht nur, wenn etwas kaputt geht.
Das Muster darunter
Alle oben genannten Fallstricke gehen auf dieselbe Grundursache zurück: Die Integration als einmalige technische Aufgabe zu behandeln und nicht als eine fortlaufende Betriebsbeziehung zwischen zwei Systemen, die sich beide ständig ändern. Oracle aktualisiert OPERA Cloud. Eigenschaften ändern die Konfiguration. Anbieter fügen Funktionen hinzu. Eine Integration, die darauf ausgelegt ist, diese Abweichung zu überstehen, mit explizitem Umfang, eigenschaftsbewusster Zuordnung und definiertem Fehlerverhalten, neigt dazu, im besten Sinne langweilig zu sein. Diejenigen, die diese Schritte überspringen, funktionieren in der Demo in der Regel einwandfrei und verursachen drei Wochen später ein Support-Ticket.