IL MAGAZZINO AUTOMATICO, UN SISTEMA COMPLESSO: COME PROGETTARE, PIANIFICARE ED ESEGUIRE I TEST CHE PORTANO ALL'ACCETTAZIONE FINALE - Pag. 3

Pagina 3 di 4: Pag. 3

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.