CAPITOLO 5
L’implementazione dell’ERP Oracle alla Power-One Italy
S.p.A.
5.1 Introduzione
In questo capitolo analizzeremo il progetto per l’implementazione dell’ERP Oracle alla Power-One Italy S.p.A. L’obiettivo di questo capitolo è quello di illustrare in modo completo l’andamento del progetto basandomi sul lavoro da me svolto come membro del team di implementazione.
Nella prima parte del capitolo verrà illustrata una visione generale del progetto, con attenzione particolare ai seguenti punti:
o Pianificazione del progetto di implementazione, parte nella quale verranno mostrate le motivazioni che hanno portato alla decisione di implementare Oracle; o Metodologia di implementazione, dove illustreremo la metodologia impiegata,
spiegando obiettivi e strumenti utilizzati in ciascuna fase;
o Il team di progetto, dove vedremo la composizione del team con particolare riferimento a compiti e responsabilità di ciascun membro;
o Gli strumenti di comunicazione, per mostrare quali strumenti sono stati utilizzati per gestire la comunicazione tra tutto il personale coinvolto nel progetto di implementazione.
Nella seconda parte del capitolo entreremo nel vivo analizzando in maniera dettagliata l’andamento del progetto in tutte le sue fasi, focalizzandoci sulle fasi salienti:
o GAP Analysis, con la quale si è cercato di valutare e colmare i GAP esistenti tra i processi attualmente in essere nello stabilimento del Valdarno e quelli futuri come supportati dal nuovo sistema. Il focus è sulla logistica delle spedizioni, modulo del quale mi sono occupato in prima persona;
o Sessioni di testing (CRP1, 2 e 3), sessioni in cui sono state testate le funzionalità dei moduli di Oracle, sia in modo separato che congiunto. Anche qui la descrizione dettagliata si concentra sulla logistica delle spedizioni;
o Andamento generale del progetto, per mostrare in modo sintetico lo svolgimento del progetto per quanto riguarda gli altri moduli che non ho seguito in prima persona, in modo da dare al lettore un’idea generale sull’andamento globale del progetto;
o Esito del progetto. Questo punto, visto che questo lavoro viene terminato prima della data di effettiva implementazione del nuovo sistema, riguarda principalmente la decisione del top management di spostare di tre mesi la data prevista del Go Live. Nel paragrafo dedicato all’esito ci occuperemo principalmente delle motivazioni che hanno portato il board a prendere questa decisione.
Il presente capitolo rappresenta quindi una cronistoria del progetto di implementazione, riportata dal mio punto di vista come membro del team di progetto, quindi più dettagliata per la parte legata al modulo da me seguito in prima persona.
Per l’analisi dei punti di forza e di debolezza del progetto e dei Fattori di Rischio che hanno maggiormente inciso sul suo andamento si rimanda al Capitolo 6.
5.2 La pianificazione del progetto di implementazione
5.2.1 La decisione dell’implementazione di Oracle alla Power-One Italy S.p.A. Il “passo 0” nei progetti di implementazione di un sistema ERP può essere considerato il processo decisionale con il quale di giunge alla decisione di dare inizio al progetto stesso.
Nel caso della Power-One questa scelta era non solo obbligata, ma vi era anche la volontà di accelerare il progetto portandolo a compimento nel più breve tempo possibile. Questo tipo di strategia era in un certo senso inevitabile, ed era direttamente riconducibile all’acquisizione da parte del gruppo Power-One del ramo PEG della MagneTek.
Come abbiamo detto precedentemente con tale acquisizione la Power-One entrava in possesso di ben quattro stabilimenti: Valdarno (Italia), Chatsworth (USA), Salgotarjan (Ungheria), Baoan (Cina). La totalità di questi impianti utilizzava il COPICS, il sistema Legacy di cui abbiamo ampiamente trattato nel capitolo 2, mentre il resto degli stabilimenti del gruppo era già passato ad Oracle attraverso una serie di progetti di implementazione (vedi figura 20 di pagina seguente).
Per poter inserire i nuovi impianti nel network aziendale si doveva procedere non solo ad una riorganizzazione globale del gruppo, ma si doveva anche pensare ad una integrazione a livello di Information Technology. Le linee decisionali che si potevano seguire erano sostanzialmente due (se si esclude la decisione di non intervenire, ovviamente impraticabile):
1. Implementare nei nuovi impianti il sistema ERP Oracle, utilizzato dai restanti stabilimenti del gruppo.
2. Continuare ad utilizzare nei nuovi impianti il sistema Legacy COPICS, costruendo apposite interfacce per permettere la comunicazione tra questo e il sistema ERP Oracle utilizzato dai restanti stabilimenti.
Come si può immaginare si tratta di due progetti diversi sia per scopo che per metodo ed impiego di risorse.
Nel primo caso si punta ad una integrazione globale dei nuovi impianti nel network aziendale: abbiamo infatti già detto che adottando un sistema ERP ci si deve adeguare al business model in esso presente, e questo comporta una standardizzazione dei processi e delle procedure. Lo sforzo che si deve compiere in questo caso è notevole e richiede non solo un adeguamento delle infrastrutture tecnologiche ma anche una vera e propria “rivoluzione” che coinvolge tutti i processi aziendali, con un ragguardevole impatto a livello di cambiamento della struttura sociale dell’azienda.
Nel secondo caso si decide per una linea d’azione più morbida, lasciando agli impianti il vecchio sistema gestionale e creando delle interfacce che permettano ai due sistemi esistenti nel gruppo, il nuovo ERP ed il vecchio Legacy, di parlare ed interagire tra loro. L’impatto a livello di processi aziendali e psicologico risulta notevolmente ridotto, ma
ridotti sono anche i risultati che si possono ottenere: in questo caso vengono a coesistere in azienda due distinti modelli di business, ciascuno con le sue peculiarità, per cui l’integrazione che si raggiunge è sicuramente minore. Inoltre questa è anche una soluzione incentrata sul breve periodo in quanto lascia intatto il sistema Legacy, sistema che, pur supportando i processi aziendali, ha tutti i difetti di un sistema di vecchia generazione elencati nel capitolo 2.
La decisione del top management della Power-One è stata quindi quella di optare per l’implementazione di Oracle nei nuovi stabilimenti, prima però si è proceduto ad una riorganizzazione degli impianti, accentrando la produzione, laddove possibile, nelle aree con una struttura di costi ridotta: per questo le produzioni dello stabilimento di Chatsworth sono state spostate nello stabilimento della Repubblica Dominicana, mentre le produzioni realizzate nello stabilimento di Salgotarjan sono state spostate nello stabilimento della Slovacchia.
Dobbiamo precisare comunque che inizialmente l’implementazione era prevista anche nello stabilimento ungherese, ma la strategia di cui abbiamo appena detto ha reso inutile la decisione di implementare Oracle nell’impianto di Salgotarjan.
5.2.2 La scelta dell’ERP
Il primo effettivo passo di un progetto di implementazione consiste nella scelta dell’ERP da implementare: ovviamente in questo caso la scelta era obbligata, dato che tutti gli stabilimenti del gruppo, ad eccezione di quelli oggetto dell’ultima acquisizione, utilizzavano Oracle.
La versione di Oracle implementata è la 11.5.8; per una visione generale delle caratteristiche di questo ERP si veda la figura 21 di pagina precedente.
Vediamo comunque come si svolge il processi di scelta di un ERP (figura 22).
Quando un’azienda decide di implementare un sistema ERP deve prima di tutto mappare i propri processi (AS IS). Dopodichè, in accordo con le strategie aziendali, si deve procedere ad una reingegnerizzazione dei processi, in modo da individuare i nuovi processi (TO BE).
A questo punto ci si rivolge al mercato dei pacchetti ERP e si procede ad analizzarli, comparando il business model sul quale i singoli pacchetti sono basati con i processi futuri sui quali si baserà l’azienda: da questa analisi emergeranno delle differenze (GAP) più o meno rilevanti.
Figura 22 – Il processo di scelta di un ERP.
Uno dei parametri di scelta, anche se non l’unico, è quello di scegliere il pacchetto ERP il cui business model meno si discosta dai processi aziendali TO BE.
Perché abbiamo parlato di questa metodologia se nel nostro caso la scelta era obbligata? Quello che vogliamo mettere in evidenza è la differenza tra una implementazione “classica”, in cui si procede alla scelta dell’ERP dopo aver effettuato una reingegnerizzazione dei processi, e il caso oggetto di questo lavoro, in cui l’ERP è già stato scelto ed i processi aziendali vengono reingegnerizzati, a meno di particolari eccezioni, sulla base del business model su cui si basa l’ERP.
5.2.3 La metodologia di implementazione Visione generale
Diamo una prima rapida occhiata all’intera metodologia di implementazione di Oracle: in figura 23 possiamo vedere la prima stesura del piano di progetto che includeva gli stabilimenti del Valdarno, di Baoan e di Salgotarjan e la Timeline originale con il Go Live previsto per il 30 settembre 2007; in figura 24 possiamo invece vedere il piano definitivo, nel quale non era più prevista l’implementazione nello stabilimento ungherese ed il Go Live era fissato per il 1 novembre 2007. Possiamo già anticipare che, mentre per l’impianto cinese le scadenze sono state rispettate, per lo stabilimento italiano il Go Live è stato posticipato al 28 gennaio 2008.
Prima di addentrarci nella analisi dei passi della metodologia dobbiamo far notare che il piano, anche nella sua versione originale, aveva già subito delle modifiche. In principio l’idea era quella di partire prima con l’implementazione nel sito cinese per poi proseguire con gli impianti italiano ed ungherese: questa scelta era essenzialmente legata al fatto che lo stabilimento di Baoan ha dei processi meno complessi della controparte italiana, e che quindi poteva essere usato come progetto “pilota” per gli altri impianti. Il motivo per cui questa decisione è stata rivista è la presenza di altri progetti “pesanti” nello stabilimento cinese all’epoca dell’avvio del progetto di implementazione di Oracle: si stavano infatti trasferendo delle produzioni di nuovi prodotti progettati nel Valdarno, con conseguente utilizzo di notevoli risorse che rendevano impossibile la contemporanea presenza del progetto legato ad Oracle.
A causa di ciò il progetto avviato a Baoan all’inizio del 2007 è stato arrestato in marzo, e il focus si è spostato sull’impianto del Valdarno, dove il progetto ha preso il via alla fine di marzo del 2007.
- 6 2 -F ig u ra 2 3 – L a m et o d o lo g ia d i i m p le m en ta zi o n e – T im el in e o rig in al e.
- 6 3 -F ig u ra 2 4 – L a m et o d o lo g ia d i i m p le m en ta zi o n e – T im el in e d ef in iti v a.
Gli obiettivi
Ovviamente l’obiettivo principale e globale di tutto il progetto è quello dell’implementazione di Oracle nello stabilimento italiano e cinese, ma vediamo in quali sotto-obiettivi si articola il goal primario del progetto, con focus particolare sullo stabilimento del Valdarno:
o Impostare l’ambiente (Environment) di Oracle per lo stabilimento del Valdarno. o Implementare quelle che vengono chiamate “Power-One Best Practice Solutions”. Si
tratta fondamentalmente delle soluzioni personalizzate già individuate durante i precedenti progetti di implementazione, e che vengono attualmente utilizzate da tutti i siti Power-One; questo è l’obiettivo fondamentale per perseguire la standardizzazione dei processi e delle procedure.
o Addestrare i “Super Users” (utenti chiave) e gli “End Users” (utenti finali) all’utilizzo di Oracle E-Business Suite (versione 11.5.8). Sui Super Users ritorneremo più avanti, nel paragrafo dedicato al team di progetto, basti qui dire che si tratta di utenti chiave che svolgono un ruolo fondamentale in tutta l’implementazione, e che acquisiscono una conoscenza approfondita del sistema ERP Oracle.
o Migrare i dati “attivi” dal sistema Legacy ad Oracle; con questo si intende che, prima di effettuare la migrazione, viene effettuata una ripulitura dei dati per eliminare le informazioni obsolete o ridondanti.
o Testare tutti i “business process” per garantire la continuità dei processi anche dopo il Go Live; ovviamente non si vuole danneggiare il business aziendale, per cui ci si deve accertare che i normali processi aziendali continuino normalmente anche dopo il Go Live.
o Effettuare degli audit durante e post-implementazione per assicurare la correttezza dei processi e che le procedure individuate vengano puntualmente seguite; oltre ad individuare eventuali miglioramenti si deve evitare che vi siano utenti che operino aggirando il sistema.
Vi sono invece due obiettivi che non rientrano nel progetto di implementazione:
o Lo storico delle transazioni non viene migrato dal COPICS ad Oracle. Si viene così a perdere un notevole volume di informazioni storiche, utili in alcuni casi per ricostruire come si è giunti alla situazione attuale: si pensi ad esempio a tutte le transazioni che subisce un codice a magazzino (versamenti, prelievi, ecc.).
o Anche se Oracle è nativamente multilingua l’unica lingua riconosciuta dal sistema, sia in input che in output, è l’inglese.
Questi due punti, per quanto possano apparire marginali, hanno un impatto notevole non solo da un punto di vista pratico ma anche psicologico.
In particolar modo l’aspetto della lingua del sistema rappresenta un cambiamento epocale: si pensi infatti che il COPICS, con la sua interfaccia a caratteri a volte criptica (a causa delle innumerevoli sigle e abbreviativi usati) ma completa, era completamente localizzato, per cui le informazioni venivano presentate in italiano. Non solo questo valeva per lo stabilimento del Valdarno ma, vista l’efficacia del Legacy, questo modello era stato applicato, con la stessa interfaccia, anche agli impianti cinese ed ungherese! Si può quindi ben capire la portata del cambiamento quando si passa da un sistema in italiano, esportato con successo in altri stabilimenti, ad un sistema completamente in inglese che viene in un certo senso imposto dalla nuova proprietà; ritorneremo su questo punto nei prossimi paragrafi.
I passi della metodologia
Facendo sempre riferimento alla figura andiamo adesso ad analizzare brevemente in cosa consistono i passi della metodologia utilizzata nell’implementazione:
o Initiations Phase (fase iniziale). Questa è la fase 0 del progetto, quella di pianificazione necessaria all’avvio del progetto. Qui si prepara il piano temporizzato del progetto, si individua il team, le risorse necessarie, si individuano i Super Users, si impostano gli strumenti da utilizzare (come ad esempio lo Share Point Web Site, sul quale ritorneremo in seguito).
o CRP0 & CRP1 Test Instance (CRP0 e preparazione CRP1). Con l’acronimo CRP si intende il Conference Room Pilot: si tratta di una sessione di testing con la quale si cerca da un lato di introdurre gradualmente gli utenti ad un ambiente Oracle che si avvicina a quello definitivo, dall’altro si testano le soluzioni individuate. La fase di CRP0 in realtà non è proprio una sessione di testing, bensì un’analisi dei processi di business AS IS dello stabilimento del Valdarno volta all’individuazione dei GAP esistenti tra i processi mappati e le Best Practise utilizzate in Power-One. Si inizia il training dei Super Users e si prepara la sessione di CRP1.
o CRP1, CRP2 e CRP3. Il progetto continua a svolgersi attraverso fasi alterne di sessioni di testing (i vari CRP) e periodi di lavoro dedicati alla soluzione sia dei
GAP1 esistenti che degli Issue2. L’obiettivo è quello di operare per affinare le soluzioni in modo da giungere all’ambiente operativo finale, garantendo la risoluzione dei problemi e il pieno supporto ai processi aziendali. Con la sessione di CRP3 inizia anche il training intensivo di tutti gli utenti aziendali (che avevamo chiamato End Users). Parallelamente a queste operazioni svolte On Site (nello stabilimento del Valdarno) si procede alla conversione e migrazione dei dati dal sistema Legacy.
o Prepare Rollout (prepararsi al Go Live). In questa ultima fase prima del Go Live ci si assicura che tutti i GAP e gli Issue siano stati risolti e definitivamente chiusi, si definiscono i vari profili utente (ovvero a quali funzioni ogni singolo utente avrà accesso), si completa l’addestramento di tutti gli utenti, si preparano le stampanti. Al termine di questa fase abbiamo l’ambiente finale di Oracle (chiamato PROD).
o Go Live!. Trattandosi di una sostituzione a taglio netto alcuni giorni prima del Go Live vengono bloccate tutte le transazioni del sistema Legacy per assicurare la consistenza dei dati da migrare, dopodichè si procede alla migrazione totale dal Legacy ad Oracle.
o PROD Production Instance (fase di post Go Live). In questa fase si deve fornire il supporto necessario agli utenti, si devono monitorare le prestazioni del sistema (fase 1) per poi procedere alla individuazione di possibili miglioramenti (fase 2).
Nei paragrafi successivi vedremo in dettaglio come questi passi sono stati eseguiti nell’implementazione di Oracle nello stabilimento italiano.
5.2.4 Il team di progetto
Per avere una visione completa del team di progetto responsabile per l’implementazione nel Valdarno e a Baoan si può fare riferimento alla figura 25 di pagina seguente.
Partendo dal più alto livello di responsabilità possiamo notare come il progetto è sotto la diretta responsabilità di due rappresentanti dello Steering Committee, ovvero dell’alta direzione aziendale, i cui compiti sono i seguenti:
o Supervisionare l’intero progetto di implementazione.
1
Un GAP è una differenza (letteralmente un “buco”) tra il processo previsto da Oracle e il processo effettivo realizzato nello stabilimento. Ad esempio nel nostro caso è un GAP il fatto che Oracle, nella versione Power-One, non supporti la gestione del Vendor Managed Inventory dei fornitori.
2
Un Issue è un errore nel processo come supportato da Oracle. Nel nostro caso è un Issue ad esempio il fatto che, durante i primi CRP, alcuni report che il sistema doveva stampare in automatico non
o Allocare e controllare il budget e le risorse necessarie al progetto.
o Aiutare nella risoluzione di quegli Issue la cui soluzione comporta dei cambiamenti sostanziali nel progetto (ad esempio una eccezione alle Best Practise Power One). o Approvare ogni cambiamento nello scopo o nelle risorse di progetto.
o Approvare variazioni di budget.
Rivedere il progetto dopo il raggiungimento di ciascuna milestone.
Alle dirette dipendenze dello Steering Committee troviamo il responsabile dell’implementazione, chiamato Director of Implementations, a cui sono affidati i seguenti compiti:
o Definire lo scopo del progetto e gli obiettivi dello stesso. o Comunicare in modo diretto col top management.
o Coordinare e gestire tutte le attività del progetto di implementazione.
o Monitorare e controllare le soluzioni individuate, assicurando la consistenza e la correttezza delle soluzioni stesse.
Figura 25 – Il team di progetto per l’implementazione negli stabilimenti del Valdarno e di Baoan.
o Gestire tutte le attività di progetto, comprese quelle relative alla definizione degli scopi e del budget di progetto.
o Assicurare la qualità dei risultati finali del progetto.
Come si può notare dalla figura sia lo Steering Committee che il Director of Implementations operano dalla sede centrale sita negli Stati Uniti (a Camarillo, nello stato della California).
Al livello gerarchico immediatamente successivo troviamo tre diverse posizioni: due riguardano i responsabili del progetto in loco, uno per ciascuno stabilimento (Baoan Site Lead e Valdarno Site Lead), mentre l’altra figura (Solution Manager & Coordinator), presente nel sito del Valdarno, funge da coordinatore per i due progetti e da responsabile per le soluzioni individuate in entrambe le implementazioni; da notare che questo ruolo viene qui ricoperto da un consulente esterno.
Ai due responsabili di ciascun stabilimento fanno riferimento i Super Users, ovvero gli utenti chiave, ai quali sono affidati i seguenti compiti:
o Definire i requisiti del business, ovvero fornire supporto agli analisti per individuare i fabbisogni peculiari di ciascun stabilimento; si tratta in pratica di mappare correttamente i processi AS IS.
o Comprendere, imparare ed adattare i processi e le soluzioni fornite da Oracle.
o Testare i processi di Oracle e i dati convertiti dal Legacy assicurandone consistenza e correttezza.
o Preparare lo stabilimento per il Go Live.
o Aggiornare le istruzioni operative di Oracle (chiamate Desktop Procedures, sulle quali torneremo più avanti) ed addestrare gli utenti finali.
o Stabilire un contatto con gli altri utenti chiave dei vari siti Power-One in modo da avviare una proficua collaborazione.
o Dopo il raggiungimento del Go Live fornire il supporto di livello 1 (monitoraggio delle prestazioni del sistema).
Agli utenti chiave è affidato un compito importante, quello di affiancare i consulenti in tutto il progetto, sin dalle fasi iniziali. Questo comporta ovviamente un aggravio del loro carico di lavoro, in quanto oltre al tempo impiegato nel progetto (che nei periodi più intensi, come quelli dei vari CRP, giunge al 70% del tempo totale) devono anche svolgere i compiti legati alla funzione da essi svolta.
Questo aspetto negativo è bilanciato proprio dal fatto che, essendo stati coinvolti fin dalle fasi iniziali, la loro conoscenza di Oracle è sicuramente più approfondita rispetto
agli utenti finali; questo arricchimento delle loro conoscenze aumenta l’importanza degli utenti chiave e li rende figure di riferimento per tutto il personale.
Tornando al Solution Manager & Coordinator vediamo che egli deve coordinare il lavoro di tre distinti team: l’Offshore Team, il Corporate Oracle Team e i Valdarno Onsite Functional Consultants.
L’ Offshore Team è composto da un team di consulenti esterni, operanti fuori sede (e più precisamente dislocati in India), che operano sotto la guida del Solution Manager per offrire un contributo alla risoluzione dei GAP, degli Issue e per effettuare la ripulitura e la migrazione dei dati assicurandone correttezza e consistenza.
Il Corporate Oracle Team è un team di persone appartenenti alla Power-One che possiedono una conoscenza avanzata di uno o più moduli di Oracle, e il cui compito è quello di supportare il team presente sul sito per la risoluzione dei GAP e degli Issue individuati.
I Valdarno Onsite Functional Consultants sono i consulenti responsabili per l’implementazione di Oracle nello stabilimento del Valdarno, ed hanno i seguenti compiti:
o Comprendere sia i requisiti del business dello stabilimento del Valdarno sia le soluzioni già implementate in Power-One.
o Guidare gli utenti chiave in tutte le fasi del progetto. o Applicare le Power-One Best Practise Solutions.
o Trasferire la propria conoscenza del sistema agli utenti chiave.
o Coordinarsi e collaborare con i consulenti non presenti nel sito per impostare in modo completo tutto il sistema ed i processi di Oracle.
o Offrire supporto di livello 1 durante tutto il progetto.
L’intero team di progetto è quindi un gruppo misto da diversi punti di vista. Dal punto di vista dell’appartenenza vi è personale Power-One e consulenti esterni; dal punto di vista della presenza fisica sul luogo dell’implementazione vi è personale presente in loco e personale dislocato in altre aree geografiche (principalmente Stati Uniti e India); dal punto di vista della nazionalità vi è personale italiano, americano e indiano.
Questa eterogeneità e il fatto che molte delle riunioni tra top management, responsabile di progetto e consulenti presenti sul sito dell’implementazione si siano svolte telefonicamente ad orari particolari che tengano conto della differenza di fuso orario non ha certo aiutato il buon esito del progetto.
Vediamo adesso di approfondire la conoscenza del team operante nello stabilimento italiano.
Il Team di Power-One Italy S.p.A.
Prima di parlare del team dobbiamo fare una premessa che riguarda il personale IT dello stabilimento italiano: al momento dell’avvio del progetto la Power-One Italy S.p.A. si trovava sprovvista di responsabile della funzione IT, e le 4 persone facenti parte di questa funzione non avevano alcuna competenza relativa ad Oracle.
A questo si è cercato di porre rimedio con l’assunzione di un responsabile IT con competenze su Oracle, assunzione che si è concretizzata ad Aprile 2007. Facciamo però qui notare come nell’organigramma del team di progetto non sia definito il ruolo del responsabile IT dello stabilimento italiano, relegandolo a mero supporto tecnico del team stesso; abbiamo infatti constatato come il pieno coinvolgimento del responsabile IT sia avvenuto decisamente tardi, al momento dell’esecuzione del CRP 3 (Settembre 2007). Un'altra nota riguarda la composizione del team di consulenti. Esso, al momento del Kick Off del progetto (28 Marzo 2007) era composto unicamente da due consulenti esterni di nazionalità indiana: restavano scoperti tutti i moduli del Finance e una sola persona doveva prendersi carico di un elevato numero di moduli originariamente pensati per l’impiego di due consulenti.
Per i moduli del Finance la soluzione è arrivata ad inizio Aprile 2007 con l’assunzione di una consulente specializzata in questi moduli e con un’ampia conoscenza di Oracle. Purtroppo la ricerca di altri consulenti di lingua italiana da aggiungere al team non ha prodotto risultati, principalmente a causa della scarsità del numero di consulenti presenti sul territorio italiano che da un lato aumentava la difficoltà nel trovare un consulente non impegnato in altri progetti e dall’altro faceva crescere il costo per l’impiego del consulente stesso. Una soluzione di compromesso è stata quella di impiegare, a tempo parziale, un consulente Oracle operante nello stabilimento della Slovacchia.
A complicare ulteriormente il lavoro del team si è aggiunta la questione del visto sui passaporti dei consulenti di nazionalità extracomunitaria: a causa di complicazioni burocratiche vi è stato un avvicendamento tra le persone che ricoprivano tale ruolo, ed ogni volta si è dovuto procedere con lo spiegare al nuovo consulente i processi AS IS e le peculiarità dello stabilimento del Valdarno.
Ovviamente anche il responsabile IT e la consulente del modulo Finance, per quanto con elevate competenze su Oracle, essendo dei neoassunti non avevano alcuna conoscenza dei processi del Valdarno.
Il Valdarno Site Leader è un dipendente Power-One che precedentemente svolgeva il ruolo di coordinatore della pianificazione, e che possiede una elevata conoscenza dei processi AS IS della Power-One non solo in riferimento allo stabilimento italiano, ma anche degli impianti cinese ed ungherese.
Per quanto riguarda il gruppo dei Super Users possiamo vederne la composizione in figura 26, dove sono riportati gli utenti chiave divisi per ciascuna funzione di appartenenza. Come si può vedere gli utenti chiave sono circa un 7% di tutto il personale impiegato nello stabilimento del Valdarno; ricordiamo che è a loro che è demandato il compito di addestrare tutti gli utenti finali.
Un punto interessante riguardo ai Super Users è quello relativo alla conoscenza della lingua inglese, il cui dato è riportato in figura 27. Si tenga presente che dal conteggio sono stati esclusi gli utenti chiave del Finance in quanto il consulente di riferimento è di nazionalità italiana. F u n z io n e N u m e ro d i S u p e r U s e rs S a le s - C u s to m e r S e rv ic e 3 P u rc h a s in g 2 S o u rc in g 1 P ro d u c tio n 5 P la n n in g 2 L o g is tic 4 Q u a lity 4 IT 1 H R 2 F in a n c e 5 R & D 5 T o ta le 3 4
Super Users - conoscenza della lingua inglese
62% 14% 24% Buona Sufficiente Nessuna conoscenza
Figura 26 – I Super Users
(utenti chiave) dello
stabilimento del Valdarno – classificazione per funzione di appartenenza,
Il dato che emerge è che il 25% degli utenti chiave non ha alcuna conoscenza della lingua inglese, e che in totale il 38% degli utenti chiave ha poca o nessuna dimestichezza con tale lingua: si può ben immaginare l’impatto negativo che questo fatto ha sull’intero progetto in cui non solo il sistema e tutta la documentazione sono in lingua inglese, ma anche i consulenti e il top management utilizzano solo questo idioma.
Ne consegue che in ogni occasione in cui sono coinvolti i consulenti e questi utenti, il cui inglese non permette loro di sostenere autonomamente una conversazione, deve intervenire un traduttore con conseguente perdita di tempo e di immediatezza.
5.2.5 Gli strumenti utilizzati per la comunicazione
In qualsiasi progetto, ed ancora di più in quelli di elevata complessità come quello oggetto di questo lavoro, la comunicazione è fondamentale ai fini della riuscita del progetto stesso.
Vi sono documenti da condividere, questionari da compilare, elenchi dei GAP e degli Issue riscontrati, istruzioni per l’utilizzo dei singoli moduli e più in generale tutto il materiale necessario al progetto.
Nell’individuare uno strumento utile a tali fini si deve pensare che il team di progetto, come abbiamo avuto modo di vedere nel paragrafo precedente, è disperso su quasi tutto il globo terrestre tra (andando da oriente verso occidente) Cina, India, Italia e Stati Uniti. Le e-mail possono fornire un supporto alla comunicazione diretta, ed infatti sono state create delle apposite mailing list, una che contiene gli indirizzi di tutti i consulenti ed una con gli indirizzi di tutti i Super Users.
Tuttavia lo strumento principe per tutte le comunicazioni relative al progetto di implementazione di Oracle è lo Share Point Web Site (vedi figura 28 di pagina seguente), ovvero il sito Web che funge (traduzione letterale) da “punto di condivisione”. Si tratta di un sito residente sulla Intranet aziendale a cui può accedere solo il personale coinvolto nel progetto (responsabili, consulenti e Super Users), e che svolge una molteplicità di funzioni:
o Contiene la documentazione di progetto, come ad esempio metodologia, istruzioni operative, piani di programmazione dell’attività del personale, ecc.
o Viene utilizzato per le comunicazioni e gli annunci ufficiali relativi al raggiungimento delle milestones di progetto.
o Contiene gli elenchi dei GAP e degli Issue individuati, costantemente aggiornati con i risultati ottenuti.
o Durante i CRP viene usato per compilare la documentazione relativa agli esiti delle sessioni svolte.
Un ultimo, ma non per importanza, mezzo di comunicazione è la conference call: si tratta fondamentalmente di una riunione a mezzo telefonico, utilizzando lo strumento vivavoce, in cui comunicano membri del team siti in località distanti, come ad esempio le comunicazioni tra il team del Valdarno e il Director of Implementations. In alcuni casi durante queste riunioni si utilizzano anche sistemi di Instant Messaging o di condivisione di file quali Net Meeting.
Figura 28 – Lo “Share Point Web Site” – Schermata principale n cui sono contenuti gli annunci più importanti e i link ai principali documenti di progetto.
5.3 Il progetto di implementazione
5.3.1 Introduzione
Dopo aver visto la metodologia, il team e gli strumenti passiamo adesso al progetto vero e proprio. Il focus del lavoro svolto durante tutto il progetto è stato sulla logistica delle spedizioni; nello stabilimento del Valdarno si incontrano i seguenti tipi principali di spedizioni:
a) Spedizioni di prodotti finiti verso i clienti.
b) Spedizioni di prodotti finiti da riparare dai clienti e spedizioni di prodotti riparati verso i clienti.
c) Spedizioni di materiali (materie prime, semilavorati, prodotti finiti) verso altri stabilimenti Power-One.
d) Spedizioni di materiali (materie prime, semilavorati) a subfornitori per lavorazioni esterne.
e) Spedizioni di materie prime e semilavorati dai fornitori.
I punti trattati in maniera approfondita sono il punto a), coperto da una parte, chiamata Shipping, del modulo di Oracle Order Management (abbreviato OM) e il punto b), trattato nella parte relativa al Return Material (abbreviato RM). Dei punti c) e d) tratteremo brevemente solo per le caratteristiche affini ai moduli summenzionati, mentre il modulo e) esula dallo scopo di questo lavoro.
Nella trattazione faremo riferimento allo svolgimento temporale del progetto come pianificato nella figura 24 di pagina 63. Ignoreremo la fase iniziale di pianificazione (Initiation Phase) per concentrarci subito sulla mappatura dei processi e la GAP Analysis.
5.3.2 CRP0 & CRP1 Test Instance (28 Marzo 2007)
In questa prima fase possiamo trovare da un lato un team di consulenti esterni (con l’aggiunta successiva di una consulente interna assunta nel mese di Aprile) ancora non a pieno organico, con alle spalle una esperienza maturata con diverse implementazioni eseguite per la Power-One, con ovviamente una scarsa conoscenza dei processi peculiari dello stabilimento del Valdarno; dall’altro un gruppo di Super Users con un’elevata conoscenza dei processi ma con nessuna familiarità con il sistema da implementare e con la metodologia da utilizzare, alcuni svantaggiati anche dalla scarsa dimestichezza con la lingua inglese.
5.3.2.1 Mappatura dei processi
Le prime attività, oltre a quelle classiche di “team building”, sono state quelle di mappatura dei processi del Valdarno nella fase chiamata “Requirement Analysis”, fase realizzata per il raggiungimento dei seguenti obiettivi:
o Piena comprensione dei processi AS IS dello stabilimento italiano.
o Confronto tra i processi così individuati e i processi implementati dal sistema. o Documentazione di ogni cambiamento proposto.
o Identificazione dei principali colli di bottiglia dei vari processi. o Creare ed aggiornare la lista dei GAP individuati.
Uno schema generale della metodologia utilizzata in questa fase si può trovare nella figura 29 di pagina seguente; vediamone di descrivere il processo nel suo insieme. Il passo iniziale della metodologia riguarda l’indagine volta a scoprire i requisiti dei vari processi del sito del Valdarno (Review Requirements); tale indagine è stata condotta con dei questionari in inglese contenenti una serie di domande con riferimento alle caratteristiche del processo oggetto di indagine; tali questionari sono stati compilati dai Super Users delle varie funzioni con il supporto dei consulenti.
Vediamo alcune delle domande contenute nel questionario del modulo Order Management:
o Quali tipi di clienti avete (diretti, distributori, ecc.)? o Vendete anche a clienti occasionali (ovvero “one-shot”)? o Vendete anche servizi?
o Quanti prodotti ordinabili avete?
o Quanti dei prodotti ordinabili sono soggetti a tassazione? o Quanti e quali tipi differenti di ordini di vendita avete?
o Effettuate spedizioni internazionali? Se sì, utilizzate uno o più corrieri? o Effettuate consolidamento delle spedizioni?
o Specificate i documenti utilizzati al momento della spedizione. o Avete una procedura per l’autorizzazione dei resi?
Una volta che il questionario è stato correttamente compilato esso è stato firmato dal Super User della funzione interessata ed entra così a far parte della documentazione ufficiale di progetto.
Dal questionario completo del modulo OM relativo allo stabilimento del Valdarno, che non riportiamo per brevità di trattazione, si può evincere come ad alcune domande
l’utente chiave non abbia saputo rispondere in modo compiuto: questo deriva principalmente dal fatto che le domande sono volte alla comprensione dei processi in ottica del loro sviluppo in Oracle, e che al momento della compilazione la conoscenza di tale sistema da parte dei Super Users era praticamente nulla.
Anche se parallelamente al questionario i Super Users hanno provveduto ad illustrare ai consulenti quali sono i processi dello stabilimento del Valdarno non è stata eseguita una vera e propria mappatura dei processi. Se si pensa al turnover di consulenti che si sono avvicendati nello stabilimento italiano si può ben immaginare come la presenza di una mappa completa dei processi AS IS avrebbe sicuramente agevolato il lavoro del team di progetto.
Figura 29 – Metodologia per la mappatura dei processi e la decisione di implementare soluzioni personalizzate..
Tornando alla figura 29 vediamo che il secondo passo della metodologia di indagine consiste nella valutazione dei requisiti come espressi dai Super Users in confronto alle Power-One Global Solutions: abbiamo già detto che il sistema Oracle impiegato dalla Power-One presenta delle personalizzazioni per adeguarlo ai requisiti dell’azienda, si tratta di valutare se i requisiti del Valdarno possono essere soddisfatti con i modelli di processi presenti nel sistema o si deve procedere ad una nuova personalizzazione.
Nel caso in cui la corrispondenza sia positiva si può passare ad implementare e documentare la soluzione, in caso contrario si devono invece sottoporre i requisiti individuati ai Super Users degli altri impianti Power-One.
Se dal nuovo riesame dei requisiti risulta che non vi è bisogno di un nuovo Business Process si passa ad implementare la soluzione standard Power-One, viceversa bisogna valutare se questa nuova soluzione può andare ad impattare sulla pianificazione temporale del progetto o sull’utilizzo di risorse.
Ancora una volta in caso di risposta negativa a questo quesito si può implementare la nuova soluzione, documentandola ed inserendola tra le Global Solutions, mentre in caso di risposta affermativa la questione passa allo Steering Committee, al quale spetta la decisione finale sull’adozione della nuova soluzione.
Come si può vedere quindi l’intera metodologia tende ad un’analisi critica dei requisiti relativi ai processi dello stabilimento del Valdarno cercando di far adottare le Global Solutions Power One, a meno che i requisiti siano tali da richiedere una customizzazione, e anche in quel caso vi sono altri due livelli di controllo prima di dare via libera.
Anche se questo viene fatto per standardizzare i processi in modo da uniformare la linea di condotta di ogni stabilimento Power-One del mondo, si tenga presente che vi deve essere un attento trade-off tra i vantaggi portati dalla standardizzazione e la necessità che il sistema supporti tutti processi di business aziendali: ricordiamo che il fine ultimo dell’implementazione di un sistema ERP è quello di fornire uno strumento di supporto al business aziendale, non quello di implementare del software.
Ritornando all’analisi dei processi AS IS segnaliamo che, per gli scopi di questo lavoro, è stata svolta un’analisi decisamente più completa su tali processi che andremo adesso ad esporre; anche se l’esposizione avviene in questo paragrafo ricordiamo che è invece avvenuta in un arco di tempo più lungo (fino alle soglie del CRP2).
Il processo AS IS di spedizione dei prodotti finiti ai clienti
Il processo AS IS di spedizione dei prodotti finiti è rappresentato in figura 30; si può vedere che esso è composta da una serie di operazioni miste, in parte a sistema e in parte manuali, che adesso andremo ad analizzare.
Lo stabilimento del Valdarno ha un magazzino per lo stoccaggio e la spedizione dei prodotti finiti nel quale lavorano un responsabile e quattro addetti; il responsabile è la figura che pianifica e coordina l’attività del magazzino, eseguendo le operazioni a sistema, mentre agli addetti è assegnato il compito di svolgere le attività operative. Il COPICS ha una serie di report che vengono lanciati e stampati automaticamente con cadenza quotidiana: tra questi vi è anche il report contenente le spedizioni di prodotti finiti pianificate per le settimane successive.
Sulla base di questo report, nel quale troviamo tutti i riferimenti delle spedizioni (cliente, articolo, conferma d’ordine, giacenza in magazzino, data prevista di consegna, ecc.), e delle ulteriori conferme d’ordine che possono giungere dal Customer Service, il responsabile del magazzino pianifica quali spedizioni preparare.
La pianificazione delle spedizioni si basa sulla valutazione di una serie di criteri in modo da ottenere una lista di priorità delle spedizioni; tra i criteri ricordiamo:
o Data di consegna prevista.
o Disponibilità del codice al magazzino.
o Esigenze particolari (ad es. urgenza della spedizione) segnalate dal Customer Service.
o Tipo di corriere utilizzato (alcuni spedizionieri hanno un ritiro quotidiano fisso, altri eseguono il servizio su chiamata; inoltre per alcuni servizi vi è un tempo massimo entro il quale prenotare il ritiro).
La pianificazione eseguita nella prima parte della giornata ha comunque carattere provvisorio in quanto le esigenze sulla quale essa viene realizzata potrebbero cambiare: ad esempio durante la giornata possono arrivare delle comunicazioni da parte del Customer Service, sia via mail che via telefono, per spedire un ordine per il quale il cliente ha richiesto la consegna urgente; oppure vi possono essere degli ordini pianificati per i quali la produzione è in ritardo e quindi si deve bloccare la spedizione; viceversa vi possono anche essere degli ordini per i quali la produzione è in anticipo e si deve procedere all’organizzazione della spedizione.
Una volta impostati gli ordini da spedire si procede alle attività di sistema che prevedono la formazione della spedizione, ovvero l’indicazione di quanti pezzi del codice questione devono essere spediti (figura 31); nell’esempio che viene mostrato troveremo un carico di 480 pezzi del codice 40830113S00 destinato alla Indesit Company.
Dopo aver formato la spedizione si procede al rilascio, ovvero al movimento a COPICS con il quale i prodotti finiti vengono movimentati in uscita dal centro di costo relativo al magazzino prodotti finiti; in questo modo il magazzino viene scaricato, in quantità e in valore, dei codici precedentemente inseriti nella spedizione e si può passare alla fase di emissione della documentazione.
Le ulteriori funzioni del COPICS che vengono utilizzati sono quelle di preparazione della documentazione, ovvero del Documento di Trasporto (DDT) e della fattura, che vengono stampati e preparati per lo smistamento; tutte queste attività vengono svolte dal responsabile.
Una volta che tutte le operazioni a COPICS sono state eseguite entrano in azione gli addetti del magazzino che devono preparare fisicamente la spedizione. Si procede quindi alla preparazione della merce (imballaggio su pallet, reggettatura, ecc.), alla compilazione manuale della documentazione aggiuntiva (lettera di vettura, packing list, istruzioni di trasporto) e allo stoccaggio in un’area temporanea per la successiva consegna allo spedizioniere incaricato del trasporto.
In figura 32 troviamo uno schema riassuntivo nel quale vengono mostrate le principali funzioni del COPICS utilizzate nelle spedizioni.
Si può notare in questo schema che vi sono, oltre alle funzioni già elencate che eseguono le transazioni, delle funzioni di controllo che sono utili sia in fase di pianificazione che in fase di controllo della transazione.
In particolar modo la funzione di controllo giacenza (figura 33) serve per verificare la quantità del codice in questione: si entra in questa funzione con il codice dell’articolo e il sistema risponde con le quantità del prodotto in giacenza presso i vari centri di costo. Nel caso mostrato vi sono 480 pezzi nel magazzino prodotti finiti (2PF) e 3 pezzi in un centro di lavorazione (2LEV04); vengono inoltre mostrate le quantità impegnate (che risultano dagli ordini confermati presenti a sistema) e quelle disponibili (che sono il risultato della differenza tra le quantità impegnate e quelle effettivamente in giacenza al magazzino).
In figura 34 troviamo la seconda funzione di controllo, quella relativa alla lista di movimenti di magazzino.
Figura 33 – Schermata del COPICS per il controllo delle quantità in giacenza di un particolare codice.
Come si può vedere da questa schermata si controlla l’avvenuta transazione del codice in questione (le transazioni di vendita vengono riportate con la sigla IC*); vediamo che in data 22/10/07 è stata eseguita una transazione di 480 pezzi e troviamo il riferimento dell’operatore che ha eseguito la transazione (ALPG), la conferma d’ordine (C0602119) e la fattura di vendita (V0705345).
Riassumiamo quindi le caratteristiche principali del processo AS IS di spedizione di prodotti finiti:
o La pianificazione delle spedizioni avviene principalmente sulla base dell’esperienza del responsabile di magazzino; il report che viene stampato quotidianamente è solo una indicazione, il vero lavoro di schedulazione viene fatto dal responsabile considerando tutta una serie di fattori (ordini aperti, disponibilità del materiale, tipo di corriere utilizzato, ecc.).
o La gestione del magazzino prodotti finiti non segue una logica particolare (ad esempio come il FIFO3), ma anche questa si basa sull’esperienza del responsabile. Questo significa che lo stoccaggio dei materiali, la movimentazione e la spedizione non seguono dei criteri ben definiti se non quelli di buona gestione del magazzino; l’unica eccezione a questo fatto è una parte del magazzino dove vengono conservati i prodotti della I-Illumination e quelli destinati allo stabilimento ungherese, che seguono invece la logica FIFO. Per questi prodotti viene creato un codice a barre che è composto dal codice del prodotto e il lotto di appartenenza e permette, attraverso l’utilizzo di lettori di codici a barre, la gestione di tali articoli rispettando il criterio FIFO.
o La spedizione avviene sulla base del codice del prodotto. La prima operazione a sistema, con la quale si crea la spedizione, avviene inserendo il codice del prodotto; solo dopo aver inserito la quantità da spedire si inserisce la conferma d’ordine. o Tutta la documentazione viene stampata nel magazzino prodotti finiti. Con questo si
intende che la documentazione accompagnatoria dei prodotti è definitiva, e che copia delle fatture stampate viene portata sia al Customer Service che in contabilità.
o DDT e fattura commerciale hanno la stessa numerazione. La numerazione automatica di DDT e fattura viene fatta con un codice alfanumerico in cui la prima lettera rappresenta il tipo di fattura (ad es. V è una fattura di vendita), dopodichè
3
FIFO (First In First Out): logica di gestione di magazzino in cui l’uscita del materiale avviene in base all’ordine di entrata: se per un particolare codice abbiamo a disposizione materiale con data di ingresso in magazzino differente ad uscire per primi sono i prodotti che sono entrati per primi nel magazzino (quelli
viene riportato l’anno ed il numero progressivo (es. V0700458 è la fattura di vendita numero 458 dell’anno 2007).
o In alcuni casi vengono stampati documenti opzionali. Per le spedizioni destinate ad alcuni clienti vengono stampate delle etichette adesive, da applicare a ciascun collo, contenenti le informazioni principali (articolo, numero di pezzi, ordine, ecc.) codificate sotto forma di codice a barre.
o Eventuali spese aggiuntive vengono inserite a livello di conferma d’ordine. Vi sono ad esempio dei casi in cui ai clienti vengono fatturate le spese di trasporto: in questo caso è il Customer Service a inserire nella conferma d’ordine un articolo fittizio (con un codice tipo “000000VARIE”) che corrisponde in realtà alle spese di trasporto. o I dati relativi a peso e volume della spedizione non vengono inseriti a sistema. Tali
informazioni vengono inserite manualmente nel DDT e nella packing list, ma non ve ne è traccia nel sistema. Questo punto è particolarmente critico nel momento in cui si desiderano ottenere i volumi di merce trasportata sulle principali rotte; per poter elaborare queste informazioni in passato si è reso necessario un data entry manuale di tutti i DDT (si parla di migliaia di registrazioni manuali!).
Ritorneremo su quanto sopra esposto nel momento in cui parleremo del processo TO BE per rimarcare le differenze ed i GAP esistenti.
Il processo AS IS di spedizione dei resi ai clienti
Il processo AS IS di spedizione dei resi ai clienti è rappresentato in figura 35 di pagina seguente; analogamente al processo che abbiamo appena analizzato anche questo è composta da una serie di operazioni miste, in parte a sistema ed in parte manuali.
Vediamo una breve panoramica del processo dei resi dai clienti: quando un cliente ha dei prodotti Power-One che devono essere riparati contatta il Customer Service che provvede ad aprire una pratica per l’autorizzazione del reso (in inglese RMA – Return Material Authorization4). Nel momento in cui avviene l’autorizzazione il cliente procede alla spedizione della merce alla Power-One, la merce all’arrivo viene quindi ingressata ed indirizzata ad un apposito centro per l’analisi del guasto; il prodotto, se possibile, viene quindi inviato ad un centro apposito dove viene riparato o rilavorato per la successiva riconsegna al cliente.
4
La riparazione del materiale e la rispedizione al cliente sono gratuite in caso di reso in garanzia, altrimenti tali spese vengono concordate ed addebitate al cliente.
Quando termina la rilavorazione e il prodotto riparato è pronto per la spedizione viene trasferito fisicamente ad una area contigua al magazzino prodotti finiti e a sistema ad un apposito centro di costo (chiamato LRESI); entra qui in gioco il magazzino spedizioni, dove vi è un addetto che è dedicato alla spedizione dei resi.
Per individuare quali resi devono essere spediti l’addetto effettua un controllo incrociato tra il materiale che ha in giacenza al centro di costo dei resi (tramite la funzione COPICS chiamata DPLL5) e le pratiche RMA ancora aperte; può capitare che alcuni resi particolarmente urgenti vengano sollecitati dal Customer Service via mail o via telefonica.
5
Questa funzione è simile a quella che abbiamo precedentemente visto per i prodotti finiti (indicata dall’acronimo DPLG): mentre però la DPLG mostra i centri di costo in cui troviamo un particolare articolo (ad es. l’articolo 40830113S00) la DPLL mostra invece gli articoli presenti in un particolare
Anche in questo caso la parte di pianificazione viene lasciata all’esperienza dell’operatore che organizza il proprio lavoro sulla base sia delle informazioni ottenute dal sistema, della situazione effettiva del materiale presente nell’area resi e delle segnalazioni ricevute dal Customer Service.
Una volta identificata la spedizione da effettuare si utilizzano delle funzioni del sistema per creare l’ordine di reso e per effettuare la spedizione del reso stesso, scaricando così in quantità e in valore il magazzino; diversamente dal caso dei prodotti finiti qui a guidare l’operazione è il numero di pratica RMA e, secondariamente, il codice dell’articolo.
Quando l’operatore ha effettuato a sistema la spedizione utilizza le stesse funzioni viste in precedenza per stampare il DDT e la fattura accompagnatoria, dopodichè si passa alla preparazione fisica della spedizione e al suo stoccaggio nell’area dedicata per la successiva consegna al trasportatore designato. La fattura che viene emessa dipende dal tipo di transazione che avviene con il cliente:
o Se il reso è in garanzia e il cliente, al momento della restituzione, ha fatturato la merce alla Power-One allora al momento della restituzione viene emessa una fattura commerciale per il valore della merce.
o Se il reso è in garanzia e il cliente per la restituzione utilizza una fattura proforma allora al momento della restituzione si emette una fattura proforma.
o Se il reso non è in garanzia viene comunque emessa una fattura commerciale per il valore della riparazione eseguita (come concordato con il cliente stesso); vengono inoltre fatturate anche le spese di trasporto (con il solito codice fittizio visto in precedenza).
Si possono quindi trovare numerose analogie tra questo processo e quello di spedizione dei prodotti finiti, ad eccezione della fase di pianificazione e di preparazione delle spedizioni. Teniamo quindi presente quanto detto perché lo riprenderemo quando parleremo dei processi TO BE.
5.3.2.2 Individuazione dei processi TO BE
La definizione dei processi TO BE, per lo meno per il processo delle spedizioni, è stata inizialmente ripresa dai processi in essere nelle altre Power-One; infatti per illustrare il processo futuro agli operatori italiani sono stati utilizzati gli operatori dello stabilimento slovacco, i quali hanno illustrato la modalità con cui svolgono il loro lavoro con il supporto di Oracle.
Sicuramente questo tipo di scelta può andare bene nella fase introduttiva ed ha il vantaggio di essere una soluzione poco costosa (non si fa ricorso a consulenti esterni), ma presenta degli svantaggi:
o Sono stati illustrati i processi in uso nello stabilimento slovacco e che rispondono quindi a requisiti diversi rispetto a quelli dell’impianto del Valdarno. Vedremo in seguito che le scelte progettuali porteranno all’adozione di soluzioni differenti rispetto a quelle utilizzate nel resto degli stabilimenti Power-One.
o La metodologia di lavoro dello stabilimento slovacco è influenzata anche dal costo della manodopera. Per fare un esempio concreto a parità circa di numero di spedizioni effettuate nel reparto slovacco lavorano sei persone che sono deputate all’esecuzione delle operazioni a sistema, mentre vi sono poi altri operatori di magazzino che eseguono le attività manuali di imballaggio e movimentazione della merce; nello stabilimento italiano, come già visto, vi è un solo operatore che svolge tutte le operazioni a sistema. È ovviamente impensabile, dato il costo della manodopera italiana, poter quadruplicare gli operatori di sistema, per cui si devono trovare soluzioni alternative (principalmente una ridefinizione della modalità di esecuzione del processo).
Inizialmente il focus del progetto è stato sulle spedizioni di prodotti finiti, mentre le spedizioni dei resi sono state analizzate solo in un secondo momento (alle soglie del CRP3); per poter seguire un filo logico entrambi i processi TO BE verranno analizzati nei prossimi paragrafi.
Il processo TO BE di spedizione dei prodotti finiti ai clienti
Il processo TO BE di spedizione dei prodotti finiti è rappresentato in figura 36; come per il processo AS IS vi sono una serie di operazioni a sistema e una serie di operazioni manuali, ma la struttura è profondamente cambiata.
Il passo di partenza è sempre un report che contiene un elenco delle spedizioni che devono essere consegnate nelle settimane successive, ed è su tale report che il responsabile di magazzino si deve basare per pianificare il proprio lavoro.
Come si può vedere dall’esempio di report riportato in figura 37 nel Pull List For Shipment si possono trovare le seguenti informazioni principali:
o Part Number (codice articolo); o Customer Name (nome cliente);
o Ultimate Ship To (destinazione della merce); o Credit Limit (limite di credito del cliente); o Scheduled Date (data pianificata di spedizione); o Order No. (numero d’ordine);
o Line (linea dell’ordine);
o Qty Open (quantità ancora “aperta”, cioè da spedire);
o Qty Available (quantità disponibile, ovvero presente a magazzino e non riservata per altri ordini);
o QOH At Sub-Inventory (quantità del codice presente nel centro di costo relativo al magazzino prodotti finiti);
o Flg Cr (eventuale superamento da parte del cliente del limite di credito). Nel caso in cui questo campo sia marcato con la lettera Y la spedizione non è possibile;
o Pick (se il materiale è gia stato prelevato o meno).
Il report ha una serie di parametri che permettono all’utente di restringere le informazioni mostrate; ad esempio si può selezionare l’intervallo delle date di spedizione (schedulate o richieste dal cliente), se mostrare o meno gli articoli a giacenza zero, se mostrare o meno gli ordini ancora non prenotati (“Booked6”), ecc.
Una volta deciso quale ordine spedire si procede alla prima operazione a sistema, quella di Pick Release (prelievo per il rilascio): con questa funzione Oracle preleva il materiale
6
Affinché il materiale sia spedibile l’ordine deve essere prenotato (“Booked”); in caso contrario, anche se
dal centro di costo (chiamati a sistema Sub-Inventory) e lo trasferisce in un’area virtuale temporanea in attesa della spedizione. Nella figura 38 mostriamo la finestra del sistema con la quale si esegue questa operazione; i parametri da inserire sono:
o Numero di ordine da spedire;
o Data schedulata oppure data pianificata per la spedizione (di solito si utilizza solo una delle due);
o Sub-Inventory dal quale effettuare il rilascio.
Le altre informazioni da inserire sono facoltative e riguardano il Set di documenti da stampare, il tipo di ordine, ecc.;
Eseguendo questa operazione il sistema è impostato per stampare un documento chiamato “Pick Slip” nel quale è contenuto il materiale da prelevare fisicamente a magazzino e da preparare per la spedizione. Inoltre con l’esecuzione di questo passo il sistema crea una “Delivery” (letteralmente una “consegna”) che ha un numero identificativo univoco che viene appuntato sul Pick Slip, e che verrà utilizzato al momento della spedizione. Il Pick Slip deve essere consegnato all’addetto del magazzino che ha il compito di preparare la merce e, soprattutto, pesarla, misurarla ed inserire in modo manuale le informazioni relative a peso e dimensioni sul Pick Slip della spedizione; in questo momento viene preparata anche, sempre in modo manuale, la packing list.
Il Pick Slip così compilato ritorna all’operatore del sistema che procede al passo finale, quello di Shipping (la spedizione vera e propria); in figura 39 è riportata la finestra di questa funzione.
A questo punto l’operatore, utilizzando il motore di ricerca del sistema con il numero di Delivery di quella particolare spedizione, deve procedere ad inserire le seguenti informazioni:
o Numero di pezzi da spedire. La spedizione può essere per l’intera quantità o per quantità parziali, tuttavia quest’ultima opzione deve essere abilitata al momento dell’inserimento dell’ordine (dal Customer Service);
o Peso e volume della spedizione;
o Spedizioniere e servizio (se non impostati di default dal sistema per quel particolare ordine);
o Ulteriori informazioni aggiuntive (come ad esempio, nel caso in cui si usi un corriere espresso, il tracking number della lettera di vettura).
Nel momento in cui viene eseguita la spedizione con l’operazione di Ship Confirm il sistema stampa automaticamente la documentazione necessaria, tra cui fattura accompagnatoria proforma (vedi figura 40 di pagina seguente), documento di trasporto e Packing Slip Bar Coded7.
7
È un report che contiene le principali informazioni sulla spedizione codificate sotto forma di codice a barre; viene stampato per facilitare il cliente il quale può eseguire le operazioni di ricezione della merce
Le ultime due operazioni manuali del processo TO BE sono analoghe a quelle del processo AS IS, e consistono nella compilazione dei documenti aggiuntivi e nello stoccaggio in un’area temporanea per la successiva consegna allo spedizioniere designato.
Vediamo di elencare le caratteristiche del processo TO BE analizzate in riferimento alle caratteristiche del processo AS IS:
a) Il rilascio e la spedizione del materiale non avviene più in base al codice ma in base all’ordine. Mentre prima il responsabile controllava il report e pianificava le spedizioni verificando la disponibilità di un particolare articolo adesso deve invece accertarsi di quali ordini sono spedibili;
b) Nel processo AS IS tutte le operazioni a sistema venivano eseguite in rapida successione, compreso la stampa di tutta la documentazione, e solo dopo venivano eseguite le operazioni manuali. Il processo TO BE come eseguito a sistema è diviso in due parti logiche, la prima è quella di rilascio (Pick Release), la seconda è quella di spedizione (Ship Confirm) vera e propria. Tra queste due fasi si inserisce la preparazione fisica della spedizione, necessaria perché le informazioni su peso e volume possono essere inserite solo al momento dello Ship Confirm e non possono più essere modificate in seguito;
c) La fattura stampata al momento della spedizione non è quella definitiva commerciale, ma solo una fattura accompagnatoria proforma che viene allegata alla Figura 40 – La fattura proforma stampata da Oracle.
merce spedita esclusivamente a fini doganali. La fattura commerciale viene stampata in un secondo momento dal reparto Contabilità;
d) Le spese di spedizione, nel caso in cui queste siano fatturate al cliente, vengono inserite al momento dell’esecuzione dello Ship Confirm, direttamente dall’operatore del magazzino;
e) Le informazioni relative a peso e volume della spedizione vengono inserite, come già detto precedentemente, al momento dell’esecuzione dello Ship Confirm;
f) Il sistema permette di stampare anche documenti opzionali. Se pensiamo al processo AS IS ricordiamo che per le spedizioni destinate ad alcuni clienti vengono stampate delle etichette adesive, da applicare a ciascun collo, contenenti le informazioni principali (articolo, numero di pezzi, ordine, ecc.) codificate sotto forma di codice a barre. Anche Oracle permette di stampare questo tipo di etichette in un forato simile a quello attualmente utilizzato.
Vediamo che i punti principali di differenza sono a) e b), che comportano un cambiamento a livello di pianificazione del processo di spedizione: si tratta di cambiare i criteri di lavoro ma il processo in sé non ne viene stravolto.
Per meglio comprendere quali cambiamenti devono essere apportati basti pensare al seguente caso: attualmente esiste un cliente per il quale la spedizione dei resi avviene come se gli articoli riparati fossero prodotti finiti, ed ogni singolo articolo ha un suo ordine che lo distingue dagli altri. Questo significa che per spedire 50 pezzi del codice riparato abbiamo una fattura che riassume insieme 50 ordine diversi, uno per ciascun pezzo spedito; con il COPICS questa operazione, venendo eseguita sulla base del codice del prodotto, è laboriosa ma fattibile.
Se invece pensiamo di effettuare la stessa operazione con Oracle la faccenda si complica perché, come abbiamo appena detto, il sistema spedisce per ordine e non per articolo, per cui dovremmo rilasciare e spedire 50 ordini con conseguente notevole incremento del tempo necessario ad eseguire tale operazione.
La soluzione può essere quella di ridiscutere l’accordo con il cliente trovando un compromesso tra i requisiti del cliente, che portano a dover individuare univocamente il singolo pezzo, e quelli interni Power-One, che rendono altamente inefficiente spedire considerando un ordine per ogni singolo pezzo.
Per quanto riguarda invece i punti successivi, da c) ad f), sono in realtà degli aggiustamenti che riguardano particolari secondari, e che hanno un impatto minore sul processo di spedizione.
- 9 3 -F ig u ra 4 1 – I l p ro ce ss o T O B E d i s p ed iz io n e d i r es i ( ai c lie n ti, a i f o rn ito ri, e cc .) .
Il processo TO BE di spedizione di resi ai clienti
Il processo TO BE di spedizione dei prodotti finiti è rappresentato in figura 41 di pagina precedente. A differenza delle rappresentazioni grafiche dei processi fin qui mostrate, realizzate sulla base del lavoro svolto dallo scrivente, questa proviene direttamente dalle procedure Power-One utilizzate nei restanti stabilimenti del gruppo.
La figura è complicata perché racchiude l’intero processo di riparazione e reso del materiale e contiene le operazioni eseguite dalla totalità degli attori coinvolti; ai fini del presente lavoro vediamo solo la parte che riguarda la spedizione del materiale una volta che questo è stato riparato con successo.
Il processo di spedizione dei resi può essere diviso tra due parti, il processo a sistema e le operazioni manuali.
Per quanto riguarda il processo a sistema la spedizione del materiale, con conseguente scarico a quantità e valore del magazzino, avviene automaticamente con il chiudersi delle operazioni di riparazione: entro 30 minuti (impostazione di sistema) dal momento in cui si chiude la riparazione del prodotto il sistema procede in modo automatico all’esecuzione delle operazioni di Pick Release e di Ship Confirm.
Per quanto riguarda invece il processo manuale i prodotti riparati verranno fisicamente trasferiti al magazzino spedizioni; sarà compito di un operatore del magazzino preparare fisicamente la spedizione e stampare la documentazione necessaria.
Come si può intuire se si pensa al processo AS IS questo nuova modalità di esecuzione è fondamentalmente diversa, e stravolge completamente il modo di operare; per una analisi dei GAP riscontrati rimandiamo al paragrafo successivo.
5.3.2.3 I GAP tra i processi TO BE e i processi AS IS
Dopo avere analizzato il processo AS IS e quello TO BE sono stati individuati i seguenti GAP; seguendo la logica dei paragrafi precedenti li abbiamo divisi tra le due tipologie di spedizione fin qui analizzate. In questo paragrafo ci limiteremo ad elencare i GAP, mentre le soluzioni individuate ed (eventualmente) testate saranno descritte nei singoli CRP.
