Scelta del sistema ERP

Una volta che è stato evidenziato il bisogno di un nuovo sistema informativo o, di sostituzione di quello presente, il prossimo passo è rappresentato dalla scelta del sistema ERP più adatto. Questo processo può essere sintetizzato in otto punti39:

1. Analisi as is dei processi interni ed esterni all’azienda ed analisi will be con una visione migliorativa dei processi.

2. Formalizzazione dell’analisi nel documento di progetto definito RFP (request for proposal), da consegnare ai potenziali fornitori del software ERP.

3. Scelta del partner sulla base di un’analisi delle risposte alla RFP, condotta attraverso lo strumento denominato “matrice delle alternative).

4. Definizione del team di progetto, con definizione dei ruoli e responsabilità 5. Gestione della formazione interna e test intermedi sui moduli della

soluzione

6. Attività di configurazione, sviluppo e rilascio della soluzione

7. Conclusione del progetto e programmazione delle attività di manutenzione 8. Miglioramento continuo dei processi attraverso la mappatura del sistema e

suoi eventuali aggiornamenti.

Nella nostra analisi, ci concentreremo sui primi tre punti.

Analisi as is e will be

Come abbiamo già detto in precedenza, l’introduzione di una nuova tecnologia, che ha un impatto sulla struttura organizzativa, necessita dell’analisi dei processi, ciò diventa ancora più importante quando l’elemento tecnologico è una soluzione IT. Infatti, soprattutto nel caso dell’introduzione di un nuovo sistema informativo, l’impatto sui processi è vigoroso e non può essere sottovalutato dal management aziendale. Per capire quanto detto possiamo considerare l’azienda come un organismo che si muove grazie alla sua “linfa vitale”, rappresentata dai dati e dalle informazioni. Come in ogni organismo vivente il flusso informativo deve fluire a una velocità adeguata, rispettando i tempi di ogni attività e i sincronismi fra esse, evitando azioni ripetute, originando output con la massima qualità possibile. I processi sono le “funzioni vitali” dell’organismo azienda, da essi si generano costi, qualità, efficienze e inefficienze, in sintesi le performance aziendali. Inoltre sono la base operativa su cui si fonda la strategia aziendale. Ecco perché l’analisi e la modellazione dei processi, attraverso la mappa organizzativa, è fondamentale per capire l’impatto che il nuovo sistema informativo può avere sui processi già esistenti. Dato per pacifico che l’implementazione software totalmente personalizzata, cioè sulla base dei processi aziendali esistenti, non è la migliore soluzione, sia da un punto di vista strettamente economico, sia dal punto di vista organizzativo, perché le soluzioni offerte dai fornitori sono definite sulla base di best practice che possono portare a un miglioramento della struttura organizzativa, l’azienda deve determinare l’aderenza dei suoi processi rispetto ai cambiamenti che la nuova soluzione software impone, e capire come questi permettano all’azienda di raggiungere la situazione will be desiderata, sostanzialmente come la soluzione può aiutare l’impresa a raggiungere gli obbiettivi che si è preposta. Possiamo parlare anche

di distanza tra l’organizzazione as is dell’azienda e quella che si rende necessaria per gestire la soluzione software offerta dal vendor. Approssimativamente si può affermare che la soluzione è vincente se complessivamente l’azienda è stata in grado di diminuire il cumulative lead time (il tempo che intercorre tra l’ordine del cliente e la sua disponibilità fisica) che caratterizzava la situazione as is. Introduciamo ora un processo logico di analisi, supponiamo di voler analizzare un processo qualsiasi. Come prima cosa dobbiamo intervistare le persone direttamente interessate nel processo e poi osservare come effettivamente sono svolte le attività, dopo di che, si procede alla rappresentazione di quanto appreso attraverso la mappatura dei processi, nel caso di studio utilizzeremo il BPMN. Per la costruzione della mappa è consigliabile l’utilizzo di swimlanes, in modo da evidenziare chiaramente gli attori coinvolti, i vari uffici e il flusso delle attività. La mappa permette di evidenziare immediatamente eventuali inefficienze, come la ridondanza di alcune attività. Dopo di che si associano alla mappa i tempi, creando la “mappa dei tempi”40, i tempi si possono ottenere dall’intervista, usando lo strumento della matrice attività/addetto, lo strumento risulta molto utile per comprendere l’utilizzo delle risorse rispetto ad ogni attività assegnata a un determinato ruolo. Come vedremo, nelle righe della matrice sono elencate tutte le attività che compongono un determinato processo, o a un livello di aggregazione più alto, i processi che compongono un macro processo, nelle colonne invece i ruoli o il nominativo di ogni addetto. Nel punto di intersezione è evidenziato il tempo che una determinata attività impegna una determinata risorsa. Per determinare il tempo che ogni addetto impiega per svolgere una particola attività, si utilizza lo strumento dell’intervista, chiedendo all’addetto il tempo che impiega a svolgere ognuna delle attività nella quale è impiegato. Se l’addetto dovesse avere delle difficoltà a fornire un’informazione precisa, si può allargare l’intervallo temporale di analisi e utilizzare le percentuali, ad esempio, “in percentuale, quanto tempo impiega settimanalmente nello svolgimento di quest’attività?”.

Addetto a Addetto b Addetto c Addetto d Addetto e Totale

Attività 1 % T 1 % T 1 % T2

Attività 2 % T 2 % T8 % T10

Attività 3 …

Totale 100% 100% 100% 100% 100% 100%

Fig. 7 Esempio matrice attività/addetto

Nel caso di studio si è deciso di fondere in un'unica matrice la matrice attività/addetto e un'altra tipologia di matrice, la “matrice RACI” o matrice di assegnazione delle responsabilità. Questa variante di matrice ci consente di determinare quale sia il carico di responsabilità e il numero di attività assegnate a un singolo ruolo.

Questo strumento di analisi offre un altro vantaggio molto importante, ossia la possibilità di non utilizzare più metodi arbitrari per la determinazione dell’assorbimento dei costi di struttura da parte delle produzioni. In sostanza lo strumento introduce l’azienda verso un nuovo metodo di attribuzione dei costi, l’Activity Based Costing, infatti, la matrice attività/addetto in qualche modo consente di analizzare i costi generali di produzione, permettendo di associare ai prodotti tali costi utilizzando una base più oggettiva, ossia il consumo di risorse da parte di ogni attività.

La decisione di approfondire l’analisi dei processi con questo strumento pare ancora più giustificata se si analizzano gli effetti collaterali, l’analisi attraverso la matrice attività/addetto consente all’azienda di approfondire la conoscenza sulla propria organizzazione permettendo l’evidenziazione sia dei difetti da correggere sia di caratteristiche operative o organizzative irrinunciabili. La loro evidenziazione è necessaria soprattutto in fase di implementazione di un nuovo sistema informativo, il fornitore del sistema informatico sarà infatti in grado di dire se, in base a queste caratteristiche, sia possibile personalizzare il nuovo sistema, a quali costi, con quali tempi e il grado di aderenza tra l’attuale struttura organizzativa e dei processi con la soluzione software da lui offerta.

“Request for proposal”

Il documento Request For Proposal41, è un documento scritto che serve a rappresentare l’organizzazione dell’azienda ai software vendor di soluzioni software, scelti come possibili partner fornitori. Lo scopo del RFP è di verificare se le soluzioni offerte dai vendor hanno un livello di aderenza adeguato rispetto ai processi interni descritti nel documento. Gli elementi più importanti che ogni RFP dovrebbe contenere sono:

• Clausole di riservatezza; l’azienda fornisce al software vendor la reppresentazione dei propri processi interni ed esterni, è quindi opportuno stipulare un accordo secondo il quale queste informazioni siano gestite solo dal personale tecnico del vendor.

• Termini temporali; per dare validità al RFP è necessario definire una data entro la quale i vendor devono rispondere.

• Descrizione dei processi; oltre alla descrizione dei processi secondo i metodi descritti in precedenza è consigliato introdurre tabelle che per ogni attività definiscano il suo livello di criticità, aiuterà il vendor ha definire quali attività a maggiore criticità il software è in grado di coprire nella versione standard e quali invece sono le attività per cui è richiesta una personalizzazione.

• Costi stimati del progetto; sia in termini di licenze dei software, sia in termini del progetto nel suo complesso, considerando soprattutto le eventuali personalizzazioni. Questo punto è necessario per capire immediatamente se le personalizzazioni richieste sono accettabili per il

software vendor.

• Garanzia di aggiornamento della soluzione; in caso di personalizzazioni il tema è complesso. Infatti, nel caso di personalizzazioni di particolari funzioni, potrebbero non consentire il rilascio dei successivi aggiornamenti. E’ quindi necessario avere garanzia dal vendor a riguardo.

41 _{per approfondimenti sulla definizione della Request For Proposal vedere B. Stefanutti (2012),}

• Costi di manutenzione, durata della garanzia e degli aggiornamenti.

La definizione di un RFP ottimale è molto complessa, ma molto importante. In alcune occasioni può essere necessario l’aiuto di personale esterno per la stesura. E’ tuttavia evidente che la specificazione soprattutto dei processi aziendali e le sue unicità sono indispensabili per un efficace gap analisys, in modo da non porre l’azienda nella situazione di percepire solo a lavori iniziati eventuali cambiamenti alla soluzione software standard, innescando una serie di pericolose e costose attività di adeguamento.

Passiamo ora all’introduzione dello strumento per il confronto delle risposte inviate dai software vendor al RFP. I criteri su cui fondare la scelta sono molti e con pesi differenti, infatti, pur essendo il prezzo una delle piu importanti dimensioni, non deve essere l’unica. Per esempio, la soluzione più economica non è detto che sia quella con la maggiore aderenza ai processi e magari nemmeno la più performante dal punto di vista tecnologico.

Occorre quindi stilare una vera e propria classifica che aiuti il processo di selezione del software vendor. Al riguardo la “matrice delle alternative”42, è un semplice strumento, ma che fornisce risposte adeguate. La matrice è composta dalle righe nelle quali sono elencati le dimensioni ritenute rilevanti e il peso assegnato, nelle colonne troviamo le soluzioni proposte, nell’intersezione invece il voto che si assegna a ogni soluzione. Appare evidente l’importanza del peso assegnato a ogni dimensione, che dovrebbe tenere di conto del maggior numero possibile d’istanze. E’ evidente che il prezzo ha, solitamente, il peso maggiore, tuttavia se si considera l’investimento nel sistema informativo come un investimento strategico, si deve dare un peso sempre maggiore a dimensioni strategiche, per esempio si può considerare la condizione societaria dei fornitori che prende in esame la stabilità finanziaria del vendor, perché il partner tecnologico deve essere scelto in conformità a un’ottica che lo vede come asset strategico.

42 _{per approfondire l’utilizzo della matrice della alternative si veda B. Stefanutti (2012), 134-}

Matrice delle alternative Soluzione 1 Soluzione 2

Dimensioni di analisi Peso

Costo 20% 4 0,8 4 0,8

Aderenza ai processi 30% 3 0,6 5 1,5

Costi Hardware 10% 2 0,2 2 0,2

Tempi di realizzo 5% 5 0,25 4 0,2

Diffusione di mercato 5% 2 0,1 2 0,1

Supporto post vendita 20% 4 0,8 4 0,8

Condizione finanziaria fornit.

10% 3 0,3 4 0,5

Score 100% 3,05 3,6

Fig. 8 Matrice delle alternative

Esistono anche altri elementi che possono spostare il giudizio tra un fornitore e un altro che però non riguardano dimensioni inserite nel RFP. Per esempio, il

feeling che esiste tra l’azienda e un particolare fornitore dovuto a relazioni

passate, la “sensazione di positività” che un particolare vendor è in grado di trasmettere, la squadra di tecnici con la quale il vendor si presenta all’incontro che può dare un senso di sicurezza maggiore, oppure il feeling con la grafica del software offerto. Tutti questi elementi possono influenzare notevolmente la scelta, tuttavia si deve cercare di mantenere la RFP libera da queste influenze e permettere a questo strumento di misurare i vendor sui parametri ritenuti oggettivi. Se poi il confronto porta alla scelta tra due vendor e il voto sulle dimensioni della RFP da “risultato pari”, si può decidere di introdurre anche altre dimensioni di tipo “emotivo”.

Analizziamo ora quelli che generalmente sono definiti come dimensioni utili per l’uso della matrice delle alternative. E’ evidente come il peso che l’azienda decide di assegnare a ogni dimensione è molto discrezionale, ogni settore e ogni azienda, presentano, per appunto, delle caratteristiche uniche che possono variare

il peso di ogni dimensione. Nel seguito proveremo a dare solo delle indicazioni di massima del peso che le dimensioni più rilevanti dovrebbero avere:

• Costo del software; E’ una delle dimensioni piu rilevanti. Riesce a quantificare in modo immediato la soluzione e solitamente è quella più osservata dal decisore. Solitamente il peso che va assegnato oscilla tra il 20% e 30%. Si deve anche analizzare se il vendor offre agevolazioni finanziarie, come i tempi di pagamento ed eventuali agevolazioni provenienti da bandi comunitari o nazionali, o nel caso italiano, regionali. • Aderenza ai processi aziendali; l’altra dimensione molto importane è

l’aderenza hai processi aziendali della soluzione software. E’ opportuno assegnare a questa voce un peso maggiore rispetto al costo, che oscilla tra il 20% e il 30%. Infatti, a un costo basso può essere associata una scarsa aderenza hai processi, questo porterebbe a personalizzazioni post implementazione che, come abbiamo in precedenza spiegato, portano a problemi vari e costi elevati, tanto che la soluzione potrebbe non essere più conveniente dal punto di vista economico.

• Impegno interno; con questa dimensione si fa riferimento all’impegno che l’organizzazione del cliente deve impiegare per l’implementazione e il successivo utilizzo del software. Si devono valutare aspetti quali la migrazione dei dati dal vecchio al nuovo sistema informativo, oppure le sessioni di apprendimento necessarie per utilizzare il software che potrebbe evidenziare un’eccessiva complessità della soluzione. Un altro aspetto che potrebbe essere non considerato è l’integrazione tra i moduli offerti, per esempio può accadere che il software vendor integri un modulo appartenente ad un altro software vendor più specializzato, in questo caso deve essere ben valutato il livello di integrazione tra i moduli soprattutto nel caso di aggiornamenti dei singoli moduli.

• Metodologia di sviluppo del progetto; per metodologia di sviluppo di progetto si intende il metodo con il quale intende il vendor intende

procedere per l’implementazione del nuovo software. Introdurremo due metodologie di progetto43:

-­‐ Big bang approach; La metodologia prevede che l’intera azienda percorra un percorso di preparazione alla nuova soluzione software. L’azienda dovrà preparare il contesto organizzativo che dovrà gestirla, soprattutto il personale attraverso corsi di formazione e prove propedeutiche di utilizzo. In sostanza l’azienda si deve preparare ad utilizzare integralmente il software prima che questo entri in funzione, perché per la data che si deciderà di “attivarlo”, il sistema informativo entrerà in funzione contemporaneamente in tutti i processi aziendali. Questo approccio presenta vantaggi come, la rapidità di svolgimento, della non necessità di implementare strutture tecnologiche per passare al nuovo sistema informatico che verranno poi dismesse, dismissione rapida del vecchio sistema informatico, maggiore economicità, teorica, rispetto al phased approach. Gli svantaggi sono, l’elevata possibilità che si verifichino malfunzionamenti e la necessità di predisporre molte attività preliminari prima di attivare la nuova soluzione software. -­‐ Phased approach; Consiste nello scomporre l’implementazione in più

fasi in relazione a come sono integrati, dal punto di vista dei dati, i processi aziendali. In sostanza si associa ogni fase dell’integrazione a ogni processo, affidando la gestione del processo al nuovo sistema e gli altri al vecchio sistema. Può essere definita un’integrazione incrementale, la gradualità del passaggio è resa disponibile grazie alla creazione di interfacce tecnologiche che non rappresentano altro che un ponte dati tra il vecchio e il nuovo sistema. Una volta poi, che si passa ad un altro processo, queste interfacce vengono soppresse, senza la possibilità di utilizzarle per altri scopi. Quest’approccio senz’altro

43

per approfondimenti vedere anche E.J.Umble, R.R. Haft, M.M. Umble, Enterprise resource planning: Implementation procedures and critical success factors, European Journal of Operational Research, Vol. 146, 2003, pagg. 241–257

più complesso sia dal punto di vista tecnologico che organizzativo può trovare giustificazione in organizzazioni molto complesse e articolate. I suoi difetti sono che come abbiamo appena detto è un metodo molto complesso e dispendioso e può essere utilizzato solo a fronte di una reale complessità aziendale, inoltre le interfacce tecnologiche costruite per la migrazione dei dati tra i due sistemi non sono più riutilizzabili. Tra gli aspetti positivi possiede il fatto di garantire una maggiore serenità nel passaggio tra i sistemi e una diluizione nel tempo della formazione del personale.

La scelta fra l’uno e l’altro metodo non può essere definita a priori, dipende, infatti, dal contesto nel quale il project management si trova a dover scegliere tra i due metodi.

• Referenze; Probabilmente è una delle prime domande che viene rivolta al

vendor, quale sia la diffusione nel mercato di riferimento della soluzione

software offerta. Conoscere, infatti, quali sono i feedback provenienti dal mercato, può rappresentare un utile fonte di giudizio se opportunatamente valutata. Infatti si deve considerare che, qualora nel settore in cui opera l’impresa non vi sia un’ampia diffusione del software offerto, non deve rappresentare un aspetto negativo. Infatti molti dei processi aziendali (gestione del magazzino, pianificazione MRP, gestione ordini fornitori, ecc.) sono molto simili tra i vari settori. Per cui un vendor potrebbe facilmente apprendere le peculiarità del settore in cui opera il cliente per offrire una soluzione comunque competitiva.

• Caratteristiche societarie del fornitore; Questa dimensione è rilevante non riguarda strettamente la software selection, ma la gestione futura del sistema informativo. Questa dimensione ha un carattere puramente strategico. Infatti, la scelta del vendor non può trascurare la tecnologia con la quale il software è sviluppato, se per esempio questa è obsoleta, oppure che non prevede funzioni che riteniamo siano centrali per il futuro, si pensi alla predisposizione dei software di anni fa di sfruttare il web. Si può anche

considerare la stabilità finanziaria ed economica del vendor, infatti, come farebbe l’azienda ha continuare ad utilizzare il software di un’azienda fallita?

Concludendo, l’implementazione del sistema informativo presenta molte insidie, che non sono solo di ordine tecnologico ma soprattutto organizzativo. Affinche la soluzione scelta aderisca efficacemente hai processi aziendali, è necessario che il partner scelto per la soluzione software conosca molto bene i processi aziendali e tutte le sue peculiarità, di tutta la supply chain dal ricevimento delle materie prime fino alla consegna finale del prodotto finito. L’azienda deve essere in grado di raccontare se stessa, i sui processi, il flusso organizzativo e l’ottica strategica al mondo esterno, senza trascurare alcun aspetto positivo o negativo esso sia. Ed è proprio attraverso il documento formale RFP, con il quale l’azienda condivide la propria organizzazione con i possibili partner fornitori. Successivamente, con la matrice delle alternative l’azienda sarà in grado di confrontare le soluzioni software offerte dai potenziali partner, ponderando tutte le dimensioni attraverso le quali valutare ogni singola offerta

III

Il caso Zac s.r.l.

Lo studio condotto su Zac s.r.l., dopo averne brevemente descritta la storia, si focalizza sull’analisi dei processi aziendali operativi. E’ opportuno sottolineare la centralità dell’analisi dei processi e la loro successiva mappatura attraverso il linguaggio di modellazione BPMN, perché, nella lettura che seguirà, potrebbe apparire come elemento marginale rispetto agli altri strumenti utilizzati. In realtà, rappresenta il perno centrale dello studio che abbiamo condotto, il quale si è poi arricchito con ulteriori strumenti al fine di poter giungere ad un giudizio critico sugli attuali processi aziendali operativi.

In principio, l’intenzione era di attuare un benchmarking competitivo al fine di confrontare i processi operativi con quelli dei migliori competitor del settore. Tuttavia, vista la forte rivalità interna, tale alternativa non è stata giudicata percorribile. La seconda possibilità era di ricorrere a consulenti esterni, tuttavia anche in questo caso la direzione di Zac s.r.l. ha ritenuto tale possibilità troppo costosa. La soluzione proposta e accettata dalla direzione è stata invece quella di valutare i processi aziendali operativi in base alla loro capacità di garantire il mantenimento e il miglioramento di quei fattori ritenuti critici per il successo competitivo. A tale scopo abbiamo determinato la formula imprenditoriale, al fine di valutare la coerenza della stessa, e la coerenza della stessa in relazione ad un investimento in soluzioni IT. Per arricchire l’analisi, abbiamo brevemente esaminato le scelte organizzative adottate dalla direzione poiché è risaltata la centralità della risorsa umana quale detentore delle principali capacità necessarie