Il Suo Template dati Purchase to Pay - Richiesta
Il Suo Template dati Purchase to Pay - Richiesta
- Attributi consigliati da raccogliere per un'analisi completa
- Attività e tappe fondamentali del processo da monitorare
- Indicazioni dettagliate per estrarre i dati dal Suo sistema
Purchase to Pay - Requisition: attributi
| Nome | Descrizione | ||
|---|---|---|---|
|
ID della richiesta di acquisto
PurchaseRequisitionId
|
L’identificativo univoco di un documento Purchase Requisition, che funge da identificativo principale del caso per il processo. | ||
|
Descrizione
Il Purchase Requisition ID è la chiave centrale che collega tutte le attività relative a una singola richiesta di beni o servizi. A ogni richiesta creata in SAP Ariba viene assegnato un ID univoco, che rimane invariato per tutto il suo ciclo di vita, dalla creazione e dall’invio fino all’approvazione finale, alla negazione o alla chiusura. Nell’analisi di Process Mining, questo Attributo è fondamentale per correlare i casi. Consente di ricostruire il percorso completo end-to-end di ogni richiesta, calcolare con precisione i tempi di ciclo, identificare le varianti di processo e analizzare i cicli di rilavorazione. Senza questo identificativo sarebbe impossibile distinguere gli eventi appartenenti a richieste diverse.
Perché è importante
È l’identificativo essenziale del caso che collega tutte le attività correlate, rendendo possibile analizzare il processo end-to-end delle richieste per ogni singola richiesta.
Dove reperirlo
È un campo chiave primario nelle principali tabelle di intestazione delle richieste all’interno della struttura dati di SAP Ariba.
Esempi
PR-102345PR-102346PR-102347
|
|||
|
Nome dell’attività
ActivityName
|
Il nome dello specifico evento di business che si è verificato in un determinato momento del ciclo di vita della richiesta. | ||
|
Descrizione
Il Nome dell’attività descrive una singola fase o milestone del processo delle richieste, come «Requisition Created», «Approval Step Approved» o «Requisition Closed». Questi dati derivano generalmente dagli Event Log, dai cambi di stato o da specifiche azioni degli utenti registrate in SAP Ariba. Questo Attributo è fondamentale per costruire la mappa di processo, che rappresenta visivamente il flusso delle attività. Analizzando la sequenza e la frequenza di tali attività, gli analisti possono individuare i percorsi di processo più comuni, i colli di bottiglia, le deviazioni dalla procedura standard e le aree di rilavorazione. Costituisce la base di ogni analisi di Process Mining.
Perché è importante
Definisce le fasi del processo e consente di visualizzare e analizzare il Workflow delle richieste, inclusi i colli di bottiglia e le deviazioni.
Dove reperirlo
Derivato dagli Event Log, dagli audit trail o dai record dei cambi di stato all’interno di SAP Ariba, spesso associati alle tabelle di intestazione delle richieste e delle righe.
Esempi
Richiesta inviataFase di approvazione approvataRichiesta modificataOrdine di acquisto creato
|
|||
|
Timestamp dell’evento
EventTimestamp
|
La data e l’ora precise in cui si è verificata l’attività, utilizzate come timestamp principale per ordinare gli eventi. | ||
|
Descrizione
Il Timestamp dell’evento registra il momento esatto in cui si è verificata un’attività. Questi dati ad alta precisione sono essenziali per ordinare correttamente gli eventi all’interno di ciascun caso e calcolare la durata tra le diverse fasi del processo. Nell’analisi, questo timestamp costituisce la base di tutti i calcoli temporali, inclusi i tempi di ciclo, i tempi di attesa e le durate di elaborazione. Viene utilizzato per alimentare Dashboard che analizzano le prestazioni, come il Requisition Approval Cycle Time e l’Approval Path Bottleneck Analysis. L’accuratezza di questo campo incide direttamente sull’affidabilità di tutte le metriche delle prestazioni.
Perché è importante
Questo Attributo fornisce l’ordine cronologico degli eventi e costituisce la base per tutti i calcoli delle prestazioni e delle durate, come i tempi di ciclo e i colli di bottiglia.
Dove reperirlo
Si trova generalmente insieme ai record delle attività o dei cambi di stato nelle tabelle dell’audit trail o dei log delle transazioni di SAP Ariba.
Esempi
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
|
|||
|
Categoria dell’articolo
ItemCategory
|
La classificazione dei beni o dei servizi richiesti, come «IT Hardware», «Office Supplies» o «Professional Services». | ||
|
Descrizione
La Categoria articolo fornisce informazioni dettagliate su ciò che viene acquistato. Questa classificazione aiuta a comprendere i modelli di spesa e ad applicare strategie e policy di approvvigionamento specifiche per categoria. Nel Process Mining, questo attributo è fondamentale per la Dashboard «Analisi delle modifiche alle richieste», poiché può evidenziare se determinate categorie di articoli sono più soggette a modifiche, indicando specifiche poco chiare o prezzi variabili. Consente inoltre di confrontare le prestazioni del processo, ad esempio i tempi di approvazione, tra diversi tipi di acquisto, per verificare se alcune categorie incontrano maggiori ostacoli.
Perché è importante
Consente di analizzare il tipo di beni o servizi acquistati, aiutando a individuare colli di bottiglia o problemi di conformità specifici per categoria.
Dove reperirlo
Consulti la documentazione di SAP Ariba. Queste informazioni si trovano generalmente a livello di riga della richiesta.
Esempi
Hardware ITServizi di consulenzaMateriale per ufficioMateriali di marketing
|
|||
|
Importo totale della richiesta
TotalRequisitionAmount
|
Il valore monetario complessivo della Purchase Requisition. | ||
|
Descrizione
Questo Attributo registra il valore finanziario dell’intera richiesta. È un elemento fondamentale del contesto aziendale, utile per classificare e definire le priorità delle richieste. Analizzare le metriche di processo in relazione a questo valore può far emergere schemi importanti. Ad esempio, le richieste di valore elevato possono seguire percorsi di approvazione diversi e più rigorosi oppure avere tempi di ciclo più lunghi. Questo Attributo è essenziale per comprendere l’impatto finanziario delle inefficienze di processo e classificare le richieste in fasce di valore per effettuare analisi comparative.
Perché è importante
Fornisce un contesto finanziario essenziale e consente di analizzare in che modo il valore della richiesta influisce sul comportamento del processo, ad esempio sui tempi di approvazione e sulla complessità del Workflow.
Dove reperirlo
Consulti la documentazione di SAP Ariba. È un campo standard nell’intestazione della Purchase Requisition.
Esempi
1500.0025000.5099.95
|
|||
|
Livello di urgenza
UrgencyLevel
|
Indicatore della priorità della richiesta, ad esempio «Normale», «Urgente» o «Critica». | ||
|
Descrizione
Il Livello di urgenza, spesso rappresentato da un indicatore di priorità, segnala la necessità aziendale di accelerare l'elaborazione. In genere viene impostato dal richiedente per garantire che le esigenze critiche siano gestite tempestivamente. Questo attributo è il principale fattore alla base della Dashboard «Monitoraggio delle richieste urgenti» e del KPI «Tempo di elaborazione delle richieste urgenti». Consente di confrontare direttamente i tempi di ciclo delle richieste urgenti e di quelle standard, verificando l'efficacia della gestione prioritaria. L'analisi di deviazioni o ritardi nelle richieste urgenti è fondamentale per garantire la continuità operativa.
Perché è importante
Consente di dare priorità alle analisi e di verificare se le richieste ad alta priorità vengono elaborate più rapidamente, garantendo la soddisfazione delle esigenze aziendali critiche.
Dove reperirlo
Consulti la documentazione di SAP Ariba. Spesso si tratta di un campo selezionabile nel modulo di creazione della richiesta.
Esempi
AltaMediaBassa
|
|||
|
Motivo del rifiuto
RejectionReason
|
Il motivo indicato da un approvatore quando una richiesta o una fase di approvazione viene rifiutata. | ||
|
Descrizione
Quando una richiesta viene rifiutata, gli approvatori indicano spesso un motivo, inserito come testo libero oppure selezionato da un elenco predefinito. Questo attributo raccoglie tale importante riscontro. Questi dati sono alla base della Dashboard «Analisi del tasso di rifiuto delle richieste». L'analisi dei motivi di rifiuto più frequenti aiuta a individuare le cause principali dei problemi di processo, come codifica errata, motivazioni insufficienti o problemi di budget. Queste informazioni possono quindi essere utilizzate per migliorare la formazione dei richiedenti e la qualità delle richieste iniziali, riducendo le rilavorazioni.
Perché è importante
Fornisce una visione diretta dei motivi per cui le richieste non vanno a buon fine, consentendo di analizzare le cause principali, ridurre le rilavorazioni e migliorare il tasso di correttezza al primo tentativo.
Dove reperirlo
Consulti la documentazione di SAP Ariba. Queste informazioni vengono generalmente registrate nei commenti o nella sezione della cronologia associata a un evento di rifiuto.
Esempi
Conto Co.Ge. erratoBudget superatoMotivazione insufficienteRichiesta duplicata
|
|||
|
Percorso del Workflow di approvazione
ApprovalWorkflowPath
|
La sequenza predefinita di fasi di approvazione che la richiesta dovrebbe seguire. | ||
|
Descrizione
Questo attributo definisce la variante di processo standard o la matrice di approvazione a cui una richiesta deve attenersi in base alle sue caratteristiche, come valore, categoria dell'articolo e reparto. Rappresenta il processo «to-be», ovvero il percorso ideale. È fondamentale per il controllo della conformità e viene utilizzato nella Dashboard «Panoramica della conformità delle richieste». Confrontando la sequenza effettiva delle attività con il Percorso del Workflow di approvazione previsto, gli analisti possono rilevare automaticamente violazioni delle policy, fasi di approvazione non autorizzate o controlli saltati. Si tratta di un elemento essenziale per l'audit interno e la gestione dei rischi.
Perché è importante
Definisce il processo standard da seguire e consente al controllo della conformità di rilevare automaticamente deviazioni e violazioni delle policy.
Dove reperirlo
Consulti la documentazione di SAP Ariba. Può essere ricavato dalla configurazione della matrice di approvazione o da un campo specifico della richiesta.
Esempi
IT standard > 10.000 $Servizi di marketing < 5.000 $CAPEX > 100.000 $
|
|||
|
Reparto del richiedente
RequesterDepartment
|
Il reparto aziendale o centro di costo del dipendente che ha creato la Purchase Requisition. | ||
|
Descrizione
Questo Attributo fornisce il contesto organizzativo identificando la parte dell’azienda che ha avviato la richiesta. Deriva generalmente dal profilo utente del richiedente oppure viene indicato direttamente nel modulo della richiesta. Nell’analisi, costituisce una dimensione efficace per filtrare e confrontare i dati. Viene utilizzato in quasi tutti i Dashboard, come «Requisition Approval Cycle Time» e «Requisition Rejection Rate Analysis», per suddividere le metriche per reparto. In questo modo è possibile individuare i reparti con i tempi di ciclo più lunghi, i tassi di modifica più elevati o il maggior numero di richieste non conformi, indirizzando interventi di miglioramento mirati.
Perché è importante
Consente di segmentare e confrontare le prestazioni del processo tra diverse aree dell’organizzazione, mettendo in evidenza problemi o best practice specifici dei singoli reparti.
Dove reperirlo
Consulti la documentazione di SAP Ariba. Il dato è generalmente disponibile nelle informazioni di intestazione della richiesta, spesso collegato al profilo del richiedente.
Esempi
MarketingOperations ITFinanzaRicerca e sviluppo
|
|||
|
Stato della richiesta
RequisitionStatus
|
Lo stato attuale della richiesta di acquisto nel suo ciclo di vita. | ||
|
Descrizione
Questo attributo riflette lo stato in tempo reale di una richiesta, ad esempio «In composizione», «Inviata», «Approvata», «Rifiutata» o «Chiusa». Fornisce una fotografia della posizione di ogni caso nel processo al momento dell'estrazione dei dati. Sebbene il Process Mining ricostruisca il flusso storico, questo attributo è fondamentale per il monitoraggio operativo. È il principale dato alla base del «Tracker live dello stato delle richieste», che consente ai responsabili di visualizzare il carico di lavoro corrente e individuare le richieste bloccate o in attesa da troppo tempo. Offre una visibilità immediata e operativa sulla pipeline delle richieste attive.
Perché è importante
Consente di monitorare in tempo reale la pipeline delle richieste, aiutando a individuare e gestire le richieste bloccate o in attesa da troppo tempo prima che diventino problematiche.
Dove reperirlo
Consulti la documentazione di SAP Ariba. Si tratta di un campo di stato standard nell'intestazione della richiesta.
Esempi
ApprovataInviataNegataIn fase di approvazione
|
|||
|
Utente dell’evento
EventUser
|
L’ID o il nome dell’utente che ha eseguito l’attività, ad esempio il richiedente o l’approvatore. | ||
|
Descrizione
L’Attributo Utente dell’evento identifica la persona responsabile dell’esecuzione di una specifica fase del processo. Può trattarsi del dipendente che ha inviato la richiesta, del manager che l’ha approvata o dell’addetto agli acquisti che l’ha elaborata. Questo Attributo è essenziale per analizzare il carico di lavoro, confrontare le prestazioni e individuare opportunità di formazione. Alimenta il Dashboard «Approver Workload and Performance», consentendo di analizzare i tempi di approvazione per utente. Viene inoltre utilizzato per indagare le cause di ritardi o deviazioni, riconducendole a persone o team specifici.
Perché è importante
Consente di analizzare la distribuzione del carico di lavoro, le prestazioni degli utenti e l’allocazione delle risorse, aiutando a individuare i colli di bottiglia causati da utenti o team specifici.
Dove reperirlo
Consulti la documentazione di SAP Ariba. Questo dato è spesso memorizzato nelle tabelle dell’audit trail o della cronologia, collegate ai dati anagrafici degli utenti.
Esempi
john.doejane.smithmanager123
|
|||
|
È automatizzato
IsAutomated
|
Indicatore booleano che segnala se un'attività è stata eseguita da un sistema o da un utente. | ||
|
Descrizione
Questo attributo distingue gli eventi di sistema automatizzati, come le approvazioni automatiche o le modifiche di stato generate dal sistema, dalle attività manuali eseguite dagli utenti. È fondamentale per comprendere il livello di automazione del processo. Nelle analisi, aiuta a misurare con precisione l'impegno umano e a individuare ulteriori opportunità di automazione. Ad esempio, filtrare le attività manuali consente di calcolare con precisione i tempi di elaborazione dal punto di vista dell'utente. Aiuta inoltre a verificare che le regole automatizzate funzionino come previsto nel processo.
Perché è importante
Distingue le azioni umane da quelle di sistema, un elemento essenziale per misurare i tassi di automazione e individuare nuove opportunità di automazione.
Dove reperirlo
In genere viene ricavato verificando se l'«Utente dell'evento» corrisponde a un ID utente di sistema o batch.
Esempi
truefalse
|
|||
|
È stata modificata
IsAmended
|
Indicatore booleano che segnala se la richiesta è stata modificata almeno una volta dopo l'invio iniziale. | ||
|
Descrizione
Questo attributo calcolato identifica i casi in cui si è verificata almeno un'attività «Richiesta modificata». Semplifica l'individuazione delle richieste che hanno richiesto modifiche durante il loro ciclo di vita. Questo indicatore viene utilizzato per calcolare il KPI «Tasso di modifica delle richieste». Contando i casi in cui l'indicatore è impostato su true, gli analisti possono misurare facilmente la frequenza delle rilavorazioni e analizzarne le cause principali mettendola in relazione con altri attributi, come «Nome del richiedente» o «Categoria articolo».
Perché è importante
Semplifica il calcolo del KPI relativo al tasso di modifica, aiutando a quantificare le rilavorazioni e a individuare le aree in cui sono necessarie specifiche iniziali più chiare.
Dove reperirlo
Impostato su true se un caso contiene una o più attività «Richiesta modificata» e su false in caso contrario.
Esempi
truefalse
|
|||
|
È una rilavorazione
IsRework
|
Indicatore booleano che segnala se la richiesta ha richiesto una rilavorazione, ad esempio a causa di un rifiuto o di più modifiche. | ||
|
Descrizione
Questo attributo calcolato misura l'inefficienza in modo più ampio rispetto a «IsAmended». Contrassegna i casi che hanno attraversato cicli significativi di rilavorazione, generalmente definiti dalla presenza di uno o più eventi «Fase di approvazione rifiutata» o di più eventi «Richiesta modificata». Questo indicatore viene utilizzato per calcolare il KPI «Tasso di rilavorazione delle richieste». Aiuta a quantificare i costi nascosti e i ritardi associati ai problemi di processo. L'analisi dei casi contrassegnati come rilavorazioni può far emergere schemi ricorrenti legati a determinati approvatori, reparti o tipi di richiesta che generano attriti nel processo.
Perché è importante
Identifica i casi caratterizzati da significativi attriti nel processo, come i rifiuti, consentendo un'analisi mirata delle cause di inefficienza e ritardo.
Dove reperirlo
Impostato su true se un caso contiene un'attività di rifiuto o più di un'attività di modifica.
Esempi
truefalse
|
|||
|
ID dell'ordine di acquisto
PurchaseOrderId
|
L'identificativo dell'ordine di acquisto creato a partire dalla richiesta approvata. | ||
|
Descrizione
Questo attributo collega una richiesta di acquisto al documento successivo del processo, l'ordine di acquisto (PO). La sua presenza indica che la richiesta è stata convertita correttamente in un ordine. È essenziale per l'analisi end-to-end del processo, che si estende oltre la fase della richiesta. Viene utilizzato per calcolare il KPI «Tempo di attraversamento da richiesta a PO», collegando l'evento di creazione della richiesta a quello di creazione del PO. Offre così una visione completa della fase iniziale del ciclo di approvvigionamento.
Perché è importante
Collega la richiesta al successivo ordine di acquisto e consente di misurare il tempo di ciclo end-to-end da richiesta a PO.
Dove reperirlo
Consulti la documentazione di SAP Ariba. In genere viene memorizzato nei dati della riga della richiesta dopo la generazione di un PO.
Esempi
PO-4500012345PO-4500012346PO-4500012347
|
|||
|
Nome del richiedente
RequesterName
|
Il nome del dipendente che ha avviato la richiesta di acquisto. | ||
|
Descrizione
Questo attributo a livello di caso identifica il creatore della richiesta di acquisto. Fornisce il contesto sull'origine della richiesta e sullo stakeholder che l'ha avviata. Nelle analisi, questo attributo viene utilizzato per filtrare il processo e analizzare i comportamenti dei singoli richiedenti. Ad esempio, le Dashboard «Analisi delle modifiche alle richieste» e «Analisi del tasso di rifiuto delle richieste» lo utilizzano per individuare le persone che potrebbero necessitare di ulteriore formazione a causa dell'elevato numero di modifiche o rifiuti. Aiuta a personalizzare il feedback e le iniziative di miglioramento.
Perché è importante
Identifica il creatore della richiesta e consente di analizzare il comportamento e la qualità del processo per singolo richiedente.
Dove reperirlo
Consulti la documentazione di SAP Ariba. È un campo standard nell'intestazione della richiesta, spesso denominato «Creato da» o «Richiedente».
Esempi
Alice WilliamsBob MillerCharles Brown
|
|||
|
Nome dell'approvatore
ApproverName
|
Il nome dell'utente assegnato all'approvazione di una specifica fase del Workflow. | ||
|
Descrizione
Questo attributo identifica il responsabile o stakeholder specifico incaricato di un'attività di approvazione. Si distingue dall'«Utente dell'evento» generico, poiché si riferisce specificamente alle attività di approvazione. È un attributo fondamentale per la Dashboard «Carico di lavoro e prestazioni degli approvatori». Consente di monitorare il numero di richieste gestite da ciascun approvatore e il relativo tempo medio di approvazione. In questo modo è possibile individuare i colli di bottiglia individuali, bilanciare i carichi di lavoro e valutare le prestazioni rispetto agli obiettivi.
Perché è importante
Individua con precisione la persona responsabile di un'approvazione, consentendo un'analisi dettagliata del bilanciamento del carico di lavoro e delle prestazioni degli approvatori.
Dove reperirlo
Consulti la documentazione di SAP Ariba. Queste informazioni sono memorizzate nei dati del flusso di approvazione collegati alla richiesta.
Esempi
Sarah JonesDavid ChenMaria Garcia
|
|||
|
Sistema di origine
SourceSystem
|
Il sistema di riferimento dal quale sono stati estratti i dati. | ||
|
Descrizione
Questo Attributo identifica l’origine dei dati di processo. In questa vista, il valore sarebbe costantemente «SAP Ariba», ma in un contesto più ampio, nel quale i dati potrebbero essere uniti da più sistemi, questo campo è fondamentale per la tracciabilità dei dati e la risoluzione dei problemi. Nell’analisi, aiuta a confermare l’origine dei dati e può essere utilizzato per filtrare o confrontare processi che coinvolgono sistemi diversi. Garantisce chiarezza e affidabilità nella fonte dei dati, aspetti importanti per ottenere il consenso degli stakeholder.
Perché è importante
Identifica l’origine dei dati, elemento fondamentale per la governance dei dati, la risoluzione dei problemi e la corretta comprensione del contesto dell’analisi.
Dove reperirlo
Si tratta generalmente di un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per indicare l’origine del dataset.
Esempi
SAP AribaSAP_ARIBA_P2PAribaCloud
|
|||
|
Ultimo aggiornamento dei dati
LastDataUpdate
|
Il timestamp che indica quando i dati di questo record sono stati aggiornati per l’ultima volta dal sistema di origine. | ||
|
Descrizione
Questo Attributo mostra la data e l’ora dell’estrazione o dell’aggiornamento più recente dei dati relativi a un determinato evento. Offre trasparenza sull’aggiornamento dei dati analizzati, aspetto particolarmente importante per il monitoraggio dei processi in corso. Gli analisti utilizzano queste informazioni per comprendere quanto siano recenti gli insight generati. Per Dashboard come il «Live Requisition Status Tracker», questo campo è fondamentale per informare gli utenti sul livello di aggiornamento delle informazioni visualizzate. Aiuta a gestire le aspettative sulla tempestività dei dati.
Perché è importante
Indica il livello di aggiornamento dei dati, essenziale per comprenderne la tempestività e la rilevanza degli insight di Process Mining.
Dove reperirlo
Questo timestamp viene generalmente generato e aggiunto a ogni record durante il processo di acquisizione dei dati.
Esempi
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
Purchase to Pay - Requisition: attività
| Attività | Descrizione | ||
|---|---|---|---|
|
Ordine di acquisto creato
|
Indica la conversione corretta di una Purchase Requisition approvata in un Purchase Order. Viene registrata tramite la creazione di un documento PO che fa riferimento alla richiesta. | ||
|
Perché è importante
È il principale esito positivo del processo di richiesta. È essenziale per misurare il KPI end-to-end «Requisition to PO Lead Time».
Dove reperirlo
Si tratta di un evento esplicito. Viene utilizzato il timestamp di creazione del documento Purchase Order, che contiene un collegamento o riferimento diretto al Purchase Requisition ID di origine.
Acquisizione
Dalla tabella di intestazione del PO, individui il PO collegato alla richiesta e ne utilizzi il timestamp di creazione.
Tipo di evento
explicit
|
|||
|
Richiesta approvata
|
Indica l’approvazione finale della Purchase Requisition dopo il superamento di tutte le fasi del Workflow. Viene registrata tramite il passaggio dello stato a «Approved». | ||
|
Perché è importante
È una milestone fondamentale che segna la conclusione della fase di approvazione. Costituisce il punto finale per misurare l’«Avg Requisition Approval Time» e indica che la richiesta è pronta per la creazione del PO.
Dove reperirlo
Derivato dalla cronologia del documento Ariba, che registra il passaggio finale dello stato della richiesta a «Approved».
Acquisizione
Individui il timestamp in cui il campo dello stato della richiesta passa a «Approved».
Tipo di evento
inferred
|
|||
|
Richiesta chiusa
|
La chiusura amministrativa finale di una Purchase Requisition dopo il completamento di tutte le attività associate, come l’ordine e la ricezione. Viene registrata tramite il passaggio finale dello stato a «Closed». | ||
|
Perché è importante
Rappresenta la conclusione definitiva dell’intero ciclo di vita della richiesta. Analizzare il tempo che intercorre tra la creazione del PO e la chiusura può far emergere colli di bottiglia nei processi successivi di ricezione o fatturazione.
Dove reperirlo
Derivato dalla cronologia del documento Ariba, che registra il passaggio dello stato della richiesta a «Closed».
Acquisizione
Individui il timestamp in cui il campo dello stato della richiesta passa a «Closed».
Tipo di evento
inferred
|
|||
|
Richiesta creata
|
Indica la creazione iniziale di un documento Purchase Requisition da parte di un utente. Viene registrata quando la richiesta viene salvata per la prima volta nello stato «Composing» o come bozza. | ||
|
Perché è importante
Questo è il punto di partenza del ciclo di vita della richiesta. Analizzare il tempo che intercorre tra la creazione e l’invio consente di misurare l’efficienza degli utenti e individuare le esigenze formative.
Dove reperirlo
Dal timestamp di creazione dell’oggetto Purchase Requisition in SAP Ariba. È disponibile nei dati di intestazione del documento della richiesta e rappresenta un evento di creazione esplicito.
Acquisizione
Utilizzi il timestamp «CreateTime» o l’equivalente dalla tabella di intestazione del documento della richiesta.
Tipo di evento
explicit
|
|||
|
Richiesta inviata
|
Rappresenta l’invio formale della Purchase Requisition nel Workflow di approvazione da parte del richiedente. Viene registrato quando lo stato passa da «Composing» a «Submitted». | ||
|
Perché è importante
È una milestone fondamentale che attiva il processo di approvazione. È essenziale per misurare il «Requisition Approval Cycle Time» e il «Requisition Creation Lead Time».
Dove reperirlo
Derivato dalla cronologia del documento Ariba o dall’audit log, che registra il passaggio dello stato della richiesta a «Submitted» e il timestamp della modifica.
Acquisizione
Individui il timestamp in cui il campo dello stato della richiesta passa per la prima volta a «Submitted».
Tipo di evento
inferred
|
|||
|
Richiesta negata
|
Rappresenta il rifiuto finale di una Purchase Requisition dopo la revisione. È uno stato conclusivo del processo e viene registrato tramite il passaggio dello stato a «Denied». | ||
|
Perché è importante
È un punto finale critico del processo. Analizzare le richieste negate è essenziale per il KPI «Requisition Rejection Rate», così da individuare gli schemi ricorrenti e migliorare la qualità delle richieste.
Dove reperirlo
Derivato dalla cronologia del documento Ariba, che registra il passaggio finale dello stato della richiesta a «Denied».
Acquisizione
Individui il timestamp in cui il campo dello stato della richiesta passa a «Denied».
Tipo di evento
inferred
|
|||
|
Fase di approvazione approvata
|
Rappresenta l’esito positivo di una fase di approvazione, nella quale un approvatore ha approvato la parte di richiesta a lui assegnata. Viene registrato esplicitamente come azione di approvazione. | ||
|
Perché è importante
Misura il tempo di elaborazione dei singoli approvatori. Questi dati sono fondamentali per calcolare l’«Avg Approval Step Duration» e valutare il carico di lavoro degli approvatori.
Dove reperirlo
Dalle tabelle del flusso di approvazione di Ariba. L’evento viene registrato con un timestamp quando un approvatore esegue l’azione «Approve» sull’attività assegnata.
Acquisizione
Utilizzi il timestamp dell’azione «Approve» registrato nella cronologia delle approvazioni per una specifica fase.
Tipo di evento
explicit
|
|||
|
Fase di approvazione avviata
|
Indica che una Purchase Requisition è stata inoltrata a un approvatore o a una coda di approvazione ed è in attesa di un’azione. Viene registrata quando una richiesta di approvazione viene generata e assegnata. | ||
|
Perché è importante
Fornisce una visione dettagliata del Workflow di approvazione. È fondamentale per calcolare i tempi di coda e individuare le fasi specifiche che costituiscono colli di bottiglia per la «Approval Path Bottleneck Analysis».
Dove reperirlo
Dalle tabelle del flusso di approvazione di Ariba, che registrano la creazione e l’assegnazione delle singole attività di approvazione collegate alla richiesta.
Acquisizione
Utilizzi il timestamp di creazione del record della richiesta di approvazione associato alla richiesta e alla specifica fase di approvazione.
Tipo di evento
explicit
|
|||
|
Fase di approvazione rifiutata
|
Rappresenta l’esito negativo di una fase di approvazione, nella quale un approvatore ha rifiutato la richiesta, generalmente rinviandola per una modifica. Viene registrato esplicitamente come azione «Deny». | ||
|
Perché è importante
Evidenzia una causa importante di rilavorazioni e ritardi di processo. Analizzare questi eventi è fondamentale per comprendere il «Requisition Rework Rate» e le ragioni dei rifiuti.
Dove reperirlo
Dalle tabelle del flusso di approvazione di Ariba. L’evento viene registrato con un timestamp quando un approvatore esegue l’azione «Deny» o «Reject» sull’attività assegnata.
Acquisizione
Utilizzi il timestamp dell’azione «Deny» registrato nella cronologia delle approvazioni per una specifica fase.
Tipo di evento
explicit
|
|||
|
Richiesta inviata al sourcing
|
Si verifica quando una richiesta approvata viene inoltrata al reparto sourcing per avviare un evento di sourcing, come una RFQ, prima della creazione di un PO. Viene registrata tramite un cambio di stato, ad esempio a «Sourcing». | ||
|
Perché è importante
Identifica un passaggio importante del processo per gli articoli di valore elevato o non standard. Aiuta ad analizzare il contributo del reparto sourcing al lead time.
Dove reperirlo
Derivato dal passaggio dello stato della richiesta a un valore che indica l’invio al sourcing. È una situazione comune in Ariba Buying integrato con Ariba Sourcing.
Acquisizione
Individui il timestamp in cui il campo dello stato della richiesta passa a «Sourcing» o a uno stato personalizzato analogo.
Tipo di evento
inferred
|
|||
|
Richiesta modificata
|
Si verifica quando un utente modifica una Purchase Requisition dopo il suo invio, spesso in seguito a un rifiuto o a una richiesta di chiarimento. Viene registrato quando il documento viene modificato e inviato nuovamente. | ||
|
Perché è importante
Tiene traccia delle rilavorazioni e delle inefficienze di processo. Un’elevata frequenza di modifiche suggerisce requisiti o policy iniziali poco chiari e incide sul KPI «Requisition Amendment Rate».
Dove reperirlo
Derivato dai dati di versioning di Ariba. Ogni modifica crea una nuova versione del documento della richiesta. La creazione di una versione superiore a 1 indica una modifica.
Acquisizione
Verifichi la creazione di nuove versioni della richiesta dopo lo stato iniziale «Submitted». Il timestamp della nuova versione rappresenta l’ora dell’evento.
Tipo di evento
inferred
|
|||
|
Richiesta ritirata
|
Si verifica quando il richiedente originale annulla una Purchase Requisition inviata prima che sia stata approvata completamente. Viene registrato tramite il passaggio dello stato a «Withdrawn» o «Canceled». | ||
|
Perché è importante
Rappresenta la conclusione del processo avviata dall’utente. Analizzare le ragioni per cui le richieste vengono ritirate può far emergere problemi legati a esigenze aziendali mutevoli o a tempi di approvazione troppo lunghi.
Dove reperirlo
Derivato dalla cronologia del documento Ariba o dall’audit log, che registra il passaggio dello stato della richiesta a «Withdrawn».
Acquisizione
Individui il timestamp in cui il campo dello stato della richiesta passa a «Withdrawn».
Tipo di evento
inferred
|
|||
|
Riga della richiesta ordinata
|
Rappresenta il passaggio dello stato di una singola riga della richiesta a «Ordered» dopo che è stata inserita in un Purchase Order. Offre un livello di dettaglio maggiore rispetto alla sola creazione del PO a livello di intestazione. | ||
|
Perché è importante
Consente di analizzare gli ordini parziali o i ritardi a livello di riga, che non sono visibili osservando soltanto l’intestazione. È utile per le richieste con numerose righe soddisfatte da PO diversi.
Dove reperirlo
Derivato dal passaggio dello stato dell’oggetto riga della richiesta. Lo stato della riga viene aggiornato a «Ordered» quando viene generato un PO per quella riga.
Acquisizione
Individui il timestamp in cui il campo dello stato della riga della richiesta passa a «Ordered».
Tipo di evento
inferred
|
|||
Guide all'estrazione
Pronto a iniziare?
Utilizzi questo Template per semplificare la preparazione dei dati e ottenere informazioni preziose sul processo Purchase to Pay - Richiesta. Inizi oggi stesso a ottimizzare le Sue attività.
Basta ritardi: ottimizzi il processo Purchase to Pay delle richieste
Individui le inefficienze di SAP Ariba e riduca il tempo di ciclo del 30%.
Non è richiesta alcuna carta di credito; la configurazione è rapida e semplice.