Il vostro Template Dati per il Service Request Management

L'attributo 'Activity' descrive un passaggio specifico o un'azione intrapresa su una richiesta di servizio. Queste attività costituiscono i blocchi sequenziali del processo, come 'Richiesta creata', 'Richiesta assegnata', 'In corso' e 'Richiesta chiusa'. Ogni attività rappresenta un punto temporale distinto nel percorso di una richiesta di servizio.

L'analisi delle attività è il cuore del Process Mining. Consente la scoperta e la visualizzazione del flusso reale del processo. Esaminando la sequenza e la frequenza delle attività, gli analisti possono identificare i percorsi comuni, le deviazioni dal processo standard, i bottleneck in cui le richieste si bloccano e i loop di rilavorazione dove le fasi vengono ripetute inutilmente.

Definisce le fasi del processo, consentendo la scoperta del flusso reale, dei bottleneck e delle deviazioni.

Spesso derivato 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 univocamente ogni richiesta durante il suo ciclo di vita. Funge da identificatore del caso, collegando tutte le attività correlate, i cambi di stato e gli attributi 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 identificare variazioni nella gestione delle diverse richieste. È la pietra angolare di qualsiasi analisi eseguita sul processo di gestione delle richieste di servizio.

Questo ID è essenziale per collegare tutti gli eventi di una richiesta, permettendo una visione completa del processo end-to-end.

In genere si trova nell'intestazione o nella tabella transazionale principale delle richieste di servizio.

L'Ora di Inizio registra la data e l'ora esatta in cui è iniziata una specifica attività. Questo timestamp è cruciale per ordinare gli eventi cronologicamente e per calcolare la durata dei task e del ciclo di vita complessivo del caso. Ogni attività nel processo dovrebbe avere un'Ora di Inizio per costruire un Event Log accurato.

Nell'analisi dei processi, l'Ora di Inizio serve a calcolare KPI come il cycle time, i tempi di attesa tra le attività e i tempi di elaborazione. Permette di creare una vista temporale del processo, evidenziando i ritardi e identificando i passaggi che richiedono più tempo. Timestamp precisi sono la base di ogni analisi delle prestazioni.

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

Si trova nelle tabelle dell'Event Log o dell'audit trail, spesso registrato come 'data di creazione' o 'timestamp dell'evento' per ogni record di attività.

L'attributo Sistema di Origine specifica il nome della piattaforma ITSM o di altra applicazione da cui sono stati estratti i dati. In ambienti multi-sistema, questo campo aiuta a differenziare le fonti e garantisce la tracciabilità del dato (data lineage).

Sebbene non sia usato direttamente nelle analisi dei flussi, è fondamentale per la data governance, la validazione e il troubleshooting. Quando si uniscono dati da più fonti, questo attributo permette di segmentare la vista del processo per sistema, rivelando eventuali differenze nell'esecuzione o nella qualità dei dati tra le diverse piattaforme.

Essenziale per la data governance e la risoluzione dei problemi, chiarisce l'origine dei dati, specialmente in ambienti con più sistemi integrati.

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

'Last Data Update' fornisce il timestamp dell'estrazione o dell'aggiornamento dati più recente. Informa gli utenti sulla freschezza dei dati analizzati, chiarificando se l'analisi riflette lo stato attuale o un'istantanea passata.

Questo attributo è essenziale per il monitoraggio operativo e la reportistica, poiché fornisce il contesto necessario sulla tempestività degli insight generati. Aiuta gli utenti a fidarsi dei dati e a prendere decisioni informate basate sulla loro attualità. Ad esempio, una dashboard che mostra dati aggiornati a una settimana fa verrebbe interpretata diversamente da una aggiornata un'ora fa.

Indica l'aggiornamento dei dati, fondamentale per garantire che le analisi siano pertinenti e basate su informazioni attuali.

Si tratta di un campo di metadati tipicamente generato e memorizzato durante il processo di estrazione dei dati (ETL).

L''Assigned Agent' è la persona specifica responsabile della gestione della richiesta in un dato momento. Una richiesta può essere assegnata a diversi operatori durante il suo ciclo di vita.

Questo attributo è fondamentale per l'analisi delle performance e del carico di lavoro. Consente alle organizzazioni di misurare e confrontare le prestazioni dei singoli operatori, inclusi i tempi medi di risoluzione e il volume di richieste gestite. Viene anche utilizzato per analizzare le riassegnazioni tra operatori, che possono indicare problemi con il triage iniziale, la specializzazione degli operatori o il bilanciamento del carico di lavoro.

Consente l'analisi delle performance dei singoli operatori, della distribuzione del carico di lavoro e della frequenza delle riassegnazioni tra operatori.

Disponibile nel record della richiesta di servizio. Le modifiche a questo campo sono spesso tracciate in un audit log o in una tabella dello storico.

La Scadenza SLA (SLA Due Date) è il limite temporale calcolato in base all'accordo sul livello del servizio associato alla richiesta. Viene determinata da fattori come priorità, tipo di richiesta e ora di creazione, definendo la finestra temporale prevista per la risoluzione.

Questo attributo è la base per l'analisi della conformità agli SLA. Confrontando il tempo di risoluzione effettivo con la Scadenza SLA, l'azienda può determinare se una richiesta è stata gestita puntualmente o se lo SLA è stato violato. Si tratta di un KPI critico per misurare la qualità del servizio e identificare problemi sistemici che causano ritardi e violazioni dei termini.

Questo è il benchmark per misurare le performance. Viene utilizzato per calcolare i tassi di conformità agli SLA e identificare le richieste fuori termine.

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

'Request Priority' è una classificazione che aiuta i team di supporto a determinare l'ordine di gestione delle richieste. Solitamente si basa su una combinazione dell'impatto della richiesta sul business e della sua urgenza. I livelli di priorità comuni includono Bassa, Media, Alta e Critica.

Questo attributo è vitale per l'analisi delle performance e l'allocazione delle risorse. Gli analisti possono confrontare i tempi di ciclo e la conformità agli SLA tra i diversi livelli di priorità per assicurarsi che le richieste ad alta priorità siano gestite correttamente. Aiuta inoltre a identificare se le richieste a bassa priorità vengono trascurate o se il sistema di prioritizzazione viene seguito correttamente dai team di supporto.

Essenziale per analizzare se le richieste sono gestite in base alla loro importanza per il business e per capire come la priorità influisce sul tempo di risoluzione.

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

Il 'Request Status' indica la fase in cui si trova la richiesta di servizio in un dato momento del suo ciclo di vita. Gli stati comuni includono Nuova, In corso, In sospeso, Risolta e Chiusa. Questo attributo fornisce un'istantanea della posizione della richiesta nel processo complessivo.

L'analisi dello stato della richiesta è fondamentale per comprendere il flusso del processo e le transizioni di stato. Può essere utilizzata per filtrare i casi, identificare le richieste bloccate in un particolare stato e misurare il tempo trascorso in ogni stato. Ad esempio, analizzare quanto tempo le richieste rimangono in uno stato 'In sospeso' può rivelare ritardi causati dall'attesa di informazioni dagli utenti o da team esterni.

Consente di analizzare quanto tempo le richieste trascorrono in ogni stato, evidenziando bottleneck o ritardi nel processo.

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

L''Assigned Team' si riferisce al gruppo di supporto specifico responsabile della richiesta di servizio. Le richieste vengono spesso instradate tra diversi team, come un help desk di primo livello, un team di rete o un team di sviluppo software, a seconda delle competenze richieste.

L'analisi dei passaggi di consegna (handoff) tra i team è una parte fondamentale del Process Mining applicato alla gestione dei servizi. Questo attributo consente la visualizzazione dei trasferimenti da team a team, aiutando a identificare lacune comunicative o ritardi. Consente inoltre il benchmarking delle performance tra i team, confrontando la loro efficienza, il volume di richieste e la capacità di risolvere le richieste senza ulteriori escalation.

Fondamentale per analizzare i passaggi di consegne (handoff) tra i team, identificare i ritardi nei trasferimenti e confrontare le performance dei team.

Un campo standard nel record della richiesta di servizio. Le modifiche a questo campo sono tracciate in un audit log.

Il 'Service Type' classifica la natura della richiesta. Può variare da richieste di nuovo hardware o accesso a software, a richieste generiche o supporto tecnico. Questa categorizzazione aiuta a indirizzare la richiesta al team corretto e a comprendere la domanda per i diversi servizi.

Nell'analisi dei processi, il Service Type è una dimensione potente per segmentare i dati. Filtrando la mappa del processo per i diversi tipi di servizio, le organizzazioni possono scoprire che certi tipi di richieste seguono processi molto diversi, hanno tempi di ciclo più lunghi o subiscono più rilavorazioni. Questo insight consente sforzi mirati di miglioramento del processo per specifiche categorie di servizio.

Consente di filtrare e confrontare i processi per diverse categorie di richieste, rivelando bottleneck o inefficienze specifiche per ogni tipologia.

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

Il Canale di Invio indica come è stata creata la richiesta, ad esempio tramite portale self-service, email, telefono o API. Canali diversi possono avere processi associati o aspettative degli utenti differenti.

Analizzare il processo per canale può fornire insight preziosi. Ad esempio, le richieste via portale potrebbero essere più strutturate e risolte più velocemente rispetto a quelle via email, che richiedono l'inserimento manuale dei dati. Questa analisi aiuta le aziende a promuovere i canali più efficienti o a migliorare i processi di quelli meno performanti.

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

In genere si trova come campo standard nel record della richiesta di servizio.

Il 'Resolution Code' fornisce un modo strutturato per classificare l'esito di una richiesta di servizio. Esempi includono 'Risolto dall'utente', 'Hardware sostituito', 'Software distribuito' o 'Richiesta duplicata'. Queste informazioni vengono solitamente inserite dall'operatore alla chiusura della richiesta.

Questi codici sono preziosi per l'analisi delle cause profonde. Analizzando la frequenza dei diversi codici di risoluzione, le organizzazioni possono identificare problemi ricorrenti, soluzioni comuni e opportunità per creare articoli della Knowledge Base o risoluzioni automatizzate. Ad esempio, un numero elevato di risoluzioni per 'Reset Password' potrebbe giustificare l'investimento in uno strumento di self-service per il reset della password.

Consente l'analisi delle cause profonde categorizzando le modalità di risoluzione delle richieste, aiutando a identificare tendenze e aree per una gestione proattiva dei problemi.

Un campo che viene solitamente compilato manualmente dall'operatore al momento della risoluzione o della chiusura della richiesta di servizio.

'Reassignment Count' è una metrica che somma il numero di volte in cui una richiesta di servizio è stata trasferita da un operatore o team a un altro. Un conteggio elevato può indicare problemi come un instradamento iniziale errato, mancanza di conoscenze dell'operatore o proprietà del processo poco chiara.

Questo è un indicatore chiave di inefficienza del processo. Nel Process Mining, questa metrica aiuta a quantificare l'effetto 'ping-pong' subito da una richiesta. Analizzare i casi con un alto numero di riassegnazioni può rivelare opportunità per migliorare il processo di triage, potenziare la formazione degli operatori o affinare le responsabilità dei team per garantire che le richieste siano indirizzate correttamente fin dalla prima volta.

Una metrica fondamentale per identificare le inefficienze del processo. Un numero elevato di riassegnazioni è spesso correlato a tempi di risoluzione più lunghi e all'insoddisfazione degli utenti.

Questa è una metrica calcolata, derivata contando quante volte i campi 'Agente Assegnato' o 'Team Assegnato' cambiano per un determinato 'CaseId'.

Questo attributo identifica il dipartimento o l'unità aziendale della persona che ha aperto la richiesta, fornendo un contesto organizzativo.

L'analisi per dipartimento aiuta a individuare esigenze, trend o problemi specifici. Ad esempio, un volume elevato di richieste dal reparto Finance potrebbe indicare la necessità di formazione mirata o miglioramenti del sistema. Consente inoltre il reporting per il chargeback e una migliore comprensione della domanda di servizi IT in tutta l'azienda.

Fornisce il contesto organizzativo, consentendo l'analisi dei pattern di richiesta e della domanda di servizi per business unit.

Queste informazioni vengono solitamente estratte dal profilo utente del richiedente nella directory aziendale o nel sistema ITSM.

L''End Time' registra la data e l'ora esatte in cui una specifica attività è stata terminata. Mentre lo Start Time segna l'inizio, l'End Time segna la conclusione, definendo la durata di un singolo passaggio del processo. Non tutti gli eventi hanno un End Time distinto, poiché alcuni possono essere istantanei.

Questo attributo è essenziale per calcolare il tempo di elaborazione delle singole attività. Sottraendo lo Start Time dall'End Time, gli analisti possono misurare quanto tempo gli operatori o i sistemi trascorrono lavorando attivamente su un compito. Ciò aiuta a individuare quali attività specifiche richiedono molto tempo e sono le principali candidate per l'ottimizzazione o l'automazione.

Consente il calcolo dei tempi di elaborazione delle attività, aiutando a identificare quali fasi specifiche del processo richiedono più tempo.

Si trova nelle tabelle dell'Event Log o dell'audit trail. Potrebbe essere necessario derivarlo utilizzando l'ora di inizio dell'attività successiva se non è esplicitamente disponibile.

Questo attributo booleano indica se la richiesta ha violato l'accordo sul livello del servizio. È impostato su 'true' se la richiesta è stata risolta dopo la 'SlaDueDate', altrimenti è 'false'.

Questo attributo semplifica i report di conformità agli SLA. Invece di eseguire confronti tra date in ogni query, questo flag permette di filtrare e aggregare i dati facilmente. È una metrica fondamentale per le Dashboard dedicate alle performance SLA e aiuta a identificare rapidamente la percentuale di richieste fuori target.

Fornisce un indicatore chiaro e semplice per l'analisi delle performance SLA, facilitando il filtraggio e la reportistica sulle richieste che hanno violato i termini.

Si tratta di un attributo derivato, calcolato confrontando il timestamp della risoluzione finale con il campo 'SlaDueDate' durante la trasformazione dei dati.