Il Suo template dati per la gestione delle richieste di servizio
Il Suo template dati per la gestione delle richieste di servizio
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione per BMC Helix ITSM
Attributi di gestione delle richieste di servizio
| Nome | Descrizione | ||
|---|---|---|---|
|
Activity
ActivityName
|
Il nome dell'evento o del compito specifico che si è verificato in un determinato momento all'interno del ciclo di vita della richiesta di servizio. | ||
|
Descrizione
Questo attributo descrive un passaggio specifico o un cambio di stato nel processo, come 'Richiesta in revisione', 'Evasione in corso' o 'Richiesta risolta'. Ogni attività rappresenta un singolo evento nel percorso end-to-end della richiesta.\n\nAnalizzare la sequenza e la frequenza delle attività è il cuore del Process Mining. Permette di scoprire le mappe dei processi, identificare i bottleneck e analizzare le varianti. Capire quali attività avvengano, in quale ordine e con quale frequenza è fondamentale per l'ottimizzazione del processo.
Perché è importante
Le attività sono i mattoni della mappa di processo. Tracciarle permette di visualizzare e analizzare il flusso del processo, rivelando come viene effettivamente svolto il lavoro.
Dove trovare
In genere deriva dai cambiamenti nei campi 'Status' e 'Status Reason' del form 'SRM:Request' o dai log delle applicazioni collegate (es. Incident, Work Order).
Esempi
Richiesta in attesa di approvazioneEvasione in corsoRichiesta di Servizio RisoltaRichiesta di Servizio Chiusa
|
|||
|
ID Richiesta di Servizio
ServiceRequestId
|
L'identificativo univoco di ogni richiesta, che funge da chiave primaria per tracciarne l'intero ciclo di vita. | ||
|
Descrizione
L'ID della richiesta di servizio identifica in modo univoco ogni singola richiesta inviata da un utente o sistema. Funge da filo conduttore che collega tutti gli eventi successivi, dalla registrazione iniziale alla chiusura finale, permettendo un'analisi end-to-end completa del percorso di ogni richiesta.\n\nNel Process Mining, questo ID è essenziale per ricostruire la sequenza delle attività di ogni caso. Consente allo strumento di raggruppare tutti gli eventi correlati, come 'Richiesta inviata', 'Richiesta assegnata' e 'Richiesta chiusa', in un'unica istanza di processo, costituendo la base per l'intera analisi.
Perché è importante
Identificativo fondamentale del caso. Senza di esso, è impossibile tracciare il percorso end-to-end e analizzare il processo.
Dove trovare
Solitamente corrisponde al campo 'InstanceId' o 'Request Number' nel form 'SRM:Request' di BMC Helix ITSM.
Esempi
SR000010572931SR000010572932SR000010572933
|
|||
|
Ora di Inizio
EventStartTime
|
Il timestamp che indica quando una specifica attività o un evento ha avuto inizio. | ||
|
Descrizione
Questo attributo registra la data e l'ora esatte di inizio di un'attività. Ogni evento nel log deve avere uno Start Time per stabilire la sequenza cronologica.\n\nQuesto timestamp è fondamentale per le analisi basate sul tempo: serve a calcolare i tempi di ciclo, la durata delle attività, i tempi di attesa e la conformità SLA. Permette di scoprire i bottleneck e analizzare l'andamento delle prestazioni nel tempo.
Perché è importante
Lo Start Time stabilisce l'ordine cronologico degli eventi, essenziale per calcolare la durata dei processi, identificare i ritardi e comprendere la timeline del processo.
Dove trovare
Corrisponde ai campi timestamp negli audit log o nelle tabelle dello storico degli stati associati al form 'SRM:Request', come la 'Submit Date' per l'evento iniziale.
Esempi
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
|
|||
|
Sistema di Origine
SourceSystem
|
Identifica il sistema da cui i dati sono stati estratti. | ||
|
Descrizione
Questo attributo specifica l'origine dei dati. In questa vista, sarà impostato su 'BMC Helix ITSM'.\n\nIn ambienti con più sistemi integrati, questo campo è cruciale per comprendere la provenienza del dato e suddividerlo in base alla sorgente, garantendo tracciabilità quando si uniscono dati da piattaforme diverse.
Perché è importante
Fornisce contesto sull'origine dei dati, importante per la data governance, la tracciabilità e la risoluzione dei problemi in ambienti multi-sistema.
Dove trovare
Valore statico aggiunto durante l'estrazione e trasformazione dei dati, non è un campo interno a BMC Helix ITSM.
Esempi
BMC Helix ITSM
|
|||
|
Ultimo `Data Update`
LastDataUpdate
|
Il timestamp che indica l'ultimo aggiornamento dei dati del processo dal sistema sorgente. | ||
|
Descrizione
Questo attributo indica la data e l'ora dell'ultima estrazione dati da BMC Helix ITSM. Fornisce all'utente il contesto sulla freschezza dei dati, garantendo la consapevolezza del periodo temporale analizzato.\n\nSi tratta di un metadato critico per ogni dashboard di Process Mining: permette di capire se gli insight si basino su dati quasi in tempo reale o su snapshot storici, influenzando la validità delle conclusioni tratte.
Perché è importante
Informa gli utenti sulla freschezza dei dati, essenziale per prendere decisioni basate sulle informazioni più aggiornate disponibili riguardo alle prestazioni del processo.
Dove trovare
Timestamp generato e aggiunto durante il processo di estrazione e caricamento dati.
Esempi
2024-05-21T08:00:00Z
|
|||
|
Agente Assegnato
AssignedAgent
|
L'utente individuale attualmente assegnato alla lavorazione della richiesta. | ||
|
Descrizione
Questo attributo identifica lo specifico operatore IT responsabile della richiesta in un dato momento. I cambiamenti in questo campo indicano passaggi di mano o riassegnazioni.\n\nL'attributo è cruciale per analizzare le prestazioni e il carico di lavoro degli agenti. Consente di tracciare quante richieste gestisce ogni operatore, il tempo medio di risoluzione e la frequenza delle riassegnazioni, supportando la gestione delle risorse e l'identificazione di esigenze formative.
Perché è importante
Tracciare l'agente assegnato è essenziale per analizzare i passaggi di consegne, misurare le performance e capire la distribuzione del carico nel team.
Dove trovare
Corrisponde al campo 'Assignee' o 'Assigned To' nel record di evasione (es. Work Order, Incident) associato alla richiesta.
Esempi
Bob SmithAlice JohnsonCharlie Brown
|
|||
|
Ora di Fine
EventEndTime
|
Il timestamp che indica quando una specifica attività o un evento è stato completato. | ||
|
Descrizione
L'End Time segna la conclusione di un'attività. Mentre molte attività nei sistemi ITSM sono cambi di stato istantanei, alcune hanno una durata misurabile. Disporre di un End Time permette di calcolare con precisione la durata di tali attività.\n\nIn fase di analisi, l'End Time viene utilizzato insieme allo Start Time per calcolare il tempo di elaborazione delle singole attività. Questo aiuta a individuare quali compiti specifici, e non solo il tempo di attesa tra l'uno e l'altro, richiedano più tempo nel processo.
Perché è importante
Permette il calcolo dei tempi di elaborazione delle attività, fondamentale per identificare passaggi inefficienti e capire come le risorse impiegano il loro tempo.
Dove trovare
Questo dato può essere derivato. L'End Time di un'attività è spesso lo Start Time della successiva per lo stesso caso. Per l'attività finale, corrisponde al timestamp di risoluzione o chiusura.
Esempi
2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
|
|||
|
Priorità
Priority
|
Il livello di priorità assegnato alla richiesta, che ne indica l'urgenza e l'impatto sul business. | ||
|
Descrizione
La priorità determina l'ordine e la velocità con cui le richieste devono essere gestite. I valori comuni includono 'Critical', 'High', 'Medium' e 'Low'. Questa assegnazione si basa spesso su una combinazione dell'impatto della richiesta sul business e della sua urgenza. L'analisi per priorità è essenziale per valutare se le richieste ad alta priorità vengano elaborate più velocemente di quelle a bassa priorità. È una dimensione chiave nelle dashboard per i tempi di risoluzione e la conformità agli SLA, aiutando a garantire che le risorse siano allocate correttamente alle esigenze aziendali più critiche.
Perché è importante
Aiuta a valutare se il processo assegna correttamente la priorità al lavoro e se rispetta i livelli di servizio previsti per richieste con diversi impatti sul business.
Dove trovare
Corrisponde al campo 'Priority' nel form 'SRM:Request'.
Esempi
CriticoElevatoMedioBasso
|
|||
|
Stato Richiesta
RequestStatus
|
Lo stato della richiesta al momento dell'evento, come 'In corso', 'In sospeso' o 'Chiusa'. | ||
|
Descrizione
Questo attributo cattura lo stato della richiesta in diversi momenti del suo ciclo di vita. Lo stato fornisce il contesto per ogni attività ed è spesso la fonte da cui deriva l'attributo 'Activity' stesso.\n\nL'analisi per stato aiuta a capire quanto tempo le richieste passino in determinati stati, come 'In attesa del cliente' o 'In attesa di approvazione'. È essenziale per identificare bottleneck e ritardi causati da dipendenze esterne o code interne, alimentando direttamente la dashboard per l'identificazione dei bottleneck.
Perché è importante
Fornisce un'istantanea dello stato della richiesta, consentendo l'analisi del tempo trascorso in stati di attesa rispetto agli stati attivi, fondamentale per identificare i colli di bottiglia.
Dove trovare
Campo 'Status' nel form 'SRM:Request'. I valori storici sono disponibili nell'audit log.
Esempi
PianificazioneIn CorsoIn SospesoRisoltoChiuso
|
|||
|
Team assegnato
AssignedTeam
|
Il gruppo di supporto o il team attualmente assegnato alla richiesta. | ||
|
Descrizione
Questo attributo identifica il gruppo funzionale responsabile della gestione, come 'Help Desk', 'Team Network' o 'Amministratori DB'. Un cambio in questo campo indica un passaggio di responsabilità tra i team.\n\nL'analisi basata sul team assegnato aiuta a identificare bottleneck a livello di team, analizzare i passaggi di consegne e valutare l'efficienza dei vari gruppi di supporto. È fondamentale per le dashboard sulla rielaborazione delle richieste e l'efficienza del triage, rivelando come il lavoro viene smistato nell'organizzazione.
Perché è importante
Abilita l'analisi del flusso di processo tra diversi gruppi funzionali, aiutando a identificare inefficienze di instradamento e misurare le prestazioni a livello di team.
Dove trovare
Corrisponde al campo 'Assigned Group' nel record di evasione (es. Work Order, Incident) associato alla richiesta.
Esempi
Service DeskSupporto InfrastrutturaleSupporto Applicativo Tier 2
|
|||
|
Tipo di Servizio
ServiceType
|
La categoria o il tipo di servizio richiesto dall'utente. | ||
|
Descrizione
Il Tipo di Servizio (Service Type) classifica la natura della richiesta, ad esempio 'Richiesta nuovo software', 'Reset password' o 'Inserimento nuovo dipendente'. È una dimensione fondamentale per filtrare e segmentare i dati del processo.\n\nNell'analisi dei processi, questo attributo permette di confrontare le prestazioni di diversi tipi di richieste, aiutando a capire quali richiedano più tempo per la risoluzione o quali presentino più rielaborazioni. È un elemento critico per le dashboard sui tempi di risoluzione e la conformità agli SLA.
Perché è importante
Permette la segmentazione delle richieste di servizio per confrontare i flussi di processo, identificare problemi specifici per tipologia e personalizzare efficacemente gli sforzi di ottimizzazione.
Dove trovare
Questi dati si trovano spesso nel campo 'Title' o in un campo di categorizzazione del form 'SRM:Request', derivati dal servizio selezionato nel catalogo.
Esempi
Nuova richiesta hardwareRichiesta di accesso softwareConfigurazione accesso VPN
|
|||
|
`Handoff Count`
HandoffCount
|
Il numero totale di volte in cui una richiesta è stata riassegnata tra diversi agenti o team. | ||
|
Descrizione
Questa metrica conta quante volte cambiano l'agente o il team assegnati a una richiesta. Un numero elevato di passaggi (handoff) può indicare frammentazione del processo, mancanza di risoluzione al primo contatto o instradamento inefficiente.\n\nL'attributo è alla base del KPI sui passaggi medi tra agenti e viene usato nella dashboard sulle riassegnazioni. Analizzare i casi con molti passaggi aiuta a migliorare il triage, pianificare la formazione o snellire il processo per ridurre i ritardi.
Perché è importante
Misura la frammentazione del processo e il sovraccarico di comunicazione. Un numero elevato di passaggi di consegna è spesso correlato a tempi di risoluzione più lunghi e a una minore efficienza del processo.
Dove trovare
Metrica calcolata contando i valori distinti negli attributi 'Agente assegnato' o 'Team assegnato' per ogni ID richiesta univoco.
Esempi
0135
|
|||
|
Canale di Presentazione
SubmissionChannel
|
Il metodo o il canale attraverso cui è stata inviata la richiesta. | ||
|
Descrizione
Questo attributo registra come è stata avviata la richiesta (es. portale self-service, email, telefono o alert automatico). Canali diversi possono generare varianti di processo e tempi di risoluzione differenti.\n\nAnalizzare il processo per canale può rivelare inefficienze o best practice. Ad esempio, le richieste dal portale potrebbero essere più veloci grazie a una migliore qualità del dato iniziale, mentre le email potrebbero richiedere più triage manuale.
Perché è importante
Aiuta a capire come il metodo di sottomissione influisca sull'efficienza del processo, sulla qualità dei dati e sul tempo di ciclo totale, permettendo miglioramenti mirati su canali specifici.
Dove trovare
Spesso può essere dedotto da campi come 'Client Type' o 'Reported Source' nel form 'SRM:Request' o nei ticket di evasione collegati.
Esempi
Portale self-serviceEmailTelefonoGenerato dal Sistema
|
|||
|
Categoria di risoluzione
ResolutionCategory
|
La classificazione della soluzione fornita per risolvere la richiesta. | ||
|
Descrizione
Questo attributo offre una categorizzazione strutturata della modalità di risoluzione (es. 'Fix Software', 'Formazione Utente', 'Correzione Dati'). Va oltre il semplice codice di chiusura.\n\nÈ essenziale per la dashboard sull'accuratezza della categoria di risoluzione, dove può essere confrontato con il tipo di servizio iniziale per verificarne la coerenza. Analizzare queste categorie aiuta a identificare trend e supporta il problem management proattivo (es. se molte richieste si risolvono con la formazione).
Perché è importante
Offre insight sulla natura delle soluzioni, aiutando a identificare trend in problemi ricorrenti e opportunità per la gestione proattiva dei problemi o la formazione degli utenti.
Dove trovare
L'informazione fa parte dei campi di categorizzazione operativa e di prodotto nel ticket di evasione, spesso etichettata come 'Resolution Category'.
Esempi
Amministrazione AccountGuasto HardwareAggiornamento SoftwareInformazioni Fornite
|
|||
|
Codice di chiusura
CloseCode
|
Un codice che indica l'esito finale o il motivo della chiusura della richiesta di servizio. | ||
|
Descrizione
Il Close Code offre un modo standardizzato per classificare la risoluzione di una richiesta di servizio. Alcuni esempi sono 'Risolto dal Service Desk', 'Annullato dall'utente' o 'Richiesta duplicata'.\n\nL'analisi di questi codici aiuta a comprendere gli esiti comuni delle richieste. Può evidenziare problemi come un numero elevato di cancellazioni, che potrebbe indicare processi troppo lunghi, o molti duplicati, segnale di possibili problemi nei sistemi o nella comunicazione. Questo attributo alimenta la dashboard sull'accuratezza della categoria di risoluzione.
Perché è importante
Fornisce dati strutturati sull'esito delle richieste, permettendo l'analisi dell'efficacia della risoluzione e dei motivi di mancato completamento o annullamento.
Dove trovare
Queste informazioni si trovano solitamente nei campi 'Resolution' o 'Closure Code' del ticket di evasione associato alla richiesta.
Esempi
RiuscitoAnnullata dall'utenteNon più richiestoRisoluzione automatizzata
|
|||
|
Data Obiettivo SLA
SlaTargetDate
|
La data e l'ora entro cui la richiesta di servizio dovrebbe essere risolta secondo lo SLA (Service Level Agreement). | ||
|
Descrizione
La data target SLA è un timestamp calcolato che rappresenta la scadenza per il completamento della richiesta. Viene determinata dalle regole degli accordi di servizio, che tengono conto di fattori come priorità e tipo di richiesta.\n\nQuesto attributo è fondamentale per la dashboard sulla conformità SLA. Funge da termine di paragone per misurare il tempo di risoluzione effettivo. Confrontando l' 'EventEndTime' dell'attività di risoluzione finale con questa data target, possiamo determinare se gli impegni di servizio siano stati rispettati.
Perché è importante
Benchmark principale per misurare le prestazioni rispetto agli impegni presi, essenziale per il monitoraggio della conformità SLA.
Dove trovare
Questa data è calcolata e memorizzata dal modulo SLM (Service Level Management) e si trova nei form SLM collegati alla richiesta.
Esempi
2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
|
|||
|
Dipartimento del richiedente
RequestorDepartment
|
Il dipartimento o l'unità di business dell'utente che ha inviato la richiesta. | ||
|
Descrizione
Questo attributo identifica il dipartimento dell'utente che richiede il servizio (es. Finance, HR, IT). L'informazione proviene solitamente dal profilo utente a sistema.\n\nSegmentare l'analisi per dipartimento permette di individuare esigenze specifiche, pattern di richiesta e aree per formazione mirata o miglioramenti del servizio. Aiuta a rispondere a domande come: 'Il dipartimento Finance sperimenta tempi di attesa più lunghi per le proprie richieste?'.
Perché è importante
Consente l'analisi del consumo dei servizi e delle prestazioni dei processi per business unit, il che può evidenziare problemi o trend specifici di un dipartimento.
Dove trovare
Queste informazioni vengono solitamente recuperate dal profilo utente associato al campo 'Requested For' nel form 'SRM:Request'.
Esempi
FinanzaVenditeRisorse UmaneTecnologia dell'Informazione
|
|||
|
È Escalato
IsEscalated
|
Un flag booleano che indica se la richiesta di servizio è stata oggetto di escalation. | ||
|
Descrizione
Questo flag è 'true' se la richiesta ha subito un'escalation funzionale o gerarchica. L'escalation avviene solitamente quando una richiesta non avanza, rischia di violare gli SLA o richiede un'autorità superiore.\n\nL'attributo è fondamentale per la dashboard sull'efficienza delle escalation. Consente di analizzare i percorsi delle richieste escalate per capire cosa le scateni, quanto tempo richiedano dopo l'escalation e quanto sia efficace la procedura stessa.
Perché è importante
Consente di isolare e analizzare il sottoinsieme di richieste che hanno richiesto un'escalation, aiutando a identificare debolezze nel processo standard o trigger per problemi complessi.
Dove trovare
Solitamente non è un campo singolo. Viene derivato controllando attività specifiche di escalation nell'audit log o cambi di priorità/assegnazione che seguono i protocolli di escalation.
Esempi
truefalse
|
|||
|
È una Rilavorazione
IsRework
|
Un flag booleano che indica se una richiesta di servizio ha subito una rilavorazione, come il ritorno a una fase precedente. | ||
|
Descrizione
Questo flag identifica le richieste che hanno subito loop o rielaborazioni. Ad esempio, una richiesta che torna da 'Evasione in corso' a 'Richiesta in revisione' è considerata rework. La definizione esatta dipende dalla logica del processo.\n\nQuesto attributo alimenta la dashboard di analisi delle rielaborazioni e il relativo KPI. Permette di quantificare la frequenza del rework e analizzarne le cause comuni (es. valutazioni iniziali errate o dati incompleti) che causano inefficienze.
Perché è importante
Quantifica l'inefficienza del processo segnalando i casi che deviano dal "percorso ideale", aiutando a identificare le cause profonde di loop e lavori ripetuti.
Dove trovare
Questo è un attributo calcolato derivato dalla sequenza di attività nell'event log. È necessaria una logica per rilevare i movimenti a ritroso nel flusso del processo.
Esempi
truefalse
|
|||
|
SLA Violato
IsSlaBreached
|
Un flag booleano che indica se la richiesta di servizio è stata risolta oltre la data obiettivo prevista dallo SLA. | ||
|
Descrizione
Questo flag calcolato è impostato su 'true' se il timestamp di risoluzione finale è successivo alla 'Data target SLA'. Fornisce un esito binario immediato sulle prestazioni SLA per ogni richiesta.\n\nL'attributo è essenziale per la dashboard di conformità SLA e per il KPI del tasso di aderenza SLA. Consente di calcolare facilmente i tassi di conformità e di filtrare le richieste che hanno violato i termini, aiutando a identificare le cause radice dei ritardi.
Perché è importante
Semplifica l'analisi delle performance SLA convertendo un confronto di timestamp in un semplice flag booleano, rendendo facile la misurazione e visualizzazione dei tassi di conformità.
Dove trovare
Campo calcolato. Logica: SE 'Timestamp Risoluzione' > 'Data Target SLA' ALLORA vero ALTRIMENTI falso.
Esempi
truefalse
|
|||
|
Tempo di Ciclo
CycleTime
|
Il tempo totale trascorso dalla creazione della richiesta alla sua risoluzione finale. | ||
|
Descrizione
Il Cycle Time, noto anche come durata end-to-end, misura la vita totale di una richiesta di servizio. Viene calcolato come differenza tra il timestamp del primo evento (es. 'Service Request Submitted') e l'ultimo evento di risoluzione (es. 'Service Request Resolved'). Si tratta di uno dei KPI fondamentali nel Process Mining, a supporto diretto della dashboard sui tempi di risoluzione delle richieste. Analizzare il tempo di ciclo medio e filtrarlo per dimensioni come tipo di servizio o priorità rivela l'efficienza complessiva del processo e mette in luce le aree che richiedono troppo tempo.
Perché è importante
Misura primaria dell'efficienza del processo. Ridurre il tempo di ciclo è spesso l'obiettivo principale delle iniziative di miglioramento.
Dove trovare
Metrica calcolata sottraendo la 'Submit Date' dalla 'Closed Date' o 'Resolved Date' per ogni ID richiesta univoco.
Esempi
2 giorni 4 ore8 ore 30 minuti15 giorni
|
|||
Attività di gestione delle richieste di servizio
| Activity | Descrizione | ||
|---|---|---|---|
|
Evasione in corso
|
L'agente o il team assegnato ha iniziato a lavorare attivamente alla richiesta. Questo indica che la richiesta è passata da una coda a uno stato di lavorazione attiva. | ||
|
Perché è importante
Segna l'inizio del lavoro di evasione a valore aggiunto. Analizzare il tempo trascorso in questa fase aiuta a comprendere la produttività delle risorse e la complessità dell'evasione.
Dove trovare
Dedotto da un cambio di stato nel modulo SRM:Request a 'In Progress'.
Acquisisci
Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'In corso'.
Tipo di evento
inferred
|
|||
|
Richiesta Assegnata
|
La richiesta è stata assegnata a un operatore o team specifico per l'evasione. Questo segna la fine della fase di triage. | ||
|
Perché è importante
Milestone critica per misurare il tempo di triage e il carico di lavoro degli agenti. Riassegnazioni frequenti possono indicare problemi di instradamento o carenze di competenze.
Dove trovare
Questo evento può essere catturato esplicitamente dall'audit log dei campi 'Assigned Group' o 'Assignee' nel SRM:Request o nei form delle applicazioni di evasione (es. WOI:WorkOrder).
Acquisisci
Timestamp dall'audit log che mostra il primo valore non nullo impostato nel campo 'Assignee'.
Tipo di evento
explicit
|
|||
|
Richiesta di servizio annullata
|
La richiesta è stata ritirata dal richiedente o dal service desk prima dell'evasione. Si tratta di uno stato terminale della richiesta. | ||
|
Perché è importante
Tracciare gli annullamenti aiuta a identificare pattern, come l'invio di richieste errate o servizi non più necessari, orientando i miglioramenti del catalogo servizi.
Dove trovare
Dedotto da un cambio di stato nel modulo SRM:Request a 'Canceled'.
Acquisisci
Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'Annullato'.
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Chiusa
|
La richiesta è chiusa formalmente e archiviata in modalità sola lettura. Questo avviene dopo la risoluzione e al termine del periodo di conferma. | ||
|
Perché è importante
Questa attività rappresenta la fine definitiva del processo. Il tempo che intercorre tra 'Risolto' e 'Chiuso' può evidenziare inefficienze nelle procedure di chiusura.
Dove trovare
Dedotto dall'ultimo cambio di stato nel modulo SRM:Request a 'Closed'.
Acquisisci
Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'Chiuso'.
Tipo di evento
inferred
|
|||
|
Richiesta di servizio inviata
|
Questa attività segna la creazione e l'invio di una nuova richiesta. Viene registrata quando viene creato un nuovo record nel form SRM:Request con stato iniziale, solitamente 'Submitted'. | ||
|
Perché è importante
Punto di partenza per ogni caso, essenziale per misurare la durata totale del ciclo di vita e analizzare i volumi delle richieste in ingresso.
Dove trovare
L'evento viene dedotto dal timestamp di creazione e dallo stato iniziale (es. 'Submitted') di un record nel form SRM:Request.
Acquisisci
Identifichi il timestamp di creazione per un nuovo Service Request ID nel modulo SRM:Request quando lo stato è 'Submitted'.
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Risolta
|
L'evasione della richiesta è completata e la risoluzione è stata comunicata al richiedente. La richiesta attende la conferma finale o verrà chiusa automaticamente dopo un periodo prestabilito. | ||
|
Perché è importante
Una tappa critica che segna la fine del ciclo di erogazione del servizio. È l'endpoint principale per misurare i tempi di risoluzione e l'aderenza agli SLA.
Dove trovare
Dedotto da un cambio di stato nel modulo SRM:Request a 'Resolved' o 'Completed'.
Acquisisci
Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'Risolto' o 'Completato'.
Tipo di evento
inferred
|
|||
|
Informazione richiesta all'utente
|
L'operatore incaricato richiede informazioni aggiuntive al richiedente per procedere. La richiesta viene solitamente messa in stato 'In sospeso' (Pending). | ||
|
Perché è importante
Questa attività è cruciale per calcolare il 'Tempo di attesa informazioni esterne', identificando quanto spesso le richieste si blocchino per informazioni incomplete.
Dove trovare
Dedotto da un cambio di stato nel modulo SRM:Request a 'Pending' con una causale come 'Customer Hold' o 'Awaiting Information'.
Acquisisci
Timestamp del cambio di stato in 'In sospeso' (Pending) combinato con una causale specifica.
Tipo di evento
inferred
|
|||
|
Richiesta approvata
|
La richiesta è stata approvata formalmente dalla parte incaricata, permettendo di procedere con l'evasione. Questo evento segue solitamente lo stato 'In attesa di approvazione'. | ||
|
Perché è importante
Segna la fine del sotto-processo di approvazione ed è una tappa fondamentale per tracciare la durata delle approvazioni e il loro impatto sui tempi di risoluzione complessivi.
Dove trovare
Dotto da un cambio di stato nel modulo SRM:Request da 'Waiting Approval' a uno stato successivo come 'Planning' o 'In Progress'. La decisione di approvazione stessa è registrata nei moduli di approvazione correlati.
Acquisisci
Timestamp del cambio di stato da 'In attesa di approvazione' a seguito di una decisione positiva.
Tipo di evento
inferred
|
|||
|
Richiesta in attesa di approvazione
|
La richiesta è stata inviata a un approvatore o gruppo di approvazione designato ed è in attesa di una decisione. È un passaggio comune per richieste che comportano costi o permessi di accesso. | ||
|
Perché è importante
Questa attività isola i ritardi legati alle approvazioni, permettendo l'analisi dei tempi di ciclo e l'identificazione di bottleneck nella catena approvativa.
Dove trovare
Dedotto da un cambio di stato nel modulo SRM:Request a un valore come 'Waiting Approval'.
Acquisisci
Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'In attesa di approvazione'.
Tipo di evento
inferred
|
|||
|
Richiesta in fase di revisione
|
La richiesta è in fase di revisione iniziale e triage da parte del service desk per determinarne natura, priorità e team di evasione competente. Solitamente è rappresentata da un cambio di stato nel record della richiesta. | ||
|
Perché è importante
Il tracciamento di questa attività aiuta a misurare l'efficienza del triage e i ritardi tra invio e assegnazione, fondamentale per il KPI sul tempo medio di triage.
Dove trovare
Dedotto da un cambio di stato nel modulo SRM:Request a un valore come 'In Review' o 'Planning'.
Acquisisci
Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'In revisione'.
Tipo di evento
inferred
|
|||
|
Richiesta Rifiutata
|
La richiesta è stata respinta durante la fase di approvazione. Si tratta di uno stato terminale che interrompe il processo prima dell'evasione. | ||
|
Perché è importante
L'analisi delle richieste rifiutate può evidenziare problemi con le giustificazioni delle richieste, i criteri di idoneità o le politiche di approvazione.
Dove trovare
Dedotto da un cambio di stato nel modulo SRM:Request a 'Rejected'.
Acquisisci
Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa a 'Rifiutato'.
Tipo di evento
inferred
|
|||
|
Richiesta Ripresa
|
La richiesta è stata sbloccata dallo stato di attesa, solitamente dopo che l'utente ha fornito le informazioni richieste. L'operatore riprende il lavoro. | ||
|
Perché è importante
Segna la fine di un periodo di attesa, consentendo la misurazione precisa dei tempi di attesa esterni e del loro impatto sulla conformità agli SLA.
Dove trovare
Dedotto quando lo stato di SRM:Request passa da 'Pending' nuovamente a 'In Progress'.
Acquisisci
Timestamp dell'aggiornamento in cui lo stato di SRM:Request passa da 'In sospeso' a 'In corso'.
Tipo di evento
inferred
|
|||
|
Risoluzione confermata dall'utente
|
Il richiedente ha confermato che il servizio è stato erogato correttamente e la richiesta è risolta. Questo di solito attiva la chiusura definitiva. | ||
|
Perché è importante
Fornisce un indicatore chiaro della soddisfazione del cliente e conclude formalmente l'interazione. Permette di distinguere la risoluzione tecnica del processo dall'accettazione finale dell'utente.
Dove trovare
L'evento potrebbe essere registrato nei log di lavoro o nelle note di attività di SRM:Request quando l'utente conferma tramite portale o email. Non sempre corrisponde a uno stato distinto.
Acquisisci
Scansione dei log di lavoro (SRM:WorkInfo) per voci specifiche che indicano la conferma dell'utente o il completamento del sondaggio.
Tipo di evento
explicit
|
|||
|
Soluzione Implementata
|
Il lavoro tecnico richiesto è stato completato dall'operatore. La richiesta è ora pronta per la conferma da parte dell'utente prima di essere risolta formalmente. | ||
|
Perché è importante
Questa attività separa il completamento tecnico dalla risoluzione formale, aiutando a identificare eventuali ritardi tra la fine del lavoro e la conferma dell'utente.
Dove trovare
Può essere dedotto dal cambio di stato in un ticket di evasione backend (es. Work Order passato a 'Completed') prima che la richiesta madre SRM:Request sia risolta.
Acquisisci
Timestamp di quando un ticket backend (Work Order, Incident, ecc.) collegato a SRM:Request viene segnato come completato.
Tipo di evento
inferred
|
|||