Data Template: Einkauf-bis-Zahlung - Bestellung
Ihr Procure-to-Pay-Bestelldaten-Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung für die Prozesskartierung
- Praktische Anleitung zur Datenextraktion
Beschaffungsprozess - Bestellattribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivitätsname
ActivityName
|
Der Name des spezifischen Geschäfts-Event oder Schrittes, der innerhalb des Bestelllebenszyklus aufgetreten ist. | ||
|
Beschreibung
Dieses Attribut beschreibt einen einzelnen Schritt im Bestellprozess, wie z. B. „Bestellung erstellt“, „Bestellung genehmigt“ oder „Wareneingang gebucht“. Die Abfolge dieser Aktivitäten bildet den Prozessfluss für jede Bestellung. Die Analyse von Aktivitäten ist der Kern des Process Mining. Sie ermöglicht die Visualisierung der Prozesslandkarte, die Entdeckung von Prozessvarianten sowie die Identifizierung von Aktivitäten, die sich häufig wiederholen oder Verzögerungen verursachen. Das Verständnis der Abfolge und Häufigkeit von Aktivitäten ist essenziell für die Prozessoptimierung.
Warum es wichtig ist
Dieses Attribut ist essenziell für den Aufbau der Prozesslandkarte und das Verständnis der Abfolge von Events, die den Bestellprozess-Lebenszyklus bilden.
Woher erhalten
Abgeleitet aus der Geschäftslogik basierend auf Statusänderungen in Tabellen wie PurchTable, PurchReqTable und zugehörigen Buchungsjournalen wie VendPackingSlipJour oder VendInvoiceJour.
Beispiele
Bestellung erstelltBestellung genehmigtWareneingang gebuchtBestellung fakturiert
|
|||
|
Bestellung
PurchaseOrderNumber
|
Die eindeutige Kennung für die Bestellung, die als primärer Case für die Prozessanalyse dient. | ||
|
Beschreibung
Die Bestellnummer ist der zentrale Identifikator, der alle zugehörigen Aktivitäten verknüpft, vom ersten Entwurf bis zum endgültigen Abschluss oder zur Stornierung. Jede eindeutige Nummer repräsentiert eine einzelne Instanz des Bestellprozesses. Im Process Mining wird dieses Attribut verwendet, um den End-to-End-Verlauf jeder Bestellung zu rekonstruieren. Die Analyse des Prozesses basierend auf diesem Identifikator ermöglicht eine detaillierte Ansicht des gesamten Lebenszyklus, wodurch gängige Pfade, Abweichungen und Engpässe für einzelne Bestellungen identifiziert werden können.
Warum es wichtig ist
Es ist der grundlegende Schlüssel zur Rekonstruktion des Prozessflusses, der die Analyse des Weges jeder Bestellung von Anfang bis Ende ermöglicht.
Woher erhalten
Dies ist der Primärschlüssel in der Bestellkopf-Tabelle, typischerweise die PurchTable mit dem Feldnamen PurchId in Microsoft Dynamics 365.
Beispiele
PO-001245PO-001246PO-001247
|
|||
|
Ereigniszeit
EventTime
|
Das genaue Datum und die Uhrzeit, zu der eine Aktivität bzw. ein Ereignis stattgefunden hat. | ||
|
Beschreibung
Dieser Timestamp erfasst, wann jede Aktivität im Bestellprozess stattfand. Er ist das chronologische Rückgrat des Prozesses und ermöglicht die korrekte Reihenfolge der Events. In der Prozessanalyse sind Event-Timestamps grundlegend für die Berechnung von Durchlaufzeiten, Dauern zwischen Aktivitäten und der gesamten Case-Dauer. Sie werden verwendet, um Engpässe zu identifizieren, die Leistung anhand von SLAs zu messen und die zeitlichen Dynamiken des Prozesses zu verstehen. Zum Beispiel wird er verwendet, um die Zeit zwischen 'Bestellung erstellt' und 'Bestellung genehmigt' zu berechnen.
Warum es wichtig ist
Timestamps sind entscheidend für die Berechnung aller zeitbasierten Leistungs-Kennzahlen, wie Durchlaufzeiten und Dauern, die unerlässlich zur Identifizierung von Prozess-Engpässen sind.
Woher erhalten
Extrahiert aus verschiedenen Datums-/Zeitfeldern über mehrere Tabellen hinweg, wie z.B. CreatedDateTime in PurchTable, oder Buchungsdaten aus zugehörigen Journaltabellen.
Beispiele
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-11-05T09:12:00Z
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der angibt, wann die Daten für diesen Prozess zuletzt aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut zeichnet das Datum und die Uhrzeit der letzten Datenextraktion aus dem Quellsystem auf. Es liefert Kontext zur Aktualität der analysierten Daten. Die Kenntnis des letzten Aktualisierungszeitpunkts ist wichtig für Benutzer, um zu verstehen, ob sie die aktuellsten Prozessdaten sehen. Es hilft bei der Bewertung der Relevanz der Analyse und bei der Planung regelmäßiger Datenaktualisierungen.
Warum es wichtig ist
Sorgt für Transparenz über die Aktualität der Daten und ermöglicht es Benutzern, den aktuellen Stand ihrer Prozessanalyse zu kennen.
Woher erhalten
Dies ist ein Metadaten-Attribut, das während des Dateningestionsprozesses generiert und gespeichert wird.
Beispiele
2024-05-21T05:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Gibt das System an, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut identifiziert die Quellanwendung, aus der die Bestelldaten stammen. Für dieses Datenmodell ist der Wert typischerweise „Microsoft Dynamics 365“. In größeren Organisationen können Beschaffungsprozesse mehrere Systeme umfassen. Dieses Attribut unterstützt die Datengovernance und stellt sicher, dass die Herkunft der Daten klar ist, was besonders wichtig ist, wenn Daten aus verschiedenen Quellen zusammengeführt werden.
Warum es wichtig ist
Liefert wesentlichen Kontext zum Ursprung der Daten, was entscheidend für die Data Governance, Validierung und das Verständnis der technologischen Landschaft des Prozesses ist.
Woher erhalten
Dies ist ein statischer Wert, der während des Datenextraktions- und Transformationsprozesses hinzugefügt wird, um den Datensatz zu kennzeichnen.
Beispiele
Microsoft Dynamics 365 F&OD365
|
|||
|
Angefordertes Lieferdatum
RequestedDeliveryDate
|
Das Datum, an dem das Unternehmen den Lieferanten um Lieferung der Waren oder Dienstleistungen gebeten hat. | ||
|
Beschreibung
Dieses Datum ist auf der Bestellung angegeben und kommuniziert den gewünschten Lieferzeitplan an den Lieferanten. Es dient als Grundlage zur Messung der Lieferantenlieferleistung. Dieses Attribut ist unerlässlich für das Dashboard 'Lieferantenliefertreue' und den KPI 'Pünktliche Lieferrate'. Durch den Vergleich des RequestedDeliveryDate mit dem tatsächlichen Wareneingangsdatum können Unternehmen die Zuverlässigkeit der Lieferanten quantifizieren und chronische Verzögerungen in der Lieferkette identifizieren.
Warum es wichtig ist
Es ist die Grundlage zur Messung der Liefertermintreue, einer kritischen KPI zur Bewertung der Lieferantenverlässlichkeit und der Effizienz der Lieferkette.
Woher erhalten
Findet sich üblicherweise auf der PurchTable (Kopfebene) oder PurchLine (Positionsebene) als DeliveryDate.
Beispiele
2023-11-152023-12-012024-01-20
|
|||
|
Benutzername
UserName
|
Der Name des Benutzers, der eine spezifische Aktivität durchgeführt hat. | ||
|
Beschreibung
Dieses Attribut identifiziert die für die Ausführung eines Events verantwortliche Person, wie z. B. die Erstellung, Genehmigung oder Änderung einer Bestellung. Es kann sich um eine System-Benutzer-ID oder einen vollständigen Namen handeln. Die Analyse der Benutzeraktivität hilft, die Arbeitslastverteilung zu verstehen, Schulungsbedarfe zu identifizieren und Personen oder Teams zu lokalisieren, die an Prozessabweichungen beteiligt sind. Es ist essenziell für Dashboards zur Leistungsanalyse von Genehmigern und kann dazu verwendet werden, den Prozess nach Aktivitäten bestimmter Benutzer zu filtern.
Warum es wichtig ist
Es ermöglicht Leistungsanalysen nach Benutzer, hilft, Bottlenecks im Zusammenhang mit spezifischen Personen zu identifizieren und bietet Verantwortlichkeit für Prozessschritte.
Woher erhalten
Kann in Feldern wie CreatedBy oder ModifiedBy in Tabellen wie PurchTable gefunden werden. Benutzerdetails werden typischerweise in der UserInfo-Tabelle gespeichert.
Beispiele
Alice JohnsonBob WilliamsSysAdmin
|
|||
|
Bestellstatus
PurchaseOrderStatus
|
Der aktuelle Status der Bestellung in ihrem Lebenszyklus. | ||
|
Beschreibung
Dieses Attribut gibt den Gesamtzustand der Bestellung zu einem bestimmten Zeitpunkt an, z. B. „Offene Bestellung“, „Eingegangen“, „Fakturiert“ oder „Storniert“. Es repräsentiert das Ergebnis der letzten Aktivität. Die Statusverfolgung ist nützlich, um den aktuellen Zustand aller offenen Bestellungen zu verstehen. Im Process Mining kann sie verwendet werden, um die Ergebnisse von Cases zu analysieren, beispielsweise durch das Filtern nach allen Bestellungen, die im Status „Storniert“ endeten, um die Gründe dafür zu untersuchen.
Warum es wichtig ist
Bietet einen Überblick über den aktuellen Status der Bestellung, was nützlich ist, um Cases zu filtern und Prozessergebnisse zu analysieren, wie z.B. Abschluss- oder Stornierungsraten.
Woher erhalten
Gefunden in der PurchTable. Die primären Statusfelder sind DocumentState und PurchStatus.
Beispiele
Offene BestellungWare erhaltenFakturiertStorniert
|
|||
|
Gesamtbestellwert
PurchaseOrderTotalAmount
|
Der monetäre Gesamtwert der Bestellung. | ||
|
Beschreibung
Dieses Attribut repräsentiert die Gesamtkosten aller in der Bestellung enthaltenen Artikel und Dienstleistungen. Es ist eine wichtige Finanzkennzahl für den Beschaffungsprozess. Die Analyse des Prozesses nach dem Gesamtbetrag kann wichtige Erkenntnisse liefern. So können Bestellungen mit höherem Wert einem anderen, strengeren Genehmigungspfad folgen oder längere Durchlaufzeiten aufweisen. Es wird auch in der Finanzberichterstattung und zur Kategorisierung von Bestellungen in Wertbereiche für die Analyse verwendet.
Warum es wichtig ist
Ermöglicht eine Finanzanalyse des Beschaffungsprozesses und hilft dabei zu identifizieren, wie der Auftragswert das Prozessverhalten, wie z.B. Genehmigungszeiten und Pfade, beeinflusst.
Woher erhalten
Dieser Wert kann aus der PurchLine-Tabelle durch Summieren des LineAmount für eine gegebene PurchId berechnet oder in Betragsfeldern auf Kopfebene der PurchTable gefunden werden.
Beispiele
5250.00120.50150000.00
|
|||
|
Lieferantenname
VendorName
|
Der Name des Lieferanten oder Verkäufers, für den die Bestellung erstellt wird. | ||
|
Beschreibung
Dieses Attribut enthält den Namen des externen Lieferanten, der die Waren oder Dienstleistungen bereitstellt. Es ist eine kritische Dimension für die Analyse von Beschaffungsaktivitäten. Die Segmentierung des Prozesses nach Lieferantennamen ist entscheidend für die Bewertung der Lieferantenleistung. Sie ermöglicht die Analyse von Pünktlichkeitsraten, Warenrücksendequoten und Ergebnissen der Qualitätsprüfung für jeden Lieferanten. Dies hilft, zuverlässige Partner und diejenigen zu identifizieren, die Verzögerungen oder Qualitätsprobleme verursachen.
Warum es wichtig ist
Dieses Attribut ist essenziell für das Lieferantenleistungsmanagement, da es die Analyse von Lieferzeiten, Rücksendequoten und der Gesamtzuverlässigkeit pro Lieferant ermöglicht.
Woher erhalten
Das Lieferantenkonto ist in PurchTable (Feld OrderAccount) gespeichert. Der Name wird durch die Verknüpfung mit der VendTable ermittelt.
Beispiele
Contoso Office SuppliesFabrikam RoboticsNorthwind Traders
|
|||
|
Abteilung
DepartmentName
|
Der Name der Abteilung, die die Bestellanforderung oder Bestellung initiiert hat. | ||
|
Beschreibung
Dieses Attribut identifiziert die interne Geschäftseinheit oder Abteilung, die für den Einkauf verantwortlich ist. Es wird oft von der Person abgeleitet, die die Bestellanforderung erstellt hat. Die Analyse des Prozesses nach Abteilung ist entscheidend, um zu verstehen, wie verschiedene Organisationseinheiten den Beschaffungsprozess nutzen. Sie kann helfen, Abteilungen mit längeren Genehmigungszyklen, höheren Raten von Bestelländerungen oder spezifischen Einkaufsmustern zu identifizieren. Dies ermöglicht gezielte Prozessverbesserungsinitiativen.
Warum es wichtig ist
Ermöglicht den Vergleich der Prozess-Performance über verschiedene Geschäftsbereiche hinweg und hilft, abteilungsspezifische Verhaltensweisen, Bottlenecks oder Ineffizienzen zu identifizieren.
Woher erhalten
Diese Information ist oft über den Anforderer oder Ersteller der Bestellanforderung (PurchReqTable) oder Bestellung (PurchTable) und deren zugehörige Abteilung im HR-Modul verknüpft.
Beispiele
FinanzenITProduktionMarketing
|
|||
|
Bestellanforderung
PurchaseRequisitionNumber
|
Der Identifikator der Bestellanforderung, die der Bestellung vorausging. | ||
|
Beschreibung
Dieses Attribut verknüpft eine Bestellung mit der ursprünglichen internen Anfrage, der Bestellanforderung. Nicht alle Bestellungen stammen aus einer Bestellanforderung. Diese Verknüpfung ist entscheidend für die Analyse des gesamten „Bestellanforderung-zu-Bestellung-Prozesses“. Sie ermöglicht die Messung des KPI „Geschwindigkeit der Bestellanforderung-zu-Bestellung-Konvertierung“ und das Verständnis, wie schnell interne Nachfrage in eine externe Bestellung umgewandelt wird. Sie hilft auch bei der Compliance-Analyse, zum Beispiel durch die Identifizierung von Bestellungen, die ohne formelle Bestellanforderung erstellt wurden.
Warum es wichtig ist
Verknüpft die Bestellung mit der ursprünglichen Anforderung, ermöglicht die Analyse der Durchlaufzeit von der Anforderung bis zur Bestellung und gewährleistet die Compliance des Prozesses.
Woher erhalten
Gefunden in der PurchLine Tabelle, im Feld PurchReqId, das auf die PurchReqTable zurückverweist.
Beispiele
PR-000871PR-000872PR-000873
|
|||
|
Buchungskreis
CompanyCode
|
Der Identifikator für die juristische Person oder das Unternehmen, das die Bestellung aufgibt. | ||
|
Beschreibung
In einer Mehrmandantenumgebung gibt dieses Attribut an, welche juristische Person den Einkauf tätigt. Dies ist ein grundlegender organisatorischer Datenpunkt. Dieses Attribut ermöglicht eine vergleichende Analyse des P2P-Prozesses über verschiedene juristische Personen innerhalb derselben Organisation. Es kann Unterschiede in der Prozesseffizienz, Compliance und im Lieferantenmanagement von einem Unternehmen zum anderen aufzeigen und somit Standardisierungsbemühungen unterstützen.
Warum es wichtig ist
Unerlässlich für Multi-Entity-Organisationen, um den Beschaffungsprozess über verschiedene Rechtseinheiten hinweg zu vergleichen und zu standardisieren.
Woher erhalten
Dies ist das DataAreaId-Feld, das auf fast jeder Tabelle in Dynamics 365 vorhanden ist, einschließlich der PurchTable.
Beispiele
USMFDEMFGBSI
|
|||
|
Einkaufskategorie
PurchaseCategory
|
Die Klassifizierung des gekauften Artikels oder der Dienstleistung, wie z.B. 'IT-Hardware' oder 'Büromaterial'. | ||
|
Beschreibung
Dieses Attribut bietet eine Möglichkeit, Bestellpositionen in logische Kategorien zu gruppieren. Diese Klassifizierung hilft bei der Analyse von Ausgabenmustern und Prozessvariationen über verschiedene Beschaffungsarten hinweg. In der Prozessanalyse kann das Filtern nach Einkaufskategorie unterschiedliche Verhaltensweisen aufzeigen. So kann der Beschaffungsprozess für Investitionsausgaben länger und komplexer sein als für Betriebsbedarf. Es wird in Dashboards verwendet, um Änderungstrends und Rücksendequoten nach Kategorie zu analysieren.
Warum es wichtig ist
Ermöglicht die Segmentierung des Prozesses nach der Art der gekauften Waren oder Dienstleistungen, wodurch unterschiedliche Prozessverhaltensweisen für verschiedene Ausgabenkategorien aufgedeckt werden.
Woher erhalten
Artikelkategorien sind mit den freigegebenen Produkten (InventTable) verknüpft, die dann in der PurchLine verwendet werden. Die Kategorieinformationen selbst sind in den Kategorieverwaltungstabellen gespeichert.
Beispiele
IT HardwareBürobedarfProfessionelle DienstleistungenRohmaterialien
|
|||
|
Freigabe-Durchlaufzeit
ApprovalCycleTime
|
Die Dauer zwischen der Erstellung einer Bestellung und ihrer endgültigen Genehmigung. | ||
|
Beschreibung
Diese berechnete Kennzahl misst die verstrichene Zeit von der Aktivität 'Bestellung erstellt' bis zur Aktivität 'Bestellung genehmigt'. Sie ist ein direktes Maß für die Effizienz des Genehmigungs-Workflows. Dieses Attribut ist die primäre Kennzahl für den KPI 'Durchschnittliche Genehmigungszeit für Bestellungen' und das Dashboard 'Analyse der Genehmigungsdurchlaufzeiten von Bestellungen'. Die Analyse dieser Dauer hilft, Engpässe in der Genehmigungskette zu identifizieren und zu bewerten, ob Genehmigungsprozesse interne Service Level Agreements (SLAs) erfüllen.
Warum es wichtig ist
Misst direkt die Effizienz des Genehmigungs-Workflows, einem häufigen Bereich für Verzögerungen im Beschaffungsprozess.
Woher erhalten
Berechnet durch Ermittlung der Zeitdifferenz zwischen dem EventTime der Aktivitäten 'Bestellung genehmigt' und 'Bestellung erstellt' für jeden Case.
Beispiele
P2DT12H30MPT8HP7D
|
|||
|
Genehmigername
ApproverName
|
Der Name des Benutzers, der die Bestellung oder einen Schritt im Genehmigungs-Workflow genehmigt hat. | ||
|
Beschreibung
Dieses Attribut identifiziert den Manager oder Benutzer, der die formelle Genehmigung für die Bestellung erteilt hat und somit die Weiterverarbeitung ermöglichte. In mehrstufigen Genehmigungs-Workflows kann es mehrere Genehmiger für eine einzelne Bestellung geben. Die Verfolgung des Genehmigers ist grundlegend für die Dashboards „Analyse der Durchlaufzeit der Bestellfreigabe“ und „Leistungskennzahlen der Genehmiger“. Sie ermöglicht die Messung, wie lange jeder Genehmiger benötigt, identifiziert Engpässe in der Genehmigungskette und hilft bei der Bewertung der Arbeitslastverteilung und Effizienz.
Warum es wichtig ist
Ermöglicht die Analyse des Genehmigungsprozesses und hilft, Genehmigungs-Bottlenecks zu identifizieren sowie die Performance und Arbeitslast verschiedener Genehmiger zu messen.
Woher erhalten
Genehmigungsinformationen werden typischerweise in Workflow-Tracking-Tabellen gespeichert, nicht direkt in PurchTable. Dies erfordert das Abfragen der Workflow-Historie, die mit der Bestellung verbunden ist.
Beispiele
Charles GreenDiana PrinceEdward Nigma
|
|||
|
Ist Bestellung geändert
IsPurchaseOrderChanged
|
Ein Boolesches Flag, das anzeigt, ob die Bestellung nach ihrer ursprünglichen Genehmigung geändert wurde. | ||
|
Beschreibung
Dieses berechnete Attribut wird auf 'true' gesetzt, wenn nach der Aktivität 'Bestellung genehmigt' eine Aktivität 'Bestellung geändert' für einen bestimmten Case auftritt. Es vereinfacht die Analyse von Nacharbeit und Änderungen. Dieser Indikator ist entscheidend für die Berechnung des KPI 'Änderungsrate von Bestellungen nach Genehmigung' und für das Dashboard 'Trends bei Bestellungsänderungen'. Er bietet eine unkomplizierte Möglichkeit, Bestellungen, die Nacharbeit erforderten, zu isolieren und zu analysieren, wodurch die Grundursachen solcher Änderungen identifiziert werden können.
Warum es wichtig ist
Vereinfacht die Messung von Nacharbeit und Änderungsfrequenz, die Schlüsselindikatoren für Prozessinstabilität und Ineffizienz sind.
Woher erhalten
Dies ist ein berechnetes Attribut, das aus der Abfolge der Aktivitäten im Event Log abgeleitet wird.
Beispiele
truefalsch
|
|||
|
Ist pünktliche Lieferung
IsOnTimeDelivery
|
Ein Boolesches Flag, das anzeigt, ob die Waren am oder vor dem angeforderten Lieferdatum eingegangen sind. | ||
|
Beschreibung
Dieses berechnete Attribut vergleicht den Timestamp der Aktivität 'Wareneingang gebucht' mit dem RequestedDeliveryDate. Es wird auf 'true' gesetzt, wenn das Eingangsdatum am oder vor dem angeforderten Datum liegt. Dieser Indikator unterstützt direkt die Berechnung des KPI 'Pünktliche Lieferrate'. Er vereinfacht die Analyse der Lieferantenleistung und ermöglicht ein einfaches Filtern und Visualisieren von pünktlichen gegenüber verspäteten Lieferungen, was für das Dashboard 'Lieferantenliefertreue' zentral ist.
Warum es wichtig ist
Liefert ein klares, binäres Ergebnis für die Lieferleistung, was die Berechnung von KPIs zur pünktlichen Lieferung und Lieferanten-Scorecards vereinfacht.
Woher erhalten
Dies ist ein berechnetes Attribut, das durch den Vergleich des RequestedDeliveryDate mit dem EventTime der Aktivität 'Wareneingang gebucht' abgeleitet wird.
Beispiele
truefalsch
|
|||
|
Lieferort
DeliveryLocation
|
Der spezifische Standort, das Lager oder die Adresse, an die die Waren geliefert werden sollen. | ||
|
Beschreibung
Dieses Attribut gibt den physischen Lieferort für die Artikel der Bestellung an. Dies könnte ein Lager, ein bestimmtes Büro oder eine Projektstätte sein. Die Analyse des Prozesses nach Lieferort kann helfen, regionale oder standortspezifische Engpässe zu identifizieren, insbesondere im Wareneingangsprozess. Das Dashboard 'Wareneingangs-Bearbeitungszeit' kann dieses Attribut nutzen, um die Effizienz an verschiedenen Standorten zu vergleichen.
Warum es wichtig ist
Hilft, standortspezifische Prozessabweichungen oder Verzögerungen zu identifizieren, insbesondere in den Phasen Wareneingang und Qualitätsprüfung.
Woher erhalten
Lieferadresse und Standortinformationen werden in der PurchTable gespeichert und können aus den Unternehmens- oder Lieferanteneinstellungen übernommen werden.
Beispiele
Hauptlager ABürogebäude CDistributionszentrum Westküste
|
|||
|
Rückgabegrund
ReturnReason
|
Der Grund, der angegeben wird, wenn Waren einer Bestellung an den Lieferanten zurückgesendet werden. | ||
|
Beschreibung
Wenn eine Aktivität 'Waren an Lieferanten zurückgesendet' auftritt, erfasst dieses Attribut die Begründung für die Rücksendung, wie 'Beschädigte Ware', 'Falscher Artikel' oder 'Mangelhafte Qualität'. Diese Daten sind für das Dashboard zur 'Retourenquote von Bestellungen' von unschätzbarem Wert. Die Analyse der Rücksendegründe hilft, die Ursachen für Retouren zu identifizieren – sei es aufgrund von Lieferantenqualität, internen Bestellfehlern oder Versandproblemen. Dies ermöglicht gezielte Maßnahmen zur Reduzierung der Retourenquote.
Warum es wichtig ist
Gibt Aufschluss darüber, warum Waren zurückgesendet werden, und hilft, Probleme bezüglich Lieferantenqualität, Bestellgenauigkeit oder Logistik zu diagnostizieren.
Woher erhalten
Rückgabegründe werden typischerweise bei Retourenauftragstransaktionen oder über Grundcodes erfasst, die mit negativen Wareneingangsbuchungen verknüpft sind.
Beispiele
TransportschadenFalscher Artikel geliefertFehlgeschlagene Qualitätsprüfung
|
|||
Beschaffungsprozess - Bestellaktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Bestellanforderung erstellt
|
Diese Aktivität kennzeichnet die Erstellung einer Bestellanforderung, also der formellen Anfrage für Waren oder Dienstleistungen. Sie wird erfasst, sobald ein neuer Datensatz in der Bestellanforderungstabelle angelegt wird, was den Beginn der Beschaffungsnachfrage signalisiert. | ||
|
Warum es wichtig ist
Dies ist der initiale Auslöser für den Bestellprozess. Die Analyse der Zeit von diesem Event bis zur Bestellerstellung hilft, die interne Prozesseffizienz und die Reaktionsfähigkeit auf die Nachfrage zu messen.
Woher erhalten
Dieses Event entspricht der Erstellung eines Datensatzes in der PurchReqTable. Der Erstellungs-Timestamp (createdDateTime) des Datensatzes markiert den Event-Zeitpunkt.
Erfassen
Extrahieren Sie den Erstellungs-Timestamp aus der PurchReqTable für jede Bestellanforderung.
Ereignistyp
explicit
|
|||
|
Bestellung abgeschlossen
|
Zeigt den erfolgreichen Abschluss des Bestellprozess-Lebenszyklus an, bei dem alle Waren empfangen und fakturiert wurden. Dies wird typischerweise abgeleitet, wenn der Bestellstatus auf einen finalen, geschlossenen Zustand aktualisiert wird. | ||
|
Warum es wichtig ist
Diese Aktivität definiert das Ende einer erfolgreichen Prozessinstanz. Die Messung der „Gesamtdurchlaufzeit der Bestellung“ von der Erstellung bis zum Abschluss bietet eine ganzheitliche Sicht auf die Prozesseffizienz.
Woher erhalten
Abgeleitet von den Statusfeldern in der PurchTable, z.B. wenn sowohl der DocumentState 'Invoiced' ist als auch die Positionsstatus den vollständigen Wareneingang und die Rechnungsstellung anzeigen.
Erfassen
Identifizieren Sie den Timestamp, wenn die Kopf- und Zeilenstatus der Bestellung auf einen finalen, geschlossenen Zustand aktualisiert werden (z.B. 'Invoiced').
Ereignistyp
inferred
|
|||
|
Bestellung an Lieferanten gesendet
|
Diese Aktivität zeigt an, dass die genehmigte Bestellung an den Lieferanten übermittelt wurde. Sie wird erfasst, wenn die Bestellung bestätigt wird, wodurch ein Bestätigungsjournal generiert und typischerweise der Versand des Dokuments ausgelöst wird. | ||
|
Warum es wichtig ist
Dies ist der erste externe Schritt und beginnt die Messung der Lieferantendurchlaufzeit. Er ist entscheidend für die Verfolgung der Lieferantenleistung und des KPI 'Pünktliche Lieferrate'.
Woher erhalten
Das Event wird durch die Erstellung eines Datensatzes in der PurchPurchaseOrderJour-Tabelle (dem Bestellbestätigungsjournal) markiert. Das Erstellungsdatum dieses Journals dient als Aktivitäts-Timestamp.
Erfassen
Verwenden Sie den creation timestamp des ersten PurchPurchaseOrderJour Datensatzes für die Bestellung.
Ereignistyp
explicit
|
|||
|
Bestellung erstellt
|
Diese Aktivität kennzeichnet die Erstellung eines Bestellentwurfs im System. Sie wird über den Erstellungs-Timestamp des Bestellkopfdatensatzes erfasst und folgt häufig einer genehmigten Bestellanforderung. | ||
|
Warum es wichtig ist
Dies markiert den Übergang von einer internen Anforderung zu einem formalen Einkaufsdokument. Es ist ein wichtiger Startpunkt für die Messung der Bestellverarbeitungs- und Genehmigungsdurchlaufzeiten.
Woher erhalten
Dieses Event ist die Erstellung eines Datensatzes in der PurchTable. Das Feld createdDateTime in dieser Tabelle liefert den Timestamp für die Aktivität.
Erfassen
Extrahieren Sie den Erstellungs-Timestamp aus der PurchTable für jede Bestellung.
Ereignistyp
explicit
|
|||
|
Bestellung genehmigt
|
Kennzeichnet die endgültige Genehmigung der Bestellung, die den Versand an den Lieferanten autorisiert. Dieses Event wird typischerweise aus einer Statusänderung der Bestellung abgeleitet oder direkt aus der Workflow-Historie erfasst. | ||
|
Warum es wichtig ist
Dies ist ein entscheidender Meilenstein, da keine weiteren Maßnahmen ergriffen werden können, bis die Bestellung genehmigt ist. Er ist unerlässlich für die Analyse von Genehmigungs-Engpässen und die Messung des KPI 'Genehmigungsdurchlaufzeit von Bestellungen'.
Woher erhalten
Abgeleitet aus der Änderung des DocumentState-Feldes in der PurchTable zu 'Approved'. Alternativ kann es aus dem Abschluss-Timestamp des letzten Genehmigungsschritts in der WorkflowTrackingStatusTable bezogen werden.
Erfassen
Identifizieren Sie den Timestamp, wenn der DocumentState in der PurchTable zu 'Approved' wechselt.
Ereignistyp
inferred
|
|||
|
Wareneingang gebucht
|
Kennzeichnet die offizielle Erfassung der erhaltenen Waren im Rahmen der Bestellung im System. Dieses Event wird erfasst, wenn ein Wareneingangsbuchungsblatt gebucht wird. | ||
|
Warum es wichtig ist
Dies ist ein wichtiger Meilenstein, der den Lagerbestand aktualisiert und den Beginn des Rechnungsabgleichprozesses markiert. Er ist der Endpunkt zur Messung der 'Pünktlichen Lieferrate' und der Lieferantendurchlaufzeit.
Woher erhalten
Erfasst aus der Erstellung des Wareneingangsjournals, gespeichert in VendPackingSlipJour. Das Feld createdDateTime oder PackingSlipDate in dieser Tabelle zeigt an, wann Waren offiziell empfangen wurden.
Erfassen
Verwenden Sie den creation oder posting timestamp aus dem VendPackingSlipJour Datensatz, der mit der Bestellung verknüpft ist.
Ereignistyp
explicit
|
|||
|
Bestellanforderung genehmigt
|
Beschreibt die formale Genehmigung einer Bestellanforderung durch einen autorisierten Manager. Dieses Event wird typischerweise aus den Workflow-Verlaufsprotokollen erfasst oder durch die Nachverfolgung einer Statusänderung im Anforderungsdatensatz. | ||
|
Warum es wichtig ist
Die Genehmigung ist ein kritischer Meilenstein, der die Umwandlung einer Bestellanforderung in eine Bestellung ermöglicht. Verzögerungen hier wirken sich direkt auf den gesamten Beschaffungszeitplan aus.
Woher erhalten
Kann aus der WorkflowTrackingStatusTable, die der Bestellanforderung zugeordnet ist, erfasst oder aus einer Änderung des Statusfelds in der PurchReqTable in den Status 'Approved' abgeleitet werden.
Erfassen
Verwenden Sie den completion timestamp des finalen Genehmigungsschritts in der Workflow-Historie für die Anforderung.
Ereignistyp
explicit
|
|||
|
Bestellung fakturiert
|
Diese Aktivität markiert den Zeitpunkt, an dem eine Lieferantenrechnung eingegangen und gegen die Bestellung gebucht wurde. Dieses Event verknüpft die Beschaffungs- und Zahlungsprozesse. | ||
|
Warum es wichtig ist
Dies ist der letzte Schritt vor der Zahlung und entscheidend für die Berechnung der endgültigen Kosten des Einkaufs. Er bietet einen Endpunkt für die Drei-Wege-Abgleichanalyse.
Woher erhalten
Dieses Event wird aus der Buchung eines Kreditorenrechnungsjournals (VendInvoiceJour) erfasst, das der Bestellung zugeordnet ist. Das InvoiceDate oder Buchungsdatum dieses Datensatzes ist der Timestamp.
Erfassen
Verwenden Sie den posting timestamp aus der VendInvoiceJour Tabelle, die mit dem PurchTable Datensatz verknüpft ist.
Ereignistyp
explicit
|
|||
|
Bestellung geändert
|
Diese Aktivität erfasst jede Änderung, die an einer Bestellung nach deren Genehmigung vorgenommen wird. Dynamics 365 kann Versionen der Bestellung verfolgen, was die Identifizierung von Änderungen ermöglicht. | ||
|
Warum es wichtig ist
Änderungen zu verfolgen, ist entscheidend für die Identifizierung von Nacharbeit, das Verständnis von Prozessinstabilität und die Messung der 'Bestelländerungsrate'. Änderungen können zu Verzögerungen und Kostenabweichungen führen.
Woher erhalten
Abgeleitet durch den Vergleich verschiedener Versionen der Bestellung, die in Archiv- oder Versionierungstabellen (z.B. PurchTableHistory) gespeichert sind. Eine Erhöhung der Versionsnummer kennzeichnet eine Änderung.
Erfassen
Identifizieren Sie Datensätze, bei denen die Versionsnummer in der PurchTable nach der Genehmigung erhöht wurde.
Ereignistyp
inferred
|
|||
|
Bestellung storniert
|
Beschreibt die Stornierung einer Bestellung, bevor diese vollständig abgeschlossen wurde. Dies wird durch eine spezifische Statusänderung im Bestelldokument erfasst. | ||
|
Warum es wichtig ist
Stornierungen sind ein wichtiger Ausnahmepfad. Die Analyse ihrer Häufigkeit und Gründe kann Probleme in der Planung oder Lieferantenverlässlichkeit aufzeigen.
Woher erhalten
Dies wird abgeleitet, wenn das DocumentState-Feld in der PurchTable auf 'Storniert' aktualisiert wird. Der Timestamp dieser Statusänderung markiert das Event.
Erfassen
Identifizieren Sie den Timestamp, wenn der DocumentState in der PurchTable auf 'Canceled' gesetzt wird.
Ereignistyp
inferred
|
|||
|
Bestellung vom Lieferanten bestätigt
|
Beschreibt die Bestätigung der Bestelldetails durch den Lieferanten. Dies ist oft ein manueller Datenerfassungsschritt, basierend auf der Kommunikation des Lieferanten. | ||
|
Warum es wichtig ist
Die Lieferantenbestätigung gibt die Gewissheit, dass die Bestellung bearbeitet wird. Verzögerungen oder Abweichungen in dieser Phase können auf potenzielle Lieferprobleme hinweisen.
Woher erhalten
Dies wird typischerweise aus der Belegung bestätigungsbezogener Datums- oder Statusfelder in der PurchTable abgeleitet, wie z.B. Lieferbestätigungsdaten. Dies ist möglicherweise kein diskretes Event.
Erfassen
Ableiten aus der Belegung eines spezifischen Bestätigungsdatumsfeldes in der PurchTable oder PurchLine.
Ereignistyp
inferred
|
|||
|
Bestellung zur Genehmigung eingereicht
|
Beschreibt den Zeitpunkt, an dem ein Bestellentwurf formal in den Genehmigungs-Workflow übermittelt wird. Dies ist typischerweise eine explizite Benutzeraktion, die über Workflow-Protokolle erfasst wird. | ||
|
Warum es wichtig ist
Diese Aktivität initiiert offiziell den Bestellfreigabezyklus. Ihre Verfolgung ermöglicht eine präzise Messung der Wartezeiten von Bestellungen bis zur Genehmigung und der gesamten Genehmigungsdauer.
Woher erhalten
Erfasst aus der WorkflowTrackingStatusTable für die Bestellung, die das Einreichungsereignis und den Timestamp protokolliert.
Erfassen
Identifizieren Sie das 'Submitted'-Event in der Workflow-Historie, das mit dem PurchTable-Datensatz verknüpft ist.
Ereignistyp
explicit
|
|||
|
Qualitätsprüfung durchgeführt
|
Beschreibt den Abschluss einer Qualitätsprüfung für die erhaltenen Güter. Dieses Event wird oft über das Qualitätsmanagementmodul oder eine Statusaktualisierung verwaltet. | ||
|
Warum es wichtig ist
Diese Aktivität kann einen erheblichen Engpass zwischen dem Wareneingang und der Verfügbarmachung der Waren darstellen. Die Analyse ihrer Dauer trägt dazu bei, den KPI „Durchlaufzeit der Qualitätsprüfung“ zu verbessern.
Woher erhalten
Dies kann aus der Fertigstellung eines Qualitätsauftrags (InventQualityOrderTable) abgeleitet werden, der mit dem Wareneingang der Bestellung verknüpft ist. Der Timestamp der Statusänderung auf 'Bestanden' oder 'Fehlgeschlagen' markiert das Event.
Erfassen
Verfolgen Sie den Timestamp des Statusabschlusses in der InventQualityOrderTable, die mit der Bestellposition verknüpft ist.
Ereignistyp
inferred
|
|||
|
Ware an Lieferanten zurückgesandt
|
Zeigt an, dass zuvor erhaltene Waren aufgrund von Problemen wie Beschädigungen oder falschen Artikeln an den Lieferanten zurückgesandt wurden. Dies wird durch die Buchung einer Retourentransaktion erfasst. | ||
|
Warum es wichtig ist
Retouren stellen Prozessfehler und zusätzliche Kosten dar. Die Nachverfolgung dieser Aktivität hilft bei der Berechnung der 'Bestellrücksendequote' und der Identifizierung von Problemen mit Lieferanten oder Produkten.
Woher erhalten
Dieses Event wird aus der Erstellung einer Bestellung mit negativer Menge oder einem spezifischen Retourenauftragsdokument abgeleitet, das auf die ursprüngliche Bestellung verweist. Das Transaktionsdatum der Retourenbuchung ist der Event-Zeitpunkt.
Erfassen
Identifizieren Sie die Buchung einer Retourenbestellung oder einer Lastschrift gegen die ursprüngliche Bestellung.
Ereignistyp
explicit
|
|||