Software interni

Come far adottare al tuo team un software nuovo (dopo 10 anni passati a sbagliare)

12 giugno 2026
105 min di lettura
Registro del giorno del passaggio: vecchio registro in sola lettura, 1.482 record migrati, team formato

📋TLDR

  • •L'adozione di un software è un problema di gestione del cambiamento. La maggior parte delle persone teme il cambiamento più di quanto detesti lo strumento vecchio.
  • •Il metodo classico funziona: coinvolgi le persone da subito, scegli uno strumento intuitivo, forma sui processi reali, festeggia i primi risultati.
  • •La tecnica che ha pesato di più in 10 anni di software interni: eliminare il sistema vecchio, così il nuovo diventa l'unico modo di lavorare.
  • •Il passaggio obbligato funziona solo se lo strumento nuovo è davvero pronto, il supporto c'è e la direzione tiene la linea.
  • •Quando ogni processo passa da un solo sistema, arriva il premio vero: l'automazione.

"Diamogli ancora un paio di settimane di transizione." Se l'hai mai detto durante il lancio di un software, sai già come va a finire: quelle due settimane diventano due mesi e lo strumento nuovo non decolla mai del tutto. Ho passato circa dieci anni come responsabile IT a costruire software interni, e quella frase — detta con le migliori intenzioni — è stata dietro alla maggior parte dei miei lanci andati male.

La risposta breve

Come fai ad adottare un software nuovo con tutto il team? Coinvolgi le persone da subito, scegli uno strumento intuitivo, forma sui processi reali e festeggia i primi risultati. È la risposta da manuale, e non è sbagliata. L'adozione è un problema di gestione del cambiamento tanto quanto di strumenti.

Ma il manuale, da solo, non è mai bastato. Quello che ha funzionato davvero era più semplice e parecchio più scomodo:

Abbiamo eliminato il sistema vecchio.

Ogni volta che introducevamo un software nuovo o cambiavamo un processo, toglievamo di mezzo il modo vecchio di lavorare. Bloccavamo il foglio di calcolo, disattivavamo il vecchio modulo. Le persone brontolavano per un paio di settimane, poi adottavano. E una volta che ogni processo passava dallo strumento nuovo, abbiamo potuto finalmente automatizzare una quantità enorme di lavoro manuale, perché l'unico modo di eseguire il processo passava da un software che controllavamo noi.

Parto dal manuale classico, perché serve comunque. Poi entro nella tecnica del passaggio obbligato, compreso come metterla in pratica senza farti odiare dal tuo team.

Perché i team resistono ai software nuovi

Non è quasi mai il software.

Il segnale. In dieci anni passati a introdurre software interni in azienda, non ho quasi mai incontrato una persona che contestasse uno strumento nuovo per i suoi meriti tecnici. Quello che ho trovato, una volta dopo l'altra, era semplice paura del cambiamento.

La causa. Il vecchio foglio di calcolo sarà pure lento e tenuto insieme a copia-incolla, ma è loro. Sanno dov'è ogni cosa, ci vanno veloci. Uno strumento nuovo, anche se palesemente migliore, per un paio di settimane li fa sentire lenti e incapaci, e nessuno si offre volontario per quella sensazione. La stima più citata di McKinsey dice che circa il 70% dei programmi di cambiamento non raggiunge i propri obiettivi, e il colpevole di sempre è la resistenza di chi quel cambiamento deve viverlo. Ogni indagine sul lavoro che ho letto di recente racconta una versione della stessa cosa: le persone si sentono già sommerse di strumenti e danno per scontato che ognuno in più significhi altro lavoro per loro.

La soluzione non sta nel software: sta nel trattare il lancio per quello che è davvero, cioè un progetto di gestione del cambiamento che per caso riguarda la tecnologia. Tutto quello che segue discende da qui.

Il manuale classico (parti da qui)

Il consiglio standard è standard perché funziona. Saltalo, e nessun trucco sul passaggio obbligato ti salverà.

1. Coinvolgi il team da subito

Chi vivrà dentro lo strumento tutti i giorni deve contribuire a dargli forma. Porta due o tre delle persone che lo useranno di più dentro al processo di costruzione, mostra loro i prototipi, lascia che rompano qualcosa. Chi ha aiutato a dare forma a uno strumento poi lo difende, ed è la stessa persona che finisce per insegnarlo a tutti gli altri.

Qui sta anche il vantaggio di costruirsi i software interni invece di comprare un pacchetto già fatto. Quando qualcuno chiede una modifica e la vede rilasciata nella stessa settimana, inizia a sentire che lo strumento è suo. Un fornitore che risponde "è in roadmap" ottiene esattamente l'effetto opposto.

2. Scegli uno strumento intuitivo

Ogni clic in più ti costa adozione. Se serve un manuale per l'attività quotidiana più elementare, il lancio è già in difficoltà. Il mio metro era sempre lo stesso: una persona nuova completa il processo principale al primo tentativo, senza aiuto. Se non ci riesce, sistema lo strumento prima di sistemare la formazione.

3. Forma sui processi reali, non sulle funzionalità

A nessuno interessa un giro guidato nella pagina delle impostazioni. Forma ogni team sul lavoro che fa davvero: "ecco come registri un reclamo di un cliente", "ecco come approvi un ordine d'acquisto". Con dati veri e casi limite veri. Una sessione di 30 minuti costruita sul martedì tipo di una persona vale più di due ore passate a mostrare ogni funzione del sistema.

4. Festeggia i primi risultati

Trova il primo momento in cui lo strumento nuovo ha chiaramente battuto il modo vecchio: il report che richiedeva quattro ore e ora ne richiede dieci minuti, quel genere di cose. Raccontalo a tutti e fai i nomi delle persone coinvolte. I primi risultati danno agli indecisi la prova che muoversi è sicuro, e danno alla direzione un motivo per continuare a sostenere il progetto.

La tecnica che ha funzionato davvero: eliminare il sistema vecchio

Dieci anni di lanci mi hanno insegnato una cosa scomoda: puoi fare bene tutti e quattro i passaggi qui sopra e vedere comunque morire il lancio. Per un motivo solo.

Il segnale. Ogni volta che lanciavamo uno strumento nuovo accanto a quello vecchio "durante un periodo di transizione", succedeva sempre la stessa cosa: l'utilizzo saliva la prima settimana, poi rifluiva dritto nel vecchio foglio di calcolo.

La causa. Finché il modo vecchio esiste, le persone continueranno a usare il modo vecchio. Il periodo di transizione non finisce mai da solo. L'adozione facoltativa è, in sostanza, un "no" che ci mette più tempo ad arrivare.

La soluzione è stata smettere di tenere due sistemi in parallelo. Il giorno del passaggio, il vecchio foglio di calcolo andava in sola lettura e il vecchio modulo veniva disattivato. Il software nuovo diventava l'unico modo di portare a casa il lavoro.

E ogni volta che l'abbiamo fatto è successa la stessa cosa: il dibattito sul se cambiare o no semplicemente finiva, e quell'energia andava dritta a imparare lo strumento nuovo. Le due settimane scomode finivano per davvero, perché tutto il team le attraversava insieme invece di rimandarle all'infinito. I problemi veri emergevano nel giro di giorni, visto che li incontravano tutti nello stesso momento, e li risolvevamo mentre l'attenzione era ancora alta. E finalmente tutti i dati stavano in un posto solo.

È il principio di bruciare le navi applicato al software da ufficio. Si racconta che Cortés affondò le sue navi perché la ritirata non fosse più un'opzione. Non serve niente di così drammatico: mettere un foglio di calcolo in sola lettura basta e avanza.

Il dividendo dell'automazione

Questa è la parte che quasi tutti gli articoli sull'adozione saltano, e per noi è stata di gran lunga la ricompensa più grande.

Quando l'unico modo di eseguire un processo passava dal software nuovo, ogni passaggio di quel processo diventava visibile a un sistema — il che voleva dire che potevamo finalmente automatizzarlo. Le approvazioni hanno iniziato a instradarsi da sole. I report settimanali hanno smesso di essere il venerdì pomeriggio di qualcuno. Niente di tutto questo era stato possibile prima, perché metà di ogni processo viveva sparsa tra caselle di posta e fogli di calcolo personali che nessun sistema poteva vedere.

L'adozione non è mai stata l'obiettivo finale, per noi. Era il prerequisito. Il vero guadagno arriva dopo, quando l'intero processo sta dentro un sistema che controlli davvero.

Come gestire un passaggio obbligato senza logorare il team

Sia chiaro: eliminare il sistema vecchio non è una scusa per saltare il lavoro di gestione del cambiamento. Anzi, alza la posta, quindi la preparazione deve essere migliore, non peggiore. Questo è il manuale a cui siamo arrivati dopo averlo sbagliato qualche volta.

  1. Non togliere niente finché lo strumento nuovo non è davvero pronto. Un passaggio obbligato verso qualcosa di incompleto brucia una fiducia che non si recupera facilmente. Il processo principale deve essere solido e testato con utenti veri prima di bloccare qualsiasi cosa.
  2. Annuncia la data con settimane di anticipo, e ripetila. "Il giorno 15 il vecchio registro passa in sola lettura." Nessuna sorpresa. È la sorpresa che le persone temono; una data è qualcosa per cui possono prepararsi.
  3. Migra i dati tu. Non chiedere mai alle persone di spostare i propri record. Se il loro storico è già nel sistema nuovo il primo giorno, hai tolto di mezzo l'obiezione razionale più grande.
  4. Blocca il sistema vecchio, non cancellarlo. Le persone si tranquillizzano sapendo che non si perde niente, e intanto tu conservi una traccia verificabile.
  5. Rinforza il supporto nella prima settimana. Orari di sportello, un canale di chat dedicato, qualcuno che gira fisicamente tra le scrivanie. Gran parte della resistenza si scioglie quando l'aiuto arriva in meno di cinque minuti.
  6. Tieni la linea. Qualcuno chiederà "solo un'eccezione". Quella prima eccezione diventa il nuovo sistema vecchio. La risposta dev'essere un no gentile ma fermo, più una soluzione concreta per il problema reale che ha fatto nascere la richiesta.
  7. Risolvi in fretta e in modo visibile quello che le persone segnalano. La prima settimana di un passaggio porta una valanga di feedback sincero. Rilasciare correzioni nel giro di giorni è ciò che convince gli scettici.

Dove si inserisce AgentUI

Un passaggio obbligato funziona solo se lo strumento nuovo è davvero migliore, e se riesci a migliorarlo alla stessa velocità con cui arriva il feedback. Questa è la parte difficile — ed è esattamente il punto in cui entra AgentUI.

Con AgentUI i team di business costruiscono software interni su misura con l'AI: una prima versione funzionante in circa 30 minuti, poi la affini man mano che le persone reagiscono. Quella velocità cambia tutta la matematica dell'adozione: quando qualcuno segnala una mancanza lunedì e la vede risolta mercoledì, lo strumento si guadagna la fiducia più in fretta di qualsiasi sessione di formazione. AgentUI include anche un onboarding personalizzato fin dal primo giorno — un team di persone vere che ti aiuta a pianificare il lancio e a migrare i dati, così il peso del cambiamento non ricade solo su di te.

Centralizzare i processi su un'unica piattaforma è anche ciò che fa arrivare il dividendo dell'automazione. Quando il lavoro passa da un solo sistema governato invece che da fogli di calcolo sparsi, le parti ripetitive si possono finalmente automatizzare.

Domande frequenti

Obbligare le persone a cambiare non fa male al clima aziendale?

Per come l'ho vissuta, un'ambiguità senza fine pesa sul clima più di un passaggio netto con una data chiara. Quello che danneggia davvero il clima è essere costretti su uno strumento che non funziona, senza supporto e senza voce in capitolo. Se lo strumento è pronto, il supporto c'è e il feedback porta visibilmente a correzioni, la maggior parte dei team prova sollievo: la decisione è stata presa e ci si è mossi tutti insieme.

E se il mio team davvero non riesce a lavorare con lo strumento nuovo?

Allora hai fatto il passaggio troppo presto. Ripristina l'accesso, colma le lacune insieme agli utenti pilota e fissa una nuova data. La tecnica è "elimina il sistema vecchio quando il nuovo è pronto", non "elimina il sistema vecchio e spera bene".

Per quanto tempo devono convivere sistema vecchio e nuovo?

Giorni, se riesci. Usa una finestra parallela breve solo per validare i dati, dalle una data di fine annunciata pubblicamente e rispettala. Un periodo parallelo che diventa comodo tende a diventare permanente.

Come capisco se l'adozione ha funzionato davvero?

Guarda tre cose: l'utilizzo attivo (tutte le persone previste entrano nello strumento ogni settimana?), il completamento dei processi (il lavoro ci passa dall'inizio alla fine?) e i sistemi ombra (stanno rispuntando in silenzio nuovi fogli di calcolo?). Quest'ultimo è il campanello d'allarme che quasi tutti i team si dimenticano di controllare.

In quanto tempo posso costruire un gestionale su misura per cui valga la pena cambiare?

Con AgentUI una prima versione funzionante richiede di solito circa 30 minuti, e un software interno pronto per la produzione circa una settimana. Ci sono inclusi i cicli di iterazione con gli utenti pilota che rendono possibile un passaggio fatto con fiducia.


Vuoi costruire un gestionale su misura che il tuo team userà davvero e mandare finalmente in pensione il foglio di calcolo?

Prova AgentUI gratis: crea il tuo primo software su misura in pochi minuti.

Pronto a creare i tuoi gestionali?

Prova AgentUI gratis e crea il tuo primo gestionale in pochi minuti.