Estrazione di dati del registro eventi
I dati del registro eventi che occorre importare nel mining dei processi devono fornire le informazioni richieste. Inoltre, il registro eventi può contenere una quantità maggiore di dati per consentire un'analisi più approfondita nel mining dei processi. Il registro eventi contiene uno o più casi, ognuno dei quali documenta i passaggi che compongono il processo oggetto dell'analisi.
I casi sono costituiti dall'insieme degli eventi che fanno parte del caso. Un singolo caso molto probabilmente presenta diversi eventi. Gli eventi possono svolgersi consecutivamente o contemporaneamente. Gli eventi che compongono un caso completo potrebbero provenire da più sistemi diversi, tutti coinvolti nel processo aziendale che si intende analizzare con il mining dei processi.
Gli eventi presentano determinati attributi per identificare i punti dati da valutare. I dati del registro eventi devono contenere ID caso, nome impegno e timestamp di inizio/fine per consentire al mining dei processi di analizzare i dati. Case ID è il componente più importante perché identifica l'oggetto su cui agisce il processo, ad esempio un ID ordine, un ID paziente o un ID parte. Il sistema usa l'ID caso per correlare gli eventi tra le diverse fasi e i sistemi coinvolti nel processo. Oltre ai dati richiesti, è possibile e opportuno fornire ulteriori dati per agevolare il processo di analisi, ad esempio informazioni sulle risorse, sugli attributi a livello di evento, sugli attributi a livello di caso e informazioni finanziarie.
Campi obbligatori
I tre campi obbligatori per ciascun caso sono:
Case ID: rappresenta un'istanza dell'intero processo. Questo campo potrebbe richiedere il mapping se un sistema di registrazione non contiene il campo. Ad esempio, potrebbe essere necessario abbinare l'ID CRM all'ID ordine interno.
Activity Name: sono le fasi del processo. I nomi descrivono ciascun passaggio e devono essere univoci tra sistemi diversi. Ad esempio, se il nome Ordine processo è presente in due sistemi, viene considerato come un unico passaggio. In questo caso, prendere in considerazione l'idea di immettere il nome del sistema o un altro attributo per renderlo univoco.
Timestamp: indicano l'ora esatta in cui si è verificato un evento o un impegno. Alcuni sistemi potrebbero avere un impegno che indica l'ora di inizio e un impegno di fine che rappresenta il timestamp di fine; tuttavia, potrebbero non trovarsi sulla stessa riga.
Altri campi
Più campi apportano più punti dati e, con più punti dati, il mining dei processi può valutare più collaboratori di un processo.
Resources: questo campo indica una risorsa tecnica o umana che sta implementando un evento specifico.
Event Level Attributes: questo campo contiene attributi analitici aggiuntivi e un valore diverso per ciascun evento. Gli attributi a livello di evento potrebbero includere reparto, origine, supporto o importi degli ordini.
Case Level Attributes (first event): questo campo contiene un attributo aggiuntivo, che considera analiticamente un singolo valore per ogni caso. Ad esempio, il sistema potrebbe identificare un attributo region nel primo evento del caso. L'area è la stessa in tutti gli eventi del caso. Il sistema archivia i valori così come sono (comprese le varianti minori), usando il meccanismo di interpretazione degli attributi a livello di caso, mentre il mining dei processi interpreta tutti gli eventi come se avessero lo stesso valore. Inoltre, il sistema prende un Case Level Attribute (last event) dall'ultimo evento cronologicamente verificatosi nel caso.
Financial per event: questo campo contiene un valore numerico/ricavo/costo fisso che cambia per ogni attività eseguita dal sistema, ad esempio i costi del servizio di corriere. Il sistema calcola il valore finanziario come somma (media, minimo, massimo) dei valori finanziari di ciascun evento.
Financial per case (first event): questo campo contiene un attributo numerico aggiuntivo che è considerato un valore singolo per ogni caso, come Case Level Attribute (first event). È il valore che appare nel primo evento che il sistema usa per tutti gli eventi del caso. Anche questo attributo usa il meccanismo di interpretazione degli attributi a livello di caso. Inoltre, il sistema prende un Financial per case (last event) dall'ultimo evento cronologicamente verificatosi nel caso.
Attributo a livello di caso negli eventi
Nei registri eventi sono disponibili diversi tipi di attributo. Gli attributi a livello di caso sono visualizzati su un singolo evento. Con la raccolta di eventi che costituiscono il caso, occorre identificare ed eseguire il mapping correttamente di tale attributo a livello di caso. Se si ha la certezza che tutti gli eventi nello stesso caso hanno lo stesso valore, il tipo di campo specifico non ha importanza (primo evento o ultimo evento). Se invece è possibile (o addirittura probabile) che si verifichino leggere differenze nei dettagli degli attributi di un singolo evento, è possibile definire quale evento del caso debba essere l'attributo del caso definito.
Nelle tabelle seguenti, l'attributo del caso Region risultante è lo stesso: Sud.
Case attribute (first event)
| CaseID | Event | Resource | Region |
|---|---|---|---|
| 123 | A | User1 | Sud |
| 123 | B | System3 | Sud |
| 123 | C | User7 | Est |
| 123 | D | User2 | Est |
Case attribute (last event)
| CaseID | Event | Resource | Region |
|---|---|---|---|
| 123 | A | User1 | Ovest |
| 123 | B | System3 | Sud |
| 123 | C | User7 | Est |
| 123 | D | User2 | Sud |
Usare Copilot per semplificare l'identificazione dei dati per il mapping
Quando si valutano e si acquisiscono i dati, Microsoft Copilot può rispondere alle domande sul processo, ad esempio quali colonne sono coinvolte nel processo stesso.
Copilot può rispondere alle domande sui dati.
Quando si è pronti a eseguire il mapping del tipo di attributo e del tipo di dati dell'attributo, Copilot offre automaticamente dei mapping. Con una semplice azione è possibile approvare i mapping suggeriti e il sistema eseguirà automaticamente il mappng che potrà successivamente essere oggetto di esame.
