> Kontinuierliche Prozessverbesserung > Purchase to Pay Anforderung > SAP Ariba > Daten Template

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

SAP Ariba

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Purchase to Pay – Bestellanforderung(19) Aktivitäten für Purchase to Pay – Bestellanforderung(13) Anleitungen zur Datenextraktion(2)

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

Dieses umfassende Daten-Template unterstützt Sie dabei, die erforderlichen Informationen für die Analyse Ihres Purchase-to-Pay-Prozesses für Bestellanforderungen effizient zu erfassen und zu strukturieren. Es beschreibt die wesentlichen Attribute und Aktivitäten für ein aussagekräftiges Event Log und ermöglicht so eine detaillierte Analyse der Prozessleistung. Außerdem finden Sie praktische Hinweise zum Extrahieren der Daten aus Ihrem Quellsystem, damit Sie mit Process Mining beginnen können.

Empfohlene Attribute für eine umfassende Analyse
Wichtige Prozessaktivitäten und Meilensteine, die Sie erfassen sollten
Detaillierte Anleitung zum Extrahieren der Daten aus Ihrem System

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute für Purchase to Pay – Bestellanforderung

Diese empfohlenen Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Bestellanforderungen im Purchase-to-Pay-Prozess umfassend zu analysieren und keine wichtigen Informationen zu übersehen.

3 Erforderlich 8 Empfohlen 8 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des konkreten Geschäftsereignisses, das zu einem bestimmten Zeitpunkt im Lebenszyklus der Bestellanforderung eingetreten ist.
Beschreibung Der Aktivitätsname bezeichnet einen einzelnen Schritt oder Meilenstein im Bestellanforderungsprozess, zum Beispiel „Bestellanforderung erstellt“, „Genehmigungsschritt genehmigt“ oder „Bestellanforderung geschlossen“. Die Daten stammen in der Regel aus Event Logs, Statusänderungen oder bestimmten Benutzeraktionen in SAP Ariba. Dieses Attribut ist entscheidend für die Erstellung der Prozesslandkarte, die den Ablauf der Aktivitäten visualisiert. Durch die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten können Analysten häufige Prozesswege, Engpässe, Abweichungen von der Standardvorgehensweise und Bereiche mit Nacharbeit erkennen. Es bildet die Grundlage jeder Process-Mining-Analyse. Warum das wichtig ist Das Attribut definiert die Prozessschritte und ermöglicht es, den Workflow der Bestellanforderung zu visualisieren und zu analysieren, einschließlich Engpässen und Abweichungen. Woher beziehen Die Daten stammen aus Event Logs, Audit Trails oder Aufzeichnungen von Statusänderungen in SAP Ariba. Häufig sind sie den Tabellen mit Kopf- und Positionsdaten von Bestellanforderungen zugeordnet. Beispiele Bestellanforderung übermitteltGenehmigungsschritt genehmigtBestellanforderung geändertBestellung erstellt
	Ereignis-Timestamp EventTimestamp	Das genaue Datum und die Uhrzeit, zu denen die Aktivität stattgefunden hat. Dieser Timestamp dient als Grundlage für die zeitliche Reihenfolge der Ereignisse.
Beschreibung Der Ereignis-Timestamp hält den genauen Zeitpunkt einer Aktivität fest. Diese präzisen Daten sind erforderlich, um Ereignisse innerhalb eines Cases korrekt anzuordnen und die Dauer zwischen einzelnen Prozessschritten zu berechnen. In der Analyse bildet der Timestamp die Grundlage für alle zeitbezogenen Berechnungen, darunter Zyklus-, Warte- und Bearbeitungszeiten. Er fließt in Dashboards zur Leistungsanalyse ein, etwa zur „Genehmigungszykluszeit der Bestellanforderung“ und zur „Engpassanalyse der Genehmigungswege“. Die Genauigkeit dieses Feldes wirkt sich unmittelbar auf die Zuverlässigkeit aller Leistungskennzahlen aus. Warum das wichtig ist Dieses Attribut gibt die chronologische Reihenfolge der Ereignisse an und bildet die Grundlage für alle Leistungs- und Zeitberechnungen, etwa zu Zykluszeiten und Engpässen. Woher beziehen Der Timestamp findet sich in SAP Ariba üblicherweise zusammen mit Aktivitäts- oder Statusänderungsdatensätzen in Audit-Trail- oder Transaktionsprotokolltabellen. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	Purchase Requisition ID PurchaseRequisitionId	Die eindeutige Kennung eines Bestellanforderungsdokuments. Sie dient als primäre Case-ID des Prozesses.
Beschreibung Die Purchase Requisition ID ist der zentrale Schlüssel, der alle Aktivitäten zu einer einzelnen Waren- oder Dienstleistungsanforderung verknüpft. Jede in SAP Ariba erstellte Bestellanforderung erhält eine eindeutige ID, die während des gesamten Lebenszyklus gleich bleibt, von der Erstellung und Übermittlung bis zur endgültigen Genehmigung, Ablehnung oder Schließung. Für Process Mining ist dieses Attribut grundlegend, um Ereignisse einem Case zuzuordnen. Es ermöglicht, den vollständigen Ablauf jeder Bestellanforderung zu rekonstruieren und Zykluszeiten präzise zu berechnen, Prozessvarianten zu erkennen und Nacharbeitsschleifen zu analysieren. Ohne diese Kennung ließen sich Ereignisse verschiedener Bestellanforderungen nicht voneinander unterscheiden. Warum das wichtig ist Diese zentrale Case-ID verknüpft alle zugehörigen Aktivitäten. So lässt sich der gesamte Bestellanforderungsprozess für jede einzelne Anfrage analysieren. Woher beziehen Dieses Feld ist ein Primärschlüssel in den Haupttabellen mit den Kopfdaten von Bestellanforderungen in der Datenstruktur von SAP Ariba. Beispiele PR-102345PR-102346PR-102347
	Ablehnungsgrund RejectionReason	Der von einer genehmigenden Person angegebene Grund für die Ablehnung einer Bestellanforderung oder eines Genehmigungsschritts.
Beschreibung Bei einer Ablehnung geben genehmigende Personen häufig einen Grund an, entweder als Freitext oder aus einer vorgegebenen Liste. Dieses Attribut erfasst diese wichtige Rückmeldung. Die Daten bilden die Grundlage für das Dashboard „Analyse der Ablehnungsquote bei Bestellanforderungen“. Die häufigsten Ablehnungsgründe zeigen die Ursachen für Prozessfehler, etwa eine falsche Kontierung, eine unzureichende Begründung oder Budgetprobleme. Diese Erkenntnisse können dazu beitragen, Anfordernde besser zu schulen und die Qualität der Erstanträge zu verbessern. So sinkt der Aufwand für Nacharbeit. Warum das wichtig ist Das Attribut zeigt direkt, warum Bestellanforderungen scheitern. So können Sie Ursachen analysieren, Nacharbeit verringern und die Quote korrekt bearbeiteter Anträge beim ersten Versuch erhöhen. Woher beziehen Lesen Sie die SAP-Ariba-Dokumentation. Diese Informationen werden üblicherweise im Kommentar- oder Verlaufsbereich des Ablehnungsereignisses erfasst. Beispiele Falsches SachkontoBudget überschrittenUnzureichende BegründungDoppelte Anfrage
	Abteilung des Anfordernden RequesterDepartment	Die Fachabteilung oder Kostenstelle des Mitarbeitenden, der die Bestellanforderung erstellt hat.
Beschreibung Dieses Attribut ordnet die Anfrage organisatorisch ein und zeigt, aus welchem Unternehmensbereich sie stammt. Es wird üblicherweise aus dem Benutzerprofil des Anfordernden abgeleitet oder direkt im Formular der Bestellanforderung angegeben. Bei der Analyse dient es als wichtige Dimension zum Filtern und Vergleichen. In fast allen Dashboards, etwa zur „Genehmigungszykluszeit der Bestellanforderung“ und zur „Analyse der Ablehnungsquote bei Bestellanforderungen“, lassen sich Kennzahlen nach Abteilung aufschlüsseln. So erkennen Sie, welche Abteilungen die längsten Zykluszeiten, die höchsten Änderungsquoten oder die meisten nicht richtlinienkonformen Anfragen aufweisen. Das hilft, gezielte Prozessverbesserungen einzuleiten. Warum das wichtig ist Das Attribut ermöglicht den Vergleich der Prozessleistung in verschiedenen Unternehmensbereichen und macht abteilungsspezifische Probleme oder bewährte Vorgehensweisen sichtbar. Woher beziehen Lesen Sie die SAP-Ariba-Dokumentation. Die Daten sind in der Regel in den Kopfdaten der Bestellanforderung verfügbar und häufig über das Benutzerprofil des Anfordernden verknüpft. Beispiele MarketingIT-BetriebFinanzenForschung und Entwicklung
	Artikelkategorie ItemCategory	Die Kategorie der angeforderten Waren oder Dienstleistungen, zum Beispiel „IT-Hardware“, „Bürobedarf“ oder „Professionelle Dienstleistungen“.
Beschreibung Die Artikelkategorie gibt an, was beschafft wird. Diese Einordnung hilft, Ausgabenmuster zu verstehen und Beschaffungsstrategien sowie Richtlinien auf die jeweilige Kategorie abzustimmen. In Process Mining ist dieses Attribut wichtig für das Dashboard „Analyse von Änderungen an Bestellanforderungen“. Es zeigt, ob bestimmte Artikelkategorien häufiger geändert werden, was auf unklare Spezifikationen oder schwankende Preise hindeuten kann. Außerdem können Sie die Prozessleistung, etwa Genehmigungszeiten, für verschiedene Beschaffungsarten vergleichen und feststellen, ob bestimmte Kategorien häufiger zu Verzögerungen führen. Warum das wichtig ist Das Attribut ermöglicht Analysen nach Art der beschafften Waren oder Dienstleistungen und hilft, kategoriespezifische Engpässe oder Compliance-Probleme zu erkennen. Woher beziehen Lesen Sie die SAP-Ariba-Dokumentation. Diese Informationen finden Sie üblicherweise auf Positionsebene der Bestellanforderung. Beispiele IT-HardwareBeratungsleistungenBürobedarfMarketingmaterialien
	Dringlichkeitsstufe UrgencyLevel	Ein Indikator für die Priorität der Bestellanforderung, zum Beispiel „Normal“, „Dringend“ oder „Kritisch“.
Beschreibung Die Dringlichkeitsstufe wird häufig als Prioritätskennzeichen dargestellt und gibt an, wie schnell eine Anfrage aus geschäftlicher Sicht bearbeitet werden muss. In der Regel legt der Anfordernde sie fest, damit dringende Anliegen zeitnah bearbeitet werden. Dieses Attribut ist die zentrale Grundlage für das Dashboard „Überwachung dringender Bestellanforderungen“ und die KPI „Bearbeitungszeit dringender Bestellanforderungen“. Damit lassen sich die Zykluszeiten dringender und regulärer Bestellanforderungen direkt vergleichen und die Wirksamkeit der Priorisierung überprüfen. Die Analyse von Abweichungen und Verzögerungen bei dringenden Anfragen hilft, die Geschäftskontinuität sicherzustellen. Warum das wichtig ist Das Attribut ermöglicht eine priorisierte Analyse und zeigt, ob Bestellanforderungen mit hoher Priorität schneller bearbeitet werden, damit dringende Geschäftsanforderungen erfüllt werden. Woher beziehen Lesen Sie die SAP-Ariba-Dokumentation. Dieses Feld lässt sich häufig im Formular zur Erstellung einer Bestellanforderung auswählen. Beispiele HochMittelNiedrig
	Ereignisbenutzer EventUser	Die Benutzer-ID oder der Name der Person, die die Aktivität ausgeführt hat, zum Beispiel der Anfordernde oder die genehmigende Person.
Beschreibung Das Attribut „Ereignisbenutzer“ gibt an, wer für einen bestimmten Prozessschritt verantwortlich war. Das kann der Mitarbeitende sein, der die Bestellanforderung übermittelt hat, die Führungskraft, die sie genehmigt hat, oder die für die Bearbeitung zuständige Person im Einkauf. Dieses Attribut ist wichtig für die Analyse der Arbeitslast, Leistungsvergleiche und die Ermittlung von Schulungsbedarf. Es ermöglicht das Dashboard „Auslastung und Leistung der Genehmigenden“, in dem sich Genehmigungszeiten nach Benutzer analysieren lassen. Außerdem können Sie damit Verzögerungen oder Abweichungen untersuchen und bestimmten Personen oder Teams zuordnen. Warum das wichtig ist Das Attribut ermöglicht die Analyse der Arbeitslastverteilung, der Benutzerleistung und der Ressourcenzuweisung. So lassen sich Engpässe erkennen, die durch bestimmte Benutzer oder Teams entstehen. Woher beziehen Lesen Sie die SAP-Ariba-Dokumentation. Die Daten sind häufig in Audit-Trail- oder Verlaufstabellen gespeichert und mit den Stammdaten der Benutzer verknüpft. Beispiele john.doejane.smithmanager123
	Genehmigungs-Workflow-Pfad ApprovalWorkflowPath	Die vorgegebene Reihenfolge der Genehmigungsschritte, die eine Bestellanforderung durchlaufen soll.
Beschreibung Dieses Attribut legt anhand von Merkmalen wie Wert, Artikelkategorie und Abteilung die Standardprozessvariante oder Genehmigungsmatrix fest, der eine Bestellanforderung folgen soll. Es bildet den Sollprozess oder Happy Path ab. Das Attribut ist grundlegend für die Konformitätsprüfung und wird im Dashboard „Compliance-Übersicht für Bestellanforderungen“ verwendet. Durch den Vergleich der tatsächlichen Aktivitäten mit dem erwarteten Genehmigungs-Workflow-Pfad können Analysten automatisch Richtlinienverstöße, nicht autorisierte Genehmigungsschritte oder ausgelassene Kontrollen erkennen. Das ist wichtig für die interne Revision und das Risikomanagement. Warum das wichtig ist Das Attribut definiert den einzuhaltenden Standardprozess. Die Konformitätsprüfung kann damit Abweichungen und Richtlinienverstöße automatisch erkennen. Woher beziehen Lesen Sie die SAP-Ariba-Dokumentation. Das Attribut lässt sich möglicherweise aus der Konfiguration der Genehmigungsmatrix oder einem bestimmten Feld der Bestellanforderung ableiten. Beispiele Standard-IT > 10.000 $Marketingdienstleistungen < 5.000 $Investitionsausgaben > 100.000 $
	Gesamtbetrag der Bestellanforderung TotalRequisitionAmount	Der Gesamtwert der Bestellanforderung.
Beschreibung Dieses Attribut erfasst den finanziellen Gesamtwert der Anfrage. Es liefert wichtigen Geschäftskontext für die Einordnung und Priorisierung von Bestellanforderungen. Der Abgleich von Prozesskennzahlen mit diesem Wert kann wichtige Muster aufdecken. Bei Bestellanforderungen mit hohem Wert gelten möglicherweise andere, strengere Genehmigungswege oder längere Zykluszeiten. Das Attribut ist wichtig, um die finanziellen Auswirkungen von Prozessineffizienzen zu verstehen und Bestellanforderungen für Vergleichsanalysen nach Wertklassen zu gruppieren. Warum das wichtig ist Das Attribut liefert wichtigen finanziellen Kontext. So lässt sich analysieren, wie sich der Wert einer Bestellanforderung auf den Prozess auswirkt, etwa auf Genehmigungszeiten und die Komplexität des Workflows. Woher beziehen Lesen Sie die SAP-Ariba-Dokumentation. Dieses Standardfeld befindet sich im Kopf der Bestellanforderung. Beispiele 1500.0025000.5099.95
	Status der Bestellanforderung RequisitionStatus	Der aktuelle Status der Bestellanforderung in ihrem Lebenszyklus.
Beschreibung Dieses Attribut gibt den Echtzeitstatus einer Bestellanforderung wieder, zum Beispiel „In Bearbeitung“, „Eingereicht“, „Genehmigt“, „Abgelehnt“ oder „Geschlossen“. Es zeigt zum Zeitpunkt der Datenextraktion, an welcher Stelle des Prozesses sich jeder Case befindet. Process Mining rekonstruiert den historischen Ablauf. Für die operative Überwachung ist dieses Attribut jedoch unverzichtbar. Es bildet die Datengrundlage für den „Live-Tracker für den Status von Bestellanforderungen“. Damit sehen Manager die aktuelle Auslastung und erkennen, welche Anforderungen ins Stocken geraten oder schon lange offen sind. So erhalten sie unmittelbar einen Überblick über die aktiven Bestellanforderungen und können gezielt handeln. Warum das wichtig ist Ermöglicht die Echtzeitüberwachung der Bestellanforderungen. So lassen sich Anfragen erkennen und bearbeiten, die ins Stocken geraten oder schon lange offen sind, bevor daraus Probleme entstehen. Woher beziehen Lesen Sie die SAP-Ariba-Dokumentation. Dies ist ein standardmäßiges Statusfeld im Kopf der Bestellanforderung. Beispiele GenehmigtEingereichtAbgelehntIn Genehmigung
	Automatisiert IsAutomated	Ein boolesches Kennzeichen, das angibt, ob eine Aktivität von einem System oder einem menschlichen Benutzer ausgeführt wurde.
Beschreibung Dieses Attribut unterscheidet automatisierte Systemereignisse, etwa automatische Genehmigungen oder systemgesteuerte Statusänderungen, von manuellen Aktivitäten der Benutzer. Das ist wichtig, um den Automatisierungsgrad des Prozesses zu verstehen. In der Analyse können Sie damit den menschlichen Arbeitsaufwand genau messen und weitere Automatisierungsmöglichkeiten erkennen. Wenn Sie beispielsweise nach manuellen Aktivitäten filtern, lassen sich die benutzerbezogenen Bearbeitungszeiten präzise berechnen. Außerdem können Sie prüfen, ob automatisierte Regeln im Prozess wie vorgesehen funktionieren. Warum das wichtig ist Unterscheidet zwischen menschlichen und systemseitigen Aktionen. Das ist wichtig, um den Automatisierungsgrad zu messen und weitere Automatisierungsmöglichkeiten zu erkennen. Woher beziehen Dieses Attribut wird in der Regel daraus abgeleitet, ob der „Event User“ einer System- oder Batch-Benutzer-ID entspricht. Beispiele truefalse
	Bestellnummer PurchaseOrderId	Kennung der Bestellung, die aus der genehmigten Bestellanforderung erstellt wurde.
Beschreibung Dieses Attribut verknüpft eine Bestellanforderung mit dem nachgelagerten Dokument, der Bestellung (PO). Ist eine Bestellnummer vorhanden, wurde die Anfrage erfolgreich in eine Bestellung umgewandelt. Das ist wichtig für die durchgängige Prozessanalyse über die Phase der Bestellanforderung hinaus. Mit diesem Attribut lässt sich die KPI „Durchlaufzeit von der Bestellanforderung bis zur Bestellung“ berechnen, indem das Ereignis zur Erstellung der Bestellanforderung mit dem Ereignis zur Erstellung der Bestellung verknüpft wird. So erhalten Sie einen umfassenden Überblick über die vorgelagerten Schritte im Beschaffungszyklus. Warum das wichtig ist Verknüpft die Bestellanforderung mit der daraus erstellten Bestellung. So lässt sich die Durchlaufzeit vom Eingang der Anforderung bis zur Bestellung messen. Woher beziehen Lesen Sie die SAP-Ariba-Dokumentation. Dieses Feld ist in der Regel in den Positionsdaten der Bestellanforderung gespeichert, sobald eine Bestellung erstellt wurde. Beispiele PO-4500012345PO-4500012346PO-4500012347
	Geändert IsAmended	Ein boolesches Kennzeichen, das angibt, ob die Bestellanforderung nach ihrer ersten Einreichung mindestens einmal geändert wurde.
Beschreibung Dieses berechnete Attribut kennzeichnet Cases, in denen mindestens einmal die Aktivität „Bestellanforderung geändert“ aufgetreten ist. Damit lassen sich Bestellanforderungen, die im Laufe ihres Lebenszyklus geändert werden mussten, einfach markieren. Das Kennzeichen dient zur Berechnung der KPI „Änderungsquote von Bestellanforderungen“. Zählen Analysten die Cases mit dem Wert „true“, können sie den Umfang der Nacharbeit leicht messen und mögliche Ursachen anhand anderer Attribute wie „Name des Anfordernden“ oder „Artikelkategorie“ untersuchen. Warum das wichtig ist Vereinfacht die Berechnung der KPI zur Änderungsquote. So lässt sich die Nacharbeit quantifizieren und erkennen, wo klarere Angaben zu Beginn des Prozesses nötig sind. Woher beziehen Der Wert ist „true“, wenn ein Case mindestens eine Aktivität „Bestellanforderung geändert“ enthält, andernfalls „false“. Beispiele truefalse
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp gibt an, wann die Daten dieses Datensatzes zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung Dieses Attribut zeigt Datum und Uhrzeit der letzten Datenextraktion oder Aktualisierung eines Ereignisses. So ist nachvollziehbar, wie aktuell die analysierten Daten sind. Das ist besonders wichtig, wenn laufende Prozesse überwacht werden. Analysten können damit beurteilen, wie aktuell die gewonnenen Erkenntnisse sind. Für Dashboards wie den „Live-Statusmonitor für Bestellanforderungen“ ist das Feld entscheidend, damit Benutzer den Aktualitätsstand der angezeigten Informationen einschätzen können. So lassen sich Erwartungen an die Aktualität der Daten steuern. Warum das wichtig ist Das Attribut zeigt, wie aktuell die Daten sind. Das ist wichtig, um die Aktualität und Relevanz der Process-Mining-Erkenntnisse zu beurteilen. Woher beziehen Dieser Timestamp wird üblicherweise während der Datenübernahme generiert und jedem Datensatz hinzugefügt. Beispiele 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	Nacharbeit IsRework	Ein boolesches Kennzeichen, das angibt, ob bei der Bestellanforderung Nacharbeit anfiel, etwa aufgrund einer Ablehnung oder mehrerer Änderungen.
Beschreibung Dieses berechnete Attribut erfasst Ineffizienzen umfassender als „IsAmended“. Es kennzeichnet Cases mit erheblichen Nacharbeitsschleifen. Dazu zählen in der Regel mindestens ein Ereignis „Genehmigungsschritt abgelehnt“ oder mehrere Ereignisse „Bestellanforderung geändert“. Das Kennzeichen dient zur Berechnung der KPI „Nacharbeitsquote bei Bestellanforderungen“. Damit lassen sich die versteckten Kosten und Verzögerungen durch Prozessfehler quantifizieren. Die Analyse der als Nacharbeit gekennzeichneten Cases kann Muster bei bestimmten Genehmigenden, Abteilungen oder Anfragetypen aufdecken, die den Prozess erschweren. Warum das wichtig ist Kennzeichnet Cases mit erheblichen Prozessproblemen, etwa Ablehnungen. So können Sie die Ursachen von Ineffizienzen und Verzögerungen gezielt untersuchen. Woher beziehen Der Wert ist „true“, wenn ein Case eine Ablehnungsaktivität oder mehr als eine Änderungsaktivität enthält. Beispiele truefalse
	Name des Anfordernden RequesterName	Name des Mitarbeitenden, der die Bestellanforderung erstellt hat.
Beschreibung Dieses Attribut auf Case-Ebene gibt an, wer die Bestellanforderung erstellt hat. Es zeigt, von wem die Anfrage stammt und welche Person daran beteiligt ist. In der Analyse können Sie den Prozess nach Anfordernden filtern und deren Verhalten untersuchen. Die Dashboards „Analyse der Änderungen an Bestellanforderungen“ und „Analyse der Ablehnungsquote von Bestellanforderungen“ verwenden das Attribut beispielsweise, um Personen zu ermitteln, die aufgrund häufiger Änderungen oder Ablehnungen zusätzliche Schulungen benötigen. So lassen sich Rückmeldungen und Verbesserungsmaßnahmen gezielt auf einzelne Personen abstimmen. Warum das wichtig ist Gibt an, wer die Anfrage erstellt hat. So können Sie Prozessablauf und Qualität für einzelne Anfordernde analysieren. Woher beziehen Lesen Sie die SAP-Ariba-Dokumentation. Dies ist ein standardmäßiges Feld im Kopf der Bestellanforderung, das häufig mit „Erstellt von“ oder „Anfordernder“ bezeichnet wird. Beispiele Alice WilliamsBob MillerCharles Brown
	Name des Genehmigenden ApproverName	Name des Benutzers, der für die Genehmigung eines bestimmten Workflow-Schritts zuständig ist.
Beschreibung Dieses Attribut gibt an, welcher Manager oder Stakeholder für eine Genehmigungsaktivität zuständig ist. Anders als das allgemeine Attribut „Event User“ bezieht es sich ausschließlich auf Genehmigungsaufgaben. Das Attribut ist eine wichtige Grundlage für das Dashboard „Arbeitsauslastung und Leistung der Genehmigenden“. Damit lässt sich erfassen, wie viele Bestellanforderungen jeder Genehmigende bearbeitet und wie lange die Genehmigung im Durchschnitt dauert. So können Sie individuelle Engpässe erkennen, die Arbeitslast ausgewogen verteilen und die Leistung anhand von Zielvorgaben bewerten. Warum das wichtig ist Zeigt, wer für eine Genehmigung zuständig ist. So können Sie die Arbeitslast gezielt verteilen und die Leistung der Genehmigenden detailliert analysieren. Woher beziehen Lesen Sie die SAP-Ariba-Dokumentation. Diese Informationen sind in den mit der Bestellanforderung verknüpften Daten zum Genehmigungsablauf gespeichert. Beispiele Sarah JonesDavid ChenMaria Garcia
	Quellsystem SourceSystem	Das führende System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt an, woher die Prozessdaten stammen. In dieser Ansicht lautet der Wert durchgehend „SAP Ariba“. Wenn Daten aus mehreren Systemen zusammengeführt werden, ist das Feld wichtig, um die Datenherkunft nachzuvollziehen und Fehler zu beheben. Bei der Analyse bestätigt es den Ursprung der Daten. Außerdem können Sie damit Prozesse aus verschiedenen Systemen filtern oder vergleichen. Das schafft Transparenz und Vertrauen in die Datenquelle und erleichtert es, Beteiligte von der Analyse zu überzeugen. Warum das wichtig ist Das Attribut gibt die Herkunft der Daten an. Das ist wichtig für die Data Governance, die Fehlerbehebung und das Verständnis des Analysekontexts. Woher beziehen Dieser statische Wert wird üblicherweise bei der Datenextraktion und -transformation hinzugefügt, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele SAP AribaSAP_ARIBA_P2PAribaCloud

Erforderlich Empfohlen Optional

Aktivitäten für Purchase to Pay – Bestellanforderung

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Prozess präzise zu entdecken und Engpässe zu erkennen.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Bestellanforderung endgültig abgelehnt	Kennzeichnet die endgültige Ablehnung einer Bestellanforderung nach der Prüfung. Damit ist der Prozess abgeschlossen. Das Ereignis wird durch einen Statuswechsel zu „Denied“ erfasst.
Warum das wichtig ist Dies ist ein wichtiger Endpunkt für gescheiterte Vorgänge. Die Analyse abgelehnter Bestellanforderungen ist entscheidend für die KPI „Ablehnungsquote bei Bestellanforderungen“. Sie hilft, Muster zu erkennen und die Qualität der Anfragen zu verbessern. Woher beziehen Das Ereignis lässt sich aus dem Dokumentverlauf von Ariba ableiten, in dem der abschließende Statuswechsel der Bestellanforderung zu „Denied“ erfasst wird. Erfassung Ermitteln Sie den Timestamp, zu dem das Statusfeld der Bestellanforderung auf „Denied“ wechselt. Ereignistyp inferred
	Bestellanforderung erstellt	Erfasst die erstmalige Erstellung eines Bestellanforderungsdokuments durch einen Benutzer. Das Ereignis wird protokolliert, sobald die Bestellanforderung erstmals im Status „Composing“ oder als Entwurf gespeichert wird.
Warum das wichtig ist Dies ist der Ausgangspunkt im Lebenszyklus der Bestellanforderung. Die Zeit von der Erstellung bis zur Übermittlung zeigt, wie effizient Benutzer arbeiten und wo Schulungsbedarf besteht. Woher beziehen Der Timestamp stammt aus dem Erstellungszeitpunkt des Purchase-Requisition-Objekts in SAP Ariba. Er ist in den Kopfdaten des Bestellanforderungsdokuments zu finden und kennzeichnet ein explizites Erstellungsereignis. Erfassung Verwenden Sie den Timestamp „CreateTime“ oder einen entsprechenden Timestamp aus der Kopftabelle des Bestellanforderungsdokuments. Ereignistyp explicit
	Bestellanforderung genehmigt	Kennzeichnet die endgültige Genehmigung der Bestellanforderung, nachdem sie alle Schritte des Workflows erfolgreich durchlaufen hat. Das Ereignis wird durch einen Statuswechsel zu „Approved“ erfasst.
Warum das wichtig ist Dieser wichtige Meilenstein markiert das Ende der Genehmigungsphase. Er bildet den Endpunkt für die Messung der „Durchschnittlichen Genehmigungszeit der Bestellanforderung“ und zeigt an, dass die Erstellung einer Bestellung möglich ist. Woher beziehen Das Ereignis lässt sich aus dem Dokumentverlauf von Ariba ableiten, in dem der abschließende Statuswechsel der Bestellanforderung zu „Approved“ erfasst wird. Erfassung Ermitteln Sie den Timestamp, zu dem das Statusfeld der Bestellanforderung auf „Approved“ wechselt. Ereignistyp inferred
	Bestellanforderung geschlossen	Kennzeichnet den endgültigen administrativen Abschluss einer Bestellanforderung, nachdem alle zugehörigen Vorgänge wie Bestellung und Wareneingang abgeschlossen sind. Das Ereignis wird durch einen abschließenden Statuswechsel zu „Closed“ erfasst.
Warum das wichtig ist Damit endet der gesamte Lebenszyklus der Bestellanforderung. Die Analyse der Zeit von der Erstellung der Bestellung bis zum Abschluss kann Engpässe in nachgelagerten Wareneingangs- oder Rechnungsprozessen aufdecken. Woher beziehen Das Ereignis lässt sich aus dem Dokumentverlauf von Ariba ableiten, in dem der Statuswechsel der Bestellanforderung zu „Closed“ erfasst wird. Erfassung Ermitteln Sie den Timestamp, zu dem das Statusfeld der Bestellanforderung auf „Closed“ wechselt. Ereignistyp inferred
	Bestellanforderung übermittelt	Kennzeichnet die formelle Übermittlung der Bestellanforderung durch den Anfordernden an den Genehmigungs-Workflow. Das Ereignis wird durch einen Statuswechsel von „Composing“ zu „Submitted“ erfasst.
Warum das wichtig ist Dieser wichtige Meilenstein setzt den Genehmigungsprozess in Gang. Er ist entscheidend für die Berechnung der „Genehmigungszykluszeit der Bestellanforderung“ und der „Durchlaufzeit von der Erstellung bis zur Übermittlung“. Woher beziehen Das Ereignis lässt sich aus dem Dokumentverlauf oder dem Audit Log von Ariba ableiten. Dort werden der Statuswechsel der Bestellanforderung zu „Submitted“ und der Timestamp dieser Änderung erfasst. Erfassung Ermitteln Sie den Timestamp, zu dem das Statusfeld der Bestellanforderung erstmals auf „Submitted“ wechselt. Ereignistyp inferred
	Bestellung erstellt	Kennzeichnet die erfolgreiche Umwandlung einer genehmigten Bestellanforderung in eine Bestellung. Das Ereignis wird erfasst, wenn ein Bestelldokument erstellt wird, das auf die Bestellanforderung verweist.
Warum das wichtig ist Dies ist das wichtigste Erfolgsergebnis des Bestellanforderungsprozesses. Es ist entscheidend für die Messung der KPI „Durchlaufzeit von der Bestellanforderung bis zur Bestellung“. Woher beziehen Dies ist ein explizites Ereignis. Verwendet wird der Erstellungs-Timestamp des Bestelldokuments, das direkt mit der ursprünglichen Purchase Requisition ID verknüpft ist oder darauf verweist. Erfassung Suchen Sie in der Bestellkopftabelle die mit der Bestellanforderung verknüpfte Bestellung und verwenden Sie deren Erstellungs-Timestamp. Ereignistyp explicit
	Bestellanforderung an den Einkauf weitergeleitet	Dieses Ereignis tritt ein, wenn eine genehmigte Bestellanforderung an die Einkaufsabteilung weitergeleitet wird, damit diese vor der Erstellung einer Bestellung ein Beschaffungsverfahren wie eine RFQ durchführt. Es wird beispielsweise durch einen Statuswechsel zu „Sourcing“ erfasst.
Warum das wichtig ist Das Ereignis kennzeichnet einen wichtigen Prozesszweig für hochwertige oder nicht standardisierte Artikel. Es hilft dabei, den Beitrag der Einkaufsabteilung zur Durchlaufzeit zu analysieren. Woher beziehen Das Ereignis lässt sich aus einem Statuswechsel der Bestellanforderung ableiten, der anzeigt, dass sie an den Einkauf weitergeleitet wurde. Dies ist bei einer Integration von Ariba Buying mit Ariba Sourcing üblich. Erfassung Ermitteln Sie den Timestamp, zu dem das Statusfeld der Bestellanforderung auf „Sourcing“ oder einen ähnlichen benutzerdefinierten Status wechselt. Ereignistyp inferred
	Bestellanforderung geändert	Dieses Ereignis tritt ein, wenn ein Benutzer eine Bestellanforderung nach der Übermittlung ändert, häufig als Reaktion auf eine Ablehnung oder Rückfrage. Es wird erfasst, wenn das Dokument bearbeitet und erneut übermittelt wird.
Warum das wichtig ist Das Ereignis macht Nacharbeit und Ineffizienzen im Prozess sichtbar. Häufige Änderungen deuten auf unklare ursprüngliche Anforderungen oder Richtlinien hin und wirken sich auf die KPI „Änderungsquote der Bestellanforderung“ aus. Woher beziehen Das Ereignis lässt sich anhand der Versionsdaten in Ariba ableiten. Bei jeder Änderung wird eine neue Version des Bestellanforderungsdokuments erstellt. Eine Versionsnummer über 1 weist auf eine Änderung hin. Erfassung Prüfen Sie, ob nach dem ersten Status „Submitted“ neue Versionen der Bestellanforderung erstellt wurden. Der Timestamp der neuen Version ist der Ereigniszeitpunkt. Ereignistyp inferred
	Bestellanforderung zurückgezogen	Dieses Ereignis tritt ein, wenn der ursprüngliche Anfordernde eine übermittelte Bestellanforderung zurückzieht, bevor sie vollständig genehmigt wurde. Es wird durch einen Statuswechsel zu „Withdrawn“ oder „Canceled“ erfasst.
Warum das wichtig ist Das Ereignis kennzeichnet einen vom Benutzer veranlassten Abbruch des Prozesses. Die Analyse der Gründe für zurückgezogene Bestellanforderungen kann Probleme durch veränderte Geschäftsanforderungen oder lange Genehmigungszeiten aufdecken. Woher beziehen Das Ereignis lässt sich aus dem Dokumentverlauf oder dem Audit Log von Ariba ableiten. Dort wird der Statuswechsel der Bestellanforderung zu „Withdrawn“ erfasst. Erfassung Ermitteln Sie den Timestamp, zu dem das Statusfeld der Bestellanforderung auf „Withdrawn“ wechselt. Ereignistyp inferred
	Bestellposition bestellt	Kennzeichnet den Statuswechsel einer einzelnen Position in einer Bestellanforderung zu „Ordered“, nachdem sie in eine Bestellung aufgenommen wurde. Damit lässt sich der Prozess detaillierter verfolgen als nur anhand der Erstellung der Bestellkopfdaten.
Warum das wichtig ist So lassen sich Teilbestellungen und Verzögerungen auf Positionsebene analysieren, die bei einer ausschließlichen Betrachtung der Bestellkopfdaten nicht sichtbar wären. Das ist besonders bei Bestellanforderungen mit vielen Positionen hilfreich, die über verschiedene Bestellungen erfüllt werden. Woher beziehen Das Ereignis lässt sich aus dem Statuswechsel des Positionsobjekts der Bestellanforderung ableiten. Sobald dafür eine Bestellung erstellt wurde, wird der Status der Position auf „Ordered“ gesetzt. Erfassung Ermitteln Sie den Timestamp, zu dem das Statusfeld der Position in der Bestellanforderung auf „Ordered“ wechselt. Ereignistyp inferred
	Genehmigungsschritt abgelehnt	Kennzeichnet die negative Entscheidung in einem Genehmigungsschritt: Eine genehmigende Person hat die Bestellanforderung abgelehnt, in der Regel mit der Folge, dass sie zur Änderung zurückgesendet wird. Die Aktion wird explizit als „Deny“ protokolliert.
Warum das wichtig ist Das Ereignis macht eine wichtige Ursache für Nacharbeit und Verzögerungen sichtbar. Die Analyse dieser Ereignisse ist entscheidend, um die „Nacharbeitsquote bei Bestellanforderungen“ und die Gründe für Ablehnungen zu verstehen. Woher beziehen Die Daten stammen aus den Tabellen zum Genehmigungsablauf in Ariba. Der Timestamp wird protokolliert, wenn eine genehmigende Person für die zugewiesene Aufgabe die Aktion „Deny“ oder „Reject“ ausführt. Erfassung Verwenden Sie den Timestamp der Aktion „Deny“, der im Genehmigungsverlauf für den jeweiligen Schritt erfasst ist. Ereignistyp explicit
	Genehmigungsschritt genehmigt	Kennzeichnet die positive Entscheidung in einem Genehmigungsschritt: Eine genehmigende Person hat den ihr zugewiesenen Teil der Bestellanforderung genehmigt. Die Genehmigungsaktion wird explizit protokolliert.
Warum das wichtig ist Das Ereignis misst die Bearbeitungszeit einzelner genehmigender Personen. Diese Daten sind wichtig, um die „Durchschnittliche Dauer eines Genehmigungsschritts“ zu berechnen und die Auslastung der Genehmigenden zu beurteilen. Woher beziehen Die Daten stammen aus den Tabellen zum Genehmigungsablauf in Ariba. Der Timestamp wird protokolliert, wenn eine genehmigende Person für die zugewiesene Aufgabe die Aktion „Approve“ ausführt. Erfassung Verwenden Sie den Timestamp der Aktion „Approve“, der im Genehmigungsverlauf für den jeweiligen Schritt erfasst ist. Ereignistyp explicit
	Genehmigungsschritt gestartet	Zeigt an, dass eine Bestellanforderung an eine genehmigende Person oder eine Genehmigungswarteschlange weitergeleitet wurde und auf Bearbeitung wartet. Das Ereignis wird erfasst, wenn eine Genehmigungsanfrage erstellt und zugewiesen wird.
Warum das wichtig ist Das Ereignis liefert detaillierte Erkenntnisse zum Genehmigungs-Workflow. Es ist entscheidend, um Wartezeiten in Warteschlangen zu berechnen und die Schritte zu ermitteln, die Engpässe in der „Engpassanalyse der Genehmigungswege“ verursachen. Woher beziehen Die Daten stammen aus den Tabellen zum Genehmigungsablauf in Ariba. Dort werden Erstellung und Zuweisung einzelner Genehmigungsaufgaben für die Bestellanforderung protokolliert. Erfassung Verwenden Sie den Erstellungs-Timestamp des Genehmigungsanfragedatensatzes, der der Bestellanforderung und dem jeweiligen Genehmigungsschritt zugeordnet ist. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus SAP Ariba

Schritte

Melden Sie sich bei SAP Ariba an: Öffnen Sie Ihre SAP-Ariba-Umgebung mit einem Benutzerkonto, das analytische Berichte erstellen und ausführen darf, zum Beispiel mit der Rolle „Reporting Analyst“.
Öffnen Sie den Bereich für analytische Berichte: Wechseln Sie im Haupt-Dashboard zum Berichtsbereich. Diesen finden Sie üblicherweise unter einem Menüpunkt wie „Reporting“, „Analytics“ oder „Manage“ > „Analytical Reports“.
Erstellen Sie einen neuen Bericht: Starten Sie die Erstellung eines analytischen Berichts. Wählen Sie dazu den primären Datenbereich aus, der häufig als „Fact“ bezeichnet wird. Wählen Sie den Fact für Bestellanforderungen, zum Beispiel „[Requisition]“ oder einen ähnlichen Namen aus Ihrer Ariba-Konfiguration.
Fügen Sie Datenfelder hinzu: Ergänzen Sie im Berichtseditor die benötigten Spalten. Um alle erforderlichen Informationen abzurufen, müssen Sie mehrere Datenquellen (Facts) verknüpfen. Ein typischer Bericht verbindet „[Requisition Fact]“, „[Approval History Fact]“ und „[Purchase Order Fact]“ über die Requisition-ID. Fügen Sie alle in der Abfragekonfiguration aufgeführten Felder hinzu, einschließlich relevanter Zeitstempel wie Erstellungsdatum, Einreichungsdatum, Genehmigungsdatum und Aktionsdatum aus dem Genehmigungsverlauf.
Legen Sie Filter fest: Begrenzen Sie den Datenumfang mit Filtern. Besonders wichtig ist der Datumsbereich. Filtern Sie nach dem gewünschten Zeitraum für „Requisition Created Date“, zum Beispiel nach den letzten 3 bis 6 Monaten. Ergänzen Sie bei Bedarf weitere Filter, etwa für bestimmte Company Codes oder Realms.
Führen Sie den Bericht aus und exportieren Sie die Rohdaten: Führen Sie den Bericht aus. Exportieren Sie die Ergebnisse nach Abschluss als CSV- oder Excel-Datei. Dieser erste Export liegt in einem breiten Format vor: Eine Zeile enthält jeweils eine Bestellanforderung oder einen Genehmigungseintrag und viele Spalten für verschiedene Datumsangaben und Benutzeraktionen.
Wandeln Sie die Daten ins Event-Log-Format um: Dieser wichtige Schritt erfolgt außerhalb von SAP Ariba. Verwenden Sie beispielsweise Microsoft Excel mit Power Query, ein Python-Skript oder ein anderes Datenaufbereitungstool, um das breite Format in ein langes Format umzuwandeln. Erstellen Sie für jede exportierte Zeitstempelspalte, etwa „Created Date“, „Submitted Date“ oder „Approved Date“, eine eigene Zeile im fertigen Event Log. Dieser Vorgang wird häufig als „Unpivoting“ oder „Melting“ bezeichnet.
Ordnen Sie Aktivitäten und Attribute zu: Erstellen Sie bei der Umwandlung die Spalten ActivityName und EventTimestamp. Wenn Sie beispielsweise die Spalte „Submitted Date“ verarbeiten, erstellen Sie Zeilen, in denen ActivityName den Wert „Requisition Submitted“ und EventTimestamp den Wert aus der Spalte „Submitted Date“ enthält.
Fassen Sie die Daten zusammen und bereinigen Sie sie: Führen Sie die umgewandelten Daten aus allen Zeitstempelspalten in einer Datei zusammen. Stellen Sie sicher, dass PurchaseRequisitionId, ActivityName und EventTimestamp in jeder Zeile korrekt ausgefüllt sind. Entfernen Sie leere Zeilen und beheben Sie Formatierungsfehler.
Speichern Sie die fertige CSV-Datei: Speichern Sie das umgewandelte Event Log als CSV-Datei mit UTF-8-Kodierung. Die Datei kann nun in das Process-Mining-Tool hochgeladen werden.

Konfiguration

Berichtstyp: Analytischer Bericht über die standardmäßige Ariba-Berichtsschnittstelle.
Zentrale Daten-Facts: Kombinieren Sie Daten aus mehreren Facts, in der Regel aus „[Requisition Fact]“, „[Approval History Fact]“ und „[Purchase Order Fact]“. Die genauen Namen können je nach Ariba-Datenmodell abweichen.
Datumsbereich: Filtern Sie nach „Requisition Created Date“ und wählen Sie einen überschaubaren Zeitraum, zum Beispiel 3 bis 6 Monate. Verwenden Sie für erste Tests einen kürzeren Zeitraum, etwa eine Woche.
Wichtige Filter: Filtern Sie immer nach einem bestimmten Datumsbereich. Begrenzen Sie den Datensatz außerdem bei Bedarf nach „Company Code“ oder „Purchasing Organization“, damit er den relevanten Geschäftsbereich abdeckt und der Bericht schneller ausgeführt wird.
Voraussetzungen: Der Benutzer, der den Bericht ausführt, benötigt eine Rolle mit Berechtigungen für das Modul „Analytical Reporting“ und die zugrunde liegenden Daten-Facts zu Bestellanforderungen, Genehmigungen und Bestellungen.

Beispielabfrage config

REPORT CONFIGURATION for SAP Ariba Analytical Reporting

REPORT TYPE: Analytical Report

PRIMARY DATA SOURCE (FACT):
*   [Requisition Fact]

JOINED DATA SOURCES (FACTS):
*   [Approval History Fact] on Requisition ID
*   [Purchase Order Fact] on Requisition ID
*   [Requisition Line Item Fact] on Requisition ID

REPORT FIELDS (COLUMNS TO EXPORT for subsequent transformation):

// Case and General Attributes
*   Requisition.Requisition ID (as PurchaseRequisitionId)
*   Requisition.Status (as RequisitionStatus)
*   Requisition.Requester.Department (as RequesterDepartment)
*   Requisition.Total Cost.Amount (as TotalRequisitionAmount)
*   Requisition.Line Items.Category (as ItemCategory)
*   Requisition.Is Urgent (as UrgencyLevel)
*   Requisition.Approval Flow Name (as ApprovalWorkflowPath)

// Fields for 'Requisition Created'
*   Requisition.Created Date (Timestamp)
*   Requisition.Requester.User ID (User)

// Fields for 'Requisition Submitted'
*   Requisition.Submitted Date (Timestamp)
*   Requisition.Submitter.User ID (User)

// Fields for 'Requisition Amended'
*   Requisition.Last Modified Date (Timestamp) - Note: Requires logic to isolate true amendment events
*   Requisition.Last Modified By.User ID (User)

// Fields for 'Approval Step' activities
*   Approval History.Approval Request Date (Timestamp for 'Approval Step Started')
*   Approval History.Action Date (Timestamp for 'Approval Step Approved'/'Approval Step Rejected')
*   Approval History.Action (Value: 'Approve'/'Deny')
*   Approval History.Approver.User ID (User)
*   Approval History.Comments (for RejectionReason)

// Fields for final status activities
*   Requisition.Approved Date (Timestamp for 'Requisition Approved')
*   Requisition.Denied Date (Timestamp for 'Requisition Denied')
*   Requisition.Withdrawn Date (Timestamp for 'Requisition Withdrawn')
*   Requisition.Closed Date (Timestamp for 'Requisition Closed')

// Fields for downstream activities
*   Requisition.Sourcing Status Date (Timestamp for 'Requisition Sent To Sourcing')
*   Purchase Order.Created Date (Timestamp for 'Purchase Order Created')
*   Purchase Order.Creator.User ID (User for 'Purchase Order Created')
*   Requisition Line Item.Ordered Date (Timestamp for 'Requisition Line Item Ordered')

FILTERS:
*   Requisition.Created Date BETWEEN [Start Date] AND [End Date]
*   Company Code IN ([Your Company Codes])

Schritte

Python-Umgebung einrichten: Stellen Sie sicher, dass Python 3.6 oder neuer installiert ist. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install requests pandas.
API-Zugriff konfigurieren: Registrieren Sie im SAP Ariba Developer Portal eine neue Anwendung. Abonnieren Sie die „Operational Reporting API for Requisitions“ und beschaffen Sie Ihre OAuth-Zugangsdaten: Application Key (API Key), OAuth Client Secret sowie den Base64-codierten String [your_api_key]:[your_client_secret].
Python-Skript anpassen: Öffnen Sie das bereitgestellte Python-Skript. Tragen Sie oben die Platzhalterwerte ein, darunter ARIBA_REALM, BASE_URL, API_KEY und BASE64_CREDS. Legen Sie außerdem mit START_DATE und END_DATE den Zeitraum für die Datenextraktion fest.
Report-Payload festlegen: Prüfen Sie das JSON-Objekt report_payload im Skript. Es definiert den auszuführenden Report. Das Skript ist bereits für RequisitionFactSystemView und die Auswahl der benötigten Aktivitäten und Attribute eingerichtet. Bei Bedarf können Sie weitere Felder oder Filter hinzufügen.
Skript ausführen: Starten Sie das Skript im Terminal mit python your_script_name.py. Zunächst authentifiziert sich das Skript bei Ariba und ruft ein Zugriffstoken ab.
Report-Auftrag übermitteln und überwachen: Das Skript übermittelt die Report-Anfrage automatisch an die Ariba API. Da der Auftrag asynchron ausgeführt wird, fragt das Skript den Status anschließend alle 60 Sekunden bei der Ariba API ab.
Report-Daten herunterladen: Sobald die Ariba API den Auftrag als „COMPLETED“ meldet, lädt das Skript die Ergebnisdaten herunter. Diese liegen in der Regel als ZIP-Datei mit einer CSV-Datei vor.
Daten verarbeiten und transformieren: Das Skript entpackt die Datei und lädt die Rohdaten in einen pandas DataFrame. Anschließend wandelt es die Daten von einem breiten Format mit einer Zeile pro Bestellanforderung und mehreren Datumsspalten in ein langes Event-Log-Format um. Dabei entstehen mehrere Zeilen pro Bestellanforderung, eine für jede Aktivität.
Event Log erstellen: Der transformierte DataFrame ist nun als Event Log mit Spalten wie PurchaseRequisitionId, ActivityName und EventTimestamp strukturiert. Das Skript speichert ihn im selben Verzeichnis wie das Skript unter dem Namen ariba_requisition_event_log.csv.
Upload vorbereiten: Die erstellte CSV-Datei kann jetzt in ProcessMind hochgeladen werden. Achten Sie darauf, dass die Spaltenüberschriften der Zuordnung in Ihrem ProcessMind-Projekt entsprechen.

Konfiguration

API-Endpunkt-URL: Das Skript benötigt die Basis-URL der API Ihrer Ariba-Instanz. Sie hat üblicherweise das Format https://[your-realm].api.ariba.com/api/operationalreporting/v2/. Ersetzen Sie [your-realm] durch den spezifischen Ariba-Realm-Namen Ihres Unternehmens.
Authentifizierung: Für die Extraktion wird OAuth 2.0 verwendet. Geben Sie einen gültigen apiKey, clientSecret und die Zeichenfolge base64EncodedCredentials an, die Sie für Ihre im Ariba Developer Portal registrierte Anwendung erhalten haben.
View-Template: Das Skript verwendet RequisitionFactSystemView. Diese standardmäßige Ariba-Ansicht muss in Ihrer Umgebung aktiviert sein. Außerdem muss Ihr API-Benutzer über die erforderlichen Zugriffsrechte verfügen.
Datumsbereichsfilter: Der Filter creationDate in den Berichtsdaten ist entscheidend, um das Datenvolumen zu begrenzen. Für die erste Extraktion empfiehlt sich ein Zeitraum von 3 bis 6 Monaten. Bei großen Unternehmen sollten Sie die Daten in kleineren monatlichen Paketen extrahieren.
Inkrementelle Ladevorgänge: Passen Sie bei späteren Extraktionen START_DATE und END_DATE an, damit nur neue oder aktualisierte Datensätze abgerufen werden. Das Skript verwaltet inkrementelle Ladevorgänge nicht automatisch. Legen Sie den Datumsbereich daher bei jedem Durchlauf manuell fest.
Voraussetzungen: Für die Erstellung der Anwendung und der Zugangsdaten benötigen Sie einen SAP-Ariba-Benutzer mit der Berechtigung „Developer Portal Access“. Die API-Anwendung selbst benötigt die Rolle „Operational Reporting API User“, um Berichtsaufträge auszuführen.

Beispielabfrage python

import requests
import json
import pandas as pd
import time
import zipfile
import io

class=class="hl-string">"hl-comment"># --- Configuration --- 
class=class="hl-string">"hl-comment"># Replace with your SAP Ariba realm, datacenter-specific URL, and credentials
ARIBA_REALM = class="hl-string">"[Your Ariba Realm]"
BASE_URL = fclass="hl-string">"https://{ARIBA_REALM}.api.ariba.com/api/operationalreporting/v2/"
TOKEN_URL = class="hl-string">"https://api.ariba.com/v2/oauth/token"
API_KEY = class="hl-string">"[Your Application Key]"
BASE64_CREDS = class="hl-string">"[Your Base64-encoded ClientID:ClientSecret]"

class=class="hl-string">"hl-comment"># --- Report Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the extraction
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-06-30T23:59:59Z"

class=class="hl-string">"hl-comment"># The main function to orchestrate the extraction process
def main():
    print(class="hl-string">"1. Acquiring access token...")
    access_token = get_access_token()
    if not access_token:
        return

    print(class="hl-string">"2. Creating asynchronous report job...")
    job_id = create_report_job(access_token)
    if not job_id:
        return

    print(fclass="hl-string">"Job created with ID: {job_id}. Polling for completion...")
    status = poll_job_status(access_token, job_id)

    if status == class="hl-string">'COMPLETED':
        print(class="hl-string">"3. Job completed. Downloading report data...")
        raw_data = download_report(access_token, job_id)
        if raw_data:
            print(class="hl-string">"4. Processing raw data into event log...")
            event_log = process_data(raw_data)
            output_filename = class="hl-string">'ariba_requisition_event_log.csv'
            event_log.to_csv(output_filename, index=False)
            print(fclass="hl-string">"5. Success! Event log saved to {output_filename}")
    else:
        print(fclass="hl-string">"Job failed or timed out with status: {status}")

def get_access_token():
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Basic {BASE64_CREDS}',
        class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded',
    }
    data = {class="hl-string">'grant_type': class="hl-string">'client_credentials'}
    try:
        response = requests.post(TOKEN_URL, headers=headers, data=data)
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        return None

def create_report_job(token):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}',
        class="hl-string">'apiKey': API_KEY,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    report_payload = {
        class="hl-string">"name": class="hl-string">"ProcessMind Requisition Extraction",
        class="hl-string">"viewTemplateName": class="hl-string">"RequisitionFactSystemView",
        class="hl-string">"outputFormat": class="hl-string">"CSV",
        class="hl-string">"filters": {
            class="hl-string">"creationDate": {
                class="hl-string">"from": START_DATE,
                class="hl-string">"to": END_DATE
            }
        },
        class="hl-string">"select": [
            class="hl-string">"RequisitionId", class="hl-string">"StatusString", class="hl-string">"SubmitDate", class="hl-string">"ApprovedState.TimeUpdated",
            class="hl-string">"DeniedState.TimeUpdated", class="hl-string">"SourcingState.TimeUpdated", class="hl-string">"ClosedState.TimeUpdated",
            class="hl-string">"WithdrawnState.TimeUpdated", class="hl-string">"Requester.Name", class="hl-string">"Requester.Department",
            class="hl-string">"TotalCost.Amount", class="hl-string">"LineItems.Category.Name", class="hl-string">"IsUrgent", class="hl-string">"ApprovalFlow.Name",
            class="hl-string">"RequisitionVersion", class="hl-string">"TimeCreated", class="hl-string">"LineItems.OrderedState.TimeUpdated", class="hl-string">"POInfo.POId"
        ]
    }
    try:
        response = requests.post(fclass="hl-string">"{BASE_URL}jobs", headers=headers, json=report_payload)
        response.raise_for_status()
        return response.json().get(class="hl-string">'jobId')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error creating report job: {e}")
        return None

def poll_job_status(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    while True:
        try:
            response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')", headers=headers)
            response.raise_for_status()
            status = response.json().get(class="hl-string">'status')
            print(fclass="hl-string">"Current job status: {status}")
            if status in [class="hl-string">'COMPLETED', class="hl-string">'FAILED', class="hl-string">'CANCELLED']:
                return status
            time.sleep(60) class=class="hl-string">"hl-comment"># Wait 60 seconds before polling again
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error polling job status: {e}")
            return class="hl-string">'FAILED'

def download_report(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    try:
        response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')/result", headers=headers, stream=True)
        response.raise_for_status()
        return response.content
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error downloading report: {e}")
        return None

def process_data(zip_content):
    try:
        with zipfile.ZipFile(io.BytesIO(zip_content)) as z:
            class=class="hl-string">"hl-comment"># Assuming the first file in the zip is the CSV we need
            csv_filename = z.namelist()[0]
            with z.open(csv_filename) as f:
                df = pd.read_csv(f)
    except Exception as e:
        print(fclass="hl-string">"Error reading zipped CSV: {e}")
        return pd.DataFrame()

    class=class="hl-string">"hl-comment"># Rename columns for clarity
    df.rename(columns={
        class="hl-string">'RequisitionId': class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'TimeCreated': class="hl-string">'Timestamp_Created',
        class="hl-string">'SubmitDate': class="hl-string">'Timestamp_Submitted',
        class="hl-string">'ApprovedState.TimeUpdated': class="hl-string">'Timestamp_Approved',
        class="hl-string">'DeniedState.TimeUpdated': class="hl-string">'Timestamp_Denied',
        class="hl-string">'SourcingState.TimeUpdated': class="hl-string">'Timestamp_SentToSourcing',
        class="hl-string">'ClosedState.TimeUpdated': class="hl-string">'Timestamp_Closed',
        class="hl-string">'WithdrawnState.TimeUpdated': class="hl-string">'Timestamp_Withdrawn',
        class="hl-string">'LineItems.OrderedState.TimeUpdated': class="hl-string">'Timestamp_LineItemOrdered',
        class="hl-string">'POInfo.POId': class="hl-string">'POId',
        class="hl-string">'Requester.Name': class="hl-string">'EventUser',
        class="hl-string">'Requester.Department': class="hl-string">'RequesterDepartment',
        class="hl-string">'TotalCost.Amount': class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'LineItems.Category.Name': class="hl-string">'ItemCategory',
        class="hl-string">'IsUrgent': class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalFlow.Name': class="hl-string">'ApprovalWorkflowPath',
        class="hl-string">'StatusString': class="hl-string">'RequisitionStatus'
    }, inplace=True)
    
    class=class="hl-string">"hl-comment"># Create a base dataframe for melting
    id_vars = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventUser', class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel', class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RequisitionStatus', class="hl-string">'RequisitionVersion', class="hl-string">'POId'
    ]
    
    timestamp_cols = [col for col in df.columns if col.startswith(class="hl-string">'Timestamp_')]
    
    class=class="hl-string">"hl-comment"># Melt the dataframe to turn timestamp columns into rows
    event_log = pd.melt(df, id_vars=id_vars, value_vars=timestamp_cols, var_name=class="hl-string">'ActivityName', value_name=class="hl-string">'EventTimestamp')
    
    class=class="hl-string">"hl-comment"># Clean up and format
    event_log.dropna(subset=[class="hl-string">'EventTimestamp'], inplace=True)
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].str.replace(class="hl-string">'Timestamp_', class="hl-string">'Requisition ')
    event_log[class="hl-string">'EventTimestamp'] = pd.to_datetime(event_log[class="hl-string">'EventTimestamp'])

    class=class="hl-string">"hl-comment"># --- Handle specific/derived activities ---
    class=class="hl-string">"hl-comment"># Requisition Amended
    amended_df = df[df[class="hl-string">'RequisitionVersion'] > 1].copy()
    if not amended_df.empty:
        amended_df[class="hl-string">'ActivityName'] = class="hl-string">'Requisition Amended'
        amended_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(amended_df[class="hl-string">'Timestamp_Submitted'])
        event_log = pd.concat([event_log, amended_df[event_log.columns]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Purchase Order Created (use the timestamp of the first line item ordered as a proxy)
    po_created_df = df[df[class="hl-string">'POId'].notna() & df[class="hl-string">'Timestamp_LineItemOrdered'].notna()].copy()
    if not po_created_df.empty:
        po_created_df[class="hl-string">'ActivityName'] = class="hl-string">'Purchase Order Created'
        po_created_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(po_created_df[class="hl-string">'Timestamp_LineItemOrdered'])
        event_log = pd.concat([event_log, po_created_df[event_log.columns]], ignore_index=True)
    
    class=class="hl-string">"hl-comment"># Placeholder for Approval Steps - requires parsing ApprovalRecords not included in this basic script
    class=class="hl-string">"hl-comment"># For now, we only have the final class="hl-string">'Approved' status. This logic can be expanded.
    class=class="hl-string">"hl-comment"># Creating dummy class="hl-string">'Approval Step Started/Approved' for demonstration.
    approval_df = df[df[class="hl-string">'Timestamp_Approved'].notna()].copy()
    if not approval_df.empty:
        approval_started = approval_df.copy()
        approval_started[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Started'
        class=class="hl-string">"hl-comment"># Approximate start time as submit time
        approval_started[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_started[class="hl-string">'Timestamp_Submitted'])
        
        approval_approved = approval_df.copy()
        approval_approved[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Approved'
        approval_approved[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_approved[class="hl-string">'Timestamp_Approved'])
        approval_approved[class="hl-string">'RejectionReason'] = None class=class="hl-string">"hl-comment"># Add column for consistency
        
        event_log = pd.concat([event_log, approval_started[event_log.columns], approval_approved[event_log.columns.tolist() + [class="hl-string">'RejectionReason']]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Add placeholder for RejectionReason, as it's not directly in this view
    if class="hl-string">'RejectionReason' not in event_log.columns:
        event_log[class="hl-string">'RejectionReason'] = None

    class=class="hl-string">"hl-comment"># Final sorting and cleanup
    event_log = event_log.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    
    class=class="hl-string">"hl-comment"># Rename class="hl-string">'Requisition LineItemOrdered' to class="hl-string">'Requisition Line Item Ordered'
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].replace({class="hl-string">'Requisition LineItemOrdered': class="hl-string">'Requisition Line Item Ordered'})

    class=class="hl-string">"hl-comment"># Final column selection
    final_columns = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventUser',
        class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount', class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RejectionReason', class="hl-string">'RequisitionStatus'
    ]
    event_log = event_log[final_columns]

    return event_log

if __name__ == class="hl-string">"__main__":
    main()

Möchten Sie loslegen?

Verwenden Sie dieses Template, um Ihre Daten effizient vorzubereiten und aussagekräftige Erkenntnisse zu Ihrem Purchase-to-Pay-Prozess für Bestellanforderungen zu gewinnen. Beginnen Sie noch heute damit, Ihre Abläufe zu optimieren.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Verzögerungen vermeiden: Optimieren Sie Ihren Purchase-to-Pay-Prozess für Bestellanforderungen

Ermitteln Sie Ineffizienzen in SAP Ariba und verkürzen Sie die Durchlaufzeit um 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Die Einrichtung ist schnell und einfach.

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

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

Attribute für Purchase to Pay – Bestellanforderung

Aktivitäten für Purchase to Pay – Bestellanforderung

Anleitungen zur Datenextraktion

Analytische Berichte in SAP Ariba als CSV/Excel exportieren

Schritte

Konfiguration

Beispielabfrage config

Datenextraktion mit Python-Skript über die Operational Reporting API

Schritte

Konfiguration

Beispielabfrage python

Möchten Sie loslegen?

Verzögerungen vermeiden: Optimieren Sie Ihren Purchase-to-Pay-Prozess für Bestellanforderungen