Migrazione ERP al cloud: cosa verificare prima del passaggio

La migrazione di un ERP al cloud può cambiare manutenzione, disponibilità e modalità di accesso. Non corregge da sola anagrafiche duplicate o procedure incoerenti. Prima di scegliere una data, chiarisci se stai spostando il software esistente, cambiando prodotto oppure riprogettando anche il modo di lavorare.

Non trattare il server locale come un problema per definizione e il cloud come una garanzia. Verifica backup, ripristino e responsabilità in entrambi i casi. Un servizio ospitato da un fornitore richiede comunque accessi corretti, configurazione e un piano per continuare il lavoro durante un’interruzione.

Spostare un gestionale su una macchina ospitata, adottare un ERP in abbonamento e sostituire il modello operativo non sono la stessa decisione. Nel primo caso potresti conservare interfaccia, personalizzazioni e problemi dei dati. Nel secondo cambiano anche condizioni di aggiornamento e possibilità di intervento. Nel terzo stai chiedendo all’organizzazione di ridefinire responsabilità e procedure.

Scrivi quale risultato giustifica il progetto. Se il problema è che il commerciale non vede la disponibilità, verifica prima se manca una sincronizzazione. Se ogni chiusura richiede riconciliazioni manuali tra tre sistemi incompatibili, il perimetro potrebbe essere più ampio. “Andare in cloud” descrive una destinazione tecnica, non il beneficio che permette di scegliere tra queste alternative.

Chiedi al fornitore una lista delle personalizzazioni attuali: mantenere, sostituire con una funzione standard, eliminare oppure ricostruire. Una funzione usata da poche persone può essere decisiva per una commessa rara ma importante. Al contrario, una personalizzazione costosa può esistere soltanto perché nessuno ha più discusso il requisito. Il criterio comprare, integrare o costruire aiuta a motivare ogni scelta.

Separare storico, anagrafiche e transazioni aperte aiuta a definire il trasferimento. Non tutti i dati devono entrare nello stesso modo nel nuovo sistema. Lo storico può richiedere consultazione e conservazione secondo le regole applicabili, mentre ordini e partite aperte devono sostenere il lavoro dal primo giorno.

Assegna la validazione a chi conosce il significato dei dati. Un totale di righe corretto non prova che fornitori, unità di misura e saldi siano stati associati bene. Controlla campioni e riconciliazioni concordate, conservando le anomalie e la decisione presa su ciascuna.

Consideriamo un esempio ipotetico: un ordine di 100 pezzi ha già avuto una consegna di 60. Restano 40 pezzi da evadere, un acconto da riconoscere e una promessa di consegna al cliente. Importare l’ordine originale come interamente aperto può creare una seconda spedizione di merce già consegnata. Importare solo la quantità residua può perdere il legame con la prima consegna e con l’acconto.

La prova deve quindi ricostruire ordine, righe, movimenti, documenti e riferimenti secondo il modello del sistema di destinazione. Non esiste un unico file corretto per tutti gli ERP. Serve una decisione sul significato di ogni stato, confermata da chi deve usarlo. Controlla anche le unità di misura: un numero può essere stato trasferito perfettamente e rappresentare scatole dove il nuovo sistema si aspetta pezzi.

Se un codice viene accorpato, conserva la tabella delle corrispondenze e la ragione della modifica. Rendila utilizzabile anche dall’assistenza: chi riceve una contestazione tre settimane dopo deve poter risalire al riferimento precedente. Nei contesti di filiera questo aspetto è particolarmente importante, come mostra la lettura dei passaggi di informazione nel distretto tessile.

Un ERP può essere accessibile e avere dati corretti, mentre il negozio online continua a inviare gli ordini alla vecchia destinazione. Elenca ogni collegamento: origine, destinazione, informazione scambiata, frequenza e responsabile. Includi esportazioni manuali e file programmati, che spesso non compaiono nei diagrammi del fornitore.

Prova una sequenza completa su dati fittizi: ricezione dell’ordine, aggiornamento della disponibilità, consegna e ritorno dello stato al canale iniziale. Poi interrompi una conferma e controlla cosa accade al nuovo tentativo. Il rischio non è solo perdere un messaggio: è eseguire due volte un’operazione perché la prima risposta non è arrivata. La guida a dati, permessi e regole di integrazione approfondisce questo controllo, valido anche senza AI.

Una prova di sola lettura non collauda una scrittura. Un account amministratore non dimostra che l’operatore possa lavorare con i permessi previsti. Prepara quindi ruoli realistici e chiedi ai referenti di eseguire i propri compiti, compreso un caso che deve essere bloccato.

La prova deve includere estrazione, trasferimento, validazione e riapertura del lavoro. Misura la durata con volumi rappresentativi. Prevedi come gestire le modifiche che arrivano dopo l’estrazione iniziale e chi può autorizzare un blocco temporaneo delle scritture.

Microsoft, nella propria guida al passaggio in produzione di Dynamics 365, include nel piano dati, validazione, comunicazioni e supporto. Sono elementi da verificare nel progetto effettivo, non una promessa di assenza di interruzioni. Riferimento: strategia di cutover Microsoft.

Scrivi le condizioni che fanno rinviare il passaggio. Una riconciliazione fallita o un’operazione essenziale non provata valgono più della pressione a rispettare una data scelta troppo presto.

La decisione finale deve collegare prove e autorità. Il tecnico conferma l’esecuzione delle attività; l’amministrazione approva le riconciliazioni pertinenti; operations verifica che si possano ricevere, preparare e consegnare gli ordini. Una persona incaricata dalla direzione decide se le anomalie residue sono compatibili con la riapertura. Non chiedere al solo sviluppatore di accettare un rischio commerciale al posto dell’azienda.

Un difetto grafico può attendere. Un’anomalia che cambia quantità, destinatario o importo di un documento può richiedere il rinvio. La gravità dipende dall’effetto, non da quanto sia facile correggere il codice. Per ogni eccezione accettata devono esserci una procedura temporanea, un referente e un termine di verifica.

La guida Microsoft al cutover di Dynamics 365 distingue strategia, piano, prove e passaggio al supporto. La matrice seguente è una proposta editoriale da adattare al progetto, non una certificazione di quel prodotto.

Tornare al vecchio sistema non significa semplicemente riaccenderlo. Se nel nuovo ERP sono già entrati ordini o registrazioni, devi sapere come riconciliarli. Chiedi al fornitore fino a quando il ritorno è possibile e chi autorizza il passaggio a un piano di continuità alternativo.

Durante le prime giornate rendi disponibili referenti e procedure di gestione degli errori. Non lasciare il team con una casella generica di assistenza se il contratto richiede decisioni tempestive. La disponibilità aggiuntiva va concordata e valorizzata nel preventivo.

Nelle prime settimane osserva quali operazioni tornano sui fogli personali. Non accusare subito il team di resistenza al cambiamento: potrebbe mancare una funzione necessaria, una vista utile o una regola comprensibile. Fai descrivere il caso e collegalo a un requisito. La formazione generica sul menu non risolve una consegna parziale che nessuno sa registrare.

Programma una verifica dopo un ciclo di lavoro completo, non soltanto dopo il giorno del lancio. A seconda dell’impresa può includere una chiusura, un riordino o un reso. Confronta le eccezioni con la situazione iniziale, usando definizioni coerenti. L’approccio agli obiettivi e alle conseguenze tra reparti evita di dichiarare successo perché il reparto IT ha terminato mentre l’amministrazione continua a ricostruire i dati.

Chiedi infine un’esportazione di prova e istruzioni di ripristino adeguate all’architettura scelta. Il contratto dovrebbe rendere comprensibili disponibilità dei dati, assistenza e uscita dal servizio. Verifica queste condizioni con i referenti tecnici e contrattuali: la parola cloud non le rende uguali tra fornitori.

Licenze, integrazioni, pulizia dei dati, formazione e assistenza iniziale devono comparire nel conto. Se non hai ancora scelto se sostituire tutto, usa la griglia comprare, integrare o costruire. A volte il problema riguarda un collegamento, non l’intero ERP.

Un Fractional CTO può coordinare il confronto tecnico e i fornitori nei limiti dell’incarico. La guida al preventivo CTO aiuta a distinguere direzione, esecuzione e reperibilità. Sono costi e responsabilità diversi.