Daten-Template: Procure-to-Pay - Bestellung

Oracle Fusion Financials
Daten-Template: Procure-to-Pay - Bestellung

Ihr Procure-to-Pay-Bestelldaten-Template

Dieses Template bietet einen klaren Fahrplan für die Sammlung der notwendigen Daten, um Ihren Procure-to-Pay-Bestellprozess zu analysieren. Es skizziert die wesentlichen Datenattribute, wichtige Aktivitäten zur Verfolgung und praktische Anleitungen zur Extraktion dieser Informationen. Nutzen Sie es, um sicherzustellen, dass Sie alle kritischen Details für ein effektives Process Mining erfassen.
  • Empfohlene Attribute für eine umfassende Datenerfassung
  • Wichtige Prozessaktivitäten zur Nachverfolgung und Analyse
  • Schritt-für-Schritt-Anleitung zur Datenextraktion für Oracle Fusion Financials
Neu bei Event Logs? Erfahren Sie wie man ein Process Mining Event Log erstellt.

Purchase to Pay - Bestellattribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihr Event Log aufnehmen sollten, um eine umfassende Analyse Ihres Beschaffungsprozesses – Bestellvorgangs zu ermöglichen.
3 Erforderlich 7 Empfohlen 12 Optional
Name Beschreibung
Aktivität
ActivityName
Der Name eines spezifischen Geschäfts-Events oder -Schritts, der innerhalb des Purchase Order-Lebenszyklus erfolgte.
Beschreibung

Dieses Attribut beschreibt eine spezifische Aufgabe oder Statusänderung im Prozess, wie z.B. 'Bestellung erstellt' oder 'Wareneingang'. Diese Aktivitäten bilden die Abfolge von Events, die den Prozessfluss ausmachen.

Die Analyse der Abfolge und des Timings dieser Aktivitäten ist der Kern des Process Mining. Sie hilft, die Prozesslandkarte zu visualisieren, Bottlenecks zu identifizieren, Abweichungen vom Standardverfahren zu entdecken und die Dauer spezifischer Schritte zu messen.

Warum es wichtig ist

Aktivitäten sind die Bausteine der Prozesslandkarte. Deren Verfolgung ermöglicht die Visualisierung und Analyse des Prozessflusses, von Engpässen und Abweichungen.

Woher erhalten

Abgeleitet aus Statusänderungen in Tabellen wie PO_HEADERS_ALL und PO_ACTION_HISTORY oder aus spezifischen Transaktionstabellen wie RCV_TRANSACTIONS für Wareneingänge.

Beispiele
Bestellung erstelltBestellung genehmigtWare erhalten
Bestellung
PurchaseOrder
Die eindeutige Kennung für das Bestelldokument, die als primäre Case ID für die Verfolgung des Beschaffungslebenszyklus dient.
Beschreibung

Die Bestellnummer ist die zentrale Kennung, die alle zugehörigen Aktivitäten, von der Erstellung bis zum finalen Abschluss, miteinander verbindet. Sie ermöglicht die End-to-End-Analyse eines einzelnen Beschaffungsfalls.

Im Process Mining stellt jede eindeutige Bestellnummer eine einzelne Instanz des Prozesses dar. Die Analyse von Daten, die nach dieser Kennung gruppiert sind, hilft dabei, Prozessvarianten, Durchlaufzeiten und die Compliance für einzelne Bestellungen zu verstehen.

Warum es wichtig ist

Dies ist die wesentliche Case ID, die alle zugehörigen Events miteinander verbindet und die Rekonstruktion und Analyse des gesamten Bestell-Lebenszyklus ermöglicht.

Woher erhalten

Oracle Fusion Cloud SCM, Beschaffungsmodul, Tabelle PO_HEADERS_ALL, Spalte SEGMENT1.

Beispiele
100234510023461002347
Startzeit
EventTime
Der Zeitstempel, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung

Dieses Attribut erfasst das genaue Datum und die Uhrzeit jeder Activity im Prozess. Es ist grundlegend für die chronologische Anordnung von Events und für alle zeitbasierten Analysen.

Im Process Mining wird die Startzeit verwendet, um das Event Log zu erstellen, Zykluszeiten zwischen Activities zu berechnen, Wartezeiten zu messen und die Prozessperformance über verschiedene Zeiträume hinweg zu analysieren. Es ist essenziell für Dashboards, die sich auf Zykluszeiten und Performance beziehen.

Warum es wichtig ist

Dieser Timestamp ist entscheidend für die korrekte Sequenzierung von Events und die Berechnung aller dauerbasierten Metriken, wie z. B. Zykluszeiten und Engpässe.

Woher erhalten

Timestamp-Felder wie CREATION_DATE und LAST_UPDATE_DATE aus verschiedenen Tabellen, darunter PO_HEADERS_ALL, PO_ACTION_HISTORY und RCV_SHIPMENT_LINES.

Beispiele
2023-04-15T10:05:00Z2023-04-16T14:30:00Z2023-05-01T09:00:00Z
Abteilung
DepartmentName
Der Name der Abteilung, die die Purchase Order initiiert hat oder dafür verantwortlich ist.
Beschreibung

Dieses Attribut gibt die Organisationseinheit an, wie 'Finanzen', 'IT' oder 'Fertigung', die dem Kauf zugeordnet ist. Es wird für die Kostenverteilung und das Organisationsreporting verwendet.

Im Process Mining-Kontext ist die Segmentierung des Prozesses nach Abteilung entscheidend, um die Performance zu vergleichen, abteilungsspezifische Bottlenecks zu identifizieren und Variationen in der Prozessausführung innerhalb der Organisation zu verstehen. Es unterstützt direkt Dashboards wie 'Analyse der Bestellgenehmigungszykluszeiten' und 'Trends bei Bestellmodifikationen'.

Warum es wichtig ist

Ermöglicht das Filtern und Vergleichen der Prozessleistung über verschiedene Geschäftseinheiten hinweg, wodurch abteilungsspezifische Probleme oder Best Practices aufgedeckt werden.

Woher erhalten

Abgeleitet aus Kostenstelleninformationen in Tabellen wie PO_DISTRIBUTIONS_ALL, die mit Stammdaten der Abteilungen verknüpft sind.

Beispiele
IT-BetriebMarketingForschung und Entwicklung
Benutzer
UserName
Die User-ID oder der Name der Person, die die Aktivität ausgeführt hat.
Beschreibung

Dieses Attribut identifiziert den Mitarbeiter oder Systembenutzer, der für ein bestimmtes Event verantwortlich ist, wie z.B. die Erstellung einer Anforderung, die Genehmigung einer Bestellung oder die Buchung eines Wareneingangs. Es wird typischerweise aus Feldern wie 'Erstellt von' oder 'Zuletzt aktualisiert von' bezogen.

Die Analyse des Prozesses nach Benutzer hilft, die Arbeitslastverteilung, die individuelle Leistung und den Schulungsbedarf zu verstehen. Es ist grundlegend für das Dashboard 'Genehmigungsressourcen-Auslastung' und für die Untersuchung von Compliance-Problemen im Zusammenhang mit Benutzeraktionen.

Warum es wichtig ist

Ordnet Benutzeraktionen bestimmten Personen zu und ermöglicht so die Analyse der Arbeitslast, die Leistungsbewertung und die Identifizierung von Schulungsmöglichkeiten.

Woher erhalten

Verknüpfen Sie Daten mit Benutzertabellen anhand von IDs in Feldern wie CREATED_BY oder LAST_UPDATED_BY in Tabellen wie PO_HEADERS_ALL und PO_ACTION_HISTORY.

Beispiele
john.doejane.smithsystem.batch
Bestellgesamtwert
PurchaseOrderTotalAmount
Der gesamte monetäre Wert der Bestellung.
Beschreibung

Dieses Attribut stellt die Gesamtkosten aller Positionen der Bestellung in der angegebenen Währung dar. Es ist eine wichtige finanzielle Metrik zum Verständnis des Wertes von Transaktionen, die den Prozess durchlaufen.

Die Analyse des Gesamtbetrags der Bestellung hilft bei der Priorisierung von Prozessverbesserungsbemühungen. Beispielsweise könnten Bestellungen mit hohem Wert einen strengeren Genehmigungsprozess durchlaufen. Sie ermöglicht auch eine Finanzwirkungsanalyse, wie die Berechnung des Wertes von Bestellungen, die häufig geändert oder verzögert werden.

Warum es wichtig ist

Bietet finanziellen Prozesskontext für wertbasierte Analysen, wie z.B. Fokus auf wertvolle Aufträge oder finanzielle Auswirkungen von Verzögerungen.

Woher erhalten

Berechnet durch Summierung der Beträge aus PO_LINES_ALL für einen bestimmten PO header oder entnommen aus einer Gesamtsumme auf Kopfebene, falls verfügbar.

Beispiele
5250.00120000.50750.99
Endzeit
EndTime
Der Timestamp, wann eine Aktivität abgeschlossen wurde. Oft derselbe wie die Start Time für atomare Events.
Beschreibung

Für Aktivitäten mit einer Dauer markiert dies die Abschlusszeit. Bei sofortigen Events ist sie typischerweise identisch mit der Start Time. Sie ist entscheidend für die Berechnung der Bearbeitungszeit einzelner Aktivitäten.

Eine separate End Time ermöglicht eine präzisere Analyse der Aktivitätsdauern, die sich von der Wartezeit zwischen den Aktivitäten unterscheiden kann. Dies hilft, aktive Arbeitszeit von Leerlaufzeiten abzugrenzen und unterstützt die Analyse der Ressourcenauslastung und Effizienz.

Warum es wichtig ist

Ermöglicht die Berechnung präziser Bearbeitungszeiten für Aktivitäten, was entscheidend für die Analyse der Ressourceneffizienz und die Identifizierung zeitaufwendiger Aufgaben ist.

Woher erhalten

Kann dieselbe wie die Startzeit für atomare Ereignisse sein oder von nachfolgenden Ereignis-Timestamps abgeleitet werden. Für einige Aktivitäten kann ein separater Abschluss-Timestamp existieren.

Beispiele
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
Lieferantenname
VendorName
Der Name des Lieferanten oder Anbieters, von dem die Waren oder Dienstleistungen gekauft werden.
Beschreibung

Dieses Attribut identifiziert den externen Lieferanten für die Bestellung. Es ist ein kritisches Stammdaten-Element, das mit dem Bestellkopf verknüpft ist.

Die Lieferantenanalyse ist ein wichtiger Bestandteil des Procure-to-Pay Process Mining. Durch das Filtern oder die Segmentierung nach Lieferant können Unternehmen die 'Lieferleistung der Lieferanten' analysieren, Pünktlichkeitsquoten vergleichen und die 'Retourenquote' untersuchen, um leistungsstarke oder leistungsschwache Lieferanten zu identifizieren. Diese Daten sind entscheidend für das Lieferantenbeziehungsmanagement und die strategische Beschaffung.

Warum es wichtig ist

Unerlässlich für die Lieferantenleistungsanalyse, da es den Vergleich von Lieferzeiten, Retourenquoten und der Gesamtzuverlässigkeit verschiedener Lieferanten ermöglicht.

Woher erhalten

Verknüpft von PO_HEADERS_ALL.VENDOR_ID mit POZ_SUPPLIERS.VENDOR_NAME.

Beispiele
Global Office SuppliesTech Solutions Inc.Advanced Logistics Co.
Name des Genehmigers
ApproverName
Der Name des Benutzers, der eine Genehmigungs- oder Ablehnungsaktion für die Bestellung durchgeführt hat.
Beschreibung

Dieses Attribut erfasst die Person, die für einen Genehmigungsschritt im Workflow verantwortlich ist. Diese Informationen werden typischerweise in einer Aktionshistorie oder Workflow-Log-Tabelle gespeichert, die mit der Bestellung verknüpft ist.

Die Analyse von Daten nach Genehmiger ist entscheidend für die Dashboards 'PO-Genehmigungs-Durchlaufzeitanalyse' und 'Genehmigungsressourcen-Auslastung'. Sie hilft zu identifizieren, welche Genehmiger oder Genehmigungsgruppen Bottlenecks sind, ermöglicht eine faire Beurteilung der Arbeitslast und kann Möglichkeiten zur Delegation oder Prozessneugestaltung aufzeigen.

Warum es wichtig ist

Identifiziert die Personen in der Genehmigungskette und ermöglicht so die Analyse von Genehmigungsengpässen, Arbeitslast und Cycle Times pro Genehmiger.

Woher erhalten

Der Benutzer, der die Aktion durchgeführt hat, zu finden in PO_ACTION_HISTORY.ACTION_PERFORMED_BY, verknüpft mit einer Benutzertabelle für den vollständigen Namen.

Beispiele
susan.managerdavid.directoremily.finance
Wunschliefertermin
RequestedDeliveryDate
Das Datum, bis zu dem die anfordernde Partei die Lieferung der Waren oder Dienstleistungen erwartet.
Beschreibung

Dieses Datum wird auf der Bestellposition angegeben und kommuniziert den gewünschten Lieferzeitpunkt an den Lieferanten. Es dient als Basis für die Messung der pünktlichen Lieferperformance.

Dieses Attribut ist entscheidend für die Berechnung des KPI 'Pünktliche Lieferrate'. Durch den Vergleich des tatsächlichen Wareneingangsdatums mit dem angeforderten Lieferdatum können Organisationen die Zuverlässigkeit von Lieferanten quantitativ messen und verfolgen sowie systemische Verzögerungen in der Lieferkette identifizieren.

Warum es wichtig ist

Dient als Basis zur Messung der Termintreue bei Lieferungen, einem zentralen KPI zur Bewertung der Lieferantenverlässlichkeit und Supply Chain-Effizienz.

Woher erhalten

Befindet sich auf der Positionslokationsebene, in der Tabelle PO_LINE_LOCATIONS_ALL, Spalte NEED_BY_DATE.

Beispiele
2023-05-202023-06-152023-07-01
Bestellanforderung
PurchaseRequisitionNumber
Die Kennung der Purchase Requisition (Bestellanforderung), die der Purchase Order vorausging und sie autorisierte.
Beschreibung

Die Bestellanforderung ist das interne Dokument, das zur Anforderung von Waren oder Dienstleistungen verwendet wird. Dieses Attribut verknüpft die Bestellung mit ihrer ursprünglichen Anforderung.

Die Einbeziehung der Anforderungsnummer ermöglicht eine breitere Analyse des Beschaffungsprozesses, beginnend mit der ursprünglichen Anforderung anstatt nur der Bestellung. Es kann helfen, die Durchlaufzeit von der Anforderung bis zur Bestellung zu analysieren und zu verstehen, wie Anforderungsdetails den nachgelagerten Bestellprozess beeinflussen.

Warum es wichtig ist

Verknüpft die Bestellung mit der ursprünglichen Anforderung, was eine umfassendere End-to-End-Prozessansicht von der Anforderung bis zur Zahlung ermöglicht.

Woher erhalten

Verknüpft über die Tabelle PO_DISTRIBUTIONS_ALL, die REQ_DISTRIBUTION_ID enthält, und zurückführt zur Tabelle POR_REQUISITION_LINES_ALL.

Beispiele
PR-2023-05-001PR-2023-05-002PR-2023-05-003
Bestellstatus
PurchaseOrderStatus
Der aktuelle Status des Purchase Order-Dokuments.
Beschreibung

Dieses Attribut gibt den aktuellen Status der Bestellung in ihrem Lebenszyklus an, wie 'Offen', 'Genehmigt', 'Endgültig geschlossen' oder 'Storniert'. Es bietet eine Momentaufnahme des Fortschritts der Bestellung.

Obwohl sich Process Mining auf die Abfolge von Activities konzentriert, ist der aktuelle Status für die Filterung von Cases wertvoll. So kann die Analyse beispielsweise auf offene Bestellungen konzentriert werden, um die aktuelle Pipeline zu verstehen, oder auf geschlossene Bestellungen, um abgeschlossene Prozessinstanzen zu analysieren. Es ist essenziell für das Dashboard 'Bestellfluss & Status'.

Warum es wichtig ist

Bietet einen aktuellen Schnappschuss des Bestellstatus, der es ermöglicht, die Analyse auf aktive, abgeschlossene oder stornierte Bestellungen zu filtern.

Woher erhalten

Oracle Fusion Cloud SCM, Tabelle PO_HEADERS_ALL, Spalten AUTHORIZATION_STATUS oder DOCUMENT_STATUS.

Beispiele
OPENGENEHMIGTFINALLY_CLOSEDSTORNIERT
Bestelltyp
PurchaseOrderType
Die Art der Bestellung, wie z.B. 'Standard', 'Rahmenbestellung' oder 'Vertragsbestellung'.
Beschreibung

Dieses Attribut klassifiziert die Bestellung basierend auf ihrem Beschaffungszweck. Verschiedene Arten von Bestellungen folgen oft unterschiedlichen Prozessregeln und Lebenszyklen.

Eine Standardbestellung ist ein einmaliger Kauf, während eine 'Rahmenbestellung' eine längerfristige Vereinbarung mit einem Lieferanten ist. Die Analyse des Prozesses nach Bestelltyp ermöglicht eine genauere Sicht auf die Prozessleistung, da ein Vergleich der Durchlaufzeit einer Standardbestellung mit einem Rahmenvertrag irreführend wäre. Sie ermöglicht direkte Vergleiche.

Warum es wichtig ist

Differenziert zwischen verschiedenen Beschaffungsszenarien und ermöglicht so genauere, direkt vergleichbare Leistungsbeurteilungen für ähnliche Auftragsarten.

Woher erhalten

Oracle Fusion Cloud SCM, Tabelle PO_HEADERS_ALL, Spalte TYPE_LOOKUP_CODE.

Beispiele
STANDARDBLANKETCONTRACT
Einkaufskategorie
PurchaseCategory
Die Klassifizierung der gekauften Waren oder Dienstleistungen, wie z.B. 'IT-Hardware' oder 'Büromaterial'.
Beschreibung

Dieses Attribut kategorisiert die Artikel auf der Bestellung in eine Beschaffungshierarchie. Diese Klassifizierung wird für die Ausgabenanalyse und das Lieferantenmanagement verwendet.

Im Process Mining kann die Segmentierung des Prozesses nach Einkaufskategorie unterschiedliche Verhaltensweisen oder Leistungsniveaus aufzeigen. Zum Beispiel könnte der Genehmigungsprozess für Kapitalausgaben länger sein als für Betriebsbedarf. Es unterstützt direkt das Dashboard 'Retourenquote & Gründe', indem es die Analyse ermöglicht, welche Kategorien am häufigsten retourniert werden.

Warum es wichtig ist

Ermöglicht die Prozessanalyse nach Ausgabenart, wodurch sich unterschiedliche Prozesspfade, Engpässe oder Retourenquoten für verschiedene Warengruppen aufdecken lassen.

Woher erhalten

Verknüpft von PO_LINES_ALL.CATEGORY_ID mit der EGP_CATEGORIES_VL View.

Beispiele
IT.Hardware.LaptopsOffice.Supplies.StationeryProfessional.Services.Consulting
Freigabe-Durchlaufzeit
ApprovalCycleTime
Die Dauer von der Erstellung einer Purchase Order bis zu ihrer endgültigen Genehmigung.
Beschreibung

Dies ist eine berechnete Dauermetrik, die die verstrichene Zeit zwischen der Aktivität 'Purchase Order Created' und der Aktivität 'Purchase Order Approved' für einen einzelnen Case misst.

Dieses Attribut liefert direkt den Wert für den KPI 'Average PO Approval Cycle Time'. Die Analyse seiner Verteilung hilft, die Effizienz des Genehmigungs-Workflows zu verstehen, Ausreißer zu identifizieren und die Auswirkungen von Prozessverbesserungsinitiativen zur Reduzierung von Genehmigungsverzögerungen zu messen.

Warum es wichtig ist

Quantifiziert den Approval Bottleneck (Genehmigungsengpass), misst direkt den KPI 'Durchschnittliche PO Approval Cycle Time' und hebt Verzögerungen im Workflow hervor.

Woher erhalten

Berechnetes Feld. Die Differenz zwischen den Timestamps der Aktivitäten 'Bestellung genehmigt' und 'Bestellung erstellt'.

Beispiele
P2DPT8H30MP5DT12H
Geschäftseinheit
BusinessUnitName
Die spezifische Geschäftseinheit innerhalb der Organisation, die den Kauf tätigt.
Beschreibung

Die Business Unit repräsentiert eine eigenständige Geschäftseinheit innerhalb des Unternehmens, oft mit eigenem Hauptbuch und Finanzberichten. Sie ist ein primärer Daten-Segmentierungsmechanismus in Oracle Fusion.

Die Analyse der Prozessleistung nach Business Unit ist in großen, multinationalen Unternehmen entscheidend. Sie ermöglicht den Vergleich der Beschaffungseffizienz, Compliance und Kosten über verschiedene Organisationsteile hinweg, wobei sowohl Best Practices als auch Verbesserungsbereiche hervorgehoben werden.

Warum es wichtig ist

Entscheidend für große Organisationen, um Prozesseffizienz und Compliance über verschiedene Geschäftsbereiche hinweg zu vergleichen.

Woher erhalten

Der Kontext der Business Unit befindet sich typischerweise im Bestellkopf, PO_HEADERS_ALL.PRC_BU_ID, der mit der FUN_ALL_BUSINESS_UNITS_V view verknüpft ist.

Beispiele
US-GeschäftseinheitEMEA VisionAPAC Services
Ist Genehmigung konform
IsApprovalCompliant
Ein Flag, das anzeigt, ob die Bestellung vor dem Versand an den Lieferanten genehmigt wurde.
Beschreibung

Dies ist ein berechnetes boolesches Attribut, das die Einhaltung einer wichtigen internen Kontrolle überprüft: Eine Bestellung muss genehmigt werden, bevor sie an einen Lieferanten versandt wird. Es ist 'wahr', wenn die Aktivität 'Purchase Order Approved' vor der Aktivität 'Purchase Order Sent to Vendor' erfolgt.

Dieses Attribut ist entscheidend für das Dashboard 'PO Process Compliance Audit' und den KPI 'PO Approval Compliance Rate'. Es bietet eine einfache Möglichkeit, Compliance-Verstöße zu identifizieren und zu quantifizieren, um Beschaffungsrichtlinien durchzusetzen und Risiken im Zusammenhang mit unbefugten Ausgaben zu mindern.

Warum es wichtig ist

Misst direkt den KPI 'PO Approval Compliance Rate' und hebt kritische Verstöße gegen interne Kontrollen hervor, bei denen Bestellungen vor der Genehmigung an Lieferanten gesendet werden.

Woher erhalten

Berechnetes Feld. Auf 'true' gesetzt, wenn der Timestamp für 'Bestellung genehmigt' kleiner oder gleich dem Timestamp für 'Bestellung an Lieferanten gesendet' ist.

Beispiele
truefalsch
Ist Nacharbeit
IsRework
Ein Flag, das anzeigt, ob die Bestellung nach ihrer ersten Erstellung geändert wurde.
Beschreibung

Dies ist ein berechnetes boolesches Attribut, das auf 'wahr' gesetzt wird, wenn ein Bestell-Case eine Aktivität 'Purchase Order Changed' enthält. Es hilft, Bestellungen schnell zu identifizieren, die Korrekturen oder Änderungen erforderten.

Dieses Kennzeichen vereinfacht die Berechnung des KPI 'PO Modification Rate' und ermöglicht eine einfache Filterung und Analyse überarbeiteter Bestellungen. Ein besseres Verständnis der Merkmale überarbeiteter Bestellungen, wie z. B. der beteiligten Lieferanten oder Abteilungen, kann dabei helfen, die Grundursachen für Datenungenauigkeiten oder sich ändernde Anforderungen zu identifizieren.

Warum es wichtig ist

Unterstützt direkt den KPI 'PO Modification Rate' und vereinfacht die Analyse von Prozessinstabilität, indem alle geänderten Bestellungen gekennzeichnet werden.

Woher erhalten

Berechnetes Feld. Auf 'true' gesetzt, wenn das Event Log für einen Case die Aktivität 'Bestellung geändert' enthält, andernfalls 'false'.

Beispiele
truefalsch
Ist verspätete Lieferung
IsLateDelivery
Ein Flag, das anzeigt, ob der endgültige Wareneingang nach dem angeforderten Lieferdatum erfolgte.
Beschreibung

Dieses berechnete Boolesche Attribut ist wahr, wenn der Timestamp der Activity 'Wareneingang' später ist als der Wert im Attribut 'Angeforderter Liefertermin' für eine bestimmte Bestellung.

Dieses Flag ist die Grundlage für den KPI 'Pünktliche Lieferrate'. Es ermöglicht eine einfache Segmentierung und Analyse von verspäteten gegenüber pünktlichen Bestellungen und hilft, die Grundursachen von Verzögerungen zu untersuchen, unabhängig davon, ob sie mit spezifischen Lieferanten, Standorten oder Produktkategorien zusammenhängen.

Warum es wichtig ist

Unterstützt direkt den KPI 'On-Time Delivery Rate' und ermöglicht eine klare Analyse der Lieferantenleistung und Lieferzuverlässigkeit.

Woher erhalten

Berechnetes Feld. Auf 'true' gesetzt, wenn der 'Wareneingang'-Aktivitätszeitstempel nach dem 'RequestedDeliveryDate'-Attribut liegt.

Beispiele
truefalsch
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp, wann die Daten zuletzt aus dem Quellsystem extrahiert oder aktualisiert wurden.
Beschreibung

Dieses Attribut zeigt die Aktualität der analysierten Daten an. Es erfasst Datum und Zeit des letzten Datenabrufs aus Oracle Fusion Financials.

Diese Information ist entscheidend, damit Benutzer die Aktualität der Analyse und der Dashboards verstehen. Sie verdeutlicht, wie aktuell die Process Insights sind, und steuert die Erwartungen hinsichtlich der Einbeziehung von sehr aktuellen Transaktionen.

Warum es wichtig ist

Schafft Transparenz über die Aktualität der Daten und stellt sicher, dass Nutzer verstehen, wie aktuell die Prozessanalyse ist.

Woher erhalten

Dies ist ein Timestamp, der während des Datenextraktions- und Transformationsprozesses (ETL) generiert und hinzugefügt wird.

Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Lieferort
DeliveryLocation
Der physische Ort oder die Adresse, an die die Waren geliefert werden sollen.
Beschreibung

Dieses Attribut gibt die Lieferadresse für die Artikel der Bestellung an. Es ist eine wichtige logistische Information.

Für Process Mining unterstützt die Analyse nach Lieferort das Dashboard 'Effizienz der Wareneingangsbearbeitung'. Es hilft zu identifizieren, ob bestimmte Lager oder Standorte in ihrem Wareneingangsprozess langsamer sind, was auf potenzielle Ressourcen- oder Prozessprobleme an spezifischen Standorten hinweist.

Warum es wichtig ist

Ermöglicht eine Leistungsanalyse nach geografischem Standort und hilft dabei, regionale oder standortspezifische Engpässe im Wareneingangsprozess zu identifizieren.

Woher erhalten

Verknüpft von PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID mit der HR_LOCATIONS_ALL View.

Beispiele
Hauptlager - Dock ABuilding 3 - ReceptionSF Büro - 10. Stock
Quellsystem
SourceSystem
Das Informationssystem, aus dem diese Daten extrahiert wurden.
Beschreibung

Dieses Attribut identifiziert den Ursprung der Daten, was besonders nützlich in Umgebungen mit mehreren integrierten Systemen ist. Für diesen Prozess wäre es typischerweise 'Oracle Fusion Financials'.

Obwohl es oft ein statischer Wert für einen gegebenen Datensatz ist, ist es entscheidend für die Data Governance, Fehlerbehebung und die Sicherstellung der Datenherkunft. Bei Analysen, die Daten aus mehreren Quellen kombinieren, ermöglicht es die Filterung und Segmentierung nach dem Herkunftssystem.

Warum es wichtig ist

Identifiziert den Ursprung der Daten, was entscheidend für Data Governance, den Kontext und die Integration mit anderen Systemen ist.

Woher erhalten

Dies ist typischerweise ein konstanter Wert, der während des Datenextraktions- und Transformationsprozesses (ETL) definiert und hinzugefügt wird.

Beispiele
Oracle Fusion FinancialsOracle Cloud SCMOracle Fusion P2P
Erforderlich Empfohlen Optional

Purchase to Pay - Bestellaktivitäten

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um eine genaue Process Discovery für den Beschaffungsprozess – Bestellvorgang zu ermöglichen.
6 Empfohlen 10 Optional
Aktivität Beschreibung
Bestellung an Lieferanten gesendet
Die genehmigte Purchase Order (Bestellung) wird offiziell an den Lieferanten kommuniziert, zum Beispiel per E-Mail oder EDI. Dieses Event wird oft aus einer Statusänderung oder einem Timestamp im PO-Kommunikationsdatensatz abgeleitet.
Warum es wichtig ist

Dies markiert den Beginn der Lieferantendurchlaufzeit. Es ist ein entscheidender Punkt zur Messung der Lieferantenleistung, von der Bestätigung bis zur endgültigen Lieferung.

Woher erhalten

Dies lässt sich ableiten, wenn der Bestellstatus auf 'Offen' wechselt und ein Kommunikationsdatum hinterlegt wird. Das spezifische Feld ist oft PO_HEADERS_ALL.communicated_date oder ein verwandter Status.

Erfassen

Ableitung vom Timestamp, wenn der Kommunikationsstatus der Bestellung auf 'Communicated' aktualisiert wird.

Ereignistyp inferred
Bestellung endgültig abgeschlossen
Die Bestellung gilt als abgeschlossen, d.h., sie wurde vollständig empfangen und/oder in Rechnung gestellt, und es wird keine weitere Aktivität erwartet. Dies ist eine explizite Aktion, die einen finalen Status für die Bestellung setzt.
Warum es wichtig ist

Diese Aktivität markiert den erfolgreichen Abschluss des Bestell-Lebenszyklus. Sie ist der primäre positive Endzustand, und ihre Verfolgung ist entscheidend für die Messung des gesamten Prozessdurchsatzes und der Abschlussraten.

Woher erhalten

Dieses Event wird in der Tabelle PO_ACTION_HISTORY mit einem ACTION_CODE von 'FINALLY CLOSE' erfasst. Der Bestellstatus in PO_HEADERS_ALL wird ebenfalls auf 'Finally Closed' aktualisiert.

Erfassen

Filtern Sie PO_ACTION_HISTORY nach ACTION_CODE = 'FINALLY CLOSE'.

Ereignistyp explicit
Bestellung erstellt
Dies ist der offizielle Start des Bestell-Lebenszyklus, bei dem ein PO-Dokument im Entwurfs- oder unvollständigen Status generiert wird. Das System erfasst dieses Event durch die Aufzeichnung des Erstellungs-Timestamps des neuen PO-Kopfsatzes.
Warum es wichtig ist

Als primäres Start-Ereignis für den Bestell-Fall ist diese Aktivität grundlegend für alle Durchlaufzeitberechnungen. Sie bildet die Grundlage zur Messung der Effizienz nachfolgender Schritte wie Genehmigung und Lieferantenkommunikation.

Woher erhalten

Dies ist ein explizites Event, das auf dem Feld CREATION_DATE in der Tabelle PO_HEADERS_ALL für eine bestimmte Bestell-ID (PO_HEADER_ID) basiert.

Erfassen

Verwenden Sie den Erstellungs-Timestamp aus der Tabelle PO_HEADERS_ALL.

Ereignistyp explicit
Bestellung genehmigt
Die Bestellung hat alle notwendigen Genehmigungen erhalten und ist nun für den Versand an den Lieferanten autorisiert. Dies ist ein wichtiges Meilenstein-Event, das explizit in der Aktionshistorie des Dokuments protokolliert wird.
Warum es wichtig ist

Dies ist ein kritischer Meilenstein, der den Versand der Bestellung an den Lieferanten steuert. Er ist unerlässlich für die Messung der Genehmigungszykluszeiten und die Sicherstellung der Einhaltung von Ausgabenrichtlinien.

Woher erhalten

Dieses Event wird in der Tabelle PO_ACTION_HISTORY erfasst, typischerweise mit einem ACTION_CODE von 'APPROVE' oder wenn sich der Dokumentstatus in PO_HEADERS_ALL in einen genehmigten Status ändert.

Erfassen

Filtern Sie PO_ACTION_HISTORY nach der finalen Aktion 'APPROVE'.

Ereignistyp explicit
Bestellung storniert
Die Bestellung wurde dauerhaft storniert, und es werden keine weiteren Transaktionen erwartet. Dies ist eine explizite Aktion, die den finalen Status des Dokuments ändert.
Warum es wichtig ist

Diese Aktivität stellt einen negativen Endzustand für den Prozess dar. Die Analyse von Stornierungen kann Probleme wie doppelte Bestellungen, Budgetänderungen oder Änderungen in den Projektanforderungen aufdecken.

Woher erhalten

Diese Aktion wird in der Tabelle PO_ACTION_HISTORY mit einem ACTION_CODE von 'CANCEL' erfasst, und der PO-Status in PO_HEADERS_ALL wird entsprechend aktualisiert.

Erfassen

Filtern Sie PO_ACTION_HISTORY nach ACTION_CODE = 'CANCEL'.

Ereignistyp explicit
Ware erhalten
Die physischen Waren wurden empfangen, gezählt und der Bestellung zugeordnet. Dies ist ein transaktionales Event, das den Lagerbestand und den Bestellstatus aktualisiert.
Warum es wichtig ist

Dies ist ein wichtiger Meilenstein zur Messung der pünktlichen Lieferleistung des Lieferanten und der gesamten Durchlaufzeit. Er dient auch als Auslöser für nachfolgende Aktivitäten wie Qualitätsprüfung und Rechnungsabgleich.

Woher erhalten

Dies ist ein explizites Event, das in der Tabelle RCV_TRANSACTIONS erfasst wird. Die spezifische Transaktion kann durch einen TRANSACTION_TYPE von 'RECEIVE' identifiziert werden.

Erfassen

Verwenden Sie das TRANSACTION_DATE aus RCV_TRANSACTIONS, wo der TRANSACTION_TYPE 'RECEIVE' ist.

Ereignistyp explicit
Bestellanforderung erstellt
Diese Aktivität markiert die Erstellung einer Bestellanforderung, welche die formelle Anforderung von Waren oder Dienstleistungen ist, die einer Bestellung vorausgeht. Sie wird erfasst, wenn ein neuer Eintrag in der Bestellanforderungs-Kopftabelle innerhalb von Oracle Fusion erstellt wird.
Warum es wichtig ist

Die Analyse dieser Aktivität hilft, die Bedarfsentstehungsphase zu verstehen. Die Verfolgung der Zeit von der Anforderung bis zur Bestellerstellung zeigt potenzielle Verzögerungen bei der Umwandlung interner Nachfrage in umsetzbare Beschaffungsaufträge auf.

Woher erhalten

Dies ist ein explizites Event, das beim Speichern einer neuen Anforderung erfasst wird. Es kann anhand des Erstellungs-Timestamps in der Tabelle POR_REQUISITION_HEADERS_ALL gefunden werden.

Erfassen

Das Event basiert auf dem Erstellungsdatum des Datensatzes in der Tabelle POR_REQUISITION_HEADERS_ALL.

Ereignistyp explicit
Bestellanforderung genehmigt
Die Bestellanforderung wurde von der zuständigen Autorität genehmigt, wodurch die Beschaffungsabteilung zur Erstellung einer Bestellung autorisiert wird. Dieses Event wird explizit in der Aktionshistorie des Systems für die Anforderung protokolliert.
Warum es wichtig ist

Dieser Meilenstein kennzeichnet das Ende des internen Genehmigungsprozesses für die Anforderung. Verzögerungen hier können den gesamten Beschaffungszeitplan direkt beeinflussen, daher ist die Überwachung seiner Dauer entscheidend.

Woher erhalten

Dieses Event wird in der Aktionshistorie der Anforderung erfasst, typischerweise über Workflow-Tabellen oder spezifische Genehmigungsstatusfelder auf dem Anforderungsdokument verfolgt.

Erfassen

Als Genehmigungsaktion im Workflow-Verlauf für das spezifische Anforderungsdokument protokolliert.

Ereignistyp explicit
Bestellung abgelehnt
Ein Genehmiger hat die Bestellung abgelehnt und sie zur Überarbeitung an den Ersteller zurückgesandt. Dies ist ein explizites Ereignis, das in der Aktionshistorie protokolliert wird und eine Unterbrechung des standardisierten Prozessflusses anzeigt.
Warum es wichtig ist

Ablehnungen führen zu Nacharbeiten und Verzögerungen im Prozess. Die Verfolgung dieser Aktivität hilft, häufige Ablehnungsgründe, Schulungsbedarfe oder unklare Genehmigungsanforderungen zu identifizieren.

Woher erhalten

Diese Aktion wird in der Tabelle PO_ACTION_HISTORY mit einem ACTION_CODE von 'REJECT' für die entsprechende PO_HEADER_ID erfasst.

Erfassen

Filtern Sie PO_ACTION_HISTORY nach ACTION_CODE = 'REJECT'.

Ereignistyp explicit
Bestellung bestätigt
Der Lieferant hat den Erhalt und die Annahme der Bestellbedingungen bestätigt. Dieses Event wird oft manuell vom Einkaufspersonal basierend auf der Lieferantenkommunikation oder durch eine elektronische Bestätigung erfasst.
Warum es wichtig ist

Die Lieferantenbestätigung gibt Gewissheit, dass die Bestellung eingegangen ist und bearbeitet wird. Dies zu verfolgen, hilft bei der Steuerung der Kommunikation mit Lieferanten und der proaktiven Identifizierung potenzieller Lieferprobleme.

Woher erhalten

Dies wird typischerweise aus einer Änderung der Bestätigungsstatusfelder im PO-Kopf oder in den Positionen abgeleitet, z. B. wenn PO_HEADERS_ALL.acceptance_status zu 'Accepted' wechselt.

Erfassen

Ableitung aus Aktualisierungen der Bestätigungsstatusfelder von Bestellungen.

Ereignistyp inferred
Bestellung eingereicht
Die erstellte Purchase Order wird in den Approval Workflow übermittelt. Oracle Fusion protokolliert diese Aktion explizit und erfasst den Benutzer sowie den Timestamp für das Einreichungs-Event.
Warum es wichtig ist

Diese Aktivität markiert den Beginn des Genehmigungszyklus. Die Analyse der Zeit zwischen Einreichung und Genehmigung ist entscheidend, um Bottlenecks im internen Freigabeprozess zu identifizieren.

Woher erhalten

Diese Aktion wird in der Tabelle PO_ACTION_HISTORY mit einem ACTION_CODE von 'SUBMIT' für die entsprechende PO_HEADER_ID erfasst.

Erfassen

Filtern Sie PO_ACTION_HISTORY nach ACTION_CODE = 'SUBMIT'.

Ereignistyp explicit
Bestellung geändert
Eine Änderung wurde an der Bestellung nach ihrer ersten Genehmigung vorgenommen, wie zum Beispiel eine Änderung der Menge, des Preises oder des Lieferdatums. Oracle Fusion erfasst dies durch das Anlegen einer neuen Revision des Dokuments.
Warum es wichtig ist

Bestellungsänderungen bedeuten Nacharbeit und können auf Probleme mit der anfänglichen Bestellgenauigkeit oder sich ändernde Geschäftsanforderungen hindeuten. Die Analyse der Häufigkeit und Art dieser Änderungen hilft, Möglichkeiten zur Verbesserung der Prozesseffizienz zu identifizieren.

Woher erhalten

Dieses Event wird explizit erfasst, wenn eine neue Dokumentrevision erstellt wird. Dies lässt sich durch eine Inkrementierung im Feld REVISION_NUM in der Tabelle PO_HEADERS_ALL identifizieren.

Erfassen

Identifizieren Sie jede Instanz, bei der die REVISION_NUM für eine PO_HEADER_ID ansteigt.

Ereignistyp explicit
Erbuchte Dienstleistungen bestätigt
Bei dienstleistungsbasierten Bestellungen kennzeichnet diese Aktivität die Bestätigung, dass Dienstleistungen wie vereinbart erbracht wurden. Diese Bestätigung wird oft manuell oder über einen Leistungserfassungsbogen festgehalten.
Warum es wichtig ist

Dies ist das Äquivalent eines Wareneingangs für Dienstleistungen und ein entscheidender Schritt, bevor eine Rechnung bezahlt werden kann. Verzögerungen bei der Servicebestätigung können zu verspäteten Zahlungen und angespannten Lieferantenbeziehungen führen.

Woher erhalten

Dies wird typischerweise als Wareneingang gegen eine Serviceposition auf der Bestellung erfasst. Es kann spezifische Felder oder komplexe Wareneingänge beinhalten, die den Fortschritt oder die Fertigstellung von Dienstleistungen verfolgen.

Erfassen

Identifizieren Sie Wareneingangstransaktionen (RCV_TRANSACTIONS), die mit dienstleistungsbasierten Bestellpositionen verknüpft sind.

Ereignistyp explicit
Qualitätsinspektion durchgeführt
Waren, die einer Qualitätskontrolle bedürfen, wurden geprüft und entweder angenommen oder abgelehnt. Diese Aktivität erfolgt nach dem ersten Wareneingang und wird als separate Transaktion erfasst.
Warum es wichtig ist

Diese Aktivität ist entscheidend für das Qualitätsmanagement. Die Analyse der Dauer von Inspektionen hilft, den Qualitätskontrollprozess zu optimieren und Verzögerungen bei der Bereitstellung von Waren zu reduzieren.

Woher erhalten

Dies wird in der Tabelle RCV_TRANSACTIONS erfasst. Es wird durch Transaktionen mit einem TRANSACTION_TYPE von 'ACCEPT' oder 'REJECT' identifiziert, die auf eine Wareneingangstransaktion folgen.

Erfassen

Verwenden Sie das TRANSACTION_DATE aus RCV_TRANSACTIONS, wo der TRANSACTION_TYPE 'ACCEPT' oder 'REJECT' ist.

Ereignistyp explicit
Ware an Lieferant zurückgesendet
Zuvor erhaltene Waren werden an den Lieferanten zurückgesendet, typischerweise aufgrund von Mängeln, Beschädigungen oder Fehllieferungen. Dies wird als spezifische Retourentransaktion im Wareneingangsmodul erfasst.
Warum es wichtig ist

Die Verfolgung von Rücksendungen ist wesentlich zur Bewertung der Lieferantenqualität und Auftragsgenauigkeit. Hohe Rücksendequoten für einen Lieferanten können auf systemische Probleme hinweisen, die angegangen werden müssen.

Woher erhalten

Dies ist ein explizites Event, das in der Tabelle RCV_TRANSACTIONS mit einem TRANSACTION_TYPE von 'RETURN TO VENDOR' erfasst wird.

Erfassen

Verwenden Sie das TRANSACTION_DATE aus RCV_TRANSACTIONS, wo der TRANSACTION_TYPE 'RETURN TO VENDOR' ist.

Ereignistyp explicit
Wareneingang erstellt
Ein Wareneingangsdokument wird im System initiiert, um die physische Ankunft von Waren vorzubereiten. Diese Aktivität kennzeichnet den Beginn des internen Wareneingangsprozesses.
Warum es wichtig ist

Dies markiert den Übergang von der Beschaffung zur Logistik. Die Analyse der Zeit von diesem Punkt bis zur finalen Wareneingangsbuchung hilft, Ineffizienzen im Lager oder in der Wareneingangsabteilung zu identifizieren.

Woher erhalten

Dies ist ein explizites Event, das durch den Erstellungs-Timestamp eines neuen Datensatzes in der Tabelle RCV_SHIPMENT_HEADERS erfasst wird, der mit der Bestellung verknüpft ist.

Erfassen

Verwenden Sie das Erstellungsdatum des entsprechenden Datensatzes in RCV_SHIPMENT_HEADERS.

Ereignistyp explicit
Empfohlen Optional

Extraktionsleitfäden

So erhalten Sie Ihre Daten aus Oracle Fusion Financials