La Fase di Implementazione

L’efficacia ed il successo connessi all’Implementazione di una applicativo di natura ERP2, ma più in generale per una qualsiasi soluzione software informativa, risentono fortemente del tipo di strategia che un’Organizzazione adotta nella conduzione di tale fase. Tipicamente la scelta implementativa è ricade su uno tra i seguenti indirizzi alternativi:

• Big Bang Strategy; • Phased Strategy.

La decisione in merito alla tipologia di Strategia, attraverso la quale veicolare la messa in atto del sistema, risente principalmente di fattori quali la dimensione e complessità strutturale dell’organizzazione, la presenza di vincoli temporali ed economici, la sussistenza di rapporti di collaborazione operativa e partnership con enti esterni.

Nelle successive sezioni del paragrafo verranno introdotti i lineamenti e le principali caratteristiche che caratterizzano le due Strategia polivalenti.

Big Bang Implementation Strategy

Una strategia di implementazione di tipo Big Bang, come può suggerire la stessa dicitura, guida una Fase Implementativa massiva e caratterizzata da un elevato livello di complessità. Si configura infatti come un’introduzione di un applicativo software estesa simultaneamente a tutte le entità interessate, che si tratti di Aree Funzionali appartenenti alla medesima organizzazione che ad una pluralità di realtà aziendali che costituiscono un Corporate Group10_.

Come precedentemente riportato, la strategia gioca su un livello di rischio estremamente elevato che prevede nel caso di successo o fallimento, rispettivamente significativi benefici che criticità.

Tra i primi, i principali si configurano con:

• Efficienza Economica: un’implementazione massiva e simultanea richiede un sacrificio economico e finanziario concentrato in una sola volta. Sebbene tale investimento iniziale risulti maggiore, se rapportato a quello sostenuto per attuare una strategia Phased, nel medio-lungo periodo la totalità dei costi supportati per quest’ultima supera l’investimento iniziale di sostentamento di una strategia di tipo Big Bang11_.

• Efficienza Temporale: come per il punto precedente, anche in tale caso, si registra una riduzione nel tempo totale di implementazione, convergente verso un singolo Go Live, dovuta all’aggregazione e alla simultanea attuazione del progetto a tutte aree di interesse.

• Efficienza di Problem Solving e Manutenzione: la strategia Big Bang tipicamente non adotta l’utilizzo di una pluralità di soluzioni, ma punta il focus sull’introduzione e strutturazione dell’architettura informativa attraverso un singolo sistema. Pertanto, tutte le attività di upgrade e update di versione, di Manutenzione e Risoluzione Problemi sono più facilmente gestibili in quanto concentrati una tantum.

10 _{E’ opportuno sottolineare che il contesto applicativo di tale strategia non si estende mai fino a toccare la}

Corporate stessa, ma si arresta fino al livello delle entità ad essa collegate o controllate. Di fatto l’Implementazione Big Bang apportata ad una Capogruppo apporterebbe un livello di rischio non sostenibile.

11 _{La supposizione risulta significativa qualora venga preso a riferimento il medesimo contesto applicativo,}

• Efficienza di Integrazione: ricollegandosi all’assunzione del punto precedente, la presenza di un unico sistema richiede lo shut down dei preesistenti sistemi legacy. Conseguentemente non sarà necessario un’integrazione tra le due diverse soluzioni.

Tra gli svantaggi che caratterizzano la strategia implementativa Big Bang si segnalano principalmente:

• Perdita di Dettaglio: fisiologicamente un’implementazione aggregata su più entità indirizza il focus organizzativo ad un livello generale ed aggregato, senza soffermarsi su aspetti ed istanze situati ad un livello maggiormente raffinato.

• Riduzione del tempo di Training: laddove il Training ricada come un’attività da condurre durante la fase implementativa, una minore durata di questa comporta di conseguenza una riduzione delle tempistiche dedicate all’attività di formazione ed addestramento degli utenti.

Inoltre, in riferimento al punto precedente, il livello eccessivamente aggregato con cui si considera il progetto potrebbe comportare attività di Training troppo generalizzate che potrebbero concretizzarsi in un insufficiente grado formativo trasmesso agli utenti.

• Effetto Waterfall: sottintende che l’impatto legato alla manifestazione di problematiche durante l’implementazione in una specifica area interessata, si ripercuoterebbe immediatamente su tutte le istanze ed entità ad essa appartenenti. • Committment Organizzativo: è un aspetto di estrema rilevanza e che necessita di non

essere trascurato. Dato l’elevato grado complessità apportato della strategia Big Bang risulta vitale per il successo del progetto, che l’Organizzazione presenti un appropriato grado di impegno nei riguardi di esso. Di contro può risultare che il livello di committment richiesto per il completamento delle attività sia troppo elevato rispetto alle possibilità organizzative portando di fatto il progetto verso una sua deriva.

Phased Implementation Strategy

La Strategia di Implementanzione Phased si articola attraverso una destrutturazione del contesto applicativo del progetto. Nello specifico si tratta di una tipologia di introduzione software apportata secondo una metodologia incrementale, che non prevede una reingegnerizzazione massiva e contemporanea a tutte le istanze interessate e che opta per

una partizione del rischio su più progetti, distinti sia temporalmente che in merito al rispettivo campo applicativo.

Proprio come per la precedente, anche la Phased Implementation presenta notevoli vantaggi e criticità che altro non sono che la trasposizione dei rispettivi svantaggi e benefici della Big Bang Implementation.

In precedenza, nella sezione introduttiva, erano stati enunciati i principali fattori che concorrono nella scelta della strategia di implementazione operata da un’Organizzazione. In particolare, si vuole porre l’attenzione su quello inerente alla presenza o meno di soggetti esterni all’interno della progettualità.

Generalmente un client, nell’attuare la messa a punto di un applicativo software informativo può affidarsi a dei consulenti terzi, specializzati in tale ambito.

Esistono approcci multipli che un’Organizzazione può scegliere, in merito all’utilizzo di consulenti per sviluppare un progetto di natura ERP2/EPM, differenziati a seconda della natura dell’Implementazione. Questi possono essere raccolti nelle sottostanti categorie principali:

• Balanced Approach; • Turnkey Approach;

• Customer-Driven Approach; • “A la Carte” Approach.

Nelle successive sezioni verrà fornita una rappresentazione generale esplicativa dei punti appena sopra riportati.

Balanced Approach

L’ approccio Balanced si basa sulla piena cooperazione tra i Project Team del cliente e quello consulenziale. La collaborazione e gli sforzi richiesti durante l’implementazione vengono interamente condivisi e sostenuti dai due team durante tutta la durata della Fase e su tutti gli aspetti ed i contesti applicativi del progetto.

L’aspetto di principale criticità connesso all’approccio Balanced non coinvolge variabili tecnico-strutturali, ma al contrario risiede all’interno di soft characteristics, coincidenti con le capacità e competenze possedute dal client Team. E’ intuibile che un’efficiente cooperazione tra due soggetti necessiti della presenza, su entrambi i fronti, di adeguate conoscenze, le quali integrandosi sinergicamente apportano valore aggiunto al progetto.

Qualora si presentasse una sostanziale asimmetria tra le skills dei due Team, in particolare si riscontrasse una carenza da parte del client Team, gli effetti si ripercuoterebbero sul livello qualitativo delle Attività, provocando ad una dilatazione dei tempi e, di conseguenza, dei costi di progetto legati al risanamento di tale carenza.

Turnkey Approach

L’approccio Turnkey si denota per un elevato coefficiente di utilizzo di figure consulenziali nell’implementazione del sistema informativo. Pertanto viene massimizzato l’utilizzo di risorse professionali esterne, riducendo al contempo quello di risorse interne.

Un tale approccio viene intrapreso di fronte alla presenza di forti vincoli temporali, i quali richiedono di minimizzare i tempi di implementazione del progetto. A tale vantaggio si contrappongono tuttavia anche fattori negativi di rischio, tra i quali l’incremento dei costi sostenuti per l’utilizzo di figure esterne, i quali non vengono bilanciati dalla riduzione di quelli a supporto delle risorse interne. Inoltre un ulteriore elemento di criticità di natura prettamente strategico-direzionale è la perdita di potere decisionale, da parte del client, in merito alle scelte di progetto, che di fatto passa sotto la stretta gestione dei soli consulenti. Infine l’ultimo tra i principali svantaggi dell’approccio Turnkey risiede nell’insufficienza, o addirittura nella mancanza, di acquisizione di conoscenze e competenze in materia di Project Management da parte delle risorse dell’Organizzazione.

Customer-Driven Approach

L’ approccio Customer-Driven si contrappone all’approccio Turnkey delineandosi come una scelta volta a minimizzare il ricorso a figure esterne per l’implementazione del progetto. L’Organizzazione client concentra pertanto gli sforzi all’interno della propria struttura, valorizzando al massimo livello le proprie risorse. L’approccio segnala importanti benefici, tra cui i principali si percepiscono attraverso un incremento di abilità e competenze di Project Management da parte dei soggetti interni e la riduzione del costo del progetto, stabilito dalla sommatoria della quota parte legata alla componente esterna e quella legata alla componente interna12.

Di contro a tali benefici l’organizzazione potrebbe tuttavia occorrere nel rischio di congelamento del progetto, un aspetto molto ricorrente nell’approccio Customer-Driven che

12 _{La riduzione del costo, da intendersi come spesa in risorse per l’Implementazione, si registra in rapporto}

evidenzia una possibile paralisi del progetto. In concreto, è possibile che il livello di reingegnerizzazione apportato da esso sia eccessivamente basso e che immobilizzi l’Organizzazione, confinandola all’interno della propria condizione As Is.

“A la Carte” Approach

L’approccio “A la Carte” sottintende la scelta del client di gestire totalmente l’intero progetto, ricorrendo all’utilizzo di consulenti esterni solamente a fronte di situazioni straordinarie. L’approccio riporta principalmente i medesimi benefici e potenziali criticità del Customer-Driven, amplificandone gli impatti in entrambi casi.

Strategia Implementativa di KPMG

KPMG S.p.A. ha curato lo Sviluppo e l’Implementazione del Budget Planning Tool mediante l’adozione di una strategia Phased di natura prototipale che ha favorito una graduale messa a punto della soluzione. Tale scelta risulta maggiormente in linea con i principi della metodologia Agile che il network di consulenza utilizza nella gestione delle proprie istanze progettuali. L’implementazione ha interessato la Business Unit Finanziaria di diverse entità Paese, estendendosi a seguito del primo Roll Out, ai restanti Uffici Nazionali.

A orientare la decisione inerente la Strategia e l’Approccio adottati durante la fase di Implementazione è stata una preliminare Analisi dei processi impattati che ha permesso di stabilirne l’effettivo livello di reingegnerizzazione da apportare attraverso le funzionalità del Budget Planning Tool.

Nei paragrafi seguenti sono riportate le Macro-Attività che hanno contrassegnato la presente Fase, e nonché le decisioni principali intraprese per ognuna di esse.

2.2.6.1 Assesment

La prima Fase condotta all’interno del contesto di Implentazione del Budget Planning Tool si è identificata con l’Assesment, step caratteristico per le progettualità di carattere software informativo e che presenta come obiettivo principale la mappatura dell’attuale stato in cui risiede l’organizzazione intenta ad intraprendere un investimento incrementale della propria architettura informativa. A partire dalla definizione dei requisiti di Business che il cliente esprime, si intraprende un percorso di Analisi inizializzato mediante la conduzione delle seguenti attività:

• Revisione e Definizione delle esigenze di Business; • Valutazione sul corrente stato dei processi;

• Verifica in merito allo stato corrente del sistema corrente e Valutazione dei futuri punti integrativi.

In relazione alla corrente fase, la metodologia intrapresa da KPMG S.p.A ha incentrato il proprio effort sulla Rilevazione, Comprensione e Documentazione degli attuali processi e funzionalità di sistema che il progetto avrebbe impattato, al fine di poter valutare in modo trasparente come poter perseguire il soddisfacimento delle esigenze espresse dall’Agenzia. Al termine della fase di Assesment è stata predisposta l’idonea reportistica che avrebbe guidato i Team progettuali nella conduzione delle successive attività di Implementazione costituenti il Project Plan. In particolare i formati documentali in questione si sono identificati coni seguenti prospetti informativi:

• Business Requirements Document;

• Technical and architectural Requirements for system installation and settings; • Data and reporting requirements;

• Organizational requirements,

Nella successiva sezione l’enfasi sarà posta sull’attività di Definizione ed Analisi dei Requisiti funzionali condotta durante l’Assesment di progetto.

Definizione ed Analisi dei Requisiti Funzionali

Un progetto, indistintamente dalla relativa tipologia e portata, necessita imprescindibilmente, a monte della sua attuazione, di una dettagliata Fase di Definizione dei Requisiti. L’analisi deve compiersi seguendo una logica adeguatamente strutturata che parta dalle esigenze di natura strategica ed arrivi fino al dispiegamento di esso sui livelli maggiormente tecnici ed operativi.

La stesura dei Requisiti espressi dal client, come di sopra riportato, è un’attività caratterizzante la fase di Assessment e presenta significativa valenza nella finale riuscita del progetto.

Proiettando il focus sul Progetto di Implementazione del Budget Planning Tool, una volta avviata la fase di Implementazione i due Team hanno incentrato la conduzione delle attività utilizzando come linea guida il Business/Technical requirements Document. Il documento

riporta al proprio interno la fedele rappresentazione delle richieste esplicitate dall’Agenzia nella fase di Scelta e Selezione dell’applicativo software, tradotte e contestualizzate attraverso le apposite funzionalità di Sistema. In sintesi, identifica la risposta funzionale del sistema alle esigenze espresse dal client.

La presente sezione intende pertanto fornire una rappresentazione maggiormente aggregata, predisposta con l’ausilio della Tabella 2, del prospetto Documentale e di quelli che si sono configurati come i Requisiti dell’applicativo, il cui livello di fit con le richieste dell’Agenzia ha giocato il ruolo decisivo nella scelta della soluzione.

Requisiti Business

Generali Requisito di Sistema Generale

Facilitare e velocizzare l’attività di inserimento dati per un gran numero di utenti.

Lo strumento deve presentare moduli e funzionalità che riducano l’attività manuale di inserimento e manipolazione dei dati da parte degli utenti. Inoltre laddove venga richiesto il diretto coinvolgimento degli utenti nell’inserimento dei dati il sistema deve essere strutturato secondo regole che minimizzino la possibilità di commettere errori. A tal proposito il BPT deve prevedere un elevato livello di somiglianza funzionale con Microsoft Excel, il precedente software di inserimento dati utilizzato dagli utenti.

Pianificare

simultaneamente ai diversi livelli gerarchici (Ufficio Nazionale, Ufficio Regionale, Quartier Generale)

Lo strumento deve assicurare scalabilità ed efficacia prestazionale, in quanto una pianificazione simultanea su più livelli comporta un consistente incremento della mole dei dati.

Incrementare il livello di sicurezza e la protezione dei dati

Lo strumento deve presentare la funzionalità di rilascio di autorizzazione sui dati basata sui ruoli organizzativi.

Garantire la propria integrazione con il sistema ERP in uso, con altri sistemi Legacy sviluppati internamente dalle funzioni IT e con la piattaforma Microsoft Office.

Lo strumento deve permettere lo scambio dei dati tra i diversi sistemi informativi presenti all’interno dell’organizzazione senza che questi vengano modificati, persi o danneggiati.

Migliorare il processo di creazione, analisi e gestione della

Reportistica.

Lo strumento deve fornire funzionalità di reporting completo e la possibilità di trasferire e recuperare i dati dagli strumenti di reporting generati. Il processo di pianificazione necessita di simulazioni basate su analisi multidimensionali che richiedono una documentazione strutturata che possa supportarle idoneamente.

2.2.6.2 Design Funzionale

L'obiettivo primario del Design Funzionale è quello di delineare e progettare i tratti To Be identificativi della nuova struttura informativa. La presente fase, si articola attraverso la conduzione di workshop concernenti studi di fattibilità ed Analisi Fit-Gap. La nuova architettura del sistema viene delineata, progettata e tracciata mediante la redazione di conforme documentazione di riepilogo dell'analisi funzionale, al fine di colmare i gap individuati.

La sezione corrente intende fornire una descrizione della fase di progettazione del BPT posizionando il proprio focus sull’aspetto funzionale e, nello specifico, su come le funzionalità richieste siano state designate e l’impattato di queste sulle attività costituenti il processo di Budgeting e Pianificazione Finanziaria dell’Agenzia. La Progettazione, da sottintendersi come la modellazione della soluzione sulle specifiche istanze di processo appartenenti all’Agenzia, è stata delineata su due distinti livelli, di seguito riportati e descritti:

1. Progettazione di Alto Livello: insieme di fasi concernenti lo sviluppo e la configurazione della soluzione EPM, attraverso limitate istanze di processo, strutturata al fine di consentire agli utenti una validazione immediata dello strumento. Il feedback rilasciato dall’Agenzia è stato raccolto e analizzato dal team di KPMG S.p.A ed è stato successivamente utilizzato come input per il secondo livello progettuale.

2. Progettazione Dettagliata: insieme di fasi inerenti lo Sviluppo e la Configurazione della soluzione EPM in tutti i suoi livelli di dettaglio. Una volta terminata la fase di Design la soluzione è stata nuovamente sottoposta ad un’attività di validazione da parte degli utenti che ha condotto all’approvazione finale da parte di UNC.

2.2.6.2.1 Overview dei Processi

In questo primo paragrafo, al fine di fornire una descrizione quanto più completa, si riportano i processi identificativi della Funzione Finanziaria di UNC, mentre nel successivo soltanto quelli condotti all’interno da ogni Ufficio Nazionale in relazione ad una precisa Unità Budget e Programmazione (UPB), in quanto quelli con cui il sottoscritto ha interagito durante il suo tirocinio formativo.

Un’Unità Budget e Programmazione, identificabile con l’acronimo UPB, si identifica come un’Area Funzionale, all’interno di un Ufficio Nazionale, contraddistinta da un

rispettivo Portfolio di attività di Budgeting e Pianificazione. All’interno di un Paese possono pertanto sussistere differenti UPB contraddistinte per la tipologia di attività finanziarie che devono essere condotte.

Il Budget Planning Tool ha supportato l’Agenzia nella Pianificazione Finanziaria, identificata dai due seguenti Macro-Processi, la cui aggregazione porta alla costituzione del Piano di Gestione Finanziaria Complessivo.

• Pianificazione basata sulle Esigenze - PBE: processo di pianificazione direzionato dai fabbisogni e delle esigenze espressi dai beneficiari, il quale è attuato e sottomesso a fronte di una previa stima della futura disponibilità di risorse finanziarie. Quest’ultime coincidono con i contributi apportati dai vari stakeholder.

• Pianificazione basata sulle Risorse - PBR: è il processo di pianificazione effettiva delle risorse, il quale a partire dal processo PBE allinea le esigenze con le fonti finanziarie, effettivamente percepite, dall’Agenzia.

Adoperando una scomposizione di primo livello dei due Macro-Processi sopra elencati si riportano i sotto-processi configurati da UNC per il proprio Modello di Business:

• Pianificazione delle Esigenze - Draft;

• Pianificazione delle Esigenze - in Approvazione; • Pianificazione delle Esigenze - Approvata; • Pianificazione delle Risorse - Draft; • Pianificazione delle Risorse - Approvata.

La dicitura “Draft”, “in Approvazione”, “Approvata”, va ad identificare la versione in cui si trova la Pianificazione, che altro non è che lo stato che ne stabilisce la rispettiva collocazione all’interno della Gerarchia Organizzativa.

Come si può facilmente intuire, l’autorità e la competenza di un Ufficio Nazionale non può includere al suo interno anche le attività di definitiva approvazione dei due Piani, la quale sarà attuata prima dal competente Ufficio Regionale e infine, in modo definitivo, dalla Sede Centrale.

Una volta che entrambi i piani finanziari completano con successo le fasi autorizzative, il risultante Piano di Gestione Finanziaria Complessivo viene presentato al Comitato Esecutivo dell’Agenzia.

2.2.6.2.2 Processi

In questo paragrafo si intende porre la lente di focalizzazione sull’attività di Budgeting e Pianificazione finanziaria competente al livello di Ufficio Nazionale.

Pertanto i processi che vengono analizzati risultano solamente una componente dell’insieme totale riportato precedentemente e si identificano con quelli di:

• Pianificazione delle Esigenze - Draft;

• Pianificazione delle Esigenze - in Approvazione; • Pianificazione delle Risorse - Draft.

Antecedentemente all’introduzione del Budget Planning Tool, e come riscontrabile in Figura 9, le unità di Budget e Programmazione, proprie di ogni Ufficio Nazionale, gestivano le attività di Pianificazione seguendo una modalità di conduzione delle operazioni di tipo off line e manuale, attuata attraverso Microsoft Excel.

Figura 9 AS IS Budget and Planning data processing.

A fronte della definizione degli obiettivi progettuali connessi all’implementazione del Budget Planning Tool, lo scenario futuro, come riportato in Figura 10, delineava un’architettura informativa di sistema totalmente integrata nell’attuazione e gestione dei processi di Budgeting e Pianificazione finanziaria.

Figura 10 TO BE Budget and Planning data processing.

I processi vengono gestiti con piena responsabilità da ciascun Ufficio Nazionale, il quale decide in merito le tempistiche di avviamento e completamento; in alternativa solo