Datenvorlage: Purchase-to-Pay - Bestellung

Coupa
Datenvorlage: Purchase-to-Pay - Bestellung

Ihr Purchase-to-Pay - Bestelldaten-Template

Dieses Template dient Ihnen als Leitfaden zur präzisen Datenerfassung und -strukturierung für das Process Mining Ihres Purchase-to-Pay - Bestellprozesses in Coupa. Es detailliert die kritischen Attribute, wesentlichen Activities zur Überwachung sowie klare Schritte zur Extraktion dieser Daten für ein vollständiges Event Log.
  • Empfohlene Datenattribute
  • Wichtige Prozessaktivitäten
  • Coupa Datenextraktionsschritte
Neu bei Event Logs? Erfahren Sie wie man ein Process Mining Event Log erstellt.

Purchase to Pay - Bestellattribute

Dies sind die wesentlichen Datenfelder, die für Ihr Event Log empfohlen werden, um eine gründliche Analyse Ihres Purchase to Pay – Bestellprozesses zu ermöglichen.
5 Erforderlich 5 Empfohlen 12 Optional
Name Beschreibung
Aktivität
ActivityName
Der Name des spezifischen Events oder der Task, der zu einem bestimmten Zeitpunkt im Lebenszyklus der Bestellung registriert wurde.
Beschreibung

Der Aktivitätsname beschreibt einen einzelnen Schritt im Purchase to Pay-Prozess, wie z. B. Bestellung genehmigt oder Wareneingang gebucht. Diese Abfolge von Aktivitäten bildet den Prozessfluss für jede Bestellung.

Dieses Attribut ist grundlegend für Process Mining, da es verwendet wird, um die Prozesslandkarte zu erstellen, Prozessvarianten zu entdecken und die Häufigkeit und Abfolge von Ereignissen zu analysieren. Es hilft, Engpässe, Rework-Loops und Abweichungen vom Standardprozessfluss zu identifizieren. Zum Beispiel kann die Analyse der Abfolge von Bestellung geändert-Aktivitäten Ineffizienzen in der Bestellgenauigkeit aufdecken.

Warum es wichtig ist

Es definiert die Schritte im Prozess und ermöglicht die Visualisierung des Prozessflusses sowie die Identifizierung von Bottlenecks, Nacharbeiten und Abweichungen.

Woher erhalten

Abgeleitet aus Event Logs, Audit Trails oder Statusänderungsprotokollen, die mit Bestellungsobjekten in Coupa verbunden sind.

Beispiele
Bestellanforderung genehmigtBestellung eingereichtWareneingang gebuchtRechnung für Bestellung erhalten
Bestellung
PurchaseOrderNumber
Die eindeutige Kennung für eine Bestellung, die als primärer Case-Identifikator für den Prozess dient.
Beschreibung

Die Bestellnummer ist der zentrale Case-Identifikator, der alle Aktivitäten von der ursprünglichen Anfrage bis zur endgültigen Bestätigung des Wareneingangs oder der Dienstleistungsannahme verbindet. Jede eindeutige Bestellnummer repräsentiert eine einzelne Instanz des Beschaffungsprozesses.

In der Process Mining-Analyse ist dieses Attribut entscheidend, um den End-to-End-Verlauf jedes Einkaufs nachzuvollziehen. Es ermöglicht Analysten, Prozesslandkarten zu visualisieren, Varianten zu identifizieren und Case-basierte KPIs, wie die gesamte cycle time für eine Bestellung, zu berechnen. Alle Events und zugehörigen Daten werden unter diesem Identifikator zusammengefasst, um eine kohärente Sicht auf den Prozess zu erstellen.

Warum es wichtig ist

Es ist unerlässlich für die Verfolgung des gesamten Lebenszyklus jedes Einkaufs und ermöglicht die Rekonstruktion einzelner Prozessinstanzen für eine detaillierte Analyse.

Woher erhalten

Dies ist ein Standard-Primärschlüsselfeld für das Bestellobjekt innerhalb von Coupa.

Beispiele
PO-2023-00123PO-2023-00456PO-2023-00789
Startzeit
EventTime
Der genaue Timestamp, der angibt, wann eine Aktivität oder ein Event aufgetreten ist.
Beschreibung

Die Ereigniszeit zeichnet das Datum und die Uhrzeit auf, zu der eine spezifische Aktivität ausgeführt wurde. Für jede Aktivität im Prozess gibt es einen entsprechenden Timestamp, der ihr Auftreten markiert.

Dieses Attribut ist entscheidend für alle zeitbasierten Analysen im Process Mining. Es wird verwendet, um Durchlaufzeiten zwischen Aktivitäten zu berechnen, die Prozessdauer zu messen und Verzögerungen zu identifizieren. Zum Beispiel wird die Zeitdifferenz zwischen den Timestamps 'Bestellung erstellt' und 'Bestellung genehmigt' verwendet, um den KPI für die Durchlaufzeit der PO-Genehmigung zu berechnen.

Warum es wichtig ist

Es liefert den zeitlichen Kontext für jedes Event, was entscheidend ist für die Berechnung von Cycle Times, die Analyse der Performance und das Erkennen von Bottlenecks.

Woher erhalten

Befindet sich in den Event Logs oder Audit Trails von Coupa, typischerweise verknüpft mit jeder Statusänderung oder Aktion, die an einer Bestellung vorgenommen wurde.

Beispiele
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp, der den Zeitpunkt der letzten Aktualisierung der Daten für diesen Prozess angibt.
Beschreibung

Dieses Attribut erfasst den Zeitpunkt der letzten Aktualisierung des Datensatzes aus dem Quellsystem. Es ist ein Metadatenfeld, das sich auf den gesamten Datensatz und nicht auf einzelne Events bezieht.

In jedem analytischen Dashboard ist dieser Timestamp entscheidend, damit Benutzer die Aktualität der angezeigten Daten verstehen. Er schafft Vertrauen, dass die Erkenntnisse auf den neuesten Informationen basieren, und hilft, die Erwartungen der Benutzer an die Datenaktualität zu steuern. Typischerweise wird er prominent in Dashboards angezeigt.

Warum es wichtig ist

Informiert Benutzer über die Aktualität der Daten und stellt sicher, dass sie verstehen, wie aktuell die Prozessanalyse und KPIs sind.

Woher erhalten

Dieser Timestamp wird von der ETL-Pipeline (Datenextraktion und -ladung) generiert und gespeichert, wenn sie läuft.

Beispiele
2023-11-01T05:00:00Z
Quellsystem
SourceSystem
Das System, aus dem die Prozessdaten extrahiert wurden.
Beschreibung

Dieses Attribut identifiziert das Ursprungsinformationssystem, in dem die Event-Daten aufgezeichnet wurden. Für diesen Prozess wäre der Wert durchgängig „Coupa“.

In Unternehmensumgebungen, in denen Daten aus mehreren Systemen stammen können (z. B. Coupa für die Beschaffung, ein anderes ERP für die Rechnungsstellung), hilft dieses Attribut, Datenquellen zu unterscheiden. Es gewährleistet Klarheit in der Datenherkunft und kann verwendet werden, um die Analyse für eine spezifische Systemsicht des Prozesses zu filtern.

Warum es wichtig ist

Es bietet entscheidenden Kontext zur Datenherkunft, gewährleistet die Nachverfolgbarkeit und ermöglicht eine ordnungsgemäße Data Governance, insbesondere in Multi-System-Landschaften.

Woher erhalten

Dies ist ein statischer Wert, der typischerweise während des Datenextraktions- und Transformationsprozesses hinzugefügt wird, um den Datensatz zu kennzeichnen.

Beispiele
Coupa
Abteilung
Department
Die Geschäftsabteilung oder Kostenstelle, der die Bestellung zugerechnet wird.
Beschreibung

Das Attribut Abteilung gibt die Organisationseinheit an, die den Kauf initiiert hat oder dessen Kosten tragen wird. Dies ist oft mit dem Anfragenden oder den Kostenstelleninformationen auf den Bestellpositionen verknüpft.

Diese Dimension ist wesentlich für die Segmentierung der Prozessanalyse und von KPIs. Sie ermöglicht Managern, die Prozesseffizienz, Compliance und Ausgabemuster in verschiedenen Bereichen der Organisation zu vergleichen. Zum Beispiel verwendet das Dashboard 'Ausgabenanalyse nach Einkaufskategorie' die Abteilung, um zu zeigen, wie verschiedene Geschäftsbereiche ihre Budgets ausgeben.

Warum es wichtig ist

Es ermöglicht die Filterung und den Vergleich von Prozess- und Ausgabenanalysen über verschiedene Geschäftsbereiche hinweg, wodurch Abweichungen in Effizienz und Compliance aufgedeckt werden.

Woher erhalten

Verfügbar im Bestellkopf oder den Bestellpositionen in Coupa, oft verknüpft mit einer Kostenstelle oder einer Organisationseinheit.

Beispiele
MarketingInformationstechnologieVorgängeFinanzen
Benutzer
User
Die Benutzer-ID oder der Name der Person, die die Aktivität ausgeführt hat, z. B. ein Genehmiger oder Anforderer.
Beschreibung

Dieses Attribut identifiziert die Person, die für die Ausführung eines spezifischen Events im Prozess verantwortlich ist. Dies könnte die Person sein, die die Bestellung entworfen hat, der Manager, der sie genehmigt hat, oder der Sachbearbeiter, der den Wareneingang gebucht hat.

Die Analyse der Leistung nach Benutzer hilft, Schulungsbedarfe, leistungsstarke Einzelpersonen und die Arbeitslastverteilung zu identifizieren. Zum Beispiel verwendet das Dashboard „PO Approval Cycle Time Performance“ dieses Attribut, um die Genehmigungszeiten nach spezifischen Genehmigern aufzuschlüsseln und hervorzuheben, wer möglicherweise ein Bottleneck im Prozess ist.

Warum es wichtig ist

Es ermöglicht die Analyse der Prozess-Performance nach Individuum oder Rolle, wodurch Bottlenecks, Schulungsmöglichkeiten und Probleme bei der Ressourcenallokation identifiziert werden können.

Woher erhalten

Verknüpft mit jedem Event im Bestellaudit-Trail oder den History-Logs in Coupa. Felder wie 'Erstellt von', 'Genehmigt von' oder 'Aktualisiert von' sind häufige Quellen.

Beispiele
j.doea.smithm.jones
Einkaufskategorie
PurchaseCategory
Die Klassifizierung der gekauften Waren oder Dienstleistungen, wie z. B. IT Hardware oder Professional Services.
Beschreibung

Eine Purchase Category, auch bekannt als Warengruppe oder Materialgruppe, ist eine Klassifizierung zur Gruppierung ähnlicher Einkaufsarten. Diese strukturierten Daten ermöglichen eine systematische Analyse von Ausgaben und Beschaffungsprozessen.

Im Process Mining ist dieses Attribut eine leistungsstarke Dimension für Filterung und Segmentierung. Das Spend Analysis by Purchase Category Dashboard stützt sich darauf, um Ausgabenmuster aufzuschlüsseln. Es kann auch aufzeigen, ob bestimmte Kategorien (z.B. komplexe Dienstleistungen) längere cycle times oder höhere Änderungsraten aufweisen als andere (z.B. Standard-Büromaterial).

Warum es wichtig ist

Es ermöglicht die Ausgaben- und Prozessanalyse nach Kategorie, was hilft, Beschaffungsmuster zu identifizieren, mit Lieferanten zu verhandeln und Prozesskontrollen anzupassen.

Woher erhalten

Typischerweise auf der Bestellpositionsebene in Coupa zu finden, oft verknüpft mit einem Warengruppenschlüssel oder Einkaufskatalog.

Beispiele
IT-HardwareBüromaterialProfessionelle DienstleistungenMarketingmaterialien
Gesamtbestellwert
TotalOrderAmount
Der gesamte monetäre Wert der Bestellung.
Beschreibung

Dieses Attribut repräsentiert die Gesamtkosten aller in der Bestellung aufgeführten Waren und Dienstleistungen, ausgedrückt in einer bestimmten Währung. Es ist ein fallbezogenes Attribut, das sich auf die gesamte Bestellung bezieht.

Diese Finanzdaten sind entscheidend für die Ausgabenanalyse und die Priorisierung von Prozessverbesserungsinitiativen. Hochwertige Bestellungen erfordern möglicherweise eine genauere Prüfung oder andere Genehmigungswege. Es wird direkt im Dashboard 'Ausgabenanalyse nach Einkaufskategorie' verwendet und ist eine Komponente zur Berechnung des KPI 'Ausgabenanteil bei Nicht-Bevorzugten Lieferanten'.

Warum es wichtig ist

Bietet den finanziellen Kontext für jeden Einkauf, ermöglicht Ausgabenanalysen, die Priorisierung hochwertiger Bestellungen und die Bewertung der finanziellen Auswirkungen.

Woher erhalten

Verfügbar im Bestellkopf in Coupa, typischerweise als 'Gesamtbetrag' oder 'Endbetrag'.

Beispiele
1500.00250.7512500.50
Lieferantenname
VendorName
Der Name des Lieferanten oder Anbieters, von dem Waren oder Dienstleistungen bezogen werden.
Beschreibung

Der Lieferantenname identifiziert die externe Partei, die die Artikel auf der Bestellung liefert. Diese Information ist grundlegend für die Beschaffungsanalyse.

Die Analyse der Prozessleistung nach Lieferant ist entscheidend für das Lieferantenbeziehungsmanagement. Sie hilft bei der Bewertung der „Lieferanten-Lieferzeit-Leistung“ (Supplier Lead Time Performance), der Identifizierung von Verzögerungen bei „Wareneingangsprozessverzögerungen“ (Goods Receipt Process Delays) und der Bewertung der Lieferantenqualität durch die „Warenrücksendequote“ (Goods Return Rate). Dieses Attribut ist auch entscheidend für die Berechnung des KPIs „Ausgaben nach Nicht-Präferenzlieferanten-Verhältnis“ (Spend by Non-Preferred Vendor Ratio).

Warum es wichtig ist

Ermöglicht die Lieferantenleistungsanalyse und hilft dabei, die Lieferantenauswahl zu optimieren, bessere Konditionen auszuhandeln sowie leistungsstarke oder leistungsschwache Anbieter zu identifizieren.

Woher erhalten

Ein Standardfeld im Bestellkopf in Coupa, verknüpft mit den Lieferantenstammdaten.

Beispiele
Global Office SuppliesTech Solutions Inc.Fortschrittliche IndustrieteileCreative Marketing Agency
Ablehnungsgrund
RejectionReason
Der angegebene Grund, wenn eine Bestellanforderung oder Bestellung während eines Genehmigungsschritts abgelehnt wird.
Beschreibung

Wenn ein Genehmiger eine Bestellung ablehnt, gibt er oft einen Grund für die Ablehnung an. Dieses Attribut erfasst diese textuelle Erklärung, wie z.B. 'Falscher Budgetcode' oder 'Überschreitet Ausgabenlimit'.

Die Analyse der Ablehnungsgründe bietet direkte Einblicke in die Grundursachen von Nacharbeit und Prozessfehlern. Diese qualitativen Daten können verwendet werden, um häufige Fehler im Anforderungsprozess zu identifizieren, was zu gezielten Schulungen oder Systemverbesserungen führt, um zukünftige Ablehnungen zu verhindern und die Genehmigungsquote beim ersten Durchlauf zu verbessern.

Warum es wichtig ist

Liefert direkte, umsetzbare Erkenntnisse darüber, warum Bestellungen abgelehnt werden, und hilft, die Ursachen für Prozessüberarbeitungen und Verzögerungen zu beheben.

Woher erhalten

Typischerweise erfasst im Kommentar- oder Notizfeld, das mit der Activity 'Purchase Order Rejected' oder 'Purchase Requisition Rejected' im Genehmigungsworkflow von Coupa verbunden ist.

Beispiele
Doppelte AnforderungBudget nicht genehmigtFalscher Lieferant ausgewählt
Änderungsgrund
ChangeReason
Der angegebene Grund für eine Änderung, die an einer Bestellung nach deren ursprünglicher Erstellung vorgenommen wurde.
Beschreibung

Dieses Attribut erfasst die Begründung, warum eine Bestellung geändert wurde, zum Beispiel „Menge aktualisiert“ (Quantity updated) oder „Preiskorrektur“ (Price correction). Diese Informationen werden oft im Audit Trail aufgezeichnet, wenn ein Benutzer eine Aktivität „Bestellung geändert“ (Purchase Order Changed) ausführt.

Zu verstehen, warum Bestellungen geändert werden, ist entscheidend für das Dashboard „Bestelländerungsanalyse“ (Purchase Order Change Analysis). Es hilft, zwischen unvermeidbaren Änderungen (z. B. Lagerbestandsprobleme des Lieferanten) und vermeidbaren Änderungen (z. B. falsche anfängliche Dateneingabe) zu unterscheiden, was Bemühungen zur Verbesserung der Bestellgenauigkeit und zur Reduzierung des KPIs „Bestelländerungsrate“ (Purchase Order Change Rate) leitet.

Warum es wichtig ist

Erklärt die Ursachen von PO-Änderungen und ermöglicht gezielte Maßnahmen, um die Erstbestellgenauigkeit zu verbessern und die Prozessnacharbeit zu reduzieren.

Woher erhalten

Oft in den Audit-Logs oder Kommentaren zu den Änderungsereignissen einer Bestellung (Purchase Order) in Coupa zu finden.

Beispiele
Preisanpassung vom LieferantenLieferdatum angepasstKorrigierter Artikelcode
Angefordertes Lieferdatum
RequestedDeliveryDate
Das Datum, an dem der Anfragende die Lieferung der Waren oder Dienstleistungen gewünscht hat.
Beschreibung

Dieses Attribut ist das vom Fachbereich im Rahmen des Anforderungsprozesses festgelegte gewünschtes Lieferdatum. Es repräsentiert die Erwartung des Unternehmens, wann die Bestellung erfüllt sein soll.

Dieses Datum ist eine kritische Messgröße zur Bewertung der Lieferanten- und internen Performance. Es wird direkt zur Berechnung des KPI 'Liefertreue der Lieferanten' verwendet, indem es mit dem tatsächlichen gebuchtem Wareneingang verglichen wird. Das Dashboard 'Abweichungen im Lieferdatum und Retouren' visualisiert Diskrepanzen zwischen diesem angeforderten und dem tatsächlichen Lieferdatum, was dabei hilft, Erwartungen zu steuern und die Prognosegenauigkeit zu verbessern.

Warum es wichtig ist

Dient als wichtige Performance-Baseline zur Messung der termingerechten Lieferung von Lieferanten und der Effizienz des internen Wareneingangsprozesses.

Woher erhalten

Ein Standardfeld auf der Bestellposition in Coupa.

Beispiele
2023-11-152023-12-012024-01-10
Bearbeitungszeit
ProcessingTime
Die Dauer einer Aktivität, die die aktive Arbeitszeit eines Benutzers an einer Aufgabe darstellt.
Beschreibung

Die Bearbeitungszeit, manchmal auch als service time bezeichnet, ist die Zeit, die aktiv für eine Aufgabe aufgewendet wird. Sie unterscheidet sich von der Wartezeit. Sie könnte beispielsweise die Zeit messen, die zwischen dem Öffnen einer PO-Genehmigungsaufgabe durch einen Benutzer und dem Absenden der Genehmigung vergeht.

Diese Metrik bietet eine genauere Sicht auf den Benutzeraufwand im Vergleich zur cycle time, die Wartezeiten einschließt. Die Analyse der Bearbeitungszeit hilft bei der Kapazitätsplanung, der Arbeitslastverteilung und der Identifizierung von Aufgaben, die von Natur aus zeitaufwendig sind. Sie erfordert sowohl eine Start- als auch eine Endzeit für eine einzelne Aktivität, die nicht immer verfügbar ist.

Warum es wichtig ist

Hilft, zwischen aktiver Arbeitszeit und Wartezeit zu unterscheiden, und liefert bessere Einblicke in die Ressourceneffizienz und Aufgabenkomplexität.

Woher erhalten

Berechnet, wenn sowohl Start- als auch End-Timestamps für eine einzelne Aktivität in den Coupa Audit-Logs verfügbar sind. Dies ist oft nicht Standard.

Beispiele
3600120900
Bestellanforderungsnummer
PurchaseRequisitionNumber
Die eindeutige Kennung für die Bestellanforderung, die der Bestellung vorausging.
Beschreibung

Dieses Attribut verknüpft eine Bestellung mit der ursprünglichen Bestellanforderung. Eine einzelne Bestellanforderung kann zu einer oder mehreren Bestellungen führen.

Diese Verknüpfung ist unerlässlich für die Analyse der gesamten Durchlaufzeit von der Bestellanforderung bis zur Bestellung. Durch die Verbindung des Erstellungs-Events der Bestellanforderung mit den Erstellungs- und Sende-Events der Bestellung können Unternehmen die Effizienz ihres gesamten Beschaffungsinitiierungsprozesses, von der Anforderung bis zur Ausführung, messen.

Warum es wichtig ist

Es verbindet die Anforderungs- und Bestellphasen des Prozesses und ermöglicht die Analyse der Requisition-to-Order Cycle Time und der Konversionsraten.

Woher erhalten

Dies ist typischerweise ein Referenzfeld auf den Bestellpositionen in Coupa, das auf die ursprüngliche Anforderung zurückverweist.

Beispiele
PR-2023-00098PR-2023-00152PR-2023-00341
Ist bevorzugter Lieferant
IsPreferredVendor
Ein boolesches Flag, das anzeigt, ob der Kauf von einem bevorzugten oder strategischen Lieferanten erfolgte.
Beschreibung

Dieses Flag identifiziert, ob der Lieferant der Bestellung Teil einer vorab genehmigten Liste strategischer Lieferanten ist. Dies wird typischerweise durch einen Abgleich des Lieferantennamens oder der ID mit einer Stammliste bevorzugter Lieferanten ermittelt.

Dieses Attribut ist unerlässlich für strategische Beschaffungs- und Ausgabenmanagement-Initiativen. Es wird zur Berechnung des KPI 'Ausgabenanteil bei Nicht-Bevorzugten Lieferanten' verwendet, was Organisationen dabei hilft, ungeplantes Beschaffen (Maverick Buying) zu überwachen und zu kontrollieren sowie Ausgaben bei wichtigen Partnern zu konsolidieren, um Volumenrabatte und bessere Konditionen zu nutzen.

Warum es wichtig ist

Hilft, die Überwachung der Einhaltung von Beschaffungsrichtlinien und strategischen Beschaffungszielen zu unterstützen, indem die Ausgaben bei bevorzugten versus nicht bevorzugten Lieferanten verfolgt werden.

Woher erhalten

Dies ist oft kein Standardfeld in Coupa, sondern wird durch den Vergleich der Vendor ID auf der PO mit einer externen Liste bevorzugter Lieferanten abgeleitet.

Beispiele
truefalsch
Ist erstmalige Genehmigung
IsFirstPassApproval
Ein berechnetes Flag, das 'wahr' ist, wenn die Bestellung nach dem Entwurf ohne Änderungen genehmigt wurde.
Beschreibung

Dieses Boolesche Flag wird auf 'wahr' gesetzt, wenn der Prozessweg einer Bestellung von 'Bestellung erstellt' bis 'Bestellung genehmigt' keine Aktivitäten wie 'Bestellung geändert' oder 'Bestellung abgelehnt' dazwischen enthält.

Dieses Attribut misst direkt den KPI 'Genehmigungsrate im ersten Durchlauf'. Eine hohe Rate deutet auf eine effiziente und präzise Erstbearbeitung hin. Die Analyse der Fälle, in denen dieses Flag auf 'falsch' gesetzt ist, kann dabei helfen, Gründe für Nacharbeit aufzudecken und die anfängliche Datenqualität von Bestellungen zu verbessern.

Warum es wichtig ist

Misst direkt die Effizienz des initialen Erstellungs- und Genehmigungsprozesses und hebt das Volumen der Bestellungen hervor, die ohne Nacharbeit durchlaufen werden.

Woher erhalten

Berechnet während der Datentransformation durch Analyse der Eventsequenz für jede Bestellnummer.

Beispiele
truefalsch
Ist Lieferung pünktlich
IsDeliveryOnTime
Ein berechnetes Flag, das anzeigt, ob die Waren am oder vor dem angeforderten Lieferdatum eingegangen sind.
Beschreibung

Dieses Boolesche Attribut wird durch den Vergleich des Timestamps des Events 'Wareneingang gebucht' mit dem RequestedDeliveryDate berechnet. Es wird auf 'wahr' gesetzt, wenn das Eingangsdatum am oder vor dem angeforderten Datum liegt.

Dieses Flag unterstützt direkt den KPI 'Liefertreue der Lieferanten' und das Dashboard 'Abweichungen im Lieferdatum und Retouren'. Es liefert ein klares, binäres Ergebnis für die termingerechte Lieferung, das sich einfach aggregieren und visualisieren lässt, und hilft, Performanceprobleme bei Lieferanten oder internen Wareneingangsprozessen schnell zu identifizieren.

Warum es wichtig ist

Bietet eine klare, binäre Metrik für die Lieferperformance, die die Berechnung von On-Time-Delivery-KPIs und die Trendanalyse vereinfacht.

Woher erhalten

Berechnet während der Datentransformation durch Vergleich des 'RequestedDeliveryDate' mit dem Timestamp der Aktivität 'Wareneingang gebucht'.

Beispiele
truefalsch
Ist Nacharbeit
IsRework
Ein berechnetes Flag, das anzeigt, ob eine Bestellung geändert wurde.
Beschreibung

Dieses Boolesche Flag wird auf 'wahr' gesetzt für jede Bestellung, die mindestens ein Event 'Bestellung geändert' in ihrer Historie aufweist. Es ist ein fallbezogenes Attribut, das aus dem Event Log abgeleitet wird.

Dieses Attribut vereinfacht die Berechnung von KPIs wie der 'Änderungsrate von Bestellungen'. Es ermöglicht ein einfaches Filtern und Segmentieren der Daten, um Prozesse für Bestellungen mit und ohne Nacharbeit zu vergleichen, was dabei hilft, die Auswirkungen von Änderungen auf die Durchlaufzeit und Kosten zu quantifizieren. Es ist ein zentraler Bestandteil des Dashboards 'Analyse von Bestelländerungen'.

Warum es wichtig ist

Vereinfacht die Analyse von Rework, indem es einfaches Filtern und Aggregieren für alle Bestellungen ermöglicht, die mindestens einmal geändert wurden.

Woher erhalten

Berechnet während der Datentransformation durch Überprüfung der Existenz einer Aktivität 'Bestellung geändert' für jede Bestellnummer.

Beispiele
truefalsch
Name des Anfragenden
RequesterName
Der Name der Person, die ursprünglich die Waren oder Dienstleistungen angefordert hat.
Beschreibung

Dieses Attribut identifiziert den Mitarbeiter, der die Bestellanforderung erstellt hat, die zur Bestellung führte. Der Anforderer ist der Geschäftsanwender mit dem Bedarf, der sich vom Käufer oder Genehmiger unterscheiden kann.

Die Analyse des Prozessverhaltens nach Anforderer hilft, Muster im Zusammenhang mit bestimmten Benutzern oder Abteilungen zu identifizieren. Das Dashboard „Bestelländerungsanalyse“ (Purchase Order Change Analysis) nutzt dies, um festzustellen, ob bestimmte Anforderer eine höhere Häufigkeit von Bestelländerungen aufweisen, was auf einen Bedarf an besserer Schulung zu den Spezifikationsanforderungen hinweisen könnte.

Warum es wichtig ist

Hilft, den geschäftlichen Ursprung eines Einkaufs zu identifizieren, was die Analyse des Beschaffungsverhaltens und die Genauigkeit auf Anfordererebene ermöglicht.

Woher erhalten

Diese Information wird üblicherweise auf der ursprünglichen Bestellanforderung gespeichert und in die Bestellung in Coupa übernommen.

Beispiele
Alice CooperBob DylanCharlie Parker
Währung
Currency
Der Währungscode für die Geldwerte auf der Bestellung.
Beschreibung

Dieses Attribut gibt die Währung (z.B. USD, EUR, GBP) an, in der der Gesamtwert der Bestellung ausgedrückt ist. Es ist unerlässlich für die korrekte Interpretation von Finanzdaten in einem global agierenden Unternehmen.

Für multinationale Unternehmen kann die Analyse von Ausgaben ohne Berücksichtigung der Währung irreführend sein. Dieses Attribut ermöglicht eine ordnungsgemäße Währungsumrechnung und eine konsistente Finanzberichterstattung innerhalb von Dashboards, wodurch sichergestellt wird, dass Werte auf einer vergleichbaren Basis verglichen werden.

Warum es wichtig ist

Sorgt für eine genaue Finanzanalyse und Berichterstattung in multinationalen Kontexten, indem die notwendigen Informationen für die Währungsumrechnung bereitgestellt werden.

Woher erhalten

Ein Standardfeld im Bestellkopf in Coupa.

Beispiele
USDEURGBPJPY
Wareneingangsort
ReceivingLocation
Der physische Standort, zum Beispiel ein Lager oder Büro, an den die Waren geliefert werden sollen.
Beschreibung

Der Wareneingangsort gibt das Ziel für die auf der Bestellung (PO) bestellten Waren an. Dies kann ein bestimmtes Lager, eine Anlage oder eine Büroadresse sein.

Dieses Attribut wird verwendet, um die Logistik- und Wareneingangsleistung über verschiedene Standorte hinweg zu analysieren. Das Dashboard „Wareneingangsprozessverzögerungen“ kann nach diesem Attribut gefiltert werden, um festzustellen, ob bestimmte Standorte langsamer bei der Bearbeitung eingehender Lieferungen sind, was helfen kann, betriebliche Ineffizienzen oder Ressourcenengpässe an bestimmten Standorten aufzudecken.

Warum es wichtig ist

Ermöglicht eine standortbasierte Analyse des Wareneingangsprozesses, die Leistungsunterschiede zwischen Lagern, Werken oder Büros hervorhebt.

Woher erhalten

Diese Information ist Teil der Lieferadresse auf der Bestellung in Coupa.

Beispiele
Warehouse A - ChicagoGebäude 5 - Londoner BüroWerk Frankfurt
Erforderlich Empfohlen Optional

Purchase to Pay - Bestellaktivitäten

Dies sind die entscheidenden Prozessschritte und Meilensteine, die Sie in Ihrem Event Log verfolgen sollten, um Ihre P2P-Operationen präzise zu erkennen und zu analysieren.
6 Empfohlen 11 Optional
Aktivität Beschreibung
Bestellanforderung erstellt
Diese Aktivität markiert die Erstellung einer Bestellanforderung, der formalen Anforderung von Waren oder Dienstleistungen, die einer Bestellung vorausgeht. In Coupa ist dies ein explizites Event, das erfasst wird, wenn ein Benutzer ein neues Anforderungsdokument speichert und übermittelt.
Warum es wichtig ist

Als typischer Startpunkt des Beschaffungsprozesses ist diese Aktivität essenziell zur Messung der vollständigen Durchlaufzeit von Bestellanforderung zu Bestellung und zum Verständnis der Effizienz vorgelagerter Prozesse.

Woher erhalten

Dieses Event entspricht dem Erstellungsdatensatz im Objekt oder der Tabelle der Bestellanforderungen in Coupa. Der Timestamp ist im Feld created_at oder einem entsprechenden systemgenerierten Erstellungsdatumsfeld zu finden.

Erfassen

Direkt protokolliert bei der Erstellung eines neuen Anforderungsdatensatzes.

Ereignistyp explicit
Bestellung abgeschlossen
Dies ist die abschließende Activity, die signalisiert, dass die Bestellung abgeschlossen ist. Die PO gilt als geschlossen, wenn sie vollständig empfangen und vollständig in Rechnung gestellt wurde und keine weiteren Transaktionen erwartet werden.
Warum es wichtig ist

Diese Aktivität beendet offiziell den Lebenszyklus der Bestellung. Die Analyse der Abschlusszeit kann Ineffizienzen bei der endgültigen Abstimmung und der Aktenführung aufdecken.

Woher erhalten

Dies wird von einer Statusänderung des Purchase Order-Objekts auf 'Closed' abgeleitet. Dieser Status wird häufig automatisch von Coupa basierend auf Geschäftsregeln bezüglich Wareneingangs- und Rechnungstoleranzen gesetzt.

Erfassen

Abgeleitet vom Timestamp der Statusänderung zu 'Geschlossen'.

Ereignistyp inferred
Bestellung an Lieferanten gesendet
Diese Aktivität markiert den Zeitpunkt, an dem die genehmigte Bestellung offiziell an den Lieferanten übermittelt wird, z. B. per E-Mail oder über das Coupa Supplier Portal. Dieses Event wandelt die Bestellung von einem internen Dokument in eine externe Verpflichtung um.
Warum es wichtig ist

Dies ist ein wichtiger Meilenstein, der den internen Bestellanforderung-bis-Bestellung-Prozess abschließt und die Lieferanten-Lieferzeit einleitet. Er ist entscheidend für die Messung der internen Effizienz und der Lieferanten-Performance.

Woher erhalten

Oft abgeleitet aus einer Statusänderung der Bestellung (PO) zu 'Ordered' oder 'Sent'. Coupa kann auch einen spezifischen last_exported_at oder sent_to_supplier_at timestamp im Bestellungsdatensatz führen.

Erfassen

Abgeleitet vom Timestamp der Statusänderung zu 'Bestellt' oder einem spezifischen Übertragungs-Timestamp-Feld.

Ereignistyp inferred
Bestellung genehmigt
Dieser Meilenstein bedeutet, dass die Bestellung ihren internen Genehmigungsworkflow abgeschlossen hat und zur Übermittlung an den Lieferanten freigegeben ist. Dies ist typischerweise der letzte Genehmigungsschritt in einem mehrstufigen Prozess.
Warum es wichtig ist

Dies ist ein kritischer Meilenstein für die Berechnung der Durchlaufzeiten von Bestellgenehmigungen und die Identifizierung von Genehmigungsengpässen. Es dient auch als wichtiger Compliance-Prüfpunkt.

Woher erhalten

Erfasst aus dem Genehmigungsprotokoll der Bestellung in Coupa. Der Timestamp der letzten Genehmigungsaktion liefert die Eventzeit.

Erfassen

Im Genehmigungsverlauf protokolliert, wenn der letzte Genehmiger seine Aufgabe abschließt.

Ereignistyp explicit
Bestellung storniert
Diese Aktivität repräsentiert die Stornierung einer Bestellung, bevor sie abgeschlossen wurde. Eine Stornierung kann in verschiedenen Phasen erfolgen, z. B. wenn die Anfrage nicht mehr gültig ist oder wenn die Bestellung irrtümlich erstellt wurde.
Warum es wichtig ist

Als alternativer Prozessabschluss ist die Verfolgung von Stornierungen wichtig, um Prozessabbrüche zu verstehen und Gründe für abgebrochene Bestellanfragen zu identifizieren.

Woher erhalten

Dies wird aus einer Statusänderung des Bestellobjekts auf 'Storniert' abgeleitet. Der Timestamp dieser Statusänderung wird als Event-Zeit verwendet.

Erfassen

Abgeleitet vom Timestamp der Statusänderung zu 'Storniert'.

Ereignistyp inferred
Wareneingang gebucht
Dies ist die formelle Bestätigung, dass Waren eingegangen, geprüft und akzeptiert wurden. Dieses Event aktualisiert Bestandsaufzeichnungen und signalisiert, dass die Verpflichtung des Lieferanten für diese Lieferung erfüllt wurde.
Warum es wichtig ist

Dieser kritische Meilenstein markiert das Ende der Lieferzeit des Lieferanten und wird zur Messung der Liefertreue verwendet. Verzögerungen bei der Buchung von Wareneingängen können die Transparenz über die tatsächlichen Lagerbestände beeinträchtigen.

Woher erhalten

Dies ist eine Kerntransaktion in Coupa, die auf dem Belegobjekt erfasst wird. Das Event wird vom Timestamp erfasst, wenn der Status des Belegs 'Gebucht' oder 'Empfangen' wird.

Erfassen

Protokolliert, wenn die Wareneingangstransaktion im System finalisiert wird.

Ereignistyp explicit
Bestellanforderung genehmigt
Eine Bestellanforderung durchläuft einen Genehmigungs-Workflow, bevor sie in eine Bestellung umgewandelt werden kann. Dieses Event kennzeichnet die endgültige Genehmigung der Anforderung, wodurch sie zur Bestellung bereit ist.
Warum es wichtig ist

Die Verfolgung von Genehmigungen für Anforderungen hilft, Engpässe in der Vorbestellphase zu identifizieren. Verzögerungen hier wirken sich direkt darauf aus, wie schnell eine Bestellung ausgestellt werden kann.

Woher erhalten

Dies wird typischerweise aus der Genehmigungshistorie des Anforderungsobjekts in Coupa erfasst. Die finale Genehmigungsaktion hat einen entsprechenden Timestamp und User.

Erfassen

Im Genehmigungsverlauf protokolliert, wenn der letzte Genehmiger eine Aktion vornimmt.

Ereignistyp explicit
Bestellung eingereicht
Nachdem eine Bestellung entworfen wurde, wird sie formell in den Genehmigungsworkflow übermittelt. Dies ist eine spezifische Benutzeraktion, die die Bestellung von einem Entwurfsstatus in einen Status der ausstehenden Genehmigung überführt.
Warum es wichtig ist

Dieses Event unterscheidet die Erstellungszeit vom Zeitpunkt, ab dem die Bestellung tatsächlich auf Genehmigung wartet. Es bietet ein klareres Bild des Benutzerverhaltens und der Prozessübergaben.

Woher erhalten

Abgeleitet von einer Statusänderung am Bestellobjekt, beispielsweise von „Entwurf“ zu „zur Genehmigung ausstehend“. Der Timestamp dieser spezifischen Statusänderung wird verwendet.

Erfassen

Abgeleitet vom Timestamp der Statusänderung zu 'Genehmigung ausstehend'.

Ereignistyp inferred
Bestellung entworfen
Dieses Event repräsentiert die anfängliche Erstellung des Bestelldokuments im System, oft aus einer genehmigten Bestellanforderung. In diesem Stadium ist die Bestellung ein interner Entwurf und wurde noch nicht zur Genehmigung eingereicht oder an den Lieferanten gesendet.
Warum es wichtig ist

Diese Aktivität startet die Zeitmessung für die Messung des KPIs „Bestellgenehmigungs-Durchlaufzeit“ (PO Approval Cycle Time). Sie ist der erste formale Schritt im eigenen Lebenszyklus der Bestellung.

Woher erhalten

Dies entspricht dem Erstellungs-Timestamp des Bestelldatensatzes in Coupa, der typischerweise in einem Feld wie created_at zu finden ist.

Erfassen

Erfasst aus dem systemgenerierten Erstellungs-Timestamp des Bestelldatensatzes.

Ereignistyp explicit
Bestellung geändert
Dieses Event repräsentiert jede Änderung, die an der Bestellung nach der ursprünglichen Erstellung vorgenommen wurde. In Coupa werden Änderungen oft durch die Versionierung des Bestelldokuments nachverfolgt.
Warum es wichtig ist

Änderungen nachzuverfolgen ist entscheidend für KPIs wie die Änderungsrate von Bestellungen und die Rate nicht konformer Bestellungen. Häufige Änderungen deuten auf Prozessinstabilität oder ungenaue ursprüngliche Anforderungen hin.

Woher erhalten

Kann durch Verfolgung verschiedener Versionen einer Bestellung abgeleitet werden. Jede neue Versionsnummer, die größer als die erste ist, zeigt eine Änderung an, wobei das Erstellungsdatum der neuen Version als Eventtimestamp dient.

Erfassen

Abgeleitet vom Erstellungs-Timestamp einer neuen Bestellversion.

Ereignistyp inferred
Bestellung zurückgewiesen
Diese Aktivität tritt auf, wenn ein Genehmiger die Bestellung während des Approval Workflows ablehnt. Die Bestellung wird dann typischerweise zur Überarbeitung oder Stornierung an den Ersteller zurückgesendet.
Warum es wichtig ist

Die Analyse von Ablehnungen hilft dabei, Probleme mit der Datenqualität, Richtlinienverstöße oder Schulungslücken aufzudecken. Sie zeigt Nachbearbeitungsschleifen auf, die zu erheblichen Prozessverzögerungen führen.

Woher erhalten

Dies ist ein explizites Event, das im Genehmigungshistorien-Log der Bestellung in Coupa erfasst wird. Das Log zeigt eine Aktion 'Ablehnen' mit einem entsprechenden Timestamp.

Erfassen

Im Genehmigungsverlauf mit dem Status „Abgelehnt“ protokolliert.

Ereignistyp explicit
Dienstleistungsbestätigung erfasst
Bei dienstleistungsbasierten Bestellungen entspricht diese Aktivität einem Wareneingang. Sie bestätigt, dass eine Dienstleistung gemäß den Bedingungen der PO erbracht wurde.
Warum es wichtig ist

Die Nachverfolgung von Dienstleistungsbestätigungen ist entscheidend, um die Ausgaben für Dienstleistungen zu steuern und sicherzustellen, dass Zahlungen nur für nachweislich abgeschlossene Arbeiten erfolgen.

Woher erhalten

Dieses Event wird aus der Erstellung oder Genehmigung eines Dienstleistungsbelegs oder Leistungserfassungsblattes erfasst, das mit der Bestellung in Coupa verknüpft ist.

Erfassen

Protokolliert bei der Erstellung und Genehmigung eines Leistungserfassungsblattes.

Ereignistyp explicit
Lieferant hat Bestellung bestätigt
Dieses Event bedeutet, dass der Lieferant die Bestellung erhalten und bestätigt hat. Diese Bestätigung wird oft elektronisch über ein Lieferantenportal wie das Coupa Supplier Portal (CSP) erfasst.
Warum es wichtig ist

Lieferantenbestätigungen schaffen Gewissheit, dass eine Bestellung bearbeitet wird, verbessern die Genauigkeit der Lieferprognosen und reduzieren die Unsicherheit in der Lieferkette.

Woher erhalten

Diese Information ist typischerweise auf der Bestellung verfügbar, wenn der Lieferant das Coupa Supplier Portal nutzt, um die Aktion 'Bestätigen' durchzuführen. Der Timestamp dieser Aktion wird verwendet.

Erfassen

Protokolliert, wenn ein Lieferant die Acknowledge-Aktion im Lieferantenportal ausführt.

Ereignistyp explicit
Qualitätsinspektion durchgeführt
Dieses Event zeigt an, dass ein empfangener Artikel eine Qualitätsprüfung durchlaufen und bestanden hat. Dies kann ein separater Schritt nach der ersten Buchung des Wareneingangs sein, abhängig vom Prozess des Unternehmens.
Warum es wichtig ist

Diese Aktivität ist entscheidend für die Messung der Effizienz des Qualitätskontrollprozesses. Verzögerungen hier können Bottlenecks zwischen Wareneingang und Verfügbarkeit zur Nutzung schaffen.

Woher erhalten

Dies kann als Statusänderung auf der Wareneingangsposition oder über ein separates Prüfobjekt in Coupa erfasst werden. Die Verfügbarkeit hängt davon ab, ob das Qualitätsmodul oder ein benutzerdefinierter Workflow verwendet wird.

Erfassen

Abgeleitet von einer Statusänderung des Wareneingangs oder einem Timestamp eines zugehörigen Inspektionsdatensatzes.

Ereignistyp inferred
Rechnung für Bestellung erhalten
Dieses Event markiert den Empfang und die Erfassung einer Lieferantenrechnung, die sich auf die Bestellung bezieht. Es signalisiert den Beginn der Rechnungsverarbeitungs- und Zahlungsphase des P2P-Prozesses.
Warum es wichtig ist

Obwohl Teil des Kreditorenprozesses, bietet die Verknüpfung des Rechnungseingangs mit der PO eine End-to-End-Sicht auf den Transaktionslebenszyklus und hilft, die Lücke zwischen Lieferung und Rechnungsstellung zu analysieren.

Woher erhalten

Erfasst aus dem Erstellungs-Timestamp der Rechnungsdokumentation in Coupa, wobei die Rechnung mit der entsprechenden Bestellnummer abgeglichen wird.

Erfassen

Protokolliert bei der Erstellung eines Rechnungsdatensatzes, der mit der Bestellung verknüpft ist.

Ereignistyp explicit
Waren zurückgesendet
Diese Aktivität wird erfasst, wenn zuvor erhaltene Waren an den Lieferanten zurückgesendet werden. Dies ist typischerweise auf Qualitätsprobleme, Beschädigungen oder fehlerhafte Lieferungen zurückzuführen.
Warum es wichtig ist

Retouren nachzuverfolgen ist wesentlich für die Berechnung der Warenrücksendequote und das Identifizieren von Problemen mit Lieferantenqualität oder Bestellgenauigkeit. Hohe Rücksendequoten deuten oft auf kostspielige Prozessfehler hin.

Woher erhalten

Dies wird aus einer 'Rücksendung an Lieferanten'-Transaktion oder einer negativen Wareneingangstransaktion in Coupa erfasst. Der Timestamp dieser Transaktion dient als Event-Zeit.

Erfassen

Protokolliert, wenn eine Retourentransaktion erstellt wird, die mit der ursprünglichen Bestellung/dem Wareneingang verknüpft ist.

Ereignistyp explicit
Wareneingang initiiert
Diese Aktivität stellt den Beginn des Wareneingangsprozesses dar, z. B. wenn ein Wareneingangsdokument in Coupa bei der physischen Ankunft von Waren erstellt wird. Die Waren wurden noch nicht formell ins Inventar gebucht oder als empfangen bestätigt.
Warum es wichtig ist

Dieses Event ist der Startpunkt für die Messung des KPI 'Wareneingangsbearbeitungszeit'. Es hilft dabei, zwischen der Zeit, in der Waren am Wareneingang warten, und der Zeit, die für die Systemverarbeitung aufgewendet wird, zu unterscheiden.

Woher erhalten

Dies kann aus dem Erstellungs-Timestamp eines Wareneingangsbelegs abgeleitet werden, der den Status 'Entwurf' oder 'Ausstehend' hat. Es geht der endgültigen Buchung des Wareneingangs voraus.

Erfassen

Abgeleitet vom Erstellungs-Timestamp eines Belegdatensatzes in einem nicht gebuchten Status.

Ereignistyp inferred
Empfohlen Optional

Extraktionsleitfäden

So erhalten Sie Ihre Daten aus Coupa