Data Template: Order to Cash – Kundenauftragsbearbeitung
Ihr Order-to-Cash-Daten-Template für die Kundenauftragsbearbeitung
- Empfohlene Attribute für eine umfassende Analyse
- Wichtige Prozessaktivitäten zur Nachverfolgung
- Spezifische Datenextraktionsanleitung für Microsoft Dynamics 365
Order-to-Cash - Attribute der Vertriebsauftragsabwicklung
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
ActivityName
|
Der Name des spezifischen Geschäfts-Events oder der Aufgabe, der/die zu einem bestimmten Zeitpunkt innerhalb des Vertriebsauftragsprozesses aufgetreten ist. | ||
|
Beschreibung
Dieses Attribut stellt einen eigenständigen Schritt oder ein Event im Lebenszyklus des Verkaufsauftrags dar, wie 'Verkaufsauftrag erstellt', 'Waren versendet' oder 'Zahlung erhalten'. Die Abfolge dieser Aktivitäten für einen bestimmten Verkaufsauftrag bildet den Prozessfluss. Die Analyse der Abfolge, Häufigkeit und Übergänge zwischen Aktivitäten ist der Kern von Process Mining. Sie hilft, die Prozesslandkarte zu visualisieren, häufige und seltene Prozessvarianten zu identifizieren, Bottlenecks zu erkennen und Bereiche für Nacharbeit oder Nicht-Compliance zu lokalisieren. Dieses Attribut ist grundlegend, um zu verstehen, was tatsächlich im Prozess geschieht.
Warum es wichtig ist
Es definiert die Schritte des Prozesses und ermöglicht so den Aufbau und die Visualisierung des Prozessflusses, was das primäre Ziel des Process Mining ist.
Woher erhalten
Dieses Attribut wird konzeptionell abgeleitet, indem spezifische System-Events oder Statusänderungen in Tabellen wie 'SalesTable' und verwandten Logistik- oder Finanztabellen einem standardisierten Aktivitätsnamen zugeordnet werden.
Beispiele
Kundenauftrag erstelltWaren versandtRechnung erstelltZahlung eingegangen
|
|||
|
Kundenauftrag
SalesOrderNumber
|
Der eindeutige Identifikator für jeden Vertriebsauftrag, der als primärer Case-Identifikator für den Prozess dient. | ||
|
Beschreibung
Die Vertriebsauftragsnummer (Sales Order Number) ist ein einzigartiger alphanumerischer Code, der jedem Kundenauftrag in Microsoft Dynamics 365 zugewiesen wird. Sie fungiert als die zentrale Case ID und verknüpft alle zugehörigen Aktivitäten und Events von der Erstellung bis zum Abschluss. Im Process Mining ist dieses Attribut essenziell für die Rekonstruktion des gesamten Prozessverlaufs jedes einzelnen Vertriebsauftrags. Es ermöglicht Analysten, die vollständige Abfolge der Aktivitäten nachzuvollziehen, Case-Dauern zu messen und Variationen für jede spezifische Bestellung zu analysieren, was die Grundlage der gesamten Prozessanalyse bildet.
Warum es wichtig ist
Dieser Bezeichner ist entscheidend für die Korrelation aller zugehörigen Events und ermöglicht eine vollständige End-to-End-Analyse des Lebenszyklus jedes Kundenauftrags.
Woher erhalten
Befindet sich in der Tabelle 'SalesTable', Feld 'SalesId'.
Beispiele
SO-00102345SO-00102346SO-00102347
|
|||
|
Startzeit
EventTime
|
Das genaue Datum und die Uhrzeit, zu der eine Aktivität bzw. ein Ereignis stattgefunden hat. | ||
|
Beschreibung
Die Event Time, oder der Timestamp, zeichnet den genauen Moment auf, zu dem eine Aktivität stattgefunden hat. Jede Aktivität im Event Log hat einen zugehörigen Timestamp, der eine chronologische Aufzeichnung des Prozesses für jeden Case erstellt. Dieses Attribut ist entscheidend für alle zeitbasierten Analysen im Process Mining. Es wird verwendet, um Zykluszeiten zwischen Aktivitäten zu berechnen, die Gesamtdauer eines Case zu messen, Wartezeiten zu analysieren und Engpässe zu identifizieren, wo der Prozess verzögert wird. Es ermöglicht auch die Leistungsüberwachung über die Zeit, wie die Verfolgung des Durchsatzes pro Tag, Woche oder Monat.
Warum es wichtig ist
Dieser Timestamp ist unerlässlich zur Berechnung aller dauerbasierten Metriken, wie Durchlaufzeiten und Bottlenecks, sowie zur chronologischen Anordnung von Events.
Woher erhalten
Dies wird aus verschiedenen Datums-/Zeitfeldern abgeleitet, die mit spezifischen Transaktionen verknüpft sind, wie z.B. 'SalesTable.CreatedDateTime' für die Auftragserstellung oder Buchungsdaten von Zahlungsjournalen für Zahlungen.
Beispiele
2023-04-15T09:02:11Z2023-04-18T14:30:00Z2023-04-25T11:21:45Z
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der den Zeitpunkt angibt, zu dem die Daten zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut erfasst Datum und Uhrzeit des letzten Datenabzugs aus Microsoft Dynamics 365. Es bietet Transparenz über die Aktualität der analysierten Daten. Für jede Prozessanalyse ist das Verständnis der Datenaktualität entscheidend für fundierte Entscheidungen. Dieser Timestamp hilft Benutzern, den Daten zu vertrauen, indem er genau anzeigt, wann sie zuletzt aktualisiert wurden, und so sicherstellt, dass Schlussfolgerungen auf aktuellen Informationen basieren.
Warum es wichtig ist
Es stellt sicher, dass Benutzer über die Aktualität der Daten informiert sind, was entscheidend für die Relevanz und Genauigkeit der Process Mining-Analyse ist.
Woher erhalten
Dies wird zum Zeitpunkt der Datenextraktion generiert und an jeden Datensatz während des Data-Ingestion-Prozesses angehängt.
Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Identifiziert das Informationssystem, aus dem die Daten stammen. | ||
|
Beschreibung
Dieses Attribut spezifiziert die Quellapplikation, in der die Event-Daten aufgezeichnet wurden. In diesem Kontext wird es typischerweise 'Microsoft Dynamics 365' sein. Obwohl es in einer Einzelsystemanalyse redundant erscheinen mag, wird es entscheidend, wenn Daten aus mehreren Systemen zusammengeführt werden, wie einem separaten CRM oder einem Lagerverwaltungssystem. Es gewährleistet die Datenherkunft und hilft bei der Fehlerbehebung von Datenextraktionsproblemen, indem es den Ursprung der Datensätze genau bestimmt.
Warum es wichtig ist
Es liefert entscheidenden Kontext zur Datenherkunft, insbesondere bei der Integration von Daten aus mehreren Systemen, und gewährleistet eine klare Datenherkunft.
Woher erhalten
Dies ist ein statischer Wert, der typischerweise während des Datentransformationsprozesses hinzugefügt wird, um den Ursprung des Datensatzes zu kennzeichnen.
Beispiele
Microsoft Dynamics 365 F&OMicrosoft Dynamics 365 Sales
|
|||
|
Angefordertes Lieferdatum
RequestedDeliveryDate
|
Das vom Kunden angefragte Lieferdatum der Bestellung. | ||
|
Beschreibung
Dieses Attribut speichert das Datum, an dem der Kunde ursprünglich den Erhalt seiner Waren angefordert hat. Dieses Datum wird zum Zeitpunkt der Auftragserstellung erfasst und dient als Basis für die Messung der Lieferperformance aus Kundensicht. Dieses Datum ist eine kritische Eingabe für das Dashboard 'Liefertermin-Einhaltung'. Der Vergleich des 'RequestedDeliveryDate' mit dem 'ConfirmedDeliveryDate' und dem tatsächlichen Datum 'Waren geliefert' zeigt, wie gut die Organisation die Kundenerwartungen erfüllt. Große Diskrepanzen können auf Probleme bei der Planung, dem Bestand oder der Logistik hinweisen.
Warum es wichtig ist
Dies dient als Kundenerwartung für die Lieferung und stellt eine wichtige Basis zur Messung der Kundenzufriedenheit und der Lieferpünktlichkeit dar.
Woher erhalten
Befindet sich in der Tabelle 'SalesTable', üblicherweise benannt als 'DeliveryDate' oder eine ähnliche Variante.
Beispiele
2023-05-102023-06-012023-05-25
|
|||
|
Auftragswert
OrderValue
|
Der gesamte monetäre Wert des Vertriebsauftrags. | ||
|
Beschreibung
Dieses Attribut repräsentiert den gesamten finanziellen Betrag des Verkaufsauftrags, einschließlich aller Artikel, Steuern und Gebühren. Es ist eine wichtige finanzielle Kennzahl, die jedem Case zugeordnet ist. Der Auftragswert ist entscheidend für eine wertorientierte Prozessanalyse. Er ermöglicht die Segmentierung des Prozesses, um zu prüfen, ob hochwertige Aufträge anders behandelt werden oder mehr Verzögerungen erfahren als geringwertige Aufträge. Dies hilft, Prozessverbesserungsbemühungen auf die finanziell bedeutendsten Cases zu priorisieren und Dashboards wie 'Verkaufsauftragswert nach Segment' zu unterstützen.
Warum es wichtig ist
Ermöglicht eine finanzielle Segmentierung des Prozesses, wodurch Verbesserungen bei hochwertigen Aufträgen priorisiert und die Kostenfolgen von Prozessabweichungen verstanden werden können.
Woher erhalten
Befindet sich in den Kopfdaten des Auftrags. Konsultieren Sie die Microsoft Dynamics 365-Dokumentation für die spezifische Tabelle und das Feld, oft berechnet aus den Auftragspositionssummen.
Beispiele
5250.7512300.00899.50
|
|||
|
Bestätigtes Lieferdatum
ConfirmedDeliveryDate
|
Das Lieferdatum, das das Unternehmen dem Kunden bestätigt und zugesagt hat. | ||
|
Beschreibung
Das Bestätigte Lieferdatum ist das Datum, das die Verkaufsorganisation dem Kunden für die Lieferung der Waren zusagt. Dieses Datum wird festgelegt, nachdem interne Prüfungen wie Bestandsverfügbarkeit und Produktionspläne abgeschlossen sind. Dieses Attribut ist essenziell für die Berechnung des KPIs Liefertreue (Delivery Date Adherence Rate) aus operativer Sicht. Es bietet einen realistischeren internen Benchmark für die pünktliche Lieferung als die ursprüngliche Kundenanfrage. Die Analyse von Abweichungen von diesem Datum hilft, interne Prozessfehler in der Logistik und im Fulfillment zu identifizieren.
Warum es wichtig ist
Dies repräsentiert die Zusage des Unternehmens gegenüber dem Kunden und ist somit ein kritischer interner Maßstab zur Messung der Auftragserfüllungszuverlässigkeit und operativen Leistung.
Woher erhalten
Befindet sich in den Auftragspositionsdaten, oft in der Tabelle 'SalesLine' mit einem Feldnamen wie 'ConfirmedDlv'.
Beispiele
2023-05-122023-06-012023-05-28
|
|||
|
Kundenname
CustomerName
|
Der Name des Kunden, der den Vertriebsauftrag aufgegeben hat. | ||
|
Beschreibung
Dieses Attribut enthält den rechtlichen Namen des Kunden, der dem Verkaufsauftrag zugeordnet ist. Es wird abgeleitet, indem die Kundenkontonummer des Verkaufsauftrags mit den Stammdaten des Hauptkunden verknüpft wird. Die Analyse des Prozesses nach Kunde ist grundlegend für das Verständnis kundenspezifischer Verhaltensweisen und Serviceniveaus. Sie hilft zu erkennen, welche Kunden die meisten Verzögerungen erfahren, welche die höchsten Nacharbeitsquoten aufweisen oder welche nicht-standardisierte Prozesspfade nutzen. Dies ist entscheidend für die Verbesserung der Kundenzufriedenheit und das effektive Management von Schlüsselkunden.
Warum es wichtig ist
Ermöglicht eine kundenorientierte Analyse, um Muster, Verzögerungen oder Probleme zu identifizieren, die spezifisch für bestimmte Kunden sind und die Kundenzufriedenheit direkt beeinflussen.
Woher erhalten
Abfrage aus der Tabelle 'CustTable' unter Verwendung des Feldes 'CustAccount' aus der Tabelle 'SalesTable'.
Beispiele
Contoso LtdAdatum CorporationFabrikam Inc.
|
|||
|
Vertriebskanal
SalesChannel
|
Der Kanal, über den der Vertriebsauftrag eingegangen ist, wie z.B. Web, Direktvertrieb oder Partner. | ||
|
Beschreibung
Der Vertriebskanal (Sales Channel) gibt den Ursprung des Kundenauftrags an. Dies könnte eine E-Commerce-Website, ein Direktvertriebsteam, ein Einzelhandelsgeschäft, ein Call Center oder ein Partnernetzwerk sein. Diese Dimension wird in Dynamics 365 oft basierend auf Geschäftsanforderungen konfiguriert. Die Analyse des Prozesses nach Vertriebskanal hilft, Leistungsunterschiede zwischen den Kanälen aufzudecken. Zum Beispiel könnten Web-Bestellungen schneller und automatischer verarbeitet werden als telefonische Bestellungen. Diese Erkenntnis ermöglicht kanalspezifische Prozessoptimierung und Ressourcenzuweisung, was Dashboards wie den Vertriebsauftragswert nach Segment (Sales Order Value by Segment) unterstützt.
Warum es wichtig ist
Ermöglicht einen Leistungsvergleich über verschiedene Vertriebskanäle hinweg, wodurch Ineffizienzen oder Best Practices identifiziert werden können, die spezifisch für die Auftragserteilung sind.
Woher erhalten
Diese Informationen werden typischerweise im Kundenauftragskopf gespeichert. Konsultieren Sie die Microsoft Dynamics 365 Dokumentation für das spezifische Feld.
Beispiele
WebDirektGeschäftspartnerRetail
|
|||
|
Artikelnummer
ItemNumber
|
Der eindeutige Identifikator für ein Produkt oder eine Dienstleistung auf dem Vertriebsauftrag. | ||
|
Beschreibung
Die Artikelnummer identifiziert das spezifische verkaufte Produkt. Da ein Vertriebsauftrag mehrere Produkte enthalten kann, ist dieses Attribut typischerweise mit Event-Daten auf der Positionsebene verknüpft. Die Analyse des Prozesses nach Produkt hilft, produktspezifische Probleme aufzudecken. Zum Beispiel können bestimmte Produkte mit längeren Fulfillment-Zeiten, höheren Nacharbeitsquoten oder häufigeren Kreditsperren verbunden sein. Dies ermöglicht gezielte Verbesserungen im Bestandsmanagement, in der Produktdatenpflege oder in den Fulfillment-Prozessen für spezifische Artikel.
Warum es wichtig ist
Ermöglicht eine Analyse auf Produktebene, die aufzeigt, ob bestimmte Artikel mit Prozessverzögerungen, Nacharbeiten oder anderen Ineffizienzen verbunden sind.
Woher erhalten
Befindet sich in der Tabelle 'SalesLine', Feld 'ItemId'.
Beispiele
PROD-00123PROD-00548SVC-00045
|
|||
|
Benutzername
UserName
|
Der Name des Benutzers, der die Aktivität ausgeführt hat. | ||
|
Beschreibung
Dieses Attribut identifiziert den spezifischen Mitarbeiter oder Systembenutzer, der für die Ausführung einer bestimmten Aufgabe verantwortlich ist, wie die Bestätigung eines Auftrags oder die Erstellung einer Rechnung. Es ist typischerweise mit einer Benutzer-ID in Microsoft Dynamics 365 verknüpft. Die Leistungsanalyse nach Benutzer hilft, Schulungsbedarfe zu identifizieren, Top-Performer zu erkennen und eine angemessene Arbeitslastverteilung sicherzustellen. Sie ist auch essenziell für Compliance- und Audit-Zwecke, da sie eine klare Rechenschaftspflicht für jede im Prozess durchgeführte Aktion ermöglicht.
Warum es wichtig ist
Es ermöglicht die Analyse der Prozessleistung nach Person oder Team, hilft bei der Identifizierung von Schulungsmöglichkeiten, Arbeitslastungleichgewichten und ressourcenbezogenen Engpässen.
Woher erhalten
Abgeleitet von Benutzer-ID-Feldern wie 'CreatedBy' oder 'ModifiedBy' in verschiedenen Transaktionstabellen, die dann mit der Hauptbenutzertabelle (z.B. UserInfo) verknüpft werden, um den vollständigen Namen zu erhalten.
Beispiele
Alice JohnsonRobert BrownSystemadministrator
|
|||
|
Durchlaufzeit
CycleTime
|
Die gesamte verstrichene Zeit von der Erstellung des Vertriebsauftrags bis zu dessen endgültigem Abschluss. | ||
|
Beschreibung
Cycle Time ist eine berechnete Metrik, die die Gesamtdauer einer Prozessinstanz misst. Für den Kundenauftragsprozess ist dies typischerweise die Zeitdifferenz zwischen dem Event 'Sales Order Created' und dem Event 'Order Closed'. Dies ist ein primärer Key Performance Indicator für die Prozesseffizienz. Dashboards und KPIs wie Overall Sales Order Cycle Time basieren direkt auf dieser Berechnung. Die Analyse ihres Durchschnitts, Medians und ihrer Verteilung hilft, die Prozessleistung zu quantifizieren, Verbesserungsziele festzulegen und die Auswirkungen von Optimierungsinitiativen zu messen.
Warum es wichtig ist
Dies ist ein wichtiger KPI für die gesamte Prozesseffizienz, der direkt die End-to-End-Zeit misst, die zur Ausführung eines Kundenauftrags benötigt wird.
Woher erhalten
Berechnet durch Subtraktion des Timestamp des ersten Event (z.B. 'Sales Order Created') vom Timestamp des letzten Event (z.B. 'Order Closed') für jede 'SalesOrderNumber'.
Beispiele
10 Tage 4 Stunden5 Tage 11 Stunden22 Tage 1 Stunde
|
|||
|
Endzeit
EndTime
|
Das genaue Datum und die Uhrzeit, zu der eine Aktivität abgeschlossen wurde. | ||
|
Beschreibung
Der Endzeit-Timestamp erfasst den Moment, in dem eine Aktivität abgeschlossen wird. Sofern verfügbar, bietet er ein genaueres Maß für die Dauer einer Aktivität, verglichen mit einer Ableitung aus der Startzeit der nächsten Aktivität. In der Analyse ermöglicht das Vorhandensein von Start- und Endzeit die präzise Berechnung der Processing Time (Bearbeitungszeit) für jede Aktivität, wodurch sie sich von der Waiting Time (Wartezeit) zwischen Aktivitäten unterscheidet. Dies ist unerlässlich, um zu identifizieren, welche spezifischen Aufgaben zeitaufwendig sind und welche Prozessschritte lange Verzögerungen mit sich bringen.
Warum es wichtig ist
Ermöglicht die präzise Berechnung individueller Aktivitätsbearbeitungszeiten, wodurch aktive Arbeitszeit von unproduktiver Wartezeit unterschieden wird.
Woher erhalten
Ähnlich wie die Startzeit wird dies aus verschiedenen Datums-/Uhrzeitfeldern abgeleitet. Es könnte ein Feld 'ModifiedDateTime' oder ein spezifischer Statusaktualisierungs-Timestamp in Tabellen wie 'SalesTable' oder 'WHSLoadTable' sein.
Beispiele
2023-04-15T09:12:30Z2023-04-18T14:35:00Z2023-04-25T11:21:55Z
|
|||
|
Ist Nacharbeit
IsRework
|
Ein boolesches Flag, das anzeigt, ob bei einem Verkaufsauftrag Nacharbeiten, wie z.B. eine wiederholte Aktivität, durchgeführt wurden. | ||
|
Beschreibung
Dieses berechnete Attribut identifiziert Cases, die von einem direkten „Happy Path“ Prozessfluss abgewichen sind. Nacharbeit wird erkannt, indem Sequenzen von Aktivitäten identifiziert werden, die auf eine Wiederholung eines Schritts hindeuten, z. B. eine Bestellung, die zurückgenommen und dann erneut bestätigt wurde, oder Waren, die kommissioniert und dann wieder eingelagert wurden. Das Markieren von Cases mit Nacharbeit ist entscheidend für den KPI 'Nacharbeitsquote bei Kundenaufträgen'. Es ermöglicht Analysten, ineffiziente Prozessabläufe schnell zu isolieren und zu untersuchen, um die Grundursachen der Nacharbeit zu ermitteln, darunter Dateneingabefehler, Kreditprobleme oder Bestandsprobleme. Die Reduzierung von Nacharbeit ist ein primäres Ziel vieler Prozessoptimierungsprojekte.
Warum es wichtig ist
Hilft, die Prozessineffizienz zu quantifizieren, indem Fälle markiert werden, die wiederholte Schritte erforderten. Dies ermöglicht eine gezielte Analyse zur Reduzierung von Verschwendung und Verzögerungen.
Woher erhalten
Dies wird vom Process Mining Tool berechnet, indem die Aktivitätensequenz für jeden Case analysiert wird. Beispielsweise würde das Erkennen eines Musters wie (A -> B -> C -> B) den Case als Nacharbeit kennzeichnen.
Beispiele
truefalsch
|
|||
|
Kundenauftragsstatus
SalesOrderStatus
|
Der aktuelle Status des Vertriebsauftrags zum Zeitpunkt der Datenextraktion. | ||
|
Beschreibung
Dieses Attribut spiegelt den Gesamtstatus des Verkaufsauftrags wider, wie 'Offener Auftrag', 'Fakturiert', 'Storniert' oder 'Geliefert'. Dies ist ein Zusammenfassungsstatus, der im Verkaufsauftragskopf geführt wird. Während das Aktivitätsprotokoll eine dynamische Sicht auf den Prozess bietet, ist der Endstatus nützlich für Filterung und Segmentierung. Er ermöglicht Analysten, alle offenen Aufträge leicht zu isolieren, um die aktuelle Arbeitslast zu überblicken, oder erfolgreich abgeschlossene Aufträge von stornierten zu trennen, um die Stornierungsgründe zu analysieren.
Warum es wichtig ist
Bietet einen Überblick über den Auftragsstatus, wodurch Analysen nach offenen, geschlossenen oder stornierten Aufträgen gefiltert werden können. Dies ist nützlich für das Arbeitslastmanagement und die Ergebnisanalyse.
Woher erhalten
Befindet sich in der Tabelle 'SalesTable', Feld 'SalesStatus'.
Beispiele
RückstandGeliefertFakturiertStorniert
|
|||
|
Land
CountryRegion
|
Das Land der Versandadresse des Kunden. | ||
|
Beschreibung
Dieses Attribut gibt das Bestimmungsland für den Verkaufsauftragsversand an. Es wird aus den in Dynamics 365 gespeicherten Lieferadressinformationen des Kunden abgeleitet. Die Analyse der Prozessleistung nach Land ist wichtig, um regionale Unterschiede zu identifizieren. Internationale Lieferungen können zusätzliche Schritte wie die Zollabfertigung erfordern, was zu längeren Durchlaufzeiten führt. Diese Analyse hilft beim Verständnis und der Optimierung der Logistik für verschiedene geografische Märkte.
Warum es wichtig ist
Ermöglicht geografische Analysen, um regionale Engpässe, Compliance-Probleme oder Leistungsschwankungen in der Lieferkette zu identifizieren.
Woher erhalten
Abgeleitet von der Lieferadresse des Kunden, die mit dem Kundenauftrag verknüpft ist. Die Länderinformationen befinden sich typischerweise in der Tabelle LogisticsPostalAddress, verknüpft über den Lieferadresslink in der SalesTable.
Beispiele
USADEUCANGBR
|
|||
|
Pünktliche Lieferung
OnTimeDelivery
|
Ein boolesches Flag, das anzeigt, ob die Waren am oder vor dem bestätigten Liefertermin geliefert wurden. | ||
|
Beschreibung
Dieses berechnete Attribut vergleicht den Timestamp der Aktivität 'Waren geliefert' mit dem 'ConfirmedDeliveryDate' für jeden Verkaufsauftrag. Es wird auf 'true' gesetzt, wenn die Lieferung pünktlich oder früher erfolgte, und auf 'false', wenn sie verspätet war. Dieses Flag ist die Basis für die Berechnung der KPI 'Liefertermin-Einhaltungsrate'. Es vereinfacht die Analyse, indem es eine einfache Filterung und Aggregation von pünktlichen gegenüber verspäteten Aufträgen ermöglicht. Dies hilft, schnell die Faktoren zu identifizieren, die mit verspäteten Lieferungen korrelieren, wie spezifische Produkte, Kunden, Regionen oder Versandmethoden.
Warum es wichtig ist
Misst direkt die Erfüllungsleistung im Vergleich zur Zusage, was entscheidend für die Überwachung der Kundenzufriedenheit und die Zuverlässigkeit der Supply Chain ist.
Woher erhalten
Berechnet durch den Vergleich des 'EventTime' der Aktivität 'Goods Delivered' mit dem Attribut 'ConfirmedDeliveryDate'. Formel: ('Goods Delivered' Timestamp <= 'ConfirmedDeliveryDate').
Beispiele
truefalsch
|
|||
|
Pünktliche Zahlung
OnTimePayment
|
Ein boolesches Flag, das anzeigt, ob die Zahlung am oder vor dem Fälligkeitsdatum eingegangen ist. | ||
|
Beschreibung
Dieses berechnete Attribut vergleicht den Timestamp der Aktivität 'Zahlung erhalten' mit dem 'PaymentDueDate'. Es wird auf 'true' gesetzt, wenn die Zahlung pünktlich erfolgte, und auf 'false', wenn sie verspätet war. Dieses Flag ist die Kernkomponente des KPI 'Pünktliche Zahlungsrate'. Es ermöglicht eine schnelle Segmentierung von Kunden in 'pünktliche' und 'verspätete' Zahler. Diese Analyse kann Kreditrichtlinien, Inkassostrategien und das Kundenbeziehungsmanagement durch die Identifizierung chronisch säumiger Kunden unterstützen.
Warum es wichtig ist
Misst das Zahlungsverhalten von Kunden im Vergleich zu vereinbarten Konditionen, was grundlegend für das Cashflow-Management und die Bewertung des Kreditrisikos ist.
Woher erhalten
Berechnet durch den Vergleich des 'EventTime' der Aktivität 'Payment Received' mit dem Attribut 'PaymentDueDate'. Formel: ('Payment Received' Timestamp <= 'PaymentDueDate').
Beispiele
truefalsch
|
|||
|
Versandmethode
ShippingMethod
|
Die Methode oder der Spediteur, der/die verwendet wird, um die Waren an den Kunden zu versenden. | ||
|
Beschreibung
Dieses Attribut spezifiziert den für die Lieferung verwendeten Transportdienst, wie 'Landversand', 'Luftfracht' oder den Namen eines bestimmten Spediteurs. Dieser wird während der Auftragsbearbeitung basierend auf Kundenpräferenz, Kosten und Liefergeschwindigkeit ausgewählt. Für das Dashboard 'Versandmethoden-Performance' ist diese Dimension essenziell. Die Analyse der Durchlaufzeiten von 'Waren verpackt' bis 'Waren geliefert', aufgeschlüsselt nach Versandmethode, hilft zu identifizieren, welche Spediteure schneller, zuverlässiger oder anfälliger für Verzögerungen sind. Diese Erkenntnis ermöglicht eine bessere Logistikplanung und Spediteur-Auswahl.
Warum es wichtig ist
Ermöglicht eine Leistungsanalyse verschiedener Spediteure und Versandoptionen und hilft, die Logistik hinsichtlich Kosten, Geschwindigkeit und Zuverlässigkeit zu optimieren.
Woher erhalten
Diese Informationen werden typischerweise im Kundenauftragskopf oder in zugehörigen Ausführungsdatensätzen gespeichert. Konsultieren Sie die Microsoft Dynamics 365 Dokumentation.
Beispiele
FedEx GroundUPS Next Day AirDHL Express
|
|||
|
Zahlungsfälligkeitsdatum
PaymentDueDate
|
Das Datum, bis zu dem der Kunde die Rechnung begleichen muss. | ||
|
Beschreibung
Das Zahlungsfälligkeitsdatum (Payment Due Date) wird basierend auf dem Rechnungsdatum und den mit dem Kunden vereinbarten Zahlungsbedingungen berechnet. Dieses Datum wird auf der Kundenrechnung erfasst. Dieses Attribut ist grundlegend für die Analyse der Zahlungsfälligkeits-Compliance (Payment Due Date Compliance) und den KPI Pünktliche Zahlungsquote (On-Time Payment Rate). Durch den Vergleich des PaymentDueDate mit dem tatsächlichen Payment Received-Datum kann das Unternehmen Zahlungsverzüge identifizieren, das Zahlungsverhalten nach Kundensegmenten analysieren und proaktive Maßnahmen ergreifen, um den Cashflow zu verbessern und die Days Sales Outstanding (DSO) zu reduzieren.
Warum es wichtig ist
Dies ist der Benchmark zur Messung der Zahlungsleistung, der entscheidend ist für die Analyse des Cashflows und das effektive Management der Debitorenbuchhaltung.
Woher erhalten
Befindet sich in der Tabelle 'CustInvoiceJour', Feld 'DueDate'.
Beispiele
2023-05-302023-06-152023-06-30
|
|||
Order-to-Cash - Aktivitäten der Vertriebsauftragsabwicklung
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Auftrag bestätigt
|
Diese Aktivität bedeutet die formale Bestätigung des Verkaufsauftrags, wodurch die Lieferung der angegebenen Waren oder Dienstleistungen zugesagt wird. In Dynamics 365 ist dies eine explizite Benutzeraktion, die ein Bestätigungsprotokoll erzeugt. | ||
|
Warum es wichtig ist
Die Bestätigung ist ein wichtiger Meilenstein, der den Abwicklungsprozess offiziell einleitet. Die Messung der Zeit von der Erstellung bis zur Bestätigung zeigt die Effizienz der Front-Office-Verarbeitung auf.
Woher erhalten
Dies ist ein explizites Event, das vom Buchungsdatum des Kundenauftragsbestätigungsjournals (SalesConfirmJour) erfasst wird. Der Timestamp kann mit der SalesTable verknüpft werden.
Erfassen
Erfassen Sie den Buchungs-Timestamp des Kundenauftragsbestätigungs-Journals.
Ereignistyp
explicit
|
|||
|
Auftrag geschlossen
|
Der finale Status eines erfolgreich bearbeiteten Vertriebsauftrags, der anzeigt, dass er vollständig versendet, fakturiert wurde und keine weiteren Transaktionen erwartet werden. Dies markiert den erfolgreichen Abschluss des Prozesses. | ||
|
Warum es wichtig ist
Diese Aktivität dient als primärer Endpunkt für erfolgreich abgeschlossene Cases. Sie ist wesentlich für die Berechnung von End-to-End-Durchlaufzeiten und des Durchsatzes.
Woher erhalten
Dies wird aus den Statusfeldern auf der SalesTable abgeleitet. Ein Auftrag gilt als abgeschlossen, wenn der 'Verkaufsstatus' 'Fakturiert' ist und die Zeilenstatus ebenfalls 'Fakturiert' sind.
Erfassen
Ableitung aus der Statusänderung der SalesTable-Felder zu 'Invoiced'. Der Timestamp ist typischerweise das letzte zugehörige Transaktionsdatum, wie Rechnungsstellung oder Zahlung.
Ereignistyp
inferred
|
|||
|
Kundenauftrag erstellt
|
Dieses Event markiert die erste Erstellung des Kundenauftrags im System durch einen Vertriebsmitarbeiter oder über einen automatisierten Kanal. Es wird explizit erfasst, wenn ein neuer Datensatz in der primären Kundenauftragstabelle erstellt und gespeichert wird. | ||
|
Warum es wichtig ist
Diese Aktivität ist der universelle Startpunkt für alle Verkaufsauftrags-Cases. Sie liefert den ersten Timestamp, der für die Berechnung der gesamten Verkaufsauftrags-Durchlaufzeit und die Analyse des Durchsatzes erforderlich ist.
Woher erhalten
Dies ist ein explizites Event, das aus dem Feld 'Erstellungsdatum und -zeit' auf dem SalesTable-Kopfsatz in Microsoft Dynamics 365 erfasst wird.
Erfassen
Liest den Erstellungs-Timestamp aus der SalesTable-Entität.
Ereignistyp
explicit
|
|||
|
Rechnung erstellt
|
Dies stellt die Generierung und Buchung der Verkaufsrechnung für die versandten Waren oder Dienstleistungen dar. Dies ist eine zentrale Finanztransaktion, die die Kundenschuld formal erfasst. | ||
|
Warum es wichtig ist
Diese Aktivität markiert den Beginn des finanziellen Abrechnungsteils des Prozesses. Die Zeit von der Lieferung bis zur Rechnungsstellung ist entscheidend für den KPI 'Rechnungsstellung-Durchlaufzeit' und beeinflusst den Cashflow.
Woher erhalten
Dies ist eine explizite Finanztransaktion. Das Event wird vom Buchungsdatum und der Uhrzeit des Verkaufsrechnungsjournals (CustInvoiceJour) erfasst.
Erfassen
Erfassen Sie den Buchungs-Timestamp des Verkaufsrechnungs-Journals.
Ereignistyp
explicit
|
|||
|
Waren versandt
|
Dieses Event bedeutet, dass die verpackten Waren für den Auftrag versandt wurden und das Lager verlassen haben. In Dynamics 365 wird dies durch das Buchen des Lieferscheins formalisiert. | ||
|
Warum es wichtig ist
Dies ist ein kritischer Meilenstein, der das Ende des internen Ausführungsprozesses und den Beginn der Lieferphase markiert. Es ist ein wichtiger Timestamp zur Berechnung der Pünktlichkeit der Lieferleistung.
Woher erhalten
Dies ist ein sehr klares und explizites Event, das vom Buchungsdatum und der Uhrzeit des Lieferschein-Journals (CustPackingSlipJour) erfasst wird.
Erfassen
Erfassen Sie den Buchungs-Timestamp des Lieferschein-Journals.
Ereignistyp
explicit
|
|||
|
Zahlung eingegangen
|
Diese Aktivität bedeutet, dass die Zahlung des Kunden für die Rechnung eingegangen und verbucht wurde. Dieses Event findet im Accounts Receivable Modul statt und ist mit der ursprünglichen Rechnung verknüpft. | ||
|
Warum es wichtig ist
Dies ist ein kritischer Meilenstein für die Analyse des Geldumschlagzyklus. Er ist unerlässlich zur Messung des KPI 'Pünktliche Zahlungsquote' und zur Identifizierung von Verzögerungen beim Zahlungseinzug.
Woher erhalten
Dies ist ein explizites Event aus dem Debitorenbuchhaltungsmodul. Es wird vom Transaktionsdatum der Kundenzahlungsabwicklung (CustSettlement) erfasst, die die Rechnungsbuchung (CustTrans) abschließt.
Erfassen
Erfassen Sie das Abrechnungsdatum aus der Tabelle CustSettlement, verknüpfen Sie es zurück mit der Rechnung und dem Kundenauftrag.
Ereignistyp
explicit
|
|||
|
An Lager freigegeben
|
Bezeichnet den Zeitpunkt, an dem der Vertriebsauftrag formell an das Lager für Kommissionier- und Versandvorgänge freigegeben wird. Dies ist ein eigenständiger Schritt in Umgebungen, die das Warehouse Management (WMS) Modul nutzen. | ||
|
Warum es wichtig ist
Diese Aktivität trennt die Auftragsbearbeitung von der physischen Ausführung. Die Analyse der Wartezeit eines Auftrags bis zur Freigabe kann Probleme bei der Ressourcenplanung oder der Systemintegration aufzeigen.
Woher erhalten
Dies ist ein explizites Event, das aus den Lagerfreigabedatensätzen (WHSLoadTable, WHSShipmentTable) erfasst wird, die mit dem Kundenauftrag verknüpft sind.
Erfassen
Erfassen Sie den Erstellungs-Timestamp der entsprechenden Lagerbeladung oder Sendung.
Ereignistyp
explicit
|
|||
|
Auftrag storniert
|
Dieses Event stellt die Stornierung eines Kundenauftrags dar, bevor er vollständig versandt und fakturiert wurde. Dies ist ein alternatives, erfolgloses Ende des Prozesses. | ||
|
Warum es wichtig ist
Die Verfolgung von Stornierungen hilft, Gründe für verlorene Verkäufe oder Prozessfehler zu identifizieren. Die Analyse, wann und warum Aufträge storniert werden, kann zu Prozessverbesserungen führen.
Woher erhalten
Dies wird aus dem Feld 'Verkaufsstatus' auf der SalesTable abgeleitet, das sich in 'Storniert' ändert. Der Timestamp wäre der Zeitpunkt, zu dem diese Statusänderung protokolliert wurde.
Erfassen
Ableitung aus der Statusfeldänderung der SalesTable zu 'Canceled'.
Ereignistyp
inferred
|
|||
|
Bestand reserviert
|
Dieses Event zeigt an, dass der erforderliche Bestand für die Kundenauftragszeilen physisch oder automatisch im System reserviert wurde. Dies stellt sicher, dass die Artikel zur Kommissionierung und Auslieferung verfügbar sind. | ||
|
Warum es wichtig ist
Die Verfolgung der Bestandsreservierung hilft, Verzögerungen zwischen Auftragsbestätigung und dem Beginn der Lageroperationen zu analysieren. Sie ist entscheidend für den KPI 'Vorlaufzeit der Bestandsallokation'.
Woher erhalten
Dies kann aus der Erstellung oder Aktualisierung von Bestandsbuchungsdatensätzen (InventTrans) abgeleitet werden, die mit den Kundenauftragszeilen verknüpft sind und bei denen der Status eine Reservierung anzeigt (z.B. „In Bestellung“, „Physisch reserviert“).
Erfassen
Ableitung vom Timestamp, wenn Bestandstransaktionen (InventTrans) für den Auftrag als reserviert markiert werden.
Ereignistyp
inferred
|
|||
|
Kreditprüfung durchgeführt
|
Repräsentiert den Abschluss einer Kreditprüfung für den dem Kundenauftrag zugeordneten Kunden. Dies kann eine automatisierte Systemprüfung oder eine manuelle Überprüfung sein und führt oft zu einer Änderung des Kreditstatus des Auftrags. | ||
|
Warum es wichtig ist
Die Analyse der Dauer und Ergebnisse von Kreditprüfungen hilft dabei, Bottlenecks im Auftragsgenehmigungsprozess zu identifizieren. Häufige Wartezeiten oder lange Genehmigungsdauern können die Auftragserfüllung erheblich verzögern.
Woher erhalten
Typischerweise abgeleitet aus Statusänderungen im Zusammenhang mit dem Kreditmanagement auf der SalesTable, wie dem Wechsel von 'In Wartestellung' mit einem Kreditgrund zu 'Offen'. Es kann auch in Kreditmanagementtabellen protokolliert werden, wenn das erweiterte Modul verwendet wird.
Erfassen
Ableitung aus der Historie der Statusänderungen in der SalesTable oder zugehörigen Kredit-Sperr-Tabellen.
Ereignistyp
inferred
|
|||
|
Waren geliefert
|
Zeigt an, dass die Sendung erfolgreich an die vom Kunden angegebene Adresse geliefert wurde. Diese Information wird oft aus dem System eines externen Spediteurs oder durch eine manuelle Bestätigung aktualisiert. | ||
|
Warum es wichtig ist
Diese Aktivität ist entscheidend für die Messung des KPI 'Liefertermin-Einhaltung' und das Verständnis der tatsächlichen kundenrelevanten Durchlaufzeit. Sie unterstützt die Bewertung der Leistung von Transportdienstleistern.
Woher erhalten
Dies wird nicht nativ als explizites Event in Standard D365 verfolgt. Es wird typischerweise abgeleitet, indem ein Update von einer Speditionsintegration oder durch eine manuelle Statusaktualisierung des Kundenauftrags- oder Lieferdatensatzes empfangen wird.
Erfassen
Ableitung aus einem integrierten Speditions-Feed oder einer manuellen Statusfeldaktualisierung.
Ereignistyp
inferred
|
|||
|
Waren kommissioniert
|
Dies repräsentiert den Abschluss der physischen Kommissionierung aller Artikel für den Auftrag aus den Lagerorten. Die Erfassung erfolgt typischerweise, wenn ein Kommissionierer eine Kommissionierliste oder einen Arbeitsauftrag im WMS-Modul abschließt. | ||
|
Warum es wichtig ist
Die Verfolgung der Kommissionierungsabschlusszeit ist unerlässlich für die Analyse der Lagereffizienz. Verzögerungen in dieser Phase wirken sich direkt auf die gesamte Lieferzeit aus.
Woher erhalten
Dies ist ein explizites Event, das im Lagermanagementmodul aufgezeichnet wird. Es wird vom Abschluss-Timestamp der Lagerarbeit (WHSWorkTable) erfasst, die mit der Kundenauftragskommissionierung im Zusammenhang steht.
Erfassen
Erfassen Sie den Timestamp, wann der Kommissionierstatus 'Work' auf 'Closed' aktualisiert wird.
Ereignistyp
explicit
|
|||
|
Waren verpackt
|
Diese Aktivität markiert den Abschluss des Verpackungsprozesses, bei dem kommissionierte Artikel konsolidiert und für den Versand vorbereitet werden. In D365 kann dies mit der Erstellung eines Lieferscheins zusammenfallen. | ||
|
Warum es wichtig ist
Die Zeit zwischen Kommissionierung und Verpackung kann Engpässe an den Packstationen aufdecken. Es ist ein wichtiger Teilprozess innerhalb der gesamten Fulfillment-Zykluszeit.
Woher erhalten
Dies kann ein explizites Event aus dem Abschluss der Behälterverpackung im WMS-Modul sein oder aus der Erstellung des Lieferschein-Journals (CustPackingSlipJour) abgeleitet werden, das oft das Ende der Verpackung markiert.
Erfassen
Ableitung aus dem Abschluss der Verpackungsarbeiten oder dem Erstellungsdatum des Lieferscheinjournals.
Ereignistyp
inferred
|
|||