1.
Implementazione in azienda di sistemi
informativi integrati: metodologie di scelta
e di gestione dei progetti
Vicenza, 8 maggio 2007
bruno.stefanutti@consept.it

2.
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.).

3.
Agenda
Parte 1: l’azienda ed il “bisogno” di sistema integrato
Parte 2: generalità sui sistemi ERP
Parte 3: realizzazione di un progetto ERP

4.
Parte 1
l’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”

5.
Parte 2
generalità 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 moduloprocesso aziendale da coprire
aderenza tra processo aziendale e modulo ERP: modulo
standard e personalizzazioni

6.
Parte 3
implementazione 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.
2.
3.
4.
5.
6.
decisione di scegliere un ERP
criteri di scelta del proprio ERP
definizione dell’organigramma di progetto: ruoli e responsabilità
“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
realizzazione del progetto: bing bang approach vs. phased approach
training (1, 2, 3, 4, 5)

7.
sistemi informativi “centralizzati”, “distribuiti”
ed “integrati”: spinte al cambiamento ed effetti
del cambiamento
r
Parte 1: l’azienda ed il “bisogno” di sistema integrato

8.
sistemi informativi “centralizzati”, “distribuiti”
ed “integrati”: spinte al cambiamento ed effetti
del cambiamento
Y2K
Internet (in azienda, 1995)
necessità
di
revisione
del sistema
informativo
Euro (2001)
Parte 1: l’azienda ed il “bisogno” di sistema integrato

9.
sistemi informativi “centralizzati”, “distribuiti”
ed “integrati”: spinte al cambiamento ed effetti
del cambiamento
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 livello
b. presenta dati non integri, difformi e di difficile acquisizione
c. si registra un’assenza o latenza di procedure oppure un eccesso di
attività manuali e ripetute
d. ………….
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 esternalizzare
ciò che non si conosce)
la sostituzione del sistema informativo non è solo un problema
tecnologico ma soprattutto organizzativo!!
Parte 1: l’azienda ed il “bisogno” di sistema integrato

10.
sistemi informativi “centralizzati”, “distribuiti”
ed “integrati”: spinte al cambiamento ed effetti
del cambiamento
D a ta
PDA
C o m pu te r
D a ta
M odem
C o m p u te r
C o m p u te r
D a ta
IN T E R N E T
H ub
C o m p u te r
H ub
R o u te r
F ire w a ll
C o m p u te r
D a ta
Parte 1: l’azienda ed il “bisogno” di sistema integrato

11.
sistemi informativi “centralizzati”, “distribuiti”
ed “integrati”: spinte al cambiamento ed effetti
del cambiamento
in realtà si trovano situazioni intermedie a quelle illustrate; un
certo numero di aziende sono ancora al modello “mainframe
AS400”, 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 aziendale,
decisioni non supportate da “fatti numerici” coerenti e
condivisi
Parte 1: l’azienda ed il “bisogno” di sistema integrato

12.
sistemi informativi “centralizzati”, “distribuiti”
ed “integrati”: spinte al cambiamento ed effetti
del cambiamento
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”
Parte 1: l’azienda ed il “bisogno” di sistema integrato

13.
monitor primari del bisogno di “sistema integrato”:
indeterminazione del costo di prodotto/servizio
le principali “indeterminazioni” gestionali che gli imprenditori
vorrebbero 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)…
Parte 1: l’azienda ed il “bisogno” di sistema integrato

14.
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
Parte 1: l’azienda ed il “bisogno” di sistema integrato

15.
LIVELLO DIREZIONALE
DI CONTROLLO
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.
LIVELLO APPLICATIVOGESTIONALE
Master
applicazione
gestionale
(E.R.P.
oppure no)
LIVELLO DATI E INFRASTR.
Online
Purchas es
T elephone
P urchases
Internatio
nal Retail
Master
PI
Master
MI
Parte 1: l’azienda ed il “bisogno” di sistema integrato
INTERNET
?
?

16.
i sistemi informativi e le decisioni aziendali:
sistemi “transazionali” e “decision support system”
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
Parte 1: l’azienda ed il “bisogno” di sistema integrato

17.
Sistemi decisionali e di reporting
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
Altri sistemi
Legacy o
di nicchia
• Sistemi ERP – Financial
• Sistemi ERP – Risorse
• Umane
• Altri sistemi orizzontali
Sistemi MRP
Produzione
• Produzione
• Approvvigionamenti
• Distribuzione
Sistemi transazionali
Parte 1: l’azienda ed il “bisogno” di sistema integrato
Sistemi CRM
• Call Center
• Portali Web
• Automazione forza vend.
• Altri

18.
i sistemi informativi e le decisioni aziendali:
sistemi “transazionali” e “decision support system”
Data Warehouse
Fonti dati (ERP, ecc..)
Data Marts
Area
collettore
Dati
estrazione dati (ETL)
accesso ai dati
Parte 1: l’azienda ed il “bisogno” di sistema integrato
Accesso
utente

19.
PEZZI,
VALORE,..
Italia
Germania
Di
Q4
Q1
Q2
Q3
Dimensione tempo
sio
n
U.K.
e
prodotto “A”
prodotto “B”
prodotto “C”
prodotto “D”
Parte 1: l’azienda ed il “bisogno” di sistema integrato
pr
od
ot
ti
Francia
me
n
Dimensione zona
i sistemi informativi e le decisioni aziendali:
sistemi “transazionali” e “decision support system”

20.
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 moduloprocesso
aderenza tra processo aziendale e modulo ERP

21.
ERP: terminologia e standard de facto
MRP II
Closedloop MRP
MRP
ERP
Parte 2: scelta della soluzione ERP

22.
ERP: terminologia e standard de facto
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
Parte 2: scelta della soluzione ERP

23.
ERP: terminologia e standard de facto
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”
Parte 2: scelta della soluzione ERP

24.
ERP: terminologia e standard de facto
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 that
support 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…
Parte 2: scelta della soluzione ERP

25.
ERP: terminologia e standard de facto
ERP: definizioni possibili
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
Parte 2: scelta della soluzione ERP

26.
l’APICS (www.apics.org) ed il suo ruolo
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 di
certificazione internazionale equiparati a master sui sistemi di
produzione 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
Parte 2: scelta della soluzione ERP

27.
ERP: terminologia e standard de facto
“Enterprise Resources Planning (ERP): framework for
organizing, defining and standardizing the business
processes necessary to effectively plan and control an
organization so the organization can use its internal
knowledge to seek external advantage” (APICS
Dictionary, page 38)
Parte 2: scelta della soluzione ERP

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

29.
pregi/difetti comunemente condivisi dei sistemi
ERP
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
Parte 2: scelta della soluzione ERP

30.
pregi/difetti comunemente condivisi dei sistemi
ERP
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
Parte 2: scelta della soluzione ERP

31.
pregi/difetti comunemente condivisi dei sistemi
ERP
“Too many companies have bought an extremely
expensive set of “golf clubs” (an enterprise
software system) but haven’t learned how to play
golf. That’s why we read about so many “ERP
failures” in the business press. (…). Saying that
ERP failed in these cases is like saying that golf
failed because I’ve bought a $2000 set of golf clubs
and didn’t break 120. Golf failed? Makes non
sense”
Parte 2: scelta della soluzione ERP
“ERP: making it happen”
T.F. Wallace
M.H. Kremzar, Wiley&Sons

32.
architettura semplificata dei
sistemi ERP
ERP
ERP PROCESSES NOT PART
STANDARD ES
• Sales forecasting
• Sales and operations planning
• Advanced planning system
• Supplier rating system
• Performance metrics
Parte 2: scelta della soluzione ERP
ERP PROCESSES IN
STANDARD ES
ES
NON ERP PROCESSES FOUND
IN A TYPICAL ES
• Ar, Ap, Gl
• Master production scheduling
• Cash management
• Rough-cut Capacity planning
• Crm
• MRP
• HR
• Capacity requirements planning
• Data wharehouse
• Distribution requirements
planning
• Customer order entry
Fonte: “ERP: Making it happen”
T. Wallace, M. Kremzar

33.
SAP module
Order management
Il concetto di “moduli” nei sistemi ERP:
la relazione modulo-processo
proposal
commitment
Config.
credit check
delivery
prima di fatturare, ha
già registrato costi di
manodopera, materiale
ed eventuali varianze
grazie all’integrazione
con gli altri moduli
Prezzo, sconti,
verifica
credito
Sales and distr.
Verifica
disponibilità e/o
rilascio ordine
produzione
Sales and distr.
production planning
purchasing
pilota l’MRP
Parte 2: scelta della soluzione ERP
billing
FInancial&Controlling
pilota l’acquisto
fasi esterne per
la lavorazione

34.
Parte 3
implementazione 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.
2.
3.
4.
5.
6.
decisione di scegliere un ERP
criteri di scelta del proprio ERP
definizione dell’organigramma di progetto: ruoli e responsabilità
“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 moduli che servono
realizzazione del progetto: bing bang approach vs. phased approach
training (1,2,3,4)

35.
perché cambiare SIA: motivazioni
che portano alla software selection
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 livello
b. presenta dati non integri e difformi a seconda dell’area funzionale
c. si registra un’assenza o latenza di procedure oppure un eccesso di
attività manuali e ripetute
d. …………….
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 esternalizzare
ciò che non si conosce)
la sostituzione del sistema informativo è principalmente un problema
organizzativo
Parte 3: implementazione in azienda di un sistema ERP

36.
ciclo di vita di un sistema ERP
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
i. censimento/revisione dei propri processi: occorre
modificarli/reingegnerizzarli oppure “modificare” il software?
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)
Parte 3: implementazione in azienda di un sistema ERP

37.
ciclo di vita sistema ERP: decisione di scegliere
(1/6)
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
Parte 3: implementazione in azienda di un sistema ERP

38.
ciclo di vita sistema ERP: scelta ERP (2/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 è (“as
is”) 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
Parte 3: implementazione in azienda di un sistema ERP

39.
ciclo di vita sistema ERP: scelta ERP (2/6)
tutta l’analisi confluisce in un documento aziendale prezioso, la Request for
Proposal
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
Parte 3: implementazione in azienda di un sistema ERP

40.
ciclo di vita sistema ERP: scelta ERP (2/6)
REQUEST FOR PROPOSAL: RICHIESTA DI OFFERTA PER IL SISTEMA INFORMATIVO DI XXXX S.R.L.
>
>
>
>
>
>
Copyrights
Sommario
Introduzione
Background
Struttura del documento
Invio dell’Offerta
> Riservatezza
> Costi di formulazione dell’Offerta
> Approfondimenti e dubbi
> Aspetti commerciali
> Numero Utenze
> Prezzo e pagamento
> Proprietà del codice
> Garanzia
> Proposta economica
> Varie
> Requisiti
> Tabella dei Requisiti Funzionali
Parte 3: implementazione in azienda di un sistema ERP
scopo del documento
descrizione dell’azienda e dell’attività
ne descrive la struttura, parti, allegati,..
a chi inviare l’offerta, in che modalità e
in che tempi (pdf, mail ordinario,….)
clausole di riservatezza per il lettore,
spesso richiamano il cc relativamente al
segreto industriale
specificazioni a carico del lettore
persone di riferimento/supporto
determina il numero licenze necessarie
prezzi di listino e/o sconti
importante per le personalizzazioni
dalla fornitura, dall’installazione,…
valori economici in gioco
eventuali altre specificazioni, es.
politica manutenzione, supporto,…
mappatura (“as is”, “will be” ovvero “nice
to have”) dei processi essenziali e delle
funzionalità irrinunciabili

41.
ciclo di vita sistema ERP: scelta ERP (2/6)
Cliente
> Allegato tabella dei Requisiti Funzionali: il processo
Generazione
ordine
Elaborazione
pagamento
OK ?
No
Sospensione
ordine
Controllo
Fidi e fatture
produzione
Sì
Prodotto
Valutazione
problema
credito
Completamento
ordine
Fattura
Vendite
20
No
Sì
Ricezione
ordine
Fidi
OK ?
Credito
OK
Inserimento
ordine
Preparazione
ordine
Invio
ordine?
Disponibile?
Invio
fattura
No
Assemblaggio
e spedizione
Copia
Sì
0
Pianificazione
produzione
Assemblaggio
confezioni
Copia
dischetti
Raccolta
ordine
Spedizione
ordine

42.
ciclo di vita sistema ERP: scelta ERP (2/6)
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”
Parte 3: implementazione in azienda di un sistema ERP

43.
ciclo di vita sistema ERP: scelta ERP (2/6)
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)
Parte 3: implementazione in azienda di un sistema ERP

44.
ciclo di vita sistema ERP: scelta ERP (2/6)
alternative matrix
sol.1
sol. 2
sol. 3
sol. 4
sol. 5
sol. 6
CRITERI
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
1
3
3
3
3
3
2,3
3,1
3,5
3
2,7
3
ma su vecchia
versione;
ASSETTO SOCIETARIO FORNITORI
10,00% crisi societaria?
100,00%
TOTALE
Parte 3: implementazione in azienda di un sistema ERP

45.
ciclo di vita sistema ERP: scelta partner
di progetto, caso 2 (2/6)
SAP Italia fornisce le licenze ed i moduli standard della
soluzione, le licenze del DB; in genere la vendita delle licenze
sotto 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 tool
standard forniti dalla casa madre una propria soluzione
certificata
Parte 3: implementazione in azienda di un sistema ERP

46.
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”
Parte 3: implementazione in azienda di un sistema ERP

47.
ciclo di vita sistema ERP: scelta ERP e tipici
spunti contrattuali (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
(!!)
Parte 3: implementazione in azienda di un sistema ERP

48.
ciclo di vita sistema ERP: organigramma
di progetto (3/6)
cliente, partner
steering
com m ittee
capo progetto
cliente
capo progetto
partner
team progetto
cliente
team
sviluppo
processo A
processo B
processo M
funzioni 1,2,..N
funzioni 1,2...N
funzioni 1,2..N
Parte 3: implementazione in azienda di un sistema ERP
team
analisi

49.
ciclo di vita sistema ERP: disegno del proprio
ERP (4/6)
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)
Parte 3: implementazione in azienda di un sistema ERP

50.
ciclo di vita sistema ERP: disegno del proprio
ERP (4/6)
nella RFP il fornitore dovrebbe fornire anche un’indicazione dell’hw
a 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
Parte 3: implementazione in azienda di un sistema ERP

51.
ciclo di vita sistema ERP: disegno del proprio
ERP (4/6)
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 captive
per il software vendor
Parte 3: implementazione in azienda di un sistema ERP

52.
ciclo di vita sistema ERP: disegno del proprio
ERP (4/6)
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”…
Parte 3: implementazione in azienda di un sistema ERP

53.
realizzazione del progetto:
bing bang (5/6)
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
Parte 3: implementazione in azienda di un sistema ERP

54.
realizzazione del progetto: phased approach
(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
Parte 3: implementazione in azienda di un sistema ERP

55.
realizzazione del progetto: phased approach
(5/6)
Check time
Parte 3: implementazione in azienda di un sistema ERP

56.
bibliografia
“ERP: making it happen” T.F. Wallace M.H. Kremzar,
Wiley&Sons
“Maximizing your ERP System”
Scott Hamilton
MC Graw Hill
“Systems analysis and design”
Alan Dennis, Barbara Haley Wixom
Wiley&Sons
“Enterprise Resource Planning Systems”
Daniel E.O’Leary
Cambridge Press
Parte 3: implementazione in azienda di un sistema ERP

57.
Dott. Ing. Bruno Stefanutti
bruno.stefanutti@consept.it