Operare entro l’ITladeliafrancesco.altervista.org/AcademyMitechSAPSite/...•SAP R/3 fornisce una...

transcript

Operare entro l’IT - 1 © Ing. Giulio Destri - 2015

Ing. Giulio Destri

Il Project Management

nei progetti IT

Operare entro l’IT

Università degli Studi di Parma Corso di Laurea in Informatica

Dr. Ing. Giulio Destri, Ph.D.

http://www.linkedin.com/giuliodestri

http://www.peopletrezero.com/chi-siamo/giulio-destri/

http://www.giuliodestri.it/articoli

giulio.destri@unipr.it – giulio.destri@peopletrezero.com

twitter.com/GiulioDestri

ICT Governance & Management Advisor @ People 3.0

Professore a contratto di Sistemi Informativi e (fino al 2009) di Ingegneria del Software @ Università of Parma

Argomenti

• Macro-categorie di applicativi: ERP, CRM, documentale…

• I servizi associati agli applicativi

• Team e ruoli entro i sistemi informativi

• Il concetto di Business Continuity

• Cosa succede quando le cose non funzionano?

Argomenti (2)

• Definizione di event, incident, problem

• Procedure di funzionamento e di risoluzione

• Strumenti per rappresentare le procedure

• Cenni al ruolo del consulente SAP

Macro-categorie di applicativi

L’azienda/ente informatizzata

ARC - 39 1 0 % _

Internet Vendite

Clienti

servizi marketing

Codesign

Intranet

Extranet

Porter, Anthony e gli applicativi

ERP SCM

Relazione fra categorie (struttura storica)

Gestione informazioni (MIS)

Elaborazione transazioni (TPS) Gestione conoscenza (KWS)

Office Automation

Supporto alle decisioni (DSS)

Supporto direzionale (ESS)

• Applicazioni gestionali (ERP)

• Applicazioni per la gestione dei processi

di fornitura (SCM)

• Applicazioni per la gestione delle

relazioni con i clienti (CRM)

• Applicazioni per la gestione della

conoscenza (KMS)

Il passaggio ai sistemi integrati

• Enterprise Resource Planning

• Sistema IT integrato per la gestione

• Copre tutti i processi più importanti in

un’azienda

• Ciclo attivo e passivo (vendite e acquisti)

• Contabilità

• Logistica

• Human resource management

• Produzione

Cos’è un ERP?

• Software modulare e configurabile che si

appoggia sulla tecnologia relazionale (e a

oggetti)

• Basato su tecnologia relazionale (RDBMS) e

(spesso) object-oriented

• Assetto per processi

Cos’è un ERP? La struttura

Architettura Client/Server 3-tier

(presentazione, applicazione e

database)

Tipica architettura “fisica” di un ERP

Applicazioni di SAP R/3

• SAP R/3 fornisce una serie di ambienti che sono

costituiti da un insieme di applicazioni chiamate

Applicazioni R/3.

• Le applicazioni R/3 sono di tipologie diverse, tra

queste hanno particolare importanza le

Applicazioni Client.

Applicazioni di SAP R/3

• Le Applicazioni Client sono tutte le applicazioni

che possono essere sviluppate per interrogare il

sistema gestionale al fine di effettuare una o più

transazioni su SAP.

• I linguaggi con cui possono essere scritte tali

applicazioni sono i più diffusi linguaggi funzionali

ed ad eventi (C, C++, Java, .NET).

Middleware di SAP R/3

• Il middleware è costituito dall’insieme di

tecnologie di interfaccia che permette di mettere

in comunicazione il sistema SAP R/3 sia con

l’hardware e software di base e sia con le

Applicazioni R/3.

• Quindi permettere, per esempio, di far

“dialogare” il sistema SAP e un Database,

usando comandi in SQL standard.

Middleware di SAP R/3

• Verso la parte alta dell’architettura SAP, cioè le

Applicazioni R/3, il middleware utilizza, nella

maggior parte dei casi, API (Application

Programming Interface) specifiche.

• In particolare nello sviluppo di Applicazioni

Client vengono usati moduli

• RFC (Remote Function Call)

• BAPI (Business Application Programming Interface)

• SAP R/3 di SAP AG (Germania)

• E-Business Suite di Oracle (USA)

• PeopleSoft Enterprise di Oracle (USA)

• JD Edwards EnterpriseOne di Oracle

• Baan di SSA Global (USA)

• Altri…

Il mercato degli ERP Internazionali

• Il CRM è un sistema di interazione con i clienti

• che integra i dati provenienti dai diversi canali di contatto

• in un’unica base dati, condivisa da ogni area dell’azienda preposta al contatto con il cliente:

– marketing,

– vendite,

– customer service

CRM: definizione base

La visione CRM

• Il CRM è l’insieme di strategia, processi, cultura e tecnologia,

• che consente alle organizzazioni di incrementare le performance ed aumentare il valore

• attraverso una migliore comprensione dei bisogni dei clienti

Accezione più ampia

• Il CRM non è solo tecnologia, benché essa rappresenti un importante fattore abilitante;

• non è solo marketing, poiché deve coinvolgere tutta l’organizzazione in un cambiamento che è innanzitutto di tipo culturale

Una prospettiva

• Alla base di un approccio di marketing supportato da un sistema di Customer Relationship Management, vi è un circolo virtuoso che si sviluppa attraverso quattro fasi e si divide in due macro-componenti

Azioni

Impreviste

dal cliente

INTERAGIRE

Esecuzione

di campagne

ed azioni mirate

APPRENDERE

E PERSONALIZZARE

Tracciare ed

analizzare le

azioni/reazioni

DIFFERENZIARE

Campagne/azioni

di marketing mirate

IDENTIFICARE

E SEGMENTARE

Le fasce di clienti

e le analisi di marketing

Definizione fonti

Ideazione del

DB dei clienti

Alimentazione

continua del DB

Ipotesi

Prospetti

Clienti piccoli

Clienti medi

Clienti grandi

Clienti top

Operativo CRM

Analitico

I macrocomponenti: CRM operativo

• Preposto alla mappatura e integrazione di tutti i canali di contatto con il cliente

• Ma anche all'esecuzione materiale di tutte le campagne ed azioni di marketing rivolte al cliente

I macrocomponenti: CRM analitico

• Preposto all'analisi dei dati provenienti dalla componente operativa e dai sistemi gestionali (ERP) per – profilazione,

– segmentazione

– valutazione dei clienti,

• al fine di – Ideare le offerte,

– Ideare le campagne di marketing più adeguate

• Presuppone l'esistenza di un Customer DataWarehouse che integra i dati dalle numerose fonti e ne facilita l'accesso

Analisi dei dati: business intelligence

• Insieme di applicazioni e tecnologie per l’analisi dei dati

• Comprende:

– DSS (Decision Support System)

– Query e Report

– OLAP (Online Analytical Processing)

– Analisi statistiche

– Modelli previsionali

– Data Mining

Business intelligence: scopi

• Reportistica direzionale

• Cruscotti aziendali

• Strumenti avanzati di navigazione nei dati

• Proiezioni territoriali dinamiche

• Sistemi predittivi

Business intelligence: ricavare i dati

• Retrieve Data

• Transform Data

• Populate Data Warehouse

• Populate Data Mart / OLAP

• Query Data

Extract Transform and Load(ing): ETL

• Fase di estrazione di dati dalla base dati di produzione

• Fase di trasformazione dei dati nella rappresentazione più adatta all’analisi da effettuare

• Fase di caricamento dei dati nella base dati del programma di analisi

IL Data Warehouse

• “Magazzino di dati” a livello di impresa

• Insieme di strumenti per convertire un vasto insieme di dati in informazioni utilizzabili dall’utente

• Obiettivi:

– Possibilità di accedere a tutti i dati dell’impresa, centralizzati in un solo database

– Coerenza e consolidamento dei dati

– Velocità nell nell’accesso alle informazioni

– Supporto per l’analisi dei dati

Il Data Mart

• “Magazzino di dati” a livello dipartimentale

• E’ un segmento di un Data Warehouse

• E’ fisicamente realizzato come un Data Warehouse, ma con una finalità più ristretta:

– I dati coprono solo alcune aree aziendali (ad es. vendite)

– Minori costi di realizzazione

– Risultati più vicini nel tempo

I flussi associati al Data Warehouse

Sistemi OLTP di produzione (es. ERP)

Data Warehouse Data Mart(s)

Postazioni client

I servizi associati agli applicativi

• FI – Financial Accounting

• CO – Controlling

• PP – Production Planning

• MM – Materials Management

• SD – Sales and Distribution

• AM – Fixed Assets Management

• PS – Project System

• WF – Work Flow

Esempio: le funzioni di SAP

Livello

Business

Livello

Applicazioni

Livello

Tecnologia

Servizio 1

Ambiente

Esterno

Clienti

Finali Processo 1 Processo 2 Processo 3

Servizio 2 Servizio 3 Servizio 4

Server Storage Rete

Servizi

supporto

Componenti server

Catalogo servizi business

Librerie

Catalogo servizi tecnici

Prodotti/Servizi

ITIL Service Catalogue (2/2)

Fornitori

Prodotti/Servizi

Gli elementi degli applicativi

• Ogni elemento che ricopre funzione specifica

• E che può essere “spento” senza influenzare gli altri

• Diventa un singolo servizio

• Ogni servizio ha un valore, dipendente dal processo che supporta

Team e ruoli entro i sistema

informativi

Dentro i sistemi informativi

• Per garantire il corretto funzionamento dei servizi esistono appositi processi e procedure

• Le persone operano seguendo ruoli precisi, in base alla propria professionalità

Profili nei contesti di esercizio (lato cliente)

• Utente (finale) del sistema

• Utente (evoluto) del sistema (key user)

• Amministratore di informatica utente

• Amministratore di sistema (sistemista)

• Amministratore di rete

• Amministratore di DB (DBA)

• Responsabile sistemi informatici (anche chiamato EDP manager)

L’utente

• E’ l’utilizzatore del sistema ICT in esame

• Svolge il suo lavoro, entro il quale il sistema si inserisce

• Molto spesso non ha competenza informatica

• L’atteggiamento verso l’ICT è molto spesso quello di considerarlo “un male necessario”

Key User

• E’ l’utilizzatore «senior» del sistema ICT

in esame

• Conosce molto bene i processi cui il sistema offre servizi

• Ha un minimo di competenza informatica

• E’ incaricato di spiegare a fornitori esterni e dipartimento IT esigenze particolai

Amministratore di informatica utente

• E’ un sistemista

• Si occupa delle postazioni utente e di scanner/stampanti/fax/plotter

• Segue anche le problematiche di applicativi utente come la suite Office

• Spesso deve occuparsi anche dell’hardware

Sistemista

• E’ l’amministratore di server, e anche di applicativi

• In sistemi grandi possono esserci diversi sistemisti, ognuno dedicato a una sola delle suddette cose

• Deve garantire il buon funzionamento costante di quanto a lui affidato

• Spesso tiene anche i rapporti con gli utilizzatori finali

Sistemista di rete

• E’ l’amministratore della rete.

• Deve garantire il funzionamento costante della connessione verso Internet e delle reti interne

Sistemista DB (DBA)

• E’ l’amministratore del database server

• Deve garantire il buon funzionamento costante del DB con anche l’integrità dei dati e l’ottimizzazione dei tempi di accesso ai medesimi

• Il suo ruolo è fondamentale dove esistano grandi moli di dati (es. grandi aziende, banche, enti pubblici)

EDP Manager

• Coordina tutta l’attività del sistema informativo

• E’ il responsabile aziendale di alcune funzioni (spesso anche dei dati)

• La sua evoluzione è il CIO (Chief Information Officer)

Profili per i progetti ERP (lato fornitore)

• Cliente

• Analista funzionale

• Progettista completo

• Analista di processo

• Programmatore

• Capo progetto

Progettista completo

• Ha grande esperienza sia nell’analisi di

processo, sia nell’uso dell’ERP in questione

• Deve suddividere le aree funzionali dell’azienda in parti “mappabili” sui moduli che formano l’ERP

Analista di processo

• Conosce bene uno o più processi e le

funzioni svolte dal modulo che lo implementa

• Definisce nel dettaglio che variazioni devono essere fatte nei processi aziendali o che personalizzazioni devono essere introdotte nell’ERP

Programmatore

• Nel mondo ERP il programmatore può

usare un linguaggio proprietario (4GL) per customizzare l’ERP

• Talvolta i cambiamenti sono semplici parametrizzazioni dell’ERP stesso

Analista funzionale

• Ha esperienza di analisi di processo

• Ha compreso il processo (lavorando con il cliente)

• Scrive le specifiche funzionali di dettaglio

Standard dei profili professionali e ambiti

Il concetto di business continuity

Definizione di Business Continuity

• Detta anche continuità aziendale

• Capacità di un sistema di erogare i servizi previsti, rispettando gli SLA (compiere le funzionalità previste per l’organizzazione)

• Comprende sia gli aspetti strettamente organizzativi, logistici e comunicativi

• Sia la continuità tecnologica (ICT)

Business Continuity Management

• Ha come obiettivo la capacità dell’organizzazione di continuare a eseguire le proprie attività a fronte di eventi imprevisti negativi.

• Disaster Recovery, termine relativo all’ICT, è l’insieme di procedure organizzative e tecnologiche per ripristinare dati, sistemi e infrastrutture necessari a erogare i servizi aziendali

Norme per la Business Continuity

• ISO 22301-2012: Societal security — Business continuity management systems — Requisiti

• ISO 22313-2012: Societal security — Business continuity management systems — Linee guida

• ISO 27001/2

• ISO 24762

Contesto per la Business Continuity

Fonte: Ing. N. Prampolini (AIEA-ISACA)

Disponibilità (Availability)

• Si esprime con la percentuale di tempo in cui il sistema è in grado di fornire il servizio, in un intervallo di tempo

• Esempi:

– 99% su un anno

– 99,9% su un anno

Affidabilità (Reliability)

• Il concetto di affidabilità consiste nella capacità del sistema di fornire il servizio (la risposta alle richieste utente, sia esso umano o di sistema) sempre con modi e tempi analoghi

• Modi e tempi sono definiti dagli SLA

Cosa succede quando le cose

non funzionano?

Quando le cose non funzionano…

• L’azienda ha alcuni processi bloccati

• Ci sono persone ferme ed impossibilitate ad operare

• Ci sono clienti in attesa di servizi/prodotti

• In sostanza => danno economico!

Il fermo macchina

• In un sistema aziendale, ogni periodo di fermo macchina (interruzione di servizio) provoca una perdita economica più o meno grave

• Un certo tempo di fermo macchina può essere fisiologico => finestre di manutenzione

• In ogni caso si deve minimizzare tale valore

Come si misura il costo del fermo macchina

• O = Operatori (ossia persone coinvolte)

• T = Tempo di fermo macchina

• P = Percentuale di inattività

• C = Costo di una persona

• F = Reddito prodotto da una persona

€ = O * (T * P / 100) * (C + F)

• O = 5 venditori

• T = 4 ore

• P = 60%

• C = 35 (euro per ora)

• F = 100 (euro per ora)

5 * (4 * 60 / 100) * (35 + 100)

1620 €

Come si misura il costo del fermo macchina

Necessità

• Minimizzare i periodi di fermo macchina

• Salvare i dati

• Salvare le configurazioni

• Salvare le installazioni

• Archiviare dati di uso non frequente

RTO Recovery Time Objective

• Tempo entro il quale deve essere ripristinato un servizio;

• include i tempi di ripristino sistemi, TLC, recupero dati, ripristino applicazioni e accesso degli utenti;

RPO Recovery Point Objective

• Punto di aggiornamento dal quale ripartire per il ripristino del servizio;

• distanza temporale tra l’ultimo salvataggio dei dati e il verificarsi dell’evento che ne provoca la distruzione o l’indisponibilità;

MPTD Maximum Tolerable Period of Downtime

• Periodo massimo di indisponibilità (accettabile) di un servizio;

Lo sviluppo è cambiamento

• Ogni cambiamento introduce un fattore di rischio

• Anche durante lo sviluppo sono possibili errori che impattano sul nuovo e sull’esistente

Il progetto di nuovo sviluppo

Ogni nuovo servizio, prima di entrare in esercizio deve:

• Avere un’analisi dei requisiti

• Essere progettato

• Essere realizzato e testato

• Essere collaudato

• Il tutto va fatto entro un tempo pianificato!

Nuovi servizi e ritardi

• Il nuovo servizio può incontrare difficoltà impreviste durante lo sviluppo

• Dovute a molteplici cause

– Errori nei requisiti

– Errori di progettazione

– Errori di programmazione

– Problematiche tecniche

– Errori di configurazione nell’ambiente di esercizio

Risoluzione dei problemi

• Anche per i nuovi servizi la risoluzione dei problemi deve seguire procedure precise

• L’obiettivo in questo caso è minimizzare i ritardi rispetto al tempo previsto

• E gli scostamenti dal budget…

Definizione di

Incident

Problem

Definizione ITIL di event (evento)

Un evento può essere definito come ogni cosa rilevabile o distinguibile che ha importanza per la gestione dell’infrastruttura IT o per l’erogazione del servizio IT e per la valutazione dell’impatto che una deviazione potrebbe causare ai servizi.

Esempi di evento

• Un Event può essere un allarme o una notifica generati da un Servizio IT, da un Configuration Item o da uno strumento di monitoring

• Una notifica del completamento di un batch job

• Un allarme di superamento di una soglia di errore di un device

Event Management: azioni di risposta

Un event può richiedere, ad esempio:

• Il semplice riconoscimento;

• Un intervento manuale;

• L’apertura di un incident;

• Event Management:

• Conoscere lo stato dell’infrastruttura e rilevare ogni scostamento dalle normali condizioni di operatività.

Event Management: capacità

• La capacità di individuare eventi e determinare le opportune azioni di controllo sono svolte dall’Event Management che è quindi la base per il monitoraggio operativo e di controllo.

• Se questi eventi sono programmati per comunicare informazioni operative possono essere utilizzate come base per l’automazione di molte attività di routine dell’Operation Management:

• ad esempio, l’esecuzione di script su dispositivi remoti, l’invio di job per il processamento o addirittura di bilanciamento dinamico della domanda di un servizio su più dispositivi per migliorare le prestazioni.

Definizione ITIL di Incident

• Una interruzione non pianificata di un servizio IT o la riduzione della qualità di un servizio IT.

• Il guasto di un configuration item che non ha ancora impattato sul servizio è già un incidente.

• Ad esempio, il malfunzionamento di un disco da un mirror set.

Il processo dell’Incident Management

• L’Incident Management è il processo per il trattamento di tutti gli incidenti;

• può includere malfunzionamenti, domande o richieste segnalate dagli utenti (di solito tramite una telefonata al Service Desk), da personale tecnico o individuate automaticamente e riportate da strumenti di monitoraggio.

Finalità dell’Incident Management

• La finalità principale del processo di Incident Management è il ripristino del normale funzionamento del Servizio nel più breve tempo possibile minimizzando impatto negativo delle funzioni di business, assicurando così che siano mantenuti i miglior livelli possibili di qualità e disponibilità del servizio.

• “Funzionamento normale del Servizio” è inteso qui come funzionamento all’interno dei limiti di SLA concordati.

Processo: Incident Prioritization

• Un altro aspetto importante del tracciamento di ogni incidente è l’assegnazione di un codice appropriato e concordato di priorità, giacché questo determina come l’incidente verrà gestito sia dagli strumenti che dal personale di supporto;

• La Priorità di solito viene assegnata considerando sia l’urgenza dell’incidente (quanto rapidamente è necessaria ripristinare il servizio secondo il business) sia il livello di impatto.

• Una idea dell’impatto è spesso (ma non sempre) data dal numero di utenti interessati.

Impatto (Impact): definizione

• Grado di deviazione dal normale livello di servizio, in termini di numero di utenti o di processi di business interessati.

• Gli Incidenti Critici (Major Incident) sono quelli per i quali l’impatto sugli utenti è grave.

• Gli Incidenti che si protraggono nel tempo, anche se relativi a una percentuale ridotta di utenti, devono essere considerati come incidenti critici.

Urgenza (Urgency): definizione

Ritardo accettabile per l’utente o per i processi di business per risolvere l'incidente.

Incident Management prioritizzazione

Impatto

Urgenza Alto Medio Basso

Alta 1 2 3

Media 2 3 4

Bassa 3 4 5

Codice Descrizione

Tempo di

risoluzione

1 Critica 1 h

2 Alta 8 h

3 Media 24 h

4 Bassa 48 h

5 Pianificabile Da stabilire

Definizione ITIL di Problema (Problem)

ITIL definisce un Problem come la causa sconosciuta di uno o più incidenti.

Scopo del Problem Management

• Il Problem Management è il processo responsabile per la gestione del ciclo di vita di tutti i problemi.

• Gli obiettivi principali del Problem Management sono quelli di prevenire i problemi e i conseguenti incidenti, eliminare gli incidenti ricorrenti e minimizzare l’impatto degli incidenti non evitati.

Ambito del Problem Management

• Il Problem Management comprende tutte quelle attività necessarie per individuare la root cause degli incidenti e trovare una soluzione per i relativi problemi.

• È inoltre responsabile al fine di assicurare che la soluzione sia implementata attraverso le appropriate procedure.

Definizione di issue

• In ambito sviluppo issue può indicare un event, un incident o un problem

• Quindi, genericamente, un «avvenimento» che ha impatto sullo sviluppo

Procedure di funzionamento e

risoluzione

Il normale funzionamento

• I sistemi informatici non funzionano da soli

• Ci sono continui cambiamenti ed adattamenti (ad esempio: gestione degli utenti)

• Ci sono le normali operazioni (ad esempio: backup)

• Ci sono le risoluzioni di event e incident…

La soluzione di problemi e…

L’obiettivo della soluzione è

• Ripristinare il normale funzionamento del servizio (definito dagli SLA)

• Nel più breve tempo possibile

• Salvaguardando i dati fino all’RPO

• Minimizzando l’impatto ed i costi del guasto

Per risolvere rapidamente…

• Non c’e’ spazio per l’improvvisazione

• Bisogna seguire procedure precise, operando entro processi

• Ognuno ha un ruolo

• Ognuno può fare fino ad un punto, poi passa la palla ad un altro membro del team

Strumenti per rappresentare le

procedure

Come mettere insieme profili e processi?

Per sapere con precisione chi fa cosa, serve

• Conoscere esattamente la struttura del processo (insieme di attività)

• Conoscere i ruoli entro ciascuna delle attività

Work Breakdown Structure (WBS) - 1

• Scomposizione strutturale del lavoro

• Rappresenta in modo strutturato e gerarchico tutte le attività che richiedono tempo e risorse

• Componenti base e grado di dettaglio sono determinati in base allo scopo

Work Breakdown Structure (WBS) - 2

• Risponde nei minimi dettagli alla domanda “Cosa si deve fare”?

• Pensabile come derivata dalla scomposizione in azioni delle attività di un activity diagram

Organization Breakdown Structure (OBS)

• E’ una scomposizione gerarchica delle responsabilità di progetto

• Generata allo scopo di individuare univocamente i responsabili dei vari elementi del lavoro previsto

Strumenti e loro uso

WBS: dettagli di cosa

si deve fare

OBS: dettagli di chi sono

i responsabili

RACI: assegnazione delle responsabilità e dei ruoli

Matrice delle responsabilità o RACI

• Chiamata anche Linear Responsability Chart (LRC) o Responsability Assignement Matrix (RAM), in realtà ne è una possibile implementazione

• Visione tabellare della responsabilità organizzativa

• Integra l’organigramma

• Incrocia le attività o fasi del processo con le strutture o con loro parti

Come nasce la RACI

• Si può pensare alla RACI come nata dall’incrocio della WBS con la OBS

• Obbliga ad assegnare una responsabilità univoca e nominale per ciascuno degli elementi di lavoro individuati nella WBS

RACI versione base

• Responsible (Responsabile dell’esecuzione): la persona o le persone che svolgono il lavoro

• Accountable (Autorizzante: Capo/Persona che autorizza e guida l’attività): soltanto una persona può essere accountable per ogni task

• Consulted (Consultato/contributore): le persone che possono essere consultate e di cui sono ritenute importanti le opinioni

• Informed (Informato): le persone che sono tenute aggiornate sui progressi conseguiti

Come nasce la RACI

Esempio: ordine dal cliente

Fliale Dir. Com.

Dir. Distr.

Magazzino

Contab. Cli.

Ricezione ordine

R A I I C

Evasione ordine da magazzino

I A R I

Spedizione I A C R I

Fatturazione I I R

A = decide/approva R = esegue I = è informato C = assiste

Esempio IT: Incident Management

A = approva/decide R = realizza/esegue I = (è) informato C = contribuisce

RACI: perchè?

• Per ufficializzare le responsabilità delle fasi di progetto e dei deliverable

• Per responsabilizzare gli attori del progetto sul dettaglio del lavoro di progetto

• Per facilitare il Project Manager nell’indirizzamento al responsabile della particolare fase/deliverable

RACI: perchè?

• Per evitare l’insorgere del fenomeno degli alibi

• Per chiarire a tutti i livelli di responsabilità

• Solo un accountable per ogni attività!

RACI: estensioni

RACI-VS con ulteriori due ruoli:

• Verifies (Verifica): la persona o il gruppo di persone che controlla se sono stati raggiunti i criteri di accettazione del lavoro;

• Signs off (Firma, Approva): la persona che approva le decisioni verificate (V) e autorizza il rilascio del prodotto. Questo ruolo potrebbe coincidere con il ruolo Accountable.

RASCI con un ruolo in più:

• Supportive (supporta): questo ruolo fornisce risorse aggiuntive per svolgere il lavoro oppure, ad esempio, gioca un ruolo di supporto nell’implementazione. Questo può dare benefici nell’implementazione dei servizi IT.

RACI: esempio completo esteso

RU1 RU2 RU3 RU4 RU5 RU6

Analisi R A I C C

Definizione I A C R

Gestione R A I S

Monitoraggio R A I C C S

• R = responsabile A = approva

• S = supporta C = contribuisce

• I = informato V = verifica

Cenni al ruolo del consulente SAP

Il Progetto SAP

• Assessment di massima

• Analisi (Business Blueprint, contenente AS IS e TO BE)

• Mappatura sui processi SAP

• Eventuale scrittura codice ABAP

• Test del sistema

• Formazione degli utenti

• Supporto post go live

Assessment

• Facciamo un primo assessment,

• Ci consente un dimensionamento di massima del progetto

• Ci consente di fare una proposta economica

Analisi

• Analisi dei processi business

• Metodologia standard SAP

• Business Blueprint, contenente AS IS e TO BE

Mappatura

• Versione alle differenze

• Customizzazione dei processi SAP

• Adattamento dei processi business dell’utente

Sviluppo codice ABAP

• Analisi tecnica

• Scrittura codice ABAP

• Debugging

• Test unitario

Sviluppo client (esterno) SAP

• Analisi funzionale

• Analisi tecnica (con individuazione servizi SAP da usare)

• Scrittura codice client

• Debugging

• Test unitario

Test del sistema

• Test scatola nera

• Test di sistema

• Collaudo finale

Formazione utenti

• Studio degli utenti

• Formazione sui nuovi moduli installati

• Importanza della comunicazione…

Supporto

• Garanzia di servizio

• Manutenzione ordinaria

• Manutenzione evolutiva

I requisiti

• La raccolta dei requisiti è spesso considerata l’attività più difficile, perché richiede la collaborazione tra più gruppi di partecipanti con differenti background.

• La raccolta dei requisiti ha l’impatto potenzialmente maggiore su tutte le fasi successive

Deve essere fatta al meglio!

Sommario

• Macro-categorie di applicativi: ERP, CRM, documentale…

• I servizi associati agli applicativi

• Team e ruoli entro i sistemi informativi

• Il concetto di Business Continuity

• Cosa succede quando le cose non funzionano?

Sommario(2)

• Definizione di event, incident, problem

• Procedure di funzionamento e di risoluzione

• Strumenti per rappresentare le procedure

• Cenni al ruolo del consulente SAP

Operare entro l’ITladeliafrancesco.altervista.org/AcademyMitechSAPSite/...•SAP R/3 fornisce una...

Documents