Tool Visibility - Punti aperti: archivio al 30 settembre 2026 (pre-revisione post-meeting)
PA-19 - Turno notturno: perdite dichiarate senza apertura a sistema [aperto - referente Sandro]
Contesto
Sul periodo giugno-luglio il turno T3 (notturno) ha 288 ore di produzione registrate a sistema, contro circa 2.400 di T1 e T2. Nello stesso periodo il T3 ha pero' 314 eventi di perdita dichiarati: in due settimane i minuti dichiarati superano il 100% dell'apertura registrata del turno (116% nella settimana del 1 giugno, 103% in quella del 13 luglio). Il grafico "Perdite per turno nel tempo" in Losses overview mostra la serie completa.
Cosa significa
Le dichiarazioni di perdita del notturno arrivano, le sue ore di produzione no: una parte dell'attivita' del T3 non risulta nei dati di produzione. Finche' l'apertura del turno e' incompleta, le percentuali di perdita del T3 non sono confrontabili con quelle degli altri turni (nel grafico la linea e' tratteggiata per questo).
La domanda
Il turno notturno registra la produzione su un flusso diverso, oppure le sue righe non vengono estratte? Se ne parla a valle del meeting del 30 settembre.
PA-18 - Conferma dei tempi ciclo per canale [aperto - referente Pompeo]
Contesto
Il foglio Anagrafica & target del caricatore contiene la colonna cycle_time_min_pz (tempo ciclo in minuti per pezzo, blocco Rettifica). I valori attuali sono stati precompilati da Jopex e non sono mai stati confermati o corretti: CH1-CH3 1,0 · CH4-CH5 1,4 · CH6 0,8 · CH7-CH9 1,1. La richiesta di conferma non era mai stata formulata esplicitamente: questo punto la formalizza.
Dove incide
Il tempo ciclo converte gli anelli scartati in minuti nella categoria Scrap/Rework, per i canali che non dichiarano l'evento direttamente. Il dettaglio del calcolo e' nella pagina Metodo, sezione 6.
La domanda
Confermare o correggere i tempi ciclo per canale nella colonna gia' presente nel caricatore. Se ne parla a valle del meeting del 30 settembre.
PA-17 - Ore di apertura della Clean room [aperto - referente Sandro]
Contesto
Richiesta nuova, nata il 28 settembre col caricamento delle ore di apertura: il foglio richiesto era pensato per la Rettifica (minuti per linea IR/OR) e copre correttamente quella. Lavorando sui dati e' emerso che anche la Clean room - che ha dichiarazioni di perdita proprie, per operazione - avrebbe bisogno della sua apertura per chiudere il calcolo OEE allo stesso modo. Non era tra le richieste fatte finora.
La domanda
Se ne parla a valle del meeting del 30 settembre: il dato di apertura della Clean room e' estraibile? Se non lo e', il tool continua col calcolo attuale (proxy dei turni teorici) e lo indica.
PA-16 - Caricatore dati v02 (giugno e mesi successivi) [verifica - referente Sandro]
Contesto
Il meeting del 21 luglio ha fissato il calcolo OEE ufficiale (vedi PA-06) e alcune richieste nuove: OEE dei canali di rettifica spaccato per linea IR/OR, blocchi Rettifica e Clean room misurati separatamente (anelli vs cuscinetti singoli), categorie di perdita coi nomi ufficiali. Il caricatore dati e' stato aggiornato di conseguenza - versione v02, scaricabile qui sotto.
Le novita' in breve
- Foglio nuovo Ore di apertura: minuti reali per turno e canale, il denominatore dell'OEE
- Colonna linea IR/OR negli scarti e negli eventi perdita di rettifica
- Colonna canale nei fogli Clean room
- 7 categorie di perdita coi nomi ufficiali
- Eliminate le colonne non piu' necessarie: in totale il file chiede meno campi della v01
La domanda
Per giugno (e i mesi successivi) usare questo file al posto della v01. Unica verifica richiesta a IT: l'estraibilita' della colonna linea (IR/OR) su scarti ed eventi perdita.
Stato (2 set)
Il 1 settembre IT ha consegnato il caricatore compilato con giugno e luglio: delivery oraria su tutti e 9 i canali, scarti ed eventi perdita Rettifica con la linea IR/OR, scarti, rilavorazioni ed eventi Clean room per operazione con le categorie compilate. Dati caricati nel tool, che ora lavora sul periodo giugno-luglio. Restano da integrare tre fogli: Ore di apertura, Delivery per step e Fermi bottleneck.
Stato (28 set)
Il 25 settembre IT ha consegnato le ore di apertura consuntive di giugno, per turno e per linea IR/OR (blocco Rettifica), caricate nel tool: l'OEE di giugno usa ora il denominatore reale, per canale e per linea - le asimmetrie IR/OR (154 turni con aperture diverse tra le due linee) sono misurate. Luglio resta sul proxy dei turni teorici in attesa del consuntivo. Vedi anche PA-17: manca l'apertura della Clean room.
PA-02 - Foglio delivery per step [verifica - referente Sandro]
Perche' l'abbiamo chiesto
Ogni pezzo attraversa la fabbrica passo dopo passo. Questo foglio chiede, per ogni turno e canale, pezzi entrati, usciti, scarti e rilavorazioni. Il foglio e' predisposto nel file che vi abbiamo passato, ma e' rimasto vuoto.
Cosa ci darebbe la compilazione
- Channels overview - l'avanzamento di ogni canale, passo per passo
- Stato del flusso - la vista del flusso produttivo turno per turno
Finche' resta vuoto
- la qualita' per canale copre solo la rettifica
- i ripassi valgono zero
- i respinti contano tutti come rottamati
La domanda
Vi chiediamo di compilarlo per i mesi caricati nel tool (oggi giugno e luglio).
Stato (17 lug)
I ripassi esistono e sono tracciati nel flusso DMC lato collaudi; l'estrazione della tabella e' in carico a IT con Oasis.
Stato (28 set)
Il 25 settembre IT ha consegnato la
delivery per step (giugno-luglio) sulla tassonomia ufficiale a 11 step, caricata nel tool: Channels overview (che ora include lo Stato del flusso) mostra le uscite reali per step. Restano tre limiti:
- gli step 8-11 (Dimensionale OR, Rasamento, MVH, Packaging) sono estratti senza canale - il tool li mostra a livello plant
- gli step 1 e 5 (finiture facce, operazione condivisa) non hanno dati
- ci sono solo le uscite: entrate, scarti e rilavorazioni per step non sono ancora estratti
Verifica di coerenza: 113.214 cuscinetti usciti dal Packaging sul periodo, contro 105.303 di versato canale (rapporto 1,08).
Stato (30 set)
Nel pomeriggio del 30 settembre IT ha consegnato l'attribuzione ai canali degli step 8-11 (Dimensionale OR, Rasamento, MVH, Packaging), caricata nel tool: le corsie di Channels overview mostrano ora l'intero flusso per canale. Restano 122 righe per step non attribuite (tipologie speciali o multi-canale, limite del DMC) e restano disponibili le sole uscite (niente entrate, scarti o rework per step). Il primo invio del 30/9 conteneva valori gonfiati di un fattore ~3,4 per un errore di aggregazione delle query, segnalato in mattinata e corretto da IT in giornata.
PA-03 - Conferma dei ritmi e dei forecast (Tabella 4) [risolto - referente Pompeo]
Contesto
La Performance dell'OEE e la Delivery del mese si calcolano confrontando la produzione reale con i ritmi e i forecast che ci avete fornito (Tabella 4). Mettendoli a fianco del versato reale di maggio, il confronto solleva una domanda:
| Canale | Ritmo (pz/turno) | Turni attivi | Forecast maggio (pz) | Versato maggio (pz) | vs forecast |
|---|
| CH1 | 250 | 3 | 16.065 | 29.186 | +82% |
| CH2 | 180 | 3 | 11.567 | 8.770 | -24% |
| CH3 | 238 | 3 | 15.294 | 2.131 | -86% |
| CH4 | 105 | 2 | 4.498 | 4.139 | -8% |
| CH5 | 27 | 1,5 | 878 | 286 | -67% |
| CH6 | 120 | 1,5 | 3.856 | 3.258 | -16% |
| CH7 | 26 | 1 | 557 | 454 | -18% |
| CH8 | 206 | 1,5 | 6.619 | 4.979 | -25% |
| CH9 | 34 | 1 | 728 | 578 | -21% |
Il versato e' quello registrato a magazzino dal 4 al 29 maggio (i giorni 1-3 non sono nei dati che abbiamo). Il canale 1 ha versato quasi il doppio del suo forecast, mentre quasi tutti gli altri sono sotto: prima di leggere questi numeri come prestazioni, vogliamo essere certi di confrontare la stessa grandezza.
Domanda 1
Ci confermate che i numeri della Tabella 4 - ritmi e forecast - si riferiscono al versato a magazzino di prodotto finito (cuscinetti confezionati)? Se qualche valore si riferisce ad altro - pezzi in rettifica, anelli, o un punto diverso del flusso - segnalatecelo canale per canale.
Domanda 2
Verificate che i valori di ritmo e forecast in Tabella 4 siano corretti e aggiornati? Alcuni canali versano molto sopra il ritmo indicato (CH1 +82% sul forecast): se i valori non riflettono la capacita' reale dei canali, correggeteli direttamente nel foglio allegato.
Stato (17 lug)
Verificato con IT il 17/7: il canale 1 e' ben monitorato in PaperEdge, il dato al 159-160% del ritmo e' reale e non spiegabile con dati mancanti. Da verificare con Operations: possibile scelta operativa di compensazione dei canali che hanno prodotto meno, oppure valori della tabella da aggiornare.
Stato (27 lug)
Pompeo ha rinviato la Tabella 4 con i valori confermati (ritmi e turni attivi invariati). Resta aperta la domanda di fondo - se il ritmo pezzi/turno rappresenti il fabbisogno per gli ordini o il massimo del canale - rilanciata via mail: senza questa risposta il confronto col versato reale di maggio (CH1 +82%) non e' interpretabile. In parallelo IT ricarichera' i dati di maggio e giugno corretti: il confronto ritmi vs versato verra' rifatto sui dati nuovi.
Esito (27 lug)
Pompeo conferma: i ritmi della Tabella 4 sono il target teorico del canale per turno, non il fabbisogno commerciale (che varia con gli ordini). Conseguenza: un versato oltre il target teorico (CH1 +82%) non e' fisicamente possibile e conferma l'errore nei dati di maggio, gia' in correzione da parte di IT. Il punto si chiude al ricaricamento dei dati corretti.
Esito (2 set)
Operations conferma che i ritmi della Tabella 4 sono il target teorico del canale per turno. Il punto si chiude: i ritmi sono in anagrafica e d'ora in poi il confronto col versato si applica al periodo di riferimento giugno-luglio.
PA-14 - Fermi delle stazioni bottleneck [risolto - referente Sandro]
Contesto
Il tempo perso di un canale e' quello della sua stazione
bottleneck. Ogni canale ha due linee, anello interno (IR) e anello esterno (OR), ciascuna col proprio bottleneck - tipicamente la rettifica di finitura piste:
- se si ferma una macchina a monte, il bottleneck si ferma solo quando finisce il materiale
- se si ferma una macchina a valle, si ferma quando il nastro si riempie
Oggi riceviamo gli eventi di fermo dichiarati dalle operazioni del canale, ma
senza l'indicazione di quale macchina li abbia generati: non potendo riconoscere il bottleneck,
temporaneamente stimiamo il tempo perso unendo i fermi sovrapposti. A maggio:
- 25.304 minuti persi dai canali (fermi sovrapposti contati una volta)
- 37.158 minuti dichiarati dalle stazioni
- la differenza sono i fermi in parallelo
Nelle pagine porteremo comunque entrambi i totali.
La domanda
Vi chiediamo l'export dei fermi delle sole stazioni bottleneck, per canale e linea, con data e ora puntuali - il tracciato esatto e' nel foglio allegato. Per maggio 2026, poi in continuo.
Stato (22 lug)
Dal meeting del 21 luglio: la registrazione dei fermi con le note e' gia' avviata dagli operatori; l'estrazione e' in carico a IT via query dedicata. Il tracciato e' ora incluso anche nel caricatore dati v02, con le categorie di perdita allineate ai 7 nomi ufficiali SKF. Questi fermi, per linea IR/OR, sono la base per l'OEE di canale spaccato per linea richiesto in meeting.
Stato (2 set)
Nella consegna del 1 settembre il foglio e' arrivato vuoto: l'estrazione dei fermi per stazione bottleneck e linea e' ancora in lavorazione presso IT. E' il dato che accende l'OEE per linea IR/OR e il box Bottleneck per canale, gia' predisposti nel tool.
Esito (15 set)
Il 14 settembre IT ha consegnato l'export dei fermi bottleneck di giugno e luglio: 572 fermi con stazione, linea IR/OR, categoria e note complete. Caricati nel tool: alimentano il box Bottleneck per canale in Plant overview e la vista "Dove si perde - Rettifica per stazione" in Losses overview. La stazione critica e' quasi ovunque la Finitura Gola, con la linea OR che pesa piu' del doppio della IR a livello plant.
PA-06 - Calcolo OEE ufficiale [risolto - referente Pompeo]
Contesto
L'OEE ufficiale dello stabilimento viene calcolato su un file Excel da un industrial engineer; il tool che stiamo progettando calcola il suo OEE con le regole documentate nella colonna delle assunzioni qui a fianco: per spiegare le differenze tra i due numeri serve mettere i due calcoli uno accanto all'altro.
La domanda
Possiamo vedere il file di calcolo con le sue formule e confrontarlo col nostro sullo stesso mese (maggio), input alla mano?
Esito (22 lug)
Pompeo ha condiviso la tabella OEE di maggio (totale factory e canali). Il calcolo e' confermato: OEE = Running hours / Manned hours, dove Manned = minuti di apertura del canale e Running = Manned meno la somma delle 7 categorie di perdita dichiarate in ore. Tempi riferiti alla stazione bottleneck del canale (linea piu' lenta tra IR e OR). Il tool adotta questo stesso calcolo, cosi' i numeri sono confrontabili con quelli ufficiali. La verifica sui totali di maggio chiude al centesimo su tutte le righe.
PA-07 - Calcolo della qualita' [verifica - referente Sandro]
Oggi
Qualita' = pezzi buoni / pezzi totali, sul periodo, per blocco: anelli scartati in rettifica (per linea IR/OR) e respinti dei collaudi in Clean room. E' il calcolo migliore possibile con i dati disponibili.
Appena avremo i dati
Con il costo standard (SC) su ogni riga di scarto - come gia' arriva per il versato - calcoleremo la qualita' in euro, valore entrato contro valore uscito, precisa anche ora per ora. Il tracciato e' nel foglio allegato.
Stato (17 lug)
Il PowerBI qualita' espone gia' lo scarto in valore e i nostri conteggi riconciliano con quel report.
PA-10 - Categoria di perdita negli eventi dei collaudi [risolto - referente Sandro]
Contesto
Per ogni fermo dichiarato chiediamo anche la categoria di perdita (guasto, attrezzaggio, mancanza materiale, ecc.): e' quella che permette di costruire il Pareto e capire dove intervenire. Per la rettifica la categoria c'e' su ogni evento; per i collaudi la colonna e' predisposta nel file che vi abbiamo passato, ma e' arrivata vuota - abbiamo la durata e l'operazione di ogni fermo, ma non il tipo. Risultato: 9.337 minuti di fermi ai collaudi che oggi non possiamo classificare.
La domanda
La categoria di perdita per gli eventi dei collaudi esiste nel sistema e si puo' esportare, oppure ai collaudi non viene dichiarata? Nel secondo caso, la colonna del file resta il posto giusto dove aggiungerla.
Esito (22 lug)
I 178 eventi di maggio sono stati classificati da noi nelle 7 categorie a partire da durata, operazione e note (classificazione consultabile e correggibile). Dal meeting del 21 luglio: l'area collaudi nel tool prende il nome "Clean room" e nel caricatore v02 la colonna categoria resta facoltativa - se arriva vuota, la classificazione la facciamo noi dalle note.
PA-13 - Target ufficiali di perdita e OEE [risolto - referente Pompeo]
Contesto
I semafori del tool confrontano ogni numero con un obiettivo: i minuti massimi di perdita al giorno per ciascuna categoria e i target di stabilimento per OEE, disponibilita', performance e qualita'.
Nelle tabelle che vi abbiamo passato la colonna "valore corretto SKF" e' rimasta vuota per tutte queste voci, quindi oggi i semafori confrontano i vostri dati reali con obiettivi di default scelti da noi: i numeri mostrati sono giusti, i colori verde/giallo/rosso no. Questi i valori:
Target di stabilimento| Parametro | Valore in uso (nostro default) | Valore corretto SKF |
|---|
| OEE | 70% | da compilare |
| Disponibilita' | 85% | da compilare |
| Performance | 90% | da compilare |
| Qualita' | 92% | da compilare |
| Perdite (min/turno) | 30 | da compilare |
| Perdite (min/giorno) | 90 | da compilare |
| Rispetto consegne (On Time Delivery) | 95% | da compilare |
Obiettivi per categoria di perdita (minuti al giorno)| Categoria | Valore in uso (nostro default) | Valore corretto SKF |
|---|
| D Time (Downtime) | 30 | da compilare |
| Resetting | 12 | da compilare |
| Tooling losses | 15 | da compilare |
| Missing resources | 10 | da compilare |
| Process Adjustment | 20 | da compilare |
| Speed loss & Minor stops | 25 | da compilare |
| Scrap & Rework | 12 | da compilare |
La domanda
Vi chiediamo di compilare la colonna "valore corretto SKF" delle due tabelle. Se questi obiettivi esistono gia' nel vostro handbook, bastano quei valori.
Stato (22 lug)
Dal meeting del 21 luglio: confermato che i valori attuali sono default nostri e vanno sostituiti. Le tabelle da compilare sono ora tutte nel caricatore dati v02 (foglio "Anagrafica & target", marcate "compila Pompeo"): target di stabilimento, target per categoria di perdita e - novita' - target OEE per singolo canale.
Esito (27 lug)
Pompeo ha inviato i target ufficiali (mail 26 lug): OEE plant 56,8%, punti di perdita ammessi per componente (Availability 35,0 - Performance 4,9 - Qualita' 3,3, complemento esatto del 56,8%), perdite ammesse 850 min/turno = 2.550 min/giorno, e target per ciascuna delle 7 categorie (Resetting 1.335,66 min/g e' il piu' alto, coerente coi cambi tipo frequenti). Valori caricati nel tool: tutti i semafori ora confrontano coi target ufficiali. Resta da compilare il solo target On Time Delivery.
PA-15 - Planimetria dello stabilimento [aperto - referente Sandro]
Contesto
Stiamo preparando una pagina del tool con la planimetria dello stabilimento e, su ogni area di canale, i valori chiave di performance. Oggi abbiamo la planimetria solo come immagine: la definizione e' sufficiente per una vista d'insieme ma non regge lo zoom sulle singole aree.
La domanda
Ci fornite il disegno 2D della planimetria in formato DWG e, insieme, un export DXF (da AutoCAD e' un "Salva con nome")? Con il file vettoriale possiamo ingrandire ogni area alla massima definizione. Utile anche la corrispondenza tra i nomi delle aree nel disegno (WCM1, WCM2, CH4B...) e i canali CH1-CH9.
PA-04 - Copertura delle dichiarazioni [risolto - risolto il 17 lug]
Contesto
Il tool calcola il tempo perso a partire dagli eventi registrati in PaperEdge, che sono dichiarazioni fatte a bordo macchina. A maggio risultano 37.158 minuti dichiarati su tutto il plant in 26 giorni. Per interpretare correttamente questo numero ci serve sapere se rappresenta tutto il tempo perso o solo una parte.
La domanda
Ci confermate che in PaperEdge viene dichiarato ogni evento di perdita, oppure esistono soglie sotto le quali gli eventi non vengono registrati (per esempio fermi sotto una certa durata, microfermate, riduzioni di ritmo)?
Risposta (17 lug)
Non esistono soglie formali sotto le quali gli eventi non si registrano, ma i due mondi hanno una natura diversa:
- rettifica: le perdite sono stimate dall'operatore a fine turno, non misurate in tempo reale
- collaudi: gli operatori devono giustificare tutte le ore del turno
- in arrivo: un nuovo sistema (in prova) confronta i pezzi dichiarati con quelli attesi dal tempo ciclo e segnala al caposquadra il divario da giustificare
Fino ad allora, la disponibilita' calcolata dal tool va letta sapendo che il dichiarato di rettifica e' una stima di fine turno.
PA-09 - Durata netta del turno [risolto - risolto il 17 lug]
Contesto
Il tool considera ogni turno come 480 minuti pieni (8 ore) di tempo pianificato, ed e' su questa base che calcola la disponibilita' dei canali. Dentro un turno esistono pero' pause, mensa e cambi squadra, e non sappiamo come vengano trattati nel calcolo ufficiale SKF: se il tempo pianificato che usate voi e' al netto di queste voci, i nostri valori assoluti non sono confrontabili con i vostri, anche a parita' di dati. Non conoscendo la regola, per far girare il modello abbiamo assunto i 480 minuti pieni (e' l'Assunzione 05 nella colonna delle assunzioni qui a fianco): un'assunzione da sostituire con il valore reale.
La domanda
Per capire meglio e allinearci al vostro standard: nel calcolo ufficiale il tempo pianificato del turno e' di 480 minuti pieni o al netto di pause, mensa e cambio squadra? In quel caso, quanti minuti vanno considerati per i turni feriali, del sabato e della domenica?
Risposta (17 lug)
Turno 1 e turno 2 valgono 450 minuti (480 meno 30 di mensa), il turno 3 vale 480 minuti pieni. Le pause fisiologiche non si dichiarano: sono gia' incluse come sotto-efficienza concordata con le maestranze. Il tool ora usa queste durate reali nel calcolo di disponibilita' e OEE.
PA-11 - Copertura dei canali CH5, CH7 e CH9 [risolto - risolto il 17 lug]
Contesto
A maggio questi tre canali hanno pochissime righe nei dati: poche consegne registrate, nessuno scarto, pochissimi eventi di perdita (CH7 per esempio ha 12 righe di versato in tutto il mese). Il tool li mostra quindi con qualita' perfetta e disponibilita' piena - non perche' siano i migliori dello stabilimento, ma perche' di loro sappiamo poco. Sono anche i canali con i volumi previsti piu' bassi, quindi il dubbio e' legittimo: pochi dati perche' hanno lavorato poco, o perche' quello che hanno fatto non e' stato registrato?
La domanda
I dati di maggio di CH5, CH7 e CH9 riflettono la loro attivita' reale (hanno davvero lavorato cosi' poco), oppure questi canali dichiarano meno degli altri o registrano su sistemi diversi?
Risposta (17 lug)
- CH7 e CH9: PaperEdge non installato
- CH5: installato da poco, dati ancora incompleti
Di questi canali arrivano solo i versamenti (dal gestionale XA), senza dichiarazioni di produzione, scarti ne' eventi. Decisione:
- esclusi dal monitoraggio di dettaglio: nei grafici per canale compaiono in grigio con la nota "non in PaperEdge"
- fuori dal calcolo di disponibilita' e performance di stabilimento
- il versato resta nei totali (e' un dato reale)
Rientreranno quando PaperEdge sara' attivo.