Incipit: Perché il “tabellone dei progressi” sul muro dell’officina è sempre due giorni in anticipo rispetto al sistema
Entrando in una fabbrica di lavorazione meccanica, sulla parete della sala riunioni campeggia una lavagna su cui sono apposte note adesive colorate; su ciascuna è scritto il numero dell’ordine di lavoro, la fase del turno e il numero del macchinario. Ogni sera il responsabile di turno deve sostituire le note. La mattina seguente, il capo viene in officina e chiede: “Il lotto di ieri è stato consegnato tutto?” Il capo reparto estrae la lavagna e, socchiudendo gli occhi, conta le note.
Nella stessa fabbrica, spesso coesistono due tipi di “progresso”: uno rappresentato dalla lavagna e dalle note adesive, l’altro dallo stato degli ordini nel sistema ERP o MES. Il primo riflette la realtà sul posto, il secondo è un dato destinato alla contabilità e ai clienti. È normale che i due non coincidano; quando invece lo fanno, diventa notizia.
Questo non è un caso isolato. Nelle officine che abbiamo visitato, da piccole botteghe con una dozzina di persone fino a grandi stabilimenti di assemblaggio con migliaia di dipendenti, si riscontrano problemi analoghi:
- La pianificazione produttiva non arriva alle postazioni di lavoro: il pianificatore inserisce 30 ordini nel sistema, ma in officina se ne vedono solo 8; gli altri restano “appesi nel sistema”.
- Il progresso si conosce solo chiedendo: il coordinatore effettua decine di telefonate al giorno per sapere “a che punto è questo lavoro”, mentre il capoturno non riesce nemmeno a ricordare a quale fase siano giunti alcuni processi.
- I tempi di lavoro non corrispondono all’effettivo: il registratore dei tempi compila un modulo ogni 4 ore, ma poco prima della fine del turno aggiunge tutti i dati insieme, con differenze tra i numeri e i ritmi reali che vanno dal 20% al 40%.
- Le anomalie passano inosservate: in una determinata fase, dopo tre giorni di attesa per un materiale, nessuno se ne accorge; solo quando il cliente sollecita la consegna ci si rende conto che manca un componente.
Il problema non sta nel fatto che qualche software non venga utilizzato, bensì nel collegamento interrotto tra il “campo” e il “sistema”. La lavagna sul muro è più veritiera dell’ERP perché è posizionata accanto ai macchinari ed è gestita direttamente da chi vede la situazione sul posto; l’ERP, invece, spesso prevede tre livelli intermedi: dal capoturno al caporeparto fino al coordinatore, e a ogni passaggio i dati vengono nuovamente trascritti, con il rischio di ritardi o errori ad ogni step.
Di seguito analizzeremo come progettare e implementare questo sistema, affinché la lavagna sul muro possa gradualmente svuotarsi.

01 Come suddividere le attività: spezzettare il “progresso” nelle azioni più piccole e raccoglibili
Molti progetti, fin dall’inizio, trattano la voce “stato della fase” come un unico campo. In realtà, lo “stato della fase” è una condizione complessa: in quale postazione si trova l’ordine di lavoro; chi lo sta eseguendo; quanto è già stato completato; quanti tempi di lavoro sono stati impiegati; se la qualità è conforme; se i materiali sono disponibili. Ognuna di queste sei dimensioni va rilevata separatamente, senza confonderle in un unico dato.
Ecco come procedere alla suddivisione:
- Postazione di lavoro: ogni macchina o postazione ha un numero univoco; tramite scansione del codice o carta magnetica è possibile identificare “qual è il lavoro in corso su questa macchina”.
- Operatore: ogni fase di avvio, trasferimento e conclusione di un ordine è associata a un numero di matricola. Anche nei casi di collaborazione tra maestro e apprendista, è il capo operatore l’unico a tenere traccia.
- Quantità completata: le fasi prevedono controllo iniziale, ispezione durante il processo e conteggio finale. La quantità non è uno stato; deve essere aggiornata premendo un pulsante o scansionando un codice.
- Tempi di lavoro effettivi: la differenza tra l’ora di inizio e quella di fine (rilevata automaticamente), sommata alle pause intermedie (registrate manualmente per motivi anomali).
- Stato della qualità: tre registri — controllo iniziale, ispezione e controllo finale — con flussi separati per qualificato, rilavorazione e scarto; non è consentito indicare solo il tasso di conformità.
- Materiali completi: ogni componente elencato nella BOM è classificato in tre stati — completo, incompleto o mancante — e questi stati sono collegati allo stato dell’ordine.
Suddividiamo queste sei dimensioni in singoli “flussi di eventi”, anziché in un unico campo di stato. Gli eventi costituiscono una cronologia dettagliata: chi, quando, su quale macchina, a che punto si è arrivati e quali anomalie sono emerse. Lo stato è una visione derivata dai flussi di eventi; i campi di stato non devono essere compilati manualmente.
02 Come progettare: definire chiaramente ruoli, processi, dati e limiti dell’interfaccia
L’errore più comune nella fase di progettazione è “realizzare un’app per far compilare i dati”; dopo due anni di funzionamento, l’app mostra solo la schermata di accesso e una pagina vuota con il campo password. Il problema nasce dalla mancata corrispondenza tra ruoli e limiti dell’interfaccia.
Progettazione dei ruoli
In officina ci sono quattro categorie di persone, ognuna delle quali utilizza un’interfaccia diversa:
- Operatore: usa un terminale di postazione con grandi pulsanti o un tablet, visualizzando solo “l’ordine che ho in mano”, con tre pulsanti: avvio, pausa, completamento. Non compare alcuna tabella sullo schermo.
- Capoturno: usa il telefono o il tabellone dell’officina, visualizzando lo stato di tutte le postazioni del turno; in due minuti può individuare “dove si è bloccato”.
- Coordinatore o pianificatore: usa il PC, consultando il diagramma di Gantt e l’elenco delle anomalie di tutte le postazioni dello stabilimento; l’attenzione è rivolta soprattutto alla programmazione e alla gestione delle emergenze.
- Responsabile della qualità o del processo: ingresso indipendente, con visualizzazione del tasso di conformità al controllo iniziale, del tasso di rilavorazione e dei trend SPC; non modifica direttamente lo stato dell’ordine, ma può solo decidere “fermare la linea” o “autorizzare la partenza”.
Modello dei dati
Quattro tabelle principali, più alcune ausiliarie, sono sufficienti:
- work_order: tabella principale degli ordini, collegata agli ordini di vendita, ai piani di produzione e ai prodotti.
- work_order_route: itinerario di lavorazione, con indicazione di quanti passaggi sono previsti per ogni fase.
- route_event: flusso degli eventi di ogni fase (cronologia fondamentale), con informazioni su chi, quando, su quale macchina e a che punto si è arrivati.
- exception_log: registro delle anomalie (mancanza di materiali, guasti alle attrezzature, rilavorazioni di qualità).
I campi di stato (status、current_step、progress_pct) sono calcolati in tempo reale a partire da route_event, senza essere memorizzati; solo gli eventi vengono salvati. In questo modo, qualunque sia la persona che modifichi l’ordine, lo stato rimane sempre basato sui flussi di eventi.
Limiti dell’interfaccia
Bisogna delineare chiaramente i confini tra i tre tipi di terminali:
- Terminale di postazione: scansione del codice → recupero dell’ordine → visualizzazione del processo → grandi pulsanti per avvio/pausa/completamento; non è consentito inserire alcun dato numerico, tutti i numeri vengono scritti automaticamente dal PLC o dal lettore di codici.
- Tabellone del capoturno: vista a griglia delle postazioni del turno, con verde per le normali, giallo per i ritmi oltre il limite e rosso per le anomalie. Cliccando sul rosso si accede direttamente ai dettagli del registro delle anomalie.
- PC del dispatcher: diagramma di Gantt con carico delle risorse e code di eccezioni, le eccezioni devono essere suddivise in code separate, non possono essere mescolate nel diagramma di Gantt facendo “cercare l’eccezione” agli utenti.

03 Come sviluppare: tre barriere per la raccolta, l’interfaccia e la verifica
La questione centrale nella fase di sviluppo è “far sì che il campo lo voglia usare”. Il presupposto perché il campo lo voglia usare è che “basta un solo clic”, non “compilare una montagna di dati”. Dietro a tutto ciò ci sono tre barriere.
Barriera della raccolta
La raccolta si articola in tre livelli:
- Raccolta diretta dai dispositivi: CNC, presse ad iniezione, SMT tramite OPC UA o Modbus, scrivendo in tempo reale i segnali di avvio/arresto, il numero del programma corrente e i conteggi nel flusso degli eventi. Questa parte è la più difficile ma anche la più preziosa: una volta completata, non si dipende più dal lavoro manuale.
- Scansione del codice a barre e pulsante: alle postazioni manuali si utilizzano il lettore di codici a barre (per i materiali) + un grande pulsante (avvio/pausa/completamento). Il lettore di codici a barre funziona tramite USB HID e produce come output una stringa; non si fa OCR né riconoscimento delle immagini, poiché in rete sul posto basta un solo problema di connessione per rendere inutilizzabile l’immagine.
- Pesatura/conteggio/radar : pesatura dei materiali, conteggio dei componenti, barriera fotoelettrica; tutti i segnali passano dal PLC all’OPC.
I tre livelli condividono un unico servizio di gateway di raccolta; il gateway normalizza i diversi protocolli in un formato di evento unificato (JSON), scrivendolo nella coda dei messaggi (Kafka o RabbitMQ), dove viene consumato dai servizi di sottoscrizione e poi scritto nel database. In questo modo, quando si sostituiscono apparecchiature o postazioni di lavorazione, è sufficiente modificare solo il gateway, senza dover riscrivere il sistema principale di gestione aziendale .
Porta d’accesso alle interfacce
Le interfacce esterne sono di due tipi:
- A monte : ERP o MES inviano ordini di lavoro, ordini di vendita, BOM. Questa è la fonte primaria dei dati , e il nostro sistema è solo in lettura, per evitare che i due sistemi si influenzino reciprocamente modificando lo stato degli ordini.
- A valle : il sistema finanziario richiede le ore lavorative e i costi; il sistema clienti richiede lo stato di consegna; il sistema fornitori deve verificare lo stato della composizione dei kit. A valle si utilizzano “eventi trigger” o “recupero programmato”; non è consentito che i sistemi a valle modifichino direttamente lo stato degli ordini nel nostro sistema.
Principi di progettazione delle interfacce: Il flusso degli eventi esce ma non entra . Il nostro sistema è la fonte autentica dei dati (source of truth), mentre i sistemi esterni sono gli abbonati. Rispettando questa regola, esiste sempre una sola versione ufficiale dello stato di avanzamento.
Porta di verifica finale
La verifica non riguarda semplicemente se le funzionalità funzionano, ma tre aspetti:
- Verifica della veridicità dei dati : si selezionano casualmente 5 ordini di lavoro e, confrontandoli con la lavagna bianca o con le riprese video sul posto, si accerta che l’errore tra i tempi registrati dal sistema e quelli effettivi di inizio e fine lavorazione non superi i 5 minuti.
- Chiusura delle eccezioni : si crea un’eccezione per mancanza di materiale e si verifica che, dalla creazione da parte del caposquadra, alla gestione da parte del responsabile della pianificazione, fino al reperimento dei materiali dall’acquirente e al ripristino della postazione, tutto sia tracciato e che il movimento venga visualizzato nella coda delle eccezioni entro 5 minuti.
- Confronto dei ritmi di produzione : per una settimana consecutiva si controlla il ritmo effettivo di ogni postazione, confrontandolo con i parametri di processo; se la differenza supera il 30%, viene generata automaticamente una notifica di allerta.
Solo quando queste tre condizioni sono soddisfatte si può dire che “il progresso delle fasi di lavorazione è realmente visibile”.
Conclusione: sequenza di implementazione, rischi e indicatori
I progetti di questo tipo vengono lanciati in tre fasi, senza tentare di completarli tutto in una volta:
- Prima fase (1-2 mesi) : si installa innanzitutto il terminale di postazione e il quadro informativo per i capisquadra; coprendo solo una linea di produzione . L’obiettivo è che “l’80% dei biglietti sulla lavagna bianca venga sincronizzato automaticamente nel sistema”.
- Seconda fase (2-3 mesi) : si aggiungono il PC del responsabile della pianificazione, la coda delle eccezioni e l’acquisto diretto delle attrezzature, estendendo la copertura a tutte le principali linee di produzione dell’intero stabilimento. L’obiettivo è che “in loco non sia più necessario chiamare per chiedere lo stato di avanzamento”.
- Terza fase (su richiesta) : si collegano i sistemi ERP, finanziari e dei clienti, per ottimizzare i ritmi di produzione e realizzare analisi SPC. Questa fase non è obbligatoria; dopo aver completato le prime due si valuta il feedback sul campo prima di decidere.
Rischi comuni:
- Resistenza sul campo : paura di essere monitorati e confrontati. Soluzione: l’interfaccia mostra solo la postazione di lavoro, non le persone; gli indicatori sono calcolati a livello di squadra, senza classifiche individuali.
- Mancanza di segnalazione nella raccolta dei dati : le attrezzature obsolete non dispongono di porte di comunicazione, quindi è necessario ricorrere a lettori di codici a barre. Alla verifica occorre assicurarsi che il tasso di mancata segnalazione non superi il 5%.
- Distorsione delle ore lavorative : gli operai, per “raggiungere i numeri”, avviano e interrompono ripetutamente le attività. Se il sistema rileva più avvii nello stesso intervallo di 5 minuti, questi vengono considerati immediatamente come anomalie.
Gli indicatori che determinano il successo del progetto sono soltanto tre:
- Numero di telefonate del responsabile della pianificazione : dopo l’implementazione diminuisce di oltre il 50%.
- Tempo medio di risposta alle eccezioni : si riduce da ore a minuti.
- Progresso consultabile dai clienti : il tasso di reclami per ritardi nelle consegne diminuisce di oltre il 30%.
Portando questi tre indicatori sul campo, si svuota la lavagna bianca sul muro e si può considerare davvero conclusa l’attività di gestione del progresso.