5. Progettazione di un sistema per la tracciabilità dei materiali
5.1 Il macroprogetto di Supply Chain Management
L’implementazione di un sistema di tracciabilità dei materiali e dei mezzi adibiti alla movimentazione all’interno del cantiere non rappresenta un intervento a sé stante, ma si colloca in un più ampio e organizzato “macroprogetto” riconducibile sì all’area di competenza dell’Ufficio Logistica, ma dei cui effetti beneficerà in maniera evidente l’intero cantiere, senza distinzioni di Ufficio o reparto.
Tale macroprogetto è stato intrapreso già parecchi mesi prima del mio ingresso in Azienda, e in linea di massima consta di tre punti (progetti) principali:
1) indipendenza operativa e realizzazione di una infrastruttura di rete (tenendo conto delle notevoli trasformazioni cui sarà soggetto il cantiere da qui ai prossimi anni, con la realizzazione della “stecca” Benetti, del quartiere “Porta a Mare” e la costruzione di altri nuovi edifici);
2) tracciabilità dei materiali e dei mezzi all'interno del cantiere; 3) sistema di videosorveglianza.
Indipendentemente dai costi che ognuno di tali progetti comporta per l’Azienda, appare subito evidente come siano i primi due a rivestire un’importanza strategica. In particolare, la realizzazione di un’infrastruttura di rete costituisce un presupposto necessario per garantire quel flusso di dati (continuo, efficiente e tempestivo) che sarà alla base del sistema di tracciabilità, sia con i semplici codici a barre che, soprattutto, con tag e gate RFID. Per questo motivo, il progetto 1 sta procedendo parallelamente al 2, anzi alcune attività del progetto di tracciabilità risultano completamente vincolate ad altre di 1 (ad esempio, le prime simulazioni di utilizzo dei palmari industriali esigeranno necessariamente la preventiva attivazione della rete wi-fi); ed ecco perché la direzione di LOG, project manager per il macroprogetto di SCM prima ancora che dei singoli progetti, ha ritenuto opportuno riunire intorno ad uno stesso tavolo tutti i fornitori coinvolti, definendo interfacce precise a livello organizzativo e coordinando le operazioni in modo da evitare indesiderati “fermi” e colli di bottiglia.
5.1.1 La scelta dei fornitori: primi cenni all’offerta DAXO
Per prima cosa, però, Benetti ha dovuto individuare, per ognuno dei tre progetti, il fornitore che meglio sposasse le sue esigenze, e non solo in fatto di prezzo o di tecnologie utilizzate. Sono 8, infatti, i “key points” presi in considerazione nel valutare i papabili fornitori1:
a) soluzioni tecniche proposte; b) elementi distintivi delle soluzioni; c) impatto sulla struttura;
d) condizioni sulla manutenzione;
e) integrazione con l’ERP aziendale (solo progetto 2); f) integrazione con la rete wi-fi (solo progetti 2 e 3); g) possibili sviluppi futuri;
h) condizioni economiche.
Sulla base di questi ed altri fattori, quali eventuali certificazioni e precedenti rapporti instaurati col cantiere, e puntando a minimizzare il numero di fornitori per gestire più agevolmente le interfacce, sono state scelte due Aziende (fig. 39):
- per i progetti 1 e 3, la AB Telematica S.r.l., Società con sede a Pontedera con notevole esperienza nel campo dei sistemi di telecomunicazione e networking destinati alle Aziende, di cui gestisce ogni aspetto: dalla progettazione alla posa della rete, dall'installazione al collaudo, allacciamento e manutenzione delle apparecchiature terminali.
- Per il progetto di tracciabilità, la DAXO – mobile & wireless di Livorno, Azienda giovane ma che si sta affermando sul territorio nazionale come “first mover” verso l’adozione di nuove soluzioni per le esigenze del mercato ICT, grazie anche a partnership tecnologiche di assoluto prestigio. Il suo obiettivo è quello di offrire ai
1
Poiché il contesto di riferimento rimane quello dell’ICT (Information and Communication Technology) per tutti i tre progetti, tali fattori sono stati ritenuti validi per valutare tutte le offerte (se si escludono poche eccezioni, indicate fra parentesi).
propri clienti molteplici opportunità a livello di innovazione organizzativa e di processo, mediante l’utilizzo di soluzioni mobile2.
Figura 39: le Aziende fornitrici per il progetto di SCM
In particolare, l’estratto in tab. 8 riporta il riepilogo dell’offerta DAXO, in cui per ciascuno degli 8 criteri sopra indicati sono riassunte le informazioni più rilevanti.
a) Soluzioni tecniche proposte b) Elementi distintivi delle soluzioni c) Impatto sulla struttura d) Condizioni sulla manutenzione
Riguardo alla tracciabilità delle merci l'uso della tecnologia RFID permette di ottimizzare l'accettazione
del materiali in ingresso, la registrazione delle movimentazioni interne dei
magazzini, la gestione della consegna e della richiesta di materiali alla
produzione oltre all'esecuzione di inventario dei vari magazzini. Ad ogni materiale è applicato un
tag RFID passivo che interagisce con lettori wi-fi e permette di dialogare col
sistema operativo. La lettura dei materiali avviene
attraversando un gate all'ingresso dei magazzini. Il sistema informativo, con le applicazioni Front Office (cuore del sistema) e Back Office (integrazione con
l'ERP aziendale), permettono di gestire anche le locazioni dei vari
articoli e permetterne la localizzazione dal momento in cui entrano in
cantiere.
Le applicazioni Back Office permettono sopperire alle mancanze
dell'attuale sistema
gestionale. - Vantaggi relativi
all'utilizzo della tecnologia RFID (lettura
a distanza, maggiore quantità di informazioni scambiate, eliminazione di errori e dimenticanze, immediatezza delle attività inventaristiche,
possibile riutilizzo dei
tag) - Manutenzione onerosa
ma offre buone
prestazioni - Utilizzo della tecnologia
JAVA che permette elevata portabilità tra
sistemi multi-piattaforma - Opzione di un programma di addestramento del personale coinvolto Il progetto non presenta elementi che modificano la struttura fisica del cantiere, se non la presenza dei gate
all'entrata dei magazzini periferici. Tutte le apparecchiature fornite, interagendo prevalentemente tramite wi-fi, non hanno impatto
significativo.
Caratterizzata da assistenza di primo (servizio Help Desk) e secondo livello (tecnico di presidio). Il costo riguarda il 15% della spesa complessiva e comprende anche l'erogazione di aggiornamenti software oltre a un servizio di assistenza telefonico in città (interventi on-site più tempestivi). 2
Da non trascurare pure il fatto che DAXO sia capofila nell’ambito del progetto “eNautica”, finanziato dalla Regione Toscana, attraverso il quale si intende promuovere la diffusione e applicazione di soluzioni ICT nel mondo della nautica.
e) Integrazione con ERP aziendale f) Integrazione con rete wi-fi g) Possibili sviluppi futuri h) Condizioni economiche Le principali interazione richieste sono: possibilità di
evasione dell'ordine fornitore, registrazione dello scarico del materiale
in produzione e rintracciabilità dei materiali.
Il progetto prevede l'integrazione delle applicazioni Back Office
con l'ERP aziendale tramite connettori presenti nella JVM. L'alta portabilità
della tecnologia JAVA permette il dialogo tra i sistemi back-end aziendali
e la base dati Oracle oggetto della fornitura. La
particolarità del DB consiste nel permettere il
dialogo tra postazioni mobili e dati aziendali in
modo trasparente con qualsiasi connessione (wireless nel nostro caso).
Le applicazioni Front Office (lettori RFID)
possono dialogare con le applicazioni server in modalità wireless nel caso in cui ci sia copertura di
rete.
Le applicazioni permettono un'integrazione con una serie di moduli,
interfacciabili al bisogno di realizzare altre funzionalità. In particolare si potrà: monitorare l'approvvigionamento
dei materiali, creare indici KPI per valutare
la performance
industriale e dare visibilità a clienti e/o fornitori sullo stato di avanzamento della
produzione
Hardware: 7 lettori, 28 antenne,, 200.000 TAG UHF, 8 palmari, 1
DB Oracle, 1 PC Server: ... € + Software: 1 piattaforma RFID Server, 1 gestione progetto, 8 licenze client: … € = ... € + ... € per manutenzione
Tabella 8: Riepilogo dell’offerta DAXO per l’implementazione del sistema di tracciabilità di materiali e mezzi
Si noti che l’offerta iniziale prevedeva l’adozione integrale e da subito della tecnologia RFID, mentre valutazioni successive da parte di Benetti hanno spinto a ripiegare – almeno per i primi mesi – su un sistema non altrettanto innovativo ma comunque molto efficace basato sull’utilizzo di codici a barre, lettori laser e palmari industriali. All’RFID è stato riservato per adesso un pilot project con fine sperimentale, ma l’intenzione è comunque quella di estenderne l’impiego in tutto il cantiere.
Questa scelta non deve essere considerata incoerente, né si può parlare di spreco, dato che l’infrastruttura applicativa (i database ed i SW) e le procedure impiegate con i barcode sono più o meno le stesse alla base dell’RFID, quindi l’eventuale transizione barcode – RFID non comporterà alcun costo aggiuntivo al di fuori di quello per i componenti hardware (tag e gate).
Anzi, i primi mesi di utilizzo di codici a barre e palmari dovranno servire proprio ad abituare tutti gli attori coinvolti ad un nuovo approccio metodologico, prima ancora che all’utilizzo delle tecnologie; inoltre, solo il risparmio di tempi e costi (cifre “concrete”, quindi) che si registrerà in questo primo periodo consentirà di giustificare agli occhi dei vertici aziendali l’ulteriore investimento nell’RFID (considerato piuttosto rischioso, dato anche che nella cantieristica navale nessuno a livello europeo ha mai intrapreso un progetto di tale portata).
5.1.2 Il kick-off meeting: organizzazione del team di progetto e programmazione delle attività
Il 7 settembre 2007, dopo mesi spesi a definire le specifiche di massima per il macroprogetto di SCM, individuare i fornitori e ritoccare alcuni dettagli delle offerte, ha avuto finalmente luogo, presso la direzione di LOG nel cantiere Benetti, l’incontro fra tutte le parti coinvolte, che ha sancito ufficialmente l’avvio delle operazioni.
In particolare, erano presenti:
- per Benetti (BU di Livorno):
o il direttore di LOG, project manager per l’intero macroprogetto;
o il responsabile dell’Ufficio Investimenti;
o rappresentanti del reparto ICT, sia per il cantiere di Livorno che per l’intero gruppo Azimut – Benetti3;
o io, figura di supporto con funzione di affiancamento al personale DAXO per quanto concerne il progetto di tracciabilità di materiali e mezzi;
- responsabili tecnici e commerciali di AB Telematica; - i vertici ed i e responsabili tecnici DAXO.
L’incontro è servito a Benetti per (ri)presentare ai fornitori il progetto di SCM e le principali criticità che presumibilmente esso avrebbe comportato, per promuovere la comunicazione e collaborazione fra AB Telematica e DAXO (evidenziando quali fasi del progetto di realizzazione dell’infrastruttura di rete sarebbero state vincolanti per l’avanzamento delle attività svolte da DAXO4), e per iniziare a definire una sorta di cronoprogramma di massima, nell’attesa che le settimane successive consentissero alle due Aziende di “ambientarsi” nel cantiere e raccogliere informazioni a sufficienza per redigere i rispettivi progetti esecutivi e Gantt.
Più specificatamente, per quanto riguarda il progetto di tracciabilità dei materiali e dei mezzi, il meeting ha consentito di ribadire la rilevanza dell’intervento, quanto mai ambizioso: Benetti, infatti, verrebbe ad essere il primo costruttore di mega-yacht in Europa, se non al mondo, ad impiegare le tecnologie di Auto-ID per tracciare i materiali (oltre che i mezzi di
3
È ovvio che qualsiasi iniziativa intrapresa da una BU Azimut – Benetti che impatti (anche indirettamente) sui SI e sull’infrastruttura di rete condivisa con le altre sedi aziendali, presuppone la partecipazione ed il benestare dei vertici ICT.
4
A dire il vero, l’unico vincolo tecnologico al sistema di tracciabilità dipendente da AB Telematica è dato dalla definitiva attivazione della rete wi-fi, che dovrà precedere i primi test di validazione dei sistemi DAXO.
movimentazione) all’interno dei propri cantieri, elemento che oltre a giovare, ovviamente, all’immagine del cantiere (che dimostrerebbe così di perseguire l’eccellenza del processo oltre a quella, già globalmente riconosciuta, del prodotto), deve costituire pure per DAXO – e, indirettamente, anche per AB Telematica – uno stimolo in più per operare al meglio (un simile progetto rappresenta una vetrina di assoluto prestigio).
I capitoli seguenti approfondiscono i vari aspetti connessi al sistema di tracciabilità, il cui sviluppo e la cui implementazione nel cantiere sono tuttora in corso di realizzazione. Solo per introdurre i temi trattati, nonché giustificare la struttura di capitoli e paragrafi, è bene individuare le tre componenti principali del progetto DAXO:
- il sistema di tracciabilità dei materiali, di gran lunga la componente principale per l’entità del lavoro progettuale che essa comporta (in termini gestionali ancor prima che tecnici), cui è dedicato il presente cap. 5;
- il sistema di tracciabilità dei mezzi adibiti alla movimentazione merci (par. 6.1); - il quadro sinottico (par. 6.2), progetto più o meno slegato dai due precedenti (anche se
sono auspicabili integrazioni, soprattutto con il sistema di tracciabilità dei mezzi) volto a creare una sorta di “data repository” che raccolga e consenta la condivisione e consultazione di tutti i dati, le informazioni e i documenti rilevanti per monitorare le attività di cantiere (non solo da parte di LOG).
Le attività in cui questi tre “sottoprogetti” si articolano sono state e vengono attualmente condotte in parallelo, e il termine per la conclusione dei lavori e la consegna “chiavi in mano” dei vari sistemi, fissato inizialmente per il 31 dicembre 2007, dovrebbe presumibilmente slittare – per motivi indipendenti da DAXO – alla fine del mese successivo.
5.2 Un approccio strutturato alla programmazione delle attività: i workpackages
La metodologia adottata da DAXO per gestire il progetto prevede un approccio di tipo strutturato basato sulla suddivisione del lavoro in workpackages (WP), ovvero moduli lavorativi ben definiti per tempistica e scopo. Ecco i WP individuati, seguiti da una breve descrizione di ciascuno:
WP1 Project Management; WP2 Analisi;
WP3 Progettazione; WP4 Sviluppo; WP5 Test e Validazione; WP6 Documentazione; WP7 Installazione e Collaudo; WP8 Avviamento e Formazione; WP9 Manutenzione;
WP1 – Project Management: attività di gestione del progetto, volta ad organizzare e coordinare un apposito gruppo di lavoro, composto dal Responsabile di Progetto, da soggetti indicati dal Committente e dal team operativo. I limiti temporali di questo WP coincidono con quelli complessivi del progetto, dato che da esso dipendono tutti i risultati progettuali. In particolare, il project management deve garantire il rispetto degli obiettivi definiti nel WP2.
WP2 – Analisi: l’obiettivo di questo workpackage è consistito nell’analizzare ed approfondire i requisiti utente attraverso una serie di colloqui e interviste per “mappare” nel dettaglio i processi operativi al momento di intraprendere lo sviluppo del progetto (situazione “as is”). Risultato della presente fase è stato un documento di analisi funzionale contenente problematiche e criticità attuali, indicazioni circa lo stato a tendere (“to be”) desiderato e, quindi, le specifiche da realizzare. Tale analisi dedica particolare attenzione anche alle esigenze del Committente in termini di strumenti di reportistica e raccolta dati necessari a valutare l’esito delle attività progettuali.
WP3 – Progettazione: essa si basa sul rispetto puntuale dei requisiti utente emersi in sede di analisi dei processi, e utilizza un approccio di tipo “object oriented”. Il suo fine è quello di delineare con esattezza il dominio dell'applicazione documentando il tutto tramite la formalizzazione diagrammi UML5. È nell’ambito di questo WP che sono stati proposti architettura e funzionalità dei sistemi da sviluppare.
5
In ingegneria del software, UML (Unified Modeling Language) è un linguaggio di modellazione e specifica basato sul paradigma object oriented. Il suo nucleo fu definito nel 1996 da G. Booch, J. Rumbaugh e I. Jacobson sotto l'egida dell’OMG (Object Management Group, consorzio creato nel 1989 con l’obiettivo di dare vita ad un sistema di gestione per un’architettura distribuita), che tuttora gestisce lo standard di UML. Il linguaggio nacque con l'intento di unificare approcci precedenti raccogliendo le “best practices” nel settore e definendo così uno standard unificato.
UML svolge un'importantissima funzione di lingua franca nella comunità della progettazione e programmazione a oggetti. Gran parte della letteratura di settore la utilizza per descrivere soluzioni analitiche e progettuali in modo sintetico e comprensibile a un vasto pubblico.
WP4 – Sviluppo: dopo l’approvazione del disegno progettuale, verranno sviluppati e testati i moduli applicativi e le relative interfacce.
WP5 – Test e validazione: il test dell’intero sistema verrà effettuato da un sottoinsieme di ISF scelti (“instant solutions framework”, cioè particolari sistemi di sviluppo) che utilizzeranno l’applicativo e segnaleranno eventuali anomalie, le quali dovranno successivamente essere corrette.
WP6 – Documentazione: questo WP è dedicato alla sola redazione dei documenti a supporto dell’installazione e del manuale d’uso.
WP7 – Installazione e collaudo funzionale: al termine della fase di test sarà predisposto, in accordo con il committente, un documento denominato “Verbale di Collaudo”, al fine di certificare il corretto funzionamento del sistema SW fornito.
WP8 – Avviamento e formazione: questo WP include le attività di formazione e addestramento degli utenti al corretto utilizzo del sistema, ed è volto a far acquisire la massima familiarità con lo strumento informatico. Esso prevede inoltre l’assistenza “on site” durante i primi giorni dall’avvio del sistema, per affiancare gli operatori nelle loro attività ed evitare così che questi si trovino a dover interrompere o alterare il regolare flusso operativo.
WP9 – Manutenzione: per un periodo di 12 mesi verranno garantite le attività di manutenzione correttiva.
Sebbene questa breve presentazione dell’approccio DAXO alle attività progettuali sia riportata nel presente capitolo e non venga più menzionata nelle sezioni successive, la struttura in WP è applicabile anche ai progetti descritti nei par. 6.1 e 6.2.
A pagina seguente (fig. 40) si riporta il Gantt di riferimento con le attività di progetto relative al solo sistema di tracciabilità dei materiali. La programmazione delle attività connesse allo sviluppo del sistema di tracciabilità dei mezzi e del quadro sinottico verrà presentata più avanti.
A seguire è una descrizione delle attività fin qui svolte e delle soluzioni progettuali in via di sviluppo o implementazione.
Una nota: la struttura dei paragrafi che seguono è funzionale ad una più chiara comprensione degli aspetti e dei contenuti più significativi del progetto; per questo essa non riflette la suddivisione del lavoro in WP né una qualche rigida sequenzialità logico-temporale (del resto la fig. 40 evidenzia come molte attività siano condotte in parallelo).
5.3 Analisi degli “as is processes”
La prima fondamentale fase, quella dalla cui completezza, accuratezza e correttezza dipendono la validità e la robustezza delle soluzioni progettuali proposte, ha previsto l’analisi dei processi gestionali e operativi così come essi effettivamente, ad oggi, si articolano.
Si è trattato di comprendere il funzionamento di ogni singola procedura in fatto di gestione dei materiali a magazzino, individuando in quali fra queste si celano le maggiori sacche di inefficienza (attività che non aggiungono valore, tempi morti, rischi di errore, colli di bottiglia) e determinando quindi dove sia prioritario intervenire coi nuovi sistemi.
Il primo processo operativo analizzato è stato quello che sancisce il primo ingresso del materiale in cantiere: il ricevimento, collaudo e carico contabile in magazzino.
5.3.1 Il ricevimento del materiale a magazzino
1. L’automezzo proveniente dal fornitore arriva in cantiere, e si dirige verso il MAG GEN. Qui presenta il DDT (documento di trasporto, o semplicemente “bolla”) preparato dal fornitore e riportante gli estremi della fornitura, nonché la firma del conducente.
2. Il responsabile per le accettazioni del MAG GEN (da qui in poi indicato come “RA”) applica 2 timbri sul DDT: il primo viene applicato da un apposito apparecchio, e riporta un numero progressivo (il “numero di entrata”, a 4 cifre: es. 3752), la data e l’ora; l'altro è un semplice timbro riportante alcuni campi da compilare: data ricevimento merci, numero ordine (es. 14902/05, dove 05 indica l’anno in cui l’ordine è partito), data ordine, codice fornitore, oltre che il codice associato alla commessa (es. FB244).
3. Il RA interroga l’ERP aziendale (VM) per reperire l'ordine connesso al DDT, compila i campi del secondo timbro, stampa l'ordine e lo spilla a una copia del DDT. Il
fascicoletto cosi ottenuto viene posto in apposito raccoglitore (raccoglitore I : "materiale da collaudare").
4. Il magazziniere che scarica la merce (uno chiunque degli addetti liberi in quel momento) scrive a pennarello sulla/e scatola/e: codice commessa, data e numero di entrata appena timbrato sul DDT. Il corriere, andandosene, porta via una copia del DDT come ricevuta per il fornitore.
5. L’addetto al collaudo (da qui “AC”) prende i fascicoletti impilati nel raccoglitore I, li porta con sé in zona collaudo, dove nel frattempo è stata posta la merce appena scaricata dal camion. Riconosce a quali codici sono associati i fascicoletti leggendo il numero di entrata scritto in fase di scarico merce, e scrive a pennarello sulle scatole i codici Benetti (es. PORL.BENE.504, o FLAN.QUAN.002).
6. L’AC effettua i controlli / collaudi opportuni, appena può stabilisce dove la merce deve essere ubicata e ve la trasferisce; nell'ordine trascrive, accanto al codice dell’articolo, il numero di entrata e l’ubicazione (es. T 23/5, ovvero corridoio T, settore 23, livello / piano 5. Si sta facendo riferimento in questo caso ad uno scaffale ubicato nel MAG GEN). Infine pone i fascicoletti così aggiornati in un secondo raccoglitore (II).
7. Il RA va a "pescare" i fascicoletti dal raccoglitore II, effettua il cosiddetto “carico in magazzino” dei codici appena collaudati e ubicati su VM e aggiorna il file Excel con le ubicazioni (dato che VM non consente di registrarle): da questo momento i codici sono, a tutti gli effetti, di “proprietà” e sotto la responsabilità del MAG. Fatto questo, il RA pone i fascicoletti in un terzo raccoglitore (III).
8. L’AC, appena può, prende i fascicoletti nel raccoglitore III e li inserisce nei cartolari conservati nell’archivio del MAG GEN (vi sono uno o più cartolari per commessa, e in ognuno i fascicoletti ordine – DDT sono ordinati alfabeticamente per fornitore).
Alcune note:
- Se viene stabilito che la merce deve essere ubicata in un magazzino periferico, l’AC pone il fascicoletto non nel raccoglitore II ma in uno diverso (IV), che interessa non il RA ma un secondo soggetto, responsabile della gestione dei ricevimenti non a MAG GEN. Dunque sarà questo secondo soggetto a caricare i codici su VM e aggiornare gli opportuni file Excel, e a porre poi nel raccoglitore III il fascicoletto per l'archiviazione.
- Può capitare che della merce in arrivo comprenda più ordini (non solo più codici o più unità dello stesso codice, ma proprio più ordini diversi, associati a una o più commesse). Per ogni ordine associato al DDT, il RA applica un diverso timbro, di cui compila i campi con i dati specifici. Il fascicolo che verrà preparato in questo caso, inoltre, includerà una copia di ciascun ordine interessato (ognuno riportante il dettaglio dei rispettivi codici).
- Come visto, una copia del DDT viene lasciata al corriere, mentre un'altra a fine procedura viene archiviata con l'ordine / gli ordini associato/i nell'apposito cartolare. Un'ulteriore copia del fascicoletto viene invece posta in un altro cartolare (qui i fascicoli vengono accumulati tutti insieme man mano che la merce arriva e viene collaudata), periodicamente consegnato all’Ufficio Amministrazione (AMM).
L’analisi del processo di ricevimento a MAG consente di evidenziare alcune problematiche di rilievo:
- Su alcuni pacchi in arrivo sono applicate etichette con barcode, che però evidentemente sono utilizzate solo per esigenze interne del fornitore e non vengono lette né in alcun modo sfruttate in Benetti.
- Così come può capitare che la merce proveniente da un fornitore comprenda più ordini, può benissimo verificarsi il contrario, cioè che il corriere non consegni l' "intero" codice. Questo o perché la fornitura prevede più unità dello stesso articolo, di cui però ne vengono approvvigionate solo alcune, o perché il codice – un portello, ad esempio - è unico ma costituito da più componenti, che potrebbero essere spediti dal fornitore in momenti diversi. In tal caso il fascicoletto associato ad un ordine va via via arricchendosi con i DDT delle varie consegne (ogni volta si va a riprendere il fascicolo nel cartolare), e sull'ordine o vengono evidenziati i componenti consegnati, o viene appuntato il numero di unità del codice arrivate, con i relativi numeri di entrata (l'ubicazione, il più delle volte, sarà invece la medesima). Solo quando tutte le unità o i componenti del codice sono giunti in cantiere, l'intero codice può essere "smarcato" e il carico su VM effettuato (mentre Excel consente più flessibilità: qui gli arrivi parziali vengono registrati come "materiale non codificato", insieme ad eventuali note).
Il flow chart riportato a pagina seguente (fig. 41) schematizza l’intero iter sopra descritto, evidenziandone la complessità: è ovvio che questa miriade di passaggi non aggiunge valore al processo, presentando tutta una serie di appesantimenti procedurali che si traducono, fra l’altro, nella produzione e accumulo di enormi quantità di “carta”.
Qui sotto (fig. 42) è invece riportato un esempio di “bolla” o DDT, in cui si evidenziano, fra le molteplici informazioni (codici, date, firme varie), quelle contenute nei due timbri descritti in precedenza: la data, l’ora ed il numero di entrata della merce (in alto), e gli estremi dell’ordine ad essa associato (timbro in basso in figura).
Si noti che, sebbene dati e campi che caratterizzano un DDT siano quasi sempre gli stessi, il formato di questo documento non è standard, bensì varia a seconda del fornitore.
Del resto basta leggere nel documento esemplificativo le codifiche delle parti approvvigionate, che nulla hanno a che fare con i codici a 11 campi adottati in Benetti.
Da rilevare infine che pure Benetti ha il “suo” DDT, impiegato ad esempio quando un codice deve essere spedito a terzi in conto lavorazione o per essere sostituito.
Ecco invece (fig. 43) una pagina estratta da un tipico ordine (il 14902/05) per il quale i codici non sono stati approvvigionati in un unico viaggio, ma sono giunti in MAG GEN in momenti successivi. In particolare si può notare come di questi tre portelli, realizzati della Metalmeccanica Iacomelli S.r.l. e individuati dalla codifica PORL.BENE.XXX, il primo ad essere spedito dal fornitore sia stato il codice PORL.BENE.510 (caratterizzato da un numero di ingresso più basso), seguito da PORL. BENE.507. Al momento in cui questa pagina è stata estratta dal relativo fascicolo, il portello PORL.BENE.508 doveva ancora essere approvvigionato. Ad ogni modo è presumibile che tale codice, come gli altri due, sia poi stato ubicato sotto il soppalco 6, proprio nel MAG GEN.
Figura 43: Ordine al fornitore evaso in momenti successivi
L’esempio riportato non si riferisce alla situazione più critica che si può presentare in quanto a difficoltà nel gestire il carico della merce sull’ERP aziendale: in questo caso, infatti, sebbene i diversi codici compresi nell’ordine non arrivino insieme, possono essere ricevuti contabilmente man mano che il fornitore li spedisce, dato che pure per il gestionale ognuno di essi ha una propria “identità” (un codice univoco).
I veri problemi si presentano, come già accennato, quando ad arrivare in momenti successivi (anche di settimane) sono singole parti di uno stesso codice (che si configura dunque come un “kit” di componenti): in tal caso i diversi numeri di entrata e le ubicazioni sono via via appuntati dall’AC accanto alla riga dell’ordine interessata, dove compare la descrizione del codice, e il codice stesso viene barrato solo quando tutti i suoi componenti sono stati
consegnati. Solo in questo momento potrà essere effettuato il definitivo carico del codice su VM, mentre prima il personale del magazzino è costretto ad arrangiarsi con note non standard riportate sui fogli Excel con le ubicazioni.
5.3.2 I possibili percorsi del materiale
Una volta che la merce giunta in cantiere è stata ubicata in magazzino ed è stata caricata sul gestionale, la stessa può essere soggetta a trasferimenti e movimentazioni con fine diverso (si può trattare anche solo di trasferimenti contabili cui non corrisponde un’effettiva movimentazione fisica, come quelli dei codici da una commessa ad un’altra). In linea di massima si possono individuare le seguenti procedure inerenti la gestione dei codici a magazzino:
- trasferimento dal MAG GEN a un magazzino periferico, o ad altra area adibita allo stoccaggio. Il contrario non si verifica quasi mai, dato che trasferire un codice al MAG GEN significherebbe allontanarlo dalla produzione (in particolare, si consideri che i magazzini periferici sono localizzati proprio nei capannoni di allestimento delle imbarcazioni). Si tratta di una procedura che si sviluppa completamente in seno alla Funzione MAG, e per questo non comporta la produzione di “carta”, ma solo l’aggiornamento delle giacenze su VM e/o delle ubicazioni sugli appositi file Excel. - Imbarco, ovvero “scarico” del codice dal magazzino (GEN o periferico che sia) e suo
trasferimento in produzione (PROD). Tale passaggio riguarda pure la responsabilità del codice stesso: dopo l’imbarco, è la PROD a risponderne in tutto e per tutto.
- Trasferimento da una commessa (ad es. la FB241) ad un’altra (es.: FB245), dovuto ad esempio alla necessità di montare sulla seconda imbarcazione un codice le cui scorte (in riferimento a quella stessa commessa) sono scarse o nulle, magari perché il fornitore tarda ad approvvigionarle, e che possono essere “prestate” da un ‘altra commessa per cui risulti meno urgente disporne subito. Si tratta ovviamente di un puro artificio contabile, dato che il più delle volte i codici interessati da questa procedura sono quelli locati nel MAG GEN (nei magazzini periferici si trovano i codici che stanno per essere utilizzati dalla PROD, e che quindi non ci si può permettere di passare ad altre imbarcazioni).
- Trasferimento da una commessa (ad es. la FB245) al MAG RESI: accade spesso, soprattutto all’avvicinarsi della data di consegna dell’imbarcazione all’armatore, che
alcuni codici rimangano inutilizzati, magari perché approvvigionati in quantità rivelatesi leggermente superiori alle reali necessità produttive, o più semplicemente qualora l’armatore, dopo aver scelto un qualche particolare (di arredo interno, ad esempio) durante le prime fasi dell’allestimento, cambi idea e decida di acquistare per conto proprio un altro modello di quel particolare da montare sulla barca, rendendo di fatto inutile il primo. In questi casi, può capitare che i codici risultino “riciclabili” per altre future commesse: il MAG RESI serve proprio a raccoglierli. È da sottolineare che, almeno sul piano prettamente formale, pure il trasferimento di un codice da una commessa ad un’altra si configura come una “triangolazione” che coinvolge il MAG RESI: il codice, infatti, come indica anche il modulo / documento per questa procedura (lo stesso utilizzato per la procedura di cui al punto precedente), viene trasferito dapprima dalla commessa al MAG RESI, e poi da questo alla nuova commessa. Si noti inoltre che per il trasferimento da commessa a commessa e quello da commessa a MAG RESI (e viceversa), pur comportando al massimo una variazione dell’ubicazione del codice, ma mai l’uscita dello stesso dai magazzini, non possono valere le stesse considerazioni fatte per le movimentazioni fra MAG GEN e magazzini periferici riguardo alla necessità di documenti cartacei (assenti in quest’ultimo caso): il trasferimento fra commesse e MAG RESI, infatti, non interessa solo la Funzione Magazzino, ma pure la Pianificazione (PNF o IGP6, da cui parte la richiesta) e pure l’Ufficio Acquisti (ACQ) e AMM, che devono essere informati per ragioni contabili. - Spedizione a terzi:
o in conto lavorazione, se ad esempio si tratta di un componente che appena giunto in cantiere dev’essere immediatamente spedito ad una Ditta esterna che ne realizzi un rivestimento, o un qualsiasi altro tipo di lavorazione, prima di poter procedere all’allestimento sull’imbarcazione;
o in conto riparazione; o in conto sostituzione; o in conto garanzia; o in conto restituzione; o in conto visione; o in omaggio;
o per campionatura gratuita.
6
In cantiere è ancora molto diffusa questa seconda denominazione, derivata dalla vecchia Ingegneria di Produzione.
- Trasferimento intersocietario dalla sede Benetti di Livorno a quella di Viareggio, o viceversa: si tratta di fatto dell’applicazione dei principi del transshipment7 alla realtà cantieristica, laddove ovviamente ciò risulti conveniente rispetto al lancio di un nuovo ordine al fornitore.
A titolo esemplificativo si riportano nelle pagine seguenti, nell’ordine:
1. la richiesta di trasferimento (fig. 44) di un codice (5 boccole) da una commessa (la FB240) ad un’altra (FB239);
2. una richiesta di spedizione (RdS), anch’essa inoltrata dal PNF / IGP (fig. 45), sulla base della quale il magazzino deve preparare il DDT per il trasferimento del materiale a terzi (oltre che contattare, se necessario, il corriere / vettore incaricato del trasporto); 3. il DDT associato alla stessa RdS (fig. 46).
7
Il transshipment è la spedizione di beni tra nodi differenti dello stesso livello della catena logistica, allo scopo di ottemperare a immediate necessità. Molto spesso esso è implementato dai rivenditori per andare incontro alla
1. In questo documento si rilevino, in particolare (cerchi rossi in fig. 44):
- la molteplicità di attori coinvolti nella procedura (IGP, da cui la richiesta viene inoltrata, MAG e ACQ);
- il ricorso alla già citata triangolazione: per essere trasferito dalla FB240 alla FB239, il materiale transita contabilmente dal MAG RESI;
- le diverse combinazioni ramo – fase – sequenza (una di partenza e una di destinazione), che rappresentano le “coordinate contabili” dell’articolo8: esse risultano del tutto indipendenti dalla codifica dell’oggetto fisico “boccole”, BOCC.BENE.002, che invece rimane sempre la medesima.
Figura 44: Richiesta di trasferimento materiale da una commessa ad un’altra
8
Il codice ramo – fase – sequenza rappresenta il legame tra il buono di prelievo (BP, non gestito dall’ERP aziendale; si veda il paragrafo. 5.3.3) e l’ordine di produzione (OdP); per questo esso assume un’importanza fondamentale, in quanto permette di gestire gli stati di avanzamento produttivi.
2. Oltre ai codici da trasferire (quali e quanti) e alla Ditta cui sono destinati, nella RdS devono essere indicati chiaramente modalità di trasporto, commessa di appartenenza e causale del trasferimento a terzi, tutte informazioni che devono essere riportate sul DDT associato.
3. Nel presente documento è di estrema importanza la sezione riservata al vettore / corriere (cerchiata in rosso in fig. 46), la cui compilazione attesta l’avvenuta presa in consegna da parte dello stesso. Si consideri comunque che i codici trasferiti rimangono sempre in carico su VM (quindi, almeno contabilmente, sotto la responsabilità del MAG), semplicemente con ubicazione “terzi” invece che nel MAG GEN o in un qualche magazzino periferico.
Fra le procedure elencate, quella che sicuramente presenta le criticità ed inefficienze più rilevanti e che può trarre i maggiori benefici dal progetto di tracciabilità delle merci preso qui in esame è la seconda, quella cioè che determina il passaggio dei codici immagazzinati (nel MAG GEN o nei magazzini periferici) alla PROD per il definitivo montaggio / allestimento sull’imbarcazione.
5.3.3 Il trasferimento dei codici dal magazzino alla produzione: il ciclo del buono di prelievo
La procedura ha inizio con la richiesta di uno o più codici al PNF da parte di un capo commessa (o “capo barca”), ovvero il soggetto che coordina i lavori di allestimento per una ben precisa imbarcazione.
Il PNF prepara subito il cosiddetto buono di prelievo (BP) per il codice / i codici appena richiesto/i, e ne invia tramite e-mail una copia al MAG GEN, per lasciare ai magazzinieri il tempo necessario a preparare la merce, ed una allo stesso capo barca.
Quest’ultimo firma il BP, e può o recarsi in prima persona al MAG GEN per effettuare il prelievo, oppure inviare un addetto appartenente al proprio team di commessa, ovviamente portando la copia firmata del BP (necessario al personale del MAG GEN per effettuare il riscontro col proprio BP).
Questo “delegato” non può però essere un addetto qualunque, bensì deve comparire su una lista indicante il personale autorizzato (dagli stessi capi barca) a effettuare i prelievi, redatta, tenuta aggiornata e periodicamente comunicata al MAG dai due capi area (ognuno responsabile di una coppia di capannoni di allestimento, quindi di 4 commesse).
Va precisato che, in realtà, ciò che il capo barca richiede rivolgendosi al PNF non sono i codici, dato che il più delle volte la codifica non è nota al personale della PROD, bensì l’oggetto in sé: capita quindi che la richiesta riguardi “due portelli di dimensioni 1200 x 800 mm da montare nella tal posizione sulla FB243”, e che sia il PNF a tradurla sul BP come “nr. 2 PORL.BENE.433”, oppure “nr. 1 PORL.BENE.421; nr. 1 PORL.BENE.424”.
Una volta effettuato il prelievo, la copia del BP inizialmente spedita dal PNF al MAG GEN può essere cestinata, poiché basta conservare la copia firmata dal capo commessa: questa è necessaria per scaricare da VM i codici prelevati, e sancire così formalmente il passaggio del materiale sotto la responsabilità della PROD, dopodichè può essere archiviata in un apposito cartolare in cui i vari BP sono ordinati in base al numero (progressivo) di emissione (senza distinguere fra le diverse commesse). Oltre alle giacenze di magazzino, devono essere aggiornati pure i file Excel riportanti le ubicazioni.
Si noti che il PNF, una volta contattato dal capo barca per emettere il BP, non viene più chiamato in causa: non vi è alcun tipo di feedback che consenta al PNF di essere informato circa l’esito del prelievo (del resto a questo Ufficio non interessa monitorare l’intera procedura).
L’analisi di questo processo ha consentito di evidenziare le seguenti problematiche:
- se è vero che il più delle volte il capo barca non conosce la codifica del materiale richiesto, non è così raro che pure i soggetti del PNF ignorino dei codici. Se si verifica tale circostanza, il PNF richiede al personale del MAG – telefonicamente o tramite e-mail, fornendo una descrizione dell’articolo e specificando la commessa coinvolta – quale sia il codice, in modo da poter preparare il BP.
- Indipendentemente da questo, tale iter si presta ad un elevato rischio di errori, dato che può capitare:
o che il PNF traduca in maniera errata una richiesta del capo barca, emettendo un BP per un codice diverso;
o che lo stesso capo barca descriva male il materiale / l’oggetto, inducendo nuovamente il PNF ad una traduzione errata.
o Il rischio è quanto meno raddoppiato se pure il PNF non conosce il codice. - L’ERP aziendale (VM) non consente di stampare i BP, che per questo devono essere
realizzati tramite Microsoft Access: si può intuire come la necessità di effettuare questo passaggio ulteriore (comunque manuale, anche se il programma va a “pescare” i codici da un’anagrafica articoli) aumenti ulteriormente il rischio di errori.
- Nel caso in cui i codici richiesti siano ubicati in uno dei magazzini periferici (presumibilmente quello in cui è collocata la commessa i cui lavori sono coordinati dal capo barca richiedente), la loro distanza dal punto in cui dovranno essere montati / utilizzati è minima, per cui la procedura descritta è di natura prettamente contabile (lo scopo è solo quello di scaricare la merce dal MAG a livello di ERP aziendale, sancendo il passaggio della responsabilità del codice alla PROD), e non aggiunge valore al processo. Anzi, essa spesso va a rallentare i lavori di allestimento, dato che in MAG GEN si accumulano i BP associati a tutte le commesse e che i prelievi non possono essere effettuati prima che siano stati completati quelli richiesti tramite i BP emessi precedentemente (logica FIFO).
o by-passando il PNF, e presentandosi direttamente in MAG GEN pretendendo il materiale (senza conoscerne la codifica, fra l’altro), magari richiedendo più unità dei codici rispetto a quelle riportate sul BP oppure codici aggiuntivi.
o Quando il capo barca invia al MAG GEN per il prelievo un addetto che non compare sulla lista del personale autorizzato;
o quando un capo barca esige una qualche priorità rispetto ai colleghi responsabili di altre commesse, adducendo come motivazione la maggiore urgenza del “suo” BP (in questo caso, il più delle volte, basterebbe semplicemente evitare di contattare all’ultimo momento il PNF).
- Come nel caso del materiale spedito dai fornitori in ingresso al MAG GEN, si presenta il problema dei codici costituiti da più componenti (i “kit”), in particolar modo quando questi vengono richiesti dalla PROD in momenti diversi: vi sono codici, infatti, che sono sì composti da miriadi di parti (minuteria, guarnizioni, alberi, cavetteria, ecc.) ma che vengono richiesti e movimentati sempre insieme, per cui il fatto di risalire ad un unico codice non causa problemi di alcun tipo per chi deve registrare i prelievi sul gestionale (il codice è a magazzino oppure no, senza ambiguità); ma vi sono moltissimi codici, come ad esempio motori, pompe, depuratori e altri impianti di varia natura, costituiti da particolari (o blocchi di particolari) che possono essere montati sulle imbarcazioni anche a giorni di distanza gli uni dagli altri. Si comprende che in questi casi il compito del personale di magazzino è arduo, in quanto:
o dal momento in cui il primo componente di un codice viene prelevato a quello in cui anche l’ultimo passa alla PROD il codice risulta “in sospeso”, in quanto non può essere scaricato da VM ma al contempo deve risultare in qualche modo che qualcosa è già stato prelevato mentre altri componenti sono ancora in giacenza. Per questo il PNF emette BP parziali invece dei normali BP “completi”, con l’indicazione / descrizione dei componenti del codice che devono essere prelevati: tali buoni, man mano che il materiale viene prelevato, si accumulano in un apposito raccoglitore (quelli relativi ad uno stesso codice vengono via via spillati a formare dei fascicoletti), da cui vengono trasferiti nel cartolare dei BP “chiusi” solo quando l’intero codice è stato prelevato e scaricato contabilmente. La procedura si complica dunque in maniera considerevole9.
9
In realtà, purtroppo, vengono emessi BP parziali pure per i codici non kit, ma di cui deve essere prelevato un numero di unità inferiore al totale in giacenza per la particolare commessa. Questo perché, se è vero che per il
o Se si escludono i BP parziali, non vi sono “tracce” del fatto che parte di un codice sia in magazzino e la restante parte sia imbarcata: non solo VM non contempla la gestione dei sottocomponenti di un codice, ma neppure i file Excel con le ubicazioni vengono in soccorso del personale di MAG, a meno che accanto a ogni codice non venga annotato il dettaglio di ciò che è ancora in giacenza (soluzione poco fattibile, data la quantità di codici in carico).
o Come il PNF può sbagliare a tradurre in codice un oggetto richiesto dalla PROD, a maggior ragione vi è il rischio che sbagli a emettere un BP parziale, riportando un elenco di componenti diversi da quelli che devono essere effettivamente imbarcati, oppure – caso più frequente – emettendo un BP normale invece che parziale. Se ciò accade, poiché il PNF non viene più contattato dopo l’emissione del BP, è assai probabile che il personale del MAG scarichi l’intero codice da VM (come indicato dal BP) nonostante l’addetto al prelievo autorizzato dal capo barca passi a prelevare solo ciò che gli serve. Ne deriva che i componenti non prelevati risultano imbarcati quando in realtà si trovano ancora sugli scaffali, il che causerà notevoli disagi nel momento in cui il capo barca si rivolgerà al PNF per far emettere un BP parziale per quei componenti.
o Allo stesso modo, può capitare che il PNF traduca correttamente una richiesta formulata in maniera erronea dal capo barca, oppure che richiesta e traduzione in codice siano corretti, ma che poi al momento del prelievo il capo barca abbia un qualche “ripensamento”: se quest’ultimo richiede un certo portello, ma successivamente ne preleva solo le cerniere, lasciando in magazzino le restanti parti del codice, si ripresenta la medesima situazione descritta al punto precedente.
Il diagramma di flusso a pagina seguente (fig. 47) riassume i passaggi principali della procedura con cui la PROD richiede i codici da prelevare presso il magazzino (MAG GEN o magazzini periferici).
gestionale), è vero anche che la procedura utilizzata dall’IGP per generare i BP tramite Access associa ad ogni tipo di codice in giacenza su una data commessa, una casellina che può essere “spuntata” solo nel momento in cui tutte le unità di quel codice vengono prelevate.
