Un software per hotel è davvero valido se la software house che lo sviluppa non è organizzata bene?

Quando scegliamo un software per il nostro hotel, tendiamo a concentrarci sulle funzionalità, sul prezzo, sulle integrazioni e sulla facilità di utilizzo. Ma c’è un elemento che spesso trascuriamo: l’organizzazione dell’azienda che quel software lo sviluppa, lo vende e soprattutto lo mantiene.

Quando dobbiamo scegliere un nuovo PMS, un Channel Manager, un RMS o qualsiasi altro software per il nostro hotel, cosa guardiamo?

Generalmente chiediamo una dimostrazione, analizziamo le funzionalità, confrontiamo i prezzi, verifichiamo le integrazioni con gli altri sistemi che utilizziamo e cerchiamo di capire se il prodotto risponde alle nostre esigenze.

Sono tutte valutazioni corrette. Ma manca qualcosa.

Ci chiediamo mai come sia organizzata l’azienda che sta dietro a quel software?

Chi decide quali funzionalità sviluppare? Chi verifica che tutto funzioni correttamente prima di pubblicare un aggiornamento? Chi raccoglie le segnalazioni dei clienti? Come vengono gestiti i problemi? E soprattutto, l’assistenza tecnica ha realmente la possibilità di confrontarsi con chi sviluppa il prodotto?

Sono domande meno immediate rispetto a quelle che facciamo durante una demo, ma possono aiutarci a capire molto del fornitore che stiamo scegliendo.

Perché un software non è soltanto il programma che utilizziamo ogni giorno. È anche il risultato del lavoro di un’organizzazione fatta di persone, competenze, processi e responsabilità.

Il software che acquistiamo è solo una parte del prodotto

Proviamo a fare un esempio.

Immaginiamo di aver acquistato un Channel Manager. Il prodotto ci piace, è semplice da utilizzare, ha tutte le integrazioni che ci servono e, almeno durante la dimostrazione, sembra funzionare perfettamente.

Dopo qualche settimana iniziano però a manifestarsi alcuni problemi. Una sincronizzazione non va a buon fine, una funzionalità non si comporta come dovrebbe oppure un’integrazione presenta delle anomalie.

A questo punto entra in gioco la software house.

Ed è proprio qui che possiamo iniziare a capire se abbiamo scelto soltanto un buon prodotto oppure anche un buon fornitore.

L’assistenza raccoglie la segnalazione? Riesce a comprenderne la natura? Il problema viene analizzato da personale competente? Se necessario, viene coinvolto il reparto sviluppo? Il cliente viene aggiornato sull’avanzamento dell’intervento?

Non sono dettagli secondari.

Un problema tecnico può capitare anche alle aziende più organizzate. La differenza sta anche nella capacità di individuarlo, gestirlo, risolverlo e, quando possibile, evitare che si ripresenti.

Tutto parte dalla direzione aziendale

Potrebbe sembrare strano, ma la qualità del software riguarda anche il lavoro del CEO.

Non perché debba conoscere ogni riga di codice o intervenire direttamente sulle attività dei programmatori, ma perché è la direzione aziendale a stabilire priorità, investimenti, obiettivi e modalità di gestione dell’impresa.

Pensiamo a una software house che decide di concentrare quasi tutte le proprie risorse commerciali sull’acquisizione di nuovi clienti.

Non c’è nulla di sbagliato nel voler crescere, naturalmente. Ma se contemporaneamente non vengono destinate risorse adeguate allo sviluppo, alla manutenzione del prodotto e all’assistenza, potrebbero crearsi degli squilibri.

Il risultato potrebbe essere un’azienda molto efficace nel vendere, ma meno efficace nel gestire le esigenze dei clienti già acquisiti.

Da albergatori dovremmo ricordarci che il rapporto con il fornitore non termina quando firmiamo il contratto o quando viene completata l’installazione.

Inizia, semmai, proprio in quel momento.

Chi decide cosa deve fare il software?

Un altro aspetto importante riguarda il Product Management, ovvero la gestione e l’evoluzione del prodotto.

Un software destinato agli hotel dovrebbe evolversi tenendo conto delle esigenze reali di chi lo utilizza.

Ma chi raccoglie queste esigenze? Chi stabilisce quali richieste hanno una reale utilità? Chi decide quali problemi devono essere affrontati prima e quali funzionalità possono aspettare?

Non tutte le richieste dei clienti devono necessariamente trasformarsi in nuove funzionalità. Sarebbe impossibile e, probabilmente, anche controproducente.

Serve qualcuno che sappia analizzare le esigenze, individuare le priorità e trasformarle in indicazioni chiare per il reparto sviluppo.

Facciamo un esempio.

Un albergatore chiede una nuova funzionalità per migliorare la gestione delle prenotazioni provenienti da un determinato canale.

La richiesta può sembrare semplice, ma per svilupparla correttamente bisogna comprenderne il contesto, valutare le implicazioni sulle funzionalità esistenti e verificare che la modifica non crei problemi in altre parti del sistema.

Senza un processo strutturato, si rischia di aggiungere continuamente funzionalità senza avere una reale visione dell’evoluzione del prodotto.

E un software con tante funzionalità non è necessariamente un software migliore.

Sviluppatori e controllo qualità: non basta scrivere codice

Naturalmente, il reparto sviluppo ha una responsabilità fondamentale.

Ma anche in questo caso, non possiamo limitarci a valutare la bravura dei programmatori.

La qualità di un prodotto software dipende anche da come viene progettato, sviluppato, verificato e mantenuto.

Esistono procedure e strumenti specifici per gestire il codice, controllare le modifiche, effettuare test e verificare che una nuova versione non comprometta funzionalità che prima funzionavano correttamente.

Pensiamo a un aggiornamento di un PMS.

La nuova versione introduce una funzionalità interessante, ma modifica anche alcune procedure di gestione delle prenotazioni.

Se non vengono effettuati test adeguati, potrebbero emergere problemi che coinvolgono attività già consolidate nell’operatività dell’hotel.

Ecco perché il controllo qualità non dovrebbe essere considerato un passaggio burocratico prima della pubblicazione di un aggiornamento.

È una parte integrante dello sviluppo del prodotto.

L’assistenza tecnica: il reparto che ci fa conoscere davvero il fornitore

Arriviamo probabilmente all’aspetto che interessa maggiormente a chi lavora in hotel.

L’assistenza tecnica.

Chiunque abbia utilizzato un software alberghiero conosce la differenza tra un servizio di assistenza che prende in carico un problema e uno che si limita a registrare una segnalazione.

Non sono la stessa cosa.

Un buon servizio di assistenza dovrebbe essere in grado di comprendere il problema, raccogliere le informazioni necessarie, individuare le eventuali cause e coinvolgere le competenze tecniche appropriate.

Ma c’è un altro aspetto fondamentale: il collegamento con il reparto sviluppo.

Immaginiamo che dieci hotel segnalino, in momenti diversi, un problema simile.

Se queste segnalazioni rimangono isolate all’interno del reparto assistenza, l’azienda rischia di perdere informazioni preziose.

Se invece vengono analizzate, aggregate e condivise con chi si occupa del prodotto, possono contribuire a individuare un problema ricorrente e a correggerne la causa.

L’assistenza, quindi, non dovrebbe essere soltanto il reparto che risponde alle telefonate dei clienti.

Dovrebbe essere anche una fonte importante di informazioni per migliorare il software.

E questo richiede organizzazione, procedure e comunicazione tra reparti.

Quando qualcosa non funziona, l’azienda deve imparare dall’errore

C’è una differenza importante tra risolvere un problema e impedire che si ripresenti.

Nel primo caso interveniamo sull’anomalia che ha coinvolto il cliente.

Nel secondo analizziamo cosa è successo, perché è successo e quali modifiche possono ridurre il rischio che accada nuovamente.

È un principio utilizzato anche nelle organizzazioni che gestiscono servizi tecnologici complessi.

Google, ad esempio, descrive nei propri documenti SRE il metodo dei cosiddetti postmortem: analizzare gli incidenti, individuare le cause e definire azioni correttive senza limitarsi ad attribuire responsabilità alle singole persone.

Il concetto è semplice: un problema dovrebbe diventare un’occasione per migliorare il sistema, non soltanto un’attività da chiudere nel gestionale dell’assistenza.

Per noi albergatori questo significa una cosa molto concreta: non dovremmo limitarci a chiedere quanto tempo impiega un fornitore a risolvere un problema. Dovremmo anche capire se l’azienda lavora per evitare che lo stesso problema si ripresenti.

Come possiamo valutare l’organizzazione di una software house?

Naturalmente, non possiamo entrare negli uffici del fornitore e verificare direttamente come lavorano i suoi dipendenti.

Possiamo però porre alcune domande durante la selezione e osservare come si comporta l’azienda nel rapporto quotidiano.

Ad esempio:

• Esiste un reparto dedicato alla gestione e all’evoluzione del prodotto?
• Come vengono raccolte e valutate le richieste dei clienti?
• Prima di pubblicare un aggiornamento vengono effettuati test?
• Come vengono comunicate le anomalie che possono coinvolgere gli utilizzatori?
• L’assistenza tecnica può coinvolgere direttamente gli sviluppatori?
• Esiste un sistema di tracciamento delle segnalazioni?
• I problemi ricorrenti vengono analizzati per individuarne le cause?
• Sono disponibili informazioni sui livelli di servizio dell’assistenza?
• L’azienda pubblica documentazione e aggiornamenti del prodotto?
• Esiste una procedura per gestire gli incidenti che compromettono il funzionamento del servizio?

Non è necessario che ogni software house abbia reparti enormi e decine di dipendenti.

Una piccola azienda può essere organizzata molto bene, così come una grande azienda può avere problemi di comunicazione e coordinamento.

Non è il numero di persone a determinare automaticamente la qualità dell’organizzazione.

Sono importanti le competenze presenti, la chiarezza delle responsabilità e la capacità di far collaborare le diverse funzioni.

Non acquistiamo soltanto un software. Scegliamo un partner tecnologico.

Quando scegliamo un PMS, un RMS, un CRM o un Channel Manager, tendiamo a concentrarci su quello che il prodotto può fare oggi.

È comprensibile, perché dobbiamo risolvere esigenze operative concrete.

Ma dovremmo dedicare un po’ di attenzione anche a quello che potrebbe succedere domani.

Il software verrà aggiornato? Le integrazioni continueranno a essere mantenute? Le nuove esigenze del mercato verranno prese in considerazione? In caso di problemi, troveremo un’organizzazione capace di gestirli?

Non possiamo avere la certezza che un fornitore non commetta mai errori. Nessuna software house può garantircelo.

Possiamo però cercare di capire se esistono le condizioni organizzative per sviluppare, mantenere e migliorare il prodotto nel tempo.

La qualità di un software non si misura soltanto durante una dimostrazione commerciale. Si misura anche nei mesi e negli anni successivi, quando quel programma entra davvero nei processi quotidiani dell’hotel.

La prossima volta che dovrai scegliere un software per la tua struttura, non limitarti a chiedere cosa sa fare. Cerca di capire anche come lavora l’azienda che lo ha realizzato.

Perché il software lo utilizzerai tu, ma per farlo funzionare, evolvere e migliorare avrai bisogno anche delle persone che ci sono dietro.