Master Universitario di I livello in Business Intelligence e Knowledge Management. VI edizione. Organizzazione, Processi e Sistemi ERP

Transcript

1 Master Universitario di I livello in Business Intelligence e Knowledge Management VI edizione Organizzazione, Processi e Sistemi ERP Leonardo Caporarello Istituto di Organizzazione e Sistemi Informativi Università Bocconi, Milano leonardo.caporarello@unibocconi.it Verona, 21/11/2008

2 Agenda Di cosa parleremo? Introduzione Alcune premesse I processi Il BPR: definizione, componenti, aspettative, relazione con l IT Gestire il cambiamento Sistemi informativi integrati (ERP) Relazione tra BPR e ERP Un modello di BPR Implementazione ERP Metodologia BPR Due casi di BPR Lessons learned Riferimenti bibliografici Allegato 1: Fattori critici di successo all implementazione di un sistema ERP slide 2

3 Di cosa parleremo? Organizzazione Processi aziendali Sistemi ERP slide 3

4 Introduzione una persona che lavora da sola non ha bisogno di alcun meccanismo di coordinamento, esegue e controlla il suo lavoro attraverso il proprio cervello, quando le persone diventano due o più piccolo gruppo la situazione cambia poiché bisogna coordinare più cervelli; questo avviene attraverso l adattamento reciproco, ovvero le persone che lavorano fianco a fianco si adattano l uno all altro. A mano a mano che si allarga, tuttavia, il gruppo diventa meno capace di coordinarsi informalmente; emerge un bisogno di leadership, e quindi attraverso la supervisione diretta, si passa ad una situazione in cui un individuo controlla il lavoro di un gruppo. A mano a mano che il lavoro diviene più interconnesso, tende a manifestarsi un altra importante modificazione e cioè lo spostamento verso la standardizzazione. Quando le attività sono semplici e ripetitive, l organizzazione può ricorrere alla standardizzazione dei processi di lavoro; per attività più complesse che non permettono la standardizzazione dei processi di lavoro obbligando a passare alla standardizzazione degli output. Al crescere della complessità delle attività, si è obbligati a passare, dapprima, alla standardizzazione degli input e nel caso in cui questo non fosse possibile si è costretti a tornare all adattamento reciproco Henry Mintzberg slide 4

5 Alcune premesse: Relazioni tra sistemi Ambiente Sistema azienda Sistema organizzativo Sistema informativo slide 5

6 Alcune premesse: Organizzazione e struttura organizzativa L organizzazione è intesa come il complesso delle modalità secondo le quali viene effettuata la divisione del lavoro in compiti distinti e viene realizzato il coordinamento fra tali compiti (Mintzberg, 1979). Le organizzazioni sono quelle unità sociali, cioè quei raggruppamenti di individui, che hanno le seguenti caratteristiche: Ambiente un fine determinato o determinabile; Sistema azienda Sistema organizzativo Sistema informativo un certo numero di meccanismi diretti ad assicurare che le attività svolte tendano a raggiungere tale fine; la possibilità di sostituire i propri componenti quando questo si riveli necessario. slide 6

7 Alcune premesse: Organizzazione e struttura organizzativa Divisione del lavoro: da un insieme indifferenziato di persone a un sistema di ruoli la progettazione organizzativa = disegno del sistema dei ruoli (strutturazione, gestione delle interdipendenze, vincolo ) Coordinamento: Strategia Gerarchia Norme e procedure Tecnologia Schemi, programmi di azione Cultura, valori Per struttura organizzativa si intende l insieme delle specifiche modalità con cui ciascuna organizzazione governa i processi di differenziazione e di integrazione slide 7

8 Alcune premesse: Le dimensioni della progettazione organizzativa * *Galbraith, 1977 slide 8

9 Alcune premesse: Sistema Informativo: una definizione l insieme di persone, apparecchiature, procedure aziendali, il cui compito è quello di riprodurre le informazioni che servono per operare nell impresa e gestirla (De Marco, 1988). Ambiente Sistema azienda Sistema organizzativo Sistema informativo slide 9

10 I processi slide 10

11 Un processo è formato da attività: intese come serie di operazioni su oggetti fisici o informativi collegate fra loro nel tempo e nello spazio svolte dalle risorse di un organizzazione (RU e mezzi). La prospettiva sui processi implica una forte enfasi su come il lavoro viene svolto all interno di un organizzazione, piuttosto che sul che cosa produrre (prospettiva orientata al prodotto) (Davenport, 1993). Un processo può essere misurato in termini di: costo, tempo, qualità del risultato, soddisfazione del cliente. slide 11

12 Il processo come insieme di competenze Un processo di business è basato su un insieme di competenze (responsabilità). Ad esempio, un impresa industriale combina: le competenze commerciali necessarie a vendere il prodotto, le competenze tecniche necessarie a produrlo le competenze generali necessarie ad approvvigionare le materie prime. Tali competenze possono afferire a diverse funzioni: marketing, produzione, approvvigionamento slide 12

13 Tipologie di processo aziendale* Quattro macro tipologie dei processi: processi core: sono costituiti dalle attività principali dell azienda processi di supporto: sostengono le attività core dell azienda (si pensi alle risorse umane, la contabilità) processi business network: coinvolgono clienti e fornitori e si estendono oltre i limiti dell azienda processi management: sono i processi attraverso i quali si pianificano, gestiscono e controllano le risorse *Tratto da: Caporarello & Basaglia, 2008 slide 13

14 Esempio processo: area amministativa Fatturazione Attiva / Passiva Libri Fiscali Incassi / Pagamenti Scritture Contabili Bilancio Fatti Patrimoniali e Finanziari Budget & Forecast Controllo di Gestione Reporting slide 14

15 Esempio processo: area commerciale/logistica Ciclo Attivo (vendite) Offerte a Cliente Approvigion. / Produzione Ordini da Cliente Consegna (DDT) Provvigioni Fatturazione Registrazione Contabile Scadenzario Incassi Ciclo Passivo (acquisti) Richiesta d Offerta (RFQ) Ordini a Fornitore Accettazione Materiali Ricevimento Fattura Registrazione Contabile Scadenzario Pagamenti Gare Collaudi slide 15

16 Esempio processo: area produzione Scorte a Magazzino Ordini da Cliente Pianificazione Ordini di Lavoro interni Ordini di Lavoro esterni Consutivazione Lavor. interne Carico Lavor. esterne Previsioni di vendita Ordini di Acquisto Accettazione Materiali slide 16

17 Funzione e processi aziendali* Processo: un insieme di attività collegate tra loro, finalizzate al raggiungimento di un obiettivo di business. Non si tratta di semplice sequenza precostituita e preordinata di attività, ma di una sequenza flessibile dotata di senso e soprattutto di scopo. L efficienza del processo non deriva solo dall efficienza delle singole attività che lo costituiscono bensì anche dal coordinamento che esiste tra di esse. Funzione vs processo: mentre la funzione è composta da attività di ugual natura (es. tutte le attività amministrative o contabili), il processo è formato da attività che, seppur di diversa natura, sono finalizzate al raggiungimento dello stesso obiettivo. *Tratto da: Caporarello & Basaglia, 2008 slide 17

18 Funzione e processi aziendali* Si consideri il seguente esempio: Cliente Invio dell ordine Ricezione e controllo ordini Controlli Controlli di conformità materiale Funzione Vendite /Commerciale Controlli di tipo amministrativo Funzione Amministrativa Controlli di disponibilità Funzione Magazzini/Spedizioni *Tratto da: Caporarello & Basaglia, 2008 slide 18

19 I processi sono spesso invisibili Nonostante i processi di business siano centrali per l intera organizzazione, c è una scarsa consapevolezza della loro importanza e rilevanza per il successo del business. Spesso, infatti, i processi sono invisibili e gestiti in modo non appropriato. Tale gestione poco attenta può avere numerose conseguenze, tra le quali: i clienti ricevono un servizio incongruente, inadeguato i manager continuano a lottare per gestire le relazioni orizzontali tra le diverse parti (unità) dell organizzazione elevati costi x bassa qualità implementare una nuova applicazione (es. un sistema ERP) può rivelarsi estremamente difficile, a causa non di problemi tecnici bensì organizzativi slide 19

20 Analisi dei processi aziendali* Mettere in atto la logica per processi, significa definire: a) l identificazione e classificazione dei processi attivi in azienda, b) la scomposizione dei processi nelle operazioni elementari, c) l individuazione dei legami tecnico-temporale, d) l individuazione e l attribuzione delle responsabilità, e) i confini del processo, così da stabilire quali siano gli interlocutori a monte (fornitore interno/esterno) e a valle (cliente interno /esterno) i loro bisogni, aspettative, e disponibilità, f) coerenza tra efficienza economica del processo e obiettivi organizzativi, g) feedback per il controllo. *Tratto da: Caporarello & Basaglia, 2008 slide 20

21 Revisione dei processi aziendali* La revisione dei processi può essere di tre tipologie: in alcuni casi si procede ad una razionalizzazione del modo di operare ripensando, governando e controllando i processi aziendali (Business Process Management, BPM) articolo CWI: in altri casi si procede con un cambiamento incrementale attraverso il quale si realizzano interventi progressivi di miglioramento che sono volti ad aumentare i livelli di efficacia ed efficienza (Business Process Improvement, BPI) in altri casi, infine, si procede con un cambiamento radicale delle logiche e routine aziendali (Business Process Re-engineering, BPR), che consiste in un completo ripensamento e radicale riprogettazione dei processi di business per raggiungere miglioramenti in termini di performance critiche, come il costo, la qualità, il servizio e la velocità (es. disegnare le attività in parallelo anziché in sequenza; ricomporre le attività frammentate; eliminare le attività che non apportano valore) *Tratto da: Caporarello & Basaglia, 2008 slide 21

22 Il concetto di BPR slide 22

23 Il concetto di BPR Agli inizi degli anni 90 diversi studiosi si occuparono del concetto di Business Process Reengineering, tra i quali: Davenport & Short, 1990 Hammer, 1990 Hammer & Champy, 1993 Davenport, 1993 slide 23

24 Business process reengineering Con il termine BPR si fa riferimento ad un significativo ridisegno dei processi aziendali al fine di ottenere rilevanti miglioramenti della performance. Un BPR di successo richiede contestualmente, da una parte, il ridisegno dei processi di business e, dall altra, la ridefinizione delle applicazioni e delle infrastrutture IT nonché la definizione dei comportamenti organizzativi connessi all introduzione/uso dell IT. Paradosso: I vantaggi del BPR costituiscono molto spesso le principali minacce/ostacoli al suo successo. slide 24

25 Business process reengineering Il BPR è stato definito come un importante attività di ripensamento e redesign radicale dei processi aziendali, con l obiettivo di raggiungere significativi miglioramenti in termini di performance aziendali, quali costi, qualità, servizi e velocità (Hammer & Champy, 1993). slide 25

26 Componenti di un BPR Processi di business Organizzazione BPR Change management Struttura organizzativa Information Technology slide 26

27 BPR: aspettative I primi ricercatori ad occuparsi di BPR (Harrington, 1991; Davenport, 1993; Hammer & Champy, 1993) ritenevano che si trattava di un fenomeno di rottura che avrebbe permesso il miglioramento delle performance dell organizzazione mediante il cambiamento/miglioramento dei processi. Tuttavia, i primi risultati non confermarono tali aspettative (Davenport, 1993; Hammer & Champy, 1993; Kotter, 1995; Bergey et al., 1999). slide 27

28 Il ruolo dell IT Le prime applicazioni dell IT erano orientate ad automatizzare alcune attività aziendali con l obiettivo di velocizzare e migliorare l accuratezza e la qualità del lavoro. Le organizzazioni che intendono rivisitare i loro processi, devono considerare l IT come un fattore abilitante del cambiamento di tale processo di cambiamento e non solo come uno strumento di automazione. Un errore ricorrente in molte organizzazioni, infatti, è che esse valutano l IT sulla base dei loro attuali processi (es. come posso utilizzare l IT per migliorare le nostre attuali attività? ) (Hammer & Champy, 1993). Dall altra parte, l IT è un fattore tipicamente necessario ma non è sufficiente per un attività di redefinizione dei processi aziendali di successo. slide 28

29 Fallimento del BPR: motivazioni Bergey et al (1999) individuarono alcuni motivi di tali insuccessi, tra i quali: l uso di una strategia di BPR imperfetta, il personale fortemente conservativo nell uso delle nuove tecnologie, scarsi investimenti in formazione, l uso di sistemi legacy non allineati con le nuove esigenze, l uso di architetture IT non allineate correttamente con gli obiettivi del BPR, i team manageriali inflessibili, la mancanza di commitment di lungo periodo. slide 29

30 Gestire il cambiamento Cambiamento significa l alterazione di uno stato in un altro. Il cambiamento organizzativo spesso comprende cambiamenti di attività, strutture, persone, cultura può necessitare di cambiamenti relativi alle attitudini dei membri dell organizzazione, dei loro comportamenti. slide 30

31 Gestire il cambiamento : le forze clienti concorrenti internazionalizzazione cambiamento organizzazione ambiente interno velocità flessibilità qualità servizi costi slide 31

32 Gestire il cambiamento : due dimensioni di analisi Due dimensioni possono essere usate per descrivere il cambiamento organizzativo: lo stimolo al cambiamento e lo scopo al cambiamento. Lo stimolo al cambiamento può venire sia dall interno sia dall esterno dell organizzazione. Il cambiamento motivato (stimolato) dall interno fa riferimento alle attività e ai processi definiti allo scopo di apportare cambiamenti in termini di: persone/gruppi di persone, struttura organizzativa, processi. Il cambiamento motivato dall esterno fa riferimento alle modifiche a livello di organizzazione, o di parti di essa, al fine di adeguarla all ambiente in cui opera. Lo scopo del cambiamento è riferito all ampiezza del cambiamento stesso. Attività di cambiamento che hanno un ampio scopo tipicamente richiedono un lungo orizzonte temporale di attuazione. slide 32

33 Gestire il cambiamento : azioni prescrittive La gestione del cambiamento può essere spiegata mediante teorie del cambiamento evolutive o rivoluzionarie. Le prime propongono un cambiamento incrementale o graduale; le seconde, invece, un cambiamento radicale, discontinuo (Gersick, 1991). I due approcci presentano sia degli elementi in comune sia degli elementi distintivi. Tra i primi: entrambi sostengono che il Top management ha un ruolo fondamentale in un qualunque processo di cambiamento organizzativo. Tra i secondi: i modelli evolutivi promuovono la partecipazione dei process owner nell attività di ridisegno; i modelli rivoluzionari, invece, sostengono la creazione di un nuovo team di gestione. slide 33

34 I sistemi informativi integrati slide 34

35 Caratteristiche organizzative, tecnologia ed obiettivi aziendali La tecnologia può intendersi come un importante strumento a supporto dei processi di gestione dell incertezza e del rischio. Il ruolo aziendale delle tecnologie dell informazione e comunicazione (di seguito chiamate ICT) è di facilitare, supportare e moderare la relazione tra le caratteristiche organizzative e gli obiettivi aziendali. La forte relazione tra l ICT e gli obiettivi aziendali rende necessario rivalutare continuamente il ruolo dell ICT in azienda. Caratteristiche Organizzative Struttura Dimensione Formazione Cultura Relazioni interorganizzative Tecnologie dell informazione e comunicazione efficienza informativa sinergie informative Obiettivi aziendali Abilitare le relazioni tra dipendenti Codificare la conoscenza organizzativa Espandere i confini organizzativi Aumentare l efficienza organizzativa Collaborare e coordinare come fattori di supporto all innovazione slide 35

36 Applicazioni software: implicazioni tecniche e manageriali Nel 1996 molte aziende statunitensi hanno avviato progetti di implementazione di applicazioni software per un valore di circa 275 miliardi di dollari. Il 53% di tali progetti non ebbe successo. Le cause non sono state di natura tecnica (software sviluppato male) bensì di natura organizzativa e manageriale. Umble (2002) ha condotto nel 2001 una ricerca nella quale il 73% dei rispondenti ha indicato la mancanza di supporto da parte del top management come uno dei principali motivi di fallimento dei progetti ERP. Il successo dell adozione di un sistema ERP dipende da variabili più di natura manageriale ed organizzativa che di natura tecnica (Willcocks e Margetts, 1994). Tuttavia anche gli aspetti tecnici hanno il loro ruolo per abilitare o inibire il successo di questo tipo di progetti. Si pensi ad esempio alle problematiche legate all eterogeneità dei sistemi informativi presenti in azienda. In questo contesto sono apparsi, a partire dagli anni 60, i primi sistemi informativi integrati. I sistemi informativi integrati hanno l obiettivo di integrare processi e funzioni aziendali, fornendo una visione integrata e complessiva della gestione aziendale secondo un approccio olistico fondato sulle informazioni e sull architettura ICT. slide 36

37 I sistemi ERP: definizioni* Razionalizzando le diverse definizioni, i sistemi ERP rappresentano delle soluzioni applicative standard parametrizzabili, personalizzabili e basate su una solida infrastruttura tecnologica in grado di mettere in relazione i processi aziendali con i dati e, quindi, di integrare le diverse funzioni o unità organizzative (Caporarello & Basaglia, 2008). Con il termine parametrizzazione, sinonimo di customizzazione, si intende l attività di inserimento dei parametri in grado di far funzionare le procedure secondo l alternativa prescelta; in altri termini, la parametrizzazione consiste nel processo di adattamento del sistema alle specifiche esigenze aziendali. Con il termine personalizzazione si intende la modifica delle procedure software che compongono il sistema ERP, intervenendo con la realizzazione di specifici programmi. *Tratto da: Caporarello & Basaglia, 2008 slide 37

38 I sistemi ERP: rappresentazione concettuale* Back-Office Back-Office Reportistica aziendale Front-Office Front-Office Fornitori Amministrazione e controllo Produzione Base dati centrale Vendite e distribuzione Servizio post-vendita Clienti Magazzino Gestione risorse umane *Tratto da: Caporarello & Basaglia, 2008 slide 38

39 I sistemi ERP: caratteristiche* Ad un livello generale, i sistemi ERP rientrano nella categoria delle applicazioni software, in particolare delle applicazioni software aziendali. Ad un livello di analisi più specifico, i sistemi ERP sono costituiti da moduli applicativi integrati, ciò significa che pur essendo moduli software distinti, essi sono in grado di dialogare tra loro come se fossero un unica applicazione. La logica sottostante al loro modo di operare è basata sul concetto di processo. I sistemi ERP sono basati su una base dati integrata che immagazzina tutti i dati in modo consistente e opportunamente ridondati. Oltre alla tipica documentazione che accompagna i software applicativi, nel caso dei sistemi ERP è necessario documentare, ad esempio: i processi che esso supporta, le strutture organizzative su cui è basato, la struttura e i modelli di dati di riferimento. *Tratto da: Caporarello & Basaglia, 2008 slide 39

40 I sistemi ERP: caratteristiche* I sistemi ERP sono cross-industry, ovvero intendono rispondere alle esigenze di diversi settori economici. Inoltre, i sistemi ERP sono cross-country, ovvero intendono rispondere alle specifiche esigenze (normative, finanziarie e così via) dei vari contesti nazionali. Dal punto di vista tecnico, i sistemi ERP sono caratterizzati, oltre che dall integrazione applicativa e dei dati, da un avanzata interfaccia utente grafica (detta GUI, graphical user interface) uniforme per tutte le funzioni o moduli applicativi. In termini architetturali, tali sistemi sono generalmente basati su architetture client-server strutturate tipicamente in tre livelli logicamente indipendenti: database, applicativo, di presentazione Quanto al sistema operativo sottostante, oggigiorno ci sono sistemi ERP crossoperating system, cioè in grado di funzionare sia in ambienti Microsoft sia Unix o Unix-like. Infine è necessario un appropriato processo di amministrazione del sistema, in termini di gestione degli utenti, del database, di monitoring e valutazione delle prestazioni, di gestione degli aggiornamenti software. *Tratto da: Caporarello & Basaglia, 2008 slide 40

41 I sistemi ERP: architettura* Livello di presentazione Computer client Livello applicativo Application server Livello dati Database server *Tratto da: Caporarello & Basaglia, 2008 slide 41

42 I sistemi ERP: vantaggi e svantaggi Secondo Davenport (1998) i sistemi ERP sono disegnati per risolvere la frammentazione delle informazioni e ad integrare i flussi informativi aziendali. Tra i principali vantaggi: 1. risolvere i problemi derivanti dall utilizzo di sistemi legacy, ovvero di quei sistemi, basati su tecnologie non recenti, che offrono specifiche funzionalità, non ancora offerte da sistemi più aggiornati 2. contribuire a ridurre il rischio aziendale 3. incrementare la competitività globale 4. incrementare l efficienza aziendale Tra i principali svantaggi: 1. conflitti con la strategia aziendale e resistenza al cambiamento integrazione con i sistemi esistenti 2. richiesta di extra budget rispetto a quanto stimato inizialmente 3. ritardo nei tempi di progetto slide 42

43 I sistemi ERP: framework di adozione (Caporarello & Basaglia, 2008) obiettivi strategia implementazione team di progetto budget di progetto benefici attesi relazione con i fornitori Preparazione progetto Implementazione e cambiamento disegno as-is e to-be implementazione sistema inizio attività di formazione disponibilità del sistema gestione del cambiamento attività di test produzione integrazione ICT a livello globale completata uso del sistema come abitudine consolidata degli utenti l azienda cerca nuove innovazioni per aumentare la competitività Uso avanzato ADOZIONE ERP Accettazione Uso normale utilizzo del sistema nelle attività ordinarie degli utenti manutenzione evolutiva integrazione organizzativa completata monitoraggio del coordinamento funzionale interno e dei vantaggi attesi post-produzione ulteriore attività di formazione supporto utente correzioni errori o malfunzionamenti slide 43

44 C è relazione tra BPR e ERP? slide 44

45 Relazione BPR e ERP Processi di business Struttura organizzativa ERP BPR Organizzazione Change management Information Technology slide 45

46 Prima BPR o ERP? E meglio verificare/ridefinire i processi di business prima di implementare un sistema integrato oppure è meglio prima implementare un sistema ERP e poi adeguare i processi di business alle best practice suggerite dall ERP stesso? slide 46

47 BPR e ERP Ci sono numerose evidenze del fatto che implementazioni di BPR che hanno avuto successo non siano state seguite da miglioramenti dell organizzazione in termini di performance finanziarie (Grint, 1994). Questo perchè le performance finanziarie sono legate ad altri fattori, quali: i concorrenti, l ambiente, la tecnologia, i mercati finanziari. slide 47

48 Un modello di BPR slide 48

49 Modello di BPR Clark et al. (1997) hanno proposto un modello di BPR composto da cinque componenti. A tale modello hanno poi contribuito altri studiosi del tema proponendo il modello di seguito presentato (Broadbent et al., 1999; Davenport & Stoddard, 1994; Harkness et al., 1996; Kettinger et al., 1997; Nissen, 1998; Paper, 1998a, 1999, 2001). Esso è composto da cinque componenti interdipendenti: Environment (E), People (P), Methodology (M), IT perspective (I), Transformation vision (T). E M T P I slide 49

50 Modello di BPR: Environment La prima componente del modello, Environment, include (Amabile, 1997; Clark et al., 1997; Lynn, 1998; O toole, 1999): il supporto del top-management, la propensione al rischio, l apprendimento organizzativo, il gioco di squadra, i sistemi di incentivazione e di ricompensa, la condivisione delle informazioni e delle risorse. L innovazione può venire da qualunque livello organizzativo, ma i cambiamenti ambientali prendono le mosse dal top (Cooper & Markus, 1995; Paper, 1999). E slide 50

51 Modello di BPR: People Il successo di un attività di cambiamento dipende dalle persone e dalla loro conoscenza, creatività e apertura al cambiamento (Cooper & Markus, 1995). Tra i fattori di successo, in termini di people, vi sono: la formazione, l avere a che fare con attività sfidanti, il lavoro in squadra, la responsabilizzazione (Paper & Dickinson, 1997). E P slide 51

52 Modello di BPR: Methodology La metodologia è un elemento critico nella gestione di un cambiamento (Davenport & Short, 1990; Guha et al., 1993; Talwar, 1993; Kim, 1996; Kettinger et al., 1997; Paper & Dickinson, 1997; Paper, 1998a; Teng et al., 1998). La metodologia consente, a tutti gli attori coinvolti (team interfunzionali, facilitatori, manager), un allineamento continuo in quanto li informa sullo stato di avanzamento del progetto (Paper & Dickinson, 1997). Ciò permette alle persone di rimanere focalizzate sulle attività di propria competenza, riducendo al minimo le dispersioni. E P M slide 52

53 Modello di BPR: Methodology La metodologia incorpora sia un approccio top-down sia bottom-up. Una visione (cioè un cambiamento) ha origine al livello più alto (top) ma l attività di definizione del processo può essere fatta da coloro i quali eseguono l attività (Davenport & Stoddard, 1994). La metodologia è quindi un attività congiunta tra il top management, il middle management e coloro che sono impegnati nelle attività operative (Paper & Dickinson, 1997). I fattori di successo in termini di metodologia, includono: principi guida appropriati, direzione/indirizzamento, monitoraggio continuo, mappa grafica dei processi, supporto ai clienti. E P M slide 53

54 Modello di BPR: IT perspective La prospettiva IT, nell ambito del BPR, assume un ruolo critico: l implementazione dell IT è un intervento organizzativo (Markus & Benjamin, 1996) ed è integrante per il successo del redisegno di un business process (Broadbent et al., 1999). I fattori di successo, in termini IT, includono: conoscenza IT, architettura IT, cultura dell IT. E P M I slide 54

55 Modello di BPR: Transformation vision Il quinto elemento, la visione della trasformazione/cambiamento, consiste nella comunicazione della filosofia di fondo del BPR all intera organizzazione attraverso: a) la divulgazione degli obiettivi strategici verso tutti i livelli organizzativi b) l allineamento del progetto di BPR con gli obiettivi di business (Harkness et al., 1996; Paper & Dickinson, 1997). Il cambiamento culturale è la sfida più difficile per il BPR (Caron et al., 1994). E M T P I slide 55

56 Modello di BPR: Transformation vision Il top management dovrebbe trasmettere la visione ai principali stakeholder (management, azionisti, employee ) prima che il cambiamento venga messo in atto (Beer et al., 1990; Clark et al., 1997; Winklhofer, 2002). Il cambiamento può comportare l accadere di eventi che non è possibile prevedere in anticipo. Orlikowski e Hofman (1997) sostengono che la visione dovrebbe tenere in considerazione sia i cambiamenti anticipabili sia quelli non anticipabili. Da questo ne consegue la necessità di flessibilità da parte del management per la gestione anche degli eventi non anticipabili. I fattori di successo, in termini di vision, includono: lo sviluppo della vision, la comunicazione della vision, impiego della vision e flessibilità della vision. E M T P I slide 56

57 Implementazione sistema ERP slide 57

58 Fasi tipiche del processo di implementazione di un sistema ERP* Ogni progetto di adozione di un sistema ERP si compone di alcune fasi tipiche che, coerentemente con il framework di adozione, sono: a) fasi sequenziali a1) preparazione del progetto a2) disegno dell as-is a3) disegno del to-be a2) implementazione a3) test Preparazione del progetto Disegno As-is Disegno To-be Implementazione Test Produzione b) fasi continue a4) produzione b1) gestione del progetto Gestione del progetto Gestione del cambiamento Supporto Tecnico e Infrastrutturale b2) supporto tecnico-infrastrutturale b3) gestione del cambiamento *Tratto da: Caporarello & Basaglia, 2008 slide 58

59 Fasi tipiche: a1) preparazione del progetto A questo stadio del processo decisionale, l azienda adottante ha scelto il sistema ERP, mentre deve ancora scegliere il partner che implementerà il sistema. La fase di preparazione del progetto consiste nella definizione: a) degli obiettivi b) della strategia di implementazione c) del team di progetto d) del budget di progetto e) dei benefici attesi f) della relazione con i fornitori Preparazione del progetto Disegno As-is Disegno To-be Implementazione Test Produzione Gestione del progetto Gestione del cambiamento Supporto Tecnico e Infrastrutturale slide 59

60 Fasi tipiche: a2) disegno As-is Il contenuto di questa fase riguarda la definizione del modello attuale dei processi e della struttura organizzativa aziendale. L obiettivo è la definizione delle caratteristiche di funzionamento attuali dell azienda. Il disegno dell As-is dovrebbe essere già stato definito per poter scegliere il sistema ERP e il partner implementatore. E ora importante formalizzare e comunicare a tutto il team di progetto alcune peculiarità aziendali che dovranno essere considerate nel corso della fase di implementazione. Preparazione del progetto Disegno As-is Disegno To-be Implementazione Test Produzione Gestione del progetto Gestione del cambiamento Supporto Tecnico e Infrastrutturale slide 60

61 Fasi tipiche: a3) disegno To-be Il contenuto di questa fase consiste nella definizione e formalizzazione, rispetto al futuro, della formula imprenditoriale aziendale, dell insieme delle combinazioni prodotto/mercato/tecnologia, del modello organizzativo, dei processi e delle attività aziendali. Gli elementi di cambiamento noti e desiderati devono essere stati definiti in anticipo rispetto alla partenza del progetto. Quello che deve avvenire in questa fase è che tali elementi di contesto futuro vengano raccolti e formalizzati, così da guidare in modo esplicito e condiviso il percorso di implementazione Preparazione del progetto Disegno As-is Disegno To-be Implementazione Test Produzione Gestione del progetto Gestione del cambiamento Supporto Tecnico e Infrastrutturale slide 61

62 Fasi tipiche: a4) implementazione Il contenuto di questa fase consiste: nella configurazione e nella parametrizzazione delle funzionalità del sistema ERP secondo il modello dei processi To-be, nella definizione del modello dei dati aziendali e delle specifiche tecniche per l attività di migrazione dei dati, nella definizione dei profili di accesso alle funzionalità e ai dati Preparazione del progetto Disegno As-is Disegno To-be Implementazione Test Produzione Gestione del progetto Gestione del cambiamento Supporto Tecnico e Infrastrutturale slide 62

63 Fasi tipiche: a5) test Il contenuto di questa fase riguarda il test di funzionamento del sistema ERP e delle interfacce con tutti i sottosistemi (come ad esempio le applicazioni legacy) che continueranno a funzionare in futuro. Alcune caratteristiche dei test sono: ampiezza interfunzionalità documentazione di test ruolo degli utenti nel test coerenza delle fasi di test con quanto previsto nel contratto Preparazione del progetto Disegno As-is Disegno To-be Implementazione Test Produzione Gestione del progetto Gestione del cambiamento Supporto Tecnico e Infrastrutturale slide 63

64 Fasi tipiche: a6) produzione Il contenuto di questa fase comprende: la migrazione dei dati (si tratta di un attività molto onerosa e delicata, dal momento che eventuali errori nelle basi dati si potrebbero ripercuotere su tutte le attività di elaborazione e potrebbero condurre quindi ad anomalie, o errori gravi, nei risultati e nei report ad essi collegati) la verifica finale delle interfacce la formalizzazione della documentazione utente la formazione e l attività conclusiva di entrata in esercizio del nuovo sistema Preparazione del progetto Disegno As-is Disegno To-be Implementazione Test Produzione Gestione del progetto Gestione del cambiamento Supporto Tecnico e Infrastrutturale slide 64

65 Fasi tipiche: b1) gestione del progetto e b2) supporto tecnico e infrastrutturale Il supporto tecnico-infrastrutturale, che tipicamente riguarda le attività di gestione delle infrastrutture hardware e software per il supporto al progetto, non viene approfondito in modo specifico, così come l attività di gestione del progetto, per la quale si rimanda alle tecniche di project management. Preparazione del progetto Disegno As-is Disegno To-be Implementazione Test Produzione Gestione del progetto Gestione del cambiamento Supporto Tecnico e Infrastrutturale slide 65

66 Fasi tipiche: b3) gestione del cambiamento L attività di gestione del cambiamento inizia fin dalle prime fasi del progetto di adozione, ma entra nel merito di dettaglio solo nelle fasi conclusive. La gestione del cambiamento è un attività di tipo trasversale all interno del progetto di adozione di un sistema ERP. Essa comprende due grandi gruppi di attività: quelle volte ad assicurare sintonia tra il progetto e l azienda, attraverso azioni di comunicazione, training e adeguamento organizzativo, quelle volte ad assicurare il buon funzionamento del team di progetto Preparazione del progetto Disegno As-is Disegno To-be Implementazione Test Produzione Gestione del progetto Gestione del cambiamento Supporto Tecnico e Infrastrutturale slide 66

67 Conclusione progetto e post-produzione Dopo la partenza del sistema ERP, il team di progetto deve ancora svolgere una serie di attività, quali: attività previste per il go-live e rinviate per agevolare la partenza correzione di anomalie e di malfunzionamenti supporto utente richieste di modifica Come gestire tali attività? E importante aver definito fin dall inizio, a livello di contratto, la modalità di gestione economica delle differenti tipologie di attività e in particolare: attività comprese nel corrispettivo per l implementazione, attività comprese nel corrispettivo per l implementazione se all interno del periodo di garanzia, attività comprese nel budget per la fase di post-produzione, attività da valorizzare in modo specifico slide 67

68 Metodologia BPR slide 68

69 Metodologia BPR: Griglia FASI 1. Rilevazione situazione attuale 2. Diagnosi e confronto 3. Riprogettazione Flussi di attività VARIABILI Struttura aziendale Risorse umane Misurazione delle prestazioni slide 69

70 Due casi di BPR * Hewlett Packard IBM Credit Corp *Tratti da: Hammer, M., Champy, J. (1994) Ripensare l azienda, Milano: Sperling & Kupfer slide 70

71 Due casi di BPR: HP Nell approvvigionamento dei materiali, come del resto nella maggior parte delle sue attività, la Hewlett-Packard adottava un sistema fortemente decentrato; essa concedeva infatti alle sue divisioni operative un autonomia quasi totale in fatto di acquisti, considerando che queste conoscessero meglio di chiunque altro le proprie necessità. Ma i vantaggi del decentramento (flessibilità, personalizzazione, prontezza decisionale) hanno una contropartita, individuabile in perdita delle economie di scala e ridotta possibilità di controllo. Alla H.P., per esempio, il decentramento degli acquisti impediva all azienda di usufruire di forti sconti che i fornitori concedevano per grossi ordinativi, cosa che si traduceva in una perdita stimata in milioni di dollari l anno. Quale soluzione potrebbe aver adottato l HP? slide 71

72 Due casi di BPR: HP La H.P. decise allora di adottare un sistema comune per la gestione degli acquisti. Con questo approccio, ciascuna divisione produttiva continua ad ordinare i componenti di cui ha bisogno, ma i vari uffici acquisti utilizzano un sistema d approvvigionamento standard; questi sistemi forniscono i dati a un nuovo database gestito da un ufficio approvvigionamenti centrale, il quale negozia con i fornitori i contratti globali con sconti per grandi volumi. L ufficio centrale è in grado di farlo perché il database gli fornisce informazioni complete sugli acquisti programmati ed effettuati dalle divisioni. Una volta conclusi i contratti, i funzionari dei vari uffici acquisti interrogano il database per individuare i fornitori approvati e piazzare gli ordini. Il nuovo processo garantisce contemporaneamente alla H.P. il meglio dell accentramento - gli sconti per grandi ordinativi - e del decentramento - il soddisfacimento delle esigenze locali. slide 72

73 Due casi di BPR: IBM Credit Corp La IBM Credit Corporation, società del gruppo IBM che finanzia l acquisto dei computer, del software e dei servizi venduti dalla IBM, ha recentemente realizzato un importante progetto di reenginering del suo processo di vendita. In precedenza, quando un rappresentante commerciale della IBM telefonava per una richiesta di finanziamento, si innescava un processo articolato su 5 fasi: 1. dall altro capo del filo gli rispondeva una delle 14 persone che lavoravano nella sede centrale della società a Old Greenwich, nel Connecticut, che annotava la richiesta su un foglio di carta; 2. la nota era inoltrata all ufficio crediti (sito al piano superiore) dove uno specialista inseriva nel sistema informativo la richiesta e verificava il fido concedibile al cliente. Annotava l esito della verifica su carta ed inviava la risposta all ufficio pratiche commerciali; slide 73

74 Due casi di BPR: IBM Credit Corp 3. questo ufficio poteva modificare le condizioni standard di finanziamento in funzione della specifica richiesta del cliente. Tale attività era svolta con l ausilio di un supporto decisionale che risiedeva su un ambiente informatico diverso dal precedente. Una volta definite, le modifiche venivano allegate al modulo della richiesta e quindi inoltrate al prezzista; 4. il prezzista inseriva i dati in un personal computer per calcolare il tasso di interesse da applicare al cliente. Questo dato veniva annotato sulla pratica e quest ultima veniva inviata ad un altro ufficio dove operavano 5 impiegati; 5. un impiegato elaborava l intera pratica e approntava la lettera di offerta che poteva essere inviata al rappresentante tramite la Federal Express. slide 74

75 Due casi di BPR: IBM Credit Corp L intero processo richiedeva in media 6 giorni che potevano diventare anche 15 a fronte di un tempo tecnico, necessario per svolgere tutte le attività, di 90 minuti. La lentezza del processo portava spesso alla perdita del cliente da parte della IBM Credit (il cliente si rivolgeva ad altre società di servizi finanziari) e, nel caso peggiore, anche alla perdita del cliente per la stessa IBM (il cliente acquistava il computer da un concorrente). slide 75

76 Due casi di BPR: IBM Credit Corp Possibili approcci alla soluzione del problema: 1. (approccio tradizionale) Costituire un tavolo di controllo in cui era presente una persona in grado di fornire una risposta al rappresentante (a che punto era la pratica?) 2. (approccio innovativo) slide 76

77 Due casi di BPR: IBM Credit Corp 2. (approccio innovativo) La IBM Credit ha sostituito gli specialisti (verificatori, prezzisti, ecc...) con esperti generici (deal structurer) che seguono la pratica dall inizio alla fine. Solamente per i casi in cui la richiesta era particolarmente complessa (poche eccezioni) si faceva nuovamente ricorso agli specialisti. La soluzione è stata resa possibile dall adozione di un sistema informativo che metteva a disposizione di tutti i deal structurer una base dati contenente tutte le informazioni utilizzate dagli specialisti. Con questa soluzione il lead time del processo è passato da 6 giorni a 4 ore. slide 77

78 Lessons learned slide 78

79 Lessons learned slide 79

80 Lessons learned 1. la tecnologia dovrebbe essere considerata come uno strumento facilitatore e non come uno strumento di problem-solving. Le organizzazioni dovrebbero disegnare una mappa dei loro attuali processi di business al fine di determinare le loro necessità e priorità in termini di investimenti in soluzioni IT. 2. l analisi dei processi è fondamentale per un attività di miglioramento degli stessi. Nonostante tale attività possa essere rigorosa e timeconsuming, le organizzazioni ne traggono grandi benefici al fine di sapere come e se i loro processi operano correttamente per l erogazione del prodotto/servizio finale. 3. iniziative di cambiamento devono prendere le mosse dal top management (soprattutto se riguardano l intera organizzazione). slide 80

81 Lessons learned 4. un attenta analisi degli obiettivi di business e dei cambiamenti di processo deve essere condotta prima dell implementazione e dell acquisto di un software. 5. un efficace ridisegno dei processi richiede un coinvolgimento attivo dei lavoratori operativi (soprattutto di coloro maggiormente impegnati nelle attività operative) e dei manager. 6. la comunicazione tra i vari livelli organizzativi può essere elemento di continuità/discontinuità tra la vision del BPR e la sua implementazione. 7. gli obiettivi di business e quelli dell IT devono essere allineati, così come entrambi devono essere allineati con gli obiettivi del BPR. 8. a volte i manager hanno una scarsa esperienza con BPR e/o enterprise system (ERP). La formazione e il coinvolgimento delle persone giuste nei giusti gruppi di lavoro rappresentano dei fattori critici di successo del BPR. slide 81

82 Riferimenti bibliografici slide 82

83 Riferimenti bibliografici Albizu, E., Olazaran, M., Simona, K. (2004), BPR and change management: a case study of a large spanish electricity company. International Journal of innovation management, 8(4), pp Amabile, T. M. (1997), Motivating creativity in organizations: on doing what you love and loving what you do, California Management Review, 40(1), pp Beer, M., Eisenstat, R. A. & Spector, B. (1990) Why change programs don t produce change, Harvard Business Review, 68(6), pp Bergey, J., Smith, D., Tiley, S., Weiderman, N. & Woods, S. (1999), Why reengineering projects fail, Carnegie Mellon Software Engineering Institute Product Line Practice Initiative, 1, pp Bracchi, G., Motta G. (1997), Processi aziendali e Sistemi informativi. Milano: Franco Angeli Broadbent, M., Weill, P. & St. Claire, D. (1999), The implications of information technology infrastructure for business process redesign, MIS Quarterly, 23(2), pp Caporarello, L., Basaglia, S. (a cura di) (2008) I sistemi ERP. Un innovazione tecnologica ed organizzativa, Milano, Egea Caron, J. R., Jarvenpaa, S. L. & Stoddard, D. B. (1994) Business reengineering at CIGNA Corporation: experiences and lessons learned from the first five years, MIS Quarterly, 18(3), pp Clark, C. E., Cavanaugh, N. C., Brown, C. V. & Sambamurthy, V. (1997), Building change-readiness capabilities in the IS organization: insights from the Bell Atlantic experience, MIS Quarterly, 21(4), pp Cooper, R. & Markus, M. L. (1995), Human reengineering, Sloan Management Review, 36(4), pp slide 83

84 Riferimenti bibliografici Davenport, T. (1993), Process Innovation: Reengineering Work Through Information Technology, Boston, MA: Harvard Business School Press, p. 4 Davenport, T. H. & Short, J. E. (1990), The new industrial engineering: information technology and business process redesign, Sloan Management Review, 31(4), pp Davenport, T. H. & Stoddard, D. B. (1994), Reengineering: business change of mythic proportions?, MIS Quarterly, 18(2), pp De Marco, M. (1988), Teaching Information Systems, in Proceedings of the European Conference on Information Systems (ECIS 1988), Aix-en-Provence De Marco, M., Bruschi, G., Manna, E., Giustiniani, G. e Rossignoli, C. (1988), L organizzazione dei sistemi informativi aziendali, Bologna: Il Mulino Galbraith, J.R., (1977), Organization Design, Massachusetts: Addison-Wesley Gersick, C. (1991), Revolutionary Change Theories: A Multilevel Exploration of the Punctuated Equilibrium Paradigm, Academy of Management Review, 16, 1, pp Grint, K. (1994), Reengineering history: Social resonances and business process reengineering, Organization, 1, pp Guha, S., Kettinger, W. J. & Teng, J. T. C. (1993), Business process reengineering: building a comprehensive methodology, Information Systems Management, 10(3), pp Hammer, M. (1990), Re-engineering work: Don t automate, obliterate. Harvard Business Review, July August, pp Hammer, M. and J. Champy (1993), Reengineering the Corporation, NY: HarperCollins Books, p. 31 slide 84

85 Riferimenti bibliografici Harkness, W. L., Kettinger, W. J. & Segars, A. H. (1996), Sustaining process improvement and innovation in the information services function: lessons learned at the Bose Corporation, MIS Quarterly, 20(3), pp Harrington, H. J. (1991), Business Process Improvement: the Breakthrough Strategy for Total Quality, Productivity, and Competitiveness, New York: McGraw-Hill Kettinger,W. J., Teng, J. T. C. & Guha, S. (1997), Business process change: a study of methodologies, techniques, and tools, MIS Quarterly, 21(1), pp Kim, C. (1996), A comprehensive methodology for business process reengineering, Journal of Computer Information Systems, Fall, pp Kotter, J. P. (1995), Leading change: why transformation efforts fail, Harvard Business Review. March April, pp Lynn, G. S. (1998), New product team learning: developing and profiting from your knowledge capital, California Management Review, 40(4), pp Markus, M. L. & Benjamin, R. I. (1996), Change agentry the next IS frontier, MIS Quarterly, 20(4), pp Mintzberg, H. (1979), The Structuring of Organization, Englewood Cliffs, NJ: Prentice Hall Nissen, M. E. (1998), Redesigning reengineering through measurement-driven inference, MIS Quarterly, 22(2), pp O toole, J. (1999), Lead change effectively, Executive Excellence, 16(4), pp Orlikowski, W. J. &Hofman, J. D. (1997) An improvisational model for change management, Sloan Management Review, 38(2), pp slide 85

86 Riferimenti bibliografici Paper, D. & Dickinson, S. (1997), A comprehensive process improvement methodology: experiences at Caterpillar s Mossville engine center, in: M. Khosrowpour & J. Liebowitz (Eds) Cases on Information Technology Management in Modern Organizations, Chapter 9 (Hershey, PA: Idea Group Publishing) Paper, D. (1998a), BPR: creating the conditions for success, Long Range Planning, 31(3), pp Paper, D. (1999), The enterprise transformation paradigm: the case of Honeywell s industrial automation and control unit, Journal of Information Technology Cases and Applications, 1(1), pp Paper, D. (2001), Managing radical transformation: a holistic paradigm, in: 2nd Annual GITM World Conference, June 10 12, Dallas, TX Talwar, R. (1993), Business re-engineering a strategy-driven approach, Long Range Planning, 26(6), pp Teng, T. C., Jeong, S. R. & Grover, V. (1998), Profiling successful reengineering projects, Communications of the ACM, 41(6), pp Umble, E.J., Umble M.M. (2002). Avoiding ERP Implementation Failure. Industrial Management, 44(1): 25 Willcocks, L.P., Margets, H. (1994). Risk Assessment and Information systems, European Journal of Information Systems, 3(2), pp Winklhofer, H. (2002) Information systems project management during organizational change, Engineering Management Journal, 14(2), pp slide 86

87 Allegato 1: Fattori critici di successo implementazione ERP* Supporto da parte sia del top management sia dell azienda Progetti di successo di riferimento Gestione del cambiamento Ridefinizione dei processi aziendali Formazione sui nuovi processi aziendali Cultura organizzativa Pianificazione strategica aziendale Pianificazione strategica dell IT Opportuni sistemi di raccordo tra l ICT e il resto dell azienda Attività di comunicazione Steering committee Cooperazione interorganizzativa Aumento del grado di autonomia dei decisori Project management Piano di progetto formalizzato Gestione delle aspettative Composizione del team del progetto ERP Definizione dell architettura IT Analisi dei dati e conversione Precisione e accuratezza dei dati Attenta selezione della soluzione applicativa Strategia di implementazione Sviluppo software, test e risoluzione di problemi Formazione utenti Risorse dedicate Bassa customizzazione Coinvolgimento di consulenti Coinvolgimento degli utenti aziendali Grado di fiducia tra i partner di progetto Controllo e valutazione delle prestazioni Supporto da parte dei fornitori Compatibilità tra software e hardware Configurazione del software Versione della soluzione applicativa *Tratto da: Caporarello & Basaglia, 2008 slide 87