Il Suo template per i dati delle richieste Purchase to Pay

Il Purchase Requisition ID è la chiave primaria che identifica univocamente ogni richiesta di beni o servizi in SAP S/4HANA. Funge da identificativo centrale del caso (Case ID), collegando tutte le attività e le modifiche relative a una specifica richiesta, dalla sua creazione fino allo stato finale (approvazione, rifiuto o conversione in ordine d'acquisto).

Nel Process Mining, questo attributo è essenziale per ricostruire il ciclo di vita end-to-end di ogni richiesta. Raggruppando tutti gli eventi correlati sotto un unico ID, gli analisti possono misurare con precisione i tempi di ciclo, tracciare i cambi di stato e analizzare i diversi percorsi che una richiesta può intraprendere durante l'approvazione.

È l'identificativo del caso essenziale che collega tutti i passaggi del processo, consentendo una visione completa e coerente del ciclo di vita della richiesta.

Questo attributo è il numero della richiesta d'acquisto, che si trova nella tabella EBAN, campo BANFN.

L'Activity Name descrive un evento o un task specifico avvenuto durante il ciclo di vita di una richiesta d'acquisto. Queste attività derivano dai log di sistema, come i documenti di modifica e lo storico dei workflow, e rappresentano milestone chiave come 'Requisition Created', 'Approval Step Started' o 'Purchase Order Created'.

L'analisi di queste attività permette di visualizzare il flusso del processo, identificare i colli di bottiglia e misurare il tempo trascorso nelle diverse fasi. Comprendere la sequenza e la frequenza di attività come 'Requisition Amended' o 'Requisition Rejected' è fondamentale per individuare inefficienze e aree di miglioramento.

Definisce le fasi del processo, costituendo la spina dorsale della mappa di processo e consentendo l'analisi dei flussi, delle varianti e dei colli di bottiglia.

Si tratta di un attributo derivato, solitamente costruito interpretando i dati delle tabelle dei documenti di modifica (CDHDR, CDPOS) e dei log di workflow (es. SWWLOGHIST).

Event Time è il timestamp che registra quando si è verificata un'attività. Questo dato è fondamentale per l'ordinamento cronologico degli eventi all'interno di un caso ed è la base per tutti i calcoli di durata e performance nel Process Mining. Ad esempio, la differenza temporale tra gli eventi 'Richiesta sottomessa' e 'Richiesta approvata' determina il tempo del ciclo di approvazione.

Timestamp accurati sono essenziali per analizzare le prestazioni del processo, identificare i ritardi e monitorare il rispetto degli SLA. Questo attributo alimenta le Dashboard che visualizzano i tempi di ciclo, tracciano le richieste bloccate e confrontano le performance in periodi diversi.

Questo timestamp è essenziale per ordinare gli eventi, calcolare i tempi di ciclo e analizzare le prestazioni del processo e i colli di bottiglia.

I timestamp sono solitamente estratti dalle testate dei documenti di modifica (CDHDR-UDATE, CDHDR-UTIME) o dai log degli eventi di workflow.

L'attributo Department, spesso rappresentato dal centro di costo in SAP, identifica l'unità aziendale responsabile dell'acquisto richiesto. Si tratta di un'informazione finanziaria e organizzativa cruciale assegnata a livello di singola voce della richiesta.

Nel Process Mining, questo attributo è essenziale per l'analisi delle performance dipartimentali. Consente di creare dashboard che confrontano metriche chiave come tempi di ciclo, tassi di modifica e tassi di rifiuto tra i vari dipartimenti. Ciò aiuta a identificare i dipartimenti più efficienti, le cui pratiche potrebbero essere adottate altrove, o quelli che potrebbero necessitare di formazione o supporto aggiuntivo.

Consente il confronto delle prestazioni tra diverse business unit, evidenziando variazioni nei tempi di ciclo o nei tassi di rigetto per identificare best practice e aree di miglioramento.

Si tratta del centro di costo, solitamente reperibile nella tabella di imputazione EBKN, campo KOSTL.

L'Approver ID identifica in modo specifico l'utente che ha completato un'attività di approvazione o rifiuto. Si distingue dal generico User ID poiché si focalizza esclusivamente sui decisori all'interno del workflow. Acquisire queste informazioni è vitale per analizzare il processo di approvazione nel dettaglio.

Questo attributo permette di analizzare il comportamento dei responsabili, identificando ad esempio manager con tempi di approvazione lunghi o che rifiutano frequentemente le richieste. È fondamentale per monitorare i tempi di ciclo delle fasi di approvazione e analizzare i colli di bottiglia, aiutando a individuare singoli individui o ruoli che potrebbero causare rallentamenti.

Individua lo specifico decisore in una fase di approvazione, consentendo un'analisi dettagliata dei tempi del ciclo di approvazione e dei bottleneck per individuo o ruolo.

Queste informazioni vengono solitamente estratte dalle tabelle SAP Business Workflow come SWW_WI2OBJ e SWWLOGHIST, che collegano i work item all'utente che li ha completati.

Lo User ID identifica l'utente (persona o sistema) responsabile di un evento nel ciclo di vita della richiesta. Può trattarsi di chi ha creato la richiesta, del manager che l'ha approvata o di chi l'ha modificata. Per i passaggi automatizzati, potrebbe essere un ID utente di sistema o batch.

L'analisi per User ID aiuta a comprendere i comportamenti dei singoli utenti, la distribuzione del carico di lavoro e le performance. È fondamentale per identificare esigenze di formazione, riconoscere i dipendenti più efficienti e garantire la responsabilità nel processo. Supporta inoltre l'analisi delle performance dipartimentali se combinato con i dati anagrafici utente.

Consente l'analisi delle performance degli utenti, della distribuzione del carico di lavoro e della conformità del processo. È fondamentale per identificare esigenze di formazione e colli di bottiglia nelle risorse.

Si trova in EBAN-ERNAM per il creatore. Per le modifiche successive, è in CDHDR-USERNAME. Per le approvazioni, si trova nei log del workflow.

L'importo della richiesta (Requisition Amount) rappresenta il costo totale stimato dei beni o servizi richiesti. Questo valore è spesso un fattore chiave nel determinare la complessità e la durata del workflow, poiché le richieste di valore più elevato richiedono tipicamente più livelli di approvazione.

L'analisi di questo attributo permette di segmentare il processo in base al valore. Aiuta a rispondere a domande come: 'Le richieste di valore elevato richiedono più tempo per l'approvazione?' o 'Qual è il valore delle richieste che vengono rifiutate più spesso?'. È una dimensione critica per comprendere l'impatto finanziario delle inefficienze di processo.

Aiuta a segmentare il processo in base all'impatto finanziario, che spesso correla con la complessità dell'approvazione e i tempi di ciclo. Fondamentale per analisi basate sul valore.

Il valore totale si trova nella tabella EBAN, campo GFWERT. Il valore a livello di voce è in EBAN-PREIS.

Il Requisition Status indica lo stato attuale della richiesta nel suo ciclo di vita. In SAP, questo è spesso rappresentato dal Release Indicator, che mostra se una richiesta è bloccata, in fase di approvazione, parzialmente approvata o completamente approvata. Lo stato cambia man mano che la richiesta avanza nel workflow.

Tracciare lo stato nel tempo è fondamentale per comprendere il flusso. Aiuta a identificare dove e per quanto tempo le richieste si fermano. L'analisi delle transizioni tra gli stati consente una visione dettagliata del processo di approvazione e delle sue varianti.

Indica lo stato attuale di una richiesta, fondamentale per monitorare l'avanzamento, identificare i colli di bottiglia e analizzare il flusso del processo.

Lo stato di rilascio è spesso determinato dal Release Indicator, che si trova nella tabella EBAN, campo FRGZU.

Il Requisition Type (o tipo documento in SAP) è un campo di configurazione chiave che categorizza le richieste d'acquisto. Tipi diversi possono attivare workflow di approvazione differenti, avere impostazioni diverse e servire a scopi aziendali distinti, come articoli a magazzino, servizi esterni o acquisto di asset.

Analizzando il processo in base al tipo di richiesta, le organizzazioni possono capire come vengono gestite le diverse categorie. Ciò permette di confrontare performance, tempi di ciclo e percorsi di approvazione, rivelando quali tipi di richiesta siano più o meno efficienti e aiutando a calibrare i miglioramenti del processo.

Categorizza le richieste per abilitare analisi comparative, aiutando a capire se diversi tipi di ordini hanno flussi, bottleneck o tempi di ciclo differenti.

È il campo del tipo documento, che si trova nella tabella EBAN, campo BSART.

La Required By Date (o data di consegna in SAP) specifica quando i beni o i servizi sono necessari. Questa data è 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 di approvazione finale o di creazione dell'ordine, l'azienda può misurare la propria capacità di soddisfare i livelli di servizio interni. L'analisi delle richieste che mancano questa scadenza può evidenziare ritardi sistemici nel processo di acquisto.

Definisce la data di completamento target per una richiesta, consentendo la misurazione della puntualità e del rispetto dei livelli di servizio interni (SLA).

È la data di consegna, reperibile a livello di singola voce nella tabella EBAN, campo LFDAT.

L'attributo Is Automated è un flag booleano impostato su true se l'attività è stata eseguita da un utente di sistema o batch, come 'WF-BATCH' per le azioni di workflow. Questo aiuta a distinguere tra passaggi manuali e automatizzati nel processo.

Questo attributo è essenziale per misurare il livello di automazione nel processo di richiesta e per calcolare il KPI 'Tasso di approvazione automatizzata'. Filtrando per passaggi automatici o manuali, gli analisti possono confrontarne l'efficienza e identificare opportunità per un'ulteriore automazione, al fine di ridurre i tempi di elaborazione e lo sforzo manuale.

Distingue tra attività umane e attività guidate dal sistema, elemento chiave per misurare i tassi di automazione e identificare opportunità per automatizzare compiti manuali.

È un attributo derivato, solitamente basato su una regola che verifica se lo User ID appartiene a un elenco di utenti di sistema o batch noti.

Is Rework è un flag booleano calcolato che identifica le attività che rappresentano un lavoro ripetitivo o senza valore aggiunto. Un esempio comune in questo processo è l'attività 'Richiesta modificata' che avviene dopo che la richiesta è già stata sottomessa per l'approvazione, costringendo il processo a ripartire.

Questo attributo è fondamentale per quantificare la quantità di rework nel processo e il suo impatto sui tempi di ciclo totali. La dashboard specifica sul tasso di modifica e rework si affida a questo flag per evidenziare le inefficienze. Ridurre il rework è spesso l'obiettivo primario dei progetti di miglioramento dei processi poiché si traduce direttamente in risparmio di tempo e fatica.

Contrassegna le attività che rappresentano sforzi sprecati o ripetizioni, consentendo la misurazione diretta del rework e del suo impatto sull'efficienza del processo.

Si tratta di un attributo calcolato. La logica solitamente contrassegna come rilavorazione qualsiasi attività 'Requisition Amended' che avvenga dopo la prima attività 'Requisition Submitted For Approval'.

L'Urgency Level indica la priorità della richiesta d'acquisto. Sebbene non sia un campo standard dedicato, alcune organizzazioni utilizzano campi come il Numero di tracciamento del requisito per acquisire questa informazione. Ciò consente ai richiedenti di segnalare necessità critiche che richiedono un'elaborazione accelerata.

Analizzare l'impatto dell'urgenza è importante per valutare se il processo dia effettivamente priorità alle richieste critiche. La dashboard di analisi dell'impatto dell'urgenza usa questo attributo per confrontare tempi di ciclo e tassi di approvazione tra richieste urgenti e standard, verificando se la gestione delle priorità funzioni come previsto.

Consente di analizzare come le performance del processo differiscano per le richieste ad alta priorità, aiutando a verificare se gli ordini urgenti siano effettivamente gestiti in modo accelerato.

Non esiste un campo standard per l'urgenza. Alcune aziende utilizzano il Requirement Tracking Number (EBAN-BEDAR) a questo scopo. Potrebbe anche essere un campo personalizzato.

La Rejection Reason spiega perché un approvatore ha deciso di respingere una richiesta. Le ragioni possono includere il superamento del budget, informazioni errate, non conformità alle policy o la duplicazione di un'altra richiesta. Queste informazioni offrono un contesto cruciale per comprendere i fallimenti del processo.

L'analisi dei motivi di rifiuto aiuta a identificare le cause profonde delle inefficienze e delle rilavorazioni. Se, ad esempio, 'Centro di costo errato' è un motivo comune, ciò indica la necessità di una migliore formazione degli utenti o di validazioni di sistema. Questo attributo è il perno della dashboard di analisi dei rifiuti ed è vitale per il miglioramento mirato dei processi.

Fornisce la causa principale dei fallimenti del processo, permettendo miglioramenti mirati per ridurre il rework e aumentare il tasso di richieste corrette al primo colpo (first-time-right).

Spesso non è un campo standard. Può essere acquisito negli elementi container del workflow, nei testi lunghi associati alla richiesta o in campi personalizzati.

L'Approval Step Name fornisce una descrizione leggibile di una specifica fase del workflow di approvazione, ad esempio 'Approvazione Manager' o 'Approvazione VP Finance'. Risulta molto più utile di una generica attività 'Fase di approvazione completata'.

Questo attributo è fondamentale per le dashboard relative ai tempi di ciclo delle fasi di approvazione e all'analisi dei colli di bottiglia nel workflow. Consente una visione granulare, rendendo possibile individuare esattamente quali fasi stiano causando i ritardi maggiori e dove si stia accumulando il lavoro. Tale livello di dettaglio è necessario per interventi mirati a snellire la catena approvativa.

Fornisce dettagli granulari sulle fasi di approvazione, consentendo l'identificazione precisa dei colli di bottiglia all'interno del workflow multi-livello.

Questa informazione deriva dalla descrizione del task di workflow, reperibile collegando il log del workflow alle tabelle di definizione dei task come T528T.

Il Purchase Order Number è l'identificativo del documento d'acquisto ufficiale creato da una richiesta approvata. La creazione di un ordine d'acquisto è spesso l'esito finale positivo per una richiesta, a indicare che il fabbisogno è stato convertito in un ordine formale a un fornitore.

Questo attributo è fondamentale per misurare il KPI 'Lead Time dalla richiesta all'ordine' e il tasso di conversione complessivo. Collega il processo di richiesta con il processo di acquisto a valle, offrendo una visione end-to-end dell'intero ciclo Procure-to-Pay.

Collega la richiesta al documento di acquisto successivo, permettendo di misurare il tasso di conversione richiesta-ordine e il lead time.

Si trova nella tabella EBAN, campo EBELN, una volta creato un ordine d'acquisto (PO) dall'item della richiesta.

EndTime è il timestamp che registra quando un'attività è stata terminata. Mentre molti eventi generati dal sistema sono istantanei (StartTime coincide con EndTime), i task umani come le approvazioni possono avere un inizio e una fine distinti. Questo timestamp segna il completamento di quel lavoro.

Disporre di un EndTime separato permette una misurazione più accurata del tempo di elaborazione attivo 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 per i task manuali.

Segna il completamento di un'attività, consentendo il calcolo del tempo di elaborazione attivo e fornendo una visione più dettagliata della durata dei task.

Questo dato è derivato dai log di workflow che possono registrare sia la creazione del work item (StartTime) sia il suo completamento (EndTime).

L'attributo Source System indica il sistema d'origine in cui sono stati generati i dati del processo. Nelle organizzazioni con più istanze SAP (es. sistemi diversi per sviluppo, QA e produzione, o sistemi separati per regioni diverse), questo campo è fondamentale per la governance e il contesto dei dati.

Assicura che i dati provenienti da fonti diverse siano distinguibili, evitando aggregazioni errate e consentendo analisi specifiche per sistema. È un attributo obbligatorio per mantenere la lineage dei dati e garantire la tracciabilità del processo.

Fornisce il contesto essenziale sull'origine e la governance dei dati, specialmente in scenari con più sistemi, garantendo la tracciabilità.

In genere è il SAP System ID (SID), che può essere recuperato dalle variabili di sistema o dalle tabelle di configurazione.

Processing Time misura il tempo impiegato per completare una singola attività. Viene calcolato come differenza tra l'ora di fine e l'ora di inizio di un evento. Per molti eventi in SAP, i tempi di inizio e fine coincidono, risultando in un tempo di elaborazione pari a zero. Tuttavia, per le fasi di approvazione, può rappresentare il tempo che un approvatore ha dedicato effettivamente al task.

Questa metrica è utile per comprendere lo sforzo richiesto nei diversi passaggi del processo. Aiuta a distinguere tra il tempo in cui un caso è in attesa (wait time) e il tempo in cui viene lavorato attivamente (processing time), offrendo una visione più sfumata delle performance.

Misura il tempo di lavoro attivo per un'attività, aiutando a distinguere tra il tempo speso lavorando e quello speso in attesa, elemento chiave per l'analisi delle risorse.

Si tratta di un attributo calcolato, derivato solitamente come differenza tra EndTime e StartTime per ogni evento nell'event log.

Questo attributo registra la data e l'ora dell'ultima estrazione o aggiornamento dei dati dal sistema d'origine. È un metadato critico per comprendere quanto siano aggiornati i dati analizzati. Analisti e utenti aziendali si affidano a questo timestamp per sapere se i dati di processo riflettono lo stato attuale delle operazioni.

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 siano tratte da dati aggiornati secondo le necessità dell'analisi specifica.

Indica l'aggiornamento dei dati, fondamentale per l'affidabilità dell'analisi e per prendere decisioni di business tempestive.

Questo timestamp viene generato e aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL).

Questo attributo specifica la valuta dell'importo della richiesta (es. USD, EUR o JPY). Fornisce il contesto necessario per l'attributo Requisition Amount, specialmente nelle multinazionali che operano con più valute.

Per un'analisi finanziaria e una reportistica accurata, è essenziale considerare la valuta. Quando si aggregano o si confrontano i valori delle richieste, tutti gli importi dovrebbero essere convertiti in una valuta comune per garantire risultati significativi. Questo attributo è un prerequisito per tali conversioni.

Fornisce il contesto essenziale per l'importo della richiesta, abilitando analisi finanziarie accurate e confronti in ambienti multi-valuta.

Si trova nella tabella EBAN, campo WAERS.