Come preparare la tua organizzazione a un progetto EAM

La maggior parte dei progetti EAM che finiscono male non fallisce durante l’implementazione. Fallisce perché è partita prima che l’organizzazione fosse davvero pronta a partire.

Il kickoff è un momento simbolico: sale riunioni, slide, entusiasmo. Ma il lavoro che determina l’esito del progetto è in larga parte quello fatto nelle settimane precedenti — e non riguarda il software. Riguarda i tuoi dati, i tuoi processi e le tue persone.

Ecco cosa conviene avere in ordine prima del giorno uno.

La gerarchia degli asset è la decisione che condiziona tutto il resto

Prima ancora di configurare qualsiasi cosa, devi sapere come intendi strutturare i tuoi asset: quanti livelli, secondo che logica, con quali criteri di raggruppamento. È una decisione apparentemente tecnica che in realtà è organizzativa, perché la gerarchia determina come leggerai i costi, come aggregherai gli indicatori e a che livello di dettaglio potrai fare analisi.

Cambiarla dopo il go-live è possibile, ma costoso: significa rimappare ordini di lavoro, ricalcolare storici e riscrivere report. Vale la pena spendere qualche settimana in più prima, discutendone con chi la manutenzione la fa davvero, piuttosto che accorgersi a sei mesi dall’avvio che la struttura non risponde alle domande che il management pone.

Guarda in faccia la qualità dei tuoi dati

Ogni organizzazione pensa che le proprie anagrafiche siano “abbastanza a posto”. Quasi nessuna lo è. Codici ricambio duplicati, fornitori censiti tre volte con ragioni sociali leggermente diverse, descrizioni asset scritte da persone diverse in dieci anni diversi, campi obbligatori compilati con “N/A” pur di andare avanti.

Un progetto EAM non ripulisce i dati per magia: li trasferisce. Se entrano sporchi, escono sporchi — e il sistema nuovo si guadagna in fretta la reputazione di essere inaffidabile, quando il problema era a monte.

Fai un’estrazione reale delle anagrafiche principali e guardala con onestà prima del kickoff. Non serve che tutto sia perfetto, serve sapere dove sei messo male, quanto lavoro di bonifica ti aspetta e chi lo farà. È una delle poche attività che puoi tranquillamente avviare mesi prima, senza dipendere dal fornitore.

Decidi ora quanto storico ti porti dietro

La tentazione è portare tutto. Vent’anni di ordini di lavoro, tutte le letture contatore, ogni movimento di magazzino. Sembra prudente, ma raramente lo è: la migrazione dello storico è una delle voci di costo e di rischio più sottovalutate di un’implementazione, e buona parte di quei dati non verrà mai consultata.

Chiediti a cosa ti serve davvero quello storico. Se ti serve per l’analisi dei guasti, potrebbero bastare tre anni. Se ti serve per obblighi normativi o certificazioni, il perimetro è definito dalla norma, non dal desiderio. Se ti serve “per sicurezza”, probabilmente non ti serve, e puoi lasciarlo consultabile nel sistema legacy in sola lettura.

È una decisione che la direzione deve prendere esplicitamente, non che deve emergere per default a metà progetto.

Stabilisci chi decide, prima che ci sia qualcosa da decidere

Durante un’implementazione emergono decine di scelte che non hanno una risposta tecnica: quale workflow di approvazione adottare, chi può chiudere un ordine di lavoro, quali campi rendere obbligatori, come gestire le eccezioni. Ognuna di queste tocca equilibri tra manutenzione, produzione, acquisti e amministrazione.

Se non è chiaro in partenza chi ha l’ultima parola, ogni scelta diventa una trattativa e il progetto rallenta. Peggio: si arriva a compromessi che non soddisfano nessuno e che poi nessuno difende in fase di adozione.

Definisci prima del kickoff un referente di progetto con mandato reale e un piccolo comitato decisionale che si riunisce con cadenza fissa. “Reale” significa che quella persona può decidere senza dover ogni volta risalire la catena.

Le persone giuste devono essere davvero disponibili

Questo è il punto dove si inceppano più progetti di quanto si ammetta. I key user vengono nominati, il loro nome finisce su una slide, e poi restano al cento per cento sul lavoro ordinario. Il risultato è che le sessioni di design si fanno con chi è libero, non con chi sa.

Se il tuo miglior pianificatore della manutenzione è la persona più indicata per il progetto, è anche la persona di cui l’officina non può fare a meno. Non c’è una scorciatoia: o si libera tempo in modo formale e sostituibile, o si accetta che il sistema venga disegnato su una conoscenza parziale dei processi.

Quantificare questo impegno prima — giornate, periodi, persone — e metterlo a budget è parte della preparazione tanto quanto la bonifica dei dati.

Non automatizzare processi che sai già essere rotti

Un progetto EAM è una delle rare occasioni in cui un’organizzazione si ferma a guardare come lavora davvero. Se sai che il tuo ciclo di approvazione delle richieste d’acquisto è farraginoso, o che le segnalazioni di guasto arrivano su tre canali diversi, il momento di intervenire è adesso.

Trasferire un processo disfunzionale dentro un sistema nuovo lo rende più rigido, non migliore: quello che prima si aggirava con una telefonata diventa un blocco formale. E poi la colpa ricadrà sul software.

Non serve riprogettare tutto — serve individuare i due o tre punti che già oggi generano attrito e decidere consapevolmente se sistemarli prima, durante, o mai.

Prepara il terreno prima di chiedere il cambiamento

Tutto quello che precede è materiale. Ma c’è una parte che non si prepara con un file Excel, ed è il modo in cui l’organizzazione riceve la notizia.

Quando un tecnico di manutenzione sente parlare per la prima volta di un nuovo sistema, la domanda che si fa non è “che funzionalità avrà”. È: mi controlleranno di più? Dovrò compilare più moduli? Chi mi insegnerà a usarlo mentre ho comunque i miei interventi da chiudere? Se a queste domande nessuno risponde, ci rispondono loro tra di loro, e in genere nel modo peggiore.

Comunicare presto, in modo concreto e senza retorica, cosa cambierà e cosa no è un investimento a costo quasi nullo che riduce moltissimo l’attrito successivo. Lo stesso vale per il coinvolgimento: chi ha partecipato a una sessione di design difende il sistema, chi l’ha subito lo critica.

Prepararsi non significa rimandare

C’è un rischio opposto, ed è quello di usare la preparazione come alibi per non partire mai: un altro giro di analisi, un’altra bonifica, un altro allineamento. La preparazione ha senso finché è finita nel tempo e ha obiettivi verificabili.

Il criterio pratico è semplice: sei pronto quando sai com’è strutturato il tuo parco asset, sai in che stato sono i tuoi dati e chi li sistemerà, sai chi decide, e le persone chiave hanno tempo assegnato. Non serve altro per partire bene.

Se invece sei ancora a monte di questa fase e devi capire su quale piattaforma puntare, il punto di partenza è un altro: come scegliere il sistema EAM giusto per la tua organizzazione.

Stai valutando l’avvio di un progetto EAM e vuoi capire quanto è pronta la tua organizzazione? Contattaci — possiamo aiutarti a fare il punto prima di partire.