Ihr Daten-Template für Purchase to Pay, Bestellanforderung

NetSuite
Ihr Daten-Template für Purchase to Pay, Bestellanforderung

Ihr Daten-Template für Purchase to Pay, Bestellanforderung

Dieses Template bietet einen klaren Fahrplan für die Erfassung der wesentlichen Datenpunkte, die Sie zur Analyse Ihres Purchase-to-Pay-Prozesses für Bestellanforderungen benötigen. Es beschreibt die relevanten Attribute, legt die wichtigsten zu erfassenden Aktivitäten fest und gibt praktische Hinweise zur Extraktion dieser Informationen aus Ihrem Quellsystem. Verwenden Sie diese Ressource, um Ihr Event Log für aussagekräftiges Process Mining vorzubereiten.
  • Empfohlene zu erfassende Attribute
  • Wichtige Aktivitäten für die Prozesserkennung
  • Hinweise zur Datenextraktion
Neu bei Event Logs? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Purchase to Pay - Requisition: Attribute

Dies sind die empfohlenen Datenfelder, die Sie für eine umfassende Analyse Ihres Purchase-to-Pay-Prozesses für Bedarfsanforderungen in das Event Log aufnehmen sollten.
3 Erforderlich 4 Empfohlen 12 Optional
Name Beschreibung
Aktivitätsname
ActivityName
Der Name eines bestimmten Geschäftsereignisses oder einer Aufgabe, die im Lebenszyklus der Bestellanforderung stattgefunden hat.
Beschreibung

Der Activity Name beschreibt einen einzelnen Schritt im Prozess der Bestellanforderung, etwa „Requisition Created“, „Approval Step Approved“ oder „Purchase Order Created“. Diese Aktivitäten bilden die Grundlage der Prozessübersicht und stellen die ausgeführten Arbeiten dar.

Durch die Analyse dieser Aktivitäten lassen sich Prozessabläufe visualisieren, Bottlenecks identifizieren und die in verschiedenen Phasen verbrachte Zeit messen. Die Abfolge der Aktivitäten für eine bestimmte Purchase Requisition ID definiert ihren Ablauf. Dieser kann anschließend mit Standardverfahren verglichen werden, um Abweichungen oder Ineffizienzen zu erkennen.

Warum das wichtig ist

Es definiert die Prozessschritte und ermöglicht die Visualisierung von Prozessübersichten, die Analyse von Prozessvarianten sowie die Identifizierung von Bottlenecks.

Bezugsquelle

Dies wird typischerweise aus einer Kombination aus Transaktionsstatus, Systemprotokolleinträgen, Workflow-Historie oder benutzerdefinierter Ereignisverfolgung in NetSuite abgeleitet.

Beispiele
Anforderung erstelltGenehmigungsschritt genehmigtAnforderung geändertBestellung erstellt
Ereigniszeit
EventTime
Das genaue Datum und die genaue Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung

Die Ereigniszeit beziehungsweise der Timestamp erfasst den genauen Zeitpunkt, zu dem eine Aktivität stattgefunden hat. Diese zeitbezogenen Daten sind entscheidend, um die Dynamik des Anforderungsprozesses zu verstehen, einschließlich seiner Dauer, der Reihenfolge der Ereignisse und des zeitlichen Ablaufs.

In der Prozessanalyse werden Timestamps 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 Dashboards wie „Durchlaufzeit der Anforderungsfreigabe“ sowie KPIs wie „Durchschnittliche Durchlaufzeit einer Anforderung“. Genaue Timestamps sind entscheidend für ein zuverlässiges Prozessmodell.

Warum das wichtig ist

Dieser Timestamp bildet die Grundlage für alle leistungsbezogenen Analysen, etwa zur Berechnung von Durchlaufzeiten, zur Ermittlung von Verzögerungen und zur Messung der Prozesseffizienz.

Bezugsquelle

Diese Information wird in systemgenerierten Feldern wie „Erstellt am“ oder in den für jede Transaktion verfügbaren Timestamps der System Notes beziehungsweise der Workflow-Ausführungsprotokolle erfasst.

Beispiele
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
ID der Bestellanforderung
PurchaseRequisitionId
Die eindeutige Kennung jeder Bestellanforderung, die als primäre Case ID für die Prozessanalyse dient.
Beschreibung

Die Purchase Requisition ID ist die zentrale Kennung, die alle Aktivitäten und Ereignisse einer bestimmten Anforderung für Waren oder Dienstleistungen miteinander verknüpft. Jede Bestellanforderung erhält bei ihrer Erstellung in NetSuite eine eindeutige ID, die während ihres gesamten Lebenszyklus unverändert bleibt.

Im Process Mining ist dieses Attribut grundlegend für die Zuordnung von Cases. Es ermöglicht die Rekonstruktion des durchgängigen Ablaufs jeder Bestellanforderung, von der erstmaligen Erstellung über alle Genehmigungsschritte und Änderungen bis zu den endgültigen Ergebnissen wie Genehmigung, Ablehnung oder Umwandlung in eine Purchase Order. Die Analyse anhand dieser ID ist entscheidend, um Lebenszyklusdauern zu berechnen, Statusänderungen zu verfolgen und Varianten in Prozessabläufen zu erkennen.

Warum das wichtig ist

Dies ist der zentrale Schlüssel, um den vollständigen Lebenszyklus einer einzelnen Bestellanforderung nachzuverfolgen. Dadurch lassen sich Prozessabläufe analysieren und Kennzahlen auf Case-Ebene berechnen.

Bezugsquelle

Dies ist die interne ID oder Transaktionsnummer des Datensatzes der Purchase Requisition in NetSuite. Sie befindet sich in der Regel im Feld „tranid“ der Transaktion.

Beispiele
PR-001254PR-001255PR-001256
Abteilung
Department
Die Geschäftsabteilung, der die Anforderung oder die anfordernde Person zugeordnet ist.
Beschreibung

Das Attribut „Abteilung“ bezeichnet die Organisationseinheit, die mit der Bestellanforderung verbunden ist. In der Regel handelt es sich um die Abteilung der anfordernden Person. Diese Information ermöglicht es, den Prozess aus organisatorischer Sicht zu segmentieren und zu analysieren.

Sie ist eine wichtige Dimension für zahlreiche Analysen, etwa den Vergleich von Freigabe-Durchlaufzeiten zwischen Abteilungen, die Untersuchung von Ausgabenmustern oder die Ermittlung von Abteilungen mit den höchsten Ablehnungsquoten. Diese Segmentierung unterstützt das Management dabei, Ressourcen zuzuweisen, Schulungen anzupassen und Workflows für bestimmte Geschäftsbereiche zu optimieren.

Warum das wichtig ist

Ermöglicht eine aussagekräftige Segmentierung der Prozessdaten, um Leistung, Kosten und Compliance in verschiedenen Geschäftsbereichen zu vergleichen.

Bezugsquelle

Diese Information ist häufig mit dem Mitarbeiterdatensatz der anfordernden Person verknüpft oder kann direkt in der Transaktionskopfzeile der Purchase Requisition festgelegt werden.

Beispiele
MarketingITFinanzenBetrieb
Anfordernde Person
Requester
Die Person, die die Bestellanforderung erstellt und eingereicht hat.
Beschreibung

Die anfordernde Person initiiert den Beschaffungsprozess, indem sie die Anforderung erstellt. Dabei handelt es sich typischerweise um eine beschäftigte Person, die bestimmte Waren oder Dienstleistungen für ihre Arbeit benötigt.

Die Analyse nach anfordernder Person ist entscheidend, um Muster im Nutzerverhalten zu erkennen. Sie unterstützt Dashboards wie „Leistung und Schulungsbedarf anfordernder Personen“, indem Personen mit hohen Ablehnungsquoten oder häufigen Änderungen sichtbar werden. Diese Erkenntnis kann zeigen, wo zusätzliche Schulungen oder klarere Richtlinien die Qualität bei der ersten Einreichung und die Effizienz des Gesamtprozesses verbessern.

Warum das wichtig ist

Identifiziert die initiierende Person und ist damit entscheidend für die Analyse des Nutzerverhaltens, der Ablehnungsquoten nach anfordernder Person und des Schulungsbedarfs.

Bezugsquelle

Dies ist typischerweise das Feld „Employee“ oder „Created By“ im Transaktionsdatensatz der Purchase Requisition.

Beispiele
John SmithJane DoePeter Jones
Gesamtbetrag
TotalAmount
Der gesamte Geldwert der Bestellanforderung.
Beschreibung

Dieses Attribut erfasst die Gesamtkosten aller in der Bestellanforderung aufgeführten Positionen. Es ist ein wichtiger Finanzdatenpunkt, der den Prozess häufig beeinflusst, etwa indem abhängig von Wertgrenzen unterschiedliche Freigabe-Workflows ausgelöst werden.

Die Analyse des Gesamtbetrags hilft, Ausgabenmuster und finanzielle Auswirkungen zu verstehen. Sie ermöglicht es, Anforderungen nach Wert zu filtern, Prozessabweichungen mit Anfragen hohen Werts in Beziehung zu setzen und die Analyse auf finanziell relevante Cases zu konzentrieren. Für jede finanz- oder compliancebezogene Prozessanalyse ist dieses Attribut grundlegend.

Warum das wichtig ist

Liefert den finanziellen Kontext und ermöglicht eine wertbasierte Analyse, da der Wert häufig den Freigabepfad und die geschäftliche Priorität bestimmt.

Bezugsquelle

Dies ist ein Standardfeld im Datensatz der Purchase Requisition, häufig mit der Bezeichnung „Total“ oder einer ähnlichen Variante.

Beispiele
500.001250.7525000.00
Status der Anforderung
RequisitionStatus
Gibt den aktuellen Status der Anforderung in ihrem Lebenszyklus an.
Beschreibung

Der Status der Anforderung zeigt zu jedem Zeitpunkt, an welcher Stelle des Prozesses sich eine Bestellanforderung befindet. Häufige Statuswerte sind „Pending Approval“, „Fully Approved“, „Rejected“ und „Closed“.

Dieses Attribut ist entscheidend für Dashboards wie „Status und Alter der Anforderungen“. Sie verfolgen aktive Anforderungen und zeigen, wie lange diese bereits in ihrem aktuellen Status verbleiben. Die Analyse von Statusübergängen ist ein wichtiger Bestandteil der Prozesserkennung. Sie hilft, sowohl die regulären Abläufe als auch Ausnahmen zu verstehen. Außerdem wird der Status verwendet, um das Endergebnis eines Cases zu bestimmen.

Warum das wichtig ist

Liefert eine Momentaufnahme des Fortschritts eines Cases und ermöglicht die Analyse überfälliger Anforderungen sowie die Ermittlung von Stellen, an denen Cases stecken bleiben.

Bezugsquelle

Dies ist das Feld „Status“ oder „Approval Status“ in der Transaktionskopfzeile der Purchase Requisition.

Beispiele
Genehmigung ausstehendVollständig genehmigtAbgelehntGeschlossen
Ablehnungsgrund
RejectionReason
Die Erklärung, die eine genehmigende Person bei der Ablehnung einer Anforderung angibt.
Beschreibung

Der Ablehnungsgrund ist ein Textattribut, in dem eine genehmigende Person angeben kann, warum eine Bestellanforderung die Voraussetzungen für eine Genehmigung nicht erfüllt hat. Er liefert qualitativen Kontext zur Aktivität „Approval Step Rejected“.

Diese Information ist für die Ursachenanalyse besonders wertvoll. Sie unterstützt Dashboards wie „Analyse der Ablehnungsquote von Anforderungen“, die nicht nur zeigen, was abgelehnt wurde, sondern auch warum. Häufige Gründe können „Falsches Sachkonto“, „Budget überschritten“ oder „Unzureichende Angaben“ sein. Die Analyse dieser Gründe hilft, systematische Probleme zu erkennen, Schulungen zu verbessern und Richtlinien für Einreichungen zu präzisieren, um Nacharbeit und Ablehnungsquoten zu reduzieren.

Warum das wichtig ist

Liefert entscheidenden Kontext zu den Ursachen von Ablehnungen und ermöglicht eine Ursachenanalyse, um künftige Ablehnungen zu reduzieren und die Qualität bei der ersten Einreichung zu verbessern.

Bezugsquelle

Dies wird häufig während der Ablehnungsaktion in einem Feld „Memo“ oder in einem benutzerdefinierten Feld des Freigabe-Workflows erfasst. Die Information kann auch in den System Notes zu finden sein.

Beispiele
Budget überschrittenFalscher Lieferant ausgewähltFehlende ArtikeldetailsDoppelte Anforderung
Artikelkategorie
ItemCategory
Die Kategorie der Waren oder Dienstleistungen, die mit der Anforderung angefragt werden.
Beschreibung

Die Artikelkategorie ordnet die Positionen einer Bestellanforderung logischen Gruppen wie „IT-Hardware“, „Bürobedarf“ oder „Professionelle Dienstleistungen“ zu. Sie kann aus den mit den Anforderungspositionen verknüpften Artikeldatensätzen abgeleitet werden.

Dieses Attribut ermöglicht eine detailliertere Analyse des Anforderungsprozesses. Es hilft bei Fragen wie: „Werden Anforderungen für IT-Hardware langsamer genehmigt als Anforderungen für Bürobedarf?“ Durch die Segmentierung nach Artikelkategorie können Unternehmen kategoriespezifische Engpässe erkennen, Ausgaben nach Kategorie analysieren und ihre Beschaffungsstrategien entsprechend ausrichten.

Warum das wichtig ist

Ermöglicht die Analyse des Prozesses auf Grundlage der beschafften Waren oder Dienstleistungen und hilft, kategoriespezifische Engpässe oder Compliance-Probleme zu erkennen.

Bezugsquelle

Diese Information wird aus den „Item“-Datensätzen abgeleitet, die auf Positionsebene mit der Purchase Requisition verknüpft sind. Die Kategorie selbst kann ein Standardfeld oder ein benutzerdefiniertes Feld im Item-Datensatz sein.

Beispiele
IT-HardwareSoftwarelizenzenBürobedarfMarketingdienstleistungen
Bestellnummer
PurchaseOrderId
Die Kennung der Bestellung, die aus der genehmigten Anforderung erstellt wurde.
Beschreibung

Die Bestellnummer ist die eindeutige Kennung der Bestellung, die aufgrund einer genehmigten Anforderung erzeugt wurde. Dieses Attribut bildet eine wichtige Verbindung zwischen dem Anforderungsprozess und den anschließenden Beschaffungsaktivitäten.

Für die End-to-End-P2P-Analyse ist diese Verbindung entscheidend. Sie ermöglicht die Berechnung des KPI „Vorlaufzeit bis zur Erstellung der Bestellung“, indem die Zeit zwischen der Genehmigung der Anforderung und der Erstellung der Bestellung gemessen wird. Außerdem unterstützt sie die Berechnung der „Umwandlungsrate von Anforderung zu Bestellung“ und liefert Erkenntnisse darüber, wie effektiv Anforderungen in umsetzbare Bestellungen überführt werden.

Warum das wichtig ist

Verknüpft die Anforderung mit der daraus entstandenen Bestellung und ermöglicht die Messung der Vorlaufzeit bis zur Erstellung der Bestellung sowie eine End-to-End-Prozessanalyse.

Bezugsquelle

Dies ist im Datensatz der Purchase Requisition zu finden, häufig in einem Unterregister für verknüpfte Datensätze oder über einen Link „Created From“ direkt in der Bestellung.

Beispiele
PO-005432PO-005433PO-005434
Dringlichkeitsstufe
UrgencyLevel
Eine Klassifizierung der Priorität einer Anforderung, etwa „Standard“ oder „Dringend“.
Beschreibung

Die Dringlichkeitsstufe ist ein kategoriales Attribut, das die geschäftliche Priorität einer Bestellanforderung angibt. So können Beschäftigte Anfragen kennzeichnen, die aufgrund kritischer geschäftlicher Anforderungen bevorzugt bearbeitet werden müssen.

Dieses Attribut unterstützt speziell das Dashboard „Leistung bei der Bearbeitung dringender Anfragen“ und den KPI „Bearbeitungszeit dringender Anforderungen“. Durch die Filterung der Prozessdaten nach diesem Attribut können Analysten die Durchlaufzeiten und Prozesspfade dringender und standardmäßiger Anfragen vergleichen. So lässt sich feststellen, ob die priorisierte Bearbeitung wirksam ist oder Engpässe weiterhin zu Verzögerungen führen.

Warum das wichtig ist

Ermöglicht den Vergleich der Prozessleistung bei Anfragen mit hoher und standardmäßiger Priorität und stellt sicher, dass kritische Anforderungen effizient erfüllt werden.

Bezugsquelle

Dies wäre typischerweise ein benutzerdefiniertes Transaktionskopffeld im Formular der Purchase Requisition.

Beispiele
HochMittelNiedrig
Durchlaufzeit
CycleTime
Die gesamte verstrichene Zeit von der Erstellung bis zur abschließenden Bearbeitung einer Anforderung.
Beschreibung

Die Durchlaufzeit ist eine berechnete Kennzahl, die die Gesamtdauer des Prozesses einer einzelnen Bestellanforderung misst. Sie wird typischerweise als Zeitdifferenz zwischen der ersten Aktivität, etwa „Requisition Created“, und der letzten abschließenden Aktivität, etwa „Requisition Fully Approved“ oder „Requisition Finally Rejected“, berechnet.

Sie ist ein zentraler KPI für die Effizienz des Gesamtprozesses. Die Durchlaufzeit wird zur Berechnung des KPI „Durchschnittliche Durchlaufzeit einer Anforderung“ verwendet und hilft, Trends, Ausreißer sowie die Auswirkungen von Prozessverbesserungen zu erkennen. Die Analyse der Verteilung der Durchlaufzeiten kann Anforderungen mit besonders langen Bearbeitungszeiten sichtbar machen, die den Durchschnitt deutlich verschlechtern.

Warum das wichtig ist

Misst die End-to-End-Effizienz des Prozesses direkt und ist damit eine zentrale Kennzahl zur Ermittlung von Verzögerungen und Bewertung der Gesamtleistung.

Bezugsquelle

Dies ist ein berechnetes Attribut, das entsteht, indem für jede „PurchaseRequisitionId“ der Timestamp des ersten Ereignisses vom Timestamp des letzten Ereignisses subtrahiert wird.

Beispiele
25920060480086400
Genehmigende Person
Approver
Die Person oder der Nutzer, die beziehungsweise der für die Genehmigung oder Ablehnung eines Freigabeschritts verantwortlich ist.
Beschreibung

Die genehmigende Person ist für die Prüfung und Bearbeitung einer Bestellanforderung in einer bestimmten Phase des Freigabe-Workflows zuständig. Für eine einzelne Anforderung kann es mehrere genehmigende Personen geben, die jeweils einer anderen Freigabeaktivität zugeordnet sind.

Dieses Attribut ist entscheidend für die Analyse des Freigabeprozesses selbst. Es unterstützt Dashboards wie „Verteilung der Durchlaufzeiten von Freigabeschritten“, mit denen sich individuelle oder gruppenbezogene Engpässe erkennen lassen. Durch die Nachverfolgung der genehmigenden Personen können Organisationen Verantwortlichkeiten sicherstellen, Arbeitslasten ausgleichen und Verzögerungen durch bestimmte genehmigende Personen identifizieren.

Warum das wichtig ist

Identifiziert die Person, die Freigabeaufgaben ausführt, und ist damit entscheidend für die Analyse von Leistung und Arbeitslast der genehmigenden Personen sowie für die Ermittlung von Engpässen.

Bezugsquelle

Diese Information findet sich häufig im Workflow-Ausführungsprotokoll oder in den System Notes, die mit Änderungen des Freigabestatus verknüpft sind. Sie kann auch in benutzerdefinierten Datensatzfeldern zum Freigabe-Workflow gespeichert sein.

Beispiele
Sarah JenkinsDavid ChenGenehmigungsgruppe der Finanzabteilung
Ist Nacharbeit
IsRework
Ein boolesches Kennzeichen, das angibt, ob die Anforderung einen Zyklus aus Ablehnung und erneuter Einreichung durchlaufen hat.
Beschreibung

„Ist Nacharbeit“ ist ein abgeleitetes boolesches Attribut. Es wird auf „true“ gesetzt, wenn eine Bestellanforderung zu irgendeinem Zeitpunkt abgelehnt und anschließend geändert oder erneut zur Genehmigung eingereicht wurde. Es identifiziert Cases, die über den regulären „Happy Path“ hinaus zusätzlichen Bearbeitungsaufwand erforderten.

Dieses Attribut vereinfacht die Analyse von Prozessineffizienzen. Es wird zur Berechnung des KPI „Anzahl der Ablehnungszyklen bei Freigaben“ verwendet und hilft, die Auswirkungen von Ablehnungen auf den Gesamtprozess zu quantifizieren. Durch die Filterung auf Cases mit dem Wert „Ist Nacharbeit“ = „true“ können Analysten problematische Prozessvarianten isolieren und die Ursachen der ursprünglichen Ablehnungen untersuchen, etwa eine unzureichende Datenqualität oder ein falsches Verständnis von Richtlinien.

Warum das wichtig ist

Hilft, Häufigkeit und Auswirkungen von Nacharbeitsschleifen zu quantifizieren, die eine wesentliche Ursache für Ineffizienz und Verzögerungen im Prozess sind.

Bezugsquelle

Dies ist ein berechnetes Attribut. Die Logik prüft, ob für denselben Case nach der Aktivität „Requisition Submitted for Approval“ eine Aktivität „Approval Step Rejected“ auftritt.

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

Dieses Attribut erfasst das Datum und die Uhrzeit des letzten Datenabrufs aus NetSuite. Es ist ein wichtiger Bestandteil der Metadaten jedes Process-Mining-Dashboards und jeder Process-Mining-Analyse.

Dieser Timestamp liefert Kontext zur Aktualität der Daten. So können Sie erkennen, ob Sie Echtzeitinformationen oder eine Momentaufnahme zu einem bestimmten Zeitpunkt betrachten. Er ist entscheidend für die Datenvalidierung und dafür, Stakeholder über die Aktualität der aus der Prozessanalyse gewonnenen Erkenntnisse zu informieren.

Warum das wichtig ist

Informiert über die Aktualität der Daten und stellt sicher, dass klar ist, wie aktuell die Erkenntnisse zum Prozess sind.

Bezugsquelle

Dieser Timestamp wird während des Prozesses zur Datenextraktion, -transformation und -ladung (ETL) erzeugt und ergänzt.

Beispiele
2024-05-21T08:00:00Z2024-05-20T08:00:00Z
Lieferantenname
VendorName
Der Name des vorgeschlagenen oder bevorzugten Lieferanten für die Anforderung.
Beschreibung

Das Attribut „Lieferantenname“ identifiziert den Lieferanten, bei dem die Waren oder Dienstleistungen voraussichtlich beschafft werden. Obwohl eine Anforderung ein internes Dokument ist, wird häufig ein bevorzugter Lieferant angegeben.

Die Analyse dieses Attributs kann Muster im Lieferantenmanagement sichtbar machen. Sie zeigt, welche Lieferanten am häufigsten angefragt werden, ob Anforderungen für bestimmte Lieferanten längere Freigabezeiten haben und ob Vereinbarungen mit bevorzugten Lieferanten eingehalten werden. Diese Information kann als wertvolle Grundlage für strategische Beschaffung und Lieferantenmanagement dienen.

Warum das wichtig ist

Unterstützt die Analyse von Beschaffungsmustern nach Lieferant, die Einhaltung von Listen bevorzugter Lieferanten und die Ermittlung lieferantenspezifischer Prozessabweichungen.

Bezugsquelle

Dies kann ein Feld „Vendor“ auf Kopfebene sein oder auf Positionsebene im Datensatz der Purchase Requisition angegeben werden.

Beispiele
Dell Inc.StaplesMcKinsey & Company
Pfad des Freigabe-Workflows
ApprovalWorkflowPath
Eine Darstellung der Reihenfolge der Freigabeschritte, die eine Anforderung durchlaufen hat.
Beschreibung

Der Pfad des Freigabe-Workflows ist ein abgeleitetes Attribut, das die Abfolge der Freigabeaktivitäten oder Statuswerte einer bestimmten Anforderung zusammenfasst, etwa „Submitted -> Manager Approval -> Finance Approval“. Dadurch entsteht eine eindeutige Signatur für den Pfad, den jeder Case durchlaufen hat.

Dieses Attribut bildet die Grundlage für Conformance Checking und Variantenanalyse. Es unterstützt direkt die Dashboards „Nicht konforme Pfade von Anforderungen“ und „Compliance des Freigabe-Workflow-Pfads“, da Cases einfach nach ihrem exakten Prozessablauf gefiltert und gruppiert werden können. Durch den Vergleich der tatsächlichen Pfade mit vordefinierten Standardpfaden können Organisationen die Compliance quantifizieren und die Ursachen von Abweichungen untersuchen.

Warum das wichtig ist

Ermöglicht eine aussagekräftige Variantenanalyse und ein Conformance Checking, indem die genaue Reihenfolge der Freigabeschritte für jeden Case zusammengefasst wird.

Bezugsquelle

Dies ist ein abgeleitetes Attribut, das berechnet wird, indem die Werte von „ActivityName“ für jede „PurchaseRequisitionId“ in chronologischer Reihenfolge zusammengeführt werden.

Beispiele
Erstellt > Eingereicht > GenehmigtErstellt > Eingereicht > Abgelehnt > Geändert > Eingereicht > GenehmigtErstellt > Eingereicht > Genehmigt > Zurückgezogen
Quellsystem
SourceSystem
Identifiziert das Quellsystem, aus dem die Daten extrahiert wurden.
Beschreibung

Dieses Attribut gibt das Ursprungssystem der Prozessdaten an, in diesem Fall NetSuite. Es ist besonders nützlich in Umgebungen, in denen Daten aus mehreren Systemen für eine umfassende Prozesssicht zusammengeführt werden.

Bei einer Analyse mit nur einem System mag der Wert statisch erscheinen. Dennoch liefert er wichtigen Kontext und gilt als bewährte Praxis für Data Governance und Nachvollziehbarkeit. Er hilft, den Ursprung der Daten zu bestätigen und sicherzustellen, dass systemspezifische Logik oder Transformationen während der Analyse korrekt verstanden werden.

Warum das wichtig ist

Liefert wichtigen Kontext zum Ursprung der Daten und sorgt insbesondere in Umgebungen mit mehreren Systemen für Klarheit und eine angemessene Governance.

Bezugsquelle

Dies ist der statische Wert „NetSuite“, der während der Datenextraktion und -transformation ergänzt werden sollte.

Beispiele
NetSuiteNetSuite SuitePeopleNetSuite ERP
Währung
Currency
Der Währungscode für den Gesamtbetrag der Anforderung.
Beschreibung

Das Attribut „Währung“ gibt an, auf welche Währung sich die finanziellen Werte der Anforderung beziehen, etwa USD, EUR oder GBP. Dies ist besonders für multinationale Organisationen wichtig, die mit mehreren Währungen arbeiten.

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 die Umrechnung aller Beträge in eine einheitliche Basiswährung oder durch eine nach Währung segmentierte Analyse. So werden fehlerhafte Finanzberichte vermieden und Klarheit in globalen Abläufen geschaffen.

Warum das wichtig ist

Für eine präzise Finanzanalyse in multinationalen Organisationen unverzichtbar, damit Geldwerte korrekt interpretiert und aggregiert werden.

Bezugsquelle

Dies ist ein Standardfeld „Currency“ im Transaktionsdatensatz der Purchase Requisition, insbesondere in NetSuite-Instanzen mit mehreren Währungen.

Beispiele
USDEURGBP
Erforderlich Empfohlen Optional

Purchase to Pay - Requisition: Aktivitäten

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie für eine präzise Prozesserkennung und Engpassidentifizierung im Event Log erfassen sollten.
5 Empfohlen 6 Optional
Aktivität Beschreibung
Anforderung endgültig abgelehnt
Die Bestellanforderung wird endgültig abgelehnt und nicht weiterbearbeitet. Dieses Ereignis wird daraus abgeleitet, dass der endgültige „Approval Status“ der Bestellanforderung auf „Rejected“ aktualisiert wird.
Warum das wichtig ist

Diese Aktivität markiert einen kritischen Endpunkt für nicht erfolgreiche Bestellanforderungen. Wenn Sie verstehen, warum und wann Bestellanforderungen endgültig abgelehnt werden, gewinnen Sie Erkenntnisse über Compliance mit Richtlinien und Budgetprobleme.

Bezugsquelle

Leiten Sie das Ereignis aus dem Subtab „System Notes“ ab, indem Sie den Timestamp identifizieren, an dem das Feld „Approval Status“ auf den endgültigen Status „Rejected“ gesetzt wird.

Erfassen

Timestamp der Änderung von „Approval Status“ zu „Rejected“.

Ereignistyp inferred
Anforderung erstellt
Ein User startet den Beschaffungsprozess, indem er einen neuen Datensatz für eine Bestellanforderung erstellt und speichert. Dies ist das erste Ereignis im Lebenszyklus der Bestellanforderung und wird erfasst, sobald der Transaktionsdatensatz erstmals in NetSuite gespeichert wird.
Warum das wichtig ist

Diese Aktivität markiert den offiziellen Beginn des Beschaffungsprozesses für einen konkreten Bedarf. Die Analyse der Zeit von der Erstellung bis zur Einreichung kann Verzögerungen bei der Dateneingabe oder der Formulierung der ursprünglichen Anforderung sichtbar machen.

Bezugsquelle

Dieses Ereignis wird anhand des Erstellungsdatums und -zeitpunkts des Transaktionsdatensatzes der Purchase Requisition erfasst. Sie finden ihn im Hauptkopf des Datensatzes oder im Subtab „System Notes“, in dem die Aktion „Create“ protokolliert wird.

Erfassen

Verwenden Sie das Feld „Date Created“ im Datensatz der Purchase Requisition.

Ereignistyp explicit
Anforderung geschlossen
Die Bestellanforderung wird formell geschlossen. Damit wird angezeigt, dass keine weiteren Aktionen erwartet werden. Dies geschieht häufig automatisch, nachdem alle Mengen der Bestellanforderung über verknüpfte Purchase Orders bestellt wurden.
Warum das wichtig ist

Diese Aktivität markiert das endgültige Ende des Lebenszyklus der Bestellanforderung. Sie bestätigt, dass der Geschäftsbedarf erfüllt und der Datensatz abgeschlossen ist.

Bezugsquelle

Leiten Sie das Ereignis aus dem Subtab „System Notes“ ab, indem Sie den Timestamp identifizieren, an dem das feld- oder kopfbezogene Feld „Status“ auf „Closed“ aktualisiert wird.

Erfassen

Timestamp der Änderung des Felds „Status“ zu „Closed“.

Ereignistyp inferred
Anforderung vollständig genehmigt
Die Bestellanforderung durchläuft erfolgreich alle erforderlichen Schritte des Genehmigungs-Workflows. Dies wird daraus abgeleitet, dass sich der endgültige „Approval Status“ des Datensatzes in „Approved“ ändert.
Warum das wichtig ist

Dies ist ein wichtiger Meilenstein. Er zeigt an, dass die Bestellanforderung in eine Purchase Order umgewandelt werden kann. Damit endet der Genehmigungszyklus und die Erfüllungsphase der Beschaffung beginnt.

Bezugsquelle

Leiten Sie das Ereignis aus dem Subtab „System Notes“ ab, indem Sie den Timestamp identifizieren, an dem das Feld „Approval Status“ auf den endgültigen Status „Approved“ gesetzt wird.

Erfassen

Timestamp der Änderung von „Approval Status“ zu „Approved“.

Ereignistyp inferred
Bestellung erstellt
Aus der vollständig genehmigten Bestellanforderung wird eine Purchase Order erstellt, wodurch Mittel offiziell einem Lieferanten zugesagt werden. Dies ist ein explizites Ereignis, das durch die Erstellung einer neuen Purchase-Order-Transaktion mit Verknüpfung zur ursprünglichen Bestellanforderung gekennzeichnet ist.
Warum das wichtig ist

Dies ist das zentrale Ergebnis einer erfolgreichen Bestellanforderung und eine wichtige Übergabe im Purchase-to-Pay-Prozess. Die Zeit zwischen Genehmigung und Erstellung der Purchase Order ist eine entscheidende KPI für die Effizienz der Beschaffung.

Bezugsquelle

Identifizieren Sie einen Purchase-Order-Datensatz, dessen Feld „Created From“ oder ein vergleichbares Verknüpfungsfeld auf die Purchase Requisition ID verweist. Das Erstellungsdatum dieser Purchase Order ist der Timestamp für diese Aktivität.

Erfassen

Suchen Sie die Purchase Order, bei der das Feld „Created From“ der Requisition ID entspricht, und verwenden Sie „Date Created“ der Purchase Order.

Ereignistyp explicit
Anforderung geändert
Ein User ändert nach der erstmaligen Erstellung ein beliebiges Feld der Bestellanforderung, häufig aufgrund einer Ablehnung oder geänderter Anforderungen. Dieses Ereignis wird direkt aus der Audit-Trail-Funktion von NetSuite erfasst.
Warum das wichtig ist

Die Nachverfolgung von Änderungen ist entscheidend, um Nacharbeitschleifen und Probleme bei der Datenqualität zu erkennen. Eine hohe Änderungsfrequenz kann auf unklare ursprüngliche Anforderungen oder Schulungsbedarf bei Anforderern hinweisen.

Bezugsquelle

Das Ereignis wird im Subtab „System Notes“ des Datensatzes der Purchase Requisition erfasst. Jeder Eintrag mit dem „Type“ „Change“ oder „Edit“ für ein relevantes Feld stellt eine Änderung dar.

Erfassen

Pro Eintrag des Typs „Change“ im Protokoll „System Notes“ ein Ereignis erfassen.

Ereignistyp explicit
Anforderung zur Genehmigung eingereicht
Der Anforderer reicht die ausgefüllte Bestellanforderung formell in den vorgesehenen Genehmigungs-Workflow ein. Dies lässt sich häufig aus einer Statusänderung im Datensatz der Bestellanforderung ableiten, zum Beispiel von „Draft“ oder „Pending Submission“ zu „Pending Approval“.
Warum das wichtig ist

Diese Aktivität startet den Genehmigungszyklus und ist ein wichtiger Ausgangspunkt für die Messung von Genehmigungsdurchlaufzeiten. Sie zeigt, wie lange Bestellanforderungen warten, bevor der formelle Genehmigungsprozess beginnt.

Bezugsquelle

Leiten Sie das Ereignis aus dem Subtab „System Notes“ ab, indem Sie den Timestamp identifizieren, an dem sich das Feld „Approval Status“ erstmals in einen Wert wie „Pending Approval“ ändert.

Erfassen

Identifizieren Sie den ersten Timestamp, an dem sich das Feld „Approval Status“ in „Pending Approval“ ändert.

Ereignistyp inferred
Anforderung zurückgezogen
Der ursprüngliche Anforderer oder ein Administrator storniert die Bestellanforderung, bevor sie vollständig genehmigt oder in eine Purchase Order umgewandelt wurde. Dies wird typischerweise aus einer Statusänderung zu „Cancelled“ oder „Withdrawn“ abgeleitet.
Warum das wichtig ist

Diese Aktivität stellt eine vom Anforderer ausgelöste Ausnahme oder Beendigung des Prozesses dar. Die Analyse zurückgezogener Anforderungen kann Änderungen des Geschäftsbedarfs oder nicht mehr gültige Bestellanforderungen sichtbar machen.

Bezugsquelle

Leiten Sie das Ereignis aus dem Subtab „System Notes“ ab, indem Sie den Timestamp verfolgen, an dem das Feld „Approval Status“ auf einen Wert wie „Cancelled“ oder einen benutzerdefinierten Status für zurückgezogene Anforderungen aktualisiert wird.

Erfassen

Timestamp der Änderung von „Approval Status“ zu „Cancelled“ oder „Withdrawn“.

Ereignistyp inferred
Genehmigungsschritt abgelehnt
Ein Genehmiger lehnt seinen zugewiesenen Schritt ab und sendet die Bestellanforderung in der Regel zur Korrektur an den Anforderer zurück. Diese Aktion wird von der SuiteApprovals-Workflow-Engine ausdrücklich protokolliert.
Warum das wichtig ist

Dieses Ereignis ist ein wichtiger Indikator für Nacharbeit und Ineffizienz im Prozess. Die Analyse von Ablehnungspunkten zeigt häufige Fehlerursachen auf, etwa Verstöße gegen Richtlinien oder fehlerhafte Daten.

Bezugsquelle

Das Ereignis wird aus dem SuiteApprovals-Protokoll oder dem Subtab „System Notes“ erfasst. Dort werden die Ablehnungsaktion, der ablehnende User und der Timestamp protokolliert.

Erfassen

Identifizieren Sie Ablehnungsaktionen im SuiteApprovals-Protokoll oder in „System Notes“.

Ereignistyp explicit
Genehmigungsschritt genehmigt
Ein autorisierter User genehmigt seinen zugewiesenen Schritt im Workflow und bringt die Bestellanforderung der endgültigen Genehmigung näher. Die SuiteApprovals-Plattform von NetSuite protokolliert diese Aktion ausdrücklich mit Angaben zu User und Timestamp.
Warum das wichtig ist

Diese Aktivität steht für einen positiven Fortschritt in der Genehmigungskette. Die Analyse der Zeit zwischen Genehmigungsschritten zeigt, wie effizient der Workflow und die einzelnen Genehmiger arbeiten.

Bezugsquelle

Das Ereignis wird aus dem SuiteApprovals-Protokoll oder dem Subtab „System Notes“ erfasst. Dort werden die Genehmigungsaktion, der Genehmiger und der genaue Timestamp des Ereignisses protokolliert.

Erfassen

Identifizieren Sie Genehmigungsaktionen im SuiteApprovals-Protokoll oder in „System Notes“.

Ereignistyp explicit
Genehmigungsschritt gestartet
Die Bestellanforderung erreicht eine bestimmte Stufe im Genehmigungs-Workflow und wartet auf eine Aktion des zuständigen Genehmigers oder der zuständigen Gruppe. Dies wird typischerweise daraus abgeleitet, dass der Workflow die Bestellanforderung dem nächsten Genehmiger in der Reihenfolge zuweist.
Warum das wichtig ist

Diese Aktivität markiert den Beginn der Wartezeit für den jeweiligen Genehmigungsschritt. Sie ist entscheidend, um Bottlenecks innerhalb der Genehmigungshierarchie zu lokalisieren und langsam reagierende Genehmiger zu erkennen.

Bezugsquelle

Leiten Sie das Ereignis aus Workflow-Ausführungsprotokollen oder Änderungen in einem Feld wie „Current Approver“ oder einem Workflow-Statusfeld ab. Die SuiteApprovals-Plattform erfasst den aktiven Genehmigungsschritt.

Erfassen

Leiten Sie das Ereignis aus Workflow-Protokollen oder dem Zeitpunkt ab, an dem der Datensatz einem neuen Genehmiger zugewiesen wird.

Ereignistyp inferred
Empfohlen Optional

Anleitungen zur Datenextraktion

So extrahieren Sie Ihre Daten aus NetSuite

Möchten Sie jetzt starten?

Verwenden Sie dieses Template, um Ihre Reise mit Process Mining zu beginnen und wertvolle Erkenntnisse aus Ihrem Purchase-to-Pay-Prozess für Bestellanforderungen in NetSuite zu gewinnen. Optimieren Sie noch heute Ihre Effizienz und verkürzen Sie Genehmigungszeiten.

Optimieren Sie Ihren Purchase-to-Pay-Prozess für Bestellanforderungen, starten Sie noch heute!

Erreichen Sie 30 % schnellere Genehmigungen von Bestellanforderungen und beseitigen Sie Engpässe.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Beginnen Sie noch heute mit der Optimierung.