Lezione tenuta dall'Ing. Stefanutti presso l'Università di Padova, Dipartimento di Ingegneria...

Implementazione in azienda di sistemi informativi integrati: metodologie di scelta e di gestione dei progetti

Vicenza, 8 maggio [email protected]

Best practices di Consept

1. l’analisi e la formalizzazione dell’organizzazione aziendale esistente e del flusso delle informazioni, o di una sua porzione e, ove necessario, la formulazione di una proposta del suo miglioramento;

2. l’analisi del sistema informativo di base e della sua infrastruttura tecnologica (hardware, software) e, ove necessario, la formulazione di una proposta del suo miglioramento

3. l’individuazione del “modello dati” più idoneo a rappresentare l’azienda, o una porzione di essa, in armonia con gli obiettivi di controllo di gestione prefissati;

4. realizzazione di un sistema di controllo della gestione aziendale (configurazione del costo, analisi dei costi, dei ricavi, dei margini, ecc.) operante secondo la struttura e le funzionalità tecnologiche offerte dai “data wharehouse” e dai “Sistemi di Supporto alle Decisioni” (D.S.S.).

Agenda

� Parte 1: l’azienda ed il “bisogno” di sistema integrato

� Parte 2: generalità sui sistemi ERP

� Parte 3: realizzazione di un progetto ERP

Parte 1l’azienda ed il “bisogno” di sistema integrato

� sistemi informativi “centralizzati”, “distribuiti” ed “integrati” (ERP): spinte al cambiamento ed effetti del cambiamento

� monitor primari del bisogno di “sistema integrato”: indeterminazione del costo di prodotto/servizio e/o scarsa integrità dei dati

� i sistemi informativi e le decisioni aziendali: sistemi “transazionali” e “decision support system”

Parte 2generalità sui sistemi ERP

� ERP: terminologia e standard de facto

� l’APICS (www.apics.org) ed il suo ruolo

� architettura semplificata dei sistemi ERP

� Il concetto di “moduli” nei sistemi ERP: la relazione modulo-processo aziendale da coprire

� aderenza tra processo aziendale e modulo ERP: modulo standard e personalizzazioni

Parte 3implementazione in azienda di un sistema ERP

� perché cambiare Sistema Informativo Aziendale (SIA): motivazioni che portano alla software selection

� ciclo di vita di un sistema ERP:

1. decisione di scegliere un ERP2. criteri di scelta del proprio ERP3. definizione dell’organigramma di progetto: ruoli e responsabilità4. “disegno” del proprio ERP

i. censimento/revisione dei propri processi: occorre modificarli/reingegnerizzarli oppure “modificare” il software?

ii. riconoscimento del proprio modello di business (MTO, MTS,..) ed implementazione dei relativi moduli

5. realizzazione del progetto: bing bang approach vs. phased approach6. training (1, 2, 3, 4, 5)

sistemi informativi “centralizzati”, “distribuiti” ed “integrati”: spinte al cambiamento ed effetti del cambiamento

r

Parte 1: l’azienda ed il “bisogno” di sistema integrato

necessità di

revisione del sistema informativo

Y2K Internet (in azienda, 1995)

Euro (2001)



� possono variare le condizioni di mercato (fusioni, delocalizzazioni, ecc..) e/o il modello di business (es. da MTS a MTO), ovvero non supporta la crescita

� il sistema è realmente obsoleto:a. non risponde più alle esigenze informative, a vario livellob. presenta dati non integri, difformi e di difficile acquisizionec. si registra un’assenza o latenza di procedure oppure un eccesso di

attività manuali e ripetuted. ………….

� processi aziendali non integrati nel sistema (esempio “posta pneumatica”)

� si vuole fondare all’interno una “competenza tecnologica”, in quanto si ritiene che sia un fattore strategico per l’azienda (non bisognerebbe esternalizzareciò che non si conosce)

� la sostituzione del sistema informativo non è solo un problema tecnologico ma soprattutto organizzativo!!



INTE R N E T

H ub

H ub

F irewall

C om puter

Com puter

C om puter

Com puter

Router

P D A

C om puter

M odem

D ata

D ata

D ata

D ata



� in realtà si trovano situazioni intermedie a quelle illustrate; un certo numero di aziende sono ancora al modello “mainframeAS400”, con terminaleria dummy agganciata al sistema centrale

� sicuramente il denominatore comune è la stratificazione di soluzioni software affiancate, spesso non integrate le une con le altre, che hanno determinato la proliferazione di processi aziendali “spontanei”, non mappati e non integrati nel sistema

� analogamente per l’hardware, la microinformatica ha portato “potenza” in periferia ma, come conseguenza diretta, la creazione di “isole” in cui gli utenti costruiscono il proprio patrimonio dati, spesso ignoto all’EDP e/o all’organizzazione;

� risultato: informazioni fuori circuito informativo azien dale, decisioni non supportate da “fatti numerici” coerenti e condivisi



� l’EDP si deve/dovrebbe trasformare da funzione puramente tecnologica in funzione di analisi organizzativa, per conoscere e pilotare l’acquisto degli strumenti software ed hardware più idonei alla gestione;

• occorre far rientrare in un unico e condiviso circuito informativo tutte le informazioni non “mappate”



� le principali “indeterminazioni” gestionali che gli imprenditorivorrebbero fossero affrontate e che, spesso, motivano da sole la sostituzione del sistema informativo aziendale sono:

I. analisi profittabilità delle produzioni/servizi aziendali

II. formulazione corretta dei prezzi di vendita di beni e/o servizi

III. piani di produzione precisi e controllabili per rispettare le consegne cliente

� talvolta, tuttavia, le indeterminazioni non vengono risolte con la sola presenza di un sistema integrato, perché si attribuisce allo strumento funzioni che non gli competono….

� ovvero, potrebbe non essere necessario solo un sistema integrato (ERP)…


monitor primari del bisogno di “sistema integrato”: indeterminazione del costo di prodotto/servizio

� occorre distinguere tra necessità gestionali legate all’integrità dei dati e dei processi..

� …e necessità direzionali legate ad informazioni e reportistica di supporto alle decisioni

� sistemi informatici diversi, supportati da architetture diverse


monitor primari del bisogno di “sistema integrato”: indeterminazione del costo di prodotto/servizio

LIVELLO APPLICATIVO-GESTIONALE

LIVELLO DATI E INFRASTR.

LIVELLO DIREZIONALE DI CONTROLLO

Master

OnlinePurchases

TelephonePurchases

International Retail

INT

ER

NE

T

? ?� Fatturato per prodotto-area geografica-cliente, prodotti più redditivi, costo dei prodotti venduti, vendite dell’ultimo semestre in rapporto a 2 anni fa, “fare” o ”acquistare” ecc.

PI MIMaster

Master

applicazione gestionale

(E.R.P.oppure no)


� Il modello dati caratteristico dei sistemi informativi aziendali ERP risponde a logiche “transazionali”; definisce, cioè, le relazioni logiche tra i dati e garantisce congruenza unicità e integrità in un ottica di attività con profondità temporale minima (input di ordini cliente, input di ordini a fornitore, etc..)

� viceversa, ogni richiesta di informazioni con caratteristiche di storicità e/o aggregazione secondo dimensioni specifiche (tempo, cliente, attività, zona geografica, etc..) richiede lo sviluppo di un modello dati parallelo ad alte prestazioni, anche generato da più sorgenti dati non necessariamente tra loro correlate integrate a priori

� Il data wharehouse svolge il ruolo di collettore di informazioni allo scopo di organizzare i dati per consentirne la loro navigabilità. E’ la tecnologia a supporto dei Decision Support System


i sistemi informativi e le decisioni aziendali: sistemi “transazionali” e “decision support system”

tecnologie di accesso (WEB, client-server,etc..)

Motori di calcolo e tecnologie DSS

Tecnologie di reporting ed EIS(Executive Information System)

Altre tecnologie

Datawarehouse e datamart

Sistemi Sistemi Sistemi Sistemi transazionalitransazionalitransazionalitransazionali

Altri sistemi Legacy o di nicchia

• Sistemi ERP – Financial• Sistemi ERP – Risorse • Umane• Altri sistemi orizzontali

Sistemi MRP Produzione

• Produzione• Approvvigionamenti• Distribuzione

Sistemi CRM• Call Center• Portali Web• Automazione forza vend.• Altri

Sist

emi d

ecis

iona

li e

di

Sist

emi d

ecis

iona

li e

di

Sist

emi d

ecis

iona

li e

di

Sist

emi d

ecis

iona

li e

di re

porti

ngre

porti

ngre

porti

ngre

porti

ng



Data Warehouse

accesso ai dati

Accesso

utenteFonti dati (ERP, ecc..)

estrazione dati (ETL)

Area

collettore

Dati

Data Marts



Q4Q1 Q2 Q3

Dimensione tempo

Dimensioneprodotti

U.K.

Germania

Francia

Dim

ensionezona

prodotto “D”

prodotto “B”prodotto “A”

ItaliaPEZZI,

VALORE,..

prodotto “C”



Parte 2: generalità sui sistemi ERP

� Enterprise Resources Planning: terminologia e standard de facto

� La standardizzazione nell’ambito production: l’APICS (www.apics.org) e al sua influenza sulle logiche ERP

� pregi/difetti comunemente condivisi dei sistemi ERP

� architettura (semplificata) dei sistemi ERP

� il concetto di “moduli” nei sistemi ERP: la relazione modulo-processo

� aderenza tra processo aziendale e modulo ERP

Parte 2: scelta della soluzione ERP

ERP: terminologia e standard de facto

MRP

Closed-loop MRP

MRP II

ERP

� MRP:1960; metodo per ordinare materiali e componenti secondo la logica (equazione universale delle imprese manifatturiere):

�what are we going to make�what does it take to make it�what do we have�what do we have to get

� Closed-loop MRP con aggiunta del controllo sulle date, sulla capacità, sulle priorità

� MRP II (Manufacturing Resource Planning) aggiunge interfacce verso la contabilità e tool di simulazione “what if” (es. APS)

� Enterprise Resources Planning; integrazione contabile più marcata, gestione di più business unit, estende la supply chain, introduce le funzionalità di commercio elettronico



� ERP non è un software (!!)

� ERP rappresenta un insieme di processi aziendali!!

� non tutti tali processi sono mappati dai pacchetti software che comunemente vengono chiamati “ERP”

� alcuni processi aziendali potrebbero in effetti essere già coperti sistema software “più generale” d’impresa, ovvero

l’”ES”= Enterprise Software”



� per meglio chiarire la differenza tra “ES” e “ERP”, utilizziamo la definizione di T.H. Davenport:

“ ES is a set of packages of computer applications thatsupport many, even most, aspects of a company’s information needs”

� in effetti per l’azienda l’acquisto del sistema ERP potrebbe essere successivo ad ulteriori software già presenti, per cui magari si potrebbe porre un problema di integrazione (Enterprise Application Integration); ad esempio moltissime aziende hanno la contabilità su un sistema diverso dal sistema di produzione

� addirittura potrebbero essere acquistati solo alcuni “moduli” o “funzionalità” di un sistema ERP…



� un set di strumenti di gestione che bilanciano domanda ed offerta, consentendo il controllo gestionale ed economico dell’impresa

� strumento che permette di collegare la domanda dei clienti con l’offerta dei fornitori, creando i relativi piani di acquisto e attuando una gestione a costi decrescenti dl magazzino minimizzando le scorte

� fornisce integrazione di risorse di flussi informativi tra i processi che attraversano le varie funzioni aziendali (unicità ed integrità del dato)

� sistema che racchiude pre-integrate le fondamenta per il commercio elettronico



ERP: definizioni possibili

� esiste uno standard de facto nella definizione dei sistemi ERP e delle loro logiche di funzionamento

� tale standard de facto è formalizzato dall’APICS (www.apics.org) che eroga (oltre a newsletter, riviste, mailing list) servizi dicertificazione internazionale equiparati a master sui sistemi diproduzione e, di riflesso, sui sistemi informativi che ne implementano ed automatizzano le logiche di gestione

� L’APICS Dictionary raccoglie le definizioni chiave nell’ambito dei sistemi di produzione dal 1963 (prima edizione del dizionario); nel 2005 è uscita l’undicesima edizione

� é molto importante saperlo, perché in fase di selection, l’aderenza a tali standard può valorizzare una soluzione rispetto ad un’altra


l’APICS (www.apics.org) ed il suo ruolo

� “Enterprise Resources Planning (ERP): framework fororganizing, defining and standardizing the business processes necessary to effectively plan and control anorganization so the organization can use its internalknowledge to seek external advantage” (APICS Dictionary, page 38)



l’APICS (www.apics.org) ed il suo ruolo

� gli ERP si sono diffusi principalmente perché:

� raccolgono “a standard” le esperienze (i processi aziendali) di più clienti e quindi è più probabile trovare aderenza con i propri

� come conseguenza, sono molto usati, arricchendo continuamente il best of breed

� definiscono “tecnologicamente” i competitor in un mercato

� consentono nativamente l’integrazione over internet e la localizzazione della soluzione, senza sviluppi software aggiuntivi

� si basano su una metodologia standard di sviluppo che consente una evoluzione controllata e controllabile nel tempo del “sistema software” nel suo complesso

� corettamente implementati, realizzano l’unicità ed integrità del dato aziendale ed il controllo dei magazzini

� portano l’azienda a ragionare per processi


pregi/difetti comunemente condivisi dei sistemiERP

� gli ERP sono criticati principalmente perché:

� richiedono una alto sforzo implementativo� richiedono la capacità di modificare e governare i propri

processi aziendali � I tempi di progetto possono essere lunghi (12-18-24

mesi) � Impongono in azienda la nascita di ruoli specifici a

seguito dell’implementazione di processi specifici, qualora non esistenti in precedenza (es. pianificazione acquisti, pianificazione di produzione, controller,…)

� ecco perché è più difficile l’affermazione degli ERP nelle piccole aziende, anche se cominciano ad affermarsi soluzioni ERP “light” per questo specifico segmento (SAP)

� non è semplice e a basso costo la realizzazione di personalizzazioni, essendo il sistema fortemente integrato



� “Too many companies have bought an extremelyexpensive set of “golf clubs” (an enterprisesoftware system) but haven’t learned how to play golf. That’s why we read about so many “ERP failures” in the business press. (…). Saying thatERP failed in these cases is like saying that golf failed because I’ve bought a $2000 set of golf clubsand didn’t break 120. Golf failed? Makes non sense”



“ERP: making it happen” T.F. WallaceM.H. Kremzar, Wiley&Sons

• Sales forecasting• Sales and operations planning• Advanced planning system• Supplier rating system• Performance metrics

ERP PROCESSES NOT PARTSTANDARD ES

Fonte: “ERP: Making it happen”

T. Wallace, M. Kremzar

• Master production scheduling• Rough-cut Capacity planning• MRP• Capacity requirements planning• Distribution requirementsplanning• Customer order entry

ERP PROCESSES IN STANDARD ES

• Ar, Ap, Gl• Cash management• Crm• HR• Data wharehouse

NON ERP PROCESSES FOUND IN A TYPICAL ES

ERP ES


architettura semplificata dei sistemi ERP

Ordermanagement

proposal commitment Config. credit check delivery billing

SAP module

Sales and distr.

production planning

Sales and distr.

FInancial&Controlling

Prezzo, sconti, verifica credito

Verifica disponibilità e/o rilascio ordine produzione

pilota l’acquisto fasi esterne per la lavorazione

purchasing

prima di fatturare, ha già registrato costi di manodopera, materiale ed eventuali varianzegrazie all’integrazione con gli altri moduli


Il concetto di “moduli” nei sistemi ERP: la relazione modulo-processo

pilota l’MRP

Parte 3implementazione in azienda di un sistema ERP

� perché cambiare Sistema Informativo Aziendale: motivazioni che portano alla software selection

� ciclo di vita di un sistema ERP:

1. decisione di scegliere un ERP2. criteri di scelta del proprio ERP3. definizione dell’organigramma di progetto: ruoli e responsabilità4. “disegno” del proprio ERP


ii. riconoscimento del proprio modello di business (MTO, MTS,..) ed implementazione dei moduli che servono

5. realizzazione del progetto: bing bang approach vs. phased approach6. training (1,2,3,4)

� possono variare le condizioni di mercato (fusioni, delocalizzazioni, ecc..) e/o il modello di business (es. da MTS a MTO)

� il sistema è realmente obsoleto:a. non risponde più alle esigenze informative, a vario livellob. presenta dati non integri e difformi a seconda dell’area funzionalec. si registra un’assenza o latenza di procedure oppure un eccesso di

attività manuali e ripetuted. …………….

� può cambiare l’organizzazione interna (CED con competenze accresciute che può garantire autonomia)

� si vuole fondare all’interno una “competenza tecnologica”, in quanto si ritiene che sia un fattore strategico per l’azienda (non bisognerebbe esternalizzareciò che non si conosce)

� la sostituzione del sistema informativo è principal mente un problema organizzativo

Parte 3: implementazione in azienda di un sistema ERP

perché cambiare SIA: motivazioni che portano alla software selection

� Il ciclo di vita di un sistema ERP può essere così riassunto:

1. decisione di scegliere un ERP

2. scelta del proprio ERP e del partner di progetto

3. definizione dell’organigramma di progetto: ruoli e responsabilità

4. “disegno” del proprio ERP


ii. scegliere il proprio modello di business, implementare i moduli che servono

5. realizzazione del progetto: bing bang approach vs. phased approach

6. training (1, 2, 3, 4, 5)

ciclo di vita di un sistema ERP


� nella pratica, la decisione di cambiare nasce internamente primariamente da due fattori, che possono pesare in misura diversa l’uno rispetto all’altro a seconda dell’azienda:

– anomalie organizzative che hanno portato alla “fusione” tra processi e procedure software (es. scarico merce su un sistema, stampa DDT su un altro sistema) creando “autonomie decisionali” tacite e non condivise all’interno di aree funzionali

– la diretta conseguenza è la non integrità/disuniformità dei dati, che si traduce in incapacità sia nella raccolta dei dati funzionali alle decisioni sia alla lettura ed interpretazione degli stessi (molto frequente è l’assenza/incongruenza/incompletezza di informazioni sul costo di prodotto/servizio);

� ciò contribuisce alla creazione di isole di (apparente) automazione slegate tra loro, in cui nascono processi spontanei non integrati nel sistema, talvolta non noti


ciclo di vita sistema ERP: decisione di scegliere(1/6)

� come si ottengono i requisiti del sistema? Esistono metodologie rigorose per affrontare questo aspetto dell’analisi:

� interviste ai key users� riunioni (joint application development)� check list (chi fa cosa)� disegni di flusso, diagrammi (casi d’uso, entità relazioni,..)� simulatori di processo (“as is”, “will be”……)

� occorre approfittare del momento per descrivere quello che si è (“asis”) ma anche quello che si vorrebbe essere (“will be”), al limite con l’aiuto di tools che misurino le performance dei processi o che ne simulino le performance in funzione di determinati cambiamenti

� il nuovo sistema non deve essere una pura e semplice sostituzione del vecchio sistema ma un’occasione di ripensamento strategico di tutti i processi aziendali o perlomeno di quelli critici e distintivi


ciclo di vita sistema ERP: scelta ERP (2/6)

� tutta l’analisi confluisce in un documento aziendale prezioso, la Request forProposal

� occorre esaminare con attenzione i propri processi affinché tale documento sia il più preciso possibile relativamente alle proprie caratteristiche organizzative ed operative, quantomeno quelle ritenute distintive

� la RFP mette il fornitore di soluzione davanti alla specifica richiesta da parte del cliente di ricevere un’offerta (di sistema informativo, in questo caso) sulla base di specifici requisiti

� su tali requisiti, il fornitore dovrà esprimersi in termini, seppure stimati, di tempi e costi

� soprattutto dovranno emergere le caratteristiche di “personalizzazione” dei processi relativamente al sw offerto e, quindi, un quadro delle possibili criticità di progetto




� REQUEST FOR PROPOSAL: RICHIESTA DI OFFERTA PER IL SISTEMA INFORMATIVO DI XXXX S.R.L.

> Copyrights> Sommario> Introduzione scopo del documento> Background descrizione dell’azienda e dell’attività> Struttura del documento ne descrive la struttura, parti, allegati,..> Invio dell’Offerta a chi inviare l’offerta, in che modalità e

in che tempi (pdf, mail ordinario,….)> Riservatezza clausole di riservatezza per il lettore,

spesso richiamano il cc relativamente al segreto industriale

> Costi di formulazione dell’Offerta specificazioni a carico del lettore> Approfondimenti e dubbi persone di riferimento/supporto> Aspetti commerciali

> Numero Utenze determina il numero licenze necessarie > Prezzo e pagamento prezzi di listino e/o sconti> Proprietà del codice importante per le personalizzazioni> Garanzia dalla fornitura, dall’installazione,…> Proposta economica valori economici in gioco> Varie eventuali altre specificazioni, es.

politica manutenzione, supporto,…> Requisiti> Tabella dei Requisiti Funzionali mappatura (“as is”, “will be” ovvero “nice

to have”) dei processi essenziali e delle funzionalità irrinunciabili


Clie

nte

Ven

dite

Fid

i e fa

tture

Con

trol

lo

prod

uzio

neC

opia

Ass

embl

aggi

o e

sped

izio

neGenerazione

ordineElaborazione pagamento

Completamento ordine

Valutazione problema credito

OK ?Sospensione

ordine

Fidi OK ?Preparazione

ordineInvio

fatturaInvio

ordine?Credito

OKRicezione

ordine

Inserimento ordine

Disponibile?

Pianificazione produzione

Copia dischetti

Assemblaggio confezioni

Raccolta ordine

Spedizione ordine

No

Sì

NoSì

No

Fat

tura

Pro

dotto

Sì

0

20

> Allegato tabella dei Requisiti Funzionali: il pro cesso


� si pone il problema, una volta ricevute le offerte, di valutale per scegliere la soluzione finale

� occorre realizzare un ranking delle RFP ricevute..

� una metodologia interessante e relativamente semplice che si può utilizzare è quella della “matrice delle alternative” ovvero“alternative Matrix”



� si crea una griglia con, sulle colonne, i fornitori di soluzione e sulle righe i criteri di valutazione

� si assegna ad ogni criterio di valutazione un peso percentuale, concordato con le funzioni aziendali e la proprietà

� sulle colonne si mettono dei “voti” che testimoniano l’aderenza della soluzione ai criteri stabiliti

� in questo modo si ottiene una valutazione che consente di scremare le proposte ed effettuare gli approfondimenti del caso solo con le soluzioni più interessanti

� chiaramente i pesi relativi hanno molta influenza sul risultato finale

� occorre un contributo di tutta l’azienda alla definizione dei criteri perché altrimenti si sceglierebbe solo la soluzione tecnologicamente migliore (primo coinvolgimento del team di progetto)



sol.1 sol. 2 sol. 3 sol. 4 sol. 5 sol. 6CRITERI PESO

COSTO SOLUZIONE 20,00% molto alto 1 medio alto 3 medio alto 3 alto 2 medio alto 3 il più basso 5

ADERENZA PROCESSI, PESO PERSON. 30,00% molta pers. 2 3 aderente 5 da fare tutto 2 3 da fare tutto, 1

dev molto flessibile

TECNOLOGIA/DEV/AUTONOMIA 20,00% oracle,pl/sql 4 oracle,pl/sql 4 oracle, pl/sql 2 .NET, sql-server 5 2 php, postgres 5

EFFORT/TIME/IMPEGNO INTERNO 10,00% elevato 2 medio 3 medio 3 molto elevato 1 medio 3 medio alto 2

METODOLOGIA PROGETTO 3,00% standard 3 standard 3 standard 3 rational rose 4 3 standard 3

REFERENZE 7,00% buone 4 poche 2 buone 4 buone 2 1 su altri settori 1

ma su vecchia

versione;

ASSETTO SOCIETARIO FORNITORI 10,00% crisi societaria? 1 3 3 3 3 3

100,00%

TOTALE 2,3 3,1 3,5 3 2,7 3

alternative matrix



� SAP Italia fornisce le licenze ed i moduli standard della soluzione, le licenze del DB; in genere la vendita delle licenzesotto un certo fatturato è fatta direttamente dal partner

� i progetti SAP vengono realizzati da partner SAP, che sul territorio possono anche farsi concorrenza

� ogni partner può avere anche un “pezzo” di soluzione elaborata in proprio a partire dai componenti standard forniti da SAP Italia, sicchè al variare del partner si potrebbero avere soluzioni applicative anche molto diverse anche nello stesso settore di mercato, benchè rispondenti ai “canoni tecnologici” SAP

� I partner, in genere, si specializzano sui settori verticali (moda, cartiere, tornerie,…) e su di essi costruiscono sui toolstandard forniti dalla casa madre una propria soluzione certificata


ciclo di vita sistema ERP: scelta partner di progetto, caso 2 (2/6)

� Microsoft fornisce un prodotto ERP che si chiama Axapta, sotto forma di licenze base e data base SQL- Server

� sul territorio i partner Axapta si specializzano su un settore (moda, acciaierie, ecc.) ed ognuno presenta la sua verticalizzazione al cliente interessato

� quindi, benchè la concorrenza sullo stesso territorio sia in questo caso più difficile (anche se non esclusa a priori), ogni partner sviluppa la propria soluzione di settore secondo le metodologie e la tecnologia di base di Microsoft;

� Microsoft promuove il partner su canali opportuni (Internet, eventi con “case history” in modo da indirizzare la domanda verso il partner più “opportuno”


ciclo di vita sistema ERP: scelta partner di progetto, caso 2 (2/6)

� é opportuno, quindi, che una RFP richieda formalmente al fornitore indicazioni su:

� “moduli” offerti dal fornitore nel pacchetto standard� tempi e costi della soluzione (€, gg/uomo complessivi, costo licenze db, costo licenze soluzione,…)� tempi e costi delle personalizzazioni (€, gg/uomo)� tecnologia utilizzata (data base, linguaggi di sviluppo,..)� politiche e costi di manutenzione nel tempo della soluzione�…e delle personalizzazioni!!� organizzazione del team di progetto, tariffe per figura professionale, spese di trasferta (progetti lunghi…)� organizzazione del progetto ed impegno stimato delle risorse interne� eventuale ricorso a “subappalti” per specifiche aree di analisi e/o implementazione� eventuali clausole di non rivendibilità di soluzioni personalizzate (!!)


ciclo di vita sistema ERP: scelta ERP e tipicispunti contrattuali (2/6)


ciclo di vita sistema ERP: organigramma di progetto (3/6)

capo progetto partner

steering committee

capo progetto cliente

funzioni 1,2..N

team sviluppo

team analisi

cliente, partner

team progetto cliente

processo A

funzioni 1,2,..N

processo B

funzioni 1,2...N

processo M

� la RFP fornirà una stima dello sforzo di progetto complessivo, in termini di costo e di risorse, compreso lo sforzo aggiuntivo rispetto alla fornitura del pacchetto base (personalizzazioni o customizing)

� per questo è importante descrivere nella RFP i processi distintivi, e le funzionalità “caratterizzanti” l’impresa, per evitare sorprese in fase di progetto

� ciò è molto importante, perché il costo seppure stimato della personalizzazione darà anche indicazioni sul livello di flessibilità dello strumento e di ulteriore sviluppo (che può essere “autonomo” o meno) delle soluzioni personalizzate che l’azienda poterebbe voler realizzare in futuro (magari autonomamente)


ciclo di vita sistema ERP: disegno del proprio ERP (4/6)

� nella RFP il fornitore dovrebbe fornire anche un’indicazione dell’hwa sostegno della soluzione (non è detto che lo debba vendere lui) nonché degli strumenti di sviluppo e della tecnologia utilizzata

� il peso relativo che viene dato alla voce “tecnologia” e “aderenza ai processi” cambia da azienda ad azienda e da settore a settore

� é comunque un aspetto da non sottovalutare; esistono soluzioni tecnologicamente spinte ma “povere” a livello di copertura di processo e, viceversa, soluzioni tecnologicamente obsolete ma ricche di substrato di supporto ai processi



� cos’è una “personalizzazione”? I fornitori di soluzione dispongono generalmente di un pacchetto cosiddetto “standard”, che racchiude in se funzionalità raccolte dall’esperienza sul “campo” dei vari clienti (best of breed)

� non è assolutamente detto che i processi aziendali del cliente si riconoscano appieno nella soluzione “standard”, anzi nella pratica ciò non avviene mai

� esistono aziende disposte a modificare il proprio processo pur di non incorrere in “modifiche a pagamento”,altre non lo possono accettare e pongono la personalizzazione alla base del rapporto di collaborazione

� si apre, in certi casi, uno scenario relativo non solo alla realizzazione(opportunità, costo, manutenzione,ecc.) delle personalizzazioni ma anche alla loro proprietà e rivendibilità, soprattutto in settori captiveper il software vendor



� perché sono progetti difficili? sono sicuramente impegnativi economicamente e temporalmente, coinvolgendo altrettanto in modo importante l’intera organizzazione

� richiedono una forte e consapevole “direzione” di progetto interna

� spesso però si commettono errori…il più comune è di ritenerlo un progetto “informatico” e non di “organizzazione e processi”; è lo stesso errore che si eredita dalla terminologia errata

� un altro è di perdersi nei dettagli, ad esempio replicando stampe, reports, ecc..prima di aver curato la presenza dei dati che li generano..

� un altro errore è di tentare di replicare il modo di operare attuale nel nuovo sistema; ciò crea sicuramente problemi, in quanto sarà molto difficile trovare un sistema che replichi esattamente le maschere, le stampe, ecc…

� se è questo che si voleva, perché cambiare allora?

� occorre mappare i propri processi nel nuovo sistema, scorporando i “processi” dalle “procedure software”…



� approccio che prevede la partenza simultanea di tutta l’azienda sul nuovo sistema informativo, ovviamente previa fase di test e di migrazione completa dei dati

� pregi:� rapidità di ultimazione del progetto� integrazione tra i moduli (tra le funzioni aziendali) provata in “tempo reale”� non coesistenza di vecchio e nuovo sistema con eliminazione di interfacce “a perdere”

� difetti:� impone di portare tutti gli archivi contemporaneamente sul nuovo sistema (conversione archivi esistenti)� necessità di formare adeguatamente e contemporaneamente tutti gli utenti in una arco temporale più stretto� possibile sovraccarico di problemi dovuto alla partenza simultanea di tutti i moduli� possibile prolungamento imprevisto a causa di formazione aggiuntiva da erogare e/o problemi da ricercare potenzialmente su più moduli


realizzazione del progetto: bing bang (5/6)

� questo scenario prevede che l’azienda venga scomposta nei suoi processi “elementari”; avremo quindi, ad esempio, il caricamento ordini cliente, gli acquisti, la programmazione della produzione, il lancio, il versamento a magazzino, la spedizione, la fatturazione, ecc. La tecnica prevede di affrontare “a pezzi” il progetto, interessando via via le funzioni aziendali coinvolte; le altre funzioni lavoreranno sul vecchio sistema; tecnologicamente si costruiranno delle interfacce per cui ogni variazione “rilevante” sul nuovo sistema sarà portata sul vecchio e viceversa

� pregi:� gradualità di progetto e maggiore facilità di “assorbimento” per l’azienda� formazione graduale in ragione delle funzioni coinvolte e del numero di fasi� test (e quindi errori) circoscritti alla funzione/processo aziendale che si sta esaminando

� difetti:�occorre separare bene i processi per destinarli opportunamente sul nuovo sistema o sul vecchio a seconda del punti di “innesco”� tempi più lunghi, complessità tecnologica più elevata, costi di progetto più elevati, necessità di mantenere vecchio sistema in vita per più tempo e di interfacciarlo molto bene al nuovo per il necessario scambio dati


realizzazione del progetto: phased approach(5/6)


realizzazione del progetto: phased approach(5/6)

Check time


bibliografia

“ERP: making it happen” T.F. Wallace M.H. Kremzar, Wiley&Sons

“Maximizing your ERP System”Scott HamiltonMC Graw Hill

“Systems analysis and design”Alan Dennis, Barbara Haley WixomWiley&Sons

“Enterprise Resource Planning Systems”Daniel E.O’LearyCambridge Press

[email protected]

Dott. Ing. Bruno Stefanutti

Date post:	06-Dec-2014
Category:	Documents
Upload:	ing-bruno-stefanutti-cpim-cscp
View:	416 times
Download:	0 times

Lezione tenuta dall'Ing. Stefanutti presso l'Università di Padova, Dipartimento di Ingegneria...

Documents