Une feuille de calcul, un CRM commercial ou un syst\u00e8me comptable standard enregistrent une vente de la m\u00eame mani\u00e8re, quel que soit ce qui a \u00e9t\u00e9 vendu : un client, un montant, une date. Cette logique fonctionne bien pour la plupart des entreprises. Dans une agence de voyages, toutefois, l\u2019objet vendu est rarement une seule chose. Un logiciel g\u00e9n\u00e9rique peut traiter le paiement, mais il ne peut pas toujours repr\u00e9senter ce qui s\u2019est r\u00e9ellement pass\u00e9 derri\u00e8re ce paiement : un forfait assembl\u00e9 avec plusieurs fournisseurs, un billet qui d\u00e9pend d\u2019un autre service et une date qui se d\u00e9cale pour tout le monde \u00e0 la fois si elle se d\u00e9cale pour l\u2019un. <\/p>\n\n
Pour un syst\u00e8me g\u00e9n\u00e9rique, une vente est un \u00e9v\u00e9nement unique : un encaissement est enregistr\u00e9, associ\u00e9 \u00e0 un client, et le processus s\u2019arr\u00eate l\u00e0. Un forfait touristique ne fonctionne pas ainsi. Vendre un forfait, c\u2019est engager, en une seule op\u00e9ration, des services provenant de fournisseurs diff\u00e9rents, dans des devises diff\u00e9rentes et avec leurs propres calendriers. Le vol peut \u00eatre confirm\u00e9 en quelques minutes. L\u2019h\u00f4tel peut prendre une journ\u00e9e. L\u2019excursion peut d\u00e9pendre d\u2019une quota minimale de passagers qui n\u2019est pas encore garantie. <\/p>\n\n
Le logiciel g\u00e9n\u00e9rique ne fait pas la diff\u00e9rence entre confirmer la vente et confirmer chaque composant de cette vente. Il traite le forfait comme s\u2019il s\u2019agissait d\u2019un seul service, alors qu\u2019en r\u00e9alit\u00e9 c\u2019est une collection d\u2019engagements avec des niveaux de certitude diff\u00e9rents. Cette diff\u00e9rence d\u00e9termine si l\u2019\u00e9quipe peut savoir, \u00e0 tout moment, quelle partie du voyage est r\u00e9gl\u00e9e et laquelle reste en attente. Avant d\u2019\u00e9valuer quel type de syst\u00e8me r\u00e9sout cela, il est utile de comprendre comment cette logique change selon le type d\u2019agence, ce qui est d\u00e9velopp\u00e9 dans cette analyse sur les types de logiciels selon le mod\u00e8le \u00e9conomique<\/a>. <\/p>\n\n Pourquoi un tour n\u2019est pas une ligne de plus dans un outil g\u00e9n\u00e9rique<\/strong><\/p>\n\n Un tour n\u2019existe presque jamais seul. Il est g\u00e9n\u00e9ralement li\u00e9 \u00e0 une quota minimale de participants, \u00e0 un horaire fixe partag\u00e9 avec le reste du groupe et \u00e0 un prestataire local qui confirme le d\u00e9part selon ses propres d\u00e9lais. Un outil g\u00e9n\u00e9rique peut enregistrer le nom du tour et son prix comme une donn\u00e9e parmi d\u2019autres, mais il ne peut pas avertir automatiquement que ce d\u00e9part a perdu sa viabilit\u00e9 parce que la quota minimale n\u2019a pas \u00e9t\u00e9 atteinte, ou que l\u2019horaire d\u2019un tour entre en conflit avec le transfert que le prestataire n\u2019a pas encore confirm\u00e9. <\/p>\n\n Un forfait typique peut inclure, par exemple :<\/p>\n\n Chacun de ces composants a son propre cycle de vie. Le logiciel g\u00e9n\u00e9rique n\u2019a pas \u00e9t\u00e9 con\u00e7u pour suivre cinq cycles de vie diff\u00e9rents au sein d\u2019une seule vente. C\u2019est pourquoi, quand quelque chose change (une date, un fournisseur, une quota), l\u2019ajustement finit par se faire en dehors du syst\u00e8me, dans un e-mail ou dans une note manuelle que personne d\u2019autre ne voit. Ce point de friction est souvent le premier \u00e0 appara\u00eetre lorsqu\u2019une agence commence \u00e0 \u00e9valuer si son syst\u00e8me de r\u00e9servation actuel suffit encore<\/a> au volume qu\u2019elle g\u00e8re. <\/p>\n\n Un service combin\u00e9, par exemple un transfert qui inclut un repas, ou une excursion qui inclut des billets et le transport, pose un probl\u00e8me suppl\u00e9mentaire : le co\u00fbt interne ne correspond pas au prix de vente au client, et ces deux chiffres doivent coexister sans se m\u00e9langer. Un syst\u00e8me g\u00e9n\u00e9rique impose souvent une simplification : il enregistre le prix final, mais perd la composition des co\u00fbts qui l\u2019a g\u00e9n\u00e9r\u00e9. <\/p>\n\n\n
Comment un syst\u00e8me g\u00e9n\u00e9rique g\u00e8re un service combin\u00e9<\/strong><\/h2>\n\n
<\/td> Syst\u00e8me g\u00e9n\u00e9rique<\/strong><\/td> Service touristique combin\u00e9<\/strong><\/td><\/tr> Unit\u00e9 de vente<\/td> Une ligne, un montant<\/td> Plusieurs composants avec leur propre co\u00fbt et leur propre fournisseur<\/td><\/tr> Devise<\/td> Une par transaction<\/td> Peut varier selon le composant<\/td><\/tr> Annulation<\/td> Une politique g\u00e9n\u00e9rale<\/td> Une politique diff\u00e9rente selon le composant<\/td><\/tr> Marge<\/td> Calcul\u00e9e sur le total<\/td> Calcul\u00e9e composant par composant<\/td><\/tr><\/tbody><\/table><\/figure>\n\n