universita di padova v3 sint - consept.it · Implementazione in azienda di sistemi informativi...

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)

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

� sistemi informativi “centralizzati”, “distribuiti” ed “integrati”: 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”

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



INT E RN E T

Hu b

Hu b

F ire wa ll

C om pu te r

C om pu ter

Co m p ute r

C om p uter

R ou ter

P D A

Co m p ute r

Mo de m

D ata

Da ta

D a ta

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 aziendale, decisioni non supportate da “fatti numerici” coeren ti e condivisi



� manca una visione di insieme sia sulla tecnologia (effetto) che primariamente sui processi aziendali (causa);

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

� l’investimento in tecnologia deve essere opportunamente “giustificato” all’imprenditore che, soprattutto nel Nord Est, vede ancora la tecnologia come un costo; la funzione EDP deve acquisire competenze “manageriali” oltre che “tecniche”, per sostenere confronti “finanziari/contabili” e di “processo” oltre che “tecnologici”

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



� la tecnologia è un valido strumento abilitatore per fronteggiare o provocare il cambiamento: essa ha un prezzo e può essere acquisita sul mercato;

� tuttavia il mero costo d’acquisto di tecnologia diviene, quindi, vero investimento aziendale solo laddove risponda ad effettive esigenze di miglioramento del modello organizzativo: perché acquistare tecnologia? con quali fini? la tecnologia ci aiuterà a modificare i processi interni rendendoli più efficaci ed efficienti?

� senza una corretta analisi di processo il rischio è quello di replicare su un nuovo supporto tecnologico hw/sw le inefficenzeche hanno spinto a cambiare quello stesso supporto



� 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

� “qual ‘ è il costo del prodotto/servizio?”

� “quali fasi di lavorazione conviene fare all’interno oppure esternalizzare?”

� “il prezzo concordato con il cliente è effettivamente remunerativo?”, “fino a che punto è conveniente effettuare un determinato investimento?”, “qual è l’ammontare di fatturato che consente la copertura delle spese generali e consente alla società il raggiungimento di un utile predeterminato?”, “come facciamo a minimizzare le scorte per non immobilizzare troppo capitale?”

� “qual è stato l’andamento delle vendite a marzo, rispetto allo stesso mese degli ultimi tre anni?”, “qual è stato il prodotto/servizio più redditizio?”, “quali sono stati i fornitori meno affidabili dal punto di vista delle consegne negli ultimi tre mesi?”



� 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 APPLICATIVO-GESTIONALE

LIVELLO DATI E INFRASTR.

LIVELLO DIREZIONALE DI CONTROLLO

Master

OnlinePurchases

T elephonePurchases

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”

LIVELLO APPLICATIVO

LIVELLO DATI

LIVELLO CONTROLLO

Master

INT

ER

NE

T

? ?

PI MIMaster

OnlinePurchases

T elephonePurchases


X X

Master

applicazione gestionale (E.R.P.

oppure no)


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”



� i sistemi ERP nascono per gestire informazioni con finestra temporale ridotta (input dati, fatture, stampe riepilogo,…)

� qualora si tenti di utilizzare tali sistemi per analisi più ”profonde” rispetto alla dimensione tempo o debbano servire per incrociare tra loro o storicizzare più dimensioni di analisi, denotano tutti i loro limiti

� effetti possibili:

� il sistema (ERP oppure no) rallenta� si interviene sull’applicazione con costose (ed inutili) personalizzazioni� magari si sostituisce l’applicazione non ERP esistente con un ERP per risolvere questo problema….

� in certi progetti ERP il costo della reportistica ha raggiunto il 30% del costo complessivo!!

� strumenti di business intelligence vanno integrati con il sistema informativo di base



LIVELLO APPLICATIVO

LIVELLO DATI

LIVELLO CONTROLLO

Master INT

ER

NE

T

Master

OnlinePurchases

TelephoneP urchases


PI MI

0

10

20

30

40

50

60

70

80

90

100

0 0,5 1 1,5 2 2,5 3 3,5

1s t Qtr2nd Qtr

3r d Qtr4th Qtr

Master

E.R.P.


beneservizio

risorse

risorse cdcbeneservizio

Costo complessivo

Materieprime

Man.diretta

AltriCostidiretti

Costi comuniIndir.

Costo primo-

Materieprime

Costi comuniIndir.

Costo primo

Costo Industr.

Comm., Ammin.oneri

Costi figurativi

Costo primo

Costo Trasf.

Costo industriale

Costo complessivo

Costo economico-tecnico

Activity

Activity Activity Activity

Activity Activity

Q4Q1 Q2 Q3Dimensione “tempo” Di

mensioni

“prodotto”

Mezzo d

Mezzo c

Mezzo b

Dim

ensioni“mercato”

analisi

smaltim.espurgo

Mezzo aRICAVI E

COSTI!!!

tr. Camp.

Master

20 dipendenti…


beneservizio

risorse

risorse cdcbeneservizio

Costo complessivo

Materieprime

Man.diretta

AltriCostidiretti

Costi comuniIndir.

Costo primo-

Materieprime

Costi comuniIndir.

Costo primo

Costo Industr.

Comm., Ammin., oneri

Costi figurativi

Costo primo

Costo Trasf.

Costo industriale

Costo complessivo

Costo economico-tecnico

Activity


Activity Activity

Q4Q1 Q2 Q3Dimensione “tempo” Di

mensioni

“prodotto”

Napoli

Roma

Milano

Dim

ensioni“mercato”

abiti

pantalonigonne

VeneziaRICAVI E

COSTI!!!

giacche

490 dipendenti…

sistema informativo

(E.R.P., no ERP)


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”



� 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

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



� 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

MASTER SCHEDULING

MRP, PLANT SCHED., SUPPLIER SCHED.,..

For

ecas

ting

and

dem

and

man

agem

ent

Cap

acity

plan

ning

execution

Logica semplificata ERP (lato produzione)

Strategic planning

Business planning

S&OP

Salesplan

Oper.plan

Family deep

Item deep

Rough cut


architettura semplificata dei sistemi ERP

� l’azienda in funzione degli obiettivi e delle capacità di investimento, può acquistare anche una sola parte dei moduli disponibili

� la loro successiva integrazione con altri moduli già esistenti ègarantita dal vendor

� questo eventuale aggiornamento non rientra nell’EAI, perché si tratta di moduli appartenenti allo stesso oggetto software


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

MATERIAL MANAGEMENT

HUMAN RESOURCES

QUALITYMANAGEMENT

…….

FINANCE AND

CONTROLLING

ACTIVITY BASED COSTING

SALES &

DISTRIBUTION

PRODUCTIONPLANNING

…….



Activity


Activity Activity

?

E.R.P.


� l’attività di copertura software-processi è la vera sfida nell’implementazione degli ERP, ed è una sfida organizzativa prima che tecnologica


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



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

� comunque la si veda, occorre prima di scegliere un sistema, individuarne le caratteristiche principali e distintive dal punto di vista aziendale

� questo processo (analisi dei requisiti e conseguentemente software selection) deve essere fatto dall’azienda, spesso con una guida “esterna”

� il risultato è formalmente un documento (Request forInformation, Request for Proposal) che serve a certificare al potenziale fornitore i requisiti di processo as is cui la soluzione software deve aderire per soddisfare le esigenze operative e strategiche aziendali correnti; il documento dovrebbe anche contenere degli spunti nice to have, ovvero delle ipotesi di processi migliorati (will be) o, quantomeno, delle “critiche” alla gestione corrente (limiti attuali imposti dalla soluzione swattualmente adottata )


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)

processo e

sue variabili interne (risorse, tempi, routing,..)

Ri(t) Ro(t)

input (funzione A) Output (funzione B)

Il processo aziendale come black box

� esiste una vera e propria “algebra di processo” , che consente di estrarre informazioni numeriche dal flow chart sfruttando le p recise regole che legano le grandezze di input, output ed interne al process o in esame

� quando l’azienda perde o non comprende la visione d ei suoi flussi a livello di processo, si originano “surrogati” di informazio ne, incompleti per definizione, che sono alla fonte delle incongruenze e non integrità dei dati



� cammino critico

� definiamo il “flow time teorico” di processo come il minimo tempo necessario a processare una tipica “flowunit”, senza alcuna attesa

� poiché un dato processo può avere più cammini che “instradano” le flow unit per condurle dall’inizio alla fine, ciò significa che il cammino più “lungo” individua di fatto tale tempo teorico “minimo”



� le attività che si trovano nel cammino più lungo so no le attività critiche ed il “cammino più lungo” è chiamato cammino critic o (critical path)

Rep. 1 Inizio

1 2

punch roof

3

4 5

6

7

8 9

end

10

inspectassemble

sub assemble base

form base

separate materials

punch base

form roof



� è intuitivo che vale

FLOW TIME REALE

=

FLOW TIME TEORICO + TEMPI DI ATTESA

=

FLOW TIME A VALORE AGGIUNTO

+

FLOW TIME A NON VALORE AGGIUNTO



5,6%5 h11 daysFinancialclosing

Auto Manufacture

3,75%3 h10 daysPatientbilling

Hospital

2,36%34 min.24 hConsumer loan

Bank

0,16%7 min.72 hNew policyapplic.

Life insurance

Flowtime effic.

theoricalFlowtime

Flowtime

processindustry

efficienza di alcuni processi (1992, Blackburn )



“Managing Business Process Flows”Ravi Anupindi et altriPearson Prentice Hall

� nelle attività di revisione/sostituzione dei sistemi informativioccorre considerare che l’analisi dei processi “as is” può portare a dei processi “will be” realmente ottimizzati

� occorre evitare il rischio di implementare software che aderisca ai processi attuali qualora gli stessi non siano efficienti o possano essere messi in discussione



� 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



> Tabella dei Requisiti Funzionali (società dedita a lla televendita)Segue tabella completa dei requisiti funzionali.

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

Il sistema deve consentire la rilevazione, da parte di un operatore, degli effettivi passaggi televisivi, all’interno della pianificazione programmata degli stessi

Molto importante

Controllo passaggi televisivi

Gestione Campagne Pubblicitaria (Televendite)

CRM2

Il calendario delle televendite deve essere gestito dal sistema, consentendo di alimentare tutti i dati accessori delle stesse (testimonial, prodotti presentati, particolari offerte, ecc)

Media importanza

Pianificazione uscite televisive

Gestione Campagne Pubblicitaria (Televendite)

CRM1

Descrizione FunzioneImportanzaFunzioneTipo di Funzione

Modulo#


ciclo di vita sistema ERP: scelta ERP (2/6)Sommario1. Sommario1. PARTE 1: OBIETTIVI DEL DOCUMENTO, STRUTTURA DELLE RISPOSTE AL DOCUMENTO, MODALITA’ DI RISPOSTA AL DOCUMENTO.2. Generalità3. Struttura del documento di risposta ed invio dell’offerta.4. Riservatezza, tutela del segreto industriale5. Architettura della soluzione6. Utenze7. Proposta economica8. Garanzia e manutenzione9. Varie10. Costi di formulazione dell’offerta11. Approfondimenti e dubbi12. PARTE 2 – GENERALITA’ SULL’ORGANIZZAZIONE DI XXXX S.P.A.13. Background14. Nomenclatura: modello, tessuto, componenti, varianti, fasi di lavorazione15. PARTE TERZA: PROCESSI AZIENDALI DI XXXX S.P.A E DESCRIZIONE DEI REQUISITI FUNZIONALI DELLA SOLUZIONE.16. Descrizione dei processi aziendali17. Ufficio Acquisti materia prima (gestione ordine a fornitore)18. Ufficio Commerciale (gestione ordine cliente)19. Ufficio Programmazione20. Produzionea. Ufficio Tempi&Metodi (Industrializzazione del lavoro)b. Cadc. Magazzino materie prime21. Magazzino capi finiti22. Ufficio Amministrazione23. PARTE QUARTA: ALLEGATI24. Individuazione dei codici di magazzino dei componenti dalle righe ordine: caso 125. Individuazione dei codici di magazzino dei componenti dalle righe ordine: caso 2


> Tabella dei Requisiti Funzionali (azienda di abbi gliamento)Segue tabella completa dei requisiti funzionali.


molto critica La rilevante criticitàrisiede non tanto nell’interazione informatica che, per quanto attiene a questo ufficio non èparticolarmente spinta, quanto ad alcune caratteristiche della gestione di XXXX: l’elevato numero di modelli gestiti, l’abbinamento “N a N” di giacche con pantaloni ed infine….

Si descrive brevemente il ciclo di gestione dell’ordine: gli ordini arrivano in XXXX tramite fax o Internet; l’attività dell’ufficio èprettamente di controllo di coerenza delle informazioni inserite e di completamento in caso di anomalie (modellature, varianti, prezzi, etc..). I listini prezzi vengono gestiti “extra sistema” e poi scaricati sul sistema gestionale. I listini vengono concepiti per categoria di listino tessuto e per tipo modello (non per codice modello)………………………………..

Gestione ordine cliente (stagionale)

Ufficio Commerciale

particolaritàDescrizione attivitàattivitàfunzione aziendale

#

Clie

nte

Ven

dite

Fid

i e fa

tture

Con

trol

lo

prod

uzio

neC

opia

Ass

embl

aggi

o e

sped

izio

ne

Generazione ordine

Elaborazione 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 m edio 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 m olto elevato 1 m edio 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 altr i settori 1

ma su vecchia

versione;

ASSETTO SOCIETARIO FORNITORI 10,00% crisi socie taria? 1 3 3 3 3 3

100,00%

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

alternative matrix



cliente finale

mercato

data base, dev tools, ecc..

� sul prodotto di “mercato”, realizza e fornisce la soluzione completa,frutto delle propriemetodologie di programmazione, personalizzazione,supporto, assistenza, ecc..

Software House

(generalmente “locale”)

� si assiste ad un sempre più frequente utilizzo di tecnologia“open source”, su cui si registra però ancora diffidenza..


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

cliente finale

partner var,

reseller,..

� il partner /var/reselleraggiunge “valore” ai “componenti”std, sviluppandoe promuovendo proprie metodiche di intervento, di personalizzazione, di manutenzione nel rispetto dei canoni tecnologici stabiliti dal vendor al fine di garantire il supporto della soluzione nel tempo

� il vendor fornisce i “componentibase” della soluzione(es. data base, software standard e licenze, toolsdi sviluppo, assistenza tecnica post vendita,.); in genere promuove delle partnership contrattuali basate sulla certificazione all’uso della tecnologia sviluppata, per garantire il cliente finale



� 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



� 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” (es. Riello, riviste, ecc..) in modo da indirizzare la domanda verso il partner più “opportuno”



� proprietà delle personalizzazioni, rivendibilità a terzi da parte del fornitore

� tutela del segreto industriale (il fornitore durante il progetto verrà a conoscenza di tutti i processi aziendali…anche quelli strategici..)

� canone di manutenzione del software, del data base, dell’hardware

� tipologia di supporto in caso di problemi (SLA, service levelagreement)

� garanzia di salvaguardia delle personalizzazioni con i cambi di versione (minor o major release)


ciclo di vita sistema ERP: scelta ERP e tipicispunti 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: scelta ERP e tipicispunti contrattuali (2/6)


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

capo progetto partner

steering comm ittee

capo progetto cliente

funzion i 1,2..N

team sviluppo

team analisi

cliente, partner

team progetto cliente

processo A

funzioni 1,2,..N

processo B

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



� i consulenti possono avere un ruolo importante, fornendo esperienza e metodologia, coordinamento delle terze parti, ecc..

� ma solo le persone dell’azienda conoscono veramente l’azienda e hanno l’autorità per abilitare il cambiamento

� dovrebbe valere il principio:

� realizzatori = utenti

ovvero le persone che “realizzano” la soluzione dovrebbero essere le stesse che la useranno in futuro



� il problema è che le persone sono sempre molto impegnate con la quotidianità del lavoro

� é necessario per la riuscita del progetto che, dall’alto, il cambio di sistema informativo diventi una priorità almeno “numero 2” (la 1 è “run the business”), altrimenti i tempi di soluzione si allungano e gli utenti si scoraggiano nei confronti del nuovo sistema

� un ERP ben implementato non ha mai fallito o disatteso gli obiettivi



� la capacità di “assorbimento” del progetto da parte dell’organizzazione è fondamentale non solo per la sua riuscita ma già per la sua corretta partenza

� Il progetto si somma alla quotidianità aziendale; si introduce, soprattutto in fase iniziale, una scarsità di risorse che l’azienda dovrà “sopportare” e “supportare”, spesso in ruoli chiave, quali quelli di “disegno organizzativo”

� le prime risorse ad essere coinvolte sono in genere gli utenti chiave per una descrizione analitica dei processi aziendali e cioè le persone di “riferimento” oltre ai sistemi informativi

� esistono due approcci possibili:

� big bang� phased


realizzazione del progetto: bing bang approach vs. phased approach (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: 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

“Managing Business Process Flows”Ravi Anupindi et altriPearson Prentice Hall

“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

universita di padova v3 sint - consept.it · Implementazione in azienda di sistemi informativi...

Documents

Transcript of universita di padova v3 sint - consept.it · Implementazione in azienda di sistemi informativi...