Nella sesta parte abbiamo visto perché i progetti ERP falliscono: un processo non definito, un responsabile assente, dati sporchi, un avvio affrettato e un team non preparato al cambiamento. Ora trasformiamo quelle lezioni in un piano di esecuzione. Scegliere il sistema è una decisione di un giorno; implementarlo è un progetto di mesi, ed è lì che si decide davvero il risultato. In questa settima parte percorriamo in ordine le fasi dell'implementazione: dall'analisi iniziale e dal blueprint dei processi alla migrazione dei dati, ai test, al go-live e all'hypercare, poi il lato umano, dove si arena la maggior parte dei progetti.

Analisi iniziale e blueprint dei processi: disegnare prima di costruire

Un'implementazione di successo inizia con una fase di analisi iniziale, non con un'installazione. Ci si siede con ogni reparto e si mappa come lavora davvero oggi — non come dovrebbe lavorare sulla carta — e poi si concorda l'unico modo in cui il sistema gestirà ciascun processo. Il risultato di questa fase è un solo documento: il blueprint dei processi, che definisce ogni processo, chi ne è responsabile e dove inizia e finisce.

Questo blueprint è la costituzione del progetto. Ogni controversia si risolve tornando a esso, e ogni personalizzazione viene valutata rispetto a esso. I progetti che saltano l'analisi iniziale e passano direttamente allo schermo scoprono le lacune dopo il go-live, quando correggerle costa molte volte di più.

Migrazione dei dati: pulire prima di spostare

I vostri vecchi dati vivono in fogli di calcolo e sistemi sparsi, accumulati nel corso degli anni, e sono la cosa più pericolosa da portare nel nuovo sistema. Una migrazione di successo è una fase a sé stante, non un copia e incolla:

  • Pulire prima di spostare: nomi duplicati, saldi che non quadrano, articoli senza categoria. Puliteli alla fonte prima che entrino nel sistema, perché i dati sporchi che entrano in un sistema pulito restano sporchi e minano la fiducia nei numeri fin dal primo giorno.
  • Mappare e verificare: fate corrispondere i campi del vecchio sistema a quelli del nuovo, migrate prima un lotto di prova, poi controllate che saldi e totali quadrino con la fonte prima di farci affidamento.
  • Lo storico da portare con sé: decidete cosa migrare e cosa archiviare. Non ogni vecchio record merita di appesantire il nuovo sistema.

La regola: prima pulire, poi migrare, infine verificare. Questo ordine fa la differenza tra un sistema che parte con fiducia e uno che parte con dubbi.

Test e collaudo prima del go-live

Prima che qualcuno usi il sistema nel lavoro reale, questo deve superare un test con i vostri dati, non con i dati dimostrativi del fornitore. Si costruiscono scenari a partire dalla vostra attività reale — una fattura completa, un ciclo di acquisto, una chiusura di fine mese — e li si esegue nel sistema per verificare che produca il risultato corretto.

Poi arriva il test di collaudo: il vostro team esegue le operazioni che svolgerà ogni giorno e attesta per iscritto che funzionano come devono. Il collaudo non è una formalità; è l'ultima occasione per individuare una lacuna prima che diventi una crisi davanti a un cliente reale.

Go-live e hypercare: graduale, non un salto

Al go-live si affrontano due decisioni:

  • Per fasi o big-bang: un avvio big-bang accende tutto in un solo giorno, moltiplicando il rischio e trasformando qualsiasi errore in una crisi per tutta l'azienda. Un rilascio per fasi — un modulo o una filiale alla volta — contiene l'errore e costruisce fiducia passo dopo passo. Nella maggior parte dei casi procedere per fasi è più sicuro; il salto unico è adatto solo alle piccole imprese con operazioni semplici.
  • Hypercare: le prime settimane dopo il go-live sono la fase più delicata. Mantenete un supporto intensivo vicino al team per intercettare gli errori e rispondere subito alle domande, finché il sistema non si stabilizza e le persone si fidano di esso. Il go-live non è il traguardo, ma l'inizio della fase più sensibile.

Il lato umano: responsabile, sponsorizzazione e cambiamento

È qui che si arena la maggior parte dei progetti, non nella tecnologia. L'implementazione ha bisogno di tre pilastri umani: un unico responsabile interno con autorità e tempo dedicato, che guidi il progetto dalla vostra parte, e non un dipendente a cui il progetto viene aggiunto come attività marginale; una sponsorizzazione del vertice che dia al progetto una priorità reale e decida ciò che attraversa più reparti; e una gestione del cambiamento consapevole che prepari il team prima del go-live, non dopo.

Gestire il cambiamento significa coinvolgere presto le persone, perché si sentano parte della decisione e non sue vittime, spiegare perché cambiamo e non solo come, e rendere la formazione continua anziché un evento unico. Un sistema che le persone adottano ha successo anche se è più semplice; uno imposto incontra una resistenza silenziosa anche se è più potente.

La visione di Origami

Siamo un'azienda tecnologica, ma per noi l'implementazione è un progetto organizzato, non l'installazione di un software. Iniziamo con l'analisi iniziale e il blueprint dei processi prima di toccare uno schermo, trattiamo la migrazione dei dati come una fase che pulisce e verifica invece di copiare, insistiamo su un collaudo firmato dal vostro team e avviamo per fasi con un hypercare ravvicinato. E rendiamo il responsabile interno, la sponsorizzazione del vertice e la gestione del cambiamento parte del piano fin dal primo giorno. Il nostro obiettivo è un sistema che viva dopo il go-live, non uno che funzioni il giorno della consegna e venga poi abbandonato.

Conclusione

Un'implementazione ERP di successo non è un evento ma un progetto per fasi: un'analisi iniziale che mappa i processi, una migrazione che pulisce prima di spostare, un collaudo firmato da chi userà il sistema, un go-live per fasi seguito da hypercare e, sopra tutto, un responsabile presente, una sponsorizzazione del vertice e un team preparato al cambiamento. Chi percorre queste fasi in ordine gestisce un sistema che vive; chi le salta gestisce una crisi rimandata. E in tutte queste fasi c'è una condizione che in Arabia Saudita non si può rimandare: la conformità normativa. Nell'ottava parte vedremo cosa pretendere da qualsiasi sistema prima di firmare — fatturazione elettronica, IVA e localizzazione araba completa — come requisiti imprescindibili, non come componenti aggiuntivi.

Fonti

  • Autorità per la Zakat, le Imposte e le Dogane (ZATCA) — La fatturazione elettronica (Fatoora) come obbligo da considerare nei test e nel go-live: https://zatca.gov.sa
  • Autorità Saudita per i Dati e l'Intelligenza Artificiale (SDAIA) — la Legge sulla protezione dei dati personali (PDPL) e i controlli sui dati durante la migrazione: https://sdaia.gov.sa
  • Saudi Vision 2030 — trasformazione digitale e sostegno alle piccole e medie imprese: https://www.vision2030.gov.sa