Ihr Daten-Template für Purchase to Pay, Bestellanforderungen

SAP S/4HANA
Ihr Daten-Template für Purchase to Pay, Bestellanforderungen

Ihr Daten-Template für Purchase to Pay, Bestellanforderungen

Dieses Template bietet eine umfassende Anleitung zur Erfassung der erforderlichen Daten für die Analyse Ihres Purchase-to-Pay-Prozesses für Bestellanforderungen. Es beschreibt die wesentlichen Attribute und Aktivitäten, die Sie erfassen sollten, sowie praktische Hinweise zur Extraktion aus SAP S/4HANA. Verwenden Sie diese Ressource, um ein zuverlässiges Event Log für aussagekräftiges Process Mining aufzubauen.
  • Empfohlene Attribute für eine detaillierte Analyse
  • Wichtige Aktivitäten für die Prozesserkennung
  • Hinweise zur Datenextraktion aus SAP S/4HANA
Neu bei Event Logs? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Purchase to Pay, Attribute der Bestellanforderung

Dies sind die empfohlenen Datenfelder, die Sie für eine umfassende Analyse von Purchase to Pay und Bestellanforderungen in Ihr Event Log aufnehmen sollten.
3 Erforderlich 6 Empfohlen 11 Optional
Name Beschreibung
Aktivitätsname
ActivityName
Der Name der Geschäftsaktivität, die zu einem bestimmten Zeitpunkt im Requisitionsprozess stattgefunden hat.
Beschreibung

Der Aktivitätsname beschreibt ein bestimmtes Ereignis oder eine Aufgabe im Lebenszyklus einer Purchase Requisition. Diese Aktivitäten werden aus Systemprotokollen wie Änderungsbelegen und Workflow-Historien abgeleitet und stellen wichtige Prozessmeilensteine dar, etwa „Requisition erstellt“, „Genehmigungsschritt gestartet“ oder „Bestellung erstellt“.

Die Analyse dieser Aktivitäten ermöglicht die Visualisierung des Prozessflusses, die Erkennung von Engpässen und die Messung der in den einzelnen Phasen verbrachten Zeit. Das Verständnis der Abfolge und Häufigkeit von Aktivitäten wie „Requisition geändert“ oder „Requisition abgelehnt“ ist entscheidend, um Ineffizienzen und Verbesserungsmöglichkeiten zu erkennen.

Warum das wichtig ist

Es definiert die Prozessschritte, bildet das Rückgrat der Prozessübersicht und ermöglicht die Analyse von Prozessfluss, Varianten und Engpässen.

Bezugsquelle

Dies ist ein abgeleitetes Attribut, das typischerweise durch die Interpretation von Daten aus Änderungsbelegtabellen (CDHDR, CDPOS) und Workflow-Protokollen, etwa SWWLOGHIST, erstellt wird.

Beispiele
Requisition erstelltGenehmigungsschritt abgeschlossenRequisition genehmigtBestellung erstellt
Ereigniszeit
EventTime
Das genaue Datum und die genaue Uhrzeit, zu denen eine bestimmte Aktivität stattgefunden hat.
Beschreibung

Die Ereigniszeit ist der Timestamp, der erfasst, wann eine Aktivität stattgefunden hat. Diese Daten sind entscheidend für die chronologische Anordnung von Ereignissen innerhalb eines Cases und bilden die Grundlage für sämtliche Berechnungen von Dauer und Leistung im Process Mining. Beispielsweise bestimmt die Zeitdifferenz zwischen den Ereignissen „Requisition eingereicht“ und „Requisition genehmigt“ die Dauer des Genehmigungszyklus.

Präzise Timestamps sind unerlässlich, um die Prozessleistung zu analysieren, Verzögerungen zu erkennen und die Einhaltung von Service-Level-Vereinbarungen zu überwachen. Dieses Attribut ermöglicht Dashboards, die Zykluszeiten visualisieren, blockierte Requisitionen verfolgen und die Leistung über verschiedene Zeiträume vergleichen.

Warum das wichtig ist

Dieser Timestamp ist unerlässlich, um Ereignisse zu ordnen, Zykluszeiten zu berechnen sowie Prozessleistung und Engpässe zu analysieren.

Bezugsquelle

Timestamps stammen typischerweise aus Änderungsbelegköpfen (CDHDR-UDATE, CDHDR-UTIME) oder Workflow-Ereignisprotokollen.

Beispiele
2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z
ID der Purchase Requisition
PurchaseRequisitionId
Die eindeutige Kennung eines Dokuments für eine Purchase Requisition.
Beschreibung

Die ID der Purchase Requisition ist der Primärschlüssel, der jede Anforderung von Waren oder Dienstleistungen in SAP S/4HANA eindeutig identifiziert. Sie dient als zentrale Case-Kennung und verknüpft alle Aktivitäten und Änderungen einer bestimmten Requisition von ihrer Erstellung bis zu ihrem endgültigen Status, etwa Genehmigung, Ablehnung oder Umwandlung in eine Bestellung.

Im Process Mining ist dieses Attribut grundlegend für die Rekonstruktion des durchgängigen Lebenszyklus jeder Requisition. Indem alle zugehörigen Ereignisse unter einer einzigen ID der Purchase Requisition gruppiert werden, können Analysten Zykluszeiten präzise messen, Statusänderungen verfolgen und die verschiedenen Pfade analysieren, die eine Requisition im Genehmigungsprozess durchlaufen kann.

Warum das wichtig ist

Dies ist die zentrale Case-Kennung, die alle zugehörigen Prozessschritte verbindet und eine vollständige, konsistente Sicht auf den Lebenszyklus der Requisition ermöglicht.

Bezugsquelle

Dieses Attribut ist die Nummer der Purchase Requisition aus der Tabelle EBAN, Feld BANFN.

Beispiele
100178901001789110017892
Abteilung
Department
Die Abteilung oder Kostenstelle, der die Kosten der Requisition belastet werden.
Beschreibung

Das Attribut Abteilung, in SAP häufig durch die Kostenstelle abgebildet, identifiziert die Geschäftseinheit, die für den angeforderten Einkauf verantwortlich ist. Es ist eine wichtige finanzielle und organisatorische Information, die auf Positionsebene der Requisition zugewiesen wird.

Im Process Mining ist dieses Attribut für die Analyse der Abteilungsleistung entscheidend. Es ermöglicht Dashboards, die zentrale Kennzahlen wie Zykluszeit, Änderungsquote und Ablehnungsquote zwischen Abteilungen vergleichen. So lassen sich leistungsstarke Abteilungen erkennen, deren Vorgehensweisen übernommen werden können, ebenso wie Abteilungen mit zusätzlichem Schulungs- oder Prozessunterstützungsbedarf.

Warum das wichtig ist

Ermöglicht den Leistungsvergleich zwischen Geschäftseinheiten. Unterschiede bei Zykluszeiten oder Ablehnungsquoten machen Best Practices und Verbesserungsbereiche sichtbar.

Bezugsquelle

Dies ist die Kostenstelle, die typischerweise in der Kontierungsstammtabelle EBKN, Feld KOSTL, zu finden ist.

Beispiele
FIN-1001IT-2005MKT-3010
Benutzer-ID
UserId
Die Kennung des Benutzers, der die Requisition erstellt oder eine bestimmte Aktivität ausgeführt hat.
Beschreibung

Die Benutzer-ID identifiziert den Mitarbeitenden oder Systembenutzer, der für ein bestimmtes Ereignis im Lebenszyklus der Requisition verantwortlich ist. Dies kann die Person sein, die die Requisition erstellt, die Führungskraft, die sie genehmigt, oder der Bearbeitende, der sie ändert. Bei automatisierten Schritten kann es sich um die ID eines System- oder Batch-Benutzers handeln.

Die Analyse nach Benutzer-ID hilft, benutzerspezifisches Verhalten, die Verteilung der Arbeitslast und die Prozesseinhaltung zu verstehen. Sie ist wichtig, um Schulungsbedarf zu erkennen, besonders leistungsstarke Mitarbeitende zu identifizieren und Verantwortlichkeiten im Prozess sicherzustellen. In Verbindung mit Benutzerdaten unterstützt sie außerdem die Analyse der Abteilungsleistung.

Warum das wichtig ist

Ermöglicht die Analyse von Benutzerleistung, Arbeitslastverteilung und Prozesseinhaltung. Das Attribut ist entscheidend, um Schulungsbedarf und Ressourcenengpässe zu erkennen.

Bezugsquelle

Für den Ersteller in EBAN-ERNAM zu finden. Bei nachfolgenden Änderungen steht die Information in CDHDR-USERNAME, bei Genehmigungen in den Workflow-Protokollen.

Beispiele
JSMITHRROEWF-BATCH
ID des Genehmigenden
ApproverId
Die Kennung des Benutzers, der einen Genehmigungs- oder Ablehnungsschritt ausgeführt hat.
Beschreibung

Die ID des Genehmigenden identifiziert den Benutzer, der eine Genehmigungs- oder Ablehnungsaktivität abgeschlossen hat. Sie unterscheidet sich von der allgemeinen Benutzer-ID, da sie ausschließlich die Entscheidungsträger im Genehmigungs-Workflow erfasst. Diese Information ist für eine detaillierte Analyse des Genehmigungsprozesses unverzichtbar.

Mit diesem Attribut können Sie das Genehmigungsverhalten analysieren, etwa Führungskräfte mit langen Genehmigungszeiten oder Personen, die Requisitionen häufig ablehnen. Es bildet eine wichtige Grundlage für Dashboards zu Zykluszeiten einzelner Genehmigungsschritte und zur Analyse von Workflow-Engpässen. So lassen sich bestimmte Personen oder Rollen identifizieren, die Verzögerungen verursachen können.

Warum das wichtig ist

Identifiziert den konkreten Entscheidungsträger in einem Genehmigungsschritt und ermöglicht eine detaillierte Analyse von Genehmigungszykluszeiten und Engpässen nach Person oder Rolle.

Bezugsquelle

Diese Information wird typischerweise aus Tabellen des SAP Business Workflow wie SWW_WI2OBJ und SWWLOGHIST extrahiert, die Work Items mit dem abschließenden Benutzer verknüpfen.

Beispiele
MJOHNSONCWILLIAMSLBLACK
Requisition-Typ
RequisitionType
Ein Code zur Klassifizierung der Purchase Requisition, etwa für Standardpositionen, Dienstleistungen oder Investitionsausgaben.
Beschreibung

Der Requisition-Typ, in SAP auch als Belegart bezeichnet, ist ein wichtiges Konfigurationsfeld zur Kategorisierung von Purchase Requisitions. Unterschiedliche Typen können verschiedene Genehmigungs-Workflows auslösen, abweichende Feldeinstellungen verwenden und unterschiedlichen Geschäftszwecken dienen, etwa Standardlagerartikeln, externen Dienstleistungen oder Anlagenkäufen.

Durch die Analyse nach Requisition-Typ können Unternehmen nachvollziehen, wie unterschiedliche Anforderungen bearbeitet werden. So lassen sich Leistung, Zykluszeiten und Genehmigungspfade zwischen Kategorien vergleichen. Dadurch wird sichtbar, ob bestimmte Requisition-Typen effizienter oder weniger effizient sind, und Prozessverbesserungen können gezielt angepasst werden.

Warum das wichtig ist

Kategorisiert Requisitionen für vergleichende Analysen und hilft zu verstehen, ob unterschiedliche Anforderungstypen abweichende Prozessflüsse, Engpässe oder Zykluszeiten aufweisen.

Bezugsquelle

Dies ist das Feld für die Belegart in der Tabelle EBAN, Feld BSART.

Beispiele
NBFORV
Requisitionsbetrag
RequisitionAmount
Der gesamte Geldwert der Purchase Requisition.
Beschreibung

Der Requisitionsbetrag entspricht den geschätzten Gesamtkosten der angeforderten Waren oder Dienstleistungen. Dieser Wert beeinflusst häufig die Komplexität und Dauer des Genehmigungs-Workflows, da Requisitionen mit höherem Wert typischerweise mehr Genehmigungsebenen erfordern.

Durch die Analyse dieses Attributs lässt sich der Prozess nach Wert segmentieren. So können Sie Fragen beantworten wie: „Werden Requisitionen mit hohem Wert langsamer genehmigt?“ oder „Welchen Wert haben Requisitionen, die häufig abgelehnt werden?“ Das Attribut ist eine wichtige Dimension, um die finanziellen Auswirkungen von Prozessineffizienzen zu verstehen.

Warum das wichtig ist

Hilft, den Prozess nach finanzieller Auswirkung zu segmentieren, die häufig mit Genehmigungskomplexität und Zykluszeit zusammenhängt. Das Attribut ist für eine wertbasierte Prozessanalyse wesentlich.

Bezugsquelle

Der Gesamtwert steht in der Tabelle EBAN, Feld GFWERT. Der Wert auf Positionsebene befindet sich in EBAN-PREIS.

Beispiele
1500.0075000.50250.75
Requisitionsstatus
RequisitionStatus
Der aktuelle Bearbeitungs- oder Genehmigungsstatus der Purchase Requisition.
Beschreibung

Der Requisitionsstatus zeigt den aktuellen Zustand der Requisition innerhalb ihres Lebenszyklus an. In SAP wird er häufig durch den Freigabeindikator dargestellt. Dieser zeigt, ob eine Requisition gesperrt, in Genehmigung, teilweise genehmigt oder vollständig genehmigt ist. Der Status ändert sich, während die Requisition den Workflow durchläuft.

Die zeitliche Nachverfolgung des Status ist grundlegend für das Verständnis des Prozessflusses. Sie hilft zu erkennen, an welchen Stellen Requisitionen festhängen und wie lange. Die Analyse von Statusübergängen ermöglicht eine detaillierte Sicht auf den Genehmigungsprozess und seine Varianten.

Warum das wichtig ist

Zeigt den aktuellen Zustand einer Requisition an und ist entscheidend, um den Fortschritt zu verfolgen, Engpässe zu erkennen und den Prozessfluss zu analysieren.

Bezugsquelle

Der Freigabestatus wird häufig durch den Freigabeindikator bestimmt, der sich in der Tabelle EBAN, Feld FRGZU, befindet.

Beispiele
B1S
Ablehnungsgrund
RejectionReason
Der bei der Ablehnung einer Bestellanforderung angegebene Grund.
Beschreibung

Die Rejection Reason erklärt, warum ein Genehmiger eine Bestellanforderung abgelehnt hat. Mögliche Gründe sind eine Überschreitung des Budgets, fehlerhafte Angaben, ein Verstoß gegen Richtlinien oder eine Duplizierung einer anderen Anforderung. Diese Information liefert wichtigen Kontext für das Verständnis von Prozessfehlern.

Die Analyse der Ablehnungsgründe hilft dabei, die Ursachen für Ineffizienzen und Nacharbeit zu identifizieren. Ist beispielsweise „Incorrect Cost Center“ ein häufiger Grund, deutet dies auf einen Bedarf an besserer Anwenderschulung oder zusätzlicher Systemvalidierung hin. Dieses Attribut bildet die Grundlage für das Dashboard „Requisition Rejection Analysis“ und ist für gezielte Prozessverbesserungen entscheidend.

Warum das wichtig ist

Liefert die Ursache für Prozessfehler und ermöglicht gezielte Verbesserungen, um Nacharbeit zu reduzieren und die First-Time-Right-Rate von Anforderungen zu erhöhen.

Bezugsquelle

Dies ist häufig kein Standardfeld. Die Information kann in Workflow-Container-Elementen, einem mit der Anforderung verknüpften Langtext oder in kundenspezifischen Feldern erfasst werden.

Beispiele
Budget überschrittenFalscher LieferantDoppelte Anforderung
Benötigt-am-Datum
RequiredByDate
Das Datum, bis zu dem der Anforderer die angeforderten Waren oder Dienstleistungen benötigt.
Beschreibung

Das Required By Date, in SAP als Delivery Date bezeichnet, gibt an, wann die Waren oder Dienstleistungen aus der Anforderungsposition benötigt werden. Dieses Datum wird vom Anforderer festgelegt und dient als Zieltermin für den gesamten Beschaffungsprozess.

Dieses Attribut ist für die Berechnung des KPI „On-Time Requisition Completion Rate“ entscheidend. Durch den Vergleich des Required By Date mit dem Datum der endgültigen Genehmigung oder der Erstellung der Bestellung kann das Unternehmen messen, inwieweit es interne Service Levels und geschäftliche Anforderungen erfüllt. Die Analyse von Anforderungen, bei denen dieses Datum überschritten wird, kann systematische Verzögerungen im Beschaffungsprozess sichtbar machen.

Warum das wichtig ist

Legt den Zieltermin für den Abschluss einer Anforderung fest und ermöglicht die Messung pünktlicher Lieferung sowie der Einhaltung interner Service Levels.

Bezugsquelle

Dies ist das Delivery Date auf Positionsebene in der Tabelle EBAN, Feld LFDAT.

Beispiele
2023-11-152023-12-012024-01-20
Bestellnummer
PurchaseOrderNumber
Die Nummer der Bestellung, die aus der Requisition erstellt wurde.
Beschreibung

Die Bestellnummer ist die Kennung des offiziellen Einkaufsdokuments, das aus einer genehmigten Bedarfsmeldung erstellt wird. Die Erstellung einer Bestellung ist häufig das erfolgreiche Endergebnis einer Bedarfsmeldung. Sie zeigt, dass die Anfrage in eine formelle Bestellung bei einem Lieferanten überführt wurde.

Dieses Attribut ist entscheidend für die Messung des KPIs zur Durchlaufzeit von der Bedarfsmeldung bis zur Bestellung sowie der gesamten Umwandlungsrate. Es verbindet den Bedarfsmeldungsprozess mit dem nachgelagerten Beschaffungsprozess und ermöglicht eine umfassendere End-to-End-Sicht auf den gesamten Purchase-to-Pay-Zyklus.

Warum das wichtig ist

Verknüpft die Bedarfsmeldung mit dem nachfolgenden Beschaffungsdokument und ermöglicht die Messung der Umwandlungsrate sowie der Durchlaufzeit von der Bedarfsmeldung bis zur Bestellung.

Bezugsquelle

Zu finden in der Tabelle EBAN, Feld EBELN, sobald aus der Position der Bedarfsmeldung eine Bestellung erstellt wurde.

Beispiele
450001789045000178914500017892
Dringlichkeitsstufe
UrgencyLevel
Eine Klassifizierung der Dringlichkeit einer Anforderung, die ihre Bearbeitungspriorität beeinflussen kann.
Beschreibung

Das Urgency Level gibt die Priorität der Bestellanforderung an. Obwohl dafür kein eigenes Standardfeld vorgesehen ist, verwenden manche Unternehmen Felder wie die Requirement Tracking Number, um diese Information zu erfassen. So können Anforderer kritische Bedarfe kennzeichnen, die eine beschleunigte Bearbeitung erfordern.

Die Analyse der Auswirkungen der Dringlichkeit ist wichtig, um zu bewerten, ob der Prozess kritische Anforderungen wirksam priorisiert. Das Dashboard „Urgency Level Impact Analysis“ verwendet dieses Attribut, um Durchlaufzeiten und Genehmigungsraten dringender und standardmäßiger Anforderungen zu vergleichen. So lässt sich feststellen, ob die priorisierte Bearbeitung wie vorgesehen funktioniert.

Warum das wichtig ist

Ermöglicht die Analyse von Leistungsunterschieden bei Anforderungen mit hoher Priorität und hilft zu prüfen, ob dringende Vorgänge tatsächlich beschleunigt werden.

Bezugsquelle

Es gibt kein standardmäßiges Feld für die Dringlichkeit. Manche Unternehmen verwenden dafür die Requirement Tracking Number (EBAN-BEDAR). Alternativ kann ein kundenspezifisches Feld zum Einsatz kommen.

Beispiele
HochMittelNiedrig
Endzeit
EndTime
Das genaue Datum und die genaue Uhrzeit, zu denen eine bestimmte Aktivität abgeschlossen wurde.
Beschreibung

EndTime ist der Timestamp, der den Abschluss einer Aktivität erfasst. Viele systemgenerierte Events erfolgen unmittelbar, sodass StartTime und EndTime identisch sind. Bei manuellen Aufgaben wie Genehmigungen können Start und Ende dagegen auseinanderliegen. Dieser Timestamp markiert den Abschluss der Arbeit.

Ein separates EndTime ermöglicht eine genauere Messung der aktiven Bearbeitungszeit im Vergleich zur Wartezeit. Zusammen mit StartTime wird es zur Berechnung der Kennzahl ProcessingTime verwendet. Diese Detailtiefe verbessert die Analyse der Ressourcennutzung und Effizienz manueller Aufgaben.

Warum das wichtig ist

Kennzeichnet den Abschluss einer Aktivität, ermöglicht die Berechnung der aktiven Bearbeitungszeit und liefert ein detaillierteres Bild der Aufgabendauer.

Bezugsquelle

Dieses Attribut wird aus Workflow-Logs abgeleitet, die sowohl die Erstellung eines Arbeitselements (StartTime) als auch dessen Abschluss (EndTime) erfassen können.

Beispiele
2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z
Ist automatisiert
IsAutomated
Ein Kennzeichen dafür, ob eine Aktivität von einem Systembenutzer statt von einer Person ausgeführt wurde.
Beschreibung

Das Attribut Is Automated ist ein boolesches Kennzeichen. Es ist wahr, wenn eine Aktivität von einem System- oder Batch-Benutzer ausgeführt wurde, beispielsweise „WF-BATCH“ bei Workflow-Aktionen. Dadurch lassen sich manuelle und automatisierte Prozessschritte unterscheiden.

Dieses Attribut ist entscheidend, um den Automatisierungsgrad im Anforderungsprozess zu messen und den KPI „Automated Approval Rate“ zu berechnen. Durch die Filterung nach automatisierten oder manuellen Schritten können Analysten deren Effizienz vergleichen und weitere Automatisierungsmöglichkeiten identifizieren, um Bearbeitungszeiten und manuellen Aufwand zu reduzieren.

Warum das wichtig ist

Unterscheidet zwischen menschlichen und systemgesteuerten Aktivitäten. Das ist entscheidend, um Automatisierungsraten zu messen und Möglichkeiten zur Automatisierung manueller Aufgaben zu erkennen.

Bezugsquelle

Dies ist ein abgeleitetes Attribut. Üblicherweise basiert es auf einer Regel, die prüft, ob die User ID eines Events zu einer Liste bekannter System- oder Batch-Benutzer gehört.

Beispiele
truefalse
Ist Nacharbeit
IsRework
Ein Kennzeichen dafür, ob eine Aktivität Nacharbeit darstellt, beispielsweise eine Änderung nach der Einreichung.
Beschreibung

Is Rework ist ein berechnetes boolesches Kennzeichen. Es identifiziert Aktivitäten, die keinen zusätzlichen Wert schaffen oder wiederholt ausgeführt werden. Ein typisches Beispiel in diesem Prozess ist die Aktivität „Requisition Amended“, nachdem die Anforderung bereits zur Genehmigung eingereicht wurde und der Genehmigungsprozess deshalb neu gestartet werden muss.

Dieses Attribut ist entscheidend, um den Umfang der Nacharbeit und ihre Auswirkungen auf die gesamte Durchlaufzeit zu quantifizieren. Das Dashboard „Requisition Amendment and Rework Rate“ verwendet dieses Kennzeichen, um Ineffizienzen im Prozess sichtbar zu machen. Die Reduzierung von Nacharbeit ist häufig ein zentrales Ziel von Prozessverbesserungen, da sie unmittelbar Zeit und Aufwand spart.

Warum das wichtig ist

Kennzeichnet Aktivitäten, die unnötigen Aufwand oder Wiederholungen darstellen. Dadurch lassen sich Nacharbeit und ihre Auswirkungen auf die Prozesseffizienz direkt messen.

Bezugsquelle

Dies ist ein berechnetes Attribut. Die Logik kennzeichnet üblicherweise jede Aktivität „Requisition Amended“, die nach der ersten Aktivität „Requisition Submitted For Approval“ auftritt, als Nacharbeit.

Beispiele
truefalse
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp, der angibt, wann die Daten dieses Datensatzes zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung

Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder Aktualisierung aus dem Quellsystem. Es ist ein wichtiger Metadatenbestandteil, um die Aktualität der analysierten Daten zu beurteilen. Analysten und Fachanwender können anhand dieses Timestamps erkennen, ob die Prozessdaten den aktuellen Stand der Abläufe abbilden.

Für jede Prozessanalyse ist die Aktualität der Daten eine wesentliche Grundlage für fundierte Entscheidungen. Dieses Attribut hilft, Erwartungen der Benutzer zu steuern und sicherzustellen, dass Schlussfolgerungen auf Daten beruhen, die für die jeweilige Analyse ausreichend aktuell sind.

Warum das wichtig ist

Zeigt die Aktualität der Daten an. Diese ist entscheidend, damit Sie der Analyse vertrauen und rechtzeitig geschäftliche Entscheidungen treffen können.

Bezugsquelle

Dieser Timestamp wird während des ETL-Prozesses für Extraktion, Transformation und Laden erzeugt und hinzugefügt.

Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Name des Genehmigungsschritts
ApprovalStepName
Der konkrete Name oder die Beschreibung eines Genehmigungsschritts im Workflow.
Beschreibung

Der Approval Step Name beschreibt eine bestimmte Phase im Genehmigungs-Workflow in verständlicher Form, beispielsweise „Manager Approval“ oder „VP Finance Approval“. Damit ist die Information aussagekräftiger als bei einer generischen Aktivität wie „Approval Step Completed“.

Dieses Attribut ist für die Dashboards „Approval Step Cycle Time“ und „Workflow Bottleneck Analysis“ entscheidend. Es ermöglicht eine detaillierte Betrachtung des Genehmigungsprozesses. Dadurch lässt sich genau feststellen, welche Genehmigungsstufen die größten Verzögerungen verursachen und an welchen Stellen sich Arbeit ansammelt. Diese Detailtiefe ist für gezielte Maßnahmen zur Optimierung der Genehmigungskette erforderlich.

Warum das wichtig ist

Liefert detaillierte Informationen zu den Genehmigungsstufen und ermöglicht die präzise Identifikation von Engpässen innerhalb des mehrstufigen Genehmigungs-Workflows.

Bezugsquelle

Diese Information wird aus der Beschreibung der Workflow-Aufgabe abgeleitet. Sie kann durch die Verknüpfung des Workflow-Logs mit Aufgabendefinitionstabellen wie T528T ermittelt werden.

Beispiele
Genehmigung durch den ManagerGenehmigung durch den DirektorGenehmigung durch den VP Finanzen
Quellsystem
SourceSystem
Identifiziert die konkrete SAP-S/4HANA-Instanz, aus der die Daten extrahiert wurden.
Beschreibung

Das Attribut Quellsystem bezeichnet das Ursprungssystem, in dem die Prozessdaten erzeugt wurden. In Unternehmen mit mehreren SAP-Instanzen, etwa getrennten Systemen für Entwicklung, Qualitätssicherung und Produktion oder separaten Systemen für verschiedene Regionen, ist dieses Feld für Data Governance und Kontext entscheidend.

Es stellt sicher, dass Daten aus unterschiedlichen Quellen unterschieden werden können. Dadurch werden fehlerhafte Aggregationen vermieden und systemspezifische Analysen ermöglicht. Für die Pflege der Datenherkunft und die Nachvollziehbarkeit der Prozessdaten ist dieses Attribut erforderlich.

Warum das wichtig ist

Liefert wichtigen Kontext zur Datenherkunft und Data Governance, insbesondere in Systemlandschaften mit mehreren Systemen, und gewährleistet die Nachvollziehbarkeit der Daten.

Bezugsquelle

Dabei handelt es sich typischerweise um die SAP-System-ID (SID), die aus Systemvariablen oder Konfigurationstabellen abgerufen werden kann.

Beispiele
S4PECCS4H_PROD_01
Währung
Currency
Der Währungscode für den Requisitionsbetrag.
Beschreibung

Dieses Attribut gibt an, in welcher Währung der Requisitionsbetrag ausgewiesen ist, etwa USD, EUR oder JPY. Es liefert den erforderlichen Kontext für das Attribut Requisitionsbetrag, insbesondere in multinationalen Unternehmen mit mehreren Währungen.

Für eine korrekte Finanzanalyse und Berichterstattung muss die Währung berücksichtigt werden. Beim Aggregieren oder Vergleichen von Requisitionswerten sollten alle Beträge in eine gemeinsame Währung umgerechnet werden, damit aussagekräftige Ergebnisse entstehen. Dieses Attribut ist Voraussetzung für solche Umrechnungen.

Warum das wichtig ist

Liefert den erforderlichen Kontext für den Requisitionsbetrag und ermöglicht präzise Finanzanalysen und Vergleiche in Umgebungen mit mehreren Währungen.

Bezugsquelle

Dieses Feld befindet sich in der Tabelle EBAN, Feld WAERS.

Beispiele
USDEURGBP
Erforderlich Empfohlen Optional

Purchase to Pay, Aktivitäten der Bestellanforderung

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie für eine präzise Prozesserkennung in Ihrem Event Log erfassen sollten.
6 Empfohlen 6 Optional
Aktivität Beschreibung
Bestellung erstellt
Zeigt an, dass eine Bestellung mit Bezug auf die Requisitionsposition erstellt wurde. Dieses ausdrückliche Systemereignis verknüpft die Requisition mit einem nachfolgenden Beschaffungsbeleg.
Warum das wichtig ist

Dies ist ein wichtiger Meilenstein und ein erfolgreiches Ergebnis des Requisitionsprozesses. Die Zeit zwischen Genehmigung der Requisition und Erstellung der Bestellung ist ein zentraler KPI für die Messung der Beschaffungseffizienz.

Bezugsquelle

Wird ausdrücklich erfasst, sobald eine Bestellposition erstellt wird. Die Verknüpfung ist in der Tabelle EKPO (Bestellposition) gespeichert, die die Nummer der Quell-Requisition (BANFN) und die Positionsnummer (BNFPO) enthält.

Erfassen

Verknüpfen Sie die Tabelle EKPO über Requisitionsnummer und Position mit EBAN. Das Erstellungsdatum der Bestellposition kennzeichnet das Ereignis.

Ereignistyp explicit
Genehmigungsschritt abgeschlossen
Tritt auf, wenn ein Genehmigender eine positive Entscheidung zu einer Requisition trifft und damit einen Schritt im mehrstufigen Genehmigungs-Workflow abschließt. Dies wird aus einer Änderung des Freigabestatus der Requisition abgeleitet.
Warum das wichtig ist

Diese Aktivität ermöglicht eine detaillierte Analyse des Genehmigungs-Workflows, einschließlich der Dauer jedes einzelnen Schritts. So lassen sich effiziente Genehmigende ebenso erkennen wie Engpässe im Prozess.

Bezugsquelle

Abgeleitet aus Änderungsbelegen (CDHDR/CDPOS) für die Tabelle EBAN. Eine Änderung des Status eines Freigabecodes, etwa im Feld FRGZU, von „nicht freigegeben“ zu „freigegeben“ für einen bestimmten Code kennzeichnet dieses Ereignis.

Erfassen

Verfolgen Sie für jeden in der Strategie definierten Freigabecode Änderungen an den Freigabestatusfeldern in EBAN.

Ereignistyp inferred
Requisition abgelehnt
Bezeichnet die endgültige Ablehnung der Purchase Requisition durch einen Genehmigenden, wodurch der Prozess angehalten wird. Erfasst wird dies durch eine Statusaktualisierung, die eine Ablehnung anzeigt.
Warum das wichtig ist

Diese Aktivität ist ein kritischer Endpunkt des Fehlschlags. Die Analyse von Ablehnungshäufigkeit, Gründen und Prozessstellen hilft, Probleme bei Richtlinienkonformität, Budget oder Qualität der Anforderung zu erkennen.

Bezugsquelle

Abgeleitet aus einer Statusänderung in der Tabelle EBAN. Der Bearbeitungsstatus (PROCSTAT) oder ein Freigabeindikator wird auf einen Wert gesetzt, der ausdrücklich „Abgelehnt“ bedeutet.

Erfassen

Ermitteln Sie über Änderungsbelege den Timestamp, zu dem der Gesamtstatus in EBAN auf „Abgelehnt“ aktualisiert wird.

Ereignistyp inferred
Requisition abgeschlossen
Zeigt an, dass die Requisitionsposition vollständig bearbeitet wurde und daraus keine weiteren Bestellungen erstellt werden können. Dieser Status wird typischerweise automatisch gesetzt, sobald die gesamte Menge bestellt wurde.
Warum das wichtig ist

Diese Aktivität kennzeichnet den endgültigen, erfolgreichen Abschluss des Lebenszyklus der Requisitionsposition. Sie bestätigt, dass der Geschäftsbedarf vollständig in einen Beschaffungsauftrag überführt wurde.

Bezugsquelle

Abgeleitet aus der Tabelle EBAN. Das Ereignis tritt ein, wenn das Kennzeichen „Abgeschlossen“ (EBAKZ) gesetzt wird. Dies geschieht typischerweise, sobald die in Bestellungen georderte Menge der Requisitionsmenge entspricht.

Erfassen

Ermitteln Sie über Änderungsbelege das Ereignis, bei dem das Kennzeichen „Abgeschlossen“ (EBAKZ) in der Tabelle EBAN gesetzt wird.

Ereignistyp inferred
Requisition erstellt
Kennzeichnet die erstmalige Erstellung des Dokuments für die Purchase Requisition im System. Das Ereignis wird ausdrücklich erfasst, sobald ein Benutzer eine neue Requisition erstmals speichert, einschließlich des Erstellungszeitpunkts.
Warum das wichtig ist

Diese Aktivität bildet den zentralen Startpunkt für die Analyse des Lebenszyklus einer Requisition. Sie ist entscheidend, um die durchgängige Zykluszeit von der Erkennung des ursprünglichen Bedarfs bis zur endgültigen Genehmigung oder Umwandlung in eine Bestellung zu messen.

Bezugsquelle

Dieses ausdrückliche Ereignis wird aus der Tabelle EBAN erfasst. Verwendet werden die Felder für Erstellungsdatum (ERDAT) und Erstellungszeit (ERZEIT) der jeweiligen Purchase Requisition (BANFN).

Erfassen

Verwenden Sie für jede Requisition (BANFN) die Felder für den Erstellungszeitpunkt (ERDAT, ERZEIT) aus der Tabelle EBAN.

Ereignistyp explicit
Requisition genehmigt
Kennzeichnet die endgültige und vollständige Genehmigung der Purchase Requisition. Damit kann sie in eine Bestellung umgewandelt werden. Dieser Meilenstein wird daraus abgeleitet, dass der Gesamtfreigabestatus den endgültig genehmigten Status erreicht.
Warum das wichtig ist

Dies ist ein wichtiger Erfolgsmeilenstein und ein häufiger Endpunkt der Zykluszeitanalyse. Er zeigt, dass die Requisition alle Prüfungen bestanden hat und von der Beschaffung bearbeitet werden kann.

Bezugsquelle

Abgeleitet aus einer Statusänderung in der Tabelle EBAN, insbesondere wenn der Gesamtfreigabeindikator (FRGZU) oder der Bearbeitungsstatus (PROCSTAT) auf den endgültigen Wert „Genehmigt“ aktualisiert wird.

Erfassen

Ermitteln Sie den Timestamp, zu dem der letzte Freigabecode angewendet wird oder sich der Gesamtstatus der Requisition in „Genehmigt“ ändert.

Ereignistyp inferred
Bezugsquelle zugewiesen
Bezeichnet die Aktion eines Einkäufers, einer genehmigten Requisitionsposition einen bestimmten Lieferanten, Vertrag oder Infosatz zuzuweisen. Dies ist ein wichtiger Schritt, um die Requisition für die Erstellung einer Bestellung vorzubereiten.
Warum das wichtig ist

Diese Aktivität verbindet Genehmigung und Bestellung. Die Messung der Zeit bis zur Zuweisung einer Bezugsquelle zeigt Verzögerungen bei der Arbeitslast des Einkäufers und bei der Effizienz der Beschaffung.

Bezugsquelle

Abgeleitet aus einem Wert, der in bezugsquellenbezogene Felder der Tabelle EBAN eingetragen wird, etwa fester Lieferant (LIFNR), Infosatz (INFNR) oder Vertrag (KONNR).

Erfassen

Verfolgen Sie über Änderungsbelege, wann Felder wie LIFNR, INFNR oder KONNR in der Tabelle EBAN befüllt werden.

Ereignistyp inferred
Genehmigung zurückgesetzt
Bezeichnet ein Ereignis, bei dem der gesamte Genehmigungs-Workflow zurückgesetzt wird, häufig aufgrund einer wesentlichen Änderung an der Requisition. Dadurch beginnt der Genehmigungsprozess erneut auf der ersten Ebene.
Warum das wichtig ist

Diese Aktivität weist auf umfangreiche Nacharbeit hin, die die Zykluszeit erheblich verlängert. Die Ursachen für das Zurücksetzen von Genehmigungen zu ermitteln, ist entscheidend, um den Prozess zu vereinfachen und Verzögerungen zu reduzieren.

Bezugsquelle

Abgeleitet aus Änderungsbelegen (CDHDR/CDPOS) zur Tabelle EBAN. Das Ereignis wird erkannt, wenn Felder für den Freigabestatus, etwa FRGKZ oder FRGZU, gelöscht werden, nachdem sie teilweise oder vollständig gesetzt waren.

Erfassen

Suchen Sie in den Änderungsprotokollen nach einem Wechsel des Freigabestatus von „freigegeben“ zurück zu „nicht freigegeben“.

Ereignistyp inferred
Genehmigungsschritt gestartet
Zeigt an, dass eine Requisition auf eine Aktion eines bestimmten Genehmigenden oder einer Genehmigungsgruppe wartet. Dies wird daraus abgeleitet, dass der Status der Requisition auf einen bestimmten ausstehenden Freigabecode hinweist.
Warum das wichtig ist

Diese Aktivität ist entscheidend, um Engpässe in der Genehmigungskette zu lokalisieren. Die Analyse der Dauer dieses Status zeigt, bei welchen Requisitionen die Bearbeitung stockt und welche Genehmigende überlastet sind.

Bezugsquelle

Abgeleitet aus den Freigabestatusfeldern der Tabelle EBAN, etwa FRGZU, und der zugrunde liegenden Konfiguration der Freigabestrategie. Das Ereignis beginnt, sobald ein bestimmter Freigabecode als nächster zu bearbeitender Code feststeht.

Erfassen

Ermitteln Sie anhand von Workflow-Protokollen oder Statusfeldern, wann eine Requisition in einen Status eintritt, in dem die Genehmigung eines bestimmten Freigabecodes aussteht.

Ereignistyp inferred
Requisition geändert
Tritt auf, wenn ein Benutzer nach der erstmaligen Erstellung ein wichtiges Feld der Requisition ändert, etwa Menge, Preis oder Material. Diese Aktion wird ausdrücklich im Änderungsbelegsystem von SAP protokolliert.
Warum das wichtig ist

Die Nachverfolgung von Änderungen ist entscheidend, um Nacharbeitschleifen und deren Auswirkungen auf die Zykluszeit zu erkennen. Eine hohe Änderungsquote deutet auf Probleme mit der Datenqualität oder wechselnde Anforderungen hin. Beide Bereiche sind für Prozessverbesserungen besonders relevant.

Bezugsquelle

Wird für Änderungen an der Tabelle EBAN ausdrücklich in den SAP-Tabellen für Änderungsbelege (CDHDR und CDPOS) protokolliert. Jede Änderung an einem überwachten Feld erzeugt einen Eintrag.

Erfassen

Extrahieren Sie Änderungsereignisse aus CDHDR/CDPOS, bei denen die Objektklasse BANF für Purchase Requisitions verwendet wird.

Ereignistyp explicit
Requisition zur Genehmigung eingereicht
Bezeichnet den Zeitpunkt, zu dem der Anfordernde die Requisition formell einreicht und damit den Genehmigungs-Workflow auslöst. Dies wird typischerweise daraus abgeleitet, dass die Freigabestrategie der Requisition festgelegt wird und sich der Status in „In Genehmigung“ ändert.
Warum das wichtig ist

Dieser wichtige Meilenstein startet die Messung der KPIs für die Dauer des Genehmigungszyklus. Die Analyse der Zeit zwischen Erstellung und Einreichung kann Verzögerungen in der Vorbereitungsphase der Requisition sichtbar machen.

Bezugsquelle

Abgeleitet aus Änderungsbelegen (CDHDR/CDPOS) für die Tabelle EBAN, insbesondere wenn Felder der Freigabestrategie, etwa FRGST, befüllt werden oder sich der Gesamtstatus (PROCSTAT) in einen Status „In Genehmigung“ ändert.

Erfassen

Ermitteln Sie den ersten Eintrag im Änderungsbeleg, der den Beginn des Genehmigungs-Workflows oder einen Statuswechsel zu „In Genehmigung“ anzeigt.

Ereignistyp inferred
Requisition zurückgezogen
Tritt auf, wenn der ursprüngliche Anfordernde die Requisition löscht oder storniert, bevor sie vollständig bearbeitet wurde. Dies ist typischerweise eine ausdrückliche Aktion, durch die das Löschkennzeichen für die Requisitionsposition gesetzt wird.
Warum das wichtig ist

Die Nachverfolgung zurückgezogener Requisitionen hilft, Schwankungen im Bedarf und Gründe für Stornierungen zu verstehen. Sie kennzeichnet einen Endstatus der Requisition und verhindert eine weitere Bearbeitung.

Bezugsquelle

Wird ausdrücklich erfasst, sobald das Löschkennzeichen (LOEKZ) in der Tabelle EBAN für eine Requisitionsposition gesetzt wird. Die Änderung wird in CDHDR/CDPOS protokolliert.

Erfassen

Ermitteln Sie das Ereignis, bei dem das Löschkennzeichen (LOEKZ) in der Tabelle EBAN auf „L“ gesetzt wird.

Ereignistyp explicit
Empfohlen Optional

Extraktionsanleitungen

So extrahieren Sie Ihre Daten aus SAP S/4HANA

Möchten Sie jetzt starten?

Verwenden Sie dieses Template, um Ihre Daten sicher vorzubereiten und das volle Potenzial von Process Mining für Ihren Purchase-to-Pay-Prozess für Bestellanforderungen auszuschöpfen. Beginnen Sie noch heute mit der Optimierung Ihrer Effizienz.

Beenden Sie Verzögerungen bei P2P-Bestellanforderungen: Optimieren Sie jetzt Ihren Workflow.

Gestalten Sie Prozesse effizienter, verkürzen Sie Durchlaufzeiten und reduzieren Sie die Zykluszeit um 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich, Einrichtung in 5 Minuten.