Capitolo 3 Processo Informativo per il rilascio commessa

3.

Capitolo 3

Processo Informativo per il rilascio commessa

Nel seguente capitolo vengono descritti alcuni dei sistemi informativi che l’aziendausa per automatizzare e ottimizzare le attività che vengono svolte al Nuovo Pignone con particolare riferimento a quelli utilizzati al manufacturing.

Mentre nella seconda parte vengono descritte le modularità con cui i vari programmi interagiscono nell’attività di gestione della commessa, partendo dal momento in cui il cliente effettua la richiesta a quando il prodotto è realizzato a livello informatico (cioè sono definiti tutti i cicli di lavorazione).

3.1 Sistemi informativi del Nuovo Pignone

Il Nuovo Pignone ha adottato nel corso del tempouna serie di programmi e/o applicazione per gestire i diversi aspetti, necessari per la gestione di una commessa.

Di seguito descriviamo in modo molto sintetico le funzioni principali per cui sono adottati tali sistemi, in modo da avere un’idea di quelle che sono le attività di gestione della commessa che verrà descritta in seguito.

3.1.1 Iman e unigraphics

IMAN (Information Managment) è un software di gestione di data base specializzato per le esigenze di un programma software di tipo grafico denominato UNIGRAPHICS (UG).

IMAN soddisfa le esigenze di UG che, in particolare, riguardano la gestione di assemblies piuttosto complessi e la creazione di part families, la gestione delle revisioni di item e part families e files associati a modelli master (quali tavole o percorsi utensile).

Un assembly è la struttura fondamentale di UG, consente di “assemblare” oggetti fino all’ottenimento del prodotto finito, questo consente a più progettisti di lavorare su elementi che, in seguito, confluiranno sullo stesso componente finale. Il vantaggio di questo sistema è anche di rendere più gestibili le parti UG. Infatti per uno stesso modello creato con assembly o senza le prestazione del sistema risultano nettamente diverse.

La part family è lo strumento usato da UG per creare famiglie di oggetti con caratteristiche geometriche simili. Gli oggetti sono generati in modo automatico compilando un foglio di calcolo su un’unica parte “padre” (es. Libreria di viti).

La compilazione del foglio di calcolo consente di modificare le caratteristiche geometriche del pezzo ed i nomi dei “figli”.

Con la diffusione di UG per la creazione di oggetti 3D è diventato fondamentale ricorrere all’utilizzo di Assemblies con il duplice vantaggio di migliorare le prestazioni del sistema e la conseguente diminuzione dei tempi di progettazione.

3.1.1.1 Caratteristiche principali.

Il programma di gestione dei database si interfaccia direttamente con UNIGRAPHICS modificando solamente quei menù relativi al salvataggio su file System.

Gli assembly creati con IMAN seguono le revisioni dei singoli item e sono, quindi costantemente aggiornati.

La possibilità di puntare all’ultima revisione è personalizzabile, è possibile specificare se un assembly deve puntare sempre all’ultima revisione di un oggetto oppure ad una determinata, rendendo in questo modo la gestione molto più flessibile.

Ogni parte creata con IMAN ha un proprietario e non è possibile cancellare parti create da altri utenti, ma è abilitato all’attività di “cancellazione” solo l’utente che l’ha creato.

Il sistema di gestione dell’informazione aziendale non lavora con la classica struttura a directory, ma consente di reperire un file solamente per nome (o codice) e rende quindi superato l’utilizzo di una struttura a directory di tipo “parlante”. Questo rappresenta il maggior vantaggio ed anche la più grande difficoltà da affrontare.

In IMAN un item è un insieme simbolico che contiene una parte UG e tutte le sue revisioni e tavole, la parte principale associata ad un item si chiama UGMASTER (e deve essere unica), mentre le parti derivate (n) si chiamano UGPART.

Il sistema consente di associare un item direttamente ad una sola parte UGMASTER (assembly o no), quindi di gestire in modo automatico le revisioni di quella stessa parte.

Ad ogni parte possono essere associate n tavole che possono avere qualunque nome (diverso all’interno del singolo item ma anche uguale alle tavole di altri item).

Il programma è stato adottato dall’azienda per poter gestire le revisioni di una parte MASTER, in modo che le revisioni delle parti seguiranno quelle del “padre”. Questo implica che, se la parte MASTER è solida e le parti derivate sono tavole, si dovrà sempre revisionare il modello per consentire una revisione delle tavole.

Il sistema di gestione dell’informazione aziendale si basa su un database Oracle in cui i nomi degli item sono la chiave stessa di ricerca, questo implica che non è concesso inserire due item con lo stesso nome: è dunque necessario creare una convenzione per i nomi.

L’indice di revisione è assegnato da iMAN (come attributo) e può essere un indice letterale, numerico o misto.

Gli ITEM sono gestiti generalmente dal sistema integrato MRP_BOM caratterizzato da un identificativo univoco e da una serie di attributi atti a definirne le caratteristiche, esistono diversi tipi di item con diverso set di attributi e flussi associati alla loro gestione. Gli item con maggiore importanza sono quelli relativi alla documentazione (IMAN), codici materiali detti anche real time che definiscono un oggetto effettivamente gestibile in un magazzino e i dummy item che vengono sostituiti a commessa dai codici materiali.

3.2 Sistema EDM

EDM è l’acronimo inglese di Enterprise Document Management. Questi sistemi garantiscono:

− reperibilità e rintracciabilità del documento via client WEB,

− gestione del ciclo di vita del documento tramite il controllo delle revisioni;

− gestione degli accessi ai vari archivi tramite UserName e Password. Sono sistemi atti a contenere elevati volumi di documenti, quindi dotati di ampia capacità di memoria magnetica ed ottica; quest’ultima garantisce inalterabilità del documento.

Le applicazioni realizzate in questa tecnologia Al Nuovo Pignone comprendono:

− Documentazione tecnica dell’Ingegneria;

− Archivio delle Distinte precedenti la codifica sul Mainframe; − Acquisti e Commesse per Documentazione dell’Ufficio − Certificati di Collaudo;

− Documentazione dello Stabilimento di Firenze, come le attrezzature necessarie per la movimentazione e non solo , portautensili, fogli metodo, etc.

− PQF: Processo Qualifica dei Fornitori: Moduli interni che vengono compilati ed appositamente approvati dagli enti di competenza, per la qualifica dei fornitori.

L’accesso alla documentazione non è competenza dell’Information Technology, ma del responsabile della documentazione, cioè i vari uffici che emettono la documentazione definiscono i requisiti di accesso alla documentazione stessa.

3.3 L’ePSS

Prima di parlare di ePSS è bene definire alcune cose come ITO inquiry to order, che è una proposta tecnica/commerciale che soddisfa la richiesta del cliente, che in caso in cui arrivi l’ordine, avvia il processo OTR (Order To Remittenze) ovvero innesca l’avvio dell’insieme delle attività che porteranno a consegnare il prodotto/fornitura al cliente.

Dopo questa breve precisazione possiamo dire che ePSS e’ un’applicazione che gestisce alcune attività delle funzioni ITO come :

− CHECKLIST Elettronica

− Technical Specification Analysis − RAC Evaluation Form

ed alcune attivita’ di collegamento fra ITO e OTR relative alla gestione della CheckList

− TO-OTR Hand-Off

− I dati Aziendali del Cliente definite dall’ITO con la CheckList − I dati Aziendali d’INGEGNERIA

− I dati Aziendali del MANUFACTURING − I dati Aziendali di Pianificazione

− L’esperienza Aziendale di Project Management degli Streams

Lo scopo del BoM Generator e’ di aiutare le varie figure aziendali ad espletare nel modo migliore tutte le attivita’ necessarie ad ottenere una BoM configurata sulle

esigenze dei Clienti e conforme ai processi Aziendali. L’interfaccia grafica dell’ePSS si presenta con tre zone specifiche, ovvero:

1) COMANDI generali relativi alle CheckList 2) elenco dei documenti accessibili

3) dati dei documenti selezionati per effettuare le operazioni di edita e stampa Con l’applicativo ePSS è possibile realizzare diverse operazioni:

− creare una nuova CHECKLIST

− Gestire le versioni successive di una CHECKLIST ( ITO ) − Attivare i vari processi ad esso collegati

− Copiare in una nuova CHEKCLIST I dati di un progetto gia’ esistente − Selezionare i dati di una CHECKLIST già esistente e li rende disponibili − Rilascia Ia CHECKLIST in esame

Per ogni particolare checklist presa in esame è possibile collegarsi direttamente con gli altri moduli, tali moduli sono quelli relativi alla definizione dello scopo di fornitura, all’organizzazione dei workflow, alle tabelle per l’analisi “grafica” delle BoM.

Ogni riga delle varie tabelle presenti nell’applicazione e’ un record di variabili che permettono di assegnare i valori delle variabili di quel record, i vari record vengono perciò differenziati in base al valore della prima variabile in tabella

Esistono svariati WIZARD all’interno di un DATA Panel per agevolare le funzioni di data entry.

L’applicativo è anche in grado di rilevare gli eventuali errori e incongruenze che vengono inserite a sistema; e successivamente attraverso l’apparizione di particolare finestre informare l’operatore

Dopo aver definito la checklist è possibile andare ad operare su uno o piu’ prodotti definiti tramite una sezione denominata “Scopo di Fornitura”

I prodotti presenti nello scopo di fornitura sono quelli per i quali i funzionari ITO possono compilare la CheckList.

3.4 Oracle e i suoi applicativi utilizzati da NUOVO PIGNONE

Tra tutti gli applicative messi a disposizione dal sistema ERP di ORACLE l’aziende nè ha adottati diversi di seguito che sono riportati di seguito con la definizione dello scopo del loro utilizzo in modo da avere più chiaro come si svolge il processo di acquisizione di una commessa e la successiva esplosione a tutti i livelli.

Project Contract (PC): il modulo è l’archivio di tutte le informazioni di progetto per un certo scopo di fornitura, ed include descrizioni, date di consegna, termini e condizioni contrattuali, termini di spedizione, ecc. Consente anche di avviare alcune attività chiave nei processi New Units: la pianificazione in ASCP dei fabbisogni (demand), gli eventi di fatturazione, la gestione del passaggio del titolo delle Functional Unit.

Bill of Material (BOM): il modulo è utilizzato come archivio delle Distinte, Generali e Parziali: le distinte sono utilizzate per la pianificazione in Oracle ASCP degli item sia “ make”, cioè da produrre, sia “buy“ cioè da acquistare e per la gestione della loro successiva produzione nel modulo Oracle WIP.

Le Distinte vengono importate nel modulo BOM da iMAN, l’applicazione utilizzata per la gestione di tutte le attività di ingegneria. Il modulo BOM, inoltre, è utilizzato per la gestione del workflow degli Engineering Change Orders, cioè le modifiche effettuate in iMAN sugli item, i relativi disegni, o le Distinte durante il ciclo di vita del progetto.

Purchase Orders (PO): è il modulo utilizzato per la creazione degli ordini di acquisto verso i fornitori. L’integrazione tra i moduli PO e ASCP assicura che gli ordini di acquisto vengano pianificati in base alle esigenze di pianificazione, secondo una logica “da destra verso sinistra”) a partire dalla data di richiesta del cliente (CWD-Customer Want Date).

Receiving: è il modulo utilizzato per la gestione della ricezione dei materiali dai fornitori. Rende inoltre i dati relativi a questi materiali visibili da tutti gli altri moduli della produzione per capirne la disponibilità per l’uso la collocazione fisica in magazzino. Il modulo è integrato con AP, per fornire i dati necessari ad autorizzare il pagamento delle fatture ai fornitori.

Project Accounting (PA): è il modulo progettato per definire il progetto dal punto di vista della gestione dei costi; con l’utilizzo di una “Work Breakdown Structure”, PA allinea la struttura dei costi allo scopo di fornitura della relativa commessa.

Project Billing (PB): è il modulo utilizzato per definire e generare il piano di fatturazione attiva; le informazioni relative al piano di fatturazione sono inviate al modulo AR per la generazione delle fatture da inviare ai clienti.

Project Manufacturing (PJM): è il modulo che supporta l’integrazione tra i moduli del Manufacturing e il modulo Project Accounting. In Project Manufacturing sono definite le regole di associazione tra gli specifici task di progetto definiti nella Work Breakdown Structure di Project Accounting ed i costi generati dalla produzione e dall’acquisto di materiali e servizi. L’integrazione tra moduli garantisce l’accuratezza e la rapida disponibilità dei dati relativi ai costi produttivi delle commesse.

Inventory (INV): è il modulo utilizzato per garantire la reperibilità e la corretta gestione dei materiali da un punto di vista fisico e finanziario. Attraverso questo modulo è possibile conoscere la quantità e la locazione degli item in tutti i magazzini societari. È integrato con il modulo WMS per la gestione della movimentazione degli item in magazzino. Il modulo associa anche agli item gli attributi che ne permettono la corretta gestione in tutti gli altri moduli (per esempio se un item è make o buy, il tempo di approvvigionamento o produzione -lead time-, se è associato a commessa oppure no, ecc.).

Advanced Supply Chain Planning (ASCP): è il modulo utilizzato per pianificare l’approvvigionamento e produzione dei materiali necessari, rispettivamente, per gli item BUY e gli item MAKE. Attraverso l’analisi della distinta generale importata da Oracle BOM, della durata (lead time) dei cicli di produzione e degli attributi degl’item, ASCP pianifica le date richieste (need by date) che devono essere rispettate per l’approvvigionamento o la produzione dei materiali necessari a completare lo scopo di fornitura dell’ordine del cliente. Oracle ASCP si occupa anche di “nettizzare” i fabbisogni generati ad alto livello dal piano della domanda, con la giacenza esistente e gli ordini di produzione ed acquisto effettivi, ovvero di bilanciare fabbisogni e disponibilità.

Warehouse Management System / Mobile Supply Chain Application (WMS):

questo modulo integra le funzionalità del modulo Inventory per la gestione fisica dei materiali in magazzino. Attraverso l’utilizzo di speciali terminali portatili, permette l’identificazione dei codici associati ai materiali, anche attraverso la lettura dei codici a

barre, e quindi garantisce la tracciabilità dei movimenti dei materiali in magazzino, dal loro ricevimento fino alla spedizione al cliente come prodotti finiti.

Order Management/Shipping (OM): è il modulo utilizzato per la gestione delle attività di spedizione materiali ai clienti. Per ogni insieme di materiali da spedire viene creato uno “shipping sales order” o ordine di spedizione: questo ordine è gestito anche in Project Contract dove è definito l’intero scopo di fornitura del cliente. Gli ordini di spedizione sono utilizzati dal modulo Shipping per fornire al magazzino le istruzioni necessarie alla identificazione del materiale da spedire (es. bolla di prelievo). Attraverso l’integrazione con il modulo WMS, è possibile aggiornare il magazzino, memorizzare come gli item sono imballati e spediti al cliente. Il modulo genera anche la documentazione necessaria alla spedizione come i documenti di trasporto.

Work in Process/Routing (WIP): questo modulo gestisce tutti i processi interni alla produzione da un punto di vista fisico e finanziario. Il modulo è integrato con ASCP per pianificare il rilascio degli ordini di produzione all’officina. Dopo il rilascio degli ordini di lavoro, il modulo WIP genera le richieste per il prelievo dei materiali in magazzino e l’aggiornamento dell’inventario. Le ore di lavorazione utilizzate in officina per i cicli sugli item vengono gestite in AEC; queste informazioni vengono automaticamente importate in WIP per poter controllare in tempo reale l’avanzamento delle attività produttive.

3.5 AEC e OSP_Item

L’archivio AEC (Archivio Elettronico Cicli) è suddiviso per competenze di stabilimento (FIR, MASSA) ed all’interno dello stabilimento FIR secondo le competenze di Servizio ( LAVorazioni, MONTaggio).

AEC è un applicativo esterno a Oracle, ma integrato con questo per l’interscambio da dati, nel quale vengono sviluppati tutti i cicli di lavorazione attraverso una particolare interfaccia realizzata ad hoc.

Passiamo in rassegna alcuni screen shot per vedere per quale scopo viene utilizzato AEC in riferimento ai vari cicli.

Ogni ciclo di lavorazione in AEC viene identificato con COC (ciclo operativo di commessa che inseguito sarà analizzato più nel dettaglio).

Mentre in Oracle è identificato con WIP Job.

Attraverso l’interfaccia con AEC, Oracle Wip provvede alla creazione automatica delle POR relative alle lavorazioni conto terzi che emergono dalla creazione del ciclo di lavorazione.

Tali POR sono individuabili per l’item che sarà denominato OSP_ (dove questi saranno valorizzati con quello che in AEC è chiamato Item critico).

Su AEC è possibile visualizzare tutto quello che riguarda la parte manufacturing del Nuovo Pignone.

Da questo applicativo è possibile gestire tutte le attività dalla semplice selezione di un utensile per una particolare operazione alle schede di collaudo delle varie prove a cui sono sottoposti i diversi prodotti aziendali.

3.6 Rilascio di una commessa

Il processo di generazione della commessa ha inizio dal tool ePSS.

EPSS è come già detto un tool attualmente usato negli uffici commerciali per riassumere in forma di checklist elettronica tutte le informazioni relative a un contratto di vendita che verranno poi trasferite a tutte le funzioni preposte per l’esecuzione delle conseguenti attività dall’ingeneria alla produzione, agli acquisti e tutte le altre funzioni aziendali interessate.

La checklist è dunque l’insieme di parametri e variabili che definiscono lo scopo di fornitura di un contratto di vendita, ossia il prodotto da realizzare e il processo con cui verrà realizzato.

A partire dalla checklist viene generata la Distinta Generale di progetto.

La compilazione della checklist comincia in fase di vendita e viene completata una volta ricevuto l’ordine dal cliente, parallelamente alla definizione dei Costing Project (in PA) e alla preparazione della struttura del contratto (in PC).

La prima selezione da compiere sulla checklist è la scelta dei prodotti in scopo di fornitura:

• Turbina a gas;Turbina a vapore; • Compressore centrifugo;

• Compressore alternativo; • Sistema di lubrificazione; • Sistema di raffreddamento

• e altri principali ausiliari.Dopo la selezione, il sistema crea una struttura “maximum case” per ciascun prodotto in scopo. Le strutture “maximum case” di prodotto seguono l’evoluzione nel tempo dei prodotti dell’azienda e vengono opportunamente aggiornate.

Per ciascun prodotto, il commerciale procede alla selezione dei componenti richiesti nella fornitura e a caratterizzare ogni componente selezionato.

La caratterizzazione del componente consiste nell’indicarne le caratteristiche tecniche in funzione delle specifiche che il cliente a richiesto al momento della definizione della commessa.

Una volta compilata, la checklist viene congelata e successivamente condivisa durante una riunione che prende il come di Apertura Commessa (RAC), dove intervengono tutti i responsabili delle principali funzioni aziendali.

La versione di checklist approvata durante la RAC viene definitivamente congelata come input principale per l’individuazione delle Functional Unit (FU), del loro raggruppamento in Planning End Item (PEI) e per generare successivamente la Distinta Generale.

A valle della RAC (Riunione Apertura Commessa) viene dato inizio al processo di generazione della distinta (BOM) che consiste nell’individuare, a partire da un modello di distinta “maximum case”, quale sia la BOM che rispecchia lo scopo di fornitura in esame.

BOM

La checklist completata dagli uffici commerciali in fase di ITO, a partire dalle strutture di distinta “maximum case”, permette di tagliare la distinta di progetto in base alle specifiche caratteristiche dello scopo di fornitura del cliente.

I template di distinta “maximum case” vengono memorizzati in iMAN, uno per ciascun modello di macchina.

I dati tecnologico-costruttivi presenti in AEC (Archivio Elettronico Cicli) consentono di arricchire la distinta con informazioni sul processo produttivo, di creare un legame con i cicli convenzionali e di determinare il lead time.

Infine, le regole provenienti dalla funzione di ingegneria e dalla funzione di produzione del Nuovo Pignone vanno ad integrare la checklist con l’inserimento di vincoli produttivi e realizzativi.

L’output del processo di generazione è la struttura della BOM di progetto (Distinta Generale) e dei legami tra ciascun componente (item) della BOM e i cicli produttivi convenzionali in AEC.

Infatti il BOM Generator seleziona i template necessari da iMAN sulla base dei dati forniti in EPSS (checklist elettronica). Successivamente li elabora, sulla base di ulteriori parametri atti a definire lo scopo di fornitura con il necessario dettaglio, configurando la struttura BOM per le specifiche esigenze del progetto del cliente.

I BOM Template sono stati costruiti per rispecchiare le nuove strutture di distinta, con il sistema MRP/BoM non si hanno diverse distinte, cioè una per l’ingegneria, una produzione e così per tutte le unità aziendali, ma una distinta unica che rispecchia il flusso delle attività produttive, aggregando i materiali in base a quando servono nel processo produttivo piuttosto che su base funzionale come avveniva prima.

L’output del BOM Generator è la struttura della distinta generale di progetto e viene trasferita in iMAN e viene anche denominata “dummy BOM”.

La dummy BOM viene controllata in iMAN, eventualmente modificata, e poi rilasciata (“congelata”).

Dopo il rilascio, qualsiasi modifica può avvenire solo con un processo di gestione dei cambiamenti detto Engineering Change Request / Engineering Change Order (ECR / ECO).

A questo punto, la definizione dello scopo di fornitura per il progetto viene trasferita nei moduli Oracle BOM e INV per le successive elaborazioni.

La dummy BOM è costituita da dummy item, codici utilizzabili per la pianificazione della Supply Chain.

Al termine dell’attività di Ingegneria a commessa, gli item dummy saranno sostituiti da item real, codici reali validi anche ai fini di esecuzione della Supply Chain.

Il corretto BOM template viene selezionato e si inserisce il Costing

Project per il quale

la struttura dummy deve essere creata.

EPSS

BOM Generator

Template items

and Template BOM Structure

Dummy items and Dummy BOM Structure

Possible Editing of Dummy BOM Structure

Release

Dummy BOM structure Template BOM

Dummy BOM

Freezing the Scope of Supply

Tech spec. and applic. docs creation Released Dummy BOM BOM codes creation Replacing Dummy Items with Real codes

Release Final BOM Structure

Realizing the Dummy BOM

Released Final BOM Long lead items

BOM revisions Change in Scope / attributes iMAN Due Dates Change Authorizer Change Executor Change Approver Release _Change Requestor Artemis

È evidente che la struttura ‘dummy BOM’ ha le prerogative della struttura distinta generale (con le posizioni da riempire) nel sistema legacy, con in più le informazioni correlate alla struttura stessa ed al processo produttivo.

Ciascun nuovo progetto è contraddistinto in iMAN da un item Costing Project equivalente al concetto attuale di numero commessa.

I documenti relativi alla commessa (documenti interni, documentazione cliente, documentazione dei fornitori) vengono creati in iMAN e associati all’item Costing Project.

Tutta la documentazione tecnica viene definita sul programma di gestione dell’informazione attraverso il processo di firma elettronica.

A partire da essa vengono creati in iMAN i real item i quali, una volta completi di attributi e di struttura, vengono rilasciati nel sistema. I real item hanno le stesse prerogative, con le dovute estensioni, dei codici materiali e delle distinte parziali del sistema legacy.

I tempi di emissione dei real code e della documentazione sono definiti all’interno del piano di progetto cliente in Artemis, utilizzato principalmente dai pianificatori degli stream, e interfacciato anche con iMAN.

L’ingegneria a commessa sostituirà i dummy item con real item definiti e rilasciati, secondo i tempi d’emissione definiti all’interno del piano in Artemis. In modo più semplice possiamo dire, che in questo contesto, ha la funzione di definizione delle scadenza per ogni step di commessa dal momento in cui viene definita la commessa al momento cui tale prodotto dovrà essere presente in cantiere.

Ogni volta che una BOM o porzione di essa viene “realizzata”, ovvero i suoi codici dummy sostituiti con codici reali, essa viene trasferita in Oracle per le successive elaborazioni fino a quando l’intera distinta è stata realizzata.

In iMAN viene inoltre gestito il processo di Engineering Change Management, un nuovo flusso di richieste e approvazioni che permetterà di eseguire in modo rigoroso e ben documentato tutti i possibili ed eventuali cambiamenti che possono essere eseguiti su una distinta o sui codici, una volta rilasciati. Ciò avviene all’inizio del progetto, ovvero prima ancora che inizi il lavoro d’ingegneria di dettaglio sul progetto stesso.

In questo modo l’azienda è in grado di realizzare la pianificazione della produzione e dell’approvvigionamento e di conseguenza poter valutare il budget di progetto senza dover attendere il completamento dell’attività dell’ingegneria del prodotto.

I BOM template sono definiti e gestiti da un gruppo di lavoro cross-funzionale creato ad hoc (BOM management team o BOM team), all’interno del quale sono presenti molteplici competenze dall’ingegneria, alla produzione e agli acquisti.

Qualunque cambiamento ai template BOM rilasciati (struttura e attributi) viene gestito da tale gruppo, tramite processi dedicati per la creazione o revisione dei template item presenti in iMAN.

Soltanto i template BOM rilasciati possono essere utilizzati dal BOM Generator in EPSS per generare le strutture distinte di commessa.

iMAN

1. Il template BOM viene creato in iMAN

Staging area for EPSS 2

Il template BOM rilasciato viene pubblicato dentro una specifica area detta “di

staging” per l’EPSS

EPSS

3

EPSS acquisisce il template BOM dall’area di staging

La sequenza delle attività per cui sono:

• Il template BOM viene creato su iMAN

• Il template BOM rilasciato viene pubblicato dentro una specifica area detta “di staging” per l’EPSS

• EPSS acquisisce il template BOM dall’area di staging

• La struttura della dummy BOM rappresenta lo scopo di fornitura relativo ad una specifica commessa.

Il numero di Costing Project viene aggiunto dal BOM Generator in coda ai differenti template item, ottenendo così una nuova struttura, da un punto di vista prettamente logistico agevola la gestione di queste strutture.

L’aggiunta del numero di commessa in coda al template rende la distinta dummy univoca per ciascuna commessa.

M2400700 1600905

M24007030 1600905 M24007550 1600905 Dummy BOM Structure

Inoltre, il BOM Generator applica delle regole di ingegneria, di acquisti e di produzione.

Il risultato di tale elaborazione consiste nella ristrutturazione a commessa della distinta, tramite operazioni di taglio spostamento e di item nella struttura principale ed infine nella valorizzazione di alcuni parametri, gli attributi, che caratterizzano ciascun dummy item.

Ciascun dummy item è caratterizzato da diversi attributi a seconda del tipo di commessa che si sta andando a definire.

Una volta creata la struttura dummy, il project engineer, per pubblicare in iMAN tale dummy e far sì che ogni modifica di struttura o attributi dell’item revisionato sia

tracciata, con la creazione di un’ulteriore revisione, deve opportunamente rilasciare l’item dummy da cui si origina tutta la struttura di commessa.

Sono stati definiti nel corso della progettazione dell’intera fase di rilascio della commessa diversi workflow, alcuni dei quali vengono svolti tra un attività e l’altra della fase di rilascio.

Alla fine di tale attività la struttura viene messa in coda al processo di pubblicazione in Oracle (operazione bacth eseguita ad ogni intervallo di tempo predefinito).

I real item usati nella BOM vengono creati in iMAN estendendo le convezioni Nuovo Pignone sulla nomenclatura dei codici già in uso nel sistema legacy e le relative regole di collegamento tra codici materiali/codici distinte e documento applicabile.

I documenti tecnici vengono collegati ai real item, che hanno item type BOM, attraverso una particolare relazione. I vari documenti applicabili vengono collegati ai codici BOM nella fase di creazione.

Il sistema controlla la disponibilità del documento applicabile basandosi sulle regole di associazione tra codici materiali e codici disegni e crea il codice materiale.

Ogni volta che un item viene “realizzato”, un’interfaccia automatica lo trasferisce da iMAN in Oracle, e gli attributi precedentemente specificati nell’item dummy trasferiti su quello reale.

I real item che sostituiscono i dummy item vengono creati e rilasciati prima che avvenga il processo di sostituzione ‘reale su dummy’.

A questo punto vengono svolti una serie di workflow in modo che alla fine l’item prende lo status di ‘Dummy Realized’, e la struttura viene messa in coda al processo di pubblicazione in Oracle (anche questa operazione viene eseguita in modo batch ad intervalli predefiniti).

Quindi, con questo processo si trasferisce in ambiente Oracle il work in progress dell’ingegneria di dettaglio,

Il nome Mixed per una struttura deriva dal fatto che il Design Engineer rilascia una struttura ‘DummyRealized’ che può avere componenti di tipo misto, dummy e real.

Facendo un resoconto finale possiamo dire che a partire dai template BOM in iMAN, la funzionalità BOM Generator di EPSS definisce la distinta generale di progetto, o Dummy BOM, che descrive lo scopo di fornitura.

La Dummy BOM viene quindi rilasciata in iMAN e successivamente inviata ad Oracle per il suo utilizzo a valle.

Una volta che questa pubblicazione è stata eseguita con successo, le stesse informazioni vengono pubblicate all’interno di un apposito DataMart del Datawarehouse.

Si noti che, con il processo MRP/BoM, la pianificazione dell’ingegneria è pienamente integrata con le esigenze della supply chain, sia per quanto concerne la documentazione interna o cliente che per quanto riguarda il completamento della struttura del prodotto.

1 Template BOM Oracle

iMAN

BOM 5 Dummy _BOM

4 Released Dummy BOM

3 Released Dummy

3.6.1.1 La gestione dei cambiamenti e i legami fra i vari documenti

Qualsiasi cambiamento su un item rilasciato o sulla struttura della BOM deve seguire un processo di Engineering Change Management, mediante opportuno workflow di controlli e autorizzazioni.

Il Change Request viene approvato da un Change Authorizer L’utente inizia il Change Request Il cambiamento viene eseguito da un Change Executor

Il Change Reviewer controlla il cambiamento eseguito e lo

rilascia in iMAN I cambiamenti effettuati

vengono inviati verso Oracle

Questo diagramma di flusso descrive, ad alto livello, il processo Engineering Change Management.

Il sistema, analogamente ai processi di rilascio dei real item, controlla i parametri critici degli item revisionati e la relativa documentazione applicabile, e, in caso positivo, rilascia le nuove revisioni dei real item create nel processo.

Tutte le informazioni relative alla modifica vengono pubblicate in Oracle con un processo di tipo “batch”.

I documenti e i codici BOM vengono gestiti separatamente, ciascuno con le proprie revisioni e cicli di rilascio, ma sono collegati tra loro.

Grazie ai vari sistemi informativi presenti in azienda e alle diverse interfacce realizzate fra i vari sistemi, è possibile oltre ai documenti applicabili, associare alle BOM, a livello del Costing Project, la documentazione a commessa, estendendo lo scopo della sezione documentazione della distinta generale nel sistema legacy.

Tutti i documenti realizzati per una commessa vengono collegati al Costing Project attraverso una relazione specifica. I documenti vengono automaticamente raggruppati all’interno di delle cartelle dopo che sono stati collegati al Costing Project con il corretto legame.

A questo punto tutte le informazioni, comprensive di documenti e disegno sono presenti su AEC il l lancio del ciclo dei compressori centrifughi può avvenire.

Tutto quello che è stato definito in AEC in termini di tempi e altro viene asportato su Oracle.

Attraverso i tool di Oracle tali dati saranno poi usati per successive analisi aziendali.

Fino a questo momento il lancio veniva fatto in modo manuale, poi con il lavoro che ho svolto e che viene spiegato in modo esaustivo nel prossimo capitolo, tale lancio viene fatto in modo automatico.