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

Il Suo template dei 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 dei dati per la gestione delle richieste di servizio

Questo template offre una panoramica chiara degli attributi essenziali da raccogliere e delle attività principali da monitorare nel processo di gestione delle richieste di servizio. Include inoltre indicazioni pratiche per estrarre i dati da BMC Helix ITSM in modo efficiente. 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 dei dati 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 analizzare in modo approfondito il 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 un passaggio specifico o una modifica di 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 completo della richiesta. L’analisi della sequenza e della frequenza delle attività è alla base del Process Mining. Consente di ricostruire le mappe di processo, individuare i colli di bottiglia e analizzare le varianti di processo. Capire quali attività si verificano, in quale ordine e con quale frequenza è essenziale per ottimizzare i processi. Perché è importante Le attività costituiscono gli elementi fondamentali della mappa di processo. Tracciarle consente di visualizzare e analizzare il flusso del processo e di capire come viene svolto il lavoro. Dove reperirli In genere, si ricava dalle modifiche dei campi 'Status' e 'Status Reason' nel modulo 'SRM:Request' o nei registri delle applicazioni correlate all’evasione, ad esempio Incident o Work Order. Esempi Richiesta in attesa di approvazioneEvasione in corsoRichiesta di servizio risoltaRichiesta di servizio chiusa
	ID della richiesta di servizio ServiceRequestId	Identificativo univoco di ogni richiesta di servizio, utilizzato come 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 da un sistema. È il riferimento centrale che collega tutti gli eventi successivi, dalla registrazione iniziale alla chiusura definitiva, e consente di analizzare l’intero percorso di ogni richiesta. Nel Process Mining, questo ID è essenziale per ricostruire la sequenza delle attività di ciascun 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, che costituisce la base di ogni analisi. Perché è importante È l’identificativo fondamentale del caso. Senza di esso, non è possibile ricostruire il percorso completo della richiesta di servizio, né individuare e analizzare il processo. Dove reperirli In genere, corrisponde al campo 'InstanceId' o 'Request Number' nel modulo 'SRM:Request' di BMC Helix ITSM. Esempi SR000010572931SR000010572932SR000010572933
	Ora di inizio EventStartTime	La marca temporale che indica quando è iniziata una specifica attività o un determinato evento.
Descrizione Questo attributo registra la data e l’ora esatte di inizio di un’attività. Ogni evento nel registro, dall’invio iniziale alla chiusura definitiva, deve avere un’ora di inizio per stabilire la sequenza cronologica del processo. Questa marca temporale è fondamentale per tutte le analisi di Process Mining basate sul tempo. Serve a calcolare i tempi di ciclo, la durata delle attività e i tempi di attesa tra i passaggi, nonché a verificare il rispetto degli SLA. Consente di individuare i colli di bottiglia e analizzare nel tempo le prestazioni del processo. 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 reperirli Corrisponde ai campi delle marche temporali nei registri di controllo 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 da cui sono stati estratti i dati.
Descrizione Questo attributo specifica l’origine dei dati di processo. In questa vista, il valore sarebbe impostato in modo statico 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 alla fonte. Garantisce chiarezza e tracciabilità, soprattutto quando si uniscono dati provenienti da piattaforme diverse. Perché è importante Fornisce informazioni sull’origine dei dati, importanti per la governance dei dati, la tracciabilità e la risoluzione dei problemi negli ambienti con più sistemi. Dove reperirli È un valore statico aggiunto durante l’estrazione e la trasformazione dei dati, non un campo presente in BMC Helix ITSM. Esempi BMC Helix ITSM
	Ultimo aggiornamento dei dati LastDataUpdate	La marca temporale dell’ultimo aggiornamento dei dati del processo dal sistema di origine.
Descrizione Questo attributo indica la data e l’ora dell’estrazione più recente dei dati da BMC Helix ITSM. Aiuta a capire quanto sono aggiornati i dati analizzati e quale periodo copre l’analisi. È un metadato fondamentale per qualsiasi Dashboard o analisi di Process Mining. Consente di capire se le informazioni si basano su dati quasi in tempo reale o su una fotografia storica, un aspetto che incide sulla validità e sulla pertinenza delle conclusioni. Perché è importante Indica quanto sono aggiornati i dati, un’informazione essenziale per prendere decisioni basate sulle informazioni più recenti disponibili sulle prestazioni del processo. Dove reperirli Questa marca temporale viene generata e aggiunta durante l’estrazione e il caricamento dei dati. Esempi 2024-05-21T08:00:00Z
	Agente assegnato AssignedAgent	L’utente attualmente incaricato di gestire la richiesta di servizio.
Descrizione Questo attributo identifica l’agente IT o il membro del personale di supporto 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. Questo attributo è fondamentale per analizzare le prestazioni degli agenti e la distribuzione del carico di lavoro. 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 di opportunità di formazione. Perché è importante Monitorare l’agente assegnato è essenziale per analizzare i passaggi di consegne, misurare le prestazioni individuali e comprendere come si distribuisce il carico di lavoro nel team di supporto. Dove reperirli Corrisponde al campo «Assignee» o «Assigned To» nel record di evasione, ad esempio Work Order o Incident, associato alla richiesta di servizio. Esempi Bob SmithAlice JohnsonCharlie Brown
	Ora di fine EventEndTime	La marca temporale che indica quando è stata completata una specifica attività o un determinato evento.
Descrizione L’ora di fine segna la conclusione di un’attività. Nei sistemi ITSM molte attività corrispondono a modifiche di stato istantanee, ma alcune hanno una durata misurabile. L’ora di fine consente di calcolare con precisione la durata di queste attività. Nell’analisi, l’ora di fine viene utilizzata insieme all’ora di inizio per calcolare il tempo di elaborazione delle singole attività. Aiuta a individuare quali attività specifiche, e non solo i tempi di attesa tra una e l’altra, assorbono più tempo nel processo. Perché è importante Consente di calcolare i tempi di elaborazione delle attività, un dato fondamentale per individuare i passaggi inefficienti e capire come viene impiegato il tempo delle risorse. Dove reperirli Può essere ricavata dai dati. Spesso, l’ora di fine di un’attività coincide con l’ora di inizio dell’attività successiva dello stesso caso. Per l’attività finale, corrisponde alla marca temporale della risoluzione o della 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 sull’attività aziendale e l’urgenza.
Descrizione La priorità determina l’ordine e la rapidità con cui devono essere gestite le richieste. I valori più comuni sono 'Critico', 'Alto', 'Medio' e 'Basso'. L’assegnazione si basa spesso sulla combinazione dell’impatto della richiesta sull’attività aziendale e della sua 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 nelle Dashboard sui tempi di risoluzione e sul rispetto degli SLA e aiuta a verificare 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 previsti per le richieste con diversi livelli di impatto sull’attività aziendale. Dove reperirli È il campo 'Priority' del modulo 'SRM:Request'. Esempi CriticoAltoMedioBasso
	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. Fornisce il contesto di ogni attività ed è spesso la fonte da cui si ricava l’attributo 'Attività'. L’analisi per stato aiuta a capire quanto tempo le richieste trascorrono in determinate condizioni, 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 per l’individuazione dei colli di bottiglia. Perché è importante Fornisce un quadro dello stato della richiesta e consente di confrontare il tempo trascorso in attesa con quello dedicato alle attività, un dato fondamentale per individuare i colli di bottiglia. Dove reperirli È il campo 'Status' del modulo 'SRM:Request'. I valori storici sono disponibili nel registro di controllo. Esempi PianificazioneIn corsoIn attesaRisoltoChiuso
	Team assegnato AssignedTeam	Il gruppo o il team di supporto a cui è attualmente assegnata la richiesta di servizio.
Descrizione Questo attributo identifica il gruppo funzionale responsabile della gestione della richiesta, ad esempio «Help Desk», «Team di rete» o «Amministrazione database». Una modifica a questo campo indica il trasferimento della responsabilità da un team a un altro. L’analisi per 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, perché mostra come il lavoro viene instradato all’interno dell’organizzazione. Perché è importante Consente di analizzare il flusso del processo tra i diversi gruppi funzionali, aiutando a individuare inefficienze nell’instradamento e a misurare le prestazioni dei team. Dove reperirli Corrisponde al campo «Assigned Group» nel record di evasione, ad esempio Work Order o Incident, associato alla richiesta di servizio. Esempi Service DeskSupporto infrastrutturaSupporto applicazioni 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 'Richiesta di nuovo software', 'Reimpostazione della password' o 'Inserimento di un nuovo dipendente'. È una dimensione fondamentale per filtrare e segmentare i dati di processo. Nell’analisi dei processi, questo attributo serve a 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 comportano più rilavorazioni?'. È fondamentale per le Dashboard sui tempi di risoluzione e sul rispetto degli SLA. Perché è importante Consente di segmentare le richieste di servizio per confrontare i flussi di processo, individuare problemi specifici per ciascun tipo e definire interventi di ottimizzazione mirati. Dove reperirli Questi dati si trovano spesso nel campo 'Title' o in un campo di classificazione 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 utilizzato per inviare la richiesta di servizio.
Descrizione Questo attributo registra come è stata avviata la richiesta di servizio, ad esempio tramite un portale self-service, un’e-mail, una telefonata al Service Desk o un avviso automatico del sistema. Canali diversi possono determinare varianti del processo e tempi di risoluzione differenti. Analizzare il processo in base al canale di invio può rivelare inefficienze o buone pratiche legate a specifiche modalità di ricezione. Per esempio, le richieste inviate tramite il portale self-service possono essere risolte più rapidamente grazie alla maggiore qualità iniziale dei dati, mentre quelle ricevute via e-mail possono richiedere più attività manuali di classificazione. Perché è importante Aiuta a comprendere in che modo il metodo di ricezione influisce sull’efficienza del processo, sulla qualità dei dati e sul tempo di ciclo complessivo, consentendo di intervenire in modo mirato sui singoli canali. Dove reperirli Spesso è possibile dedurlo da campi come «Client Type» o «Reported Source» nel modulo «SRM:Request» o nei ticket di evasione associati. Esempi Portale self-serviceE-mailTelefonoGenerato dal sistema
	Categoria di risoluzione ResolutionCategory	La classificazione della soluzione fornita per risolvere la richiesta.
Descrizione Questo attributo classifica in modo strutturato le modalità di risoluzione di una richiesta, ad esempio «Correzione software», «Formazione dell’utente» o «Correzione dei dati». Descrive la natura della risoluzione in modo più dettagliato rispetto a un semplice codice di chiusura. È essenziale per la Dashboard Resolution Category Accuracy, che consente di confrontare la categoria di risoluzione con il tipo di servizio iniziale e verificarne la coerenza. L’analisi delle categorie di risoluzione aiuta a individuare tendenze nei problemi e a gestirli in modo proattivo, per esempio quando molte richieste vengono risolte formando gli utenti. Perché è importante Offre informazioni sulla natura delle soluzioni e aiuta a individuare tendenze nei problemi ricorrenti e opportunità per gestire i problemi in modo proattivo o formare gli utenti. Dove reperirli Queste informazioni fanno parte dei campi di classificazione operativa e del prodotto nel ticket di evasione, spesso denominati «Resolution Category». Esempi Amministrazione degli 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 codice di chiusura offre un metodo standardizzato per classificare la risoluzione di una richiesta di servizio. Alcuni esempi sono «Risolto dal Service Desk», «Annullato dall’utente» o «Richiesta duplicata». L’analisi dei codici di chiusura aiuta a comprendere gli esiti più comuni delle richieste. Può mettere in evidenza problemi come un numero elevato di richieste annullate dagli utenti, che potrebbe indicare un processo troppo lungo, o molte 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 e consente di analizzare l’efficacia delle risoluzioni e i motivi del mancato completamento o dell’annullamento. Dove reperirli Queste informazioni si trovano solitamente nel 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, in base al Service Level Agreement (SLA), è prevista la risoluzione della richiesta di servizio.
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 servizio, che spesso tengono conto di fattori quali la priorità e il tipo di richiesta. Questo attributo è fondamentale per la Dashboard SLA Compliance Overview e costituisce il valore di riferimento per misurare il tempo effettivo di risoluzione. Confrontando l’«EventEndTime» dell’attività finale di risoluzione con la data obiettivo, è possibile stabilire se l’impegno di servizio è stato rispettato. Perché è importante È il principale valore di riferimento per misurare le prestazioni del servizio rispetto agli impegni assunti ed è quindi essenziale per monitorare e rendicontare la conformità agli SLA. Dove reperirli Questa data viene calcolata e memorizzata dal modulo Service Level Management (SLM) ed è disponibile nei moduli SLM correlati alla richiesta di servizio. Esempi 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
	È stata inoltrata a un livello superiore IsEscalated	Un indicatore booleano che specifica se la richiesta di servizio è stata inoltrata a un livello superiore.
Descrizione Questo indicatore assume il valore true se la richiesta di servizio è stata oggetto di un’escalation funzionale o gerarchica. In genere, l’escalation avviene quando la richiesta non procede come previsto, rischia di non rispettare uno SLA o richiede l’intervento o l’approvazione di un’autorità superiore. Questo attributo è fondamentale per la Dashboard Request Escalation Efficiency Analysis. Consente di filtrare e analizzare i percorsi delle richieste inoltrate a un livello superiore, per capire che cosa le ha innescate, quanto tempo occorre per risolverle dopo l’escalation e quanto è efficace il processo. Perché è importante Consente di isolare e analizzare le richieste che hanno richiesto un’escalation, aiutando a individuare i punti deboli del processo standard o i fattori che innescano i casi complessi. Dove reperirli In genere non corrisponde a un singolo campo. Si ricava cercando attività specifiche legate all’escalation nel registro di controllo oppure modifiche alla priorità o all’assegnazione conformi a un protocollo di escalation. Esempi truefalse
	È stato necessario rifare il lavoro IsRework	Un indicatore booleano che specifica se la richiesta di servizio ha richiesto una rilavorazione, ad esempio tornando a una fase precedente.
Descrizione Questo indicatore identifica le richieste di servizio che hanno seguito un ciclo o richiesto una rilavorazione nel flusso del processo. Per esempio, una richiesta che passa da «Evasione in corso» a «Revisione della richiesta» viene considerata una rilavorazione. 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 rilavorazioni e di analizzarne le cause più comuni, come una valutazione iniziale errata o informazioni incomplete, che generano inefficienze nel processo. Perché è importante Quantifica le inefficienze del processo segnalando i casi che si discostano dal percorso ottimale e aiuta a individuare le cause profonde dei cicli e delle attività ripetute. Dove reperirli È un attributo calcolato a partire dalla sequenza di attività nell’event log. Occorre definire una logica che rilevi i passaggi a ritroso nel flusso del processo. Esempi truefalse
	Numero di passaggi di consegne HandoffCount	Il numero totale di volte in cui una richiesta di servizio è stata riassegnata tra agenti o team diversi.
Descrizione Questa metrica calcolata conta quante volte cambiano i valori di «AssignedAgent» o «AssignedTeam» per una singola richiesta di servizio. Un numero elevato di passaggi di consegne può indicare una frammentazione del processo, una bassa percentuale di risoluzione al primo contatto o un instradamento inefficiente. Questo attributo è alla base del KPI Average Agent Handoffs per Request ed è utilizzato nella Dashboard Request Rework and Reassignment. Analizzare i casi con molti passaggi di consegne può rivelare opportunità per migliorare la classificazione iniziale, offrire una formazione più adeguata o semplificare il processo di risoluzione, riducendo i ritardi e migliorando la soddisfazione dei clienti. Perché è importante Misura la frammentazione del processo e il carico di comunicazione. Un numero elevato di passaggi di consegne è spesso associato a tempi di risoluzione più lunghi e a una minore efficienza del processo. Dove reperirli È una metrica calcolata contando i valori distinti dell’attributo «AssignedAgent» o «AssignedTeam» per ogni ID univoco della richiesta di servizio. 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, ad esempio «Finanza», «Risorse umane» o «IT». In genere, queste informazioni provengono dal profilo dell’utente nel sistema. Segmentare l’analisi del processo per reparto consente di individuare esigenze e modelli di richiesta specifici, nonché possibili ambiti in cui concentrare la formazione o migliorare il servizio. Può aiutare a rispondere a domande come: «Il reparto Finanza deve attendere più a lungo per le proprie richieste?». Perché è importante Consente di analizzare il consumo dei servizi e le prestazioni del processo per unità aziendale, mettendo in evidenza eventuali problemi o tendenze specifici di un reparto. Dove reperirli Queste informazioni si recuperano solitamente dal profilo dell’utente associato all’utente «Requested For» nel modulo «SRM:Request». Esempi FinanzaVenditeRisorse umaneTecnologie dell’informazione
	SLA non rispettato IsSlaBreached	Un indicatore booleano che specifica se la richiesta di servizio è stata risolta dopo la data obiettivo SLA.
Descrizione Questo indicatore calcolato assume il valore true se il timestamp della risoluzione finale della richiesta di servizio è successivo alla relativa «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 calcolare facilmente i tassi complessivi di conformità e di filtrare le richieste per confrontare le caratteristiche del processo nei casi in cui lo SLA non è stato rispettato con quelle dei casi conformi, aiutando a individuare le cause profonde dei mancati SLA. Perché è importante Semplifica l’analisi delle prestazioni SLA trasformando il confronto tra timestamp in un semplice indicatore booleano, così da misurare e visualizzare facilmente i tassi di conformità. Dove reperirli È 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

Per individuare e visualizzare correttamente il processo, è importante registrare nell’Event Log questi passaggi e traguardi fondamentali.

6 Consigliato 8 Facoltativo

	Attività	Descrizione
	Evasione in corso	L’agente o il team assegnato ha iniziato a lavorare attivamente per soddisfare la richiesta di servizio. La richiesta è passata dalla coda a una fase di lavoro attivo.
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 reperirli Si deduce da una modifica dello stato nel modulo SRM:Request a 'In Progress'. Acquisizione Marca temporale 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, responsabile del completamento del lavoro. Questo passaggio segna la fine della fase di triage.
Perché è importante Questa tappa è fondamentale per misurare il tempo di triage e analizzare il carico di lavoro degli agenti. Le riassegnazioni frequenti possono indicare problemi di instradamento o carenze di competenze. Dove reperirli L’evento può essere acquisito direttamente dal registro di controllo dei campi 'Assigned Group' o 'Assignee' nel modulo SRM:Request o nei moduli applicativi correlati all’evasione, ad esempio WOI:WorkOrder. Acquisizione Marca temporale del registro di controllo che indica la prima assegnazione di un valore non nullo al campo 'Assignee'. Tipo di evento explicit
	Richiesta di servizio annullata	La richiesta di servizio è stata ritirata da chi l’ha inviata o dal service desk prima del completamento dell’evasione. È uno stato terminale della richiesta.
Perché è importante Monitorare gli annullamenti aiuta a individuare schemi ricorrenti, ad esempio richieste inviate con dati errati o servizi non più necessari, e a migliorare il catalogo dei servizi. Dove reperirli Si deduce da una modifica dello stato nel modulo SRM:Request a 'Canceled'. Acquisizione Marca temporale 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 passa a uno stato archiviato, di sola lettura. Ciò avviene dopo la risoluzione e una volta trascorso l’eventuale periodo di conferma.
Perché è importante Questa attività rappresenta la fine definitiva del processo. Il tempo che intercorre tra 'Resolved' e 'Closed' può mettere in luce inefficienze nella procedura di chiusura. Dove reperirli Si deduce dalla modifica finale dello stato nel modulo SRM:Request a 'Closed'. Acquisizione Marca temporale 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à segna la creazione e l’invio di una nuova richiesta di servizio da parte di un utente. Viene registrata quando si crea una nuova voce nel modulo SRM:Request con uno stato iniziale, in genere '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 reperirli L’evento si deduce dalla marca temporale di creazione e dallo stato iniziale, ad esempio 'Submitted', di un record nel modulo SRM:Request. Acquisizione Individui la marca temporale di creazione di un nuovo ID della richiesta di servizio 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 a chi l’ha inviata. La richiesta attende la conferma finale oppure si chiuderà automaticamente dopo un periodo prestabilito.
Perché è importante Una tappa fondamentale che segna la fine del ciclo di erogazione del servizio. È il principale punto di arrivo per misurare i tempi di risoluzione e il rispetto degli SLA. Dove reperirli Si deduce da una modifica dello stato nel modulo SRM:Request a 'Resolved' o 'Completed'. Acquisizione Marca temporale 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	Per procedere con il lavoro, l’agente incaricato dell’evasione ha bisogno di ulteriori informazioni da chi ha inviato la richiesta. In genere, la richiesta passa allo stato 'Pending'.
Perché è importante Questa attività è essenziale per calcolare il 'Tempo di attesa per informazioni esterne' e individuare la frequenza con cui le richieste si bloccano a causa di informazioni incomplete. Dove reperirli Si deduce da una modifica dello stato nel modulo SRM:Request a 'Pending', con una motivazione come 'Customer Hold' o 'Awaiting Information'. Acquisizione Marca temporale della modifica dello stato a 'Pending', associata a una motivazione specifica. Tipo di evento inferred
	Richiesta approvata	La richiesta di servizio è stata approvata formalmente dalla persona o dal gruppo competente e il processo di evasione può proseguire. In genere, questo evento segue lo stato 'Waiting for Approval'.
Perché è importante Segna la fine del sottoprocesso di approvazione ed è una tappa fondamentale per misurare i tempi delle approvazioni e il loro impatto sul tempo complessivo di risoluzione. Dove reperirli Si deduce 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 moduli di approvazione correlati. Acquisizione Marca temporale della modifica di stato da 'Waiting Approval' a uno stato successivo, dopo una decisione di approvazione positiva. Tipo di evento inferred
	Richiesta in attesa di approvazione	La richiesta di servizio è stata inviata a un approvatore designato o a un gruppo di approvazione e attende una decisione prima che possa iniziare l’evasione. È un passaggio comune per le richieste che comportano costi o diritti di accesso.
Perché è importante Questa attività isola i ritardi legati all’approvazione e consente di analizzare i tempi del ciclo di approvazione e individuare i colli di bottiglia nella catena di approvazione. Dove reperirli Si deduce da una modifica dello stato nel modulo SRM:Request a un valore come 'Waiting Approval'. Acquisizione Marca temporale dell’evento di aggiornamento in cui il campo 'Status' di SRM:Request passa a 'Waiting Approval'. Tipo di evento inferred
	Richiesta in revisione	Il service desk sta svolgendo la revisione iniziale e il triage della richiesta di servizio per determinarne la natura e la priorità, nonché il team incaricato di soddisfarla. In genere, questa fase è rappresentata da una modifica dello stato nel record della richiesta.
Perché è importante Monitorare questa attività aiuta a misurare l’efficienza del triage e a individuare i ritardi tra l’invio e l’assegnazione, un dato essenziale per il KPI 'Tempo medio di triage'. Dove reperirli Si deduce da una modifica dello stato nel modulo SRM:Request a un valore come 'In Review' o 'Planning'. Acquisizione Marca temporale dell’evento di aggiornamento in cui il campo 'Status' di SRM:Request passa a 'In Review'. Tipo di evento inferred
	Richiesta respinta	La richiesta di servizio è stata respinta durante la fase di approvazione. È uno stato terminale che interrompe il processo prima dell’inizio dell’evasione.
Perché è importante Analizzare le richieste respinte può mettere in luce problemi nelle motivazioni delle richieste, nei criteri di ammissibilità o nelle politiche di approvazione. Dove reperirli Si deduce da una modifica dello stato nel modulo SRM:Request a 'Rejected'. Acquisizione Marca temporale 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 è uscita dallo stato di attesa, in genere dopo che l’utente ha fornito le informazioni necessarie. L’agente incaricato dell’evasione riprende il lavoro sulla richiesta.
Perché è importante Segna la fine di un periodo di attesa e consente di misurare con precisione i tempi di attesa per informazioni esterne e il loro impatto sul rispetto degli SLA. Dove reperirli Si deduce quando lo stato di SRM:Request passa da 'Pending' a 'In Progress'. Acquisizione Marca temporale 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	Chi ha inviato la richiesta ha confermato esplicitamente che il servizio è stato erogato in modo soddisfacente e che la richiesta è risolta. Spesso, questa conferma avvia la chiusura definitiva della richiesta.
Perché è importante Fornisce un indicatore chiaro della soddisfazione del cliente e conclude formalmente l’interazione relativa al servizio. Distingue la risoluzione del processo dall’accettazione da parte del cliente. Dove reperirli L’evento può essere registrato nei registri di lavoro o nelle note sulle attività di SRM:Request quando l’utente conferma tramite il portale o via e-mail. Non sempre corrisponde a uno stato distinto. Acquisizione Esamini i registri di lavoro (SRM:WorkInfo) per individuare le voci che indicano la conferma dell’utente o il completamento di un sondaggio. Tipo di evento explicit
	Soluzione implementata	L’agente ha completato il lavoro tecnico necessario per soddisfare la richiesta di servizio. La richiesta è pronta per essere confermata dall’utente prima della risoluzione formale.
Perché è importante Questa attività distingue il completamento del lavoro tecnico dalla risoluzione formale e aiuta a individuare eventuali ritardi tra la fine del lavoro e la conferma dell’utente. Dove reperirli L’evento può essere dedotto da una modifica dello stato di un ticket di evasione nel sistema di back-end, ad esempio quando lo stato di un ordine di lavoro passa a 'Completed', prima che la richiesta SRM:Request principale venga contrassegnata come 'Resolved'. Acquisizione Marca temporale in cui un ticket di back-end, come un ordine di lavoro o un incidente, collegato a SRM:Request viene contrassegnato come completato. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da BMC Helix ITSM

Passaggi

Acceda a Smart Reporting: acceda al Suo ambiente BMC Helix ITSM. Apra la sezione dedicata ai report e avvii Smart Reporting. A seconda della versione, la funzione potrebbe chiamarsi 'Report' o 'Smart Reporting'.
Crei un nuovo report: nell’interfaccia di Smart Reporting, selezioni l’opzione per creare un nuovo report. Scelga 'Report' come tipo.
Selezioni l’origine dei dati e la vista: Le verrà chiesto di selezionare un’origine dei dati. Scelga l’origine principale dei dati AR System. Per la vista, cerchi e selezioni la vista Service Request, generalmente basata sul modulo SRM:Request.
Aggiunga altri moduli (join): per acquisire l’intero ciclo di vita, deve unire il modulo principale SRM:Request ai moduli correlati. Nella scheda 'Dati', aggiunga i seguenti join:
- SRM:WorkInfo (su SR ID+ = Request Number) per ottenere informazioni sulle attività di evasione e sui registri di lavoro.
- AP:Signature (su Request = SRInstanceID) per acquisire gli eventi relativi alle approvazioni, come approvazioni e rifiuti. Potrebbe essere necessario configurare un join personalizzato.
Definisca le colonne del report: trascini i campi richiesti dai moduli uniti nell’area 'Colonne'. Includa campi come Request Number, Submit Date, Stato, Descrizione, Priority, Assigned To e Assigned Group di SRM:Request, oltre ai campi correlati dei moduli uniti.
Crei campi calcolati per le attività: il metodo si basa sulla creazione di una serie di campi calcolati che rappresentano la data e l’ora di ciascuna attività. Apra la scheda 'Dati' e crei un nuovo campo calcolato per ogni attività. Per esempio:
- Data e ora di invio: utilizzi direttamente il campo Submit Date.
- Data e ora di approvazione: utilizzi Signature Date del modulo AP:Signature.
- Data e ora di inizio lavorazione: utilizzi MIN(Submit Date) da SRM:WorkInfo, raggruppato per Request Number.
Prepari il report per l’unione dei dati: 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 data e l’ora di ciascuna attività. Dovrà poi formattare l’esportazione finale per trasformare queste colonne in righe separate, una per ogni attività.
Applichi i filtri: per limitare l’ambito dei dati e migliorare le prestazioni, aggiunga filtri al report. Come minimo, filtri il campo Submit Date del modulo SRM:Request per selezionare un intervallo di date specifico. Se opera in un ambiente multi-tenant, aggiunga anche filtri per 'Company'.
Esegua il report e visualizzi un’anteprima dei dati: esegua il report per verificare che i dati vengano recuperati correttamente. Controlli che i join siano corretti, che le colonne siano compilate e che i campi calcolati restituiscano le date e le ore previste.
Esporti il report: dopo aver verificato il report, esporti i dati. Scelga CSV o Microsoft Excel come formato di esportazione, poiché entrambi sono facilmente elaborabili per l’importazione negli strumenti di Process Mining.
Trasformi i dati: dopo l’esportazione, trasformi i dati da un formato largo (una riga per richiesta di servizio con molte colonne contenenti date e ore) a un formato lungo (una riga per attività). Utilizzi uno script, ad esempio in Python o PowerShell, oppure uno strumento come Power Query di Excel per trasformare le colonne delle date e delle ore in due colonne: ActivityName e EventStartTime. Questo passaggio è essenziale per creare la struttura richiesta per l’Event Log.

Configurazione

Prerequisiti: deve disporre di un account utente con autorizzazioni per la creazione e l’esecuzione di report in BMC Helix ITSM, in particolare in Smart Reporting. Sono inoltre necessarie le autorizzazioni di lettura per i moduli SRM:Request, SRM:WorkInfo e AP:Signature.
Moduli principali: il report si basa sull’unione dei seguenti moduli:
- SRM:Request: modulo principale con i dettagli della richiesta di servizio.
- SRM:WorkInfo: contiene le voci del registro di lavoro, utilizzate per ricavare le attività di evasione.
- AP:Signature: contiene i record delle approvazioni, essenziali per monitorare le attività correlate.
Filtro per intervallo di date: applichi sempre un filtro per intervallo di date al campo SRM:Request.Submit Date. Si consiglia di utilizzare dati relativi a un periodo compreso tra 3 e 6 mesi, così da ottenere un campione rappresentativo senza compromettere le prestazioni del report.
Filtri importanti: oltre all’intervallo di date, filtri per 'Company' per isolare i dati di una specifica entità aziendale. Può anche escludere determinati tipi di richiesta o stati, ad esempio 'Bozza', non pertinenti all’analisi del processo.
Considerazioni sulle prestazioni: i report che uniscono più moduli su un ampio intervallo di date possono richiedere molto tempo. Per i volumi di dati elevati, si consiglia di pianificare l’esecuzione del report nelle fasce orarie di minore attività. Se si verificano timeout, suddivida l’estrazione in intervalli mensili più brevi.

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: verifichi di disporre di un client per 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 per stabilire una connessione al server del database AR System.
Prepari la query: copi la query SQL completa fornita nella sezione 'Query' di questo documento nell’editor di query del client.
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 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 alcuni minuti.
Riveda i risultati: al termine dell’esecuzione, verrà visualizzato un insieme di risultati contenente l’Event Log. Controlli brevemente che i dati siano stati compilati correttamente e includano le colonne e le attività previste.
Verifichi le date e le ore: controlli che tutte le colonne con date e ore, in particolare EventStartTime, EventEndTime e LastDataUpdate, utilizzino un formato coerente, ad esempio '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 per salvare l’intero insieme di risultati in un file CSV. Scelga la codifica UTF-8 per garantire la compatibilità.
Prepari il file per 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 evitano modifiche accidentali ai dati e si rispettano le migliori pratiche 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 da 3 a 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 per azienda: è incluso il segnaposto :company_name per filtrare le richieste di una specifica azienda operativa. Per estrarre i dati di tutte le aziende, può rimuovere la riga AND req.Company = :company_name oppure impostare 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, In Review = 1 e così via. Il Suo sistema potrebbe utilizzare stati personalizzati o una corrispondenza diversa con i valori interi. 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 registri di audit, possono richiedere molte risorse. Pianifichi l’estrazione nelle fasce orarie di minore attività per ridurre al minimo l’impatto sulle prestazioni del sistema.

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: verifichi che nel sistema sia installato Python 3.6 o una versione successiva. 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. L’account deve disporre almeno delle autorizzazioni di sola lettura per il modulo SRM:Request e per il modulo corrispondente al registro di audit, spesso denominato SRM:Request_AuditLog o in modo simile. Annoti il nome utente, la password e l’URL di base dell’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 inserisca i valori nelle variabili segnaposto all’inizio: BASE_URL, USERNAME, PASSWORD e AUDIT_FORM_NAME. Aggiorni il dizionario STATUS_ACTIVITY_MAP in base ai valori di stato utilizzati nel flusso di lavoro 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 la prima prova, utilizzi un intervallo breve, ad esempio un solo giorno.
Esegua lo script: avvii lo script dal terminale con il comando python extract_servicerequests.py. Per prima cosa, lo script effettuerà l’autenticazione tramite API per ottenere un token.
Recuperi i dati iniziali: lo script interroga il modulo SRM:Request per recuperare l’elenco di tutte le richieste di servizio create nell’intervallo di date specificato. In questo passaggio raccoglie l’ID del caso e gli attributi statici associati, come la priorità e il tipo di servizio.
Recuperi la cronologia degli eventi: lo script scorre gli ID delle richieste di servizio ottenuti nel passaggio precedente. Per ciascun ID, effettua una seconda chiamata API al modulo del registro di audit configurato, per recuperare la cronologia dettagliata delle modifiche di stato della richiesta.
Trasformi i dati in un Event Log: per ogni record del registro di audit, lo script associa la modifica di stato a un nome di attività standard utilizzando STATUS_ACTIVITY_MAP. Crea una riga per ogni attività associata, con l’ID della richiesta di servizio, il nome dell’attività e la data e l’ora della modifica.
Generi l’evento di invio: per ogni richiesta, lo script crea anche l’attività iniziale 'Richiesta di servizio inviata', utilizzando il campo Submit Date del modulo principale SRM:Request.
Esporti in CSV: dopo aver elaborato tutte le richieste di servizio e le relative cronologie, lo script riunisce le righe generate in un unico elenco e salva 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 avviene tramite api/jwt/login. I dati vengono interrogati da arsys/v1/entry/SRM:Request per ottenere l’elenco dei casi e da arsys/v1/entry/[AUDIT_FORM_NAME] per recuperare 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 del registro di audit del sistema. L’utilizzo di un account di servizio è essenziale per la sicurezza e la tracciabilità.
Filtro per intervallo di date: lo script filtra le richieste di servizio in base al campo Submit Date. Per garantire prestazioni affidabili, si consiglia di estrarre i dati in blocchi gestibili, ad esempio per periodi di 3-6 mesi.
Associazione tra stati e attività: il dizionario STATUS_ACTIVITY_MAP nello script è il fulcro della logica di trasformazione. Deve essere configurato con attenzione per rispecchiare gli stati personalizzati dell’organizzazione e associarli ai nomi di attività desiderati. Gli stati del flusso di lavoro non inclusi nella mappa verranno ignorati.
Modulo del registro di audit: la possibilità dello script di acquisire attività dettagliate dipende interamente dalla disponibilità di un registro di audit interrogabile. Individui il nome corretto del modulo nel Suo ambiente, quello in cui viene archiviata la cronologia delle modifiche di stato delle richieste di servizio, e aggiorni di conseguenza la variabile AUDIT_FORM_NAME.
Paginazione: lo script gestisce automaticamente la paginazione dell’API per recuperare tutti i record. Il parametro limit della chiamata API è impostato per recuperare 1000 record per richiesta, bilanciando prestazioni e utilizzo della memoria.

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 a iniziare?

Utilizzi questo template per semplificare la raccolta dei dati e avviare con sicurezza il Process Mining. Inizi subito a ottimizzare la gestione delle richieste di servizio.

Torna alla guida al miglioramento

Scarica il template

Più efficienza: ottimizzi subito la gestione delle richieste di servizio

Raggiunga il 70% di automazione, elimini i ritardi nell’evasione delle richieste e migliori l’esperienza degli utenti.

Inizi la prova gratuita

Non è richiesta una carta di credito. Può iniziare in pochi minuti.

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

Il Suo template dei 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

Query di esempio sql

Query SQL diretta sulle tabelle del database AR System

Passaggi

Configurazione

Query di esempio sql

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

Passaggi

Configurazione

Query di esempio python

È pronto a iniziare?

Più efficienza: ottimizzi subito la gestione delle richieste di servizio