Problem Management

La gestione e risoluzione di uno o più  incident può generare un “Problem”.

Vediamo cosa è un Problem e un esempio di processo di gestione e relativa risoluzione. 

Definizione e Scopo del Problem Management:

Il Problem Management è un processo volto a individuare le cause radici degli incidenti al fine di prevenirne il ripetersi. Questo processo mira a minimizzare l'impatto e la frequenza degli incidenti, migliorare la qualità del servizio e rafforzare la gestione complessiva dei servizi IT. 

Spesso, la causa è sconosciuta al momento dell'identificazione del problema, e il Problem Management è responsabile di guidare ulteriori indagini per determinare la causa radice e monitorare le azioni per la sua risoluzione. Si tratta di un processo orientato agli obiettivi che mira a ridurre l'impatto degli incidenti sull'organizzazione, migliorare l'integrità complessiva dei servizi IT - inclusa la disponibilità, ridurre i tempi di inattività e aumentare la soddisfazione del cliente.

Ogni problema è assegnato a un Problem Owner, generalmente al Problem Manager stesso. Sono responsabili di coordinare la risoluzione del problema dall'inizio alla fine in modo tempestivo ed efficace. Possono monitorare varie attività aprendo un Task. Il task può riguardare l'Analisi, l'Analisi delle Cause Radici, l'Implementazione o un argomento generale.

Il Problem Task Owner è responsabile di svolgere l'indagine eseguendo l'attività assegnata dal Problem Owner.

Stakeholders del Problem Management

Ogni problema è assegnato a un Problem Owner, generalmente al Problem Manager stesso. Sono responsabili di coordinare la risoluzione del problema dall'inizio alla fine in modo tempestivo ed efficace. Possono monitorare varie attività aprendo un Task. Il task può riguardare le fasi di Assess, Root Cause Analysis, Fix implementation o un argomento generale. Il Problem Task Owner è responsabile di svolgere l'indagine eseguendo l'attività assegnata dal Problem Owner.

Processo di Problem Management

Il processo di Problem Management include attività di diagnosi, risoluzione e implementazione di soluzioni, spesso attraverso il Change Management. Questo processo si basa sull'uso di strumenti ITSM (e.g.: ServiceNow) per tracciare e gestire i problemi in modo efficiente. Il problema passa attraverso fasi come Draft, Assess, Root Cause Analysis, Fix Implementation, Resolved e Closed, ognuna con azioni specifiche e criteri per il passaggio alla fase successiva.

• DRAFT: In questa prima fase viene segnalato, nel tool dedicato alla gestione dei problemi, la presenza di un nuovo caso e si inseriscono le informazioni disponibili con eventuali riferimenti ad incident generati dal problema
• ASSESS: In questa fase, il team di Problem Management valuta la richiesta per il nuovo record di problema. Se tutto è a posto, un Problem Manager approva il ticket, lo sposta alla fase successiva - Analisi delle Cause Radici, e apre task ai relativi stakeholder.
• ROOT CAUSE ANALYSIS: In questa fase, il problema viene ufficialmente approvato. Qui vengono aperti i task necessari ai relativi stakeholder per l'analisi delle cause radici. Essi definiscono la causa principale del problema e un piano d'azione per risolverlo definitivamente. In questa fase, ci sono diverse opzioni oltre a risolvere il problema:

o   Se la causa principale non può essere identificata (nel peggiore dei casi) e non esiste una soluzione alternativa, il Problem Manager clicca sul pulsante per aprire un task di Rischio al Proprietario dell'Applicazione.

o   Se la causa principale è identificata, ma la soluzione non può essere implementata a causa della mancanza di budget/risorse o verrà eseguita all'interno di un progetto, il Problem Manager aprirà un task di Rischio al Proprietario dell'Applicazione.

o   Se la causa principale è identificata, ma le azioni intraprese non sono le più appropriate, allora il Problem Manager compila un nuovo articolo Primario di Errore Conosciuto per il Database degli Errori Conosciuti. Si noti che il codice di risoluzione "Workaround" può essere deciso successivamente, nella fase "Fix in Progress", e non è una fase come Valutazione del Rischio e Chiusura del Rischio.

Nel migliore dei casi (e generalmente è così), la causa principale viene identificata e le azioni possono essere eseguite.

In tal caso, il problem manager inserisce un codice di fallimento e di sotto-fallimento in base alla causa principale e fa clic su per spostare il ticket alla fase successiva: Fix Implementation.

• FIX IMPLEMENTATION: In questa fase, il Problem Manager apre un task per ogni azione. La data di scadenza viene concordata con il Problem Task Owner. Quando il task viene chiuso con un'analisi/implementazione, il Problem Manager scrive una nota di chiusura sul problema. Se esiste una soluzione alternativa, allora il Problem Manager esegue le azioni descritte nella fase precedente. Si noti che quando un problema viene Risolto, non significa che sia Chiuso.
• RESOLVED: Durante questa fase, tutti i Problem Manager si riuniscono per una riunione interna una volta alla settimana per rivedere i ticket Risolti e decidere se chiuderli. Se si rendono conto che manca qualcosa, il problema tornerà all'Analisi delle Cause Radici. In caso contrario, se decidono di chiuderlo, verrà eseguito il controllo della qualità del ticket e il problema verrà spostato in fase Closed. Qui, c'è un'altra fase cruciale se il codice di risoluzione è uno di questi: Workaround, Valutazione del Rischio o Chiusura del Rischio. Se il problema è risolto con uno di questi codici, allora i Problem Manager possono tracciare questi problemi internamente e avviare un altro processo: Gestione dei Bug Potenziali.
• CLOSED: In questa fase finale, non possono essere intraprese ulteriori azioni. Una volta che un problema è chiuso, non può essere riaperto. Qui, vediamo solo le informazioni che abbiamo inserito precedentemente e non possiamo apportare modifiche.