Il nuovo standard di classificazione
Nel presente capitolo si vuole presentare il nuovo standard di codifica progettato dal consorzio in collaborazione con Sofidel. Verrà descritta la nuova gerarchia, esplicitando le motivazioni che hanno condotto a determinate scelte e la filosofia che le ha accompagnate. Seguirà la presentazione di alcune famiglie, tra le più significative, per permettere di comprendere meglio il fine del lavoro svolto. Si introdurranno inoltre le nuove logiche da adottare su SAP per poter rendere fruibile ed efficace la struttura progettata. La creazione di procedure dettagliate del processo di codifica sarebbe infatti inutile se non correttamente corredata da un’interfaccia informatica. La lingua ufficiale utilizzata all’interno del nuovo sistema di codifica sarà l’inglese. In prima istanza, il cambio linguistico introdurrà notevoli difficoltà nel lavoro di magazzinieri e manutentori. Tuttavia, una volta che gli utenti avranno fatto proprio il vocabolario tecnico e familiarizzato con il nuovo sistema, ci si attendono grossi benefici a livello di standardizzazione linguistica e interfaccia cross-country.Si ricorda che il lavoro svolto avrà un valore aggiunto ridotto se, internamente all’azienda, non si attuerà un processo di coinvolgimento che conduca tutti gli enti che dovranno cimentarsi nell’utilizzo del nuovo sistema a farne proprie le logiche.
6.1
Descrizione delle attività
Il processo di progettazione si è articolato in diverse attività che hanno come requisito preliminare un’accorta analisi dei tabulati estratti dal sistema ERP.
Per ogni famiglia esistente si è effettuata un’attività di censimento finalizzata ad identificare possibili somiglianze nella descrizione breve materiale tra i codici al suo interno.
Questo nostro lavoro di analisi ha portato all’individuazione di un set di informazioni utili a Sofidel per classificare quella tipologia di oggetto.
I tabulati forniti da Sofidel contenevano un numero enorme di codici. Per semplificazione sono stati esclusi dall’analisi tutti i codici la cui prima cifra è ‘7’, riferiti a ricambi belgi ed americani.
Ci si è interrogati inoltre sul comportamento da seguire interfacciandosi a codici con giacenza pari a zero, ovvero codici riguardanti pezzi che hanno transitato dal magazzino, ma non presenti fisicamente al momento in cui è stata effettuata l’estrazione da SAP.
La politica adottata è stata quella di escludere dall’analisi i seguenti tipi di codice: • Codici con stock nullo la cui ultima movimentazione è risalente ad una data
antece-dente al 2010;
• Codici con stock nullo, mai movimentati, e creati prima del 2010.
Si è scelto di marcare come “da verificare” quei codici di parti di ricambio, sempre con giacenza nulla, mai movimentati, che sono stati creati dopo il 2010. Il team interno di Sofidel si è incaricato di verificare puntualmente la natura di tali articoli e se essi avessero o meno dignità di essere inclusi all’interno dell’analisi.
Nei prossimi paragrafi si presenteranno nel dettaglio le singole attività.
6.1.1 Creazione della nuova gerarchia
Durante la delineazione dello scenario As is si è parlato della gerarchia utilizzata dal gruppo in fase di catalogazione dei ricambi.
Ricordiamo che questa è organizzata su tre livelli: • Il primo indica il tipo di ricambio;
• Il secondo la famiglia tecnologica cui esso appartiene;
• Il terzo fornisce, in maniera poco chiara, informazioni sulle caratteristiche tecniche dell’oggetto inquadrandolo all’interno della famiglia.
Nel primo livello la scelta del tipo di ricambio può cadere su tre possibilità: ricambio meccanico, ricambio elettrico o ricambio custom.
La scelta all’interno del secondo livello ricade all’interno di 145 famiglie. Un numero estremamente elevato ed ingiustificato.
Il terzo livello, quasi mai esistente, ha una struttura poco chiara.
Si capisce bene che con questo sistema la classificazione e la ricerca degli item risultano difficoltose poichè non esistono nè tassonomie chiare che definiscano i tre livelli, nè procedure che obblighino chi richiede l’apertura di un nuovo codice, o il codificatore a compilare i tre campi.
E’ infatti a discrezione di chi compila i campi la scelta del livello di dettaglio a cui fermarsi.
La nuova gerarchia è nata al fine di eliminare le ambiguità e le falle presenti nel precedente sistema.
Essa mantiene comunque una struttura articolata su tre livelli:
• Categoria: Rappresenta il primo livello di classificazione. Come nel precedente caso, reca al suo interno informazioni sul tipo di ricambio. E’ stata tuttavia eliminata la categoria macchine, riducendo la scelta a ricambi meccanici o elettrici. Il modo in cui si è deciso di gestire gli item custom viene presentato più avanti.
• Famiglia: Il secondo livello della gerarchia ci dà informazione sulla natura del ricambio, specificando se esso sia un motore, una pompa, un azionamento, etc.; • Gruppo: Il gruppo delinea, con maggior grado di dettaglio, rispetto alla famiglia, la
natura del ricambio. Ad ogni gruppo sarà associato un set di caratteristiche tecniche che permetterà una precisa catalogazione, facilitando, nel futuro, le operazioni di ricerca. Se siamo in presenza di un ricambio meccanico, appartenente alla famiglia delle cinghie, potremo aspettarci di trovare tra i gruppi quello delle cinghie piatte, quello delle dentate, etc. Per maggior chiarezza si rimanda alla figura6.1.
La nuova gerarchia è composta da 2 categorie, 43 famiglie e 265 gruppi.
Al momento dell’inserimento di un nuovo codice all’interno del sistema ERP diventa obbligatorio compilare i campi inerenti a tutti i tre livelli. La compilazione non sarà di tipo libero, ma guidata da un menù a tendina che inibirà l’utilizzo di testo libero, eliminando alla radice i refusi di digitazione.
Figura 6.1: Nuova gerarchia prodotto
Come vedremo nel seguito della trattazione, la compilazione corretta dei vari livelli della gerarchia diverrà un requisito essenziale, poichè la ricerca su SAP sarà funzione della definizione del gruppo.
6.1.2 Definizione delle caratteristiche tecniche
Ad ogni gruppo creato corrisponderà un set definito di caratteristiche tecniche necessario per descrivere in maniera esaustiva l’oggetto.
Prima di presentare la modalità e i criteri che hanno portato alla scelta di determinati parametri tecnici è interessante introdurre la filosofia che ha guidato queste operazioni.
Grande importanza è stata data al concetto di Intercambiabilità. Due ricambi sono tra loro intercambiabili se uno può adempiere ai compiti dell’altro, ovvero essere sostituito al suo posto in caso di guasto, anche solo per gestire un’emergenza.
Si trascurano temporaneamente i concetti di prestazioni ed efficienza, concentrando l’attenzione sull’individuazione e l’accorpamento di questo tipo di oggetti.
Due oggetti saranno dunque intercambiabili se possiedono le medesime caratteristiche tecniche e andranno codificati con il medesimo codice SAP.
Si introduce ora un concetto che verrà sviluppato meglio in seguito per evitare errori di interpretazione di ciò che è appena stato scritto. E’ facile intuire che non sarà possibile classificare utilizzando tutti i parametri che possono descrivere un ricambio. Servirebbero
venti o trenta caratteristiche per oggetto, introducendo nel sistema un onere compilativo enorme.
Si deve quindi trovare un numero congruo di caratteristiche per ogni gruppo che sia al contempo in grado di identificare l’item e di non pesare eccessivamente sul lavoro dei codificatori e degli utenti.
Facendo questo si sacrificano alcuni parametri che, in determinate applicazioni, possono influenzare l’intercambiabilità.
In questo caso l’unico tutore della corretta classificazione sarà il codificatore.
SAP, una volta definita la gerarchia ed introdotte le caratteristiche tecniche, manderà un alert all’utente segnalando che esiste già un oggetto simile ed “apparentemente” inter-cambiabile. Sarà il responsabile del processo di codifica che dovrà sincerarsi se questo è effettivamente vero con un controllo incrociato sui due ricambi.
Lo scopo della definizione delle caratteristiche tecniche è quindi quello di creare uno standard di informazione da attribuire ad ogni gruppo di ricambi della codifica. Facendo questo si crea un filtro che permette di individuare un certo numero di oggetti simili. L’ultima revisione sarà del codificatore che dovrà decidere se quegli item hanno ragione di stare sotto il medesimo codice SAP o se è necessario separarli in quanto esiste una caratteristica extra che li rende non intercambiabili.
Il processo di assegnazione delle caratteristiche tecniche si è svolto parallelamente alla creazione della nuova gerarchia.
Partendo dalle estrazioni ottenute dal sistema ERP è stata effettuata un’analisi delle vecchie famiglie creando, passo passo, la nuova struttura e, grazie all’interpretazione delle vecchie “descrizioni brevi materiale”, assegnando le caratteristiche tecniche ai gruppi che venivano creati.
La scelta delle caratteristiche di ogni gruppo, definite in prima istanza dal Consorzio, ha avuto origine da un compromesso tra quelle che, dal vecchio sistema di codifica, sembravano le esigenze di Sofidel e quelli che, secondo la lettura tecnica, sono i parametri tecnici fondamentali per la descrizione dei ricambi.
Questo processo è stato fortemente iterativo per due motivi:
• Il procedere nell’analisi della vecchia struttura ha permesso di individuare ricambi o addirittura famiglie che costringevano a riconsiderare le logiche puntuali con cui si era costruita la struttura a monte;
• L’emissione da parte del Consorzio di una famiglia, divisa nei suoi gruppi, con le relative caratteristiche tecniche associate, era seguita da una fase di revisione ad opera di Sofidel. In un consesso appositamente indetto i due enti si sono trovati a discutere le soluzioni adottate. Grazie al feedback interno di Sofidel, fornito da personale di alta competenza tecnica, le strutture sono state perfezionate e ritagliate su misura al fine di adattarle ai bisogni interni dell’azienda.
Questa fase di revisione è stata articolata in 2 step. Il primo all’interno del comitato operativo con interfaccia diretta tra Sofidel e Quinn.
Il secondo coinvolgendo gli opinion leaders per avere pareri non solo a livello tecnico, ma anche riguardanti le scelte linguistiche adottate. I contributi arrivati da ogni paese sono stati rielaborati ed introdotti all’interno del nuovo sistema (vedi fig.6.2).
Figura 6.2: Distribuzione dei feedback forniti dagli opinion leaders
Nonostante questi due feedback, la conferma finale dell’efficienza della struttura e della scelta delle caratteristiche sarà fornita dalla fase di implementazione durante la quale si potrà capire se la gerarchia e i parametri scelti saranno facili da rintracciare per i ricambi da codificare.
Al momento della codifica di un ricambio il soggetto designato non potrà lasciare vuoto nessun campo, ma dovrà provvedere ad inserire le informazioni di cui è in possesso e a rintracciare quelle mancanti per arrivare ad identificare l’item. La compilazione dei campi sarà inoltre guidata in gran parte dei casi da elenchi di valori (menù a tendina), che eliminano l’inconveniente dell’utilizzo di testo libero. Questo concetto sarà chiarito meglio nel seguito durante la presentazione delle strutture di alcune famiglie.
6.1.3 Codifica parlante
La corretta costruzione della gerarchia prodotto e la definizione del set di caratteristiche sono gli ingredienti fondamentali per arrivare ad un sistema di codifica parlante efficace e strutturata.
Uno degli obiettivi di progetto era far sì che ad ogni codice SAP ne fosse associato automaticamente uno parlante.
Sarà quindi il sistema ERP, una volta compilate gerarchia e caratteristiche, ad elaborare una codifica descrittiva.
Quest’ultima è una lontana parente del testo breve materiale precedentemente esistente, ma estremamente snella e precisa nell’adempiere al suo compito comunicativo.
La codifica parlante deve infatti fungere da interfaccia diretta tra i codici e gli utenti del magazzino rendendo, a prima vista, agevole il riconoscimento del ricambio.
La logica che accompagna la creazione della stringa parlante è piuttosto semplice. Il sistema raccoglierà informazioni sia dalla gerarchia che dalle caratteristiche tecniche (vedi fig. 6.3), combinandole e abbreviandole al fine di costruire un record sintetico e al contempo esplicativo.
Figura 6.3: Struttura di un generico codice parlante
Per ogni gruppo sarà costruito un algoritmo dedicato che riorganizzerà i campi sopra citati.
La scelta di quali caratteristiche inglobare e di quali escludere è stata effettuata, di comune accordo tra Sofidel e Quinn, sulla base dell’importanza che queste rivestono per l’individuazione del ricambio.
Per non rendere eccessivamente lunga la stringa si è deciso di assegnarle una lunghezza di 40 caratteri, comprensiva dei separatori. Risulta evidente che alcuni parametrici tecnici dovranno essere esclusi dalla selezione per mancanza di spazio
Esempio Si riporta, per chiarezza esplicativa, un esempio in cui si mostra la codifica parlante assegnata al gruppo Cinghia dentata (Timing belt), appartenente alla famiglia
cinghie (Belt):
Be-TimingBelt-S-AT10-mm-C-1111,1-222,2
Senza scendere nel merito del significato dei vari campi (peraltro esplicitato più avanti nella trattazione) si può vedere che la struttura porta con sè due informazioni riguardanti la gerarchia prodotto e sei riguardanti le caratteristiche tecniche.
In totale questa stringa è composta da 38 caratteri.
Le informazioni sulla gerarchia non sono altro che abbreviazioni delle definizioni di famiglia e gruppo cui il ricambio fa riferimento.
Per questo gruppo si è deciso di riportare sei parametri tecnici nella stringa. Per ogni gruppo è stata effettuata un’attenta valutazione per scegliere le caratteristiche più significative ai fini dell’identificazione.
6.1.4 Interazione con il sistema ERP
Dopo aver progettato la gerarchia prodotto e definito i set di caratteristiche nonché le logiche di creazione del codice parlante, l’ufficio IT ha programmato l’interfaccia utente con SAP.
Per il caricamento dei dati nel sistema sono stati previsti appositi template che andranno progressivamente riempiti durante la fase di implementazione con tutte le informazioni riguardanti i codici ed i pezzi censiti. Oltre ad indicare quali caratteristiche inserire in ogni gruppo, nei template saranno definiti, per ogni campo, il tipo di dati da assegnare, la lunghezza e una serie di altre informazioni la cui conoscenza è necessaria per effettuare una buona blindatura della fase compilativa.
Ogni gruppo avrà il proprio template dove sono previsti tabulati da riempire, per ogni codice visionato in magazzino, con i parametri tecnici e dove sono descritte le logiche puntuali per la costruzione del codice parlante.
Durante la fase di implementazione si prevede una stretta collaborazione tra il gruppo operante in magazzino, per il riconoscimento dei ricambi, e l’ufficio IT di Sofidel; in questo modo si evita di fare un caricamento massivo dei dati a lavoro terminato e lo si dilaziona lungo tutta la durata delle operazioni.
Il caricamento delle strutture su SAP non impedisce che queste possano ancora essere modificate per adattarsi a bisogni improvvisi insorti durante l’analisi di magazzino.
Ogni modifica diventerà invece irreversibile quando i template, ormai caricati a sistema, verranno riempiti con i codici analizzati.
Dopo questa breve presentazione della modalità di caricamento dei dati nei database di Sofidel, si espongono le procedure con cui manutentori e magazzinieri dovranno interfacciarsi con SAP.
Le due fasi più interessanti da presentare sono quella di introduzione di un nuovo codice e quella di ricerca di un ricambio:
• Introduzione di un nuovo ricambio a sistema: Per questa operazione è stata costruita una maschera che, a differenza della precedente (vedi fig. 5.2), vincola il codificatore a riempire tutti i campi previsti. Dopo aver compilato le informazioni di carattere prettamente commerciale o legate all’ubicazione del ricambio, l’utente deve procedere a definire la gerarchia prodotto e ad inserire valori compatibili nelle caselle associate ai parametri tecnici richiesti. Questi dovranno essere tutti compilati a meno che non si inneschino logiche “if” di SAP che consentono l’omissione di qualche valore (Questo concetto sarà esplicitato meglio negli esempi che seguono).
• Ricerca di un codice: Al bisogno, un magazziniere o un manutentore potranno servirsi della nuova struttura per cercare agevolmente un pezzo attraverso le sue caratteristiche tecniche all’interno di SAP e, tramite l’informazione sull’ubicazione, rintracciarlo velocemente in uno dei magazzini del gruppo.
Se in caso di rottura di un pezzo se ne vorrà trovare uno intercambiabile, ovvero con le medesime caratteristiche tecniche, egli potrà procedere dettagliandone famiglia e gruppo di appartenenza ed inserendo poi, in un’apposita maschera di ricerca, anche solo alcuni dei parametri tecnici a cui è interessato.
La fase di definizione della gerarchia prodotto è di fondamentale importanza: i gruppi costituiscono infatti dei sottoinsiemi chiusi nelle logiche SAP. Le ricerche per caratteristiche di dettaglio sono possibili solo all’interno di essi e non trasversalmente.
La definizione del gruppo all’interno del quale si suppone si trovi il ricambio desiderato, è requisito necessario per avviare la ricerca.
Selezionata la gerarchia prodotto, una maschera generata da SAP guida l’utente nella ricerca delle caratteristiche che ha necessità di conoscere.
Si capisce che questo processo non identificherà necessariamente un item puntuale, ma funzionerà come filtro per isolare un insieme di item accomunati da gerarchia e caratteristiche richieste.
Una volta delimitato il campo d’azione della ricerca è necessaria una fase di individua-zione fisica del ricambio ricercato.
Nel seguito della trattazione si presentano alcune famiglie, scelte come casi di studio, per mostrare il lavoro fatto e presentare le principali criticità incontrate. Lo scopo è quello di mostrare al lettore, tramite analisi puntuale di alcuni gruppi e caratteristiche salienti, le soluzioni adottate a fronte delle varie tipologie di problemi affrontati.
6.2
La famiglia “Belt”
La prima famiglia trattata è quella delle “cinghie”, appartenente alla categoria dei ricambi meccanici. Tramite l’analisi di questa e delle seguenti famiglie, si vogliono mostrare nel dettaglio le attività in cui si è articolata la prima fase di progetto.
A monte della creazione della nuova struttura è stata effettuata un’analisi dettagliata delle tabulazioni estratte da SAP per quella che, anche nel vecchio sistema di codifica, era la famiglia “Cinghie”.
E’ emerso che la vecchia gerarchia non sempre definisce per i ricambi i tre livelli previsti, fermandosi spesso al secondo.
Quando essa è completa va ad identificare la tipologia di cinghia trattata (dentata, liscia, etc.) inquadrando però solo alcune delle possibili esecuzioni.
Il testo breve materiale utilizzato per descrivere il singolo ricambio, il cui inserimento non è regolato da alcun criterio, risulta farraginoso e incompleto nella gran parte dei casi.
Nella figura 6.4 è possibile vedere lo scheletro della nuova struttura.
E’ stato qui omesso il primo livello gerarchico, ma, come è stato precisato in precedenza, si tratta di un ricambio di tipo meccanico.
A questa famiglia sono stati assegnati sette gruppi: Cinghie dentate (Timing belt), Cinghie lisce (Flat belt), Cinghie trapezoidali (V-belt), Cinghie saldanti (Heat sealing belt), Cinghie tonde (Round belt), Cinghie di trasporto (Conveyor belt) e Cinghie speciali (Special
Per evitare di appesantire eccessivamente la lettura non si analizzeranno tutti i gruppi presentati, limitandoci alle casistiche più interessanti. Tra i sette gruppi introdotti sopra, i primi cinque differenziano le cinghie per le loro caratteristiche morfologiche; è interessante invece soffermarsi sulle logiche che hanno portato alla creazione degli ultimi due.
Conveyor belt In questo gruppo sono comprese tutte le cinghie che non svolgono il compito di trasmissione di potenza. Costruttivamente come si può osservare dalle caratteristiche elencate in figura 6.4 sono praticamente identiche alle normali cinghie. Il fattore distintivo è la funzione che le caratterizza all’interno dello stabilimento. In fase di interfaccia diretta con i tecnici di Sofidel è stata espressa l’esigenza di distinguere questo tipo di ricambio dagli altri, sia fisicamente in magazzino che virtualmente all’interno di SAP.
Special belt Il gruppo “speciale” è stato creato in quasi tutte le famiglie. E’ destinato ad accogliere tutti gli oggetti appartenenti a quella famiglia, ma che non sono collocabili in alcuno dei gruppi disponibili. Siamo dunque in presenza di una cinghia particolare, che non viene descritta al completo da nessuno dei set di caratteristiche tecniche presentati. Come si vede le uniche caratteristiche del gruppo “speciale” sono il tipo di cinghia e un campo di informazioni addizionali costituito da un testo libero di circa 20 caratteri che rappresenta un’eccezione rispetto agli standard. Come già detto in precedenza, dalla nuova struttura è stato eliminato quasi completamente l’utilizzo di testo libero. Questo è stato possibile fornendo, nella maggior parte dei casi, delle opzioni compilative che hanno portato alla blindatura dei campi. Ovviamente in presenza di campi che richiedono l’inserimento di un valore numerico, la compilazione sarà libera, ma vincolata all’inserimento di soli numeri.
Non si riesce ad eliminare totalmente il rischio di errori compilativi, ma, visto che nella nuova gestione l’inserimento di nuovi codici sarà demandato solo al responsabile dell’area centrale, si riducono notevolmente le possibilità di sbagliare.
Si scende ora nel dettaglio di alcuni gruppi per mostrare e giustificare alcune delle scelte adottate. Dalla presentazione meticolosa del gruppo Timing belt si passerà alla descrizione di alcune casistiche salienti.
Cinghie dentate
Le cinghie dentate, gruppo la cui struttura è presentata nella prima colonna della figura 6.4, presentano un set di nove caratteristiche tecniche.
Per fare un excursus su alcune delle problematiche incontrate durante la progettazione si presentano singolarmente le più significative:
• Timing belt type: Questa caratteristica indica il tipo di dentatura, singola o doppia, della cinghia. Si introduce subito il concetto di blindatura dei campi. In figura 6.4 si vedono tra parentesi le due possibili opzioni selezionabili. Tutte le possibilità saranno gestite da SAP in un file chiamato help che per ogni caratteristica blindata fornirà la rosa di scelte a disposizione, tramite un apposito menù a tendina.
• Timing belt profile: In questo campo si decide il profilo della dentatura della cinghia. Esso è identificato da una stringa alfanumerica. Anche in questo caso la caratteristica è blindata e gestita tramite help.
• Unit of measurement: Viene introdotta per alcuni dei profili dentati (L, XL, etc.) che al contrario degli altri sono, in letteratura, misurati e catalogati in pollici. Questo campo, dotato di help servirà per gestire una logica “if” costruita all’interno di SAP: selezionare “mm” darà accesso alla compilazione dei campi belt pitch lenght e belt
width, espressi in mm; viceversa selezionare “inch” impedirà la compilazione di questi,
rendendo invece fruibili i campi belt pitch lenght code e belt width code.
• Open end/Endless: Questa caratteristica indica se la cinghia è stoccata in magaz-zino a metratura oppure già chiusa e pronta all’utilizzo. Se la cinghia è stoccata a metro non si vuole riportare tra le caratteristiche quella concernente la lunghezza, che andrebbe continuamente tracciata e aggiornata in maniera molto approssimativa. Dal momento che gestire una logica “multi-if“ diventa eccessivamente oneroso per l’ufficio IT, si è deciso di adottare una logica interna per cui, in presenza di cinghia aperta, si assegna in maniera fittizia il valore “1” alla lunghezza (si sarebbe scelto il valore zero, ma SAP non lo accetta in fase compilativa).
• Belt pitch lengh & Belt width: Queste caratteristiche, compilabili qualora si sia selezionato Unit of measurement=mm, sono campi numerici in cui inserire sviluppo primitivo e larghezza della cinghia.
• Belt pitch lengh code & Belt width code: Queste due caratteristiche sono l’alternativa alle due precedentemente presentate. La differenza è che non riportano un valore effettivo in pollici, ma un codice che può essere trasformato in valore
fruibile tramite semplice conversione. Si è scelto di lasciare il codice poichè questo è direttamente stampato sulla cinghia e quindi facilmente rintracciabile.
• Presence of cleats & Number of cleats: Queste caratteristiche sono state prese in considerazione per evidenziare un diverso risvolto della logica “if” adottata. Se viene selezionata l’opzione Presence of cleats (Presenza di tasselli)=Y (Campo blindato con un semplice help Y/N), si avrà allora accesso al parametro “Numero di tasselli”. Viceversa questo campo rimarrà bloccato e non compilabile.
Codifica parlante: Una volta presentate la struttura e il set di caratteristiche designato, si illustra brevemente la nuova logica per la costruzione della codifica parlante associata a questo gruppo. Questo record descrittivo sarà, come illustrato in precedenza, generato in automatico nel momento in cui verranno definite gerarchia e caratteristiche. Estrapolando informazioni da entrambe, SAP costruirà un codice parlante descrittivo dell’oggetto.
Il codice parlante per una generica cinghia dentata sarà: Be-TimingBelt-S-T10-mm-C-1111,1-22,2
Si può notare che solo alcune delle caratteristiche tecniche del gruppo sono riportare nel codice parlante. Analizzandolo brevemente, si capisce che le prime due informazioni riguardano la gerarchia prodotto, la S indica una dentatura singola, AT10 il profilo della dentatura e il passo, mm indica che lunghezza e larghezza (riportate a seguire in questo ordine) saranno espresse in millimetri e la C che la cinghia è chiusa.
Il codice parlante per una cinghia dentata stoccata a metraggio sarebbe stato: Be-TimingBelt-S-L-inch-O-1-075
Questo descrive una cinghia il cui passo è espresso in pollici; il valore L è assimilato ad un passo di 3/8 inch, con dentatura singola.
Come introdotto in precedenza alla selezione dell’opzione cinghia aperta (O=Open end) corrisponde la compilazione del campo lunghezza con un valore fittizio pari ad uno.
E’ possibile anche osservare il codice larghezza 075, utilizzato per le cinghie catalogate tramite british unit system; dividendolo per cento si ottiene il valore effettivo della larghezza in pollici.
Per riuscire ad interpretare il codice parlante, qualora non sia semplice comprendere a prima vista le abbreviazioni, si può far riferimento alla tassonomia (riportata in appendice) per quanto riguarda la gerarchia e all’help per le caratteristiche tecniche.
Merita spendere qualche parola anche sul gruppo delle cinghie saldanti. Senza soffermarsi sulle singole caratteristiche è interessante specificare che questi ricambi daranno origine a codici aventi come prima cifra ‘8’, siamo in fatti in presenza di ricambi consumabili. Le cinghie saldanti sono utilizzate nell’ultima fase di imballaggio ed hanno il compito di accompagnare e di riscaldare il nylon che confeziona il blister fino a saldarlo per garantirne la chiusura.
Dato che questi item si usurano a contatto col prodotto in lavorazione si tratta per definizione di ricambi a consumo.
6.3
La famiglia “Bearing”
Si prosegue con la trattazione della famiglia cuscinetti, anch’essi appartenenti alla categoria dei ricambi meccanici. L’assegnazione dei set di caratteristiche è stata più agevole poiché è stato possibile basarsi sulla struttura creata da SKF, azienda leader nella produzione di cuscinetti, nonché uno dei principali fornitori di Sofidel.
Anche nella vecchia struttura, nelle descrizioni brevi materiale di questi ricambi, si ritrova la codifica di SKF, seppur senza rigore né ordine costituito.
La nuova famiglia predisposta per ospitare i codici riguardanti i cuscinetti (vedi fig.6.5) è divisa in quattro gruppi: Cuscinetti (Bearing), Perni folli (Cam follower), Accessori per cuscinetti (Bearing accessories) e Cinghie speciali (Special bearing).
Cuscinetti
Per mostrare il metodo con cui si è attinto al sistema di codifica SKF, si analizza nel dettaglio il set di caratteristiche tecniche associate al gruppo Bearing:
• SKF designation: In questo campo si inserisce l’appellativo che SKF dà al cusci-netto. Si tratta di una stringa alfanumerica, in cui sono contenute gran parte delle informazioni riguardanti il cuscinetto, ricavabili utilizzando le disposizioni previste dal costruttore nel catalogo. Dal momento che questo appellativo è alfanumerico e non è sempre costituito da un numero di caratteri costante, il codificatore dovrà porre massima attenzione a non fare errori in fase compilativa. Dovrà inoltre sincerarsi della correttezza delle informazioni relative a questo campo che gli sono giunte nella richiesta di apertura di un nuovo codice. Qualora il cuscinetto non sia stato comprato
da SKF, ma da un altro costruttore, esistono apposite tabelle di conversione che dalle caratteristiche tecniche permettono di risalire alla designazione SKF.
• Rolling elements type: Questo campo fa riferimento al tipo di elementi volventi presenti all’interno del cuscinetto. Si tratta di un campo blindato e dotato di apposito help.
• Bearing configuration: È qui riportata l’informazione riguardante il tipo di carico che il cuscinetto può sopportare. Anche questo è un campo blindato che permetterà la selezione delle tre opzioni: radiale, assiale od obliquo.
• Bearing design: In questo campo si trovano informazioni sul tipo costruttivo del cuscinetto, sia esso orientabile, ad Y, etc.
• Bearing bore diameter, outside diameter, width: In questi campi sono con-tenute le informazioni geometriche riguardanti il cuscinetto; nell’ordine si trovano diametro interno, diametro esterno e larghezza. Si tratta di campi in cui è vincolato l’inserimento di valori numerici.
• Bearing bore shape: Questa caratteristica informa l’utente sull’esecuzione dell’a-nello interno del cuscinetto e, di conseguenza, sul tipo di calettamento da prevedere. Le opzioni di scelta saranno esecuzione cilindrica/esecuzione conica.
• Bearing with plummer block: In questo parametro si indica se il cuscinetto è stoccato all’interno del magazzino con il relativo supporto.
Come anticipato nella descrizione di “SKF designation”, in questo campo sono reperibili, tramite apposita tabella di conversione, tutte le informazioni necessarie ad identificare univocamente il cuscinetto.
Sembra perciò ridondante l’inserimento di tutte le ulteriori caratteristiche, geometriche e non, che in apparenza non fanno altro che appesantire il lavoro computazionale del codificatore e di chi invia la richiesta di codifica.
Si coglie l’occasione per rimarcare il concetto che, in fase di inserimento di un nuovo codice, il sistema non accetta in fase di input una richiesta in cui tutte le caratteristiche tecniche non siano state compilate nel rispetto dei vincoli previsti.
In realtà l’inserimento di tutti i parametri che seguono la designazione SKF è stata pensata per perseguire il fine dell’intercambiabilità.
È ovvio che due oggetti avente diversa “SKF designation”, essendo questa una caratte-ristica tecnica, verranno classificati con diversi codici SAP.
Non saranno quindi allocati nello stesso spazio in magazzino, né verranno ritenuti, in prima istanza, intercambiabili.
Tuttavia in casi di emergenza, in assenza del ricambio cercato, il manutentore, con l’aiuto del magazziniere, può effettuare una ricerca basata su parametri tecnici. Individuerà un item che, pur non avendo la stessa designazione SKF di quello da sostituire, può, anche provvisoriamente, sopperire alle necessità. In questo modo ci si tutela da possibili fermate dell’impianto sacrificando, almeno temporaneamente, efficacia e prestazioni.
Non ci soffermiamo nella descrizione dei gruppi accessori cuscinetti e cuscinetti speciali. Si vuole invece motivare la scelta che ha portato alla creazione di un gruppo dedicato ai perni folli (Cam follower).
Questo ricambio nel vecchio sistema di codifica veniva chiamato “Cuscinetto F”, andando ad identificare con F la sua natura di perno folle.
L’assimilazione di questi ricambi a cuscinetti veniva fatta poiché si tratta di oggetti costruiti anche da SKF e soprattutto codificati secondo la logica di questo costruttore.
Nella nuova struttura non è stato però possibile inserirli nel gruppo “Bearing” essendo impossibile riempire il set di caratteristiche. È stato dunque deciso di creare un gruppo a parte che permettesse di identificarli immediatamente e li descrivesse con più semplicità.
Nella vecchia gerarchia all’interno della famiglia dei cuscinetti sono stati trovati anche dei ricambi denominati “Manicotto lineare a sfere”, “Cuscinetto M”, “Snodo sferico” e “Rod end”.
Nonostante siano anch’essi item prodotti da SKF non ha senso collocarli all’interno della famiglia cuscinetti trattandosi di giunti prismatici e rotoidali.
È stata creata un’apposita famiglia chiamata “Joint” (Coppie cinematiche) che, orga-nizzata in opportuni gruppi, potesse contenere questi oggetti e descriverli con le adeguate caratteristiche.
Tra i gruppi in cui è divisa la famiglia “Joint”, oltre a Rod end, Snodi sferici (Ball
joint) e Manicotti lineari(Linear bearing) si annovera quello dedicato alle viti a ricircolo di
Codifica parlante: Si riporta a seguire un esempio di codifica parlante associata al gruppo “Bearing”:
Bn-Bearing-B-61803-2RS1
I primi due campi forniscono informazione su famiglia e gruppo, in questo caso omonimi. Le informazioni riguardanti le caratteristiche tecniche sono, in numero, molto ridotte: una volta definito il tipo di corpi volventi (lettera B=Ball), ci si limita a riportare la SKF designation. Da questa informazione, spesso stampigliata sul cuscinetto, si riesco-no facilmente, tramite catalogo, a coriesco-noscere tutti i parametri costruttivi riguardanti il cuscinetto.
In particolare il cuscinetto 61804-2RS1 sopporta carichi di tipo radiale, ha diametro interno pari a 20 mm, esterno pari a 32 mm e larghezza pari a 7 mm. Dal catalogo si vede che è non orientabile e non possiede altre caratteristiche particolari. La sigla 2RS1 fornisce informazioni sul tipo di schermatura di cui il ricambio è dotato.
6.4
La famiglia “Motor”
Si presentano ora due famiglie appartenenti alla categoria dei ricambi elettrici. La prima delle due è la famiglia “Motor”, che al suo interno ospita i codici relativi ai differenti tipi di motori elettrici utilizzati all’interno degli impianti di produzione. Il motore elettrico è uno degli elementi maggiormente presente nel sito produttivo. Le specifiche necessarie per identificare ciascun motore sono riportate dal costruttore su una targa affissa sulla carcassa dello stesso. La forma e la disposizione dei dati all’interno della targa differiscono a seconda del fornitore, ma i dati riportati sono sostanzialmente sempre gli stessi.
La famiglia “Motor” è divisa in otto gruppi (vedi fig.6.6): Motori a doppia velocità (Double speed Motor), Motori AC (AC Motor), Motori DC (DC Motor), Motori brushless (Brushless Motor), Motori passo-passo (Stepper Motor), Motori a controllo vettoriale (Vector control AC Motor), Spazzole per motore (Motor brush) e Accessori per motore (Motor accessories).
Il gruppo “Vector control AC motor” è stato creato su espressa richiesta degli interni di Sofidel. Si tratta di oggetti che costruttivamente altro non sono che motori alimentati in corrente alternata, ma, per il particolare sistema con cui sono controllati, devono essere individuati univocamente.
Le tecniche di controllo vettoriale permettono di governare il transitorio elettromagne-tico, non regolabile tramite controllo di tipo scalare. Il controllo vettoriale si basa su una opportuna scelta degli assi di riferimento utilizzati dal sistema d controllo per determinare le componenti del vettore corrente statorica.
Visto la repentina crescita dell’utilizzo di questo tipo di ricambio è stato deciso che abbia un gruppo dedicato che ne consenta l’immediata tracciabilità.
Le spazzole per motori potrebbero essere tranquillamente incluse nel gruppo “Motor accessories”, la cui prima caratteristica definisce proprio il tipo di accessorio trattato. Dato l’elevato numero di codici associati a spazzole all’interno del database, è stato deciso di creare un gruppo dedicato.
Si procede ora con l’analisi dettagliata del gruppo “AC motor”, andando ad evidenziare le maggiori problematiche sorte durante la fase di assegnazione del set di caratteristiche.
Motori AC
Le informazioni ritenute indispensabili per un rapido riconoscimento dei motori alimen-tati in corrente alternata sono le seguenti:
• Rated output power at 50 Hz & Rated output power at 60 Hz: In questi due campi si riportano le informazioni riguardanti la potenza che il motore può sviluppare a 50 (frequenza della rete elettrica europea) o a 60 Hertz (frequenza della rete americana).
• Number of motor poles: Viene fornito il numero di poli del motore. Da questa informazione, tramite una semplice operazione si può risalire alla velocità del motore espressa in giri al minuto:
n = 2· 60 · fp (6.1)
dove con n si sono indicati i giri al minuto del motore, con f la frequenza di eccitazione e con p il numero di poli.
• Power supply voltage: Si riporta qui l’informazione riguardante la tensione di alimentazione del motore. Questo campo sarà blindato e riporterà i valori principali di tensione possibili nella rete europea (230/400V, 400/690V) e quelli della rete americana (460V).
• Motor mounting arrangement: Questo parametro riporta informazioni riguar-danti l’ancoraggio del motore. Anch’esso è un campo blindato cui fa riferimento un
help in cui sono elencate tutte le possibili posizioni di montaggio del motore.
• Type of braking system: Questo parametro ci informa se il motore sia o me-no dotato di sistema di frenatura. In presenza di quest’ultimo ci fornisce anche informazioni relative alla sua tensione di alimentazione del sistema.
• Motor bearing design: Questa caratteristica descrive il tipo di cuscinetto che sorregge l’albero motore. Esso solitamente è a sfere, ma può essere montato a rulli qualora l’albero sia sottoposto a cimenti particolarmente gravosi
In fase di progettazione della struttura ci siamo posti il problema se fosse o meno necessario introdurre entrambe le informazioni riguardanti le potenze a 50 a 60 Hz. Nei motori meno moderni comprati da fornitori europei l’informazione riguardante la potenza a 60 Hz è molto difficile da rintracciare e può essere stimata soltanto per similitudine in maniera molto approssimativa. Ricordando che il gruppo possiede stabilimenti anche oltre oceano si sono inseriti entrambi i campi obbligatori da compilare per impedire l’insorgenza di errori di codifica.
Se fosse inserita una sola informazione riguardante la potenza, senza alcuna informazione sulla frequenza di utilizzo, non si riuscirebbe, codificando sia in Europa che in America con lo stesso standard, a sapere per quale frequenza quel valore è effettivo. Si correrebbe il rischio di accorpare sotto lo stesso codice due ricambi con le medesime caratteristiche, potenza inclusa, ma provenienti dai due continenti diversi. Questo porterebbe ad errori interpretativi nel caso (molto raro) in cui si verifichi l’esigenza di cedere il ricambio ad uno stabilimento dell’altro paese. Non ci sarebbero grandi problemi spedendo un motore in America dall’Europa poiché l’item funzionerebbe ugualmente anche se con prestazioni inferiori a quelle di targa. Il viceversa porterebbe invece a ricevere un oggetto sottodimensionato e quindi inutilizzabile per l’applicazione prevista.
Se si fosse imposto di codificare sempre seguendo gli standard Europei, si sarebbero create delle difficoltà oltreoceano nelle fasi di ricerca che avrebbero richiesto una fase preliminare di conversione dei valori.
La soluzione finale è stata appunto quella di inserire entrambi i valori appesantendo leggermente la fase di reperimento di informazioni durante l’implementazione.
La presenza della doppia potenza ha portato ad errori interpretativi anche nella fase di analisi dei tabulati estratti dal database della vecchia struttura.
Questo doppio valore poteva infatti far riferimento a due differenti casistiche:
• In alcune applicazioni esso faceva riferimento alle potenze espresse in funzione delle due differenti frequenze eccitatrici;
• In altre indicava le due potenze sviluppabili a 50 Hz da motori a doppia velocità. Per eliminare questa ambiguità si è dovuto incrociare il controllo sulla potenza, con quello sul numero di poli: un doppio numero di poli insieme ad un doppio valore di potenza ci garantisce di avere a disposizione un motore a doppia velocità.
Nella nuova struttura (vedi fig.6.6) per il gruppo Double speed motor è richiesta la compilazione di quattro distinti campi di potenza, essendo possibile sviluppare due diverse potenze a 50 e due a 60 Hz.
Quando si è introdotta la gestione a partita si è descritto il modo di tracciare all’interno di essa le informazioni riguardanti il costruttore (Manufacturer) e il codice costruttore del ricambio (Manufacturer item code). Dal momento che queste informazioni sono gestite nella partita, sono state inserite nei set di caratteristiche associate ai gruppi solo in presenza di ricambi molto specifici e particolari, per cui anche l’identificazione del costruttore rappresenta un criterio discriminativo.
E’ il caso dei motori brushless, tra le cui caratteristiche tecniche ritroviamo “Manufac-turer” e “Manufacturer item code”.
Questi ricambi specificatamente progettati per determinate applicazioni, necessitano di un azionamento dedicato ed appropriatamente programmato. È quindi necessario tracciarli individualmente poiché praticamente impossibili da intercambiare.
Codifica parlante: Si riporta un esempio di stringa parlante per il gruppo “AC motor”: Mo-ACMot-0,37kW-4P-230/400V-B5-NU
La regola di composizione è sempre la medesima: Primo e secondo campo identificativi rispettivamente di famiglia (Mo:Motor) e gruppo (ACMot:AC Motor); Dal terzo iniziano le caratteristiche tecniche nella cui interpretazione siamo aiutati, in alcuni casi dalla presenza delle unità di misura. Nell’ordine troviamo informazioni su potenza (0,37kW), numero
di poli (4P), tensione di alimentazione (230/400V), ancoraggio (B5) e tipo di cuscinetto montato (NU).
È interessante notare che “NU” è la designazione SKF per indicare un cuscinetto a rulli, adottata anche in questo caso per semplicità comunicativa.
6.5
La famiglia “Pump”
Si presenta ora la famiglia delle pompe, appartenente anch’essa alla categoria dei ricambi di tipo elettrico. Sia nell’ambito di cartiera che di trasformazione sono presenti numerosi sistemi di pompaggio. È dunque evidente la necessità della presenza di questi ricambi in magazzino e della loro immediata rintracciabilità
La famiglia “Pump” è divisa in nove gruppi (vedi fig.6.7): Pompe a vuoto (Vacuum
pump), Pompe centrifughe (Centrifugal pump), Pompe sommerse (Submerged pump),
Pompe pneumatiche (Pneumatic pump), Pompe idrauliche a ingranaggi (Hydraulic gear
pump), Pompe idrauliche a pistoni (Hydraulic piston pump), Pompe dosatrici (Metering pump), Accessori per pompa (Pump accessories) e Pompe speciali (Special pump).
La famiglia pompe è stata costruita ad hoc per le necessità di Sofidel, creando dei gruppi molto specifici che avrebbero dovuto essere catalogati insieme per natura costruttiva. Illustreremo più avanti la soluzione prospettata da Quinn in prima istanza.
Si procede a descrivere il gruppo delle “Vacuum pump” facendo un rapido excursus sul set di caratteristiche scelto.
Pompe a vuoto
Una pompa a vuoto è un dispositivo meccanico utilizzato per creare il vuoto in un ambiente in modo da facilitarvi l’introduzione di fluido che verrà rilasciato, previa compressione, in un ambiente a pressione maggiore.
Le informazioni ritenute necessarie per un’adeguata classificazione sono le seguenti: • Vacuum pump type: Si elencano in questo campo i vari tipi di pompa a vuoto
utilizzati da Sofidel. Il campo è dotato di help e propone le soluzioni visibili in figura 6.7.
• Motor power: In questo campo si riporta in kW la potenza del motore che aziona la pompa.
• Flow rate: Vi si inserisce il dato relativo alla portata della pompa. Nella vecchia struttura questa era indicata con una miriade di unità di misura diverse. Per la nuova si è scelto di adottarne una univoca per gruppo, in funzione della quantità di fluido trattata dalla pompa. Per le pompe a vuoto si è scelto di utilizzare m3/h. • Vacuum pump attachment: Questa caratteristica riporta le dimensioni di attacco
idraulico della pompa di solito espresse tramite l’NPS (Nominal pipe size). Questo parametro fornisce informazioni approssimative sul diametro esterno in pollici. Per trovare il valore esatto serve un’apposita tabella di conversione.
• Head: In questo campo si deve riportare l’informazione riguardante la prevalenza della pompa. La sua unità di misura dipende dal gruppo in cui si colloca la pompa e può essere espressa in metri o in bar. Per le pompe a vuoto si utilizzano i metri. Come anticipato in precedenza, la struttura progettata inizialmente dal Consorzio era molto differente da quella definitiva adottata ed era stata costruita rifacendosi ai dettami della letteratura impiantistica.
In questa struttura (vedi fig.6.8) la famiglia pompa era divisa in soli cinque gruppi fornendo una soluzione più snella, ma meno funzionale ai bisogni interni dell’azienda.
Il terzo livello della gerarchia era articolato in cinque gruppi:
• Turbopompa: Questo gruppo conteneva le pompe in cui l’aumento di pressione avviene per conversione di energia cinetica conferita al fluido da una girante. La prima caratteristica tecnica avrebbe identificato il tipo di rotore e la sua modalità d’azione differenziando le pompe in centrifughe, semiassiali o assiali.
• Pompa rotativa: Insieme alla pompa alternativa costituirebbe il macrogruppo delle pompe volumetriche. Il pompaggio avviene trasferendo volumi di liquido da un ambiente ad uno di pressione maggiore. L’organo meccanico che fornisce energia al fluido è dotato di moto rotatorio. Sono riconducibili a questo gruppo le pompe ad ingranaggi, a lobi, a palette e a vite.
• Pompa alternativa: Anch’essa è una pompa volumetrica con la differenza che l’organo cui è demandato l’aumento di pressione è dotato di moto alternativo. A questo gruppo appartengono le pompe a membrana e quelle a pistoni.
• Pompa sommersa: Presente anche nella struttura definitiva adottata, questo tipo di pompa, grazie all’ermeticità di tutti i componenti elettrici e all’accoppiamento
Figura 6.8: Prima emissione della struttura della famiglia pompe
diretto del motore con la girante, può operare direttamente immersa all’interno del fluido.
• Accessori pompa: Gruppo presente anche nella struttura definitiva che accoglie tutti gli accessori necessari per le pompe.
La struttura appena presentata, sebbene tecnicamente più corretta, poco si adattava alle esigenze di Sofidel ed avrebbe complicato notevolmente le operazioni di catalogazione e ricerca. È stata pertanto scartata.
Codifica parlante: Si riporta un esempio di codifica parlante per il gruppo “Vacuum pump”:
Pm-Vacuum-Vane-2,3m3/h-12,7m
Si riconoscono i primi due campi associati alla gerarchia che ci danno rispettivamente informazione sulla famiglia (Pm: Pump) e sul gruppo (Vacuum: Vacuum pump).
A seguire troviamo alcune della caratteristiche tecniche; la prima ci fornisce informazione sulla tipologia costruttiva (Vane: Pompa a palette), la seconda sulla portata e la terza sulla prevalenza. In questo caso l’interpretazione delle caratteristiche è facilitata dalla giustapposizione delle unità di misura al parametro.
Quelle presentate nella trattazione sono solo alcune delle 43 famiglie. Sono state scelte come modello perché al loro interno si trovano esempi significativi delle maggiori problematiche tecniche emerse in fase di progettazione, dalla gestione delle unità di misura, alla necessità di costruire soluzioni “ad hoc” per il gruppo cartario. Ovviamente, per brevità di trattazione, sono state omesse tantissime criticità puntuali che si sono dovute affrontare durante l’analisi di ogni famiglia.
