Daten-Template: Procure-to-Pay - Bestellung
Ihr Procure-to-Pay-Bestelldaten-Template
- 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
Purchase to Pay - Bestellattribute
| 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
|
|||
Purchase to Pay - Bestellaktivitäten
| 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
|
|||