Ihr Purchase-to-Pay-Bestellanforderungsdaten-Template
Ihr Purchase-to-Pay-Bestellanforderungsdaten-Template
- Empfohlene Attribute zur Erfassung
- Schlüsselaktivitäten zur Verfolgung für die Prozesserkennung
- Anleitung zur Datenextraktion
Purchase-to-Pay – Bestellanforderungsattribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivitätsname
ActivityName
|
Der Name eines spezifischen Geschäftsereignisses oder einer Aufgabe, die innerhalb des Lebenszyklus der Bestellanforderung aufgetreten ist. | ||
|
Beschreibung
Der Aktivitätsname (Activity Name) beschreibt einen einzelnen Schritt im Bestellanforderungsprozess, wie „Requisition Created“, „Approval Step Approved“ oder „Purchase Order Created“. Diese Aktivitäten sind die Bausteine der Prozesslandkarte und repräsentieren die ausgeführte Arbeit. Die Analyse dieser Aktivitäten ermöglicht die Visualisierung des Prozessflusses, die Identifizierung von Engpässen und die Messung der in verschiedenen Phasen verbrachten Zeit. Die Abfolge der Aktivitäten für eine bestimmte Purchase Requisition ID definiert deren Weg, der dann mit Standardverfahren verglichen werden kann, um Abweichungen oder Ineffizienzen zu identifizieren.
Bedeutung
Es definiert die Schritte im Prozess und ermöglicht die Visualisierung von Prozesslandkarten, die Analyse von Prozessvarianten und die Identifizierung von Engpässen.
Datenquelle
Dies wird typischerweise aus einer Kombination des Transaktionsstatus, Systemprotokolleinträgen, Workflow-Historie oder benutzerdefinierter Event-Verfolgung innerhalb von NetSuite abgeleitet.
Beispiele
Anforderung erstelltGenehmigungsschritt genehmigtBestellanforderung geändert`Bestellung` erstellt
|
|||
|
Bestellanforderungs-ID
PurchaseRequisitionId
|
Die eindeutige Kennung für jede Bestellanforderung, die als primäre Case ID für die Prozessanalyse dient. | ||
|
Beschreibung
Die Bestellanforderungs-ID (Purchase Requisition ID) ist die zentrale Kennung, die alle Aktivitäten und Events im Zusammenhang mit einer spezifischen Anfrage für Waren oder Dienstleistungen verknüpft. Jeder Bestellanforderung wird bei der Erstellung in NetSuite eine eindeutige ID zugewiesen, die während ihres gesamten Lebenszyklus konstant bleibt. Im Process Mining ist dieses Attribut grundlegend für die Case-Korrelation. Es ermöglicht die Rekonstruktion des End-to-End-Verlaufs jeder Bestellanforderung, von ihrer ersten Erstellung über alle Genehmigungsschritte, Änderungen und endgültigen Ergebnisse wie Genehmigung, Ablehnung oder Umwandlung in eine Bestellung. Die Analyse von Prozessen anhand dieser ID ist unerlässlich für die Berechnung von Lebenszyklusdauern, die Verfolgung von Statusänderungen und die Identifizierung von Variationen in Prozessabläufen.
Bedeutung
Dies ist der wesentliche Schlüssel, um den gesamten Lebenszyklus einer einzelnen Bestellanforderung zu verfolgen und so Prozessabläufe zu analysieren und Case-Level-Metriken zu berechnen.
Datenquelle
Dies ist die interne ID oder Transaktionsnummer des Purchase Requisition Datensatzes in NetSuite. Sie ist typischerweise im Feld „tranid“ für die Transaktion zu finden.
Beispiele
PR-001254PR-001255PR-001256
|
|||
|
Ereigniszeit
EventTime
|
Das genaue Datum und die genaue Uhrzeit, zu der die Aktivität stattgefunden hat. | ||
|
Beschreibung
Die Event Time, oder der Timestamp, erfasst den genauen Zeitpunkt, zu dem eine Aktivität stattfand. Diese temporalen Daten sind entscheidend für das Verständnis der Dynamik des Bestellanforderungsprozesses, einschließlich seiner Dauer, der Abfolge von Events und des Timings. In der Prozessanalyse werden Time Stamps verwendet, um Zykluszeiten, Wartezeiten zwischen Aktivitäten und die Einhaltung von Service Level Agreements zu berechnen. Sie bilden die Grundlage für alle zeitbasierten Analysen und ermöglichen die Erstellung von Dashboards wie 'Bestellanforderungs-Genehmigungszykluszeit' und KPIs wie 'Durchschnittliche Bestellanforderungs-Zykluszeit'. Genaue Timestamps sind entscheidend für ein zuverlässiges Prozessmodell.
Bedeutung
Dieser Timestamp ist die Grundlage für alle leistungsbezogenen Analysen, wie die Berechnung von Zykluszeiten, die Identifizierung von Verzögerungen und die Messung der Prozesseffizienz.
Datenquelle
Diese Informationen werden in systemgenerierten Feldern wie „Date Created“ oder in den Timestamps erfasst, die in den System Notes oder Workflow-Ausführungsprotokollen für jede Transaktion verfügbar sind.
Beispiele
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Abteilung
Department
|
Die Geschäftsabteilung, zu der die Bestellanforderung oder der Anforderer gehört. | ||
|
Beschreibung
Das Attribut Abteilung (Department) repräsentiert die Organisationseinheit, die mit der Bestellanforderung verbunden ist, was normalerweise die Abteilung des Anforderers ist. Diese Information bietet eine Möglichkeit, den Prozess aus organisatorischer Sicht zu segmentieren und zu analysieren. Es ist eine Schlüsseldimension für viele Analysen, wie den Vergleich von Genehmigungszykluszeiten über Abteilungen hinweg, das Verständnis von Ausgabenmustern oder die Identifizierung von Abteilungen mit den höchsten Ablehnungsraten. Diese Segmentierung hilft dem Management, Ressourcen zuzuweisen, Schulungen anzupassen und Workflows für spezifische Geschäftseinheiten zu optimieren.
Bedeutung
Ermöglicht eine leistungsstarke Segmentierung der Prozessdaten, um Leistung, Kosten und Compliance über verschiedene Geschäftseinheiten hinweg zu vergleichen.
Datenquelle
Diese Informationen sind oft mit dem Mitarbeiterdatensatz des Anforderers verknüpft oder können direkt im Transaktionskopf der Purchase Requisition festgelegt werden.
Beispiele
MarketingITFinanzenVorgänge
|
|||
|
Anfragender
Requester
|
Der Mitarbeiter, der die Bestellanforderung erstellt und eingereicht hat. | ||
|
Beschreibung
Der Anforderer (Requester) ist die Person, die den Beschaffungsprozess durch die Erstellung der Bestellanforderung initiiert. Dies ist typischerweise ein Mitarbeiter, der spezifische Waren oder Dienstleistungen zur Erfüllung seiner Aufgaben benötigt. Die Analyse von Daten nach Anforderer ist essenziell, um Muster im Benutzerverhalten zu identifizieren. Sie hilft beim Aufbau von Dashboards wie „Requester Performance and Training Needs“, indem sie Personen mit hohen Ablehnungsraten oder häufigen Änderungen hervorhebt. Diese Erkenntnis kann Bereiche aufzeigen, in denen zusätzliche Schulungen oder klarere Richtlinien die Qualität der Ersterstellung und die gesamte Prozesseffizienz verbessern könnten.
Bedeutung
Identifiziert den Prozessinitiator, was entscheidend ist für die Analyse des Benutzerverhaltens, der Ablehnungsraten pro Anforderer und die Identifizierung von Schulungsbedarfen.
Datenquelle
Dies ist typischerweise das Feld „Employee“ oder „Created By“ im Purchase Requisition Transaktionsdatensatz.
Beispiele
John SmithJane DoePeter Jones
|
|||
|
Bestellanforderungsstatus
RequisitionStatus
|
Zeigt den aktuellen Status der Bestellanforderung in ihrem Lebenszyklus an. | ||
|
Beschreibung
Der Bestellanforderungsstatus (Requisition Status) bietet einen Überblick darüber, wo sich eine Bestellanforderung zu einem bestimmten Zeitpunkt in ihrem Prozess befindet. Gängige Status sind „Pending Approval“, „Fully Approved“, „Rejected“ und „Closed“. Dieses Attribut ist entscheidend für die Erstellung von Dashboards wie „Requisition Status and Aging“, das aktive Bestellanforderungen und deren Verweildauer im aktuellen Status verfolgt. Die Analyse von Statusübergängen ist ein wichtiger Bestandteil der Prozessentdeckung und hilft, sowohl die positiven Pfade („Happy Paths“) als auch die Ausnahmen zu verstehen. Es wird auch verwendet, um das Endergebnis eines Falls zu bestimmen.
Bedeutung
Bietet einen Überblick über den Fortschritt eines Falls und ermöglicht die Analyse alternder Bestellanforderungen sowie die Identifizierung, wo Fälle stecken bleiben.
Datenquelle
Dies ist das Feld „Status“ oder „Approval Status“ im Purchase Requisition Transaktionskopf.
Beispiele
Genehmigung ausstehendVollständig genehmigtAbgelehntGeschlossen
|
|||
|
Gesamtbetrag
TotalAmount
|
Der gesamte Geldwert der Bestellanforderung. | ||
|
Beschreibung
Dieses Attribut erfasst die Gesamtkosten aller auf der Bestellanforderung aufgeführten Artikel. Es ist ein kritischer finanzieller Datenpunkt, der oft den Prozess selbst beeinflusst, zum Beispiel durch die Auslösung unterschiedlicher Genehmigungs-Workflows basierend auf Wertschwellen. Die Analyse des Gesamtbetrags hilft beim Verständnis von Ausgabenmustern und finanziellen Auswirkungen. Sie ermöglicht das Filtern von Bestellanforderungen nach Wert, die Korrelation von Prozessabweichungen mit hochwertigen Anfragen und die Priorisierung der Analyse auf finanziell bedeutsame Fälle. Es ist ein fundamentales Attribut für jede finanzielle oder Compliance-bezogene Prozessanalyse.
Bedeutung
Bietet finanziellen Kontext und ermöglicht eine wertbasierte Analyse, die oft Genehmigungspfade und Geschäftsprioritäten bestimmt.
Datenquelle
Dies ist ein Standardfeld im Purchase Requisition Datensatz, oft benannt als „Total“ oder eine ähnliche Variante.
Beispiele
500.001250.7525000.00
|
|||
|
Ablehnungsgrund
RejectionReason
|
Die Begründung eines Genehmigers, wenn eine Bestellanforderung abgelehnt wird. | ||
|
Beschreibung
Der Ablehnungsgrund (Rejection Reason) ist ein Textattribut, in dem ein Genehmiger angeben kann, warum eine Bestellanforderung die Genehmigungsanforderungen nicht erfüllt hat. Dies liefert qualitativen Kontext zur Aktivität „Approval Step Rejected“. Diese Information ist von unschätzbarem Wert für die Ursachenanalyse. Sie speist Dashboards wie „Requisition Rejection Rate Analysis“, indem sie nicht nur zeigt, was abgelehnt wurde, sondern auch warum. Häufige Gründe können „Incorrect GL Account“, „Budget Exceeded“ oder „Insufficient Detail“ sein. Die Analyse dieser Gründe hilft, systemische Probleme zu identifizieren, die Benutzerschulung zu verbessern und die Einreichungsrichtlinien zu verfeinern, um Nachbearbeitungs- und Ablehnungsraten zu reduzieren.
Bedeutung
Liefert kritischen Kontext, warum Ablehnungen auftreten, und ermöglicht eine Ursachenanalyse, um zukünftige Ablehnungsraten zu reduzieren und die Qualität der Ersterstellung zu verbessern.
Datenquelle
Dies wird oft in einem „Memo“-Feld während der Ablehnungsaktion oder einem benutzerdefinierten Feld, das zum Genehmigungs-Workflow hinzugefügt wurde, erfasst. Es kann auch in den System Notes gefunden werden.
Beispiele
Budget überschrittenFalscher Lieferant ausgewähltFehlende ArtikeldetailsDoppelte Anforderung
|
|||
|
Artikelkategorie
ItemCategory
|
Die Kategorie der Waren oder Dienstleistungen, die in der Bestellanforderung angefragt werden. | ||
|
Beschreibung
Die Artikelkategorie (Item Category) klassifiziert die Artikel einer Bestellanforderung in logische Gruppen wie „IT Hardware“, „Bürobedarf“ oder „Professionelle Dienstleistungen“. Dies kann aus den Artikeldatensätzen abgeleitet werden, die mit den Bestellanforderungspositionen verknüpft sind. Dieses Attribut ermöglicht eine tiefere, granularere Analyse des Bestellanforderungsprozesses. Es hilft, Fragen zu beantworten wie: „Dauert die Genehmigung von Bestellanforderungen für IT Hardware länger als die für Bürobedarf?“ Durch die Segmentierung des Prozesses nach Artikelkategorie können Unternehmen domänenspezifische Engpässe aufdecken, Ausgaben nach Kategorien analysieren und Beschaffungsstrategien entsprechend anpassen.
Bedeutung
Ermöglicht die Analyse des Prozesses basierend auf dem, was gekauft wird, und hilft dabei, kategorie-spezifische Engpässe oder Compliance-Probleme zu identifizieren.
Datenquelle
Diese Informationen werden von den „Item“-Datensätzen abgeleitet, die auf Positionsebene der Purchase Requisition verknüpft sind. Die Kategorie selbst kann ein Standard- oder benutzerdefiniertes Feld im Item-Datensatz sein.
Beispiele
IT HardwareSoftware LicensesBürobedarfMarketingdienstleistungen
|
|||
|
Bestell-ID
PurchaseOrderId
|
Die Kennung der Bestellung, die aus der genehmigten Bestellanforderung erstellt wurde. | ||
|
Beschreibung
Die Bestell-ID (Purchase Order ID) ist die eindeutige Kennung für die Bestellung, die infolge einer genehmigten Bestellanforderung generiert wird. Dieses Attribut dient als entscheidende Verbindung zwischen dem Bestellanforderungsprozess und den nachfolgenden Beschaffungsaktivitäten. In der Prozessanalyse ist diese Verknüpfung für die End-to-End-P2P-Analyse von entscheidender Bedeutung. Sie ermöglicht die Berechnung des KPI „PO Creation Lead Time“, indem die Zeit zwischen der Genehmigung der Bestellanforderung und der PO-Erstellung gemessen wird. Sie hilft auch bei der Berechnung der „Requisition-to-PO Conversion Rate“ und liefert Einblicke, wie effektiv Bestellanforderungen in umsetzbare Bestellungen umgewandelt werden.
Bedeutung
Verknüpft die Bestellanforderung mit der resultierenden Bestellung und ermöglicht die Messung der Durchlaufzeit für die Bestellerstellung sowie eine End-to-End-Prozessanalyse.
Datenquelle
Dies ist im Purchase Requisition Datensatz zu finden, oft auf einem Subtab für verknüpfte Datensätze oder einem „Created From“-Link auf der Bestellung selbst.
Beispiele
PO-005432PO-005433PO-005434
|
|||
|
Dringlichkeitsstufe
UrgencyLevel
|
Eine Klassifizierung der Priorität der Bestellanforderung, wie Standard oder Dringend. | ||
|
Beschreibung
Die Dringlichkeitsstufe ist ein kategoriales Attribut, das die geschäftliche Priorität einer Bestellanforderung angibt. Dies ermöglicht es Mitarbeitern, Anfragen zu kennzeichnen, die aufgrund kritischer geschäftlicher Anforderungen eine beschleunigte Bearbeitung erfordern. Dieses Attribut ist speziell dafür konzipiert, das Dashboard 'Leistung bei der Bearbeitung dringender Anfragen' und den KPI 'Bearbeitungszeit dringender Bestellanforderungen' zu unterstützen. Durch das Filtern der Prozessdaten basierend auf diesem Attribut können Analysten die Zykluszeiten und Prozesspfade dringender Anfragen im Vergleich zu Standardanfragen vergleichen, um festzustellen, ob die Prioritätsbehandlung effektiv ist oder ob Bottlenecks immer noch Verzögerungen verursachen.
Bedeutung
Ermöglicht den Vergleich der Prozessleistung für Anfragen mit hoher Priorität im Vergleich zu Standardanfragen, um sicherzustellen, dass kritische Anforderungen effizient erfüllt werden.
Datenquelle
Dies wäre typischerweise ein benutzerdefiniertes Transaktionshauptfeld auf dem Bestellanforderungsformular.
Beispiele
HochMittelNiedrig
|
|||
|
Durchlaufzeit
CycleTime
|
Die gesamte verstrichene Zeit von der Erstellung bis zur endgültigen Lösung einer Bestellanforderung. | ||
|
Beschreibung
Die Zykluszeit ist eine berechnete Metrik, die die Gesamtdauer des Bestellanforderungsprozesses für einen einzelnen Case misst. Sie wird typischerweise als Zeitdifferenz zwischen der ersten Aktivität (z. B. 'Bestellanforderung erstellt') und der letzten terminalen Aktivität (z. B. 'Bestellanforderung vollständig genehmigt' oder 'Bestellanforderung endgültig abgelehnt') berechnet. Dies ist ein primärer Key Performance Indicator für die gesamte Prozesseffizienz. Er wird zur Berechnung des KPIs 'Durchschnittliche Bestellanforderungs-Zykluszeit' verwendet und hilft, Trends, Ausreißer und die Auswirkungen von Prozessverbesserungsinitiativen zu identifizieren. Die Analyse der Zykluszeitverteilung kann Long-Tail-Bestellanforderungen aufdecken, die die durchschnittliche Leistung erheblich beeinträchtigen.
Bedeutung
Misst direkt die End-to-End-Effizienz des Prozesses, die eine Kernmetrik zur Identifizierung von Verzögerungen und zur Bewertung der Gesamtleistung ist.
Datenquelle
Dies ist ein berechnetes Attribut, abgeleitet durch Subtraktion des Timestamps des ersten Events vom Timestamp des letzten Events für jede „PurchaseRequisitionId“.
Beispiele
25920060480086400
|
|||
|
Genehmiger
Approver
|
Der Mitarbeiter oder Benutzer, der für die Genehmigung oder Ablehnung eines Genehmigungsschritts verantwortlich ist. | ||
|
Beschreibung
Der Genehmiger (Approver) ist die Person, die zugewiesen ist, eine Bestellanforderung in einer bestimmten Phase des Genehmigungs-Workflows zu prüfen und zu bearbeiten. Es kann mehrere Genehmiger für eine einzelne Bestellanforderung geben, die jeweils mit einer anderen Genehmigungsaktivität verbunden sind. Dieses Attribut ist wesentlich für die Analyse der Leistung des Genehmigungsprozesses selbst. Es hilft beim Aufbau von Dashboards wie „Approval Step Cycle Time Distribution“, die individuelle oder Gruppenengpässe genau identifizieren können. Durch die Verfolgung, wer Genehmigungen durchführt, können Organisationen die Verantwortlichkeit sicherstellen, Arbeitslasten ausgleichen und Verzögerungen durch bestimmte Genehmiger identifizieren.
Bedeutung
Identifiziert den Benutzer, der Genehmigungsaufgaben durchführt, was entscheidend ist für die Analyse der Genehmigerleistung, Arbeitslast und die Identifizierung von Engpässen.
Datenquelle
Diese Informationen sind oft im Workflow-Ausführungsprotokoll oder in den System Notes im Zusammenhang mit Genehmigungsstatusänderungen zu finden. Sie können auch in benutzerdefinierten Datensatzfeldern gespeichert werden, die sich auf den Genehmigungs-Workflow beziehen.
Beispiele
Sarah JenkinsDavid ChenFinanzgenehmigungsgruppe
|
|||
|
Genehmigungs-Workflow-Pfad
ApprovalWorkflowPath
|
Eine Darstellung der Abfolge von Genehmigungsschritten, die eine Bestellanforderung durchlaufen hat. | ||
|
Beschreibung
Der Genehmigungs-Workflow-Pfad (Approval Workflow Path) ist ein abgeleitetes Attribut, das die Abfolge von Genehmigungsaktivitäten oder -status für eine gegebene Bestellanforderung verkettet, z.B. „Submitted -> Manager Approval -> Finance Approval“. Dies erzeugt eine einzigartige Signatur für den Pfad, den jeder Fall genommen hat. Dieses Attribut ist die Grundlage für die Konformitätsprüfung und Variantenanalyse. Es unterstützt direkt die Dashboards „Non-Compliant Requisition Pathways“ und „Approval Workflow Path Compliance“, indem es das Filtern und Gruppieren von Fällen nach ihrem genauen Prozessfluss erleichtert. Durch den Vergleich tatsächlicher Pfade mit vordefinierten Standardpfaden können Organisationen die Compliance quantifizieren und die Grundursachen von Abweichungen untersuchen.
Bedeutung
Ermöglicht eine leistungsstarke Variantenanalyse und Konformitätsprüfung, indem die genaue Abfolge der Genehmigungsschritte für jeden Case zusammengefasst wird.
Datenquelle
Dies ist ein abgeleitetes Attribut, berechnet durch die Verkettung der „ActivityName“-Werte in chronologischer Reihenfolge für jede „PurchaseRequisitionId“.
Beispiele
Erstellt > Eingereicht > GenehmigtErstellt > Eingereicht > Abgelehnt > Geändert > Eingereicht > GenehmigtErstellt > Eingereicht > Genehmigt > Zurückgezogen
|
|||
|
Ist Nacharbeit
IsRework
|
Eine boolesche Markierung, die angibt, ob die Bestellanforderung einen Ablehnungs- und Wiedereinreichungszyklus durchlaufen hat. | ||
|
Beschreibung
Is Rework ist ein abgeleitetes boolesches Attribut, das auf „true“ gesetzt wird, wenn eine Bestellanforderung zu irgendeinem Zeitpunkt abgelehnt und anschließend geändert oder erneut zur Genehmigung eingereicht wurde. Es identifiziert Fälle, die zusätzliche Arbeit und Bearbeitung über den Standard-„Happy Path“ hinaus erforderten. Dieses Attribut vereinfacht die Analyse von Prozessineffizienzen. Es wird verwendet, um den KPI „Approval Rejection Cycle Count“ zu berechnen und hilft, die Auswirkungen von Ablehnungen auf den Gesamtprozess zu quantifizieren. Durch das Filtern nach Fällen, in denen Is Rework „true“ ist, können Analysten problematische Prozessvarianten isolieren und die Grundursachen der ursprünglichen Ablehnungen untersuchen, wie z.B. schlechte Datenqualität oder Missverständnisse von Richtlinien.
Bedeutung
Hilft bei der Quantifizierung der Häufigkeit und Auswirkungen von Nacharbeitszyklen, die eine Hauptursache für Prozesseffizienzverluste und Verzögerungen sind.
Datenquelle
Dies ist ein berechnetes Attribut. Die Logik prüft, ob eine Aktivität „Requisition Submitted for Approval“ nach einer Aktivität „Approval Step Rejected“ für denselben Fall auftritt.
Beispiele
truefalsch
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Zeitstempel, der angibt, wann die Daten zuletzt aus dem Quellsystem extrahiert oder aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut zeichnet Datum und Uhrzeit des letzten Datenabzugs aus NetSuite auf. Es ist ein kritisches Metadatum für jedes Process Mining Dashboard oder jede Analyse. Dieser Timestamp liefert Kontext für die Aktualität der Daten und ermöglicht es den Benutzern zu verstehen, ob sie Echtzeitinformationen oder eine Momentaufnahme zu einem bestimmten Zeitpunkt betrachten. Er ist entscheidend für die Datenvalidierung und für die Kommunikation der Aktualität der aus der Prozessanalyse generierten Erkenntnisse an Stakeholder.
Bedeutung
Informiert Nutzer über die Aktualität der Daten und stellt sicher, dass sie verstehen, wie aktuell die Process Erkenntnisse sind.
Datenquelle
Dieser
Beispiele
2024-05-21T08:00:00Z2024-05-20T08:00:00Z
|
|||
|
Lieferantenname
VendorName
|
Der Name des vorgeschlagenen oder bevorzugten Lieferanten für die Bestellanforderung. | ||
|
Beschreibung
Das Attribut Lieferantenname (Vendor Name) identifiziert den Lieferanten, von dem die Waren oder Dienstleistungen gekauft werden sollen. Während eine Bestellanforderung ein internes Dokument ist, wird oft ein bevorzugter Lieferant angegeben. Die Analyse dieses Attributs kann Muster im Zusammenhang mit dem Lieferantenmanagement aufdecken. Es hilft zu verfolgen, welche Lieferanten am häufigsten angefragt werden, ob Bestellanforderungen für bestimmte Lieferanten längere Genehmigungszeiten aufweisen und die Einhaltung von Vereinbarungen mit bevorzugten Lieferanten sicherzustellen. Diese Informationen können ein wertvoller Input für strategisches Sourcing und Lieferantenbeziehungsmanagement sein.
Bedeutung
Hilft bei der Analyse von Beschaffungsmustern nach Lieferanten, stellt die Einhaltung von bevorzugten Lieferantenlisten sicher und identifiziert lieferantenspezifische Prozessvariationen.
Datenquelle
Dies kann ein „Vendor“-Feld auf Kopfebene sein oder auf den Positionen des Purchase Requisition Datensatzes angegeben werden.
Beispiele
Dell Inc.StaplesMcKinsey & Company
|
|||
|
Quellsystem
SourceSystem
|
Identifiziert das Quellsystem, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut spezifiziert das Ursprungssystem für die Prozessdaten, das in diesem Fall NetSuite ist. Es ist besonders nützlich in Umgebungen, in denen Daten aus mehreren Systemen für eine umfassende Prozessansicht kombiniert werden. Obwohl es in einer Einzel-System-Analyse statisch erscheinen mag, bietet es wesentlichen Kontext und ist eine Best Practice für Data Governance und Nachvollziehbarkeit. Es hilft, den Datenursprung zu bestätigen und stellt sicher, dass system-spezifische Logik oder Transformationen während der Analyse korrekt verstanden werden.
Bedeutung
Bietet entscheidenden Kontext über den Datenursprung, um Klarheit und eine ordnungsgemäße Governance zu gewährleisten, insbesondere in Multi-System-Umgebungen.
Datenquelle
Dies ist ein statischer Wert, „NetSuite“, der während des Datenextraktions- und Transformationsprozesses hinzugefügt werden sollte.
Beispiele
NetSuiteNetSuite SuitePeopleNetSuite ERP
|
|||
|
Währung
Currency
|
Der Währungscode für den Gesamtbetrag der Bestellanforderung. | ||
|
Beschreibung
Das Attribut Währung (Currency) spezifiziert die Währung, in der die Finanzwerte der Bestellanforderung angegeben sind, wie USD, EUR oder GBP. Dies ist besonders wichtig für multinationale Organisationen, die mit mehreren Währungen operieren. Dieses Feld stellt sicher, dass Finanzdaten korrekt interpretiert werden. Im Process Mining ermöglicht es die korrekte Aggregation und den Vergleich von Geldwerten, entweder durch Umrechnung aller Beträge in eine einzige Basiswährung oder durch Segmentierung der Analyse nach Währung. Es verhindert ungenaue Finanzberichterstattung und sorgt für Klarheit in globalen Operationen.
Bedeutung
Unerlässlich für eine genaue Finanzanalyse in multinationalen Unternehmen, um sicherzustellen, dass monetäre Werte korrekt interpretiert und aggregiert werden.
Datenquelle
Dies ist ein Standardfeld „Currency“ im Purchase Requisition Transaktionsdatensatz, insbesondere in NetSuite-Instanzen mit mehreren Währungen.
Beispiele
USDEURGBP
|
|||
Purchase-to-Pay – Bestellanforderungsaktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
`Bestellung` erstellt
|
Eine Bestellung (PO) wird aus der vollständig genehmigten Bestellanforderung generiert, wodurch Gelder offiziell einem Lieferanten zugewiesen werden. Dies ist ein explizites Event, das durch die Erstellung einer neuen PO-Transaktion gekennzeichnet ist, die auf die Ursprungsbestellanforderung zurückverweist. | ||
|
Bedeutung
Dies ist das primäre Ergebnis einer erfolgreichen Bestellanforderung und eine wichtige Übergabe im Purchase-to-Pay-Prozess. Die Zeit zwischen Genehmigung und PO-Erstellung ist ein kritischer KPI für die Beschaffungseffizienz.
Datenquelle
Identifiziert durch das Auffinden eines Bestellungsdatensatzes, bei dem das Feld 'Erstellt aus' oder ein ähnliches Verknüpfungsfeld auf die
Erfassen
Suchen Sie die Bestellung (PO), bei der das Feld 'Erstellt aus' der Bestellanforderungs-ID entspricht und verwenden Sie das 'Erstellungsdatum' der Bestellung.
Ereignistyp
explicit
|
|||
|
Anforderung erstellt
|
Ein Benutzer initiiert den Beschaffungsprozess, indem er einen neuen Bestellanforderungsdatensatz erstellt und speichert. Dies ist das erste Event im Lebenszyklus der Bestellanforderung und wird erfasst, wenn der Transaktionsdatensatz zum ersten Mal in NetSuite gespeichert wird. | ||
|
Bedeutung
Diese Aktivität markiert den offiziellen Beginn des Beschaffungsprozesses für einen spezifischen Bedarf. Die Analyse der Zeit von der Erstellung bis zur Einreichung kann Verzögerungen bei der Dateneingabe oder der anfänglichen Anforderungsformulierung aufdecken.
Datenquelle
Dieses Event wird vom Erstellungsdatum-Timestamp des Purchase Requisition Transaktionsdatensatzes erfasst. Es kann im Hauptkopf des Datensatzes oder im Subtab „System Notes“ gefunden werden, der die Aktion „Create“ protokolliert.
Erfassen
Verwenden Sie das Feld 'Erstellungsdatum' im Bestellanforderungsdatensatz.
Ereignistyp
explicit
|
|||
|
Bestellanforderung endgültig abgelehnt
|
Die Bestellanforderung wird endgültig abgelehnt und nicht weiter bearbeitet. Dieses Event wird abgeleitet, wenn der endgültige „Approval Status“ der Bestellanforderung auf „Rejected“ aktualisiert wird. | ||
|
Bedeutung
Diese Aktivität ist ein kritischer Endpunkt für erfolglose Bestellanforderungen. Das Verständnis, warum und wann Bestellanforderungen endgültig abgelehnt werden, liefert Einblicke in die Richtlinien-Compliance und Budgetprobleme.
Datenquelle
Abgeleitet aus dem Subtab „System Notes“, indem der Timestamp identifiziert wird, zu dem das Feld „Approval Status“ auf seinen endgültigen Status „Rejected“ gesetzt wird.
Erfassen
Timestamp der Statusänderung des 'Genehmigungsstatus' auf 'Abgelehnt'.
Ereignistyp
inferred
|
|||
|
Bestellanforderung geschlossen
|
Die Bestellanforderung wird formal geschlossen, was darauf hindeutet, dass keine weiteren Maßnahmen erwartet werden. Dies geschieht oft automatisch, nachdem alle Mengen der Bestellanforderung über verknüpfte Bestellungen bestellt wurden. | ||
|
Bedeutung
Diese Aktivität markiert das definitive Ende des Lebenszyklus der Bestellanforderung. Sie bestätigt, dass der geschäftliche Bedarf gedeckt wurde und der Datensatz finalisiert ist.
Datenquelle
Abgeleitet aus dem Subtab „System Notes“, indem der Timestamp identifiziert wird, zu dem das Statusfeld auf Positions- oder Kopfebene auf „Closed“ aktualisiert wird.
Erfassen
Timestamp der Statusänderung des 'Statusfeldes' auf 'Geschlossen'.
Ereignistyp
inferred
|
|||
|
Bestellanforderung vollständig genehmigt
|
Die Bestellanforderung durchläuft erfolgreich alle erforderlichen Schritte im Genehmigungs-Workflow. Dies wird abgeleitet, wenn der endgültige „Approval Status“ des Datensatzes auf „Approved“ wechselt. | ||
|
Bedeutung
Dies ist ein wichtiger Meilenstein, der signalisiert, dass die Bestellanforderung bereit ist, in eine Bestellung umgewandelt zu werden. Es markiert das Ende des Genehmigungszyklus und den Beginn der Beschaffungserfüllungsphase.
Datenquelle
Abgeleitet aus dem Subtab „System Notes“, indem der Timestamp identifiziert wird, zu dem das Feld „Approval Status“ auf seinen endgültigen Status „Approved“ gesetzt wird.
Erfassen
Timestamp der Statusänderung des 'Genehmigungsstatus' auf 'Genehmigt'.
Ereignistyp
inferred
|
|||
|
Bestellanforderung geändert
|
Ein Benutzer ändert ein beliebiges Feld der Bestellanforderung nach der ersten Erstellung, oft als Reaktion auf eine Ablehnung oder eine Änderung der Anforderungen. Dieses Event wird direkt aus der Audit-Trail-Funktion von NetSuite erfasst. | ||
|
Bedeutung
Die Nachverfolgung von Änderungen ist entscheidend, um Nacharbeitschleifen und Probleme mit der Datenqualität zu identifizieren. Eine hohe Änderungsfrequenz kann auf unklare ursprüngliche Anforderungen oder Schulungsbedarf bei den Anfordernden hinweisen.
Datenquelle
Erfasst aus der Unterregisterkarte Systemnotizen des Bestellanforderungsdatensatzes. Jeder Eintrag mit einem 'Typ' von 'Änderung' oder 'Bearbeiten' in einem relevanten Feld stellt eine Änderung dar.
Erfassen
Protokollieren Sie ein Event für jeden Eintrag vom Typ „Change“ im System Notes Log.
Ereignistyp
explicit
|
|||
|
Bestellanforderung zur Genehmigung eingereicht
|
Der Anforderer reicht die ausgefüllte Bestellanforderung formal in den dafür vorgesehenen Genehmigungs-Workflow ein. Dies wird oft aus einer Statusänderung des Bestellanforderungssatzes abgeleitet, zum Beispiel von „Draft“ oder „Pending Submission“ zu „Pending Approval“. | ||
|
Bedeutung
Diese Aktivität löst den Genehmigungszyklus aus und ist ein entscheidender Startpunkt für die Messung von Genehmigungsdurchlaufzeiten. Sie hilft zu identifizieren, wie lange Bestellanforderungen warten, bevor der formale Genehmigungsprozess beginnt.
Datenquelle
Abgeleitet aus dem Subtab „System Notes“, indem der Timestamp identifiziert wird, zu dem das Feld „Approval Status“ zum ersten Mal einen Wert wie „Pending Approval“ annimmt.
Erfassen
Ersten Timestamp identifizieren, an dem das Feld 'Genehmigungsstatus' zu 'Ausstehende Genehmigung' wechselt.
Ereignistyp
inferred
|
|||
|
Bestellanforderung zurückgezogen
|
Der ursprüngliche Anforderer oder ein Administrator storniert die Bestellanforderung, bevor sie vollständig genehmigt oder in eine Bestellung umgewandelt wird. Dies wird typischerweise aus einer Statusänderung zu „Cancelled“ oder „Withdrawn“ abgeleitet. | ||
|
Bedeutung
Diese Aktivität stellt eine Ausnahme oder Beendigung des vom Anforderer initiierten Prozesses dar. Die Analyse von Rückzügen kann Änderungen in den Geschäftsanforderungen oder nicht mehr gültige Bestellanforderungen hervorheben.
Datenquelle
Abgeleitet aus dem Subtab „System Notes“, indem der Timestamp verfolgt wird, zu dem das Feld „Approval Status“ auf einen Wert wie „Cancelled“ oder einen benutzerdefinierten Status „Withdrawn“ aktualisiert wird.
Erfassen
Timestamp der Statusänderung des 'Genehmigungsstatus' auf 'Storniert' oder 'Zurückgezogen'.
Ereignistyp
inferred
|
|||
|
Genehmigungsschritt abgelehnt
|
Ein Genehmiger lehnt seinen zugewiesenen Schritt ab und sendet die Bestellanforderung typischerweise zur Korrektur an den Anforderer zurück. Diese Aktion wird explizit von der SuiteApprovals Workflow-Engine protokolliert. | ||
|
Bedeutung
Dieses Event ist ein Schlüsselindikator für Nachbearbeitung und Prozesseffizienz. Die Analyse von Ablehnungspunkten hilft, häufige Fehlerursachen wie Richtlinienverstöße oder inkorrekte Daten zu identifizieren.
Datenquelle
Erfasst aus dem SuiteApprovals Log oder der Unterregisterkarte Systemnotizen, die die Ablehnungsaktion, den ablehnenden Benutzer und den Timestamp aufzeichnet.
Erfassen
Ablehnungsaktionen im SuiteApprovals Log oder in den Systemnotizen identifizieren.
Ereignistyp
explicit
|
|||
|
Genehmigungsschritt genehmigt
|
Ein autorisierter Benutzer genehmigt seinen zugewiesenen Schritt im Workflow, wodurch die Bestellanforderung der endgültigen Genehmigung näher rückt. Die SuiteApprovals-Plattform von NetSuite zeichnet diese Aktion explizit mit Benutzer- und Timestamp-Details auf. | ||
|
Bedeutung
Diese Aktivität stellt einen positiven Fortschritt in der Genehmigungskette dar. Die Analyse der Zeit zwischen den Genehmigungsschritten hilft, die Effizienz des Workflows und einzelner Genehmiger zu verstehen.
Datenquelle
Erfasst aus dem SuiteApprovals Log oder der Unterregisterkarte Systemnotizen, die die Genehmigungsaktion, den Genehmiger und den genauen Timestamp des Events aufzeichnet.
Erfassen
Genehmigungsaktionen im SuiteApprovals Log oder in den Systemnotizen identifizieren.
Ereignistyp
explicit
|
|||
|
Genehmigungsschritt gestartet
|
Die Bestellanforderung tritt in eine spezifische Phase des Genehmigungs-Workflows ein und wartet auf die Aktion eines benannten Genehmigers oder einer Gruppe. Dies wird typischerweise abgeleitet, wenn der Workflow die Bestellanforderung dem nächsten Genehmiger in der Sequenz zuweist. | ||
|
Bedeutung
Diese Aktivität markiert den Beginn der Wartezeit für jeden einzelnen Genehmigungsschritt. Sie ist essenziell, um Engpässe innerhalb der Genehmigungshierarchie zu identifizieren und langsame Genehmiger ausfindig zu machen.
Datenquelle
Abgeleitet aus Workflow-Ausführungsprotokollen oder Änderungen in einem Feld für den „Current Approver“ oder den Workflow-Status. Die SuiteApprovals-Plattform verfolgt den aktiven Genehmigungsschritt.
Erfassen
Ableitung aus Workflow-Logs oder wenn der Datensatz einem neuen Genehmiger zugewiesen wird.
Ereignistyp
inferred
|
|||