Nel mondo dello sviluppo software esiste un termine che i programmatori usano con una certa ironia quando un collega si complica la vita da solo con una prassi che prende il nome di over-engineering.
Questo termine indica quella tendenza a costruire soluzioni elaborate per problemi semplici, a creare architetture che anticipano scenari ipotetici che non arriveranno mai, a trasformare un’operazione lineare in un labirinto di dipendenze.
Chi lavora nel software lo riconosce immediatamente, e di solito ci ride sopra. Poi fa esattamente lo stesso errore in hotel, in distribuzione, in revenue management, e non ci ride più.
Nell’episodio 262 di Ospitalità 4.0 Marco Matarazzi ed Edoardo Ridolfi hanno parlato a lungo di questo fenomeno applicato alla gestione alberghiera.
Il punto di partenza è semplice: è molto semplice complicare le cose semplici.
Ma le conseguenze di quella complicazione raramente vengono messe a fuoco fino in fondo.
L’over-ingegnerizzazione in hotel non nasce da cattive intenzioni.
Nasce da un’ambizione tecnica legittima, dalla volontà di fare le cose bene, di coprire tutti i casi possibili, di non farsi trovare impreparati.
Il problema è che questo impulso, applicato senza criterio, produce il risultato opposto: processi che nessuno capisce, dati che nessuno riesce a leggere, sistemi che funzionano solo finché c’è in giro la persona che li ha costruiti.
Troppi strumenti, nessun dato utile
Un caso molto diffuso è quello della proliferazione di software: l’hotel che usa due sistemi di tracciamento diversi per il sito web perché il primo “non bastava”, oppure quello che gestisce email marketing, social e analytics con tre piattaforme separate, non collegate tra loro, che producono tre report diversi con numeri che non tornano mai.
Ad un certo punto non si capisce più quale numero credere, e il risultato pratico è che non si prende nessuna decisione basata sui dati, perché i dati sono diventati un problema invece che una risposta.
La stessa logica si applica alla scelta dei software.
Quante volte un booking engine viene scelto per i colori personalizzabili della schermata di prenotazione, ignorando che l’integrazione col PMS è lenta, che lo scarico delle prenotazioni richiede ore, che la comunicazione tra i sistemi produce ritardi che in alta stagione diventano errori?
Il dettaglio estetico ha prevalso sull’infrastruttura, e l’infrastruttura si è presa la sua rivalsa.
Nel revenue management questo eccesso di ingegnerizzazione porta a un’altra trappola: il mito dell’AB testing applicato alla singola struttura ricettiva.
L’AB testing è una tecnica potente, usata bene da Booking.com, Amazon, dalle grandi compagnie aeree. Funziona quando si hanno volumi statistici sufficienti a rendere significativo il confronto tra due varianti.
Un hotel da cento camere con una stagionalità marcata non è Booking.com.
Non ha i volumi per trarre conclusioni valide da un test su due versioni diverse del preventivo. Il processo esiste, è sofisticato, sembra professionale, ma non produce nulla di utile.
È complessità fine a se stessa.
Il sistema che funziona solo finché c’è “LUI”
C’è un costo dell’over-ingegnerizzazione che viene quasi sempre sottovalutato, ed è il costo umano.
Ogni sistema troppo complesso tende a diventare patrimonio esclusivo di chi lo ha costruito. Chi lo ha architettato conosce le dipendenze, sa dove stanno le eccezioni, ha in testa la mappa di quel labirinto. Tutti gli altri si limitano a usare le parti che capiscono, o a non usarle affatto.
La domanda che Marco e Edoardo pongono nella puntata è diretta: “se tu oggi non ci sei in hotel, chi manda avanti questa baracca che hai strutturato?”
Non è una domanda retorica.
È il test pratico di qualunque processo. Se la risposta è “nessuno” o “bisogna aspettare che torni lui”, allora il processo non è un asset dell’hotel, è un rischio operativo.
Questo vale per la tecnologia, ma vale ancora di più per i processi di marketing e distribuzione.
Un piano editoriale così ambizioso da non essere mai rispettato, profili social aperti su tutte le piattaforme esistenti senza le risorse per gestirli, un calendario di contenuti che si svuota ogni volta che il reparto è sotto pressione.
Il risultato di questa complessità non è una presenza digitale migliore: è una presenza digitale piena di post vecchi di tre mesi e account abbandonati che comunicano trascuratezza invece che cura.
Pubblicare, misurare, correggere
Il perfezionismo è il compagno di viaggio naturale dell’over-ingegnerizzazione.
Si aspetta la foto perfetta, il copy ideale, il sistema completamente configurato prima di partire. Nel frattempo non parte nulla.
Vale per i podcast, vale per i processi in hotel.
Pubblicare e correggere in corsa produce quasi sempre risultati migliori rispetto ad aspettare una perfezione che si sposta sempre un po’ più avanti.
I sistemi semplici, comprensibili, gestibili anche da chi è arrivato in hotel il mese scorso, reggono nel tempo molto meglio dei castelli tecnici costruiti da qualcuno che poi se n’è andato.
È la stessa filosofia con cui è stato progettato Slope: non aggiungere complessità dove non serve, ma toglierla.
Un unico sistema che copre PMS, booking engine, channel manager, CRM e revenue, in modo che il dato non si disperda tra piattaforme diverse e che chiunque nel team possa trovare quello che cerca senza bisogno di un manuale.
