Dynamic Packaging - Parte 4

Il post precedente si era chiuso sulla domanda se esista un modo per integrare diversi fornitori in un unica piattaforma di pacchetto turistico dinamico anche se questi non possiedono una interfaccia XML standard OTA, o se non possiedono una interfaccia tout court.

La prima risposta che mi sentirei di dare è: Si, ma con un costo di sviluppo talmente alto che rende di fatto impraticabile il progetto.

La via intermedia è quella ibrida derivata dall'idea di MarketPlace, cioè una piattaforma standard dove i diversi fornitori accedono direttamente (ed in alcuni casi manualmente) per inserire i popri prodotti e servizi, le proprie offerte. All'interno della piattaforma avviene una normalizzazione dei dati in modo che possano essere ricercati e utilizzati secondo schemi standard. L'intera piattaforma deve naturalmente esporre verso l'esterno una interfaccia XML standard OTA.
Il costo di interfacciamento per i fornitori non strutturati viene quindi rimpiazzato dal costo umano di chi caricherà ed aggiornerà i dati manualmente nei casi in cui non sia possibile alcun tipo di automazione. Si tratta comunque di un impegno distribuito fra i vari fornitori e non centralizzato, a beneficio dell'economia del sistema.

Si tratta quindi di far apparire il sistema, alimentato da diversi fornitori, come un enorme fornitore unico, che espone verso l'esterno una unica interfaccia standard per i vari tipi di servizi prenotabili.

Per il caricamento dei dati da parte dei fornitori, quelli più strutturati che già dispongono di interfacce OTA possono essere integrati direttamente, chi invece ha interfacce proprie deve adattarle agli standard o realizzare applicazioni proxy di traduzione. Per i fornitori più piccoli o solo meno strutturati dal punto di vista tecnologico, che però rappresentano il vero valore aggiunto del sistema, occorre realizzare una applicazione di backoffice che permetta il caricamento e la gestione dei dati. Eventuali interfacce ad-hoc possono essere costruite solo dove la mole dei dati non consenta la gestione manuale, o dove esistano già applicativi gestionali proprietari da dove attingere le informazioni.

Parlando di informazioni gestite dal sistema, è indubbio che queste rappresentano non solo i dati relativi a servizi turistici, ma anche e soprattutto informazioni di contorno che costruiscano l'ambiente "sociale" nel quale tutta l'offerta deve integrarsi. Anche il concetto di fornitore deve essere quindi esteso agli utenti stessi che alimentano il database con le loro recensioni, le loro foto, i loro giudizi e quant'altro.

Google, ha da tempo iniziato un percorso simile di integrazione dei contenuti generati dagli utenti miscelandoli alle sue mappe interattive dove vengono riportate anche le realtà economiche (alberghi, ristoranti, attrazioni ...). Le risorse messe in campo da Big G sono senza dubbio il massimo oggi disponibile, ma quello che a mio avviso ancora manca è la facilità per l'utente di distillare da questo mare magnum di informazioni una idea concreta di itinerario, un preventivo di spesa, un punto finale dove riepilogare le scelte fatte e decidere l'acquisto di quanto necessario. Non esito ad immaginare che Google stia puntando a questo, le voci di una imminente applicazione specifica per il turismo targata Google sono ormai più che certezze e si tratta solo di aspettare. Ma Google come affronterà l'integrazione dei fornitori? Si limiterà a linkare il sito web dove mandare il cliente per finalizzare gli acquisti mancando ancora una volta l'obiettivo dell'one-stop-shop?

Qualcuno ha voglia di approfondire i concetti ed andare più a fondo su questa tematica?