Tecniche di Problem Management secondo ITIL

IT Infrastructure Library ™ (ITIL ®) nella pubblicazione Service Operation, nello specifico processo di Problem Management descrive le fasi del metodo di analisi della causa principale denominato Kepner-Tregoe - Definire e descrivere il problema, Stabilire le possibili cause, Testare la causa più probabile e Verificare la vera causa.

ITIL pur citando Kepner-Tregoe, non fornisce dei dettagli sufficienti e pratici per usarlo nella risoluzione di problemi difficili, pertanto questo ha comportato che la maggior parte degli analisti di fatto non applicano la tecnica di Kepner-Tregoe. Si basano invece su idee preconcette e spesso saltano dei passi importanti. Poi, senza un piano e nella “disperazione” ricadono sulla vecchia buona tecnica "nel dubbio cambialo".

Prendersi del tempo per usare Kepner-Tregoe può portare a notevoli miglioramenti nella risoluzione dei problemi e fornire correzioni permanenti per evitare problemi futuri. Di seguito viene fornito un modello per l'utilizzo di Kepner-Tregoe che i Problem Manager e coloro che sono coinvolti nella risoluzione dei problemi possono utilizzare per accelerare l'analisi delle cause.

Il metodo

Il vero nome è Kepner - Tregoe Problem Solving and Decision Making (PSDM) . Si chiama Kepner-Tregoe la parte di PSDM alla quale ITIL fa riferimento per l’Analisi del problema. L’Analisi del problema aiuta il professionista a prendere decisioni sagge .Fornisce un processo per identificare e risolvere tutti i problemi che circondano una decisione. Come strumento di risoluzione dei problemi, L’Analisi del problema consente di evitare di saltare alle conclusioni.

Degli analisti poco esperti tendono ad utilizzare le intuizioni, l’istinto e l’intuito. Questi singoli atti di eroismo possono apparire brillanti, ma possono anche provocare più problemi portando a saltare a conclusioni spesso composte o allargare il problema invece di risolverlo.

L’Analisi del problema sfrutta la conoscenza combinata, l'esperienza , l'intuizione ed il giudizio di un gruppo, con conseguente decisioni migliori e più rapide. L’utilizzo dell'Analisi del problema per supportare il Problem Management non solo è condotta da un gruppo unito, ma anche aiuta a identificare la causa principale.

Il processo di Analisi del problema è suddiviso in 5 step, in ciascuno dei quali prendere una decisione:

1. Definire il Problema
2. Descrivere il Problema
3. Stabilire le possibili cause
4. Testare la causa più probabile
5. Verificare la vera causa

1. Definire il Problema

L’Analisi del problema inizia con la definizione del problema.

Il team di Problem management non può sottovalutare questo passo fondamentale.

Non comprendere esattamente quale sia la criticità comporta molto spesso una perdita di tempo prezioso. Molti analisti inesperti considerano questo step una inutile perdita di tempo poiché credono di sapere già che cosa andare a fare – e questo è l’errore tipico che viene fatto da molti. Questi preconcetti spesso comportano un aumento della durata dell’interruzione ed anche dell’estensione del problema a causa di una scarsa capacità di giudizio.

Dal momento che la gestione del problema diventa un esercizio di squadra, è importante costituire un gruppo che comprenda il problema.

Prendi in considerazione i seguenti esempi. Una scarsa definizione del problema potrebbe essere la seguente: “Il server si è bloccato.”

Mentre una migliore definizione dovrebbe includere un maggior numero di informazioni. Un buon modello per chiarire le affermazioni di tutte le tipologie è il metodo Goal Question Metric (GQM). Il quale si traduce in una più chiara definizione dell’Oggetto, Scopo, Focus, Ambiente e Punto di vista. Ciò si traduce in una dichiarazione chiara e facilmente comprensibile.

Una definizione più chiara del problema potrebbe essere:

"Il sistema di posta elettronica si è bloccato dopo che il terzo turno di supporto ha installato una hot-fix XYZ al Server Exchange 123."

Nello sviluppo di una definizione del problema usa sempre la "Tecnica 5 Why" per arrivare al punto in cui non vi è alcuna spiegazione per il problema. l’utilizzo dei 5 perché con Kepner - Tregoe ne accelera il processo .

2. Descrivere il Problema

Descrivendo il problema con una chiara definizione del problema, il passo successivo è quello di descrivere il problema in dettaglio. La seguente tabella fornisce un bel modello per questa attività. È possibile farlo utilizzando una scheda di presentazione, cartacea o elettronica. La Tabella 1 descrive il foglio di base utilizzato nel processo.

Il foglio di lavoro descrive i quattro aspetti di qualsiasi problema: What che cosa è, Where dove si verifica, When quando si è verificato, e Extent la misura in cui si è verificato. La colonna IS offre spazio per descrivere le specifiche sul problema - quale sia il problema. La colonna COULD BE but IS NOT fornisce lo spazio per elencare le specifiche associate, ma escluso - che cosa COULD BE but IS NOT. Queste due colonne aiutano ad eliminare le ipotesi "intuitive ma non corrette" sul problema. Con le colonne uno e due completate, la terza colonna fornisce lo spazio per dettagliare le differenze tra la IS e COULD BE but IS NOT.

Queste differenze sono alla base della risoluzione dei problemi. L'ultima colonna fornisce lo spazio per elencare tutte le modifiche apportate che potrebbero spiegare le differenze.

3. Stabilire le possibili cause

Chiunque abbia trascorso del tempo nella risoluzione dei problemi è in grado di vedere "cosa è cambiato da quando ha funzionato" e avviare la risoluzione dei problemi attraverso il controllo di eventuali modifiche. Il problema è che possono verificarsi molti cambiamenti, e questo complica le cose. L’Analisi del problema può aiutare descrivendo quale sia il problema e quale sia il problema che potrebbe essere, ma non è.

Per esempio:

Problema:. "Il sistema di posta elettronica si è fermato dopo che il 3° turzo di supporto tecnico ha installato una hot-fix XYZ sul Server Exchange 123".

L’esperienza (e le migliori pratiche), ci hanno portato ad indicare quale probabile causa principale del problema qualche cambiamento recente.

Con il foglio di lavoro completato, alcune nuove possibili soluzioni diventano evidenti. Come illustrato sopra appare evidente che la causa principale è probabilmente procedurale, per il fatto il venditore non ha applicato le procedure hot-fix, ma piuttosto ha fornito l'hot-fix all’azienda.

4. Testare la causa più probabile

Con un breve elenco di possibili cause (valutazione delle recenti modifiche trasformate in un elenco), il passo successivo è pensare-attraverso ogni possibile problema. I seguenti possono aiutare in questo processo.

Porre la domanda:

"Se ____ è la causa principale di questo problema non spiega il problema IS e che cosa il problema COULD BE but IS NOT ? "

Se questa potenziale soluzione è la causa principale allora la soluzione potenziale deve "mappare" o "adattarsi" a tutti gli aspetti del foglio di lavoro dell’Analisi del problema. Utilizzare un foglio di lavoro come quello mostrato in figura 3 può aiutare ad organizzare il vostro pensiero circa le possibili soluzioni.

5. Verificare la vera causa

Il passo successive è quello di confrontare le possibili cause (tabella 3) con la descrizione del problema (tabella2). Eliminando le possibili soluzioni che non sono in grado di spiegare la situazione, e focalizzandosi su quelle rimanti. Ma prima di effettuare alcuna modifica sarà opportuno verificare che la soluzione proposta possa essere la causa, la mancata verifica della vera causa invaliderebbe l’intero esercizio e sarebbe equivalente ad andare a caso. Solo dopo aver verificato la vera causa, potrai proporre l’azione richiesta per porre rimedio al problema.

È altresì importante pensare anche a come poter prevenire simili problematiche in futuro, pertanto il Problem Manager dovrebbe prendere in considerazione come questa criticità è emersa, attraverso una serie di domande mirate:

• In quale altra situazione sarebbe potuto accadere?
• Ci sono state altre occorrenze del medesimo problema in passato?
• Anche altre procedure hanno bisogno di essere modificate?

Conclusioni

La tecnica dell’Analisi del problema di Kepner-Tregoe venne utilizzata dalla NASA per la risoluzione del problema di Apollo XIII – anche se i tecnici non credevano nei benefici, seguirono il processo e salvarono la missione. Il resto del racconto, come dicono loro è Storia…

Anche senza molto tempo a disposizione, l’applicazione della tecnica può comportare dei risultati molto efficienti nella risoluzione dei problem. Integrata con altre tecniche come 5 Why ed i diagrammi di Ishikawa, un Problem Manager può catturare l’esperienza e la conoscenza di un team, che quando combinata con l’Analisi del problema di Kepner-Tregoe i risultati sono sorprendenti.