Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template
Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template
- Empfohlene Attribute zur Erfassung
- Schlüsselaktivitäten zur Verfolgung für die Prozesserkennung
- Anleitung zur Datenextraktion
Purchase-to-Pay – Purchase Requisitions-Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivitätsname
ActivityName
|
Der Name eines spezifischen Geschäftsereignisses oder einer Aufgabe, die innerhalb des Lebenszyklus der Purchase Requisition aufgetreten ist. | ||
|
Beschreibung
Der Aktivitätsname (Aktivitätsname) beschreibt einen einzelnen Schritt im Purchase Requisitionsprozess, wie „Requisition Created“, „Approval Step Approved“ oder „Purchase Order Created“. Diese Aktivitäten sind die Bausteine der Prozessablauf 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 den Antrag bearbeitet.ann mit Standardverfahren verglichen werden kann, um Abweichungen oder Ineffizienzen zu identifizieren.
Bedeutung
Es definiert die Schritte im Prozess und ermöglicht die Visualisierung von Prozessablaufn, die Analyse von Prozessvarianten und die Identifizierung von Engpässen.
Datenquelle
Dies wird in der Regel aus einer Kombination des Transaktionsstatus, Systemprotokolleinträgen, Workflow-Verlauf oder benutzerdefinierter Event-Verfolgung innerhalb von NetSuite abgeleitet.
Beispiele
Anforderung erstelltGenehmigungsschritt genehmigtPurchase Requisition geändertBestellung erstellt
|
|||
|
Ereigniszeit
EventTime
|
Das genaue Datum und die genaue Uhrzeit, zu der den Antrag bearbeitet.ie Aktivität stattgefunden hat. | ||
|
Beschreibung
Die Event Time, oder den Antrag bearbeitet.er Zeitstempel, erfasst den genauen Zeitpunkt, zu dem eine Aktivität stattfand. Diese temporalen Daten sind wichtig für das Verständnis der Dynamik des Purchase Requisitionsprozesses, einschließlich seiner Dauer, der Abfolge von Ereignisse und des Timings. In der Prozessanalyse werden Time Stamps verwendet, um Durchlaufzeiten, 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 'Purchase Requisitions-Genehmigungszykluszeit' und KPIs wie 'Durchschnittliche Purchase Requisitions-Zykluszeit'. Genaue Zeitstempels sind wichtig für ein leistungsstarkes Prozessmodell.
Bedeutung
Dieser Zeitstempel ist die Grundlage für alle leistungsbezogenen Analysen, wie die Berechnung von Durchlaufzeiten, die Identifizierung von Verzögerungen und die Messung der Prozesseffizienz.
Datenquelle
Diese Informationen werden in systemgenerierten Feldern wie „Date Created“ oder in den Zeitstempels 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
|
|||
|
Purchase Requisitions-ID
PurchaseRequisitionId
|
Die eindeutige Kennung für jede Purchase Requisition, die als primäre Case-ID für die Prozessanalyse dient. | ||
|
Beschreibung
Die Purchase Requisitions-ID (Purchase Requisition ID) ist die zentrale Kennung, die alle Aktivitäten und Ereignisse im Zusammenhang mit einer spezifischen Anfrage für Waren oder Dienstleistungen verknüpft. Jeder Purchase Requisition wird bei der Erstellung in NetSuite eine eindeutige ID zugewiesen, die während ihres gesamten Lebenszyklus konstant bleibt. Im Process Mining ist dieses Attribut wichtig für die Case-Korrelation. Es ermöglicht die Rekonstruktion des End-to-End-Prozesses jeder Purchase Requisition, von ihrer ersten Erstellung über alle Genehmigungsschritte, Änderungen und endgültigen Resultate 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 Purchase Requisition zu verfolgen und so Prozessabläufe zu analysierenn und Case-Level-Metriken zu berechnen.
Datenquelle
Dies ist die interne ID oder Transaktionsnummer des Purchase Requisition Datensatzes in NetSuite. Sie ist in der Regel im Feld „tranid“ für die Transaktion zu finden.
Beispiele
PR-001254PR-001255PR-001256
|
|||
|
Abteilung
Department
|
Die Geschäftsabteilung, zu der den Antrag bearbeitet.ie Purchase Requisition oder den Antrag bearbeitet.er Anforderer gehört. | ||
|
Beschreibung
Das Attribut Abteilung (Department) repräsentiert die Organisationseinheit, die mit der Purchase Requisition verbunden ist, was normalerweise die Abteilung des Anforderers ist. Diese Information bietet eine Möglichkeit, den Prozess aus organisatorischer Sicht zu segmentieren und zu analysierenn. Es ist eine Schlüsseldimension für viele Analysen, wie den Vergleich von Genehmigungszykluszeiten über Abteilungen hinweg, das Verständnis von Ausgabenmustern oder den Antrag bearbeitet.ie 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 effektive 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
MarketingITFinanzenOperations
|
|||
|
Anfragender
Requester
|
Der Mitarbeiter, der den Antrag bearbeitet.ie Purchase Requisition erstellt und eingereicht hat. | ||
|
Beschreibung
Der Anforderer (Requester) ist die Person, die den Beschaffungsprozess durch die Erstellung der Purchase Requisition initiiert. Dies ist in der Regel ein Mitarbeiter, der spezifische Waren oder Dienstleistungen zur Erfüllung seiner Aufgaben benötigt. Die Analyse von Daten nach Anforderer ist wichtig, um Muster im Benutzerverhalten zu identifizieren. Sie hilft beim Aufbau von Dashboards wie „Requester Leistungsfähigkeit and Schulungsbedarf“, indem sie Personen mit hohen Ablehnungsraten oder häufigen Änderungen hervorhebt. Dies zeigt auf, wo zusätzliche Schulungen oder klarere Richtlinien die Qualität der Ersterstellung und die gesamte Prozesseffizienz verbessern könnten.
Bedeutung
Identifiziert den Prozessinitiator, was wichtig ist für die Analyse des Benutzerverhaltens, der Ablehnungsraten pro Anforderer und die Identifizierung von Schulungsbedarf.
Datenquelle
Dies ist in der Regel das Feld „Employee“ oder „Created By“ im Purchase Requisition TransaktionsDatensatz.
Beispiele
John SmithJane DoePeter Jones
|
|||
|
Gesamtbetrag
TotalAmount
|
Der Gesamtbetrag der Purchase Requisition. | ||
|
Beschreibung
Dieses Attribut erfasst die Gesamtkosten aller auf der Purchase Requisition 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 Purchase Requisitionen nach Wert, die Korrelation von Prozessabweichungen mit hochwertigen Anfragen und die Priorisierung der Analyse auf finanziell bedeutsame Fälle. Es ist ein wesentliches 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
|
|||
|
Purchase Requisitionsstatus
RequisitionStatus
|
Zeigt den aktuellen Status der Purchase Requisition in ihrem Lebenszyklus an. | ||
|
Beschreibung
Der Purchase Requisitionsstatus (Requisition Status) bietet einen Überblick darüber, wo sich eine Purchase Requisition zu einem bestimmten Zeitpunkt in ihrem Prozess befindet. Gängige Status sind „Pending Approval“, „Fully Approved“, „Rejected“ und „Closed“. Dieses Attribut ist maßgeblich für die Erstellung von Dashboards wie „Requisition Status and Aging“, das aktive Purchase Requisitionen 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 Purchase Requisitionen sowie die Identifizierung, wo Fälle stecken bleiben.
Datenquelle
Dies ist das Feld „Status“ oder „Approval Status“ im Purchase Requisition Transaktionskopf.
Beispiele
Genehmigung ausstehende Zahlungen identifizieren.endVollständig genehmigtAbgelehntGeschlossen
|
|||
|
Ablehnungsgrund
RejectionReason
|
Die Begründung eines Genehmigers, wenn eine Purchase Requisition abgelehnt wird. | ||
|
Beschreibung
Der Ablehnungsgrund (Rejection Reason) ist ein Textattribut, in dem ein Genehmiger angeben kann, warum eine Purchase Requisition die Genehmigungsanforderungen nicht erfüllt hat. Dies liefert qualitativen Kontext zur Aktivität „Approval Step Rejected“. Diese Information ist von besonders wertvoll 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 Purchase Requisition angefragt werden. | ||
|
Beschreibung
Die Artikelkategorie (Item Category) klassifiziert die Artikel einer Purchase Requisition in logische Gruppen wie „IT Hardware“, „Bürobedarf“ oder „Professionelle Dienstleistungen“. Dies kann aus den ArtikelDatensätzen abgeleitet werden, die mit den Purchase Requisitionspositionen verknüpft sind. Dieses Attribut ermöglicht eine tiefere, detailliertere Analyse des Purchase Requisitionsprozesses. Es hilft, Fragen zu beantworten wie: „Dauert die Genehmigung von Purchase Requisitionen 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 analysierenn 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-Verstöße 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ürobedarfMarketing-Dienstleistungen
|
|||
|
Bestell-ID
PurchaseOrderId
|
Die Kennung der Bestellung, die aus der genehmigten Purchase Requisition erstellt wurde. | ||
|
Beschreibung
Die Bestell-ID (Purchase Order ID) ist die eindeutige Kennung für die Bestellung, die Hinweislge einer genehmigten Purchase Requisition generiert wird. Dieses Attribut dient als wichtige Verbindung zwischen dem Purchase Requisitionsprozess und den nachfolgenden Beschaffungsaktivitäten. In der Prozessanalyse ist diese Verknüpfung für die End-to-End-P2P-Analyse von wichtiger Bedeutung. Sie ermöglicht die Berechnung des KPI „PO Creation Lead Time“, indem die Zeit zwischen der Genehmigung der Purchase Requisition und der PO-Erstellung gemessen wird. Sie hilft auch bei der Berechnung der „Requisition-to-PO Conversion Rate“ und liefert Einblicke, wie effektiv Purchase Requisitionen in direkt anwendbare Bestellungen umgewandelt werden.
Bedeutung
Verknüpft die Purchase Requisition 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 Purchase Requisition, wie Standard oder Dringend. | ||
|
Beschreibung
Die Dringlichkeitsstufe ist ein Kategorisierungs-Attribut, das die geschäftliche Priorität einer Purchase Requisition 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 Purchase Requisitionen' zu unterstützen. Durch das Filtern der ProzessDaten basierend auf diesem Attribut können Analysten die Durchlaufzeiten und Prozesspfade dringender Anfragen im Vergleich zu Standardanfragen vergleichen, um festzustellen, ob die Prioritätsbehandlung effektiv ist oder ob Engpässe 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 in der Regel ein benutzerdefiniertes Transaktionshauptfeld auf dem Purchase Requisitionsformular.
Beispiele
HochMittelNiedrig
|
|||
|
Durchlaufzeit
CycleTime
|
Die gesamte verstrichene Zeit von der Erstellung bis zur endgültigen Lösung einer Purchase Requisition. | ||
|
Beschreibung
Die Zykluszeit ist eine berechnete Metrik, die die Gesamtdauer des Purchase Requisitionsprozesses für einen einzelnen Case misst. Sie wird in der Regel als Zeitdifferenz zwischen der ersten Aktivität (z. B. 'Purchase Requisition erstellt') und der letzten terminalen Aktivität (z. B. 'Purchase Requisition vollständig genehmigt' oder 'Purchase Requisition endgültig abgelehnt') berechnet. Dies ist ein primärer Key Leistungsfähigkeit Indicator für die gesamte Prozesseffizienz. Er wird zur Berechnung des KPIs 'Durchschnittliche Purchase Requisitions-Zykluszeit' verwendet und hilft, Trends, Ausreißer und die Auswirkungen von Prozessoptimierungsinitiativen zu identifizieren. Die Analyse der Zykluszeitverteilung kann Long-Tail-Purchase Requisitionen 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 Zeitstempels des ersten Ereignisse vom Zeitstempel des letzten Ereignisse 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 Purchase Requisition in einer bestimmten Phase des Genehmigungs-Workflows zu prüfen und zu bearbeiten. Es kann mehrere Genehmiger für eine einzelne Purchase Requisition 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 Durchlaufzeit 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 wichtig 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 Purchase Requisition 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 Purchase Requisition 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 Prozesspfade“ und „Approval Workflow Path Compliance“, indem es das Filtern und Gruppieren von Fällen nach ihrem genauen Prozessfluss vereinfacht. 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 Purchase Requisition einen Ablehnungs- und Wiedereinreichungszyklus durchlaufen hat. | ||
|
Beschreibung
Is Rework ist ein abgeleitetes boolesches Attribut, das auf „Ja“ gesetzt wird, wenn eine Purchase Requisition 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 „Ja“ 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
JaNein
|
|||
|
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 Zeitstempel liefert Kontext für die Aktualität der Daten und ermöglicht es den Benutzern zu verstehen, ob sie EchtzeitHinweisrmationen oder eine Momentaufnahme zu einem bestimmten Zeitpunkt betrachten. Er ist wesentlich 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 Prozess-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 Purchase Requisition. | ||
|
Beschreibung
Das Attribut Lieferantenname (Vendor Name) identifiziert den Lieferanten, von dem die Waren oder Dienstleistungen gekauft werden sollen. Während eine Purchase Requisition 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 Purchase Requisitionen 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 vollständige Prozessansicht kombiniert werden. Obwohl es in einer Einzel-System-Analyse statisch erscheinen mag, bietet es wesentlichen Kontext und ist eine Best Practice für Daten 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 wichtigen Kontext über den Datenursprung, um Klarheit und eine ordnungsgemäße Governance zu sicherstellen, 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 Purchase Requisition. | ||
|
Beschreibung
Das Attribut Währung (Currency) spezifiziert die Währung, in der den Antrag bearbeitet.ie Finanzwerte der Purchase Requisition 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 den Antrag bearbeitet.urch Umrechnung aller Beträge in eine einzige Basiswährung oder den Antrag bearbeitet.urch 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 Geldwerte 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 – Purchase Requisitions-Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Anforderung erstellt
|
Ein Benutzer initiiert den Beschaffungsprozess, indem er einen neuen Purchase RequisitionsDatensatz erstellt und speichert. Dies ist das erste Event im Lebenszyklus der Purchase Requisition 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 den Antrag bearbeitet.er anfänglichen Anforderungsformulierung aufdecken.
Datenquelle
Dieses Event wird vom Erstellungsdatum-Zeitstempel des Purchase Requisition TransaktionsDatensatzes erfasst. Es kann im Hauptkopf des Datensatzes oder im Subtab „System Notes“ gefunden werden, der den Antrag bearbeitet.ie Aktion „Create“ protokolliert.
Erfassen
Verwenden Sie das Feld 'Erstellungsdatum' im Purchase RequisitionsDatensatz.
Ereignistyp
explicit
|
|||
|
Bestellung erstellt
|
Eine Bestellung (PO) wird aus der vollständig genehmigten Purchase Requisition 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 Purchase Requisition 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 den Antrag bearbeitet.as Feld 'Erstellt aus' der Purchase Requisitions-ID entspricht und verwenden Sie das 'Erstellungsdatum' der Bestellung.
Ereignistyp
explicit
|
|||
|
Purchase Requisition abgeschlossen
|
Die Purchase Requisition wird formal geschlossen, was darauf hindeutet, dass keine weiteren Maßnahmen erwartet werden. Dies geschieht oft automatisch, nachdem alle Mengen der Purchase Requisition über verknüpfte Bestellungen bestellt wurden. | ||
|
Bedeutung
Diese Aktivität markiert das definitive Ende des Lebenszyklus der Purchase Requisition. Sie bestätigt, dass der geschäftliche Bedarf gedeckt wurde und der Datensatz finalisiert ist.
Datenquelle
Abgeleitet aus dem Subtab „System Notes“, indem der Zeitstempel identifiziert wird, zu dem das Statusfeld auf Positions- oder Kopfebene auf „Closed“ aktualisiert wird.
Erfassen
Zeitstempel der Statusänderung des 'Statusfeldes' auf 'Geschlossen'.
Ereignistyp
inferred
|
|||
|
Purchase Requisition endgültig abgelehnt
|
Die Purchase Requisition wird endgültig abgelehnt und nicht weiter bearbeitet. Dieses Event wird abgeleitet, wenn der endgültige „Approval Status“ der Purchase Requisition auf „Rejected“ aktualisiert wird. | ||
|
Bedeutung
Diese Aktivität ist ein kritischer Endpunkt für erfolglose Purchase Requisitionen. Das Verständnis, warum und wann Purchase Requisitionen endgültig abgelehnt werden, liefert Einblicke in die Richtlinien-Compliance und Budgetprobleme.
Datenquelle
Abgeleitet aus dem Subtab „System Notes“, indem der Zeitstempel identifiziert wird, zu dem das Feld „Approval Status“ auf seinen endgültigen Status „Rejected“ gesetzt wird.
Erfassen
Zeitstempel der Statusänderung des 'Genehmigungsstatus' auf 'Abgelehnt'.
Ereignistyp
inferred
|
|||
|
Purchase Requisition vollständig genehmigt
|
Die Purchase Requisition 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 Purchase Requisition bereit ist, in eine Bestellung umgewandelt zu werden. Es markiert das Ende des Prozesses.kiert das Ende des Genehmigungszyklus und den Beginn der Beschaffungserfüllungsphase.
Datenquelle
Abgeleitet aus dem Subtab „System Notes“, indem der Zeitstempel identifiziert wird, zu dem das Feld „Approval Status“ auf seinen endgültigen Status „Approved“ gesetzt wird.
Erfassen
Zeitstempel der Statusänderung des 'Genehmigungsstatus' auf 'Genehmigt'.
Ereignistyp
inferred
|
|||
|
Genehmigungsschritt abgelehnt
|
Ein Genehmiger lehnt seinen zugewiesenen Schritt ab und sendet die Purchase Requisition in der Regel 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 den Antrag bearbeitet.er Unterregisterkarte Systemnotizen, die die Ablehnungsaktion, den ablehnenden Benutzer und den Zeitstempel 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 Purchase Requisition der endgültigen Genehmigung näher rückt. Die SuiteApprovals-Plattform von NetSuite zeichnet diese Aktion explizit mit Benutzer- und Zeitstempel-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 den Antrag bearbeitet.er Unterregisterkarte Systemnotizen, die die Genehmigungsaktion, den Genehmiger und den genauen Zeitstempel des Ereignisse aufzeichnet.
Erfassen
Genehmigungsaktionen im SuiteApprovals Log oder in den Systemnotizen identifizieren.
Ereignistyp
explicit
|
|||
|
Genehmigungsschritt gestartet
|
Die Purchase Requisition tritt in eine spezifische Phase des Genehmigungs-Workflows ein und wartet auf die Aktion eines benannten Genehmigers oder einer Gruppe. Dies wird in der Regel abgeleitet, wenn der Workflow die Purchase Requisition dem nächsten Genehmiger in der Sequenz zuweist. | ||
|
Bedeutung
Diese Aktivität markiert den Beginn der Wartezeit für jeden einzelnen Genehmigungsschritt. Sie ist wichtig, 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 Antrag bearbeitet.en 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
|
|||
|
Purchase Requisition geändert
|
Ein Benutzer ändert ein beliebiges Feld der Purchase Requisition 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 maßgeblich, um Nacharbeitsschleifen 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 Purchase RequisitionsDatensatzes. 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
|
|||
|
Purchase Requisition zur Genehmigung eingereicht
|
Der Anforderer reicht die ausgefüllte Purchase Requisition formal in den dafür vorgesehenen Genehmigungs-Workflow ein. Dies wird oft aus einer Statusänderung des Purchase Requisitionssatzes abgeleitet, zum Beispiel von „Draft“ oder „Pending Submission“ zu „Pending Approval“. | ||
|
Bedeutung
Diese Aktivität löst den Genehmigungszyklus aus und ist ein wichtiger Startpunkt für die Messung von Genehmigungsdurchlaufzeiten. Sie hilft zu identifizieren, wie lange Purchase Requisitionen warten, bevor der formale Genehmigungsprozess beginnt.
Datenquelle
Abgeleitet aus dem Subtab „System Notes“, indem der Zeitstempel identifiziert wird, zu dem das Feld „Approval Status“ zum ersten Mal einen Wert wie „Pending Approval“ annimmt.
Erfassen
Ersten Zeitstempel identifizieren, an dem das Feld 'Genehmigungsstatus' zu 'Ausstehende Genehmigung' wechselt.
Ereignistyp
inferred
|
|||
|
Purchase Requisition zurückgezogen
|
Der ursprüngliche Anforderer oder ein Administrator storniert die Purchase Requisition, bevor sie vollständig genehmigt oder in eine Bestellung umgewandelt wird. Dies wird in der Regel aus einer Statusänderung zu „Abbrechenled“ 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 Purchase Requisitionen hervorheben.
Datenquelle
Abgeleitet aus dem Subtab „System Notes“, indem der Zeitstempel verfolgt wird, zu dem das Feld „Approval Status“ auf einen Wert wie „Abbrechenled“ oder einen benutzerdefinierten Status „Withdrawn“ aktualisiert wird.
Erfassen
Zeitstempel der Statusänderung des 'Genehmigungsstatus' auf 'Storniert' oder 'Zurückgezogen'.
Ereignistyp
inferred
|
|||