Critical issues
Il capitolo tratta le principali criticità, di carattere generale, incontrate ciclicamente durante la costruzione della nuova struttura. La soluzione definitiva per far fronte a questi problemi è stata raggiunta solamente dopo numerosi tentativi e iterazioni. La conferma definitiva dell’efficacia delle soluzioni adottate sarà l’implementazione stessa.
Gli elementi critici da prendere in esame sono sostanzialmente tre: • Logica di creazione dei codici SAP;
• Gestione dei codici custom (ex categoria macchine); • Gestione della minuteria.
Si descrivono nei paragrafi seguenti le soluzioni puntuali adottate e le motivazioni che hanno influenzato le scelte fatte.
7.1
Logica di creazione dei codici SAP
La struttura creata ha avuto come risultato la blindatura di quasi tutti i campi da riempire durante la fase di apertura di un nuovo codice. La maggior parte di quelli non blindati sono gestiti tramite restrittive regole di riempimento.
Si focalizza l’attenzione su quelli che sono i sostanziali benefici che la nuova struttura può apportare:
• Facilitare le attività di codifica, rendendo più precise e strutturate le richieste di codifica per i nuovi item;
• Impedire la proliferazione dei codici facilitando l’individuazione a sistema di un oggetto (già codificato) di cui è richiesta nuova codifica;
• Ridurre lo stock di magazzino introducendo il concetto di sostituibilità, considerando quindi “uguali” due oggetti intercambiabili;
• Facilitare la ricerca dei codici da parte degli operatori, che potranno servirsi delle caratteristiche tecniche in fase di tracciamento dei ricambi.
Abbiamo fino ad ora parlato del concetto di blindatura e di procedure che regolino il processo di codifica di un nuovo ricambio. Non ci siamo tuttavia soffermati ad analizzare l’evenienza in cui l’operatore si trovi una richiesta di apertura di un nuovo codice descritto dalle stesse caratteristiche tecniche di un codice già esistente all’interno del database. Esistono due possibilità per gestire questa eventualità:
• Opzione A: Il SW SAP avvisa, con un alert, il codificatore che è già presente a sistema un item con le caratteristiche tecniche inserite. Il codificatore è tuttavia libero di valutare se esiste una differenza, non evidenziata dalle caratteristiche tecniche della struttura, che rende il nuovo oggetto non equiparabile a quello già a sistema. Il codificatore è dunque libero di creare un nuovo codice SAP con i medesimi parametri tecnici di quello già esistente;
• Opzione B: Il SW SAP, con un alert, blocca il codificatore nel suo tentativo di creazione di un nuovo codice, comunicandogli che è già presente a sistema un item con le caratteristiche tecniche inserite. In questo caso ogni gruppo deve essere descritto con tutte le caratteristiche tecniche sufficienti ad identificare un insieme di oggetti uguali o simili,che possono cioè essere tra loro intercambiabili.
È evidente che nell’ottica di blindatura finora perseguita l’opzione B sarebbe quella preferibile da adottare. Risulta tuttavia impossibile farlo perché, come già ribadito in precedenza, descrivere un ricambio con tutti i parametri tecnici che lo contraddistinguono diventa un lavoro eccessivamente oneroso.
Un espediente per poter utilizzare l’opzione B sarebbe l’inserimento del codice costrutto-re tra le caratteristiche tecniche dei gruppi i cui set di parametri non sono sempcostrutto-re garanzia di completa descrizione del ricambio. Anche questa soluzione diventa però difficile da attuare dal momento che i fornitori cambiano i loro codici ogniqualvolta esce una modifica
o una nuova versione del ricambio in questione. L’operazione di tracciamento dei codici fornitore viene già eseguita in partita e sarebbe un inutile dispendio di energie ripeterla anche all’interno delle caratteristiche tecniche.
Per i motivi sopra addotti è stata scelta l’opzione A per quanto non costituisca la soluzione più rigorosa. Il codificatore potrebbe trovare difficoltà ad interpretare le richieste di codifica e, di fronte a due oggetti con le stesse caratteristiche tecniche, potrebbe non essere in grado di stabilire se effettivamente esista una differenza tale da non poter assimilare il nuovo oggetto a quelli già codificati. Bisogna ricordare che l’operazione di codifica è demandata alla sede centrale del gruppo. Se la richiesta arriva da fuori il codificatore può non essere in grado di accertarsi, tramite ispezione visiva, dell’effettiva natura dei pezzi che sta catalogando. Tuttavia tramite controlli incrociati tra le partite e le informazioni contenute nei set di caratteristiche, integrate con foto e datasheet degli oggetti da codificare, l’addetto ai lavori dovrebbe essere in grado di prendere le decisioni più corrette in ottica di ottimizzazione.
7.2
Gestione dei codici custom
Prima ancora di spiegare come si è affrontato il problema riguardante la gestione di questo tipo di codici ha senso introdurre quali oggetti si trovassero all’interno della categoria macchine nella vecchia struttura. Questi sono sostanzialmente riconducibili a quattro tipologie:
• Item totalmente standard, venduto anche da altri fornitori, che può essere facilmente incasellato e descritto tramite le strutture della nuova codifica. Di questo oggetto si perderà l’informazione “custom” poiché la sua appartenenza alla categoria “macchine” era legata solamente all’essere montato sulla macchina di quel preciso fornitore; • Item realizzato a disegno le cui caratteristiche tecniche calzano con quelle di uno
dei gruppi della nuova struttura. Servirà, in alcuni casi, un ulteriore campo per descrivere eventuali particolarità dell’oggetto;
• Item realizzato a disegno per cui si può trovare una famiglia, ma non un gruppo compatibile a livello di caratteristiche tecniche ( non si riesce a riempire i campi previsti dalla nuova struttura).
Nella nuova struttura la categoria macchine è stata quasi completamente smantellata e quello che ne rimane non costituisce più una categoria a sé stante. Risulta dunque che tutti gli oggetti che vi erano contenuti andranno collocati altrove.
Gli oggetti appartenenti al primo tipo sopra presentato saranno incasellati nei relativi gruppi di appartenenza. Un cuscinetto standard, collocato nella categoria macchine solo perché arrivato insieme ad una macchina di uno specifico costruttore, verrà spostato nel gruppo cuscinetti ( Famiglia: cuscinetti; Categoria: ricambio meccanico).
Gli oggetti del secondo tipo verranno collocati nel gruppo di destinazione. È necessario evidenziare, però, che per descrivere l’oggetto non sono sufficienti le caratteristiche rese disponibili nel set. Per far questo si introduce, in quasi ogni gruppo, un campo in cui si può tramite una semplice logica Yes/No comunicare se l’oggetto sia custom o meno.
L’assegnazione della caratteristica custom ad un ricambio apre in automatico i campi costruttore e codice costruttore (gestiti da una logica “if”). In questa maniera si riesce a descrivere in maniera totalmente esaustiva il ricambio (vedi fig.7.1).
Figura 7.1: Caratteristica tecnica custom
In presenza di un oggetto del terzo tipo, cui riusciamo ad assegnare una famiglia, si ricorrerà al gruppo speciale. Collocandolo in tale gruppo sarà possibile utilizzare il campo “additional info” per descrivere liberamente l’oggetto. Si possono poi integrare le informazioni fornite con quelle presenti in partita.
Per catalogare gli oggetti del quarto tipo si sono create due famiglie: “Mechanical custom spare parts” e “Electrical custom spare parts”. I gruppi costituenti queste famiglie non sono altro che i fornitori da cui si sono acquistati i ricambi che vi sono contenuti. Sarà la prima caratteristica tecnica a dare informazioni sulla natura tecnologica del ricambio (vedi fig.7.2).
Qualora si utilizzi l’informazione riguardante il costruttore bisogna fare attenzione a distinguerla in maniera corretta da quella riguardante il fornitore.
La maggior parte delle volte fornitore e costruttore sono lo stesso soggetto, ma può succedere che un’azienda fornisca beni costruiti da un’altra. Può inoltre accadere che il
Figura 7.2: Struttura della famiglia “custom”
fornitore tenti di mascherare le informazioni riguardanti il costruttore per evitare che il cliente, in futuro, effettui riordini direttamente dalla ditta costruttrice. Bisogna assicurarci, in questa evenienza, di risalire esattamente al costruttore originario per poter riportare in partita le informazioni corrette.
7.3
Gestione della “minuteria”
In una fase iniziale del progetto era stato deciso, all’interno del comitato direttivo, di codificare qualsiasi ricambio presente all’interno dei magazzini. Effettuando un sopralluogo in alcuni magazzini campione si è capito che far questo non sarebbe stato possibile. Per oggettistica come minuteria metallica, raccorderia e tubazioni di piccole dimensioni è necessaria una gestione a vista non veicolata dal SW SAP. Questi ricambi di piccole dimensioni sono stoccati in scaffalature disposte all’interno dello stabilimento nei pressi delle officine o delle aree di lavoro. È dunque impensabile creare una struttura dedicata a questi item di piccole dimensioni. Il loro riapprovigionamento sarà curato a vista dagli addetti ai lavori o dai magazzinieri. In alternativa la loro gestione può essere demandata ad un fornitore esterno che, periodicamente, verrà a sincerarsi delle quantità disponibili effettuando il “refill” per gli oggetti in via di esaurimento.
Esistono tuttavia elementi di minuteria e di raccorderia di dimensioni e costi notevoli. Avendo interesse di classificare e catalogare questi oggetti si è dovuta introdurre una duplice gestione che fissi una soglia di costo unitario al di sopra della quale si è deciso di codificare
i ricambi.
Si sono perciò approntate strutture destinate ad accogliere gli item al di sopra della soglia prefissata.
