Il Suo Template dati Purchase to Pay - Requisition
Il Suo Template dati Purchase to Pay - Requisition
- Attributi consigliati da raccogliere per un'analisi dettagliata
- Attività chiave da monitorare per la process discovery
- Indicazioni per l'estrazione dei dati da SAP S/4HANA
Purchase to Pay - Attributi della richiesta d’acquisto
| Nome | Descrizione | ||
|---|---|---|---|
| ID della richiesta di acquisto PurchaseRequisitionId | L'identificatore univoco di un documento di richiesta di acquisto. | ||
| Descrizione L'ID della richiesta di acquisto è la chiave primaria che identifica univocamente ogni richiesta di beni o servizi in SAP S/4HANA. Funge da identificatore centrale del caso e collega tutte le attività e le modifiche relative a una specifica richiesta, dalla creazione allo stato finale, ad esempio approvazione, rifiuto o conversione in un ordine di acquisto. Nel Process Mining, questo Attributo è fondamentale per ricostruire il ciclo di vita end-to-end di ogni richiesta. Raggruppando tutti gli eventi correlati sotto un unico ID della richiesta di acquisto, gli analisti possono misurare con precisione i tempi di ciclo, monitorare le variazioni di stato e analizzare i diversi percorsi che una richiesta può seguire nel processo di approvazione. Perché è importante È l'identificatore essenziale del caso che collega tutte le fasi correlate del processo, consentendo una visione completa e coerente del ciclo di vita della richiesta. Dove reperirlo Questo Attributo corrisponde al numero della richiesta di acquisto, presente nella tabella EBAN, campo BANFN. Esempi 100178901001789110017892 | |||
| Nome dell'attività ActivityName | Il nome dell'attività aziendale che si è verificata in uno specifico momento del processo della richiesta. | ||
| Descrizione Il nome dell'attività descrive uno specifico evento o compito che si è verificato nel ciclo di vita di una richiesta di acquisto. Queste attività derivano dai log di sistema, come i documenti di modifica e la cronologia del Workflow, e rappresentano tappe fondamentali del processo, quali «Richiesta di acquisto creata», «Fase di approvazione avviata» o «Ordine di acquisto creato». L'analisi di queste attività consente di visualizzare il flusso del processo, individuare i colli di bottiglia e misurare il tempo trascorso nelle diverse fasi. Comprendere la sequenza e la frequenza di attività come «Richiesta di acquisto modificata» o «Richiesta di acquisto rifiutata» è fondamentale per individuare le inefficienze del processo e le aree di miglioramento. Perché è importante Definisce le fasi del processo, costituendo la struttura portante della mappa del processo e consentendo di analizzare il flusso, le varianti e i colli di bottiglia. Dove reperirlo Si tratta di un Attributo derivato, generalmente costruito interpretando i dati delle tabelle dei documenti di modifica (CDHDR, CDPOS) e dei log del Workflow, ad esempio SWWLOGHIST. Esempi Richiesta di acquisto creataFase di approvazione completataRichiesta di acquisto approvataOrdine di acquisto creato | |||
| Ora dell'evento EventTime | La data e l'ora precise in cui si è verificata una specifica attività. | ||
| Descrizione L'ora dell'evento è il timestamp che registra il momento in cui si è svolta un'attività. Questi dati sono fondamentali per ordinare cronologicamente gli eventi all'interno di un caso e costituiscono la base per tutti i calcoli di durata e prestazione nel Process Mining. Ad esempio, la differenza di tempo tra gli eventi «Richiesta di acquisto inviata» e «Richiesta di acquisto approvata» determina il tempo di ciclo dell'approvazione. Timestamp accurati sono essenziali per analizzare le prestazioni del processo, individuare i ritardi e monitorare il rispetto degli accordi sui livelli di servizio. Questo Attributo consente di creare Dashboard che visualizzano i tempi di ciclo, monitorano le richieste bloccate e confrontano le prestazioni in periodi diversi. Perché è importante Questo timestamp è essenziale per ordinare gli eventi, calcolare i tempi di ciclo e analizzare le prestazioni del processo e i colli di bottiglia. Dove reperirlo I timestamp provengono generalmente dalle intestazioni dei documenti di modifica (CDHDR-UDATE, CDHDR-UTIME) o dai log degli eventi del Workflow. Esempi 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| ID approvatore ApproverId | L'identificatore dell'utente che ha eseguito una fase di approvazione o rifiuto. | ||
| Descrizione L'ID approvatore identifica nello specifico l'utente che ha completato un'attività di approvazione o rifiuto. Si distingue dall'ID utente generico perché si concentra esclusivamente sui responsabili delle decisioni all'interno del Workflow di approvazione. Acquisire queste informazioni è fondamentale per analizzare in dettaglio il processo di approvazione. Questo Attributo consente di analizzare i comportamenti degli approvatori, ad esempio individuando i manager con tempi di approvazione lunghi o quelli che rifiutano frequentemente le richieste. È fondamentale per le Dashboard dedicate ai tempi di ciclo delle fasi di approvazione e all'analisi dei colli di bottiglia del Workflow, aiutando a individuare persone o ruoli specifici che possono causare ritardi. Perché è importante Individua il responsabile della decisione in una specifica fase di approvazione, consentendo un'analisi dettagliata dei tempi di ciclo e dei colli di bottiglia per persona o ruolo. Dove reperirlo Queste informazioni vengono generalmente estratte da tabelle SAP Business Workflow come SWW_WI2OBJ e SWWLOGHIST, che collegano gli elementi di lavoro all'utente che li ha completati. Esempi MJOHNSONCWILLIAMSLBLACK | |||
| ID utente UserId | L'identificatore dell'utente che ha creato la richiesta o eseguito una specifica attività. | ||
| Descrizione L'ID utente identifica il dipendente o l'utente di sistema responsabile di un determinato evento nel ciclo di vita della richiesta. Può trattarsi della persona che ha creato la richiesta, del manager che l'ha approvata o dell'operatore che l'ha modificata. Nel caso di fasi automatizzate, può corrispondere all'ID di un utente di sistema o batch. L'analisi per ID utente aiuta a comprendere i comportamenti individuali, la distribuzione del carico di lavoro e le prestazioni. È fondamentale per individuare le esigenze formative, riconoscere le persone con prestazioni elevate e garantire la responsabilità all'interno del processo. Supporta inoltre l'analisi delle prestazioni dei reparti se combinato con i dati anagrafici degli utenti. Perché è importante Consente di analizzare le prestazioni degli utenti, la distribuzione del carico di lavoro e la conformità del processo. È fondamentale per individuare opportunità di formazione e colli di bottiglia nelle risorse. Dove reperirlo Per il creatore, si trova in EBAN-ERNAM. Per le modifiche successive, si trova in CDHDR-USERNAME. Per le approvazioni, si trova nei log del Workflow. Esempi JSMITHRROEWF-BATCH | |||
| Importo della richiesta di acquisto RequisitionAmount | Il valore monetario totale della richiesta di acquisto. | ||
| Descrizione L'importo della richiesta di acquisto rappresenta il costo totale stimato dei beni o servizi richiesti. Questo valore è spesso un fattore determinante per la complessità e la durata del Workflow di approvazione, poiché le richieste di importo più elevato richiedono generalmente più livelli di approvazione. Analizzare questo Attributo consente di segmentare il processo in base al valore. Può aiutare a rispondere a domande come «Le richieste di importo elevato richiedono più tempo per essere approvate?» oppure «Qual è il valore delle richieste che vengono rifiutate più frequentemente?». È una dimensione fondamentale per comprendere l'impatto finanziario delle inefficienze del processo. Perché è importante Aiuta a segmentare il processo in base all'impatto finanziario, spesso correlato alla complessità dell'approvazione e al tempo di ciclo. È fondamentale per l'analisi del processo basata sul valore. Dove reperirlo Il valore totale si trova nella tabella EBAN, campo GFWERT. Il valore a livello di posizione si trova in EBAN-PREIS. Esempi 1500.0075000.50250.75 | |||
| Reparto Department | Il reparto o centro di costo a cui vengono addebitati i costi della richiesta. | ||
| Descrizione L'Attributo Reparto, spesso rappresentato dal centro di costo in SAP, identifica l'unità aziendale responsabile dell'acquisto richiesto. È un'informazione finanziaria e organizzativa fondamentale, assegnata a livello di posizione della richiesta. Nel Process Mining, questo Attributo è essenziale per l'analisi delle prestazioni dei reparti. Consente di creare Dashboard che confrontano metriche chiave come tempi di ciclo, tassi di modifica e tassi di rifiuto tra reparti diversi. In questo modo è possibile individuare i reparti con le prestazioni migliori, le cui pratiche possono essere adottate altrove, e quelli che potrebbero richiedere ulteriore formazione o supporto al processo. Perché è importante Consente di confrontare le prestazioni tra unità aziendali, evidenziando variazioni nei tempi di ciclo o nei tassi di rifiuto per individuare best practice e aree di miglioramento. Dove reperirlo È il centro di costo, generalmente presente nella tabella di assegnazione contabile EBKN, campo KOSTL. Esempi FIN-1001IT-2005MKT-3010 | |||
| Stato della richiesta di acquisto RequisitionStatus | Lo stato attuale di elaborazione o approvazione della richiesta di acquisto. | ||
| Descrizione Lo stato della richiesta di acquisto indica la condizione attuale della richiesta nel suo ciclo di vita. In SAP è spesso rappresentato dall'indicatore di rilascio, che mostra se una richiesta è bloccata, in approvazione, parzialmente approvata o completamente approvata. Questo stato cambia man mano che la richiesta avanza nel Workflow. Monitorare lo stato nel tempo è fondamentale per comprendere il flusso del processo. Aiuta a individuare dove le richieste si bloccano e per quanto tempo. Analizzare le transizioni tra gli stati consente di ottenere una visione dettagliata del processo di approvazione e delle sue varianti. Perché è importante Indica lo stato attuale di una richiesta, fondamentale per monitorare l'avanzamento, individuare i colli di bottiglia e analizzare il flusso del processo. Dove reperirlo Lo stato di rilascio è spesso determinato dall'indicatore di rilascio, presente nella tabella EBAN, campo FRGZU. Esempi B1S | |||
| Tipo di richiesta di acquisto RequisitionType | Un codice che classifica la richiesta di acquisto, ad esempio per articoli standard, servizi o investimenti. | ||
| Descrizione Il tipo di richiesta di acquisto, noto anche come tipo di documento in SAP, è un campo di configurazione fondamentale che categorizza le richieste di acquisto. Tipi diversi possono attivare Workflow di approvazione differenti, prevedere impostazioni diverse per i campi ed essere utilizzati per finalità aziendali diverse, come articoli standard a magazzino, servizi esterni o acquisti di cespiti. Analizzare il processo in base al tipo di richiesta di acquisto consente alle organizzazioni di comprendere come vengono gestite le diverse richieste. Permette di confrontare prestazioni, tempi di ciclo e percorsi di approvazione tra le categorie, evidenziando se determinati tipi di richiesta sono più o meno efficienti e aiutando a definire miglioramenti mirati. Perché è importante Categorizza le richieste per consentire analisi comparative e comprendere se tipi diversi di richiesta presentano flussi di processo, colli di bottiglia o tempi di ciclo differenti. Dove reperirlo È il campo Tipo di documento, presente nella tabella EBAN, campo BSART. Esempi NBFORV | |||
| Data richiesta RequiredByDate | La data entro la quale il richiedente necessita dei beni o servizi richiesti. | ||
| Descrizione La data richiesta, o data di consegna in SAP, specifica quando sono necessari i beni o servizi indicati nella posizione della richiesta. Viene impostata dal richiedente e funge da obiettivo per l'intero processo di approvvigionamento. Questo Attributo è essenziale per calcolare il KPI «Tasso di completamento puntuale delle richieste». Confrontando la data richiesta con la data dell'approvazione finale o della creazione dell'ordine di acquisto, l'organizzazione può misurare la propria capacità di rispettare i livelli di servizio interni e le esigenze aziendali. Analizzare le richieste che non rispettano questa data può far emergere ritardi sistemici nel processo di approvvigionamento. Perché è importante Definisce la data obiettivo di completamento di una richiesta, consentendo di misurare la puntualità della consegna e il rispetto dei livelli di servizio interni. Dove reperirlo È la data di consegna, presente a livello di posizione nella tabella EBAN, campo LFDAT. Esempi 2023-11-152023-12-012024-01-20 | |||
| È automatizzata IsAutomated | Un indicatore che segnala se un'attività è stata eseguita da un utente di sistema anziché da una persona. | ||
| Descrizione L'attributo Is Automated è un flag booleano che vale true se un'attività è stata eseguita da un utente di sistema o batch, ad esempio 'WF-BATCH' per le azioni del Workflow. Questo consente di distinguere tra passaggi manuali e automatizzati nel processo. Questo attributo è essenziale per misurare il livello di automazione nel processo di richiesta d'acquisto e per calcolare il KPI 'Automated Approval Rate'. Filtrando i passaggi automatizzati o manuali, gli analisti possono confrontarne l'efficienza e individuare opportunità per aumentare ulteriormente l'automazione, riducendo i tempi di elaborazione e il lavoro manuale. Perché è importante Distingue tra attività eseguite da persone e attività gestite dal sistema, un elemento fondamentale per misurare i tassi di automazione e individuare opportunità per automatizzare le attività manuali. Dove reperirlo Si tratta di un attributo derivato, generalmente basato su una regola che verifica se lo User ID associato a un evento appartiene a un elenco di utenti di sistema o batch noti. Esempi truefalse | |||
| È una rilavorazione IsRework | Flag che indica se un'attività costituisce una rilavorazione, ad esempio una modifica effettuata dopo l'invio. | ||
| Descrizione Is Rework è un flag booleano calcolato che identifica le attività che rappresentano lavoro ripetitivo o senza valore aggiunto. Un esempio comune in questo processo è l'attività 'Requisition Amended' che si verifica dopo che la richiesta è già stata inviata per l'approvazione, costringendo a riavviare il processo di approvazione. Questo attributo è fondamentale per quantificare la rilavorazione nel processo e il suo impatto sui tempi di attraversamento complessivi. Il Dashboard Requisition Amendment and Rework Rate utilizza questo flag per evidenziare le inefficienze del processo. Ridurre la rilavorazione è spesso uno degli obiettivi principali delle iniziative di miglioramento dei processi, poiché si traduce direttamente in un risparmio di tempo e di lavoro. Perché è importante Segnala le attività che rappresentano lavoro sprecato o ripetuto, consentendo di misurare direttamente la rilavorazione e il suo impatto sull'efficienza del processo. Dove reperirlo Si tratta di un attributo calcolato. In genere, la logica contrassegna come rilavorazione qualsiasi attività 'Requisition Amended' che si verifica dopo la prima attività 'Requisition Submitted For Approval'. Esempi truefalse | |||
| Livello di urgenza UrgencyLevel | Classificazione dell'urgenza della richiesta d'acquisto, che può influire sulla priorità di elaborazione. | ||
| Descrizione Il Livello di urgenza indica la priorità della richiesta d'acquisto. Sebbene non esista un campo dedicato standard, alcune organizzazioni utilizzano campi come il Requirement Tracking Number per registrare questa informazione. In questo modo, i richiedenti possono segnalare esigenze critiche che potrebbero richiedere un'elaborazione accelerata. Analizzare l'impatto dell'urgenza è importante per valutare se il processo assegna effettivamente la priorità alle richieste critiche. Il Dashboard Urgency Level Impact Analysis utilizza questo attributo per confrontare i tempi di attraversamento e i tassi di approvazione delle richieste urgenti e standard, aiutando a determinare se la gestione prioritaria funziona come previsto. Perché è importante Consente di analizzare come le prestazioni del processo variano per le richieste ad alta priorità, aiutando a verificare se gli elementi urgenti vengono realmente elaborati più rapidamente. Dove reperirlo Non esiste un campo standard per l'urgenza. Alcune aziende utilizzano il Requirement Tracking Number (EBAN-BEDAR) a questo scopo. Può anche trattarsi di un campo personalizzato. Esempi AltaMediaBassa | |||
| Motivo del rifiuto RejectionReason | Il motivo indicato quando una richiesta di acquisto viene rifiutata. | ||
| Descrizione Il motivo del rifiuto spiega perché un approvatore ha deciso di rifiutare una richiesta di acquisto. Tra le possibili ragioni rientrano il superamento del budget, informazioni errate, la non conformità alle policy o la duplicazione di un'altra richiesta. Queste informazioni forniscono un contesto fondamentale per comprendere gli esiti negativi del processo. Analizzare i motivi del rifiuto aiuta a individuare le cause principali delle inefficienze e delle rilavorazioni. Ad esempio, se «Centro di costo errato» è un motivo frequente, ciò indica la necessità di una formazione migliore degli utenti o di controlli di validazione nel sistema. Questo Attributo è alla base della Dashboard di analisi dei rifiuti delle richieste ed è fondamentale per un miglioramento mirato del processo. Perché è importante Fornisce la causa principale degli esiti negativi del processo, consentendo miglioramenti mirati per ridurre le rilavorazioni e aumentare il tasso di correttezza al primo tentativo delle richieste. Dove reperirlo Spesso non si tratta di un campo standard. Può essere acquisito negli elementi del contenitore del Workflow, nei testi estesi associati alla richiesta o nei campi personalizzati. Esempi Budget superatoFornitore erratoRichiesta duplicata | |||
| Nome del passaggio di approvazione ApprovalStepName | Nome o descrizione specifica di un passaggio di approvazione nel Workflow. | ||
| Descrizione Il Nome del passaggio di approvazione fornisce una descrizione comprensibile di una determinata fase del Workflow di approvazione, ad esempio 'Manager Approval' o 'VP Finance Approval'. È più descrittivo rispetto a un'attività generica come 'Approval Step Completed'. Questo attributo è fondamentale per i Dashboard Approval Step Cycle Time e Workflow Bottleneck Analysis. Consente di analizzare il processo di approvazione con un livello di dettaglio elevato, rendendo possibile individuare con precisione le fasi che causano i ritardi più significativi e i punti in cui il lavoro si accumula. Questo livello di dettaglio è necessario per definire interventi mirati e rendere più fluida la catena di approvazione. Perché è importante Fornisce un livello di dettaglio granulare sulle fasi di approvazione, consentendo di identificare con precisione i colli di bottiglia all'interno del Workflow di approvazione multilivello. Dove reperirlo Queste informazioni derivano dalla descrizione dell'attività di Workflow, disponibile collegando il log del Workflow alle tabelle di definizione delle attività, come T528T. Esempi Approvazione del managerApprovazione del direttoreApprovazione del VP Finanza | |||
| Numero dell'ordine di acquisto PurchaseOrderNumber | Il numero dell'ordine di acquisto creato a partire dalla richiesta. | ||
| Descrizione Il numero dell'ordine di acquisto è l'identificatore del documento ufficiale di approvvigionamento creato a partire da una richiesta approvata. La creazione di un ordine di acquisto rappresenta spesso l'esito finale e positivo di una richiesta, indicando che la domanda è stata convertita in un ordine formale presso un fornitore. Questo Attributo è fondamentale per misurare il KPI del tempo di attraversamento dalla richiesta all'ordine di acquisto e il tasso complessivo di conversione. Collega il processo di richiesta al successivo processo di approvvigionamento, consentendo una visione più ampia end-to-end dell'intero ciclo Purchase-to-Pay. Perché è importante Collega la richiesta al successivo documento di approvvigionamento, consentendo di misurare il tasso e il tempo di conversione da richiesta a ordine di acquisto. Dove reperirlo Si trova nella tabella EBAN, campo EBELN, una volta creato un ordine di acquisto a partire dalla posizione della richiesta. Esempi 450001789045000178914500017892 | |||
| Ora di fine EndTime | Data e ora precise in cui è stata completata una determinata attività. | ||
| Descrizione EndTime è il timestamp che registra il momento in cui un'attività è stata completata. Sebbene molti eventi generati dal sistema siano istantanei, ovvero StartTime coincide con EndTime, le attività svolte da persone, come le approvazioni, possono avere un inizio e una fine distinti. Questo timestamp indica il completamento dell'attività. La disponibilità di un EndTime separato consente di misurare con maggiore precisione il tempo di elaborazione effettivo rispetto al tempo di attesa. Viene utilizzato insieme a StartTime per calcolare la metrica ProcessingTime. Questo livello di dettaglio migliora l'analisi dell'utilizzo delle risorse e dell'efficienza delle attività manuali. Perché è importante Indica il completamento di un'attività, consentendo di calcolare il tempo di elaborazione effettivo e offrendo una visione più dettagliata della durata dell'attività. Dove reperirlo Deriva dai log del Workflow, che possono registrare sia il momento di creazione di un elemento di lavoro (StartTime) sia quello del suo completamento (EndTime). Esempi 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Sistema di origine SourceSystem | Identifica l'istanza specifica di SAP S/4HANA da cui sono stati estratti i dati. | ||
| Descrizione L'Attributo Sistema di origine indica il sistema di provenienza in cui sono stati generati i dati del processo. Nelle organizzazioni con più istanze SAP, ad esempio sistemi distinti per sviluppo, controllo qualità e produzione oppure sistemi separati per diverse aree geografiche, questo campo è fondamentale per la governance dei dati e il contesto. Garantisce che i dati provenienti da fonti diverse possano essere distinti, evitando aggregazioni errate e consentendo analisi specifiche per sistema. È un Attributo obbligatorio per mantenere la lineage dei dati e garantire la tracciabilità dei dati di processo. Perché è importante Fornisce il contesto essenziale sull'origine e sulla governance dei dati, soprattutto nei paesaggi con più sistemi, garantendo la tracciabilità dei dati. Dove reperirlo In genere si tratta del SAP System ID (SID), recuperabile dalle variabili di sistema o dalle tabelle di configurazione. Esempi S4PECCS4H_PROD_01 | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Il timestamp che indica quando i dati di questo record sono stati aggiornati l'ultima volta dal sistema di origine. | ||
| Descrizione Questo Attributo registra la data e l'ora dell'estrazione o dell'aggiornamento più recente dal sistema di origine. È un elemento di metadati fondamentale per comprendere l'aggiornamento dei dati analizzati. Gli analisti e gli utenti aziendali si affidano a questo timestamp per sapere se i dati di processo riflettono lo stato operativo più recente. In qualsiasi analisi di processo, conoscere l'attualità dei dati è fondamentale per prendere decisioni informate. Questo Attributo aiuta a gestire le aspettative degli utenti e garantisce che le conclusioni si basino su dati aggiornati nella misura richiesta dall'analisi specifica. Perché è importante Indica l'aggiornamento dei dati, un elemento fondamentale per considerare affidabile l'analisi e prendere decisioni aziendali tempestive. Dove reperirlo Questo timestamp viene generato e aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati. Esempi 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Valuta Currency | Il codice valuta dell'importo della richiesta di acquisto. | ||
| Descrizione Questo Attributo specifica la valuta in cui è espresso l'importo della richiesta, ad esempio USD, EUR o JPY. Fornisce il contesto necessario per l'Attributo Importo della richiesta di acquisto, soprattutto nelle organizzazioni multinazionali che operano con più valute. Per un'analisi e una reportistica finanziaria accurate, è essenziale considerare la valuta. Quando si aggregano o confrontano i valori delle richieste, tutti gli importi devono essere convertiti in una valuta comune per ottenere risultati significativi. Questo Attributo è un prerequisito per tali conversioni. Perché è importante Fornisce il contesto essenziale per l'importo della richiesta di acquisto, consentendo analisi e confronti finanziari accurati in ambienti con più valute. Dove reperirlo Si trova nella tabella EBAN, campo WAERS. Esempi USDEURGBP | |||
Purchase to Pay - Attività della richiesta d’acquisto
| Attività | Descrizione | ||
|---|---|---|---|
| Fase di approvazione completata | Si verifica quando un approvatore esprime un parere positivo su una richiesta, completando una fase del Workflow di approvazione multilivello. Viene dedotto da una modifica dello stato di rilascio della richiesta. | ||
| Perché è importante Questa attività consente un'analisi dettagliata del Workflow di approvazione, misurando il tempo impiegato per ogni singola fase. Aiuta a distinguere gli approvatori efficienti dai colli di bottiglia del processo. Dove reperirlo Viene dedotto dai documenti di modifica (CDHDR/CDPOS) relativi alla tabella EBAN. Una modifica dello stato del codice di rilascio, ad esempio nel campo FRGZU, da non rilasciato a rilasciato per uno specifico codice indica questo evento. Acquisizione Monitori le modifiche ai campi dello stato di rilascio in EBAN per ogni codice di rilascio definito nella strategia. Tipo di evento inferred | |||
| Ordine di acquisto creato | Indica che è stato generato un ordine di acquisto con riferimento alla posizione della richiesta. Si tratta di un evento esplicito del sistema che collega la richiesta a un successivo documento di approvvigionamento. | ||
| Perché è importante È una tappa importante e un esito positivo del processo di richiesta. Il tempo trascorso tra l'approvazione della richiesta e la creazione dell'ordine di acquisto è un KPI fondamentale per misurare l'efficienza dell'approvvigionamento. Dove reperirlo Viene registrato esplicitamente quando viene creata una posizione dell'ordine di acquisto. Il collegamento è memorizzato nella tabella EKPO (posizione dell'ordine di acquisto), che contiene il numero della richiesta di acquisto (BANFN) e il numero della posizione (BNFPO). Acquisizione Colleghi la tabella EKPO alla tabella EBAN tramite il numero e la posizione della richiesta. La data di creazione della posizione dell'ordine di acquisto identifica l'evento. Tipo di evento explicit | |||
| Richiesta di acquisto approvata | Indica l'approvazione finale e completa della richiesta di acquisto, che diventa così idonea alla conversione in un ordine di acquisto. Questa tappa viene dedotta quando lo stato complessivo di rilascio raggiunge lo stato finale di approvazione. | ||
| Perché è importante Si tratta di una tappa fondamentale per il buon esito del processo e di un punto finale comune per l'analisi dei tempi di ciclo. Indica che la richiesta ha superato tutti i controlli ed è pronta per essere gestita dall'ufficio acquisti. Dove reperirlo Viene dedotto da una modifica dello stato nella tabella EBAN, in particolare quando l'indicatore complessivo di rilascio (FRGZU) o lo stato di elaborazione (PROCSTAT) viene aggiornato a un valore finale «Approvato». Acquisizione Individui il timestamp in cui viene applicato il codice di rilascio finale o lo stato complessivo della richiesta passa ad «Approvato». Tipo di evento inferred | |||
| Richiesta di acquisto chiusa | Indica che la posizione della richiesta è considerata completamente elaborata e che non è più possibile creare ordini di acquisto a partire da essa. In genere questo stato viene impostato automaticamente quando è stata ordinata l'intera quantità. | ||
| Perché è importante Questa attività rappresenta il completamento finale e positivo del ciclo di vita della posizione della richiesta. Conferma che la necessità aziendale è stata interamente trasformata in un ordine di approvvigionamento. Dove reperirlo Viene dedotto dalla tabella EBAN. Si verifica quando viene impostato l'indicatore «Closed» (EBAKZ), generalmente quando la quantità ordinata negli ordini di acquisto è uguale alla quantità richiesta. Acquisizione Individui l'evento in cui l'indicatore «Closed» (EBAKZ) viene impostato nella tabella EBAN tramite i documenti di modifica. Tipo di evento inferred | |||
| Richiesta di acquisto creata | Indica la creazione iniziale del documento di richiesta di acquisto nel sistema. Questo evento viene acquisito esplicitamente quando un utente salva per la prima volta una nuova richiesta, registrandone il timestamp di creazione. | ||
| Perché è importante Questa attività costituisce il principale punto di avvio per l'analisi del ciclo di vita della richiesta. È essenziale per misurare il tempo di ciclo end-to-end, dall'identificazione iniziale della necessità fino all'approvazione finale o alla conversione in un ordine di acquisto. Dove reperirlo Si tratta di un evento esplicito acquisito dalla tabella EBAN, utilizzando i campi relativi alla data di creazione (ERDAT) e all'ora di creazione (ERZEIT) per lo specifico numero di richiesta di acquisto (BANFN). Acquisizione Utilizzi i campi relativi al timestamp di creazione (ERDAT, ERZEIT) della tabella EBAN per ogni richiesta (BANFN). Tipo di evento explicit | |||
| Richiesta di acquisto rifiutata | Rappresenta il rifiuto finale della richiesta di acquisto da parte di un approvatore, che interrompe il processo. Viene acquisito tramite uno specifico aggiornamento dello stato che indica il rifiuto. | ||
| Perché è importante Questa attività rappresenta un punto finale critico in caso di esito negativo. Analizzare la frequenza e le motivazioni dei rifiuti, nonché i punti del processo in cui si verificano, aiuta a individuare problemi di conformità alle policy, di budget o di qualità della richiesta. Dove reperirlo Viene dedotto da una modifica dello stato nella tabella EBAN. Lo stato di elaborazione (PROCSTAT) o un indicatore di rilascio viene impostato su un valore che significa esplicitamente «Rifiutato». Acquisizione Individui il timestamp in cui lo stato complessivo in EBAN viene aggiornato a «Rifiutato» tramite i documenti di modifica. Tipo di evento inferred | |||
| Fase di approvazione avviata | Indica che una richiesta è in attesa dell'intervento di uno specifico approvatore o gruppo di approvazione. Viene dedotto quando lo stato della richiesta indica che è in attesa di uno specifico codice di rilascio. | ||
| Perché è importante Questa attività è essenziale per individuare con precisione i colli di bottiglia nella catena di approvazione. Analizzare la durata di questo stato aiuta a identificare le richieste bloccate e gli approvatori sovraccarichi. Dove reperirlo Viene dedotto dai campi dello stato di rilascio della tabella EBAN, ad esempio FRGZU, e dalla configurazione sottostante della strategia di rilascio. L'evento inizia quando uno specifico codice di rilascio diventa il successivo da elaborare. Acquisizione Determini quando una richiesta entra in uno stato in cui uno specifico codice di rilascio è in attesa di approvazione, sulla base dei log del Workflow o dei campi di stato. Tipo di evento inferred | |||
| Fonte di approvvigionamento assegnata | Rappresenta l'azione con cui un buyer assegna uno specifico fornitore, contratto o record info a una posizione della richiesta approvata. È una fase fondamentale per preparare la richiesta alla creazione di un ordine di acquisto. | ||
| Perché è importante Questa attività colma il divario tra approvazione e ordinazione. Misurare il tempo necessario per assegnare una fonte aiuta a individuare i ritardi nel carico di lavoro del buyer e nell'efficienza dell'approvvigionamento. Dove reperirlo Viene dedotto dall'inserimento di un valore nei campi della tabella EBAN relativi alla fonte di approvvigionamento, come fornitore fisso (LIFNR), record info (INFNR) o contratto (KONNR). Acquisizione Monitori la valorizzazione di campi come LIFNR, INFNR o KONNR nella tabella EBAN tramite i documenti di modifica. Tipo di evento inferred | |||
| Reimpostazione dell'approvazione | Rappresenta un evento in cui l'intero Workflow di approvazione viene reimpostato, spesso a causa di una modifica significativa della richiesta. Il processo di approvazione deve quindi ripartire dal primo livello. | ||
| Perché è importante Questa attività evidenzia una rilavorazione significativa, con un forte impatto sul tempo di ciclo. Individuare le cause delle reimpostazioni dell'approvazione è fondamentale per semplificare il processo e ridurre i ritardi. Dove reperirlo Viene dedotto dai documenti di modifica (CDHDR/CDPOS) della tabella EBAN. L'evento viene rilevato quando i campi dello stato di rilascio, come FRGKZ o FRGZU, vengono cancellati dopo essere stati impostati parzialmente o completamente. Acquisizione Cerchi nei log delle modifiche un passaggio dello stato di rilascio da rilasciato a non rilasciato. Tipo di evento inferred | |||
| Richiesta di acquisto inviata per l'approvazione | Rappresenta il momento in cui il richiedente invia formalmente la richiesta, attivando il Workflow di approvazione. In genere viene dedotto quando viene determinata la strategia di rilascio della richiesta e lo stato passa a «In approvazione». | ||
| Perché è importante Si tratta di una tappa fondamentale che avvia il conteggio dei KPI relativi al tempo di ciclo dell'approvazione. Analizzare il tempo trascorso tra la creazione e l'invio può far emergere ritardi nella fase di preparazione della richiesta. Dove reperirlo Viene dedotto dai documenti di modifica (CDHDR/CDPOS) relativi alla tabella EBAN, in particolare quando i campi della strategia di rilascio, ad esempio FRGST, vengono valorizzati oppure quando lo stato complessivo (PROCSTAT) cambia per indicare una condizione di approvazione in corso. Acquisizione Individui la prima voce del documento di modifica che indica l'avvio del Workflow di approvazione o il passaggio dello stato a «In approvazione». Tipo di evento inferred | |||
| Richiesta di acquisto modificata | Si verifica quando un utente modifica un campo chiave della richiesta dopo la creazione iniziale, ad esempio quantità, prezzo o materiale. Questa azione viene registrata esplicitamente nel sistema SAP dei documenti di modifica. | ||
| Perché è importante Monitorare le modifiche è fondamentale per individuare i cicli di rilavorazione e il loro impatto sui tempi di ciclo. Un'elevata frequenza di modifiche suggerisce problemi nella qualità dei dati o requisiti variabili, aree chiave per il miglioramento del processo. Dove reperirlo Viene registrato esplicitamente nelle tabelle SAP dei documenti di modifica (CDHDR e CDPOS) per le modifiche apportate alla tabella EBAN. Ogni modifica a un campo monitorato genera una voce. Acquisizione Estragga gli eventi di modifica da CDHDR/CDPOS quando la classe oggetto è BANF per le richieste di acquisto. Tipo di evento explicit | |||
| Richiesta di acquisto ritirata | Si verifica quando il richiedente originale annulla o elimina la richiesta prima che venga elaborata completamente. In genere si tratta di un'azione esplicita che imposta un indicatore di eliminazione sulla posizione della richiesta. | ||
| Perché è importante Monitorare i ritiri aiuta a comprendere la volatilità della domanda e le ragioni delle cancellazioni. Rappresenta uno stato terminale per la richiesta, impedendone l'ulteriore elaborazione. Dove reperirlo Viene acquisito esplicitamente quando il campo dell'indicatore di eliminazione (LOEKZ) nella tabella EBAN viene impostato per una posizione della richiesta. La modifica viene registrata in CDHDR/CDPOS. Acquisizione Individui l'evento in cui l'indicatore di eliminazione (LOEKZ) nella tabella EBAN viene impostato su «L». Tipo di evento explicit | |||
Guide all'estrazione
Passaggi
- Prerequisiti: verifichi di disporre di un utente con le autorizzazioni appropriate in SAP S/4HANA per accedere alle CDS View necessarie. In genere sono richieste autorizzazioni per oggetti come S_TABU_NAM e l'accesso agli strumenti di visualizzazione dei dati.
- Identifichi il metodo di accesso al sistema: determini come collegarsi al database SAP S/4HANA per eseguire query SQL. Tra gli strumenti più comuni rientrano SAP HANA Studio, l'IDE Eclipse con ADT (ABAP Development Tools) o client SQL di terze parti come DBeaver, collegabili tramite il client del database SAP HANA.
- Esamini la query SQL: acquisisca familiarità con lo script SQL fornito. Utilizza Common Table Expressions (CTE) per raccogliere i dati relativi alle diverse attività e unirli in un Event Log unificato.
- Personalizzi i segnaposto: individui e sostituisca i segnaposto nella query. Dovrà impostare l'intervallo di date, nel formato
[YYYY-MM-DD], relativo al periodo di estrazione e specificare i codici azienda pertinenti,[Your Company Code], per la Sua organizzazione. - Esegua la query: esegua la query SQL completa e personalizzata sul database SAP S/4HANA. In base al volume dei dati e all'intervallo di date selezionato, l'esecuzione potrebbe richiedere tempo.
- Esamini inizialmente i dati: al termine della query, esamini le prime righe dell'output. Verifichi che tutte le colonne, come PurchaseRequisitionId, ActivityName ed EventTime, siano valorizzate come previsto e che i formati dei dati siano corretti.
- Gestisca la trasformazione dei dati: la query fornita è progettata per produrre dati già pronti per il Process Mining. Le funzioni
CASTeCONCATassicurano la coerenza dei tipi di dati. Non dovrebbe essere necessaria alcuna trasformazione significativa dopo l'esecuzione. - Esporti l'Event Log: esporti l'intero set di risultati dal client SQL in un file CSV. Verifichi che la codifica sia impostata su UTF-8 per evitare problemi con i caratteri.
- Prepari il caricamento: prima di caricare il file in uno strumento di Process Mining, verifichi che il file CSV contenga le intestazioni corrette, tra cui
PurchaseRequisitionId,ActivityNameedEventTime, e che il formato di data e ora diEventTimesia coerente e supportato dalla piattaforma di destinazione. - Carichi i dati in ProcessMind: carichi il file CSV finale nel Suo progetto ProcessMind. Configuri il progetto associando
PurchaseRequisitionIdal Case ID,ActivityNameall'Activity edEventTimeal Timestamp.
Configurazione
- CDS View principali: l'estrazione utilizza principalmente
I_PurchaseRequisitionAPI01per i dati principali delle richieste,I_ChangeDocumenteI_ChangeDocumentItemper monitorare modifiche e aggiornamenti di stato, eI_PurchaseOrderItemAPI01per il collegamento agli ordini d'acquisto. - Autorizzazioni: l'utente che esegue l'operazione deve disporre dell'accesso in lettura alle CDS View indicate. Si rivolga al team di sicurezza SAP per individuare ruoli e autorizzazioni necessari.
- Filtro per intervallo di date: è fondamentale applicare un filtro sull'intervallo di date relativo alla data di creazione della richiesta (
CreationDate) per limitare il volume dei dati. Per un'analisi iniziale si consiglia un intervallo compreso tra 3 e 6 mesi. - Filtro organizzativo: filtri i dati per
CompanyCodeper assicurarsi di analizzare il processo dell'entità aziendale corretta. Può inoltre valutare un filtro perPurchaseRequisitionTypeper concentrarsi su specifici processi di approvvigionamento, ad esempio beni standard rispetto ai servizi. - Configurazione dei documenti di modifica: l'acquisizione di attività come 'Requisition Amended' e delle diverse fasi di approvazione dipende dall'attivazione della registrazione dei documenti di modifica per i campi pertinenti nel sistema SAP. Se questi eventi non sono presenti, verifichi la configurazione del sistema per la tabella EBAN.
- Prestazioni: nei sistemi molto grandi, con milioni di richieste, l'esecuzione della query su un periodo esteso può influire sulle prestazioni del sistema. Valuti l'esecuzione in orari di minore attività o in un ambiente non di produzione con dati aggiornati di recente.
a Query di esempio sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' Passaggi
- Confermi che sia disponibile l'accesso diretto in lettura allo schema SAP HANA contenente EBAN ed EBKN e individui gli oggetti dei documenti di modifica e dei documenti d'acquisto utilizzati nel Suo sistema per le modifiche alle richieste, l'elaborazione dei rilasci, l'assegnazione delle fonti, i riferimenti agli ordini d'acquisto e la chiusura. Poiché questi oggetti e campi possono variare in base alla release e alla configurazione, sostituisca ogni segnaposto tra parentesi quadre nella query con l'oggetto o il campo corrispondente del Suo sistema.
- In SAP GUI, utilizzi la transazione SE16H o uno strumento di amministrazione del database approvato per esaminare EBAN ed EBKN, verificare i campi chiave della richiesta e confermare la disponibilità dei campi relativi a data, ora, utente, stato, eliminazione, rilascio, assegnazione contabile e riferimenti ai documenti d'acquisto. Utilizzi SE11 o il dizionario dati SAP per verificare le definizioni dei campi. Non esponga dati di produzione durante i test.
- Individui la fonte dei documenti di modifica configurata per le modifiche alle richieste e agli stati di approvazione. La query prevede una fonte di modifica normalizzata denominata [Your requisition change document source], con campi per numero della richiesta, numero dell'articolo, campo modificato, valore precedente, nuovo valore, data della modifica, ora della modifica e utente. Prima dell'esecuzione, associ questa fonte alle tabelle dei documenti di modifica SAP o alla CDS View pertinente del Suo sistema.
- Individui la fonte di Workflow o di rilascio configurata per l'invio, il ripristino dell'approvazione, l'avvio e il completamento dei passaggi di approvazione, l'approvazione finale e il rifiuto. La query prevede [Your requisition approval event source], con una riga per ogni transizione di stato o rilascio e campi per numero della richiesta, numero dell'articolo, tipo di evento, codice di rilascio o gruppo di approvazione, approvatore, data dell'evento, ora dell'evento e stato. La associ alla persistenza del rilascio o del Workflow utilizzata dalla configurazione S/4HANA.
- Individui le fonti per l'assegnazione delle fonti, il riferimento all'ordine d'acquisto e la chiusura. La query prevede [Your requisition source assignment source], [Your requisition purchase order reference source] e [Your requisition closure source]. Associ questi segnaposto alle tabelle o alle viste approvate del Suo sistema. La creazione dell'ordine d'acquisto deve essere rappresentata da un riferimento esplicito dall'articolo dell'ordine d'acquisto all'articolo della richiesta, non dedotta da attività d'acquisto non correlate.
- Imposti la finestra di estrazione utilizzando [Start date] e [End date]. Per la prima esecuzione si consiglia un intervallo compreso tra tre e sei mesi. Utilizzi un intervallo più ampio solo dopo aver verificato le prestazioni del database e il volume degli eventi. La query filtra le date di creazione e degli eventi, mantenendo l'identificativo della richiesta come identificativo del caso.
- Esegua la query in un client SQL approvato e collegato a SAP HANA. Sostituisca esclusivamente i dettagli di connessione esterni alla query, i parametri di data, i filtri specifici dell'azienda e i segnaposto di fonti e campi esplicitamente documentati. Mantenga esattamente i nomi delle colonne di output: PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount e RequisitionStatus.
- Esamini gli eventi duplicati, la precisione dei timestamp, la gestione del fuso orario e il livello di granularità per articolo rispetto a documento. La query produce identificativi del caso a livello di documento e include internamente il contesto dell'articolo. Se più articoli generano la stessa attività con lo stesso timestamp, mantenga righe separate, salvo che il design di ProcessMind non richieda esplicitamente la deduplicazione.
- Verifichi che ogni attività richiesta sia presente come valore di ActivityName, che EventTime sia valorizzato e cronologicamente plausibile e che l'identificativo del caso richiesto non sia nullo. Riconcili i conteggi con i report SAP o con estrazioni operative approvate per lo stesso intervallo di date.
- Esporti il risultato come CSV UTF-8 o in un altro formato tabellare supportato da ProcessMind. Includa una riga di intestazione, mantenga timestamp compatibili con lo standard ISO, conservi i valori nulli come celle vuote e carichi il file utilizzando PurchaseRequisitionId come identificativo del caso, ActivityName come colonna dell'attività ed EventTime come colonna del timestamp.
Configurazione
- Identificativo del caso: utilizzi il numero del documento della richiesta d'acquisto proveniente da EBAN, rappresentato da PurchaseRequisitionId. Se il processo è configurato a livello di articolo, utilizzi invece una chiave composita documentata, ad esempio numero della richiesta e numero dell'articolo, applicando la stessa chiave a ogni evento.
- Fonte principale: EBAN viene utilizzata per i dati degli articoli della richiesta. EBKN viene utilizzata per l'assegnazione contabile e per l'arricchimento con reparto o centro di costo. Confermi i nomi esatti e i tipi di dati dei campi nel dizionario dati SAP prima dell'esecuzione.
- Fonti degli eventi: la query utilizza deliberatamente segnaposto professionali per le fonti di modifica, approvazione, assegnazione delle fonti, riferimento all'ordine d'acquisto e chiusura, poiché tali fonti dipendono dalla release di S/4HANA, dal design del Workflow, dalla procedura di rilascio, dalle business function attivate e dalle estensioni del cliente.
- Intervallo di date: inizi con un periodo compreso tra tre e sei mesi. Quando possibile, utilizzi un intervallo delimitato su campi data indicizzati o che consentono il partition pruning. Per i caricamenti incrementali, sovrapponga sufficientemente le finestre di estrazione per acquisire le modifiche arrivate in ritardo, quindi deduplichi utilizzando la combinazione di caso, attività, timestamp, articolo e chiave dell'evento di origine.
- Filtri aziendali: configuri [Company code filter], [Document type filter], [Purchasing group filter] e [Plant filter] solo quando questi campi sono disponibili e il loro significato aziendale è stato confermato. Eviti di filtrare per stato quando l'obiettivo è acquisire l'intero ciclo di vita.
- Mappatura degli stati: configuri i valori per In Approval, final approved, rejected, reset, pending release code e closed in base alla strategia di rilascio o alla configurazione del Workflow del sistema di destinazione. Non presuma che un codice di stato sia universale tra diversi client SAP.
- Mappatura delle modifiche: includa le modifiche a quantità, prezzo, materiale, data di consegna, assegnazione contabile e agli altri campi definiti come chiave per il processo. La query include predicati espliciti per i campi chiave elencati e richiede che la fonte esponga il nome del campo modificato.
- Gestione dei timestamp: combini la data e l'ora dell'evento nel fuso orario del database, documentando quindi l'eventuale conversione in UTC. Se una fonte memorizza solo la data, utilizzi la mezzanotte esclusivamente quando non è disponibile un timestamp più preciso e registri tale limitazione.
- Prestazioni: limiti l'estrazione iniziale per data e ambito aziendale, selezioni solo le colonne necessarie, eviti join senza restrizioni con cronologie estese di modifiche o Workflow e verifichi il piano di esecuzione HANA. Se sono necessarie estrazioni ripetute, materializzi o prepari in staging le fonti di eventi normalizzate.
- Autorizzazioni e prerequisiti: ottenga l'autorizzazione in lettura per EBAN, EBKN, le fonti di modifica e Workflow configurate, i dati di assegnazione delle fonti, i dati di riferimento degli ordini d'acquisto e i dati di chiusura. Confermi che l'accesso diretto al database sia approvato, che le funzionalità di acquisto e Workflow pertinenti siano attive e che siano disponibili eventuali licenze del database SAP HANA o strumenti di amministrazione necessari.
- Sicurezza: applichi il principio del privilegio minimo, protegga gli identificativi degli utenti e degli approvatori e segua le regole aziendali per l'estrazione di informazioni sugli acquisti e finanziarie.
a Query di esempio sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; Pronto per iniziare?
Utilizzi questo Template per preparare i Suoi dati con sicurezza e sfruttare appieno il potenziale del Process Mining per il processo Purchase to Pay - Requisition. Inizi oggi stesso a ottimizzare l'efficienza.
Fermi i ritardi nelle richieste P2P: ottimizzi subito il Suo Workflow.
Renda più efficienti i processi, riduca i tempi di attraversamento e diminuisca del 30% il tempo di ciclo.
Non è richiesta alcuna carta di credito; la configurazione richiede 5 minuti.