Migrare verso un nuovo ERP: ripresa dei dati e calendario nelle PMI svizzere

Ripresa dei dati: il vero punto di rottura di una migrazione ERP nelle PMI

Il software è la parte visibile del progetto. Due cause fanno deragliare una migrazione ERP nelle PMI: dati trasferiti troppo in fretta e un calendario fissato in base alla scadenza di un contratto di manutenzione, non alla maturità dei dati.

Il contesto: le PMI della Svizzera romanda con alcune decine o centinaia di collaboratori, uno o due siti, una gestione amministrativa e logistica integrata. Due fili conduttori: il perimetro della ripresa dei dati e la sequenza delle tappe fondamentali.

Quattro decisioni condizionano il successo. Innanzitutto l’elenco delle famiglie di dati da riprendere e il criterio che li rende idonei al passaggio. Poi il backup testato prima di qualsiasi operazione e i nomi delle persone che convalidano saldi e storici.

Cosa osserva la ricerca svizzera sulle migrazioni ERP

Alcuni lavori di master del laboratorio BISA (Business Information Systems and Architecture) dell’Università di Losanna documentano questi cantieri. Elena Martinez Ferradal vi studia, per NTT DATA, le barriere all’adozione del passaggio da un ERP di terza a quarta generazione, durante una migrazione verso SAP S/4HANA.

Vincent Nieto (Breitling) ha esaminato la preparazione e le difficoltà dell’integrazione tra PLM ed ERP nell’industria orologiera svizzera. Sophie Kern, dal punto di vista della consulenza presso KPMG, analizza il ruolo dell’architettura aziendale nella trasformazione digitale dell’orologeria di lusso.

Su un altro fronte, Valerie Estelle Tsague Mbialeu (Migros) descrive l’allineamento tra architettura business e architettura applicativa ottenuto tramite la modellazione dei flussi. David Hornung (G+F Châtelain) affronta la trasformazione della produzione orologiera svizzera attraverso i dati.

Una migrazione ERP si conduce come un cantiere di architettura e flussi, non come un’esportazione-importazione di file. Cambiare generazione di ERP implica gestire le barriere all’adozione, documentate dal caso di migrazione verso SAP S/4HANA.

Delimitare, pulire e solo poi trasferire

L’inventario inizia con quattro famiglie. I dati di base coprono articoli, ubicazioni, scorte; le controparti, clienti e fornitori. Gli storici coprono ordini, fatture, scritture contabili. I documenti o gli allegati formano la quarta famiglia.

Per ogni famiglia, una decisione scritta: ripresa così com’è, correzione prima del trasferimento, archiviazione fuori dall’ERP in sola lettura o abbandono. Senza di essa, il dubbio si risolve nel pieno del passaggio, quando nessuno ha più tempo per arbitrare.

L’individuazione dei duplicati, delle unità incoerenti e dei riferimenti obsoleti avviene prima del passaggio. Questa pulizia pesa spesso di più, in termini di carico di lavoro, rispetto al trasferimento tecnico stesso.

Per gli storici, la questione è sapere quanti esercizi finanziari riprendere. Riprendere solo i dati aperti — saldi, ordini in corso, fatture non saldate — e archiviare il resto alleggerisce i test e le correzioni.

Gli allegati richiedono un trattamento particolare: volumetria, formati eterogenei, collegamenti con i record. Un caricamento di prova su un campione dà un’idea del volume da immagazzinare prima di avviare la ripresa completa.

La rete di sicurezza: backup e ritorno allo stato precedente

La regola detta 3-2-1 rimane il riferimento: tre copie dei dati, su due supporti diversi, di cui una copia off-site. La sua applicazione concreta dipende dall’infrastruttura esistente.

Su server locale, si declina così: produzione, backup locale su NAS o server dedicato per un ripristino rapido. Poi una copia in un cloud svizzero per resistere a un sinistro.

In Microsoft 365, la situazione cambia. Microsoft garantisce la disponibilità del servizio, non il recupero dei file eliminati o corrotti: questa responsabilità resta all’azienda. Gli strumenti di backup cloud lavorano quindi da cloud a cloud, senza copia locale su NAS.

Per Pascal Rajower, ingegnere di sistema presso Infologo, un backup non testato non è un backup. Gli audit rivelano regolarmente configurazioni corrette che non ripristinano più come previsto.

Il divario tra backup dichiarato e backup utilizzabile è frequente. Secondo l’esperienza di Infologo presso oltre 100 PMI ginevrine e vodesi, sette aziende su dieci presentano lacune critiche nei loro backup.

Una PMI di 50 persone del Canton Vaud dispone di un NAS locale da 6 TB accoppiato a una replica Acronis nel cloud. In caso di guasto del server, il ripristino completo ha richiesto 45 minuti; senza questo dispositivo, avrebbe perso almeno una giornata di lavoro.

Finché nessun ripristino è stato verificato sull’ambiente di test, la ripresa non è pronta. Il ritorno allo stato precedente si prepara prima del passaggio, non dopo l’incidente.

Rischi identificati nei backup delle PMI svizzere

Un calendario per tappe, non per settimane promesse

La sequenza tipo si articola in otto tappe: definizione e perimetro, prima ripresa a vuoto, correzioni, seconda ripresa, formazione, doppio esercizio, passaggio, stabilizzazione. Ciascuna si chiude su un criterio osservabile, non su una durata teorica.

La definizione si conclude quando l’elenco delle famiglie di dati da riprendere e il nome del responsabile di ogni ambito sono stabiliti. È anche il momento di congelare ciò che non verrà ripreso.

La prima ripresa a vuoto è terminata quando l’intero set di dati è caricato nell’ambiente di test. I conteggi e i saldi devono corrispondere alla fonte. Le correzioni avvengono nel sistema di origine, poi vengono riesportate. Correggere solo il file di estrazione lascerebbe la fonte errata.

La seconda ripresa porta lo stesso set di dati e serve a verificare che le discrepanze siano nulle o giustificate. La formazione si conclude quando gli utenti chiave eseguono le loro operazioni correnti sul set di test senza assistenza.

Il doppio esercizio fa funzionare i due sistemi per un periodo definito e confronta i risultati. Il passaggio si avvia solo con un backup della fonte verificato e una procedura di ritorno allo stato precedente scritta.

La stabilizzazione copre la chiusura di un primo ciclo completo e il trattamento delle discrepanze residue. Il dimensionamento dell’insieme segue la dimensione e i vincoli dell’azienda, non un modello standard copiato.

Il percorso critico non è tecnico: qualità dei dati di base, disponibilità degli utenti chiave, arbitrati sul perimetro. Sono queste tre voci a slittare un calendario.

Riprese a vuoto e formazione: ciò che si gioca fuori dal software

La convalida spetta alle funzioni aziendali. I futuri utenti verificano saldi, storici e casi limite — ordini parziali, note di credito, scorte negative, scritture di apertura — sul set di test, prima del passaggio definitivo.

Il servizio IT non può convalidare da solo una migrazione. Non conosce né le tolleranze della contabilità, né le abitudini del servizio commerciale o della produzione.

La formazione fa parte del calendario, con un criterio di uscita: gli utenti chiave eseguono i loro compiti quotidiani senza assistenza. L’obiettivo è uno strumento produttivo fin dai primi giorni, e non dopo diverse settimane di apprendimento.

Le resistenze pesano spesso più degli ostacoli tecnici. Tre leve concrete: nominare un referente per servizio, spiegare cosa cambia nelle attività quotidiane, raccogliere i punti di irritazione durante il doppio esercizio per trattarli prima del passaggio.

Chi pilota, chi accompagna

Tre ruoli interni bastano a strutturare il progetto. Il comitato di pilotaggio decide il perimetro e il budget. Il proprietario dei dati garantisce le regole di codifica e la qualità. Gli utenti chiave testano, formano e segnalano le discrepanze.

Gli arbitrati sul perimetro si decidono in base a due criteri: l’impatto business di una famiglia di dati e il costo della sua ripresa. Una decisione di abbandono o archiviazione viene documentata, per non essere riaperta nel pieno del passaggio.

L’ecosistema si legge nelle fiere informatiche svizzere. Camptocamp SA, attiva nei servizi open source dal 2001 con uffici in Svizzera, Francia e Germania, figura tra gli espositori del settore ERP, accanto a dimostrazioni di Odoo Open Source ERP.

Altri stand vertono sulla sovranità dei dati. dotBase vi tiene una conferenza sulla ripresa del controllo dei propri dati, presentata come un’alternativa sovrana a Salesforce, HubSpot e Microsoft.

Domande da porre a un partner o a un editore: dove sono ospitati i dati? Quali condizioni di reversibilità e di uscita dal contratto, e in quale formato e entro quale termine i dati vengono restituiti? Il modello di licenza è per organizzazione o per utente? Le esigenze locali di protezione dei dati sono trattate e quale label di qualità software si applica?

Un esempio di risposta leggibile viene da Nexellerator. L’editore annuncia opzioni di licenza basate sull’organizzazione, senza licenza per utente né percentuale sulle transazioni. Le sue soluzioni sono preparate per il RGPD e la nLPD svizzera. I suoi pacchetti portano il label «swiss made software».

Dopo il passaggio: mantenere i dati puliti

Il giorno dopo il passaggio, il progetto cambia natura ma non si ferma. Un monitoraggio regolare della qualità dei dati — duplicati, riferimenti incompleti, unità incoerenti — evita che le discrepanze si propaghino al reporting.

Alcuni dashboard bastano all’inizio. Volumetria dei dati di base, tasso di errori di inserimento, articoli o controparti creati fuori procedura.

Lavori di master condotti al laboratorio BISA dell’Università di Losanna mostrano questo tipo di dispositivo in pratica. Anika Haque ha lavorato, presso la Centrale di compensazione della Confederazione Svizzera, all’implementazione di dashboard utilizzabili e pertinenti per il team di controlling IT.

Maxime Bayle ha trattato, presso Lonza, la messa a disposizione di informazioni sulla qualità dei dati di riferimento. Esse sono leggibili da utenti tecnici e non tecnici.

Punti di revisione periodici riuniscono il proprietario dei dati e i servizi interessati. Permettono di correggere una regola di codifica o di completare un repertorio prima che l’errore contamini le decisioni.

Il valore di un ERP si costruisce nei mesi successivi alla messa in servizio. Regole di codifica aggiustate, dati mancanti completati, dashboard ricalcolati su cifre affidabili.