• prezzo

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.
L’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.
Inizialmente, è 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.
Un 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.
La 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.
Allo 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).
In 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.
In 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.
Una 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.
La 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.
Un 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.
Un’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.
A 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 acquisiscono in maniera separata informazioni globalmente presenti su Oracle. Da ciò l’inutilità di parte del processo MD50 che riunisce solo a posteriori informazioni che sarebbe possibile reperire direttamente e univocamente dal sistema Oracle. É stato inoltre dimostrato come parte degli artefatti passati fosse dovuta proprio a questa scorretta modalità di reperimento degli output.
La proposta consiste dunque nello spostamento della fase iniziale dell’analisi precedente alla macro, direttamente su una Oracle Application, ovvero una piattaforma capace non solo di elaborare dati automatici ma anche di accedere direttamente al database. In questo modo vengono raggiunti obiettivi di velocizzazione, automazione ed affidabilità fino allo step relativo alla macro vera e propria.
L’idea è stata approvata dal team e, pertanto, al fine di portare avanti tale progetto, il sottoscritto è stato affiancato dall’Ing. Simone Fantini del team IMT (Information Management Technology), esperto sistemista conoscitore del sistema Oracle aziendale, nonché dal Dott. Chen Lixiangi, programmatore Sql. Il team ha dunque lavorato alla realizzazione della Oracle Application chiamata Tool NP – SPI/OPI per la quale si rimanda al capitolo 5. Il sistema in questione è stato successivamente testato nei vari ambienti di sviluppo. Una volta superato il benchmark creato dal sottoscritto congiuntamente al Dott. Fantini in ognuno di questi ambienti, esso è stato mandato in produzione in data 11 Giugno 2009. Attualmente, rappresenta un tool Oracle-based aziendale accessibile sia dal reparto Pricing che da tutti gli altri reparti dell’azienda. Il codice di programmazione del tool in questione generato dalla fase di produzione è reperibile in appendice.
Per quanto riguarda lo step inerente alla macro, il sottoscritto ha provveduto ad esporre al team di Pricing la relativa architettura e filosofia di funzionamento, mettendo in evidenza delle perplessità su talune procedure interne, soprattutto quelle relative agli algoritmi condizionali. È stato proposto, pertanto, grazie alla collaborazione degli stagisti Veronica Gharbi, Carmela Capalbo e Simone Francesco Tiana, oltre che alla già citata Dott.ssa Del Mese e alla Dott.ssa Giulia Prayer Galetti, un modello alternativo a quello esistente. Ci si è occupati, dunque, della creazione del nuovo codice macro basato su un miglioramento non solo sul fronte degli algoritmi concettuali ma anche su quello delle performance relative al tempo di esecuzione. Sono state altresì inserite all’interno della nuova architettura specifiche funzionalità in grado di dar risalto ai dettagli relativi ai dispositivi elettronici contenuti nella famiglia 04G nonché a quelli di tutti i prodotti con problematiche simili. La nuova macro è stata realizzata e testata sotto tutti i punti di vista.
Al di là, dunque, degli obiettivi logico-funzionali considerati pienamente raggiunti in questa sede, una delle conquiste principali della riprogettazione è rappresentata dal passaggio da un tempo di esecuzione di un’ora a un tempo di esecuzione di una manciata di minuti. Sempre dal punto di vista del guadagno temporale, il sottoscritto ha contribuito ad un’automazione e snellimento dei passaggi di incrocio manuale che non è stato però possibile introdurre né nel tool né nella nuova macro (si pensi, ad esempio, alla fase di Drill Down). A tale scopo, è stata realizzata una serie di macro addizionali di tipo V.B.A. tese ad incrementare l’affidabilità dello strumento e a velocizzare le operazioni escluse dalle due applicazioni precedenti. Successivamente, si è passati alla fase di testing di tali macro che ha prodotto risultati soddisfacenti permettendo un’esecuzione scevra di errori e della durata di circa due minuti relativamente ad operazioni che richiedevano generalmente un tempo di esecuzione compreso tra dieci minuti e un’ora (Drill Down). Si rimanda al capitolo 6 per una descrizione accurata relativa sia alla creazione della nuova macro di analisi e delle varie sotto-macro sia alla fase di testing ad esse relativa.
Per concludere, è possibile affermare che lo scopo del progetto è stato pienamente raggiunto dal momento che un processo critico aziendale obsoleto, manuale, concettualmente inaffidabile e della durata di circa tre ore e trenta minuti è stato trasformato in un processo tecnologicamente più avanzato, automatizzato, affidabile, snello e semplice da utilizzare della durata di circa venti minuti. È stato possibile altresì fornire un dettaglio di analisi sulla vendita di apparati elettronici non ancora disponibili nella realtà aziendale.
Il sottoscritto ha inoltre presentato un resoconto del lavoro svolto durante il periodo di stage alla Dott.ssa Alessandra Pavolini, Marketing Leader della divisione Global Services di GE che si è dimostrata entusiasta dei risultati ottenuti, ringraziando personalmente sia chi scrive sia l’intero team coordinato dalla Dott.ssa Del Mese per il notevole apporto al miglioramento di un processo cruciale per il reparto come quello di Price Analysis.
A sua volta, il sottoscritto ha espresso tutta la sua soddisfazione per la grande opportunità formativa che gli è stata proposta, in quanto ha avuto la possibilità di prendere parte ad un processo aziendale fondamentale, contribuendo al miglioramento. Ciò non sarebbe stato possibile se non in un contesto come quello di GE che unisce all’altissima competenza e professionalità dei suoi dipendenti anche una filosofia di inserimento armonico nell’ambiente aziendale e nel team di lavoro che si è rivelata decisamente vincente.
Doverose sono quindi queste poche righe di ringraziamento per le Dott.sse Alessandra Pavolini, Annalucia Del Mese, Giulia Prayer Galletti, Veronica Gharbi, Carmela Capalbo e per i Dott. Michelangelo Lauria, Simone Fantini, Simone Francesco Tiana e Chen Lixiangi. Un grazie a tutti voi.
Desidero infine ringraziare la Prof.ssa Antonella Martini ed il Prof. Luca Fanucci che con la loro ineguagliabile umanità, disponibilità, serietà e competenza hanno accettato di appoggiare e dirigere sapientemente questo progetto di natura gestionale che non avrebbe probabilmente raggiunto i risultati ottenuti senza il loro prezioso contributo.