ERP E COMPLESSITA' AZIENDALE - PERCHÉ E COME ADOTTARE LE TECNOLOGIE ERP Perugia - Confindustria Umbria
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
ERP E COMPLESSITA’
AZIENDALE
PERCHÉ E COME ADOTTARE
LE TECNOLOGIE ERP
Perugia
9 maggio 2019
Severino Meregalli
severino.meregalli@sdabocconi.it
1
Il contesto: la complessità aziendale • Dinamismo e complessità come elementi strutturali • Scenari non definibili a priori • Nuove forme d’impresa: aziende virtuali e senza confini • Crollo del mito della pianificazione come antidoto alla complessità • Molteplicità degli attori coinvolti (es. shareholders, stakeholders, globalizzazione. . . ) • Management non pronto a definire requirement e a descrivere operativamente le scelte “forti” • Economia digitale (IT come fattore produttivo) • Digital transformation
Gestire la complessità: approcci a confronto
• Evitare
• La nicchia semplice
• Ridurre
• Adozione di luoghi comuni e decisioni di «semplificazione»
• Prassi di imitazione e confronto
• Governare
• Discriminare fra «bad» e «good» complexity (Wilson, Perumal, 2009)
• Fare leva sulle proprie dimensioni di complessità
• Adottare la strumentazione necessaria
• La generazione di valore e di reddito sembra essere molto collegata con la
capacità di governare e non di ridurre o di evitare la complessità
• Anche «evitare» può generare reddito, ma non su un lungo periodo
3
Il contributo dell’ICT e del sistema di offerta
• Le tecnologie ICT sono uno dei principali strumenti utilizzati per gestire la complessità.
Nel tempo alcune tecnologie hanno abilitato passaggi epocali nella capacità di gestire la
complessità (reti geografiche, sistemi ERP, tecnologie on-demand)
• Oggi la risposta alla complessità consiste nel rendere fruibile alle aziende tutto l’insieme
delle tecnologie all’interno di una architettura di offerta orchestrata e accessibile
• Ciò comporta la costruzione di sistemi di offerta articolati, accessibili solo a pochi player
ICT che per dimensione e know how possono accettare questa sfida, restando in
condizioni di economicità
• L’esistenza di questa offerta consente di affrontare le nuove sfide della complessità
4Complessità e soluzioni estese
Soluzione estesa
Soluzione su misura
Fabbisogno
funzionale
Funzionalità
non attivateLa domanda • Le esigenze delle aziende si caratterizzano su fronti di alta complessità tecnologica, applicativa ed economica • Gestione delle dimensioni a supporto dell’internazionalizzazione • Poco spazio per insuccessi e spreco di risorse • Alla ricerca di fornitori che abbiano (almeno) lo stesso livello di eccellenza dei loro clienti
L’offerta • Spesso basata su modelli commerciali e logiche che non hanno diretto riscontro nella realtà • Troppe prodotti “perfetti” che il mercato delle Aziende non capisce • Il livello di competenza è disomogeneo rispetto alle esigenze (spesso troppo superficiale o troppo specialistico) • Spazi economici ridotti per chi vuole fare bene (crisi + istigazione alla mediocrità da parte della domanda), ma ….forse si può avere successo economico anche lavorando seriamente • Pochi player che possano combinare ampiezza di offerta, qualità e compatibilità economica con la domanda
Il confronto tra domanda e offerta di prodotti ERP
• L’offerta di prodotti software per la gestione integrata delle aziende
ha raggiunto un livello di sofisticazione manageriale molto elevato
• Le aziende devono essere in grado di sfruttare queste potenzialità per
giustificare gli investimenti
• La “pesantezza” concettuale dei sistemi integrati non va confusa con
la “pesantezza” tecnico/economica
• Il confronto tra domanda e offerta di soluzioni informatiche vede
alcune aziende in posizione “difensiva”
Copyright SDA Bocconi 2005
8Il confronto tra domanda e offerta di prodotti ERP
• Chi fornisce consulenza sui sistemi informativi deve avere una chiara
visione delle esigenze aziendali
• E’ auspicabile che anche le aziende siano in grado di essere sempre
un passo più avanti rispetto alle soluzioni informatiche disponibili
• Una azienda leader nel campo degli ERP è una software house o una
casa editrice che si occupa di management ?
Copyright SDA Bocconi 2005
9Aspetti rilevanti per il successo dei progetti ERP
• Pensiero e non luoghi comuni
• Valutare con attenzione l’offerta nel suo complesso e le dinamiche del
mercato ERP
• No al concetto di sponsorship del management
• Una volta scelto il prodotto (e l’implementatore) adattarsi alla sua filosofia
• Il potenziale di flessibilità offerto dai sistemi integrati non sempre si
traduce in reale flessibilità dei sistemi informativi aziendali
Copyright SDA Bocconi 2005
10Re-interpretare il confronto domanda - offerta
Barriera della
complessità
+ Sol 2 AZ 1
AZ 2 Sol 1
GAP di conoscenza
ERP
GAP di implementazione
Execution Zone
AZ 3 Sol 4
Sol 3 AZ 4
-
- +
Vision
11La complessità come chiave di confronto fra
domanda e offerta di soluzioni estese
Zona dei sistemi Zona delle
Zona delle
funzionali e soluzioni ERP
architetture
verticali
estese
+
? ?
Execution
Complessità Complessità Complessità
contestuale di crescita pluridimensionale
?
?
-
Costo
- Complessità +
12Zona dei sistemi Zona delle
Zona delle
funzionali e verticali soluzioni ERP
soluzioni estese
+
?
?
Execution
Complessità Complessità Complessità
contestuale di crescita pluridimensionale
?
?
-
- Complessità +
Valore
Costo
Driver di valutazioneDimensioni/vettori di complessità aziendale
Il modello di riferimento
Struttura proprietaria
Compliance Struttura manageriale
Caratteristiche del modello
Modello di controllo
commerciale
Caratteristiche del modello
Modello operativo
produttivo
Caratteristiche della supply
Assetto societario
chain
Dinamicità del business Internazionalizzazione
Strategie di crescita
14Valutare il sistema di offerta ICT con la logica del valore • La misura del valore è lo strumento per riconciliare la gestione della complessità con la vista monetaria del Sistema Informativo, in particolare nella valutazione degli investimenti e delle performance economiche dello stesso • I fattori che portano ad un aumento del valore del patrimonio IT sono tutti quelli che abilitano miglioramenti di performance aziendali documentabili e ripetibili nel tempo • Gran parte di questi fattori sono collegabili all’adozione di piattaforme applicative estese e di soluzioni tecniche robuste • Solo abbinando la valutazione degli effetti sui costi con quella sugli impatti sul valore si possono trovare gli elementi per giustificare economicamente investimenti come quelli necessari per l’adozione di sistemi applicativi estesi • La prospettiva di valutazione cambia il peso fra costo e valore
Aspetti rilevanti per il successo dei progetti ERP
• La rifondazione di un sistema informativo non si può basare solo sul
progetto ERP
• Va verificato con attenzione il gap tra azienda e soluzioni ERP:
• Abbiamo raggiunto, o superato, il punto di pareggio tra le competenze
manageriali disponibili in azienda e quelle contenute nei sistemi integrati ?
• Siamo in grado di gestire in modo integrato ?
• Siamo aggiornati ?
• Ci confrontiamo con gli altri ?
• Studiamo ?
• Può esistere una “terra di nessuno” che va attentamente presidiata:
Copyright SDA Bocconi 2005
16I gap di competenza
Dalla Vision alla implementazione, passando dalla RFP
Funzionalità richieste al
Sistema Informativo per il
raggiungimento degli
obiettivi aziendali
Nuove procedure e regole
gestionali per il
raggiungimento degli
obiettivi aziendali
Livello di Astrazione
Individuazione degli
Progetti di adeguamento del
OBIETTIVI delle diverse
Sistema Informativo
unità organizzative necessari
per declinare la Vision
Business
Obiettivi Requirements
Definizione delle linee
strategiche evolutive di e
declinazione in componenti
Progetti Organizzativi
Progetto Y di Supporto
Vision
Progetto X
Software & Partner SelectionMetodologia di Riferimento
1.Valutazione
Check-up e 2.Definizione
verifica assetto
attuale del SI Architettura e
Definizione Interventi
Obiettivi
Strategici 3.Selezione
Aziendali
Definizione Soluzioni e 4. Implementazione e Sistemi
Architettura
Generale
Fornitori di IS Governance
Individuazione
Interventi e Definizione
Priorità dei Business Implementazione
Requirement
Short List
Potenziali
Partner Progetto xxx
Stesura del
Project Chart Progetto yyy
SW & Partner
Selection Progetto zzz
Set Up di
Progetto e
definizione dei
Meccanismi di
Gestione
Sistema di IS Governance
Cultura e Persone
Meccanismi di Orientamento
Portafoglio Applicativo
Infrastrutture Tecnologiche1.Valutazione 2.Architettura 3.Selezione 4.Implementazione 1. Valutazione
1. Valutazione
Check-up e
verifica assetto
attuale del SI
Definizione
Obiettivi
Strategici
Aziendali
1.Valutazione
Rilevazione Obiettivi Strategici
In questa fase vengono effettuate una serie di interviste al
Top Management per individuare le linee future di sviluppo
della Strategia Aziendale
Le indicazioni raccolte in questa fase sono necessarie ad
indirizzare la definizione dell’Architettura di Riferimento
Per orientare opportunamente lo sviluppo futuro del
Sistema Informativo è fondamentale condividere con il Top
Management l’approccio a proposito della gestione della
complessità ambientale ed aziendale
>
>Modello di Riferimento del Sistema Informativo
SISTEMA INFORMATIVO
Infrastrutture Portafoglio
Infrastrutture tecnologiche per il
trattamento dei Dati e la produzione delle Applicativo
Informazioni Insieme delle Procedure e delle Applicazioni
per l’acquisizione, il trattamento e la
riproduzione delle informazioni
Principi e Valori
Dati Persone
Patrimonio di Dati gestito dal sistema Persone che sovrintendono alle
Anagrafiche di base ed eventuali acquisizioni Infrastrutture ed al Portafoglio Applicativo
da fonti esterne (Istituti di ricerca, (Risorse Umane ed Organizzazione della
Associazioni di Categoria, Banche Dati Funzione Sistemi Informativi
esterne….)
Consulenti Esterni)
<
221.Valutazione: definizione Obiettivi Strategici
• In questa fase vengono effettuate una serie di interviste al Top
Management per individuare le linee future di sviluppo della Strategia
Aziendale
• Le indicazioni raccolte in questa fase sono necessarie ad indirizzare la
definizione dell’Architettura di Riferimento
• Per orientare opportunamente lo sviluppo futuro del Sistema Informativo
è fondamentale condividere con il Top Management l’approccio a proposito
della gestione della complessità ambientale ed aziendale
<1.Valutazione 2.Architettura 3.Selezione 4.Implementazione
2.Definizione Architettura
Generale e Interventi
242.Definizione Architettura Generale e Interventi
Processo
Processi Aziendali Processo
2. Processo
Definizione
Architettura
Funzionalità Funzionalità
Funzionalità Funzionalità
e interventi
Architettura Applicativa Applicativo
Applicativo Applicativo
Definizione
Architettura
Generale Piattaforma Tecnologica Tecnologia Tecnologia
Tecnologia Tecnologia
Individuazione >
Interventi e
Priorità
Processi Aziendali Individuazione e descrizione dei singoli Processi Aziendali ed attività
che contribuiscono alla creazione ed erogazione dei servizi/prodotti
offerti dall’azienda
Funzionalità Descrizione delle transazioni, delle informazioni e degli strumenti di
condivisione/collaborazione a supporto dei processi
Individuazione Interventi e Priorità
Architettura Applicativa Identificazione delle possibili soluzioni in termini di
• Successivamente alla declinazione dell’architettura generale pacchetti/piattaforme SW ottimali per la copertura delle aree di
del Sistema Informativo nei suoi vari livelli, vengono anche funzionalità sia per ampiezza che per profondità
identificate e condivise le priorità d’intervento per le fasi
successive
Piattaforma Tecnologica Disegno delle possibili architetture infrastrutturali e tecnologiche
(server, DB, reti, integrazione con device specifici), che possano
> supportare la piattaforma applicativa identificata
>Architettura
Ambito di Analisi
Vendita, Sviluppo Gestione Mostra Approvvigionamenti
Commerciale
Gestione Amministrativa per conto
Pianificazione Manifestazioni ed
Contratti.
Mostra
Quadro
Progettazione Mostra
Organizzatori
Erogazione Servizi
Organizzatori
Assistenza
Espositori
Primarie
Eventi
Quartiere
Contratti
Visitatori Aperti
Gestione
Accessi e
Sicurezza Altro
Marketing Operativo
Gestione Infrastrutture
Pianificazione e Budgeting
Investimenti & Progetti
Supporto
Studi (Marketing Strategico)
Comunicazione
Gestione e Sviluppo del Personale
Amministrazione Finanza & Controllo di Gestione
Processi Processo
Processo
Aziendali
Processo
•Azionisti, Enti Locali •Organi di Controllo •Comunità Finanziaria
Funzionalità •Corporate Portal •Document •Posti •Profiling•& •…
•Work Flow •Single•Sign•On
Funzionalità •Management •Informazione •Security
•Fondazione
Funzionalità Funzionalità •Applicativi Verticali
•Rilevazione Consumi •SSF
•Biglietteria •Gestione e Controllo Accessi
•Energetici
•Progettazione Spazi ed •Sicurezza Mostra ed •FMC
•Espositori •…
•Ambientazioni •Impianti
•FMI
•Pubblico •Applicativi Gestionali
Architettura •Gestione Strategica dell’Impresa •Business Intelligence &
•Data•Warehousing
•Controllo Strategico (BSC&
•Reporting
•)
•Controllo di Gestione
•Amministrazione
•e Finanza
•… •Altre Società
•del Gruppo
Applicativo •Gestione Relazione con l Clientela
Applicativa •Call•Management
•Marketing
•Program Management
•Service Fulfillment
•SATE
•Presidio della relazione nel
•Mercato di Riferimento
•…
Applicativo Applicativo •Visitatori
•Vendite e Marketing •Pianificazione &
•Simulazione
•Gestione Ordini Formulari
•Progetto Fiera
•DB di Marketing
•Rilevazione•Customer
•Satisfaction
•Gestione
•Catalogo
•…
•Altre società
•del Gruppo
•Gestione Progetti •Pianificazione •Realizzazione e Controllo •Avanzamento •Programmazione/ •…
•Progetti •Progetti •Attività •Consuntivazione attività
•Fiere Virtuali
•Gestione Risorse Umane •Pianificazione delle •Amministrazione del •Time •Sviluppo
•Selezione •Formazione •…
•Risorse Umane •Personale •Management •Personale
•.
•Espositori
•Servizio alla Clientela
•Call•Center •Assistenza Clienti •Manutenzione •…
•Acquisti
•Gestione
-
•Self••Service •Gestione Catalogo •Gestione Contratti •Valutazione Fornitori •…
•Ordine
•Organizzatori •Utenti
•Fatturazione •Pianificazione •Fatturazione per conto
•Fatturazione
•Fatturazione
•terzi
•Pagamenti Elettronici •… •Fiera Milano Spa
Piattaforma •Business•Support
•Gestione Investimenti •Gestione Cespiti •Tesoreria •…
Tecnologia Tecnologia
Tecnologica Tecnologia Tecnologia
•Fornitori •Fornitori
•FornitoriLivelli di Articolazione dell’Architettura Generale
Processi Aziendali Individuazione e descrizione dei singoli Processi Aziendali ed
attività che contribuiscono alla creazione ed erogazione dei
servizi/prodotti offerti dall’azienda
Funzionalità Descrizione delle transazioni, delle informazioni e degli
strumenti di condivisione/collaborazione a supporto dei
processi
Architettura Applicativa Identificazione delle possibili soluzioni in termini di
pacchetti/piattaforme SW ottimali per la copertura delle aree
di funzionalità sia per ampiezza che per profondità
Piattaforma Tecnologica Disegno delle possibili architetture infrastrutturali e
tecnologiche (server, DB, reti, integrazione con device
specifici), che possano supportare la piattaforma applicativa
identificata
<
28Livelli di Articolazione dell’Architettura
Processo
Processi Aziendali Processo
Processo
Funzionalità Funzionalità
Funzionalità Funzionalità
Architettura Applicativa Applicativo
Applicativo Applicativo
Piattaforma Tecnologica Tecnologia Tecnologia
Tecnologia Tecnologia
<Modello Architettura Applicativa
ENTERPRISE INTEGRATION PORTAL
PROCESSI COMUNI SISTEMI DI FILIALE
Agenti di Filiale
Pianificazione e Budget Legal ??? Vendita Tentata
Vendita
Internal Users Amministraz. & Controllo di Finanza Fatturazione
Payroll Gestione
Recupero crediti
H.R.
Agenti e Agenti
Pre Vendita
A GELATO (processi specifici e app.) COMMERCIALE
P Gestione Materiali
Internal Users P R&D MARKE Programmazione Versato a Accessori (espositori, BI
Altri R TING Produzione Magazzino frigoriferi, Forni,
Cartellonistica....)
O L Key Account
V Applicazioni trasversali o (GDO,
VI Ingegneria di Fabbrica
Fornitori
Manutenzione Impianti rispetto a linee di g HORECA)
Critici GI
O business (es. i
s RETAIL
N Ass. Qualità produzione)
A t
Fornitori Altri M CROIX. (processi specifici e app.) i
E c
N R&D MARKETIN Programmazione Versato a
a
TI G Produzione Magazzino
Other SERVIZI E FUNZIONI COMUNI
stakeholders
Single sign on Workflow Portal Knowledge Document Produttività Individuale,
& Security Utility Sharing & Social Management Office Automation
Clienti GDO Clienti Consumatori
Clienti HORECA
CONCESSIONARIArchitecture Alignment Loops
ACCOUNTABILITY
Top Management
CIO
Corporate Business Application Manager
Governance
ACCOUNTABILITY
LOB Managers
Business Application Manager
Requirements Demand Manager
ACCOUNTABILITY
Application Manager
ICT Trends Application System ArchitectPianificazione
Individuazione Interventi e Priorità
Successivamente alla declinazione dell’architettura generale del Sistema Informativo nei
suoi vari livelli, vengono anche identificate e condivise le priorità d’intervento per le fasi
successive
In questa sede è importante verificare la coerenza con i metodi di allineamento tra
esigenze aziendali e SI (logiche e strumenti di governance)
<
C1.Valutazione 2.Pianificazione 3.Selezione 4.Implementazione
3. Selezione
• Raccolta e formalizzazione Business Requirements
• Stesura Request for Proposal (RFP) e Sw & Partner Selection
• Negoziazione e Contratto di “Appalto d’opera”3.Selezione
Business Requirement Project Chart
3.Selezione
Durante la fase di raccolta dei Business Requirement • Formalizzazione di un documento che individui:
sarà necessario: • Contesto Aziendale
• Identificare i Processi Principali • Obiettivi di Progetto
• Definire le Macro Funzionalità • Business Requirement
• Raccogliere i Business Requirement (BR) • Struttura dell’Offerta
• Rivedere ed Integrare i BR • Quadro contrattuale
• Pesare i BR • Aspetti Critici del Progetto
• Formalizzare i Business Requirement Definitivi •
• Tale documento servirà come base comune per:
Definizion • condividere con i fornitori i contenuti del progetto
e dei • facilitare il processo di formulazione e selezione
Business delle proposte
Requirem
ent Short List
Codice MacroArea Area Business Requirement
Potenziali
575 Acquisti Gestione Gestione premi di fine anno da fornitore
Partner
58 Commerciale
fornitori
Forza Attribuzione del venduto alle singole agenzie sparse sul territorio Stesura del
61 Commerciale
vendite
Forza Possibilità di definire le provvigioni come:
Project Chart
vendite - percentuale fissa per prodotto finito
- possibilità di range di percentuali in funzione della quantità SW & Partner
- gestione del reso che crea nota di debito verso l'agente per le provvigioni
corrispondenti ... Selection
62 Commerciale Forza Gestione di provvigioni con possibilità di calcolo sull'incassato, sul fatturato, o su una
63 Commerciale
vendite
Forza
determinata percentuale di questi valori
Gestione di provvigioni destinate ad agenti diversi per lo stesso ordine
SW & Partner Selection
vendite
108 Commerciale Gestione Possibilità di avere delle funzionalità di calcolo di indici di performance del servizio al
115 Commerciale
ordini
Listino
cliente
Calcolo dei listini in valuta derivandoli da quello base per un cambio standard definito, • Incontri Direzionali con i Software vendor ed i rispettivi
148 Dati Tecnici Anagrafiche
anche per copia di listini su stessa valuta da uno di riferimento.
Possibilità che le dimensioni del prodotto finito definite a sistema siano ereditate da partner implementatori
262 Magazzini
articolo
Inventario
quelle dell'imballo corrispondente in distinta base
Possibilità di effettuare una rettifica inventariale per la materia prima di estrusione • Workshop di approfondimento per determinare gli elementi
rimacinata e di associarla a tutti gli ordini di produzione che hanno utilizzato quella
materia prima necessari alla decisione finale
286 Magazzini Spedizioni Ottimizzazione del piano di spedizione in base al carico e alla rotta (verifica di fattibilità
del piano di spedizione su vincoli parametrici: volume/peso, …) • Valutazione delle livello di copertura dei Business
> Requirement
• Valutazione aspetti economici delle offerte
• Approfondimenti su aspetti critici/specificità
• Definizione delle caratteristiche fondamentali del/dei
contratto/i3. Selezione: Business Requirement
Business Requirement
Durante la fase di raccolta dei Business Requirement sarà necessario:
Identificare i Processi Principali
Definire le Macro Funzionalità
Raccogliere i Business Requirement (BR)
Rivedere ed Integrare i BR
Pesare i BR in funzione della loro relativa criticità/priorità
Formalizzare i Business Requirement DefinitiviRilevazione dei Business Requirement • Questa fase ha come finalità la produzione e validazione di una lista qualificata di Business Requirement (BR) che serviranno come griglia di selezione delle soluzioni software per quanto concerne gli aspetti funzionali • I BR vengono raccolti dopo che sono stati identificati i processi e gli ambiti di rilevazione, anche in base alle evidenze emerse nel corso della fase di Definizione del Modello Operativo Futuro
Rilevazione dei Business Requirement • Il principale obiettivo di questa attività è l’identificazione degli aspetti funzionali peculiari e critici del business ai fini della progettazione del nuovo Sistema Informativo Aziendale • Nel corso degli incontri è importante far emergere le logiche di fondo necessarie per l’impostazione di un sistema informativo in grado di rispondere alle necessità attuali ed alle linee evolutive dell’azienda • Il livello di dettaglio raggiunto durante questa fase non pretende di esaminare tutte le tematiche bensì di evidenziare i soli aspetti determinanti per l’impostazione del nuovo sistema
Che cosa è un Business Requirement
• Descrizione espresse in forma verbale dei dati che devono essere gestiti dal sistema e
delle modalità di elaborazione (inserimento, elaborazione, presentazione)
• Suggerimento di formalizzazione: VERBO IN FORMA INFINITA
“Input – Processing – Output” verbo + complemento oggetto
• “Gestione del fido cliente” vs. “Determinare il fido cliente sulla base del fatturato medio
degli ultimi tre anni e permettere un incremento da parte dell’account all’interno di un
range predefinito”.
Copyright SDA Bocconi © Gianluca Salviotti
38Esempio di formulazione Business Requirement
Generico
“….Sistema veloce e flessibile per gestire il conto
economico aziendale….”
“…Supporto alla formulazione del Conto Economico Corretto
gestionale a margini di contribuzione, con utilizzo di
una configurazione di costo standard unitario di
produzione o di acquisto dei singoli item…”
“…Possibilità di gestire un Conto Economico che Troppo Specifico
prevede una struttura articolata nei seguenti
conti:
43100 Vendite Italia (+)
43200 Vendite Estero (+)
43300 Sconti a cliente (-)
84100 Resi da cliente (-)Caratteristiche dei Business Requirement • Completezza: all’interno dei business requirement dovranno essere contenute tutte le informazioni necessarie ad analizzare il fabbisogno. Eventuali informazioni mancanti difficilmente potranno essere desunte dalla lettura incrociata di due o più Business Requirement • Coerenza: due o più business requirement non possono essere tra di loro in conflitto • Autoesplicazione: il significato di ogni singolo business requirement dovrà essere chiaro ed inequivocabile dalla lettura del singolo business requirement. Perché ciò sia possibile non dovranno essere presenti riferimenti incrociati tra due o più business requirements • Tracciabilità: ogni business requirement dovrà contenere un solo requisito funzionale rendendo in questo modo facilmente collegabili le singole funzionalità realizzate ai singoli business requirements espressi dagli utenti • Determinatezza: i business requirement dovranno avere una forma tale da rendere possibile la verifica oggettiva di rispondenza tra quanto sviluppato e il business requirement stesso (esempio: non dovranno contenere attributi quali infinite, innumerevoli, facile, veloce, efficiente, efficace, ecc.) tuttavia non dovranno neppure contenere un livello di dettaglio superfluo ai fine della loro comprensione
Rilevazione Business Requirements
Durante la fase di Rilevazione dei Business Requirements sarà necessario:
• Definire le Macro Funzionalità per Processo di Business
• Raccogliere i Business Requirements (BR) Macro
• Raccogliere i Business Requirements (BR) di dettaglio
• Rivedere ed Integrare i BR
• Pesare i BR in funzione della loro relativa criticità/priorità
• Formalizzare i Business Requirements DefinitiviRilevazione Business Requirement
1° Incontro 2°/3° Incontro Workshop di allineamento 4° Incontro
• Condivisione della Metodologia di • Condivisione dello Schema delle • Coinvolgimento KU/PO • Validazione dei BR formalizzati
raccolta • macro Aree Funzionali Oggetto • Sintesi stato avanzamento • Definizione delle Modalità di
• Definizione delle Modalità di Lavoro dell’Analisi rilevazione BR Pesatura
• Descrizione da parte degli Utenti dei • Analisi e Approfondimento dei • Confronto e analisi eventuali • Consegna dei BR definitivi per la
Principali Processi di cui sono i Business Requirement criticità Pesatura da parte degli Utenti Interni
rappresentanti • Integrazione con ulteriori BR emersi • Integrazione BR con osservazioni e
• Esempi e chiarimenti dalla discussione necessità ulteriori
• Condivisione Agenda incontri
successivi Team n Team n Team n
Team n
DEFINIZIONE MACRO BR Sintesi e Valutazioni
Impegno richiesto
Raccolta dei BR pesati, Consolidamento
• Mezza giornata ad incontro per un totale di 2/3 Sintesi e Valutazioni dei Risultati emersi
incontri
RACCOLTA BR di DETTAGLIO
• Mezza giornata ad incontro per un totale di 4 incontri
• Tempo necessario a ciascun gruppo per approfondire alcuni temi critici
• Tempo necessario a ciascun gruppo per pesare, consolidare e validare i BR prodottiEsempi di Business Requirement
Codice MacroArea Area Business Requirement
575 Acquisti Gestione Gestione premi di fine anno da fornitore
fornitori
58 Commerciale Forza Attribuzione del venduto alle singole agenzie sparse sul territorio
vendite
61 Commerciale Forza Possibilità di definire le provvigioni come:
vendite - percentuale fissa per prodotto finito
- possibilità di range di percentuali in funzione della quantità
- gestione del reso che crea nota di debito verso l'agente per le provvigioni
corrispondenti ...
62 Commerciale Forza Gestione di provvigioni con possibilità di calcolo sull'incassato, sul fatturato, o su una
vendite determinata percentuale di questi valori
63 Commerciale Forza Gestione di provvigioni destinate ad agenti diversi per lo stesso ordine
vendite
108 Commerciale Gestione Possibilità di avere delle funzionalità di calcolo di indici di performance del servizio al
ordini cliente
115 Commerciale Listino Calcolo dei listini in valuta derivandoli da quello base per un cambio standard definito,
anche per copia di listini su stessa valuta da uno di riferimento.
148 Dati Tecnici Anagrafiche Possibilità che le dimensioni del prodotto finito definite a sistema siano ereditate da
articolo quelle dell'imballo corrispondente in distinta base
262 Magazzini Inventario Possibilità di effettuare una rettifica inventariale per la materia prima di estrusione
rimacinata e di associarla a tutti gli ordini di produzione che hanno utilizzato quella
materia prima
286 Magazzini Spedizioni Ottimizzazione del piano di spedizione in base al carico e alla rotta (verifica di fattibilità
del piano di spedizione su vincoli parametrici: volume/peso, …)Business Requirement e Mappa Applicativa
• Dalla rilevazione dei Business Requirement verrà costruita e/o validata la Mappa Applicativa coerentemente ai
bisogni emersi e ai processi che saranno ambito di Progetto
• Tale Mappa rappresenterà un quadro di sintesi della struttura dei Business Requirements e servirà per
comprendere il livello di copertura funzionale di possibili piattaforme applicative di mercato che andranno ad
essere valutate
• Di seguito un esempio che evidenzia le connessioni logiche tra Area Applicativa della Mappa, modulo applicativo
e Business Requirement: Modulo
Vendita e Sviluppo Commerciale Analisi sul Mercato e sulla Previsione della
Pianificazione & Simulazione Listino Prodotto/Cliente
Clientela Domanda
Area Applicativa Anagrafica Clienti
Ricezione, inserimento e
gestione ordini
Gestione provvigioni Gestione resi e reclami
Business Requirements del Singolo Modulo
9-10 Vendita e Sviluppo Previsioni COM002 Analizzare gli scostamenti tra previsione e consuntivo con possibilità di articolare
Commerciale l'analisi per articolo, per famiglie di prodotto, per cliente, per gruppo di clienti.
9-10 Vendita e Sviluppo Previsioni COM003 Interfacciare il modulo di previsione della domanda con strumenti elettronici di
Commerciale scambio dei dati (es. EDI)
9-10 Vendita e Sviluppo Previsioni COM004 Generare automaticamente delle previsioni per mezzo di algoritmi di estrapolazion
Commerciale basate sulle serie storiche della domanda.
9-10 Vendita e Sviluppo Previsioni COM005 Gestire il consumo delle previsioni da parte degli ordini automaticamente: i dati
Commerciale consuntivi degli ordini acquisiti vanno a consumare le previsioni del periodo
corrispondente. Esempio: previsione iniziale del mese 1000, ordini acquisiti 300
==> previsione residua del mese 700
9-10 Vendita e Sviluppo Previsioni COM006 Gestire previsioni con differenti bucket temporali (settimana, mese, trimestre) con
Commerciale delle regole di suddivisione della previsione all'interno del bucket temporale.
Esempio: inserire le previsioni mensili e poi ripartirle automaticamente sulle singole
settimane appartenenti al mese
9-10 Vendita e Sviluppo Previsioni COM007 Gestire differenti modalità di definizione della domanda (budget, forecast mensili,
Commerciale ordini previsionali da cliente, call-off) riconoscibili a sistema
9-10 Vendita e Sviluppo Previsioni COM008 Generare e gestire la previsione della domanda sia a quantità sia a valore con
Commerciale possibilità, in base al listino di passare da quantità a valore e viceversa
9-10 Vendita e Sviluppo Gestione ordini COM009 Gestire l'inserimento degli ordini cliente, dei call-off e dei JIT in modalità elettronica
Commerciale mediante EDI e con il protocollo OdettePesatura dei Business Requirement
• Al fine di individuare le priorità a livello aziendale (adottando una visione complessiva di tutte le aree funzionali)…
• …è necessario definire un peso associato ai Business Requirement espresso come supporto alla operatività
aziendale nelle varie aree dell’organizzazione
• Ciascun Gruppo di Lavoro coinvolto, deve condividere una pesatura dei singoli BR di propria competenza secondo la
scala indicata
3. Essenziale Il sistema non sarà ritenuto accettabile se il requisito indicato non
sarà disponibile nei termini e nelle modalità concordate. Sono
funzionalità prioritarie ai fini del business per le quali una corretta
gestione da parte del sistema è indispensabile
Requisito che migliorerebbe il sistema, ma non lo renderebbe
2. Necessario inaccettabile (almeno in una prima fase del progetto)
Senza questo requisito l’attività può essere svolta solo a costo di
rilevanti integrazioni manuali)
Requisito la cui presenza potrebbe anche non essere necessaria.
1. Opzionale Rappresentano funzionalità/procedure che oggi hanno un ‘importanza
marginale, o che vengano gestite manualmente o parzialmente dal
sistema e senza di cui il lavoro scorre comunque senza sostanziali
mancanze o forzature. Il coprire tali requisiti porterebbe ad un
miglioramento di efficienza
E’ un fabbisogno che in futuro potrebbe diventare importanteComposizione e Organizzazione
dei Gruppi di Lavoro per la
rilevazione dei BRIl modello dei processi aziendali: un esempio
Acquisti Logistica in Ideazioe e Gestione anagrafiche Marketing e Distribuzione Gestione
Ingresso sviluppo Sviluppo Punti Vendita
prodotto commerciale
Primari
Produzione
Controllo Qualità
Amministrazione/Finanza/tesoreria
Supporto
Controllo di Gestione
Gestione e Sviluppo delle Risorse UmaneSchema complessivo dei Processi
VENDITE e SERVIZI ALLA
LOGISTICA di CLIENTELA
PIANIFICAZIONE ACQUISTI LOGISTICA IN PRODUZIONE DISTRIBUZIONE
COMMERCIALE MAGAZZINO
INGRESSO
Primari
Team Team Team Team Team
1 2 4 1 1
Team 3
PIANIFICAZIONE E PROGRAMMAZIONE DELLA PRODUZIONE
MARKETING
Team 5
R&D
Team 6
AMMINISTRAZIONE E FINANZA - PAYROLL
Team 7
BUDGET & CONTROL Team 8
Supporto
QUALITA’
Team 9
SICUREZZA & SERVIZI GENERALI
Team 10
RISORSE UMANE
Team 11
DIREZIONE LEGALE
Team 12
MANUTENZIONE
Team 31.Valutazione 2.Pianificazione 3.Selezione 4.Implementazione
La fase di Selezione
• Raccolta e formalizzazione Business Requirements
• Stesura Request for Proposal (RFP) e Sw & Partner Selection
• Negoziazione e Contratto di “Appalto d’opera”3. Selezione: Project Chart e RFP
Project Chart
Formalizzazione di un documento che individui:
Contesto Aziendale
Obiettivi di Progetto
Business Requirement
Struttura dell’Offerta
Quadro contrattuale
Aspetti Critici del Progetto
Tale documento servirà come base comune per:
condividere con i fornitori i contenuti del progetto
facilitare il processo di formulazione e selezione delle proposte
<
Copyright SDA Bocconi 2005
50La Request for Proposal
• La RFP è il documento che descrive, in modo “sufficientemente” dettagliato, il contesto aziendale del cliente,
il progetto, gli obiettivi, i vincoli (operativi e legali) che il cliente intende porre, al fine di mettere il fornitore
nella migliore condizione per formulare un’offerta altrettanto dettagliata e precisa in termini sia operativi
che economici.
• La RFP deve quindi esplicitare:
• Contesto Aziendale
• Obiettivi di Progetto
• Business Requirement
• Struttura dell’Offerta come richiesta dal cliente
• Quadro contrattuale richiesto dal cliente
• Aspetti Critici del Progetto
• Tale documento di RFP servirà come base comune per:
• condividere con i fornitori i contenuti del progetto e formulare specifiche richieste e/o vincoli da rispettare nella
formulazione delle offerte
• facilitare e rendere il più possibile “trasparente” il processo di formulazione delle offerte da parte dei fornitori
• facilitare il confronto tra le differenti offerte e quindi l’individuazione della proposta che meglio rispecchia i bisogni
del cliente (non solo da un punto di vista economico)Request for Proposal: descrizione della struttura
Il documento di Project Charter & Request For Proposal costituisce la fonte unica delle informazioni volta a
supportare l'Outsourcer nella formulazione di un’ offerta tecnica ed economica di una soluzione a copertura dei
fabbisogni espressi dal Cliente
Il documento è articolato in Sezioni: le sezioni A e B rappresentano il Project Charter, mentre le sezioni C e D
costituiscono la Request for Proposal (RFP)
Project Charter
Sezione A – Elementi descrittivi del contesto Sezione B – Ipotesi preliminari e linee guida per il
In questa Sezione sono raccolte informazioni volte ad illustrare al System Integrator Progetto
lo scenario aziendale, organizzativo, di business e dei Sistemi Informativi della In questa Sezione si tracciano una serie di ipotesi relative al
Società in modo da facilitare l’inquadramento dell’iniziativa progettuale. Disegno Architetturale ed Evolutivo, al percorso di Progetto,
Tra gli elementi fondamentali riportati vi sono il Company Profile, la Vision e gli all’Organizzazione a Supporto del Progetto e, più in generale,
Obiettivi Strategici del Progetto declinati nelle Linee Guida della Direzione, la vengono esposte tutte le linee guida che il management della
Descrizione del Sistema Informativo Attuale, ed altri elementi ritenuti coerenti ai fini Società ha ritenuto di indirizzare quale importante riferimento per
esposti. il System Integrator
Request for Proposal
Sezione C – Elementi vincolanti per l’esecuzione Sezione D – Elementi da fornire nella Proposta, template ed indicazioni
del Progetto per la compilazione
In questa Sezione trovano posto le condizioni che il System In questa Sezione si fornisce il perimetro della proposta formale richiesta, volta ad
Integrator dovrà necessariamente rispettare nel formulare la ottenere una soluzione complessiva che indirizzi i temi anticipati nel capitolo
Proposta a copertura dei fabbisogni legati al Progetto. Oltre “Premessa e finalità del documento”. Con lo scopo di ottenere offerte uniformi e
alla fondamentale copertura dei Business Requirement, sono complete e quindi di semplificare il processo di confronto e valutazione, la sezione
presentati requisiti relativi al processo di progettazione e le fornisce inoltre la struttura con cui dovrà essere formulato il documento di risposta,
Condizioni Generali di Offerta, completate dalle Terms & articolandolo secondo i capitoli esposti in dettaglio
Conditions3.Selezione: Software e Partner Selection
SW & Partner Selection
Incontri Direzionali con i Software vendor ed i rispettivi partner
implementatori
Workshop di approfondimento per determinare gli elementi
necessari alla decisione finale
Valutazione delle livello di copertura dei Business Requirement
Valutazione aspetti economici delle offerte
Approfondimenti su aspetti critici/specificità
Definizione delle caratteristiche fondamentali del/dei contratto/i
<
Copyright SDA Bocconi 2005
53La “famigerata” demo
• Serve?
• Non può rappresentare lo strumento principale di valutazione e di scelta tra soluzioni
alternative
• A che cosa (potrebbe) servire ?
• Verificare la modalità di copertura di un’area funzionale estremamente specifica
• Es. 1: gestire le versioni alternative di prodotto
• Es.2: calcolo dei premi ai clienti di fine anno
• NO: immissione di un ordine di acquisto, contabilizzazione di un costo
• Coinvolgere, in modo guidato, alcuni utenti nel processo di valutazione
• Coinvolgere le competenze tecniche del venditore del software in fase di valutazione
• Come si organizza?
• Definire e condividere con i fornitori in modo specifico il requisito funzionale che si desidera
verificare mediante la demo
• Identificare con gli utenti ammessi alla valutazione un metodo strutturato di valutazione degli
esiti della demo
• Copertura dell’esigenza
• Distanza rispetto alla soluzione attuale
• Impatti del cambiamentoLa selezione delle soluzioni e dei partner
• Sapere cosa si sta cercando
• Rifuggire dai luoghi comuni
• Verificare il livello di compatibilità con filosofie di prodotto
• Va selezionato il produttore e non il prodotto (software house
selection vs software selection)
• Non tentare di escogitare sistemi di selezione “scientifici” (es. scoring)
Copyright SDA Bocconi 2005La selezione delle soluzioni e dei partner
• Coordinare tutte le scelte nei casi in cui si stia rifondando il sistema
informativo (la scelta del sistema ERP non
• ERP
• Consulenti di management
• Carrier per le telecomunicazioni
• Hardware vendor
• .....
Copyright SDA Bocconi 2005
56Selezione del prodotto ERP
• Non dedicare troppo tempo (e budget) ad analisi di copertura delle proprie
esigenze
• l’azienda cambia e i prodotti si evolvono
• tutti hanno tutto
• Fare liste di funzionalità “ragionate” e per criticità
• Sviluppare scenari applicativi complessi (o critici) e verificare la capacità di
dare risposte tecniche, applicative e…manageriali ai problemi presentati
• Non confondere la verticalizzazione con la coerenza con le proprie esigenze
57Selezione del vendor ERP
• Scartare subito le soluzioni non coerenti (short list) sulla base degli
aspetti macro
• Ampiezza del progetto
• Dimensione internazionale
• Stato dell’offerta
• Compatibilità con piattaforma scelta (se rilevante)
• Solidità aziendale globale e situazione locale
• Coerenza con il proprio progetto
• Localizzazione
• Incontri con il top management delle aziende selezionate
• Sfruttare le analisi degli analisti finanziari
58La selezione dell’implementatore
• Non sbagliare la tipologia di implementatore
• Practice tecnologica
• Practice anche consulenziale
• Simile al processo di scelta del vendor (incontri con management, ecc)
• Concordare il sistema di misurazione delle performance del progetto
(anche extra contrattuale)
• Coerenza molto forte tra metodi proposti e risultati effettivi
• Non tralasciare gli aspetti legali
59Criteri per la valutazione dell’implementatore
• Business style
• Cultura orientata al mantenimento delle persone
• Flessibilità contrattuale e nel delivery
• Reputazione di buon team building con i clienti
• Propensione al trasferimento di conoscenze
• Mancanza di arroganza
• Sistema di incentivazione delle risorse
• Costi e forma contrattuale
• Modalità di predisposizione delle offerte
• Copertura geografica (solo se necessaria)
60La selezione delle soluzioni e dei partner
• Condivisione delle responsabilità della scelta con management e
consulenti
• Non affidarsi a calcoli su ritorni finanziari come il ROI (evidenziare
invece il profilo economico e finanziario del progetto)
61La Richiesta di Offerta
la Valutazione delle offerte e la Selezione del partner
Creazione
della Short-List
Definizione Richiesta di Offerta Valutazione offerte e
degli Obiettivi (RFP) Selezione del partner
Raccolta dei fabbisogni
(Business Requirements)Framework di valutazione delle
Offerte
Ambiti, Pilastri di analisi, Driver
Business Requirements: valutazione della CoperturaIl processo di valutazione
Introduzione
Soluzione
Architettura della Copertura dei
soluzione Business
applicativa Requirements
Effort
Economics
Progetto
Organizzazione e
Strategia di Strumenti di Sviluppo della Supporto alla Architettura
AMS
implementazione governo del Soluzione transizione Tecnologica
Progetto
Effort Effort Effort Effort Effort Effort
Economics Economics Economics Economics Economics Economics
Terms &
Effort Economics
Conditions
Condizioni
Partner
Approccio e
Caratteristiche Valutazioni degli
conduzione
Dichiarate Analisti processo di offerta
Sintesi e
Prossimi Passi
raccomandazioniLa struttura dell’offerta di
servizi ERP (cenni)Le linee guida dell’offerta
• Dal punto di vista dell’offerta progettuale e dei conseguenti
contratti l’azienda richiede il rispetto di due principi cardine:
1. Assunzione piena di responsabilità del fornitore rispetto al completamento del progetto
e al raggiungimento degli obiettivi concordati (“Appalto d’Opera”)
2. Definizione di un unico interlocutore (Main Contractor) per tutte le attività di servizio pur
in presenza di più di una società e/o risorse coinvolteGli elementi dell’offerta
Ambito, Strategia e Copertura Funzionale
Al fine di ottimizzare la fase di software e partner selection e ritenendo cruciale la
valutazione dei servizi di consulenza/implementazione, sono di seguito indicati i macro
argomenti che tutte le offerte devono obbligatoriamente contenere
• Strategia
• Indicare la strategia con cui si intende affrontare il progetto mettendo in chiara evidenza i seguenti
elementi caratteristici
• Fasi (includendo il post avviamento)
• Ruoli e responsabilità
• Tempi
• Deliverables
• Ambito
• Definire l’ambito della proposta, specificando le aree di business e le società coperte nonchè i
prodotti/moduli software coinvolti
• Copertura Funzionale
• Specificare, secondo le modalità proposte, il grado di copertura dei Business Requirement nonchè
i moduli specifici del prodotto ERP/SCM o di Configurazione con i quali si prevede di coprirliFixed Price
Pro : Contro:
• costi noti dall’inizio • rischio che i contenuti (documenti e
deliverable tecnici) non vengano in effetti
• possibilita’ di tarare l’intervento della
rilasciati nei termini concordati dal punto di
consulenza in funzione del budget disponibile
vista qualitativo
• minore rischio di maggiori costi rispetto al
budget di progetto • grosso sforzo per mantenere i tempi, ma
rischio di scarso coinvolgimento dell’azienda
nel controllo dei contenuti e dei deliverables
rilasciati dal consulente
• probabile differenza di velocita’ tra
consulente e utenza che penalizza l’aziendaTime & Materials
Pro: Contro:
• forte attenzione alla qualità dell’output • costi non noti dall’inizio
realizzato • rischio elevato di maggiori costi rispetto
• massima partecipazione dell’azienda al budget di progetto
• vera appropriazione del sistema rilasciato • rischio di prolungare la durata del
progetto oltre a quella pianificata1.Valutazione 2.Pianificazione 3.Selezione 4.Implementazione
La fase di Selezione
• Raccolta e formalizzazione Business Requirements
• Stesura Request for Proposal (RFP) e Sw & Partner Selection
• Negoziazione e Contratto di “Appalto d’opera”Negoziazione e Contratto • Una volta concluso il processo di Selezione con la valutazione delle Offerte ricevute, si procederà con la fase di Negoziazione commerciale e contrattale con il Fornitore scelto, che porterà alla stesura e sottoscrizione del Contratto attraverso la messa a punto di una Griglia Contrattuale e di Terms & Conditions • Il Cliente potrà definire tali aspetti con il supporto della propria Funzione Legale e/o consulenza di propria fiducia
Ciclo di vita del Contratto
PIANIFICAZIONE SVILUPPO
Verifica Preliminare Identificazione Identificazione Stesura del Negoziazione di Gestione, modifica,
Fasi del ciclo di
dell’oggetto del dell’impianto Contratto e dei dettaglio e stipula cessazione degli
Contratto e delle contrattuale di relativi allegati del contratto effetti del Contratto
logiche sottese al massima (Griglia tecnici
contratto
contratto in Contrattuale)
vita del
Funzione delle
criticità Progettuali
Assenza di verifiche Mancanza di Mancanza di studio Stesura di un Perdita di dominio Carenza di
rispetto alla liceità approfondimento di e approfondimento contratto generico, sul contratto attenzione nella
del progetto e alla quale sarà l’oggetto delle criticità non aderente alle Accettazione dei gestione del
Patologie Legali
sua conformità alle del contratto che specifiche di cui specifiche del contratti dei contratto
regolamentazioni dovrà essere potrà risentire il progetto. fornitori Mancata attivazione
aziendali e stipulato contratto Assenza di reali Negoziazione delle di possibili tutele
infragruppo Errata impostazione tutele sole tutele legali Perdita di diritti
del contratto Perdita di potere Accettazione di
negoziale per comportamenti
mancanza di difformi da quanto
dominio sul contrattualizzato
contrattoIl ciclo di vita dei Sistemi Informativi
PIANIFICAZIONE SVILUPPO GESTIONE
Indagine Studio di fattibilità
Ricerca della soluzione Progettazione
preliminare tecnica / economica
migliore Identificazione della Realizzazione Esercizio
(Definizione degli (Analisi degli impatti
(Software & Partner soluzione migliore Test Check up
obiettivi e delle organizzativi e
Selection) Avviamento
specifiche funzionali) tecnologici)
Diritti d’autore
Identificazione delle Diritti d’autore
Condivisione con i Diritti sulle banche dati
Impostazione e aree logiche in cui Diritti sulle banche dati
fornitori delle macro Responsabilità sui dati
stesura degli allegati suddividere il contratto Formazione
specifiche contrattuali personali
tecnici del contratto (Copertura delle Redazione del Documentazione
(Offerta chiusa vs. Time & Obbligo di
(Specifiche funzionali specifiche funzionali, contratto Manutenzione
Materials collaborazione
e obiettivi del delle attività tecniche, di Garanzie
Prestazioni di Servizi vs. Controlli
progetto) change management, Responsabilità
Appalto d’opera) Sviluppo software
ecc.) Norme etiche
Collaudo
Valutazione della conformità del progetto alle Responsabilità contrattuale
norme di legge Applicazione norme civilistiche
Responsabilità
(Non è possibile implementare un sistema di Applicazione delle normative specifiche per il diritto dell’informatica
precontrattuale
controllo occulto dei lavoratori posto in essere Eventuale responsabilità penale
attraverso la strumentazione informatica) Gestione Controversie
731.Valutazione 2.Pianificazione 3.Selezione 4.Implementazione La fase di Implementazione • L'Organizzazione e il controllo del progetto • La gestione dei rischi di progetto
4.Implementazione e Sistemi di Governance
Meccanismi Organizzativi di Gestione
Nella preparazione del progetto è necessario istituire tutti 4. Implementazione e Sistemi
quei meccanismi organizzativi necessari alla gestione del
progetto di Governance
• Organigramma
• Definizione struttura dei comitati guida ed operativi
• Mansionari dei singoli ruoli organizzativi
• Eventuali Sistemi di incentivazione
• ….
Implementazione
Progetto xxx
Sistemi di Governance Set Up di
Progetto e
definizione dei Progetto yyy
• La realizzazione di un nuovo sistema informativo deve
Meccanismi di
procedere di pari passo con la verifica dell’adeguatezza degli
Gestione Progetto zzz
strumenti di IT governance
• Una volta rivisto il portafoglio applicativo è fondamentale
porre attenzione al tema del mantenimento di una buona
coerenza tra Sistema Informativo ed esigenze aziendali
• Il tema centrale in questa fase è la scelta/conferma del
meccanismo di orientamento del Sistema Informativo Sistema di Governance
Cultura e Persone
Meccanismi di Orientamento
Portafoglio Applicativo
Infrastrutture TecnologicheOrganizzazione operativa del Progetto
Fase di rilevazione BR
• L’attività verrà condotta attraverso l’istituzione di un organo specifico con l’incarico di coordinare il
Programma, inteso come l’attuazione dei filoni progettuali dedicati al Disegno dell’Achitettura, alla
Rilevazione dei BR ed alla loro formalizzazione
• La responsabilità di formulare e definire i BR sarà assegnata a Team specializzati per area di Processo, la cui
composizione sarà costituita dai Ruoli previsti nel Modello di riferimento, descritti nel seguito:
Coordinamento del
Programma
Team 1 Team 2 ………… Team n
Team Leader
Coordinatore Process Owner
Business Analyst Key User/User
IT
HR support ControllerPuoi anche leggere
