> Miglioramento continuo dei processi > Gestione delle richieste di servizio > BMC Helix ITSM > Template dei dati

Il Suo Template dati per la gestione delle richieste di servizio

BMC Helix ITSM

Attributi della gestione delle richieste di servizio (20) Attività di gestione delle richieste di servizio (14) Guide all'estrazione (3)

Il Suo Template dati per la gestione delle richieste di servizio

Questo Template offre una panoramica chiara degli attributi di dati essenziali da raccogliere e delle attività principali da monitorare nel processo di gestione delle richieste di servizio. Include inoltre indicazioni pratiche per estrarre questi dati in modo efficiente da BMC Helix ITSM. Utilizzi questa risorsa per semplificare la preparazione dei dati e avviare con sicurezza le iniziative di Process Mining.

Attributi consigliati da raccogliere
Attività principali da monitorare
Indicazioni per l'estrazione da BMC Helix ITSM

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il Template

Attributi della gestione delle richieste di servizio

Questi campi dati sono essenziali per creare un Event Log completo e consentire un’analisi approfondita del processo di gestione delle richieste di servizio.

5 Obbligatorio 6 Consigliato 9 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Il nome dell'evento o dell'attività specifica che si è verificata in un determinato momento del ciclo di vita della richiesta di servizio.
Descrizione Questo attributo descrive una fase specifica o una modifica dello stato nel processo di richiesta di servizio, come «Request In Review», «Fulfillment In Progress» o «Service Request Resolved». Ogni attività rappresenta un singolo evento nel percorso end-to-end di una richiesta di servizio. L'analisi della sequenza e della frequenza delle attività costituisce il nucleo del Process Mining. Consente di individuare le mappe di processo, identificare i colli di bottiglia e analizzare le varianti di processo. Comprendere quali attività si verificano, in quale ordine e con quale frequenza è fondamentale per ottimizzare il processo. Perché è importante Le attività costituiscono gli elementi fondamentali della mappa di processo. Monitorarle consente di visualizzare e analizzare il flusso del processo, mostrando come viene effettivamente svolto il lavoro. Dove reperirlo In genere deriva dalle modifiche apportate ai campi «Status» e «Status Reason» del modulo «SRM:Request» o dai registri delle applicazioni di evasione correlate, ad esempio Incident o Work Order. Esempi Richiesta in attesa di approvazioneEvasione in corsoRichiesta di servizio risoltaRichiesta di servizio chiusa
	ID della richiesta di assistenza ServiceRequestId	L'identificativo univoco di ogni richiesta di servizio, che funge da chiave primaria per monitorarne l'intero ciclo di vita.
Descrizione Il Service Request ID identifica in modo univoco ogni singola richiesta di servizio inviata da un utente o da un sistema. Costituisce il filo conduttore che collega tutti gli eventi successivi, dalla registrazione iniziale alla chiusura definitiva, consentendo un'analisi completa, end-to-end, del percorso di ogni richiesta di servizio. Nel Process Mining, questo ID è essenziale per ricostruire la sequenza delle attività di ogni caso. Consente allo strumento di raggruppare tutti gli eventi correlati, come «Request Submitted», «Request Assigned» e «Service Request Closed», in una singola istanza di processo, costituendo la base di ogni analisi di processo. Perché è importante È l'identificativo fondamentale del caso. Senza di esso è impossibile tracciare il percorso end-to-end di una richiesta di servizio, rendendo impossibili la process discovery e l'analisi. Dove reperirlo In genere corrisponde al campo «InstanceId» o «Request Number» nel modulo «SRM:Request» di BMC Helix ITSM. Esempi SR000010572931SR000010572932SR000010572933
	Ora di inizio EventStartTime	Il timestamp che indica quando è iniziata una specifica attività o un determinato evento.
Descrizione Questo attributo registra la data e l'ora precise di inizio di un'attività. Ogni evento nel log, dall'invio iniziale alla chiusura definitiva, deve avere un'ora di inizio per stabilire la sequenza cronologica del processo. Questo timestamp è fondamentale per tutte le analisi di Process Mining basate sul tempo. Viene utilizzato per calcolare i tempi di ciclo, la durata delle attività e i tempi di attesa tra le fasi, nonché per verificare la conformità agli SLA. Consente di individuare i colli di bottiglia e analizzare le prestazioni del processo nel tempo. Perché è importante L'ora di inizio stabilisce l'ordine cronologico degli eventi, essenziale per calcolare la durata dei processi, individuare i ritardi e comprendere la sequenza temporale del processo. Dove reperirlo Corrisponde ai campi timestamp nei registri di audit o nelle tabelle della cronologia degli stati associate al modulo «SRM:Request», come «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 dal quale sono stati estratti i dati.
Descrizione Questo attributo specifica l'origine dei dati di processo. In questa vista verrebbe impostato staticamente su «BMC Helix ITSM» per indicare che tutti gli eventi relativi alle richieste di servizio provengono da questo sistema. Negli ambienti con più sistemi integrati, questo campo è fondamentale per comprendere la provenienza dei dati e suddividerli in base all'origine. Garantisce chiarezza e tracciabilità, soprattutto quando si uniscono dati provenienti da piattaforme diverse. Perché è importante Fornisce il contesto sull'origine dei dati, un elemento importante per la governance dei dati, la tracciabilità e la risoluzione dei problemi negli ambienti con più sistemi. Dove reperirlo È un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati, non un campo presente in BMC Helix ITSM. Esempi BMC Helix ITSM
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp dell'ultimo aggiornamento dei dati relativi a questo processo dal sistema di origine.
Descrizione Questo attributo indica la data e l'ora dell'estrazione più recente dei dati da BMC Helix ITSM. Fornisce agli utenti il contesto sull'aggiornamento dei dati analizzati, assicurando che siano consapevoli del periodo coperto dall'analisi. È un attributo di metadati fondamentale per qualsiasi Dashboard o analisi di Process Mining. Consente di capire se gli insight si basano su dati quasi in tempo reale o su uno snapshot storico, un aspetto che influisce sulla validità e sulla rilevanza delle conclusioni. Perché è importante Informa gli utenti sull'attualità dei dati, un elemento essenziale per prendere decisioni basate sulle informazioni più aggiornate disponibili sulle prestazioni del processo. Dove reperirlo Questo timestamp viene generato e aggiunto durante il processo di estrazione e caricamento dei dati. Esempi 2024-05-21T08:00:00Z
	Agente assegnato AssignedAgent	L'utente attualmente incaricato di lavorare sulla richiesta di servizio.
Descrizione Questo attributo identifica l'agente IT o il membro del personale di supporto specificamente responsabile della richiesta in un determinato momento. Le modifiche a questo campo durante il ciclo di vita di una singola richiesta indicano un passaggio di consegne o una riassegnazione. L'attributo è fondamentale per analizzare le prestazioni e il carico di lavoro degli agenti. Consente di monitorare quante richieste gestisce ciascun agente, il tempo medio di risoluzione e la frequenza delle riassegnazioni. Questi dati supportano la gestione delle risorse e l'individuazione delle opportunità di formazione. Perché è importante Monitorare l'agente assegnato è essenziale per analizzare i passaggi di consegne, misurare le prestazioni individuali e comprendere la distribuzione del carico di lavoro nel team di supporto. Dove reperirlo Corrisponde al campo «Assignee» o «Assigned To» del record di evasione, ad esempio Work Order o Incident, associato alla richiesta di servizio. Esempi Bob SmithAlice JohnsonCharlie Brown
	Ora di fine EventEndTime	Il timestamp che indica quando una specifica attività o un determinato evento è stato completato.
Descrizione L'ora di fine indica la conclusione di un'attività. Sebbene nei sistemi ITSM molte attività siano modifiche istantanee dello stato, alcune hanno una durata misurabile. Disporre dell'ora di fine consente di calcolare con precisione la durata di tali attività. Nell'analisi, l'ora di fine viene utilizzata insieme all'ora di inizio per calcolare il tempo di elaborazione delle singole attività. Ciò aiuta a individuare quali attività specifiche, e non soltanto i tempi di attesa tra una fase e l'altra, assorbono più tempo nel processo. Perché è importante Consente di calcolare i tempi di elaborazione delle attività, un elemento fondamentale per identificare le fasi inefficienti e comprendere dove viene impiegato il tempo delle risorse. Dove reperirlo Può essere derivata. L'ora di fine di un'attività coincide spesso con l'ora di inizio dell'attività sequenziale successiva per lo stesso caso. Per l'attività finale corrisponderebbe 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 di servizio, che ne indica l'impatto e l'urgenza per l'azienda.
Descrizione La priorità determina l'ordine e la rapidità con cui devono essere gestite le richieste. I valori comuni includono «Critical», «High», «Medium» e «Low». L'assegnazione si basa spesso sulla combinazione dell'impatto della richiesta sull'azienda e della relativa urgenza. L'analisi per priorità è essenziale per valutare se le richieste ad alta priorità vengono elaborate più rapidamente di quelle a bassa priorità. È una dimensione chiave delle Dashboard dedicate ai tempi di risoluzione e alla conformità agli SLA e contribuisce ad assicurare che le risorse siano assegnate in modo adeguato alle esigenze aziendali più critiche. Perché è importante Aiuta a valutare se il processo assegna correttamente le priorità al lavoro e rispetta i livelli di servizio attesi per le richieste con diversi livelli di impatto aziendale. Dove reperirlo È il campo «Priority» del modulo «SRM:Request». Esempi CriticaAltaMediaBassa
	Stato della richiesta RequestStatus	Lo stato della richiesta di servizio al momento dell'evento, ad esempio «In Progress», «Pending» o «Closed».
Descrizione Questo attributo registra lo stato della richiesta di servizio nei diversi momenti del suo ciclo di vita. Lo stato fornisce il contesto di ogni attività ed è spesso la fonte da cui viene derivato lo stesso attributo «Activity». L'analisi per stato aiuta a comprendere quanto tempo le richieste trascorrono in determinati stati, come «Pending Customer» o «Waiting for Approval». È essenziale per individuare i colli di bottiglia e i ritardi causati da dipendenze esterne o code interne. Supporta direttamente la Dashboard Bottleneck Identification. Perché è importante Fornisce un'istantanea dello stato della richiesta, consentendo di analizzare il tempo trascorso negli stati di attesa rispetto a quelli attivi, un elemento chiave per identificare i colli di bottiglia. Dove reperirlo È il campo «Status» del modulo «SRM:Request». I valori storici sono disponibili nel registro di audit. Esempi PianificazioneIn corsoIn attesaRisoltaChiusa
	Team assegnato AssignedTeam	Il gruppo o il team di supporto attualmente assegnato alla richiesta di servizio.
Descrizione Questo attributo identifica il gruppo funzionale responsabile della gestione della richiesta, come «Help Desk», «Network Team» o «Database Administration». Una modifica a questo campo indica un trasferimento di responsabilità tra team. L'analisi basata sul team assegnato aiuta a individuare i colli di bottiglia a livello di team, analizzare i passaggi di consegne tra team e valutare l'efficienza dei diversi gruppi di supporto. È fondamentale per le Dashboard Request Rework and Reassignment e Triage Efficiency, poiché rivela come il lavoro viene instradato nell'organizzazione. Perché è importante Consente di analizzare il flusso del processo tra diversi gruppi funzionali, aiutando a individuare inefficienze nell'instradamento e a misurare le prestazioni a livello di team. Dove reperirlo Corrisponde al campo «Assigned Group» del record di evasione, ad esempio Work Order o Incident, associato alla richiesta di servizio. Esempi Service DeskSupporto infrastrutturaleSupporto applicativo di livello 2
	Tipo di servizio ServiceType	La categoria o il tipo di servizio richiesto dall'utente.
Descrizione Il tipo di servizio classifica la natura della richiesta, ad esempio «Request New Software», «Password Reset» o «Onboard New Employee». È una dimensione fondamentale per filtrare e segmentare i dati di processo. Nell'analisi dei processi, questo attributo viene utilizzato per confrontare le prestazioni dei diversi tipi di richiesta. Aiuta a rispondere a domande come «Quali tipi di servizio richiedono più tempo per essere risolti?» o «Quali tipi di servizio presentano il maggior numero di rilavorazioni?». È fondamentale per le Dashboard Resolution Time e SLA Compliance. Perché è importante Consente di segmentare le richieste di servizio per confrontare i flussi di processo, individuare problemi specifici del tipo di richiesta e definire interventi di ottimizzazione mirati. Dove reperirlo Questi dati si trovano spesso nel campo «Title» o in un campo di categorizzazione del modulo «SRM:Request» e derivano dal servizio selezionato nel catalogo. Esempi Richiesta di nuovo hardwareRichiesta di accesso al softwareConfigurazione dell'accesso VPN
	Canale di invio SubmissionChannel	Il metodo o il canale attraverso cui è stata inviata la richiesta di servizio.
Descrizione Questo attributo registra come è stata avviata la richiesta di servizio, ad esempio tramite un portale self-service, e-mail, telefonata al service desk o avviso di sistema automatizzato. Canali diversi possono generare varianti di processo e tempi di risoluzione differenti. Analizzare il processo in base al canale di invio può rivelare inefficienze o best practice associate a specifici metodi di acquisizione. Per esempio, le richieste inviate tramite il portale self-service possono essere risolte più rapidamente grazie a una migliore qualità iniziale dei dati, mentre quelle ricevute via e-mail possono richiedere un triage più manuale. Perché è importante Aiuta a comprendere in che modo il metodo di acquisizione influisce sull'efficienza del processo, sulla qualità dei dati e sul tempo complessivo di ciclo, consentendo di definire miglioramenti mirati per i singoli canali. Dove reperirlo Spesso può essere dedotto da campi come «Client Type» o «Reported Source» del modulo «SRM:Request» o dei ticket di evasione associati. Esempi Portale self-serviceE-mailTelefonoGenerata dal sistema
	Categoria di risoluzione ResolutionCategory	La classificazione della soluzione fornita per risolvere la richiesta.
Descrizione Questo attributo fornisce una categorizzazione strutturata delle modalità di risoluzione di una richiesta, come «Software Fix», «User Training» o «Data Correction». Va oltre un semplice codice di chiusura, descrivendo la natura della risoluzione. È essenziale per la Dashboard Resolution Category Accuracy, nella quale può essere confrontato con il tipo di servizio iniziale per verificarne la coerenza. L'analisi delle categorie di risoluzione aiuta a individuare le tendenze relative ai problemi e orienta la gestione proattiva dei problemi, per esempio quando molte richieste vengono risolte tramite formazione degli utenti. Perché è importante Offre una visione della natura delle soluzioni, aiutando a identificare le tendenze relative ai problemi ricorrenti e le opportunità per una gestione proattiva dei problemi o per la formazione degli utenti. Dove reperirlo Queste informazioni fanno parte dei campi di categorizzazione operativa e del prodotto presenti nel ticket di evasione, spesso denominati «Resolution Category». Esempi Amministrazione degli accountGuasto hardwareAggiornamento del softwareInformazioni fornite
	Codice di chiusura CloseCode	Un codice che indica l'esito finale o il motivo della chiusura della richiesta di servizio.
Descrizione Il codice di chiusura fornisce un metodo standardizzato per classificare la risoluzione di una richiesta di servizio. Tra gli esempi figurano «Resolved by Service Desk», «Canceled by User» o «Duplicate Request». L'analisi dei codici di chiusura aiuta a comprendere gli esiti più comuni delle richieste. Può evidenziare problemi come un numero elevato di richieste annullate dagli utenti, che potrebbe indicare un processo troppo lungo, oppure numerose richieste duplicate, che potrebbero segnalare un problema di sistema o di comunicazione. Questo attributo supporta la Dashboard Resolution Category Accuracy. Perché è importante Fornisce dati strutturati sugli esiti delle richieste, consentendo di analizzare l'efficacia della risoluzione e le ragioni della mancata conclusione o dell'annullamento. Dove reperirlo Queste informazioni si trovano generalmente in un campo «Resolution» o «Closure Code» del ticket di evasione associato alla richiesta di servizio. Esempi Completata con successoAnnullata dall'utenteNon più necessariaRisoluzione automatizzata
	Data obiettivo SLA SlaTargetDate	La data e l'ora entro cui si prevede che la richiesta di servizio venga risolta in base al relativo Service Level Agreement (SLA).
Descrizione La data obiettivo SLA è un timestamp calcolato che rappresenta la scadenza per completare la richiesta di servizio. Viene determinata dalle regole dell'accordo sul livello di servizio, che spesso tengono conto di fattori come la priorità e il tipo di richiesta. Questo attributo è fondamentale per la Dashboard SLA Compliance Overview. Costituisce il riferimento rispetto al quale viene misurato il tempo effettivo di risoluzione. Confrontando l'«EventEndTime» dell'attività finale di risoluzione con questa data obiettivo, è possibile determinare se l'impegno di servizio è stato rispettato. Perché è importante È il principale riferimento per misurare le prestazioni del servizio rispetto agli impegni assunti, risultando quindi essenziale per il monitoraggio e la reportistica sulla conformità agli SLA. Dove reperirlo Questa data viene calcolata e memorizzata dal modulo Service Level Management (SLM) e può essere reperita nei moduli SLM correlati collegati alla richiesta di servizio. Esempi 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
	È stato sottoposto a escalation IsEscalated	Flag booleano che indica se la richiesta di servizio è stata sottoposta a escalation.
Descrizione Questo flag è impostato su true se una richiesta di servizio è stata sottoposta a un'escalation funzionale o gerarchica. In genere si ricorre all'escalation quando una richiesta non procede come previsto, rischia di violare uno SLA oppure richiede l'approvazione o l'intervento di un'autorità superiore. Questo attributo è fondamentale per la Dashboard Request Escalation Efficiency Analysis. Consente di filtrare e analizzare i percorsi di processo delle richieste sottoposte a escalation, per comprendere quali fattori le attivano, quanto tempo richiede la loro risoluzione dopo l'escalation e quanto è efficace il processo di escalation. Perché è importante Consente di isolare e analizzare il sottoinsieme di richieste che ha richiesto un'escalation, aiutando a individuare le debolezze del processo standard o i fattori che attivano la gestione dei problemi complessi. Dove reperirlo In genere non si tratta di un singolo campo. Il valore viene ricavato verificando la presenza di specifiche attività correlate all'escalation nell'audit log oppure di modifiche alla priorità o all'assegnazione successive all'applicazione di un protocollo di escalation. Esempi truefalse
	È una rielaborazione IsRework	Flag booleano che indica se una richiesta di servizio è stata sottoposta a rielaborazione, ad esempio tornando a una fase precedente.
Descrizione Questo flag identifica le richieste di servizio che hanno seguito un ciclo o una rielaborazione nel proprio flusso di processo. Ad esempio, una richiesta che passa da «Fulfillment in Progress» a «Request in Review» viene considerata una rielaborazione. La definizione esatta dipende dalla logica del processo aziendale. Questo attributo supporta direttamente la Dashboard Request Rework and Reassignment Analysis e il KPI Request Rework Rate. Consente di quantificare la frequenza delle rielaborazioni e di analizzarne le cause più comuni, come una valutazione iniziale errata o informazioni incomplete, che generano inefficienze di processo. Perché è importante Quantifica l'inefficienza del processo segnalando i casi che si discostano dal «percorso standard», aiutando a individuare le cause principali dei cicli e delle attività ripetute. Dove reperirlo Si tratta di un attributo calcolato, ricavato dalla sequenza delle attività nell'event log. È necessaria una logica specifica per rilevare i movimenti a ritroso nel flusso di processo. Esempi truefalse
	Numero di passaggi di consegna HandoffCount	Il numero complessivo di volte in cui una richiesta di servizio è stata riassegnata tra agenti o team diversi.
Descrizione Questa metrica calcolata conta il numero di volte in cui «AssignedAgent» o «AssignedTeam» cambia per una singola richiesta di servizio. Un numero elevato di passaggi di consegna può indicare frammentazione del processo, una bassa percentuale di risoluzione al primo contatto o un instradamento inefficiente. Questo attributo costituisce la base del KPI Average Agent Handoffs per Request e viene utilizzato nella Dashboard Request Rework and Reassignment. L'analisi dei casi con un numero elevato di passaggi di consegna può evidenziare opportunità per migliorare il triage, offrire una formazione più efficace o semplificare il processo di risoluzione, riducendo i ritardi e aumentando la soddisfazione dei clienti. Perché è importante Misura la frammentazione del processo e il sovraccarico comunicativo. Un numero elevato di passaggi di consegna è spesso correlato a tempi di risoluzione più lunghi e a una minore efficienza del processo. Dove reperirlo Si tratta di una metrica calcolata, ottenuta contando il numero di valori distinti dell'attributo «AssignedAgent» o «AssignedTeam» per ogni Service Request ID univoco. Esempi 0135
	Reparto del richiedente RequestorDepartment	Il reparto o l'unità aziendale dell'utente che ha inviato la richiesta.
Descrizione Questo attributo identifica il reparto organizzativo della persona che richiede il servizio, come «Finance», «Human Resources» o «IT». Queste informazioni provengono generalmente dal profilo dell'utente nel sistema. Segmentare l'analisi del processo per reparto consente di individuare esigenze specifiche, modelli di richiesta e potenziali aree per interventi formativi o miglioramenti mirati del servizio. Aiuta a rispondere a domande come «Il reparto Finance deve affrontare tempi di attesa più lunghi per le proprie richieste?». Perché è importante Consente di analizzare il consumo dei servizi e le prestazioni del processo per unità aziendale, evidenziando eventuali problemi o tendenze specifici di un reparto. Dove reperirlo Queste informazioni vengono generalmente recuperate dal profilo dell'utente associato all'utente «Requested For» nel modulo «SRM:Request». Esempi FinanzaVenditeRisorse umaneTecnologie dell'informazione
	SLA violato IsSlaBreached	Flag booleano che indica se la richiesta di servizio è stata risolta dopo la data obiettivo dello SLA.
Descrizione Questo flag calcolato è impostato su true se il timestamp della risoluzione finale della richiesta di servizio è successivo alla «SLA Target Date». Fornisce un esito semplice e binario delle prestazioni SLA per ogni richiesta. Questo attributo è essenziale per la Dashboard SLA Compliance Overview e per il KPI SLA Adherence Rate. Consente di aggregare facilmente i dati per calcolare i tassi complessivi di conformità e di applicare filtri per analizzare le caratteristiche di processo delle richieste con SLA violato rispetto a quelle conformi, aiutando a individuare le cause principali delle violazioni SLA. Perché è importante Semplifica l'analisi delle prestazioni SLA trasformando il confronto tra timestamp in un semplice flag booleano, così da rendere agevoli la misurazione e la visualizzazione dei tassi di conformità. Dove reperirlo Si tratta di un campo calcolato. La logica è: IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false. Esempi truefalse

Obbligatorio Consigliato Facoltativo

Attività di gestione delle richieste di servizio

Questi passaggi chiave e queste tappe fondamentali del processo devono essere acquisiti nel Suo Event Log per una corretta individuazione e visualizzazione del processo.

6 Consigliato 8 Facoltativo

	Attività	Descrizione
	Evasione in corso	L'agente o il team assegnato ha iniziato a lavorare attivamente sull'evasione della richiesta di servizio. Ciò indica che la richiesta è passata dalla coda a uno stato di lavorazione attiva.
Perché è importante Segna l'inizio del lavoro di evasione che genera valore. Analizzare il tempo trascorso in questa fase aiuta a comprendere la produttività delle risorse e la complessità dell'evasione. Dove reperirlo Deducibile da una modifica dello stato nel modulo SRM:Request a «In Progress». Acquisizione Timestamp dell'evento di aggiornamento in cui il campo «Status» di SRM:Request passa a «In Progress». Tipo di evento inferred
	Richiesta assegnata	La richiesta di servizio è stata assegnata a un agente o a un team specifico incaricato di completare il lavoro. Questo segna la conclusione della fase di triage.
Perché è importante Questa tappa è fondamentale per misurare il tempo di triage e analizzare il carico di lavoro degli agenti. Riassegnazioni frequenti possono indicare problemi di instradamento o lacune nelle competenze. Dove reperirlo Questo evento può essere acquisito esplicitamente dal registro di audit dei campi «Assigned Group» o «Assignee» di SRM:Request o dei relativi moduli applicativi di evasione, ad esempio WOI:WorkOrder. Acquisizione Timestamp del registro di audit che mostra, per la prima volta, l'impostazione di un valore non nullo nel campo «Assignee». Tipo di evento explicit
	Richiesta di servizio annullata	La richiesta di servizio è stata ritirata dal richiedente o dal service desk prima del completamento dell'evasione. Si tratta di uno stato terminale della richiesta.
Perché è importante Il monitoraggio degli annullamenti aiuta a individuare schemi ricorrenti, ad esempio richieste inviate erroneamente dagli utenti o servizi non più necessari, fornendo indicazioni utili per migliorare il catalogo dei servizi. Dove reperirlo Deducibile da una modifica dello stato nel modulo SRM:Request a «Canceled». Acquisizione Timestamp dell'evento di aggiornamento in cui il campo «Status» di SRM:Request passa a «Canceled». Tipo di evento inferred
	Richiesta di servizio chiusa	La richiesta di servizio viene chiusa formalmente e trasferita in uno stato di sola lettura e archiviazione. Ciò avviene dopo la risoluzione e il decorso dell'eventuale periodo di conferma.
Perché è importante Questa attività rappresenta la conclusione definitiva del processo. Il tempo tra «Resolved» e «Closed» può evidenziare inefficienze nella procedura di chiusura. Dove reperirlo Deducibile dalla modifica finale dello stato nel modulo SRM:Request a «Closed». Acquisizione Timestamp dell'evento di aggiornamento in cui il campo «Status» di SRM:Request passa a «Closed». Tipo di evento inferred
	Richiesta di servizio inviata	Questa attività indica la creazione e l'invio di una nuova richiesta di servizio da parte di un utente. Viene registrata quando nel modulo SRM:Request viene creata una nuova voce con uno stato iniziale, generalmente «Submitted».
Perché è importante È il punto di partenza di ogni caso di richiesta di servizio, essenziale per misurare la durata complessiva del ciclo di vita e analizzare i volumi delle richieste ricevute. Dove reperirlo Questo evento viene dedotto dal timestamp di creazione e dallo stato iniziale, ad esempio «Submitted», di un record nel modulo SRM:Request. Acquisizione Identificare il timestamp di creazione di 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 di servizio è completata e la risoluzione è stata comunicata al richiedente. La richiesta attende la conferma finale oppure verrà chiusa automaticamente dopo un periodo prestabilito.
Perché è importante Una tappa fondamentale che segna la conclusione del ciclo di erogazione del servizio. È il principale punto finale per misurare il tempo di risoluzione e il rispetto degli SLA. Dove reperirlo Deducibile da una modifica dello stato nel modulo SRM:Request a «Resolved» o «Completed». Acquisizione Timestamp dell'evento di aggiornamento in cui il campo «Status» di SRM:Request passa a «Resolved» o «Completed». Tipo di evento inferred
	Informazioni richieste all'utente	L'agente incaricato dell'evasione necessita di ulteriori informazioni da parte del richiedente per poter procedere. La richiesta viene generalmente posta nello stato «Pending».
Perché è importante Questa attività è fondamentale per calcolare l'«External Information Wait Time» e individuare la frequenza con cui le richieste si bloccano a causa di informazioni incomplete. Dove reperirlo Deducibile da una modifica dello stato nel modulo SRM:Request a «Pending», con una motivazione come «Customer Hold» o «Awaiting Information». Acquisizione Timestamp della modifica dello stato a «Pending», associato a una motivazione specifica. Tipo di evento inferred
	Richiesta approvata	La richiesta di servizio è stata formalmente approvata dalla parte competente, consentendo l'avvio del processo di evasione. Questo evento segue generalmente lo stato «Waiting for Approval».
Perché è importante Segna la conclusione del sottoprocesso di approvazione ed è una tappa fondamentale per monitorare la durata delle approvazioni e il loro impatto sul tempo complessivo di risoluzione. Dove reperirlo Deducibile da una modifica dello stato nel modulo SRM:Request da «Waiting Approval» a uno stato successivo come «Planning» o «In Progress». La decisione di approvazione viene registrata nei relativi moduli di approvazione. Acquisizione Timestamp della modifica di stato in uscita da «Waiting Approval» dopo una decisione di approvazione positiva. Tipo di evento inferred
	Richiesta in attesa di approvazione	La richiesta di servizio è stata sottoposta a un approvatore designato o a un gruppo di approvazione e attende una decisione prima che possa iniziare l'evasione. È una fase comune per le richieste che comportano costi o diritti di accesso.
Perché è importante Questa attività isola i ritardi legati all'approvazione, consentendo di analizzare i tempi del ciclo di approvazione e di individuare i colli di bottiglia nella catena approvativa. Dove reperirlo Deducibile da una modifica dello stato nel modulo SRM:Request a un valore come «Waiting Approval». Acquisizione Timestamp dell'evento di aggiornamento in cui il campo «Status» di SRM:Request passa a «Waiting Approval». Tipo di evento inferred
	Richiesta in revisione	La richiesta di servizio è sottoposta alla revisione iniziale e al triage da parte del service desk, che ne determina natura, priorità e team incaricato dell'evasione. Questa fase è generalmente rappresentata da una modifica dello stato nel record della richiesta.
Perché è importante Il monitoraggio di questa attività consente di misurare l'efficienza del triage e di individuare i ritardi tra l'invio e l'assegnazione, un aspetto fondamentale per il KPI «Average Triage Time». Dove reperirlo Deducibile da una modifica dello stato nel modulo SRM:Request a un valore come «In Review» o «Planning». Acquisizione Timestamp dell'evento di aggiornamento in cui il campo «Status» di SRM:Request passa a «In Review». Tipo di evento inferred
	Richiesta rifiutata	La richiesta di servizio è stata negata durante una fase di approvazione. Si tratta di uno stato terminale che interrompe il processo prima dell'inizio dell'evasione.
Perché è importante L'analisi delle richieste rifiutate può evidenziare problemi nelle motivazioni delle richieste, nei criteri di ammissibilità o nelle politiche di approvazione. Dove reperirlo Deducibile da una modifica dello stato nel modulo SRM:Request a «Rejected». Acquisizione Timestamp dell'evento di aggiornamento in cui il campo «Status» di SRM:Request passa a «Rejected». Tipo di evento inferred
	Richiesta ripresa	La richiesta di servizio è stata rimossa dallo stato di sospensione o attesa, generalmente dopo che l'utente ha fornito le informazioni necessarie. L'agente incaricato riprende il lavoro sulla richiesta.
Perché è importante Segna la conclusione di un periodo di attesa, consentendo di misurare con precisione i tempi di attesa esterni e il loro impatto sulla conformità agli SLA. Dove reperirlo Deducibile quando lo stato di SRM:Request passa da «Pending» a «In Progress». Acquisizione Timestamp dell'evento di aggiornamento in cui il campo «Status» di SRM:Request passa da «Pending» a «In Progress». Tipo di evento inferred
	Risoluzione confermata dall'utente	Il richiedente ha confermato attivamente che il servizio è stato erogato in modo soddisfacente e che la richiesta è risolta. Questo spesso attiva la chiusura definitiva della richiesta.
Perché è importante Fornisce un indicatore chiaro della soddisfazione dell'utente e conclude formalmente l'interazione relativa al servizio. Distingue la risoluzione del processo dall'accettazione da parte dell'utente. Dove reperirlo Questo evento può essere acquisito nei registri di lavoro o nelle note dell'attività di SRM:Request quando l'utente conferma tramite il portale o via e-mail. Non è sempre rappresentato da uno stato distinto. Acquisizione Esaminare i registri di lavoro (SRM:WorkInfo) alla ricerca di voci specifiche che indichino la conferma dell'utente o il completamento del sondaggio. Tipo di evento explicit
	Soluzione implementata	Il lavoro tecnico necessario per evadere la richiesta di servizio è stato completato dall'agente. La richiesta è ora pronta per la conferma da parte dell'utente prima di essere formalmente risolta.
Perché è importante Questa attività separa il completamento tecnico dalla risoluzione formale, aiutando a individuare eventuali ritardi tra la conclusione del lavoro e la conferma dell'utente. Dove reperirlo Può essere dedotta da una modifica dello stato su un ticket di evasione backend, ad esempio dallo stato «Completed» di un Work Order, prima che la SRM:Request principale venga impostata su «Resolved». Acquisizione Timestamp in cui un ticket backend, come Work Order o Incident, collegato a SRM:Request viene contrassegnato come completato. Tipo di evento inferred

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i Suoi dati da BMC Helix ITSM

Passaggi

Accesso a Smart Reporting: Acceda al Suo ambiente BMC Helix ITSM. Passi alla sezione dei report e avvii Smart Reporting. A seconda della versione, questa funzione potrebbe essere denominata 'Report' o 'Smart Reporting'.
Creazione di un nuovo report: Nell’interfaccia Smart Reporting, selezioni l’opzione per creare un nuovo report. Scelga 'Report' come tipo.
Selezione dell’origine dei dati e della vista: Le verrà richiesto di selezionare un’origine dei dati. Scelga l’origine principale dei dati AR System. Per la vista, cerchi e selezioni la vista Service Request, che in genere si basa sul modulo SRM:Request.
Aggiunta di moduli aggiuntivi, join: Per acquisire l’intero ciclo di vita, deve unire il modulo principale SRM:Request ai moduli correlati. Utilizzi la scheda 'Data' e aggiunga le seguenti join:
- SRM:WorkInfo su SR ID+ = Request Number, per ottenere i dettagli sulle attività di evasione e sui registri di lavoro.
- AP:Signature su Request = SRInstanceID, per ottenere eventi relativi alle approvazioni, come approvazioni e rifiuti. Potrebbe essere necessaria una join personalizzata.
Definizione delle colonne del report: Trascini i campi richiesti dai moduli collegati nell’area 'Columns'. Sono inclusi campi come Request Number, Submit Date, Stato, Descrizione, Priority, Assigned To e Assigned Group da SRM:Request, oltre ai campi correlati dei moduli collegati.
Creazione dei campi calcolati per le attività: Il punto centrale di questo metodo consiste nel creare una serie di campi calcolati per rappresentare la marca temporale di ciascuna attività. Acceda alla scheda 'Data' e crei un nuovo campo calcolato per ogni attività. Ad esempio:
- Marca temporale di invio: utilizzi direttamente il campo Submit Date.
- Marca temporale di approvazione: utilizzi Signature Date dal modulo AP:Signature.
- Marca temporale di lavorazione in corso: utilizzi MIN(Submit Date) da SRM:WorkInfo, raggruppato per Request Number.
Strutturazione del report per l’unione: Smart Reporting non dispone di un semplice pulsante 'UNION ALL' come SQL. Per ottenere questo risultato, crei un unico report e utilizzi funzioni avanzate o sottoquery per trasformare i dati. Una tecnica comune consiste nel creare più colonne calcolate, una per la marca temporale di ciascuna attività. Dovrà quindi formattare l’esportazione finale per trasformare queste colonne in righe separate per ogni attività.
Applicazione dei filtri: Per limitare l’ambito dei dati e migliorare le prestazioni, aggiunga filtri al report. Come minimo, filtri Submit Date del modulo SRM:Request per selezionare un intervallo di date specifico. Aggiunga inoltre filtri per 'Company' se opera in un ambiente multi-tenant.
Esecuzione e anteprima dei dati: Esegua il report per assicurarsi che i dati vengano recuperati correttamente. Verifichi le join, le colonne compilate e che i campi calcolati restituiscano le marche temporali previste.
Esportazione del report: Dopo aver convalidato il report, esporti i dati. Scelga CSV o Microsoft Excel come formato di esportazione, poiché sono facilmente elaborabili per l’importazione negli strumenti di Process Mining.
Trasformazione finale dei dati: Dopo l’esportazione, deve trasformare i dati dal formato wide, con una riga per ogni richiesta di servizio e numerose colonne di marche temporali, al formato long, con una riga per ogni attività. Utilizzi uno script, ad esempio Python o PowerShell, oppure uno strumento come Excel Power Query per annullare il pivot delle colonne delle marche temporali e ottenere due colonne: ActivityName e EventStartTime. Questo passaggio è fondamentale per creare la struttura richiesta dell’Event Log.

Configurazione

Prerequisiti: deve disporre di un account utente con autorizzazioni di reporting in BMC Helix ITSM, in particolare dell'accesso per creare ed eseguire report in Smart Reporting. Sono inoltre necessarie autorizzazioni di lettura per i moduli SRM:Request, SRM:WorkInfo e AP:Signature.
Moduli principali: il report viene creato unendo questi moduli fondamentali:
- SRM:Request: il modulo principale che contiene i dettagli essenziali della richiesta di servizio.
- SRM:WorkInfo: contiene le voci del worklog, utilizzate per ricavare le attività di evasione.
- AP:Signature: contiene i record delle approvazioni, essenziali per monitorare le attività correlate alle approvazioni.
Filtro per intervallo di date: applichi sempre un filtro per intervallo di date al campo SRM:Request.Submit Date. Si consiglia un intervallo compreso tra 3 e 6 mesi, così da bilanciare la rappresentatività del campione e le prestazioni del report.
Filtri importanti: oltre all'intervallo di date, applichi un filtro su Company per isolare i dati di una specifica entità aziendale. Potrebbe inoltre voler escludere determinati tipi di richiesta o stati, come «Draft», non pertinenti all'analisi del processo.
Considerazioni sulle prestazioni: i report che uniscono più moduli su un intervallo di date ampio possono richiedere molto tempo per essere generati. Per grandi volumi di dati, si consiglia vivamente di pianificare l'esecuzione del report nelle ore di minore attività. Se si verificano timeout, valuti di suddividere l'estrazione in blocchi mensili più piccoli.

a Query di esempio sql

/*
This is a conceptual SQL query representing the logic you would build in the BMC Helix ITSM Smart Reporting UI.
Smart Reporting uses a graphical interface, so you will create this structure by joining forms and creating calculated fields that correspond to each SELECT block below.
The final step of unpivoting data from columns to rows must be done after exporting the report.
*/

-- 1. Service Request Submitted
SELECT
  'Service Request Submitted' AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType", -- Or another field representing the service
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 2, 3, 4, 14: Approval Steps (Waiting, Approved, Rejected)
SELECT
  CASE sig."Outcome" WHEN 'Approved' THEN 'Request Approved' WHEN 'Rejected' THEN 'Request Rejected' ELSE 'Request Waiting for Approval' END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  sig."Signature Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
JOIN "AP:Signature" AS sig ON req."InstanceId" = sig."Request"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 5. Request Assigned (based on first Work Info entry)
SELECT
  'Request Assigned' AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  MIN(wi."Submit Date") AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY wi."Request Number", req."Status", req."Title", req."Priority", req."ASG_Assignee", req."Assigned Group"

UNION ALL

-- 6, 7, 8, 9: Fulfillment Steps from Work Logs
SELECT
  CASE 
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Fulfillment In Progress%' THEN 'Fulfillment In Progress'
    WHEN wi."Work Log Type" = 'Customer Communication' AND wi.Description LIKE '%Information Requested%' THEN 'Information Requested from User'
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Request Resumed%' THEN 'Request Resumed'
    WHEN wi."Work Log Type" = 'Resolution Communications' THEN 'Solution Implemented'
    ELSE NULL 
  END AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  wi."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND wi."Work Log Type" IN ('General Information', 'Customer Communication', 'Resolution Communications')

UNION ALL

-- 10, 11, 12, 13: Terminal Statuses (Resolved, Confirmed, Closed, Canceled)
SELECT
  CASE req."Status"
    WHEN 'Resolved' THEN 'Service Request Resolved'
    WHEN 'Closed' AND req."Status_Reason" = 'Confirmed' THEN 'Resolution Confirmed by User'
    WHEN 'Closed' THEN 'Service Request Closed'
    WHEN 'Cancelled' THEN 'Service Request Canceled'
    ELSE NULL
  END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Last Modified Date" AS "EventStartTime", -- This is an approximation of when the status change occurred
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND req."Status" IN ('Resolved', 'Closed', 'Cancelled')

Passaggi

Prerequisiti: si assicuri di disporre di un client database, come DBeaver, SQL Server Management Studio o Oracle SQL Developer, e di credenziali di sola lettura per il database BMC Helix AR System.
Si connetta al database: utilizzi il client database per stabilire una connessione al server del database AR System.
Prepari la query: copi l'intera query SQL fornita nella sezione «Query» di questo documento nell'editor di query del client database.
Imposti i parametri: individui i valori segnaposto nella query. Sostituisca :start_date e :end_date con l'intervallo di date desiderato per l'estrazione, ad esempio «2023-01-01» e «2023-12-31». Se applicabile, sostituisca :company_name con il nome specifico dell'azienda da utilizzare come filtro.
Esegua la query: esegua la query SQL modificata. A seconda dell'intervallo di date e delle dimensioni del sistema, l'operazione potrebbe richiedere diversi minuti.
Esamini i risultati: al termine della query verrà visualizzato un set di risultati contenente l'event log. Esamini brevemente i dati per verificare che siano stati popolati correttamente e contengano le colonne e le attività previste.
Gestisca i timestamp: verifichi che tutte le colonne timestamp, in particolare EventStartTime, EventEndTime e LastDataUpdate, siano formattate in modo coerente, ad esempio come «YYYY-MM-DD HH:MI:SS». Se il database restituisce un formato diverso, modifichi di conseguenza le funzioni TO_CHAR o CONVERT nella query.
Esporti i dati: utilizzi la funzione di esportazione del client database per salvare l'intero set di risultati in un file CSV. Scelga la codifica UTF-8 per garantire la compatibilità.
Prepari il caricamento: assegni al file un nome appropriato, ad esempio servicerequest_eventlog.csv. Il file è ora pronto per essere caricato sulla piattaforma ProcessMind.

Configurazione

Credenziali del database: è necessario un account utente di sola lettura per il database AR System. In questo modo si prevengono modifiche accidentali ai dati e si rispettano le best practice di sicurezza.
Filtro per intervallo di date: la query include i segnaposto :start_date e :end_date. È fondamentale impostare un intervallo di date specifico e ragionevole, in genere compreso tra 3 e 12 mesi di dati, per gestire le prestazioni della query e il volume dei dati. Il filtro viene applicato al campo Submit_Date della richiesta di servizio.
Filtro azienda: è incluso il segnaposto :company_name per filtrare le richieste relative a una specifica azienda operativa. Se deve estrarre i dati di tutte le aziende, può rimuovere la riga AND req.Company = :company_name oppure impostarla su un carattere jolly, se supportato.
Valori di stato: la query utilizza i valori interi standard degli stati di BMC Helix ITSM, ad esempio Submitted = 0 e In Review = 1. Il Suo sistema potrebbe utilizzare stati personalizzati o mappature intere diverse. Verifichi questi valori nel modulo SYS:Status o in Developer Studio e, se necessario, modifichi le clausole WHERE della query.
Prestazioni: le query dirette su tabelle di grandi dimensioni, come SRM_Request e i relativi audit log, possono richiedere molte risorse. Pianifichi l'estrazione nelle ore di minore attività per ridurre al minimo l'impatto sulle prestazioni del sistema.

a Query di esempio sql

WITH ServiceRequests AS (
  SELECT
    req.Request_Number AS ServiceRequestId,
    req.Submit_Date AS SubmitDate,
    req.Status AS CurrentStatus,
    req.Description AS ServiceType,
    req.Priority AS Priority,
    req.Assignee AS AssignedAgent,
    req.Assigned_Group AS AssignedTeam,
    req.Company,
    req.InstanceId
  FROM
    SRM_Request req
  WHERE
    req.Submit_Date BETWEEN TO_TIMESTAMP(:start_date, 'YYYY-MM-DD') AND TO_TIMESTAMP(:end_date, 'YYYY-MM-DD')
    AND req.Company = :company_name
)
-- 1. Service Request Submitted
SELECT
  sr.ServiceRequestId AS "ServiceRequestId",
  'Service Request Submitted' AS "ActivityName",
  sr.SubmitDate AS "EventStartTime",
  sr.SubmitDate AS "EventEndTime",
  'Submitted' AS "RequestStatus",
  sr.ServiceType AS "ServiceType",
  sr.Priority AS "Priority",
  sr.AssignedAgent AS "AssignedAgent",
  sr.AssignedTeam AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
UNION ALL
-- 2. Request In Review
SELECT
  sr.ServiceRequestId,
  'Request In Review' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Review' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Review%'
UNION ALL
-- 3. Request Waiting for Approval
SELECT
  sr.ServiceRequestId,
  'Request Waiting for Approval' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Waiting Approval' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Waiting Approval%'
UNION ALL
-- 4. Request Approved
SELECT
  sr.ServiceRequestId,
  'Request Approved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Approved' AS "RequestStatus", -- This status might vary, often transitions to Planning or Assigned
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Planning%' AND audit.Old_Values LIKE '%Waiting Approval%'
UNION ALL
-- 5. Request Assigned
SELECT
  sr.ServiceRequestId,
  'Request Assigned' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Assigned' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Assigned_Group%' AND audit.New_Values IS NOT NULL
UNION ALL
-- 6. Fulfillment In Progress
SELECT
  sr.ServiceRequestId,
  'Fulfillment In Progress' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%'
UNION ALL
-- 7. Information Requested from User
SELECT
  sr.ServiceRequestId,
  'Information Requested from User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Pending' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Pending%'
UNION ALL
-- 8. Request Resumed
SELECT
  sr.ServiceRequestId,
  'Request Resumed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%' AND audit.Old_Values LIKE '%Pending%'
UNION ALL
-- 9. Solution Implemented
SELECT
  sr.ServiceRequestId,
  'Solution Implemented' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Completed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Completed%'
UNION ALL
-- 10. Service Request Resolved
SELECT
  sr.ServiceRequestId,
  'Service Request Resolved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Resolved' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Resolved%'
UNION ALL
-- 11. Resolution Confirmed by User
SELECT
  sr.ServiceRequestId,
  'Resolution Confirmed by User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%' AND audit.Old_Values LIKE '%Resolved%'
UNION ALL
-- 12. Service Request Closed
SELECT
  sr.ServiceRequestId,
  'Service Request Closed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%'
UNION ALL
-- 13. Service Request Canceled
SELECT
  sr.ServiceRequestId,
  'Service Request Canceled' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Cancelled' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Cancelled%'
UNION ALL
-- 14. Request Rejected
SELECT
  sr.ServiceRequestId,
  'Request Rejected' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Rejected' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Rejected%';

Passaggi

Prerequisiti: si assicuri di avere Python 3.6 o una versione successiva installata sul sistema. Installi la libreria requests, necessaria per effettuare chiamate API HTTP, eseguendo pip install requests nel terminale o nel prompt dei comandi.
Ottenga le credenziali API: crei o richieda le credenziali per un account di servizio dedicato in BMC Helix ITSM. Questo account deve disporre almeno di autorizzazioni di sola lettura per il modulo SRM:Request e per il modulo dell'audit log corrispondente, spesso denominato SRM:Request_AuditLog o in modo simile. Annoti il nome utente, la password e l'URL di base della Sua istanza BMC Helix, ad esempio https://[your-company].bmc.com.
Configuri lo script Python: copi lo script Python fornito in un file, ad esempio extract_servicerequests.py. Modifichi lo script e valorizzi le variabili segnaposto iniziali: BASE_URL, USERNAME, PASSWORD e AUDIT_FORM_NAME. Adatti il dizionario STATUS_ACTIVITY_MAP ai valori di stato specifici utilizzati nel Workflow delle richieste di servizio della Sua organizzazione.
Imposti il periodo di estrazione: modifichi le variabili START_DATE e END_DATE nello script. Queste definiscono l'intervallo temporale dell'estrazione in base alla data di invio della richiesta di servizio. Per il test iniziale, utilizzi un intervallo breve, ad esempio un solo giorno.
Esegua lo script: esegua lo script dal terminale utilizzando il comando python extract_servicerequests.py. Lo script eseguirà innanzitutto l'autenticazione tramite API per ottenere un token.
Recuperi inizialmente i dati: lo script interroga il modulo SRM:Request per recuperare l'elenco di tutte le richieste di servizio create nell'intervallo di date specificato. Questo passaggio raccoglie l'ID del caso e gli attributi statici associati, come priorità e tipo di servizio.
Recuperi la cronologia degli eventi: lo script scorre ogni ID di richiesta di servizio ottenuto nel passaggio precedente. Per ciascun ID effettua una seconda chiamata API al modulo dell'audit log configurato, per recuperare la cronologia dettagliata delle modifiche di stato di quella specifica richiesta.
Trasformi i dati in un event log: per ogni record dell'audit log, lo script associa la modifica di stato a un nome di attività standard utilizzando STATUS_ACTIVITY_MAP. Crea una riga per ogni attività mappata, includendo il Service Request ID, l'Activity Name e il timestamp della modifica.
Generi l'evento di invio: lo script crea inoltre l'attività iniziale «Service Request Submitted» per ogni richiesta, utilizzando Submit Date dal modulo principale SRM:Request.
Esporti in CSV: dopo aver elaborato tutte le richieste di servizio e le relative cronologie, lo script consolida le righe generate in un unico elenco e scrive i dati in un file CSV denominato servicerequest_event_log.csv. Il file è formattato e pronto per essere caricato in uno strumento di Process Mining.

Configurazione

Endpoint API: lo script utilizza principalmente due endpoint API. L'autenticazione viene gestita tramite api/jwt/login. I dati vengono interrogati da arsys/v1/entry/SRM:Request per l'elenco dei casi e da arsys/v1/entry/[AUDIT_FORM_NAME] per la cronologia degli eventi.
Autorizzazioni dell'account di servizio: è necessario un account di servizio dedicato con accesso in lettura al modulo SRM:Request e al modulo dell'audit log di sistema. L'utilizzo di un account di servizio è fondamentale per la sicurezza e la tracciabilità.
Filtro per intervallo di date: lo script è configurato per filtrare le richieste di servizio in base a Submit Date. Si consiglia di estrarre i dati in blocchi gestibili, ad esempio da 3 a 6 mesi alla volta, per garantire prestazioni affidabili.
Mappatura da stato ad attività: il dizionario STATUS_ACTIVITY_MAP nello script costituisce il nucleo della logica di trasformazione. Deve essere configurato con attenzione per riflettere gli stati personalizzati della Sua organizzazione e associarli ai nomi delle attività desiderati. Gli stati del Workflow non presenti nella mappa verranno ignorati.
Modulo dell'audit log: la capacità dello script di acquisire attività dettagliate dipende interamente dalla disponibilità di un audit log interrogabile. Deve individuare il nome corretto del modulo nel Suo ambiente, quello che memorizza la cronologia delle modifiche di stato delle richieste di servizio, e aggiornare di conseguenza la variabile AUDIT_FORM_NAME.
Paginazione: lo script gestisce automaticamente la paginazione API per recuperare tutti i record. Il parametro limit nella chiamata API è impostato per recuperare 1.000 record per richiesta, bilanciando prestazioni e utilizzo della memoria.

a Query di esempio python

import requests
import json
import csv
import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your BMC Helix environment details
BASE_URL = class="hl-string">"https://[your-company].bmc.com"
USERNAME = class="hl-string">"[your-service-account-username]"
PASSWORD = class="hl-string">"[your-service-account-password]"
class=class="hl-string">"hl-comment"># This is a placeholder; you must identify the correct audit form for SRM:Request in your system
AUDIT_FORM_NAME = class="hl-string">"SRM:Request_AuditLog"

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-03-31"

class=class="hl-string">"hl-comment"># --- Status to Activity Mapping --- #
class=class="hl-string">"hl-comment"># CRITICAL: Customize this map to match your system's status values
STATUS_ACTIVITY_MAP = {
    class="hl-string">"In Review": class="hl-string">"Request In Review",
    class="hl-string">"Waiting for Approval": class="hl-string">"Request Waiting for Approval",
    class="hl-string">"Approved": class="hl-string">"Request Approved",
    class="hl-string">"Assigned": class="hl-string">"Request Assigned",
    class="hl-string">"In Progress": class="hl-string">"Fulfillment In Progress",
    class="hl-string">"Pending": class="hl-string">"Information Requested from User", class=class="hl-string">"hl-comment"># This is a simplification; may need refinement
    class="hl-string">"Completed": class="hl-string">"Service Request Resolved",
    class="hl-string">"Closed": class="hl-string">"Service Request Closed",
    class="hl-string">"Cancelled": class="hl-string">"Service Request Canceled",
    class="hl-string">"Rejected": class="hl-string">"Request Rejected"
    class=class="hl-string">"hl-comment"># Add other custom statuses as needed
}

class=class="hl-string">"hl-comment"># Map specific status transitions for more granular activities
TRANSITION_ACTIVITY_MAP = {
    (class="hl-string">'Pending', class="hl-string">'In Progress'): class="hl-string">'Request Resumed'
    class=class="hl-string">"hl-comment"># You can add other specific transitions here
}

def get_jwt_token(base_url, username, password):
    class="hl-string">"""Authenticates with the REST API and returns a JWT token."""
    url = fclass="hl-string">"{base_url}/api/jwt/login"
    payload = {
        class="hl-string">'username': username,
        class="hl-string">'password': password
    }
    headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
    try:
        response = requests.post(url, data=payload, headers=headers)
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting JWT token: {e}")
        return None

def get_paginated_results(base_url, token, form_name, query, fields):
    class="hl-string">"""Retrieves all entries from a form, handling pagination."""
    all_entries = []
    url = fclass="hl-string">"{base_url}/api/arsys/v1/entry/{form_name}"
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    params = {
        class="hl-string">'q': query,
        class="hl-string">'fields': fclass="hl-string">'values({fields})',
        class="hl-string">'limit': 1000
    }
    while True:
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_entries.extend(data[class="hl-string">'entries'])
            class=class="hl-string">"hl-comment"># Check for next page link
            if class="hl-string">'next' in data[class="hl-string">'_links']:
                url = data[class="hl-string">'_links'][class="hl-string">'next'][class="hl-string">'href']
                params = {}
            else:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {form_name}: {e}")
            break
    return all_entries

def main():
    class="hl-string">"""Main function to orchestrate the data extraction."""
    print(class="hl-string">"Starting extraction...")
    token = get_jwt_token(BASE_URL, USERNAME, PASSWORD)
    if not token:
        return

    class=class="hl-string">"hl-comment"># 1. Get all Service Requests within the date range
    print(fclass="hl-string">"Fetching service requests from {START_DATE} to {END_DATE}...")
    srm_query = fclass="hl-string">"'Submit Date' >= \"{START_DATE}T00:00:00Z\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}T23:59:59Z\class="hl-string">""
    srm_fields = class="hl-string">"Request Number,Submit Date,Priority,Assignee,Assigned Group,Title"
    srm_requests = get_paginated_results(BASE_URL, token, class="hl-string">"SRM:Request", srm_query, srm_fields)
    print(fclass="hl-string">"Found {len(srm_requests)} service requests.")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">"Z"

    class=class="hl-string">"hl-comment"># 2. For each request, get its audit history
    for i, req in enumerate(srm_requests):
        req_values = req[class="hl-string">'values']
        request_id = req_values.get(class="hl-string">'Request Number')
        if not request_id:
            continue

        print(fclass="hl-string">"Processing request {i+1}/{len(srm_requests)}: {request_id}")

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Service Request Submitted' event
        event_log.append({
            class="hl-string">'ServiceRequestId': request_id,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Submitted',
            class="hl-string">'EventStartTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'EventEndTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'RequestStatus': class="hl-string">'Submitted',
            class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
            class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
            class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'),
            class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'),
            class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
            class="hl-string">'LastDataUpdate': current_time
        })

        class=class="hl-string">"hl-comment"># 3. Fetch audit log for status changes
        audit_query = fclass="hl-string">"'Original Request ID' = \"{request_id}\class="hl-string">" AND 'Fields Changed' LIKE \"%Status%\class="hl-string">""
        audit_fields = class="hl-string">"New Value,Old Value,Log Key 1,Create Date"
        audit_entries = get_paginated_results(BASE_URL, token, AUDIT_FORM_NAME, audit_query, audit_fields)
        
        class=class="hl-string">"hl-comment"># Sort audit entries by date to ensure correct order
        audit_entries.sort(key=lambda x: x[class="hl-string">'values'][class="hl-string">'Create Date'])

        for audit_entry in audit_entries:
            audit_values = audit_entry[class="hl-string">'values']
            class=class="hl-string">"hl-comment"># Ensure we are only processing status changes
            if class="hl-string">'Status' not in audit_values.get(class="hl-string">'Log Key 1', class="hl-string">''):
                continue

            new_status = audit_values.get(class="hl-string">'New Value')
            old_status = audit_values.get(class="hl-string">'Old Value')
            timestamp = audit_values.get(class="hl-string">'Create Date')
            activity_name = None

            class=class="hl-string">"hl-comment"># Check for specific transitions first
            if (old_status, new_status) in TRANSITION_ACTIVITY_MAP:
                activity_name = TRANSITION_ACTIVITY_MAP.get((old_status, new_status))
            class=class="hl-string">"hl-comment"># Then check for general status mappings
            elif new_status in STATUS_ACTIVITY_MAP:
                activity_name = STATUS_ACTIVITY_MAP.get(new_status)

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestId': request_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventStartTime': timestamp,
                    class="hl-string">'EventEndTime': timestamp,
                    class="hl-string">'RequestStatus': new_status,
                    class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
                    class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
                    class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'), class=class="hl-string">"hl-comment"># Note: Assignee is static from the main request
                    class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'), class=class="hl-string">"hl-comment"># Note: Team is static from the main request
                    class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
                    class="hl-string">'LastDataUpdate': current_time
                })
    
    class=class="hl-string">"hl-comment"># 4. Write to CSV
    output_file = class="hl-string">'servicerequest_event_log.csv'
    print(fclass="hl-string">"Writing event log to {output_file}...")
    if event_log:
        with open(output_file, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=event_log[0].keys())
            writer.writeheader()
            writer.writerows(event_log)
        print(class="hl-string">"Extraction complete.")
    else:
        print(class="hl-string">"No events to write.")

if __name__ == class="hl-string">"__main__":
    main()

È pronto per iniziare?

Utilizzi questo Template per semplificare la raccolta dei dati e avviare con sicurezza il Suo percorso di Process Mining. Inizi oggi stesso a ottimizzare la gestione delle richieste di servizio.

Torna alla guida al miglioramento Scarica il Template

Sblocchi l'efficienza: ottimizzi oggi la gestione delle richieste di servizio

Raggiunga il 70% di automazione, elimini i rallentamenti nell'evasione e offra un'esperienza eccellente agli utenti.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito: inizi in pochi minuti.

Il Suo Template dati per la gestione delle richieste di servizio

Il Suo Template dati per la gestione delle richieste di servizio

Attributi della gestione delle richieste di servizio

Attività di gestione delle richieste di servizio

Guide all'estrazione

Smart Reporting di BMC Helix ITSM per le richieste di servizio

Passaggi

Configurazione

a Query di esempio sql

Query SQL diretta sulle tabelle del database AR System

Passaggi

Configurazione

a Query di esempio sql

Estrazione tramite script Python con l'API REST di BMC Helix

Passaggi

Configurazione

a Query di esempio python

È pronto per iniziare?

Sblocchi l'efficienza: ottimizzi oggi la gestione delle richieste di servizio

Il Suo Template dati per la gestione delle richieste di servizio

Il Suo Template dati per la gestione delle richieste di servizio

Attributi della gestione delle richieste di servizio

Attività di gestione delle richieste di servizio

Guide all'estrazione

Smart Reporting di BMC Helix ITSM per le richieste di servizio

Passaggi

Configurazione

a Query di esempio sql

Query SQL diretta sulle tabelle del database AR System

Passaggi

Configurazione

a Query di esempio sql

Estrazione tramite script Python con l'API REST di BMC Helix

Passaggi

Configurazione

a Query di esempio python

È pronto per iniziare?

Sblocchi l'efficienza: ottimizzi oggi la gestione delle richieste di servizio

La Sua privacy è importante