Cosa aspettarsi nei primi mesi dopo l’adozione di una nuova piattaforma

Nei primi mesi dopo l’adozione di una nuova piattaforma aziendale si decide se l’investimento genera valore o resta un costo sommerso

Il 70% dei progetti di trasformazione organizzativa non raggiunge gli obiettivi previsti, e la causa principale non è quasi mai la tecnologia scelta. Lo documenta una ricerca McKinsey ormai citata in modo sistematico nella letteratura manageriale, che attribuisce il fallimento soprattutto alla resistenza dei dipendenti e alla mancanza di supporto del management nella fase successiva all’implementazione. È un dato che dovrebbe far riflettere chiunque stia valutando o abbia appena avviato l’adozione di una nuova piattaforma gestionale: il rischio più concreto non si annida nella selezione del fornitore o nella fase di setup tecnico, ma nei mesi che seguono, quando il software è già acceso e l’organizzazione deve imparare a viverci dentro.

Questo articolo si rivolge a chi quella decisione l’ha presa o la sta per prendere e prova a rispondere a una domanda che raramente trova spazio nelle presentazioni commerciali: cosa succede davvero, nell’azienda, nei primi tre-sei mesi dopo l’adozione di una nuova piattaforma.

Il divario tra chi adotta e chi adotta bene

In Italia il tema non è più l’accesso alla tecnologia. Secondo i dati Eurostat sul Digital Decade, nel 2025 il 78% delle imprese italiane utilizza già almeno una tra intelligenza artificiale, servizi cloud avanzati o intermedi e strumenti di data analytics, un risultato che colloca il Paese sopra la media europea e ai vertici del continente insieme a Danimarca e Svezia per adozione del cloud.

I dati ISTAT raccontano però una seconda verità, meno raccontata: l’utilizzo di software gestionali riguarda circa il 90% delle grandi imprese ma solo il 52,7% di quelle con 10-49 addetti. Il divario non è nell’accesso alla piattaforma — quello, ormai, è alla portata di quasi chiunque — ma nella capacità organizzativa di metabolizzarla una volta installata. È esattamente il punto in cui si gioca la partita nei primi mesi post go-live.

La curva a J: il calo di produttività che nessuno racconta in fase di vendita

Chi ha già attraversato un’implementazione software sa che l’efficienza non migliora dal giorno uno. Nella maggior parte dei casi peggiora, temporaneamente, prima di superare il livello di partenza: è il fenomeno che gli analisti organizzativi chiamano curva a J, perché il grafico della produttività scende prima di risalire e stabilizzarsi su un piano più alto. Durante questa fase i processi che prima richiedevano un clic ne richiedono tre, i responsabili devono validare manualmente output che l’algoritmo dovrebbe generare in automatico, e i team più esperti, quelli che avevano ottimizzato il vecchio sistema in anni di lavoro, si trovano temporaneamente meno produttivi dei colleghi junior, semplicemente perché hanno più abitudini da disimparare.

Il problema non è la curva in sé, che è fisiologica in qualsiasi cambiamento di strumento. Il problema è quando il management non l’ha preventivata: se il board si aspetta un incremento di efficienza a trenta giorni dal go-live e osserva invece un rallentamento, la tentazione di considerare il progetto un errore , o peggio, di tornare parzialmente al vecchio sistema in parallelo, diventa concreta. E ogni ritorno al vecchio processo, anche parziale, allunga la curva invece di accorciarla.

Cosa succede davvero dentro l’organizzazione

Nei primi mesi convivono tre dinamiche che raramente vengono nominate esplicitamente nei piani di progetto, ma che determinano l’esito dell’adozione più di qualunque parametro tecnico.

La prima è la resistenza silenziosa, distinta dall’opposizione dichiarata. Un collaboratore che continua a tenere un foglio Excel parallelo alla piattaforma non sta boicottando il progetto: sta gestendo un’incertezza percepita, spesso legittima, sulla affidabilità del nuovo strumento. Ignorare questo comportamento, anziché intercettarlo e chiedersene la ragione, è l’errore più comune osservato nei progetti che non decollano.

La seconda dinamica riguarda il ruolo dei key user, le persone che l’organizzazione identifica, esplicitamente o implicitamente, come riferimento per i colleghi durante la transizione. Se questo ruolo non viene assegnato con consapevolezza, l’azienda ne ha comunque uno: sarà semplicemente la persona più esperta di scorciatoie nel vecchio sistema, che diventerà per emulazione il riferimento informale anche nel nuovo, spesso trasferendo pratiche che la nuova piattaforma dovrebbe superare.

La terza riguarda l’IT, che nella percezione diffusa gestisce l’installazione ma smette di essere protagonista una volta completato il deployment tecnico. È un errore di sequenza: l’integrazione tra sistemi, la qualità dei dati migrati e la gestione delle eccezioni che emergono con l’uso reale, non quello di test, richiedono presidio IT proprio nei mesi in cui l’attenzione organizzativa si sposta altrove.

Il fattore che statisticamente cambia l’esito

Su questo terreno, il dato più utile per chi decide non riguarda la tecnologia ma il metodo di accompagnamento al cambiamento. Secondo Prosci, autorità di riferimento nella metodologia ADKAR di change management, i progetti gestiti con un approccio strutturato al cambiamento hanno una probabilità di successo sei volte superiore rispetto a quelli lasciati alla gestione spontanea dei team.

Non è un dettaglio metodologico per specialisti delle risorse umane: è la variabile che, più di ogni altra, separa un progetto che genera ritorno da uno che resta un costo iscritto a bilancio senza benefici misurabili.

Come impostare i primi novanta giorni

Le prime settimane dopo il go-live dovrebbero essere trattate come una fase di osservazione attiva, non come un collaudo tecnico da chiudere il prima possibile. In questo periodo il compito principale del management non è misurare quanto la piattaforma fa risparmiare, ma capire dove gli utenti stanno creando eccezioni manuali, dove si formano colli di bottiglia nell’approvazione dei flussi, e quali funzionalità restano inutilizzate perché nessuno ne ha compreso il valore nella pratica quotidiana. È il momento in cui un canale di segnalazione rapido, anche informale, tra utenti e key user vale più di qualunque dashboard di adozione.

Nel mese successivo l’attenzione si sposta naturalmente sulla standardizzazione: i processi che nella prima fase venivano gestiti caso per caso devono trovare una procedura condivisa, altrimenti l’organizzazione rischia di consolidare tante piccole eccezioni individuali che, sommate, ricreano la frammentazione che la piattaforma avrebbe dovuto eliminare. È anche il periodo in cui il divario tra reparti diventa visibile: alcune funzioni aziendali assorbono lo strumento più rapidamente di altre, non per merito tecnico ma perché avevano già una cultura di processo più solida in partenza.

Solo nel terzo mese ha senso iniziare a leggere i primi indicatori quantitativi di adozione (tempo medio di completamento delle attività, percentuale di processi che passano dalla piattaforma senza deviazioni, riduzione degli errori manuali) e confrontarli non con il giorno del go-live, ma con la baseline del sistema precedente misurata su un periodo comparabile. Misurare troppo presto produce dati fuorvianti, perché fotografa l’organizzazione nel punto più basso della curva a J anziché nel suo assestamento.

Il ruolo di CEO e CFO non finisce con la firma del contratto

Per chi ha la responsabilità del budget e del risultato, la tentazione più comune è considerare conclusa la propria parte nel momento della decisione d’acquisto, delegando l’esecuzione all’IT o al fornitore. È una lettura che i dati contraddicono sistematicamente: la ricerca McKinsey citata in apertura attribuisce alla mancanza di supporto del management una quota rilevante dei fallimenti quanto la resistenza stessa dei dipendenti. Quando il vertice aziendale continua a essere visibilmente coinvolto nei primi mesi, partecipando a una revisione periodica dell’adozione, chiedendo conto degli ostacoli emersi, riconoscendo pubblicamente i primi risultati anche parziali, il segnale che arriva all’organizzazione è che il cambiamento è una priorità reale, non un progetto IT lasciato correre.

Per un CFO, in particolare, questo significa anche resistere alla tentazione di misurare il ritorno dell’investimento troppo presto, applicando alla nuova piattaforma gli stessi parametri di efficienza del sistema che ha sostituito. Il beneficio economico di una piattaforma ben adottata si manifesta tipicamente a partire dal secondo o terzo trimestre, non nel primo, e leggerlo con gli indicatori sbagliati nel momento sbagliato porta spesso a conclusioni premature su un investimento che, dati alla mano, aveva semplicemente bisogno di più tempo per essere assorbito dall’organizzazione.

Un investimento che si valuta sulla durata, non sul lancio

I primi mesi dopo l’adozione di una nuova piattaforma non sono un dettaglio operativo da lasciare all’IT: sono il periodo in cui si costruisce, o si perde, il ritorno dell’intero investimento. Le aziende che presidiano questa fase con la stessa attenzione dedicata alla selezione del fornitore ottengono risultati misurabilmente diversi da quelle che considerano il go-live come il traguardo finale del progetto.

Se la vostra organizzazione sta valutando l’adozione di una nuova piattaforma o si trova nei primi mesi successivi al lancio, confrontarsi con chi ha accompagnato altre aziende in questo passaggio può fare la differenza tra un progetto che genera valore e uno che resta sulla carta.

This post is also available in: