Perché migrare l'ERP in cloud non risolve il tuo problema di processi

C'è una promessa che torna in ogni riunione di migrazione ERP. "Quando saremo in cloud, tutto questo diventerà più semplice." Non sarà così. Il cloud cambia dove gira il software, non come lavora la tua azienda.

Se oggi l'ordine d'acquisto passa per tre approvazioni via e-mail, un foglio Excel parallelo e una telefonata, continuerà a passare per lo stesso percorso dopo la migrazione. Solo che ora gira su server a Francoforte invece che su una macchina in cantina.

Il cloud è un luogo, non una decisione di processo

Migrare in cloud risolve problemi reali. Smetti di gestire hardware. Hai backup gestiti, scala elastica, aggiornamenti senza fermare l'operatività. Questo vale l'investimento. Ma è un problema di infrastruttura.

Il tuo problema, quasi sempre, è un altro. È il venditore che approva il credito a istinto. È il magazzino che diverge dal sistema perché nessuno registra i resi al momento giusto. È la chiusura di fine mese che richiede due settimane perché metà delle registrazioni vive in fogli sparsi.

Nessuna di queste cose migliora cambiando server. L'ERP, on-premise o cloud, è lo specchio dei tuoi processi. Se il processo è confuso, lo specchio restituisce confusione con un uptime migliore.

L'errore del rilevamento "as-is" pigro

La migrazione tipica parte da un rilevamento dei processi attuali. L'obiettivo dichiarato è "replicare ciò che abbiamo già". È qui che il progetto muore prima di iniziare.

Replicare ciò che hai già significa codificare decenni di eccezioni, scorciatoie e "si è sempre fatto così" dentro un sistema nuovo e costoso. Il risultato è un Frankenstein personalizzato che poi nessuno riesce ad aggiornare.

Il caso Lidl è l'esempio pubblico più citato. Il retailer ha lavorato per anni a un nuovo sistema di gestione del magazzino basato su SAP. Il progetto è stato cancellato nel 2018 dopo centinaia di milioni investiti. Uno dei motivi riportati: Lidl ha insistito per adattare il software al proprio modello di inventario a costo d'acquisto, invece di adattare il processo allo standard. Il software si è piegato fino a spezzarsi.

Vent'anni prima, Hershey ha preso la strada opposta ed è fallita per la fretta. Ha messo in produzione ERP, CRM e gestione della catena di fornitura tutti insieme, proprio prima di Halloween, senza tempo per stabilizzare i processi. Non è riuscita a spedire ordini che aveva già a magazzino. La migrazione era tecnicamente fatta; l'operatività si è bloccata lo stesso.

Cosa devi fare prima di toccare il cloud

L'ordine giusto è scomodo perché all'inizio è più lento. Prima capisci i processi. Poi decidi quali valgono la pena, quali tagli e quali allinei allo standard del software. Solo allora migri.

• Mappa i processi reali, non quelli scritti nel manuale. Il processo reale è quello che le persone fanno alle 17 di un venerdì con un cliente arrabbiato al telefono.
• Per ogni eccezione personalizzata, chiediti il perché. Metà delle volte la risposta è una regola di cui ormai nessuno ha bisogno.
• Decidi cosa allinei allo standard. La personalizzazione costosa di oggi è debito tecnico che domani ti lega a un fornitore.
• Pulisci i dati prima di migrare. Dati sporchi su un sistema nuovo restano dati sporchi, punto.
• Definisci chi è il proprietario di ogni processo. Senza un proprietario, nessuno difende il cambiamento quando il team resiste.

La resistenza interna è il vero progetto

La parte tecnica di una migrazione è la più prevedibile. API, integrazioni, finestre di cutover: tutto questo ha i suoi manuali. Quello che non ha manuale sono le persone che hanno svolto il vecchio processo per quindici anni e lo conoscono meglio di qualsiasi consulente.

Gli studi classici sulla gestione del cambiamento sono coerenti su questo punto. La maggior parte dei programmi di trasformazione non fallisce per la tecnologia. Fallisce per esecuzione, allineamento e adesione delle persone. La HBR lo riassume bene nel lavoro di Sirkin, Keenan e Jackson sui fattori duri del cambiamento.

Immagina lo scenario tipico: il responsabile di magazzino riceve un sistema nuovo che lo obbliga a registrare ogni movimento sul momento, invece che a fine turno. Per lui il nuovo sistema è più lavoro, non meno. Se non gli mostri il perché e non adatti il processo alla realtà del piano di lavoro, torna al foglio Excel parallelo. E il tuo ERP in cloud diventa un archivio morto e costoso.

E allora il cloud, vale la pena?

Vale. Ma per i motivi giusti. Migra in cloud per smettere di gestire l'infrastruttura, per avere elasticità e per integrarti più facilmente con il resto del tuo stack digitale. Non migrare aspettandoti che il cambio di server riorganizzi la tua operatività.

La sequenza che funziona è semplice da dire e dura da fare. Sistema il processo. Pulisci i dati. Allinea le persone. Poi accendi il cloud. Chi inverte questo ordine paga due volte: una nella migrazione e una per disfare la migrazione.

Il software buono non aggiusta un'operatività cattiva. La rende solo più veloce a spezzarsi. La domanda giusta non è mai stata "cloud o on-premise". Era "i nostri processi meritano di essere automatizzati così come sono?". Nella maggior parte dei casi la risposta onesta è no, ed è lì che il progetto inizia davvero.