CAPITOLO 4
SALES PLAN TOOL
4.1 ITER DI CREAZIONE E DI IMPLEMENTAZIONE DEL TOOL
L’iter che è stato seguito per la creazione del Sales Plan Tool ha previsto innanzitutto la stesura di una specifica tecnica, chiamata MD50, che riportasse in dettaglio quali dovessero essere le principali funzionalità del tool tali da soddisfasse le esigenze di business che erano state riscontrate.
La specifica riporta brevemente il cosiddetto problem statement, ovvero la definizione del problema di partenza, rappresentato dalla mancanza di un processo solido e di un tool per pianificare e tenere aggiornato il piano di sales del settore Units con la conseguente impossibilità di tenere tracciati i price split, le consegne parziali degli item e le eventuali modifiche effettuate su di essi.
L’obiettivo dichiarato del progetto (objective description) è stato quindi quello di creare un apposito strumento informatico che permettesse ai vari project manager di costruire un piano di sales in maniera semplice e di mantenerlo aggiornato secondo un ritmo operativo scandito da review settimanali, con il fine di fornire una visibilità dei piani di vendita il più affidabile possibile, sia per i PM Leader che per le funzioni aziendali come il Finance.
Il processo pre-esistente infatti prevedeva dei sotto processi, uno per ogni applicazione di Project Management (Transportation>L, NG&Processing, Turn Key Solutions), in cui le sales venivano gestite manualmente dai PM tramite dei file Excel e non c’era integrazione nè standardizzazione dei metodi.
La specifica MD50 riporta quindi un elenco di tutte le informazioni che si vuole compaiano nel data base, sia quelle strettamente necessarie, di cui non si può fare a meno, che quelle facoltative, che comunque danno valore aggiunto al tool nel suo complesso.
Viene specificato che cosa si vorrebbe poter estrarre dai report e quali funzioni si vorrebbero poter implementare per facilitare il lavoro ai PM.
Una volta redatta, la specifica tecnica è stata inviata all’IT (Information Technology) dove un gruppo di sviluppatori ha realizzato la struttura del tool, compresa la veste grafica.
Lo step successivo è stato quello di scegliere un gruppo di progetti pilota da caricare nel data base per valutare parametri quali la facilità d’uso, la velocità nell’inserimento dei dati, la correttezza dei campi, l’affidabilità delle estrazioni e dei report ecc.
Dopo il caricamento dei progetti pilota e dopo i test preliminari si è passati ad effettuare il caricamento di tutti i dati pregressi a cominciare da una certa data in poi.
Si è quindi passati alla cosiddetta fase di QA (Quality Assurance) nella quale i responsabili del progetto hanno cominciato ad usare il tool per valutarne le caratteristiche tecniche e la rispondenza alle specifiche precedentemente definite.
Una volta appurato che il tool non riscontrava difetti o malfunzionamenti si è passati alla fase di Produzione nella quale l’IT ha definitivamente reso pubblico e operativo il tool dando ai PM gli accessi al form per la compilazione.
Il Sales Plan entra così a far parte degli strumenti operativi del PM e delle altre funzioni che possono adesso accedere alle informazioni in esso contenute ed avere finalmente quella visibilità che prima era difficile raggiungere.
La fase di progettazione, sviluppo e creazione del tool ha richiesto circa 3 trimestri ed il suo rilascio ufficiale (Go Live) è avvenuto a fine ottobre 2006, proprio nel periodo in cui il candidato ha cominciato la sua esperienza di stage.
In conseguenza di ciò il candidato ha seguito la fase vera e propria di introduzione del tool nell’attività quotidiana dei PM ed ha potuto così osservare i cambiamenti che tale strumento ha apportato a livello operativo rispetto alla situazione precedente.
Al momento dell’introduzione è stato condotto un breve corso di formazione ai PM e agli utenti Finance al fine di dare a tutti le conoscenze di base per cominciare ad utilizzare il tool e poter sfruttare le sue potenzialità.
L’effettiva implementazione del tool ha richiesto comunque del tempo e a tutt’oggi non è completa.
Non tutti i PM hanno infatti compreso a fondo le regole per la compilazione dei campi e l’utilizzo del tool non è ancora totale.
I PM Leader stanno infatti spingendo affinchè il tool diventi il punto cardine per la gestione operativa delle commesse e tutti i PM lo usino quotidianamente per aggiornare i price split e soprattutto le date previste di vendita (Promise Date) in modo tale che gli altri utenti, in primo luogo il Finance ma anche la Pianificazione, possano avere visibilità della situazione sales.
4.2 IL SALES PLAN TOOL COME PROGETTO 6SIGMA
Per comprendere appieno l’importanza e la portata di un progetto come il Sales Plan Tool, merita soffermarsi un attimo sui concetti di qualità e di Six Sigma, due argomenti fortemente sentiti all’interno di GE e di grande attualità nello scenario aziendale globale.
La metodologia Six Sigma è infatti l’ultimo ritrovato nel campo della qualità totale e GE la applica fin dal 1996 per accrescere continuamente la qualità dei propri prodotti.
A partire dal 2004 si comincia a parlare addirittura di progetti Lean Six Sigma detti così proprio perchè combinano la metodologia Six Sigma di gestione della qualità con i principi del Lean Enterprise Management per il miglioramento dell’efficienza dei processi operativi interni.
Ogni evento Lean Six Sigma, chiamato Action Workout, coinvolge le persone della funzione direttamente interessata dalla rivisitazione del processo e quelle delle funzioni collegate (i clienti “interni”) le quali possono essere in qualche modo interessate dal cambiamento.
Le metodologie Six Sigma e Lean Management hanno avuto molto successo negli ultimi vent’anni, partendo entrambe dall’ottimizzazione delle linee di produzione ed estendendosi successivamente a gran parte dei processi aziendali e dei settori economici.
Il Lean Management si concentra sulla eliminazione degli sprechi, nel senso di sforzi non necessari, cioè attività che non creano valore per il cliente finale.
Nella pratica i team Lean mappano il flusso con cui il valore del prodotto (value stream) arriva al cliente e intervengono eliminando appunto le attività che rallentano tale flusso.
Six Sigma invece è una metodologia per raggiungere, in un processo, livelli di qualità prossimi alla perfezione, intorno ai 3,4 difetti su milione, dove “difetti” può voler dire, di volta in volta, non conformità di un componente o bug nel codice di un software.
I team Six Sigma definiscono quali siano le caratteristiche più critiche per la qualità del prodotto o del processo (le cosiddette CTQ, Critical To Quality) e individuano le attività che più impattano su di esse, quindi le ottimizzano standardizzandole e mettendo in opera strumenti e meccanismi per ridurre al minimo le anomalie rispetto allo standard.
La creazione del Sales Plan Tool si è collocata fin dall’inizio proprio in questo contesto ed è diventata da subito un progetto Six Sigma.
Il team di progetto, come già accennato nel capitolo precedente, era infatti composto da una Master Black Belt ed una Black Belt, affiancate da due Green Belt, per il coordinamento e la gestione della qualità, dai PM Leader del gruppo OTR, dai rappresentanti del Finance e da un responsabile dell’IT per il supporto tecnico.
Un progetto Six Sigma per essere tale deve seguire una metodologia di implementazione chiamata DMAIC, un acronimo che sta ad indicare i 5 passi fondamentali da seguire per riuscire a garantire il raggiungimento degli standard di qualità sei sigma.
Vediamo brevemente quali sono stati questi passi, in relazione al progetto di sviluppo del Sales Plan Tool.
(D) Define: si tratta di dare una definizione del problema da risolvere (Problem
Statement) e di identificare le esigenze del cliente tramite l’individuazione delle cosiddette CTQ (Critical To Quality) ovvero i requisiti cogenti da soddisfare. Strumenti in questo senso possono essere la costruzione della House of Quality, la definizione della Team Charter (chi fa che cosa e come) e la redazione della Process Map (vedi Fig.1) per descrivere il processo in questione.
La Process Map, relativa al processo di utilizzo e gestione del Sales Plan Tool, è stata rivista e corretta dal candidato durante il periodo di stage.
L’introduzione effettiva del Sales Plan come strumento operativo basilare per le attività giornaliere dei PM e degli altri utenti appartenenti alle funzioni, ha infatti modificato il concetto iniziale di processo che era stato pensato e previsto per l’utilizzo del tool.
Inizialmente si era infatti progettato di creare uno strumento che soddisfasse le esigenze interne al reparto di project management per quel che riguardava il miglioramento della comunicazione tra PM Leader, PM Coordinator e PM e che potesse servire al PM Leader ed al Finance per migliorare i problemi legati ai disallineamenti nei dati di vendita.
Dopo un breve periodo dalla sua introduzione però, il tool ha sollevato l’interesse anche di altre funzioni aziendali, tra cui, in primo luogo, la Pianificazione, con cui il Project Management lavora in stretto contatto.
Avere la possibilità di estrarre i report che danno visibilità dei piani di vendita degli item di commessa e dei relativi price split, si è rivelato un fatto di estrema importanza, non solo per i responsabili del project management ma anche e soprattutto per le funzioni che collaborano con esso, a partire dal Finance fino alla Pianificazione e al Manufacturing.
Come si può vedere dalla Process Map di fig.1, che riporta il processo come si svolge attualmente, ogni funzione attinge al sales plan per ottenere informazioni che possano servire a migliorare e ottimizzare la comunicazione con il project management e a ridurre i tempi, prima decisamente più lunghi, necessari al reperimento di tali informazioni.
Per il Sales Plan la fase di Define ha riguardato la definizione dei seguenti punti:
• Problem Statement: il problema riscontrato, dovuto all’elevato numero di commesse da consegnare nei quarter, riguarda la necessità di avere un sistema integrato che permetta di condividere il dettaglio degli item a sales (ovvero il price split contrattuale). Prima della creazione del Sales Plan tutte le informazioni sui price split erano gestite a mano dai singoli PM su dei fogli Excel e non c’era alcuna standardizzazione dei metodi di gestione dei price split. La funzione Finance doveva quindi interrogare i vari PM, uno ad uno, per ottenere le informazioni sullo stato degli item (risk, roll up, opps) o sui valori cumulati di sales per i vari quarter. Ciò richiedeva ovviamente un tempo maggiore e creava non pochi problemi di comunicazione e di rapporti interpersonali tra il PM ed il rappresentante Finance.
• Scope of the Project: gli scopi del progetto sono quelli di garantire una visibilità totale delle sales (per Units, Manufacturing, Sourcing, Finance, Planning & Fulfillment), di dare la possibilità ai PM di gestire in maniera semplice e integrata risk & opps, di migliorare la comunicazione all’interno dei vari team di progetto, di mantenere la linearità delle vendite. Quest’ultimo concetto merita un breve approfondimento. Linearity, nel gergo aziendale, significa avere un andamento delle vendite, all’interno del quarter e durante l’anno, il più lineare possibile, ovvero senza picchi evidenti, ma che aumenti costantemente. Il piano di sales deve essere ben distribuito su tutto l’anno e bisogna operare in modo da evitare sovraccarichi alla fine di ogni quarter e soprattutto alla fine dell’anno, cosa che però avviene inevitabilmente (vedi Fig. 2). La linearità delle vendite è un obiettivo strategico particolarmente sentito dall’alto management GE e per questo rappresenta un punto fondamentale e
imprescindibile dell’attività quotidiana dei PM Leaders che operano con i propri team per il raggiungimento di tale obiettivo.
Sales Profile - To Be 0 5 10 15 20 25 30 1 2 3 4 5 6 7 8 9 10 11 12 Months S a le s [ € ] Sales Profile - As Is 0 5 10 15 20 25 30 1 2 3 4 5 6 7 8 9 10 11 12 Months S a le s [ € ]
Fig.2: Il concetto di Linearity spiegato attraverso due grafici: situazione come dovrebbe essere (To Be) e com’è nella realtà (As
Is).
• Target: l’obiettivo è quello di riuscire ad avere il controllo delle informazioni relative ai piani di vendita ed ai price split. Tali informazioni devono essere affidabili e aggiornate dai PM secondo i ritmi imposti dal PM Leader o dal General Manager.
• Customers: i clienti interni del Tool sono innanzitutto il reparto di Project Management e la funzione Finance, ma oggigiorno anche Manufacturing, Planning e Sourcing, ovvero tutte le funzioni che collaborano con i PM e con i quali condividono le informazioni sui progetti, sono diventati clienti usuali. In riferimento alla Process Map riportata in precedenza (vedi Fig.1) si può vedere come il Sales Plan rappresenti oggi un importante anello di congiunzione tra le funzioni dell’azienda per ciò che riguarda l’argomento ‘sales’. La visibilità che è possibile ottenere dai report da esso estratti, è il punto focale intorno a cui ruota l’attività quotidiana di una molteplicità di attori.
• Process to improve: definizione dei ruoli (chi fa che cosa) e del ritmo operativo. Occorre specificare chi sono gli utenti del tool e soprattutto in che modo devono essere usate ed interpretate le informazioni presenti nel data base. Lo scopo del tool è infatti quello di porre il focus sulla condivisione dei numeri che i PM inseriscono nel DB rendendoli il principale punto di riferimento anche per le altre funzioni in modo tale da raggiungere un buon allineamento dei dati. Come vedremo in seguito invece, su questo punto si è creata un pò di confusione perchè le Funzioni non hanno compreso bene che il Sales Plan, dal momento della sua introduzione, avrebbe rappresentato il principale strumento per avere visibilità dei piani di vendita ed i numeri inseriti dai PM sarebbero stati quelli più affidabili da prendere a riferimento. Il Sales Tool avrebbe dovuto essere lo strumento trainante l’attività operativa, non solo del Project Management, ma anche delle funzioni come il Finance e la Pianificazione. Oggi invece continuano a nascere incomprensioni su quali siano i dati più affidabili, se quelli a Sales Plan o quelli gestiti dal Finance nel business model, e per questo si spende sempre parecchio tempo a giustificare i numeri da entrambe le parti, cercando di capire da dove vengano gli scostamenti più evidenti.
Nella fase di Define è stato anche stilato un piano d’azione delle principali attività e delle date entro le quali tali attività si sarebbero dovute concludere.
Il piano prevedeva: l’identificazione delle CTQ (Linearity & Customer Satisfaction) il cui driver principale altro non è che il processo di sales recognition, la progettazione e lo sviluppo del tool, l’esecuzione della fase di training, la stesura del manuale di istruzioni, il lancio del tool in fase di produzione, l’implementazione del tool negli altri stabilimenti oltre Firenze, fino ad arrivare alla conclusione del progetto con la conferma del processo.
(M) Measure: è la fase dedicata alla misurazione del processo per verificare che
soddisfi le esigenze del cliente. Si parte definendo gli standard di performance, raccogliendo i dati e valutando gli scostamenti. Nel caso del Sales Plan questa fase si riduce ad una semplice misura tipo Yes/No visto che in precedenza non esisteva nessuno strumento di gestione integrata delle vendite nè tantomeno il relativo processo.
(A) Analyse: questa fase riguarda il calcolo della Process Capability, la
definizione degli obiettivi di performance e l’individuazione delle principali fonti di varianza ovvero di quegli elementi di disturbo che genererebbero scostamenti rispetto all’andamento standard del processo.
(I) Improve: è la fase di miglioramento nella quale si mettono in atto tutta una
serie di azioni per correggere eventuali scostamenti dagli standard o inserire modifiche per aumentare l’efficienza. Rientrano in questa fase tutte quelle modifiche apportate al tool durante la fase di implementazione (vedi paragrafo successivo) dovute all’emergere di bisogni nuovi che prima non erano stati considerati e che solo con l’utilizzo da parte dei PM si sono evidenziati.
(C) Control: consiste nell’implementare un sistema di controllo del processo che
permetta di calcolare alcuni parametri di performance e valutare se le previsioni fatte all’inizio sono state raggiunte nella pratica. L’obiettivo è quello di avere un feedback sul corretto andamento del processo che dia una risposta alle domande:
abbiamo raggiunto i target? le previsioni si sono realizzate? Nel caso del Sales Plan, come già visto per la fase Measure, il controllo è consistito innanzitutto nella verifica del parametro “esistenza del tool” ovvero nel dare una risposta del tipo Yes/No.
Prima infatti non esisteva alcun sistema integrato e condiviso per la gestione delle sales e nemmeno il relativo processo, quindi non è stato possibile effettuare un controllo comparato.
Il Sales Tool ha rappresentato una totale novità ed è oggi uno strumento operativo usato non solo dal gruppo Project Management e dal Finance, come invece era stato pensato inizialmente, ma anche da tutte le altre funzioni aziendali ed è stato addirittura implementato negli altri stabilimenti produttivi italiani e esteri.
Adesso che il tool è diventato parte integrante dei processi quotidiani si può pensare a forme di controllo volte a valutarne l’efficienza, l’efficacia e le possibilità di miglioramento che, qualora ci fossero, porterebbero ad una nuova implementazione degli step del DMAIC (metodologia circolare).
4.3 DESCRIZIONE GENERALE DELLE PRINCIPALI FUNZIONALITA’ DEL TOOL
Il Sales Plan Tool è un’applicazione che si appoggia all’ERP aziendale. Si presenta come una maschera composta da campi e linee che il PM deve compilare con i dati di price split. Vi si accede dalla rete intranet aziendale tramite password.
La parte superiore della maschera (vedi fig. pag.15) deve essere compilata con i dati generali di progetto. I campi obbligatori sono:
• il codice della commessa madre: Mother Job (M_110XXX, M_160XXX, M_170XXX)
• il nome del progetto: Project Name
• il numero di commessa: Job (110XXXX per i compressori -160XXXX per le turbine)
• l’Applicazione
• il PM Leader (Transportation>L, NG&Processing, Turn Key Solutions)
• l’Account Manager (il PM Coordinator)
• il Title Transfer del progetto completo (EXW, FAS, FOB...) Campi facoltativi permettono di inserire informazioni aggiuntive quali:
• la data di creazione : Creation Date
• il livello cumulato di rischio/opportunità della commessa: Risk rate/Opps rate
• il nome del compilatore del form: Owner
La parte inferiore della maschera è strutturata come una tabella e presenta i seguenti campi:
• il nome dell’ item: Item Name (es.: camera filtri, motore, condotto d’ingresso ecc.)
• il numero delle Functional Units: FU Number (fornito dal Finance)
• la tipologia di item: On Skid/Off Skid (ovvero Macchine/MSD)
• il codice PEI e la sua descrizione (fornito dal Planner)
• il valore monetario: Value Currency
• la valuta di riferimento: Project Currency (Euro o Dollari)
• il tasso di cambio: Swop Rate/Exchange Rate
• il valore in Euro: Value Euro
• il quarter (1Q, 2Q, 3Q, 4Q, entro il quale avverrà la vendita)
• la data di vendita contrattuale: 1st Schedule Sales Date
• la data prevista di vendita: Promise Sales Date
• la data dell’Ex Works: EXW Date
• la conferma della vendita: Accrued (Yes/No)
• lo stato dell’item: Risk, Roll up, Opps
• il quarter di opportunità: Opportunity Quarter
• la tipologia di Tiltle Tranfer del singolo item (EXW, FAS, FOB...) Inizialmente i campi erano in numero minore. Da quando il tool è entrato in funzione ed i PM hanno cominciato ad inserire tutti i price split e si è quindi cominciata ad avere una certa visibilità del piano di sales, si sono evidenziate esigenze nuove e ulteriori campi sono stati creati o modificati, anche per dare risposta alle richieste delle altre funzioni in merito a particolari informazioni.
Sono stati così creati ad hoc i campi: Skid – FU Number – Title Transfer. L’ aggiunta del campo Skid ha permesso di suddividere gli item del price split tra On-Skid (Macchine) e Off-Skid (MSD) dando così al Finance un’informazione in più necessaria per una corretta contabilizzazione delle vendite legata ad una regola interna che non permette il passaggio degli MSD se prima non è stata contabilizzata la vendita della rispettiva Macchina.
Il campo relativo al FU Number invece è stato creato nel momento in cui alcuni colleghi del Finance, a seguito dell’implementazione di un nuovo processo interno per il calcolo dei costi di progetto (denominato Sop 81.1), hanno sollevato la necessità di poter estrarre dal Sales Plan un report in cui accanto al nome dell’item ci fosse anche il numero della relativa functional unit: un numero identificativo, da loro generato, che permette di classificare gli item secondo il criterio voluto dal nuovo sistema di contabilizzazione.
Questa modifica al tool ha permesso di ottenere il risultato voluto e di semplificare il lavoro al Finance.
Un’altra modifica, auspicata fin dall’inizio, ha riguardato invece il title tranfer.
Nonostante la maschera generale prevedesse l’inserimento del title transfer della commessa (job), si è successivamente richiesto che la stessa cosa si potesse fare per ogni linea del price split, visto che ogni item può avere un TT diverso da quello della commessa di riferimento.
L’idea era che il flag indicasse l’avvenuta vendita dell’item ma, man mano che i PM iniziavano a fare sempre più ampio uso del tool e a riempire tutti i campi del form, è nato il problema della poca chiarezza nella definizione di Accrued: non era infatti chiaro quale fosse il momento in cui la vendita si considerasse effettuata ed il PM potesse di conseguenza segnare Yes nel relativo campo.
Si è discusso di questo con i vari PM Leader ed alla fine si è deciso di specificare che la vendita risultasse effettuata nel momento in cui il PM avesse inoltrato la richiesta di sales sul sistema ERP aziendale (Oracle), che prevede una specifica procedura in merito.
Oggi lo stato degli accrued è diventato un dato fondamentale che il PM Leader tiene costantemente sotto controllo poichè gli permette di valutare lo scostamento rispetto ai target fissati per il quarter e porre in atto eventuali azioni correttive per avvicinarsi sempre di più agli obiettivi di vendita.
Come si può osservare dalla figura sotto, l’interfaccia grafica del tool è particolarmente user-friendly.
Presenta i campi obbligatori in verde e quelli campi facoltativi in bianco. La barra degli strumenti in alto permette di effettuare ricerche e accedere ai price split dei vari progetti presenti nel data base.
Il PM sarà l’unico che potrà modificare i dati, tutti gli altri utenti potranno solo leggere ed estrarre i report relativi ai progetti di interesse.
Tali report possono essere semplicemente estratti cliccando in basso sulle due icone denominate Detailed Report e Cumulative Report (vedi paragrafo successivo).
Ultimamente sono state apportate ulteriori modifiche ed arricchimenti al form, seguendo i suggerimenti raccolti dai PM ed in base alle esigenze di visibilià evidenziate dai PM Leader.
I nuovi campi che sono stati aggiunti sono: quello denominato Price Split Agreed With Customer che, se spuntato, indica che il price split inserito nel data base è stato concordato precedentemente con il cliente ed approvato; quelli relativi al valore totale, in Euro, di commessa e progetto, ed un campo note per permettere al PM di scrivere particolari informazioni che altrimenti non potrebbero essere inserite nel form.
Sull’estrema destra della tabella, alla fine di ogni riga, il tasto H (Record History) permette di aprire una finestra che riporta i dettagli dell’ultima modifica effettuata su quell’item di price split (vedi Fig.2).
Le informazioni visualizzate riguardano la data in cui è stata effettuata la modifica (Last Update Date), la persona responsabile della modifica (Updated By), la cosiddetta Root Cause ovvero l’imputazione della modifica, il campo che è stato modificato (Last Status) ed infine il motivo della modifica (es.: ritardo fornitore, ritardo manufacturing, ritardo nelle consegne)
Fig.2: La finestra Record History
Questo sistema permette di tenere traccia delle ultime modifiche apportate ai price split e di ricostruire gli ultimi cambiamenti, dandone giustificazione se necessario.
Permette altresì di capire quali siano le cause principali o più comuni delle variazioni, che solitamente riguardano il rilancio (posticipo) delle date Promise dovuto, nella maggioranza dei casi, a problemi legati alle ispezioni da parte cliente per il controllo della qualità e per la chiusura delle punch list (lista delle non conformità sui materiali arrivati in cantiere), alla ricezione dei materiali (MSD) dai fornitori, all’ imballaggio e alle spedizioni (come nel caso in figura 2, ritardo nella consegna) che sono affidate in outsourcing ad una ditta esterna.
In sintesi dunque le funzioni offerte dal Sales Plan sono molteplici ed i PM hanno la possibilità di gestire in maniera semplice ed efficace i loro price split e i loro piani di sales.
Tutti gli altri utenti, estraendo i report, hanno la visibilità sull’andamento delle vendite e sugli eventuali aggiornamenti.
Vediamo ora un pò più in dettaglio che tipo di report vengono generati dal sistema.
4.4 I REPORT: DETAILED E CUMULATIVE
Nel momento in cui un qualsiasi utente voglia conoscere lo stato delle vendite in un certo periodo o in relazione ad un certo PM Leader, basta che selezioni uno dei due report offerti dal tool.
Per effettuare l’estrazione dei due report basta cliccare sulle icone riportate in basso nel form e compilare una finestra con i criteri per la ricerca.
L’utente può riempire i campi della finestra di ricerca grazie a dei menù a tendina che gli permettono di selezionare i parametri con cui impostare la ricerca e renderla più o meno ristretta (vedi Fig.3).
Come si può osservare dalla Fig.3 un utente che voglia conoscere i price split delle commesse gestite da un certo PM Leader effettuerà la ricerca selezionando il nome del PM Leader dalla lista presente nel menù a tendina e selezionerà il quarter, o i quarter se è interessato ad un range temporale più ampio, nello stesso modo (vedi Fig.4). Potrà lasciare gli altri campi vuoti con l’indicazione di default ‘%’.
Qualora l’utente volesse restringere la ricerca ad una commessa in particolare o al portafoglio gestito da un singolo PM basterà che selezioni i campi ad essi relativi.
I campi From/To sono compilati di default con gli ultimi quattro giorni a partire dalla data attuale e rappresentano le date di riferimento iniziale e finale del report.
Il sistema cioè estrae le informazioni considerando i cambiamenti e le variazioni che possono essere avvenuti negli ultimi quattro giorni.
Il campo Quarter invece consente di selezionare il trimestre (o i trimestri) per il quale si vuole visualizzare il piano di sales (vedi Fig.4).
La tipica ricerca che viene effettuata è quella in cui si selezionano il PM Leader ed il Quarter attuale, nel quale ci si trova al momento, così da ottenere la situazione di sales aggiornata.
Fig.3: Maschera per l’estrazione dei Report
Ma, selezionando i Quarter successivi, si può avere una previsione del profilo delle vendite future, che è l’informazione che solitamente serve al General Manager per avere una visibilità di medio-lungo termine sull’andamento del business.
Vediamo ora nel dettaglio in cosa consistono i due report.
Detailed Report
Da eseguire per singola commessa o job, riporta il dettaglio degli item di price split che dovranno essere venduti nel particolare quarter che è stato precedentemente selezionato nella maschera per l’estrazione del report.
Per ogni item viene poi riportato il nome, il valore monetario, il relativo codice PEI (vedi oltre), il numero della Functional Unit, la tipologia (On/Off Skid), il title transfer, il quarter previsto per la vendita, le date di vendita, contrattuale e Promise, lo stato (Roll up, Risk, Opps) e l’eventuale condizione di Accrued (Yes/No).
E’ il report più completo che riporta tutto un insieme di informazioni di dettaglio necessarie non solo al PM ma anche alle varie funzioni aziendali.
Il gruppo Planning & Fulfillment per esempio, focalizza la propria attenzione sulla colonna che riporta l’indicazione del PEI (Planning End Item), un codice che permette di rappresentare l’item (o gli item) dal quale comincia la fase di pianificazione cosiddetta top to bottom, dall’alto verso il basso, ed è anche l’item della BOM (distinta base) che verrà usato per generare un fabbisogno verso la produzione in base alla data di Manufacturing Complete (data di fine produzione) e che sarà spedito virtualmente per il passaggio del titolo.
Un codice PEI di solito raggruppa sotto di sè una serie di item della commessa e serve per l’emissione dei relativi ordini d’acquisto, se gli item sono di tipo Buy, o per il lancio in produzione se sono di tipo Make.
Nel primo caso il codice PEI servirà al Sourcing per identificare gli item da acquistare ed emettere le relative POR (Purchase Order Request) ai fornitori.
Nel secondo caso il PEI servirà all’Ingegneria per la redazione delle specifiche tecniche e dei disegni.
Facendo riferimento alla Fig.5, ad esempio, il codice PEI chiamato Balance of Plant (BOP) comprende tutti quei materiali e servizi addizionali al prodotto principale come per es. lavori civili, istallazioni e sistemi ausiliari.
Fig.5: Esempi di codici PEI riportati nel Detailed Report.
Al planner, che definisce le date in cui i materiali di un determinato progetto devono arrivare ed essere disponibili per la spedizione al cliente (Need Date), e che quindi lavora su un orizzonte temporale di medio–lungo periodo, interessa poter associare al PEI un valore monetario, rappresentato dal valore di price split degli item che lo compongono, così da darvi una consistenza in ottica strategica e valutarne eventuali rischi e opportunità.
In questo modo il Planner potrà dare informazioni più affidabili sullo stato dei materiali al PM il quale, a sua volta, potrà definire meglio lo stato degli item a sales nel quarter (Roll Up, Risk, Opp).
Il PEI è quindi fondamentale nel processo di sales recognition poichè anch’esso viene “virtualmente” venduto e spedito ma solo nel momento in cui saranno passati a sales tutti gli item che lo compongono.
A quel punto si potrà avere il trasferimento del titolo ed il riconoscimento dei ricavi.
Un'altra informazione basilare che il Detailed report permette di ottenere è quella relativa alla data Promise entro la quale il PM prevede che verrà effettuato il passaggio del titolo di un determinato item.
Questa data, messa in confronto con la data contrattuale (1st Schedule Sales Date), permette di capire il livello di criticità dell’item.
Se, per esempio, la data decisa a contratto con il cliente per la consegna dell’item era stata fissata al 1° aprile e la data Promise risulta pianificata al 1° settembre significa che alcuni problemi si sono verificati durante le attività relative all’acquisizione/produzione di quel determinato item.
Il PM è responsabile in prima persona di tali ritardi e deve agire per cercare di consegnare tutti gli item del price split entro le date stabilite
Da questi esempi si capisce come il Detailed Report rappresenti uno strumento efficace per molte delle funzioni aziendali che collaborano con il project management poiché rende disponibili ad una molteplicità di utenti informazioni di dettaglio che in precedenza erano di proprietà esclusiva dei singoli PM e quindi difficilmente reperibili.
In Fig.6 si riporta un esempio di Detailed Report.
Nelle review settimanali (i cosiddetti Staff Meeting), che il PM Leader effettua con i propri PM Coordinator, con il Business Analyst e con i rappresentanti del Finance, ed a cui il candidato ha personalmente partecipato durante lo stage, il Detailed report viene utilizzato per controllare item per item la situazione generale di una determinata commessa.
Ciò significa, in primo luogo, analizzare gli item a rischio per verificare che siano state intraprese tutte le azioni necessarie per cercare di portarli a roll up, in secondo luogo controllare l’affidabilità delle date Promise inserite dai PM ed eventualmente dare direttive per rilanciarle.
Inoltre il PM Leader può, in concerto con i propri Coordinator, decidere di cambiare lo stato di alcuni item, a seguito di valutazioni di carattere tattico e/o strategico, o perché si sono verificati degli eventi, nella catena di attività che portano alla vendita dell’item (attività quali l’acquisizione delle forniture, gli
imballaggi e le spedizioni, la produzione, i collaudi delle macchine ecc.), che spingono a modificarne il livello di criticità.
Come già accennato, la suddivisione degli item in risk, roll up e opps, è il concetto che sta alla base della gestione operativa del business da parte del PM Leader e dei suoi collaboratori.
Tutto ruota intorno a questa classificazione, ed i valori cumulati, per ogni quarter, del roll up e dei rischi sono i parametri fondamentali a cui ci si riferisce per il controllo del raggiungimento dei target di fatturato e di CM imposti dai vertici aziendali.
Da ciò si capisce quanto la corretta gestione ed il tempestivo aggiornamento di tali dati sul Sales Plan siano fattori critici per il corretto andamento della gestione, non solo a livello strettamente operativo, ma anche a livello strategico, visto che i dati estratti dal tool vengono riportati dal PM Leader al General Manager delle Units e al Presidente della compagnia.
La visibilità che il Detailed Report fornisce sullo stato degli item (come si può vedere dalla Fig.6 le celle relative a risk, opps e roll up sono state appositamente colorate per permettere una più facile e immediata lettura) ha reso molto più semplice la gestione del business dei gruppi di project management.
L’utilizzo del Sales Plan Tool da parte di tutti i PM ha reso possibile una standardizzazione dei metodi di lavoro, delle procedure interne e dei documenti utilizzati (i report appunto) che ha apportato non pochi benefici sia a livello operativo, per tutti gli utenti coinvolti nel processo di gestione delle commesse, sia a livello strategico, per i Leader e per i vertici aziendali, che possono appoggiarsi ad una base solida e condivisa di dati affidabili per conoscere l’andamento del business e poter prendere le decisioni di indirizzo più strategico per il miglioramento delle performance aziendali.
Cumulative Report
Dà evidenza del valore cumulato di sales a roll up per ogni commessa e per ogni quarter, e fornisce anche i valori totali e le eventuali variazioni, se ci sono state, di ciò che è a rischio e ad opportunità.
Riportando i valori complessivi del piano di sales per l’intero anno il Cumulative Report permette anche di fare previsioni sulle vendite e di avere una visibilità di più lungo periodo, fondamentale per poter tracciare una linea d’azione strategica che possa portare alla massimizzazione del fatturato e alla soddisfazione dei clienti.
Per estrarre tale report il sistema effettua delle operazioni sui dati, e richiede quindi qualche secondo in più rispetto all’estrazione del Detailed report.
Tali operazioni producono il valore cumulato delle varie linee di price split di ogni commessa e forniscono quindi i valori totali di ciò che è in vendita nei quattro quarter, sia per il roll up che per i rischi e le opportunità.
C’è però una differenza concettuale importante tra i due report: mentre nel Detailed i valori di roll up e risk sono separati (ad esempio RU=70 e RISK=30) nel Cumulative il rischio è una quota parte del roll up (ovvero il valore totale del roll up comprende già il valore totale del rischio: RU=RU+RISK, quindi si avrebbe RU=100=70+30 e RISK=30).
Perciò, quando si va a leggere il valore di roll up nei due report ci sarà uno scostamento dovuto proprio a questa differenza.
Una volta estratti, i report devono essere salvati come file Excel in modo tale da poter successivamente effettuare operazioni sulle righe o filtraggi per selezionare particolari gruppi di dati.
Nel Detailed, per esempio, si può modificare la colonna relativa alla Promise Date in modo tale da avere le date ordinate dalla più lontana alla più recente per verificare ad oggi quanti item sono scaduti rispetto alla data pianificata per la vendita; oppure verificare lo stato degli Accrued ovvero di tutti quegli item che hanno già fatto sales nel quarter per avere in tal modo visibilità dello scostamento tra ciò che è gia stato realizzato e ciò che occorre fare per raggiungere il target.
Il Cumulative Report invece (vedi Fig.7), come già accennato, riporta, per ogni quarter, i valori cumulati di Roll Up, Risk e Opps di ogni job e le rispettive variazioni, se ci sono state, assieme al valore totale dell’Accrued.
Se nella colonna denominata Variance (vedi Fig.7) compare una X allora significa che il valore totale della commessa (job) ha subito una modifica.
Tale variazione sarà dovuta a cambiamenti dello stato di alcuni item e se ne ha riscontro nelle colone denominate Risk Variation e Opps Variation.
Il report non dà indicazione dell’item che ha subito la modifica ma per conoscere nel dettaglio la situazione basterà estrarre il Detailed report e controllare il price split di quel job.
E’ proprio questo che solitamente si fa durante gli Staff Meeting, le riunioni di aggiornamento settimanali.
Il PM Leader, partendo dalle variazioni riscontrate, effettua un drill down con l’aiuto dei Coordinator responsabili dei vari progetti (LNG piuttosto che Pipeline o W2E) per capire dove sono state apportate le modifiche e per darne giustificazione.
In questo modo egli tiene sotto controllo l’andamento dei vari progetti e degli item più critici, quelli cioè che rischiano di non essere consegnati in tempo al cliente.
Dal Cumulative report, aggregando ulteriormente i dati al fine di ottenere la visibilità dei valori totali di sales gestiti da ogni singolo PM Coordinator, e di conseguenza del valore totale gestito dal PM Leader, si è pensato di costruire una tabella pivot che mostri schematicamente la situazione particolare di sales dei singoli Account manager, con l’indicazione dei valori di Roll Up, Risk e Opps del Quarter e delle loro eventuali variazioni (vedi Fig.8).
Il candidato è stato responsabile della creazione di tale tabella per il PM Leader il quale, grazie ad essa, poteva tenere sotto controllo i valori totali di sales di ogni progetto e gli eventuali cambiamenti ad essi apportati.
Fig.7: Cumulative Report
Tale tabella riassuntiva dà altresì evidenza dei numeri effettivi del gruppo e rappresenta un documento fondamentale di confronto con il Business Model elaborato dal Finance.
Nelle riunioni di aggiornamento settimanali infatti la tabella viene usata come documento standard a cui fare riferimento per effettuare il confronto e l’allineamento con i dati Finance, che solitamente, come spiegato nel capitolo 3, risultano leggermente disallineati rispetto ai valori estratti dal Sale Plan Tool.
Le variazioni del rischio e delle opportunità (Risk Variation e Opps Variation) danno indicazioni di eventuali cambiamenti nello stato di alcuni item.
I valori tra parentesi rappresentano le variazioni negative e stanno a significare che, durante le settimana, uno o più item sono passati da rischio a roll up o ad opportunità.
Se la cella relativa a Opps Variation è positiva significa che qualche item è stato anticipato al quarter presente (operazione cosiddetta di pull in) ed è stato inserito come opportunità; se è negativa significa che ciò che prima era un’opportunità adesso è passato a roll up oppure è diventato un rischio.
Data
Account Manager Project Name Job 1Q Variation 1Q ACCRUED RISK Risk Variation 1Q OPPS OPPS Variation 1Q
BIANCHI ALFA 1705842 572 - 240 212 (485) - -BETA 1101892 198 - - 187 - - -1609447 750 - - - - - -1609448 733 - - - - - -1609449 7,335 - - - - - -GAMMA 1102011 558 - - 500 - - -1102012 976 - 61 100 - - -1102013 6,579 - 612 1,000 - - -1609456 1,000 - - 1,000 - - -1609457 100 - - 100 - - -1609458 2,100 - 500 10 - - -DELTA 1101988 2,700 - 2,427 - - - -1101989 1,523 - - - - - -1609453 5,488 - 959 - - - -1609454 864 - - 403 - - -1609455 2,540 - - 1,350 - - -EPSILON 1102096 1,188 - 206 492 - - -1609469 2,948 - 1,578 - (1,083) 907 -1609470 166 - 312 - - 108 -1609471 5,469 - 312 - - 135 -ZETA 1705843 655 - 54 384 266 862 (114) 1705844 331 - 54 30 (165) - -SIGMA 1102005 1,424 - 424 - - - -1102006 280 - 280 - - - -1102007 280 - 280 - - - -1609450 8,219 - 54 5,575 - - -1609451 2,750 - 18 - - - -1609452 88 - - - - - -OMEGA 1102122 544 - 544 - - 68 61 1102123 302 - - 302 - 30 -1609475 265 - 265 - - - -1609476 2,655 - 129 857 - - -1609477 4,400 - 3,082 - - - -BIANCHI Total 65,980 - 12,391 12,502 (1,467) 2,110 (53) ROSSI KAPPA 110XXX 3,653 - 3,653 - - - -LAMBDA 1102182 3,500 - - - - 251 -1108660 1,789 - - - - 180 -1605913 586 - 130 - - 13 -1607317 2,561 - - - - 1,226 -PI 1607318 1,600 - - - - - -1607319 160 - - - - - -1607320 1,654 (800) - - (800) - -ROSSI Total 15,503 (800) 3,783 - (800) 1,670 -Grand Total 81,483 (800) 16,174 12,502 (2,267) 3,780 (53)
Fig.8: Esempio di tabella pivot ottenuta dal Cumulative Report che mostra i dati di riferimento per la gestione ordinaria del business del gruppo Transportation>L.
La colonna 1Q dà il valore totale del roll up nel primo quarter per ogni commessa.
La colonna Variation 1Q invece riporta eventuali modifiche del piano di sales. Se compare un valore negativo significa che qualche item è stato spostato
ad un altro quarter oppure che è cambiato il price split di progetto magari a causa di un Change Order richiesto dal cliente o ottenuto dal PM.
La colonna Accrued riporta il valore totale di tutti gli item che sono già stati venduti e per i quali il PM ha effettuato la richiesta di sales tramite l’apposita procedura sul sistema ERP aziendale.
Infine, la somma dei valori del roll up di ogni progetto (Grand Total) dà il indicazione dell’entità del business gestito da ogni singolo PM Coordinator e, complessivamente, dal PM Leader.
Questi valori rappresentano l’entità del fatturato che si prevede di ottenere nei vari quarter.
In conclusione, dopo aver esposto le funzionalità e le possibilità offerte dal Sales Plan Tool e dai suoi report, Cumulative e Detailed, nel prossimo capitolo verrà descritto un’ulteriore strumento operativo usato nel gruppo Transportation>L da PM Leader e PM Coordinator per tenere sotto controllo i principali parametri di gestione.
Tale strumento è rappresentato da un insieme di documenti, report e file che danno visibilità delle situazioni di sales, cash e di altri parametri legati alla gestione delle commesse, quali i piani di produzione di turbine e compressori e gli aggiornamenti delle BCE (rif. capitolo 3) sullo stato di avanzamento dei costi sostenuti.
Tutti questi documenti vengono raccolti in un fascicolo denominato Book che viene distribuito settimanalmente al PM Leader ed ai suoi Coordinator.
Nel Book confluiscono tutta una serie di documenti che come si è detto sono fondamentali per dare visibilità dell’andamento, a livello aggregato per i vari progetti aperti, dei parametri di gestione.
Il candidato ha, nei sei mesi di stage, personalmente curato la creazione e la distribuzione del Book diventandone alla fine l’unico responsabile.
