Lezione tenuta dall'Ing. Stefanutti presso l'Università di Padova, Dipartimento di Ingegneria Gestionale (Vicenza), Corso di "Economia delle reti e commercio elettronico", Prof. Ettore Bolisani

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

Vicenza, 8 maggio 2007
bruno.stefanutti@consept.it

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 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”

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

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)

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

r


del cambiamento

Y2K

Internet (in azienda, 1995)

necessità
di
revisione
del sistema
informativo

Euro (2001)


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!!

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


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


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”


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)…


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


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


INTERNET

?

?

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


Sistemi decisionali e di reporting


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


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

Data Warehouse
Fonti dati (ERP, ecc..)

Data Marts
Area
collettore
Dati

estrazione dati (ETL)
accesso ai dati


Accesso
utente

PEZZI,
VALORE,..

Italia

Germania

Di

Q4
Q1
Q2
Q3
Dimensione tempo

sio
n

U.K.

e

prodotto “A”
prodotto “B”
prodotto “C”
prodotto “D”


pr
od
ot
ti

Francia

me
n

Dimensione zona


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

MRP II
Closedloop MRP

MRP

ERP

Parte 2: scelta della soluzione 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 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…


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



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



“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)


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

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

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”


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

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


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

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


billing

FInancial&Controlling

pilota l’acquisto
fasi esterne per
la lavorazione

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

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

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
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 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

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


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



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


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


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


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)

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


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

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 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
(!!)

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


team
analisi

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)


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


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

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”…


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


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

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 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


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

Lezione tenuta dall'Ing. Stefanutti presso l'Università di Padova, Dipartimento di Ingegneria Gestionale (Vicenza), Corso di "Economia delle reti e commercio elettronico", Prof. Ettore Bolisani

Recommended

Recommended

More Related Content

What's hot

What's hot (8)

Viewers also liked

Viewers also liked (20)

Similar to Lezione tenuta dall'Ing. Stefanutti presso l'Università di Padova, Dipartimento di Ingegneria Gestionale (Vicenza), Corso di "Economia delle reti e commercio elettronico", Prof. Ettore Bolisani

Similar to Lezione tenuta dall'Ing. Stefanutti presso l'Università di Padova, Dipartimento di Ingegneria Gestionale (Vicenza), Corso di "Economia delle reti e commercio elettronico", Prof. Ettore Bolisani (20)

Lezione tenuta dall'Ing. Stefanutti presso l'Università di Padova, Dipartimento di Ingegneria Gestionale (Vicenza), Corso di "Economia delle reti e commercio elettronico", Prof. Ettore Bolisani