PBA

Need Assessment.
Il punto di partenza è l’identificazione dei BUSINESS NEEDS.

Un Business Need può essere un problema o una opportunità-

L’analisi dei business needs è fondamentale per non avviare un progetto

con assunti non verificati o dati mancanti.

STEP 1: Identificare problemi / opportunità.

Step 1.1: Analisi Stakholders

Per identificare in modo corretto il problema / opportunità bisogna
coinvolgere le persone giuste. Per questo è opportuno stilare una RACI
degli stakeholders coinvolti:

Sponsor Direzione Responsabili di Consulente ….

Tecnica reparto
Step 1: Identificare A C C R
problemi / opportunità
Step 2: Valutare l’as is A C C R
Step 3: Definire il to be I A C R
Step 4: Valutare e C C I R
raccomandare Soluzioni
Step : Preparare il I A I R
business case

Obiettivo: prima di partire col lavoro dobbiamo sapere chi deve essere coinvolto in quale fase e a
che titolo.

Step 1.2: Investigazione

A questo punto bisogna porsi in ascolto. Spesso chi ci comunica un problema / opportunità ci offre
anche una soluzione. A volte siamo noi stessi a convincerci da subito della necessità di una certa
soluzione. Tuttavia dobbiamo fare il possibile per evitare di saltare a conclusioni senza aver
completato tutti i passaggi dell’analisi. Dopo aver identificato le persone da coinvolger nelle varie
fasi conduciamo una sorta di investigazione per capire quali sono i problemi/opportunità che
dobbiamo affrontare.
L’osservazione è svolta tramite:
- interviste alle persone definite “Consulted” nella RACI per lo step 1, che hanno come tema
l’identificazione di problemi / opportunità;
- raccolta di documenti riguardanti i problemi / opportunità segnalati
- benchmarking (confrontare il problema / opportunità con gli standard di mercato – concorrenza
per avere un ordine di grandezza)
- osservazione diretta
Il livello di dettaglio non deve essere alto. L’obiettivo è costruire una lista di “business needs” ,
ovvero problemi/opportunità.

Step1.3: Situation statements.

Una volta ottenuta la lista dei business needs su cui concentrarsi è necessario per ognuno di loro
scrivere un “Situation Statement” : un breve documento che descriva in sintesi il
problema/opportunità (A), ne chiarisca gli effetti (B) e definisca l’impatto di questi effetti (C).
A questo punto non si fanno ancora analisi sulle cause o l’impatto finanziario. Tutto è a puro livello
descrittivo.
Esempio:
L’azienda sta ricevendo moltissime richieste di supporto negli ultimi mesi (A) che hanno generato
un aumento del carico di lavoro dei tecnici (B) il che ha costretto a straordinari e assunzioni extra,
con un conseguente aumento dei costi e del livello di soddisfazione dei collaboratori (C).
Il situation statement è un modo veloce e chiaro per comunicare l’oggetto del lavoro del progetto
che stiamo prospettando, prima di impegnare risorse nel lavoro stesso. L’obiettivo è che il cliente
approvi formalmente tutti i situation statements. Questo dà il formale “via” al lavoro.

GATE: approvazione del cliente sui situation statements. (proposta e accettazione preventivo)

STEP 2: Valutare As Is

2.1 Goal & Objectives? Ci sono? Se si vanno studiati. Se no Vanno definiti.

Definire Goal & Objectives: Hoshin Kanri (Mission, STEEP, SWOT, Vision – reflection question &
affinity diagram, Relation Diagram, Radar diagram, etc..)

Goals & Objectives presenti: acquisire

Acquisire in ogni caso organigramma; bilancio; policies e regole aziendali; standard in cui operano;
budget plan… in breve tutti i EEF & OPA.

L’acquisizione (o definizione) di G&O serve da contesto al progetto. Ci fa capire i limiti entro cui
opera, i criteri con i quali il business valuta cosa è importante, cosa si aspetta e cosa non vuole.

Obiettivo: Lista dei Business Requirements di alto livello, lista di EEF & OPA, da usare come
riferimenti e guida, valutazione maturità azienda, cultura aziendale, grado di preparazione al
cambiamento.

2.2 Root Cause Analysis

Bisogna analizzare a fondo le cause che hanno portato al probelma o che hanno prospettato una
opportunità.

In base alla situazione usare: 5whys, Ishikawa, Relation Diagram, Process flow

2.3 Capabilities analysis

Bisogna analizzare le risorse in mano all’organizzazione per realizzare i suoi obiettivi. Tramite una
serie di tabelle bisogna mappare:
Persone / Assets Tecnogici / Processi in base al livello di maturità.
Per ogni riga della tabella si deve creare una tabella specifica per esplodere le capacità specifiche
presenti e mapparle in base al livello di maturità (maturity model).
Es framework delle competenze:
Livello iniziale Livello 1 Livello 2 Livello 3
(nessun tipo di (Gestito (Gestito (Gestito e
gestione) sporadicamente) regolarmente) continuamente
migliorato)
Persone Responsabile Commerciale HR
tecnico
Tecnologia Sistemi di Sistemi SW Finanziario
pianificazione comunicazione
lavoro
Processi Processo di Processo di Processo di
pianificazione vendita gestione
finanziaria

Es tabella competenze specifica:

Responsabile tecnico Livello iniziale Livello 1 Livello 2 Livello 3
Organizzazione del X
tempo
Soft Skills X
Competenza tecnica X

2.4 Redazione della relazione “as is”

Questa relazione riassume i risultati del lavoro di analisi precedente sotto forma di un documento
che deve contenere:
- Goals & Objectives
- EEF & OPA rilevanti
- Capability framework
- Risultati della root cause analysis in forma tabellare e accompagnati da diagrammi di
Pareto se i problemi o le root cause sono molte.
Esempio di capability table finale:

Problema / Root Cause Capability collegata

Opportunità
Problema 1 - causa a - mancanza di una capability
- causa b
Problema 2 - causa a - Necessario affinamento di una capability
Problema 3 - causa a - mancanza di una capability
- causa b - Necessario affinamento di una capability

Step 3: Definire il “to Be”

A partire dai situation statements e la connessa tabella delle capabilities è necessario organizzare
Brainsotrming / focus group durante i quali elicitare possibili soluzioni.
Tipicamente le soluzioni sono:
- Acquisire una capacità mancante
- Esternalizzare la capacità mancante
 - Migliorare una capacità presente al livello necessario

Per ogni problema vanno esplorate queste tre vie per tutte le soluzioni discutendole con il cliente.
Per facilitare la discussione è possibile creare diagrammi di affinità / fare benchmarking

L’output atteso è una lista delle capabilities da acquisire / migliorare / esternalizzare.

A questo punto non escludiamo nulla. Tutte le possibili soluzioni vanno tenute in conto.

Step 4: Definire e raccomandare soluzioni

La lista delle capabilities da acquisire / migliorare / esternalizzare va sottoposta ad una

valutazione.
La valutazione deve riguardare a fattibilità:
- Tecnica (è possibile da un punto di vista tecnologico)
- Organizzativa (è possibile all’interno della nostra organizzazione)
- Costi-Benefici (il costo è coperto dal beneficio atteso)
- Tempo (è possibile nei tempi necessari)
Per operare l’analisi è bene procedere con brainstorming / benchmarking / Kano analisys /
Purpose alignment / matrice soluzione capacità / Feature injection / ROI e NPV / Valutazione
parametrica

Kano:
un grafico cartesiano con all’asse x la qualità (da cattiva a buona) e all’asse y la soddisfazione del
cliente.
I prodotti possono essere:
- Basic  sono nei due quadranti in basso: per quanto alta la qualità la soddisfazione non
sarà mai alta.
- Performance  quadrante in basso a sx e alto a dx: relazione lineare tra qualità e
soddisfazione
- Delighters  sono nei due quadranti in alto: per quanto bassa la qualità la soddisfazione
sarà sempre alta.
(due casi particolari cono i prodotti “indifferenti” la soddisfazione non cambia mai e “reverse”
in cui se a qualità aumenta la soddisfazione diminuisce)
Questa tecnica serve a contestualizzare la soluzione e metterla a confronto con altre per poter fare
una scelta.

Purpose alignment:
un grafico cartesiano con all’asse x l’importanza della soluzione e all’asse y la differenziazione sul
mercato che garantisce (o se vogliamo il valore percepito dal cliente).
Soluzioni nel quadrante in basso a sx sono “who cares” : né critiche né danno valore aggiunto.
Avranno priorità bassa
Soluzioni nel quadrante in alto a sx sono “partner” non sono di importanza critica, ma hanno
effetto sul mercato quindi conviene esternalizzarle
Soluzioni nel quadrante in basso a dx sono “parity” ovvero non danno vantaggi sul mercato ma
sono critiche: meglio acquisirle.
Soluzioni nel quadrante in alto a dx garantiscono che l’azienda sia al vertice del mercato e sono un
asset fondamentale: è necessario sviluppare queste soluzioni in house.
Matrice soluzione / capacità:
una semplice tabella che mostra quali capacità ogni soluzione riesce a garantire per facilitare il
confronto:

Soluzione 1 Soluzione 2 Soluzione 3

Capacità 1 x x x
Capacità 2 x x
Capacità 3 x

Feature injection:
quando non è semplice valutar con modalità quantitative e il contesto in cui si inserisce la
soluzione p molto complesso e c’è tanta variabilità la feature injection permette di capire la
fattibilità ed il valore della soluzione. Non è altro che la costruzione di uno scenario in cui la
soluzione viene utilizzata come da scenario based design.

ROI e NPV:

classica valutazione costi / benefici. Si calcola il costo dell’acquisizione / sviluppo /

esternalizzazione della soluzione e il beneficio prodotto nell’arco del suo ciclo di vita, riportando il
valore al valore attuale del denaro (quindi includendo un tasso di interesse).

Valutazione parametrica:
si fa una tabella con l’elenco delle soluzioni nelle righe e nelle colonne i criteri con cui le valutiamo
con il relativo perso. Per ogni soluzione si dà un punteggio da 1 a 10 per ogni criterio. Il punteggio
viene moltiplicato per il peso del criterio. La somma di tutti i punteggi pesati determina la classifica
delle soluzioni.

Stage Gate: Decidere quali soluzioni applicare

Step 5: Preparare il Business Case

Creare template per i BC