SISTEMIINFORMATIVI

5/2007

CONTROLLODI GESTIONE

31

I l sistema informativo non è un prodottoma un processo: partendo da questaimportante – ma tutt’altro che scontata –premessa, il presente intervento è volto

ad illustrare, soprattutto a servizio delle PMI, ilpercorso analitico ed organizzativo necessarioai fini di una corretta ed efficiente scelta edimplementazione in azienda di un EnterpriseResources Planning.

Introduzione

Come noto, la PMI rappresenta una realtàcaratteristica del tessuto connettivo imprenditorialenazionale; da ultimo, il fenomeno dei cosiddetti«distretti industriali» ha esaltato questo tipo diapproccio al mercato in alcune aree geografiche,soprattutto del Nord Est.Ma cosa significa, nello specifico, da un punto divista organizzativo, del sistema informativo e delcontrollo di gestione questo approccio al «fareimpresa»?2

In tali contesti aziendali, la relazione tra PMI el’impiego di tecnologia si presenta decisamentecomplessa: i sistemi informativi sono spesso cresciutiin modo disarticolato e poco organico, con modalitàche si potrebbero definire «a stratificazione» e/o «apatchwork», ossia con il ricorso a soluzioniapplicative che nel tempo si sono sovrapposte,stratificate o affiancate le une alle altre, quasi sorte«spontaneamente» per rispondere alle peculiarinecessità operative di una funzione, un’area, unufficio se non addirittura di un singolo utente. L’avvento di Internet in azienda, la necessitàcontabile legata all’euro e, prima ancora, la modificanecessaria per la gestione delle quattro cifre nellarappresentazione dell’anno (Y2K) hannorappresentato un pretesto importante per molteaziende, soprattutto PMI, per pianificare ilcambiamento del proprio sistema informativoaziendale.Nella realtà, input anche, e soprattutto, di naturaendogena (organizzativi, strategici ed operativi)hanno portato le aziende a dover intraprendere illungo e faticoso percorso verso un nuovo sistemainformativo di tipo integrato (Tavola 1).

Tra le motivazioni che possono condurre le aziendealla percezione della necessità direvisione/cambiamento del proprio Sistemainformativo, l’esperienza sul campo ci suggerisce dievidenziare:• la variazione delle condizioni di mercato (fusioni,delocalizzazioni, plant esteri, ecc..) e/o del modellodi business (ad esempio dal Make To Stock al MakeTo Order)3 tali da non supportare piùadeguatamente la crescita/variazione del modello digestione della vendita e, più in generale, delle risorse(materie prime, personale, magazzini, ecc.);• la provata obsolescenza tecnologica di talunisistemi informativi attuali, tale da:a) non rispondere più alle esigenze informative e,quindi, decisionali, a vario livello, presentando datinon integri, difformi e di difficile «acquisizione» od«esposizione»;b) il palesarsi di un’assenza/latenza di procedureinformatiche strutturate ed aderenti al processoorganizzativo da servire, oppure un eccesso diattività manuali e ripetute;c) il manifestarsi di difformità nellarappresentazione/esposizione degli stessi dati trafunzioni aziendali diverse (l’esempio classico è ladifformità di dati sul venduto tra produzione efunzione commerciale e, ancor più, tra funzionecommerciale ed amministrativa);• la presenza di processi aziendali non integrati nelsistema, ovvero un eccesso di comunicazioni«informali» (verbali o scritte) extra-sistema (es.uso/abuso di fogli Excel® oppure di database locali,posta elettronica, ecc.) che si basano spesso su unaraccolta dati «spontanea» (generalmente effettuatatramite apposite query dal sistema centrale) da partedell’utente, dati sui quali viene spesso attivata un post-elaborazione/aggregazione che da spazio a colori,forme e, più in generale a «dialetti di rappresentazionedel dato» non condivisi, in quanto locali;• la volontà di fondare all’interno dell’azienda una«competenza tecnologica», in quanto la si ritiene unfattore strategico per l’azienda (non bisognerebbeesternalizzare ciò che non si conosce);• la mancanza di un supporto all’analisi diprofittabilità delle produzioni/servizi aziendali,ovvero la conoscenza dei margini diguadagno/perdita di ciascuna linea di

di Bruno Stefanutti1

Consulente aziendale inorganizzazione, processie tecnologia - Consept sassocietà selezionatadall’Incubatore d’Impresadell’Università di PadovaStart Cube

SCEGLIERE E GESTIREUN PROGETTO «ERP»,ANCHE A MISURA DI PMI

1 Il presente articolo riporta inmassima parte i contenuti di unrecente intervento curato dalnostro autore nell’ambito delCorso di Economia delle reti eCommercio Elettronico (Prof.Ettore Bolisani) pressol’Università di Padova,dipartimento di IngegneriaGestionale.2 Per un’analisi più dettagliatadel contesto produttivo etecnologico delle PMI, sirimanda in proposito agliarticoli già pubblicati in Rivista,sempre a cura di BrunoStefanutti: «Business ProcessFlow management: un metododi qualità», in Controllo diGestione, n. 4/2006 e«Business Process FlowManagement: l’analisi discenario e di performance», n.5/2006.3 Si definisce «Make to Stock»(produzione per magazzino) unmodello di business chepresuppone la produzione dibeni o serviziindipendentemente dallapresenza di ordini cliente agiustificazione della produzionestessa; è un tipo di produzioneche «carica» il magazzino difinito e lo rende disponibile allavendita. Tale modellopresuppone che il lead time diproduzione del bene o delservizio sia superiore al leadtime considerato dal clientecome accettabile a partire dalmomento in cui l’ordine è statoemesso fino alla consegna delprodotto finito/servizio.Viceversa, nel modello Make toOrder (produzione sucommessa), ogni ordine diproduzione di un bene oservizio è giustificato dallapresenza di un ordine clienteall’origine; ciò implica unaattenzione marcata al leadtime, in quanto si produce inmodo sincrono a ciò che ilcliente finale percepisce comelead time «tollerabile».

5/2007

SISTEMIINFORMATIVICONTROLLO

DI GESTIONE

32

prodotto/servizio4, con conseguente difficoltà neldefinire la corretta formulazione dei prezzi divendita;• la difficoltà a rappresentare e gestire piani diproduzione precisi e controllabili per rispettare leconsegne cliente.Queste le più comuni percezioni della necessità dicambiamento del Sistema Informativo Aziendale(SIA) e della, spesso conseguente, necessità diintegrazione di strumenti di controllo di gestione nelSIA stesso, i quali non possono che fondarsi su di unSIA integro, coerente dal punto di vista dei datimemorizzati e realmente rappresentativo deiprocessi aziendali correnti.

I sistemi ERP: una risposta «storica»

Entra in gioco a questo punto del nostro dibattito, ilsistema ERP (Enterprise Resources Planning)5, chestandardizza, armonizza ed integra a livelloorganizzativo e di dati elementari i processiaziendali, offrendo gli strumenti per pianificare econtrollare i processi stessi, nell’ottica di unosvolgimento più efficiente ed efficace del business. Ilconcetto di «integrità ed univocità del dato» è afondamento di un sistema ERP ben congeniato,perché consente alle varie funzioni aziendali dianalizzare una stessa informazione senzainquinamenti derivanti da «dialetti» dirappresentazione dell’informazione che, spesso, sioriginano proprio nella su citata post-elaborazionedi informazioni memorizzate in personal computerlocali presso una o più aree funzionali. Non tutti sono consapevoli del fatto che esistonoben precisi standard de facto per le più comunidefinizioni logiche e funzionali alla base dellagestione aziendale (Material Requirement Planning,Capacity Requirement Planning, CustomerRelationship Management, Just in Time, MRPII,…),e soprattutto risposte univoche ai più comuni dubbiin materia: come deve funzionare un sistema di

Material Requirement Planning (MRP) per l’ordinedella materia prima, del semilavorato o per lagestione del conto lavoro per essere propriamenteconsiderato un MRP? Qual è la logica di gestione diuna distinta base e come deve essere correttamentestrutturata? Qual è il processo di gestione dellaspedizione del prodotto finito? Quali movimenti dimagazzino devono essere previsti? Quali documentidevono essere previsti?APICS (Association of Operations Management)6 èl’ente internazionale di cui ricorre quest’anno ilcinquantenario di fondazione e che, già dalla comparsadei primi micro-elaboratori negli Stati Uniti, si occupadella formalizzazione, standardizzazione, diffusione deiconcetti che devono supportare la correttaimplementazione dei sistemi informativi aziendali. Laconoscenza delle logiche di funzionamento dei concettibase della gestione aziendale oltre ad aiutare, senzaombra di dubbio, in una fase preliminare discrematura delle offerte software, risulta essenziale peril personale direttivo di produzione alle prese con lagestione della supply chain.Ripercorrendo in estrema sintesi, la storia dei sistemiERP, proprio aiutati in questo dall’impiantoconcettuale dell’APICS, possiamo collocare la nascitadel concetto di sistema informativo di tipo ERPintorno al 1960, con il contestuale sviluppo dei primisistemi automatici congeniati per l’approvvigionamentodei materiali (Material Requirement Planning) favoriti,come detto, dalla comparsa negli Stati Uniti del primielaboratori; l’MRP rappresenta, di fatto, un metodoper ordinare materiali e componenti secondo laseguente logica, detta anche «equazione universaledelle imprese manifatturiere»:• what are we going to make (cosa dobbiamo produrre);• what does it take to make it (cosa ciò richiede peressere prodotto);• what do we have (che cosa abbiamo «in casa» perprodurlo);• what do we have to get (cosa dobbiamo procurareall’esterno per produrlo).Qualche anno dopo si decise di proporre un metodoper inserire anche un controllo all’MRP sulle date diconsegna cliente rispetto alle date di arrivo delmateriale, nonché sulle capacità effettive diproduzione e sulle priorità, dando luogo alcosiddetto Closed-loop MRP. Con l’aggiunta delleinterfacce verso la contabilità si arriva all’MRPII(Manufacturing Resource Planning), sistema dotatonativamente, in versioni avanzate, di tools disimulazione «what if», che consentono lagenerazione di scenari al cambiamento dideterminati parametri quantitativi (prezzi, costi, ciclidi lavoro, distinte base, ecc.). Nell’ultimo decennio,con l’avvento del commercio elettronico come realtàper integrare le unità distribuite dell’azienda estesa(partner compresi), si arriva alla definizione e

4 A bene vedere, l’analisi dimarginalità rappresenta spesso

un vero e proprio «paradossoinformatico» in quanto, talvolta,

il solo sistema informativo nonrisponde in senso lato a tale

esigenza informativa, che trovaviceversa soluzione formale e

sostanziale in un’ulteriore«estensione tecnologica» del

sistema informativo aziendale,denominata decision support

system, spesso «confusa» o«venduta» (e quindi conosciuta)

come «business intelligence».5 Acronimo di EnterpriseResources Planning, esso

rappresenta la famiglia diapplicazioni software aziendalinate per mettere a disposizione

dell’utente tutti i principaliprocessi produttivi, logistici,

contabili, finanziari, di gestionedel personale, ecc. necessari al

completo funzionamento econtrollo dell’andamento

aziendale. In fase direalizzazione del progetto,

l’azienda può optare su qualidebbano essere i moduli

(ovvero i processi) da attivare,spesso a seguito di un’analisi

preventiva che indichi, adesempio, la presenza di altrisoftware in azienda che giàcoprono al meglio e con un

maggiore livello di specificitàtaluni processi; in questo caso

si assiste, spesso, ad un’attivitàdi integrazione tra software ERP

e applicazioni esistenti, al finedi garantirne la comunicazione.

Ad esempio in SAP possiamoritrovare i moduli FI (Financial

Accounting), CO (Controlling),HR (Human Resources), MM(Materials Management), PP

(Production Planning), SD (Salesand Distribution), solo per

citare i più comuni ed utilizzati.6 cfr. http://www.apics.org.

Enterprise Resources Planning(ERP): «framework for

organizing, defining andstandardizing the business

processes necessary toeffectively plan and control an

organization so theorganization can use its internal

knowledge to seek externaladvantage» (APICS Dictionary,

page 38).

Tavola 1 – L’azienda e il bisogno di sistema integrato

SISTEMIINFORMATIVI

5/2007

CONTROLLODI GESTIONE

33

commercializzazione degli ERP attuali, caratterizzatianche da un’integrazione «lato contabile» piùmarcata, dalla gestione di più business unit e daconcetti che estendono la gestione della supply chainall’esterno dell’azienda (terzisti, magazzini periferici,gestione della distribuzione) fino ad arrivare al«DRP», Distribution Requirement Planning ovveroalla programmazione non solo della distribuzionedei magazzini periferici ma anche alla domanda diprodotto/servizio da essi verso la unit centrale. Risulta, peraltro, interessante notare che esistonoprocessi aziendali «coperti per definizione» da unsistema ERP ed altri processi che non sono«necessariamente» riscontrabili in un sistema ERPstandard; la corretta percezione e conoscenza di ciò,consente già in fase di analisi dell’ipoteticasoluzione, di distinguere tra soluzione e soluzionenonché tra moduli e funzioni di uno stesso prodottosoftware; in effetti esistono moduli e funzionistandard senza i quali un ERP non si può definiretale, come d’altra parte esistono processi aziendalicoperti da software all’interno della soluzione ERPche non rientrano nella definizione specifica diprocessi ERP.La Tavola 2 aiuta a chiarire questo concetto.L’Enterprise System (ES) può essere inteso, inquesto contesto, come il complesso del softwareesistente in azienda, di cui l’ERP rappresenta solouna parte. In proposito, ad esempio, la suitecontabile «universalmente» nota (contabilità clienti,fornitori, contabilità generale, contabilità analitica,..)non rappresenta, dal punto di vista formale, unprocesso ERP. Stesso dicasi per il CRM oppure per ildata wharehouse (alla base dei decision supportsystem). Generalmente questi moduli vengonoforniti a richiesta dal software vendor, ma perdonoevidentemente il loro valore aggiunto senzal’integrazione con i moduli core che ritroviamo nellazona intersezione dei due cerchi, alla base di unsistema ERP.

Il ciclo di vita del sistema informativo aziendale

Fatta questa breve premessa «storica», utile adinquadrare l’evoluzione delle necessità aziendali edelle relative possibili risposte tecnologiche, è utileformalizzare il ciclo di vita di un sistema ERP, perdescrivere praticamente i progressivi «passaggi» cheguidano la sua introduzione in azienda, la suaimplementazione e manutenzione nel tempo. Possiamo quindi individuare i seguenti step:1) decisione di scegliere un sistema ERP;2) criteri per scegliere il corretto sistema ERP: ildocumento Request for Proposal, RFP;3) consegna delle RFP da parte dei fornitori e sceltadella soluzione: la matrice delle alternative;4) definizione dell’organigramma di progetto: ruoli eresponsabilità;5) disegno del proprio ERP;6) censimento dei propri processi:modificarli/crearli/reingegnerizzarli oppuremodificare il software (personalizzazioni)?7) riconoscimento del proprio modello di businessed implementazione dei relativi moduli e featuresspecifiche;8) realizzazione del progetto: big bang approachversus phased approach;9) gestione del training;10) manutenzione del sistema nel tempo.

La decisione per un sistema ERP

La scelta di un sistema ERP - fatta in particolare dauna PMI - può essere determinata, come accennato(si rimanda alla Tavola 1), da diversi fattori di tipo:a) esogeno: differenti condizioni di mercato,opportunità tecnologiche «indotte» dai businesspartner , adeguamenti legislativi, ecc.;b) endogeno, tra cui principalmente:- fattori tecnologici: obsolescenza del sistemainformativo attuale; obsolescenza tecnologicaintrinseca del sistema, magari basato su linguaggi diprogrammazione non più supportati;- fattori strategici: incapacità di determinare ilprezzo dei prodotti/servizi offerti, difficoltà nelgestire piani di produzione attendibili, necessità diriportare all’interno dell’azienda un know howtecnologico per garantire maggiore autonomia,necessità di affidarsi ad un partner tecnologico conuna solidità tecnica e societaria che garantisca esupporti una proiezione nel tempo dell’azienda.E’ fondamentale che l’esigenza di rinnovamento sia«sponsorizzata» dal vertice aziendale, in quanto sirivela necessario non solo pervadere l’azienda diquesta onda di cambiamento ma anche pilotare egovernare l’onda stessa, definendo da subito ruoli e

Tavola 2 – La «copertura» dei processi da partedi un sistema ERP nella sua versione standard

5/2007

SISTEMIINFORMATIVICONTROLLO

DI GESTIONE

34

responsabilità non solo per i necessariapprofondimenti interni di analisi e descrizione delleesigenze ma anche per una prima indagine sullesoluzioni più idonee offerte dal mercato. Vale la pena di specificare che le aziende cheacquistano un software ERP non sono mai in gradodi implementarlo totalmente da sole; tipicamentel’implementazione del sistema è un vero e proprioprogetto, in cui in relazione alle dimensioni ed alleesigenze dell’azienda, possono lavorare anche piùpartner. Ad esempio, presso le grandi aziende, sipossono trovare fino a quattro 4 tipi di partnerdifferenti:- fornitori di servizi professionali sulla soluzione scelta,- fornitori di servizi legati all’hardware,- fornitori di servizi tecnologici su database e sistemaoperativo,- fornitori di servizi complementari.Nei progetti ERP che interessano le PMI, viceversa,date le dimensioni dell’azienda ed il numero diinterlocutori interni ragionevolmente implicati, ilpartner di progetto è rappresentato dallo stessofornitore di soluzione, che diviene così l’unicointerlocutore verso il software vendor, certificato dalsoftware vendor stesso nel proporre e realizzareprogetti, vendere licenze ed erogare formazione. Adesempio, la nota soluzione «SAP» prevede un ampioparco di partner diffusi sul territorio nazionale, cosìcome nel caso Microsoft, solo per citare i brand piùconosciuti. Per entrambe le soluzioni, si sonooriginate nel tempo delle “specificità di settore” (lecosiddette «verticalizzazioni») a parità di «pacchettosoftware base», spesso a cura diretta di bendeterminati partner, i quali hanno magari sviluppatouna soluzione per uno specifico mercato e sonocertificati a distribuirla, talvolta anche su indicazionediretta al cliente finale da parte del software vendor.

I criteri per la selezione: il Request for Proposal (RFP)

Occorre innanzitutto tenere ben presente che ifornitori dispongono di una soluzione cosiddetta«standard», non sempre perfettamente adatta alsettore di riferimento per il cliente.Il fornitore dovrebbe quindi poter disporre,nell’interesse e tutela dello stesso cliente finale, di undocumento preliminare, che qualifichi le necessitàaziendali a livello di processo e funzionalità ritenutestrategiche, in modo che possa avviarsi un’attività difeedback a straordinario valore aggiunto nella fase diselezione.Il cosiddetto Request for Proposal (d’ora in avantiRFP) è quindi il documento che dovrebbe essereconsegnato ad ogni potenziale fornitore di soluzioneprevio incontro e colloquio preliminare: esso

dovrebbe prevedere alcuni «elementi»particolarmente significativi quali:a) le clausole di riservatezza; l’azienda si apprestainfatti a descrivere i propri processi interni e deveessere quindi formalmente garantita relativamenteall’uso che di tali informazioni verrà fatto dalpersonale tecnico e non del potenziale partner diprogetto che valuterà i contenuti del documento; ciòsia in armonia alla legislazione sulla privacy maanche, più in generale, in relazione alla normativa ditutela del segreto industriale;b) i termini temporali entro i quali il fornitore dovràprodurre l’offerta, in base alle specificheorganizzative e di processo dell’azienda descritte neldocumento; l’azienda può dedicare un «tempo» alprogetto, e tale tempo deve essere noto al potenzialepartner per definire, a partire dalla consegna dellespecifiche (la RFP, appunto) anche il pianotemporale preliminare di realizzazione del progetto,verificandone la fattibilità rispetto alle attese delcliente;c) la descrizione, quanto più dettagliata possibile,dei processi dell’azienda a livello di funzione,qualificando attività, flussi in input ed output,responsabili interni di riferimento; si suggerisce,oltre ad una descrizione esplicita del processo,eventualmente corredata di un suo flow chart percomprendere il transito dei flussi informativi, disviluppare in parallelo un approccio tabellare(Tavola 3) che, oltre a fornire una descrizionesintetica dell’attività, attribuisca un «peso»all’attività caratterizzante il processo in questione, inmodo da suggerire al fornitore di esplicitare lacosiddetta «copertura funzionale» nella propriasoluzione; ciò che, a standard, non risulterà copertodovrà rientrare in un documento detto di «gapanalisys», nel quale le differenze tra ciò che l’aziendarichiede e quello che il fornitore può offrire possonoessere non solo identificate con precisione ma anchepreliminarmente quantificate in termini di dispendioeconomico, applicativo, organizzativo e di realeopportunità; ciò è importante per stimare non solol’aderenza della soluzione rispetto ai processi internima anche per una prima quantificazione dellenecessità di adattamento della soluzione ai processidel cliente;d) i costi della soluzione in termini non solo dilicenze software (numero utenti) ma anche delprogetto nel suo complesso, considerando anchel’eventuale non copertura del software di talunespecifiche; le stesse necessiteranno infatti,ragionevolmente, di sviluppi personalizzati, più omeno complessi. In questa fase non è richiesto undettaglio eccessivo su tali aspetti (anche perché laRFP per quanto completa non potrà mai essere deltutto esaustiva), ma è certamente fondamentalecondividere i punti critici dell’organizzazione e,

SISTEMIINFORMATIVI

5/2007

CONTROLLODI GESTIONE

35

quindi, del software che dovrà mapparli, per poternequantificare gli impatti economici ed organizzativi; èfondamentale che vi sia una percezione molto nettada parte del fornitore di quelli che sono i vincolifunzionali inderogabili per l’azienda, che potrannocertamente essere discussi, riproposti o addiritturamigliorati; e) i costi per la manutenzione della soluzione, ladurata e gestione della garanzie e degliaggiornamenti, i vari livelli di supporto tecnicopossibile (Service Level Agreement); a questospecifico proposito si potranno trovare varietipologie di intervento (a chiamata, a pacchetto digiornate, ecc…) che vanno però evidenziate inquanto impattano comunque non solo sui costi delciclo di vita della soluzione ma anche sulla«disponibilità» della soluzione e soprattutto dei datiin caso di malfunzionamenti;f) la garanzia di aggiornamento della soluzione anchein caso di realizzazione di personalizzazioni; questo èun tema controverso che sarebbe bene esplicitare inmodo netto nel documento RFP. Spesso, infatti,personalizzazioni di particolari funzioni richieste dalcliente che non seguono specifici standard disviluppo definiti dal produttore di software,potrebbero non consentire il rilascio e, quindi,l’utilizzo di determinati aggiornamenti di versione,causando non pochi problemi allo stesso clientefinale; g) la clausola che specifica la proprietà del software,importante ancor più nel caso di sviluppo dipersonalizzazioni; tema anch’esso delicato, in quantola «tecnica» ampiamente diffusa dai software vendorè quella di «pacchettizzare» le esperienze dei clientinella futura versione standard, in modo da potercapitalizzare l’esperienza di progetto su futuriprospect; ciò non è illegittimo di per sé, ma potrebbe

essere necessario o interessante per l’aziendal’opportunità di tutelare determinati sviluppi ad hocproprio per mantenere un vantaggio competitivo neiconfronti della concorrenza.Nella Tavola 4 riportiamo un esempio di indice di unbuon documento RFP.Certamente la redazione di un documento RFP è unprocesso articolato quanto importante; è ancheprobabile che possa servire un aiuto esterno per unasua stesura corretta, con relativi costi di consulenzada sostenere. E’ però altrettanto certo che il valoreaggiunto di una RFP ben strutturata, soprattutto dalpunto di vista della descrizione dei processi aziendalie del loro grado di necessità/criticità, vale da solabuona parte del successo del progetto, in quanto laspecificazione delle particolarità aziendali e laseppure preliminare gap analisys mettono giàl’azienda nelle condizioni di valutare l’impatto e lacopertura delle varie soluzioni, senza correre ilrischio di accorgersene on the job; il checomporterebbe pericolose attività di adattamentodell’organizzazione al software, sconsigliabile fino ache possibile, rispetto al processo inverso diadattamento del software all’organizzazione.

La «matrice delle alternative»: la short list

Una volta ricevute le risposte dai potenziali fornitoridi soluzione alle RFP consegnate, si deve attivare unprocesso interno di scrematura delle offerte che deveportare alla cosiddetta «short list», ovvero all’elencodi pochi e qualificati fornitori più vicini alle esigenzedi processo descritte dall’azienda.Si pone però subito un problema, non banale, di«misura» delle offerte ricevute, non solo dal punto

Tavola 3 – La descrizione dei requisiti funzionali in una «Tabella RFP»

5/2007

SISTEMIINFORMATIVICONTROLLO

DI GESTIONE

36

di vista economico; infatti è evidente che la soluzionepiù economica non è necessariamente la più aderenteai processi aziendali descritti e nemmeno quellatecnologicamente più performante, ammettendo checiò possa essere un requisito «esplicito» dellapotenziale soluzione. In sostanza, si pone il problemaclassificare le soluzioni fornite, originando un vero eproprio ranking. In che modo è possibile determinare

tale classifica? Dall’esperienza sul campo, l’approccionel contempo più semplice ed a maggior valoreaggiunto è quello della «matrice delle alternative». La matrice delle alternative può essere sviluppatasemplicemente con un foglio Excel, così strutturato(Tavola 5):- le colonne rappresentano le soluzioni sotto esame(soluzione A, B,C.,,..);

Tavola 5 – La matrice delle alternative per il ranking finale

Tavola 4 – Request For Proposal: un esempio di indice

SISTEMIINFORMATIVI

5/2007

CONTROLLODI GESTIONE

37

- le righe rappresentano le «dimensioni» di analisi diqueste soluzioni, ovvero i parametri che l’aziendaritiene fondamentali per valutare le proposte. A ciascuna di dette dimensioni va assegnato un peso;ad ogni soluzione si può così dare un voto inrapporto a ciascuna dimensione7. Si arriva quindi adottenere uno schema in cui la classifica finaleconsente una quantificazione utile al processo dieliminazione/promozione di alcune soluzionirispetto ad altre, in relazione alle dimensioni divalutazione definite dall’azienda.E’ evidente l’importanza della scelta dei pesi e delledimensioni, che dovrebbero tenere conto delmaggior numero delle istanze e delle aspettativeaziendali possibili, benché evidentemente vi sarannodirettive generalmente più «pesanti» di altre(tipicamente, il prezzo della soluzione ha un pesorilevante rispetto ad altri fattori).

La definizione dell’organigramma di progetto: ruoli e responsabilità

Scelta la soluzione e formalizzati gli aspetticontrattuali, tenendo presente le eventuali clausole di

riservatezza e proprietà del software che dovrebberogià essere state «smarcate» all’interno della RFPricevuta, è opportuno definire la squadra di progettoed il calendario delle attività (Tavola 6).Il ruolo del fornitore è evidentemente importante, inquanto egli detta i tempi di realizzo della soluzione infunzione della disponibilità di personale specializzatodi vario livello: analisti funzionali, tecnici, sviluppatoridi report solo per citarne alcuni; generalmente questoteam viene coordinato da un capo progetto «latofornitore», che si interfaccia con un capo progetto«lato cliente». Il team così costituito ha il compito diarmonizzare sia tecnicamente che a livelloorganizzativo la soluzione da implementare,sostanzialmente «mappando» i processi aziendali aimoduli software caratterizzanti la soluzione. Non sicitano, per brevità, tutte le attività tecniche di «ripresadati», alimentazione anagrafica, ecc.. che vannoevidentemente organizzate e presidiate dal gruppotecnico del partner di progetto8 in affiancamento alpersonale tecnico del cliente.Il capo progetto «lato cliente» deve evidentementeavere mandato pieno dalla direzione di progettonella conduzione e gestione dello stesso. Talemandato si esplicita sovente con una riunione

7 I voti, generalmente, vannoda 1 a 5, ove 5 rappresenta ilvoto migliore per l’azienda dalpunto di vista della specificadimensione; ad esempio«costo» = 5 vuol dire bassocosto della soluzione.8 Spesso si parla di partner diprogetto piuttosto che difornitore di soluzione; infattitipicamente le soluzioni ERP piùdiffuse vengono distribuitetramite partner di zona, i qualidispongono degli stessi«contenuti» software standard,ma che hanno la possibilità disviluppare eventualmente lecosiddette «verticalizzazioni»su settori specifici, che vengono(devono essere) certificate dalfornitore di soluzione comegaranzia di affidabilità. Inquesto modo, sul territoriopossono, ad esempio, esisterepiù partner Microsoft, SAP oOracle (i veri e propri fornitoridi soluzione); va da sè chegran parte del successo delprogetto è dovuto alla correttascelta del partner. Potremmoanche spingerci a dire chel’insuccesso è spesso dovutoall’incapacità del partner nelcogliere le specificitàcaratterizzanti l’azienda o di«sottovalutare» l’analisi diprocesso, limitandosi ad unapproccio sui moduli standardche potrebbe risultare nonsufficiente (e quindi maldigerito) dall’azienda. Suquesto ultimo aspetto incideanche la preparazione tecnicadel partner stesso, fatta di«storia» e di progetti svolti.Implicitamente, anchel’esperienza del partner intermini di progetti svoltipotrebbe diventare unadimensione di analisi nelladefinizione della matrice dellealternative.

Tavola 6 – Un esempio di organigramma di progetto ERP

5/2007

SISTEMIINFORMATIVICONTROLLO

DI GESTIONE

38

aziendale di kick-off di progetto, in cui oltre apresentare obiettivi e tempi di realizzo del progetto,si tende a presentare la squadre di progetto ed iruoli. Altrettanto spesso viene istituito un comitatodi progetto, detto anche steering commettee, il qualeha il ruolo di supervisionare la cadenza del progetto,risolverne eventuali criticità e, soprattutto,relazionare l’amministratore delegato del clientesullo stato di avanzamento lavori. Non è affatto raroche i pagamenti pattuiti in sede di offerta e seguentefirma del contratto, vengano vincolati a particolariraggiungimenti di stato di avanzamento, la cuimisura è subordinata alla valutazione del «comitatotecnico» che fa parte dello steering commettee.

Il «disegno» del proprio ERP

Il «disegno» della soluzione è certamente l’aspettopiù critico nel ciclo di vita del proprio sistemainformativo, non fosse altro per il fatto che il disegnodefinitivo del sistema è - utilizzando una metaforapresa in prestito dal settore edile - equivalente ad unacolata di cemento; finché lo stesso è fresco, risultamalleabile e modificabile; quando si solidifica, lemodifiche sono sicuramente ancora possibili manecessitano di un lavoro di smantellamento moltopesante, in quanto integrato con altri moduli. E’quindi fondamentale l’analisi ed il censimento deipropri processi interni nell’implementazione delproprio ERP, sottoponendo tale attività ad unatempistica adeguata e ben monitorata dal capoprogetto interno (al limite anticipata rispetto allapartenza vera e propria del progetto); è altrettantoovvio che tale attività non può essere demandatacompletamente al partner esterno; è l’azienda checonosce sé stessa ed è l’azienda che, al limite conl’aiuto di una guida indipendente, deve mettersi nellecondizioni di specificare nel modo più precisopossibile le proprie peculiarità.Ciò detto, il primo output per una correttaimplementazione è il censimento dei propri processiinterni e la verifica, da parte del fornitore disoluzione, della «percentuale di sovrapposizione»degli stessi rispetto ai processi così comeimplementati dal software standard; se i processinon aderiscono con un grado di sovrapposizioneritenuto accettabile, le strade sono due:- si modifica il processo interno;- si modifica il software. La modifica di processo interno non è di per sé unapproccio negativo, in quanto generalmente (eprovocatoriamente) potrebbe essere un «portato» avalore aggiunto di un progetto di implementazioneERP in azienda proprio quello di poter rivederecriticamente i propri processi per renderli piùefficienti ed efficaci; in questo senso è anche

possibile che il processo implementato nel softwarescelto possa anche essere migliore, in quanto «percostruzione» è il risultato di esperienza raccoltepresso una moltitudine di altri clienti (le cosiddettebest practices); in sostanza vi è un buon indice diprobabilità di poter trovare un miglioramentoindotto nel processo dell’azienda con il sempliceutilizzo del software. Si pensi, a titolo di esempio, adun’integrazione nativa di strumenti inradiofrequenza nel processo di emissione D.D.T. espedizione dei prodotti finiti.E’ pur vero, d’altra parte, che il processo internopotrebbe essere così caratteristico e caratterizzante danon poter essere modificato; in questo caso non restache la strada di fare aderire il software al processoaziendale, implementando le cosiddette«personalizzazioni». Chiaramente le personalizzazionihanno un costo e vanno ponderate, in quanto si vacomunque in deroga ad una costruzione standard. Ilcosto delle personalizzazioni potrebbe non esseretanto di breve periodo o di realizzazione, masoprattutto di lungo periodo; infatti, lepersonalizzazioni devono essere sviluppate in armoniacon i dettami di sviluppo del fornitore del software(Oracle®, SAP®, Microsoft®, ecc.) al fine di garantirnel’aggiornamento nel tempo con le versioni successive.Se questo non avvenisse si potrebbe correre il rischiodi dover riscrivere le personalizzazioni a seguito dicambi di versione del software, ciclicamente rilasciati.E anche per questo motivo, che, come visto, la RFPdovrebbe prevedere uno specifico paragrafo aproposito di questa eventualità.La Tavola 7 illustra graficamente cosa si intenda persovrapposizione tra processo aziendale e modulo delsoftware che lo implementa nella soluzione adottata.L’esempio riporta la gestione di un ordine cliente, dallaproposta economica alla sua configurazione diprodotto finale ed infine consegna e fatturazione.Evidentemente, ogni attività caratteristica del processodeve trovare una sua collocazione nel modulo softwarein questione; è proprio in questa mappatura chepotrebbero comparire delle attività nuove non previstedal processo originario, che magari hanno un impattoorganizzativo da considerare; oppure, viceversa, taluneattività potrebbero essere assorbite e quindi eliminatein attività differenti; ad esempio il nuovo sistemasoftware potrebbe prevedere il check del credito clientecontestualmente all’introduzione dell’ordine, evitandodi fatto un’operazione a valle. Oppure la fatturazionepotrebbe essere contestuale alla spedizione.

La realizzazione del progetto: big bangapproach vs phased approach

Una volta che l’analisi è stata terminata e si hannochiari i moduli da attivare e le eventuali modifiche

SISTEMIINFORMATIVI

5/2007

CONTROLLODI GESTIONE

39

rispetto allo standard per soddisfare particolariesigenze di processo, l’azienda deve pianificare neltempo il rilascio della soluzione, attività checomprende la ripresa dei dati dal sistema legacyverso il nuovo sistema, nonché l’alimentazione ditutte le anagrafiche necessarie al funzionamentodel nuovo impianto (clienti, fornitori, materiali,distinte base, cicli di lavoro, tabelle ausiliarie per ilsupporto a logiche specifiche nella gestione ditaluni processi, nuovi campi, ecc..). Ma comepartire con il nuovo sistema? Esistonofondamentalmente due possibilità realistiche, conimpatti non solo economici ma anche temporali edorganizzativi molto differenti:• Big Bang approach: è l’approccio cosiddetto a «girodi chiave»; in sostanza si decide che a partire da unacerta data, tutta l’azienda lavorerà sul nuovo sistemacontemporaneamente. Evidentemente è unasoluzione «forte», che taglia nettamente il legamecon il passato ed ha il merito di «responsabilizzare»l’utenza nei confronti delle attività da svolgere edelle nuove modalità di gestione; non sempre però èpossibile un simile approccio, in quanto è intuitivoche lo stesso deve prevedere, oltre che un sistematecnicamente «pronto all’uso», anche (e soprattutto)una specifica preparazione tecnica degli utenti nellagestione dei processi sul nuovo sistema. Ciò deveessere fatto non solo per tutta l’azienda, ma deveanche prevedere spazi temporali adeguati per i testdel caso su dati magari reali ma che possono essereanche «violabili», in quanto sarà sempre possibilericostruire un sistema di test integro a partire da unaprecedente copia dello stesso. Ad ogni buon conto,occorre che l’azienda sia in grado di sostenere il big

bang come complessità e numerosità di processi daavviare e gestire, nonché come adeguatezza dellivello di formazione degli utenti. Un altro aspettoriguardante l’approccio big bang risiede nel fattoche l’assistenza post-avviamento va garantita su tuttii processi avviati, ovvero su tutti i moduliimplementati, il che implica una pianificazione eschedulazione delle risorse del partner da nonsottovalutare. Nelle realtà piccole, in cui sonosostanzialmente pochi i processi da avviare,l’approccio big bang può risultare, almeno in linea diprincipio, il più conveniente. Ancora di più sel’azienda ha già «sperimentato» in passato l’adozionedi un sistema ERP;• Phased approach; è un approccio più sofisticato,che richiede competenze tecniche maggiori alpartner, ma certamente più «sicuro»; è un approcciodi progetto giustificabile in realtà più complesse edarticolate9, in cui non è soprattutto pensabile lagestione della formazione degli utenti in modocumulativo ed in tempi utili con il grado disicurezza e dominio dell’applicazione richiestodall’attività aziendale ad ogni funzione. In un taleapproccio i processi dell’azienda vengono assiematiin gruppi denominati «fasi»; ogni fase è quindi ungruppo di processi che, ragionevolmente, interessasolo una parte di utenti. L’idea è quindi di far partirei moduli del nuovo sistema solo una fase alla volta,garantendo la comunicazione e l’integrità deiprocessi aziendali tramite interfacce tecnologiche discambio dati (uni o bi-direzionali), che consentonoagli utenti non interessati alla fase in questione dilavorare sul vecchio sistema (Tavola 8).In sostanza, il processo aziendale viene preservato a

9 «Complesse» ed «articolate»non corrispondenecessariamente a «moltepostazioni di lavoro in rete»; sisono gestiti progetti ERP inmodalità phased anche suaziende con 50 postazioni dilavoro in Rete.

Tavola 7 – Un esempio di sovrapposizione processo/modulo: il ciclo ordini gestito con SAP

5/2007

SISTEMIINFORMATIVICONTROLLO

DI GESTIONE

40

cavallo di due sistemi informativi, il «nuovo» ed il«vecchio». Ovvio che le interfacce sono, oltre checomplesse da realizzare e costose, anche «aperdere», nel senso che a mano a mano esaurirannoil loro ruolo operativo di collegamento e verrannoletteralmente gettate.Il vantaggio dell’approccio phased risiedesicuramente in una maggiore serenità di approccio alprogetto, con un numero sempre circoscritto diutenti da formare, nonché un numero circoscritto diprocessi da attivare e governare al rilascio. L’aspettonegativo dell’approccio, oltre al costo ed alla nonriutilizzabilità delle interfacce, è sicuramente unallungamento dei tempi di progetto ed una maggiorenecessità di tenuta «psicologica» richiesta ai projectmanager ed agli utenti finali.

La gestione del training utente

La gestione del training è una delle principali attivitàche interessano un progetto di cambiamento delsistema informativo aziendale; è un momentodelicato da gestire, in quanto spesso provoca deltimore negli utenti, che si apprestano adabbandonare abitudini radicate e procedureconsolidate per avvicinarsi ad un sistema softwarecomunque diverso, articolato per processi e non perfunzioni10 e nel quale la responsabilità del datodiviene fondante non solo per l’attività corrente maanche per le attività successive nella catena delvalore. D’altra parte, è solo dalla conoscenza via via

più profonda del sistema e delle modalità con cui iprocessi aziendali vengono gestiti al suo interno chesi realizza il vero valore aggiunto del progetto dicambiamento: la crescita e responsabilizzazione delpersonale umano e la sua sensibilità adun’articolazione aziendale per processi, in cui sidiviene realmente consapevoli che ogni attività èstrettamente correlata, a monte ed a valle, conattività afferenti ad altri processi, in un sistemaintegrato. A seconda dell’approccio di progetto, comeabbiamo visto, il training potrebbe essere gestito conun coinvolgimento aziendale ad intensità diversa,che può prevedere il coinvolgimento progressivodelle funzioni (approccio phased) oppure di tutte lefunzioni in un arco di tempo più limitato (approcciobing bang). Esiste¸ tuttavia, un approccio differentealla formazione genericamente considerata comemomento specifico confinato nel tempo in qualchegiornata; l’approccio è quello della formazionecontinua e graduale, che si fonda su unavvicinamento progressivo degli utenti al nuovosistema, che culminerà comunque con la sessioneufficiale di formazione ma non si esaurisce con essa;è un approccio che prevede la presenza dellacosiddetta test room, ovvero dell’ufficio adibito allesessioni di prova, presso il quale gli utenti possono,con la guida dei tecnici di progetto, sperimentareprogressivamente talune applicazioni o funzionalitàcaratterizzanti il nuovo sistema (possibilmente sudati rappresentativi dell’azienda) prima ancora cheavvenga la vera e propria formazione. Spesso, infatti,

10 Soprattutto qualora perl’azienda si tratti della prima

esperienza ERP.

Tavola 8 – L’implementazione di un progetto di tipo phased

SISTEMIINFORMATIVI

5/2007

CONTROLLODI GESTIONE

41

nella test room si presentano i cosiddetti «progettipilota» o «prototipi», ovvero porzioni di processiaziendali così come analizzati e specificati nella RFPovvero come risultato di approfondimenti successivi,eventualmente migliorati in modo congiunto daazienda e partner di progetto. Grazie a taliapprofondimenti; si ha così ad esempio la possibilitàdi testare la particolare soluzione o processoverificando sul campo il reale impatto operativo efornendo ai tecnici di progetto importanti feedbacksull’efficacia della realizzazione in corso osull’opportunità di apportare dei miglioramenti. E’una tecnica che consente anche di stimolare erendere gli utenti partecipi al progetto in modoprogressivo, valorizzandone l’esperienza el’operatività.E’ una tecnica che può apparire scontata e banale,ma dall’altissimo valore aggiunto; esistono, infatti,concetti fondanti dei sistemi ERP (si pensi adesempio all’approvvigionamento materiali,semilavorati, conto lavoro, ecc., ottenuto grazieall’MRP) che meritano sicuramente sessioniesplicative che interessano tutte le funzioniaziendali e che, quindi, è opportuno divulgare congradualità e concretezza grazie ad un ambiente ditest. Si ricorda, inoltre, che è molto frequente chenelle sessioni di test emerga una consapevolezzaoggettiva del cambiamento organizzativo indottodall’adozione di un sistema ERP. In effetti, lefunzionalità tipiche di questi sistemi11 originanospesso la necessità di stabilire nuovi ruoli eresponsabilità che devono essere quanto primacondivise e, se il caso, criticate per attuare esostenere le necessarie contromisureorganizzative.

La manutenzione del sistema nel tempo

C’è chi afferma che il vero progetto ERP «inizia allafine del progetto stesso»; è sicuramente un’enfasi,che racchiude però una verità: il sistema informativoaziendale non è un «prodotto» ma, in qualchemodo, è anch’esso un «processo» che come tutti iprocessi evolve nel tempo. Possono cambiare leesigenze dell’azienda ed occorre quindi disporre ditutti gli strumenti tecnici e di supporto tali dagarantire la proiezione nel tempo del sistema.Occorre, peraltro, distinguere tra assistenza post-avviamento e manutenzione/supporto evolutivo;l’assistenza post-avviamento è legata alla necessitàimmediata di supporto ed assistenza che èfacilmente immaginabile all’avvio del sistema (avviointegrale o parziale); è opportuno stabilire in modoesplicito, magari a livello di RFP, delle giornate diassistenza in grado di rassicurare e supportare gliutenti durante le prime settimane di utilizzo del

nuovo sistema, per poter altresì contare su unintervento specializzato in tempo reale in caso dianomalie di vario tipo. Forse è in questa necessità disupporto che si ravvede maggiormente il valoreaggiunto dell’approccio per fasi, in quanto lacaratteristica di tale approccio pone una sostanzialenecessità di supporto solo per alcuni moduli dellasoluzione, confinando ad essi rischi di errore edanomalie12.Per quanto riguarda la manutenzione ed il supportoevolutivo, spesso si attivano contratti di assistenzache prevedono, oltre agli aggiornamenti software,anche dei tempi di intervento stabiliti in caso dianomalie software (o hardware); ovviamente èl’azienda che decide quanto sia il «fermo macchina»tollerabile ed in funzione di questo stabilisce illivello di intervento13. Altrettanto spesso siconcordano giornate di assistenza pianificate nelcorso del mese/anno, nelle quali il partner diprogetto mette a disposizione le figure professionalirichieste per l’analisi di determinati specificiproblemi di gestione, al fine di individuare lamigliore soluzione e/o contribuire a validareun’analisi in atto e le relative conclusioni diintervento sul sistema.

Conclusioni

In questo contributo è stata presentata unametodologia consolidata di approccio alcambiamento del sistema informativo aziendale;tale metodologia parte necessariamente dall’analisidei processi aziendali per giungere ai requisiti dellasoluzione ed arrivare a descrivere, in ultima analisi,le modalità di gestione e manutenzione del nuovosistema nel tempo. E’ il cosiddetto cycle time deisistemi ERP. La caratteristica di questametodologia è essenzialmente basata sulla necessitàdi poter disporre di un’accurata analisi dei propriprocessi interni, al fine di poter rappresentare almeglio le proprie esigenze a se stessi ed al mondodei potenziali fornitori di soluzione; abbiamo vistocome il documento RFP sia allo scopo unformidabile spunto di riflessione critica perl’azienda. In effetti si assiste spesso a situazioninelle quali, in assenza di una chiara, definita econdivisa certificazione dei propri processi e delleproprie necessità e metodologie, si demanda quasicompletamente l’analisi in questione al partner diprogetto, rischiando con elevata probabilità chel’organizzazione si debba adattare al softwarescelto per una pura e semplice (scontata, sidirebbe) mancanza di completa conoscenza e«sensibilità» ai processi interni da parte delfornitore di soluzione. Tale errore è, peraltro,molto comune anche quando si interpreta un

11 Si pensi alla funzionalitàMRP, che coinvolgedirettamente la funzioneacquisti di materia prima esemilavorati ma anche lafunzione di produzione perl’eventuale acquisto di ore dimanodopera per l’esecuzionedi fasi di lavoro esterne. Eccola necessità di avere due«mandanti» MRP, ovvero unpossibile «sdoppiamento»della funzione acquistipropriamente detta.12 I critici dell’approcciophased sostengono, ad onordel vero, che solol’integrazione e la messa «inproduzione» di tutti i modulidella soluzione sceltarappresenterà un test definitivosulla reale integritàdell’implementazione; d’altraparte, per sua natura,l’approccio phased minimizzacomunque i rischi connessi alla«futura» gestione integrale edintegrata del sistema, proprioinserendo i moduli inproduzione progressivamente,circoscrivendo in ogni caso leanomalie, gli errori e lenecessità di formazione utentesul modulo stesso. A moduliintegrati, il sistema avrà peròun grado di maturità più altorispetto ad un approccio bigbang, senza trascurare il fattoche l’utente utilizzatore delmodulo sarà sicuramente ingrado di dominare econtrollare meglio il sistema, ilche di per sé consente difiltrare ed assegnare prioritàmeno «emotive» ad eventualianomalie di gestione delprocesso che dovesseropresentarsi.13 Tipicamente entro le 4 ore,entro le 8 ore, next day, ecc.

5/2007

SISTEMIINFORMATIVICONTROLLO

DI GESTIONE

42

progetto di implementazione di un sistema ERPcome un problema tecnologico piuttosto cheorganizzativo, come di fatto dovrebbe essere. Latecnologia è, al giorno d’oggi, disponibile e ad unlivello qualitativamente elevato. Il problema non èquindi sostituire un oggetto software con un altrooggetto software ma, piuttosto, analizzare lapropria organizzazione e verificare primariamenteciò che si desidera dal nuovo software in termini diimpatti sui processi, d’integrità dei flussiinformativi, di aumento dell’efficienza, di controllodei costi e dei magazzini, di vantaggio competitivo:chi deve fare cosa e come per operare con processiinterni misurati e misurabili, che diano origine aflussi informativi ed, in ultima analisi, ad una basedati realmente predisposta all’assunzione didecisioni coerenti sulla propria gestione. Ciòrappresenta la vera necessità dell’azienda di oggi inun contesto di mercato come quello che viviamo.Gli oggetti software cambiano, ciò che resta sonosempre e comunque i processi aziendali e la loroformidabile potenza nel poter rappresentarel’azienda a sé stessa ed al mondo esterno.

Bibliografia

THOMAS H. DAVENPORT (1993), Innovazione dei processi:riprogettare il lavoro attraverso l’infornation technology,Franco Angeli (edizione Italiana a cura di Ernst&YoungConsultants)

FILIPPO C. BARBARINO (2002), Capire i processi. Comeorganizzarli, gestirli, migliorarli, Edizione UNI Milano

JHON INNES, FALCONER MITCHELL (2005), I costi di struttura,Edizione SDA Bocconi Scuola di Direzione Aziendale

MASCIA FERRARI, BRUNO STEFANUTTI (2005), Business ProcessImprovement: un’applicazione di successo nel tessile,Edizione IPSOA Controllo di Gestione, n.2/2005

BRUNO STEFANUTTI (2006), Business Process Flowmanagement: un metodo di qualità, Edizione IPSOAControllo di Gestione, n.4/2006

BRUNO STEFANUTTI (2006), Business Process FlowManagement: l’analisi di scenario e di performance, EdizioneIPSOA Controllo di Gestione, n.5/2006

DANIEL E. O’LEARY, Enterprise Resources Planning Systems:systems, life cycle, electronic commerce, and risk, CambridgePress

STEPHEN HARWOOD, ERP: the implementation cycle,Computer Weekly Professional Series

SCOTT HAMILTON, Maximizing your ERP System, MC Graw HillALAN DENNIS, BARBARA HALEY WIXOM, Systems analysis and

design, Wiley&Sons.