• Like
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
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

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

  • 224 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
224
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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