Ihr Daten-Template für den Bestellprozess
Ihr Daten-Template für den Bestellprozess
- Empfohlene Attribute für eine umfassende Datenerfassung
- Wichtige Prozessaktivitäten zur Erfassung und Analyse
- Schritt-für-Schritt-Anleitung zur Datenextraktion aus Oracle Fusion Financials
Attribute des Bestellprozesses
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
ActivityName
|
Die Bezeichnung eines bestimmten Geschäftsereignisses oder Prozessschritts im Bestellprozess. | ||
|
Beschreibung
Dieses Attribut bezeichnet eine bestimmte Aufgabe oder Statusänderung im Prozess, zum Beispiel 'Bestellung angelegt' oder 'Waren eingegangen'. Die Aktivitäten bilden die Ereignisfolge des Prozessablaufs. Die Abfolge und Zeitpunkte dieser Aktivitäten zu analysieren, ist die Grundlage des Process Mining. So lässt sich der Prozessablauf visualisieren, Engpässe lassen sich erkennen, Abweichungen von der Standardvorgehensweise aufdecken und die Dauer einzelner Schritte messen.
Warum das wichtig ist
Aktivitäten sind die Bausteine des Prozessablaufs. Werden sie nachverfolgt, lässt sich der Ablauf visualisieren und auf Engpässe sowie Abweichungen untersuchen.
Woher beziehen
Abgeleitet aus Statusänderungen in Tabellen wie PO_HEADERS_ALL und PO_ACTION_HISTORY oder aus bestimmten Transaktionstabellen wie RCV_TRANSACTIONS für Wareneingänge.
Beispiele
Bestellung erstelltBestellung genehmigtWaren eingegangen
|
|||
|
Bestellung
PurchaseOrder
|
Die eindeutige Kennung des Bestelldokuments. Sie dient als primäre Case-ID zur Nachverfolgung des Beschaffungsprozesses. | ||
|
Beschreibung
Die Bestellnummer ist die zentrale Kennung, über die alle zugehörigen Aktivitäten von der Erstellung bis zum endgültigen Abschluss verknüpft werden. Sie ermöglicht die durchgängige Analyse eines einzelnen Beschaffungsfalls. Im Process Mining steht jede eindeutige Bestellnummer für eine einzelne Prozessinstanz. Werden Daten nach dieser Kennung gruppiert, lassen sich Prozessvarianten, Zykluszeiten und die Compliance einzelner Bestellungen untersuchen.
Warum das wichtig ist
Diese wichtige Case-ID verknüpft alle zugehörigen Ereignisse und ermöglicht so, den gesamten Bestellprozess zu rekonstruieren und zu analysieren.
Woher beziehen
Oracle Fusion Cloud SCM, Beschaffungsmodul, Tabelle PO_HEADERS_ALL, Spalte SEGMENT1.
Beispiele
100234510023461002347
|
|||
|
Startzeit
EventTime
|
Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat. | ||
|
Beschreibung
Dieses Attribut erfasst Datum und Uhrzeit jeder Aktivität im Prozess. Es ist die Grundlage für die chronologische Sortierung von Ereignissen und alle zeitbasierten Analysen. Im Process Mining dient die Startzeit dazu, das Event Log zu erstellen, Zykluszeiten zwischen Aktivitäten zu berechnen, Wartezeiten zu messen und die Prozessleistung über verschiedene Zeiträume hinweg zu analysieren. Sie ist für Dashboards zu Zykluszeiten und Leistung unverzichtbar.
Warum das wichtig ist
Dieser Timestamp ist entscheidend, um Ereignisse korrekt zu ordnen und alle zeitbasierten Kennzahlen wie Zykluszeiten und Engpässe zu berechnen.
Woher beziehen
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
|
Die Bezeichnung der Abteilung, die die Bestellung veranlasst hat oder für sie verantwortlich ist. | ||
|
Beschreibung
Dieses Attribut bezeichnet die Organisationseinheit, zum Beispiel 'Finanzen', 'IT' oder 'Fertigung', die mit dem Einkauf verbunden ist. Es dient der Kostenverteilung und dem Organisationsreporting. Im Process Mining ist eine Aufschlüsselung nach Abteilungen wichtig, um die Leistung zu vergleichen, abteilungsspezifische Engpässe zu erkennen und Unterschiede bei der Prozessausführung innerhalb der Organisation zu verstehen. Sie unterstützt direkt Dashboards wie 'Analyse der Genehmigungszykluszeit von Bestellungen' und 'Trends bei Bestelländerungen'.
Warum das wichtig ist
Ermöglicht, die Prozessleistung verschiedener Geschäftseinheiten zu filtern und zu vergleichen. So werden abteilungsspezifische Probleme und bewährte Vorgehensweisen sichtbar.
Woher beziehen
Abgeleitet aus Kostenstelleninformationen in Tabellen wie PO_DISTRIBUTIONS_ALL, die mit den Stammdaten der Abteilungen verknüpft sind.
Beispiele
IT-BetriebMarketingForschung und Entwicklung
|
|||
|
Angeforderter Liefertermin
RequestedDeliveryDate
|
Der Termin, zu dem die anfordernde Stelle die Lieferung der Waren oder Dienstleistungen erwartet. | ||
|
Beschreibung
Dieser Termin wird auf der Bestellposition angegeben und teilt dem Lieferanten mit, wann die Lieferung erwartet wird. Er dient als Grundlage für die Messung der termingerechten Lieferleistung. Dieses Attribut ist wichtig für die Berechnung der KPI 'Quote termingerechter Lieferungen'. Durch den Vergleich des tatsächlichen Wareneingangsdatums mit dem angeforderten Liefertermin können Unternehmen die Zuverlässigkeit von Lieferanten messen und verfolgen sowie systematische Verzögerungen in der Lieferkette erkennen.
Warum das wichtig ist
Dient als Grundlage für die Messung der termingerechten Lieferleistung. Diese wichtige KPI zeigt, wie zuverlässig Lieferanten sind und wie effizient die Lieferkette arbeitet.
Woher beziehen
Auf Ebene der Positionslieferung in der Tabelle PO_LINE_LOCATIONS_ALL, Spalte NEED_BY_DATE.
Beispiele
2023-05-202023-06-152023-07-01
|
|||
|
Benutzer
UserName
|
Die Benutzer-ID oder der Name der Person, die die Aktivität ausgeführt hat. | ||
|
Beschreibung
Dieses Attribut gibt an, welcher Mitarbeitende oder Systembenutzer für ein Ereignis verantwortlich war, zum Beispiel für das Anlegen einer Bestellanforderung, die Genehmigung einer Bestellung oder die Buchung eines Wareneingangs. Die Daten stammen üblicherweise aus Feldern wie 'Erstellt von' oder 'Zuletzt aktualisiert von'. Eine Analyse nach Benutzern zeigt, wie sich die Arbeitslast verteilt, wie die individuelle Leistung ausfällt und wo Schulungsbedarf besteht. Sie ist eine wichtige Grundlage für das Dashboard 'Arbeitslast der Genehmigenden' und für die Untersuchung von Compliance-Verstößen im Zusammenhang mit Benutzeraktionen.
Warum das wichtig ist
Ordnet Benutzeraktionen einzelnen Personen zu. So lassen sich Arbeitslast und Leistung analysieren und Schulungsbedarf erkennen.
Woher beziehen
Verknüpfen Sie die Daten anhand der IDs in Feldern wie CREATED_BY oder LAST_UPDATED_BY mit Benutzertabellen, zum Beispiel für PO_HEADERS_ALL und PO_ACTION_HISTORY.
Beispiele
john.doejane.smithsystem.batch
|
|||
|
Endzeit
EndTime
|
Der Timestamp, zu dem eine Aktivität abgeschlossen wurde. Bei atomaren Ereignissen entspricht er häufig der Startzeit. | ||
|
Beschreibung
Bei Aktivitäten mit einer Dauer gibt dieser Wert den Abschlusszeitpunkt an. Bei Ereignissen ohne Dauer entspricht er üblicherweise der Startzeit. Er ist wichtig, um die Verarbeitungszeit einzelner Aktivitäten zu berechnen. Eine separate Endzeit ermöglicht eine genauere Analyse der Aktivitätsdauer, die sich von der Wartezeit zwischen Aktivitäten unterscheiden kann. So lassen sich aktive Arbeitszeit und Leerlauf voneinander abgrenzen und die Ressourcenauslastung sowie Effizienz analysieren.
Warum das wichtig ist
Ermöglicht die genaue Berechnung der Verarbeitungszeiten einzelner Aktivitäten. Das ist wichtig, um die Ressourceneffizienz zu analysieren und zeitaufwendige Aufgaben zu erkennen.
Woher beziehen
Bei atomaren Ereignissen kann die Endzeit der Startzeit entsprechen oder aus den Timestamps nachfolgender Ereignisse abgeleitet werden. Für manche Aktivitäten gibt es einen eigenen Abschluss-Timestamp.
Beispiele
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
|
|||
|
Gesamtbetrag der Bestellung
PurchaseOrderTotalAmount
|
Der Gesamtwert der Bestellung. | ||
|
Beschreibung
Dieses Attribut gibt die Gesamtkosten aller Positionen der Bestellung in der angegebenen Währung an. Es ist eine wichtige finanzielle Kennzahl, um den Wert der durch den Prozess laufenden Transaktionen zu verstehen. Der Gesamtbetrag der Bestellung hilft dabei, Verbesserungsmaßnahmen zu priorisieren. Bestellungen mit hohem Wert können beispielsweise ein strengeres Genehmigungsverfahren durchlaufen. Außerdem ermöglicht er eine Analyse der finanziellen Auswirkungen, etwa des Werts häufig geänderter oder verspäteter Bestellungen.
Warum das wichtig ist
Liefert den finanziellen Kontext für den Prozess. So können Sie nach Geldwert analysieren, etwa Bestellungen mit hohem Wert priorisieren oder die finanziellen Folgen von Verzögerungen untersuchen.
Woher beziehen
Berechnet durch Addition der Beträge aus PO_LINES_ALL für einen Bestellkopf oder aus einem verfügbaren Gesamtbetrag auf Kopfebene.
Beispiele
5250.00120000.50750.99
|
|||
|
Lieferantenname
VendorName
|
Der Name des Lieferanten, bei dem Waren oder Dienstleistungen eingekauft werden. | ||
|
Beschreibung
Dieses Attribut bezeichnet den externen Lieferanten der Bestellung. Es handelt sich um wichtige Stammdaten, die mit dem Bestellkopf verknüpft sind. Die Lieferantenanalyse ist ein wichtiger Bestandteil des Process Mining für den Beschaffungsprozess. Durch Filtern oder Aufschlüsseln nach Lieferanten können Unternehmen die 'Lieferanten-Lieferleistung' analysieren, die Quoten termingerechter Lieferungen vergleichen und die 'Warenrücksendequote' untersuchen. So lassen sich leistungsstarke und leistungsschwache Lieferanten erkennen. Diese Daten sind wichtig für das Lieferantenmanagement und die strategische Beschaffung.
Warum das wichtig ist
Wichtig für die Analyse der Lieferantenleistung: Lieferzeiten, Rücksendequoten und Zuverlässigkeit lassen sich lieferantenübergreifend vergleichen.
Woher beziehen
Verknüpft über PO_HEADERS_ALL.VENDOR_ID mit POZ_SUPPLIERS.VENDOR_NAME.
Beispiele
Global Office SuppliesTech Solutions Inc.Advanced Logistics Co.
|
|||
|
Name des Genehmigenden
ApproverName
|
Der Name des Benutzers, der die Bestellung genehmigt oder abgelehnt hat. | ||
|
Beschreibung
Dieses Attribut gibt an, wer für einen Genehmigungsschritt im Workflow verantwortlich war. Die Information ist üblicherweise in einer Aktionshistorie oder einer Workflow-Protokolltabelle zur Bestellung gespeichert. Eine Analyse nach Genehmigenden ist wichtig für die Dashboards 'Analyse der Genehmigungszykluszeit von Bestellungen' und 'Arbeitslast der Genehmigenden'. Sie zeigt, bei welchen Genehmigenden oder Genehmigungsgruppen Engpässe entstehen, ermöglicht eine faire Bewertung der Arbeitslast und kann Möglichkeiten zur Delegation oder Neugestaltung des Prozesses aufzeigen.
Warum das wichtig ist
Zeigt, welche Personen an der Genehmigung beteiligt waren. So lassen sich Engpässe, Arbeitslast und Zykluszeiten nach Genehmigenden analysieren.
Woher beziehen
Der Benutzer, der die Aktion ausgeführt hat. Er ist in PO_ACTION_HISTORY.ACTION_PERFORMED_BY angegeben und kann über eine Benutzertabelle mit dem vollständigen Namen verknüpft werden.
Beispiele
susan.managerdavid.directoremily.finance
|
|||
|
Beschaffungskategorie
PurchaseCategory
|
Die Klassifizierung der eingekauften Waren oder Dienstleistungen, zum Beispiel 'IT-Hardware' oder 'Bürobedarf'. | ||
|
Beschreibung
Dieses Attribut ordnet die Positionen der Bestellung einer Beschaffungshierarchie zu. Die Klassifizierung dient der Ausgabenanalyse und dem Lieferantenmanagement. Im Process Mining kann eine Aufschlüsselung nach Beschaffungskategorie unterschiedliche Abläufe und Leistungsniveaus sichtbar machen. So kann die Genehmigung von Investitionsgütern länger dauern als die von Betriebsbedarf. Das Attribut unterstützt direkt das Dashboard 'Warenrücksendequote und Gründe', indem es zeigt, welche Kategorien besonders häufig zurückgesendet werden.
Warum das wichtig ist
Ermöglicht die Prozessanalyse nach Ausgabenart. So lassen sich unterschiedliche Prozessabläufe, Engpässe oder Rücksendequoten für verschiedene Warenkategorien erkennen.
Woher beziehen
Verknüpft über PO_LINES_ALL.CATEGORY_ID mit der Ansicht EGP_CATEGORIES_VL.
Beispiele
IT.Hardware.LaptopsBürobedarf.SchreibwarenProfessionelle.Dienstleistungen.Beratung
|
|||
|
Bestellanforderung
PurchaseRequisitionNumber
|
Die Kennung der Bestellanforderung, die der Bestellung vorausging und diese autorisierte. | ||
|
Beschreibung
Die Bestellanforderung ist das interne Dokument, mit dem Waren oder Dienstleistungen angefordert werden. Dieses Attribut verknüpft die Bestellung mit der ursprünglichen Anforderung. Die Bestellanforderungsnummer ermöglicht eine umfassendere Analyse des Beschaffungsprozesses, die bereits bei der ursprünglichen Anforderung beginnt und nicht erst bei der Bestellung. So lässt sich die Zykluszeit von der Anforderung bis zur Bestellung untersuchen und nachvollziehen, wie sich die Angaben in der Anforderung auf den weiteren Bestellprozess auswirken.
Warum das wichtig ist
Verknüpft die Bestellung mit der ursprünglichen Anforderung und ermöglicht eine durchgängige Sicht auf den Prozess von der Bestellanforderung bis zur Zahlung.
Woher beziehen
Verknüpft über die Tabelle PO_DISTRIBUTIONS_ALL, die REQ_DISTRIBUTION_ID enthält und auf POR_REQUISITION_LINES_ALL zurückverweist.
Beispiele
BA-2023-05-001BA-2023-05-002BA-2023-05-003
|
|||
|
Bestellart
PurchaseOrderType
|
Die Art der Bestellung, zum Beispiel 'Standard', 'Rahmenbestellung' oder 'Vertrag'. | ||
|
Beschreibung
Dieses Attribut klassifiziert die Bestellung nach ihrem Beschaffungszweck. Für unterschiedliche Bestellarten gelten häufig unterschiedliche Prozessregeln und Abläufe. Eine Standardbestellung betrifft einen einmaligen Einkauf, während eine Rahmenbestellung eine längerfristige Vereinbarung mit einem Lieferanten ist. Eine Analyse nach Bestellart ermöglicht eine aussagekräftigere Bewertung der Prozessleistung. Ein Vergleich der Zykluszeit einer Standardbestellung mit der einer Rahmenvereinbarung wäre irreführend. Stattdessen lassen sich gleichartige Bestellungen miteinander vergleichen.
Warum das wichtig ist
Unterscheidet verschiedene Beschaffungsszenarien und ermöglicht aussagekräftige Leistungsvergleiche zwischen Bestellungen derselben Art.
Woher beziehen
Oracle Fusion Cloud SCM, Tabelle PO_HEADERS_ALL, Spalte TYPE_LOOKUP_CODE.
Beispiele
STANDARDRAHMENBESTELLUNGVERTRAG
|
|||
|
Bestellstatus
PurchaseOrderStatus
|
Der aktuelle Status des Bestelldokuments. | ||
|
Beschreibung
Dieses Attribut gibt den aktuellen Stand der Bestellung in ihrem Lebenszyklus an, zum Beispiel 'Offen', 'Genehmigt', 'Endgültig abgeschlossen' oder 'Storniert'. Es zeigt den aktuellen Fortschritt der Bestellung. Im Process Mining steht die Abfolge der Aktivitäten im Mittelpunkt. Der aktuelle Status ist dennoch hilfreich, um Fälle zu filtern. So können Sie beispielsweise nur offene Bestellungen untersuchen, um den aktuellen Auftragsbestand zu verstehen, oder abgeschlossene Bestellungen analysieren. Das Attribut ist wichtig für das Dashboard 'Bestellablauf und -status'.
Warum das wichtig ist
Zeigt den aktuellen Stand einer Bestellung. So lässt sich die Analyse auf aktive, abgeschlossene oder stornierte Bestellungen beschränken.
Woher beziehen
Oracle Fusion Cloud SCM, Tabelle PO_HEADERS_ALL, Spalten AUTHORIZATION_STATUS oder DOCUMENT_STATUS.
Beispiele
OFFENGENEHMIGTENDGÜLTIG_ABGESCHLOSSENSTORNIERT
|
|||
|
Geschäftseinheit
BusinessUnitName
|
Die Geschäftseinheit innerhalb der Organisation, die den Einkauf tätigt. | ||
|
Beschreibung
Die Geschäftseinheit ist eine eigenständige Unternehmenseinheit, häufig mit eigenem Hauptbuch und eigener Finanzberichterstattung. In Oracle Fusion dient sie als zentrale Grundlage für die Datentrennung. In großen multinationalen Unternehmen ist es wichtig, die Prozessleistung nach Geschäftseinheit zu analysieren. So lassen sich Beschaffungseffizienz, Compliance und Kosten in verschiedenen Unternehmensteilen vergleichen und bewährte Vorgehensweisen sowie Verbesserungsmöglichkeiten erkennen.
Warum das wichtig ist
Wichtig für große Organisationen, um Prozesseffizienz und Compliance in verschiedenen Geschäftsbereichen zu vergleichen.
Woher beziehen
Die Geschäftseinheit ist üblicherweise im Bestellkopf unter PO_HEADERS_ALL.PRC_BU_ID angegeben. Dieses Feld verweist auf die Ansicht FUN_ALL_BUSINESS_UNITS_V.
Beispiele
US-GeschäftseinheitEMEA VisionAPAC Services
|
|||
|
Ist genehmigungskonform
IsApprovalCompliant
|
Kennzeichnet, ob die Bestellung vor dem Versand an den Lieferanten genehmigt wurde. | ||
|
Beschreibung
Dieses berechnete boolesche Attribut prüft die Einhaltung einer wichtigen internen Kontrolle: Eine Bestellung muss genehmigt werden, bevor sie an einen Lieferanten versendet wird. Das Attribut ist „true“, wenn die Aktivität „Bestellung genehmigt“ vor der Aktivität „Bestellung an Lieferanten gesendet“ erfolgt. Dieses Attribut ist entscheidend für das Dashboard „Compliance-Prüfung des Bestellprozesses“ und die KPI „Einhaltungsquote bei Bestellgenehmigungen“. Es bietet eine einfache Möglichkeit, Verstöße zu erkennen und zu quantifizieren. So können Sie Beschaffungsrichtlinien durchsetzen und Risiken durch nicht autorisierte Ausgaben mindern.
Warum das wichtig ist
Misst direkt die KPI „Einhaltungsquote bei Bestellgenehmigungen“ und macht kritische Verstöße gegen interne Kontrollen sichtbar, bei denen Bestellungen vor der Genehmigung an Lieferanten gesendet werden.
Woher beziehen
Berechnetes Feld. Wird auf „true“ gesetzt, wenn der Timestamp von „Bestellung genehmigt“ kleiner oder gleich dem Timestamp von „Bestellung an Lieferanten gesendet“ ist.
Beispiele
truefalse
|
|||
|
Ist Nacharbeit
IsRework
|
Kennzeichnet, ob die Bestellung nach ihrer erstmaligen Erstellung geändert wurde. | ||
|
Beschreibung
Dieses berechnete boolesche Attribut wird auf „true“ gesetzt, wenn ein Bestellvorgang die Aktivität „Bestellung geändert“ enthält. So lassen sich Bestellungen, die korrigiert oder geändert werden mussten, schnell erkennen. Das Kennzeichen vereinfacht die Berechnung der KPI „Änderungsquote bei Bestellungen“ und ermöglicht es, überarbeitete Bestellungen gezielt zu filtern und auszuwerten. Merkmale dieser Bestellungen, etwa die beteiligten Lieferanten oder Abteilungen, können dabei helfen, die Ursachen für ungenaue Daten oder geänderte Anforderungen zu ermitteln.
Warum das wichtig ist
Unterstützt direkt die KPI „Änderungsquote bei Bestellungen“ und erleichtert die Analyse von Prozessinstabilität, indem alle geänderten Bestellungen gekennzeichnet werden.
Woher beziehen
Berechnetes Feld. Wird auf „true“ gesetzt, wenn das Event Log eines Vorgangs die Aktivität „Bestellung geändert“ enthält, andernfalls auf „false“.
Beispiele
truefalse
|
|||
|
Ist verspätete Lieferung
IsLateDelivery
|
Kennzeichnet, ob der endgültige Wareneingang nach dem angeforderten Lieferdatum erfolgte. | ||
|
Beschreibung
Dieses berechnete boolesche Attribut ist „true“, wenn der Timestamp der Aktivität „Wareneingang“ nach dem Wert des Attributs „Angefordertes Lieferdatum“ für eine Bestellung liegt. Dieses Kennzeichen bildet die Grundlage für die KPI „Pünktliche Lieferquote“. Damit lassen sich verspätete und pünktliche Bestellungen einfach segmentieren und analysieren. So können Sie die Ursachen für Verzögerungen untersuchen, etwa bestimmte Lieferanten, Standorte oder Produktkategorien.
Warum das wichtig ist
Unterstützt direkt die KPI „Pünktliche Lieferquote“ und ermöglicht eine klare Analyse der Lieferantenleistung und Lieferzuverlässigkeit.
Woher beziehen
Berechnetes Feld. Wird auf „true“ gesetzt, wenn der Timestamp der Aktivität „Wareneingang“ nach dem Attribut „RequestedDeliveryDate“ liegt.
Beispiele
truefalse
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, zu dem die Daten zuletzt aus dem Quellsystem extrahiert oder aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut gibt an, wie aktuell die analysierten Daten sind. Es erfasst Datum und Uhrzeit des letzten Datenabrufs aus Oracle Fusion Financials. Diese Information hilft Benutzern einzuschätzen, wie aktuell die Analyse und die Dashboards sind. Sie zeigt, bis zu welchem Zeitpunkt Prozessdaten berücksichtigt wurden, und macht deutlich, ob sehr aktuelle Transaktionen bereits enthalten sind.
Warum das wichtig ist
Macht transparent, wie aktuell die Daten sind, damit Benutzer den Aktualitätsstand der Prozessanalyse einschätzen können.
Woher beziehen
Dieser Timestamp wird während der Datenextraktion und -transformation (ETL) erzeugt und hinzugefügt.
Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Lieferort
DeliveryLocation
|
Der physische Standort oder die Adresse, an die die Waren geliefert werden sollen. | ||
|
Beschreibung
Dieses Attribut gibt die Lieferadresse für die Positionen der Bestellung an. Es enthält wichtige logistische Informationen. Im Process Mining unterstützt eine Analyse nach Lieferort das Dashboard 'Effizienz der Wareneingangsbearbeitung'. Sie zeigt, ob bestimmte Lager oder Standorte den Wareneingang langsamer bearbeiten und ob dort möglicherweise Ressourcen- oder Prozessprobleme bestehen.
Warum das wichtig ist
Ermöglicht den Leistungsvergleich nach geografischem Standort und hilft, regionale oder standortspezifische Engpässe beim Wareneingang zu erkennen.
Woher beziehen
Verknüpft über PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID mit der Ansicht HR_LOCATIONS_ALL.
Beispiele
Hauptlager - Rampe AGebäude 3 - EmpfangBüro San Francisco - 10. Etage
|
|||
|
Quellsystem
SourceSystem
|
Das Informationssystem, aus dem diese Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut gibt die Herkunft der Daten an. Das ist besonders in Umgebungen mit mehreren integrierten Systemen hilfreich. Für diesen Prozess wäre der Wert üblicherweise 'Oracle Fusion Financials'. Auch wenn der Wert für einen bestimmten Datensatz oft gleich bleibt, ist er für Data Governance, die Fehlerbehebung und die Nachverfolgung der Datenherkunft wichtig. Bei Analysen aus mehreren Quellen ermöglicht er, Daten nach dem Ursprungssystem zu filtern und aufzuschlüsseln.
Warum das wichtig ist
Gibt die Herkunft der Daten an. Das ist wichtig für Data Governance, den Kontext und die Integration mit anderen Systemen.
Woher beziehen
In der Regel handelt es sich um einen konstanten Wert, der während der Datenextraktion und -transformation (ETL) festgelegt und hinzugefügt wird.
Beispiele
Oracle Fusion FinancialsOracle Cloud SCMOracle Fusion P2P
|
|||
Aktivitäten des Bestellprozesses
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Bestellung an Lieferanten gesendet
|
Die genehmigte Bestellung wird dem Lieferanten offiziell übermittelt, zum Beispiel per E-Mail oder EDI. Dieses Ereignis wird häufig anhand einer Statusänderung oder eines Timestamps im Datensatz zur Bestellkommunikation abgeleitet. | ||
|
Warum das wichtig ist
Damit beginnt die Lieferzeit des Lieferanten. Dieser Zeitpunkt ist entscheidend, um die Lieferantenleistung von der Bestätigung bis zur endgültigen Lieferung zu messen.
Woher beziehen
Das Ereignis lässt sich häufig daran erkennen, dass sich der Status des Bestelldokuments in „Offen“ ändert und ein Kommunikationsdatum eingetragen wird. Das entsprechende Feld ist oft PO_HEADERS_ALL.communicated_date oder ein zugehöriger Status.
Erfassung
Leiten Sie das Ereignis aus dem Timestamp ab, zu dem der Kommunikationsstatus der Bestellung auf 'Communicated' gesetzt wird.
Ereignistyp
inferred
|
|||
|
Bestellung endgültig abgeschlossen
|
Die Bestellung gilt als abgeschlossen, wenn alle Waren eingegangen und/oder alle Rechnungen gestellt wurden und keine weiteren Aktivitäten zu erwarten sind. Diese ausdrückliche Aktion setzt den endgültigen Status der Bestellung. | ||
|
Warum das wichtig ist
Diese Aktivität markiert den erfolgreichen Abschluss des Bestellprozesses. Sie ist der wichtigste positive Endzustand. Ihre Erfassung ist entscheidend, um den Gesamtdurchsatz und die Abschlussquoten des Prozesses zu messen.
Woher beziehen
Dieses Ereignis wird in der Tabelle PO_ACTION_HISTORY mit dem ACTION_CODE 'FINALLY CLOSE' erfasst. Auch der Bestellstatus in PO_HEADERS_ALL wird auf 'Finally Closed' gesetzt.
Erfassung
Filtern Sie PO_ACTION_HISTORY nach ACTION_CODE = 'FINALLY CLOSE'.
Ereignistyp
explicit
|
|||
|
Bestellung erstellt
|
Damit beginnt offiziell der Lebenszyklus der Bestellung. Das Bestelldokument wird mit dem Status „Entwurf“ oder „Unvollständig“ erstellt. Das System erfasst dieses Ereignis anhand des Erstellungs-Timestamps des neuen Bestellkopfsatzes. | ||
|
Warum das wichtig ist
Als primäres Start-Event des Bestell-Case ist diese Aktivität die Grundlage für alle Berechnungen der Durchlaufzeit. Sie dient als Ausgangspunkt, um die Effizienz nachfolgender Schritte wie Genehmigung und Lieferantenkommunikation zu messen.
Woher beziehen
Dieses explizite Ereignis basiert für eine bestimmte Bestell-ID (PO_HEADER_ID) auf dem Feld CREATION_DATE in der Tabelle PO_HEADERS_ALL.
Erfassung
Verwenden Sie den Erstellungs-Timestamp aus der Tabelle PO_HEADERS_ALL.
Ereignistyp
explicit
|
|||
|
Bestellung genehmigt
|
Die Bestellung hat alle erforderlichen Genehmigungen erhalten und darf nun an den Lieferanten gesendet werden. Dieser wichtige Meilenstein wird ausdrücklich im Aktionsverlauf des Dokuments protokolliert. | ||
|
Warum das wichtig ist
Dieser kritische Meilenstein ist Voraussetzung dafür, dass die Bestellung an den Lieferanten gesendet werden darf. Er ist wichtig, um Genehmigungszeiten zu messen und die Einhaltung der Ausgabenrichtlinien sicherzustellen.
Woher beziehen
Dieses Ereignis wird in der Tabelle PO_ACTION_HISTORY in der Regel mit dem ACTION_CODE 'APPROVE' erfasst. Es kann auch anhand einer Statusänderung des Dokuments in PO_HEADERS_ALL in einen genehmigten Status erkannt werden.
Erfassung
Filtern Sie PO_ACTION_HISTORY nach der abschließenden Aktion 'APPROVE'.
Ereignistyp
explicit
|
|||
|
Bestellung storniert
|
Die Bestellung wurde endgültig storniert. Weitere Transaktionen sind nicht zu erwarten. Diese ausdrückliche Aktion ändert den endgültigen Status des Dokuments. | ||
|
Warum das wichtig ist
Diese Aktivität markiert einen negativen Endzustand des Prozesses. Eine Analyse der Stornierungen kann Probleme wie doppelte Bestellungen, Budgetänderungen oder geänderte Projektanforderungen aufdecken.
Woher beziehen
Diese Aktion wird in der Tabelle PO_ACTION_HISTORY mit dem ACTION_CODE 'CANCEL' erfasst. Der Bestellstatus in PO_HEADERS_ALL wird entsprechend aktualisiert.
Erfassung
Filtern Sie PO_ACTION_HISTORY nach ACTION_CODE = 'CANCEL'.
Ereignistyp
explicit
|
|||
|
Waren eingegangen
|
Die Waren sind physisch eingegangen, gezählt und der Bestellung zugeordnet. Dieses Transaktionsereignis aktualisiert den Bestand und den Bestellstatus. | ||
|
Warum das wichtig ist
Dieser Meilenstein ist wichtig, um die termingerechte Lieferleistung des Lieferanten und die gesamte Durchlaufzeit zu messen. Außerdem löst er nachfolgende Aktivitäten wie die Qualitätsprüfung und den Rechnungsabgleich aus.
Woher beziehen
Dieses Ereignis wird ausdrücklich in der Tabelle RCV_TRANSACTIONS erfasst. Die betreffende Transaktion ist am TRANSACTION_TYPE 'RECEIVE' zu erkennen.
Erfassung
Verwenden Sie TRANSACTION_DATE aus RCV_TRANSACTIONS, wenn TRANSACTION_TYPE den Wert 'RECEIVE' hat.
Ereignistyp
explicit
|
|||
|
Bestellanforderung erstellt
|
Diese Aktivität kennzeichnet die Erstellung einer Bestellanforderung, also der formellen Anforderung von Waren oder Dienstleistungen, die einer Bestellung vorausgeht. Sie wird erfasst, wenn in Oracle Fusion ein neuer Eintrag in der Anforderungskopftabelle erstellt wird. | ||
|
Warum das wichtig ist
Die Analyse dieser Aktivität zeigt, wie der Bedarf entsteht. Die Zeit zwischen der Bestellanforderung und der Erstellung der Bestellung macht mögliche Verzögerungen bei der Umwandlung des internen Bedarfs in konkrete Beschaffungsaufträge sichtbar.
Woher beziehen
Dieses explizite Ereignis wird beim Speichern einer neuen Bestellanforderung erfasst. Es lässt sich anhand des Erstellungs-Timestamps in der Tabelle POR_REQUISITION_HEADERS_ALL ermitteln.
Erfassung
Das Ereignis basiert auf dem Erstellungsdatum des Datensatzes in der Tabelle POR_REQUISITION_HEADERS_ALL.
Ereignistyp
explicit
|
|||
|
Bestellanforderung genehmigt
|
Die zuständige Stelle hat die Bestellanforderung genehmigt. Damit ist die Beschaffungsabteilung berechtigt, eine Bestellung zu erstellen. Dieses Ereignis wird ausdrücklich im Aktionsverlauf der Anforderung protokolliert. | ||
|
Warum das wichtig ist
Dieser Meilenstein markiert das Ende des internen Genehmigungsprozesses für die Anforderung. Verzögerungen an dieser Stelle können den gesamten Beschaffungszeitplan beeinträchtigen. Daher ist es wichtig, die Dauer zu überwachen.
Woher beziehen
Dieses Ereignis wird im Aktionsverlauf der Bestellanforderung erfasst. In der Regel wird es über Workflow-Tabellen oder bestimmte Genehmigungsstatusfelder im Anforderungsdokument nachverfolgt.
Erfassung
Als Genehmigungsaktion im Workflow-Verlauf des jeweiligen Anforderungsdokuments protokolliert.
Ereignistyp
explicit
|
|||
|
Bestellung abgelehnt
|
Eine genehmigende Person hat die Bestellung abgelehnt und zur Überarbeitung an die erstellende Person zurückgesendet. Dieses Ereignis wird ausdrücklich im Aktionsverlauf protokolliert und kennzeichnet eine Abweichung vom regulären Prozessablauf. | ||
|
Warum das wichtig ist
Ablehnungen verursachen Nacharbeit und Verzögerungen. Durch die Nachverfolgung dieser Aktivität lassen sich häufige Ablehnungsgründe, Schulungsbedarf oder unklare Genehmigungsanforderungen erkennen.
Woher beziehen
Diese Aktion wird für die entsprechende PO_HEADER_ID in der Tabelle PO_ACTION_HISTORY mit dem ACTION_CODE 'REJECT' erfasst.
Erfassung
Filtern Sie PO_ACTION_HISTORY nach ACTION_CODE = 'REJECT'.
Ereignistyp
explicit
|
|||
|
Bestellung bestätigt
|
Der Lieferant hat den Erhalt der Bestellung und die Annahme ihrer Bedingungen bestätigt. Dieses Ereignis wird häufig von Mitarbeitenden in der Beschaffung anhand der Lieferantenkommunikation manuell erfasst oder elektronisch bestätigt. | ||
|
Warum das wichtig ist
Die Bestätigung des Lieferanten zeigt, dass die Bestellung eingegangen ist und bearbeitet wird. Durch die Nachverfolgung lässt sich die Kommunikation mit Lieferanten besser steuern und möglichen Problemen bei der Auftragsabwicklung frühzeitig begegnen.
Woher beziehen
Dieses Ereignis wird in der Regel anhand einer Änderung der Bestätigungsstatusfelder im Bestellkopf oder in den Bestellpositionen abgeleitet, etwa wenn sich PO_HEADERS_ALL.acceptance_status in 'Accepted' ändert.
Erfassung
Leiten Sie das Ereignis aus Aktualisierungen der Statusfelder zur Bestellbestätigung ab.
Ereignistyp
inferred
|
|||
|
Bestellung eingereicht
|
Die erstellte Bestellung wird in den Genehmigungsworkflow eingereicht. Oracle Fusion protokolliert diese Aktion ausdrücklich und erfasst den Benutzer sowie den Timestamp des Einreichungsereignisses. | ||
|
Warum das wichtig ist
Diese Aktivität markiert den Beginn des Genehmigungszyklus. Die Analyse der Zeit zwischen Einreichung und Genehmigung ist entscheidend, um Engpässe im internen Freigabeprozess zu erkennen.
Woher beziehen
Diese Aktion wird für die entsprechende PO_HEADER_ID in der Tabelle PO_ACTION_HISTORY mit dem ACTION_CODE 'SUBMIT' erfasst.
Erfassung
Filtern Sie PO_ACTION_HISTORY nach ACTION_CODE = 'SUBMIT'.
Ereignistyp
explicit
|
|||
|
Bestellung geändert
|
Nach der ersten Freigabe wurde die Bestellung geändert, zum Beispiel hinsichtlich Menge, Preis oder Liefertermin. Oracle Fusion bildet dies durch eine neue Dokumentversion ab. | ||
|
Warum das wichtig ist
Änderungen an Bestellungen bedeuten Nacharbeit und können auf Ungenauigkeiten bei der ursprünglichen Bestellung oder auf veränderte Geschäftsanforderungen hinweisen. Die Häufigkeit und Art dieser Änderungen zu analysieren, hilft dabei, Möglichkeiten zur Steigerung der Prozesseffizienz zu erkennen.
Woher beziehen
Dieses Ereignis wird ausdrücklich erfasst, wenn eine neue Dokumentversion angelegt wird. Erkennbar ist dies an einem höheren Wert im Feld REVISION_NUM der Tabelle PO_HEADERS_ALL.
Erfassung
Ermitteln Sie jeden Fall, in dem der Wert von REVISION_NUM für eine PO_HEADER_ID steigt.
Ereignistyp
explicit
|
|||
|
Dienstleistungserbringung bestätigt
|
Bei dienstleistungsbezogenen Bestellungen bestätigt diese Aktivität, dass die vereinbarten Leistungen erbracht wurden. Die Bestätigung wird häufig manuell oder über ein Leistungserfassungsblatt dokumentiert. | ||
|
Warum das wichtig ist
Bei Dienstleistungen entspricht dies dem Wareneingang und ist ein wichtiger Schritt, bevor eine Rechnung bezahlt werden kann. Verzögerungen bei der Leistungsbestätigung können zu verspäteten Zahlungen und belasteten Lieferantenbeziehungen führen.
Woher beziehen
In der Regel wird dies als Wareneingang zu einer Dienstleistungsposition der Bestellung erfasst. Dabei können bestimmte Felder oder komplexe Wareneingangsbuchungen zum Einsatz kommen, mit denen der Fortschritt oder Abschluss der Leistungen dokumentiert wird.
Erfassung
Ermitteln Sie Wareneingangstransaktionen (RCV_TRANSACTIONS), die mit dienstleistungsbezogenen Bestellpositionen verknüpft sind.
Ereignistyp
explicit
|
|||
|
Qualitätsprüfung durchgeführt
|
Waren, für die eine Qualitätsprüfung erforderlich ist, wurden geprüft und entweder angenommen oder abgelehnt. Diese Aktivität findet nach dem ersten Wareneingang statt und wird als eigene Transaktion erfasst. | ||
|
Warum das wichtig ist
Diese Aktivität ist für das Qualitätsmanagement entscheidend. Die Dauer der Prüfungen zu analysieren, hilft dabei, die Qualitätskontrolle effizienter zu gestalten und Verzögerungen zu verringern, bevor die Waren verwendet werden können.
Woher beziehen
Die Erfassung erfolgt in der Tabelle RCV_TRANSACTIONS. Erkennbar ist die Aktivität an Transaktionen mit TRANSACTION_TYPE 'ACCEPT' oder 'REJECT', die auf eine Wareneingangstransaktion folgen.
Erfassung
Verwenden Sie TRANSACTION_DATE aus RCV_TRANSACTIONS, wenn TRANSACTION_TYPE den Wert 'ACCEPT' oder 'REJECT' hat.
Ereignistyp
explicit
|
|||
|
Waren an Lieferanten zurückgesendet
|
Bereits eingegangene Waren werden an den Lieferanten zurückgesendet, meist wegen Mängeln, Beschädigungen oder einer falschen Lieferung. Im Wareneingangsmodul wird dies als eigene Rücksendetransaktion erfasst. | ||
|
Warum das wichtig ist
Rücksendungen zu verfolgen ist wichtig, um die Lieferantenqualität und die Bestellgenauigkeit zu bewerten. Eine hohe Rücksendequote bei einem Lieferanten kann auf grundlegende Probleme hinweisen, die behoben werden müssen.
Woher beziehen
Dieses Ereignis wird ausdrücklich in der Tabelle RCV_TRANSACTIONS mit dem TRANSACTION_TYPE 'RETURN TO VENDOR' erfasst.
Erfassung
Verwenden Sie TRANSACTION_DATE aus RCV_TRANSACTIONS, wenn TRANSACTION_TYPE den Wert 'RETURN TO VENDOR' hat.
Ereignistyp
explicit
|
|||
|
Wareneingang angelegt
|
Im System wird ein Wareneingangsbeleg angelegt, bevor die Waren physisch eintreffen. Diese Aktivität markiert den Beginn des internen Wareneingangsprozesses. | ||
|
Warum das wichtig ist
Hier geht der Prozess von der Beschaffung in die Logistik über. Die Zeitspanne von diesem Zeitpunkt bis zur endgültigen Buchung des Wareneingangs zeigt, wo es im Lager oder in der Wareneingangsabteilung zu Verzögerungen kommt.
Woher beziehen
Dieses Ereignis wird ausdrücklich erfasst: Maßgeblich ist der Erstellungszeitpunkt eines neuen, mit der Bestellung verknüpften Datensatzes in der Tabelle RCV_SHIPMENT_HEADERS.
Erfassung
Verwenden Sie das Erstellungsdatum des zugehörigen Datensatzes in RCV_SHIPMENT_HEADERS.
Ereignistyp
explicit
|
|||
Anleitungen zur Datenextraktion
Möchten Sie loslegen?
Verwenden Sie dieses Template, um Ihre Datenerfassung zu vereinfachen und Erkenntnisse zu Ihrem Bestellprozess zu gewinnen. Beginnen Sie noch heute damit, Ihre Abläufe zu optimieren.
Optimieren Sie noch heute Ihren Bestellprozess
Erkennen Sie kostspielige Engpässe und verkürzen Sie die Zykluszeit ganz einfach um 30 %.
Keine Kreditkarte erforderlich. Beginnen Sie noch heute mit der Optimierung.