Ihr Daten-Template für den Purchase-to-Pay-Prozess mit Bestellungen
Ihr Daten-Template für den Purchase-to-Pay-Prozess mit Bestellungen
- Empfohlene Datenattribute
- Wichtige Prozessaktivitäten
- Schritte zur Datenextraktion aus Coupa
Attribute für den Purchase-to-Pay-Prozess mit Bestellungen
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
ActivityName
|
Der Name des konkreten Ereignisses oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Lebenszyklus der Bestellung stattgefunden hat. | ||
|
Beschreibung
Der Aktivitätsname bezeichnet einen einzelnen Schritt im Purchase-to-Pay-Prozess, zum Beispiel „Bestellung genehmigt“ oder „Wareneingang gebucht“. Die Abfolge dieser Aktivitäten bildet den Prozessablauf für jede Bestellung. Dieses Attribut ist grundlegend für Process Mining: Es dient dazu, das Prozessmodell zu erstellen, Prozessvarianten zu erkennen und Häufigkeit sowie Reihenfolge der Ereignisse zu analysieren. So lassen sich Engpässe, Nacharbeitsschleifen und Abweichungen vom Standardprozess erkennen. Die Analyse von Aktivitäten wie „Bestellung geändert“ kann beispielsweise Ineffizienzen bei der Bestellgenauigkeit aufdecken.
Warum das wichtig ist
Das Attribut legt die Prozessschritte fest und ermöglicht es, den Prozessablauf zu visualisieren sowie Engpässe, Nacharbeit und Abweichungen zu erkennen.
Woher beziehen
Abgeleitet aus Event Logs, Audit-Trails oder Statusänderungsdatensätzen zu Bestellobjekten in Coupa.
Beispiele
Bestellanforderung genehmigtBestellung eingereichtWareneingang gebuchtRechnung zur Bestellung eingegangen
|
|||
|
Bestellung
PurchaseOrderNumber
|
Die eindeutige Kennung einer Bestellung, die als primäre Case-ID des Prozesses dient. | ||
|
Beschreibung
Die Bestellnummer ist die zentrale Case-ID, die alle Aktivitäten von der ursprünglichen Anforderung bis zur abschließenden Bestätigung des Wareneingangs oder der Leistungserbringung miteinander verknüpft. Jede eindeutige Bestellnummer steht für einen einzelnen Beschaffungsvorgang. In der Process-Mining-Analyse ist dieses Attribut entscheidend, um den gesamten Ablauf jeder Bestellung nachzuverfolgen. Es ermöglicht Analysten, Prozessmodelle zu visualisieren, Varianten zu erkennen und Kennzahlen auf Case-Ebene zu berechnen, etwa die gesamte Durchlaufzeit einer Bestellung. Alle Ereignisse und zugehörigen Daten werden unter dieser Kennung zusammengeführt, um den Prozess als Ganzes abzubilden.
Warum das wichtig ist
Dieses Attribut ist entscheidend, um den vollständigen Lebenszyklus jedes Einkaufs nachzuverfolgen und einzelne Prozessinstanzen für eine detaillierte Analyse zu rekonstruieren.
Woher beziehen
Dies ist ein standardmäßiges Primärschlüsselfeld des Bestellobjekts in Coupa.
Beispiele
PO-2023-00123PO-2023-00456PO-2023-00789
|
|||
|
Startzeit
EventTime
|
Der genaue Timestamp, der angibt, wann eine Aktivität oder ein Ereignis stattgefunden hat. | ||
|
Beschreibung
Der Ereigniszeitpunkt erfasst Datum und Uhrzeit, zu denen eine bestimmte Aktivität ausgeführt wurde. Für jede Aktivität im Prozess gibt es einen entsprechenden Timestamp. Dieses Attribut ist für alle zeitbasierten Process-Mining-Analysen entscheidend. Es dient dazu, Zykluszeiten zwischen Aktivitäten zu berechnen, die Prozessdauer zu messen und Verzögerungen zu erkennen. So wird beispielsweise die Differenz zwischen den Timestamps „Bestellung als Entwurf erstellt“ und „Bestellung genehmigt“ zur Berechnung der Kennzahl „Genehmigungszykluszeit der Bestellung“ herangezogen.
Warum das wichtig ist
Das Attribut ordnet jedes Ereignis zeitlich ein. Diese Information ist notwendig, um Zykluszeiten zu berechnen, die Leistung zu analysieren und Engpässe zu erkennen.
Woher beziehen
Zu finden in den Event Logs oder Audit-Trails von Coupa, üblicherweise bei jeder Statusänderung oder Aktion zu einer Bestellung.
Beispiele
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp der letzten Aktualisierung der Daten für diesen Prozess. | ||
|
Beschreibung
Dieses Attribut erfasst, wann der Datensatz zuletzt aus dem Quellsystem aktualisiert wurde. Es handelt sich um ein Metadatenfeld für den gesamten Datensatz, nicht für einzelne Ereignisse. In jedem analytischen Dashboard ist dieser Timestamp wichtig, damit Benutzer erkennen können, wie aktuell die angezeigten Daten sind. Er zeigt, ob die Erkenntnisse auf aktuellen Informationen beruhen, und hilft dabei, Erwartungen an die Aktualität der Daten zu steuern. In Dashboards wird er üblicherweise gut sichtbar angezeigt.
Warum das wichtig ist
Das Attribut informiert Benutzer über die Aktualität der Daten. So können sie einschätzen, wie aktuell die Prozessanalyse und die Kennzahlen sind.
Woher beziehen
Dieser Timestamp wird bei der Ausführung der Datenextraktions- und Ladepipeline (ETL) erzeugt und gespeichert.
Beispiele
2023-11-01T05:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Prozessdaten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut kennzeichnet das Informationssystem, in dem die Ereignisdaten ursprünglich erfasst wurden. Für diesen Prozess lautet der Wert durchgehend „Coupa“. In Unternehmen können Daten aus mehreren Systemen stammen, zum Beispiel aus Coupa für die Beschaffung und aus einem anderen ERP-System für die Rechnungsstellung. Dieses Attribut hilft, die Datenquellen voneinander zu unterscheiden. Es sorgt für Transparenz bei der Datenherkunft und ermöglicht es, die Analyse auf die Prozesssicht eines bestimmten Systems zu beschränken.
Warum das wichtig ist
Das Attribut liefert wichtige Informationen zur Herkunft der Daten. So bleiben sie nachvollziehbar und lassen sich ordnungsgemäß verwalten, insbesondere in Umgebungen mit mehreren Systemen.
Woher beziehen
Dies ist ein statischer Wert, der üblicherweise während der Datenextraktion und -transformation hinzugefügt wird, um den Datensatz zu kennzeichnen.
Beispiele
Coupa
|
|||
|
Abteilung
Department
|
Die Fachabteilung oder Kostenstelle, der die Bestellung belastet wird. | ||
|
Beschreibung
Das Attribut „Abteilung“ gibt die Organisationseinheit an, die den Einkauf veranlasst hat oder dessen Kosten trägt. Häufig ist es mit der anfordernden Person oder der Kostenstellenangabe in den Bestellpositionen verknüpft. Diese Dimension ist wichtig, um Prozessanalysen und Kennzahlen aufzuschlüsseln. Führungskräfte können damit Prozesseffizienz, Compliance und Ausgabenmuster in verschiedenen Bereichen der Organisation vergleichen. Das Dashboard „Ausgabenanalyse nach Einkaufskategorie“ verwendet beispielsweise die Abteilung, um zu zeigen, wie viel die einzelnen Geschäftseinheiten von ihrem Budget ausgeben.
Warum das wichtig ist
Damit lassen sich Prozess- und Ausgabenanalysen nach Geschäftseinheit filtern und vergleichen. So werden Unterschiede bei Effizienz und Compliance sichtbar.
Woher beziehen
In Coupa im Bestellkopf oder in den Bestellpositionen verfügbar, häufig mit einer Kostenstelle oder Organisationseinheit verknüpft.
Beispiele
MarketingInformationstechnologieBetriebFinanzen
|
|||
|
Benutzer
User
|
Die Benutzer-ID oder der Name der Person, die eine Aktivität ausgeführt hat, zum Beispiel ein Genehmiger oder Anforderer. | ||
|
Beschreibung
Dieses Attribut kennzeichnet die Person, die für die Ausführung eines bestimmten Ereignisses im Prozess verantwortlich ist. Das kann die Person sein, die den Bestellentwurf erstellt hat, die Führungskraft, die ihn genehmigt hat, oder der Sachbearbeiter, der den Wareneingang gebucht hat. Die Analyse der Leistung nach Benutzer hilft, Schulungsbedarf, besonders leistungsstarke Mitarbeitende und die Verteilung der Arbeitslast zu erkennen. Das Dashboard „Leistung der Genehmigungszykluszeit von Bestellungen“ verwendet dieses Attribut beispielsweise, um Genehmigungszeiten nach einzelnen Genehmigern aufzuschlüsseln. So wird sichtbar, bei wem im Prozess ein Engpass entstehen kann.
Warum das wichtig ist
Das Attribut ermöglicht die Analyse der Prozessleistung nach Person oder Rolle. So lassen sich Engpässe, Schulungsbedarf und Probleme bei der Ressourcenzuweisung erkennen.
Woher beziehen
Wird jedem Ereignis im Audit-Trail oder Verlauf der Bestellung in Coupa zugeordnet. Häufige Datenquellen sind Felder wie „Created By“, „Approved By“ oder „Updated By“.
Beispiele
j.doea.smithm.jones
|
|||
|
Einkaufskategorie
PurchaseCategory
|
Die Klassifizierung der eingekauften Waren oder Dienstleistungen, zum Beispiel IT-Hardware oder professionelle Dienstleistungen. | ||
|
Beschreibung
Die Einkaufskategorie, auch als Warengruppe oder Materialgruppe bezeichnet, fasst ähnliche Einkäufe zusammen. Diese strukturierten Daten ermöglichen eine systematische Analyse der Ausgaben und Beschaffungsprozesse. Beim Process Mining dient dieses Attribut als wichtige Dimension für Filter und Segmentierungen. Das Dashboard „Ausgabenanalyse nach Einkaufskategorie“ schlüsselt damit Ausgabenmuster auf. Außerdem lässt sich feststellen, ob bestimmte Kategorien, etwa komplexe Dienstleistungen, längere Durchlaufzeiten oder häufigere Änderungen aufweisen als andere, zum Beispiel Standard-Bürobedarf.
Warum das wichtig ist
Ermöglicht die Analyse von Ausgaben und Prozessen nach Kategorie. So lassen sich Beschaffungsmuster erkennen, Lieferantenverhandlungen vorbereiten und Prozesskontrollen gezielt anpassen.
Woher beziehen
In Coupa üblicherweise auf Positionsebene der Bestellung zu finden, häufig mit einem Warencode oder Einkaufskatalog verknüpft.
Beispiele
IT-HardwareBürobedarfProfessionelle DienstleistungenMarketingmaterialien
|
|||
|
Gesamtbestellwert
TotalOrderAmount
|
Der Gesamtwert der Bestellung. | ||
|
Beschreibung
Dieses Attribut gibt die Gesamtkosten aller in der Bestellung aufgeführten Waren und Dienstleistungen in einer bestimmten Währung an. Es gilt für den gesamten Case. Diese Finanzdaten sind für die Ausgabenanalyse und die Priorisierung von Prozessverbesserungen wichtig. Bei Bestellungen mit hohem Wert können zusätzliche Prüfungen oder andere Freigabewege erforderlich sein. Das Dashboard „Ausgabenanalyse nach Einkaufskategorie“ verwendet den Gesamtbestellwert direkt. Außerdem fließt er in die Berechnung der Kennzahl „Anteil der Ausgaben bei nicht bevorzugten Lieferanten“ ein.
Warum das wichtig ist
Liefert den finanziellen Kontext zu jedem Einkauf. Damit können Sie Ausgaben analysieren, Bestellungen mit hohem Wert priorisieren und die finanziellen Auswirkungen bewerten.
Woher beziehen
Im Bestellkopf von Coupa verfügbar, üblicherweise als „Total“ oder „Grand Total“.
Beispiele
1500.00250.7512500.50
|
|||
|
Lieferantenname
VendorName
|
Der Name des Lieferanten, von dem Waren oder Dienstleistungen bezogen werden. | ||
|
Beschreibung
Der Lieferantenname bezeichnet den externen Anbieter der in der Bestellung aufgeführten Artikel. Diese Angabe ist eine wichtige Grundlage für die Beschaffungsanalyse. Die Prozessleistung nach Lieferant auszuwerten, ist für das Lieferantenmanagement entscheidend. So lassen sich die „Lieferzeit des Lieferanten“ bewerten, Verzögerungen beim „Wareneingang“ erkennen und die Lieferantenqualität anhand der „Warenrücklaufquote“ beurteilen. Außerdem ist dieses Attribut wichtig für die Kennzahl „Anteil der Ausgaben bei nicht bevorzugten Lieferanten“.
Warum das wichtig ist
Ermöglicht die Analyse der Lieferantenleistung. So können Sie die Lieferantenauswahl verbessern, bessere Konditionen aushandeln und leistungsstarke sowie leistungsschwache Lieferanten erkennen.
Woher beziehen
Ein Standardfeld im Bestellkopf von Coupa, verknüpft mit den Stammdaten der Lieferanten.
Beispiele
Global Office SuppliesTech Solutions Inc.Advanced Industrial PartsCreative Marketing Agency
|
|||
|
Ablehnungsgrund
RejectionReason
|
Der Grund für die Ablehnung einer Bestellanforderung oder Bestellung während eines Freigabeschritts. | ||
|
Beschreibung
Lehnt eine freigebende Person eine Bestellung ab, gibt sie häufig einen Grund an. Dieses Attribut erfasst die Erklärung als Text, zum Beispiel „Falscher Budgetcode“ oder „Ausgabenlimit überschritten“. Die Analyse der Ablehnungsgründe zeigt direkt, wo Nacharbeit und Prozessfehler entstehen. Anhand dieser qualitativen Daten können häufige Fehler bei Bestellanforderungen erkannt werden. Gezielte Schulungen oder Systemverbesserungen helfen, weitere Ablehnungen zu vermeiden und die Erstfreigabequote zu erhöhen.
Warum das wichtig ist
Zeigt konkret, warum Bestellungen abgelehnt werden. So lassen sich die Ursachen für Nacharbeit und Verzögerungen gezielt angehen.
Woher beziehen
Wird in Coupa üblicherweise im Kommentarfeld oder in den Notizen zur Aktivität „Bestellung abgelehnt“ oder „Bestellanforderung abgelehnt“ im Freigabe-Workflow erfasst.
Beispiele
Doppelte AnforderungBudget nicht freigegebenFalscher Lieferant ausgewählt
|
|||
|
Änderungsgrund
ChangeReason
|
Der Grund für eine Änderung an einer Bestellung nach ihrer ursprünglichen Erstellung. | ||
|
Beschreibung
Dieses Attribut erfasst die Begründung für eine Änderung an einer Bestellung, zum Beispiel „Menge angepasst“ oder „Preis korrigiert“. Die Angabe wird häufig im Prüfprotokoll erfasst, wenn ein Benutzer die Aktivität „Bestellung geändert“ ausführt. Die Gründe für Bestelländerungen zu verstehen, ist wichtig für das Dashboard „Änderungsanalyse für Bestellungen“. So lassen sich unvermeidbare Änderungen, etwa aufgrund fehlender Lieferantenbestände, von vermeidbaren Änderungen, etwa durch fehlerhafte Dateneingaben, unterscheiden. Das hilft dabei, die Bestellgenauigkeit zu verbessern und die Kennzahl „Änderungsquote bei Bestellungen“ zu senken.
Warum das wichtig ist
Zeigt die Ursachen für Änderungen an Bestellungen. So können Sie gezielt die Genauigkeit bei der ersten Bestellung verbessern und Nacharbeit reduzieren.
Woher beziehen
Häufig in den Prüfprotokollen oder Kommentaren zu Änderungsereignissen einer Bestellung in Coupa zu finden.
Beispiele
Preisänderung durch LieferantenLieferdatum angepasstArtikelnummer korrigiert
|
|||
|
Bestellanforderungsnummer
PurchaseRequisitionNumber
|
Die eindeutige Kennung der Bestellanforderung, aus der die Bestellung hervorgegangen ist. | ||
|
Beschreibung
Dieses Attribut verknüpft eine Bestellung mit der ursprünglichen Bestellanforderung. Aus einer Bestellanforderung können eine oder mehrere Bestellungen entstehen. Diese Verknüpfung ist wichtig, um die gesamte Durchlaufzeit von der Anforderung bis zur Bestellung zu analysieren. Werden das Erstellungsereignis der Anforderung sowie die Erstellungs- und Versandereignisse der Bestellung miteinander verknüpft, lässt sich die Effizienz des gesamten Beschaffungsprozesses vom Bedarf bis zur Erfüllung messen.
Warum das wichtig ist
Verknüpft die Anforderungs- und Bestellphase. So lassen sich die Durchlaufzeit von der Anforderung bis zur Bestellung und die Umwandlungsraten analysieren.
Woher beziehen
In Coupa üblicherweise ein Referenzfeld in den Bestellpositionen, das auf die ursprüngliche Bestellanforderung verweist.
Beispiele
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
|
Gewünschtes Lieferdatum
RequestedDeliveryDate
|
Das Datum, zu dem die anfordernde Person die Lieferung der Waren oder Dienstleistungen wünscht. | ||
|
Beschreibung
Dieses Attribut enthält das gewünschte Lieferdatum, das die anfordernde Person während des Anforderungsprozesses angegeben hat. Es bildet die Erwartung des Unternehmens ab, bis wann die Bestellung erfüllt sein soll. Das Datum ist ein wichtiger Maßstab für die Bewertung der Lieferantenleistung und interner Abläufe. Für die Kennzahl „Einhaltung des Liefertermins durch den Lieferanten“ wird es direkt mit dem tatsächlichen Datum des gebuchten Wareneingangs verglichen. Das Dashboard „Abweichungen beim Liefertermin und Rücksendungen“ zeigt die Unterschiede zwischen dem gewünschten und dem tatsächlichen Lieferdatum. So lassen sich Erwartungen besser steuern und Prognosen verbessern.
Warum das wichtig ist
Dient als wichtige Vergleichsgröße, um die pünktliche Lieferung durch Lieferanten und die Effizienz des internen Wareneingangs zu messen.
Woher beziehen
Ein Standardfeld in der Bestellposition von Coupa.
Beispiele
2023-11-152023-12-012024-01-10
|
|||
|
Ist bevorzugter Lieferant
IsPreferredVendor
|
Ein boolesches Kennzeichen dafür, ob der Einkauf bei einem bevorzugten oder strategischen Lieferanten erfolgte. | ||
|
Beschreibung
Dieses Kennzeichen gibt an, ob der Lieferant der Bestellung auf einer vorab genehmigten Liste strategischer Lieferanten steht. Dazu werden der Lieferantenname oder die Lieferanten-ID üblicherweise mit einer Stammliste bevorzugter Lieferanten abgeglichen. Das Attribut ist wichtig für strategische Beschaffung und Ausgabenmanagement. Es fließt in die Berechnung der Kennzahl „Anteil der Ausgaben bei nicht bevorzugten Lieferanten“ ein. Damit können Unternehmen nicht genehmigte Einkäufe überwachen und kontrollieren sowie Ausgaben bei wichtigen Partnern bündeln, um Mengenrabatte und bessere Konditionen zu erhalten.
Warum das wichtig ist
Unterstützt die Überwachung der Beschaffungsrichtlinien und strategischen Beschaffungsziele, indem Ausgaben bei bevorzugten und nicht bevorzugten Lieferanten erfasst werden.
Woher beziehen
In Coupa häufig kein Standardfeld. Das Kennzeichen wird abgeleitet, indem die Lieferanten-ID der Bestellung mit einer externen Liste bevorzugter Lieferanten abgeglichen wird.
Beispiele
truefalse
|
|||
|
Ist Erstfreigabe
IsFirstPassApproval
|
Ein berechnetes Kennzeichen, das angibt, ob die Bestellung nach dem Entwurf ohne Änderungen freigegeben wurde. | ||
|
Beschreibung
Dieses boolesche Kennzeichen wird auf „true“ gesetzt, wenn zwischen den Aktivitäten „Bestellung entworfen“ und „Bestellung freigegeben“ weder „Bestellung geändert“ noch „Bestellung abgelehnt“ auftritt. Das Attribut misst direkt die Kennzahl „Erstfreigabequote für Bestellungen“. Eine hohe Quote weist auf eine effiziente und korrekte Erstbearbeitung hin. Die Analyse der Fälle mit dem Wert „false“ kann Ursachen für Nacharbeit aufdecken und die Datenqualität der Bestellungen bei der Erfassung verbessern.
Warum das wichtig ist
Misst direkt die Effizienz der ursprünglichen Erstellung und Freigabe. So wird sichtbar, wie viele Bestellungen ohne Nacharbeit durchlaufen.
Woher beziehen
Wird bei der Datentransformation berechnet, indem die Ereignisfolge für jede PurchaseOrderNumber analysiert wird.
Beispiele
truefalse
|
|||
|
Ist Lieferung pünktlich
IsDeliveryOnTime
|
Ein berechnetes Kennzeichen dafür, ob die Waren am gewünschten Lieferdatum oder früher eingegangen sind. | ||
|
Beschreibung
Dieses boolesche Attribut wird berechnet, indem der Timestamp des Ereignisses „Wareneingang gebucht“ mit dem Attribut „RequestedDeliveryDate“ verglichen wird. Es wird auf „true“ gesetzt, wenn der Wareneingang am gewünschten Lieferdatum oder früher erfolgt ist. Das Kennzeichen unterstützt direkt die Kennzahl „Einhaltung des Liefertermins durch den Lieferanten“ und das Dashboard „Abweichungen beim Liefertermin und Rücksendungen“. Es liefert ein eindeutiges Ja-Nein-Ergebnis zur Pünktlichkeit, das sich einfach zusammenfassen und visualisieren lässt. So erkennen Sie schnell Leistungsprobleme bei Lieferanten oder im internen Wareneingang.
Warum das wichtig ist
Liefert eine eindeutige Kennzahl zur Lieferleistung und vereinfacht die Berechnung von Kennzahlen für pünktliche Lieferungen sowie die Trendanalyse.
Woher beziehen
Wird bei der Datentransformation berechnet, indem „RequestedDeliveryDate“ mit dem Timestamp der Aktivität „Wareneingang gebucht“ verglichen wird.
Beispiele
truefalse
|
|||
|
Ist Nacharbeit
IsRework
|
Ein berechnetes Kennzeichen, das angibt, ob eine Bestellung geändert wurde. | ||
|
Beschreibung
Dieses boolesche Kennzeichen wird für jede Bestellung auf „true“ gesetzt, für die im Verlauf mindestens ein Ereignis „Bestellung geändert“ vorliegt. Es handelt sich um ein Case-Attribut, das aus dem Event Log abgeleitet wird. Das Attribut vereinfacht die Berechnung von Kennzahlen wie der „Änderungsquote bei Bestellungen“. Damit lassen sich Daten einfach filtern und segmentieren, um Prozesse bei Bestellungen mit und ohne Nacharbeit zu vergleichen. So können Sie die Auswirkungen von Änderungen auf Durchlaufzeit und Kosten quantifizieren. Das Attribut ist ein zentraler Bestandteil des Dashboards „Änderungsanalyse für Bestellungen“.
Warum das wichtig ist
Vereinfacht die Analyse von Nacharbeit, da sich alle mindestens einmal geänderten Bestellungen einfach filtern und zusammenfassen lassen.
Woher beziehen
Wird bei der Datentransformation berechnet, indem für jede PurchaseOrderNumber geprüft wird, ob die Aktivität „Bestellung geändert“ vorliegt.
Beispiele
truefalse
|
|||
|
Lieferort
ReceivingLocation
|
Der physische Ort, etwa ein Lager oder Büro, an den die Waren geliefert werden sollen. | ||
|
Beschreibung
Der Lieferort gibt das Ziel der in der Bestellung aufgeführten Waren an. Dabei kann es sich um ein bestimmtes Lager, Werk oder eine Büroadresse handeln. Mit diesem Attribut lassen sich Logistik und Wareneingang an verschiedenen Standorten analysieren. Im Dashboard „Verzögerungen beim Wareneingang“ können Sie nach Lieferort filtern und feststellen, ob bestimmte Standorte eingehende Lieferungen langsamer bearbeiten. So lassen sich betriebliche Ineffizienzen oder fehlende Ressourcen an einzelnen Standorten erkennen.
Warum das wichtig ist
Ermöglicht eine standortbezogene Analyse des Wareneingangs und macht Leistungsunterschiede zwischen Lagern, Werken und Büros sichtbar.
Woher beziehen
Diese Angabe ist Teil der Lieferadresse („Ship-To“) in der Bestellung in Coupa.
Beispiele
Lager A - ChicagoGebäude 5 - Büro LondonWerk Frankfurt
|
|||
|
Name der anfordernden Person
RequesterName
|
Der Name der Person, die die Waren oder Dienstleistungen ursprünglich angefordert hat. | ||
|
Beschreibung
Dieses Attribut bezeichnet die Person, die die Bestellanforderung erstellt hat, aus der die Bestellung hervorging. Die anfordernde Person hat den Bedarf und kann sich von der einkaufenden oder freigebenden Person unterscheiden. Eine Analyse des Prozessverhaltens nach anfordernder Person macht Muster bei bestimmten Benutzern oder Abteilungen sichtbar. Das Dashboard „Änderungsanalyse für Bestellungen“ zeigt damit beispielsweise, ob bestimmte Personen besonders häufig Änderungen an Bestellungen veranlassen. Das kann auf einen Schulungsbedarf bei den Anforderungen an Spezifikationen hinweisen.
Warum das wichtig ist
Zeigt, aus welchem Geschäftsbereich ein Einkauf stammt. So lässt sich das Beschaffungsverhalten und die Genauigkeit auf Ebene der anfordernden Person analysieren.
Woher beziehen
Diese Angabe wird üblicherweise in der ursprünglichen Bestellanforderung gespeichert und in Coupa in die Bestellung übernommen.
Beispiele
Alice CooperBob DylanCharlie Parker
|
|||
|
Währung
Currency
|
Der Währungscode für die Beträge in der Bestellung. | ||
|
Beschreibung
Dieses Attribut gibt an, in welcher Währung, zum Beispiel USD, EUR oder GBP, der Gesamtbestellwert ausgewiesen ist. Für die korrekte Interpretation von Finanzdaten in international tätigen Organisationen ist diese Angabe unerlässlich. Bei multinationalen Unternehmen kann eine Ausgabenanalyse ohne Berücksichtigung der Währung zu falschen Schlussfolgerungen führen. Mit diesem Attribut lassen sich Währungsumrechnungen korrekt durchführen und Finanzdaten in Dashboards einheitlich darstellen. Dadurch sind die Werte direkt vergleichbar.
Warum das wichtig ist
Ermöglicht korrekte Finanzanalysen und Berichte in multinationalen Unternehmen, da die erforderlichen Angaben für die Währungsumrechnung vorliegen.
Woher beziehen
Ein Standardfeld im Bestellkopf von Coupa.
Beispiele
USDEURGBPJPY
|
|||
Aktivitäten im Purchase-to-Pay-Prozess mit Bestellungen
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Bestellanforderung erstellt
|
Diese Aktivität kennzeichnet die Erstellung einer Bestellanforderung, also der formellen Anforderung von Waren oder Dienstleistungen vor der Bestellung. In Coupa wird dieses Ereignis ausdrücklich erfasst, wenn ein Benutzer ein neues Anforderungsdokument speichert und einreicht. | ||
|
Warum das wichtig ist
Als typischer Startpunkt des Beschaffungsprozesses ist diese Aktivität entscheidend, um die gesamte Durchlaufzeit von der Anforderung bis zur Bestellung zu messen und die Effizienz der vorgelagerten Prozessschritte zu verstehen.
Woher beziehen
Dieses Ereignis entspricht dem Erstellungsdatensatz im Objekt oder in der Tabelle für Bestellanforderungen in Coupa. Der Timestamp steht im Feld „created_at“ oder in einem entsprechenden, vom System erzeugten Feld für das Erstellungsdatum.
Erfassung
Wird direkt bei der Erstellung eines neuen Anforderungsdatensatzes protokolliert.
Ereignistyp
explicit
|
|||
|
Bestellung abgeschlossen
|
Dies ist die letzte Aktivität und zeigt an, dass die Bestellung abgeschlossen ist. Sie gilt als geschlossen, wenn alle Waren eingegangen und alle Rechnungen verbucht sind und keine weiteren Vorgänge erwartet werden. | ||
|
Warum das wichtig ist
Diese Aktivität beendet offiziell den Lebenszyklus der Bestellung. Die Analyse der Zeit bis zum Abschluss kann Ineffizienzen beim abschließenden Abgleich und bei der Dokumentation aufdecken.
Woher beziehen
Abgeleitet aus einer Statusänderung des Bestellobjekts zu „Closed“. Coupa setzt diesen Status häufig automatisch anhand von Geschäftsregeln für Toleranzen beim Wareneingang und bei der Rechnungsstellung.
Erfassung
Abgeleitet aus dem Timestamp der Statusänderung zu „Closed“.
Ereignistyp
inferred
|
|||
|
Bestellung an Lieferanten gesendet
|
Diese Aktivität kennzeichnet den Zeitpunkt, zu dem die genehmigte Bestellung offiziell an den Lieferanten übermittelt wird, zum Beispiel per E-Mail oder über das Coupa Supplier Portal. Damit wird die Bestellung von einem internen Dokument zu einer externen Verpflichtung. | ||
|
Warum das wichtig ist
Dieser wichtige Meilenstein schließt den internen Ablauf von der Anforderung bis zur Bestellung ab und markiert den Beginn der Lieferzeit. Er ist entscheidend, um sowohl die interne Effizienz als auch die Lieferantenleistung zu messen.
Woher beziehen
Wird häufig aus einer Statusänderung der Bestellung zu „Ordered“ oder „Sent“ abgeleitet. Im Bestelldatensatz in Coupa kann außerdem ein spezifischer Timestamp wie „last_exported_at“ oder „sent_to_supplier_at“ verfügbar sein.
Erfassung
Abgeleitet aus dem Timestamp der Statusänderung zu „Ordered“ oder aus einem spezifischen Feld für den Übermittlungs-Timestamp.
Ereignistyp
inferred
|
|||
|
Bestellung genehmigt
|
Dieser Meilenstein zeigt an, dass die Bestellung den internen Genehmigungs-Workflow durchlaufen hat und an den Lieferanten ausgegeben werden darf. In einem mehrstufigen Prozess ist dies üblicherweise der letzte Genehmigungsschritt. | ||
|
Warum das wichtig ist
Dieser wichtige Meilenstein ist entscheidend für die Berechnung der Genehmigungszykluszeit und die Ermittlung von Engpässen bei Genehmigungen. Außerdem dient er als wichtiger Compliance-Kontrollpunkt.
Woher beziehen
Wird aus dem Genehmigungsverlauf der Bestellung in Coupa erfasst. Der Timestamp der abschließenden Genehmigung gibt den Ereigniszeitpunkt an.
Erfassung
Wird im Genehmigungsverlauf protokolliert, sobald der letzte Genehmiger seine Aufgabe abgeschlossen hat.
Ereignistyp
explicit
|
|||
|
Bestellung storniert
|
Diese Aktivität bezeichnet die Stornierung einer Bestellung, bevor sie abgeschlossen wurde. Eine Stornierung kann in verschiedenen Prozessphasen erfolgen, zum Beispiel wenn die Anforderung nicht mehr gültig ist oder die Bestellung versehentlich erstellt wurde. | ||
|
Warum das wichtig ist
Stornierungen stellen einen alternativen Prozessabschluss dar. Ihre Erfassung ist wichtig, um abgebrochene Prozessabläufe zu verstehen und die Gründe für aufgegebene Bestellanforderungen zu ermitteln.
Woher beziehen
Abgeleitet aus einer Statusänderung des Bestellobjekts zu „Canceled“. Der Timestamp dieser Statusänderung dient als Ereigniszeitpunkt.
Erfassung
Abgeleitet aus dem Timestamp der Statusänderung zu „Canceled“.
Ereignistyp
inferred
|
|||
|
Wareneingang gebucht
|
Dieses Ereignis bestätigt formell, dass die Waren eingegangen, geprüft und angenommen wurden. Es aktualisiert die Bestandsdaten und zeigt an, dass der Lieferant seine Verpflichtung für diese Lieferung erfüllt hat. | ||
|
Warum das wichtig ist
Dieser wichtige Meilenstein markiert das Ende der Lieferzeit und dient dazu, die Einhaltung von Lieferterminen zu messen. Verzögerungen bei der Buchung des Wareneingangs können die Sicht auf die tatsächlichen Bestände beeinträchtigen.
Woher beziehen
Dies ist ein zentraler Geschäftsvorgang in Coupa, der im Receipt-Objekt erfasst wird. Als Ereignis-Timestamp dient der Zeitpunkt, zu dem sich der Status des Wareneingangs zu „Posted“ oder „Received“ ändert.
Erfassung
Wird protokolliert, sobald der Wareneingangsvorgang im System abgeschlossen ist.
Ereignistyp
explicit
|
|||
|
Bestellanforderung genehmigt
|
Bevor eine Bestellanforderung in eine Bestellung umgewandelt werden kann, durchläuft sie einen Genehmigungs-Workflow. Dieses Ereignis kennzeichnet die endgültige Genehmigung. Danach kann die Bestellung aufgegeben werden. | ||
|
Warum das wichtig ist
Die Erfassung von Genehmigungen für Bestellanforderungen hilft, Engpässe in der Phase vor der Bestellung zu erkennen. Verzögerungen wirken sich unmittelbar darauf aus, wie schnell eine Bestellung ausgestellt werden kann.
Woher beziehen
Dieses Ereignis wird in der Regel aus dem Genehmigungsverlauf des Anforderungsobjekts in Coupa ausgelesen. Zur abschließenden Genehmigung sind ein entsprechender Timestamp und der Benutzer hinterlegt.
Erfassung
Wird im Genehmigungsverlauf protokolliert, sobald der letzte Genehmiger die Entscheidung trifft.
Ereignistyp
explicit
|
|||
|
Bestellung abgelehnt
|
Dieses Ereignis tritt ein, wenn ein Genehmiger die Bestellung während des Genehmigungs-Workflows ablehnt. In der Regel wird sie anschließend zur Überarbeitung oder Stornierung an den Ersteller zurückgesendet. | ||
|
Warum das wichtig ist
Die Analyse von Ablehnungen hilft, Probleme mit der Datenqualität, Richtlinienverstöße oder Schulungsbedarf aufzudecken. Außerdem werden Nacharbeitsschleifen sichtbar, die den Prozess erheblich verzögern.
Woher beziehen
Dieses Ereignis wird ausdrücklich im Genehmigungsverlauf der Bestellung in Coupa erfasst. Der Verlauf enthält die Aktion „Reject“ mit dem zugehörigen Timestamp.
Erfassung
Wird im Genehmigungsverlauf mit dem Status „Reject“ protokolliert.
Ereignistyp
explicit
|
|||
|
Bestellung als Entwurf erstellt
|
Dieses Ereignis bezeichnet die erstmalige Erstellung des Bestelldokuments im System, häufig auf Grundlage einer genehmigten Anforderung. Zu diesem Zeitpunkt liegt die Bestellung als interner Entwurf vor. Sie wurde noch nicht zur Genehmigung eingereicht und nicht an den Lieferanten gesendet. | ||
|
Warum das wichtig ist
Mit dieser Aktivität beginnt die Messung der Kennzahl „Genehmigungszykluszeit der Bestellung“. Sie ist der erste formelle Schritt im Lebenszyklus der Bestellung.
Woher beziehen
Dies entspricht dem Erstellungs-Timestamp des Bestelldatensatzes in Coupa, der üblicherweise in einem Feld wie „created_at“ zu finden ist.
Erfassung
Wird anhand des vom System erzeugten Erstellungs-Timestamps des Bestelldatensatzes erfasst.
Ereignistyp
explicit
|
|||
|
Bestellung eingereicht
|
Nach der Erstellung des Bestellentwurfs wird die Bestellung formell in den Genehmigungs-Workflow eingereicht. Mit dieser gesonderten Benutzeraktion wechselt die Bestellung vom Entwurfsstatus in den Status „Genehmigung ausstehend“. | ||
|
Warum das wichtig ist
Dieses Ereignis unterscheidet die Zeit für die Erstellung des Entwurfs von der Zeit, in der die Bestellung tatsächlich auf die Genehmigung wartet. Dadurch lassen sich das Benutzerverhalten und die Übergaben im Prozess besser nachvollziehen.
Woher beziehen
Wird aus einer Statusänderung des Bestellobjekts abgeleitet, zum Beispiel von „draft“ zu „pending approval“. Verwendet wird der Timestamp dieser Statusänderung.
Erfassung
Abgeleitet aus dem Timestamp der Statusänderung zu „pending approval“.
Ereignistyp
inferred
|
|||
|
Bestellung geändert
|
Dieses Ereignis steht für jede Änderung an der Bestellung nach ihrer ersten Erstellung als Entwurf. In Coupa werden Änderungen häufig über die Versionierung des Bestelldokuments nachverfolgt. | ||
|
Warum das wichtig ist
Die Erfassung von Änderungen ist entscheidend für Kennzahlen wie die Änderungsrate von Bestellungen und den Anteil nicht konformer Bestellungen. Häufige Änderungen deuten auf instabile Prozesse oder ungenaue ursprüngliche Anforderungen hin.
Woher beziehen
Das Ereignis lässt sich durch die Nachverfolgung verschiedener Versionen einer Bestellung ableiten. Jede neue Versionsnummer über der ersten Version weist auf eine Änderung hin. Als Ereignis-Timestamp dient das Erstellungsdatum der neuen Version.
Erfassung
Abgeleitet aus dem Erstellungs-Timestamp einer neuen Bestellversion.
Ereignistyp
inferred
|
|||
|
Leistungserbringung bestätigt
|
Bei Bestellungen für Dienstleistungen entspricht diese Aktivität dem Wareneingang. Sie bestätigt, dass die Dienstleistung gemäß den Bedingungen der Bestellung erbracht wurde. | ||
|
Warum das wichtig ist
Die Erfassung von Leistungsbestätigungen ist wichtig, um die Ausgaben für Dienstleistungen zu steuern und sicherzustellen, dass nur nachweislich abgeschlossene Arbeiten bezahlt werden.
Woher beziehen
Dieses Ereignis wird bei der Erstellung oder Genehmigung eines Leistungsnachweises oder Service Entry Sheets erfasst, der mit der Bestellung in Coupa verknüpft ist.
Erfassung
Wird bei der Erstellung und Genehmigung eines Service Entry Sheets protokolliert.
Ereignistyp
explicit
|
|||
|
Lieferant hat Bestellung bestätigt
|
Dieses Ereignis zeigt an, dass der Lieferant die Bestellung erhalten und bestätigt hat. Die Bestätigung wird häufig elektronisch über ein Lieferantenportal wie das Coupa Supplier Portal (CSP) erfasst. | ||
|
Warum das wichtig ist
Die Bestätigung durch den Lieferanten gibt Sicherheit, dass die Bestellung bearbeitet wird. Das verbessert die Genauigkeit von Lieferprognosen und verringert Unsicherheiten in der Lieferkette.
Woher beziehen
Diese Information ist in der Regel in der Bestellung verfügbar, wenn der Lieferant im Coupa Supplier Portal die Aktion „Acknowledge“ ausführt. Verwendet wird der Timestamp dieser Aktion.
Erfassung
Wird protokolliert, wenn ein Lieferant im Lieferantenportal die Aktion „Acknowledge“ ausführt.
Ereignistyp
explicit
|
|||
|
Qualitätsprüfung durchgeführt
|
Dieses Ereignis zeigt an, dass ein eingegangener Artikel einer Qualitätsprüfung unterzogen und für gut befunden wurde. Je nach Unternehmensprozess kann dies ein separater Schritt nach der Buchung des Wareneingangs sein. | ||
|
Warum das wichtig ist
Diese Aktivität ist wichtig, um die Effizienz der Qualitätskontrolle zu messen. Verzögerungen können Engpässe zwischen Wareneingang und Verfügbarkeit zur Nutzung verursachen.
Woher beziehen
Dieses Ereignis kann als Statusänderung der Wareneingangsposition oder über ein separates Prüfobjekt in Coupa erfasst werden. Ob die Daten verfügbar sind, hängt davon ab, ob das Qualitätsmodul oder ein benutzerdefinierter Workflow verwendet wird.
Erfassung
Abgeleitet aus einer Statusänderung des Wareneingangs oder einem Timestamp in einem zugehörigen Prüfdatensatz.
Ereignistyp
inferred
|
|||
|
Rechnung zur Bestellung eingegangen
|
Dieses Ereignis kennzeichnet den Eingang und die Erfassung einer Lieferantenrechnung, die sich auf die Bestellung bezieht. Damit beginnt die Rechnungsbearbeitung und Zahlungsphase des P2P-Zyklus. | ||
|
Warum das wichtig ist
Die Verknüpfung des Rechnungseingangs mit der Bestellung bietet eine End-to-End-Sicht auf den Transaktionslebenszyklus, auch wenn die Rechnung Teil des Kreditorenprozesses ist. So lässt sich der Zeitraum zwischen Lieferung und Rechnungsstellung analysieren.
Woher beziehen
Wird anhand des Erstellungs-Timestamps des Rechnungsdokuments in Coupa erfasst. Dabei wird die Rechnung der entsprechenden Bestellnummer zugeordnet.
Erfassung
Wird bei der Erstellung eines mit der Bestellung verknüpften Rechnungsdatensatzes protokolliert.
Ereignistyp
explicit
|
|||
|
Waren zurückgesendet
|
Diese Aktivität wird erfasst, wenn zuvor eingegangene Waren an den Lieferanten zurückgesendet werden. Gründe dafür sind üblicherweise Qualitätsmängel, Beschädigungen oder eine falsche Lieferung. | ||
|
Warum das wichtig ist
Die Erfassung von Rücksendungen ist wichtig, um die Rücksendequote zu berechnen und Probleme mit der Lieferantenqualität oder der Bestellgenauigkeit zu erkennen. Hohe Rücksendequoten weisen häufig auf kostspielige Prozessfehler hin.
Woher beziehen
Wird in Coupa über einen Vorgang „Return to Supplier“ oder eine negative Wareneingangsbuchung erfasst. Der Timestamp dieses Vorgangs dient als Ereigniszeitpunkt.
Erfassung
Wird protokolliert, wenn ein mit der ursprünglichen Bestellung oder dem Wareneingang verknüpfter Rücksendevorgang erstellt wird.
Ereignistyp
explicit
|
|||
|
Wareneingang begonnen
|
Diese Aktivität kennzeichnet den Beginn des Wareneingangsprozesses, zum Beispiel wenn bei der physischen Ankunft der Waren in Coupa ein Wareneingangsbeleg erstellt wird. Die Waren wurden noch nicht formell im Bestand gebucht oder als eingegangen bestätigt. | ||
|
Warum das wichtig ist
Dieses Ereignis ist der Startpunkt für die Messung der Kennzahl „Bearbeitungszeit des Wareneingangs“. Es hilft, die Wartezeit der Waren an der Rampe von der Zeit für die systemseitige Bearbeitung zu unterscheiden.
Woher beziehen
Das Ereignis lässt sich aus dem Erstellungs-Timestamp eines Wareneingangsbelegs mit dem Status „Draft“ oder „Pending“ ableiten. Es tritt vor der endgültigen Buchung des Wareneingangs auf.
Erfassung
Abgeleitet aus dem Erstellungs-Timestamp eines Wareneingangsdatensatzes, der noch nicht gebucht wurde.
Ereignistyp
inferred
|
|||
Anleitungen zur Datenextraktion
Möchten Sie loslegen?
Bereiten Sie Ihre Daten mit diesem Template für Process Mining vor und gewinnen Sie konkrete Erkenntnisse. Beginnen Sie noch heute damit, Ihren Purchase-to-Pay-Prozess für Bestellungen zu optimieren.
Optimieren Sie Ihre P2P-Bestellungen und steigern Sie noch heute die Effizienz
Verkürzen Sie Ihre P2P-Durchlaufzeit um 30 % und sehen Sie schnell erste Ergebnisse.
Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.