Ihr Daten-Template für Purchase to Pay – Bestellung

SAP ECC
Ihr Daten-Template für Purchase to Pay – Bestellung

Ihr Daten-Template für Purchase to Pay – Bestellung

Dieses Template führt Sie durch die wichtigsten Datenpunkte, die Sie für die Analyse Ihres Purchase-to-Pay-Prozesses für Bestellungen in SAP ECC benötigen. Es zeigt, welche Attribute Sie erfassen und welche Aktivitäten Sie nachverfolgen sollten. Außerdem enthält es praktische Hinweise zum Datenexport aus Ihrem System. Mit diesen Informationen erstellen Sie ein aussagekräftiges Event Log für Ihre Process-Mining-Analysen.
  • Empfohlene Attribute für die Datenerfassung
  • Wichtige Aktivitäten für die Analyse
  • Hinweise zum Datenexport aus SAP ECC
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute für Purchase to Pay – Bestellung

Dies sind die wichtigsten Datenfelder, die Sie in Ihr Event Log aufnehmen sollten, um Ihren Purchase-to-Pay-Prozess für Bestellungen umfassend zu analysieren.
3 Erforderlich 6 Empfohlen 12 Optional
Name Beschreibung
Aktivität
Activity
Die Bezeichnung des konkreten Geschäftsereignisses oder Prozessschritts im Lebenszyklus einer Bestellung.
Beschreibung

Dieses Attribut beschreibt einen einzelnen Prozessschritt, etwa „Bestellung angelegt“, „Bestellung genehmigt“ oder „Wareneingang gebucht“. Die Abfolge dieser Aktivitäten bildet den Prozessfluss für jede Bestellung.

Die Analyse der Reihenfolge, Häufigkeit und Dauer zwischen den Aktivitäten ist der Kern des Process Mining. Sie hilft, Engpässe, Nacharbeitsschleifen und Abweichungen vom Standardprozess zu erkennen und gezielte Verbesserungen sowie Standardisierungen umzusetzen.

Warum das wichtig ist

Aktivitäten bilden die Prozessschritte ab. Ihre Reihenfolge und Zeitpunkte zeigen den tatsächlichen Prozessfluss, Engpässe und Abweichungen.

Woher beziehen

Abgeleitet aus verschiedenen SAP-Tabellen und Transaktionsprotokollen, etwa CDHDR/CDPOS für Änderungen, EKBE für Wareneingang und Rechnungsprüfung sowie EBAN für Bestellanforderungen. Zur Generierung ist häufig eine individuelle Logik oder ein Extraktionsprogramm erforderlich.

Beispiele
Bestellung angelegtBestellung genehmigtWareneingang gebucht
Bestellung
PurchaseOrder
Der eindeutige Bezeichner des Bestelldokuments (PO), das als zentraler Case für die Nachverfolgung des Beschaffungsprozesses dient.
Beschreibung

Die Bestellnummer ist der zentrale Bezeichner, der alle Aktivitäten von der Erstellung bis zum endgültigen Wareneingang und Abschluss miteinander verknüpft. Jede eindeutige Bestellnummer steht für einen einzelnen Beschaffungsvorgang.

Im Process Mining ist dieses Attribut entscheidend, um den gesamten Ablauf jeder Bestellung zu rekonstruieren. Es ermöglicht eine detaillierte Analyse der Zykluszeiten, Prozessvarianten und Compliance-Prüfungen für jede einzelne Bestellung und bildet die Grundlage für das gesamte Prozessmodell.

Warum das wichtig ist

Dieser zentrale Bezeichner verknüpft alle zugehörigen Ereignisse und ermöglicht so die Analyse des vollständigen Lebenszyklus jeder einzelnen Bestellung.

Woher beziehen

Tabelle: EKKO, Feld: EBELN

Beispiele
450001762345000176244500017625
Ereigniszeit
EventTime
Das genaue Datum und die Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung

Dieser Timestamp kennzeichnet den genauen Zeitpunkt eines Ereignisses, etwa die Genehmigung einer Bestellung oder die Buchung eines Wareneingangs. Er legt die chronologische Reihenfolge aller Aktivitäten innerhalb eines Case fest.

Timestamps sind eine wesentliche Grundlage für das Process Mining, da sie alle zeitbasierten Analysen ermöglichen. Dazu gehören die Berechnung von Zykluszeiten zwischen Aktivitäten, das Erkennen von Verzögerungen, die Analyse des Prozessdurchsatzes und der Leistungsvergleich mit Service Level Agreements (SLAs).

Warum das wichtig ist

Dieser Timestamp ist entscheidend für die Berechnung aller zeitbezogenen Kennzahlen, etwa Zykluszeiten und Engpässe, sowie für die chronologische Sortierung der Ereignisse.

Woher beziehen

Abgeleitet aus verschiedenen Datums- und Uhrzeitfeldern in SAP-Tabellen, etwa EKKO-AEDAT (Änderungsdatum), CDHDR-UDATE/UTIME (Timestamp des Änderungsprotokolls) oder EKBE-BUDAT (Buchungsdatum).

Beispiele
2023-04-15T10:05:31Z2023-04-16T14:22:00Z2023-05-01T09:00:15Z
Belegart
DocumentType
Ein Code zur Klassifizierung verschiedener Bestellarten.
Beschreibung

Die Belegart ist eine SAP-Konfiguration, die den Nummernkreis, die Feldauswahl und den gesamten Prozessfluss einer Bestellung steuert. So kann es unterschiedliche Belegarten für Standardbestellungen, Dienstleistungsbestellungen oder Umlagerungsbestellungen geben.

Dieses Attribut ist eine wichtige Analysedimension, da verschiedene Belegarten oft bewusst unterschiedlichen Prozessen folgen. Durch die Filterung nach Belegart lassen sich Zykluszeiten und Prozessflüsse präziser miteinander vergleichen.

Warum das wichtig ist

Unterscheidet verschiedene Beschaffungsprozesse, etwa Standard-, Dienstleistungs- oder Retourenprozesse, die oft eigene Abläufe und Leistungserwartungen haben.

Woher beziehen

Tabelle: EKKO, Feld: BSART

Beispiele
NBFOUB
Benutzername
UserName
Die Benutzer-ID der Person, die die Aktivität ausgeführt hat.
Beschreibung

Dieses Attribut erfasst den SAP-Benutzernamen des Mitarbeitenden, der ein Dokument angelegt, geändert oder genehmigt hat. Bei automatisierten Schritten kann eine System- oder Batch-Benutzer-ID angezeigt werden.

Die Analyse nach Benutzern hilft, Schulungsbedarf und besonders leistungsstarke Mitarbeitende zu erkennen sowie mögliche Compliance-Probleme aufzudecken. Sie ist wichtig für Dashboards zur Arbeitslastverteilung und zur Einhaltung der Genehmigungsmatrix und ermöglicht den Leistungsvergleich zwischen Teams und einzelnen Mitarbeitenden.

Warum das wichtig ist

Ordnet Benutzeraktionen bestimmten Personen zu und ermöglicht so die Analyse von Leistung, Arbeitslast und Einhaltung der Compliance-Vorgaben.

Woher beziehen

Tabelle: EKKO, Feld: ERNAM (Erstellt von); Tabelle: CDHDR, Feld: USERNAME (Geändert von).

Beispiele
JSMITHMBROWNBATCH_USER
Bestellwert
OrderAmount
Der Gesamtwert der Bestellposition.
Beschreibung

Dieses Attribut gibt den Gesamtwert einer bestimmten Bestellposition an. Er berechnet sich aus der Menge multipliziert mit dem Nettopreis. Für den Gesamtwert einer Bestellung müssen die Beträge aller Positionen addiert werden.

Die Analyse nach Bestellwert ist entscheidend, um Transaktionen mit hohem Wert zu erkennen, für die strengere Kontrollen oder andere Genehmigungswege erforderlich sein können. Sie bildet die Grundlage für das Dashboard zur Analyse des Bestellwerts und hilft, Verbesserungsmaßnahmen auf finanziell besonders bedeutende Bestellungen auszurichten.

Warum das wichtig ist

Beziffert die finanziellen Auswirkungen jeder Bestellung und ermöglicht wertbasierte Analysen, um Bestellungen mit hohem Wert zu priorisieren oder Einsparpotenziale zu erkennen.

Woher beziehen

Tabelle: EKPO, Feld: NETWR (Nettobestellwert).

Beispiele
1500.00250.7512345.50
Buchungskreis
CompanyCode
Der Bezeichner der juristischen Person oder des Unternehmens, das die Beschaffung veranlasst.
Beschreibung

Der Buchungskreis steht in SAP für eine eigenständige juristische Person. Alle Transaktionen werden auf Ebene des Buchungskreises gebucht. Er ist damit eine grundlegende Organisationseinheit.

Die Analyse nach Buchungskreis ermöglicht den Vergleich von Beschaffungseffizienz und Compliance zwischen verschiedenen Geschäftseinheiten oder Ländern. Sie hilft, bewährte Vorgehensweisen einer Einheit zu erkennen und an anderer Stelle zu übernehmen oder gezielt Einheiten zu identifizieren, die Unterstützung benötigen.

Warum das wichtig ist

Kennzeichnet die juristische Person und ermöglicht den Vergleich der Prozessleistung sowie Compliance-Prüfungen in verschiedenen Unternehmensbereichen.

Woher beziehen

Tabelle: EKKO, Feld: BUKRS

Beispiele
10002100US01
Lieferantennummer
VendorNumber
Der eindeutige Bezeichner des Lieferanten.
Beschreibung

Dieser Code kennzeichnet eindeutig den Lieferanten, von dem Waren oder Dienstleistungen beschafft werden. Er ist ein wichtiges Stammdatenattribut im Beschaffungsprozess.

Dieses Attribut ist für lieferantenbezogene Analysen unverzichtbar. Es ermöglicht die Bewertung der Lieferanten-Lieferleistung, den Vergleich von Lieferzeiten verschiedener Lieferanten und die Analyse von Ausgabenmustern. Es ist die zentrale Dimension des Dashboards „Lieferanten-Lieferleistung“.

Warum das wichtig ist

Ermöglicht die Analyse der Lieferantenleistung und hilft, zuverlässige Lieferanten sowie Verursacher von Verzögerungen oder Qualitätsproblemen zu erkennen.

Woher beziehen

Tabelle: EKKO, Feld: LIFNR

Beispiele
100345V-20598700112
Warengruppe
MaterialGroup
Eine Klassifizierung, mit der Waren oder Dienstleistungen mit ähnlichen Merkmalen gruppiert werden.
Beschreibung

Die Warengruppe beziehungsweise Beschaffungskategorie klassifiziert die Art der beschafften Waren oder Dienstleistungen. Beispiele sind „IT-Hardware“, „Bürobedarf“ oder „professionelle Dienstleistungen“.

Dieses Attribut ist wichtig für die Ausgabenanalyse und das Verständnis von Beschaffungsmustern. Damit lässt sich der Prozess filtern und untersuchen, wie verschiedene Kategorien bearbeitet werden, wer sie genehmigt und welche Lieferanten sie bereitstellen. Es ist eine zentrale Dimension des Dashboards zur Analyse des Bestellwerts.

Warum das wichtig ist

Ermöglicht die Segmentierung des Prozesses nach Produkt- oder Dienstleistungskategorie. So werden Unterschiede bei Abläufen, Zykluszeiten und Lieferanten für verschiedene Ausgabenarten sichtbar.

Woher beziehen

Tabelle: EKPO, Feld: MATKL

Beispiele
00101IT-HardwareBERATUNG
Ablehnungsgrund
RejectionReason
Der Grundcode oder Text, der erklärt, warum eine Bestellanforderung oder Bestellung abgelehnt wurde.
Beschreibung

Dieses Attribut erfasst den konkreten Grund für die Ablehnung einer Bestellung im Freigabe-Workflow. Diese Information ist entscheidend, um die Ursachen für Nacharbeit und Verzögerungen zu verstehen.

Die Analyse der Ablehnungsgründe zeigt häufige Probleme auf, etwa falsche Preise, überschrittene Budgets oder die Auswahl nicht konformer Lieferanten. So kann das Unternehmen die Ursachen angehen, die Qualität der ursprünglichen Bestellung verbessern und den Freigabeprozess vereinfachen.

Warum das wichtig ist

Zeigt direkt, warum Freigaben scheitern. So können Sie gezielt Verbesserungen umsetzen, Nacharbeit verringern und Freigabezeiten verkürzen.

Woher beziehen

Diese Information ist möglicherweise schwer zu finden. Sie kann in Langtextfeldern gespeichert sein oder von einer kundenspezifischen Workflow-Konfiguration abhängen. Für ihre Ermittlung sind häufig spezielle Implementierungskenntnisse erforderlich.

Beispiele
Falscher PreisBudget überschrittenDoppelte Anforderung
Änderung nach Freigabe
IsPostApprovalChange
Kennzeichnet, ob eine Bestellung nach der ursprünglichen Freigabe geändert wurde.
Beschreibung

Dieses boolesche Attribut ist wahr, wenn für dieselbe Bestellung nach der Aktivität „Bestellung freigegeben“ die Aktivität „Bestellung geändert“ erkannt wird. Damit lassen sich problematische Änderungen identifizieren, die erst spät im Prozess erfolgen.

Dieses berechnete Feld unterstützt direkt die Kennzahl „Änderungsquote von Bestellungen nach Freigabe“ und das Dashboard „Nacharbeit und Änderungen bei Bestellungen“. Es quantifiziert und verdeutlicht störende Änderungen, die Verzögerungen verursachen und eine erneute Freigabe erfordern können. So werden mögliche Probleme bei der ursprünglichen Spezifikation oder der Abgrenzung des Umfangs sichtbar.

Warum das wichtig ist

Misst direkt die Nacharbeit nach der Freigabe, eine wichtige Kennzahl für Prozessstabilität und Effizienz. Hohe Werte weisen auf Probleme bei der vorgelagerten Anforderungsdefinition hin.

Woher beziehen

Dieses berechnete Attribut wird aus der Abfolge der Aktivitäten im Event Log abgeleitet.

Beispiele
truefalse
Angeforderter Liefertermin
RequestedDeliveryDate
Das Datum, zu dem das Unternehmen die Lieferung der Waren oder Dienstleistungen angefordert hat.
Beschreibung

Dies ist der in der Bestellung angegebene Zieltermin für die Lieferung. Er dient als Vergleichswert für die Bewertung der tatsächlichen Lieferleistung.

Dieses Datum ist entscheidend für die Berechnung der Kennzahl zur pünktlichen Wareneingangsquote. Durch den Vergleich des tatsächlichen Wareneingangsdatums mit dem angeforderten Liefertermin können Unternehmen die Zuverlässigkeit der Lieferanten und die Effizienz der internen Warenannahme quantitativ bewerten. Das unterstützt direkt das Dashboard „Lieferanten-Lieferleistung“.

Warum das wichtig ist

Dieser Zieltermin ist entscheidend für die Berechnung von Kennzahlen zur Pünktlichkeit und die Bewertung der Lieferantenzuverlässigkeit.

Woher beziehen

Tabelle: EKPO, Feld: EINDT

Beispiele
2023-06-102023-07-222023-08-01
Bestellanforderung
PurchaseRequisition
Der Bezeichner der Bestellanforderung, die der Bestellung vorausging.
Beschreibung

Dieses Attribut verknüpft die Bestellung mit der ursprünglichen Bestellanforderung. Nicht jeder Bestellung geht eine Bestellanforderung voraus.

Diese Verknüpfung ist wichtig für die Analyse des Dashboards zur Umwandlung von Bestellanforderungen in Bestellungen und der Kennzahl zur Umwandlungsquote. Damit lässt sich die Effizienz des vorgelagerten Prozesses von der ersten Anforderung bis zur Erstellung einer formellen Bestellung messen. Außerdem können nicht konforme Bestellungen erkannt werden, die ohne vorherige Bestellanforderung angelegt wurden.

Warum das wichtig ist

Verknüpft die Bestellung mit der ursprünglichen Anforderung und ermöglicht die Analyse der Umwandlung von Bestellanforderungen in Bestellungen sowie das Erkennen von Bestellungen ohne vorherige Anforderung.

Woher beziehen

Tabelle: EKPO, Feld: BANFN

Beispiele
1001589010015891
Einkäufergruppe
PurchasingGroup
Der Einkäufer oder die Gruppe von Einkäufern, die für die Beschaffungsaktivität zuständig ist.
Beschreibung

Die Einkäufergruppe bezeichnet die Person oder das Team, die beziehungsweise das für eine bestimmte Beschaffungsaktivität zuständig ist. Sie ist die zentrale Anlaufstelle für Lieferanten.

Dieses Attribut ermöglicht eine detailliertere Analyse als die Einkaufsorganisation. Es hilft, die Arbeitslast unter den Einkäufern zu verstehen und Leistungsunterschiede auf Ebene der einzelnen Einkäufer zu erkennen. Diese Erkenntnisse können in die Ressourcenplanung und in Schulungsmaßnahmen einfließen.

Warum das wichtig ist

Ermöglicht eine detaillierte Übersicht darüber, wer für einen Einkauf verantwortlich ist. So lassen sich Arbeitsaufkommen und Leistung auf Ebene einzelner Einkäufer oder Teams analysieren.

Woher beziehen

Tabelle: EKKO, Feld: EKGRP

Beispiele
001002N01
Einkaufsorganisation
PurchasingOrganization
Die Organisationseinheit, die für Preisverhandlungen und die Beschaffung von Materialien oder Dienstleistungen zuständig ist.
Beschreibung

Die Einkaufsorganisation ist eine wichtige Organisationseinheit in SAP, die für Beschaffungsaktivitäten zuständig ist. Sie kann zentral für das gesamte Unternehmen oder dezentral nach Werk oder Region organisiert sein.

Die Analyse der Prozessleistung nach Einkaufsorganisation zeigt, welche Beschaffungsteams besonders effizient arbeiten. Kennzahlen wie Zykluszeit, Nacharbeitsquote und Kosten lassen sich zwischen Organisationseinheiten vergleichen. So werden bewährte Vorgehensweisen und Bereiche mit Unterstützungsbedarf sichtbar.

Warum das wichtig ist

Kennzeichnet das zuständige Beschaffungsteam und ermöglicht Leistungsvergleiche sowie Analysen zwischen verschiedenen Organisationseinheiten.

Woher beziehen

Tabelle: EKKO, Feld: EKORG

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

Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder -aktualisierung. So lässt sich die Aktualität der analysierten Daten einordnen.

Die Anzeige dieser Information in Dashboards ist wichtig, damit Benutzer erkennen, ob die Erkenntnisse auf nahezu aktuellen Daten oder auf einem historischen Datenstand beruhen. Das schafft klare Erwartungen und stellt sicher, dass Entscheidungen auf Grundlage von Daten mit bekanntem Aktualitätsstand getroffen werden.

Warum das wichtig ist

Informiert Benutzer über die Aktualität der Daten und zeigt, ob die Analyse den neuesten Betriebsstand widerspiegelt.

Woher beziehen

Dieser Timestamp wird bei der Ausführung durch den Datenextraktions- oder ETL-Prozess erzeugt und hinzugefügt.

Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Lieferantenname
VendorName
Der rechtliche Name des Lieferanten.
Beschreibung

Der ausgeschriebene Name des Lieferanten, der verständlicher ist als die Lieferantennummer. Er stammt üblicherweise aus den Lieferantenstammdaten.

Die Lieferantennummer dient zum Verknüpfen und zur eindeutigen Identifizierung. Der Lieferantenname ist dagegen für Dashboards und Berichte wichtig, die sich an Benutzer richten. Er macht Analysen für Fachanwender verständlicher, die mit den Lieferantencodes möglicherweise nicht vertraut sind.

Warum das wichtig ist

Zeigt den Lieferanten unter einem verständlichen Namen an und erleichtert Fachanwendern die Auswertung von Dashboards und Berichten.

Woher beziehen

Tabelle: LFA1, Feld: NAME1. Dazu ist eine Verknüpfung von EKKO-LIFNR mit LFA1-LIFNR erforderlich.

Beispiele
Staples Inc.Global Tech SolutionsOffice Supply Co.
Pünktliche Lieferung
IsOnTimeDelivery
Kennzeichnet, ob die Waren am angeforderten Liefertermin oder früher eingegangen sind.
Beschreibung

Dieses boolesche Attribut ist wahr, wenn der Timestamp der Aktivität „Wareneingang gebucht“ am oder vor dem „Angeforderten Liefertermin“ liegt. Damit wird die Lieferleistung für jede Bestellposition eindeutig als erfüllt oder nicht erfüllt ausgewiesen.

Das Attribut bildet die Grundlage für die Kennzahl „Quote pünktlicher Wareneingänge“. Es vereinfacht die Analyse der Lieferantenleistung und der internen Wareneingangseffizienz, da pünktliche und verspätete Lieferungen einfach aggregiert und gefiltert werden können.

Warum das wichtig ist

Liefert eine eindeutige Kennzahl zur Pünktlichkeit der Lieferungen und unterstützt direkt Kennzahlen und Dashboards zur Lieferantenleistung.

Woher beziehen

Dieses berechnete Attribut ergibt sich aus dem Vergleich des Buchungsdatums des Wareneingangs (EKBE-BUDAT) mit dem angeforderten Liefertermin (EKPO-EINDT).

Beispiele
truefalse
Quellsystem
SourceSystem
Das System, aus dem die Daten extrahiert wurden.
Beschreibung

Dieses Attribut kennzeichnet die Herkunft der Daten. In der Regel handelt es sich um eine SAP-ECC-Instanzkennung, etwa „ECC_PROD_100“. In Umgebungen mit mehreren Systemen lassen sich damit die Datenquellen unterscheiden.

Für Governance und Datenherkunft ist die Kenntnis des Quellsystems entscheidend. Sie unterstützt die Sicherung der Datenintegrität und die Fehlersuche bei Problemen mit der Datenextraktion oder -qualität, insbesondere wenn Daten aus verschiedenen ERP-Systemen oder Modulen zusammengeführt werden.

Warum das wichtig ist

Kennzeichnet die Herkunft der Daten. Das ist entscheidend für Data Governance, Validierung und die Verwaltung von Analysen über mehrere Systeme hinweg.

Woher beziehen

In der Regel wird während der Datenextraktion ein statischer Wert hinzugefügt, der den Datensatz mit seinem Ursprungssystem kennzeichnet.

Beispiele
SAP_ECC_PRODECC_EU_100S4H_FIN
Währung
Currency
Der Währungscode des Bestellbetrags.
Beschreibung

Dieses Attribut gibt an, in welcher Währung der Bestellwert ausgewiesen wird, etwa USD, EUR oder GBP. Es liefert den notwendigen Kontext für alle Geldbeträge.

Für international tätige Unternehmen ist die Währung eine wichtige Grundlage für korrekte Finanzanalysen. Sie ermöglicht die sachgerechte Aggregation und den Vergleich von Bestellwerten. Alle monetären Kennzahlen müssen im Kontext der jeweiligen Währung interpretiert werden.

Warum das wichtig ist

Liefert den erforderlichen Kontext für alle Geldbeträge und ermöglicht korrekte Finanzanalysen, insbesondere in multinationalen Unternehmen.

Woher beziehen

Tabelle: EKKO, Feld: WAERS

Beispiele
USDEURJPY
Werk
Plant
Der physische Standort oder das Werk, an das die Waren geliefert werden sollen.
Beschreibung

Das Werk ist eine Organisationseinheit und steht für eine Produktionsstätte, ein Lager oder einen anderen Standort, an dem Waren oder Dienstleistungen eingehen.

Die Analyse nach Werk zeigt geografische Unterschiede im Beschaffungsprozess. Sie kann beispielsweise abweichende Lieferzeiten von Lieferanten an bestimmte Standorte aufdecken oder Werke mit ineffizienten Wareneingangsprozessen identifizieren. So lässt sich die Pünktlichkeit des Wareneingangs besser beurteilen.

Warum das wichtig ist

Gibt den Lieferstandort an und eignet sich zur Analyse regionaler Prozessunterschiede und der Logistikleistung.

Woher beziehen

Tabelle: EKPO, Feld: WERKS

Beispiele
100011002000
Erforderlich Empfohlen Optional

Aktivitäten für Purchase to Pay – Bestellung

Diese wichtigen Prozessschritte und Meilensteine sollten Sie im Event Log erfassen. Sie bilden die Grundlage für eine präzise Prozesserkennung und die Identifizierung von Engpässen.
6 Empfohlen 8 Optional
Aktivität Beschreibung
Bestellanforderung angelegt
Diese Aktivität kennzeichnet die Erstellung einer formellen Anforderung für Waren oder Dienstleistungen. Das Ereignis wird explizit erfasst, wenn ein Benutzer ein neues Bestellanforderungsdokument speichert, beispielsweise über die Transaktion ME51N. Dabei entsteht ein eindeutiger Datensatz in der Tabelle EBAN.
Warum das wichtig ist

Dies ist der zentrale Startpunkt des Beschaffungsprozesses. Die Zeitspanne zwischen diesem Ereignis und der Erstellung der Bestellung zeigt, wie effizient interne Bedarfe in konkrete Bestellungen überführt werden.

Woher beziehen

Das Ereignis wird erfasst, sobald ein Eintrag in der Kopftabelle der Bestellanforderungen (EBAN) angelegt wird. Erstellungsdatum (EBAN-BADAT) und -Uhrzeit dienen als Timestamp.

Erfassung

Ermitteln Sie anhand des Erstellungsdatums neue Einträge in der Tabelle EBAN.

Ereignistyp explicit
Bestellung abgeschlossen
Dieses Ereignis zeigt an, dass eine Bestellposition als vollständig geliefert gilt. Es wird üblicherweise daraus abgeleitet, dass das Kennzeichen „Lieferung abgeschlossen“ für die Bestellposition automatisch oder manuell gesetzt wurde.
Warum das wichtig ist

Diese Aktivität bildet den logischen Endpunkt der Auftragsabwicklung. Sie ist entscheidend für die Berechnung der gesamten Zykluszeit der Bestellung von der Erstellung bis zum Abschluss.

Woher beziehen

Das Ereignis wird aus den Änderungsbelegen (CDHDR/CDPOS) abgeleitet, die erfassen, wann das Kennzeichen „Lieferung abgeschlossen“ (EKPO-ELIKZ) für eine Bestellposition auf „X“ gesetzt wird. Wenn die letzte Position als abgeschlossen markiert ist, kann dies den Abschluss der gesamten Bestellung anzeigen.

Erfassung

Ermitteln Sie anhand der Änderungsbelege den Timestamp, zu dem das Kennzeichen EKPO-ELIKZ gesetzt wird.

Ereignistyp inferred
Bestellung an Lieferanten gesendet
Diese Aktivität kennzeichnet den Zeitpunkt, zu dem die genehmigte Bestellung offiziell an den Lieferanten übermittelt wird, beispielsweise per EDI, E-Mail oder Druck. Das Ereignis wird explizit in den Nachrichtensteuerungstabellen erfasst, wenn eine Ausgabenachricht erfolgreich verarbeitet wurde.
Warum das wichtig ist

Dieser wichtige Meilenstein markiert den Beginn der Lieferzeit des Lieferanten. Die Zeitspanne von diesem Ereignis bis zum Wareneingang ist entscheidend für die Bewertung der Lieferantenleistung und der Pünktlichkeit.

Woher beziehen

Das Ereignis wird in der Nachrichtenstatustabelle (NAST) erfasst. Als Timestamp dienen NAST-DATVR und NAST-UHRVR, wenn der Verarbeitungsstatus (NAST-VSTAT) für die betreffende Bestellausgabe auf „1“ (erfolgreich verarbeitet) steht.

Erfassung

Verwenden Sie den Verarbeitungs-Timestamp der Ausgabenachricht zur Bestellung aus der Tabelle NAST.

Ereignistyp explicit
Bestellung angelegt
Diese Aktivität kennzeichnet die Erstellung eines formellen Bestelldokuments, das einen verbindlichen Vertrag mit einem Lieferanten darstellt. Das Ereignis wird explizit erfasst, wenn ein Benutzer eine Bestellung anlegt und speichert, beispielsweise über die Transaktion ME21N. Dabei entstehen Einträge in den Tabellen EKKO und EKPO.
Warum das wichtig ist

Damit beginnt offiziell der Lebenszyklus der Bestellung. Dieser Meilenstein dient als Grundlage für die Messung der Umwandlungszeit von der Bestellanforderung zur Bestellung sowie der gesamten Auftragsabwicklungszeit.

Woher beziehen

Der Timestamp wird aus dem Erstellungsdatum (EKKO-AEDAT) in der Kopftabelle der Bestellungen (EKKO) für die jeweilige Bestellnummer (EKKO-EBELN) übernommen.

Erfassung

Verwenden Sie für jede neue Bestellung den Erstellungs-Timestamp aus der Tabelle EKKO.

Ereignistyp explicit
Bestellung genehmigt
Dieses Ereignis steht für die endgültige Genehmigung der Bestellung. Damit kann sie an den Lieferanten gesendet werden. Dieser wichtige Meilenstein wird üblicherweise aus einer Änderung des Freigabestatus der Bestellung in den Status „vollständig freigegeben“ oder „genehmigt“ abgeleitet.
Warum das wichtig ist

Diese Aktivität ist entscheidend für die Berechnung der Kennzahl zur Genehmigungszykluszeit der Bestellung und für das Erkennen von Engpässen im Genehmigungs-Workflow. Sie ist Voraussetzung für die meisten nachfolgenden Aktivitäten, etwa das Senden der Bestellung an den Lieferanten.

Woher beziehen

Das Ereignis wird ermittelt, indem die Änderungsbelege (CDHDR/CDPOS) zur Kopftabelle der Bestellung (EKKO) daraufhin geprüft werden, wann der endgültige Freigabecode angewendet oder der Gesamtfreigabestatus (EKKO-FRGKE) auf „freigegeben“ gesetzt wurde.

Erfassung

Ermitteln Sie den Timestamp, zu dem sich der Gesamtfreigabestatus der Bestellung (EKKO-FRGKE) in den endgültigen Genehmigungsstatus ändert.

Ereignistyp inferred
Wareneingang gebucht
Diese Aktivität kennzeichnet den physischen Eingang von Waren eines Lieferanten zu einer bestimmten Bestellung. Die Buchung des Wareneingangs ist eine explizite Aktion, beispielsweise über die Transaktion MIGO. Dabei wird ein Materialbeleg angelegt und der Bestand aktualisiert.
Warum das wichtig ist

Dieser wichtige Meilenstein dient der Überwachung der Lieferanten-Lieferleistung und markiert den Beginn der Rechnungsprüfung. Er wird zur Berechnung der pünktlichen Lieferungen und der Pünktlichkeit des Wareneingangs herangezogen.

Woher beziehen

Das Ereignis wird beim Anlegen eines Materialbelegs erfasst. Als Timestamp dient das Buchungsdatum (MKPF-BUDAT) oder das Erstellungsdatum (MKPF-CPUDT) aus der Materialbelegkopftabelle (MKPF). Über die Positionstabelle (MSEG) ist der Beleg mit der Bestellung verknüpft.

Erfassung

Verwenden Sie den Buchungs- oder Erstellungs-Timestamp aus der Tabelle MKPF für Materialbelege mit Bezug zur Bestellung.

Ereignistyp explicit
Bestellanforderung genehmigt
Dieses Ereignis steht für die formelle Genehmigung einer Bestellanforderung. Damit ist sie zur Umwandlung in eine Bestellung freigegeben. Das Ereignis wird aus Änderungen der Freigabestatusfelder in den Daten der Bestellanforderung abgeleitet, die SAPs Freigabestrategie-Workflow erfasst.
Warum das wichtig ist

Die Erfassung von Genehmigungen ist entscheidend, um Engpässe in der Phase vor der Bestellung zu erkennen und die Einhaltung der Genehmigungsrichtlinien sicherzustellen. Verzögerungen wirken sich unmittelbar auf die gesamte Zykluszeit der Beschaffung aus.

Woher beziehen

Das Ereignis wird aus den Änderungsbelegen zur Tabelle der Bestellanforderungen (EBAN) abgeleitet. Dabei werden insbesondere Änderungen an den Freigabestatusfeldern überwacht, etwa EBAN-FRGZU. Alternativ lassen sich die Änderungsbelege in CDHDR/CDPOS für das Objekt EBAN analysieren.

Erfassung

Überwachen Sie die Änderungsbelege zu den Freigabestatusfeldern in EBAN, um den Timestamp der endgültigen Genehmigung zu ermitteln.

Ereignistyp inferred
Bestellung abgelehnt
Diese Aktivität tritt ein, wenn ein Genehmigender eine Bestellung während des Genehmigungs-Workflows ablehnt. Das Ereignis wird aus einer Statusänderung in den Freigabedaten der Bestellung abgeleitet, die eine Ablehnung anzeigt.
Warum das wichtig ist

Die Erfassung von Ablehnungen hilft, Probleme mit der Datenqualität der Bestellung, Verstöße gegen Richtlinien oder Schwachstellen in der Genehmigungsmatrix zu erkennen. Häufig sind Nacharbeiten und längere Durchlaufzeiten die Folge.

Woher beziehen

Das Ereignis wird aus Änderungsbelegen (CDHDR/CDPOS) zum Freigabestatus der Bestellung abgeleitet. Eine Ablehnung wird üblicherweise erfasst, wenn ein Freigabecode zurückgenommen oder ein bestimmter Ablehnungsstatus gesetzt wird.

Erfassung

Überwachen Sie die Änderungsbelege auf die Rücknahme eines Freigabecodes oder eine Statusänderung, die eine Ablehnung anzeigt.

Ereignistyp inferred
Bestellung geändert
Dieses Ereignis umfasst alle Änderungen an einer Bestellung nach ihrer erstmaligen Erstellung, etwa an Menge, Preis oder Lieferterminen. SAP protokolliert diese Änderungen explizit im Änderungsbelegsystem.
Warum das wichtig ist

Häufige Änderungen, insbesondere nach der Genehmigung, weisen auf ineffiziente Abläufe, unzureichende Planung oder nachträgliche Ausweitung des Umfangs hin. Diese Aktivität ist eine wichtige Grundlage für das Dashboard zu Nacharbeiten und Änderungen an Bestellungen sowie für die zugehörigen Kennzahlen.

Woher beziehen

Die Änderungen werden explizit in den Tabellen für Änderungsbelegkopf (CDHDR) und -positionen (CDPOS) zum Bestellobjekt (EINKBELEG) protokolliert. Für jede Änderung wird ein neuer Eintrag mit Timestamp angelegt.

Erfassung

Extrahieren Sie Änderungsereignisse und Timestamps aus den Tabellen CDHDR und CDPOS, die mit der Bestellnummer verknüpft sind.

Ereignistyp explicit
Bestellung gelöscht
Dieses Ereignis steht für die Stornierung oder logische Löschung einer Bestellposition. Dadurch werden weitere Schritte wie Wareneingang oder Rechnungsstellung verhindert. Das Ereignis wird abgeleitet, wenn das Löschkennzeichen für die Bestellposition gesetzt wird.
Warum das wichtig ist

Diese abschließende Aktivität zeigt an, dass eine Bestellung storniert wurde. Die Analyse, warum und wann Bestellungen gelöscht werden, kann Probleme in der Bedarfsplanung oder Lieferantenauswahl aufdecken.

Woher beziehen

Das Ereignis wird aus Änderungsbelegen (CDHDR/CDPOS) abgeleitet, die zeigen, dass das Löschkennzeichen (EKPO-LOEKZ) für eine Bestellposition auf „L“ gesetzt wurde.

Erfassung

Ermitteln Sie anhand der Änderungsbelege den Timestamp, zu dem das Kennzeichen EKPO-LOEKZ gesetzt wird.

Ereignistyp inferred
Genehmigung der Bestellung angefordert
Dieses Ereignis zeigt an, dass eine angelegte oder geänderte Bestellung gemäß der konfigurierten Freigabestrategie zur Genehmigung eingereicht wurde. Es wird abgeleitet, wenn die Freigabestrategie ausgelöst wird und die Bestellung den Status „Genehmigung ausstehend“ erhält.
Warum das wichtig ist

Wenn Sie die Erstellung der Bestellung vom Beginn des Genehmigungsprozesses unterscheiden, lässt sich die Kennzahl für die Genehmigungszykluszeit präzise messen. So werden Verzögerungen vor dem Start des Genehmigungs-Workflows sichtbar.

Woher beziehen

Das Ereignis wird aus Änderungsbelegen (CDHDR/CDPOS) zur Bestellung (Objekt EINKBELEG) abgeleitet, die die erstmalige Festlegung eines Freigabestatus zeigen. Es kann auch ermittelt werden, wenn der Gesamtfreigabestatus (EKKO-FRGKE) erstmals auf einen Wert gesetzt wird, der einen laufenden Genehmigungsprozess anzeigt.

Erfassung

Ermitteln Sie den ersten Eintrag im Änderungsbeleg, der die Freigabestrategie für die Bestellung auslöst.

Ereignistyp inferred
Leistungserfassung eingegeben
Bei dienstleistungsbezogenen Bestellungen steht diese Aktivität für die Bestätigung, dass die Leistungen erbracht wurden. Das Ereignis wird explizit durch das Anlegen eines Leistungserfassungsblatts erfasst, beispielsweise über die Transaktion ML81N.
Warum das wichtig ist

Bei Dienstleistungen entspricht dies dem Wareneingang und ist entscheidend für die Überwachung der Erfüllung von Dienstleistungsaufträgen. Damit wird der Zahlungsprozess für die Dienstleistung angestoßen.

Woher beziehen

Der Timestamp wird aus dem Erstellungsdatum (ESSR-ERDAT) in der Kopftabelle des Leistungserfassungsblatts (ESSR) übernommen. Die Verknüpfung zur Bestellung befindet sich in der Tabelle ESLL.

Erfassung

Verwenden Sie den Erstellungs-Timestamp aus der Tabelle ESSR für Leistungserfassungsblätter mit Bezug zur Bestellung.

Ereignistyp explicit
Qualitätsprüfung durchgeführt
Dieses Ereignis zeigt an, dass die eingegangenen Waren einer Qualitätsprüfung unterzogen wurden. Es wird üblicherweise abgeleitet, wenn für ein Prüflos, das beim Wareneingang angelegt wurde, im Qualitätsmanagement eine Verwendungsentscheidung getroffen wird.
Warum das wichtig ist

In Branchen mit hohen Qualitätsanforderungen hilft diese Aktivität, Dauer und Ergebnisse des Prüfprozesses zu analysieren. Verzögerungen können Engpässe zwischen Wareneingang und Verfügbarkeit der Waren verursachen.

Woher beziehen

Das Ereignis wird aus dem Qualitätsmanagement abgeleitet. Beim Wareneingang wird ein Prüflos angelegt (Tabelle QALS). Die Aktivität wird durch das Anlegen einer Verwendungsentscheidung (Tabelle QAVE) gekennzeichnet, die einen Timestamp enthält.

Erfassung

Ermitteln Sie den Timestamp der Verwendungsentscheidung in der Tabelle QAVE für das mit dem Materialbeleg verknüpfte Prüflos.

Ereignistyp inferred
Waren zurückgesendet
Dieses Ereignis steht für die Rücksendung zuvor eingegangener Waren an den Lieferanten, häufig aufgrund von Qualitätsproblemen oder einer fehlerhaften Lieferung. Es wird explizit durch die Buchung eines Materialbelegs mit einer speziellen Retourenbewegungsart erfasst.
Warum das wichtig ist

Diese Aktivität weist auf Probleme mit der Lieferantenqualität oder der Bestellgenauigkeit hin und ist ein wichtiger Indikator für Nacharbeiten im Prozess. Sie ist entscheidend für die Berechnung der Kennzahl zur Abweichungsquote beim Wareneingang.

Woher beziehen

Das Ereignis wird in den Materialbelegtabellen (MKPF/MSEG) erfasst, wenn eine Retourenbewegungsart verwendet wird, etwa „122“ für die Rücklieferung an den Lieferanten. Als Timestamp dient das Buchungsdatum (MKPF-BUDAT).

Erfassung

Ermitteln Sie Materialbelege mit einer Retourenbewegungsart, beispielsweise 122, die sich auf die ursprüngliche Bestellung beziehen.

Ereignistyp explicit
Empfohlen Optional

Anleitungen zum Datenexport

So exportieren Sie Ihre Daten aus SAP ECC

Möchten Sie loslegen?

Mit diesem Template erhalten Sie eine Vorlage zur Optimierung Ihres Purchase-to-Pay-Prozesses für Bestellungen in SAP ECC. Nutzen Sie Ihre Daten, um Erkenntnisse zu gewinnen und die Effizienz zu steigern.

Optimieren Sie P2P-Bestellungen: Starten Sie noch heute Ihre kostenlose Testphase

Beseitigen Sie Engpässe und verkürzen Sie die Zykluszeit um mindestens 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten startklar.