L'implementazione di un software MES fallisce quasi sempre per la stessa ragione, e non è la tecnologia. Il progetto viene avviato senza che nessuno abbia verificato la qualità dei dati esistenti, senza che il perimetro sia stato scritto e senza che il cliente sappia, prima di firmare, quali risultati misurabili definiranno il successo. Dopo sei mesi il sistema è installato, funzionante ma il reparto lo subisce o peggio lo aggira e la direzione considera l'investimento di scarsa qualità o addirittura risorse perdute sotto il peso di decine di motivazioni spesso di basso impatto.
Il metodo di implementazione del software MES adottato da Heuris nasce per evitare questa dinamica. Si articola in cinque passi, ciascuno con un esito verificabile, e prevede che il cliente resti libero di fermarsi fino alla chiusura del project charter. In questa pagina trovi che cosa accade in ogni fase, quali documenti vengono prodotti, quali prerequisiti servono e che cosa succede se il proof of concept non dà l'esito sperato.
Indice della pagina
- Perché i progetti MES falliscono, (quasi mai per il software)
- Il metodo Heuris in cinque passi
- Primo passo, l'assessment della fabbrica e dei dati
- Secondo passo, la definizione dei bisogni e dei vincoli reali
- Terzo passo, il project charter che tutela l'investimento
- Quarto passo, l'offerta master non vincolante
- Quinto passo, il proof of concept sui dati reali
- Quanto costa un proof of concept e come viene scomputato
- Un secondo proof of concept dedicato alla schedulazione
- Che cosa succede se il proof of concept non è positivo
- I prerequisiti che l'azienda deve avere
- Chi partecipa al progetto dalla parte del cliente
- Quanto dura l'implementazione di un software MES
- Da dove si comincia
Perché i progetti MES falliscono, (quasi mai per il software)
Nella nostra esperienza di installazioni industriali, le cause che ci hanno portato a sostituire dei sistemi fallimentari sono raggruppabili in tre macrotipologie e nessuna riguarda le funzionalità del prodotto.
La prima è l'assenza di dati affidabili di partenza, poiché anagrafiche incomplete, cicli mai aggiornati e tempi standard inventati rendono imprecisa qualunque elaborazione successiva.
La seconda è il perimetro implicito, ovvero ciò che il cliente dà per compreso e il fornitore del software dà per escluso, che emerge puntualmente a metà progetto sotto forma di contestazione.
La terza è la resistenza al cambiamento del reparto, che non si vince con la formazione ma con il coinvolgimento di chi oggi decide a mente le priorità.
Un'azienda che sostituisce un MES esistente parte avvantaggiata, perché possiede già la cultura del dato raccolto in tempo reale. Un'azienda che non ne ha mai avuto uno deve mettere in conto almeno sei mesi di maturazione organizzativa, e preferiamo dirlo prima anziché dopo: chi non è disposto a investire quel tempo otterrà un sistema formalmente installato e sostanzialmente inutilizzato.
Il metodo Heuris in cinque passi
Il percorso di implementazione del software MES Heuris è costruito in modo che il rischio cresca soltanto dopo che l'incertezza è stata ridotta. Nei primi due passi si misura la realtà aziendale, nel terzo si scrive che cosa significa avere successo, nel quarto si quantifica l'orizzonte completo dell'investimento e soltanto nel quinto si costruisce qualcosa di funzionante, su dati veri e su un perimetro ristretto.
Primo passo, l'assessment della fabbrica e dei dati
L'assessment è una ricognizione condotta in stabilimento, non un questionario. Si osserva come circolano oggi le informazioni fra ufficio e reparto, si verifica quali dati esistano davvero e in quale stato, si misura la distanza fra i tempi dichiarati a sistema e quelli osservati sulle macchine, si individuano i punti in cui la sequenza viene decisa a mano e da chi.
L'esito è una fotografia franca, che comprende anche ciò che non funziona. Capita che l'assessment si concluda con la raccomandazione di rimandare il progetto e di sistemare prima le anagrafiche o i cicli di lavorazione, ed è un esito legittimo: un progetto MES avviato su dati inattendibili produce soltanto una versione informatizzata del disordine esistente. In questa fase si valuta anche quale sia il modulo da cui conviene partire, che nella maggior parte dei casi è la raccolta dati dal campo, poiché alimenta tutto il resto.
Secondo passo, la definizione dei bisogni e dei vincoli reali
I bisogni dichiarati in prima battuta raramente coincidono con quelli effettivi. Un'azienda chiede il controllo dell'avanzamento e in realtà ha un problema di ritardi originato dalla sequenza, un'altra chiede il calcolo dell'indice OEE e scopre che senza causali di fermo attendibili quel numero non le direbbe nulla.
In questa fase si traducono le esigenze in requisiti verificabili e si mappano i vincoli industriali che il sistema dovrà rispettare, dagli stampi al personale qualificato, dalle sequenze obbligate alle finestre di manutenzione. Si stabilisce inoltre il confine con i sistemi esistenti, in particolare con il gestionale, poiché l'integrazione con l'ERP determina quali dati restino di competenza dell'uno e quali dell'altro.
Terzo passo, il project charter che tutela l'investimento
Il project charter è il documento che distingue questo metodo da una fornitura ordinaria. Viene redatto prima di qualunque impegno economico rilevante e contiene l'ambito del progetto, le esclusioni esplicite di perimetro, la matrice dei rischi con probabilità e gravità, i criteri di successo misurabili e i fattori determinanti da cui dipende l'esito di tutto il prototipo.
Il punto decisivo non è la forma del documento, bensì il fatto che i criteri di successo siano scritti prima e siano verificabili da chiunque, cliente compreso. Quando il progetto arriva alla verifica finale non c'è spazio per interpretazioni, perché la definizione di riuscita è stata concordata quando ancora nessuna delle due parti sapeva come sarebbe andata. Il Project charter è un documento riservato e non viene pubblicato, ma la sua struttura è esattamente quella appena descritta e viene condivisa con il cliente fin dal primo incontro.
Fino alla chiusura del charter il cliente non è vincolato ad alcuna prosecuzione. È il momento in cui l'azienda dispone di tutte le informazioni necessarie a decidere e non ha ancora speso quasi nulla.
Quarto passo, l'offerta master non vincolante
L'offerta master descrive l'orizzonte completo dell'intervento, modulo per modulo, con il perimetro funzionale, le integrazioni previste, i rilasci e la valorizzazione economica dell'insieme. Non è vincolante e non chiede una firma ma serve a mostrare fin da subito dove si arriverà, perché nessuno dovrebbe avviare un progetto industriale conoscendo soltanto il costo del primo passo.
Da questa offerta discende il documento POC (proof of concept), che ne costituisce un estratto ristretto e che la richiama esplicitamente. Il cliente si trova così davanti a due documenti coerenti fra loro, uno che delimita la prova e uno che descrive la destinazione, e può valutare l'intero percorso prima di impegnare risorse significative.
Quinto passo, il proof of concept sui dati reali
Il proof of concept è un prototipo funzionante costruito sui dati veri dell'azienda, non una dimostrazione su archivio campione. Si sceglie un perimetro ristretto, tipicamente una linea o un reparto, si collegano le macchine e i terminali di reparto, si integra il gestionale ERP (per le anagrafiche gli Ordini di produzione gli impianti etc), si acquisiscono avanzamenti e causali di fermo, si verifica lo scambio di informazioni con il gestionale e si misurano i risultati rispetto ai criteri fissati nel project charter.
Il valore della prova sta nel fatto che il reparto tocca il sistema mentre lo si costruisce. Le obiezioni emergono in quelle settimane, quando correggerle costa poco, anziché al collaudo finale, quando costa molto. Al termine si sarà quindi certi che il modello funziona in quella fabbrica, si conosce la qualità effettiva dei dati e si è individuato chi, all'interno dell'organizzazione, sarà in grado di governare il sistema.
Quanto costa un proof of concept e come viene scomputato
Il proof of concept viene valorizzato in giornate di sviluppo, non a corpo. Nella configurazione tipica si tratta di una ventina di giornate di lavoro, riconosciute ad un costo essenziale, alle quali si aggiungono i soli costi vivi di trasferta. È una valorizzazione volutamente contenuta rispetto all'impegno effettivo, poiché la prova serve a decidere la bontà del software e soprattutto del fornitore.
In caso di prosecuzione l'importo del proof of concept viene decurtato dal prezzo dell'offerta master, quindi il cliente non paga due volte la stessa attività. Va detto con chiarezza che il progetto completo si colloca su un ordine di grandezza di decine di migliai di euro, e che proprio la prova POC serve a stabilirne il perimetro con cognizione di causa anziché per stime e offerte demandate a commerciali senza scrupoli.
Un secondo proof of concept dedicato alla schedulazione
Il proof of concept iniziale si concentra sulla raccolta dati e sulle integrazioni, che sono le fondamenta di ogni sistema. Introdurre subito la schedulazione euristica lo renderebbe più complesso, poiché richiede cicli e tempi già attendibili, che nella maggior parte delle aziende esistono solo dopo qualche mese di raccolta.
Sono percorribili quindi due strade. La prima consiste nell'includere nella prova iniziale alcune metriche di schedulazione a titolo dimostrativo, sufficienti a far vedere il meccanismo senza pretendere di mandarlo in produzione. La seconda, che nella maggior parte dei casi preferiamo, prevede un secondo proof of concept dedicato, condotto a valle del successo del primo e costruito con alcune euristiche essenziali: bastano una manciata di pesi ben scelti per dimostrare la bontà del modello su una sequenza reale, e da lì estenderla progressivamente.
Che cosa succede se il proof of concept non è positivo
Può accadere, e il metodo lo prevede. Se i criteri di successo scritti nel charter non vengono raggiunti, il cliente perde soltanto il costo contenuto del proof of concept, mentre l'impegno reale sostenuto per costruirlo resta a carico di Heuris. La garanzia di svincolo vale in ogni momento del percorso.
Questa asimmetria è voluta e ha una conseguenza pratica che invitiamo a considerare: un fornitore che accetta di misurarsi su criteri concordati in anticipo, con la possibilità di non proseguire, ha interesse a dire subito ciò che deve essere migliorato. La tutela della bontà del progetto deve essere massima, e la relazione di partnership che nascerà tra cliente e fornitore del MES ne deve essere la garanzia di successo.
I prerequisiti che l'azienda deve avere
Sul piano dei dati servono anagrafiche articoli coerenti, cicli di lavorazione aggiornati e una definizione condivisa delle causali di fermo. Non è necessario che siano perfetti all'avvio, ma occorre che qualcuno in azienda se ne assuma la responsabilità, perché nessun software può sostituirsi a quella funzione.
Sul piano tecnico l'infrastruttura resta a carico del cliente e comprende un server Windows adeguatamente dimensionato, con base dati MS SQL Server, un accesso remoto sicuro per le attività di sviluppo e assistenza, e i terminali di reparto, siano essi pannelli touch o tablet, insieme ai lettori di codice a barre dove previsti. L'hardware potrebbe anche non essere compreso nella fornitura, e specificarlo prima evita l'equivoco più frequente in fase di avviamento.
Chi partecipa al progetto dalla parte del cliente
Un progetto MES coinvolge almeno quattro figure, e la loro assenza è un segnale di rischio più grave di qualunque limite tecnico. Serve un referente di direzione che possa decidere sulle priorità, un responsabile di produzione che conosca i vincoli reali del reparto, un referente dei sistemi informativi per le integrazioni e le infrastrutture, e soprattutto la persona che oggi stabilisce a mente o su altri strumenti informatici la sequenza delle lavorazioni.
Quest'ultima figura è la più delicata e spesso la più trascurata. La sua conoscenza va incorporata nel sistema, non scavalcata, e il proof of concept è il momento in cui questo trasferimento comincia. Quando quella persona lascerà l'azienda, l'esperienza resterà nei parametri anziché uscire dal cancello con lei.
Quanto dura l'implementazione di un software MES
La durata dell'implementazione di un software MES dipende in modo determinante dalla situazione di partenza. Un'azienda che sostituisce un sistema esistente può completare il proof of concept nell'ordine di un paio di mesi, poiché la cultura del dato è già presente e le anagrafiche sono in genere già utilizzabili.
Un'azienda alla prima esperienza deve invece mettere in conto un orizzonte più lungo, con almeno sei mesi di maturazione organizzativa prima che i dati raccolti diventino affidabili. In quel periodo si affrontano la diffidenza del personale, le dimenticanze nelle registrazioni, l'uso poco confidente dei terminali e la tentazione di tornare al foglio di carta. Chi dichiara tempi molto più brevi, semplicemente, non ha considerato questa fase.
Da dove si comincia
Il primo passo è un incontro gratuito, nel quale esaminiamo insieme la situazione della tua produzione e i dati di cui disponi oggi. Al termine sapremo dire, con la stessa franchezza usata in questa pagina, se conviene procedere con un assessment strutturato oppure se è preferibile attendere.
Nel frattempo puoi approfondire il funzionamento del software MES, il ruolo dei sistemi MES e MOM, il motore della schedulazione euristica, i KPI aziendali che il sistema rende disponibili, e i progetti già realizzati nelle case history del settore automotive, dello stampaggio plastica e dell'industria alimentare.
