.webp)
Dans ce numéro, Ben Waymark aborde les questions difficiles relatives à la livraison basée sur les commandes : comment gérer les états du cycle de vie des services, résoudre les conflits entre les systèmes, gérer les perturbations sans files d'attente de l'ère PNR, et ce qu'il faut pour fonctionner dès le premier jour dans un environnement aérien hybride.
Dans les trois premiers numéros de cette série de FAQ sur la prestation de services, nous avons abordé le passage d'un fonctionnement basé sur les PNR à une prestation de services basée sur les commandes, en explorant ce que signifie concrètement la « prestation avec commandes » et pourquoi elle est préférable aux approches traditionnelles. Nous avons examiné comment les compagnies aériennes peuvent entamer cette transition même avec des systèmes PSS traditionnels, comment le statut « prêt à voler » passe du DCS aux commandes et comment les services sont transférés aux systèmes opérationnels. Nous avons examiné la gestion des bagages, l'interligne ad hoc, les médias enrichis dans les flux d'achat et les avantages pratiques dont bénéficient déjà les compagnies aériennes, qu'il s'agisse de l'amélioration du service à la clientèle, de la visibilité en temps réel ou de l'accélération des ventes incitatives. Nous avons également exploré la manière dont les transporteurs gèrent le statut de la prestation de services sur les trajets interlignes, en garantissant une vision cohérente sans avoir besoin d'intégrations directes entre les systèmes des transporteurs.
Nous abordons maintenant les questions plus difficiles : comment garder le contrôle lorsque les choses tournent mal ? Comment définir la vérité lorsque les systèmes divergent ? Et que faut-il réellement pour mettre en place une livraison axée sur l'ordre dès le premier jour ?
Quel est le cycle de livraison par article commandé et quelles sont les transitions de statut non négociables ?
Chaque élément de commande comprend un service (vol, siège, bagage, repas, etc.) qui suit un cycle de livraison défini. Ce cycle est suivi grâce aux mises à jour de statut échangées entre le système de gestion des commandes (OMS), le système de gestion des livraisons (DMS) – le contrôle des départs (DCS) est une fonction du DMS – et les prestataires de livraison. Nous avons besoin d'un modèle d'état pratique qui couvre toutes les étapes critiques : enregistrement, embarquement, livraison, livraison échouée, remplacement, remboursement, compensation et exécution partielle.
Pour l'instant, cela n'est pas très bien défini par l'IATA, mais idéalement, nous devons nous orienter vers quelque chose comme ceci :
Créé : Le droit est réservé dans la commande, mais n'a pas encore été livré.
Prêt pour la livraison : le client est autorisé à utiliser le service (par exemple, il peut s'enregistrer ou déposer ses bagages).
Enregistrement effectué : le contrôle des départs confirme l'enregistrement. Le siège est attribué, les bagages sont acceptés, etc.
Embarquement : Le passager monte physiquement à bord et le service (par exemple, le vol) commence.
Livré : le service a été consommé. Le passager a voyagé, le bagage a été transporté, le repas a été servi.
Livraison échouée : le service n'a pas été fourni (par exemple, absence, problème technique, sac refusé).
Remplacé : le service initial a été remplacé par un autre (par exemple, nouveau type de siège, vol dérouté).
Remboursé : le service non fourni est annulé et remboursé.
Indemnisation : une compensation financière ou sous forme de services est accordée en cas de défaillance du service.
Partiellement rempli : une partie du service a été fournie (par exemple, trajet partiel effectué ou un seul des deux sacs chargé).
Ces transitions doivent être reflétées dans les messages ServiceStatusChangeNotif et enregistrées dans la piste d'audit de la commande. Ce modèle prend en charge une gestion riche des perturbations sans revenir à la réémission d'artefacts.
À qui appartient la vérité lorsque la livraison, la gestion des commandes et les partenaires ne sont pas d'accord ?
Lorsque plusieurs systèmes sont impliqués, les conflits sont inévitables. Nous devons donc clairement identifier quel système est à l'origine de quels événements, comment les conflits sont résolus et à quoi ressemble le registre d'audit.
Dans le modèle axé sur les commandes :
- L'OMS est le système d'enregistrement des droits et de leur statut. Il détermine ce qui a été proposé, confirmé, annulé, remplacé ou remboursé.
- Le DMS/Contrôle des départs génère des événements opérationnels tels que l'enregistrement, l'embarquement et l'état du chargement. Ceux-ci sont communiqués via ServiceStatusChangeNotif.
- Les prestataires de services de livraison (tels que les prestataires de services d'assistance en escale) fournissent également des mises à jour sur le statut, par exemple, accès au salon accordé ou poids des bagages confirmé.
- Le système de gestion des livraisons (DMS) fournira des fonctionnalités de contrôle des départs ainsi que les statuts des prestataires de livraison.
La résolution des conflits suit cette hiérarchie :
- Si un service n'est pas marqué comme livré dans l'OMS, il est considéré comme non livré, indépendamment de ce qu'indiquent les registres du contrôle des départs (DC/DCS).
- Si l'OMS a reçu une mise à jour de statut provenant d'une source fiable (DC ou partenaire), celle-ci devient la vérité canonique.
- Les divergences sont consignées et signalées pour être traitées manuellement ou automatiquement.
Le journal d'audit est centralisé dans l'Ordre et contient toutes les mises à jour de statut avec le système source, l'horodatage et les détails de l'événement. Cela permet une traçabilité complète et la gestion des litiges.
Comment fonctionne la gestion des perturbations dans un modèle de livraison basé sur les commandes sans files d'attente de l'ère PNR ?
Passons en revue un scénario complet de bout en bout pour voir comment cela fonctionne dans la pratique. Nous aborderons une erreur de connexion avec des complications liées aux bagages, un réaménagement, une réattribution de siège, un report des services auxiliaires et la messagerie client, en suivant les mises à jour à chaque étape.
- Connexion manquée : le passager arrive en retard et rate sa correspondance. DC envoie un ServiceStatusChangeNotif à l'OMS indiquant : « Vol non embarqué ».
- Réacheminement : OMS déclenche un processus de réacheminement via OrderReshop afin de proposer de nouvelles options d'itinéraire. Le client sélectionne son nouveau vol.
- Réattribution de siège : le nouveau siège fait partie de l'offre de réinstallation et est mis à jour dans la commande via OrderChange.
- Report des services auxiliaires : les services auxiliaires valides (comme un repas prépayé) sont réattribués ou remboursés selon une logique de correspondance.
- Bagages : Le bagage est déjà chargé sur le vol initial. Le système de suivi des bagages met à jour l'OMS, qui signale l'incohérence.
- Messagerie client : OMS lance la messagerie via une notification push ou un workflow d'agent, envoyant le nouvel itinéraire et les mises à jour.
- Compensation (si nécessaire) : si le client passe à un service inférieur ou perd un service, OrderChange ou OrderQuote reflète l'ajustement et un remboursement ou un bon d'achat est émis.
Toutes les mises à jour sont répercutées en temps réel dans la commande. Aucune mise en file d'attente ni synchronisation manuelle n'est nécessaire entre les systèmes de billetterie, de réservation ou d'inventaire.
Comment gérer les livraisons partielles, les substitutions de services et les compensations sans recréer de billets et d'EMD ?
La question clé ici est de savoir comment représenter directement dans l'Ordre l'accomplissement, l'échec et la réparation sans retomber dans la création de nouveaux artefacts sous un nom différent.
Il n'est pas nécessaire de recréer des billets ou des EMD. L'enregistrement de la commande s'occupe de tout :
- Livraison partielle : chaque article commandé a son propre statut de livraison. Si une partie du trajet est effectuée en avion ou si un service n'est que partiellement utilisé, cela est enregistré séparément.
- Substitution : la commande indique quel service a été remplacé et par quoi. Par exemple : le siège 12A a été remplacé par le 14C, avec un remboursement si la valeur diffère.
- Compensation : elle apparaît sous la forme d'un nouvel article de commande (comme un bon d'achat), d'un ajustement du montant total payé ou d'une valeur stockée associée à la commande.
Tous les événements sont consignés avec des mises à jour de statut (ServiceStatusChangeNotif), des entrées dans la piste d'audit et, le cas échéant, des actions OrderChange. Les remboursements, pénalités ou gestes commerciales sont directement intégrés dans la commande ; aucun artefact dupliqué n'est nécessaire.
Quelles sont les intégrations et les contrôles minimaux nécessaires pour mettre en œuvre la livraison basée sur les commandes dans une compagnie aérienne hybride ?
Pour une compagnie aérienne fonctionnant selon un modèle hybride (front-end basé sur les commandes avec des systèmes hérités en arrière-plan), vous devez définir l'ensemble minimal viable d'interfaces et de contrôles. Cela inclut l'ingestion d'événements, les vérifications des droits, la gestion des exceptions et la sémantique partagée « prêt à voler ».
Voici à quoi cela ressemble :
Ingestion d'événements : votre OMS doit recevoir les événements provenant du DCS, des systèmes de bagages, des salons, de la restauration et de l'enregistrement via ServiceStatusChangeNotif.
Vérification des droits : les systèmes de livraison doivent interroger l'OMS (ou recevoir des messages push ServiceDeliveryNotif ) pour vérifier ce qui doit être livré.
Gestion des exceptions : votre OMS doit gérer les réponses d'erreur et les indicateurs de conflit (par exemple, lorsqu'un sac est livré mais que la commande a été annulée).
Sémantique commune « prête à l'emploi » : tous les systèmes de livraison doivent s'aligner sur les définitions basées sur les commandes des termes « enregistré », « embarqué » et « livré ».
Processus de secours : vous devez pouvoir enregistrer ou remplacer manuellement le statut à l'aide des outils de l'agent, tout en préservant l'intégrité de l'audit des commandes.
Cette configuration vous permet de prendre en charge NDC et ONE Order sur votre infrastructure existante, tout en vous affranchissant progressivement des dépendances PSS.
Auteur
