Il Suo Template dei dati per la gestione delle richieste di servizio

L’attributo Activity descrive una fase o un’azione specifica eseguita su una richiesta di servizio. Queste attività costituiscono gli elementi sequenziali del processo, come «Request Created», «Request Assigned», «Work In Progress» e «Request Closed». Ogni attività rappresenta un preciso momento nel percorso della richiesta di servizio.

L’analisi delle attività è il fulcro del Process Mining, perché consente di individuare e visualizzare il flusso di processo effettivo. Esaminando la sequenza e la frequenza delle attività, gli analisti possono identificare i percorsi più comuni, le deviazioni dal processo standard, i colli di bottiglia in cui le richieste rimangono bloccate e i cicli di rilavorazione in cui le fasi vengono ripetute senza necessità.

Definisce le fasi del processo e consente di individuare il flusso effettivo, i colli di bottiglia e le deviazioni.

Spesso deriva dai log dei cambi di stato, dalle tabelle degli eventi o dagli audit trail associati all’oggetto della richiesta di servizio.

Il Service Request ID è la chiave primaria che identifica in modo univoco ogni richiesta di servizio per tutto il suo ciclo di vita. Funge da identificativo del caso e collega tutte le attività, i cambi di stato e gli attributi correlati in un’unica istanza di processo coerente.

Nell’analisi di Process Mining, questo ID è fondamentale per ricostruire il percorso end-to-end di ogni richiesta. Raggruppando tutti gli eventi sotto un CaseId comune, gli analisti possono visualizzare i flussi di processo, calcolare la durata dei casi e individuare le differenze nella gestione delle varie richieste. È il fondamento di qualsiasi analisi eseguita sul processo di gestione delle richieste di servizio.

Questo ID è essenziale per riunire tutti gli eventi di una richiesta di servizio e ottenere una visione completa del processo end-to-end.

In genere si trova nell’intestazione o nella tabella principale delle transazioni relative alle richieste di servizio.

Start Time registra la data e l’ora precise di avvio di una specifica attività. Questo timestamp è fondamentale per ordinare cronologicamente gli eventi e calcolare la durata delle attività e dell’intero ciclo di vita del caso. Ogni attività del processo dovrebbe avere un Start Time corrispondente, così da costruire un Event Log accurato.

Nell’analisi dei processi, Start Time viene utilizzato per calcolare KPI fondamentali, come il tempo di ciclo, il tempo di attesa tra le attività e il tempo di lavorazione delle attività. Consente di creare una visione temporale del processo, evidenziando i ritardi e aiutando a individuare le fasi che richiedono più tempo. Timestamp accurati sono indispensabili per qualsiasi analisi delle prestazioni.

Questo timestamp è fondamentale per ordinare correttamente gli eventi e calcolare tutte le metriche temporali, come i tempi di ciclo e i colli di bottiglia.

Si trova nelle tabelle dell’Event Log o dell’audit trail, spesso registrato come «creation date» o «event timestamp» per ogni record di attività.

L’attributo Source System specifica il nome della piattaforma di IT Service Management (ITSM) o di un’altra applicazione da cui sono stati estratti i dati. Negli ambienti con più sistemi, questo campo consente di distinguere le fonti dei dati e garantisce la tracciabilità della loro origine.

Sebbene non venga utilizzato direttamente nella maggior parte delle analisi dei flussi di processo, è fondamentale per la governance dei dati, la convalida e la risoluzione dei problemi. Quando si combinano dati provenienti da più fonti, questo attributo consente agli analisti di segmentare la vista del processo per sistema, evidenziando eventuali differenze nell’esecuzione del processo o nella qualità dei dati tra le diverse piattaforme.

È fondamentale per la governance dei dati e la risoluzione dei problemi, perché chiarisce l’origine dei dati, soprattutto negli ambienti con più sistemi integrati.

Questo valore viene in genere aggiunto durante il processo di estrazione dei dati (ETL) e non è un campo nativo del sistema di origine.

Last Data Update fornisce il timestamp dell’estrazione o dell’aggiornamento più recente dei dati. Informa gli utenti sul livello di aggiornamento dei dati analizzati, consentendo loro di capire se l’analisi riflette lo stato attuale o una fotografia precedente.

Questo attributo è essenziale per il monitoraggio operativo e la reportistica, perché fornisce il contesto necessario per valutare la tempestività degli insight generati. Aiuta gli utenti a fidarsi dei dati e a prendere decisioni informate sulla base della loro attualità. Ad esempio, una Dashboard con dati aggiornati una settimana fa va interpretata diversamente da una aggiornata un’ora fa.

Indica il livello di aggiornamento dei dati, fondamentale per garantire che le analisi siano pertinenti e basate su informazioni aggiornate.

È un campo di metadati generalmente generato e memorizzato durante il processo di estrazione dei dati (ETL).

Assigned Agent è la persona specifica responsabile della gestione della richiesta di servizio in un determinato momento. Nel corso del suo ciclo di vita, una richiesta può essere assegnata a diversi agenti.

Questo attributo è fondamentale per analizzare prestazioni e carichi di lavoro. Consente alle organizzazioni di misurare e confrontare le prestazioni dei singoli agenti, inclusi i tempi medi di risoluzione e il volume di richieste gestite. Viene inoltre utilizzato per analizzare le riassegnazioni tra agenti, che possono indicare problemi nel triage iniziale, nella specializzazione degli agenti o nel bilanciamento dei carichi di lavoro.

Consente di analizzare le prestazioni dei singoli agenti, la distribuzione dei carichi di lavoro e la frequenza delle riassegnazioni tra agenti.

È disponibile nel record della richiesta di servizio. Le modifiche a questo campo vengono spesso registrate in un audit log o in una tabella dello storico.

Request Priority è una classificazione che aiuta i team di supporto a stabilire l’ordine di gestione delle richieste. In genere si basa sulla combinazione dell’impatto della richiesta sull’azienda e della sua urgenza. I livelli di priorità più comuni sono Low, Medium, High e Critical.

Questo attributo è fondamentale per l’analisi delle prestazioni e l’allocazione delle risorse. Gli analisti possono confrontare i tempi di ciclo e la conformità agli SLA tra i diversi livelli di priorità, verificando che le richieste ad alta priorità siano gestite adeguatamente. Consente inoltre di individuare se le richieste a bassa priorità vengono trascurate o se i team di supporto applicano correttamente il sistema di prioritizzazione.

È essenziale per analizzare se le richieste vengono gestite in base alla loro importanza per l’azienda e per comprendere l’impatto della priorità sui tempi di risoluzione.

In genere è un campo standard del record principale della richiesta di servizio.

SLA Due Date è un timestamp obiettivo calcolato sulla base dell’accordo sul livello di servizio associato alla richiesta. Viene determinato da fattori quali priorità, tipo e ora di creazione della richiesta e definisce il tempo previsto per la risoluzione.

Questo attributo costituisce la base di ogni analisi della conformità agli SLA. Confrontando il tempo effettivo di risoluzione con la SLA Due Date, le organizzazioni possono stabilire se una richiesta è stata risolta nei tempi previsti o se lo SLA è stato violato. Si tratta di un KPI fondamentale per misurare la qualità del servizio e individuare i problemi sistemici che causano ritardi e violazioni.

È il riferimento per misurare le prestazioni. Viene utilizzato per calcolare i tassi di conformità agli SLA e individuare le richieste per cui lo SLA è stato violato.

Spesso è un campo calcolato del record della richiesta di servizio, determinato dalla policy SLA applicata.

Request Status indica lo stato della richiesta di servizio in un determinato momento del suo ciclo di vita. Tra gli stati più comuni figurano New, In Progress, Pending, Resolved e Closed. Questo attributo offre una fotografia della posizione della richiesta nel processo complessivo.

Analizzare Request Status è fondamentale per comprendere il flusso del processo e le transizioni tra gli stati. Può essere utilizzato per filtrare i casi, individuare le richieste bloccate in uno stato specifico e misurare il tempo trascorso in ciascuno stato. Ad esempio, analizzare quanto a lungo le richieste rimangono nello stato «Pending» può rivelare ritardi dovuti all’attesa di informazioni da parte degli utenti o di team esterni.

Consente di analizzare quanto tempo le richieste trascorrono in ciascuno stato, evidenziando colli di bottiglia o ritardi nel processo.

È disponibile nella tabella principale delle richieste di servizio o nei log dello storico degli stati.

Assigned Team indica il gruppo di supporto specificamente responsabile della richiesta di servizio. Le richieste vengono spesso instradate tra team diversi, come un help desk di primo livello, un team di rete o un team di sviluppo software, in base alle competenze necessarie.

Analizzare i passaggi di consegna tra team è una componente fondamentale del Process Mining nella gestione dei servizi. Questo attributo consente di visualizzare i trasferimenti da un team all’altro e aiuta a individuare lacune nella comunicazione o ritardi. Permette inoltre di confrontare le prestazioni dei team, valutandone efficienza, volume di richieste e capacità di risolvere le richieste senza ulteriori escalation.

È fondamentale per analizzare i passaggi di consegna tra team, individuare i ritardi nei trasferimenti e confrontare le prestazioni dei team.

Un campo standard del record della richiesta di servizio. Le modifiche a questo campo vengono registrate in un audit log.

Service Type classifica la natura della richiesta di servizio. Può comprendere richieste di nuovo hardware, accesso a software, informazioni generali o supporto tecnico. Questa categorizzazione aiuta a instradare la richiesta al team corretto e a comprendere la domanda relativa ai diversi servizi.

Nell’analisi dei processi, Service Type è una dimensione efficace per segmentare i dati. Filtrando la process map per tipo di servizio, le organizzazioni possono scoprire che alcune categorie di richieste seguono processi molto diversi, hanno tempi di ciclo più lunghi o presentano più rilavorazioni. Questo insight consente di definire interventi di miglioramento mirati per specifiche categorie di servizio.

Consente di filtrare e confrontare i processi relativi a diverse categorie di richieste, evidenziando colli di bottiglia o inefficienze specifici per ciascun tipo.

Un campo standard del record della richiesta di servizio, spesso collegato a un catalogo dei servizi.

Submission Channel indica come è stata creata la richiesta di servizio, ad esempio tramite un portale self-service, e-mail, telefonata o API. Canali diversi possono essere associati a processi o aspettative degli utenti differenti.

Analizzare il processo in base al canale di invio può rivelare insight importanti. Ad esempio, le richieste inviate tramite un portale self-service possono essere più strutturate e risolte più rapidamente rispetto a quelle inviate via e-mail, che potrebbero richiedere l’inserimento manuale dei dati. Questa analisi può aiutare le organizzazioni a promuovere i canali più efficienti o a migliorare i processi associati a quelli meno efficienti.

Aiuta a determinare se il metodo di invio influisce sull’efficienza del processo, sui tempi di risoluzione o sul tasso di risoluzione al primo contatto.

In genere è disponibile come campo standard del record della richiesta di servizio.

Resolution Code offre un metodo strutturato per classificare l’esito di una richiesta di servizio. Tra gli esempi figurano «Solved by User», «Hardware Replaced», «Software Deployed» o «Duplicate Request». In genere, queste informazioni vengono inserite dall’agente al momento della chiusura della richiesta.

Questi codici sono preziosi per l’analisi delle cause principali. Analizzando la frequenza dei diversi codici di risoluzione, le organizzazioni possono individuare problemi ricorrenti, soluzioni comuni e opportunità per creare articoli della knowledge base o risoluzioni automatizzate. Ad esempio, un numero elevato di risoluzioni «Password Reset» potrebbe giustificare l’investimento in uno strumento self-service per la reimpostazione delle password.

Consente di analizzare le cause principali classificando il modo in cui vengono risolte le richieste e aiutando a individuare tendenze e aree per una gestione proattiva dei problemi.

Un campo generalmente compilato manualmente dall’agente al momento della risoluzione o della chiusura della richiesta di servizio.

Il Numero di riassegnazioni indica il numero totale di volte in cui una richiesta di servizio è stata trasferita da un agente o team a un altro. Un numero elevato può indicare problemi quali un instradamento iniziale errato, una conoscenza insufficiente da parte degli agenti o una responsabilità sul processo non chiaramente definita.

Si tratta di un indicatore chiave dell'inefficienza del processo. Nel Process Mining, questa metrica aiuta a quantificare il numero di passaggi tra diversi interlocutori che una richiesta deve affrontare. L'analisi dei casi con un numero elevato di riassegnazioni può evidenziare opportunità per migliorare il processo di triage, rafforzare la formazione degli agenti o definire con maggiore chiarezza le responsabilità dei team, così da instradare correttamente le richieste già al primo tentativo.

Una metrica fondamentale per individuare le inefficienze del processo. Un numero elevato di riassegnazioni è spesso correlato a tempi di risoluzione più lunghi e a una minore soddisfazione degli utenti.

Si tratta di una metrica calcolata, ottenuta contando il numero di volte in cui il campo 'AssignedAgent' o 'AssignedTeam' cambia per un determinato 'CaseId'.

End Time registra la data e l’ora precise di completamento di una specifica attività. Mentre Start Time indica l’inizio, End Time indica la conclusione e definisce la durata di una singola fase del processo. Non tutti gli eventi hanno un End Time distinto, poiché alcuni possono essere istantanei.

Questo attributo è essenziale per calcolare il tempo di lavorazione delle singole attività. Sottraendo Start Time da End Time, gli analisti possono misurare quanto tempo gli agenti o i sistemi dedicano effettivamente a un’attività. Ciò aiuta a individuare le attività specifiche che richiedono più tempo e che sono quindi le principali candidate all’ottimizzazione o all’automazione.

Consente di calcolare i tempi di lavorazione delle attività e di individuare le fasi specifiche del processo che richiedono più tempo.

Si trova nelle tabelle dell’Event Log o dell’audit trail. Se non è disponibile in modo esplicito, può essere derivato utilizzando lo Start Time dell’attività successiva.

Questo attributo identifica il reparto o l’unità aziendale della persona che ha avviato la richiesta di servizio. Fornisce il contesto organizzativo della richiesta.

Analizzare le richieste per reparto può aiutare a individuare esigenze, tendenze o problemi specifici. Ad esempio, un volume elevato di un determinato tipo di richiesta da parte del reparto Finance potrebbe indicare la necessità di una formazione mirata o di un miglioramento del sistema. Consente inoltre di elaborare report di chargeback e comprendere la domanda di servizi IT nelle diverse aree dell’organizzazione.

Fornisce il contesto organizzativo e consente di analizzare i modelli delle richieste e la domanda di servizi per unità aziendale.

Queste informazioni vengono in genere recuperate dal profilo utente del richiedente nella directory dei dipendenti o nel sistema ITSM.

Questo attributo booleano indica se la richiesta di servizio non ha rispettato l’accordo sul livello di servizio definito. È true se la richiesta è stata risolta dopo «SlaDueDate» e false in caso contrario.

Questo attributo semplifica la reportistica e l’analisi della conformità agli SLA. Invece di eseguire confronti tra date in ogni query, questo semplice indicatore consente di filtrare e aggregare facilmente i dati. È una metrica primaria per le Dashboard dedicate alle prestazioni SLA e permette di individuare rapidamente il volume e la percentuale di richieste che non rispettano gli obiettivi di servizio.

Fornisce un indicatore chiaro e semplice per analizzare le prestazioni SLA, rendendo agevole filtrare e creare report sulle richieste per cui lo SLA è stato violato.

È un attributo derivato, calcolato confrontando il timestamp finale di risoluzione con il campo «SlaDueDate» durante la trasformazione dei dati.