Il magazzino automatico, un sistema complesso: come progettare, pianificare ed eseguire i test che portano all'accettazione finale

La complessità dei magazzini automatici

I magazzini automatici, anche quelli più essenziali, sono indubbiamente sistemi complessi.

La loro complessità consiste nella numerosità dei componenti presenti nella fornitura, come ad esempio le macchine per lo stoccaggio / messa a dimora delle unità di carico (traslo-elevatori, shuttle, miniload etc.), i sistemi di convogliamento di testata (rulli / catene, nastri, navette, mono-rail etc.), i sorter di prestazioni elevate, le baie di prelievo con logica “merce all’uomo”, aree di prelievo attrezzate con “decision point” e strumenti di supporto al ptelievo, macchine speciali (de/palletizzatori, filmatrici, etichettatrici, formazione colli di spedizione, linee di chiusura colli), robot, fine-linea di controllo / confezionamento colli e si potrebbe continuare a lungo, senza ovviamente dimenticare elementi fondamentali come i vari software che governano strategie e tattiche per la pianificazione ed esecuzione delle missioni (secondo alcune delle diciture più diffuse: Warehouse Execution System – WES, Warehouse Management System – WMS, Automation Control System – ACS, System Control and Data Acquisition – SCADA etc.).

Avrete notato come nell’elenco non siano stati citati gli scaffali, elementi cruciali per la buona riuscita del progetto, ma che in questo contesto vorremmo accantonare, in quanto il nostro obiettivo è quello di considerare gli aspetti “dinamici” dei sistemi-magazzino.

Ogni singolo elemento citato ha le sue complessità funzionali, prestazionali e di utilizzo.

Ma i magazzini automatici sono anche - e forse soprattutto – “sistemi complessi” per il modo in cui i vari componenti interagiscono tra loro nel tempo, in funzione del carico di lavoro cui sono sottoposti, estremamente “nervoso” e variabile di momento in momento: tutto ciò porta ad una difficoltà oggettiva a prevedere le prestazioni complessive di tali sistemi, prestazioni che spesso rischiano di rivelarsi insoddisfacenti, inferiori a ciò che si può prevedere considerando le prestazioni delle singole macchine.

Premesse della "Buona Progettazione"

Ammettendo di avere affrontato e poi risolto la sfida di fare un “buon progetto”, certamente da verificare e affinare per mezzo di una simulazione dinamica, resta davanti a noi l’impegnativa necessità di essere in grado di dimostrare, con appositi test e verifiche, che il magazzino realizzato sia davvero conforme al progetto precedentemente fatto e ai requisiti funzionali e prestazionali che dovrebbero essere stati precedentemente specificati, per potere accettare con serenità il passaggio di mano (handover) del magazzino dal fornitore al cliente che lo dovrà usare per anni.

La prima cosa fondamentale (apparentemente ovvia, ma invece troppo spesso trascurata) è avere definito in modo chiaro e completo i suddetti requisiti: questo fa infatti parte del già citato “buon progetto”, che le aziende dovrebbero affrontare col supporto di società di consulenza logistica qualificate e ricche di un’esperienza “trasversale”, ossia relativa a tutte le fasi del progetto, fino al go-live di impianti complessi.

Ammettendo di avere affrontato con successo la fase dei test di accettazione in officina (i cosiddetti Factory Acceptance Test - FAT) dei singoli elementi (ove fattibile) e soprattutto del software, prima del loro trasferimento in cantiere, rimangono ancora alcune sfide molto ardue prima di potersi dire certi di accettare senza remore la fornitura del sistema, che passa così di mano dal fornitore all’utente finale, in grado di fornire le prestazioni richieste.

Verifiche da effettuare per l'accettazione finale di un progetto di automazione

Questo dell’accettazione finale è proprio il tema che si intende approfondire nell’articolo.

Le fasi

Essenzialmente, le verifiche da fare per l’accettazione riguardano:

1. la consistenza / completezza della fornitura: devono cioè essere stati installati tutti i componenti previsti dal progetto, secondo il layout concordato, con tutte le connessioni fatte a regola d’arte, il giusto livello di lubrificanti, con la piena corrispondenza di materiali e finiture alle specifiche tecniche etc. e completi degli accessori / ricambi e periferiche (HMI);
2. tutte le funzionalità operative degli equipment e del software di governo;
3. le prestazioni dei singoli equipment o di alcuni sotto-sistemi significativi;
4. la prestazione complessiva di sistema, visto in chiave olistica, con riferimento alla capacità del sistema steso di smaltire un complesso di flussi concomitanti in tempi confacenti al livello di servizio obiettivo che si intende ottenere: queste prestazioni sono le più difficili sia da specificare che soprattutto da verificare sul campo, e spesso risultano inferiori alla somma delle prestazioni delle singole parti;
5. l’affidabilità complessiva del sistema, anche questo un concetto più complesso di quanto non si possa credere in prima istanza.

Come anticipato, per effettuare in modo corretto e incontrovertibile le verifiche di cui sopra, i parametri relativi a materiali, funzioni e prestazioni attese devono essere stati per tempo (ossia al momento del contratto) definiti e specificati con cura.

Ad es. nel caso delle prestazioni, dovranno essere stati identificati i KPI di riferimento, completi delle loro metriche, e i valori minimi di di accettabilità, avendo peraltro fissato le condizioni in cui i test saranno effettuati.

Va quindi da sé che, senza un progetto ben dettagliato e documentato, diventerà poi assai difficile avere chiare e presenti tutte le prestazioni e funzionalità che si vogliono ottenere dal “sistema magazzino” e quindi la fase di test e accettazione può diventare oggetto di infinite discussioni col fornitore.

Tornando alle considerazioni per le attività di accettazione di quanto installato, sul punto 1 direi non vale la pena di dilungarsi qui troppo: è chiaramente un’attività importante, che consiste nel rilevare sul campo il numero ed il tipo di componenti installati, verificandone la disposizione negli edifici, controllando i certificati relativi ai materiali etc.

Per quel che riguarda il punto 2, la premessa per poter verificare tutte le funzionalità è quella di avere preventivamente ben definito in un apposito documento (di solito chiamato “Specifiche Funzionali” o “Users Requirements Specifications – URS”) quello che ciascun elemento del sistema e il sistema nel suo complesso deve essere in grado di fare, con riferimento non solo alle funzioni operative, ma anche a quelle di controllo e diagnostica.

La verifica delle funzionalità, specie quella del software, risulterà tanto più veloce ed efficace quanto più lavoro si sarà fatto nelle fasi precedenti il cantiere, ossia in laboratorio, con particolare riferimento ai già citati FAT.

In questi anni, inoltre, si sta definendo come un vero e proprio nuovo “golden standard” la prassi del cosiddetto “virtual commissioning” che consente di avere un “gemello digitale” dell’impianto in un ambiente virtuale, in cui può essere direttamente incluso il software che si intende testare (WMS e PLC), emulando in modo dettagliato i dispositivi di campo. La promessa di questa tecnica è quella di poter comprimere in modo significativo i tempi di esecuzione sul campo del commissioning dell’impianto e dei test di accettazione.

La fase 3, ossia la verifica delle prestazioni di singoli elementi del sistema (es. un elevatore, una macchina filmatrice, un deviatore rulli catene etc.) può sembrare apparentemente semplice, ma richiede anch’essa un’accurata preparazione.

Innanzitutto, sarebbe ideale che questa fase e le successive fossero effettuate con unità di carico vere, con prodotto valido o placebo, e che queste unità di carico fossero disponibili per tempo in quantità adeguata. Nella vita reale, specie quando si abbia a che fare con prodotti costosi o freschi o con molte varianti in grado di mettere in crisi il componente che si deve testare, questo può essere un problema, cui pensare per tempo assieme alla Produzione o alla Supply Chain.

Oltre al prodotto da movimentare, l’effettuazione di questi test richiede anche dotarsi del personale necessario e dei servo mezzi utili a movimentare le unità di carico da e per il sistema automatico. In genere, se non diversamente negoziato in fase contrattuale, queste ultime risorse devono essere messe a disposizione dal cliente.

Se per alcuni equipment può risultare abbastanza semplice definire il ciclo di prova, per altre apparecchiature – e ci riferiamo segnatamente a traslo elevatori e miniload – la faccenda può risultare significativamente più complessa, specie in presenza di scaffalature a profondità multipla e/o ad attrezzi di presa multi carico. Molte di queste casistiche sono state fortunatamente normate dalla F.E.M. (Federation Europeénne de la Manutenion - https://www.fem-eur.com/about/), come ad esempio la FEM 9.851 “Performance data of storage and retrieval machines”.

Pur essendo F.E.M. l’associazione dei principali produttori e integratori di sistemi logistici, e quindi in qualche modo fornendo una visione di parte, nella pratica queste norme sono accettate come riferimento da tutti, sia per semplificare i riferimenti prestazionali, sia per definire range accettabili di tolleranze di costruzione / realizzazione, che poi consentono una più semplice integrazione di macchine e scaffali provenienti da fornitori diversi.

Ciò non toglie, naturalmente, che a livello contrattuale la prestazione di riferimento possa anche essere definita nel modo più congeniale al cliente, di caso in caso.

Molto importante avere concordato col fornitore il formato della modulistica da utilizzare test per test, per tenere traccia controfirmata dell’andamento della prova e del suo esito, con particolare riferimento a campi da compilare in caso di esito negativo, che registrino le possibili causali del fallimento e quanto concordato tra fornitore e cliente per la successiva messa a punto dell’apparecchio e la nuova esecuzione dei test.

La fasi 1-3 daranno certamente luogo ad un elenco dei punti aperti (detta “punch list”), alla luce delle varie verifiche effettuate, che va tenuta costantemente aggiornata: non tutti i punti aperti saranno necessariamente ostativi rispetto al progresso dei test o addirittura all’uso del bene, tuttavia essi andranno chiusi del tutto prima dell’accettazione finale.

La fase 4, per ovvie ragioni da farsi dopo avere accertato l’adeguatezza dei singoli equipment e sotto sistemi, quella relativa al test delle prestazioni del sistema complessivo, è purtroppo ad un tempo quella più importante e quella più difficile (direi estremamente difficile, a volte) da mettere in pratica.

In primis, bisogna avere definito accuratamente cosa si intenda per “prestazioni del sistema complessivo” e questo rimanda inevitabilmente ad un progetto accurato. Infatti, all’interno di un sistema complesso di material handling possono aversi molti o anche moltissimi flussi concomitanti (ingressi, uscite a spedizione, uscite verso aree di prelievo e/o preparazione, rilocazione di merci, abbassamenti, controlli di merce a stock), con profili di flusso variabili nel tempo.

In questo quadro, avere realizzato un modello dettagliato di simulazione dinamica aiuta – oltre ovviamente a fare un buon progetto, includente anche gli aspetti logici e gestionali – anche a darsi degli obiettivi chiari e concreti su molti KPI dinamici, specie quelli legati ai lead-time minimi necessari a garantire il livello di servizio desiderato: i risultati della simulazione possono quindi divenire dei veri e propri riferimenti, da verificare sul campo.

Quando anche il quadro di riferimento del test fosse chiaro, vi possono essere difficoltà a volte insormontabili nella gestione pratica della “regia” degli eventi che porta alla ricostruzione sul campo di tale quadro. Occorre infatti predisporre accuratamente le merci in magazzino, il piano degli ingressi, quello delle uscite e tutte le risorse che servono a realizzare tali piani senza intoppi, il tutto in fase iniziale dell’impianto, in cui macchine e persone spesso non sono ancora “mature” e “rodate” per fare funzionare il tutto al meglio.

Ogni intoppo anche minimo e non necessariamente dato dall’impianto in sé (es. pallet che si mettono di traverso, mancate letture di etichette bar-code etc.) può comportare la necessità di partire da capo, per non inficiare i risultati del test, e quindi il compito defatigante di riportare il tutto alle condizioni iniziali.

Oltre alla complessità intrinseca della faccenda, già evidenziata, occorre mettere nel debito conto un periodo di tempo sufficiente ad effettuare questi test.

Ecco quindi che a volte si preferisce (o si è costretti) a non fare una “prova d’orchestra” realmente onnicomprensiva e ci si accontenta di testare più o meno larghi raggruppamenti di equipment (sotto sistemi) possibilmente poco interferenti gli uni con gli altri, per garantire la significatività di questi test parziali.

Un altro possibile approccio è quello di testare le prestazioni dei singoli elementi del sistema e poi inserire tali prestazioni (e le logiche di gestione del WMS/ACS e magari anche ragionevoli tassi di affidabilità: MTBF/MTTR) in un modello di simulazione dinamica in “scala 1:1” e verificare con tale modello – ossia “in vitro” – le prestazioni risultanti.

Il tema delle prestazioni complessive del sistema può essere ancora più complesso, o meglio la determinazione delle responsabilità in caso di mancato raggiungimento delle prestazioni target, in virtù della strategia di acquisto che il Cliente ha deciso di adottare e che – come facile intuire – condiziona anche i test da realizzare.

Semplificando un po’, la strategia di acquisto può prevedere di rivolgersi a un interlocutore unico – che integri le varie componenti del sistema e che si responsabilizzi rispetto al risultato complessivo finale – ovvero andare sul mercato ad acquistare i componenti separati e poi curare in modo più o meno diretto la loro integrazione.

La prima alternativa, a prima vista più costosa (e si potrebbe parlare a lungo di ciò) vede fin dall’inizio un responsabile chiaro e ben definito – il cosiddetto system integrator, che a volte non produce in proprio alcunché, se non il software – non solo per quelle che sono le prestazioni dei singoli dispositivi, ma soprattutto per le prestazioni del sistema.

Inutile dire che concettualmente questa è una grande semplificazione lungo la strada dell’accettazione del sistema e delle responsabilità per le prestazioni dello stesso, in grado di rendere anche meno spinosi anche alcuni aspetti “politici” che portano verso tale obiettivo (ci torneremo sopra più avanti).

Viceversa, la seconda strategia – quella che potremmo definire simpaticamente dello “spezzatino” – porta ad alcune economie sui costi di acquisto iniziali, evitando l’intermediazione del system integrator, ma porta anche notevoli complicazioni nella fasi di progetto e di accettazione finale, quelle stesse complicazioni (selezione dei sub-fornitori, perfetta integrazione fisica e funzionale delle forniture, gestione del cantiere etc.) per affrontare le quali il system integrator giustamente esige un compenso.

Per inciso, non è che questi costi siano realmente evitati da parte del cliente finale con lo “spezzatino”, solo che rischiano di essere meno evidenti, specie se sostenuti in economia dal team interno, oppure sono il corrispettivo per società di consulenza ed ingegneria.

Lo “spezzatino” può essere fatto in mille modi diversi: uno dei più facili e redditizi, sebbene non privo di difficoltà e rischi, è quello di comperare separatamente gli scaffali (specie se importanti economicamente, come nel caso di soluzioni autoportanti) e quella che potremmo definire “automazione”, somma degli equipment e del software.

In questo caso, ai fini del nostro tema, di fatto siamo in una situazione del tutto analoga a quella del system integrator. O quasi, perché è pur sempre possibile che un cattivo funzionamento delle macchine al servizio dello scaffale sia determinato da un cattivo montaggio dello scaffale stesso, con tutte le difficoltà a individuare il vero “colpevole”.

A volte, però, lo “spezzatino” si può fare in modo più spinto, fino al caso più complesso – che tratteremo a parte, dal punto di vista dell’accettazione finale – in cui il cliente decida di comperare separatamente il “ferro” (convogliatori, traslo etc.) dal software (WMS).

Ciò non è sempre dettato da driver di risparmio economico: tale scelta può essere la conseguenza di linee guida “corporate” che impongono il WMS (es. SAP EWM) e magari anche il suo implementatore, per avere strumenti e processi omogenei nel mondo.

Come è facile intuire, avere “cervello” (il software) e “muscoli” (l’automazione) forniti da due diversi attori comporta una sostanziale difficoltà pratica nell’attribuire le responsabilità di eventuali defaillance prestazionali di sistema: l’unico modo per aggirare l’ostacolo è quello di riuscire a mettere tutti attorno allo stesso tavolo fin dalla fase di progetto e coordinare lo sviluppo sinergico delle diverse componenti. Fermo restando che poi alla fine sarà sempre un terreno assai “scivoloso” quello dell’attribuzione di responsabilità, per non dire della situazione non gradevole né gradita da parte del fornitore dell’automazione, che vedrà usato per settimane o mesi il proprio impianto – idealmente già perfettamente funzionante in semi-automatico – solo per testare il WMS altrui, con tutto ciò che questo comporta in termini di usura in un periodo in cui la garanzia non è ancora iniziata.

In questi casi, diventa di fondamentale importanza la figura di quello che potremmo definire l’architetto del sistema, che – entro certi limiti – deve farsi garante del disegno strategico dello stesso sistema, in cui siano considerati caratteristiche e limiti del WMS e dell’automazione. Ancora una volta, lo strumento principe per verificare situazioni così complesse già in fase di progetto rimane la simulazione dinamica.

Il ruolo di “architetto di sistema” può essere convenientemente coperto da un Consulente Logistico esperto, specie nella misura in cui sia in grado di gestire in prima persona la simulazione dinamica.

La prestazione complessiva del sistema, però, non può prescindere dalla verifica positiva che anche l’affidabilità dello stesso sia sufficientemente alta: a poco serve infatti un sistema che sia molto prestante quando funziona, ma che poi risulti spesso fuori uso.

Tuttavia, si consideri che l’affidabilità del sistema non può essere alta nelle fasi iniziali dell’esercizio di sistemi cosi complessi: empiricamente, e anche intuitivamente, si sa che essa cresce col passare del tempo, durante il quale si devono affinare i punti aperti, e gli utenti e i manutentori migliorano la loro abilità nella gestione del sistema stesso.

Per contro, è intuibile che il Cliente voglia iniziare a usare al più presto per fini commerciali il costoso investimento fatto, e quindi potrebbe non essere disposto ad attendere troppo per il momento in cui misurare l’affidabilità. Per soprammercato, l’affidabilità si può affinare solo con un uso vero del sistema, con flussi e situazioni che possano “sollecitare” tutte le possibili casistiche, che neppure il più completo “test plan” potrebbe mettere in conto.

Ecco quindi che le norme F.E.M. (più precisamente le 9.222) invitano a verificare in Fase 4 – al cui termine generalmente è posto il cosiddetto “handover” del sistema, ossia il passaggio di proprietà dello stesso dal fornitore al cliente e l’inizio del periodo di garanzia – solo l’esistenza di una disponibilità alta, ma non altissima (es. 80%), affinché il Cliente inizi a usare con sufficiente confidenza l’impianto, anche perché si spera che all’inizio l’impianto non debba essere al 100% delle prestazioni per tutto il tempo, nella consapevolezza che l’obiettivo finale di affidabilità (es. 98%) potrà essere raggiunto solo nel giro di qualche mese di utilizzo intenso dell’impianto stesso, facendone l’opportuna manutenzione.

Ecco che la Fase 5, la verifica del raggiungimento della disponibilità obiettivo da contratto, avverrà solo in un momento successivo, anche relativamente lontano dall’handover (es. 6 mesi). In questo periodo, il fornitore sarà vincolato a risolvere tutti gli eventuali punti aperti.

Scendendo sul piano tecnico ed organizzativo, neppure la verifica del tasso di affidabilità è attività scevra da difficoltà e complicazioni. È anzi forse una delle più intricate.

Difficoltà nella verifica del tasso di affidabilità

Le difficoltà riguardano:

• la determinazione di un modello di affidabilità coerente e condiviso, suddividendo il sistema in sottosistemi in serie ed in parallelo tra loro, individuando eventuali ridondanze e buffer che rendano ininfluenti eventuali indisponibilità localizzate, pesando il tasso di disponibilità di ciascun sottosistema in funzione di criteri razionali (es. percentuale di flusso gestito)
• la conduzione pratica del test e soprattutto la raccolta dei dati, con particolare riferimento alla definizione di chi sia il responsabile di un certo guasto (l’automazione, le unità di carico, il WMS, altro) e quale sia la durata del ripristino del guasto stesso: in sistemi estesi geograficamente e/o composti da molti elementi, può risultare davvero difficile tenere il passo degli eventi.

Nella pratica, anche se tutto parrebbe facile da considerare in modo “scientifico”, specie se supportati da evoluti SCADA che forniscono buone indicazioni diagnostiche circa la causale di guasto, si finisce spesso per tribolare abbastanza.

Le tipiche ragioni di discussione sono: quanta parte della durata di un guasto è attribuibile al fornitore del sistema e quanto al cliente, che magari non ha messo a disposizione un numero adeguato di manutentori preparati o che non ha un adeguato parco ricambi in casa¹? Quando un blocco è da attribuire al fornitore e quando al cliente, magari per l’adozione di unità di carico non adatte alla movimentazione automatica (es. pallet rotti)?

Tali discussioni interrompono la continuità del test, allungandolo e a volte rendendolo poco significativo, cartemonete creando un'atmosfera conflittuale e poco costruttiva, anche perché normalmente ci sono aspetti economici legati all’accertata disponibilità finale.

Conclusioni

La buona conduzione della realizzazione ed avviamento di sistemi complessi, come quelli di stoccaggio e movimentazione automatizzata, non può prescindere da una buona “ingegnerizzazione”, pianificazione ed esecuzione di tutte le attività di test e verifica che è opportuno compiere.

Per fare ciò, serve una comprovata professionalità ed esperienza, nonché il coinvolgimento profondo del fornitore, che può essere convenientemente chiamato a sottoporre per commenti ed accettazione al Cliente e al suo Consulente Logistico le proprie specifiche di test.

Di certo, non è consigliabile ignorare il problema o neppure rimandarlo troppo, fino a giungere al ridosso dei test stessi.

La prevenzione che un buon progetto strutturato offre è l’unico rimedio veramente efficace per affrontare e risolvere con la massima serenità ed efficacia questa fondamentale fase. 

¹  :  Per ovviare a ciò in modo pratico, spesso si definisce contrattualmente un “tempo limite” della durata di un guasto: durate eccedenti tale limite sono ad esso ricondotte, a significare che entro quel tempo il servizio di manutenzione DEVE avere posto rimedio. 

Per informazioni:

Simco Consulting - mail: Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.

https://simcoconsulting.com/