PERCHÉ UN SISTEMA ERP? un ERP.pdf · un ERP tanto da un punto di vista dei sistemi quanto da...

GUGLIELMO LAGUARDIA

PERCHÉ UN SISTEMA ERP?

Come si colloca il sistema in azienda, gli impatti dovuti al cambiamento, l’approccio al progetto di implemen-tazione.

1

GUGLIELMO LAGUARDIA

PERCHÉ UN SISTEMA ERP?

Come si colloca il sistema in azienda, gli impatti dovuti al cambiamento, l’approccio al progetto di implemen-tazione.

2

Prodotto da

http://xoomer.virgilio.it/sito_della_pace

2003

Opera completamente gratuita e liberamente distribuibile

3

http://xoomer.virgilio.it/sito_della_pace

Indice

1. Premessa 8

2. Con l’ERP arriva il cambiamento? Che cosa cambia? 11

3. L’Azienda per processi? 16 1. Cosa sono i processi? 17 2. Cos’è il modello dei processi? 18 3. Che senso assumono i modelli di Anthony e Simon? 21

4. Quali i vincoli ed i benefici dell’integrazione? 25 1. Cos’è l’integrazione aziendale? 26 2. Come interpretare l’integrazione di processo? 35 3. Perché l’integrazione di sistema? 36

5. Come interpreta un ERP l’integrazione? 41

6. Ma come si posiziona un ERP in azienda? Come si approccia? 45

7. Come scegliere l’approccio? 51

8. Che cos’è allora un ERP? 54 1. L’ambiente Office 56 2. L’ambiente degli strumenti di supporto 56 3. L’ambiente di riferimento del sistema 57 4. Le Aree Applicative 58 5. La personalizzazione del sistema 60

4

9. Ma è proprio necessario fare un progetto? 62

10. Come è fatto un progetto per un ERP? 65

11. Ma serve anche una metodologia? 71

12. In cosa consiste il processo realizzativo? 73 1. Il prestudio – è chiaro come si intende procedere? 75 2. La fattibilità – siamo sicuri di raggiungere gli obiettivi attesi?78

2.1. As is & to be – la situazione attuale è come quella desiderata? 82 2.2. As is & to be – come gestire il gap? 83 2.3. Il modello del sistema - occorre definire degli scenari intermedi? 86 2.4. Quali sono gli impatti di cambiamento? 88 2.5. Come lo costruiamo il sistema? 92 2.6. Conviene continuare nella realizzazione del progetto? 98

3. Il prototipo – costruiamo il sistema? 101 3.1. Di che cosa è costituito il prototipo? 103 3.2. Cosa sono gli scenari? A cosa servono? 105

4. Estensioni, interfacce, conversioni e documentazione: che senso hanno? 110

4.1. Le estensioni – in cosa consistono? 110 4.2. Le interfacce – bisogna proprio farle? Che cosa comportano? 112 4.3. Le conversioni – quale approccio? 115 4.4. La documentazione – che cosa documentare? 118

5. System test – Che cosa? Chi? Perché? 124 5.1. Un approccio ed un piano? 125 5.2. Il Test d’Integrazione? 126 5.3. Il test utente? 127

6. Il supporto tecnologico – A che serve? 128 6.1. Come lo percepiscono gli utenti? 129 6.2. Che cos’è il landscape? 132 6.3. Quali strumenti gestire? 133 6.4. Anche l’architettura d’interfaccia? 134 6.5. E le stampe? 136

7. Formazione – Cosa fare? 138 7.1. Chi addestrare? – Il censimento della popolazione target 139 7.2. Come? – Applicazione dell’approccio definito 142 7.3. Su che cosa addestrare? – Il disegno dei corsi 144

5

7.4. Chi sarà addestrato su che cosa? 144 7.5. Quali strumenti usare nei corsi? – I materiali didattici 146 7.6. Quando erogare i corsi? – La pianificazione 147 7.7. Chi farà che cosa col nuovo sistema? – Le autorizzazioni ed i profili149 7.8. Bisogna comunicare? Che cosa? A chi? 150

8. Avvio – Dopo tante fatiche … era ora! 155 8.1. Prima dell’avvio 156 8.2. Durante l’Avvio 159 8.3. Dopo l’Avvio 163 8.4. E dopo che succede? 165

13. Ma chi ha già fatto un progetto ERP cosa ha imparato? 167

Vocabolario ERPESE 169

6

A Michele e Francesco perché comprendano che le cose, generalmente, non accadono per caso ma sono piuttosto il risultato del nostro impegno e del nostro lavo-ro quotidiano.

7

1. Premessa Vorrei innanzi tutto ringraziare quanti, con il loro contributo, hanno per-

messo la pubblicazione di questo lavoro considerando che rappresenta in qualche modo la sintesi dell’esperienza da me vissuta in circa venticinque anni di attività svolta sui progetti informatici e di cui otto con i sistemi ERP.

Sollecitato da richieste di colleghi e volendo contribuire a fornire qualche elemento di riferimento per chi già opera o si accinge ad affrontare progetti di questo tipo, ho realizzato questo lavoro pensando a “cosa sarebbe utile sa-pere”, nell’intraprendere un progetto basato su questo prodotto, anche con riferimento a quello che un’azienda dovrebbe fare per accogliere al meglio un ERP tanto da un punto di vista dei sistemi quanto da quello dell’organizzazione e d’eventuale revisione dei suoi processi produttivi e di supporto.

Ovviamente lungi da me l’idea d’essere esaustivo o di fornire “il vademe-cum del buon progettista IT” o “il manuale dell’utente furbo”; qui si è tentato di tracciare un percorso, partendo dal punto di vista del fornitore dei servizi di consulenza (con i limiti che ciò comporta), pensando a tutti gli attori del processo realizzativo, alle loro preoccupazioni ed ai loro obiettivi che posso-no a volte divergere. Questo lavoro non costituisce un approccio metodolo-gico o il risultato di uno studio accademico: molto più semplicemente è l’annotazione d’osservazioni che nascono dalla pratica di tutti i giorni o, se volete, il racconto d’esperienze reali di cui in genere si avverte tanto il biso-gno se non altro per avere un utile confronto. Vita vissuta sui progetti, a con-tatto diretto con il cliente, i fornitori ed i colleghi, nella consapevolezza di voler contribuire a fornire un semplice riferimento in cui, tutti gli attori coin-volti da un approccio progettuale, possano ritrovare un minimo comune de-nominatore.

8

Articolazione del lavoro

Come si può già evincere dall’indice, il lavoro è stato articolato pensando di dover rispondere ai classici dubbi che si generano soprattutto in casa di chi vuol adottare un ERP. Ritengo siano gli interrogativi che possono nascere in ogni organizzazione, benché da punti di vista differenti, considerando di tro-varsi di fronte ad un oggetto sconosciuto, un po’ misterioso ed abbastanza “grande”; che ai primi approcci risulta sempre ostico e sterminato ma che si presenta bene e richiede un minimo di familiarizzazione per essere apprezza-to appieno. Ma non temete! Tutti passano per queste sensazioni: utenti e spe-cialisti accomunati dallo stesso sentire soprattutto agli esordi con i primi cor-si e con la nuova terminologia (appunto l’erpese nuovo dialetto del gergo informatico). Ho pensato quindi che bisognasse introdurre il lettore “per pas-si successivi”: dargli prima un quadro di riferimento generale (motivazioni al cambiamento) in cui probabilmente si troverà ad operare, approfondendo poi il valore dell’integrazione da più punti di vista per giungere infine alle speci-ficità del prodotto ERP che qui viene descritto in termini molto generali evi-denziando alcune delle sue peculiarità ed i più evidenti punti di debolezza (per la verità molto pochi). Si è proseguito cercando di definire i paletti fon-damentali di un approccio progettuale che tracciasse un’indicazione sulle possibilità di arrivare all’installazione del prodotto consci dei rischi connessi all’accettabilità ed all’utilizzabilità del sistema stesso. L’approccio proget-tuale a un ERP è solo una possibilità realizzativa consigliata a quanti voglia-no raggiungere, in modo controllato, il risultato atteso tanto in termini di tempi che di costi. Quello che qui viene proposto è semplicemente un riferi-mento “logico” che va applicato nella realtà con gli strumenti e le modalità più consone all’ambiente in cui si intende introdurre il prodotto o in funzione di metodi e consuetudini in uso nelle singole organizzazioni. Ovviamente questo lavoro non costituisce un approccio universale e sicuramente non è l’unico possibile; tale tipo di approccio, infatti, è probabile che sia appropria-to tanto per medio–grandi organizzazioni che per piccole società per le quali, pur assumendo valido il senso della definizione e del controllo delle attivi-tà/obiettivi o dell’impegno richiesto all’organizzazione cliente, tuttavia può essere significativamente diverso in termini realizzativi (metodologia di im-plementazione) e di modalità di raggiungimento degli obiettivi (comunica-zione, cambiamento, ritorni economici ecc.).

9

Confido nella benevolenza dei lettori consapevole di aver prodotto sem-plicemente un diario di esperienze vissute sui progetti ERP; mi auguro, con questo, di fornire loro un piccolo contributo tanto nel capire “cosa c’è dietro le quinte”, quanto nel tentare di impostare quelli che mi sembra siano i “pa-letti fondamentali” del ciclo di vita del processo realizzativo di un progetto ERP. In attesa di avere vostri feed-back auguro a tutti una buona lettura.

[email protected]

Marzo 2003

10

mailto:[email protected]

2. Con l’ERP arriva il cambiamento? Che cosa cambia?

Tra le motivazioni che hanno sostenuto la diffusione dei sistemi ERP ne-

gli ultimi 3–4 anni troviamo certamente la necessità d’adeguare il sistema informativo aziendale alle esigenze di revisione indotte dall’avvento dell’anno 2000 e, almeno in Europa, dall’introduzione dell’Euro come mone-ta di conto e di transazione commerciale. Ovviamente a questi motivi si ag-giunge sicuramente l’antieconomicità di rifacimento di quei sistemi realizzati negli anni ’70 e ’80 che, in termini di ciclo di vita, risultavano superati – per tecnologia ed architettura applicativa – ed i cui costi di manutenzione ed e-sercizio ne sconsigliavano la revisione; probabilmente il quadro si completa sufficientemente considerando anche l’accresciuta maturità degli utenti che in termini di richieste, hanno spinto la domanda sempre più verso soluzioni integrate ed a cui i sistemi ERP hanno fornito una risposta adeguata.

A tali necessità le società di consulenza hanno generalmente risposto con due diversi modi d’approcciare il progetto ERP:

1. fornendo consulenza specialistica sul prodotto (generalmente body–

rental) e demandando al cliente la responsabilità del raggiungimento complessivo degli obiettivi di progetto (questo è stato tipico soprattutto nei primi approcci ad un sistema ERP);

2. proponendo soluzioni “chiavi–in–mano” e condividendo, seppure par-zialmente (nella maggior parte dei casi solo da un punto di vista della rea-lizzazione del sistema), gli obiettivi del rinnovamento che richiedevano oltre al rifacimento dei sistemi anche revisioni di processi, formazione a nuove professionalità e ristrutturazioni organizzative.

11

In molti casi, infatti, l’introduzione di un sistema ERP in azienda è stata l’occasione per rivedere assetti organizzativi, processi e procedure di lavoro e, non ultimi, le modalità e gli strumenti di controllo del business che gene-ralmente hanno richiesto un salto qualitativo nella cultura, nei valori e nei comportamenti delle persone. Questo ci induce a ritenere che in termini di approccio progettuale, lo scenario realizzativo di un sistema ERP non può prescindere da quanto viene rivisto in termini di processi e procedure azien-dali ma, al contrario (vedremo bene perché), i due aspetti del cambiamento si condizionano vicendevolmente essendo il sistema a supporto delle attività aziendali e queste ultime ispirate dalle possibilità funzionali del sistema (quindi in ottica di opportunità) e della sua architettura profondamente inte-grata. Infatti, un fattore determinante – che si deve sempre tenere presente nell’approccio ad un ERP – è sicuramente costituito dalla sua maggiore pe-culiarità: l’integrazione. “Croce e delizia” delle necessità informative socie-tarie, l’integrazione coinvolge tutta l’organizzazione dell’azienda; la pervade in ogni recesso, le richiede di superare le classiche barriere interfunzionali e la costringe a ripensare il “modo italiano” (solo per usare un luogo comune sulla nostra capacità di adattamento) di fare le cose. Non è più consigliata la pratica dell’“arrangiarsi” per reperire o fornire delle informazioni ma tutti gli attori aziendali, devono essere consapevoli di:

come si sviluppa il processo; chi fa che cosa, come, quando e perché; quali flussi informativi attraversano i processi; chi genera e chi utilizza le informazioni; chi è “il proprietario” dei dati e quindi il responsabile della loro correttez-

za. In ultima analisi possiamo considerare che all’interno di un programma di

cambiamento, l’ERP è solo una componente; per alcuni è da considerarsi un “abilitatore” e, comunque, non è da ritenersi l’elemento dominante o esausti-vo. Infatti l’aspetto realizzativo del nuovo sistema informatico, costituisce uno dei primi tasselli dell’intero mosaico considerando che:

1. con la fase di realizzazione ci si prepara a sostenere il cambiamento po-

nendo le basi per il suo sviluppo; 2. ci si “attrezza” per avviare il processo e si individuano tutti gli elementi

da tenere sotto controllo quando la “macchina sarà a regime” (per esem-

12

pio in termini di misuratori di performance, di piani di diffusione e co-municazione ecc.).

Successivamente è necessario promuovere e monitorare le componenti

determinanti del cambiamento (nuova cultura, comportamenti, grado di coinvolgimento delle persone, nuove modalità di gestione e controllo ecc.) comprendendo anche la parte sistemica in quanto caratterizzata da un proprio ciclo di vita.

È fondamentale considerare che il processo di cambiamento non è mai un processo statico; evolve nel tempo, in funzione degli obiettivi di strategia a-ziendale, ed ingloba in se il sistema informatico che è da ritenersi a supporto delle necessità (divenendo a volte anche opportunità) di business e quindi soggetto anch’esso alle modifiche di assetto richieste dal cambiamento.

L’esperienza ha insegnato che generalmente sono quattro le dimensioni del cambiamento indotte dall’introduzione di un ERP (fig. 1).

Processi

Organizzazione

Risorse Umane

ERP

Sistema

13

Fig. 1 – Impatti del cambiamento

Ed ognuna di esse ha impatto sull’altra e ne è in qualche modo a sua volta

influenzata. In altre parole la gestione del cambiamento, più in generale, è finalizzata

al conseguimento dei benefici attesi dall’azienda agendo anche sulle compo-nenti esterne alla realizzazione del sistema informatico (procedure, strutture organizzative, formazione risorse umane); gestisce la preparazione e l’attuazione del piano necessario a facilitare l’accettazione del nuovo conte-sto, ad assicurare l’assimilazione e l’utilizzo tanto del sistema quanto delle nuove modalità operative ed infine ad apportare variazioni coerenti alle re-sponsabilità, alle posizioni ed alle strutture organizzative coinvolte dal pro-cesso stesso di cambiamento. Da questo si comprende bene come l’aspetto realizzativo del nuovo sistema informatico sia solo un particolare del quadro d’insieme e che sebbene esso stesso adduca impatti di cambiamento, questi devono essere recepiti ed armonizzati nell’ambito di un piano più generale con traguardi e finalità di più ampio respiro e che consideri un periodo tem-porale di attuazione di più lungo termine.

Se, ad esempio, considerassimo gli obiettivi di cambiamento all’interno di una iniziativa progettuale (tipica di un’area funzionale) e supponessimo una situazione analoga alla seguente:

Obiettivi dell’area funzionale: XYZ

1. Riorganizzazione di tutte le strutture organizzative della funzione e loro

integrazione con le altre funzioni aziendali. 2. Ridefinizione dei ruoli e delle procedure di area. 3. Confronto tra i metodi di lavoro applicati dai diversi stabilimenti produt-

tivi e ricerca delle soluzioni ottimali. 4. Riduzione dei costi interni della funzione. 5. Univocità dei dati e delle informazioni prodotte per tutta l’azienda. 6. Disponibilità immediata delle informazioni per tutte le strutture azienda-

li. Potremmo subito individuare quali degli obiettivi definiti hanno impatto

sul sistema informatico (o da esso sono in qualche modo condizionati) e qua-li, al contrario, devono essere raggiunti con strumenti e modalità diversi. Ti-

14

picamente gli obiettivi 5. e 6. sono quelli immediatamente riconducibili all’ado–zione di un sistema informatico mentre, come si può intuire, gli altri obiettivi, anche se in qualche modo condizionati dalle logiche e dalle funzio-ni di sistema, necessitano tuttavia di approcci e strumenti ad hoc per il loro conseguimento. In particolare la fig. 2 fornisce una visione d’insieme delle correlazioni sistema/obiettivi.

6. Disponibilità immediata delle informazioni per tutte le strutture aziendali

Il sistema è completato, documentato ed il materiale di training è disponibile per l’addestramento

4. Riduzione dei costi interni della Funzione5. Univocità dei dati e delle informazioni prodotte per tutta l’azienda

Gli utenti sono formati ed addestrati all’utilizzo del nuovo strumento. La struttura conosce e condivide ilvalore ed i benefici del nuovo sistema.

La struttura organizzativa ed i processi sono ripensati ed adeguati alle nuove regole ed alle nuove logiche.

1. Riorganizzazione di tutte le strutture organizzative della funzione e lorointegrazione con le altre funzioni aziendali

2. Ridefinizione dei ruoli e delle procedure di Area3. Confronto tra I metodi di lavoro applicati dai diversi stabilimenti e ricerca

delle soluzioni ottimali

SistemaRealizzato

SistemaUtilizzato

Area Funzionale Efficiente

Fig. 2 – Relazione sistema/obiettivi Da cui è evidente che il conseguimento complessivo degli obiettivi di a-

rea viene raggiunto intervenendo a più livelli ed ottenendo risultati intermedi che, nel loro insieme, soddisfano le esigenze di cambiamento attese (fig. 3).

SistemaRealizzato

Sistema Utilizzato

Funzioneefficiente

ObiettiviRaggiunti

Fig. 3 – Raggiungimento degli obiettivi

15

D’altro canto anche i ruoli degli attori sono generalmente diversi: dal suo lato il fornitore di competenze ERP (anche se dipende molto dalle capacità possedute e dagli obiettivi di core business della società di consulenza), più in generale, si preoccupa di realizzare il sistema, di fornire l’addestramento agli utenti, di avviare il sistema in esercizio e di manutenerlo nel tempo; l’azienda cliente, invece, garantisce la coerenza del sistema con tutte le altre iniziative in ambito aziendale, gestisce la condivisione dei fattori di successo ed il presidio delle azioni conseguenti, controlla il raggiungimento comples-sivo degli obiettivi del cambiamento e si assume l’onere di svolgere quel ruolo di più ampio respiro che segue l’implementazione del sistema ancorato nel tempo alla evoluzione strategica dell’impresa.

3. L’Azienda per processi? La prima volta che parlai del sistema azienda in termini di modello dei

processi era il lontano luglio 1989 e mi accorsi che in quell’aula gremita all’inverosimile, non tutto l’uditorio capiva il significato di quelle parole e che, soprattutto, non riusciva a ricondurre tale concetto alla pratica di tutti i giorni. Ed infatti la chiave di volta della comprensione era proprio tutta lì, a portata di mano del “volgo”, ed io pensai, a torto o a ragione, che la colpa era tutta mia che non riuscivo ad esprimermi in modo adeguato. Trascorse qual-che tempo e mi vennero in mente le affermazioni di Luciano De Crescenzo quando sosteneva che si poteva spiegare concetti filosofici anche con parole molto semplici a tutto beneficio dell’efficacia dei discorsi e della loro com-prensione. Il lettore quindi mi scuserà se ripercorro brevemente tali concetti traducendo in soldoni (la pratica di tutti i giorni infatti) concetti che solo in

16

apparenza sembrano distanti e comunque alla portata dei soliti “consulenti acculturati alla maniera anglosassone” (si riporta in questi termini, per con-venienza ed educazione, la traduzione di una più assonante e colorita espres-sione dialettale siciliana). D’altro canto il tempo mi ha dato ragione: le suc-cessive presentazioni, soprattutto quelle di un sistema ERP, hanno beneficia-to di tale chiarezza nel senso che si sono dimostrate più efficaci quando la gente poteva “toccare con mano” quello che gli si proponeva: i concetti a-stratti erano calati nella loro realtà di tutti i giorni.

1. Cosa sono i processi? Premesso questo e senza cercare una definizione “accademica” del termi-

ne, possiamo dire che un processo altro non è che l’insieme più o meno complesso delle attività che qualcuno svolge per ottenere un qualsiasi obiet-tivo. Ogni giorno vado in ufficio o in fabbrica e svolgo il mio lavoro: faccio delle cose per me, per il mio capo, il collega del mio ufficio o per il collega di qualche altro ufficio oppure per un cliente o per un fornitore. In altre paro-le:

svolgo delle attività; le cose che faccio servono a qualcosa (hanno un obiettivo); che quanto da me svolto è utile/atteso da/per un altro; che alcune cose posso farle solo dopo aver ricevuto il risultato (o obietti-

vo) delle attività di qualcun altro; che sappia quello che devo fare; che sappia entro quando dovrò finirlo; che abbia tutti gli strumenti per operare; che la mia azienda sappia valutare quello che faccio, me lo comunichi e

mi indichi eventuali aree di miglioramento. È evidente che il livello a cui porto l’analisi delle attività può variare in

funzione del grado di aggregazione delle attività stesse; possiamo allora par-lare di macro processi là dove il grado di aggregazione è più elevato e di micro processi per le attività più elementari ovvero per quelle attività ad un livello di dettaglio più elevato. Per esemplificare parleremo quindi di macro processo se facciamo riferimento alla contabilità fornitori e di micro proces-so se parliamo di registrazione della fattura; oppure possiamo considerare

17

macro processo la qualifica fornitori o la gestione del credito dei clienti e micro processo la registrazione anagrafica del fornitore o il calcolo del fido di un cliente. Quindi più le attività sono aggregate più ci riferiamo a macro processi e, al contrario, più le attività sono di dettaglio tanto più facciamo ri-ferimento a micro processi.

2. Cos’è il modello dei processi? Come abbiamo visto un processo altro non rappresenta che un insieme di

attività più o meno aggregate in funzione del tipo d’analisi che vogliamo condurre; l’insieme dei processi oggetto o risultato d’analisi costituisce il modello dei processi. In letteratura si sono succedute varie metodologie di rappresentazione dei processi ed ognuno di tali modelli ha teso rappresenta-re, oltre alle attività, anche altri elementi che ad esse si collegano (p.e. chi fa che cosa, i flussi informativi che attraversano i processi, i punti decisionali, gli eventi che si susseguono ecc.). In questa sede, e solo a titolo esemplifica-tivo, ve ne propongo uno utilizzato nella pratica:

Come si può vedere nella fig. 1, tale tipo di rappresentazione serve ad e-videnziare semplicemente la catena dei processi e l’elemento qualificante del cambiamento senza altri riferimenti a persone, entità organizzative o quant’altro.

18

MARKETING D’ACQUISTOPOLITICHE DI

APPROVVIGIONAMENTO

MODELLO DATI DI BASEE ATTIVITA’ INFRASTRUTTURALI

UNIFICAZIONE /CENTRALIZZAZIONE

VERIFICA FATTURE

INVESTIMENTI

MANUTENZIONE

ESERCIZIO

QUALIFICA FORNITORI

INTEGRAZIONE

GESTIONE DELLE SCORTE

MAGAZZINO VIRTUALE

PROCEDUREAUTOMAZIONE

PIANIFICAZIONE E REALIZZAZIONEACQUISTI

RICEVIMENTO MATERIALI

Particolare dei processi del Ciclo Passivo

MARKETING D’ACQUISTOPOLITICHE DI

APPROVVIGIONAMENTO

MODELLO DATI DI BASEE ATTIVITA’ INFRASTRUTTURALI

UNIFICAZIONE /CENTRALIZZAZIONE

VERIFICA FATTURE

INVESTIMENTI

MANUTENZIONE

ESERCIZIO

QUALIFICA FORNITORI

INTEGRAZIONE

GESTIONE DELLE SCORTE

MAGAZZINO VIRTUALE

PROCEDUREAUTOMAZIONE

PIANIFICAZIONE E REALIZZAZIONEACQUISTI

RICEVIMENTO MATERIALI

Particolare dei processi del Ciclo Passivo

Fig. 1 – Esempio di modello dei processi Ogni modello rappresentativo dei processi è generalmente ideato in fun-

zione degli obiettivi che si vogliono raggiungere con quel tipo di strumento; possiamo pensare allora che non esiste un modello di riferimento universal-mente riconosciuto e che ogni esigenza di analisi suggerisca l’adozione di una simbologia che sia la più adeguata alle necessità di rappresentazione. In alcuni sistemi ERP, inoltre, le cose si sono progressivamente evolute nel cor-so degli ultimi 5 anni e ad ogni release dei vari prodotti è stato proposto un nuovo strumento di rappresentazione.

La fig. 2 illustra uno stralcio dei processi d’acquisto: come si può evince-

re riporta lo schema dei macro processi, la loro sequenza (in termini di pre-decessori e flussi di collegamento) ed il legame tra loro esistente.

19

EntrataMerci

Prestazione

Richiestedi

AcquistoAcquisto

Trasporto

Magazzino

Gestione

Qualità

EntrataFattura

Esempio di processi di acquisto

Entrata

Gestione

EntrataMerci

Prestazione

Richiestedi

AcquistoAcquisto

Trasporto

Magazzino

Gestione

Qualità

EntrataFattura

Esempio di processi di acquisto

Entrata

Gestione

Fig. 2 – Esempio di processi di acquisto Dove da una prima visualizzazione della catena dei processi è possibile

scendere nel dettaglio di ogni processo come riportato dalla fig. 3. E da qui rilevare tutti i flussi e gli eventi che possono verificarsi ed essere gestiti all’interno di ogni processo, fino alla visualizzazione di tutti gli attributi del-lo stesso ed alla customizzazione (personalizzazione tramite parametri ester-ni al codice dell’applicazione) del sistema.

Fig. 3 – Dettaglio Entrata Fattura

20

Come si vede, per concludere, ogni strumento è finalizzato all’uso cui è destinato ed agli obiettivi che si vogliono conseguire. Il lettore troverà che in letteratura esiste un ampio spettro di possibilità metodologiche e di rappre-sentazione ed in ogni caso, quello che qui interessa, è che l’impiego di tali strumenti trova giustificazione al solo fine di ottenere una chiave di rappre-sentazione e d’interpretazione della realtà di un’azienda o di una parte di essa. Si consideri, inoltre, che esiste uno stretto legame fra tipologie di pro-cessi aziendali e sistemi informatici di supporto e che questo legame è il pun-to di partenza per capire cosa è un ERP e come si colloca nell’ambito dei si-stemi informativi societari. Ma andiamo per ordine.

3. Che senso assumono i modelli di Anthony e Si-mon?

Un modello di rappresentazione d’insieme dei processi aziendali fu for-

mulato da R. Anthony e successivamente da H. Simon1 i quali sostenevano, sostanzialmente ed in estrema sintesi, che i processi aziendali potevano esse-re classificati in tre sottoinsiemi (fig. 2).

Processi Decisionali Strategici

Processi Gestiona

Processi Opera

Pianificazione

Consuntivi

Piani

Strategici

Piani - annuali

Controllo

Budget di Periodo

Work-Flow

Processi Decisionali Strategici

Processi Gestiona

Processi Opera

Pianificazione

Consuntivi

Piani

Strategici

Piani - annuali

Controllo

Budget di Periodo

Work-Flow

Fig. 2 – Il modello di Simon: esempio d’applicazione ai processi di pianificazio-ne

1 Qui si propone una sintesi esemplificativa dei due modelli considerando di voler trasmettere un solo messaggio: in azienda ci sono diverse classi di attività che condizionano l’architettura e la tipologia dei sistemi informatici di supporto. Pertanto, per una più accurata analisi dei modelli, si veda P.F. Camussone (1990), Informatica aziendale, SDA Bocconi , EGEA.

21

Processi decisionali strategici: tipici del top management sono tesi al

raggiungimento degli obiettivi complessivi dell’azienda. Questa tipologia di processi è costituita generalmente da attività poco strutturate ed altrettanto poco ripetitive; in tale ambito è estremamente importante “prendere le deci-sioni giuste” e promuovere le iniziative al momento più opportuno traguar-dando periodi a medio–lungo termine (3–5 anni). I fabbisogni informativi sono tipicamente costituiti da aggregazioni di sintesi, sviluppate per scenario o per obiettivo, ed i dati esprimono quantità e valori rappresentativi tanto della realtà interna all’azienda quanto di quella esterna; non è richiesto un grado di precisione elevato ed in genere si fa ricorso anche a dati stimati. La comunicazione investe poche persone (quindi pochi problemi di entropia!) e gli strumenti di supporto sono da considerarsi abilitatori dei fattori decisiona-li intendendo con questo: la possibilità di poter effettuare delle analisi con simulazioni e modelli dinamici, accedere ad informazioni interne e/o esterne all’organizzazione, disporre di dati attendibili e non ultima avere la possibili-tà di condividere i risultati delle analisi e delle decisioni assunte.

Processi gestionali: costituiscono la struttura portante dell’azienda in

quanto finalizzati alla sua gestione corrente; sono costituiti, in altre parole, da attività tese al raggiungimento di obiettivi d’efficacia ed efficienza nel breve–medio periodo (generalmente un anno). In questo ambito le attività sono più strutturate e ripetitive rispetto ai processi di pianificazione strategi-ca, sono coinvolte molte più persone (con conseguenti problemi di comuni-cazione e di informazione) e le necessità informative richiedono una preci-sione più accurata dei dati che, per questo, hanno la caratteristica di essere più analitici.

Processi operativi: rappresentano l’insieme delle attività più esecutive

svolte in azienda e comunque mirate alla realizzazione della sua “missione”. In soldoni rappresentano l’attività quotidiana delle persone in cui l’accento è posto sul fare le cose piuttosto che sulla loro impostazione e verifica; qui la caratteristica di ripetitività delle azioni è molto spinta e nella gran parte dei casi è possibile che i processi vengano “normalizzati” da procedure e moda-lità di comportamento operativo codificati a livello organizzativo. Gli eventi vengono gestiti nel momento in cui si verificano, la comunicazione investe la maggior parte dell’azienda e quindi gli strumenti informativi di supporto tro-vano ampio spettro d’impiego favoriti dalla necessità di stabilità e ripetitività

22

dei comportamenti lungo tutto il processo. I dati sono gestiti in forma estre-mamente analitica ed il grado di precisione richiesto è necessariamente ele-vato.

Se, come abbiamo visto, in azienda convivono più tipologie di processo

(che si differenziano per necessità informative, traguardi temporali, ripetitivi-tà delle azioni, qualità ed analiticità dei dati) si può presumere di conseguen-za che i sistemi informatici preposti al loro supporto, seguano la logica di di-versificazione in virtù delle peculiarità e delle caratteristiche dei processi stessi2. C’è, inoltre, da considerare un altro aspetto: i sistemi d’automazione offrono il loro maggior vantaggio se applicati a quei processi più stabili (al-meno nel breve periodo) e ripetitivi in cui la maggior parte delle attività di gestione e controllo dei dati sia delegabile ad un’entità diversa dalla persona fisica (proprio un sistema informatico) lasciando a quest’ultima le attività a maggior valore aggiunto. Questo vuol dire che nell’applicare i sistemi infor-matici, più si va verso il basso del modello, maggiori risultano essere i bene-fici indotti sulla catena del valore. Ora è altrettanto vero che le caratteristiche del sistema informatico, dovendo seguire la logica di diversità dei processi e la necessità di uniformità informativa (sia in senso verticale che orizzontale del modello come vedremo oltre) non possono sicuramente prescindere da quello che è ormai diventato un dogma: la necessità d’integrazione. Volendo rivedere il modello proposto dei processi in un’ottica più orientata alle fun-zioni aziendali, potremmo tracciare uno schema come quello di fig. 3.

2 In realtà esistono svariati studi (anche di illustri professori italiani) che in merito dimostrano questo stretto legame tra processi e sistemi informatici. Qui vogliamo semplicemente ricorda-re che tutte le metodologie di progettazione e sviluppo del software (da Gane e Sarson a P. Chen, J. Martin ecc.) hanno come passi fondamentali l’indagine sulla realtà da automatizzare e questo aspetto, in ultima analisi, altro non rappresenta che l’insieme delle attività che saran-no svolte da qualcuno utilizzando la futura applicazione.

23

Appro

vvig

ionam

enti

e Con

trollo

Qua

lità

Inge

gner

ia e

Pro

duzi

one

Am

min

istr

azio

ne F

inan

za e

Con

trol

lo

Marketing e Vendite

Gestione e Am

ministrazione PersonaleApp

rovv

igion

amen

ti e C

ontro

llo Q

ualità

Inge

gner

ia e

Pro

duzi

one

Am

min

istr

azio

ne F

inan

za e

Con

trol

lo

Marketing e Vendite

Gestione e Am

ministrazione Personale

Fig. 3 – I processi per area funzionale Da cui è più evidente la caratteristica di trasversalità dei processi azienda-

li (rispetto alle aree funzionali) e quindi si avverte meglio la necessità di un sistema informatico che integri le esigenze informative a tutti i livelli ed in tutte le aree. Ma come recita un vecchio luogo comune ... “dal dire al fare c’è di mezzo il mare”; vediamo perché.

24

4. Quali i vincoli ed i benefici dell’integrazione? L’introduzione delle prime applicazioni su computer in azienda, rispetto a

quelle che erano le aree funzionali in essa presenti, avvenne seguendo una logica che potremmo definire “a macchia di leopardo”. Con questo voglio dire che la preoccupazione maggiore degli IT manager, indotti anche dalle logiche di mercato (software su misura) e della domanda interna (ma il com-puter a che serve? Come funziona? Conserverò il mio posto di lavoro?), si preoccupavano d’automatizzare quelle attività più ripetitive investendo in quelle aree funzionali in cui meglio si presentavano tali ricorrenze; in questo modo nacquero le prime procedure di paghe e stipendi, le prime applicazioni di contabilità e così via. Man mano che la diffusione e l’evoluzione tecnolo-gica aumentavano, allo stesso modo le applicazioni crescevano e cominciava a nascere l’esigenza di “far parlare tra di loro” questi sistemi, che nel frat-tempo si erano evoluti. Infatti, se qualcuno avesse fotografato i sistemi di un’azienda degli anni ’80, con buo-na probabilità, avrebbe prodotto un’immagine simile alla fig. 1, dove si vede coesistere sistemi “monoliti di area” che per funzionare, contengono tutto il corredo informativo di base di cui hanno bisogno.

Fig. 1 – Immagine dei sistemi anni ’80

25

Solo per fare un esempio si può immaginare che l’anagrafica dipendenti fosse presente nel sistema degli stipendi, nel data base di gestione del perso-nale, nel sistema di contabilità fornitori e/o clienti ed alcuni suoi attributi nel sistema di contabilità analitica o in quello della manutenzione; inoltre, per connettere tra di loro sistemi diversi, nati in momenti differenti e magari con tecnologie difformi, si erano dovute realizzare interfacce – programmi che consentivano a sistemi diversi di comunicare tra di loro – che in molti casi erano esse stesse dei veri e propri sistemi. Quello che qui interessa, in ogni caso, è che in azienda si cominciava a prendere coscienza, anche da parte degli utenti, della necessità d’integrare tra di loro sistemi dedicati che conte-nevano o producevano informazioni d’interesse per altre aree aziendali oltre che per quelle in cui erano utilizzati. Anche la tecnologia informatica, inol-tre, cominciava a poter supportare (si pensi per esempio all’avvento dei data base relazionali) la necessità d’integrità delle relazioni tra le informazioni; i tempi di trasferimento dati erano sempre più contenuti e si aprivano le porte per applicazioni grafiche e per gli ERP (Enterprise Resource Planner).

Tra la metà degli anni ’80 ed i primi anni ’90, infine, gli utenti comincia-no a mostrarsi più “maturi”; capiscono il valore degli strumenti, li adoperano e redigono sempre più spesso istanze d’estensione ai sistemi aziendali chie-dendo nuove e più estese funzionalità a supporto delle attività operative. Ma c’è un fatto nuovo: si comincia a capire che il proprio lavoro non è fine a se stesso; che non si vive più nel classico guscio d’uovo isolati dal resto del mondo, ma che, al contrario, le informazioni possedute da un altro collega, che opera in un’altra area aziendale, rivestono interesse anche per noi e aiu-tano a migliorare la qualità dei propri risultati. Ed è da queste necessità e dall’accre–sciuta maturità del mercato (come del resto aveva teorizzato No-lan agli inizi degli anni ’70) che muove i primi passi un nuovo concetto d’integrazione: vediamola più da vicino facendo al solito ricorso ad “espe-rienze dirette sul campo”.

1. Cos’è l’integrazione aziendale? È sicuramente l’aspetto dell’integrazione più difficile da conseguire nelle

aziende. Coinvolge tutta l’organizzazione ed ha impatto sui suoi valori, la sua cultura e sulle modalità di relazione tra le persone nel senso che, a pre-scindere dagli strumenti adottati, è fondamentale che si crei consapevolezza sulla necessità di sinergie tra funzioni diverse ed in alcuni casi che le rela-

26

zioni addirittura s’invertano. Volendo trovare dei riferimenti ai ruoli giocati dalle varie funzioni aziendali nella catena interna cliente–fornitore, si può notare, per esempio, che nella vecchia concezione del modello dei processi era generalmente l’Amministrazione la funzione preposta ad “ufficializzare” gli eventi e le informazioni aziendali (tanto verso il management quanto ver-so l’esterno dell’azienda). Proprio in tale ambito, dovendo essere gestite tipo-logie di dati difformi (quantità con unità di misura diverse, differenti valute e tipologie merceologiche ecc.) si finiva col tradurre tutto in moneta di conto (cioè in valore) cercando di gestire a livello di contabilità analitica (la cui funzione preposta diventava il ricettacolo di tutti i problemi e di tutte le me-diazioni) gli obiettivi economici e di responsabilità dei vari manager di linea. Dal canto loro le altre funzioni, un po’ per la natura delle attività un po per cultura e formazione tecnico/professionale, erano abituati a manipolare dati eterogenei tra di loro e diventava veramente difficile trovare un linguaggio comune. Per meglio chiarire quali possano essere tali problemi mi sembra utile ricorrere ad una storiella raccontatami in proposito e che suona più o meno così:

Il presidente di una nota società manifatturiera fu costretto un brutto

giorno a misurarsi con un problema che metteva addirittura a rischio l’esistenza stessa della società. Consultato il solito luminare d’organizzazione aziendale questi sentenziò che il problema era molto com-plesso ma comunque riconducibile ad un modello matematico la cui soluzio-ne, benché complicata, aveva fornito in altre realtà similari degli ottimi ri-sultati. Ora noi per semplicità descriveremo in questo modo il modello:

2 + 2 = ?

E lo stesso luminare aveva proposto il suo modello di soluzione che, sem-

pre per semplicità, argomenteremo in:

2 più o meno TOT

dove TOT dipenderà dalla velocità con cui sarà realizzato il cambiamento comprendendo anche l’incidenza del suo onorario (diciamo che fu onesto!).

Ora, come dicono a Napoli: “a cà nisciun è fess”, il buon presidente pen-sò bene di sentire i suoi più stretti collaboratori che, riconosciuto da tutti, avevano fama di sapere il fatto loro sulle attività di pertinenza. Detto fatto il

27

presidente convocò il suo responsabile della Ricerca e gli sottopose il quesi-to senza mezzi termini: “Giovanni secondo te 2 + 2 quanto fa?”. Il buon Giovanni senza perdersi d’animo, benché preso “in contropiede”, tirò fuori il suo regolo, si fece prestare dal presidente dei fogli di carta ed una matita (la volle rigorosamente HB e qui nacque una piccola disquisizione tra i due), fece i suoi calcoli, annotò i risultati intermedi ed alla fine sentenziò: “Caro presidente i miei calcoli dicono 2,0000001.” Salutò con la sua solita cortesia e si licenziò.

Ma il buon presidente che nella sua lunga carriera ne aveva viste di tutti i colori, pensò bene di sentire anche il direttore del marketing, i responsabili dell’IT e degli acquisti e, per essere sicurissimo anche il direttore generale della produzione ed il responsabile del personale. “In questo modo – pensò – quadro sicuramente il cerchio”. Ma ahimè le cose non andarono come a-veva sperato: 1. il direttore del marketing era in Brasile e riuscì ad incontrarlo solo du-

rante una cena di lavoro… ma solo per cominciare a discuterne (la cosa andò avanti per un po);

2. il responsabile dell’IT lo tenne in apprensione per 5 giorni (i suoi consu-lenti non riuscivano a trovare un accordo accettabile);

3. il responsabile degli acquisti dopo averlo tenuto in ostaggio per mezza giornata fornì una versione dei risultati che era a dir poco sorprendente (vedi tabella oltre: sembrava che qualcuno volesse dei non meglio identi-ficati diritti di mediazione!);

4. il direttore generale della produzione prese tempo e solo dopo il tour de-gli stabilimenti si decise a promettergli “me ne occuperò personalmen-te!”;

5. Il responsabile del personale, persona molto riservata, lo invitò a discu-terne sulle Dolomiti lontano da orecchie indiscrete (il presidente si dovet-te prestare a un week–end sulla neve!)

28

Nella tabellina qui sotto riepiloghiamo tutti i modelli di soluzione a cui il

buon presidente arrivò dopo un mese circa di paziente lavoro:

Funzione aziendale

Tempo di rispo-sta (in giorni)

Soluzione

Ingegneria – Ricerca e Sviluppo 1

2,000001

Marketing e Vendite

13 Compreso tra 1,5 e 3 ma se ne poteva discutere

Servizi IT 5 2 benché non tutti i consulenti

si trovarono in accordo Approvvigionamenti e Logistica Interna

15

1,9 + 0,1 (0,1 erano i diritti di media-zione richiesti da un broker)

Personale ed Organizzazione

7 2 o 1,9 (in funzione di come andava

la trattativa coi sindacati) Il presidente vide i risultati e scoraggiato pensò di parlarne con l’unico

direttore che non aveva interpellato sino ad allora (conoscendo i suoi polli… aveva pensato bene di tenerlo come asso nella manica!): ovvero il direttore dell’amministrazione finanza e controllo. Lo chiamò al telefono che erano ormai le 21.15 e con sua soddisfazione fu invitato nella sala conferenze all’ultimo piano dove una dolce musica di sottofondo augurava una rilassan-te serata casalinga. Il direttore lo accolse sorridente sulla porta, lo invitò ad entrare e prima di richiudere, si assicurò che non ci fosse più nessuno al piano. Entrò nel salone anche lui, chiuse la porta a doppia mandata ed invi-tò il presidente ad occupare una lussuosa e comoda poltrona posta in un an-golo discreto del salone. Qui tutto l’ambiente era ovattato ed oltre loro due non si sentiva volare una mosca; tutto era tranquillo e rilassante come in quei momenti in cui “la quiete preannuncia la tempesta”. A quel punto il di-rettore, con aria di disponibilità e sicurezza (tipico di chi sa di avere già la risposta in tasca pur non avendo idea della questione!), invitò il presidente ad esporgli il problema. Il buon presidente espose quindi tutti i fatti, gli spiegò che era in gioco il futuro della società, gli mostrò i risultati ottenuti dalla sua indagine preliminare comprese le soluzioni ricevute da tutti gli al-tri manager ed anche a lui fece la fatidica domanda: “A tuo parere: quanto fa 2 + 2?”. Il direttore non fece una piega, ascoltò con molta attenzione,

29

guardò la tabella che il suo presidente gli aveva sottoposto poi si alzò, con tutta calma aumentò il volume degli altoparlanti e rivolgendosi al suo presi-dente chiese: “Presidente ma lei quanto vuole che faccia?”

Al di là dell’aneddoto, mi sembra che la storia proponga alcuni problemi

di fondo connessi con l’integrazione aziendale:

♦ ogni manager propone e percepisce i fatti aziendali in funzione della sua esperienza, della sua cultura e dei suoi valori; elabora una propria strate-gia di relazione verso gli altri interlocutori e soprattutto cerca di fornire proposte ed informazioni in linea “con le aspettative dell’interlocutore”;

♦ le informazioni assumono rilevanza di area funzionale e molto spesso vengono riportate secondo consuetudini ed in funzione dei propri obiettivi (da qui la necessità di “omogeneizzare” i dati);

♦ gli errori e le carenze d’informazione finiscono per ricadere su tutti quei processi “a valle” della catena senza rendersi conto che è un problema e-sistente “a monte”;

♦ ogni volta che l’alta direzione richiede informazioni si scatena “la rincor-sa ai dati”, si redigono report ad hoc e, ad ogni richiesta successiva, il processo viene ripercorso interamente senza tenere conto di quanto fatto la volta precedente.

E come dar torto a chi deve per così dire “arrangiarsi” senza apparire né

uno sprovveduto né tantomeno qualcuno carente verso il rispetto degli obiet-tivi? Da questo dipendono la sua carriera ed il suo avanzamento retributivo! Comunque non è altrettanto corretto ridurre tutto solo ad un problema di o-mogeneità informativa. Il problema è sicuramente più complesso ed articola-to ma qui è stato strumentalizzato al solo fine di chiarire un concetto di fon-do: l’integrazione aziendale avviene attraverso l’integrazione di eventi e processi finalizzati al raggiungimento di obiettivi strategici, tattici e/o operativi.

30

Richiesta diAcquisto

RicevimentoMaterialiOrdine Fatturazione

Controlling

Progetti

Acquisti

Tesoreria

Budgeting MaturatoImpegnato Report

Pagamentielettronici

Gestioneclussi dicassa

Previsione flussidi cassa

BudgetingControlloEconomicoForecast Report

• Condivisione Informazioniattraverso i processi

• Efficacia e sinergia tra lefunzioni aziendali

• Disponibilità informativaorientata al supporto delledecisioni

CODIFICHE

UNIVOCHE

Condivisione delle informazioni attraverso i processi

Richiesta diAcquisto

RicevimentoMaterialiOrdine Fatturazione

Controlling

Progetti

Acquisti

Tesoreria

Budgeting MaturatoImpegnato Report

Pagamentielettronici

Gestioneclussi dicassa

Previsione flussidi cassa

BudgetingControlloEconomicoForecast Report

• Condivisione Informazioniattraverso i processi

• Efficacia e sinergia tra lefunzioni aziendali

• Disponibilità informativaorientata al supporto delledecisioni

CODIFICHE

UNIVOCHE

Condivisione delle informazioni attraverso i processi

Fig. 2 – L'integrazione Aziendale La fig. 2 aiuta a chiarire meglio il concetto di integrazione aziendale.

Nell’esempio sono riportate alcune aree di una generica azienda:

il controlling, la gestione dei progetti, gli acquisti, la gestione della tesoreria, ed alcuni processi tipici di ogni area; le frecce indicano i possibili flussi

informativi tra i processi senza riferimenti a scadenze temporali, vincoli di precedenza e/o sincronismi vari.

D’altronde quello che interessa è l’influenza che ogni evento ha in termini di flusso informativo tanto verso processi della stessa area quanto su processi di aree diverse; ma vediamo nel dettaglio. Dalla stessa fig. 2 si evince che, nell’ambito della funzione acquisti, il processo di gestione delle r.d.a. (ri-chieste d’acquisto) genera informazioni tanto verso la gestione dei progetti quanto verso la funzione di tesoreria; nel momento in cui viene emessa una r.d.a., infatti, ed ancor prima che questa venga processata nell’ambito della funzione acquisti per dare origine per esempio ad un ordine, la stessa r.d.a. riveste un significato importante in ambito aziendale. Supponendo che sia stata emessa da un progetto (magari d’investimento) è essenziale che il pro-ject manager (e tanto più la pianificazione degli investimenti che segue quel progetto) sia al corrente della sua diminuita disponibilità d’impiego; inoltre, chi fa previsioni di cassa, come generalmente avviene in ambito tesoreria, è

31

opportuno che venga informato di un’ipotesi d’esborso già apprezzabile (e magari di fabbisogno di valuta se la r.d.a. fa riferimento ad un acquisto in va-luta), seppure a lungo termine. Ora già qui è sufficientemente chiaro come il verificarsi di un semplice evento, come l’immissione di una richiesta d’acquisto, possa avere interesse per altre funzioni aziendali oltre che per la funzione emittente. Inoltre è importante notare che l’evento su citato ha im-patto verso le attività (i processi!) della funzione acquisti; infatti la r.d.a. do-vrà essere processata, presumibilmente da un ufficio acquisti, per dare origi-ne o ad un acquisto vero e proprio (rapporto verso un fornitore esterno) o per essere soddisfatta nell’ambito della propria organizzazione (per esempio un magazzino ovvero un fornitore interno). Se analizzassimo più in dettaglio il corredo informativo di una r.d.a., scopriremmo che i suoi attributi hanno an-che carattere “contabile” nel senso che si potrebbero fare acquisti per un cen-tro di costo, per un assett o una commessa interna e che questi attributi gene-rano informazioni per i gestori degli oggetti di destinazione (ovvero per il centro di costo, l’assett o la commessa interna a cui fanno riferimento) ed hanno influenza sulle attività di quelle funzioni aziendali preposte alla loro analisi (contabilità analitica, patrimoniale ecc.). Un dato è fondamentale in tutto questo “turbi–nio” d’implicazioni: La funzione aziendale che intro-duce la r.d.a. è al contempo proprietaria e responsabile delle informa-zioni immesse. Cioè è l’unità emittente che si fa garante della correttezza delle informazioni: il fornitore è proprio quello, il materiale o la prestazione a cui si fa riferimento sono corretti, le quantità sono giuste e l’eventuale pro-getto di riferimento è il progetto destinato a ricevere quanto “prenotato” nella r.d.a..; in casi di errore non è opportuno che l’informazione continui a per-correre tutta la catena dei processi. Anzi è vero il contrario: la funzione che ha emesso la r.d.a.., essendo garante del contenuto informativo della stessa, è proprio la funzione che rimuove gli errori generati e non delega ad altre fun-zioni aziendali (a valle del processo) la loro risoluzione. Questo vuol dire che chi emette r.d.a. deve essere cosciente del fatto che le sue informazioni rive-stono carattere di ufficialità nell’azienda e sono le stesse informazioni con cui l’azienda si misura al suo interno (es. controllo di gestione) e si presenta verso l’esterno (es. bilancio).

Ora, man mano che si prosegue con i processi di acquisto e presupponen-do di processare la r.d.a. in senso di acquisto da un fornitore esterno (fig. 2), l’ufficio approvvigionamenti costruisce il suo ordine partendo proprio dai dati contenuti nella r.d.a. dove già buona parte delle informazioni sono pre-senti. È ancora più evidente come la correttezza dei dati immessi all’origine

32

sia fondamentale: l’ordine sarà inviato al fornitore identificato nella r.d.a., il materiale o la prestazione saranno gli stessi, le quantità anche e così via. L’ufficio approvvigionamenti compilerà l’ordine con le informazioni tipiche dell’ordine stesso (es. condizioni, tempi stabiliti col fornitore ovvero dei ri-sultati della trattativa) lo riprodurrà sul supporto concordato col fornitore, si preoccuperà d’avere tutte le autorizzazioni come prescritto dalle disposizioni interne e provvederà a rendere definitivo l’ordine stesso. In questo preciso momento l’ufficio approvvigionamenti genera un evento che ha rilevanza a-ziendale. Infatti: il project manager deve essere tenuto al corrente con infor-mazioni per esso vitali (tempo di consegna, a che punto è l’evasione da parte del fornitore, eventuali parametri qualitativi da tenere sotto controllo, dove sarà consegnata la merce ecc.) e considerare che l’ipotesi d’acquisto si è tra-mutata in una “certezza” e che quindi le sue previsioni d’impegno sono ca-ratterizzate da maggiore precisione. Anche la tesoreria è interessata all’evento: le sue previsioni diventano più attendibili passando dal lungo al medio–breve periodo; i fabbisogni valutari vengono meglio messi a fuoco ed il gestore può tentare una prima analisi di “bilancia valutaria”. Infine le in-formazioni immesse nell’ordine potranno essere riutilizzate in momenti suc-cessivi anche da altre funzioni aziendali diverse dalla funzione approvvigio-namenti (per esempio dalla funzione di qualifica fornitori o controllo quali-tà).

Nel momento in cui la merce o la prestazione viene ricevuta in azienda, (per esempio presso un magazzino o, nel caso di prestazioni, presso una fun-zione produttiva o di staff), ecco che anche questo evento riveste rilevanza per più funzioni contemporaneamente. Intanto chi riceve la merce deve esse-re cosciente di un fatto: egli attesta la “nascita di un costo” o di una “entrata a magazzino” che hanno rilevanza ai fini dell’informativa aziendale e civili-stica/fiscale (in altre parole questi dati vanno a bilancio)! E non solo: tali in-formazioni d’entrata merce/prestazione, infatti, saranno riprese da qualcun altro in un momento successivo per verificare che quanto ricevuto sia coe-rente con le comunicazioni del fornitore (es. fattura passiva) e con quanto ordinato dalla funzione approvvigionamenti (processo di verifica fattura ef-fettuato in genere dalla funzione amministrativa). In ogni caso tali dati sono importanti per:

la funzione amministrazione al fine d’effettuare eventuali “stanziamenti”

di costo (i puristi di ragioneria mi passino il termine!) e per tenere sotto controllo quali fatture saranno ricevute e da quali fornitori;

33

il project manager in modo che possa aggiornare i propri dati di avanza-mento e cash–flow di progetto, di eventuali collaudi della merce e di logi-stica dei materiali (si allude ai possibili magazzini di progetto distribuiti anche geograficamente);

le funzioni approvvigionamenti, qualifica del fornitore, controllo qualità; il magazzino, qualora la merce sia ad esso destinato, per tutte le operazio-

ni di stoccaggio e/o eventuale consegna al destinatario finale; il controlling per le attività di registrazione sulle destinazioni contabili e

la redazione del reporting gestionale; la tesoreria per l’aggiornamento delle previsioni.

È ovvio che le informazioni debbano essere identiche per tutte le funzioni

coinvolte pena la non condivisibilità: le codifiche (materiali, prestazioni, for-nitore, centri di costo, progetti ecc.), le quantità ed i valori sono unici per tut-ti gli attori interessati che sui dati analitici possono operare in termini di in-tegrazione e aggregazione, in funzione di specificità di reporting, ma mai in termini sostitutivi. Allora rimane un problema: Chi e come deve farsi carico della univocità delle codifiche? Cercheremo di mettere meglio a fuoco que-sto aspetto quando vedremo l’integrazione da un punto di vista dei sistemi di supporto.

34

2. Come interpretare l’integrazione di processo?

Organizzazione di risorse, sistemi e flussi in ottica di “Catena del Valore”

Richiestedi

Acquisto

Ordinedi

Acquisto

EntrataFattura

EntrataMerce

GestionePagamenti

GestioneBanche

Miglior controllo del processo

Organizzazione finalizzata ed efficiente

Qualità dell’informazione

Efficienza nei costi

Si ottengono rivedendo attività e procedure. L’introduzione di un sistema nuovocome SAP in genere è l’occasione per fare del reengineering dei processi

Fig. 3 – Esempio di Integrazione di Processo cross Area funzionale

In genere l’introduzione di un sistema ERP è l’occasione buona per rive-dere, all’interno dell’azienda, tanto le attività che si svolgono quanto l’organizzazione di supporto. L’obiettivo ultimo rimane comunque quello di ottenere la migliore prestazione, tanto in termini di efficienza quanto di effi-cacia, l’ungo tutta la catena delle attività; questo vuol dire che è più sentita la necessità di rivedere comportamenti non finalizzati a fornire valore, raziona-lizzando attività e risorse in funzione degli obiettivi da raggiungere. È possi-bile che in quest’ottica si tenda a considerare modelli di riferimento esterni all’organizzazione (generalmente best practice che hanno fornito i migliori risultati in termini di costi/benefici) ed a trasferire tali modelli, adoperando i dovuti accorgimenti, nella propria realtà aziendale.

Al fine di ottimizzare la performance complessiva, il processo viene ana-lizzato nel suo insieme considerando l’obiettivo finale dell’intero processo; in altre parole si va oltre la visione “funzionale” delle attività e si evitano inutili controlli intermedi che generalmente richiedono strutture organizzati-ve ad hoc. In tal senso l’intero processo diviene più efficiente; i flussi infor-mativi non richiedono manipolazione e sincronizzazione intermedi di tratta-mento (decodifiche di dati, tempi di ricezione e trasmissione, supporti diversi

35

ecc.) ed il processo ne beneficia in termini di efficacia in quanto i destinatari delle informazioni sono raggiunti direttamente e con un contenuto informati-vo identico a quello della fonte. Ne consegue una visione più appropriata del processo che in tal senso può essere controllato più agevolmente (p.e. analisi K.P.I. più adeguata agli obiettivi). Ora è più evidente come una razionalizza-zione dei processi incida tanto sull’organizzazione di supporto quanto su una maggior efficienza in termini di costi; il beneficio indotto da una revisione finalizzata per obiettivi, con l’esclusione di controlli ed attività inutili (o co-munque demandabili ad una entità diversa dalle persone), consente un salto qualitativo delle risorse umane coinvolte dal processo stesso. Viene cioè cre-ata l’opportunità di liberare risorse che possono essere destinate ad incidere sulla qualità degli obiettivi e quindi sulla loro efficacia; possono nascere esi-genze di nuove professionalità (con conseguente necessità di riconversione e/o formazione delle risorse umane), strutture organizzative non presenti in azienda o più semplicemente revisioni di modalità operative che coinvolgano persone di unità/aree funzionali diverse. Tutto questo significa che si deve essere coscienti della possibilità di dover gestire un “progetto di cambiamen-to” che, con impatti diversificati, possa interessare più comparti aziendali (c.f.r. integrazione a livello aziendale). È chiaro che obiettivi di cambiamento possano andare ben oltre i tempi di realizzazione del progetto ERP ma quello che qui interessa è che le due attività sono strettamente correlate e interdi-pendenti tra di loro come già si può intuire dalle necessità scaturite dai con-cetti di integrazione sin qui viste.

3. Perché l’integrazione di sistema?

Rivediamo la Fig. 1 del capitolo 4: abbiamo detto che può rappresentare la fotografia dei sistemi di una generica società sul finire degli anni ’80 come conseguenza di uno sviluppo “a macchia di leopardo” dei sistemi informati-ci. Questo in qualche modo dimostra come i sistemi informatici siano una risultante, in quanto sono da ritenersi dei “semplici” strumenti di supporto, del modo di svolgere le attività lungo quei processi aziendali che risultano poi cablati al suo interno. In ottica di coerenza, inoltre, possiamo dire che a fronte di una logica di processi per “comparti” anche i sistemi informatici ri-sultano strutturati con la stessa logica tanto per politiche di sviluppo quanto per necessità informative che risultano esse stesse scarsamente integrate

36

(supponendo che anche queste seguano la stessa logica per comparti). Ma al-lora: per quale motivo un sistema deve essere integrato?

Le necessità di informazione si sono evolute fino a considerare l’informatica una opportunità di sviluppo del business aziendale. Oggi la tecnologia consente ed abilita nuove opportunità che in passato venivano ne-gate; un esempio è costituito dalla possibilità di “far parlare” tra di loro, con tempi utili, computer di diverse organizzazioni che, seppure appartenenti a tipologie di industry diverse, riescono ad integrare i loro obiettivi di business per offrire un servizio a più alto valore aggiunto per il cliente. Oppure alle nuove possibilità offerte da Internet in termini di scambi informativi ed atti-vità infrastrutturali: connessioni con fornitori e clienti, market–place, accesso a data base esterni all’azienda, trasferimento delle immagini e quant’altro. Sono tutti sintomi di una maggiore maturità del mercato e degli utenti che comprendono meglio l’utilità di un computer, lo utilizzano con maggior fre-quenza e percepiscono più immediatamente i benefici indotti sulle loro attivi-tà. E c’è una più attenta risposta dei fornitori di servizi e prodotti informati-ci, che indirizzano le loro produzioni verso soluzioni standard ma sufficien-temente flessibili per adattarsi alle esigenze più diversificate. Solo per fare un esempio possiamo ricorrere ad una analogia col mondo automobilistico: oggi quasi tutte le case automobilistiche puntano ad avere degli standard di base (finalizzati a conseguire volumi produttivi maggiori rispetto al passato), che non precludano però la possibilità di diversificazione dell’offerta; si pen-si a quante versioni ci sono mediamente per ogni modello di auto! Inoltre nessuno si sogna di chiedere alla Fiat o alla Ford una macchina personalizza-ta sulle proprie esigenze di utenza (anche se una macchina che avesse: quat-tro ruote con cerchi al titanio da 16 pollici, due motori, trazione permanente su tutte le ruote, che viaggiasse anche a 200 Km/h, che avesse un sistema di navigazione radar ecc. ecc. sarebbe molto aderente alle mie esigenze!) è im-pensabile ed antieconomico per il cliente che, al contrario, si limita a sce-gliere, tra i modelli disponibili, quello che più si avvicina alle sue esigenze, magari rinunciando a qualche optional non disponibile per quel dato modello o tipo di automobile. Così come per l’automobile anche il mercato dell’informatica si sta evolvendo e crescendo in termini di una maggiore ma-turità; ecco allora una prima risposta: i sistemi dell’ultima generazione.

37

I sistemi ERP sono proprio l’espressione più consolidata della nuova ge-nerazione di sistemi informatici; questi, infatti, sono caratterizzati da una po-liedricità funzionale, rivolta a coprire i processi aziendali a 360° (o almeno ci provano!) e la loro caratteristica peculiare è proprio la capacità di potersi adattare alle diverse realtà aziendali senza per questo modificare la sua strut-tura interna (ricordate le automobili?). Più “semplicemente” è possibile in-tervenire su tabelle esterne al codice dei programmi perché questi funzionino nel modo più vicino alle aspettative dell’utente; da un altro punto di vista, provando a far riferimento ad un modello sufficientemente generale dei si-stemi aziendali, potremmo arrivare alla conclusione per cui, nell’ambito di un progetto di cambiamento dei sistemi più attuale, esiste la necessità di ot-tenere un disegno organico dei sistemi stessi il cui elemento portante sia in grado di integrare ed integrarsi con strumenti e procedure più disparati che convivono all’interno di un’azienda. Quello che viene qui proposto, pertanto, è un modello sufficientemente di dettaglio che spiega meglio quanto asserito:

Il Sistema Informativo Aziendale

Sistema Complessivo

Formale

Formale

Informale

Informale

Sistema Ufficiale

Sistema Personale

1. 2.

3. 4.

Fig. 4 – Modello di sistema informativo aziendale

Se guardassimo i sistemi informativi1 di un’azienda potremmo classificar-

li secondo il modello sopra riportato: 1 In questa accezione il sistema informativo è una estensione del concetto di sistema informatico (che ne costituisce un sottoinsieme) comprendendo la totalità dei flussi informativi circolanti in azienda. Per una spiegazione più

38

1. Sistema ufficiale formale è lo strumento mediante cui l’azienda gesti-

sce ufficialmente il suo patrimonio informativo tanto al suo interno quanto verso l’esterno (es. bilanci, rapporti col personale, documenta-zione verso l’azionista, i fornitori, i clienti ecc.); è costruito in modo da gestire gli interscambi di dati tra le funzioni aziendali finalizzati generalmente al raggiungimento di obiettivi generali della società. Si caratterizza per attività codificate in formalismi organizzativi (proce-dure, ordini e comunicazioni organizzative) che nel loro insieme de-finiscono le modalità ed i passi procedurali, riportano gli obiettivi, le responsabilità e gli strumenti di supporto (tra cui anche quelli infor-matici). Per esemplificare al massimo possiamo dire che è l’insieme delle cose strutturali e strutturabili formalmente che servono per rag-giungere più in generale gli obiettivi di business.

2. Sistema ufficiale informale è costituito dall’insieme di attività, stru-menti ed informazioni che sono più difficilmente strutturabili ma che comunque hanno una valenza ufficiale. Tipicamente riunioni, telefo-nate, fax ed altre attività similari che difficilmente si prestano ad esse-re strutturate in modo da originare, per esempio, una procedura orga-nizzativa; il contributo individuale delle persone risulta fondamentale in termini di stile ed approccio per cui è veramente difficile codifi-carle in modo univoco per tutta l’organizzazione. Quest’area tipica-mente, non costituisce ambito per i sistemi informatici (benché gli strumenti a disposizione stiano facendo passi da gigante) che, come abbiamo visto nei capitoli precedenti, prediligono quei processi ripeti-tivi e codificabili in cui l’automazione assume valore di efficienza.

3. Sistema personale formale è un sistema che nasce su iniziativa dei singoli manager di linea; generalmente hanno valenza di area nel sen-so che perseguono obiettivi specifici della funzione e possono non trovare un’integrazione a livello generale aziendale. È proprio nelle singole funzioni che viene utilizzato e riconosciuto come momento formale (nel senso che può esserci anche una disposizione organizza-tiva che la descrive e ne sancisce validità) e generalmente è sponso-rizzato dal “capo” della funzione che ne governa l’evoluzione in tutti

accurata tanto del modello proposto quanto della differenza tra sistema in-formatico e sistema informativo si faccia riferimento a: P.F. Camussone ope-ra già citata.

39

i sensi. Esempi di tali sistemi sono riconducibili ad obiettivi di valu-tazione (es. dei fornitori, del personale ecc.) o di misura (es. rotazio-ne delle merci in magazzino).

4. Sistema personale informale è l’insieme delle attività, degli strumenti e delle modalità realizzative di processi individuali riconducibili ad obiettivi estemporanei. Tipicamente reporting una tantum, strumenti di office automation, colloqui ecc.

Un sistema quindi è tanto più integrato quanto più riesce a compendiare le

esigenze viste in precedenza che sono ricoperte dai vari sistemi presenti in azienda; trasportando questi concetti ai sistemi informatici (che ricordiamo sono strumenti di supporto nel senso che consentono di automatizzare com-pletamente o in parte le componenti di un processo) possiamo dire che un si-stema integrato deve avere la tendenza a rivestire tanto il ruolo di strumento ufficiale dell’azienda, quanto quello di integratore di attività, strumenti, e-venti e modalità operative che, seppure non ufficiali e/o formali, concorrono al raggiungimento degli obiettivi di business nel pieno rispetto delle coeren-ze di processo e delle necessità di omogeneità ed univocità delle informazio-ni lungo tutti i processi (integrazione aziendale e di processo). Quindi, per derivazione, possiamo sostenere che un sistema informatico deve assumere una struttura integrata:

in virtù delle necessità di integrazione che nascono in azienda; per asservire l’integrazione dei processi; per abilitare l’integrazione stessa in ambienti non integrati; per sfruttare appieno le nuove opportunità offerte dalla tecnologia; per supportare i processi decisionali; per costituire una opportunità di miglioramento e cambiamento per tutta

l’organizzazione.

40

5. Come interpreta un ERP l’integrazione?

A mio avviso e confortato solo dall’esperienza, un sistema ERP riveste ap-pieno il ruolo di sistema integrato nel senso che possiede tutte quelle caratte-ristiche che abbiamo visto essere indispensabili per un sistema moderno ed adeguato alle nuove esigenze di cambiamento. Anzi, possiamo sostenere che con buona probabilità, la caratteristica peculiare di un ERP è proprio l’integrazione e tanto la sua struttura tecnica quanto quella applicativa, costi-tuiscono un punto di riferimento avanzato nel panorama delle possibili archi-tetture di un sistema aziendale.

Integrazione AZIENDALECondivisione delle informazioni attraverso i processi

Integrazione di PROCESSOOrganizzazione di risorse, sistemi e flussiin ottica di “Catena del Valore”

Integrazione di SISTEMAConvergenza piattaforme e applicazioni

ERP

Integrazione AZIENDALECondivisione delle informazioni attraverso i processi

Integrazione di PROCESSOOrganizzazione di risorse, sistemi e flussiin ottica di “Catena del Valore”

Integrazione di SISTEMAConvergenza piattaforme e applicazioni

ERP

Fig. 5 – Il sistema informatico basato su ERP

41

Infatti, come ogni sistema che voglia coprire l’azienda a “tutto tondo”, il grado di affinamento funzionale dei vari moduli ERP può non sempre essere ottimale in rapporto alle specifiche esigenze di area o di business (vogliamo qui osservare che i sistemi legacy, nel bene e nel male, venivano “cuciti” sui processi dell’azienda riproducendo comportamenti tipici dell’operatività u-tente e rispetto a questi, anche i moduli verticali IS, possono presentare lacu-ne funzionali) e tuttavia, quello che si guadagna con un ERP, è sicuramente un contributo importante ed innovativo nel gestire attività ed informazioni in ottica integrata lungo tutta la catena dei processi. L’aspetto più convincete è che un ERP non è soltanto un sistema orientato alla gestione dell’operatività utente in senso classico; è un ambiente completo ed integrato in cui troviamo gli strumenti di sviluppo, di monitoring del sistema, di oggetti applicativi e di strumenti per la loro personalizzazione, un sistema di posta elettronica, un modello metodologico di sviluppo e qualche strumento per il controllo di progetto (ed altro che vedremo meglio in seguito). E comunque, esempi di integrazione di sistema sono sicuramente: ♦ unicità delle anagrafiche di base tanto in termini di archivi quanto di co-

difiche e significato per tutti i moduli del sistema; ♦ processi gestiti in ottica di integrazione della catena delle attività e dei

flussi informativi superando la suddivisione fisica per moduli; ♦ gestione degli eventi di processo integrati/integrabili con le funzioni

messe a disposizione nei vari moduli; ♦ necessità di avere viste integrate delle strutture organizzative presenti in

ogni modulo al fine di garantire congruenza nel trattamento dei dati; ♦ possibilità di aprire il sistema verso il mondo esterno all’azienda consa-

pevoli di avere alle spalle uno strumento in grado di sostenere integra-zioni con altre organizzazioni sia in termini di protocolli che di strumenti tecnologici e funzioni di base;

♦ integrazione con l’ambiente di sviluppo di moduli di estensione funzio-nale e garanzia di apertura del sistema standard ad accogliere moduli rea-lizzati in tale ambiente in modo coerente e trasparente per l’utente finale;

♦ possibilità di definire, monitorare ed integrare processi operativi (non presenti nello standard) con oggetti realizzati ad hoc e funzioni standard del sistema (work–flow);

♦ possibilità di integrazione con sistemi specifici di area funzionale (cu-stom o di terze parti certificate);

42

♦ integrazione con strumenti di office automation; ♦ integrazione di macchine fisiche diverse su cui possono risiedere sistemi

ERP differenti anche distribuiti geograficamente;

che a ben guardare sono i veri punti di forza dei sistemi ERP. Un sistema in grado di “adeguarsi” all’ambiente in cui viene calato, che costringe a com-portamenti coerenti tutti gli operatori che lo utilizzano, che si fa carico di gestire quei controlli definiti a basso valore aggiunto in modo da liberare ri-sorse per la gestione, strumento moderno di navigazione e reporting dei dati, gestore intransigente della codifica univoca delle informazioni. Molto spesso e specie all’inizio dei progetti, ho potuto percepire commenti su ERP quasi sempre orientati a considerarlo un sistema troppo rigido in rapporto alla fan-tasia ed alla capacità di risoluzione dei problemi da parte degli italiani; forse a ragione o forse senza aver avuto ancora modo di apprezzare quel modello operativo più “regolato”. In ogni caso, dopo l’avvio e la stabilizzazione del sistema in esercizio, quasi generalmente gli apprezzamenti si sprecavano. Gli utenti cioè, cominciavano ad assimilare le potenzialità dello strumento e co-me sempre accade, in crescendo, migliorava la loro capacità propositiva tan-to verso aspetti di superamento dei problemi e di adeguatezza del sistema a supporto dei processi operativi, sia verso modalità ancora più evolute e coe-renti di utilizzo dei supporti; come dire che “l’appetito viene mangiando” considerando che certe opportunità venivano generalmente negate dai vecchi sistemi legacy. In conclusione possiamo dire che ERP si presenta come un ambiente estre-mamente integrato secondo più dimensioni che la figura qui di lato ci rias-sume in una prima approssimazione.

43

Eventi-DatiProcessiFunzioni

ERPArchitettura

TecnicaAm

bienteSviluppo

Stru

men

tiin

divid

uali

Wor

k

Flow

AltriSistemi

Eventi-DatiProcessiFunzioni

ERPArchitettura

TecnicaAm

bienteSviluppo

Stru

men

tiin

divid

uali

Wor

k

Flow

AltriSistemi

Fig. 6– Le dimensioni dell'integrazione ERP

44

6. Ma come si posiziona un ERP in azienda? Come si approccia? Facendo riferimento a quanto detto finora possiamo dire che un ERP rispetto ai modelli di Anthony e Simon, per le ragioni che abbiamo visto sulle possi-bilità dei sistemi informatici, copre la parte bassa della piramide supportando prevalentemente quei processi gestionali ed operativi che meglio si prestano ad essere automatizzati.

WORK - FLOW

Anagrafiche

Posta elettronica - Apertura verso il WWW

Integrazione con strumenti Office

Acquisti Manutenzione Amministraz. Produzione Controllo Personale Vendite

Società

Fig. 7– Posizionamento di un ERP ed elementi di integrazione

45

Con riferimento alle aree funzionali dell’azienda ed ai moduli applicativi presenti generalmente in un sistema ERP è ragionevole supporre che il pro-dotto standard copra la maggior parte dei processi e dei fabbisogni informa-tivi; se a questo aggiungiamo la possibilità di integrarlo con software di terze parti (la cui integrazione è generalmente certificata anche dalla stessa casa produttrice del sistema ERP) e con le funzionalità offerte dalle varie vertica-lizzazioni per tipologia di industry, probabilmente la copertura va ben oltre ogni ragionevole aspettativa considerando che comunque, mediamente ogni anno, viene immessa sul mercato una nuova versione del prodotto. Ovvia-mente per certe tipologie di produzione può non essere l’optimum ma in ogni caso le sue peculiarità fanno in modo che costituisca l’ossatura portante del sistema aziendale (c.f.r. il sistema ufficiale formale) a cui è possibile comun-que associare moduli specializzati o di nicchia, anche non legati al sistema ERP direttamente. E tuttavia, come soleva dire spesso uno dei miei capi: “… un ERP non fa il caffè! …”. Benché vi siano in tutto il mondo migliaia di clienti che adottano questo sistema, non è stata ancora raggiunta una copertu-ra totale dei processi d’azienda (e direi che questo vale non solo per gli ERP ma anche per tutti i sistemi finora realizzati). Forse, con più realismo, non c’è da parte delle case produttrici la volontà ad andare in questa direzione considerando le caratteristiche di generalità del prodotto e gli sforzi necessari per rendere l’iniziativa praticabile. Se pensiamo soprattutto alla parte bassa del modello (a quei processi cioè “di campo”) il mercato dell’informatica è veramente obbligato ad orientarsi verso una molteplice varietà di prodotti specifici per tali processi (penso per esempio alla gestione delle catene di produzione tanto diverse tra tipologie di industry) e dove la specificità è un’esigenza irrinunciabile ed imprescindibile dettata dalla diversa natura del-le produzioni e delle tecnologie ad esse applicate. Voglio dire che si potreb-be pur tentare di gestire la produzione di una raffineria alla stessa stregua di un impianto petrolchimico, ma se si dovessero applicare gli stessi strumenti nella catena di montaggio delle automobili o della produzione della pasta la cosa potrebbe diventare sì molto sfidante ma estremamente dura da praticare. Facendo ancora qualche riflessione meno fantasiosa possiamo riflettere sul possibile approccio da tenere nel caso dovessimo revisionare il sistema in-formatico di una generica azienda ed a questo rapportare la strategia di im-plementazione di un ERP. Innanzi tutto consideriamo che questo tipo di si-stema è molto grosso e però può adattarsi anche ad organizzazioni medio–piccole considerando che gli approcci realizzativi possono essere diversi; in-fatti, se un approccio progettuale e metodologicamente strutturato è garanzia

46

di raggiungimento degli obiettivi e di ritorni misurabili, senza prescindere da questo, dobbiamo considerare il diverso sforzo economico richiesto per at-tuare il progetto stesso. Prescindendo dai costi dell’hardware che in qualche modo sono proporzionali alle dimensioni dell’azienda (qui presumiamo che dipendano direttamente – solo per citarne alcuni – dalla configurazione ri-chiesta, dalla distribuzione geografica del sistema, dal numero di licenze e delle work station, dalle performance in termini di tempi di risposta e volume di dati da trattare che sono parametri generalmente funzione della “grandez-za” di un’azienda) con buona approssimazione possiamo ritenere che molto dipenda da come si implementa il sistema e quindi dall’impegno delle risorse (interne ed esterne) richieste. In altre parole possiamo dire che, per rendere meno oneroso lo sviluppo del sistema (si veda anche più avanti le fasi di progetto), bisogna che l’ERP sia già in qualche modo predisposto in configu-razione “go live” e che abbia bisogno solo di qualche piccolo ritocco (custo-mizing) di adeguamento alle specificità dell’organizzazione a cui è rivolto.

Particolare attenzione deve comunque essere prestata alla “Strategia di Implementazione” che, soprattutto per le grosse aziende, riveste un ruolo fondamentale in termini di impatto tanto sull’organizzazione della società cliente quanto su quella del fornitore in relazione al tempo (ciclo di vita del progetto), alle risorse da impegnare ed alla loro distribuzione temporale. In generale possiamo considerare i seguenti approcci:

♦ per strutture organizzative;

♦ per Area Geografica;

♦ per Omogeneità di processi;

che possono essere tutte praticabili in considerazione dello “stato” dell’azienda; vediamo più in dettaglio perché e quali dovrebbero essere alcu-ni dei parametri da considerare per decidere al meglio l’approccio più con-veniente.

47

L’approccio per struttura organizzativa

Vengono identificate una o più strutture organizzative (p.e. la filia-le/consociata di una multinazionale piuttosto che una divisione all’interno di una singola società ecc.) all’interno dell’organizzazione cliente e si sceglie di implementare il sistema in modo che tali unità siano “pilota” della soluzione; il senso di tutto questo è che il modello complessivo realizzato per quelle u-nità pilota possa essere successivamente esteso alle altre unità aziendali. Qui mi sembra di poter dire che le implicazioni sono molto forti:

1. il modello ideato deve avere la caratteristica di potersi adattare a tutte le realtà aziendali al fine di evitare ricicli ovvero di fare un progetto per ogni struttura organizzativa coinvolta; sarebbe meglio avere un unico modello uguale per tutti;

2. presuppone un forte committment del top management per superare le ovvie e conseguenti resistenze dei singoli manager di struttura;

3. ogni struttura organizzativa coinvolta deve affrontare un big–bang con-siderando che tutta la sua organizzazione viene investita dall’introduzione del nuovo sistema;

4. per contro i benefici sono immediati a livello di singola struttura orga-nizzativa (integrazione), è possibile approcciare i progetti con delle task–force indirizzate, è probabile che il numero delle interfacce “usa e getta” sia notevolmente ridotto.

L’approccio per Area Geografica

In genere è da preferire quando le esigenze specifiche di area lo richiedo-no o dove si intravedono i maggiori risparmi legati alla distribuzione territo-riale dell’organizzazione. Tipicamente più stabilimenti ubicati in zone limi-trofi (potrebbero, per esempio, condividere uno stesso magazzino) o esigenze civilistico/fiscali particolari di un paese ecc. Mi pare che anche qui valgano un po tutte le considerazioni fatte in precedenza considerando di poter vedere

48

come un'unica entità più strutture organizzative e quindi le conseguenti si-nergie derivanti dalla facilitata logistica progettuale.

L’approccio per Processo

È quello tipico che in genere si adotta su una media organizzazione. I processi vengono analizzati e sviluppati in senso orizzontale all’organizzazione ed il limite dell’ambito può essere scelto in funzione degli obiettivi strategici prefissati (al limite anche per singola area funzionale!). Questo riduce la complessità della struttura progettuale ma al contempo in-duce:

1. un probabile aumento delle interfacce temporanee per supportare i vari scenari di transizione per evitare il big–bang;

2. può richiedere rilavorazioni successive per garantire coerenza ed inte-grazione dei processi;

3. i benefici attesi sono circoscritti all’ambito di intervento.

4. può richiedere un minore impegno alla struttura in funzione della nume-rosità delle aree d’intervento e comunque incide sulla distribuzione temporale dei fabbisogni;

5. può allungare i tempi di realizzazione complessivi dell’intero processo di cambiamento.

49

Ora si capisce meglio perché non esiste una ricetta univoca di approccio ma, al contrario, ogni contesto va analizzato come caso a se e quindi valutato sia in funzione dei benefici attesi sia in relazione alla capacità di rispondere allo sforzo richiesto all’organizzazione, alla rapidità con cui si vogliono otte-nere i risultati, alla natura stessa del business dell’azienda ed in fine alla di-stribuzione ed ai vincoli geografici esistenti.

Durata di Progetto

Dimensioni Projectteam

Raggiungimentobenefici diintegrazione

InterfaccieTemporanee

Cambiamentiorganizzativi

Logistica di Progetto

Strategia diProcesso

StategiaOrganizzativa

StrategiaGeografica

Inferiore Maggiore

Inferiore Maggiore

Più lentamente Più velocemente

Più numerose Minori

Minori Maggiori

Più complessa Più semplice

Fig. 8– Confronto delle Strategie di Approccio

50

7. Come scegliere l’approccio?

Come abbiamo visto nel capitolo precedente non c’è un approccio stan-dard valido per tutte le situazioni; anzi, è vero il contrario. Ogni installazione ha una storia propria in quanto i fattori che incidono su questo processo deci-sionale sono molteplici e rivestono una certa complessità. L’esperienza ha insegnato che generalmente occorre sviluppare un piccolo progetto ad hoc (definiamolo master plan) che in un tempo ragionevolmente breve fissi un quadro sufficientemente stabile (Piano di attuazione) in cui vengano valutati, in funzione di tempi, vincoli, priorità, sistemi esistenti ed obiettivi strategici, tanto gli impatti che il nuovo sistema potrà avere sulla nostra azienda quanto i rischi connessi alla sua realizzazione, divulgazione ed accettazione. In altre parole

Situazione Attuale

Situazione Futura

Master Plan

Tempi, Vincoli, Obiettivi

Ambito Sistemi

BusinessCase

PianoAttuativo

GestioneCambiam.

Fig. 10 – Obiettivi del Master Plan

51

occorre definire una sorta di “piano regolatore” della fase realizzativa perché è necessario considerare che non è importante solo realizzare il sistema, ma è altrettanto fondamentale che l’utenza faccia suo il nuovo strumento, supe-rando le naturali resistenze al cambiamento.

Da questa prima valutazione è necessario che:

venga creato il disegno complessivo del nuovo sistema considerando an-che le necessità di software aggiuntivo;

individuare i possibili scenari di transizione per giungere alla configura-zione finale del sistema;

vengano identificati i primi macro Gap di copertura del nuovo sistema, rispetto ad una situazione in essere, che porti a definire le necessità di in-tegrazione al prodotto tanto con estensioni ad hoc quanto con l’utilizzo di moduli verticali e di software di terze parti;

occorre analizzare in dettaglio i costi/benefici per controllarne i ritorni;

definire l’infrastruttura tecnologica necessaria;

identificare un approccio realizzativo evidenziando criticità, rischi e/o punti di attenzione;

realizzare un primo piano complessivo di sviluppo dell’intero sistema; qui l’ottica deve essere quella di ottenere la migliore visibilità possibile delle attività e degli obiettivi in ambito ad ogni singola iniziativa proget-tuale da intraprendere e considerando, se possibile, tutte le iniziative ne-cessarie a rendere reale il cambiamento (c.f.r. Fig. 1 capitolo 1 – Impatti del cambiamento).

52

Top Management

Impatti sullePersone

Piani e ApprocciRealizzativi

Processi - SistemiScenari transitori

ImpattiOrganizzativi Business Case

Fig. 11 – Il Master Plan Tuttavia, e lo vedremo meglio in seguito quando parleremo delle motiva-

zioni che ci sono dietro la scelta di un approccio progettuale, chi si predispo-ne ad affrontare una implementazione ERP, deve avere ben chiaro quanto prodotto da un Master Plan; gli elementi di valutazione desunti da un Master Plan, infatti, devono essere comunque definiti e monitorati nelle fasi realiz-zative (a prescindere dalle dimensioni dell’azienda e/o dello stesso Master Plan), considerando che sono gli elementi che veicolano l’implementazione del sistema tanto in termini di ambito quanto di approccio, impatti sull’organizzazione e ritorno degli investimenti.

53

8. Che cos’è allora un ERP?

Da quanto abbiamo visto fino ad ora possiamo intuire che un ERP è mol-to di più che un semplice sistema applicativo. A questo termine, infatti, l’accezione comune degli informatici intendeva attribuire il significato di si-stema volto ad automatizzare i processi operativi di un generico utente, di una certa area funzionale dell’azienda (generalmente contabilità, personale ecc.), ma, come abbiamo visto, il sistema ERP va ben oltre questa accezione considerando che vi sono altre tipologie di utenza legate alla vita di un si-stema informatico: gli specialisti IT. A ben vedere, inoltre, le componenti che costituiscono ed integrano un sistema informatico sono molteplici e po-tremmo schematizzarle per esempio in questo modo:

∗ ∗ ∗ ∗ ∗ ∗ ∗

i componenti software applicativi; i componenti software di base e di ambiente; i componenti hardware di elaborazione; i componenti hardware di comunicazione; gli utenti utilizzatori (utenti finali); gli specialisti informatici; la documentazione specialistica di sistema;

54

∗ la documentazione utente;

che nel loro insieme: da un lato formano la struttura portante del sistema e dall’altra ne garantiscono il funzionamento, l’evoluzione, ne ricevono e for-niscono dati. Ricorrendo alla teoria dei sistemi, quello informatico, possiamo considerarlo un sistema aperto verso il mondo circostante con cui si instaura uno scambio di informazioni nell’ottica di raggiungere degli obiettivi di pro-cesso:

Hardwaredi

Elaborazione

Hardwaredi

Elaborazione

Hardwaredi

Comunicazione

Hardwaredi

Comunicazione

Softwaredi

Base

Softwaredi

Base

SoftwareApplicativoSoftware

Applicativo

DocumentazioneUtente

DocumentazioneUtente

DocumentazioneSpecialistica

DocumentazioneSpecialistica

UtentiFinali

UtentiFinali

SpecialistiSpecialisti

Sistema InformaticoSistema Informatico

Figura 12 – Il Sistema Informatico

Consideriamo ancora che tutti gli utenti del sistema, specialisti e utenti fi-

nali, possono avere la necessità di operare in “ambienti” diversificati e con strumenti specifici; questo vuol dire che anche al sistema informatico, può essere richiesto un supporto diversificato adatto agli specifici obiettivi opera-tivi dei vari utenti. In tal senso il sistema ERP dovrebbe supportare le varie necessità; è come se fosse un unico grande ambiente omogeneo e strutturato in cui, tutti i suoi componenti, sono riconoscibili ed indirizzabili per ogni ti-pologia di utenza. Si deve considerare, infatti, che anche gli insiemi degli u-tenti e degli specialisti non sono dei monoliti, nel senso che non tutti hanno le stesse caratteristiche, ma al loro interno sono riconoscibili ruoli e capacità eterogenei corrispondenti ad altrettante necessità operative diverse fra di lo-

55

ro. Fatta questa premessa necessaria a chiarire che esiste una necessità di di-versificazione di ruoli e responsabilità connessi all’utilizzo di un sistema, vediamo più da vicino quali sono gli ambienti (i più rilevanti) che un ERP mette a disposizione dei suoi utenti:

1. L’ambiente Office

È l’ambiente tipico dell’office automation dove troviamo funzioni quali la posta elettronica, la gestione delle sale riunioni e delle aule, la possibilità di condividere una propria agenda con quella dei collaboratori e di gestire l’archiviazione di documenti. Ci potrebbe essere una funzione importante che consente di attivare “flussi di lavoro” che veicolino le attività da svolgere quotidianamente. Su questo aspetto, legato alla possibilità di definire proces-si custom non cablati cioè nelle funzioni standard dell’ERP, torneremo me-glio quando vedremo le possibilità offerte dal work flow; qui basti ricordare che all’interno di un ambiente office è possibile attivare quei processi che in qualche modo vedono protagonista l’utente. In altre parole il sistema propo-ne, guidando l’utente, una serie di attività correlate ad un processo più ampio che veda accomunate le attività di altri utenti: un esempio può essere costi-tuito dalle attività inerenti il processo di autorizzazione delle Richieste di Acquisto (a volte cablato in modo standard nel sistema). A fronte della nasci-ta di una r.d.a., infatti, il sistema può gestire il flusso autorizzativo, associato a quella tipologia di richiesta, proponendo a tutti gli utenti delegati le funzio-ni di autorizzazione e di indagine previste. Tutte le funzioni di office posso-no essere utilizzate anche in integrazione con gli strumenti già in uso al mo-mento della installazione del sistema o possono costituire un’opportunità là dove tali strumenti non esistono.

2. L’ambiente degli strumenti di supporto

Costituisce l’insieme degli strumenti dedicati agli specialisti IT o ad uten-ti che comunque hanno il compito di definire il modo con cui l’ERP dovrà

56

funzionare (es. analisti di organizzazione, process owner ecc.). È un ambien-te piuttosto articolato che comprende:

♦ l’ambiente di sviluppo di nuovi programmi e moduli (nuove funzioni e-stensive del prodotto standard);

♦ gli strumenti di personalizzazione dei supporti di comunicazione (office, tracciati records, flussi ecc.);

♦ il Customizing ovvero i progetti di personalizzazione dei moduli applica-tivi (contabilità, logistica ecc.);

♦ il modello di riferimento dei processi aziendali gestiti;

♦ l’ambiente di gestione del work flow;

♦ l’ambiente di gestione delle connessioni di sistema con l’ambiente ester-no (altri sistemi, web ecc.);

♦ il repository degli oggetti contenuti nel sistema;

♦ gli ambienti di monitoring ed amministrazione del sistema (performance, carichi, log, risorse, trasporti ecc.).

3. L’ambiente di riferimento del sistema

Raggruppa tutti gli strumenti di interesse personale dell’utente collegato col sistema: i valori di default (dati individuali e preferenze), l’attivazione di altre sessioni, la gestione dei propri lavori, la coda di stampa, il passaggio dati a strumenti di office (es. MS Excel) ed altro ancora. Sono cioè quegli strumenti individuali di gestione delle informazioni di cui abbiamo visto nel capitolo dedicato ai sistemi informati aziendali e che consentono, tra le altre cose, l’estrazione delle informazioni contenute nel sistema e la loro integra-zione in strumenti di informatica individuale.

57

4. Le Aree Applicative

Contengono tutte le funzioni dedicate all’attività dell’Utente finale e sono raggruppate in Aree; per esempio:

1. logistica e produzione

2. contabilità

3. risorse umane

4. sistema di reporting.

Rientrano nell’area logistica e produzione tutte le funzionalità relative a-gli Acquisti, Gestione dei materiali, i magazzini, la manutenzione, la gestio-ne della produzione, della qualità e dei servizi, il ciclo delle vendite, la logi-stica operativa. Costituiscono l’area contabilità le funzionalità relative alla contabilità generale, clienti, fornitori e patrimoniale, la contabilità gestionale ed il relativo reporting, la gestione dei programmi di investimento, la piani-ficazione aziendale, il consolidato e la tesoreria. Sono raggruppate nell’area delle risorse umane tutte le funzioni relative alla gestione e amministrazione del personale, la rilevazione presenze, la simulazione ed il calcolo delle re-tribuzioni, la gestione dell’organizzazione aziendale e la gestione delle tra-sferte. Unica particolarità di questo quadro è rappresentato dalla gestione dei progetti che per la sua duplice natura (contabile e operativa), la possiamo ri-trovare tanto nell’area logistica quanto in quella contabile. Il sistema di re-porting agglomera il reporting direzionale, i sistemi di reporting di ogni area applicativa (viste in dettaglio in precedenza) e strumenti di creazione indivi-duale di report estemporanei (ritroviamo nuovamente gli strumenti indivi-duali). Questi ultimi, comunque, generalmente non vengono affidati agli u-tenti finali del sistema in quanto il proliferare incontrollato degli stessi re-port, potrebbe influire (anche pesantemente in funzione del numero di utenti

58

abilitati a tali funzioni) sulle performance complessive del sistema; ecco allo-ra che si preferisce attribuire l’utilizzo di tali strumenti a personale IT o co-munque a particolari utenti, che assumo il ruolo di gestori della richiesta ed eventualmente quella di realizzatori della soluzione là dove non la demandi-no ad un fornitore esterno all’organizzazione.

Come si può vedere il sistema ERP ha la giusta pretesa di voler abbrac-ciare l’azienda a 360° ma al di là delle funzioni presenti nei vari moduli ap-plicativi, che possono essere più efficacemente illustrate con presentazioni mirate del prodotto, è importante osservare come tali funzioni debbano esse-re personalizzate in modo da aderire quanto più possibile alle aspettative de-gli utenti e là dove questo non sia possibile, occorre che vengano analizzate e realizzate funzioni ad hoc che comunque si dovranno integrare al contesto. Come abbiamo avuto modo di osservare nei capitoli precedenti, il sistema ERP è sufficientemente flessibile da adattarsi all’ambiente in cui viene calato in virtù del fatto che le sue funzionalità sono pilotabili attraverso l’impostazione di tabelle esterne ai programmi. Un esempio che aiuti a capire meglio il concetto può essere costituito dalla modalità di visualizzazione dei partitari clienti e fornitori: è possibile definire non solo la struttura di ogni singola riga (cioè quali elementi caratteristici del cliente o dei documenti vo-glio vedere) del partitario ma posso costruire tante viste quante sono le mie esigenze di indagine e definire totali per ogni campo valorizzato e presente nella mia struttura di riga. Potremmo andare oltre dicendo che, anche qui, quasi tutte le anagrafiche di base del sistema, possono essere gestite (visua-lizzate e trattate) in modo personalizzato; si possono definire quali campi ve-dere, quali rendere obbligatori e/o facoltativi, quali operazioni abilitare sugli archivi (ma anche chi è abilitato a fare che cosa) e così via. Questo modo di impostare esternamente i parametri di funzionamento, consente al sistema di potersi adattare alle più diverse esigenze non solo nell’ambito della singola installazione, ma anche tra installazioni differenti (ovvero per tipologie di industry/cliente). Perché tutto ciò sia possibile occorre che il sistema acquisi-sca gli opportuni parametri necessari allo scopo e, quasi generalmente, gli strumenti preposti a rendere questa operazione praticabile, sono costituiti dalle funzioni di personalizzazione contenute nell’ambiente degli strumenti di supporto.

59

5. La personalizzazione del sistema

Tra gli attributi che caratterizzano un’installazione ERP vogliamo menziona-re la complessità dell’ambiente in cui il sistema dovrà operare. Questo è ge-neralmente funzione delle dimensioni dell’azienda (ma non solo!) ed alcuni parametri che possono aiutarci a misurarla, possono essere il numero degli utenti che opereranno sul sistema, il numero degli eventi e dei processi da gestire, quante tipologie di oggetti e così via. Quello che qui importa rilevare non è “come” si stabilisce la grandezza dell’azienda (tali driver incidono an-che sullo sforzo richiesto per la realizzazione è ovvio) quanto “in che modo” occorre organizzarsi per approcciare la personalizzazione del sistema e più in generale l’implementazione dello stesso; in questo senso un ERP offre diver-se alternative:

mappa di implementazione standard di sistema (come riferimento);

mappa di accesso a tutte le funzioni di personalizzazione cucita ad hoc per quella particolare installazione;

mappe di accesso diversificate per obiettivi di installazione (progetto);

accesso mediante strategia implementativa legata al progetto (metodolo-gia di sviluppo del progetto già prevista per qualche ERP);

ognuna delle quali è adatta per ogni tipo di installazione che come già detto dipende dalle dimensioni dell’azienda. In generale possiamo dire che, se per piccole e medie installazioni può essere sufficiente definire un solo progetto, per installazioni più complesse, dove più gruppi di lavoro possono interagire e sovrapporsi nelle attività, conviene diversificare i progetti (p.e. per area funzionale, processi o quant’altro) e seguire un metodo che garanti-sca il raggiungimento degli obiettivi.

Una volta istallato sui computer del cliente, il sistema ERP è pronto per essere parametrizzato in modo consono ai requirement dell’utente e quindi di poter funzionare senza dover ricorrere a lunghi periodi di “parallelo” con i vecchi sistemi legacy. In termini realizzativi tutto questo si traduce in tempi di implementazione più accettabili e costi minori rispetto al tradizionale ap-

60

proccio del fare ad hoc per cui, per i responsabili informatici delle società, si pone il classico problema del “make or buy”. Ovviamente anche l’approccio progettuale cambia rispetto alla tradizionale realizzazione legacy: benché possa essere pensato un approccio diversificato, in funzione della tipologia e delle dimensioni dell’azienda, la novità sostanziale, come vedremo meglio più avanti, si caratterizza per il fatto che il sistema già esiste, che occorre ri-levare le differenze rispetto tanto al modo di operare in azienda quanto alle funzionalità offerte dai sistemi legacy (analisi dei gap), valutare gli impatti delle estensioni in termini di costi/benefici, progettare e pianificare il cam-biamento agevolando l’introduzione e l’accettazione del nuovo sistema. Si deve sempre tenere presente che un ERP ha cablate al suo interno logiche di funzionamento che derivano da centinaia di installazioni presso i clienti più disparati ed ha la pretesa (probabilmente a ragione) di voler fornire strumen-ti e funzionalità per ogni area aziendale. In altre parole il sistema si propone in forma integrata al fine di supportare le necessità di integrazione aziendale e di processo, così come abbiamo visto nei paragrafi precedenti; è proprio lui a farsi carico di quei controlli a basso valore aggiunto, di garantire l’univocità delle codifiche, di gestire la coerenza dei flussi lungo tutti i pro-cessi, di gestire il verificarsi degli eventi di business ed indirizzare l’operatività conseguente in modo coordinato.

61

9. Ma è proprio necessario fare un progetto?

Benché, come abbiamo visto, lo sforzo realizzativo sia strettamente legato alle dimensioni dell’azienda, tuttavia, l’approccio “per progetto” all’implementazione di un ERP è una delle garanzie di successo in quanto costringe a misurare e monitorare costantemente tutte le attività connesse al processo di realizzazione del cambiamento. Cercando una definizione pos-siamo dire che:

Progetto è, in genere, sinonimo di "piano" o "dise-gno" di qualcosa da realizzare e, nella sua accezio-ne più ampia, rappresenta l’insieme delle azioni e delle risorse (persone incluse) che concorrono alla realizzazione di un insieme di prodotti che ne costi-tuiscono l'obiettivo finale. Ne consegue che la sua gestione debba essere finalizzata tanto a disciplina-re le azioni delle persone che partecipano al pro-cesso, quanto a definire gli oggetti da produrre nel suo corso in modo che rispondano a criteri di otti-mizzazione nel rispetto di vincoli, tempi e costi predefiniti.

Ne deriva che: se per un verso è importante osservare le cose da un punto

di vista quantitativo dello sforzo richiesto, è altrettanto evidente che si rende necessaria una gestione razionale ed efficace del processo al fine di non va-nificare i benefici attesi; cioè si può discutere circa le dimensioni del proget-

62

to, il suo assetto organizzativo, il tempo dedicato dalle risorse e quant’altro ad esso connaturato ma che non si può prescindere da un approccio struttura-to sia in termini qualitativi che quantitativi. In altre parole occorre che duran-te tutto il processo realizzativo, si abbia sempre la percezione misurata di tut-te le variabili in gioco e, poiché non ci si trova di fronte ad un processo pre-codificato (si pensi, per esempio, alla diversità coi processi produttivi mani-fatturieri dove la distinta base fornisce il modello realizzativo tanto in termi-ni di fabbisogni quanto di cicli lavorativi necessari alla realizzazione dei prodotti), l’approccio progettuale e le relative tecniche di gestione, sono le uniche in grado di offrire un supporto, adeguato ed efficiente, a chi ha la re-sponsabilità del raggiungimento degli obiettivi. D’altronde si potrebbe vede-re la cosa da un altro punto di vista considerando di dover gestire:

• le attività da svolgere; • la necessità di integrazione; • la gestione dei rischi di insuccesso; • i prodotti da ottenere; • i tempi, i costi, la qualità attesi; • gli acquisti da fare ed i tempi di approvvigionamento coerenti con le

necessità di delivery; • la gestione e motivazione delle risorse coinvolte; • la formazione; • la comunicazione; • la gestione del business case;

in modo coordinato ed integrato, in un lasso di tempo ben definito e ma-

gari con scenari evolutivi intermedi che consentano di fruire dei benefici at-tesi il più presto possibile. Quando prima si alludeva all’inesistenza di un processo realizzativo codificato a priori, si intendeva sostenere la irripetibili-tà sistematica del percorso realizzativo considerando che ogni installazione di un qualsiasi ERP è un caso a se (cioè è difficile che si ripropongano le stesse condizioni e necessità su aziende diverse) e quindi, poiché un proget-to, per sua natura, è un fatto unico e irripetibile, le tecniche per una sua ge-stione precipua si prestano bene a calzare il processo implementativo consi-derando l’adeguatezza degli strumenti e la dimostrata efficacia negli svariati campi di applicazione. D’altro canto i processi produttivi per progetto sono tipici delle società di consulenza informatica che per loro natura sono “co-

63

strette” a seguire metodi e tecniche di project management al fine di garantir-si e garantire il delivery dei prodotti; e tali approcci, per implicazione, asso-nanza e tipologia di obiettivi sono riproposti soprattutto per avere una visio-ne condivisa del processo produttivo e dell’ambito d’intervento, dei rischi e delle attività tese al loro contenimento ed alla loro gestione, delle risorse coinvolte da ambo le parti e del loro impegno, dei prodotti attesi e delle mo-dalità con cui saranno realizzati. Insomma un sentire comune per evitare sor-prese dopo!.

Anche un ERP (forse per questi motivi o altri ancora) propone un approc-cio progettuale all’implementazione del sistema e, come visto in precedenza, il prodotto è corredato di alcuni oggetti, che aiutano nel processo di gestione del progetto stesso, benché tali strumenti debbano essere integrati (anche se non vale per tutti i casi) e trovare una loro collocazione in un quadro più ge-nerale del rapporto di fornitura.

64

10. Come è fatto un progetto per un ERP?

Anche il progetto di implementazione di un sistema ERP, come ogni altro progetto, è caratterizzato da un proprio ciclo di vita; risulta cioè segmentato in fasi ognuna delle quali raggruppa un’insieme di attività che di volta in volta, nel tempo, dovranno essere effettuate per realizzare i prodotti previsti. L’insieme delle attività da svolgere viene definita WBS (in inglese Work Breakdown Structure) ed è rappresentata da una struttura gerarchica “ad al-bero rovesciato” in cui ogni macro attività è scomposta in attività più ele-mentari; l’insieme delle attività, rappresentate graficamente seguendo una distribuzione temporale ed in funzione di priorità e vincoli, prende il nome di Gantt. Allo stesso modo anche l’insieme dei prodotti, PBS (Product Brea-kdown Structure), viene scomposto seguendo uno schema gerarchico ad al-bero e questo permette di poter identificare ed aggregare i singoli prodotti di dettaglio (delivarable) in modo da capire come sono costituiti i prodotti pre-visti dalla fornitura. Va da se che esiste un collegamento stretto tra la WBS e la PBS, in modo che si comprenda bene quali sono i prodotti che verranno realizzati e da quali attività, e tale legame è in genere la base comune, tra fornitore e cliente, affinché quest’ultimo abbia piena visibilità tanto relati-vamente a quello che gli verrà fornito, quanto alle modalità ed ai tempi con cui verranno realizzati i prodotti previsti.

65

Livello Gestionale(Rif. Contratto)

PBS - Prodotti

Livello Operativo(Dettaglio)

Livello Gestionale(Controllo Milestone)

WBS - Attività

Livello Operativo(Settimanale)

Deliverable

Attività/DeliverableProdotti/Deliverable

Coerenza

MetodologiaTecnica

Fig. 13 – Relazione PBS e WBS

Dalla figura 13 si evince che esistono due livelli di dettaglio per la relazione PBS/WBS uno Gestionale l’altro Operativo e che questi si distinguono per il diverso livello di dettaglio necessario tanto per la gestione quanto per le viste di analisi del progetto. Mentre il livello gestionale è caratterizzato da uno stato avanzamento mensi-le e pone l’enfasi sugli aspetti contrattuali della fornitura (i macro prodotti, le macro attività, le milestone di consegna, fatturazione e completamento delle attività ecc.) e sul controllo economico del progetto, il livello operativo defi-nisce in dettaglio gli oggetti, schedula in modo fine attività e deliverable, for-nisce un avanzamento settimanale/quindicinale per ogni area progettuale (o sottoprogetto). Ogni fase progettuale, inoltre, è caratterizzata dai processi tipici di gestione del progetto stesso e che potremmo riassumere in: ♦ processi di attivazione; ♦ processi di pianificazione; ♦ processi di esecuzione; ♦ processi di controllo; ♦ processi di chiusura;

66

schematizzabili come segue:

A ttivaz io n e P ian ificaz io n e E sec u z io n e C o n tro llo C h iu su ra

F a se d i P ro g e tto

Figura 14 – Schema delle attività di gestione progetto in una Fase

E “personalizzabili” per ogni progetto in funzione dei requisiti di qualità

sul controllo della fornitura, dei tempi a disposizione, dei vincoli contrattuali e così via. Questi processi, in pratica, costituiscono l’insieme delle attività di gestione del progetto (per intenderci quelle che saranno in carico al project manager) per ogni fase definita, in generale, dal contratto di fornitura e non sono da confondersi con le attività tipiche di realizzazione legate al pro-dotto ERP. Volendo schematizzare il progetto nel suo insieme avremmo una figura (Fig. 15):

Attivazione Pianificazione Esecuzione Controllo Chiusura

Fase 1

Tempo

Attività

R e a l i z z a t i v eGestione Progetto


Fase 1


Fase 1

Fig. 15 – Gantt delle attività di Progetto

67

C’è ancora un’altra considerazione da fare che riguarda l’organizzazione di un progetto. Abbiamo visto che ci sono delle attività da svolgere per rea-lizzare dei prodotti, che è necessario avviare le attività, controllare costante-mente il loro “avanzamento” ed infine, al termine di ogni fase, eseguire quel processo di chiusura che sancisca il termine della fase per evitare che il pro-getto si trasformi nella classica “fabbrica del duomo”. Resta ancora da defi-nire una dimensione, nel progetto, che spieghi sostanzialmente quali sono le figure di riferimento del progetto stesso, che ruoli devono ricoprire, quali responsabilità devono avere ed infine a chi devono rispondere. Tutto questo è contenuto nella OBS (Organization Breakdown Structure) che rende eviden-te a tutte le parti coinvolte nel progetto, “chi fa che cosa” e “perché”. Anche qui non esiste una ricetta valida per tutte le situazioni; in linea di principio si può sostenere che l’organizzazione efficiente è quella orientata a finalizzare gli obiettivi di ogni singola parte e che ogni attore, partecipa al progetto con pari dignità e fornisce il contributo più adeguato alle esigenze del progetto stesso. Provando a tradurre in pratica il concetto, possiamo osservare che, all’interno del progetto, convivono generalmente due “anime”(2): ♦ quella di chi conosce il sistema ERP e come si implementa (il fornitore

di specialisti); ♦ l’altra di chi conosce bene l’azienda in cui il sistema dovrà operare, è re-

sponsabile degli obiettivi di cambiamento e dà al progetto le competenze sui processi, sulla popolazione che dovrà adottare il nuovo sistema e sa valutare gli impatti organizzativi sulla sua struttura (la società cliente);

allora uno schema organizzativo potrebbe essere come la Fig. 16:

(2) in realtà le cose potrebbero essere più complesse di quanto viene qui considerato e tuttavia, in questa sede, si farà riferimento ai casi più frequenti senza avere la pretesa di completezza.

68

ComitatoGuida

ComitatoGuida

Capo ProgettoCliente

Capo ProgettoCliente

Capo ProgettoFornitore

Capo ProgettoFornitore

Specialisti

• SAP• Formazione• Tecnologie• Processo

Specialisti

• SAP• Formazione• Tecnologie• Processo

Riferimentidi altre

Funzioni

Riferimentidi altre

Funzioni

Responsabilidi Processo

Responsabilidi Processo

Utenti Chiaveper

Processo

Utenti Chiaveper

Processo

Fig. 16 – Schema dell'organizzazione di progetto

in cui:

Il comitato guida è l’entità organizzativa di maggior livello a cui il pro-getto risponde; è composto dal top management delle due organizzazioni (cliente e fornitore) ed è preposto a:

rimuovere i problemi ed i conflitti non risolvibili in seno al progetto; valutarne l’avanzamento in termini di prodotti ed attività con riferi-

mento agli aspetti contrattuali; assicurare che tutte le risorse necessarie siano disponibili nei tempi

previsti; gestire il cambiamento nel suo insieme; supportare il progetto nella comunicazione.

Capo progetto cliente è il responsabile verso il comitato guida del rag-

giungimento complessivo degli obiettivi di progetto. Per esso predispone gli stati avanzamento lavori (SAL contrattuali) ed è garante, verso la sua organizzazione societaria, della rispondenza del sistema ai requisiti ri-chiesti. Si avvale della collaborazione di riferimenti funzionali aziendali (personale, formazione, comunicazione, IT ecc.) e coordina le attività progettuali dei responsabili di processo e degli utenti chiave. Partecipa alle riunioni di SAL di progetto e ne approva i risultati.

69

Capo progetto fornitore è responsabile delle attività progettuali realiz-

zative del sistema; coordina le attività degli specialisti e predispone i piani di fase, ne controlla l’avanzamento e redige i documenti di SAL di progetto (contrattuali ed operativi). Richiede le autorizzazioni e le ap-provazioni del caso ed è garante di tutte le specifiche contrattuali di for-nitura nei confronti del capo progetto cliente.

Responsabili di processo sono utenti di altissimo livello (generalmente

responsabili di funzione) che hanno una profonda conoscenza dei pro-cessi di loro competenza e dei legami che questi hanno con il resto dell’azienda. Autorizzano le scelte funzionali di comportamento del si-stema ed approvano i documenti di pertinenza.

Utenti chiave ottimi conoscitori dei processi aziendali, vivono fianco a

fianco con gli specialisti al fine di fornire i requirement funzionali e di processo e contribuire alla scelta delle opzioni di soluzione applicabili al sistema. Sono a stretto contatto con i responsabili di processo, a cui in genere riportano funzionalmente, approvano la documentazione di com-petenza e costituiscono il nucleo portante delle risorse aziendali destinate a facilitare l’adozione del sistema in azienda.

Specialisti sono le figure del fornitore preposte alla costruzione del si-

stema. A questi signori è richiesta una grande capacità propositiva sia in termini di soluzioni applicative che di capacità di analisi degli impatti che le nuove adozioni portano sui processi del cliente. Redigono la do-cumentazione progettuale e realizzano la manualistica di supporto al si-stema. Progettano le sessioni di addestramento dell’utente ed eventual-mente si fanno carico della relativa erogazione. Generalmente a queste persone viene anche chiesto di ricoprire un ruolo di supporto nei processi di comunicazione a sostegno della diffusione e dell’accettazione del si-stema.

70

11. Ma serve anche una metodologia? Certo che è necessario avere una metodologia! Da un punto di vista pretta-mente di approccio al problema, un metodo costituisce il “vademecum” del buon informatico; il senso di questo deriva dal fatto che non esiste un mo-dello universalmente riconosciuto nell’approccio alla realizzazione dei si-stemi informatici e quindi occorre fare di necessità virtù. Questo vuol dire che ogni metodologia può essere costituita dagli oggetti più disparati, come suggerito dell’esperienza storica delle società di consulenza che le adottano, e generalmente può contenere, in forma molto dettagliata, l’insieme delle at-tività e dei prodotti elementari di una certa tipologia di fornitura, le motiva-zioni e gli obiettivi da raggiungere per ogni fase metodologica, i contenuti e le modalità di passaggio da una fase alla successiva, il contesto progettuale ed i relativi strumenti di supporto (per esempio i driver di stima degli impe-gni e/o uno strumento di Project Management ecc.). Senza voler approfondi-re questo argomento (probabilmente ci vorrebbe un’opera ad hoc), ma limi-tandoci a ricercare le motivazioni più pratiche legate alla conduzione di un progetto, come abbiamo visto, esistono due necessità di gestione sul proget-to: il controllo del progetto stesso (che implica l’adozione di una Metodo-logia di Project Management) e la gestione delle attività inerenti la realizza-zione del sistema (metodologia tecnica di realizzazione) e ad entrambe le necessità occorre dare delle risposte adeguate sia in termini di strumenti che di procedure operative. Queste ultime, in particolare, rivestono un ruolo fon-damentale in quanto devono garantire da un lato, il raccordo del progetto con le strutture aziendali (e questo vale sia per il fornitore che per il cliente relativamente ai rispettivi sistemi di controllo costi, qualità, fatturazione, ge-stione delle risorse ecc.) e dall’altra permettere al progetto di avere piena au-

71

tonomia di gestione nel rispetto dei ruoli che i singoli attori di tutte le parti, sono chiamati a ricoprire nel processo realizzativo.

72

12. In cosa consiste il processo realizzativo?

Come abbiamo già visto, le motivazioni che spingono verso un approccio progettuale e le implicazioni che da questo derivano, costituiscono la fonte della maggior parte dei problemi e delle attività di cui un capo progetto deve farsi carico; poiché i rischi di insuccesso sono elevati, ecco allora che l’adozione di una metodologia, fornisce un approccio sufficientemente strut-turato e si configura come “un faro che segnala la rotta ai naviganti”. Ora il lettore troverà che tanto in letteratura quanto presso le più quotate società di consulenza sono già presenti ed adottate le più disparate metodologie realiz-zative; quello che qui interessa è mettere in evidenza gli elementi caratteriz-zanti il processo di costruzione di un sistema ERP ed i possibili approcci nei vari momenti progettuali. Solo per avere un riferimento concettuale possia-mo pensare di individuare quelli che mi sembra siano i momenti salienti nel-la costruzione del Sistema:

73

D is e g n o e R e a liz z a z io n e

E s te n s io n iIn te rfa c c e

C o n v e rs io n iD o c u m e n ta z io n e

F o rm a z io n e

S u p p o rto T e c n o lo g ic o

P re s tu d io F a ttib ilità P ro to tip o

S y s te m T e s t

P o s t A v v io

A v v io

Fig. 17 – I processi di costruzione del sistema

prestudio fattibilità prototipo disegno e realizzazione – estensioni, interfacce, conversioni e documen-

tazione system test supporto tecnologico formazione avvio supporto post–avvio Che, nella maggior parte dei casi, sono presenti in tutte le metodologie

proposte, anche se le attività vengono espresse con aggregazioni e denomi-nazioni differenti. Si noti che tali processi costituiscono solo un sottoinsieme delle attività prevedibili in un progetto e, generalmente, sono presenti in quella metodologia tecnica cui abbiamo fatto riferimento in precedenza; tali attività, inoltre, dal punto di vista del capo progetto, sono da integrare con le attività tipiche di gestione e controllo del progetto stesso sia in termini di a-vanzamento che di gestione dei prodotti, dei costi, della qualità e del rischio. Qui non vogliamo proporre una metodologia di implementazione progettua-le; semplicemente evidenziare le tappe necessarie ed alcuni degli approcci

74

possibili per ogni momento di costruzione ponendo l’attenzione su quello che è importante fare e su che cosa ci si deve aspettare da ogni processo. Il lettore troverà che qui non vi sono riferimenti ai punti di vista dei vari attori del processo (Costruttore dell’ERP, fornitore, cliente, consulenti ecc.) ma più semplicemente si è cercato di evidenziare i motivi che sottintendono le necessità realizzative – viste soprattutto in un’ottica di efficacia dell’intero processo costruttivo del nuovo sistema basato su un ERP – ponendo al centro dell’attenzione l’oggetto da costruire, il perché è necessario realizzarlo ed in che modo è possibile giungere al suo completamento.

1. Il prestudio – è chiaro come si intende procede-re?

Obiettivo dell’attività è quello di fornire un prima visione dell’intero sce-nario realizzativo alla luce delle istanze di cambiamento. Nei capitoli prece-denti abbiamo fatto riferimento alla opportunità di effettuare un master plan e quello che qui viene definito prestudio, vuole proprio riproporre la necessi-tà di definizione di un piano, di una strategia complessiva di approccio al progetto/programma(3) e della sua opportunità sia in termini tecnologici che di ritorni attesi. Per una rivisitazione di questo processo si faccia quindi rife-rimento al capitolo: come scegliere l’approccio? Vogliamo solo ricordare che in funzione delle complessità da affrontare potrebbe essere necessario avviare più iniziative progettuali, magari differite nel tempo, in modo da non pregiudicare la continuità di funzionamento della realtà di impatto. Là dove, per esempio, ci si trova a dover “smontare” un grosso sistema legacy (magari anche estremamente integrato!) ed in funzione dell’approccio più convenien-te (per processo, geografico o organizzativo), si possono configurare scenari transitori di regime differenziato del sistema, con vincoli di priorità o so-vrapposizione tra le singole iniziative progettuali (per esempio si può consi-derare di dover utilizzare anche parti di sistemi legacy i cui progetti di manu-

(3) In questa sede col termine Programma si intende un’iniziativa coordinata di più progetti che, pur insistendo su ambiti diversi, devono comunque essere ricondotti ad un quadro più generale tanto in termini di gestione dei conflitti quanto per possibili sinergie e/o scenari evo-lutivi di costruzione del sistema a tendere.

75

tenzione evolutiva potrebbero rientrare nell’ambito dell’iniziativa complessi-va), che potrebbero richiedere una gestione coordinata di programma. In altre parole occorre riassumere la visione strategica che dà l’avvio alla realizza-zione del sistema considerando

i motivi che possono condurre alla scelta di un sistema ERP; il contesto di cambiamento in cui l’iniziativa si collocherà; l’opportunità dell’investimento; la capacità di assorbimento dell’iniziativa da parte dell’organizzazione le necessità tecnologiche, formative e di revisione della struttura azien-

dale (quest’ultima indotta non solo dall’utilizzo di un nuovo strumento ma soprattutto derivante dalla necessità di cambiamento delle strategie di business);

il controllo coordinato dei fattori critici di successo; la gestione dei rischi;

e creando la consapevolezza della necessità di un forte impegno del

management a fondamentale garanzia del raggiungimento degli obiettivi a cui l’iniziativa è rivolta. È proprio in questa ottica che l’intero sforzo proget-tuale assume un senso di reale fattibilità; una forte determinazione del top management è uno dei più importanti fattori di successo verso cui occorre prestare la massima attenzione. Questo, infatti, legato alla necessità di “vei-colare” il cambiamento (comunicazione), unito ad un approccio interfunzio-nale (integrato – come vedremo meglio più avanti – in termini tanto di anali-si delle necessità quanto di scelta delle soluzioni) e ad una più ampia delega decisionale “verso il basso”, concorre a costituire l’insieme degli ingredienti fondamentali che garantiscono il successo di una revisione dell’assetto in-formativo dell’azienda. Del resto sono fondamentali l’attenzione ed il sup-porto proattivo alle tappe di riferimento del progetto, l’aiuto a superare i pro-blemi di progetto ed interprogettuali, la costante comunicazione e presenza tanto sul progetto quanto per conto di questi verso il resto dell’azienda. In altre parole non è pensabile che il tutto sia riconducibile ad un semplice pro-getto informatico a cui “l’Azienda” presta la solita occhiata distratta e priva di reale interesse; per i più “distratti”, infatti, l’informatica in azienda non è considerabile un asset ma solo un costo fisso o al massimo un problema per soli specialisti del settore! E tuttavia, come ormai acquisito dagli utenti più maturi, “l’informatica è diventata una cosa troppo seria per essere lasciata in

76

mano agli informatici”. Allora, se questo è vero, gli interrogativi che possono far riflettere sono in parte riassumibili, per brevità, come di seguito:

Quanto l’azienda riesce a rispondere alle nuove esigenze (obiettivi di strate-gia aziendale, vincoli/obbligazioni esterni, necessità tecnologiche ecc.) senza il rinnovo del suo sistema informativo? Quali sono le opportunità offerte dalle nuove tecnologie? Può l’azienda far-ne a meno? Quanto costa cambiare? È conveniente? Quanto l’ambiente esterno (mercato, competitori, azionista ecc.) è condizio-nante e spinge verso il cambiamento? Che priorità dare all’iniziativa? Quanto incide sull’azienda l’impatto di cambiamento (in termini organizza-tivi, di sforzo, di risorse ecc.)? Può essere sostenuto? Come assecondarlo? E le risposte a questi quesiti, come si intuisce, possono misurare “il livello di attenzione” che il management aziendale deve rivolgere all’iniziativa e ri-chiedere anche ai fornitori esterni al fine di condividere con loro obiet-tivi, rischi e valori del successo. È fondamentale considerare il valore da attribuire al nuovo sistema informa-tivo aziendale, metterne in evidenza la caratteristica di essere non solo veico-lo abilitante il cambiamento ma anche strumento a supporto del raggiungi-mento degli obiettivi di business e quindi contributo importante a creare va-lore per l’azienda. Il nuovo modo di lavorare che rompe col passato e che necessita di essere interiorizzato prima di produrre i suoi effetti, sarà interio-rizzato quando la gente si renderà conto dei benefici dell’integrazione che, superando le barriere interfunzionali, indurrà efficacia ed efficienza nei pro-cessi seppur convivendo con scetticismo ed un iniziale maggior assorbimen-to di impegno. Il management deve essere consapevole che la coscienza del-le potenzialità dello strumento sarà sentita dall’organizzazione solo dopo che il progetto avrà portato a termine le sue attività realizzative ed avrà raggiunto i suoi obiettivi. E proprio per superare quelle forze che si contrappongono al cambiamento si dovrà ricorrere ad un più adeguato sistema premiante – che

77

da un lato sarà volto alla motivazione e dall’altra farà percepire l’importanza attribuita all’iniziativa – alla comunicazione, al coinvolgimento, al sostegno ed alla propositività che costituiranno gli ingredienti indispensabili per creare un clima che agevoli l’iniziativa di cambiamento e le imprima una connota-zione positiva e di successo.

2. La fattibilità – siamo sicuri di raggiungere gli o-biettivi attesi? Obiettivo fondamentale di questo processo è quello di fugare ogni possibile dubbio circa la realizzabilità dell’intera iniziativa in modo da approfondire, per ogni singolo progetto, tutti gli aspetti visti nella fase di prestudio e con-siderando di dover fornire maggior precisione informativa a quanti rappre-sentano le parti in causa e che quindi hanno responsabilità decisionale sull’intero processo realizzativo. Vedendo in dettaglio gli obiettivi di questo processo troviamo (Fig. 18):

SITUAZIO- Best Practi-”

Fig. 18 – La fattibilità

ATTUALE

ISTANZE CAMBIAMENTO

MODELLO TENDERE

MODELLO RIFERIMEN-

Integrazio- Estensio- Interven- sui proces- Interven-

ERP

FUNZIONALI-

78

la definizione degli obiettivi di progetto, della sua organizzazione e dei ruoli di tutti i componenti il team;

l’analisi di dettaglio della situazione in essere e di quella desiderata con evidenza dei GAP rispetto alle funzionalità/processi del sistema ERP standard;

la costruzione del modello futuro del sistema e degli scenari intermedi; l’individuazione degli impatti di cambiamento; la definizione dell’approccio realizzativo; l’analisi di dettaglio costi e benefici; la definizione del piano delle attività successive.

Cominciamo con l’osservare che una focalizzazione sugli obiettivi è il

primo passo per capire che cosa il progetto deve fare; esiste, cioè, il proble-ma di dover definire quali elementi della strategia aziendale sono a carico del progetto (che quindi deve raggiungere in termini di risultati quali/quantitativi misurabili!) e di questi quelli che sono direttamente riconducibili alla costru-zione del nuovo sistema informatico o comunque da esso condizionati. Il motivo di tale chiarezza lo ritroviamo nella opportunità di cominciare a rac-cogliere gli elementi di dettaglio per la definizione dell’analisi costi/benefici e nella necessità di capire quali altre attività il progetto dovrà mettere in campo per ottenere quei benefici non riconducibili all’adozione di un ERP. Qui si pone anche un altro problema: definire quali obiettivi aziendali siano da ritenersi ad esclusivo carico del committente e quali invece gli aspetti su cui ragionevolmente ci si può aspettare un contributo del fornitore il quale, generalmente, pone più l’enfasi sulla necessità di modellare i requirement, finalizzandoli alla ricerca delle possibili soluzioni funzionali del nuovo si-stema, piuttosto che supportare il processo di sviluppo di tutte le iniziative necessarie a gestire il cambiamento – questo tuttavia non è sempre vero e di-pende, come abbiamo già avuto modo di dire, dal tipo di fornitura, dalle ca-ratteristiche del fornitore stesso e da quanto questi sia in grado di (ovvero preveda nel suo core business e quindi possieda in termini di risorse, compe-tenze e know–how) erogare servizi diversi dalla mera costruzione del sistema ERP. Inoltre, in un ottica di definizione di una strategia di sviluppo e rilascio del sistema, è chiaro che gli obiettivi dell’azienda committente giocano un ruolo fondamentale; proprio in questa fase vengono ripresi gli assunti del prestudio e rapportati alla specifica realtà di progetto individuando, in modo dettagliato, i legami esistenti tra gli obiettivi aziendali definiti ed il contribu-to del sistema al raggiungimento degli stessi – al fine di valutarne il benefi-

79

cio indotto dalla sua adozione – e di conseguenza, le priorità esistenti tra gli obiettivi, veicolano il piano di sviluppo e la strategia di rilascio dei singoli prodotti previsti dalla fornitura stessa. Se è importante definire che cosa il progetto deve produrre non si può pre-scindere dalle implicazioni che questo assume nell’ambito della definizione contrattuale del rapporto di fornitura e dalle modalità di realizzazione della fornitura stessa. E tuttavia, considerando la vastità dell’argomento e le speci-ficità esistenti su ogni progetto, qui ci si limiterà ad osservare che esiste la necessità di far collimare le esigenze di gestione e controllo della fornitura con le attività ed i prodotti attesi dalla stessa; in linea di massima possiamo dire che il piano di realizzazione complessivo deve tenere conto di entrambi gli aspetti e definire le modalità di raccordo tra le due viste, implementando un approccio ed un percorso progettuale finalizzati da un lato a soddisfare le varie esigenze dall’altra a rendere trasparente per tutti l’intero processo di sviluppo del progetto (o processo di produzione).

80

Livello Gestionale(Rif. Contratto)

PBS - Prodotti

Livello Operativo(Dettaglio)

Livello Gestionale(Controllo Milestone)

WBS - Attività

Livello Operativo(Settimanale)

Metodologia Attività/DeliverableProdotti/Deliverable

Previsione

Consuntivo

Coerenza

Deliverable

Fig. 19 – Raccordo necessità progettuali PBS4 e WBS5

Definiti quindi gli obiettivi, i prodotti, le attività ed i tempi di progetto resta da stabilire con quale organizzazione il progetto debba operare. Soprattutto nelle realtà più complesse uno schema organizzativo (la OBS ovvero Orga-nization Breakdown Structure) viene definito – generalmente in funzione delle attività – per legare logicamente le persone alle attività; inoltre asso-ciando ad essa una matrice delle relazioni che definisca figure, responsabilità e ruoli sia all’interno del progetto che fra questi e l’esterno, è possibile otte-nere una mappa che veicoli e garantisca una comunicazione efficiente. La gestione della comunicazione, infatti, credo debba ritenersi come un “pro-blema” da pianificare, avviare e controllare ritenendolo un progetto nel pro-getto. Come abbiamo già avuto modo di osservare l’entropia generata su un progetto (ovvero il numero di disturbi che su di esso si riversano) è diretta-mente dipendente dalle sue dimensioni, dal numero delle relazioni che si in-staurano tra gli interlocutori, dal numero di clienti e fornitori da gestire con-temporaneamente (la complessità aumenta in modo esponenziale!) e non ul-timi dagli obiettivi e dalle aspirazioni di ogni interlocutore stesso. Inoltre esi-

progetto (ovvero il numero di disturbi che su di esso si riversano) è diretta-mente dipendente dalle sue dimensioni, dal numero delle relazioni che si in-staurano tra gli interlocutori, dal numero di clienti e fornitori da gestire con-temporaneamente (la complessità aumenta in modo esponenziale!) e non ul-timi dagli obiettivi e dalle aspirazioni di ogni interlocutore stesso. Inoltre esi-

4 Product Breakdown Structure (PBS) definisce la struttura gerarchica dei prodotti previsti dal progetto fino ad un livello ritenuto sufficiente ad identificare gli oggetti fisici della fornitura stessa (deliverable). 5 Work Breakdown Structure (WBS) costituisce l’insieme delle attività di progetto articolate secondo uno schema gerarchico di raggruppamento delle attività più di dettaglio.

4 Product Breakdown Structure (PBS) definisce la struttura gerarchica dei prodotti previsti dal progetto fino ad un livello ritenuto sufficiente ad identificare gli oggetti fisici della fornitura stessa (deliverable). 5 Work Breakdown Structure (WBS) costituisce l’insieme delle attività di progetto articolate secondo uno schema gerarchico di raggruppamento delle attività più di dettaglio.

81

ste, per il progetto, la necessità di soddisfare le esigenze informative tanto rivolte a divulgare contenuti ed obiettivi quanto a recepire necessità ed aspet-tative; da tutto questo si intuisce che una comunicazione efficiente necessita di essere finalizzata in funzione degli interlocutori, pianificata per garantire efficacia e controllata in tutti i suoi aspetti più salienti comprendendo tra questi anche e soprattutto la gestione dei feedback.

2.1. As is & to be – la situazione attuale è come quella de-siderata? Stabilito che cosa fare, chi fa che cosa, quando, come e che cosa produce (definiamole linee guida del progetto) siamo pronti per avviare le vere e pro-prie attività progettuali:

l’analisi della situazione in essere e di quella desiderata che porta il gruppo di lavoro a definire i processi ed i sistemi attuali (as is), l’eventuale revisione dei processi ed il grado di copertura delle funzioni ERP rispetto alla nuova situazione desiderata (to be). Da questo tipo di analisi è possibile capire che cosa il gruppo di lavoro del fornitore dovrà realizzare in aggiunta alle funzioni standard dell’ERP (soluzione ai gap) perché il sistema risponda in modo adeguato alle istanze di rinnovamento dell’ambiente in cui dovrà essere “calato”.

MODELLO ATENDERE

ANALISI GAP

Fig. 20 – as is & to be

82

È altresì vero – come abbiamo già avuto modo di dire – che spesso l’introduzione di un sistema ERP in azienda è motivo di stimolo verso il cambiamento e considerando le best–practice6 cablate all’interno del prodot-to, generalmente conviene farsi guidare dal sistema nel ridefinire processi, ruoli e modalità di relazione tra gli attori dello stesso processo.

2.2. As is & to be – come gestire il gap? In altre parole e come abbiamo visto nei capitoli precedenti, non sempre tutti i requisiti di processo espressi da una specifica organizzazione, possono tro-vare soluzione all’interno del sistema ERP standard. Questi, infatti, pur a-vendo la caratteristica di un sistema molto esteso e generalizzato, proprio per questa sua natura, può non possedere funzioni specifiche per esigenze parti-colari. Vogliamo anche ricordare che per grandi gap, tipici per esempio delle verticalizzazioni per tipologie di aziende, esiste la possibilità di poter adotta-re soluzioni verticali standard (industry solution) che indirizzano le macro differenze che generalmente possono presentarsi in una installazione ERP. Pensiamo, per esempio, alla problematica delle joint venture accounting in ambito OIL o alla gestione del ciclo attivo in ambito utility e così via; ogni specificità di industry può trovare un’adeguata copertura funzionale che, al limite, è ancora possibile integrare con le specificità di ogni singola organiz-zazione. Quello che qui si vuole sottolineare è comunque la necessità di do-ver affrontare i gap in modo attento considerando di poter assumere approcci diversi anche in funzione del tipo di soluzione che si presume di adottare: ♦ è possibile “estendere” le funzioni standard del sistema con pezzi di sof-

tware che si affianchino all’architettura già definita dell’ERP e che quin-di non tocchino il suo standard;

♦ è possibile “modificare le funzioni standard” per adeguarle alle esigen-ze specifiche dell’installazione (altamente sconsigliato se si vogliono as-sumere atteggiamenti neutri o “indolore” rispetto all’adozione di release successive del prodotto);

6 Questo termine possiamo tradurlo come “migliori soluzioni”. Considerando che il contenuto di un sistema ERP, tanto in termini di processi che di funzioni gestite, è il risultato dell’evoluzione del prodotto derivata dall’esperienza maturata su migliaia di installazioni sparse per tutto il mondo, mi pare che il termine possa essere ritenuto accettabile.

83

♦ per superare il problema è possibile adottare “soluzioni organizzative“ diverse dalla prassi corrente aziendale considerando che generalmente, tali soluzioni, trovano applicazione “fuori” dal sistema (attività manuali regolate da “una norma” interna aziendale o attività automatizzate con altri strumenti diversi dal sistema ERP ed eventualmente ad esso integra-ti).

Ora, in presenza di gap, si intuisce bene che sia necessaria una gestione mira-ta di molteplici fattori condizionanti che scaturiscono da alcune considera-zioni di fondo; in genere sono elementi legati da un lato alla efficacia del si-stema nella copertura dei processi (quindi alle implicazioni sulle attività di business), e dall’altra alle politiche di evoluzione dell’intero sistema infor-mativo. In estrema sintesi per ogni gap rilevato occorre valutare: 1. l’impatto che il gap genera sul business in termini di disefficienze provo-

cate sulle attività utente, mancato raggiungimento di benefici attesi ecc.: ovvero quanto sia indispensabile per l’avvio del sistema in esercizio;

2. la sua priorità per esempio in funzione della tipologia di attività, di u-tenza, di condizionamento ai benefici ecc.;

3. l’entità della modifica ed il suo impatto sul sistema in termini di integra-zione;

4. la convenienza a realizzare una soluzione “automatica” ed integrata (co-sto vs beneficio);

5. la sua fattibilità in termini di impatto dei tempi di realizzazione sulle mi-lestone di progetto e quindi sulla strategia di rilascio del sistema dovendo considerare eventuali ripianificazioni delle attività;

6. la fattibilità in funzione dello sforzo supplementare richiesto al gruppo di lavoro tanto del cliente quanto del fornitore. Qui l’elemento critico è quasi generalmente lo sforzo richiesto al gruppo di lavoro del cliente; è normale che l’organizzazione del cliente si trovi ad operare sul progetto con risorse distolte dalle funzioni organizzative coinvolte dal progetto stesso per cui richiedere altri sforzi può compromettere le aspettative di operatività corrente delle linee.

Si consideri, inoltre, che non essendoci una ricetta valida per tutte le oc-

casioni, può essere ragionevole supporre l’adozione di una struttura predi-sposta alla gestione dei gap; pensiamo ad un “osservatorio” di livello suffi-cientemente alto (p.e. un comitato guida supportato dal responsabile dei si-

84

stemi informativi societari) che sostenga o reindirizzi le scelte di progetto in modo coerente ed in funzione delle politiche e delle strategie di sviluppo del sistema informativo aziendale. Una funzione “sulle parti” che abbia gli ele-menti e le leve per incidere sulle scelte di progetto assicurando la coerenza di tutte le componenti che influiscono e determinano la scelta finale: la fattibili-tà, i costi ed i benefici, l’evoluzione del sistema, la sostenibilità e così via. Il processo complessivo di gestione dei Gap potrebbe essere riassunto come nella Fig. 21:

Gruppo di Progetto

Analisi Requisiti• Richieste• Opportunità• Criticità• Impatti

ValutazioneRequisiti

RevisioneModelloProcessi

AnalisiCoperturaFunzionaleSAP

ConfermaModelloProcessi

CensimentoGap

Analisi eSoluzioneGap

ApprovazioneSoluzione

Gruppo di Progetto OrganizzazioneReferenti di altre Funzioni

Gruppo di Progetto OrganizzazioneReferenti di altre Funzioni

Capo Progetto Comitato - Resp. FornitoreResp. Sistemi Informativi

Fig. 21 – Il processo di gestione dei gap

Dove è importante rilevare la presenza di tutti i riferimenti aziendali nella ri-levazione dei requisiti (ricorderete la trasversalità dei processi rispetto alle

85

funzioni aziendali) a garanzia di copertura di tutte le esigenze di processo. La presenza di un responsabile del Fornitore nel momento di approvazione delle soluzioni, è dettata dalla necessità di valutare esigenze di nuovi sviluppi (e-stensioni) e di raccordare eventuali impatti contrattuali alla capacità produt-tiva profusa sul progetto. Ovviamente lo schema su riportato deve ritenersi un semplice riferimento soprattutto per la gestione di quei gap che rivestano impatti significativi sul progetto e/o sul sistema standard; impatti “minori” possono essere gestiti direttamente all’interno del Progetto tanto in seno all’analisi dei requisiti quanto a livello di soluzioni che non richiedono il co-involgimento del top management aziendale.

2.3. Il modello del sistema - occorre definire degli scenari intermedi?

Abbiamo detto della necessità di definire un modello to be che, tenendo conto delle nuove esigenze organizzative e di processo, contenga un nuovo modello applicativo basato tanto su soluzioni ERP quanto su applicazioni e-sistenti e/o di terze parti. In buona sostanza deve essere definita la “mappa delle applicazioni” a tendere che sarà in grado di sostenere il raggiungimento dei benefici attesi dal nuovo assetto informativo e tuttavia, l’implementazione complessiva del modello, potrebbe non essere completata secondo una logica “tutto insieme e allo stesso tempo” (detta anche big bang) ma, al contrario, potrebbe seguire una “strategia”, per passi successivi, in funzione delle modalità definite da un master plan di cui accennavamo nel capitolo dedicato all’approccio. L’intero ciclo realizzativo del nuovo sistema, per complessità, convenienza, vincoli e priorità può condurre alla necessità di definire più momenti (fasi) di rilascio in esercizio del software portando così a degli scenari temporali intermedi dell’assetto applicativo complessivo dell’azienda. È come fare delle istantanee del sistema in momenti diversi, ognuna delle quali rappresenta proprio uno scenario intermedio; in pratica questo generalmente si traduce in impatti sull’utenza che, non di rado, può vedere trasformarsi la propria operatività tanto in termini di maggiore ma-nualità quanto di difformità di impiego di supporti e sistemi informatici.

86

Mappa Applicativa scenario 1Situazione al 1.1.1999

AssetsAcquisti

Magazzini

Logistica

Impianti Vendite

GestioneProgetti


Logistica

Impianti Vendite

GestioneProgetti


Logistica

Impianti(Produzione) Vendite


Impianti(Produzione)

ERPFin

ContProc

ERPFin

Cont

Proc

ERPFin

Cont

Prj

Ass

Ass

Proc

ERPFin

Cont

PrjAss

Sal


AssetsAcquisti

Magazzini

Logistica

Impianti Vendite

GestioneProgetti


Logistica

Impianti Vendite

GestioneProgetti


Logistica

Impianti(Produzione) Vendite


Impianti(Produzione)

ERPFin

ContProc

ERPFin

Cont

Proc

ERPFin

Cont

Prj

Ass

Ass

Proc

ERPFin

Cont

PrjAss

Sal

Figura 22 – Gli scenari transitori del sistema a tendere

Ora è chiaro che la necessità di contenimento del disagio utente è l’elemento di rilievo da tenere presente nella definizione di uno o più transi-tori. E tuttavia tale necessità va coniugata con le esigenze di architettura del sistema complessivo che dovrà tenere in debito conto delle interazioni che necessariamente dovranno essere stabilite tra sistemi legacy e sistema ERP. Il problema che ci si pone, in buona sostanza, è quello di garantire il massi-mo dell’automazione dei processi (quindi ridurre al minimo le attività ma-nuali) impiegando tanto sistemi in essere (li abbiamo definiti Legacy) quanto moduli ERP “ricuciti” tra loro mediante apposite interfacce che garantiscano il flusso delle informazioni, in entrambe le direzioni, come da aspettative di processo. Anche qui non esiste una ricetta valida sempre ed applicabile in ogni circostanza, ed allora conviene che a guidare siano al solito: le esigenze connesse al raggiungimento degli obiettivi, i vincoli architetturali di sistema

87

(quanto i sistemi siano tra loro connettibili) e le implicazioni di processo in termini di sostenibilità da parte dell’utenza. L’importante è avere sempre ben chiaro l’approccio definito, l’architettura del sistema a tendere, il percorso per attuarla, ed infine un piano realizzativo che, pur passando per scenari in-termedi, ne garantisca il raggiungimento in termini di sostenibilità, fruibilità ed in tempi ragionevoli per l’organizzazione impattata.

2.4. Quali sono gli impatti di cambiamento?

Tra gli aspetti caratterizzanti il cambiamento l’impatto indotto dal nuovo sistema è probabilmente tra quelli da affrontare con sistematicità per garanti-re l’utilizzabilità e l’accettabilità dei nuovi strumenti informatici a supporto dei processi. La valutazione di tali impatti passa anche qui attraverso la rile-vazione della situazione attuale e la definizione di una situazione futura (as is e to be) in termini di: ♦ nuove opportunità, vincoli e linee guida; ♦ valutazione degli impatti organizzativi e di nuovi fabbisogni di profes-

sionalità; ♦ work flow indotti dall’impiego del nuovo sistema; ♦ profili professionali da costruire in ERP; ♦ definizione dell’approccio alla formazione7 e di un piano realizzativo; ♦ definizione del piano di comunicazione legato alle attività di progetto; tutti aspetti che afferiscono la sfera dell’operatività sul sistema e che quindi in questa sede vediamo esclusivamente con l’ottica del progetto realizzativo ERP consci che il tema di gestione del cambiamento è ben più ampio e non riducibile ai pochi elementi qui riportati. Quello che occorre chiedersi in buona sostanza sono i classici quesiti circa cosa deve intendersi per cambia-mento: che cosa cambia, quali iniziative devono essere adottate per agevola-re il cambiamento ed infine chi sono gli attori deputati a gestire il cambia-mento. Le caratteristiche salienti del cambiamento, quindi, pongono

7 In questa sede il termine più corretto potrebbe essere addestramento in quanto ci si riferisce più ad abilità (saper fare) sul nuovo strumento che ad acquisizione di nuove competenze di business.

88

l’accento su due aspetti di fondo che sottolineano l’impatto che l’organizzazione aziendale risente in termini di “rottura” rispetto al passato e questo da anche la misura di quanto grande sia il cambiamento:

quali e quante strutture organizzative sono coinvolte;

su quali aspetti (efficacia, efficienza …) occorre che l’organizzazione catalizzi la sua attenzione.

Altri aspetti non trascurabili, inoltre, sono sicuramente costituiti dal con-tributo e dalle modalità con cui la comunicazione può supportare e favorire le iniziative di cambiamento (qui l’accento è posto in termini di attività di progetto e non nel senso di impatto su tutta l’organizzazione). È chiaro che il cambiamento sarà tanto più ampio quanto più l’organizzazione coinvolta si avvicinerà all’insieme delle strutture aziendali e quanto più sarà necessario rivisitare i processi di gestione, controllo ed operativi della stessa organizza-zione. In tal senso si intuisce bene che il contributo del top management e dei responsabili delle singole funzioni coinvolte risulta determinante in quanto organismi propulsori e “naturali”, delle energie aziendali, tanto in termini di carisma che di posizione gerarchica in seno all’organizzazione. La necessità di una forte sponsorship è tanto più evidente quanto maggiore è l’ampiezza del cambiamento che, a dispetto degli scettici, degli illusi e degli snob (at-teggiamenti molto diffusi in chi non valuta correttamente il salto qualitativo che la propria organizzazione si accinge a compiere), è l’elemento fonda-mentale per una iniziativa di successo. Allora si pone un problema:

COME GESTIRE IL CAMBIAMENTO?

Riportandoci in un’ottica di progetto possiamo affermare che gli elementi da prendere in considerazione sono sostanzialmente:

la definizione ed il controllo di un piano di gestione del cambiamento in-tegrato con attività di comunicazione. In sostanza il progetto deve sem-pre essere in grado di “navigare” supportando le proprie iniziative e ri-chiedendo il sostegno là dove si rendesse necessario; è inoltre determi-nante la diffusione, ai livelli più appropriati, delle proprie attività e dei risultati conseguiti finalizzando la comunicazione al coinvolgimento ed all’accettazione delle proprie proposte;

89

il capo progetto, in particolare, deve sempre costituire un punto di rife-rimento in grado di guidare e sostenere le iniziative di cambiamento fa-cendo suo il piano definito ed integrandolo opportunamente con le nor-mali attività di costruzione del sistema. Questo si tradurrà in un piano coordinato e di maggiore efficacia delle iniziative progettuali conside-rando che le azioni rivolte al cambiamento si tradurranno in cose reali da fare e verificare;

il progetto deve, infine, avere la capacità di coinvolgere le unità funzio-nali impattate vincendo le resistenze e motivando le risorse a vario titolo coinvolte. Ovviamente l’attenzione alle risorse dovrà essere tanto mag-giore quanto maggiore è l’impegno che il progetto chiede loro ed infine, risulterà fondamentale, la capacità di realizzazione di una “rete di rela-zioni” volte da un lato al superamento degli ostacoli (sponsor) e dall’altra a veicolare le azioni del cambiamento (supporter).

In particolare il piano di gestione del cambiamento dovrà essere strutturato per tutte le fasi del progetto e sarà volto a presidiare ed ottenere il successo del progetto sia nella sua fase realizzativa del sistema sia durante il successi-vo corso di esercizio dello stesso. Più propriamente possiamo dire che devo-no essere affrontati tre temi di fondo in tale ambito: ♦ il successo in termini applicativi riferendoci all’utilizzabilità degli am-

bienti di base e delle funzioni di sistema; ♦ il successo in termini di conoscenza di che cosa è cambiato nei processi -

il nuovo modo di lavorare introdotto da ERP, le nuove procedure orga-nizzative, i nuovi ruoli e le nuove responsabilità;

♦ il successo in termini consoli-dati nel tempo – implicazioni dell’integrazione, comporta-menti adeguati anche del management, riconoscimento e coinvolgimento nel “nuovo” di cui ci si sente protagonisti, motivazioni dell’ambiente nuovo e stimolante;

ImpattiProceduraliNormativi

Organizzativi

Formazione edAddestramento

Documentazionee Supporto

Utenti

Monitoraggiopost-avvio

90

Abbiamo detto che il successo del progetto passa attraverso

l’accettabilità del sistema e la sua utilizzabilità; ecco allora evidente la ne-cessità, da parte del progetto stesso, di mettere in campo attività e prodotti che possano agevolare tali processi: la descrizione degli impatti indotti sull’organizzazione dai nuovi processi (chi fa che cosa lungo tutta la catena); la formazione e l’addestramento degli utenti (meglio se ad illustrare il si-stema è il collega con maggior autorevolezza e carisma che parla lo stesso linguaggio) ai nuovi strumenti ed ai nuovi ruoli; la documentazione di prodotto che aiuti “a navigare” tra processi e sistema ed il supporto, nella fase di avviamento del sistema, dei colleghi che hanno avuto modo di vivere il progetto e che quindi possono aiutare meglio ogni singolo utente; Il monitoraggio della fase di avviamento in termini di attività svolte, docu-menti gestiti, problemi rilevati, risolti, pendenti, tempestività del supporto fornito ecc.. Sono alcuni spunti delle azioni che il progetto può mettere in campo insieme ad attività di comunicazione rivolte al gruppo di progetto e/o verso interlocu-tori esterni:

91

Il Piano di Comunicazione

Modalità Messaggi chiave Destinatari Entro il Kick-off Resp.: Rossi

1. Obiettivi di progetto 2. Piano draft 3. O.B.S. 4. P.B.S. 5. Calendario week n° 1

Project Manager Resp. Area Funzionale Responsabili di Processo Utenti Chiave Gruppo Fornitore Referenti funzioni coinvolte

22.01.1999

Over-view ERP Resp.: Bian-chi

1. L’integrazione 2. ERP in generale 3. I moduli in uso 4. Discussione su as-is 5. Necessità hardware

Project Manager Responsabili di Processo Utenti Chiave IT manager Referente Organizzazione

30.01.1999

Il processo di definizio-ne TOBE Resp.: Verdi

1. Le attività previste 2. Il lavoro dei team 3. I prodotti attesi 4. Le priorità 5. Il concetto di Gap

Project Manager Resp. Area Funzionale Responsabili di Processo Utenti Chiave

15.02.1999

Work Shop Resp.: Rossi

1. Team Building (dilemma del prigioniero) 2. Rilevazione Aspettati-

ve (questionario) 3. Cena

Project Manager Resp. Area Funzionale Responsabili di Processo Utenti Chiave Gruppo Fornitore Referenti funzioni coinvolte

18/2/1999

…………. ………….. ………… ………..

Fig. 23 – Il cambiamento ed il piano di comunicazione

2.5. Come lo costruiamo il sistema? L’Approccio alla realizzazione e la definizione del piano delle attività suc-cessive costituisce il passo fondamentale per racchiudere in un solo quadro generale le modalità, i tempi e gli sforzi necessari per giungere ad un sistema ERP in esercizio ed integrato nell’ambiente preesistente. Nei paragrafi pre-cedenti abbiamo avuto modo di definire:

92

• la situazione attuale; • la situazione attesa tanto in termini sistemici che di necessità indotte dal

cambiamento; • la copertura del nuovo sistema e quindi i moduli ERP necessari ed i gap

emersi; • gli eventuali scenari transitori prima della situazione a tendere; ci troviamo quindi di fronte al problema di stabilire che cosa occorre fare per raggiungere la situazione a tendere, chi farà che cosa, quando, perché e con quali strumenti e modalità. In una sola parola abbiamo la necessità di un pia-no complessivo di progetto che ci guidi passo per passo verso un traguardo di prodotti da realizzare e tempi da rispettare per garantire costi, qualità e be-nefici attesi. Se si vuole, in tale ambito, emerge un problema di impostazione progettuale che passi per tutti quegli elementi e condizioni determinanti il successo dell’iniziativa. Ma al di là degli aspetti progettuali su cui abbiamo già avuto modo di soffermarci, un altro aspetto che qui conviene rimarcare è l’approccio alla costruzione del sistema; come vedremo meglio successiva-mente parlando di prototipo, con ERP ci si trova a dover affrontare in modo desueto, rispetto ai classici canoni dei sistemi custom, le attività ed i modi di costruire il sistema. Le metodologie usate per la costruzione dei sistemi in-formatici, adottate negli anni passati, prevedevano che tali oggetti fossero “cuciti su misura” degli utenti che li avrebbero impiegati e pertanto l’approccio che gli informatici generalmente seguivano8 prevedeva: 1. l’analisi delle esigenze dell’utente; 2. l’elaborazione autonoma delle specifiche funzionali ed architetturali del

sistema (autonome perché l’utenza generalmente non aveva tali capaci-tà);

3. la realizzazione del software; 4. la condivisione con l’utente di quanto realizzato; 5. il rilascio dell’applicazione in esercizio;

8 Anche qui occorre ricordare che non esiste uno schema metodologico universale ma ogni società di consulenza informatica prevede di adottarne una propria. In ogni caso lo schema che qui riportiamo e sufficientemente generico e prevede comunque i passi fondamentali che interessano.

93

e nella maggior parte dei casi succedeva che le attività di condivisione met-tessero in risalto un fatto: lo specialista informatico non aveva capito bene oppure l’utente non si era spiegato affatto. Al solito, parlando due lingue diverse - per esempio “il ragionierese” e “l’informatichese” – non ci si ren-deva conto che il significato attribuito alle parole risentiva più del retro pen-siero dei protagonisti che degli elementi oggettivi di confronto per cui, tanto il processo produttivo quanto i relativi risultati, li possiamo riassumere come fig. 24:

Richiesta utente Percezione Specialista

ElaborazioneSpecifiche

Oggetto inCondivisione

CompromessoFinale

Fig. 24 – Il processo produttivo del software custom

A proposito di linguaggi diversi mi viene in mente una bellissima storia

di cui protagonisti sono un gatto ed un topo; state a sentire. “Era una bellissima giornata di sole ed il topolino, dopo un dolce risveglio, pensò bene di fare quattro passi per il quartiere ed incontrare i soliti amici con cui scambiare quattro chiacchiere. Detto fatto si ritrovò a percorre un lungo viale alberato la cui frescura rendeva ancora più piacevole quella splendida giornata di primavera. Mentre passeggiava godendosi l’aria friz-zante che gli riempiva i polmoni e lo faceva sentire padrone del mondo, ecco che in lontananza, si stagliò l’ombra minacciosa di un gatto che, in meno che non si dica, lo vide e prese a rincorrerlo. Il povero topo assalito dal panico non trovò di meglio che infilarsi in un tombino che purtroppo non aveva altre vie di uscita se non la grata da cui si era infilato. Appena so-praggiunse, il gatto provò più volte a prendere il malcapitato topolino che, per sua fortuna, godeva di un tombino piuttosto profondo e ricoperto da una grata che ne impediva al gatto l’accesso. Visto il momentaneo scampato pe-ricolo, il topo tirò un lungo sospiro di sollievo e pensò di attendere qualche

94

minuto prima di tentare una sortita. Rinfrancato da quegli attimi di attesa il malcapitato tentò di tirar fuori la testa ma il gatto, che era ancora lì ad at-tenderlo, lasciò partire un robusto gancio che per poco non tramortì il pove-ro topolino. Passò ancora qualche minuto e la scena si ripeté ancora come prima mandando il cuore in gola al topo che non trovava modo di trarsi da quella scomoda posizione. Fu così che lo sfortunato animale decise di rima-nersene lì, buono buono, fintanto che non fosse giunta la sera per cui potesse sperare che il gatto fosse in qualche modo distratto dal suo proposito. Men-tre era lì che pensava alla sua sorte il topolino sentì abbaiare un cane che sembrava correre in direzione del suo tombino e così, tranquillo e rincuora-to, decise di uscire convinto che il gatto avesse trovato qualche motivo di preoccupazione così come era toccato a lui. Prese quindi il coraggio a quat-tro mani e deciso, si tirò fuori dal tombino ma il gatto … ne approfittò per acchiapparlo tra le sue grinfie. Il topo non ci capì più nulla, si rivolse al gatto e disse: - ma scusa, non hai sentito arrivare il cane? – ed il gatto di rimando: - E già, caro mio, certo che ho sentito. Però ho imparato una cosa: se oggi non parli almeno due lingue … non mangi! -”

Bene, dopo questa dotta assertazione sulla comunicazione e sull’entropia generabile, oggi, dopo qualche evoluzione dei processi produttivi, possiamo dire che la realizzazione di un sistema ERP può seguire un altro approccio e che quindi è pensabile che siano superate le incomprensioni in modo che gli attori della comunicazione possano anche condividere l’oggetto in quanto immediatamente visibile e valutabile da entrambi. Come abbiamo avuto mo-do di vedere, il sistema ERP è un oggetto reale già realizzato e predisposto tanto con logiche integrate di processo quanto di programmi già funzionanti che, per adeguarsi alla realtà della specifica organizzazione, hanno bisogno di essere “personalizzati” sulla base delle specificità dell’utente. Questo è un gran vantaggio rispetto al realizzare dei software custom che, non esistenti, devono essere progettati e quindi realizzati (da qui la generazione di entropia tra gli interlocutori); allora i termini del problema possono essere considerati risolti perché basta mettere insieme l’utente (o meglio l’utente chiave) e lo specialista che, insieme, costruiscono il sistema, ne verificano il funziona-mento e ne garantiscano l’adeguatezza alle esigenze di business. Tale ap-proccio possiamo definirlo prototipale in quanto:

non è necessario passare tutto il processo produttivo prima di vedere i prodotti attesi dalle attività realizzative;

95

permette un approccio “per passi successivi” ovvero la costruzione di un oggetto dopo l’altro e solo dopo che il precedente “funzioni” come pre-visto;

i tempi di processo possono essere più lunghi rispetto all’approccio cu-stom ma si ha una maggiore garanzia di successo;

ogni oggetto è immediatamente condivisibile tra gli interlocutori che ne valutano l’adeguatezza;

il sistema è già in grado di gestire dati “veri” cioè significativi della re-altà quotidiana in cui dovrà operare e quindi risulta più familiare all’utente;

è possibile iterare sul singolo oggetto fintanto che gli interlocutori non raggiungono un accordo e senza, per questo, dover ripercorrere tutto il processo nel suo insieme ma solo alcuni suoi passi (customizing);

l’oggetto viene documentato e reso disponibile per il test di integrazione solo quando gli interlocutori lo accettano come definitivo.

In pratica è come ripercorrere il processo produttivo per ogni oggetto da rea-lizzare ed i risultati sono condivisi man mano che i prodotti vengono resi o-perativi in modo che alla fine si evitino spiacevoli sorprese!. Infatti il limite dell’approccio custom era proprio quello di proporre la verifica e l’accettazione dei prodotti solo alla fine del processo realizzativo e “tutti in-sieme”. La costruzione prototipale, seppure richieda maggiori costi realizza-tivi (p.e. presenza utente richiesta in modo efficace), ha tuttavia il grande pregio di superare il problema della sorpresa finale, rende trasparente a tutti gli interlocutori le attività e gli obiettivi da raggiungere per ognuna di esse (i prodotti ed il loro funzionamento), offre maggiori garanzie di successo e quindi alla fine può risultare l’approccio più efficiente in quanto non sono necessari ricicli su grossi pezzi di sistema così come è probabile per i metodi tradizionali.

Ma allora: come lo costruiamo il sistema a tendere?

96

Proc

ERPFin

Cont

PrjAss

SalImpianti

(Produzione)

MagazzinoFisico

LogisticaOperativa

TrasportiMare

Pipe Line

Budget EnterpriseControl

Proc

ERPFin

Cont

PrjAss

SalProc

ERPFin

Cont

PrjAss

SalImpianti

(Produzione)

MagazzinoFisico

LogisticaOperativa

TrasportiMare

Pipe Line

Budget EnterpriseControl

Figura 25 – Il Sistema a Tendere

In parte a questa domanda abbiamo già fornito una prima risposta: occor-re innanzi tutto costruire il sistema ERP, poi progettare e realizzare le inter-facce che saranno impiegate per consentirgli di comunicare con i sistemi e-sterni e quindi di realizzare i vari transitori definiti; occorrerà progettare e realizzare i programmi di conversione in funzione dell’approccio definito per le varie tipologie di dati che il sistema dovrà trattare (cioè per quei dati per cui si è prevista una conversione automatica dai sistemi esistenti), progettare e realizzare le sessioni di formazione dell’utente finale, i materiali didattici ed infine il manuale di utilizzo del sistema. Ma non è tutto; perché l’insieme degli oggetti realizzati sia coerente, occorre verificare che funzionino corret-tamente sia autonomamente che tutti insieme, ed infine, che siano approvvi-gionati e resi disponibili al progetto gli ambienti hardware di sviluppo, for-mazione, test ed esercizio del sistema, che si formino gli utenti finali e che si avvii in esercizio il sistema seguendo le modalità e gli scenari di transizione previsti. Quindi siamo appena all’inizio di questa avventura. In ogni caso ci sono tutti gli elementi, seppure ad un livello accettabile per le stime, per predisporre un piano complessivo e sufficientemente accurato del-le attività successive. Allo stato attuale del progetto, infatti, ci si trova ad a-vere queste conoscenze:

97

1. quali funzioni ERP saranno implementate; 2. i temi di cambiamento e gli strumenti da realizzare per supportare il pro-

cesso di accettabilità ed utilizzo del sistema; 3. quali altre funzionalità aggiuntive dovranno essere progettate e realizzate 4. i tempi e le modalità di esercizio del sistema a tendere (i transitori); 5. i sistemi con cui ERP dovrà colloquiare e quindi le interfacce che occor-

rerà realizzare; 6. i sistemi attuali da cui sarà necessario attingere i dati per le conversioni e

quindi il numero di conversioni automatiche da progettare e realizzare. In altre parole abbiamo tutti gli ingredienti per definire un piano realizzativo delle fasi successive del progetto stimando opportunamente tanto lo sforzo richiesto al fornitore di servizi quanto quello necessario all’organizzazione cliente, alle attività che ci porteranno a realizzare e controllare che il sistema funzioni correttamente, a formare gli utenti e ad avviare il sistema in eserci-zio.

2.6. Conviene continuare nella realizzazione del progetto?

L’analisi dei costi e dei benefici probabilmente ci aiuta a rispondere a questa domanda; nel corso delle pagine precedenti abbiamo avuto modo di focalizzare e definire in un dettaglio sufficiente: • gli obiettivi che si vogliono raggiungere in termini di benefici attesi; • lo sforzo richiesto per la realizzazione complessiva del progetto (ovvero

i costi).

Siamo pronti per valutare l’opportunità economica dell’iniziativa che, seppure costituisca un elemento decisionale importante, tuttavia non è da considerarsi l’unico da un punto di vista della strategia aziendale. Senza vo-ler entrare nel merito dei motivi che spingono ad assumere delle decisioni, in questa sede ci si limiterà a delineare per sommi capi gli elementi di base che occorre prendere in considerazione per un’analisi dei valori economici in

98

gioco. Innanzi tutto cominciamo con l’osservare che su questo argomento i ruoli del fornitore e del cliente seguono una logica di interdipendenza nel senso che: Il fornitore di servizi

Ha redatto le stime, può essere in grado di valutare i benefici attesi da cliente (tanto qualitativi quanto quantitativi in funzione della “profondità” dell’analisi svolta) per ogni obiettivo riconducibile all’adozione del nuovo sistema e può, ancora - là dove possieda le capacità, le competenze e le co-noscenze - valutare quei benefici non direttamente riconducibili all’adozione del sistema ma derivanti da fattori ad esso esterni (es. revisione dei processi, nuovi assetti logistico – produttivi, acquisizione di know-how, riassetti socie-tari ecc.). La società cliente

Ha la responsabilità di garantire la fattibilità dell’iniziativa in termini di impatti organizzativi; ha la necessità di valutare in termini economici l’intero progetto di cambiamento in modo da garantirsi il ritorno dell’investimento; può aver stilato – p.e. in fase di pianificazione strategica – una prima versio-ne del business case; può avvalersi del contributo del fornitore nel redigere il documento (non solo la prima versione ma anche le successive) e può, in-fine, chiedere la responsabilizzazione del fornitore sul raggiungimento degli obiettivi complessivi dell’iniziativa (partnership). Diventa importante osservare che è necessario chiarire una questione di fon-do e cioè quali siano:

LLL ’’’ aaa mmm bbb iii ttt ooo eee lll ’’’ aaa ppp ppp rrr ooo ccc ccc iii ooo ddd iii aaa nnn aaa lll iii sss iii ddd aaa aa ppp ppp lll iii ccc aaa rrr eee a

considerando di potersi ritrovare ad operare su livelli e contenuti diversi in funzione tanto dell’accezione da attribuire all’analisi quanto delle aspettative che si hanno dell’iniziativa. In altre parole, per meglio circoscrivere il pro-blema, in questa sede, ci si limiterà a considerare ambito del business case

99

quello relativo al progetto di realizzazione del sistema ERP e quindi ai relati-vi costi e benefici diretti di progetto pur consapevoli, che l’ambito di analisi, può essere esteso a tutto ciò che è indotto dal cambiamento. Inoltre, per quanto concerne l’approccio, si osservi che le possibilità sono molteplici e funzione soprattutto delle aspettative e delle modalità con cui il cliente è in genere abituato a “vedere” le informazioni tanto da un punto di vista dei con-tenuti quanto temporale (p.e. in occasione delle milestone di controllo del progetto). Ora, poiché il business case costituisce lo strumento più importan-te per il controllo dell’iniziativa da parte della committenza, a prescindere dai rapporti cliente/fornitore, è importante che il documento contenga:

le modalità di approvazione da parte del riferimento dell’iniziativa l’ambito di riferimento del documento; i requisiti per l’analisi economico/finanziaria; la descrizione dei contenuti in termini tanto di formati quanto di livelli di

dettaglio; i criteri di revisione ed aggiornamento del documento ; l’elenco dei destinatari, i tempi e le modalità di condivisione del docu-

mento; la descrizione dei problemi di progetto che possono/hanno impatto sul

business case; i dati di progetto e le modalità di valutazione degli stessi;

in modo da rappresentare un quadro d’insieme sia in termini qualitativi (effi-cacia, rischi, impatti ecc.) sia in termini quantitativi cercando di tradurre in valori, là dove possibile, tanto i benefici quanto gli impieghi di risorse, mate-riali e di quant’altro intervenga nel processo realizzativo dell’iniziativa pro-gettuale. In genere occorre che il documento contenga tutti gli elementi chia-ve e le informazioni di sintesi – cioè in una forma adatta ad una lettura da parte del top management aziendale – che seppure definiti all’inizio, evol-vano nel tempo seguendo l’andamento del progetto e con riferimento ai risul-tati ed ai documenti dello stesso (es. stato avanzamento lavori). Al di là dei possibili contenuti di un business case che, ripetiamo, può essere costruito in funzione delle consuetudini dell’organizzazione cliente, quello che qui inte-ressa constatare è che il documento sarà comunque finalizzato a definire: 1. in che cosa consiste l’iniziativa (attività, prodotti, organizzazione, mile-

stone ecc.);

100

2. perché occorre fare il progetto (contesto, obiettivi, aspettative, esigenze ecc.);

3. evidenza delle necessità di risorse (umane, materiali, servizi, finanziarie ecc.);

4. elementi di rischio con impatti sul progetto e sul suo business case; 5. elementi di controllo qualità su attività, prodotti e risorse in genere; 6. fattori chiave di successo ed azioni volte a sostenerle; 7. un’analisi economica dei valori associati ai costi ed ai benefici; 8. un’analisi delle tendenze nel tempo pur partendo dalle informazioni in seno alla/e unità organizzative interessa-ta/e dal progetto. Le unità organizzative coinvolte, inoltre, dovranno essere protagoniste non solo nell’identificazione dei benefici ma anche nell’analisi costi/benefici che determinano il risultato operativo del progetto. Il business case, infine, deve essere gestito per l’intero ciclo di vita del risultato del progetto (o almeno fino al momento di chiusura dell’investimento) che, al di là del puro momento realizzativo (gestito in prima persona dal progetto), può durare negli anni ben oltre la chiusura del progetto stesso.

3. Il prototipo – costruiamo il sistema? Vogliamo ancora ricordare, ammesso che ce ne sia bisogno, che un ERP pur essendo un sistema già realizzato, ha bisogno di essere “personalizzato” alla specifica realtà dell’organizzazione in cui verrà impiegato e che tale attività viene generalmente affrontata con un approccio prototipale come abbiamo avuto modo di vedere nell’ambito della fattibilità.

Stabilito che il progetto continui nella sua fase più realizzativa e seguendo le linee guida definite per la costruzione del sistema, il progetto deve seguire e controllare le relative attività di personalizzazione. In questa sede, infatti, per prototipo si intende l’insieme delle funzionalità a tendere del sistema ERP avulso dall’ambiente esterno con cui dovrà essere integrato.

101

Ambiente d’integrazione

Sistema Esterno

Sistema Esterno

Proc

ERPFin

Cont

PrjAss

Sal


Sistema Esterno

Sistema Esterno

Proc

ERPFin

Cont

PrjAss

SalProc

ERPFin

Cont

PrjAss

Sal

Fig. 26 – Il Prototipo ERP

La definizione del prototipo, quindi, sarà tesa da un lato a verificare che ERP sia effettivamente in grado di sostenere le attività “core” dell’utente e dall’altra ad evidenziare eventuali nuovi gap originati dall’operatività dello stesso, su dati reali di business, non perfettamente in linea con quanto offerto dalle funzionalità standard del sistema. Questo significa fondamentalmente tre cose: 1. il prototipo si costruisce con dati effettivamente rappresentativi della re-

altà quotidiana dell’organizzazione cliente in modo da verificarne la compatibilità col sistema in termini di codifiche, tipologie di documenti gestiti, necessità di processi indotti da ERP, verifica con procedure e standard organizzativi, funzionalità disponibili ed impatti operativi;

2. il prototipo può essere costruito per step successivi considerando una di-stribuzione della realizzazione secondo elementi di priorità: un primo momento relativo alla verifica dell’applicabilità del sistema su eventi, oggetti e processi fondamentali per le attività di business, un secondo momento che veda la costruzione dei rimanenti casi che, in genere, costi-tuiscono il 40% degli eventi gestiti dall’organizzazione, sono relativi ad attività non fondamentali che ricorrono più di rado, possono essere attivi-tà attualmente gestite fuori sistema ma che si vorrebbe fossero cablate nel nuovo sistema ERP;

102

3. la fase di prototipo può originare gap, derivanti dall’operatività utente, che vanno affrontati e risolti come abbiamo già visto nel corso della fat-tibilità.

In buona sostanza occorre focalizzarsi prima sulle cose veramente importan-ti e poi sugli argomenti “secondari” in modo da distribuire gli sforzi realizza-tivi con una più adeguata priorità ed una più efficace rappresentatività dell’applicazione del nuovo sistema. Alla fine della prima fase, infatti, sarà possibile “toccare con mano” il funzionamento del sistema applicato all’organizzazione cliente ed il management aziendale potrà essere conforta-to in tal senso. Infine, perché l’attività possa aver corso effettivo, occorre che il sistema ERP sia stato precedentemente installato e configurato opportunamente in modo da fornire almeno un ambiente dedicato allo sviluppo del prototipo.

3.1. Di che cosa è costituito il prototipo?

Durante il corso di questa attività è di fondamentale importanza il contri-buto fornito dalle risorse del cliente (c.f.r. responsabili del processo e utenti chiave): conoscono benissimo la loro realtà, sono in grado di verificare l’applicabilità del sistema alle loro attività e costituiscono i veri garanti del buon funzionamento del sistema nei confronti dell’azienda. Dal canto loro, gli specialisti del fornitore, conoscono il sistema ERP, sanno come va perso-nalizzato alle varie realtà, hanno un approccio metodologico che può guidare verso il raggiungimento degli obiettivi. Unendo queste competenze (cioè co-stituendo un unico gruppo di lavoro) è possibile raggiungere l’obiettivo prin-cipe dell’attività di prototipo: la costruzione del sistema ERP. Se è necessario che il sistema gestisca i dati propri della realtà in cui viene applicato, occorre che innanzi tutto tali dati vengano collezionati, selezionati ed infine organizzati per schemi rappresentativi dei flussi informativi in seno ai processi. In genere le entità che occorre definire sono sostanzialmente

103

“suggerite” dal sistema in quanto propedeutiche al suo funzionamento e co-stituenti le informazioni di base. In prima approssimazione sono le seguenti:

la struttura organizzativa del cliente per ogni unità funzionale coinvolta dall’utilizzo del sistema e/o da esso implicitamente indotta;

i dati anagrafici che il sistema dovrà gestire (es. Clienti, Fornitori, Mate-riali, Prodotti, Piano dei Conti ecc.), gli attributi associati ed i relativi processi di gestione;

l’insieme dei processi di business da sviluppare e gestire per ogni modu-lo ERP;

l’insieme degli eventi che si generano lungo i processi e le eventuali en-tità organizzative che le producono;

le tipologie di documenti gestiti lungo tutti i processi ed i loro attributi. La necessità di disporre di tutti questi elementi è determinante per l’organizzazione delle attività di prototipo; tali informazioni, infatti, sono in stretta relazione con:

la struttura organizzativa dell’ERP che definisce le strutture e le viste delle informazioni all’interno del sistema (p.e. quante società, qua-li/quante strutture di acquisto/vendita, di stabilimenti/impianti, magazzi-ni, centri di costo e così via); tale struttura di base, si noti, è fondamenta-le per l’impostazione del sistema, ne costituisce la struttura portante ed in caso di un suo ripensamento può portare a dover ripercorrere le attivi-tà di prototipo;

i dati anagrafici del sistema e la personalizzazione delle viste di gestione degli stessi (quali campi obbligatori, quali facoltativi e quali non neces-sari);

le autorizzazioni circa la gestione dei dati (chi può fare che cosa); la definizione degli scenari di prototipo ovvero l’aggregazione di proces-

si ed eventi secondo schemi che indirizzano l’associazione delle attività utente e le modalità di funzionamento del sistema;

le tipologie di documenti da gestire nel sistema associati ad eventi e/o processi.

104

3.2. Cosa sono gli scenari? A cosa servono?

La definizione degli scenari di prototipo, poi, è l’aspetto che guida la co-struzione del sistema; ogni scenario, infatti, è costituito in modo da aggrega-re un’insieme di attività utente, rappresentative di una determinata catena di gestione di eventi e tipologie di documenti, finalizzate al raggiungimento di uno o più obiettivi di business. Partendo dai macro processi in ambito e de-componendoli fino al maggior dettaglio possibile, si definisce l’insieme degli scenari di aggregazione degli oggetti che costituiranno il futuro sistema ERP. Questo vuol dire che il gruppo di lavoro avrà a disposizione una traccia reale tanto per personalizzare il sistema (da dove partire per condurre tali attività) quanto per verificarne il funzionamento (esecuzione dello scenario) e regi-strare la bontà dei risultati ottenuti. Per ricorrere ad un’analogia col mondo del cinema, possiamo dire che l’insieme degli scenari di prototipo è parago-nabile al “copione” di un film; ogni attore che recita sulla scena ha un rife-rimento, identico per tutti gli attori, per cui, in ogni scena, ognuno conosce la sua parte e gli intrecci con le parti degli altri attori. Man mano che la produ-zione prosegue ed il regista sviluppa quindi la trama, il film si arricchisce di contenuti ed assume corpo trasmettendo un significato suo complessivo che costituisce l’obiettivo perseguito per tutto il corso della lavorazione. Allo stesso modo possiamo considerare la realizzazione del prototipo: l’obiettivo di costruire il sistema ERP passa attraverso la realizzazione di passi interme-di ognuno rappresentativo di uno scenario di comportamento dell’utente (se volete sono le singole scene del film). Ogni scenario è costituito da un’insieme di attività “elementari” che, nel loro insieme, rappresentano una parte o una tipologia di processo. Per fare un esempio concreto pensiamo ad un processo di ciclo passivo analogo al seguente:

105

ProcessoR.d.A.

Approvaz.R.d.A.

DefinizioneOrdine

Approvaz.Ordine

EntrataMerce

SbloccoFattura

PagamentoFattura

RegistrazioneFattura

DefinizioneR.d.A.

DisponibilitàMerce

FunzioneAcquisti

FunzioneAmm.ne

FunzioneOperativa

T0 T1 T2 T3 T4 T5 T6

T E M P O Fig. 27 – Scenari: un processo di ciclo passivo

dove più funzioni organizzative sono impegnate per raggiungere un determi-nato obiettivo aziendale: soddisfare un fabbisogno di materiali definito nella r.d.a.9. Ora prendendo tale processo come riferimento facciamo qualche as-sunzione:

supponiamo che il processo, espresso in questa forma, sia sufficiente-mente dettagliato per indicare le attività elementari che lo compongono e la distribuzione nel tempo di tali attività;

supponiamo che ogni attività sia contraddistinta da un evento scatenante e che tali sincronismi siano evidenziati dalle frecce e dai blocchi in ca-scata;

le linee orizzontali continue delimitano le attività di una funzione orga-nizzativa rispetto all’altra.

È bene sottolineare che gli scenari possono avere due caratteristiche e cioè essere rappresentativi di un prototipo (che veda cioè solo funzioni standard ERP) o d’integrazione tra ERP e gli oggetti “estensivi” delle sue funzioni standard; questo vuol dire, come sarà evidente più avanti, che il piano com-plessivo delle attività di progetto dovrà essere articolato in modo da tenere 9 r.d.a. acronimo di richiesta di approvvigionamento. E’ un particolare docu-mento con cui viene tracciato il fabbisogno all’interno del sistema. Ogni or-ganizzazione, generalmente, esprime al suo interno uno o più tipologie di documenti per ogni specifico fabbisogno.

106

conto non solo delle attività e dei tempi di prototipo ma anche di quanto ne-cessario alla realizzazione degli oggetti custom.

Possiamo allora partire dal processo su descritto e definire tanto gli eventi presenti al suo interno quanto le attività, le tipologie di documenti gestiti, gli input e gli output di ogni attività; siamo cioè in grado di definire uno scena-rio di prototipo.

Scenario XX – Gestione del Fabbisogno di Materiali a Consumo Funzioni Coinvolte: Funzioni Richiedenti, Funzione Acquisti, Funzione Amministrazione Data Inizio: __/__/__ Data Fine: __/__/__ Data Approvazione: __/__/__ Process Owner: ___________________Key User: ______________________ Team Leader: ________________________ Evento Input

Attività Funzione Coinvolta

Tipo Doc./ En-tità Input

Tipo Doc./ En-tità Out-put

Evento Output

Fabbisogno A01 Definizione R.d.A. per Mate-riali a Consumo

Ogni funzione richiedente

RDA-MC Richiesta approvazio-ne RDA-MC

Richiesta ap-provazione RDA-MC

A02 Approva-zione per limite di spesa

Come da pro-cedura orga-nizzativa so-cietaria

RDA-MC RDA-MC Approvato

Richiesta Ordine di acquisto

Richiesta Ordi-ne di acquisto

A03 Processo RdA

Funzione Ac-quisti

RDA-MC RDA-MC Richiesta di Formula-zione Ordine per Ma-teriale Generico

Richiesta di Formulazione Ordine per Ma-teriale Generico

A04 Definizione Ordine

Funzione Ac-quisti

RDA-MC ODA-MG Richiesta approvazio-ne ODA-MG

Fig. 28 – Esempio di scenario di prototipo

Là dove fosse necessario l’attività potrebbe essere ridefinita con maggior dettaglio prevedendo passi intermedi significativi, anche loro, in termini di eventi, tipologie di documenti e/o entità (p.e. anagrafiche) coinvolte. In ogni caso dall’esempio si intuisce bene come il gruppo di lavoro sia in grado di approcciare la costruzione del sistema partendo da una base concreta e rap-presentativa della realtà in cui il sistema stesso dovrà operare. Se ci riferiamo all’attività A01 Definizione r.d.a. per materiali a consumo, esemplifican-do, si procederà a:

107

- definire una tipologia di Richiesta di Acquisto “RDA-MC” con tutti gli attributi necessari e con tutte le caratteristiche corrette (quali campi ob-bligatori, quali facoltativi ecc.);

- impostare l’oggetto sull’ERP; - definire i profili utente da associare ai richiedenti (coloro che formule-

ranno a sistema la r.d.a) e costruirli nell’ERP; - costruire a sistema l’evento che avvierà l’attività A02 (processo di ap-

provazione della r.d.a tramite work-flow). Tale processo potrà essere applicato per ogni altra attività utente definita nel-lo scenario in modo che tutto il processo ricostruito dallo stesso sia definito all’interno del sistema. Passo successivo, una volta, cioè, che il sistema è sta-to personalizzato come da richiesta di utenti chiave e responsabili del proces-so, il gruppo di lavoro eseguirà lo scenario verificando che tanto il compor-tamento del sistema quanto i risultati da esso prodotti siano congruenti con le aspettative; questo significa che saranno attivate ed eseguite tutte le transa-zioni e gli oggetti correlati di sistema preposti alla gestione delle richieste d’acquisto, verranno valutati i risultati e verificati i profili utente predisposti. Tale processo, definito “esecuzione dello scenario” ed effettuato dal gruppo di lavoro nel suo insieme, può sostanzialmente avere due esiti: o il sistema risponde alle esigenze manifestate dall’utenza, oppure, al contrario, occorre che venga modificato per meglio aderire ai bisogni espressi. Nel primo caso occorre che il gruppo di lavoro registri l’accettazione dei risultati prodotti in ambito allo scenario in quanto, in sostanza, è stato raggiunto un risultato in-termedio; nel secondo caso gli specialisti provvederanno immediatamente a modificare i parametri di sistema, lo scenario sarà ripercorso nel suo insieme e solo alla fine, quando tutto risulterà efficace ed aderente alle aspettative, di nuovo il gruppo di lavoro si troverà a ratificare l’accettabilità dei risultati ot-tenuti. È importante, a questo punto, fare un’altra considerazione: lo scenario non dipende strettamente dal processo che si vuole realizzare ma può costi-tuire una sua particolare ricorrenza; in altre parole, se supponiamo che il pro-cesso su descritto sia lo stesso per “i materiali dedicati alla manutenzione” (per cui, per esempio, possa cambiare solo la destinazione contabile), lo schema processuale potrebbe non subire sostanziali modifiche ma lo scenario di costruzione del sistema potrebbe essere un altro in quanto:

potrebbe riguardare un’altra tipologia di documenti e quindi altri attributi con caratteristiche difformi;

108

impegnare utenti diversi e quindi richiedere profili differenti; richiedere diverse regole di autorizzazione.

Tutto questo processo, sviluppato secondo l’approccio prototipale, forni-sce un ragionevole grado di assicurazione circa l’adeguatezza del sistema co-struito; infatti, al termine delle esecuzioni di tutti gli scenari definiti, il siste-ma, almeno nelle sue forme standard, sarà sufficientemente rispondente alle aspettative dell’organizzazione del cliente e solo le estensioni (c.f.r. soluzio-ni automatiche per i gap), le interfacce e le conversioni dovranno essere og-getto di verifica attraverso scenari ad essi dedicati. È ovvio che, là dove ven-gano definiti scenari di integrazione che prevedano l’impiego di funzionalità standard e custom (come abbiamo già detto sono le estensioni, le interfacce e le conversioni), occorrerà che tali scenari vengano eseguiti solo dopo che gli oggetti custom siano stati resi disponibili e questo implica che a livello di piano complessivo di progetto, tanto le attività realizzative dei custom quan-to quelle di esecuzione degli scenari, siano necessariamente sincronizzate tra di loro.

Da un punto di vista di gestione del progetto, inoltre, tale approccio è ga-ranzia di tracciabilità dell’attività di prototipazione, in quanto è possibile mi-surarne l’avanzamento (p.e. in numero di scenari eseguiti su scenari definiti), ed il termine dell’attività può prestarsi a rappresentare una milestone fonda-mentale dell’intero ciclo di vita del progetto stesso rappresentando sia per il fornitore sia per il committente un momento comune di confronto.

109

4. Estensioni, interfacce, conversioni e documenta-zione: che senso hanno? Lo hanno nella misura in cui: 1. il sistema standard non risponde a tutti i requisiti espressi dagli utenti

chiave a dai responsabili di processo per cui sono necessarie nuove fun-zionalità;

2. il sistema ERP deve scambiare informazioni con altri sistemi tanto per sostenere un transitorio quanto per realizzare una situazione definitiva;

3. esistono grossi volumi di dati da convertire e sono disponibili su qualche supporto informatico;

4. si vuole fornire all’utente finale una documentazione di quanto realizzato che lo aiuti a “navigare” nel sistema.

4.1. Le estensioni – in cosa consistono?

Ne abbiamo già accennato parlando di risoluzione dei gap e qui conviene osservare che comunque, la realizzazione di estensioni, richiede un maggior impegno alle risorse di progetto. Là dove le carenze funzionali ERP pregiu-dicassero le attività “core” dell’utente quelle, cioè, da cui l’organizzazione cliente non può prescindere tanto per motivi di efficacia quanto di efficienza rispetto al raggiungimento dei propri obiettivi, si pone il problema di soppe-rire a tali carenze. Generalmente la necessità di software aggiuntivo viene generata da richieste di soluzioni automatiche ai gap e segue la logica di “porsi di fianco” alle funzionalità standard del sistema al fine di non pregiu-dicarne gli sviluppi nel tempo. E tuttavia non sempre questo è vero; a volte ci si trova a dover modificare oggetti standard che occorre censire e monitorare molto da vicino per tutto il ciclo di vita del sistema. Il problema, quindi, si pone in termini di architettura complessiva del sistema a tendere che pur in-vestendo la realizzazione di nuovi oggetti o la modifica di quanto fornito dal-la ERP, dovrà risultare comunque coerente nel suo insieme. In altre parole si pone un problema di gestione complessiva delle estensioni ritenendo che sia necessario:

110

♦ definire regole e standard di comportamento per questi casi da ritenersi atipici ed eccezionali (come abbiamo già detto: strutture organizzative e processi autorizzativi di supporto);

♦ verificarne la realizzabilità con particolare attenzione all’architettura esi-stente sia per quanto riguarda report e transazioni che per integrità e coe-renza della base dati (coesione, connessione, relazioni tra tabelle e inte-grità referenziale dei dati, performance e tempi di risposta ecc.) e consi-derare che per questi motivi, modifiche complesse, possono risultare im-praticabili o comunque non convenienti da un punto di vista dei co-sti/benefici;

♦ censire tutti gli oggetti modificati e predisporre una lista ben dettagliata con le tipologie di modifiche effettuate (es. exit routine, parametri addi-zionali, codice inserito ecc.);

♦ prevedere per questi oggetti un più attento test funzionale e tecnico in fase di collaudo complessivo del sistema;

♦ approntare un’adeguata documentazione di supporto alla fase di manu-tenzione del sistema nel periodo di esercizio (per esempio indicando modalità e tipi dati da usare nei test di regressione piuttosto che uno schema di sintesi degli oggetti coinvolti dalla stessa modifica);

♦ creare consapevolezza nell’organizzazione del cliente circa la necessità di tenere sempre bene in vista tali modifiche al fine di controllare l’evoluzione del sistema in termini di adottabilità delle release successive approntate dal fornitore del sistema ERP;

considerando che per le modifiche “estensive” dello standard, il problema è relativamente più semplice – nel senso che in genere non si pregiudica l’evoluzione del sistema – ma tuttavia da tenere sempre sotto controllo sia per i maggiori impegni di realizzazione che di complessità indotta sulle atti-vità di progetto e sulla loro gestione.

111

4.2. Le interfacce – bisogna proprio farle? Che cosa com-portano?

Più volte, nel corso dei capitoli precedenti, abbiamo fatto riferimento a possibili scenari di transizione necessari prima di giungere ad un’architettura definitiva del nuovo sistema ed abbiamo anche osservato che tanto per rea-lizzare i transitori, quanto per la configurazione a tendere, esisteva la neces-sità di predisporre delle interfacce che consentissero al sistema ERP di collo-quiare con gli altri sistemi componenti l’intero sistema informatico azienda-le. In generale e per quello che qui interessa, le interfacce altro non sono che oggetti software necessari per “far parlare tra loro” due o più sistemi sia resi-denti sullo stesso calcolatore che operanti su macchine diverse anche geo-graficamente distribuite. Ovviamente in questa accezione si prescinde da tut-te le componenti hardware e di comunicazione che costituiscono il substrato di base necessario a rendere possibile la connessione tra sistemi (si faccia ri-ferimento al capitolo sul supporto tecnologico); qui vogliamo limitarci a ve-dere le cose da un punto di vista logico applicativo ponendo l’enfasi sugli impatti generati dalle interfacce sull’organizzazione del cliente consci che non si tratti del solo processo di realizzazione informatica.

SistemaLegacy

“A”

SistemaLegacy

“B”

SistemaLegacy

“C”

Estrattore“A”

Caricatore“B”

Estrattore“C”

Caricatore“C”

NORMALIZZATORE

Decodifica“Flussi A”

Decodifica“Flussi B”

Decodifica“Flussi C”

Input“X”

Input“Y”

Output“Z”

ERP

Interfaccia

SistemaLegacy

“A”

SistemaLegacy

“B”

SistemaLegacy

“C”

Estrattore“A”

Caricatore“B”

Estrattore“C”

Caricatore“C”

NORMALIZZATORE

Decodifica“Flussi A”

Decodifica“Flussi B”

Decodifica“Flussi C”

Input“X”

Input“Y”

Output“Z”

ERP

Interfaccia

Fig. 29 – Schema d'interfaccia

112

La fig. 29 riporta lo schema logico di una interfaccia che consente lo scam-bio di informazioni tra l’ERP e tre sistemi proprietari; in particolare: ♦ il sistema “A” fornisce dati per l’ERP; ♦ il sistema “B” riceve dati dall’ERP; ♦ il sistema “C” riceve ed invia dati da/per l’ERP. Osserviamo, innanzitutto, che l’interfaccia proposta è un oggetto composto da più componenti specializzati tanto per tipologia di flusso dati da trattare quanto per destinazione d’uso (ovvero a che serve); non è l’unica possibile e potrebbe costituire tanto un oggetto da realizzare in seno al gruppo degli spe-cialisti quanto un oggetto “chiuso” fornito da un qualsiasi fornitore di sof-tware e che quindi viene semplicemente applicato dagli specialisti del gruppo di progetto per realizzare gli scenari di connessione tra i sistemi. Al di là, quindi, degli aspetti specialistici quello che più interessa sono le implicazioni che l’interfaccia ha sia sull’organizzazione che sull’operatività utente; voglio dire che un’interfaccia non rappresenta un oggetto statico ed immutabile nel tempo; deve evolvere all’unisono con i sistemi che connette, richiede che qualcuno controlli il suo funzionamento ed è necessario che qualcun altro ve-rifichi i risultati prodotti ed eventualmente intervenga per risolvere possibili errori o scarti ricevuti durante il corso dell’elaborazione. Questo vuol dire che non basta, semplicemente, realizzare un software in grado di gestire tutti i casi possibili per porsi al riparo da ogni malfunzionamento; al contrario è probabile che nel ciclo di vita dell’interfaccia, ci possano essere momenti (la maggior parte degli inconvenienti si manifesta nella fase iniziale di esercizio) in cui i risultati prodotti non saranno quelli attesi e che qualcuno dovrà inter-venire per porvi rimedio. Se rivediamo la figura, infatti, ci accorgiamo che i dati di scambio tra l’ERP ed i sistemi legacy coinvolti, sono strettamente di-pendenti dalle informazioni contenute nei sistemi di origine e che ogni loro cambiamento può provocare modifiche ai dati di interscambio.

Un’altra considerazione da fare è legata ai tempi di disponibilità dei risul-tati attesi ed ai conseguenti impatti operativi sull’utenza: ci possono essere interfacce con cadenza temporale diversificata (giornaliera, settimanale, mensile ecc.) i cui risultati di elaborazione devono comunque essere prodotti in un lasso di tempo contenuto al fine di ottemperare alle esigenze operative. Si pensi per esempio ai processi tipici delle chiusure contabili mensili o di

113

consuntivazione dei dati giornalieri di produzione: tali processi sono gene-ralmente pilotati da calendari che in maniera rigida, fissano i tempi entro cui certe informazioni devono essere disponibili per le elaborazioni di chiusura. Là dove tali dati occorre che siano elaborati sull’ERP e reperiti dai sistemi esterni si pone il problema tipico del controllo delle interfacce. Occorre non solo monitorare i processi elaborativi dei dati gestiti dall’interfaccia stessa ma anche di controllare gli eventuali scarti prodotti nella fase di caricamento nell’ERP, determinarne le cause, valutare gli impatti che la mancanza di tali dati genera sui risultati finali e quindi decidere sulla opportunità di ripresa delle informazioni mancanti una volta che siano rimosse, a monte, le cause che hanno generato gli scarti. Questo, normalmente, si traduce in un insieme di attività coordinate, anche tra funzioni aziendali diverse, finalizzate a veri-ficare e correggere i dati proprietari dei sistemi di origine (a cura degli utenti che li adoperano), riavviare i processi elaborativi dell’interfaccia (gli specia-listi informatici del cliente o del suo outsourcer), ricontrollare i risultati della fase di caricamento delle informazioni nell’ERP (a cura dell’utente ERP) rei-terando l’intero processo fino alla completa gestione degli errori riscontrati.

Da un punto di vista realizzativo, la costruzione delle interfacce, general-mente, pone un problema di esistenza delle informazioni sui sistemi d’origine. Nei casi in cui si dovessero verificare carenze di questo tipo è ne-cessario pianificare e realizzare un’integrazione dei sistemi in questione con-siderando tanto gli eventuali impatti sull’operatività utente (dove recuperare le informazioni, eventuali necessità di conversione e bonifica ecc.) quanto i tempi necessari alla popolazione dei dati mancanti. Il problema che si pone per l’azienda, in sostanza, è quello di ricondurre ad una coerenza complessi-va tutte le attività implementative sui sistemi di origine, l’addestramento u-tente alle nuove funzionalità, le attività utente di costruzione della base dati integrata, le attività di test del nuovo sistema ERP e dell’interfaccia interes-sata. Si apre cioè uno dei temi di integrazione tra il gruppo di progetto ERP e le strutture di gestione della manutenzione dei sistemi proprietari che vanno gestite in un ottica di convergenza verso un obiettivo comune: l’esercizio del sistema informatico dell’azienda così come previsto dal nuovo assetto defini-to. Anche se qui gli approcci possono essere diversi, tuttavia conviene notare che l’esistenza di un punto unico di gestione e controllo delle attività, con buona probabilità, può favorire l’integrazione delle parti ed indirizzare le so-luzioni in modo coerente. Si consideri ancora che la numerosità delle inter-facce, amplificando l’effetto sull’organizzazione del cliente, deve tenden-zialmente essere contenuta, specie in quelle organizzazioni dove non è pos-

114

sibile presidiarle in modo adeguato, per cui l’architettura dei componenti de-ve essere impostata anche in riferimento alle strutture di gestione presenti in azienda. Con questo si vuol dire che le tipologie di interfaccia adottabili sono diverse e che l’impiego di un tipo rispetto ad un altro dovrebbe essere guida-to da un insieme di parametri tra cui:

i tempi a disposizione che possono orientare la scelta tra l’adozione di un prodotto preconfezionato rispetto ad una realizzazione ex novo;

l’integrabilità di prodotti di terze parti con l’ERP che veicola l’opportunità di adozione di un prodotto preconfezionato;

i vincoli di business, il volume dei dati da trasferire e le capacità dell’hardware che faranno propendere per interfacce di trasferimento immediato dei dati (on-line) piuttosto che a momenti stabiliti in un arco temporale (batch);

il ciclo di vita dell’interfaccia che, se necessaria per sostenere un transi-torio, deve poter ispirarsi anche a criteri di economicità;

la tipologia di struttura di gestione operativa che potrebbe suggerire l’adozione di un ambiente di base atto a facilitare lo scheduling (ordinare secondo priorità) automatico;

la ciclicità operativa e l’architettura dei sistemi di origine che possono suggerire o vincolare l’architettura delle interfacce tanto in termini di di-sponibilità dei dati che di opportunità di sviluppo;

questo significa, in sostanza, che non esiste una soluzione standard che possa andare bene per ogni circostanza; ogni installazione deve essere vista come un caso a se, valutata in ogni sua peculiarità/esigenza e prevista una soluzio-ne precipua per ogni specificità.

4.3. Le conversioni – quale approccio?

Una delle esigenze fondamentali, presente nell’implementazione di un sistema informatico, è quella di trovare le modalità più appropriate per popo-lare la base dati di partenza del sistema. Anche l’ERP, avendo simili caratte-ristiche, non si sottrae a questa necessità per cui occorre affrontare lo stesso

115

problema in seno al progetto di realizzazione. Ora, generalmente, tali infor-mazioni sono già presenti nel sistema informativo dell’azienda che si accinge ad installare ERP per cui si rende necessario:

individuare quali sono i dati da convertire; capire dove sono reperibili i dati e su quale supporto risiedono; quali attività propedeutiche occorre attivare prima di portare i dati in

ERP; stabilire le modalità di conversione per ogni entità; definire le relazioni tra vecchie e nuove codifiche dei dati; realizzare i programmi di conversione automatica; specificare le sequenze ed i tempi delle conversioni; definire i passi operativi di verifica e controllo delle conversioni; predisporre un piano delle conversioni.

Tutto quanto su riportato esprime, seppure in maniera sintetica, quello che possiamo definire l’approccio alle conversioni; Tutte le attività evidenziate dovranno essere realizzate e monitorate per giungere ad un sistema avviabile in produzione e soprattutto per essere sicuri del raggiungimento dell’obiettivo.

Approccioallaconversionecondiviso

Condivisione

• Competenze Utente• Competenze SAP• Vincoli• Linee Guida• Modelli

• Competenze Utente• Competenze SAP• Vincoli• Linee Guida• Modelli

Piano Conversioni

Figura 30 – Approccio alle conversioni

Il primo passo da effettuare, allora, è senza dubbio l’identificazione delle co-se da convertire (entità ed attributi ad esse associati) ed in merito, lo stesso sistema ERP, può venirci incontro suggerendoci una prima loro individua-zione e classificazione; gli specialisti ERP, infatti, sanno bene che per ogni

116

modulo applicativo del sistema esistono entità di base di cui il sistema ha bi-sogno per funzionare ed in genere, queste informazioni, possono essere rag-gruppate come di seguito:

• dati anagrafici definiti e gestiti in modo specifico all’interno di un singolo modulo (p.e. voci di costo, CBS e network);

• dati anagrafici validi per più moduli (p.e. anagrafiche clienti e forni-tori, condizioni di pagamento, piano dei conti);

• dati caratteristici del modulo (p.e. saldo dei conti, ordini di Acquisto o di vendita, movimenti di magazzino ecc.);

• legami di coerenza tra le entità proprie dell’ERP (p.e. fabbisogni ge-nerati da network, collegamenti tra r.d.a. e ordini, entrate merci e fat-ture e così via);

tutti elementi da prendere in considerazione per verificare la fattibilità di conversioni automatiche al fine di ricostruire e garantire le coerenze ed i le-gami tra le entità gestite dal sistema. Dal canto loro, inoltre, gli utenti cono-scono benissimo la realtà aziendale in termini di:

• volumi di dati ed occorrenze per ogni entità (quanti fornitori e quan-

te volte un fornitore è stato codificato con codici diversi); • procedure operative di gestione dei dati; • ubicazione e difformità dei supporti di registrazione delle informa-

zioni; • grado di obsolescenza dei dati negli archivi in uso dei sistemi attuali;

parametri che possono suggerire l’opportunità/necessità circa l’adozione di processi automatici di conversione.

117

Appl. locali distabilimento

Estrazioni datiDati per gli stabilimentiin fase di avviamento:• dati di contabilità• dati di gestione• dati di magazzino

Caricamento datisu ERP ERP

ERP

Verifica codicimateriali

report deglierrori (*)

integrazione manuale

Conversione Anagrafica Materiali

Appl. locali distabilimento

Estrazioni datiDati per gli stabilimentiin fase di avviamento:• dati di contabilità• dati di gestione• dati di magazzino

Caricamento datisu ERP ERP

ERPERP

Verifica codicimateriali

report deglierrori (*)report deglierrori (*)

integrazione manuale

Conversione Anagrafica Materiali

Figura 31 – Esempio di processo di conversione

Coniugando le necessità e le viste utente con la fattibilità espressa dagli specialisti ERP è possibile stilare un elenco completo delle entità da conver-tire evidenziando: l’ubicazione dei dati (p.e. distribuzione geografica), mo-dalità di conversione (automatiche/manuali/assistiti da uno strumento), ne-cessità di bonifica degli archivi esistenti, necessità di ricodifiche là dove rite-nuto necessario, sequenze da rispettare ed un’ipotesi dei tempi di conversio-ne. Fatto questo, siamo pronti per definire le procedure ed i tempi per il con-trollo dei risultati delle attività di conversione; occorrerà evidenziare soprat-tutto il carico utente per assicurarsi che non ci sia bisogno di un maggior as-sorbimento di risorse considerando che nella fase attuativa delle conversioni, l’utente potrebbe trovarsi ad operare tanto sui vecchi sistemi quanto su ERP. A questo punto abbiamo tutti gli elementi per poter definire una prima ver-sione di piano che guidi tutte le attività di conversione e che tuttavia, lo ve-dremo in seguito, dovrà essere rivisto ed integrato con le altre attività di av-viamento del sistema.

4.4. La documentazione – che cosa documentare?

Proviamo per una volta a metterci nei panni del cliente il quale, avendo commissionato un progetto di realizzazione di un sistema, normalmente si

118

aspetta di ricevere qualcosa che gli faccia “toccare con mano” quello che ha comprato e che possibilmente non sia “il solito fumo” prodotto dagli specia-listi che, per tradizione e forma mentale, sono generalmente portati a sottova-lutare questo aspetto della fornitura. E già! Ma che cosa ha comprato il cliente? Non potendo, ovviamente, in questa sede, entrare nel merito di ogni possibile transazione commerciale e quindi sui possibili impegni che può as-sumersi ogni specifico interlocutore, ragionevolmente possiamo limitarci ad osservare che, in genere, i progetti ERP possono prevedere di produrre più tipologie di documenti tra cui:

1. la documentazione relativa alla gestione del progetto; 2. la documentazione specifica delle attività di gestione del cambiamento ; 3. i documenti/prodotti scaturiti dalle attività svolte dal progetto (delivera-

ble); 4. la documentazione di supporto all’addestramento sul sistema; 5. la documentazione inerente il supporto all’utilizzo in esercizio del nuovo

sistema. Prescindendo da quelle tipologie strettamente connesse tanto ai termini con-trattuali definiti quanto alle metodologie adottate in seno ad ogni progetto o alla stessa specifica realtà progettuale, in questa sede ci limiteremo a delinea-re le esigenze di documentazione circa l’utilizzo del sistema, le possibili mo-dalità realizzative ed i relativi strumenti di supporto.

Cominciamo con l’osservare che il progetto, introducendo il nuovo siste-ma in una realtà esistente, può aver ridefinito processi, procedure operative e, non ultimo, introdotto nuovi strumenti di gestione delle attività soprattutto basate su ERP. Per un’utenza indotta al cambiamento è forte la necessità di uno strumento di riferimento, sufficientemente articolato, che gli consenta di “navigare” tanto all’interno dei nuovi processi definiti quanto di svolgere le singole attività operative anche con l’impiego del nuovo sistema. In queste circostanze il senso di disorientamento è molto avvertito dalle persone e so-prattutto tra coloro che non hanno vissuto in prima persona il progetto ma che comunque usufruiranno degli strumenti da esso approntati.

119

Processi

Sottoprocessi

Organizzazione coinvolta

Procedure Operative e Strumenti

Transazioni SAP

Codifiche

Modelli e Strutture di Navigazione

Interfaccia Utente

Figura 32 - Il Manuale di Supporto Utente

Per venire incontro a tale esigenza e per favorire l’utilizzabilità dei nuovi strumenti, un ausilio importante è costituito proprio dal manuale di utilizzo del sistema; uno strumento articolato in funzione della tipologia di utenza da sostenere, facilmente accessibile da tutti e, soprattutto, semplice da usare ed accattivante dal punto di vista dell’interfaccia utente. Credo siano questi gli ingredienti indispensabili per costruire uno strumento rivolto a molte persone e che deve evolvere nel tempo all’unisono col sistema informativo che rappresenta; costituisce quasi un “biglietto da visita” del sistema e nel contempo un veicolo che introduce ad esso, ne fa comprendere la sua articolazione e guida l’utente lungo tutta la catena delle attività che potrà svolgere. In qualsiasi punto del processo l’utilizzatore del sistema deve sentirsi “sicuro” dell’ambito in cui si muove; innanzi tutto deve sentire che quello è il suo nuovo ambiente operativo, deve ricevere tutti i riferimenti circa le attività che può svolgere, di come deve farlo, quali oggetti ERP dovrà utilizzare ed in che modo colloquiare col sistema ed infine, dovrà conoscere quali implicazioni avrà il suo operato sulle attività di altri colleghi. Perché tutto questo sia facilmente fruibile e differenziato per ogni tipologia di utente del sistema, possiamo ipotizzare la realizzazione di uno strumento articolato su più livelli; ogni livello: può rappresentare un possibile accesso al sistema informativo, si differenzia dall’altro per il grado di analiticità con

120

vo, si differenzia dall’altro per il grado di analiticità con cui affronta i vari argomenti, tutti i livelli sono tra loro dipendenti e navigabili - sia in senso verticale cioè per dettaglio più o meno elevato quanto in senso orizzontale in modo da passare da un argomento ad un altro – ogni livello conterrà le in-formazioni indirizzate per ogni tipologia di utenza.

Distribuibilità Geografica

LANLAN

ERP

LAN

Distribuibilità Geografica

LANLAN

ERP

LAN

Fig. 33 – Distribuibilità del manuale utente

In tale accezione del manuale di utilizzo diciamo che l’oggetto si configura come un prodotto autonomo, dotato cioè di un proprio ciclo di vita, che sep-pure non avulso dal contesto sistemico di riferimento, tuttavia si caratterizza per una propria autonomia di architettura/funzionamento e scevro da legami statici col sistema di riferimento. Al suo interno, infatti, ritroviamo molti e-

121

lementi del sistema informativo non correlati direttamente a quello informa-tico per cui può essere difficile, se non impossibile, definire relazioni uno a uno tra manuale e sistema informatico. Con questo si vuole sottolineare la scelta di non legare in modo vincolante il manuale all’ERP (p.e. accesso al manuale da una transazione ERP) ma di poter disporre, per esempio sulla stessa postazione di lavoro dell’utente ERP, di un collegamento all’oggetto “manuale” alla stessa stregua di una qualsiasi applicazione accessibile dal desktop. I motivi di tale scelta risiedono in due considerazioni di fondo: a guidare l’attività utente è il processo specifico della sua realtà, delle sue mo-dalità operative e dei vincoli organizzativi propri del processo; il sistema è solo uno strumento di supporto che automatizza alcune/molte attività del processo ed il sistema ERP in particolare, inoltre, offre la possibilità di un help ampliabile, precipuo per la spiegazione dei vari campi contenuti in ogni transazione, che comunque è un’altra cosa rispetto a descrivere processi, at-tività ed impatti operativi, procedure e quant’altro. Nella composizione del manuale qui ipotizzata, come abbiamo visto, il contenuto informativo delle singole transazioni è solo un elemento dell’intero patrimonio informativo contenuto nell’oggetto ed il presupposto più rilevante è costituito dal porre l’utente al centro dell’attenzione (o meglio del processo) fornendogli una “bussola di navigazione” che gli consenta di individuare percorsi, attività, strumenti (tra cui anche l’ERP) ed il loro modo d’impiego. Per garantire un’interfaccia “user friendly”, inoltre, gli specialisti potranno ricorrere, com-patibilmente con l’ambiente in cui l’oggetto andrà a calarsi, agli ultimissimi strumenti di sviluppo (p.e. WEB based, CBT, iper testi ecc.) approntando prodotti che possano essere “accattivanti” e soprattutto facilmente divulgati anche in organizzazioni distribuite geograficamente.

Resta ora da definire il contenuto di questo strumento e le fonti cui attin-gere le informazioni per popolarlo! In pratica il progetto dovrebbe aver pro-dotto tutto quanto necessario nel corso delle sue attività realizzative in quan-to: che cosa può contenere un manuale di utilizzo? Intanto possiamo distin-guere due grandi temi:

gli aspetti più “sistemici” legati sostanzialmente alla gestione degli am-bienti hardware e software (di base e di ambiente) e quindi indirizzati ad un’utenza di specialisti ICT (di informatica e telecomunicazione);

122

gli argomenti di business che richiamano processi, attività e strumenti di supporto.

Se consideriamo quest’ultimo come oggetto prioritario, cioè quello a cui prestare la maggiore attenzione (per via delle più elevate necessità e degli impatti indotti dal cambiamento) e per cui occorre produrre uno sforzo signi-ficativo, possiamo ragionevolmente supporre che occorrerà prevedere:

1. le mappe dei processi a diversi livelli di dettaglio;

2. le procedure organizzative che regolano i vari processi aziendali e gli or-ganigrammi delle funzioni coinvolte dai processi;

3. le procedure operative con tutte le attività comprese quelle “fuori siste-ma”;

4. la collezione delle transazioni personalizzate del sistema;

5. la documentazione di customizing esplicativa del significato e del conte-nuto dei campi presenti nelle transazioni (codifiche, strutture ecc.);

6. la documentazione delle estensioni (negli stessi termini visti per lo stan-dard dell’ERP);

7. la documentazione dei nuovi modelli (di controllo, reporting, contabile, ecc.);

queste informazioni, almeno in buona parte, sono normalmente prodotte dal progetto nelle sue fasi realizzative per cui lo sforzo relativo al reperimento ed alla redazione delle informazioni dovranno essere indirizzate soprattutto ver-so quegli aspetti più propriamente organizzativi in cui, la “parte da protago-nista”, verrà svolta soprattutto dalla funzione organizzazione della società cliente che generalmente è preposta a tale ruolo. In ogni caso occorre fare un’altra considerazione: il manuale non si ottiene magicamente “mescolan-do” gli ingredienti visti ai punti precedenti. È anch’esso un processo produt-tivo di progetto che va pianificato, seguito all’interno del progetto in modo coordinato con tutte le altre attività – specie in relazione a quei prodotti da riutilizzare in tale contesto – e condotto seguendo un metodo sistematico che

123

conduca, passo dopo passo, al prodotto finale. Richiederà anche qui l’impegno costante non solo degli specialisti ma anche degli utenti chiave e dei proprietari dei processi, alla stessa stregua di tutte le altre attività di pro-getto.

5. System test – Che cosa? Chi? Perché?

C’è un momento del ciclo di vita realizzativo del sistema informatico in cui è necessario verificare che gli oggetti prodotti funzionino correttamente e producano i risultati per cui sono stati progettati e realizzati. Il progetto, in-fatti, con le sue attività ha:

personalizzato l’ERP (customizing); realizzato i programmi di comunicazione tra l’ERP e quei sistemi che

comporranno il nuovo assetto transitorio o definitivo (c.f.r. le interfac-ce);

costruito i programmi di conversione dati dai vecchi sistemi; realizzato le estensioni al prodotto standard; realizzato il Manuale di Utilizzo.

Tutto questo va verificato in modo coerente e, soprattutto, integrato tanto da-gli specialisti quanto dagli utenti chiave e dai proprietari di processo. In altre parole con questa attività il progetto certifica

Fig. 34 – Il system test

124

Il Problema del System Test

l’adeguatezza dei prodot-ti realizzati e diventa ga-rante verso tutti gli utiliz-zatori futuri dell’organizzazione clien-te. Ne consegue l’estrema criticità di questa specifi-

ca attività non solo in termini di qualità attesa ma anche temporale rispetto ai tempi di delivery del progetto. Infatti, quasi generalmente, al termine del system test occorrerà che il progetto si predisponga ad avviare il sistema in produzione e quindi è normale che il gruppo di lavoro viva un particolare momento di stress che in qualche modo va controllato e ricondotto a livelli di normale accettabilità. Visti gli elementi ed il clima che caratterizzano tale at-tività possiamo pensare che uno sforzo così importante debba, per forza di cose, essere disarticolato in più fasi: - definizione di un piano articolato dei test; - definizione di un approccio complessivo al test; - esecuzione del test da parte degli specialisti con l’eventuale supporto de-

gli utenti; - esecuzione del test condotto autonomamente dagli utenti con l’eventuale;

supporto degli specialisti soprattutto nella rimozione di errori e/o mal-funzionamenti;

- ratifica ed accettazione dei risultati ottenuti al fine di consentire il pas-saggio del sistema in produzione.

5.1. Un approccio ed un piano?

La necessità di avere un piano specifico delle attività è ovviamente lega-ta da un lato alle criticità viste in precedenza e dall’altra al fatto di trovarsi nella condizione di dover necessariamente sincronizzare sia gli aspetti di test che quelli di realizzazione relativamente agli oggetti che risultano ancora in fase di completamento. Inoltre è molto probabile che l’intero gruppo di lavo-ro venga investito dall’attività in oggetto per cui il numero di persone coin-volte può costituire un ulteriore elemento di complessità che induca ad una più dettagliata pianificazione nei soliti termini di “chi fa che cosa e quando”. Parallelamente alla pianificazione occorre definire, come abbiamo detto, un approccio complessivo al test in termini di modalità, oggetti da testare, pre-disposizione dati, definizione degli scenari di test ed analisi dei risultati, tracciabilità delle correzioni apportate.

125

La fase diPianificazione

La definizionedell’approccio

Il test d’integrazione

Il controllo deirisultati

Il test utenteL’accettazione

finale

Figura 35 - System test: il processo realizzativo

Coerentemente con gli aspetti di qualità e di metodologia adottati dal proget-to occorre che vengano definiti tutti gli aspetti sopra citati, condivisi da tutto il gruppo di lavoro (qui la comunicazione riveste un aspetto importante) ed eventualmente concordati con enti esterni al progetto in qualche modo coin-volti da questa attività – generalmente persone di altri progetti in corso, refe-renti di altre unità aziendali coinvolte e così via -.

5.2. Il Test d’Integrazione?

Quando tutto è pronto l’attività può prendere il via: i primi a dover verifi-care che tutto funzioni alla perfezione sono gli specialisti del gruppo di lavo-ro; percorrono tutti gli scenari di test (per il significato di scenario si faccia riferimento all’attività di realizzazione del prototipo) definiti generalmente con lo scopo di percorrere processi tra loro correlati da priorità e precedenze logiche insite nel processo. Ad esempio per verificare le funzionalità di ge-stione di un’anagrafica lo scenario sarà organizzato in modo che tale proces-so sia preceduto da una fase di conversione dati da un sistema esistente; allo

126

stesso modo e seguendo una logica di causa effetto, si procederà ad eseguire prima un processo interno all’ERP e dopo a verificare che i dati prodotti sia-no per esempio coerenti con le modalità di interfaccia verso un sistema e-sterno e che i dati travasati in esso abbiano significato al suo interno. Allo stesso modo dovranno essere verificate le funzionalità contenute nelle esten-sioni e la coerenza delle informazioni da/verso l’ERP; in sostanza un vero e proprio test di integrazione che tuttavia ripercorra anche scenari di prototipo al fine di verificare il buon funzionamento del sistema anche in funzione di dati ricevuti da fonti ad esso esterne. Quest’ultimo aspetto, in particolare, viene talvolta sottovalutato dagli specialisti del prodotto che sono indotti a dare per scontato il buon funzionamento del sistema in ogni circostanza: in realtà l’esperienza ha insegnato che i problemi sono sempre in agguato e pronti a manifestarsi anche nella fase di esercizio del sistema per cui occorre non sottovalutare quanto indotto dall’integrazione con interfacce. È necessa-rio, infine, che l’esecuzione delle attività di test siano adeguatamente docu-mentate sia per motivi metodologici e di qualità, legati ai prodotti previsti dalla fornitura, sia perché tale documentazione può tornare utile in fase di adozione di nuove release del sistema, in cui, gli aspetti di test di regressione, sono particolarmente sentiti in quanto certificano tanto l’adottabilità delle nuove funzioni quanto la compatibilità della base dati.

5.3. Il test utente?

Fig. 36 - Lo User Test

Quando il test d’integrazione è terminato

il sistema ed il suo manuale di utilizzo pos-sono essere rilasciati agli utenti chiave ed ai proprietari di processo che a loro volta do-vranno certificare l’adeguatezza del sistema, verso la loro organizzazione, rispetto alle a-spettative ed alle specifiche adottate. Gene-ralmente possono essere rieseguiti gli scenari utilizzati dagli specialisti ma, dove ritenuto

diversamente, anche gli utenti possono organizzare e percorrere scenari a lo-ro più consoni oppure solo parte di quanto adottato dagli specialisti. In ogni

127

caso conviene che quest’ultima attività venga eseguita non solo con il sup-porto del manuale di utilizzo ma anche con quello degli specialisti del grup-po di lavoro. Il compito di questi ultimi sarà, intanto, quello di fornire le in-dicazioni e le informazioni richieste ma soprattutto avranno il compito di prendere nota dei malfunzionamenti del sistema o delle incoerenze del ma-nuale, registrare quanto rilevato, provvedere alla rimozione degli errori e ri-lasciare nuovamente agli utenti le versioni corrette degli oggetti modificati – si noti che tale iter dovrà essere ripercorso sino alla completa eliminazione di tutti gli errori rilevati –. Questo permette agli utenti di essere gli attori prota-gonisti del processo di test che focalizzano l’attenzione sui loro problemi, ve-rificano gli impatti sulla loro operatività suggerendo eventuali riassetti orga-nizzativi/operativi, hanno l’opportunità di controllare soprattutto gli oggetti “indispensabili” al lavoro di tutti i giorni e di assumere un atteggiamento più diretto al controllo che non al segretariato. Non si dimentichi che sono pro-prio gli utenti a certificare l’adeguatezza del sistema alle specifiche di fun-zionamento all’interno dell’organizzazione; il loro compito di garanti dovrà essere agevolato il più possibile in modo da indurre sicurezza e consapevo-lezza dei nuovi strumenti che saranno adottati in futuro dall’azienda: costi-tuiscono i portavoce del progetto nei confronti del top management che – a-spetto affatto trascurabile – ha profuso impegno, attenzione e sostegno a tutta l’iniziativa.

6. Il supporto tecnologico – A che serve?

Questo è probabilmente l’aspetto meno clamoroso del progetto nel senso che è vissuto più dietro le quinte del progetto stesso; costituisce l’attività più specialistica, sia in termini di contenuto che di utenza diretta coinvolta (il personale ICT dell’organizzazione cliente e gli specialisti del gruppo di pro-getto), e tuttavia fornisce la struttura portante del sistema che rende sosteni-bile l’intero sforzo progettuale.

128

• Logistica– Il Gruppo di Lavoro di progetto, per portare avanti le diverse attività, ha

la necessità di operare a contatto con le risorse di riferimento; da quil’esigenza di una collocazione fisica unica per l’intero progetto.

• Comunicazione– Le esigenze di comunicazione del Gruppo di Lavoro richiedono

l'installazione di una rete locale (LAN) che sia di supporto a:• Posta elettronica, per la gestione organizzata delle comunicazioni

tra il Gruppo di Lavoro e gli utenti di riferimento di Sede e diPeriferia.

• Ambiente KES, che costituisca la base dati in rete perl’archiviazione e la diffusione della documentazione di progetto.

• Ambiente ERP Demo/Addestramento– Una installazione del sistema per erogare il Training alle risorse del

Gruppo di Lavoro e per la verifica delle modalità di funzionamento delsistema.

• Strumenti di Lavoro– Project, Word, Excel,Powerpointdi Microsoft– Accesso ai tool metodologici

INFRASTRUTTUREINFRASTRUTTURE

PIANO DI LAVOROPIANO DI LAVORO

GRUPPO DI PROGETTOGRUPPO DI PROGETTO

PRODOTTIPRODOTTI

OBIETTIVIOBIETTIVI

Supporto Tecnologico e Servizi Infrastrutturali

• Logistica– Il Gruppo di Lavoro di progetto, per portare avanti le diverse attività, ha

la necessità di operare a contatto con le risorse di riferimento; da quil’esigenza di una collocazione fisica unica per l’intero progetto.

• Comunicazione– Le esigenze di comunicazione del Gruppo di Lavoro richiedono

l'installazione di una rete locale (LAN) che sia di supporto a:• Posta elettronica, per la gestione organizzata delle comunicazioni

tra il Gruppo di Lavoro e gli utenti di riferimento di Sede e diPeriferia.

• Ambiente KES, che costituisca la base dati in rete perl’archiviazione e la diffusione della documentazione di progetto.

• Ambiente ERP Demo/Addestramento– Una installazione del sistema per erogare il Training alle risorse del

Gruppo di Lavoro e per la verifica delle modalità di funzionamento delsistema.

• Strumenti di Lavoro– Project, Word, Excel,Powerpointdi Microsoft– Accesso ai tool metodologici




PRODOTTIPRODOTTI

OBIETTIVIOBIETTIVI




PRODOTTIPRODOTTI

OBIETTIVIOBIETTIVI

Supporto Tecnologico e Servizi Infrastrutturali

Figura 37 - Esempio di servizi del supporto tecnologico

6.1. Come lo percepiscono gli utenti?

Gli utenti, infatti, percepiscono l’innovazione e la presenza dell’ERP gra-zie ad uno dei servizi forniti nell’ambito di questa attività; quando sulla loro scrivania viene installato un nuovo personal computer – che alla sua accen-sione mostra delle colorate ed ammiccanti videate sia ERP che di altre ap-plicazioni intuibili e facili da usare – il loro vecchio terminale va in pensio-ne per lasciare il posto ad una nuova tecnologia più al passo con i tempi. Grazie ai nuovi strumenti forniti dal progetto sono consentite tante cose fino a ieri impensabili e soprattutto è possibile sfruttare strumenti individuali in forma integrata, non solo tra loro, ma anche con l’ERP. Il nuovo sistema, in-fatti, non si sottrae a questo tipo di integrazione ma, al contrario, ne esalta le potenzialità; consente al singolo utente di utilizzare la capacità elaborativa della sua macchina per produrre proprie informazioni integrando dati fra tut-te le applicazioni presenti sulla sua nuova postazione di lavoro: strumenti di elaborazione testi, presentazione slide, posta elettronica, fogli di calcolo, ERP e così via. Oltre che produrre i requisiti di base e di ambiente per le sta-zioni di lavoro, il supporto tecnologico può svolgere le attività di pianifica-zione e diffusione delle stesse in ambito all’organizzazione di progetto e/o

129

del cliente e, dove previsto, può farsi carico di gestire ed eseguire le richieste di intervento sull’hardware. Altri utenti che si giovano delle attività, dei servizi e dei prodotti del sup-porto tecnologico sono le persone che costituiscono il gruppo di lavoro del progetto: questi, infatti, possono accedere a tutti gli ambienti predisposti per il progetto tanto per poter gestire ogni fase del ciclo realizzativo e di eserci-zio del sistema quanto per fruire di strumenti e riferimenti metodologici, ser-vizi di elaborazione e di rete, installazione hardware e software (dipende co-munque da ogni singolo progetto e dalle sue specifiche esigenze), gestione degli ambienti ERP predisposti per le varie attività di progetto. Ma proce-diamo per ordine e cominciamo a vedere la struttura di base del nuovo siste-ma ed il contributo del supporto tecnologico. L’architettura hardware su cui l’ERP risiede è definita architettura Client – Server che si basa su un concet-to di fondo secondo cui esistono due componenti fondamentali:

1. la macchina che interagisce con l’utente (il Client);

2. l’elaboratore su cui risiede l’applicazione (il Server).

Questo vuol dire che le due componenti di base sono dotate di capacità di e-laborazione autonoma e che tra loro instaurano e gestiscono una comunica-zione continua di scambio dati.

Client ServerRete Locale o Geografica

Figura 38 - Client & Server schema di base

Ora si tenga presente – specie per i non addetti ai lavori – che lo schema su riportato può essere dettagliato ulteriormente e tuttavia costituisce il riferi-mento base da cui prendere lo spunto per dire che vi sono due componenti ERP: una con funzione di interfaccia utente (la GUI – lato client) e l’altra di elaborazione dati (il server) che costituisce la componente applicativa vera e

130

propria. Mentre la componente client è preposta a rilevare le richieste infor-mative dell’utente ed a fornirgli i risultati dell’elaborazione, la parte server contiene l’applicativo che interpreta la richiesta (modulo di interfaccia) ed avvia la funzione di sistema legata alla richiesta (application server), accede alla base dati (data base server), elabora i dati ed invia al client i risultati ot-tenuti. Il supporto tecnologico provvede in prima istanza ad installare tutte le componenti ERP richieste dall’architettura di progetto e successivamente si predispone per erogare un servizio di gestione di base del prodotto. Tipica-mente un progetto, nell’arco del suo ciclo realizzativo, può avere la necessità di definire diversi sistemi ERP e, all’interno di ognuno di essi, più ambienti dedicati a specifiche esigenze. Un progetto sufficientemente articolato può, ad esempio, aver bisogno di un sistema dedicato allo sviluppo, uno all’addestramento, uno al test ed uno per la produzione; nell’ambito del si-stema di addestramento potrebbe aver bisogno di un ambiente di riferimento (preposto ad accogliere tutte le funzioni sviluppate nel sistema di sviluppo), un ambiente dedicato ai corsi che contenga i dati necessari alle esercitazioni ed infine un ambiente dedicato alle libere esercitazioni dell’utente che, tor-nando sul suo posto di lavoro dopo un corso formativo, possa tranquillamen-te interagire col sistema per ripercorrere in autonomia quanto appreso in au-la. Si capisce bene come sia necessario che tutti questi sistemi e tutti gli am-bienti ad essi associati debbano:

essere progettati; realizzati acquisendo l’hardware, il software - di base, di ambiente e di

sistema - ed i dispositivi di connessione; tutti i loro componenti resi funzionanti tanto in termini di abilitazioni di

oggetti quanto di autorizzazioni al loro utilizzo; resi disponibili al gruppo di lavoro; mantenuti durante tutto il tempo necessario al delivery del progetto.

131

6.2. Che cos’è il landscape?

Sistema di SviluppoSYS A

Ambientedi

SviluppoM2

Ambientedi

ProvaM1

Sistema di TestSYS B

Ambientepre

ProduzioneM22

AmbienteConversioni

M11

Sistema di EsercizioSYS PROD

Sistema di FormazioneSYS C

Ambiente

M32Corsi

Ambientedi

RiferimentoM31

AmbienteUtente

M33

M Prod

Sistema di SviluppoSYS A

Ambientedi

SviluppoM2

Ambientedi

ProvaM1

Sistema di TestSYS B

Ambientepre

ProduzioneM22

AmbienteConversioni

M11

Sistema di EsercizioSYS PROD

Sistema di FormazioneSYS C

Ambiente

M32Corsi

Ambientedi

RiferimentoM31

AmbienteUtente

M33

M Prod

Figura 39 - Il System Landscape

Tutte le attività viste in precedenza sono tipiche del supporto tecnologico che, soprattutto nella fase di mantenimento provvede a rendere operative le procedure e le regole di aggiornamento degli oggetti su ogni sistema ed in ogni ambiente ad esso associato. Il system landscape in soldoni, costituisce la mappa dei sistemi ERP, tanto in termini di “Sistemi” (per esemplificare possiamo definirle singole macchine su cui possono risiedere più ERP) che di singoli sistemi ERP. Le regole e le procedure di aggiornamento degli am-bienti e dei sistemi costituiscono le politiche di mantenimento di tutto l’ambiente di progetto nel suo insieme. Ed allora il supporto tecnico si capi-sce bene che ha il compito di definire tanto il landscape quanto le politiche di mantenimento dell’intero sistema e, facendo riferimento alla figura 23, per esempio, provvederà periodicamente a ripulire l’ambiente M1 ricoprendolo con M2, a “trasportare”, a richiesta, gli oggetti aggiornati su M1 verso gli

132

ambienti M11 e M12; a costruire l’ambiente M Prod partendo da M22 nel momento in cui il sistema andrà in produzione, a riaggiornare gli ambienti di SYS C con gli ultimi oggetti prodotti o modificati in M2 e così via.

6.3. Quali strumenti gestire?

Un altro aspetto affatto trascurabile tra le attività del supporto tecnologico è sicuramente il presidio di tutti gli aspetti legati alla metodologia ed agli strumenti in uso nel progetto. In sintesi ci si riferisce a tutte le attività di pre-disposizione e mantenimento degli ambienti destinati a contenere gli stru-menti necessari a rendere operative le attività progettuali e/o di quanto pro-dotto nel loro ambito: tool metodologici, office automation, posta elettronica, controllo progetto, repository dei deliverable prodotti, strumenti di controllo dei flussi autorizzativi e così via. Il presidio di tali aspetti diventa tanto più rilevante quanto più il gruppo di lavoro è dislocato sul territorio. In tali con-dizioni, infatti, la comunicazione e gli standard rivestono un ruolo fondamen-tale se si vuole che tutte le attività vengano ricondotte ad un unico alveo strutturale ed i prodotti abbiano le medesime conformazioni tanto in termini di approccio quanto di layout e contenuti informativi (per esempio a parità di documento si chiede che gruppi operativi diversi facciano comunque riferi-mento ad uno stesso schema di documento e che lo compilino con la stessa tipologia di informazioni). Inoltre, là dove i prodotti della fornitura devono essere verificati ed approvati da più persone, può essere utile legare un si-stema di posta elettronica ad un work flow autorizzativo in modo da coniuga-re necessità di comunicazione con aspetti di qualità e controllo della fornitu-ra stessa. È chiaro infine, che i prodotti realizzati dal progetto devono essere in qualche modo conservati, in tutti i vari stadi produttivi, e quindi messi a disposizione di tutti gli interlocutori del progetto stesso; si pone allora il pro-blema di regolare l’accesso a questi oggetti, considerando le diverse necessi-tà informative che ogni interlocutore può avere, e di realizzare una efficace politica di protezione tanto dalla violazione quanto dalla distruzione, anche se involontaria, di quello che via via il progetto avrà realizzato. Si consideri ancora, che le attività tipiche di mantenimento operativo degli ambienti di progetto, sono di vitale importanza per lo stesso: i sistemi devono essere sempre a disposizione degli utilizzatori (utenti, specialisti, management ecc.)

133

pena l’inefficienza operativa ed il conseguente aggravio di costi, i carichi delle macchine sempre ben bilanciati per consentire tempi di risposta accet-tabili sia da un punto di vista realizzativo che di efficacia nelle dimostrazioni (solo per fare qualche esempio), le politiche di salvataggio finalizzate a ripri-stinare le versioni più aggiornate dei prodotti realizzati.

Questo è solo un piccolo spaccato delle necessità di sup-porto che un progetto può richiedere al suo team tecnologico in termini di sostegno all’attività produttiva; ricorrendo ad un’allegoria, possiamo dire che tutto il progetto è da conside-rarsi una “torre” di attività in cui ogni piano si regge sul sot-tostante ed è da esso alimentato e sostenuto. Allo stesso modo le attività di realizzazione non potrebbero avvenire senza il

sostegno tecnologico e le attività di comunicazione e controllo della realizza-zione non avrebbero senso di fronte a carenze di strumenti e di supporto.

6.4. Anche l’architettura d’interfaccia?

Come abbiamo visto, inoltre, gli specialisti ERP non potrebbero costruire il sistema se non avessero degli elaboratori efficienti ed in grado di funzionare con continuità; i prodotti realizzati dal progetto non sarebbero fruibili se i si-stemi non fornissero risposte in tempi adeguati e non proteggessero effica-cemente quanto custodito, una organizzazione efficiente non potrebbe esiste-re se gli strumenti di supporto alla comunicazione non fossero adeguatamen-te progettati e mantenuti nel tempo.

134

Sistema ERP

Componenti funzionali

Ambiente

Componenti di comunicazione

Componenti Fisici

Componenti di comunicazione

Componenti funzionali

Sistema da Interfacciare

Ritorno

Andata

Figura 40 - L'architettura d'interfaccia

Ma, a proposito di comunicazione, come è possibile che il sistema ERP co-munichi con altri sistemi? Questo è un altro dei problemi che il team di sup-porto tecnologico deve gestire nell’ambito del progetto realizzativo! Quando abbiamo parlato di interfacce abbiamo fatto riferimento ad uno schema logi-co di connessione riportato dalla fig. 29; in questo capitolo (fig. 40), invece, si mette in evidenza l’esistenza di un ambiente d’integrazione che supporti lo schema logico visto e che, per essere realizzato, necessita di una base sovra-strutturale su cui poggiare i suoi componenti. In altre parole è necessario progettare e realizzare un livello di software capace di fare da cuscinetto tra le componenti funzionali delle interfacce ed il livello di comunicazione di base fornito dagli elaboratori su cui tali componenti risiedono. La necessità di questa sovrastruttura nasce dalla opportunità di rendere sincrone le fun-zioni classiche di ricezione ed invio dei dati, la schedulazione e l’avvio dei componenti l’interfaccia, il controllo degli errori e la ripresa automatica dei processi interrotti. In altre parole è conveniente, anche per motivi di efficien-za dell’ambiente di gestione operativa delle macchine, definire uno strato di

135

software (detto proprio software d’ambiente) che renda omogenea l’integrazione e che sia al contempo abilitatore e facilitatore dei processi d’interfaccia. È come costruire, in sintesi, un monitor di governo di tutte le componenti che da un lato offra opportunità di più efficaci sviluppi applica-tivi – per esempio la definizione esterna alle interfacce di tutti i parametri di connessione e di identificazione dei dati – e dall’altra standardizzi le attività di gestione operativa dell’ambiente di base del sistema con possibilità di de-finire calendari di elaborazione, priorità per lo scheduling, aggancio automa-tico di programmi applicativi, gestione controllata degli errori.

6.5. E le stampe? Un altro aspetto da considerare tra le attività del team di supporto tecno-logico è quello relativo alla definizione di un’architettura complessiva del sistema di stampa. Là dove i volumi delle informazioni da produrre - su sup-porto cartaceo - raggiungono livelli considerevoli e comunque si presenta la necessità di stampa in tempi rapidi, il pensare a strumenti più adeguati e di-stribuiti diventa un fatto da prendere seriamente in considerazione.

136

SAPClient

SAPServer

Mainframe

3270

Centro Stampa

Attività manageriali

1994 1995 1996

Attività operativa

Venditore

StampanteVeloce

Figura 41 - L'Architettura di stampa

Si consideri soprattutto quelle tipologie di report che subiscono più pro-cessi oltre alla produzione della sola stampa e che possono richiedere delle gestioni ad hoc (selezione, imbustamento, produzione su registri bollati ecc.). Inoltre l’impatto di gestione delle stampe sulle performance della macchina può diventare un fatto preoccupante soprattutto considerando la peculiarità dell’ERP che è quella di essere un sistema on–line; in questo caso, infatti, il numero di utenti che può interagire col sistema ed il volume di dati da essi prodotto e da gestire – sui server e sui client – potrebbe mettere in crisi l’architettura di sistema tanto per i tempi di risposta richiesti quanto per i vo-lumi di traffico generati sulle linee. Per ovviare a tutto questo il supporto tecnologico deve pensare ad un’architettura complessiva del sistema di sup-porto ai processi di stampa: definire le esigenze, i tempi, i volumi ed i pro-cessi richiesti sono il primo passo per individuare strumenti, supporti e dislo-cazione delle macchine, tipologie di stampanti e macchinari accessori nonché eventuali strutture organizzative di gestione. Il tutto inoltre dovrà essere rap-portato a quanto in essere nell’organizzazione cliente e quindi darà vita ad un piano di realizzazione e ad un piano di approvvigionamento per quanto si rendesse necessario acquistare all’esterno. Un esempio di quanto deve essere affrontato in questo ambito è certamente costituito dai processi di “chiusura” mensile; questi, infatti, richiedono una grande interazione col sistema tanto in termini transazionali quanto di interrogazione della base dati e produzione di stampe; si pensi soprattutto alla consuntivazione del Controlling dove tutto

137

il management è impegnato nel produrre situazioni di confronti bu-dget/consuntivi e dove tali attività possono sovrapporsi a quelle di routine di tutti i giorni: abbiamo detto che l’ERP produce le stampe direttamente su vi-deo al momento della richiesta dell’utente (e stampare successivamente su carta) e questo, normalmente, si traduce in un fabbisogno di potenza di cal-colo dell’elaboratore su cui risiede il sistema. Considerando il numero di u-tenti che in un certo istante possono richiedere situazioni – tanto a video quanto su carta – che, lo ricordiamo, possono essere “concorrenti” con gli utenti “abituali” del sistema, si comprende bene come la macchina, specie se non correttamente dimensionata, potrebbe essere appesantita dal volume ec-cezionale di richieste di tutti gli utenti di quel periodo. Allora un modo per non richiedere eccessive risorse macchina potrebbe essere quello di produrre di notte i maggiori volumi di stampa e provvedere a “parcheggiarle” sulle code di stampa. In questo modo il management potrebbe utilizzare le stampe già prodotte (anche sfruttando le opzioni di drill-down) e nel contempo, gli altri utenti, usufruire di tutte le funzionalità abituali del sistema ottenendo tempi di risposta accettabili.

7. Formazione – Cosa fare?

Già nei capitoli precedenti, a proposito di gestione del cambiamento, ab-biamo avuto modo di osservare come la formazione giochi un ruolo determi-nante sia nell’utilizzabilità del nuovo sistema che nella diffusione dei nuovi processi e del nuovo modo di lavorare. Gli esperti del settore, tuttavia, ci av-vertono che parlare di formazione come sinonimo di addestramento è del tut-to improprio e che occorre qualche precisazione; se ci riferiamo all’utilizzabilità del sistema in una certa organizzazione occorre tenere pre-sente due aspetti:

1. la necessità di definire nuovi ruoli e figure aziendali non previste

dall’attuale organizzazione ma indotti dall’adozione del nuovo sistema; 2. la capacità delle persone ad utilizzare i nuovi strumenti. Per esemplificare possiamo allora dire che il primo aspetto è riconducibile all’interno di un quadro più generale di formazione delle risorse umane - le-gato al “sapere” ed al ruolo che tali persone dovranno sostenere all’interno

138

dell’organizzazione - ed è in stretto rapporto con l’evoluzione delle politiche di gestione del personale (percorsi di carriera, valutazione del potenziale, ge-stione delle capacità ecc.); il secondo, più operativo, è connesso al “saper fa-re” ovvero all’abilità delle persone nell’usare tecniche, strumenti e quant’altro sia utile a sostenere il ruolo assegnato nell’ambito dell’organizzazione. Per rendere più chiaro quello che qui si vuol dire, fac-ciamo ricorso ad un esempio pratico e supponiamo che l’adozione dell’ERP richieda, per esempio, che all’interno dell’azienda ci sia bisogno di una figu-ra professionale - che definiremo “pianificatore degli approvvigionamenti” – non presente in quell’azienda. È naturale che si ponga il problema di identi-ficare le persone “giuste” che per potenziale, capacità ed esperienze siano in grado di sostenere questo nuovo ruolo; occorre ancora definire un percorso formativo che metta queste persone in condizione di conoscere il problema in tutte le sue sfaccettature: tanto teoricamente (ovvero in che cosa consiste la pianificazione degli approvvigionamenti, da dove ed in che modo vengono originati i fabbisogni, i problemi di processo connessi ai tempi ed alla logi-stica ecc.) quanto praticamente ovvero riferiti alla realtà della loro azienda (come l’azienda pensa di realizzare quei processi, che relazioni dovranno es-sere mantenute e con chi, quali obiettivi l’azienda pensa di perseguire e con che organizzazione e così via) e delle tipologie di strumenti a supporto dell’area di pertinenza. Proprio in quest’ultimo ambito trova posto il siste-ma: lo strumento che abilita e supporta le persone nel sostenere il loro ruolo aziendale; il sistema, infatti, ha un suo modo di funzionare ed implica certi comportamenti. Infatti per fornire risultati attendibili, occorre che venga ali-mentato correttamente e con responsabilità e, per questo, è necessario che sia conosciuto adeguatamente da tutti gli utilizzatori sia in termini di utilizzo delle funzioni quanto in termini di flusso e sequenza delle stesse nell’ambito del processo operativo.

Ora si capisce bene come, per raggiungere appieno l’obiettivo, sia neces-sario soddisfare le due specificità formative e comunque, per ambito di rife-rimento, in questa sede si farà cenno ai soli aspetti addestrativi rimandando a lavori più specialistici quanto più propriamente legato alla formazione.

7.1. Chi addestrare? – Il censimento della popolazione target

139

Ovviamente quando si intende addestrare qualcuno occorre stabilire “chi” , nell’ambito dell’organizzazione cliente, deve essere addestrato; occorre cioè identificare le persone che, per ruolo, attività ed obiettivi aziendali sa-ranno i futuri operatori del nuovo sistema: l’obiettivo dell’addestramento. Per procedere a questa operazione è opportuno definire: • gli obiettivi da raggiungere; • l’approccio da seguire; • i criteri di selezione; • le caratteristiche e le competenze delle persone; • gli elementi di misura del raggiungimento degli obiettivi. In genere gli obiettivi da raggiungere con le attività di addestramento sono derivabili dagli obiettivi più generali di progetto (c.f.r. Il prestudio – È chia-ro come si intende procedere?) e da quanto dicevamo in premessa a questo capitolo a proposito di addestramento. In estrema sintesi qui vogliamo che gli utenti individuati siano in grado di utilizzare il sistema, che conoscano il nuovo modo di lavorare e che sappiano cogliere i benefici indotti dall’integrazione ovvero comprendano il supporto fornito dai nuovi strumen-ti nel corso del loro lavoro quotidiano. Dovendo allora addestrare del perso-nale dell’azienda cliente si pone subito il problema di stabilire le modalità con cui dar luogo a tali attività; in altre parole possiamo dire che si pone il problema di definire un approccio all’addestramento considerando sia l’organizzazione della struttura aziendale del cliente sia le specifiche compe-tenze messe in campo dal fornitore e le relazioni che dovranno essere stabili-te tra queste due entità. In altre parole occorre prima di tutto che il progetto abbia definito nel suo ambito che cosa farà in termini di addestramento; quali relazioni saranno stabilite con la funzione aziendale del cliente preposta alla formazione (ed alla comunicazione che vedremo subito dopo) e soprattutto dovrà essere definito chi è responsabile di fornire che cosa a chi. Supponia-mo che il progetto abbia bisogno banalmente dell’elenco delle persone da formare: occorre che qualcuno dell’organizzazione cliente fornisca questi da-ti al progetto. Come procedere? È la formazione cliente che si fa unico inter-locutore verso il progetto o questi deve relazionarsi con l’ufficio del persona-le direttamente? In altre parole ci si pone un problema di questo tipo:

140

FunzioneFormazioneProgetto

FunzionePersonale

FunzioneOrganizzazione

AltreFunzioni

Progetto

FunzionePersonale

FunzioneOrganizzazione

AltreFunzioni

FunzioneFormazione

Relazione “A”

Relazione “B”

Figura 42 - Relazioni progetto/funzione formazione

Che tipo di relazioni il progetto deve gestire? Uno a uno con la formazione che provvederà a gestire i rapporti in seno all’organizzazione cliente (rela-zione “A”) o uno a molti quante sono le strutture aziendali da coinvolgere di volta in volta (relazione “B”)? Ovviamente non c’è una sola risposta a questo tipo di domanda in quanto dipende dalla specifica realtà progettuale e dalla organizzazione del cliente; possiamo solo osservare che, muovendosi il pro-getto nell’ottica di contenere la complessità dei rapporti progettuali, la dove applicabile, la relazione tipo “A” sarà privilegiata rispetto all’altra proprio per mantenere il più basso possibile “il rumore di fondo” ed i “disturbi” ver-so il progetto. Stabilita la relazione con la funzione della formazione e sup-ponendo una fattiva collaborazione tra quest’ultima ed il progetto occorrerà che di concerto si stabilisca il migliore approccio all’addestramento degli u-tenti del sistema ovvero: 1. l’utente si addestra da solo (autoaddestramento); 2. i colleghi più esperti addestrano quelli meno esperti; 3. i consulenti che hanno realizzato il sistema addestrano solo un gruppo di

utenti; 4. i consulenti addestrano tutti gli utenti; 5. …. E così via.

141

7.2. Come? – Applicazione dell’approccio definito

Per semplicità conviene che ci soffermiamo sui quattro punti su riportati, che ci sembrano quelli più proponibili in generale, senza comunque esclude-re la possibilità di adottare altre tipologie di approccio in funzione delle spe-cifiche esigenze di ambiente e/o di progetto che ognuno si trova ad affronta-re. Osserviamo allora che il primo approccio, quello cioè fornito dall’autoaddestramento, è conveniente quando il numero delle funzioni da descrivere è contenuto (una o due al massimo), la complessità dell’argomento è anch’essa contenuta e gli utenti sono molto numerosi. Tipi-camente strumenti CBT (Computer Based Training) o WBT (Web Based Training) possono essere efficaci nello scopo in quanto gli argomenti trattati non richiedono la necessità di normali sessioni d’aula. Il secondo approccio ha il merito di essere sicuramente e di gran lunga il più efficace là dove esi-stono le condizioni per poterlo applicare. Con questo voglio dire che se a raccontare le cose è una persona con un certo peso nell’organizzazione (quel-lo cioè con maggiori capacità, esperienza ed autorevolezza) il discente è più a suo agio perché ha un interlocutore che gode della sua stima e “parla un linguaggio” molto più simile al suo di quanto non possa un’altra persona e-sterna alla sua organizzazione. Il processo di apprendimento che in genere è basato sullo scambio tra docente e discente, ne risulta più efficace ed effi-ciente in quanto i termini del nuovo linguaggio vengono tradotti nell’idioma di tutti i giorni e chi li racconta è in grado di portare innumerevoli esempi che facciano capire tanto il nuovo modo di lavorare quanto le differenze ri-spetto “a prima”. E questo è quanto la gente ha bisogno di recepire sia per accettare il nuovo sistema che per poterlo utilizzare al meglio (anche se non sono gli unici elementi!) pur considerando che questo approccio richiede all’organizzazione cliente un maggiore sforzo sia in termini di disponibilità di risorse umane che di competenze da dedicare al progetto. Tale modalità, tuttavia, ben si coniuga con l’approccio riportato al punto 3 nel senso che ad-dirittura lo integra. L’organizzazione del fornitore, infatti, potrà limitarsi a formare un certo numero di “super utenti” e lasciare a questi il compito di condurre l’addestramento ti tutta la popolazione censita limitandosi even-tualmente ad intervenire “a supporto” solo là dove ritenuto necessario da qualche super utente. Tale approccio è stato adottato con successo in molti progetti soprattutto quando la disponibilità di persone dell’organizzazione cliente lo ha consentito; i risultati si sono dimostrati di gran lunga più ap-

142

prezzabili che in tutti gli altri casi. Certo si è dovuto formare persone a “tene-re” l’aula, ad usare strumenti e tecniche di esposizione, ma la loro esperienza di business li faceva essere facilmente efficaci e la loro autorevolezza li ren-deva la voce vera dell’azienda … quella che cioè indica la strada da seguire nel nuovo processo di cambiamento.

L’alternativa a tale approccio è costituito dalla possibilità di delegare tutto al fornitore ed ai suoi specialisti. È possibile che l’azienda cliente non sia in grado di esprimere sia in numero che in qualità, competenze e risorse ade-guate nel progetto e quindi, per forza di cose, deve delegare in tutto, o gran parte, al fornitore. Si noti che là dove la fornitura non preveda l’addestramento utenti (o per incompletezza contrattuale o per servizi non erogati dal fornitore) ma semplicemente la produzione di un manuale di uti-lizzo del sistema, l’organizzazione cliente si dovrà far carico di identificare una strategia idonea a realizzare tali attività parallelamente alle attività rea-lizzative di progetto e dovrà gestire in prima persona gli eventuali diversi fornitori, per le due tipologie di fornitura, garantendosi il coordinamento ed il contenuto di tutte le attività e dei prodotti relativi in tempi coerenti tra di loro.

143

7.3. Su che cosa addestrare? – Il disegno dei corsi

Supponendo di avere un unico ente preposto all’addestramento e che le relative attività siano in carico al progetto, il passo successivo è quello di progettare i corsi tanto in termini di approccio previsto quanto in coerenza con le figure professionali identificate, le funzioni di sistema realizzate e le modalità di erogazione stabilite. In altre parole occorre identificare tutti gli elementi distintivi dei corsi in modo da definirne: • le caratteristiche (tipologia e target); • gli obiettivi; • le fasi (articolazione e durata); • i contenuti (funzioni realizzate, processi operativi ed esercitazioni ); • le modalità operative di erogazione (chi fa/dice che cosa e con che mez-

zi) • vantaggi e criticità; • l’aggregazione dei moduli di corso per profilo professionale; sì che si possa giungere alla definizione di un “catalogo dei corsi” e ad una “scheda riepilogativa” che, per ogni corso, descriva sinteticamente titolo, o-biettivo, profili professionali target, durata, modalità didattica, contenuto principali funzioni (dove disponibili). In questo modo si avranno a disposi-zione strumenti adeguati tanto per fini divulgativi (comunicazione) quanto per valutazioni gestionali (logistica, pianificazione, calendari, associazione persone/corsi ecc.). Si noti che tra gli strumenti di supporto alla erogazione dei corsi un contributo determinante può essere fornito dal “manuale di uti-lizzo del sistema” (cfr. § 4.4 La documentazione – Che cosa documentare?) che, se opportunamente costruito, potrebbe essere utilizzato per fornire agli utenti tanto gli elementi di utilizzabilità del sistema quanto le modalità con cui lo stesso manuale può essere fruito.

7.4. Chi sarà addestrato su che cosa?

144

Definiti i corsi e le figure professionali a tendere (vecchie e nuove per l’organizzazione) si pone il problema di incrociare le due entità in modo da ottenere una vista del tipo “chi farà che cosa” nell’ambito del nuovo sistema societario per cui si pongono le basi anche per una prima impostazione delle “Autorizzazioni” all’utilizzo delle funzioni del sistema. Questo significa che se tutti gli utenti potranno fare, per esempio, le richieste di acquisto, solo al-cuni, i capi ufficio, potranno autorizzarle veicolandone l’inoltro verso l’ufficio acquisti. Se da un lato stiamo dicendo chi fa che cosa:

Contenuto dell’addestramento

Profili d’utenza

Introduzione

R.d.A.

Autorizzazione

R.d.A

Processo

R.d.A.

Utente Generico X Capo Ufficio X X Acquisitore X X Dall’altra stiamo implicitamente assumendo che: 1. l’utente generico potrà usare esclusivamente la funzione di inserimento

delle r.d.a.; 2. il capo ufficio anche la funzione di autorizzazione delle r.d.a.; 3. l’acquisitore, dal canto suo, potrà usare la funzione di inserimento delle

r.d.a. (in quanto utente generico) e potrà usare tutte le funzioni per tra-durre in ordine le r.d.a. autorizzate; non gli sarà consentito autorizzare le r.d.a. perché non è previsto che impari a farlo!

Ora diventa evidente che quando andremo a pianificare le sessioni dei corsi dovremo tenere conto del fatto che il corso di Introduzione delle r.d.a. dovrà essere fruibile anche per i capi ufficio e per gli acquisitori che avranno altri corsi (autorizzazioni e processo r.d.a.) da sostenere e per questo, la pro-grammazione dei corsi stessi, dovrà essere opportunamente schedulata per consentire a tutte le figure professionali di poter fruire di tutti i corsi per loro previsti. Un altro aspetto importante da tenere presente in questo frangente e l’attribuzione delle persone fisiche ai singoli ruoli (o figure professionali) in

145

modo da porre le basi sia per una corretta attribuzione delle autorizzazioni che vedremo meglio dopo, sia per una pianificazione efficiente di tutte le sessioni dei corsi che saranno erogati.

7.5. Quali strumenti usare nei corsi? – I materiali didattici

In base a quanto già visto a questo punto risulta più evidente che i mate-riali didattici sono da considerarsi fortemente correlati all’approccio definito. Trascurando per un attimo il quanto necessario per l’autoaddestramento (si vedano le voci CBT e WBT del vocabolario erpese) ci possiamo concentrare sui corsi erogati in aula che per complessità e necessità sono di gran lunga più significativi: vediamo perché. Innanzi tutto si tenga presente che la predi-sposizione delle aule è fondamentale per l’erogazione dei corsi per cui, tanto i PC quanto le connessioni con la rete aziendale e gli ambienti ERP predi-sposti per la formazione, sono fondamentali per la buona riuscita dei corsi. Inoltre i docenti avranno bisogno di una “guida” che li conduca per tutte le fasi del corso fornendogli “il cammino” da seguire nell’ambito dell’articolazione e della durata dello stesso. È importante che tali guide for-niscano loro l’evidenza delle cose importanti da sottolineare, diano traccia degli esercizi da compiere e delle soluzioni previste, prevedano i tempi per ogni argomento e riportino le criticità e/o i punti di attenzione per ogni spe-cifica funzione o processo operativo. Non di rado i docenti potrebbero tro-varsi ad utilizzare strumenti multimediali (generalmente audio e video inte-grati con computer) che aiutino a simulare situazioni reali e tali strumenti dovranno essere predisposti e verificati prima dell’erogazione dei corsi per non pregiudicarne il buon esito. Non di meno, dal punto di vista del discente, una guida del partecipante che lo guidi passo passo per tutta la durata e l’evoluzione del corso, può agevolare l’apprendimento (p.e. con ampi spazi per gli appunti) e sicuramente contribuisce a fare in modo che “non si senta perso” collocando correttamente ogni argomento all’interno del quadro d’insieme. Non ultimo, come abbiamo già detto, l’impiego del manuale di utilizzo del sistema che, come abbiamo già visto, contiene cose che qui pos-sono essere utilizzate:

146

- le mappe dei processi a diversi livelli di dettaglio e la documentazione dei nuovi modelli (di controllo, di reporting, di autorizzazioni ecc.);

- le procedure organizzative che regolano i vari processi aziendali e gli or-ganigrammi delle funzioni coinvolte dai processi ;

- le procedure operative con tutte le attività comprese quelle “fuori siste-ma”;

- la collezione delle transazioni standard e personalizzate del sistema;

perché è articolato per livelli, garantisce la navigabilità per la ricerca delle informazioni, riporta sia i processi che le procedure operative (come si la-vora con le nuove funzioni offerte dal sistema ed il loro funzionamento), descrive tutte le componenti del sistema; tutti elementi questi che a ben guardare, vanno incontro tanto alle esigenze di addestramento sul sistema quanto all’apprendimento dei nuovi processi introdotti col cambiamento.

7.6. Quando erogare i corsi? – La pianificazione

Probabilmente è l’aspetto più complesso da gestire considerando che la complessità cresce esponenzialmente col numero delle persone da addestra-re, con le aule a disposizione in rapporto al numero di corsi (e loro sessioni) da erogare, il numero di ricicli da effettuare per garantire che tutta la popola-zione coinvolta possa partecipare ai corsi stabiliti per la figura professionale di appartenenza (si pensi per esempio alle rinunce dell’ultimo momento ed alla necessità di spostare le persone da una sessione ad un’altra). In ogni caso la prima cosa da fare è sicuramente la determinazione del numero di aule da impiegare, la loro esistenza, l’eventuale predisposizione degli strumenti per attrezzarle ed il loro cablaggio per i collegamenti verso gli ambienti di for-mazione previsti per il nuovo sistema. Fatto questo e avendo definito il nu-mero di corsi e le sessioni per ognuno di essi si procederà alla verifica della compatibilità de:

1. i tempi di acquisizione e predisposizione aule;

147

2. i tempi di approvvigionamento degli strumenti didattici non presenti in azienda;

3. la disponibilità delle aule rispetto al numero di corsi da erogare;

4. la coerenza dei tempi di erogazione con i tempi di avvio del sistema (non si può arrivare né troppo “prima” né troppo “dopo” l’apertura del sistema all’utenza);

5. i tempi di disponibilità delle funzioni del sistema (standard e nuove);

6. i tempi di disponibilità delle procedure operative;

7. i tempi di disponibilità ed aggiornamento del manuale di utilizzo;

8. la coerenza della distribuzione geografica delle aule e degli utenti;

9. la coerenza sessioni da erogare e disponibilità formatori;

10. i tempi di comunicazione;

la cui soluzione, come si può intuire, non è immediatamente evidente ma è il risultato di un lungo ed articolato processo di pianificazione e modulazione in funzione tanto degli eventi di variazione del quadro d’insieme quanto de-gli elementi su menzionati che lo compongono. In ogni caso si dovrà perve-nire ad un piano complessivo di progetto che armonizzi i tempi di realizza-zione, quelli di addestramento e comunicazione configurando il piano di ad-destramento con una granularità delle attività adeguata a tenere sotto control-lo la singola sessione addestrativa. Ora l’ultimo aspetto legato alla pianifica-zione dell’addestramento è quello relativo all’attribuzione delle persone fisi-che alle varie sessioni previste per ogni tipologia di corso. Per questa attività strumenti automatici di scheduling possono dimostrarsi sicuramente efficaci considerando la movimentazione che si produce normalmente durante tutta la fase di erogazione dei corsi. Con questo voglio dire che se si è fatto ricorso a strumenti automatici di gestione, risulta meno complesso ridistribuire le persone sulle varie sessioni nel caso di rinunce o impossibilità di partecipa-zione indotte dalle “solite esigenze improrogabili dell’ufficio”, assenze e così via; queste, infatti, potrebbero essere facilmente gestite dallo strumento de-mandando al progetto o alla funzione di formazione dell’azienda cliente solo il trattamento della comunicazione degli eventi (che non è di poco conto se si pensa ad organizzazioni piuttosto numerose!).

148

7.7. Chi farà che cosa col nuovo sistema? – Le autorizzazioni ed i profili Un problema spinoso? Indubbiamente si! È una cosa da non sottovalutare mai perché: ♦ ha un forte impatto sull’operatività delle persone; ♦ può pregiudicare la fase di avviamento del sistema; ♦ non sempre se ne avvertono immediatamente le implicazioni in quanto la

definizione dei profili avviene in tempi precedenti alla loro assegnazione e quindi, questa prima definizione, risente di una impostazione “teorica”;

♦ richiede un lavoro “a quattro mani” che vede coinvolto il progetto, le funzioni aziendali cui è diretto il sistema, la funzione organizzazione dell’azienda cliente, l’ente gestore dell’ambiente di esercizio del sistema se questi è diverso dall’azienda cliente.

Ma vediamo bene quale sia la criticità insita nell’attività di definizione

delle autorizzazioni e nella loro applicazione a sistema. Tali autorizzazioni, infatti, si tradurranno in profili autorizzativi di sistema che, associati ad ogni utente, esprimeranno le possibili operazioni fattibili da ogni utente nell’ambito del sistema realizzato (oggetti usabili). Ma come procedere? In-nanzi tutto occorre definire tutte le figure professionali che si avvarranno del sistema (non si parte da un foglio bianco ma dal censimento fatto nell’attività di identificazione delle figure professionali) al massimo dettaglio possibile: questo vuol dire che se in una prima analisi è stata individuata, per esempio, la figura di “Acquisitore”, ora occorrerà definire quanti tipi di acquisitori a-vrò nel sistema (p.e. di materiali piuttosto che di prestazioni, oppure per tipo-logia di materiali, di prestazioni o per valore di fornitura ecc.). Per ogni tipo-logia di utente identificata occorrerà associare l’insieme degli oggetti da essi utilizzabili nell’ambito dei processi definiti a sistema (i profili di utenza) e, successivamente, costruire la tabella di associazione tra profili di utenza e gli utenti veri e propri (le loro user id). Ora sono più chiare le asserzioni fatte all’inizio del capitolo: Questa attività ha un forte impatto sull’operatività del-le persone in quanto è qui che si definisce “che cosa” ogni utente può fare nel sistema tanto in termini di operazioni quanto di visibilità e manipolazione

149

dei dati; e questo non è di poco conto perché si ripercuote immediatamente sull’avviamento del sistema in produzione. È solo in questa fase che si avrà “la prova” dell’attività di associazione utente/profilo; quando l’utente chia-merà per comunicare la sua “impossibilità a fare le cose che faceva normal-mente prima” è probabile che inneschi un’attività di revisione dell’attribuzione dei profili e quindi sia costretto a subire ritardi nelle sue at-tività dovute da quanto dovrà fare il gruppo di sviluppo del progetto per si-stemare le cose. Adesso chiariamo anche perché è un lavoro da farsi “a quat-tro mani”: quando l’utente chiamerà per esternare la sua impossibilità a fare delle attività ci si troverà di fronte a queste due possibilità:

1. è giusto che sia così: il suo ruolo è stato ridefinito; 2. il processo è cambiato e le sue attività rivisitate per cui non deve fare co-

se che faceva prima; 3. il profilo che gli è stato attribuito è effettivamente non corretto per cui va

revisionato. È evidente che in tutti i casi non può essere solo il progetto ad entrare nel merito delle questioni (a meno di non averne la delega e le competenze) ma piuttosto diventa opportuno instaurare un dialogo tra funzione aziendale, or-ganizzazione, personale e progetto in modo che venga verificato: ♦ il ruolo a fronte dei nuovi processi; ♦ il percorso di crescita previsto per quell’utente; ♦ l’eventuale revisione del profilo se previsto; ♦ ….. e così via in funzione delle regole che ogni azienda si sarà data per gestire il fenomeno.

7.8. Bisogna comunicare? Che cosa? A chi?

La comunicazione gioca un ruolo estremamente determinante nel realiz-zare un’iniziativa di successo, tanto da richiedere che il capo progetto segua

150

la buona norma di costruirsi una griglia di informazione che riporti da un lato gli interlocutori e dall’altra i momenti di comunicazione. L’obiettivo è quello di ottenere un incrocio del tipo: - chi dovrà preparare l’informativa; - l’oggetto dell’informativa; - chi dovrà informare; - chi dovrà essere informato; - i tempi di erogazione delle informazioni; in modo da giungere ad un vero e proprio piano di comunicazione che dovrà essere integrato a tutti gli effetti col piano di progetto. Anche qui è probabile che il piano debba essere rivisto ad ogni fase di progetto; voglio dire che non sempre le informazioni sono disponibili “tutte insieme” ed allo stesso mo-mento e ciò significa che tale piano, una volta definito, potrà evolvere con maggior precisione nel tempo e potrà essere sottoposto a revisioni e ripiani-ficazioni come ogni qualsiasi altro piano di lavoro. Vediamone il contenuto.

Tutti gli attori del processo di cambiamento dovrebbero essere costante-mente aggiornati tanto sulle attività da svolgere e le loro modalità realizzati-ve quanto sui risultati parziali o definitivi raggiunti; qui ci si riferisce non so-lo alle persone componenti il gruppo di lavoro del progetto – che come ab-biamo visto, hanno un’estrazione culturale ed una provenienza organizzativa diverse – ma anche a tutti gli altri protagonisti che interagiscono col progetto sia per fornire informazioni e prestazioni (si pensi alle necessità informative che il progetto può avere dall’esterno!) quanto per riceverne (per esempio l’addestramento). Durante tutto il ciclo di vita del progetto è fondamentale che le risorse allocate comunichino tra di loro e che il progetto costituisca “un clima” tipico del progetto stesso; le persone devono sentirsi parte inte-grante del progetto e conERPevoli del fatto che tutti i loro colleghi concorro-no al raggiungimento degli stessi obiettivi. Questo è fondamentalmente il cemento che terrà legate le persone del progetto le cui organizzazioni di ap-partenenza possono avere anche obiettivi societari diversi tra loro; l’importante è che si crei conERPevolezza della necessità di “remare tutti in-sieme” verso lo stesso obiettivo comune ed in tal senso attività di “costruzio-ne del gruppo” (dall’inglese team building) sono indispensabili, specie all’avvio del progetto, quanto più numeroso ed eterogeneo è il gruppo di la-voro.

151

Un secondo momento di comunicazione fondamentale deve essere instau-rato tra il progetto ed il suo principale interlocutore che detiene le informa-zioni necessarie a costruire il sistema; generalmente sono le funzioni orga-nizzative della società cliente cui il sistema è destinato ed in special modo i vertici di tali funzioni e tale attività di comunicazione dovrà essere instaurata e mantenuta per tutto il ciclo di vita dello stesso progetto. Qui è indispensabi-le che il team di sviluppo si faccia promotore di continui messaggi informa-tivi che spieghino sia il percorso metodologico dell’attività realizzativa (cioè come si intende procedere per realizzare un prodotto) sia le componenti che costituiscono il prodotto finale e “lo stato dell’arte”. Chi non ha mai parteci-pato ad un progetto di questo tipo deve comunque rendersi conto di che cosa sarà fatto e di come si arriverà ad ottenerlo; tale processo cognitivo e fonda-mentale se si vuole da un lato la piena partecipazione di tutti i componenti il gruppo di progetto e dall’altra rendere trasparente il processo realizzativo verso i destinatari del prodotto finale al fine di agevolarne l’accettazione! È chiaro! … quanto più il destinatario sarà consapevole di come si sta operan-do e di che cosa deve aspettarsi, tanto più riuscirà a capire quello che gli sarà consegnato e a controllarne l’utilizzabilità e l’efficacia che si aspetta dal pro-dotto che si sta realizzando. Il risultato di tale processo è una maggiore velo-cità di accettazione dei prodotti ed una conseguente maggior efficienza ed efficacia nei rapporti contrattuali (p.e. accettazione delle milestone!).

Analogamente la comunicazione nei confronti del committente e del suo top management aziendale avrà lo scopo di informare “sullo stato dell’arte”, richiedere approvazioni su eventuali change contrattuali, dirimere controver-sie sui processi di confine tra le varie funzioni interessate, approvare lo stato avanzamento complessivo del progetto, promuovere ed assecondare la co-municazione prestandone “i protagonisti” (si pensi al ruolo che possono gio-care figure aziendali quali direttori, amministratori delegati e presidenti) e gestire le aspettative di cambiamento (motivazioni, sistema premiante, obiet-tivi per il management e così via). Il concetto di fondo che deve accompa-gnare il capo progetto, in questo tipo di comunicazione, è costituito dalla ne-cessità di creare consapevolezza su una questione di base: il suo progetto po-ne solo il primo mattone di un processo di più lungo respiro e che prosegue lungo la direttrice della maggior consapevolezza e del miglioramento conti-nuo. In buona sostanza qui la comunicazione sarà tesa ad esprimere: ♦ le necessità di intervento del top management per togliere il progetto da

situazioni di impasse;

152

♦ la necessità di ottenere l’approvazione degli stati avanzamento di proget-to che abbiano significato contrattuale;

♦ la richiesta di partecipazione del top management nei momenti di comu-nicazione istituzionali del progetto (es. discorsi di incitamento nell’avvio di fasi progettuali, introduzione di attività di workshop, messaggi forti durante le fasi di formazione e celebrazione dei risultati raggiunti ecc.);

♦ porre le basi perchè gli obiettivi di business si integrino con gli obiettivi di progetto;

♦ proporre e ratificare un sistema premiante per le risorse allocate al pro-getto;

♦ illustrare i maggiori risultati ottenuti anche con demo a sistema; con l’obiettivo di “agevolare” il percorso realizzativo del progetto tenendo conto che lo stesso lascerà un’eredità che dovrà essere raccolta dall’organizzazione del cliente sia in termini di miglioramento dei processi (cambiamento continuo) che di evoluzione del sistema realizzato.

In altre parole, se il progetto si muove in senso orizzontale all’organizzazione, – investendola cioè a tutti i livelli impattati dai cambia-menti introdotti – il processo di intervento del management sarà indirizzato dall’alto verso il basso in modo da pervadere l’organizzazione seguendo i canali “ufficiali” dell’azienda e conferendo carattere di capillarità all’informazione. In tal modo tanto gli obiettivi di miglioramento quanto la caratteristica dell’impegno saranno diffuse a tutti i livelli aziendali che si sentiranno ”investiti” della responsabilità del raggiungimento degli obiettivi di cambiamento. Ora perché tutto il processo di cambiamento sia sostenuto e trovi efficacia è necessario supportarlo, anche in termini di informazione e comunicazione, in modo che: • chi opererà a sistema sia addestrato adeguatamente in modo da cono-

scerne gli strumenti ed i processi coperti; • i nuovi processi di lavoro introdotti dal sistema siano ben compresi in

termini di procedure, ruoli, comportamenti organizzativi e responsabilità; • le persone si sentano coinvolte nel nuovo processo, sono motivate dalla

nuova cultura e la supportano, trovano comportamenti coerenti nel management, si sentono parte integrante dei nuovi processi integrati a-ziendali.

153

L’ultimo punto su cui converrà soffermarci, in termini di comunicazione,

riguarda l’addestramento delle persone che utilizzeranno il sistema. Se in termini di contenuto abbiamo già visto nei paragrafi precedenti, qui ci limite-remo ad osservare che esiste la necessità di supportare il processo formativo tanto in termini di informazioni dirette dal progetto verso l’utenza quanto in termini di raccolta di feedback dall’utenza verso lo stesso progetto. In primo luogo, avendo stabilito chi parteciperà ai corsi di addestramento, sarà oppor-tuno che costoro siano avvisati, che diano la loro disponibilità o comunichino la loro impossibilità a partecipare in modo che vengano rischedulati per ses-sioni formative successive. Qui strumenti di scheduling (come abbiamo già detto), di posta elettronica e di informazione capillare (p.e. web based) risul-tano molto efficaci e consentono la necessaria efficienza e tempestività in-formativa. Durante l’erogazione dei corsi di addestramento si porrà particola-re enfasi sulla comunicazione soprattutto relativamente a quegli aspetti inno-vativi introdotti nella organizzazione del cliente. Siano essi di carattere si-stemico che riferiti a processi o riassetti organizzativi sarà opportuno l’intervento del management a supporto del formatore in quei passaggi che richiedono “la presenza dell’azienda” ad avvallare le scelte effettuate. Questo servirà a garantire le persone circa gli indirizzi generali dell’azienda e a farli sentire protagonisti dei nuovi processi integrati aziendali. Al fine di monito-rare lo stato di apprendimento dei discenti ed il grado di soddisfazione degli stessi relativamente ai corsi frequentati, la raccolta dei feedback è uno stru-mento molto efficace che, oltre a fornire la misura di gradimento ed appren-dimento addestrativo, deriva gli elementi utili a definire ulteriori necessità formative non previste in sede di pianificazione.

154

8. Avvio – Dopo tante fatiche … era ora! Bene, siamo giunti quasi in fondo! Dopo tante fatiche il progetto si predispo-ne per avviare il sistema in produzione. Tutto è stato realizzato secondo i piani e le specifiche, gli utenti sono stati addestrati opportunamente, il management ha profuso impegno e motivazione sia in comunicazione che in obiettivi. È giunto il momento di “girare la chiave” e partire … ed allora VIA! Si ma è tutto chiaro? Come partire? Che cosa occorre fare ancora? Chi deve essere coinvolto? Quali altri obiettivi occorre raggiungere? Andiamo con ordine.

L’avviamento di un nuovo sistema implica una serie di azioni propedeutiche all’avviamento stesso (prima), delle attività durante il periodo di avviamento (durante) e la gestione dell’entrata a regime del sistema (dopo). In tale conte-sto è necessario un presidio continuo che garantisca lo svolgersi coerente e controllato dell’avvio stesso; in altre parole occorre definire un piano di av-viamento del nuovo sistema informativo evidenziando le relazioni esistenti tra le attività propedeutiche all’avvio e le normali attività operative tanto le-gate al nuovo sistema quanto inerenti la chiusura dell’esercizio sui vecchi si-stemi.

PrimaDurante

Dopo

Figura 43 - Le fasi dell'avviamento

155

Inoltre si dovrà definire e comunicare il previsto modello di supporto, le strutture operative e di progetto preposte ai diversi livelli per presidiare la fa-se dell’avviamento, controllarne lo svolgimento, attivare eventuali azioni correttive, garantire un adeguato supporto agli utenti finali. In altre parole occorrerà: • definire un approccio all’avviamento del nuovo sistema informativo a-

ziendale integrato basato sull’ERP; • l’avviamento di un nuovo sistema non deve far dimenticare che ci sono

cose da fare anche sui vecchi sistemi e che entrambe le attività vanno armonizzate tra di loro all’interno di un unico piano;

• occorre organizzarsi al meglio per evitare che tutti facciano tutto consi-derando che è importante sapere in ogni momento quali sono i traguardi da raggiungere e quando questi devono essere raggiunti;

• è probabile che il nuovo modo di lavorare all’inizio non aiuterà ma … si dovrà recuperare man mano che si diventerà sempre più padroni dei nuovi strumenti anche con l’aiuto dei più esperti;

• in buona sostanza: bisogna prepararsi per affrontare l’avvio del nuovo sistema.

8.1. Prima dell’avvio Pur essendo relativamente “poche” le cose da fare, questa fase dell’avviamento si caratterizza per il “patema d’animo” che colpisce tutte le persone del progetto e quelle che intorno ad esso ruotano.

156

Politiche di Conversione

PredisposizioneI.T.

FormazioneAddestramento

Prima ...Prima ...

•ID •Nome attività•1 Progetto congiunto integrato

•2 Avviamento Settore A

•3 Creazione produzione

•4 Avvio sistema di produzione

•5 Caricamento PdC

•6 Caricamento anagrafica Banche Italia

•7 Caricamento automatico effettivo Settore

•8 Attivazione siustema per dati generali

•12/12

•12/12

•12/12 •15/12

•14/12

•15/12 •15/12

•02/01 •03/01

•17/12

•18/12 •20/12

•27/11 •04/12 •11/12 •18/12 •25/12 •01/01 •08/01•dicembre •gennaio

Prima


PredisposizioneI.T.


Prima ...Prima ...









•12/12

•12/12

•12/12 •15/12

•14/12

•15/12 •15/12

•02/01 •03/01

•17/12

•18/12 •20/12










•12/12

•12/12

•12/12 •15/12

•14/12

•15/12 •15/12

•02/01 •03/01

•17/12

•18/12 •20/12


Prima

Figura 44 - Attività propedeutiche all’avviamento del sistema

E le reazioni sono dissimili non solo per il ruolo che ogni risorsa è chiamata a sostenere ma soprattutto per il carattere e lo stile del singolo interlocutore. In ogni caso, prima dell’avviamento, alcune delle cose da fare e da tenere ben presenti possono essere queste: 1. definire un piano di dettaglio delle attività; 2. definire un modello di supporto all’avviamento; 3. definire le politiche di conversione e predisporre gli strumenti sia per

quelle automatiche che per le conversioni “manuali”; 4. continuare ad addestrare gli utenti seguendo il piano stabilito; 5. assicurarsi che tutti gli utenti abbiano le postazioni di lavoro ed even-

tualmente continuare a seguire il piano di diffusione predisposto. Sembrerà banale ma qui ci si gioca gran parte del lavoro svolto durante tutto il progetto. Quello dell’avvio, infatti, è il momento in cui l’organizzazione cliente percepirà l’impatto dei nuovi strumenti e del nuovo modo di lavorare e quindi il progetto si gioca “l’immagine” e la credibilità in termini di rispo-ste alle istanze di cambiamento. Si consideri che occorre iniziare il nuovo si-stema con i dati di partenza (p.e. contratti, fatture, anagrafiche ecc. ecc.), es-

157

sere sicuri che tutti gli utenti siano stati addestrati ed abbiano gli strumenti fisici per operare, tutta l’organizzazione del cliente sappia che ci si sta av-viando con certe modalità, che sia stato definito tanto un modello di supporto organizzativo all’avviamento che di comunicazione tra i vari attori nonché siano stati concordati gli strumenti di monitoraggio e di controllo delle attivi-tà e dei risultati che via via si raggiungeranno durante il corso di tutte le fasi dell’avviamento.

Conversione Attivitàtransazionali

Accordi conClienti/Fornitori

Settore 1

Coordin amento di Società

Utenti finali

SupportoSpecialistic

o

Avviocontrollato

Settore 2

Coordinamento di So cietà

Utenti finali

Supp ortoSpecialistic

o

• Avviocontrollato

Prog etto

Supp ortoTec

Prog etto

Help DeskCentrale

Struttura di supporto

ProcERP

Fin

Cont

PrjAssSal

ConversioneConversione Attivitàtransazionali



Settore 1

Coordin amento di Società

Utenti finali

SupportoSpecialistic

o

Avviocontrollato

Settore 2

Coordinamento di So cietà

Utenti finali

Supp ortoSpecialistic

o

• Avviocontrollato

Prog etto

Supp ortoTec

Prog etto

Help DeskCentrale

Struttura di supporto

ProcERP

Fin

Cont

PrjAssSal

ProcERP

Fin

Cont

PrjAssSal

Figura 45 - Il Modello di Avviamento

Dal punto di vista del progetto il piano delle attività avrà come orizzonte temporale la milestone di conclusione del supporto post avvio (generalmente due-tre mesi oltre la data di avvio) e la struttura delle attività (WBS) operati-ve dovrà seguire molto da vicino tanto la strategia delle conversioni quanto le modalità ed i tempi di rilascio del sistema alle varie utenze. Questo è mo-tivato dal fatto che è necessario che si instauri una coerenza complessiva (quasi una osmosi) tra: • politiche di conversione (che cosa convertire e con che modalità); • risorse dedicate (chi fa che cosa per tutto l’avviamento); • strumenti disponibili (con che mezzi: automatici o di supporto); • attività del gruppo di lavoro di progetto; • attività utente esterne al progetto (non direttamente controllabili come

p.e. diffusione delle stazioni di lavoro, attività di conversioni manuali e così via);

158

• attività di comunicazione verso terze parti impattate dall’avvio del nuovo sistema (es. fornitori, clienti, autorità ecc. per concordare cosa cambia, come e quando);

• attività possibili a sistema durante la fase di avviamento (nei casi di dif-fusione programmata e non big bang delle funzioni);

• attività di monitoraggio dell’andamento e degli oggetti registrati nel si-stema;

• controllo delle criticità e attività di contenimento dei rischi/problemi; tutti elementi che concorrono a definire i piano di avviamento del sistema che il progetto appronterà nella fase propedeutica all’avvio. Fatto questo si può procedere all’avvio del piano definito provvedendo, in particolare, a di-vulgarlo nelle sedi impattate ed a caricare i dati iniziali del sistema come previsto dalla strategia di conversione definita.

8.2. Durante l’Avvio

È il caso di dire che il testimone passa agli utenti che avviano il si-stema utilizzandolo conformemen-te alle modalità stabilite dal proget-to. La struttura progettuale di sup-porto provvede a fornire gli stru-menti ed il know-how sia per l’attività degli utenti a sistema sia

per il monitoraggio delle informazioni immesse; tale attività, inoltre, consen-tirà di verificare la coerenza dei comportamenti utente col modello di avvio

159

definito non solo in termini quantitativi (quanti oggetti introdotti) ma anche qualitativi (ad esempio per tipologia di oggetto). Tutte le informazioni sono raccolte giorno per giorno e costituiranno la base per effettuare l’analisi di tendenza, soprattutto rispetto ai volumi ipotizzati, in riferimento alla capacità del progetto di raggiungere gli obiettivi prefissati:

• qualità della formazione; • completezza dei processi gestiti a sistema; • qualità del software sviluppato ad hoc; • qualità e completezza dei profili autorizzativi (generalmente nota dolente

di tutte le installazioni); • efficienza ed efficacia del gruppo di supporto; • efficacia del modello di comunicazione; • volumi di oggetti ipotizzati specie se riferiti a particolari momenti delle

attività di business (p.e. numero di documenti contabili immessi su nu-mero documenti previsti nel periodo di chiusura della contabilità).

ApplicazioneAvviamento

GestioneTransitorio

IT

SupportoUtenza

… Durante ...… Durante ...

ID Nome attività9 Caricamento Anagrafiche di Base

10 Anagrafiche materiali

11 Anagrafiche commesse

12 Anagrafiche Clienti

13 Anagrafiche Fornitori

14 Anagrafiche Dipendenti

15 Anagrafiche CdC e CdP

16 Anagrafiche VdC

17 Contratti attivi

18 Contratti di rivendita

19 Contratti di rivendita BBP (Trader)

20 Contratti canone

21 Contratti passivi

22 Contratti di rivendita

23 Contratti di rivendita BBP (Trader)

24 Contratti canone

25 Contratti approvvigionamenti diversi

26 Caricamento manuale saldi banca

27 Caricamento automatico partite aperte Fornitor

28 Caricamento automatico partite aperte Clienti

18/12 26/01

20/12 26/01

02/01 26/01

21/12 29/12

21/12 29/12

02/01 05/01

27/12 05/01

18/12 26/01

02/01 26/01

02/01 26/01

02/01 12/01

02/01 19/01

02/01 26/01

02/01 26/01

02/01 12/01

02/01 19/01

02/01 26/01

08/01 09/01

22/01 26/01

22/01 26/01

27/11 04/12 11/12 18/12 25/12 01/01 08/01 15/01 22/01 29/01 05/02dicembre gennaio febbraio

Fig. 46 – Le attività del periodo di avvio

160

Come abbiamo già avuto modo di dire il periodo di avviamento vedrà susse-guirsi molte attività (sui sistemi attuali, sull’ERP, di chiusura e di operatività corrente) volte da un lato a garantire il corretto svolgimento dei processi at-tuali dall’altra a preparare ed avviare il nuovo sistema informativo. La carat-teristica di “novità” sarà quella più generalizzata in tutti i processi ed è pro-babile che questa contribuisca ad accrescere ansia e dubbi, a veder “tradite” aspettative, ad aumentare i carichi di lavoro … in sostanza tutta l’organizzazione impattata vivrà, in corrispondenza dell’avviamento, un pe-riodo di turbolenza che solitamente viene definito “la valle della disperazio-ne”.

DESIDERATA:

Tempo

Cap

acità

ope

rativ

aU

tent

e

Fasi progettuali in vista dell’avvio

Rischio abbassamento tensione generale

Fase post progettuale e gestione a regime

AVVIO

Fig. 47 – La valle della disperazione

La fig. 31, ripresa dall’esperienza vissuta sui progetti, evidenzia l’andamento del livello di capacità operativa degli utenti che, proprio in prossimità dell’avviamento, subisce un brusco calo dovuto al clima che viene ad instaurarsi in concomitanza con l’evento. Gli effetti, riconducibili alle cause di cui si diceva in precedenza, sono contenibili supportando l’intero processo di avviamento con un’adeguata struttura organizzativa ed un appro-priato insieme di competenze, fornite sia dal gruppo di progetto che dalle funzioni aziendali del cliente, anche al fine di garantire l’applicazione dei modelli definiti in fase di realizzazione del sistema. Ora non essendovi una ricetta che possa andare bene comunque ed in ogni situazione (anche perché ogni progetto è unico ed irripetibile per definizione!), possiamo solo osserva-re che l’approccio da seguire è funzione della complessità della singola si-tuazione e che il problema di fondo deve essere ricondotto da un lato a fare

161

in modo che i protagonisti siano le strutture e le risorse dell’organizzazione cliente (che sono credibili e si fanno garanti verso la società) dall’altra che la struttura di progetto non venga “presa d’assalto” direttamente dagli utenti ma che sia dedicata a gestire ordini di problemi con una certa significatività (problemi che possano bloccare l’operatività e non connessi alla richiesta di informazioni). Questo vuol dire che si dovrebbe pensare ad una struttura a più livelli in cui:

• i problemi vengano tracciati completamente • che vengano altresì valutati per complessità ed importanza • vengano catalogati in funzione di una scala di priorità • gestiti da chi detiene le competenze più indicate per risolverli • le soluzioni siano riportate all’utente che li ha generati.

Distribuzionegeografica 1



Distribuzionegeografica 4UTENTI





1° Livellodi supporto

Centrale di SupportoKey User e Specialisti


Formatori e Key User

Gruppo di Progetto

RiferimentoICT Cliente

Rif. Organiz.Cliente

Rif. Formaz.Cliente

Rif. Comunic.Cliente

Rif. Funzion.Cliente

Riferimentiesterni Cliente


Figura 48 - La struttura organizzativa di Supporto all'avviamento

162

8.3. Dopo l’Avvio

ID Nome atti vità29 AFC

30 Registrazioni Co.Ge.

31 Fatture Manuali

32 Pagamenti Manuali

33 Incassi Manuali

34 Ve.Fa.

35 Pagamenti Automatici

36 Incassi Automatici

37 Movimenti di Tesoreria

38 Interfaccia VS altro

39 Rendicontazione

40 Ciclo Passivo

41 Immissione RdA

42 Immissione Offerte

43 Immissione Ordini specifici

44 Entrate Merci

45 Gestione Movimenti da BBP

46 Ciclo Attivo

47 Immissione RdO



50 Gestione Uscite Merci

51 Fatturazione

/01 23/02

08/01

08/01

08/01

08/01

02/02

05/02 09/02

29/01 02/02

12/02 16/02

19/02 23/02

23/02

12/01 02/02

19/01

19/01

19/01

29/01 02/02

12/01

12/01 26/01

26/01

26/01

12/01

26/01

26/01

01/01 08/01 15/01 22/01 29/01 05/02 12/02 19/02 26/02 05/03gennaio febbraio marzo


PredisposizioneI.T.


Dopo ...

Dopo



31 Fatture Manuali


33 Incassi Manuali

34 Ve.Fa.





39 Rendicontazione

40 Ciclo Passivo

41 Immissione RdA



44 Entrate Merci


46 Ciclo Attivo

47 Immissione RdO




51 Fatturazione

/01 23/02

08/01

08/01

08/01

08/01

02/02

05/02 09/02

29/01 02/02

12/02 16/02

19/02 23/02

23/02

12/01 02/02

19/01

19/01

19/01

29/01 02/02

12/01

12/01 26/01

26/01

26/01

12/01

26/01

26/01




31 Fatture Manuali


33 Incassi Manuali

34 Ve.Fa.





39 Rendicontazione

40 Ciclo Passivo

41 Immissione RdA



44 Entrate Merci


46 Ciclo Attivo

47 Immissione RdO




51 Fatturazione

/01 23/02

08/01

08/01

08/01

08/01

02/02

05/02 09/02

29/01 02/02

12/02 16/02

19/02 23/02

23/02

12/01 02/02

19/01

19/01

19/01

29/01 02/02

12/01

12/01 26/01

26/01

26/01

12/01

26/01

26/01



31 Fatture Manuali


33 Incassi Manuali

34 Ve.Fa.





39 Rendicontazione

40 Ciclo Passivo

41 Immissione RdA



44 Entrate Merci


46 Ciclo Attivo

47 Immissione RdO




51 Fatturazione

/01 23/02

08/01

08/01

08/01

08/01

02/02

05/02 09/02

29/01 02/02

12/02 16/02

19/02 23/02

23/02

12/01 02/02

19/01

19/01

19/01

29/01 02/02

12/01

12/01 26/01

26/01

26/01

12/01

26/01

26/01



PredisposizioneI.T.


Dopo ...

Dopo

Figura 49 – Le attività dopo l’avvio

Il sistema comincia il suo esercizio in modo controllato e supportato da

tutta la struttura organizzativa vista in precedenza. In funzione della strategia di rilascio definita dal progetto, le funzioni realizzate possono essere rilascia-te agli utenti:

tutte insieme e contemporaneamente per insiemi omogenei in tempi successivi (es. vendite, contabilità forni-

tori, contabilità clienti, acquisti e quindi gestione progetti) Al di là dei vantaggi e degli svantaggi dei due approcci, si consideri che la prima modalità ha l’effetto di rovesciare immediatamente sulla struttura tutto l’effetto dei “rumori” causati dall’avviamento e questo vuol dire che se non si dispone di competenze capillari e sufficientemente forti per sostenere

163

l’urto, è possibile che il successo della fase di avvio ne risulti fortemente compromesso. Un’altra considerazione riguarda la distribuzione geografica degli utenti, la numerosità e le relative funzioni adoperate. Probabilmente là dove ci sono pochi utenti e concentrati in pochi siti si può propendere per il primo approccio mentre, al contrario, la seconda modalità sarà preferita quando la popolazione interessata è numerosa e distribuita capillarmente sul territorio. In questo modo non solo si diluiscono nel tempo le richieste dell’utente ma si ha maggior tempo per concentrarsi sui problemi di malfun-zionamento e disponibilità del sistema (in tutte le sue componenti!).

Quando l’utente genera una richiesta comunque, la prima struttura di sup-porto è quella preposta a fornire le indicazioni più immediate: - ti ricordi come abbiamo fatto in quel tale esercizio? - hai visto il manuale a pagina … ? Riporta proprio il tuo caso! - ma il computer e la stampante sono accesi? - e così via … Le persone che compongono il team di supporto di primo livello, infatti, so-no le stesse che gli utenti hanno visto durante il corso di addestramento. So-no già in sintonia tra di loro, “parlano ormai la stella lingua”, e sono anche i colleghi “un poco più esperti” che sanno come districarsi in quel labirinto di tasti e videate. E poi, se non hanno le risposte sul momento, sanno a chi chiedere!! Certamente Si … sanno a chi rivolgersi in caso di bisogno: chia-mano la centrale di supporto dove trovano i key user più esperti e qualche specialista del fornitore che li aiutano a: 1. descrivere il problema; 2. attribuire al problema una classe di criticità; 3. concordare un primo livello di priorità; 4. ricercare una soluzione in tale ambito; 5. sollecitare l’intervento del 3° livello là dove non si riesca ad individuare

una soluzione. Con l’ausilio dei due filtri costituiti dai primi due livelli è pensabile che ver-so il terso livello giungano solo quei problemi che: • richiedano un intervento sul sistema ERP;

164

• richiedano un intervento sui processi o sui comportamenti operativi; • richiedano l’intervento di un ente esterno all’organizzazione cliente; • richiedano la diffusione di comunicazioni; che sono i temi più significativi e che meritano l’attenzione e l’impegno più importanti di tutti. Su tali temi, di volta in volta, interverranno gli specialisti di sistema, i process owner, le funzioni i.c.t., comunicazione ed organizza-zione della società cliente in funzione del tipo di intervento/soluzione richie-sta dal problema e le soluzioni identificate saranno reindirizzate verso l’utente dalla centrale di supporto passando per le strutture di primo e se-condo livello.

Un’ultima considerazione la riserverei per gli strumenti di supporto. L’esperienza dei progetti seguiti ha insegnato che sono di fondamentale im-portanza tanto gli strumenti di catalogazione e tracciatura delle richieste de-gli utenti quanto quelli di comunicazione delle soluzioni di tipo “generalizza-to” e di utilizzo del sistema. I primi consentono di quantificare i fenomeni oggettivamente; forniscono gli elementi di efficacia ed efficienza dell’intera struttura di supporto ed aiutano a mantenere la storia degli interventi in modo da definirne i trend e passare un bagaglio culturale a chi verrà dopo il proget-to (in genere l’Application Management). Gli strumenti di comunicazione delle soluzioni sono di due tipi: integrati allo strumento di rilevazione delle richieste - in modo da tracciare completamente il problema – e di tipo web-based per quelle soluzioni che richiedono di essere diffuse ad un gran nume-ro di utenti per la loro caratteristica di generalità. Infine un cenno agli stru-menti di rilevazione dell’utilizzo del sistema: sono prevalentemente strumen-ti specialistici adoperati per indagini circa la qualità e la numerosità degli oggetti presenti nel sistema. Servono essenzialmente per tracciare il trend dell’attività a sistema e di controllo di coerenza con le politiche di rilascio del sistema. Tutti gli strumenti visti hanno la caratteristica di poter essere u-sati in combinazione tra di loro per fornire “un cruscotto di controllo” a chi è preposto alla gestione ed al controllo dell’intero processo di avviamento.

8.4. E dopo che succede?

165

Scusate se è poco ma l’avventura si conclude al termine della fase di sup-porto. Il progetto chiude le sue attività e redige un bilancio di quanto capita-lizzato. I risultati vengono presentati per l’approvazione del committente e si pianifica, se necessario, l’attività di passaggio delle consegne al gruppo di lavoro che curerà la manutenzione del sistema. Il ERP è rilasciato completa-mente ai suoi utenti che lo impiegheranno come strumento quotidiano di la-voro; col tempo sarà meglio apprezzato (comincia qui la china di risalita dal-la valle della disperazione) e come al solito, quando l’appetito vien mangian-do, si sbizzarriranno a richiedere modifiche ed implementazioni per trarre i maggiori benefici che si intravedranno nel corso del suo utilizzo. Tutti gli at-tori avranno un’unica certezza: la consapevolezza di aver preso parte ad una grande avventura!

166

13. Ma chi ha già fatto un progetto ERP cosa ha imparato?

Cercando di riportare i concetti fondamentali di un summary visto qual-che tempo fa ricordo che quanti hanno potuto vivere l’esperienza di un pro-getto ERP hanno imparato una curiosa litania che recita così:

i processi sono i nuovi concetti di riferimento; l’integrazione è l’obiettivo finale; l’ERP è solo uno strumento per raggiungere l’obiettivo; l’informazione è una opportunità; il cambiamento è un aspetto critico; la leadership è un requisito; la fine è solo l’inizio.

In buona sostanza sono tutti sopravvissuti all’esperienza anche se durante l’avvio hanno cantato in coro gli inni sacri al Signore. Hanno gridato alla fi-ne della civilizzazione come la conoscevano fino a quel momento e temuto per la loro incolumità ritenendo il progetto un trapianto a cuore aperto senza anestesia. I più maligni (o forse quelli più agguerriti!) hanno ritenuto l’avvento degli ERP come un’opportunità per i consulenti di venire in azien-da e diventare una cosa sola con l’arredamento considerando l’evento né l’inizio della fine, né la fine dell’inizio ma semplicemente un altro giorno di prolungata agonia di una serie senza fine. I più dotti hanno fatto ricorso all’allegoria della guerra di Troia considerando l’avvento del nuovo sistema come “il ciuco di Troia” per i nuovi sacerdoti del dio dollaro (probabilmente

167

si riferivano ancora ai consulenti!). Ora tutte queste considerazioni, frutto del vissuto di tanti progetti, anche se non sostenute da prove effettive, probabil-mente esprimono un disagio dovuto alla pervasività dell’avvenimento. Lo abbiamo visto in molti dettagli ed è subito emerso un dato di fondo: cambia la cultura aziendale. Le persone non possono più permettersi il lusso di concepire le cose alla vecchia maniera con la logica degli “orticelli privati”; il cambiamento implica che le pentole vengano scoperchiate e che i manager rifacciano almeno il look al loro stile di leadership. I più lungimiranti però hanno colto il senso vero delle cose: chi utilizza questo sistema è conscio di non vivere in un’isola felice ma di essere un anello importante di una più va-sta catena “cliente – fornitore” che ha come obiettivo ultimo la creazione del valore per l’azienda. Da questa considerazione emerge che l’organizzazione interna ha maggiore visibilità non solo degli impatti tra i gruppi ma anche del valore che l’azienda porta ai suoi clienti. Se prima la merce usciva dai ma-gazzini anche quando non c’era, adesso non esce se prima non è stata prodot-ta! Se prima, in uno stabilimento, la gente non aveva la necessità di lavorare insieme, ora il sistema obbliga la cooperazione tra le varie unità; quando si riceve la merce in un deposito si producono automaticamente i movimenti di magazzino, le scritture contabili e le informazioni per altri settori dell’azienda. Per la prima volta l’azienda è “costretta” a documentare come lavora e realmente capisce i suoi processi: adesso documenta anche i reclami sui prodotti in garanzia e non può più lavorare senza avere delle previsioni di vendite, produzione e stoccaggi accurati e coerenti tra di loro. In buona so-stanza l’implementazione del sistema ERP ha reso le aziende più organizzate perché le relazioni tra le attività sono finalizzate alla creazione di valore. Quindi non più attività senza valore aggiunto, basta con la bassa qualità, i ri-tardi, le rilavorazioni, gli errori, la scarsa standardizzazione e lo “scarico del-le responsabilità”. L’integrazione apporta solo benefici: focalizzazione sugli aspetti importanti (il Cliente), facilità di controllo, univocità e disponibilità delle informazioni, efficienza di processo, riduzione costi, maggior valore per il mercato. E speriamo che non sia solo una pia illusione!!

168

Vocabolario ERPESE As is: Letteralmente: come è; in gergo è usato per indicare la “Situazione at-

tuale” di un’organizzazione in termini di processi e sistemi a supporto. CBT: Computer Based Training. Sono strumenti di training individuali basati

sul supporto fornito da un computer. Tipicamente l’utente dispone di un supporto elettronico (Compact disc o Floppy disc) su cui è contenuto il corso che viene avviato e gestito autonomamente dall’utente sempre con l’ausilio del proprio Personal Computer. In questo modo l’utente si gesti-sce autonomamente i tempi e le verifiche di apprendimento ritornando anche più volte sugli argomenti che dovessero sembrargli più complessi da recepire o semplicemente per delle ripetizioni. L’apprendimento, in sostanza, si realizza interagendo autonomamente con uno strumento in-dividuale come appunto il PC.

Custom: Oggetti estensivi delle funzionalità standard del sistema ERP usato anche come sinonimo di Estensione. Nell’accezione informatica, più in generale, i sistemi custom sono prevalentemente sistemi cuciti sull’organizzazione dell’utente e quindi molto vicini al “loro modo di pensare e di operare”. Tipicamente tali sistemi componevano la stra-grande maggioranza dei portafogli informatici delle aziende prima dell’avvento dei sistemi ERP.

Customizing: In genere gli specialisti lo preferiscono all’italiano Parametriz-zare. Indica le attività relative alla definizione dei parametri di sistema necessari a renderlo consono alle aspettative di business. È l’attività fon-damentale e necessaria perché un ERP sia in grado di funzionare corret-tamente in relazione all’organizzazione in cui deve essere calato. È an-che sinonimo di Personalizzazione.

Entità: È da considerarsi qualsiasi oggetto, concreto o astratto, rappresentati-

vo di un certo insieme omogeneo di informazioni. A titolo di esempio

169

posiamo considerare entità: il Fornitore, il Cliente, il Piano dei Conti, L’Ordine di Acquisto o di Vendita e così via. Ogni entità è composta da un’insieme di elementi – detti attributi – che caratterizzano l’entità: così gli attributi del Fornitore possono essere la ragione sociale, l’indirizzo, la Partita Iva ecc. L’insieme degli attributi che consentono di identificare univocamente un elemento dell’insieme è definito Elemento Chiave (p.e. la Ragione Sociale + la Partita Iva per identificare un certo fornitore).

Gap: Distanza, differenza. Indica la carenza funzionale del sistema conside-rando la sua copertura dei processi To be. Generalmente in presenza di tali differenze si possono assumere atteggiamenti diversi anche in fun-zione del tipo di Gap: • È possibile “estendere” le funzioni ERP con funzioni che si affianchi-

no a quelle già cablate al suo interno e che quindi non toccano le fun-zioni standard

• È possibile “modificare” le funzioni standard per adeguarle alle esi-genze specifiche dell’installazione (altamente sconsigliato se si vo-gliono adottare le release successive del prodotto in modo “indolore”)

• È possibile adottare soluzioni organizzative diverse per superare il pro-blema e generalmente, tali soluzioni, trovano applicazione “fuori” dal sistema (attività manuali o automatizzate con altri strumenti diversi dall’ERP).

Implementare: Sinonimo di Sviluppare e Realizzare. In genere viene usato per intendere una modalità realizzativa fatta per passi successivi come tipicamente descrivono le metodologie informatiche.

Istanza: Indica generalmente una macchina fisica che contiene un sistema. Master Plan: Progetto indirizzato ad identificare un piano di attuazione com-

plessivo delle iniziative volte ad introdurre ERP in azienda. Progetto: È il raggiungimento di un obiettivo realizzato attraverso la pianifi-

cazione ed il controllo di una serie di attività, nel rispetto di vincoli tem-porali, organizzativi e di risorse assegnate.

R.d.A.: Acronimo di Richiesta di Acquisto. Definisce un bisogno aziendale per una determinata fornitura, che successivamente si trasformerà in un ordine d’acquisto.

Responsabili di Processo: Sono quelle figure aziendali, generalmente di li-vello medio-alto che possiedono tutte le conoscenze di un determinato processo e sono il riferimento principale del progetto tanto nella defini-zione dei requisiti quanto nel disegno del sistema e nella soluzione dei

170

Gap. In altre parole il ruolo di queste persone è quello di assicurare all’azienda che il costruendo sistema assolverà i bisogni di business ga-rantendo l’operatività delle risorse coinvolte in un determinato processo.

Sponsorship: Termine inglese con cui si indica l’attività di sostegno al pro-getto da parte di una figura carismatica all’interno di una organizzazione (generalmente i massimi livelli aziendali); a tale figura è richiesto di as-solvere al ruolo di Sponsor dell’iniziativa in modo da esercitare la sua in-fluenza in azienda per eludere gli ostacoli che si frappongono tra il pro-getto ed il raggiungimento dei suoi obiettivi.

To be: Contrapposto all’As is indica la “Situazione a Tendere” cioè quella futura ottenuta in seguito dell’adozione del ERP. La situazione To be viene generalmente descritta sia in termini di processi che di sistemi in-formatici a supporto.

Transazione: Esemplificando possiamo definirla come l’insieme delle attivi-tà che il sistema deve mettere in atto (ovvero svolge al suo interno) per eseguire una richiesta utente - dall’invio della richiesta da parte utente al prospetto dei risultati.

Utenti Chiave: Sono figure aziendali preposte a vivere “giorno per giorno” la costruzione del sistema insieme ai consulenti del Fornitore. Generalmen-te hanno una buona conoscenza del processo e costituiscono il primo punto di riferimento dell’azienda nel progetto a cui assicurano la rispon-denza funzionale del sistema.

WBT: Web Based Training. È uno strumento analogo al CBT in termini di interazione tra l'utente e lo strumento di apprendimento. La particolarità di questa tipologia di strumento è legata alla tecnologia realizzativa che si basa su supporto Web e non su Compact disc o Floppy disc. Questo vuol dire che lo strumento risiede in generale sulla rete WWW (Word Wide Web), o in alternativa su quella aziendale e che può essere fruita dall’utente direttamente sulla sua stazione di lavoro.

171

L’ERP questo sconosciuto!


Sistema Esterno

Sistema Esterno

Proc

ERPFin

Cont

PrjAss

Sal


Sistema Esterno

Sistema Esterno

Proc

ERPFin

Cont

PrjAss

SalProc

ERPFin

Cont

PrjAss

Sal

Sono tutti sopravvissuti all’esperienza … considerando l’evento né l’inizio della fine, né la fine dell’inizio ma semplicemente un altro giorno di prolungata agonia di una serie senza fine.

Un fatto è certo: cambia la cultura aziendale.

172

Questa monografia costituisce un diario di esperienze vissute sui progetti ERP; un utile contributo per delineare qualche elemento di riferimento per chi opera o si accinge a realizzare nuovi sistemi informativi basati su questa tipologia di prodotti.

Diventare un’azienda di successo significa dover trasferire più valore ai prodotti ed ai servizi offerti al mercato in modo da divenirne leader o co-munque occupandone una posizione di controllo. Da tali obiettivi deriva la necessità per l’azienda, di esprimere una nuova cultura d’impresa, in cui l’integrazione delle attività e l’univocità delle informazioni siano considerati fattori determinanti il successo, ed ogni funzione aziendale si senta parte in-tegrante del processo produttivo. In questo nuovo scenario il sistema ERP si rivela un fattore abilitante il cambiamento culturale; si rende “garante” dell’integrazione dei processi e dell’univocità delle informazioni gestite e ri-chiede che tutte le funzioni aziendali coinvolte abbiano una visione integrata e coerente tanto dei requisiti di costruzione del sistema quanto delle “regole” di funzionamento e dei risultati ottenibili lungo tutta la catena dei processi.

Il lavoro è stato articolato pensando di dover rispondere ai classici dubbi che possono nascere nell’affrontare un progetto realizzativo; è indirizzato non solo agli specialisti ma anche a tutti gli attori del processo di sviluppo del nuovo sistema. Il lettore viene “condotto per passi successivi” attraverso:

• un quadro di riferimento generale relativamente alle motivazioni che sottintendono il cambiamento;

• approfondimento del significato e del valore dell’integrazione;

• specificità del sistema ERP in termini di punti di forza e di debolezza e sua collocazione tra i sistemi aziendali;

• l’approccio progettuale per definire chi fa, che cosa, come, quando e perché durante tutto il corso del processo di sviluppo del sistema.

L’opera, infine, è corredata di un vocabolario “erpese”, nuovo dialetto del gergo informatico, che aiuterà il neofita a districarsi nella giungla dei nuovi termini adottati dagli specialisti IT.

173

PERCHÉ UN SISTEMA ERP? un ERP.pdf · un ERP tanto da un punto di vista dei sistemi quanto da...

Documents

Transcript of PERCHÉ UN SISTEMA ERP? un ERP.pdf · un ERP tanto da un punto di vista dei sistemi quanto da...