Reengineering tecnologico e concettuale di una metodologia di analisi di prezzo,con riferimento a componenti elettronici e prodotti Core : il caso GE Oil & Gas.

Il presente elaborato illustra il progetto sviluppato durante lo stage formativo presso lo stabilimento di Nuovo Pignone, della General Electric Oil & Gas, sede di Firenze, dal 10 Novembre 2008 al 10 Maggio 2009.\nL’obiettivo principale del lavoro è stata la reengineerizzazione ed ottimizzazione, sia dal punto di vista delle prestazioni che della definizione concettuale, di un processo critico aziendale. Il lavoro è stato svolto presso il reparto Pricing (reparto destinato all’analisi dei prezzi applicati alle varie transazioni) del settore Global Services della suddetta azienda, sotto il coordinamento del Marketing Manager, la Dott.ssa Annalucia Del Mese.\nInizialmente, è stato analizzato il processo interno di analisi di prezzo (processo di Price Analysis), realizzato nel 2006 da terzi per conto del reparto stesso. Lo scopo di questa procedura è confrontare la strategia di prezzo adottata in un trimestre dell’anno (quarter) con quella del corrispondente trimestre dell’anno precedente. Tramite questa analisi, il reparto può valutare la validità della strategia adottata ed, eventualmente, adottare misure preventive in merito ai quarter futuri. Dal 2006 il processo è stato ampiamente utilizzato e non ha subito alcuna modifica. Tuttavia, il reparto lamentava non solo una certa lentezza esecutiva del sistema, ma anche un’evidente mancanza di fiducia quanto all’affidabilità dello stesso. Più volte, infatti, nel corso dei quarter precedenti, erano stati segnalati casi di incongruenze o anomalie di risultati che avevano costretto il reparto a bypassare il processo ed effettuare una lunga e laboriosa indagine analitica.\nUn ulteriore problema del sistema concerneva la mancanza di dettaglio: il processo produceva solo parametri medi relativi a raggruppamenti degli item venduti secondo le tipologie di famiglia e prodotto. In tal modo, veniva persa l’informazione di dettaglio per quelle tipologie di item che, seppur numerose e variegate, facevano parte di un’unica famiglia. In particolare, il problema si poneva per la famiglia 04G relativa al materiale di natura elettronica venduto dall’azienda. La Dott.ssa Del Mese e il suo team di collaboratori delineavano, quindi, la necessità di ottenere dettagli relativamente a quella particolare famiglia, in quanto era fondamentale condurre un’analisi più approfondita su una categoria accessoria – sebbene parimenti importante rispetto alle altre – in un business incentrato principalmente sulla vendita di parti e dispositivi di natura meccanica.\nLa prima fase del lavoro all’interno del reparto è stata, dunque, incentrata su un’analisi dettagliata del processo in questione. Tale esigenza era particolarmente determinante dal momento che talune parti del processo, benché meccanicamente note nella loro esecuzione, non dimostravano lo stesso livello di immediatezza quanto a funzionalità ed architettura operativa.\nAllo scopo di mettere ancor più in evidenza le problematiche specifiche del sistema e proporre possibili migliorie da attuare, il sottoscritto è stato chiamato ad analizzare attivamente la chiusura dell’ultimo quarter dell’anno 2008. Nell’ambito di tale esperienza, è stata sviluppata una conoscenza dettagliata del sistema per la quale si rimanda all’ampia descrizione contenuta nel capitolo 3 del presente lavoro. La stesura di tale elaborato rientra nell’ambito di ottimizzazione della situazione del reparto aziendale in merito al processo analizzato, in quanto esso vuole rappresentare un valido testo di riferimento di cui il sistema era sprovvisto sin dal 2006, data della sua creazione. Si può dunque intuire come il lavoro di indagine e di raccolta di informazioni sia stato tutt’altro che semplice e immediato, in quanto basato fondamentalmente sulle capacità analitiche del sottoscritto e, ove possibile, sui contributi dei vari stagisti precedentemente preposti all’esecuzione manuale delle varie procedure. Come ampiamente discusso nel capitolo 3, il processo in questione ha come obiettivo quello di reperire dai sistemi interni aziendali tutte le informazioni relative alle transazioni di vendita di un certo intervallo temporale (quarter).\nIn particolare, il processo è stato concepito allo scopo di esaminarne i due filoni principali. Il primo è rappresentato dagli ordini, ovvero i preventivi indirizzati ai clienti, cui è dedicata la sezione denominata OPI (da OrderPrice Index, ovvero il parametro globale di output obiettivo dell’analisi). Il secondo è legato alle fatturazioni vere e proprie ed è relativo al periodo di interesse al quale è dedicata la sezione chiamata SPI (da Sales Price Index). Le due sezioni si sdoppiano a loro volta in CORE e RECO che rappresentano i due business aziendali analizzati dal reparto.\nIn definitiva, si è di fronte ad un processo costituito complessivamente da quattro analisi che, pur presentando tratti similari, sono separate da fonti proprie non solo per quanto riguarda il quarter attuale, ma anche quello pregresso. Inoltre, per ognuna di esse vengono invocate ben quattro tipologie differenti di database aziendali, sia di natura ufficiale, che di natura ufficiosa. Al reperimento dei dati inerenti alle transazioni fa seguito un lento processo di collage delle informazioni distribuite nelle varie fonti all’interno di fogli Excel. Tale processo prende il nome di MD50. I fogli Excel ottenuti come output del processo costituiscono l’input di una macro, scritta nel linguaggio Visual Basic For Applications che cicla, fornendo in uscita delle tabelle in cui sono calcolati – per famiglia e per prodotto – dei parametri medi per il confronto delle strategie di prezzo tra quarter attuale e quarter pregresso. Allo step relativo alla macro segue uno step di Drill Down, ovvero una scrematura dei dati atta ad individuare tra tutti gli articoli esaminati una top ten tra quelli venduti meglio e una top ten tra quelli venduti peggio. A questo punto, qualora i dati ottenuti per ogni analisi dovessero essere ritenuti validi, ognuna di esse può ritenersi conclusa e viene così inserito, in apposite slide preformattate in Power Point, un sommario dei dati ricavati nel quarter. In caso contrario, scatta un lungo iter di indagine flashback che non di rado porta alla ripetizione dell’intero processo.\nUna volta presa confidenza con i dettagli del processo, sono stati evidenziati tutti i punti critici del sistema (per i quali si rimanda al capitolo 4), tra cui i lunghissimi tempi di esecuzione. Nella migliore delle ipotesi, infatti, ognuna delle quattro analisi dura circa tre ore e trenta minuti. Tenuto conto che spesso si rivela necessario ripetere le operazioni (che ovviamente devono essere tutte portate a termine), è intuibile come una simile performance del sistema risulti inaccettabile. Tale lentezza è caratteristica di tutti i blocchi costitutivi del processo. MD50 e Drill Down sono infatti processi del tutto meccanici che vengono gestiti manualmente dagli stagisti interni al reparto tramite le principali funzioni Excel (Vlookup, Tabelle Pivot, operazioni algebriche, algoritmi condizionali, etc.) in grado di incrociare i dati per ottenere gli output desiderati spesso con un enorme dispendio di tempo ed energie.\nLa lentezza di esecuzione non risparmia nemmeno la macro. Sebbene, infatti, si tratti di un processo automatico, esso impiega circa un’ora per generare i risultati. Di conseguenza, un primo obiettivo di reengineering consiste in una riduzione significativa dei tempi di esecuzione.\nUn ulteriore inconveniente del processo concerne, come accennato precedentemente, la sua affidabilità. Innanzitutto è importante sottolineare che non è concepibile impostare un processo critico aziendale come quello in questione su operazioni di incrocio manuale che non escludono l’errore umano. Inoltre, al momento dell’indagine condotta sull’intero sistema sia la metodologia di acquisizione dei dati recuperati dalle varie fonti sia l’algoritmo interno della macro erano del tutto oscure non solo al sottoscritto ma anche al resto del reparto. Inoltre, entrambe rappresentano delle procedure la cui effettiva concretezza risulta decisamente poco chiara alla luce delle anomalie riscontrate in merito ai risultati di taluni quarter precedenti. Di conseguenza, la fase di riprogettazione prevede due ulteriori obiettivi: l’automazione dell’intero sistema e la revisione concettuale sia della sezione di reperimento delle fonti sia del codice della macro.\nUn’ultima linea di azione concerne la qualità tecnologica del sistema. Da questo punto di vista, essendo basato principalmente sul pacchetto Office e su Visual Basic For Applications, esso risulta piuttosto obsoleto. L’unico sistema di più alto livello utilizzato è quello costituito dalle interfacce del database aziendale Oracle che, tuttavia, vengono utilizzate unicamente per acquisire le fonti e non per gli effettivi processi di incrocio in sé. Sebbene si tratti di un elemento fondamentale del lavoro eseguito, il margine di intervento relativamente a tale aspetto è stato di piccola entità. Ciò è dipeso dal fatto che l’esecuzione del processo è affidata a stagisti che non sempre possiedono un background informatico adeguato e che talvolta, per motivi legati ad urgenze scaturenti dalla necessità di essere sostituiti da qualcun altro, sono chiamati ad afferrare sin da subito le redini di un’analisi approntata precedentemente da terzi. Pertanto, si è cercato di adottare una soluzione che, a nostro parere, risulta migliore da tutti i punti di vista in quanto fa’ affidamento sulle risorse tecnologiche di cui sopra e sfrutta gli strumenti di più alto livello, ovvero quelli relativi al sistema Oracle. In ogni caso, si è puntato pur sempre ad ottenere interfacce utente che fossero immediate e facilmente fruibili.\nA tal proposito, è stata presentata al team Pricing la seguente soluzione di reengineering. In primis la sostituzione di tutte le fonti disponibili con un’unica fonte. É stata, infatti, evidenziata un’anomalia concernente le fonti che

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.