Introdurre un ERP in un'agenzia incoming: la gestione del cambiamento viene prima del software

In breve. In una DMC (agenzia incoming), un ERP non si impone, si fa adottare. L'adozione si regge su quattro tempi: condividere il perché, partire dai problemi reali del team, coinvolgerlo nella scelta e gestire il passaggio con dei champion interni e una data di spegnimento rispettata. Il software conta, ma è la gestione del cambiamento a decidere il risultato.

Dirigo Mexikoo, la mia DMC in Messico, da più di dieci anni, e ho fondato Odys, un software pensato per le DMC. Ho vissuto questo tema da entrambi i lati: la titolare che vuole cambiare strumento e si trova davanti un team che non ne vuole sapere, e la fornitrice che accompagna le agenzie nell'onboarding. Quello che ne ho imparato sta in una frase: cambiare ERP è un progetto di gestione del cambiamento, non un progetto informatico.

Una precisazione. In una DMC, quando dico ERP intendo lo strumento in cui vivono preventivi, prenotazioni ai fornitori, pratiche in operativo e fatturazione. Il nome sulla brochure conta poco.

Perché un team resiste a un nuovo ERP?

Perché l'essere umano preferisce ciò che conosce, anche quando l'alternativa è migliore. Nel 1988 gli economisti William Samuelson e Richard Zeckhauser gli hanno dato un nome: il bias dello status quo. Nei loro esperimenti, un'opzione diventava molto più scelta non appena veniva presentata come la situazione attuale.

In una DMC questo bias pesa ancora di più. L'ERP è la seconda mano dei tuoi operativi. Ci passano la giornata: un preventivo, una conferma d'hotel, un volo da riprogrammare, un roadbook da inviare. Cambiare strumento significa chiedere loro di tornare principianti proprio in ciò che sanno fare meglio, in piena stagione, con i viaggiatori a destinazione. Non è cattiva volontà. È un disagio reale, e va trattato come tale.

I numeri vanno nella stessa direzione. Nella ricerca Best Practices in Change Management di Prosci (oltre 2.600 professionisti intervistati), l'88% dei progetti con un'eccellente gestione del cambiamento ha raggiunto o superato gli obiettivi, contro il 13% quando era scarsa. È un dato dichiarativo e correlazionale, non una prova di causalità. Ma il divario è abbastanza netto da smettere di trattare le persone come l'ultima riga del cronoprogramma.

Perché partire dal perché, prima del software?

Perché un team che capisce dove sta andando l'azienda ti segue molto più facilmente sul come e sul cosa. Se apri con una demo, parli di schermate. Se apri con la tua visione della DMC di domani, parli del loro futuro.

In Mexikoo ho incontrato resistenza quando ho voluto introdurre nuovi strumenti. A sbloccare la situazione non è stata una demo migliore. È stato presentare più volte a tutto il team la DMC che volevo costruire: un'agenzia all'avanguardia, dove la tecnologia fa parte della cultura e non di un progetto una tantum. E soprattutto, cosa diventavano i loro ruoli in quella DMC.

È il punto che molti titolari dimenticano. Il tuo team passa gran parte del tempo sulla logistica: reinserire dati, sollecitare, verificare, ricopiare. Se lo strumento assorbe una parte di questo lavoro, la domanda legittima di ognuno è "e io cosa divento?". Rispondi prima che te la facciano. Aiuta ogni persona a immaginarsi in un ruolo che va oltre i compiti di oggi: più tempo con i viaggiatori, più progettazione del prodotto, più relazione con i partner. Un perché che non dice nulla del loro posto nel futuro resta un discorso della direzione.

Come partire dai problemi del team?

Con una domanda semplice, che chiamo la domanda della bacchetta magica: "Se avessi una bacchetta magica, cosa vorresti non dover fare mai più nella tua giornata?"

Le risposte sono concrete e spesso inaspettate: inserire la stessa pratica in tre file, sollecitare i fornitori a mano, cercare l'ultima tariffa aggiornata, rifare il roadbook da zero a ogni modifica. È la tua vera lista di criteri di selezione, molto più utile di un confronto tra funzionalità.

Il meccanismo è questo:

1. Raccogli le risposte persona per persona, non in una riunione di gruppo dove chi parla di più si prende tutto lo spazio.
2. Raggruppale in una breve lista di problemi prioritari, una decina al massimo, formulati con le loro parole.
3. Durante le demo dei fornitori, fai rimettere in scena quei problemi su casi reali della tua agenzia, idealmente dalle persone che li hanno sollevati.
4. Fai confermare al team che lo strumento risolve proprio quei problemi, e non problemi che non hanno.

Se il tuo team non sente che stai risolvendo un problema suo, non cambierà strumento. Un software che risolve i problemi del titolare ma non quelli dell'operativo viene aggirato, ed Excel rientra dalla porta di servizio.

Bisogna coinvolgere il team nella scelta del software?

Sì, e il prima possibile. Un titolare che sceglie da solo lo strumento che tutto il team userà otto ore al giorno parte con un serio handicap. Al contrario, raramente si rifiuta uno strumento che si è contribuito a scegliere.

Non è solo un'intuizione da fondatrice. Nel 1948 Lester Coch e John French studiarono i cambiamenti nei metodi di lavoro alla Harwood Manufacturing, uno stabilimento tessile in Virginia (studio originale). Il gruppo semplicemente informato del cambiamento vide la produttività scendere a circa due terzi del suo livello per un mese, con circa il 17% di dimissioni in quaranta giorni. I gruppi coinvolti nella progettazione del cambiamento recuperarono il loro livello in pochi giorni e poi lo superarono di circa il 14%, senza alcuna dimissione. Lo studio ha le sue critiche metodologiche, ma il suo insegnamento principale ha retto per decenni: la resistenza dipende molto da come il cambiamento viene introdotto.

In pratica, coinvolgi almeno una persona per ogni funzione (vendite, operativo, amministrazione) nella preselezione, nelle demo e nella scelta finale. E sii trasparente su ciò che è davvero aperto. Se budget e data di spegnimento li fissa la direzione, dillo da subito. Ciò che deve essere davvero aperto è la scelta tra le opzioni preselezionate e il modo di lavorare nello strumento. Una finta consultazione, in cui la decisione era già presa, fa più danni di nessuna consultazione.

Che ruolo hanno i champion interni nell'adozione di un ERP?

Il champion è la persona che tiene vivo lo strumento ogni giorno quando il supporto del fornitore non è disponibile in quel momento. In una piccola DMC ne basta uno. In una struttura più grande, prevedine due.

Scegli profili con una certa passione per la tecnologia, rispettati dai colleghi, e dai loro un mandato vero:

• la diffusione dello strumento inserita nelle loro mansioni e nei loro obiettivi, idealmente nel variabile;
• tempo dedicato nei primi mesi, non in aggiunta al carico abituale;
• una linea diretta con il fornitore per segnalare i blocchi.

Il loro valore sta in qualcosa che nessun supporto esterno può offrire: conoscono il tuo modo di operare. Quando un operativo si blocca su un utilizzo, il champion non dà la risposta del manuale, dà quella che funziona nella tua agenzia. È questo che evita i piccoli aggiramenti che, sommati, uccidono l'adozione.

Come gestire il passaggio dal vecchio strumento al nuovo?

Fissando una data di spegnimento e rispettandola. In Odys vedo che, nella maggior parte degli onboarding, i più rapidi sono quelli in cui il vecchio strumento si spegne: un contratto che scade, una licenza che termina. Nessuno vuole pagare due strumenti contemporaneamente, quindi tutti accelerano.

La lezione è ricreare quell'urgenza anche quando nulla ti obbliga. Il tuo vecchio strumento è gratuito, o è un Excel fatto in casa? Dagli comunque una data di spegnimento. Senza una data chiara, comunicata e condivisa con tutto il team, il passaggio non avviene mai davvero: il riflesso umano riporta sempre verso ciò che è comodo.

Ci sono due leve.

Il bastone: spegnere il vecchio strumento

Fissi una data, la annunci, e quel giorno il vecchio strumento passa in sola lettura o sparisce. Funziona ed è sano. Ma usato da solo è un metodo di costrizione, e un team costretto fa il minimo.

La carota: un premio di adozione

È il metodo che preferisco, perché rende il passaggio volontario. Crei un premio eccezionale, nel variabile o a parte, per chi ha fatto il passaggio entro una certa data.

La trappola è scegliere il criterio sbagliato. Se paghi in base al numero di pratiche create nello strumento, otterrai pratiche, non necessariamente un uso reale. È la legge di Goodhart: quando una misura diventa un obiettivo, smette di essere una buona misura. Un premio ben costruito segue tre regole:

1. Premia una quota, non un volume: il 100% dei nuovi preventivi e delle nuove pratiche in operativo creati nel nuovo strumento dalla data fissata.
2. È limitato nel tempo e annunciato come eccezionale, così non diventa un diritto acquisito.
3. Coincide con la data di spegnimento del vecchio strumento: la carota muove la maggioranza, il bastone mette al sicuro gli ultimi resistenti.

La carota allinea i pianeti. Il bastone è la rete di sicurezza. Insieme trasformano un passaggio annunciato in un passaggio reale.

I quattro tempi del passaggio, in sintesi

1. Il perché: la tua visione della DMC di domani e il posto di ognuno al suo interno.
2. Il problema: la domanda della bacchetta magica, poi demo sui loro casi reali.
3. La decisione condivisa: il team partecipa alla scelta, con regole del gioco chiare.
4. Il passaggio: champion con un mandato, una data di spegnimento rispettata e un premio legato alla quota di utilizzo.

Domande frequenti

Quanto tempo serve per far adottare un nuovo ERP a una DMC?

Dipende dal volume di pratiche e dalla dimensione del team, ma il fattore più determinante è che il vecchio strumento abbia una data di spegnimento. Senza data, l'adozione si trascina all'infinito.

Chi deve partecipare alla scelta di un software per agenzie incoming?

Almeno una persona per ogni funzione che userà lo strumento ogni giorno: vendite, operativo, amministrazione. Partecipano alle demo su casi reali dell'agenzia e confermano che lo strumento risolve i loro problemi prioritari.

Come gestire un collaboratore che rifiuta il nuovo strumento?

Parti dal capire il suo problema: un rifiuto spesso segnala un utilizzo mal coperto o la paura di perdere competenza. Affiancagli il champion interno. Se la resistenza continua oltre la data di spegnimento, la data vale per tutti, senza eccezioni.

Serve un premio per far adottare un software?

Non è obbligatorio, ma è un acceleratore efficace se ben costruito: premia la quota di nuove pratiche create nello strumento invece di un volume, è limitato nel tempo e coincide con la data di spegnimento del vecchio strumento.

Cos'è un champion interno?

Un collaboratore di riferimento per lo strumento, con una certa passione per la tecnologia, i cui obiettivi includono accompagnare i colleghi e sbloccare l'uso quotidiano in linea con il modo di operare dell'agenzia.

In una DMC, l'ERP non è un software come un altro. È lo strumento con cui il tuo team lavorerà ogni giorno, nel bene e nel male. Sceglilo insieme a loro. Il software, in fondo, è la parte facile.