Quello riportato sotto (fig. 48) è invece un esempio di BP (non parziale), in cui oltre al codice della commessa e del materiale, alla firma del capo barca, al numero del buono e alla data di emissione, nonché ad altre informazioni di natura contabile, compaiono il numero di unità richieste di ciascun codice e le rispettive ubicazioni (intesi in questo caso non solo come magazzini, ma proprio come ubicazioni a scaffale, scritte a penna da un addetto del MAG subito dopo l’invio del buono da parte del PNF consultando i file Excel di interesse).
Si riporta infine copia di un BP parziale (fig. 49), in cui si specifica come dell’impianto sottovuoto IMSV.JETS.008 debba essere prelevato dal MAG GEN (codificato come LIVORNO su VM) solamente il componente “quadro”.
5.3.4 Individuazione delle principali aree di intervento
Come visto, l’attenzione è stata focalizzata sui due processi ritenuti più critici e, dunque, maggiormente migliorabili attraverso l’implementazione del nuovo sistema di tracciabilità: il ricevimento del materiale a MAG ed il suo trasferimento da questo alla PROD, per il definitivo imbarco.
In particolare, per quanto riguarda il primo processo:
- la gestione dell’ingresso, e dunque della movimentazione dei componenti di un prodotto, è un punto critico del progetto, dato che attualmente essi non risultano codificati e che, quindi, non è possibile tracciarne i movimenti. Il sistema realizzato da DAXO prevedrà la codifica di tali oggetti, ed in più permetterà di associare i componenti ai rispettivi “codici padre” costruendo delle distinte base vere e proprie. - La gestione delle ubicazioni, attualmente non contemplata dall’ERP aziendale e
supportata solo dai fogli Excel tenuti aggiornati dal personale del MAG, sarà effettuata dall’applicativo DAXO: ogni magazzino sarà suddiviso per locazioni, e ogni locazione verrà associata ad una commessa.
- Le informazioni da stampare sull’etichetta contenente il codice a barre del prodotto dovranno essere:
o codice del prodotto in formato barcode; o codice del prodotto in chiaro;
o descrizione del prodotto;
o codice padre, nel caso si tratti di un componente.
- L’associazione tra codice in chiaro (Benetti) e codice a barre / codice RFID verrà effettuata automaticamente dall’applicativo DAXO;
- al momento dell’ingresso del materiale in magazzino può essere prevista la stampa di etichette adesive che risparmino al magazziniere l’incombenza di dover scrivere sulle scatole il codice della commessa di riferimento, oltre che numero e data d’ingresso della consegna.
- La produzione, gestione, e archiviazione della documentazione cartacea dovranno essere ridotte al minimo.
L’analisi del processo di trasferimento del materiale alla PROD, invece, induce a ritenere che possa risultare decisivo riuscire a gestire i buoni di prelievo direttamente dall’applicazione DAXO, poiché ciò consentirebbe di:
- fornire al personale di PROD (capo barca) uno strumento, su dispositivo mobile, in grado di analizzare l’ordine di produzione (OdP) e le giacenze di magazzino in modo tale da poter effettuare delle richieste più corrette e precise all’IGP;
- stampare sul buono di prelievo la locazione del materiale richiesto senza l’intervento dell’operatore di MAG;
- registrare lo scarico dal MAG su VM semplicemente richiamando lo specifico BP, senza dover digitare nuovamente i codici dei prodotti.
La soluzione progettuale proposta è volta a intervenire su questi punti, oltre che ad aggiungere alcune funzionalità che migliorino ulteriormente l’item management1 nel cantiere Benetti.
5.4 Una problematica chiave: i codici multi-componente
Dall’analisi delle procedure di ricevimento e accettazione del materiale approvvigionato a MAG e di prelievo dello stesso da parte della PROD, sicuramente quelle che dovrebbero beneficiare maggiormente delle migliorie che il progetto di tracciabilità si prefigge di apportare, si è già potuto rilevare come uno degli aspetti più critici da dover gestire sia rappresentato dalla codifica dei materiali. In particolare, è necessario focalizzare l’attenzione su quegli articoli attualmente identificati da un codice unico, ma costituiti da più componenti o gruppi di componenti approvvigionati e/o richiesti dalla PROD in momenti diversi: il fine che si vuole perseguire è infatti quello di identificare univocamente tutte quelle parti o insiemi che possono essere movimentati separatamente all’interno del cantiere, dato che presupposto fondamentale di un sistema di tracciabilità è l’identificazione (quindi la codifica) di ciò che si vuole (rin)tracciare.
Sia chiaro che codificare ogni singolo componente (vite, guarnizione o albero che sia) dei codici attuali, soluzione peraltro quasi impossibile da attuare, non solo non aiuterebbe, ma appesantirebbe in maniera notevole procedure e carichi di lavoro (soprattutto del personale di MAG), oltre a “ingolfare” un ERP già di per sé piuttosto obsoleto: a che servirebbe codificare
1
tutti i componenti di una lavastoviglie da imbarcare su una certa commessa, se comunque l’elettrodomestico viene sempre movimentato come blocco unico?
5.4.1 Il tentativo di IDEA
Ecco perché, purtroppo, non si può pensare di utilizzare in ottica tracciabilità la stessa (sotto)codifica impiegata per gestire le parti di ricambio (spare parts) di alcuni codici Benetti (soprattutto impianti quali pompe, motori e depuratori), creata dalla tedesca IDEA – nautic data solutions per venire incontro alle esigenze del cantiere in ambito manutentivo: tale codifica prevede l’aggiunta, al codice base Benetti a 11 campi (del tipo XXXX.YYYY.NNN, già descritto nel par. 4.2), di un ulteriore suffisso numerico a 4 campi (“.nnnn”, a numerazione progressiva), e per crearla l’IDEA si è avvalsa della manualistica fornita a corredo dei codici e messa a disposizione da Benetti.
Ecco dunque che, interrogando l’anagrafica articoli su VM, si può scoprire ad esempio che l’elettropompa della Gianneschi & Ramacciotti codificata come EPOM.G&RA.007 è costituita da centinaia di componenti codificati a 15 campi, come ad esempio la girante EPOM.G&RA.007.0005, o l’anello di tenuta EPOM.G&RA.007.0231. E, tanto per avere un’idea dei numeri in gioco, basti pensare che un compressore può essere “esploso” in più di 1500 componenti!
In realtà, tale codifica risulta eccessivamente dettagliata anche in ottica parti di ricambio: si consideri infatti che da quando un paio di anni fa l’ “esperimento IDEA” è partito, risulta siano stati effettuati solamente 90 ordini di acquisto (OdA) per parti di ricambio utilizzando la codifica a 15 campi, per un totale di 77 diversi componenti sui quasi 16000 codificati da IDEA e inseriti nell’anagrafica di VM. Il fatto che tali codici siano rimasti di fatto inutilizzati è certamente dovuto a carenze comunicative e negligenze in seno all’Azienda (gli attori che avrebbero dovuto utilizzarli non sono stati informati in modo adeguato circa la loro esistenza e le modalità di utilizzo, oppure pur essendone a conoscenza hanno continuato a ragionare in termini di “materiale non codificato”), ma è indubbio che codificare la minuteria, oppure componenti non critici da un punto di vista manutentivo, non aggiunge valore al processo di gestione ricambi.
Per di più, con una tale mole di codici emergono numerosi problemi di difficile risoluzione: - una recente analisi che ha avuto come oggetto il database IDEA, ovvero l’anagrafica
articoli di cui si serve la ditta fornitrice per gestire a distanza il progetto Benetti, e l’anagrafica di VM interna al cantiere, ha evidenziato che solo 4000 dei 16000
componenti sopra citati combaciano perfettamente, mentre i restanti codici a 15 campi su VM o riportano informazioni / descrizioni differenti, o addirittura sono codificati diversamente (l’unica spiegazione è che il personale Benetti, nell’utilizzare il gestionale, abbia inavvertitamente modificato l’anagrafica articoli, di fatto invalidandola).
- Il fatto che gran parte delle giacenze siano suddivise per commessa determina che vi siano più articoli di fatto identici, ma codificati (a 11 campi) in maniera diversa (in particolare, è l’ultima terna “.NNN” a variare). Nel caso in cui questi codici siano costituiti da più componenti a loro volta codificati (a 15 campi), tutti i sotto-codici coinvolti rappresentano dei “doppioni” che appesantiscono il sistema.
- Si consideri inoltre che molti componenti sono comuni a più codici anche completamente diversi (ad esempio, uno stesso alberino può far parte di 7 diversi tipi di motore, di 3 elettropompe e 4 compressori): ebbene, questi componenti compaiono nell’anagrafica articoli tante volte quanti sono i macro-codici di appartenenza, con altrettanti codici differenti.
Per queste ad altre problematiche, la Benetti di Livorno ha recentemente deciso di rivedere il sistema di codifica IDEA, snellendolo:
- dapprima, “ripulendo” completamente l’anagrafica articoli di VM dai codici a 15 campi;
- successivamente, creando dei nuovi codici a 15 campi solo per i componenti critici in termini di gestione delle spare parts (non più di un migliaio, da individuare in collaborazione con l’Ufficio Tecnico o TEC, altri soggetti interni al cantiere e le Ditte fornitrici, peraltro non sempre coincidenti con quelle costruttrici).
Tale opera di “riprogettazione” risulta tutt’oggi in corso.
Di seguito (fig. 50) sono mostrati due “screenshots” dall’anagrafica articoli di VM, in cui è possibile riconoscere i codici IDEA a 15 campi ordinati in base al suffisso finale “.nnnn”. In particolare, il secondo screenshot evidenzia come pure per un singolo codice a 11 campi possano esistere più sotto-codici diversi (addirittura 6) per identificare uno stesso componente (“2-way solenoid valve”).
Figura 50: Codici IDEA per l’identificazione dei componenti
Sebbene il fine di un sistema di codifica in ottica tracciabilità sia completamente diverso da quello appena descritto, e nonostante il primo risulti presumibilmente ancor più complesso da implementare (in linea teorica, tutti i codici dovrebbero essere passati in rassegna dal personale dei diversi Uffici e reparti, in collaborazione con i fornitori, per individuare i blocchi di componenti da identificare con un codice unico), quanto riportato può dare quanto meno un’idea della criticità della questione.
5.4.2 Il coinvolgimento dei fornitori strategici
Ecco perché LOG ha ritenuto opportuno contattare quei fornitori per cui tutti o buona parte dei codici approvvigionati presentano i problemi sopra descritti, per fissare degli incontri in via del tutto informale e introdur loro alla questione: l’intento è stato quello di capire se vi fosse la possibilità di sfruttare eventuali codifiche “interne” (se non addirittura codici a barre) utilizzate dal fornitore, e in caso affermativo di porre le basi (a livello di interfacce organizzative e informative) per un’integrazione.
Il compito è stato – ed è tuttora, dato che gli incontri proseguiranno per alcune settimane – assai arduo, e non certo per l’elevato numero di Aziende coinvolte o per mancanza di collaborazione. Anzi:
- almeno inizialmente, è sufficiente individuare non più di 15 – 20 fornitori strategici in ottica codifica: allacciati i contatti con questi, rimangono pochi i codici “kit” critici da gestire;
- almeno per quanto riguarda i fornitori finora interpellati, la risposta è stata buona: indipendentemente dall’esistenza o meno di codifiche interne, dalla loro sfruttabilità da parte di Benetti, nonché dall’attuale livello di automazione con cui essi gestiscono i prodotti che approvvigionano al cantiere (impiego o meno di barcode), quasi tutti si sono mostrati estremamente disponibili a venire incontro alle esigenze di Benetti. Del resto, un’integrazione operativa basata sulla condivisione delle codifiche dei materiali ordinati non può che portare benefici ad entrambe le parti, dato che le procedure amministrative risulterebbero agevolate e, quindi, i rapporti commerciali migliori.
La fase più critica si colloca invece a monte, in seno a Benetti, ed è costituita dall’individuazione dei fornitori da contattare. L’ERP VM, infatti, non gestisce (come visto) i codici multi-componente, il che non consente di effettuare alcun tipo di interrogazione utile allo scopo. Le uniche informazioni utilizzabili per risalire ai fornitori cercati sono infatti:
- le descrizioni dei singoli codici, reperibili ad esempio richiamando la voce “Ordini di Acquisto” dal menu “Applicazioni”, e una volta selezionato l’ordine e lo specifico articolo dall’apposita maschera (fig. 51) cliccando sul tasto “Specifiche di Linea”. Si tratta in realtà di un breve elenco delle caratteristiche costruttive e funzionali di massima del codice, e non è di molto aiuto: un articolo può infatti essere composto da
numerosi elementi senza che ciò compaia sulle specifiche, oppure al contrario possono comparire numerosi elementi anche se di fatto dentro il cantiere il codice viene sempre movimentato come un unico blocco.
Figura 51: Specifiche di Linea di un codice richiamate dalla finestra “Ordini di Acquisto”
- I fascicoli DDT – OdA che riempiono l’archivio del MAG GEN, contenuti in appositi cartolari e ordinati per numero di commessa (yacht) e fornitore: la descrizione dei codici che compare su questi ordini è esattamente la stessa riportata nelle “Specifiche di Linea” su VM, ma in questo caso l’associazione con i DDT, nonché l’indicazione dei diversi numeri di ingresso a fianco dei componenti dei codici (nel caso in cui questi siano stati spediti dal fornitore in momenti successivi), consentono una ricerca più efficace. Peccato però che tale ricerca sia resa quasi impossibile dall’enorme quantità di fascicoli presenti in archivio.
- I codici a 15 campi creati da IDEA per gestire le spare parts di impianti e di altri articoli soggetti a guasto o rottura: sebbene, come detto, questi si spingano ad un livello di dettaglio eccessivo per il progetto di tracciabilità, l’elenco dei codici (a 11 campi) per cui esistono più sottocodici a 15 campi può dare una pur minima idea di
quali siano gli articoli più complessi e – almeno presumibilmente – destinati ad essere movimentati in blocchi di componenti separati.
La conclusione cui si giunge è che, essendo questo il gestionale a disposizione dell’Azienda (o quanto meno le sue funzionalità attualmente sfruttate), solo la PROD possiede il know-how necessario a stabilire quali codici (e quindi quali fornitori) sono quelli critici, anche se di fatto, grazie all’esperienza “sul campo” acquisita nel tempo, pure il personale del MAG ne ha un’idea più o meno precisa.
La gestione di buoni di prelievo parziali, il “via vai” del personale di PRO per ritirare il materiale da imbarcare, spedizioni scaglionate dei codici ordinati da parte dei fornitori, sono solo alcune delle situazioni all’ordine del giorno nel MAG GEN, con la conseguenza che spesso i responsabili del MAG detengono una conoscenza dei codici almeno pari a quella dei capi barca.
Ecco dunque come ho agito per risalire ai fornitori da interpellare:
1) Per prima cosa, ho consultato l’intera anagrafica articoli memorizzata su VM (circa 45.000 codici, molti dei quali ormai imbarcati e non più in giacenza), e ho appuntato tutti i codici (a 11 campi) per i quali esistesse almeno un componente codificato a 15 campi, ottenendo un lista di circa 100 articoli;
2) Insieme al personale del MAG, ho eliminato dalla lista tutti quei codici: - che nessuno ricordava di aver mai movimentato in blocchi separati; - riferibili a fornitori che ormai non servono più il cantiere.
Laddove vi fossero i maggiori dubbi, ho consultato i cartolari in archivio con i fascicoli DDT – OdA, per cercare di capire come dovessero essere trattati i relativi codici.
3) Tramite opportune interrogazioni a VM, sono risalito ai fornitori dei codici rimanenti; 4) Con l’ausilio del personale di MAG, e consultando alcuni altri fascicoli DDT – OdA
in archivio, oltre che vecchi buoni di prelievo parziali ormai evasi, ho aggiunto ulteriori fornitori all’elenco così ottenuto.
Una volta individuato questo primo gruppo di fornitori, che ovviamente potrà essere aggiornato e arricchito in qualsiasi momento, ho cercato di operare una loro classificazione di massima (sempre con l’aiuto dei responsabili dei MAG) sulla base della percentuale di codici kit sul totale degli articoli ordinati. Senza fare riferimento a cifre esatte (non ricavabili da
VM, a meno di passare in rassegna insieme a personale esperto tutte le anagrafiche articoli associate ad ogni fornitore), ma semplicemente facendo affidamento all’esperienza dei miei collaboratori, ho suddiviso i fornitori in 4 sottoinsiemi:
- fornitori i cui codici sono tutti / quasi tutti kit; - fornitori per cui la maggior parte dei codici sono kit; - fornitori per cui alcuni codici sono kit;
- altri fornitori di codici kit.
Ovviamente, spostandosi dall’ultimo al primo sottoinsieme la criticità delle forniture in ottica tracciabilità va aumentando.
Tuttavia, tale classificazione – peraltro non fondata su cifre esatte, va ribadito – fornisce un’informazione solo parziale: un’Azienda che fornisce al cantiere materiale di continuo e per milioni di euro ogni anno, di cui solo un terzo è costituito da codici kit, dovrà essere considerata più importante di una che approvvigiona solo codici kit, ma con frequenza ridotta e per un importo totale di poche migliaia di euro.
Il passo successivo è stato dunque quello di consultare alcuni file Excel disponibili nelle cartelle condivise dell’Intranet aziendale, riportanti le analisi ABC di Pareto di tutti i fornitori del cantiere per il periodo agosto 2004 – febbraio 20072, e suddivise (oltre che per periodo di competenza) in base al tipo di costo sostenuto.
In particolare, per i fornitori precedentemente individuati, sono risalito agli importi totali riferiti alla tipologia di costo 1 (vd. par. 4.1), quella cioè relativa ai materiali.
La seguente schermata Excel (fig. 52) riporta l’elenco dei fornitori ripartiti in categorie e dettagliato con i costi dei materiali approvvigionati nel periodo preso a riferimento, in termini sia assoluti che percentuali rispetto al totale delle forniture per la stessa tipologia di costo (gli importi sono stati cancellati per ovvi motivi di riservatezza).
2
Si ricordi che per l’Azienda l’anno contabile ha inizio il 1 settembre e termina il 31 agosto dell’anno (solare) successivo, quindi l’intervallo indicato comprende 2 anni contabili più il periodo settembre 2006 – febbraio 2007.
Figura 52: Fornitori di codici “kit”
Come accennato, la risposta da parte dei primi fornitori interpellati è stata buona, a riprova del fatto che un’integrazione fra le parti non può che giovare ad entrambe. È ovvio però che bisognerà vedere chi effettivamente passerà dalle parole ai fatti, impegnando fatica e risorse per favorire l’integrazione anche a livello “hardware”.
5.5 Struttura della soluzione proposta
Sulla base di quanto emerso dall’analisi dei processi attuali, quella proposta è una soluzione informatica strutturata su due diversi livelli applicativi:
- un’applicazione Front Office (FO): installata sui palmari industriali, rappresenta il vero cuore del sistema. Essa è alimentata dall’applicazione Server / Back Office, e sfruttando il lettore barcode in dotazione permetterà di automatizzare e velocizzare le attività di interesse.
- Un’applicazione Back Office (BO): essa costituirà un’integrazione all’attuale sistema gestionale, ed in particolar modo permetterà a Benetti di disporre di un sistema parallelo flessibile in grado di soddisfare appieno le esigenze manifestate. Il modulo
Server del BO renderà possibile il (necessario) dialogo con l’attuale ERP aziendale, dando vita ad un’interoperabilità che, in una direzione (dati da VM al BO DAXO), alimenterà la base dati necessaria al nuovo applicativo per espletare le funzionalità previste, e nell’altra (trasmissione dal BO DAXO a VM) consentirà di trasferire (e quindi di registrare) sull’ERP Benetti le transazioni eseguite dall’applicativo stesso. È grazie alla struttura modulare del BO, inoltre, che in futuro sarà possibile arricchire il sistema di ulteriori funzionalità.
Di seguito (fig. 53) viene riportata una rappresentazione schematica della soluzione proposta.
Figura 53: Schema logico della soluzione proposta da DAXO
5.5.1 Applicazione Front Office
L’applicazione FO permetterà di gestire le seguenti attività: 1. autenticazione;
2. registrazione del materiale in arrivo con evasione dell’ordine fornitore di riferimento; 3. emissione delle richieste di prelievo, verso l’IGP, da parte del personale di PROD
(capo barca);
4. gestione dei buoni di prelievo;
5. rintracciabilità e disponibilità di un articolo all’interno del MAG GEN o dei magazzini periferici;
6. stampa di etichette con codice a barre;
7. interrogazione del magazzino e ricerca delle locazioni vuote; 8. registrazione dell’inventario di magazzino;
9. visualizzazione dei componenti di un articolo.
L’applicazione FO sarà sviluppata in modalità off-line; l’aggiornamento dei dati sarà garantito dall’applicazione stessa e avverrà in modalità wireless.
1. Autenticazione: ad ogni specifica applicazione potrà accedere solo il personale autorizzato, quindi all’apertura della stessa sarà richiesta l’autenticazione tramite utente e password. Una volta avuto accesso al sistema, l’utente potrà utilizzare le funzionalità di sua competenza.
2. Registrazione del materiale in arrivo: in fase d’ingresso merce, il magazziniere potrà selezionare gli ordini a fornitore cui corrisponde il materiale arrivato, e nella maschera che verrà visualizzata, con l’aiuto del lettore laser e delle etichette barcode, potrà selezionare l’articolo indicando, sempre tramite palmare, la quantità caricata.
La procedura provvederà ad evidenziare eventuali differenze riscontrate con l’ordine e ad aggiornare l’applicativo DAXO comunicando l’avvenuto carico e le altre informazioni necessarie.
Il magazziniere potrà attribuire ad ogni riga d’ordine il layout.
Una volta selezionato il menu corrispondente a tale funzione (“Evasione ordine fornitore”), l’utente avrà a disposizione l’elenco di tutti gli ordini a fornitore ancora aperti, ed in particolare potrà vedere: lo stato dell’ordine (“pallino” verde se completamente aperto, giallo se evaso parzialmente, rosso se evaso totalmente), il numero e la data dell’ordine, il codice e la ragione sociale del fornitore, la commessa di riferimento, la data prevista di consegna, eventuali note3.
Selezionando la testata dell’ordine si entrerà nel dettaglio, con la finestra successiva che mostrerà: stato della riga (vd. “testata documento”, al punto 12 del par. 5.5.2), codice e descrizione dell’articolo, la quantità ordinata e quella evasa, la zona / area di ubicazione (con il dettaglio di corridoio, traversa e altezza4), commessa di riferimento, specifica di linea5.
Lo stato “rosso” della riga (operazione conclusa) sarà attribuito dall’applicazione in base alla quantità evasa rispetto alla quantità ordinata, ma pure in base alla presenza o meno
3
I dati all’apertura saranno ordinati per ragione sociale del fornitore.
4
Da questo punto in poi, i termini “corridoio”, “traversa” e “altezza” saranno utilizzati per indicare quelli che nel par. 4.3 erano stati identificati, rispettivamente, come “scaffale”, “sezione” e “livello” (o “piano”).
della locazione: se ad una riga non sarà associata alcuna locazione, essa rimarrà nello stato “giallo”, segnalando così al magazziniere la necessità di ubicare i codici corrispondenti. L’utilizzo del lettore laser aiuterà l’operatore a selezionare la riga d’ordine specifica, e ad ogni lettura la quantità evasa verrà incrementata di 1; in alternativa potrà essere l’utente, tramite tastiera, ad inserire la quantità totale caricata.
Una volta confermato l’inserimento dei dati, l’operatore potrà decidere se comunicare il movimento di carico all’applicativo oppure sospendere l’operazione per riprenderla in un momento successivo. Nel primo caso, il sistema esigerà numero, data e tipo (“Bolla” o “Fattura”) del documento del fornitore, e una volta confermata l’operazione l’ordine sparirà dal display del palmare.
Ad ogni modo, il carico a MAG non potrà essere confermato fino a quando l’operatore non avrà attribuito ad ogni singola riga dell’ordine una locazione.
3. Emissione delle richieste di prelievo: la richiesta di prelievo è un’attività di competenza del capo barca. Per poterla inoltrare, egli dovrà interrogare il sistema per verificare la disponibilità del materiale all’interno dei magazzini.
Se tale verifica avrà avuto esito positivo, l’applicazione dovrà permettere all’utente di selezionare il codice desiderato ed indicarne la quantità da prelevare.
Una volta selezionato il menu corrispondente, “Richiesta Prelievo”, si aprirà una maschera di selezione, attraverso la quale il capo barca indicherà la commessa per cui dev’essere effettuato il prelievo. Ogni utente sarà abilitato a inoltrare richieste solo per le commesse di sua competenza.
Mediante la maschera di selezione si potrà selezionare uno specifico magazzino, mentre l’interrogazione di default riguarderà tutte le aree di stoccaggio associate alla commessa di riferimento.
Effettuata la selezione, l’utente avrà a disposizione l’elenco dei codici presenti nel magazzino e per la commessa specificati, ed in particolare saranno visualizzati: stato della riga, codice e descrizione dell’articolo, giacenza, quantità richiesta, ubicazione (zona, corridoio, traversa, altezza), specifica di linea.
A questo punto sarà sufficiente posizionarsi sulle righe di interesse e indicare la quantità da prelevare. Una volta completata la selezione l’operazione potrà essere confermata, e la richiesta perverrà all’IGP.
4. Gestione dei buoni di prelievo: una volta che l’IGP avrà convalidato le richieste del capo barca, sull’applicazione BO verrà creato un buono di prelievo gestibile direttamente dal magazziniere.
Nell’apposito menu (“Buoni di Prelievo da evadere”) l’utente disporrà dell’elenco dei buoni di prelievo da gestire, ed in particolare visualizzerà le seguenti informazioni: stato del buono (verde se completamente aperto, giallo se evaso parzialmente, rosso se evaso totalmente), numero e data dello stesso, richiedente, operatore designato per prelevare il materiale, commessa di riferimento6.
Selezionando la testata del buono, si aprirà una finestra con riportate le seguenti informazioni di dettaglio: stato della riga (vd. “testata documento”, al punto 12 del par. 5.5.2), codice e descrizione dell’articolo, giacenza, quantità richiesta ed evasa, ubicazione (zona, corridoio, traversa, altezza), specifica di linea7.
L’utilizzo del lettore laser supporterà l’operatore nella ricerca e selezione della specifica riga del buono, e ad ogni lettura la quantità evasa si incrementerà di 1. In alternativa, sarà direttamente l’utente ad inserire la quantità totale da prelevare tramite tastiera.
A questo punto l’operatore potrà decidere se confermare il prelievo, comunicando così all’applicativo DAXO l’avvenuto scarico dal MAG, o se invece sospendere l’operazione per riprenderla in un momento successivo.
Il richiedente, sul proprio palmare, potrà visualizzare in tempo reale lo stato effettivo del buono, oppure potrà essere avvisato con un “alert” nel momento in cui il materiale da prelevare sarà stato preparato.
5. Rintracciabilità di un articolo: per verificare la disponibilità e l’ubicazione di un articolo l’operatore dovrà accedere alla funzione ”Anagrafica articoli”.
Si aprirà una maschera di selezione che permetterà all’utente di ricercare un articolo per codice o per descrizione (informazioni che dovranno essere inserite manualmente).
In questa fase saranno attivi anche il lettore laser, che potrà essere utilizzato per selezionare l’articolo, e un “check box” per visualizzare tutti gli articoli via via selezionati.
Una volta effettuata la selezione si avrà accesso ad una seconda maschera, che permetterà di visualizzare e gestire: codice e descrizione dell’articolo, unità di misura per il carico e lo scarico, confezione di vendita, pezzi per confezione, codice a barre, (eventuale) codice RFID (nessuna di queste informazioni sarà modificabile).
6
I dati all’apertura saranno ordinati per numero per buono.
Un’ulteriore finestra consentirà di visualizzare anche una tabella contenente: uno o più magazzini, la zona relativa al magazzino, il corridoio relativo alla zona, la traversa relativa al corridoio, l’altezza relativa alla traversa, la giacenza relativa alla locazione.
Da tale maschera sarà possibile trasferire un articolo da una locazione ad un’altra operando sulla riga associata, oppure potrà essere inserita una nuova ubicazione semplicemente aggiungendo una riga.
Giacenza e disponibilità saranno suddivise per locazione.
Per i prodotti costituiti da più componenti sarà possibile visualizzare l’elenco di questi ultimi, ed in particolare saranno indicati il codice e la descrizione dell’articolo, l’unità di misura e la quantità necessaria.
In ogni momento, ovviamente, sarà possibile richiamare la finestra / maschera precedente. 6. Stampare l’etichetta con il codice a barre: per effettuare tale operazione basterà accedere
alle funzioni “Anagrafica articoli” oppure “Evasione ordine a fornitore”, e seguire la procedura che guiderà alla selezione dell’articolo e alla stampa della relativa etichetta nel formato prestabilito. Al momento di cliccare sul pulsante “Stampa”, la procedura richiederà l’inserimento del numero di etichette da stampare.
Il formato dell’etichetta e le informazioni da riportarvi sono, ad oggi, ancora da definire. Nel momento in cui il sistema sarà avviato, per garantirne l’efficacia a regime, gli operatori dovranno aver applicato su ogni articolo presente in magazzino (nei limiti del possibile8) la relativa etichetta.
7. Interrogazione del magazzino e ricerca delle locazioni vuote. Per verificare la capacità residua di un magazzino o lo stato di occupazione di una specifica locazione, l’utente potrà richiamare la funzione “Interrogazione di magazzino”: l’operatore avrà a disposizione una maschera di selezione in cui indicare il magazzino da controllare e, eventualmente, la singola ubicazione.
Una volta effettuata le selezione l’applicazione mostrerà: codice e descrizione dell’articolo, zona relativa al deposito, corridoio, traversa e altezza, giacenza relativa alla locazione.
Nella stessa maschera l’utente avrà a disposizione un secondo pannello, in cui l’applicazione indicherà le locazioni vuote evidenziandone le coordinate (zona, corridoio, traversa, altezza).
8
Chiaramente, non potranno essere etichettate tutte le rondelle di una confezione da 1500 pezzi, che pure potrebbero essere prelevate e movimentate separatamente.
8. Inventario di magazzino e chiusura giornaliera: accedendo a tale funzione, l’utente avrà subito modo di inserire, mediante un’apposita maschera, il deposito che sta inventariando, la tipologia dei codici da leggere ed eventuali note. Una volta confermati i dati inseriti, sarà possibile accedere alle righe delle transazioni e registrare gi articoli inventariati. I campi visualizzati nella maschera di inserimento saranno: codice e descrizione dell’articolo, quantità inventariata, commessa di riferimento, zona, corridoio, traversa e altezza.
L’utilizzo del lettore laser aiuterà l’operatore a selezionare la specifica riga d’ordine e, come visto in precedenza, o la quantità si incrementerà di 1 ad ogni lettura, o in alternativa l’utente potrà inserire la quantità totale scaricata tramite tastiera.
L’operatore potrà decidere se confermare il movimento, comunicandolo così in automatico all’applicativo DAXO, oppure sospendere l’operazione per riprenderla in un secondo momento.
L’applicazione permetterà di effettuare la stampa della situazione e l’elenco delle operazioni effettuate per un determinato magazzino.
9. Visualizzazione dei componenti di un prodotto: per ogni procedura che possa contemplare la gestione di codici “kit”, i singoli componenti saranno visualizzabili subito sotto il codice “padre”, (eventualmente) appena spostati sulla destra.
Si consideri ad esempio l’articolo A, formato da A1 e B1: ciò che l’operatore visualizzerà sul proprio palmare, nel caso di buono di prelievo da evadere, sarà una tabella di questo tipo (tab. 9):
Cod.Art. Descrizione Giac QtaOrd QtaEva Zona Corr Trav Alt
A …. .. .. .. .. .. .. ..
A1 … .. .. .. .. .. .. ..
B1 … .. .. .. .. .. .. ..
Tabella 9: Possibile finestra di selezione del materiale da prelevare con buono di prelievo in caso di codice multi-componente
5.5.2 Applicazione Back Office
Per poter supportare le esigenze del FO, l’applicazione Back Office dovrà gestire le seguenti informazioni:
1. anagrafica articoli di magazzino (giacenza e ubicazione); 2. anagrafica distinte basi;
3. anagrafica magazzini; 4. anagrafica locazioni;
5. associazione magazzino / locazioni; 6. anagrafica commesse;
7. associazione commessa / magazzino / locazioni; 8. anagrafica utenti;
9. associazione utenti / commesse; 10.associazione utenti / funzioni; 11.anagrafica fornitori;
12.anagrafica repertori; 13.ordini di acquisto; 14.ordini di produzione;
Oltre a gestire queste informazioni, l’applicazione dovrà permettere di: 15.evadere un ordine d’acquisto;
16.creare buoni di prelievo;
17.spostare un articolo da una commessa ad un'altra o da un magazzino / locazione ad un altro/a;
18.visualizzare la giacenza di un articolo;
19.visualizzare il livello di stoccaggio di un magazzino / locazione;
20.visualizzare l’elenco degli articoli presenti in magazzino per una determinata commessa;
21.visualizzare l’elenco dei movimenti di un articolo.
1. Anagrafica articoli. L’anagrafica degli articoli conterrà le informazioni relative ai prodotti e ai componenti codificati, ed in particolar modo: tipologia dell’articolo (prodotto o componente), codice, descrizione, unità di misura, disponibilità (calcolata come dato di riepilogo), specifica tecnica.
Gli articoli importati da VM non potranno essere modificati, mentre quelli registrati direttamente sull’applicazione DAXO potranno essere gestiti sotto ogni aspetto.
All’interno dell’anagrafica articoli sarà possibile accedere al dettaglio delle disponibilità, e quindi visualizzare per ogni articolo uno o più magazzini di stoccaggio, per ognuno di questi zona, corridoio, traversa e altezza, ed infine la giacenza.
Nessuno di questi dati potrà essere modificato.
2. Anagrafica distinte basi. Essa conterrà le informazioni relative ai codici “padre” e ai singoli elementi che li compongono, e consentirà di gestire e mostrare le rispettive associazioni.
Saranno visualizzati codice e descrizione dell’articolo, l’elenco dei componenti associati e, per ognuno di questi, codice, descrizione, unità di misura e quantità.
Sarà prevista una funzione di ricerca dei componenti, tramite la quale:
o selezionando un articolo sprovvisto di distinta base, l’applicazione consentirà associarvene una;
o selezionando invece un codice cui è già associata una distinta base, sarà possibile visualizzare e gestire tutti i suoi componenti.
3. Anagrafica magazzini. Tale anagrafica consentirà di codificare tutti i magazzini presenti in Benetti. Essa potrebbe anche essere acquisita da VM, ma per non appesantire il gestionale ed evitare di generare problemi di sincronizzazione con l’applicativo DAXO è stato deciso di gestirla manualmente.
I campi e le informazioni visibili riguarderanno solo il codice e la descrizione del magazzino stesso.
4. Anagrafica locazioni: essa permetterà di codificare tutte le locazioni gestite all’interno dei magazzini, e le informazioni saranno divise, per livello di dettaglio crescente, in zona, corridoio, traversa ed altezza.
5. Associazione magazzino / locazioni: questa associazione permetterà di gestire una stessa locazione all’interno di magazzini diversi, senza dover replicare il dato.
Ad esempio, se nei magazzini identificati dal sistema come 1 e 2 è presente la locazione A1, nell’anagrafica locazioni verrà registrata una sola volta A1 mentre nell’associazione magazzino / locazione saranno registrati tutti e due i magazzini, e sarà associata ad entrambi la locazione A1.
6. Anagrafica commesse: essa permetterà di codificare le diverse commesse aperte. Pure in questo caso, nonostante fosse possibile importare l’anagrafica direttamente dall’ERP Benetti, si è optato per una gestione manuale della stessa.
I campi e le informazioni visibili riguarderanno solo il codice e la descrizione delle commesse.
7. Associazione commesse / magazzino / locazioni: essa permetterà di attribuire delle aree di magazzino, e quindi un ben preciso insieme di locazioni, ad una determinata commessa. Ciò consentirà di:
o agevolare l’introduzione dei dati da parte dell’utente, il quale visualizzerà solo le informazioni congrue con l’operazione che sta effettuando;
o facilitare le interrogazioni relative ad una commessa e alla presenza dei materiali ad essa associati;
o monitorare più efficacemente l’attività di ubicazione dei codici associati ad una certa commessa in una ben precisa locazione.
Nelle locazioni non associate ad alcuna commessa sarà possibile ubicare codici di tutte le commesse.
8. Anagrafica utenti: essa conterrà l’elenco del personale abilitato all’utilizzo delle applicazioni BO e FO.
9. Associazione utenti / commesse: è questa associazione a determinare l’accesso ai dati e la loro visibilità da parte di ogni singolo utente. Ad esempio, il capo barca che lavora sulla sola commessa FB240 non potrà interrogare il sistema per ottenere informazioni riguardanti la FB241.
10.Associazione utenti / funzioni: essa consentirà di abilitare o disabilitare, per ogni singolo utente, le funzionalità del BO e del FO.
11.Anagrafica fornitori: l’anagrafica fornitori conterrà le informazioni (codice e ragione sociale) relative a tutti i fornitori dei codici immagazzinati nel cantiere Benetti.
12.Anagrafica repertori: essa gestirà le informazioni contabili da indicare al momento della creazione di un documento di movimentazione tra depositi o tra commesse.
Tale informazione serve all’AMM per attribuire correttamente la voce di spesa ad un determinato articolo per una certa commessa (vd. anche il par. 4.1.4, relativo ai repertori). Le informazioni da gestire sono capitolo, articolo, voce e descrizione.
13.Ordini d’acquisto: si tratta dell’elenco degli ordini d’acquisto da evadere totalmente o parzialmente. Le informazioni visualizzate saranno:
o lista ordini: stato dell’ordine (verde se completamente aperto, giallo se evaso parzialmente, rosso se evaso totalmente), numero e data del documento, codice e ragione sociale del fornitore, commessa.
o Testata documento: numero e data del documento, codice e ragione sociale del fornitore, commessa, magazzino in cui dev’esser effettuato il carico contabile, eventuali note.
o Righe documento: stato della riga (verde se completamente aperta, giallo se evasa parzialmente, rosso se evasa totalmente), codice, descrizione e unità di misura dell’articolo, quantità ordinata ed evasa, commessa.
All’interno della maschera di gestione ordini, semplicemente cliccando su un pulsante, potranno essere visualizzati i carichi effettuati per l’ordine selezionato, mentre un secondo pulsante rimanderà alla locazione dei singoli articoli.
Gli ordini chiusi non verranno più visualizzati nell’elenco, ma potranno comunque essere richiamati tramite una specifica funzionalità. L’utente, attraverso un’interfaccia estremamente “friendly”, potrà decidere di ordinare i dati visualizzati come meglio crede.
14.Ordini di produzione: questa anagrafica conterrà l’elenco degli OdP da gestire e combinata alle giacenze di magazzino, consentirà a DAXO di gestire la creazione dei buoni di prelievo. Gli OdP non saranno visualizzati dall’applicazione.
15.Evasione degli ordini d’acquisto: l’evasione di un ordine di acquisto (OdA) verrà eseguita esclusivamente tramite FO (vd punto 2 del par. 5.5.1, “Registrazione materiale in arrivo”), mentre l’applicazione BO registrerà i movimenti di carico dando la possibilità all’operatore di visualizzarli e, eventualmente, gestirli / modificarli prima di trasferirli al gestionale.
Le informazioni visualizzate saranno:
o lista documenti di carico: numero e data del documento, codice e ragione sociale del fornitore, commessa, numero e data dell’ordine di riferimento.
o Testata documento: numero e data del documento, codice e ragione sociale del fornitore, commessa, magazzino di carico ed eventuali note.
o Righe documento: codice e descrizione articolo, unità di misura, quantità caricata, commessa, zona, corridoio, traversa e altezza.
16.Creazione dei buoni di prelievo: al termine del mese di novembre 2007, la procedura di creazione dei buoni di prelievo doveva ancora essere analizzata nel dettaglio.
17.Movimentazione tra commesse o tra magazzini / locazioni: spesso capita che un articolo venga spostato da una commessa ad un'altra o tra un magazzino / locazione e un altro/a. Per eseguire questa operazione l’operatore, attraverso apposito menu, indicherà il codice dell’articolo da movimentare; l’applicazione selezionerà le commesse, i magazzini e le locazioni di e permetterà all’operatore di indicare per ogni riga una nuova destinazione, quindi una nuova commessa (non necessaria per gli spostamenti tra magazzini), un nuovo magazzino e una nuova locazione. Il magazzino può anche essere il MAG RESI.
18, 19, 20 e 21: Visualizzazioni e stampe: al termine del novembre 2007, anche le query di visualizzazione e le stampe di riepilogo (con le relative informazioni) risultavano ancora da analizzare nel dettaglio.
5.5.3 Sviluppi futuri
L’applicazione BO così strutturata potrà essere sfruttata come base di partenza per sopperire ad alcune mancanze dell’attuale ERP aziendale, attraverso l’aggiunta di nuove funzionalità non necessariamente connesse all’warehouse management:
- la stampa di un’etichetta di ingresso per il materiale (riportante data e numero progressivo di entrata ed il codice della commessa), che eliminerebbe completamente il ricorso al “pennarello” da parte del magazziniere che scarica la merce.
- L’archiviazione elettronica di documenti cartacei quali gli OdA ei DDT;
- la gestione ottimale della pianificazione produttiva (dotando di palmari altri soggetti interni all’Azienda oltre al personale di MAG e PROD);
- il monitoraggio degli approvvigionamenti e la possibilità di offrire ai fornitori strategici canali e strumenti per interagire con Benetti nell’ottica di una gestione just in time (JIT) delle consegne;
- la creazione di KPI per la valutazione delle performance operative.
Questi sviluppi futuri, se solo si vorrà attuarli, saranno resi possibili dall’approccio modulare ed incrementale che è alla base della creazione del sistema informativo DAXO.
5.5.4 L’importanza del linguaggio di programmazione: JAVA
Per realizzare e fornire i propri sistemi, DAXO si avvale delle tecnologie Java. Java è un linguaggio di programmazione ad alto livello per lo sviluppo di software robusto che può essere utilizzato per sviluppare un’ampia gamma di applicativi, in grado di gestire interfacce utente, operazioni in rete, connessioni a database e altre funzionalità sofisticate. Java appartiene a quella generazione di linguaggi di programmazione che fanno riferimento al cosiddetto "paradigma della programmazione ad oggetti"; in particolare, si tratta di un linguaggio multi-piattaforma, il che significa che i suoi programmi possono essere progettati per funzionare allo stesso modo su piattaforma Microsoft, Apple Macintosh e sulla maggior parte delle versioni di Linux e Unix. La neutralità dell’architettura rappresenta un elemento chiave in un mondo in cui continuano ad essere introdotti i più disparati dispositivi hardware e sistemi operativi, e con l’inarrestabile sviluppo e diffusione delle reti telematiche questa esigenza è divenuta ancor più pressante.
Al fine di garantire tale neutralità, Java affida l’esecuzione dei suoi programmi ad una macchina virtuale, ovvero una CPU ideale che viene simulata sulla CPU effettiva mediante l’esecuzione di un programma (“Java run-time environment”).
La sicurezza offerta da Java si esplica sia a livello strutturale (per l’assenza di puntatori e la gestione automatica della memoria in fase di esecuzione) che a livello di librerie per l’interfacciamento sicuro con i protocolli Internet.
Allo stato attuale Java risulta essere il miglior linguaggio di programmazione per lo sviluppo di applicazioni multi-piattaforma, in grado di coniugare alla potenza espressiva e alla facilità dello sviluppo, una vasta collezione di librerie che ne arricchiscono le potenzialità.
5.6 Interoperabilità con l’ERP Benetti 5.6.1 I due momenti dello scambio dati
Come già accennato, per raggiungere gli obiettivi del progetto si rende necessaria una stretta interoperabilità con il sistema VM attualmente in uso.
Sono previsti due “momenti” di dialogo, coincidenti il primo con la selezione dei dati da VM (cioè la fase che ha visto DAXO “attingere” dai database di VM per poter costruire i propri), ed il secondo con la trasmissione dei dati in direzione opposta (grazie alla quale le transazioni effettuate dall’applicativo DAXO potranno essere registrate nell’ERP aziendale).
1. Selezione dati da VM: per ciò che riguarda la selezione dei dati da Visual, DAXO avrebbe necessità di leggere e quindi poter prelevare le seguenti informazioni:
o anagrafica articoli attivi (dati anagrafici e giacenza); o anagrafica fornitori attivi;
o ordini di acquisto da evadere; o ordini di produzione da evadere.
L’aggiornamento delle informazioni, per un corretto utilizzo, dovrebbe avvenire ad intervalli regolari e il più frequente possibile, se non sarà possibile accedere direttamente alle tabelle DAXO consiglia l’utilizzo di viste strutturate.
2. Trasmissione dati a VM: questa eviterà al personale di magazzino di dover registrare manualmente le operazioni già in memoria sul sistema DAXO, e sarà resa possibile da una tabella di interscambio dati ancora da definire.
Le informazioni che DAXO fornirà, mediante l’utilizzo di tabelle strutturate secondo caratteristiche concordate con Benetti, riguardano:
o le registrazioni dei carichi in magazzino con evasione dell’ordine a fornitore; o le registrazioni degli scarichi dal magazzino con evasione del buono di
prelievo;
o le movimentazioni di un articolo da un magazzino ad un altro; o le rettifiche inventariali.
Il trasferimento automatico delle informazioni dal database DAXO a quello Benetti potrebbe avvenire ad intervalli regolari oppure su richiesta dell’utente stesso.
5.6.1 Quale grado di integrazione
Il 29 ottobre 2007 ha avuto luogo un incontro cui hanno partecipato: - per Benetti:
o il responsabile della Logistica per il cantiere di Livorno (Project Manager per il progetto di tracciabilità);
o rappresentanti del reparto ICT, sia per il cantiere di Livorno che per l’intero Gruppo Azimut – Benetti;
o il responsabile dei progetti di miglioramento. - i responsabili DAXO per il progetto;
In questa occasione, per l’applicativo DAXO sono stati proposti tre livelli di integrazione con VM alternativi:
1. gestione di tutte le funzionalità BO descritte in precedenza realizzata direttamente su VM (tali funzionalità non verrebbero sviluppate sull’applicativo DAXO);
2. livello 2: trasferimento di tutte le funzionalità di gestione della logistica di magazzino (lato BO) sull’applicativo DAXO;
3. livello 3: sviluppo di un’integrazione più completa tra i due sistemi, soluzione auspicata da DAXO.
In APPENDICE B è riportato l’elenco dettagliato delle informazioni la cui gestione verrebbe a competere all’uno e/o all’altro sistema, a seconda del livello di integrazione per il quale Benetti deciderà di optare.
In breve:
1. nel primo caso, VM necessiterebbe di un’opera di adeguamento e personalizzazione notevole; inoltre, si perde la possibilità di visualizzare e gestire tramite palmare le funzionalità di cui ai punti 17, 18, 19 e 20 nel par. 5.5.2, oltre che di gestire le richieste di emissione dei buoni di prelievo inoltrate dai capi barca (par. 5.5.1, punto 3).
2. Qualora si optasse per il secondo livello di integrazione, VM verrebbe a perdere una buona parte delle funzionalità inerenti la logistica: esso costituirebbe un gestionale prettamente “contabile”, e dovrebbe ricevere dall’applicativo DAXO tutti i dati relativi all’warehouse management.
3. La soluzione integrata prevede che a VM competa la normale gestione di tutte le informazioni (quindi pure quelle relative al magazzino), che il BO DAXO consentirebbe di dettagliare maggiormente. DAXO ha suggerito di adottare questo tipo di integrazione, poiché esso garantirebbe il massimo sfruttamento delle potenzialità del nuovo applicativo senza alterare il regolare flusso dati e, altrettanto importante, senza impattare eccessivamente sulle attuali procedure operative (il nuovo sistema,
infatti, oltre che efficace, dovrà risultare il meno invasivo possibile per l’end user Benetti).
Un secondo e decisivo incontro, volto a stabilire definitivamente quale delle tre soluzioni adottare e ad iniziare ad approfondire gli aspetti più strettamente tecnici inerenti le interfacce fra i sistemi, si è tenuto il 12 novembre 2007. Il taglio maggiormente operativo di questa riunione ha reso necessaria la presenza, oltre che di coloro che avevano preso parte al precedente incontro, di un responsabile dell’area tecnica DAXO e, soprattutto, di un responsabile della Società che ha realizzato l’ERP VM e a cui di fatto spetterà il compito di implementare le modifiche allo stesso gestionale, a seconda del livello di integrazione richiesto con l’applicativo DAXO.
Come auspicato da DAXO, la scelta è ricaduta sulla terza opzione, che prevederà la suddivisione delle attività e dell’onere di gestire le informazioni tra VM e DAXO, oltre che la definizione di un sistema di interscambio dati che permetterà ai due sistemi di rimanere “allineati”.
In APPENDICE B, dopo le tre tabelle di dettaglio relative ai livelli di integrazione, è riportata la tabella che sintetizza l’articolazione delle interfacce nel caso scelto (non proprio identica all’ultima delle tre precedenti, dato che comunque l’incontro ha consentito di correggere qualche dettaglio).
In particolare, le viste verranno create e gestite dalla Società che ha realizzato VM, come pure sarà questa Società a creare la tabella di scambio dati necessaria per trasferire le informazioni da DAXO e VM e a gestire la lettura dei dati trasferiti su quest’ultimo. La gestione della scrittura sarà invece a carico di DAXO.
Per ciò che riguarda le locazioni, e quindi la gestione del magazzino per commessa, DAXO prevederà la seguente struttura:
- magazzino o zona
corridoio ◦ traversa
altezza.
Cioè, per rispettare la struttura di VM, i dati inseriti in DAXO saranno organizzati secondo il seguente schema di riferimento:
- FBXXX (la commessa); o magazzino centrale
◦ 01, 02, 03, … 01, 02, 03, …; o magazzino periferico 1, 2, 3, … A, B, C, … ◦ 01, 02, 03, … 01, 02, 03, … .
Attualmente VM si limita a gestire il seguente livello di dettaglio:
- FBXXX;
o magazzino centrale;
o magazzino periferico 1, 2, 3, … (si ricordi che pure per il materiale presso terzi, ad esempio per una sostituzione o una riparazione, è prevista un’ubicazione “contabile” analoga a quelle fisiche corrispondenti ai vari magazzini periferici). 5.7 Lo scenario applicativo: i processi “to be”
Nelle pagine seguenti sono riportati i diagrammi di flusso (figg. 54 e 55) relativi alle due procedure prese in considerazione, riferiti però stavolta a quello che, allo stato attuale delle operazioni, si prefigura verosimilmente come lo scenario applicativo (“to be”) nel breve termine.
Senza stare a descrivere nuovamente gli interi processi, basti notare ad esempio che (vd. cerchi rossi nei flow charts):
- per quanto riguarda il ricevimento del materiale a MAG (fig. 54):
o il fatto che tutti gli ordini da evadere, del tutto o solo parzialmente, siano memorizzati nell’applicativo DAXO (e quindi nel palmare dell’addetto al collaudo), farà sì che non vi siano differenze fra gli arrivi di ordini “interi” e consegne parziali: se cioè il fornitore spedirà solo alcuni dei codici ordinati, e magari altri codici riferiti allo stesso ordine saranno già stati ricevuti a MAG, non sarà più necessario cercare in archivio il relativo fascicolo ordine – DDT, come pure verranno eliminate tutte le operazioni di aggiornamento dello stesso fascicolo (l’addetto al collaudo che evidenzia nuove righe sull’ordine e vi scrive accanto il numero d’ingresso). Da sottolineare che l’automatizzazione di queste operazioni non consentirà solamente di risparmiare tempo, snellendo la procedura, ma pure di abbattere la probabilità di errori, limitando il ricorso al manuale.
o Sempre grazie al palmare, il nuovo sistema consentirà all’addetto al collaudo di interrogare l’applicativo per sapere dove ubicare il materiale ricevuto, senza dover perdere tempo per cercare posti pallet o altri spazi liberi all’interno del magazzino (questo discorso, almeno inizialmente, varrà soprattutto per il MAG GEN, che si estende per 6.000 m2).
o La visualizzazione sul palmare delle locazioni libere verrà resa possibile dal fatto che l’applicativo DAXO è in grado di gestire tali locazioni, funzionalità non contemplata da VM. Ecco perché il nuovo sistema permetterà di eliminare anche la doppia registrazione del carico a MAG, dato che l’aggiornamento dei file Excel con le ubicazioni non sarà più necessario.
- Riguardo invece alle richieste di materiale dalla PROD e al ciclo del buono di prelievo (fig. 55), oltre al fatto che pure in questo caso la possibilità di gestire le ubicazioni eviterà di dover ricorrere ad Excel:
o i BP non dovranno più essere preparati dall’IGP con Access in seguito alla richiesta telefonica di un capo barca, ma sarà direttamente quest’ultimo a effettuare le richieste attraverso il palmare in dotazione. Il fatto che la richiesta debba essere visualizzata dall’IGP per la conferma definitiva e l’inoltro al MAG serve solo a garantire una minor probabilità di errore (soprattutto nei primi tempi, dato che i capi barca dovranno abituarsi all’utilizzo del palmare e familiarizzare con la codifica dei materiali). Ad ogni modo, l’interfaccia “user friendly” del palmare sarà tale da guidare il capo barca alla selezione dei codici corretti, il che eliminerà quasi del tutto non solo le telefonate del capo barca all’IGP, ma pure quelle (non poco frequenti) dell’IGP al MAG per conoscere la codifica di alcuni articoli, e con queste gli errori dovuti a incomprensioni circa i codici da prelevare.
o Nel momento in cui l’IGP avrà confermato o modificato la richiesta del capo barca, il BP perverrà automaticamente all’ufficio del MAG GEN e sul palmare dei magazzinieri, che potranno così iniziare subito a preparare il materiale senza dover attendere che sia il personale in ufficio a stampare una copia del BP e a scrivere accanto a ogni codice l’ubicazione (consultando i file Excel che, grazie all’applicativo DAXO, non saranno più necessari).
o Non appena il materiale sarà pronto al ritiro, il sistema lo segnalerà al capo barca mediante un “alert” sul palmare. In questo modo non potrà più accadere
che il personale di PROD addetto al prelievo si presenti in MAG GEN quando ancora gli articoli non sono stati preparati, causando inefficienze e malumori. o Così come in fase di ricevimento a MAG il nuovo sistema permetterà di gestire
nella stessa maniera ordini da evadere del tutto o solo parzialmente, pure nel caso di richiesta dalla PROD non vi sarà alcuna differenza fra BP completi e parziali, e questo anche perché l’applicativo DAXO consentirà di gestire l’informazione relativa a componenti e codici “kit”.
A tutto questo, ovviamente, si aggiungono i vantaggi dell’Auto-ID e della tecnologia barcode in particolare, in termini sia di tempi risparmiati che di minori probabilità di errore (grazie all’eliminazione di buona parte delle operazioni manuali).
Alcune importanti considerazioni:
- i processi schematizzati nelle pagine precedenti si riferiscono cautelativamente ad uno scenario pessimistico, il quale cioè prevede una scarsa integrazione fra il gestionale VM e l’applicativo DAXO (in particolare per quanto riguarda il flusso dati dal secondo al primo, vd. par. 5.6.1) che costringerebbe gli operatori del MAG a dover registrare manualmente carichi, scarichi e trasferimenti del materiale sull’ERP Benetti. In realtà, è auspicabile che i due sistemi dialoghino in maniera tale da automatizzare queste operazioni, consentendo al personale di MAG di dedicarsi alla supervisione dei processi più che alla meccanica compilazione di campi e tabelle sul terminale.
- Lo scenario prospettato è “pessimistico” pure nel senso che i processi descritti prevedono, rispetto a quelli attuali, solo le modifiche strettamente imposte dall’implementazione dei nuovi sistemi: il fatto che nei flow charts compaiano ancora, ad esempio, le operazioni di archiviazione dei documenti cartacei, non significa che ciò sia necessario, ma semplicemente che spetterà all’Azienda decidere se e per quanto tempo sarà il caso di “proteggersi” da eventuali guasti o problemi ai nuovi sistemi continuando a gestire il cartaceo.
- Una delle principali innovazioni apportate dal nuovo sistema consiste nella possibilità di gestire i buoni di prelievo direttamente dall’applicativo, senza dover ricorrere ad Access e a tutta la documentazione cartacea prevista dall’attuale procedura. Ebbene, proprio questa nuova funzionalità potrà (e dovrà) essere sfruttata per ottenere dal nuovo sistema benefici ben maggiori di quelli che presumibilmente si otterranno all’inizio: se nelle prime settimane, infatti, saranno solo i due processi analizzati ad essere snelliti e resi più efficienti, successivamente a Benetti basterà ritoccare le procedure relative a trasferimenti fra magazzini, da / a terzi, tra commesse e tra commesse e MAG RESI (e viceversa) in modo che pure queste si basino sull’impiego dei BP, affinché tempi e costi risparmiati si moltiplichino.
- Riferendosi a scenari pessimistici, le procedure previste non tengono neppure conto di ulteriori modifiche, sviluppi e miglioramenti che potranno essere apportati in un secondo momento, come ad esempio:
o la stampa di una seconda etichetta barcode da applicare ai colli al momento del loro scarico (fisico) dall’automezzo, oltre a quella riportante il codice dell’articolo / degli articoli, con indicati numero e data di ingresso e codice della commessa di destinazione (se si deciderà di non inserirla nel barcode
principale). Tale etichetta eliminerebbe definitivamente la marcatura a pennarello da parte dei magazzinieri.
o La conferma dell’avvenuto ritiro del materiale da parte della PROD tramite la lettura dei relativi barcode, per mezzo del reader integrato al palmare del capo barca. Dopo lo scarico contabile dal MAG, infatti, il sistema considererà automaticamente i codici imbarcati, ma in teoria vi è il rischio che se ne perda la tracciabilità.
o Spingendosi ancora oltre, il maggiore coinvolgimento dei fornitori strategici, anzi una loro integrazione con Benetti (vd. anche par. 7.2), può far prefigurare uno scenario in cui le due parti condividano le informazioni riguardo ai movimenti del materiale fornito: è ovvio che se il fornitore avesse modo di sapere in tempo reale dell’avvenuto carico dei codici in MAG da parte di Benetti, non vi sarebbe più bisogno del DDT associato alla consegna e di tutti i relativi timbri.
Prima di passare alla descrizione del pilot project RFID, è bene sottolineare che i vantaggi del nuovo sistema sono sì notevoli, ma non sufficienti ad eliminare tutte le problematiche attuali; anzi in alcuni casi ne sorgono di nuove:
- qualora il capo barca sbagli a selezionare sul palmare il codice da prelevare (confondendolo con un altro), mancando l’interazione diretta (la consueta telefonata) con l’IGP è più probabile che tale Ufficio non riconosca l’errore, confermando la richiesta e inoltrandola al MAG. L’errore verrebbe così scoperto solo al momento del ritiro del materiale.
- In fase di preparazione del materiale da prelevare, se per sbaglio il magazziniere dovesse leggere due volte con il reader, senza accorgersene, lo stesso codice a barre, il sistema verrebbe “ingannato” e per il dato articolo verrebbe registrata un’unità prelevata in più. Questo per far comprendere che il nuovo sistema, per quanto “robusto”, non sarà mai capace di prevedere o porre rimedio a qualsiasi errore umano. Ad ogni modo, questo specifico problema dovrebbe sparire nel momento in cui entrerà in gioco la tecnologia RFID, dato che i tag consentiranno di identificare non il tipo di articolo, ma la singola unità.
- Il fatto che attualmente l’addetto al collaudo debba recarsi fisicamente fra gli scaffali per scegliere l’ubicazione da assegnare ai codici (col palmare potrà visualizzare i vani liberi senza doversi spostare) comporta sì una perdita di tempo, ma consente di vedere
se un vano è veramente saturo o se è invece occupato da una scatolina; il sistema DAXO, invece, definirà il vano occupato pure in quest’ultimo caso, per cui il rischio sarà quello di ottenere una “finta saturazione” dei posti pallet. Ecco perché dovranno essere studiati degli algoritmi che prevedano per il vano non solo gli stati “libero” e “occupato”, ma pure tutta una serie di stati di saturazione intermedi.
5.8 Pilot project RFID
Parallelamente all’implementazione del sistema di tracciabilità delle merci mediante barcode, sarà realizzato un progetto pilota che utilizzerà la tecnologia RFID UHF (vd. par. 3.5) per tracciare i codici associati ad una particolare commessa9.
Tale progetto sarà finalizzato a testare l’efficacia operativa della tecnologia RFID all’interno del cantiere e a dare un’idea di massima dei benefici tangibili che essa potrà comportare, in termini di tempi e costi risparmiati.
Dal punto di vista dell’infrastruttura software precedentemente descritta, non sarà necessario apportare modifiche ai sistemi FO e BO.
Per quanto riguarda invece l’hardware, saranno previste sia l’applicazione di tag RFID sui materiali, sia l’installazione di gate RFID all’ingresso del magazzino periferico scelto per il progetto pilota (LIV-F, vd. par. 4.3.4) e all’uscita del MAG GEN.
La seguente fig. 56 illustra le funzionalità del gate RFID.
9
La FB247, scelta in quanto:
- il personale di PROD che vi lavora (capo barca in primis) si è mostrato molto aperto a sperimentare la nuova tecnologia;
- essa risulta nelle prime fasi di allestimento, dunque nel capannone che la ospita (F) e nel relativo magazzino periferico (LIV-F) dovranno essere stoccati i “suoi” codici ancora per numerosi mesi. Ciò dovrebbe dare il tempo a tutti gli attori coinvolti di valutare bene l’esito del progetto pilota, consentendo di comprendere se sia effettivamente il caso di estendere l‘utilizzo dell’RFID agli altri magazzini. - LIV-F, per dimensioni e posizione all’interno del capannone, si è rivelato il miglior magazzino
Figura 56: Esempio di utilizzo della tecnologia RFID in fase di movimentazione del materiale
Il principale vantaggio della tecnologia RFID rispetto al barcode consiste nella riduzione dei tempi necessari a identificare i codici e tracciare i loro spostamenti, dato che il gate RFID consente la lettura di più codici contemporaneamente (anche senza visibilità diretta del tag). Per di più, alcuni tipi di tag RFID possono essere riutilizzati: qualora l’operatore dovesse prelevare il materiale dal magazzino periferico per utilizzarlo in PROD, il tag RFID associato potrebbe essere “staccato” e reso disponibile per un altro articolo.
Per rendere meno “traumatica” l’introduzione della tecnologia RFID per le attività di logistica interna, l’offerta DAXO prevede sin da subito la fornitura di due palmari industriali dotati sia di lettore barcode che di reader RFID: un palmare sarà utilizzato dal personale addetto alla gestione del materiale nel MAG GEN, che in questo modo potrà gestire sia i codici per cui è previsto l’impiego dei soli barcode, sia gli articoli destinati al magazzino scelto per il pilot project RFID; l’altro palmare sarà invece consegnato a chi si dovrà occupare della movimentazione dei materiali proprio in quest’ultimo magazzino.
Riassumendo, il sistema RFID sarà costituito dai seguenti elementi:
- etichette RFID UHF da applicare alla merce giunta nel MAG GEN;
- palmari industriali dotati di lettori per barcode e per tag UHF, per consentire la lettura dei tag in ottica mobile;
- gate (antenna più lettore) da installare all’ingresso del magazzino interessato, per permettere il controllo della merce in ingresso ed in uscita;
- cablaggio della rete wireless, dove necessario, per permettere la comunicazione tra le applicazioni BO e FO.
La quantità di tag necessari sarà stimata sulla base delle scorte di ciclo presenti nei vari magazzini.
Dopo un sopralluogo sarà anche possibile stimare il numero di gate RFID, postazioni fisse di lavoro e di access point necessari per garantire il corretto funzionamento del sistema.
Dopo la fase di testing, spetterà solo a Benetti scegliere quando adottare anche negli altri magazzini i dispositivi RFID, sostituendo gradualmente la tecnologia barcode oppure prevedendo un sistema ibrido che utilizzi entrambi i sistemi.
5.9 Altri aspetti e fasi del progetto
5.9.1 Collaudo funzionale
Questa fase (WP5) comprende le attività di installazione dell’applicativo sul server dedicato, il collaudo funzionale ed il caricamento delle tabelle specifiche per il corretto funzionamento a regime dell’applicazione.
Secondo un “Piano del Collaudo” concordato con il committente, saranno condotte le prove per verificare che il sistema presenti un comportamento coerente ed adeguato alle esigenze manifestate dal committente stesso.
Quando tutti i test saranno stati eseguiti con esito positivo, verrà redatto un “Verbale di Collaudo” cui saranno allegate tutte le specifiche dei test eseguiti certificate dal responsabile della loro conduzione. Tale verbale dovrà essere controfirmato dal committente e formalizzerà il termine della fase.
Durante tutto il periodo di sviluppo del sistema, il committente potrà controllare lo svolgimento delle attività del fornitore; in particolare è auspicabile, durante le attività di testing, la presenza degli addetti (per specifica competenza) al successivo collaudo del sistema.
Al termine di questa attività verranno consegnate le versioni aggiornate dei manuali per i sistemi forniti.
5.9.2 Formazione ed avviamento
Il programma di formazione dovrà essere dettagliatamente concordato con il personale Benetti, in relazione alle esigenze, alla numerosità e alla disponibilità (in termini di tempo) dei soggetti coinvolti.
I docenti del corso saranno soggetti coinvolti sin dall’inizio nel progetto, e che quindi conosceranno molto bene il contesto di riferimento e la soluzione proposta. Tali figure, scelte
