Ihr Daten-Template für das Transportmanagement
Ihr Daten-Template für das Transportmanagement
- Empfohlene Attribute für eine umfassende Analyse
- Wichtige Aktivitäten für die Prozessentdeckung
- Detaillierte Anleitung zur Datenextraktion aus Blue Yonder TMS
Attribute des Transportmanagements
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivität ActivityName | Bezeichnung des konkreten Geschäftsereignisses oder der Aktivität, die zu einem bestimmten Zeitpunkt für eine Sendung stattgefunden hat. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt im Transportprozess, zum Beispiel „Sendung geplant“, „Frachtführer angefragt“ oder „Ware zugestellt“. Die Aktivitäten bilden die Knoten der ermittelten Prozesslandkarte. Ihre Reihenfolge bestimmt den Prozessablauf für jede Sendung. Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten ist ein Kernbestandteil des Process Mining. Sie hilft, häufige Prozesspfade (Varianten) zu erkennen, Engpässe durch verzögerte Aktivitäten aufzudecken und Schleifen mit erneuter Bearbeitung zu finden, etwa wenn ein Transportangebot wiederholt abgelehnt wird. Warum das wichtig ist Das Attribut legt die Prozessschritte fest. So lässt sich der Sendungsverlauf visualisieren und die Effizienz des Prozesses beurteilen. Woher beziehen Abgeleitet aus Event Logs, Statusänderungsdatensätzen oder Transaktionscodes in verschiedenen Modulen von Blue Yonder TMS. Häufig müssen System-Events dafür verständlichen Aktivitätsbezeichnungen zugeordnet werden. Beispiele Sendung geplantFrachtführer angefragtWare zugestelltZahlung verarbeitet | |||
| Sendung ShipmentId | Eindeutige Kennung einer einzelnen Sendung. Sie dient als Case-ID für den Transportprozess. | ||
| Beschreibung Die Sendungs-ID ist der zentrale Schlüssel, der alle Aktivitäten und Events zur Beförderung der Ware vom Ausgangspunkt bis zum Ziel verknüpft. Jede eindeutige ID steht für einen vollständigen Transportfall, von der ersten Anfrage bis zur abschließenden Zahlung. Für das Process Mining ist dieses Attribut grundlegend, um den durchgängigen Ablauf jeder Sendung zu rekonstruieren. Es ermöglicht, Events wie „Sendung geplant“, „Ware abgeholt“ und „Ware zugestellt“ zu einem zusammenhängenden Prozessablauf zu gruppieren. So lassen sich Zykluszeiten berechnen und Prozessvarianten für einzelne Sendungen erkennen. Warum das wichtig ist Dies ist die zentrale Case-ID, die alle zugehörigen Transport-Events verknüpft und so die Analyse des gesamten Lebenszyklus einer Sendung ermöglicht. Woher beziehen Dies ist ein Primärschlüssel in den Modulen zur Sendungs- oder Ladungsverwaltung von Blue Yonder TMS. Informationen zur konkreten Tabelle finden Sie in der Systemdokumentation. Wahrscheinlich handelt es sich um eine Tabelle mit Sendungskopfdaten. Beispiele SHP-0012845SHP-0012991SHP-0013054 | |||
| Startzeit EventTime | Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Event stattgefunden hat. | ||
| Beschreibung Die Ereigniszeit gibt für jede Aktivität im Sendungsprozess das genaue Datum und die genaue Uhrzeit an. Sie bildet die chronologische Grundlage des Event Logs. Damit lassen sich Aktivitäten ordnen und Zeitspannen zwischen ihnen berechnen. Für die Analyse ist dieser Timestamp entscheidend, um zeitbezogene KPIs zu berechnen, etwa die durchgängige Zykluszeit der Sendung, die Dauer der Zollabfertigung und die Leistung bei termingerechter Lieferung. Er zeigt, wann Verzögerungen auftreten und wie lange die einzelnen Prozessphasen dauern. Warum das wichtig ist Dieser Timestamp ist wichtig, um Events zu ordnen, Zykluszeiten zu berechnen und die Prozessleistung im Zeitverlauf zu analysieren. Woher beziehen Dieser Timestamp findet sich in der Regel neben Status- oder Ereignisdatensätzen in den Transaktionsprotokollen von Blue Yonder TMS. Jedem Event und jeder Statusänderung sollte ein Timestamp zugeordnet sein. Beispiele 2023-04-15T09:00:00Z2023-04-16T14:30:00Z2023-04-25T11:15:00Z | |||
| Letzte Datenaktualisierung LastDataUpdate | Timestamp der letzten Aktualisierung oder Extraktion der Daten dieses Datensatzes aus dem Quellsystem. | ||
| Beschreibung Dieses Attribut gibt an, wie aktuell die Daten sind. Es erfasst Datum und Uhrzeit der letzten Aktualisierung des Event Logs aus Blue Yonder TMS. Für die Analyse ist dies wichtig, um die Aktualität der Dashboards und KPIs einzuschätzen. Benutzer sehen, ob sie Echtzeitinformationen oder Daten aus einem früheren Zeitraum betrachten. Das ist entscheidend für fundierte operative Entscheidungen. Warum das wichtig ist Das Attribut zeigt Benutzern, wie aktuell die Daten sind. Das ist wichtig für die Aussagekraft und Genauigkeit der Analyse. Woher beziehen Dieses Metadatenfeld wird in der Regel während der Datenextraktion (ETL) erstellt und hinzugefügt. Beispiele 2023-05-20T02:00:00Z2023-05-21T02:00:00Z | |||
| Quellsystem SourceSystem | Gibt an, aus welchem System die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt die Herkunft der Event-Daten an, in diesem Fall Blue Yonder TMS. Es ist besonders hilfreich, wenn Daten aus mehreren Systemen für eine übergreifende Prozesssicht zusammengeführt werden. Bei der Analyse erleichtert es die Filterung der Daten und hilft, ihren Kontext zu verstehen. Die Herkunftsinformationen zu erhalten, sichert die Datenherkunft und gilt als bewährte Praxis der Data Governance. Warum das wichtig ist Das Attribut liefert wichtige Informationen zur Datenherkunft. So bleiben die Daten nachvollziehbar und lassen sich aus mehreren Quellen verwalten. Woher beziehen In der Regel handelt es sich um einen statischen Wert, der während der Datenextraktion, -transformation und -ladung (ETL) hinzugefügt wird. Beispiele Blue Yonder TMSBY_TMS_NABY_TMS_EMEA | |||
| Angefordertes Lieferdatum RequestedDeliveryDate | Das vom Kunden gewünschte oder im Kundenauftrag vorgegebene Lieferdatum. | ||
| Beschreibung Dieses Attribut erfasst das angestrebte Lieferdatum des Logistikprozesses. Es entspricht den Erwartungen des Kunden oder der internen Service-Level-Vereinbarung (SLA) für die Sendung. Dieses Datum dient als Grundlage für die Berechnung der KPI „Pünktlichkeitsquote bei der Lieferung“. Durch den Vergleich von „ActualDeliveryTime“ und „RequestedDeliveryDate“ lässt sich feststellen, ob eine Sendung zu früh, pünktlich oder verspätet zugestellt wurde. Das ist eine wichtige Kennzahl im Dashboard „Leistung bei pünktlicher Abholung und Lieferung“. Warum das wichtig ist Das Attribut dient als zentrale Vergleichsgröße für die Messung der Pünktlichkeit bei der Lieferung und der Kundenzufriedenheit. Woher beziehen Diese Information stammt in der Regel aus einem vorgelagerten System wie einem ERP oder Auftragsverwaltungssystem und wird in den Sendungsanfragedetails von Blue Yonder TMS gespeichert. Beispiele 2023-04-25T23:59:59Z2023-05-10T17:00:00Z | |||
| Bestimmungsland DestinationCountry | Land, in das die Sendung geliefert wird. | ||
| Beschreibung Dieses Attribut gibt das Bestimmungsland der Sendung an. Es wird aus der Adresse des Empfängers oder den Angaben zum Lieferort abgeleitet. Wie das Herkunftsland dient auch dieses Attribut der geografischen Segmentierung. Damit können Analysten die Leistung auf verschiedenen Handelsrouten vergleichen, etwa USA nach Kanada gegenüber USA nach Mexiko, Herausforderungen bei der Zustellung in bestimmten Ländern untersuchen und den Einfluss grenzüberschreitender Komplexität auf Zykluszeiten bewerten. Warum das wichtig ist Das Attribut ermöglicht die Analyse der Leistung nach Bestimmungsland. Das ist wichtig, um die Komplexität von Handelsrouten und regionale Herausforderungen bei der Zustellung zu verstehen. Woher beziehen Wird in den Sendungsdetails von Blue Yonder TMS als Teil der Daten zum Bestimmungsort oder zur Adresse des Empfängers gespeichert. Beispiele KanadaMexikoVereinigtes Königreich | |||
| Herkunftsland OriginCountry | Land, aus dem die Sendung stammt. | ||
| Beschreibung Dieses Attribut gibt das Ausgangsland der Sendung an. Es wird aus der Adresse des Versenders oder den Angaben zum Abholort abgeleitet. Bei der Analyse ermöglicht das Herkunftsland eine aussagekräftige Segmentierung der Daten. So lassen sich regionale Unterschiede bei Prozessleistung, Verfügbarkeit von Frachtführern und Zykluszeiten erkennen. Für die Analyse der Zollabfertigungszeiten internationaler Sendungen ist das Attribut besonders wichtig. Warum das wichtig ist Das Attribut ermöglicht eine geografische Analyse der Prozessleistung und hilft, regionale Engpässe oder Effizienzunterschiede zu erkennen. Woher beziehen Wird in den Sendungsdetails von Blue Yonder TMS als Teil der Daten zum Ausgangsort oder zur Adresse des Versenders gespeichert. Beispiele USADeutschlandChina | |||
| Name des Frachtführers CarrierName | Name des Transportunternehmens oder Logistikdienstleisters, das beziehungsweise der für den Transport der Sendung verantwortlich ist. | ||
| Beschreibung Der Name des Frachtführers bezeichnet das externe Unternehmen, das mit dem Transport der Ware beauftragt wurde. Dabei kann es sich um ein Transportunternehmen, eine Fluggesellschaft, eine Reederei oder einen Spediteur handeln. Dieses Attribut ist wichtig für die Leistungsanalyse, insbesondere im Dashboard „Leistungsvergleich der Frachtführer“. Es ermöglicht, Daten zu filtern und nach Frachtführer aufzuschlüsseln, um beispielsweise Pünktlichkeitsquoten, die Einhaltung von Abholterminen und durchschnittliche Verzögerungen zu vergleichen. Das unterstützt die strategische Auswahl von Frachtführern und die Pflege der Geschäftsbeziehungen. Warum das wichtig ist Das Attribut ermöglicht den Leistungsvergleich verschiedener Frachtführer. So können Sie die Auswahl optimieren und die Servicequalität verbessern. Woher beziehen Zu finden in den Sendungs- oder Ladungsdetails von Blue Yonder TMS, häufig über eine Verknüpfung mit einer Stammdatentabelle der Frachtführer. Beispiele Global Shipping Inc.FastLane LogisticsAirExpress Cargo | |||
| Sendungsstatus ShipmentStatus | Aktueller oder zuletzt bekannter Status der Sendung. | ||
| Beschreibung Der Sendungsstatus gibt den aktuellen Stand der Sendung in ihrem Lebenszyklus an, zum Beispiel „Geplant“, „Unterwegs“, „Zugestellt“ oder „Storniert“. Er zeigt, an welcher Stelle des Prozesses sich die Sendung befindet. Beim Process Mining ist der Endstatus der Cases wichtig für die Ergebnisanalyse. Ein Vergleich der Prozessabläufe zugestellter und stornierter Sendungen kann beispielsweise Muster aufdecken, die zu unerwünschten Ergebnissen führen. Außerdem lässt sich die aktuelle Arbeitslast überwachen, indem noch nicht abgeschlossene Sendungen gefiltert werden. Warum das wichtig ist Das Attribut gibt einen schnellen Überblick über den aktuellen Stand der Sendung und unterscheidet abgeschlossene, laufende und stornierte Sendungen. Woher beziehen Dies ist ein wichtiges Feld im Sendungskopf oder in der zentralen Statustabelle von Blue Yonder TMS. Beispiele GeplantUnterwegsZugestelltStorniert | |||
| Tatsächlicher Lieferzeitpunkt ActualDeliveryTime | Der tatsächliche Timestamp des Events „Ware zugestellt“. | ||
| Beschreibung Dieses Attribut enthält den Timestamp der abschließenden Zustellaktivität. Es erfasst genau, wann die Sendung ihren Bestimmungsort erreicht hat und die Zustellung bestätigt wurde. Dieser Datenpunkt ist entscheidend für die Leistungsmessung. Die KPI „Pünktlichkeitsquote bei der Lieferung“ wird berechnet, indem dieser Timestamp mit „RequestedDeliveryDate“ verglichen wird. Außerdem markiert er den Endpunkt für die Berechnung der KPI „Gesamtdurchlaufzeit bis zur Zustellung“. Warum das wichtig ist Dieser Timestamp ist wichtig, um die Pünktlichkeitsquote bei der Lieferung und die gesamte Transportzeit der Sendung zu berechnen. Woher beziehen Dies ist der Timestamp der Statusmeldung „Ware zugestellt“. Sie geht häufig per EDI-Nachricht des Frachtführers ein oder wird manuell in Blue Yonder TMS erfasst. Beispiele 2023-04-25T11:15:00Z2023-05-11T09:30:00Z | |||
| Transportmittel ModeOfTransport | Transportart der Sendung, zum Beispiel Lkw, Luftfracht, Seefracht oder Schiene. | ||
| Beschreibung Dieses Attribut gibt das Transportmittel an. Übliche Werte sind Teilladung (LTL), Komplettladung (FTL), Luftfracht, Seefracht und Schiene. Bei der Prozessanalyse ist das Transportmittel eine wichtige Auswertungsdimension. Prozesse, Zykluszeiten und Kosten können sich je nach Transportmittel deutlich unterscheiden. Die „Engpassanalyse bei der Zollabfertigung“ ist beispielsweise für Luft- und Seefracht besonders relevant, für innerstaatliche Lkw-Transporte hingegen weniger. Eine Auswertung nach Transportmittel hilft, Verbesserungsmaßnahmen auf die jeweiligen logistischen Rahmenbedingungen abzustimmen. Warum das wichtig ist Das Attribut ermöglicht eine segmentierte Analyse, da sich Prozesse, Kosten und typische Zykluszeiten je nach Transportmittel unterscheiden. Woher beziehen Dies ist ein Standardfeld in den Modulen für Sendungsplanung und Frachtratenberechnung von Blue Yonder TMS. Beispiele LTLFTLLuftfrachtSeefracht | |||
| Abweichung bei der Frachtrechnung FreightBillDiscrepancyReason | Code oder Beschreibung des Grundes, aus dem eine Frachtrechnung die Prüfung nicht bestanden hat. | ||
| Beschreibung Ergibt die Prüfung einer Frachtrechnung eine Abweichung, gibt dieses Attribut den Grund an. Beispiele sind „Falsche Frachtrate“, „Doppelte Rechnung“ oder „Zustellnachweis fehlt“. Dieses Attribut ist wichtig für das Dashboard „Zustellnachweis und Abrechnungsgenauigkeit“ und die KPI „Anteil erneut bearbeiteter Frachtrechnungen“. Die Häufigkeit der verschiedenen Abweichungsgründe zeigt die Ursachen von Abrechnungsfehlern. Diese können auf Fehler des Frachtführers, Abweichungen von den Vertragsbedingungen oder interne Prozessprobleme zurückgehen. So lassen sich gezielte Maßnahmen ergreifen, um die erneute Bearbeitung von Rechnungen zu verringern. Warum das wichtig ist Das Attribut zeigt die Ursachen von Abrechnungsfehlern auf und ermöglicht gezielte Verbesserungen, um die erneute Bearbeitung von Frachtrechnungen und Zahlungsverzögerungen zu verringern. Woher beziehen Zu finden im Modul für Frachtprüfung und Zahlung von Blue Yonder TMS, verknüpft mit Ausnahme- oder Ablehnungsprotokollen. Beispiele Falsche Frachtrate angewendetDoppelte RechnungStreitfall zu Zusatzkosten | |||
| Benutzer User | Benutzer-ID oder Name der Person, die die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut bezeichnet den Logistikplaner, Koordinator oder Systembenutzer, der im TMS ein bestimmtes Event oder eine Statusänderung ausgeführt hat. Bei automatisierten Events kann es sich um die ID eines System- oder Dienstkontos handeln. Eine Auswertung nach Benutzer hilft, die Verteilung der Arbeitslast, die individuelle Leistung und den Schulungsbedarf zu verstehen. Sie kann zeigen, ob bestimmte Benutzer häufiger mit erneuter Bearbeitung oder Verzögerungen verbunden sind oder ob einzelne Teams effizienter arbeiten. Das unterstützt die Ressourcenplanung und gezielte Prozessverbesserungen. Warum das wichtig ist Das Attribut ermöglicht die Analyse von Leistung und Arbeitslast nach Benutzer oder Team. So lassen sich Schulungsbedarf und Ressourcenengpässe erkennen. Woher beziehen Diese Information sollte in den Transaktions- oder Ereignisprotokollen verfügbar sein, häufig in einem Feld wie „Geändert von“ oder „Benutzer-ID“, das dem jeweiligen Datensatz zugeordnet ist. Beispiele j.doea.smithTMS_AUTOMATION_USER | |||
| Geplanter Abholzeitpunkt ScheduledPickupTime | Geplantes Datum und geplante Uhrzeit, zu denen der Frachtführer die Ware am Ausgangsort abholen soll. | ||
| Beschreibung Dieses Attribut enthält den mit dem Frachtführer vereinbarten Abholtermin für die Sendung. Er ist ein wichtiger Meilenstein im Sendungsplan. Der Timestamp dient als Grundlage für die Berechnung der KPIs „Pünktlichkeitsquote bei der Abholung“ und „Durchschnittliche Abholverzögerung“. Der Vergleich mit „ActualPickupTime“ zeigt Verzögerungen zu Beginn des Sendungsverlaufs. Diese können sich auf nachfolgende Meilensteine auswirken. Warum das wichtig ist Der geplante Abholzeitpunkt dient als Vergleichsgröße für die Messung der Pünktlichkeit bei der Abholung und gibt Aufschluss über die Zuverlässigkeit des Frachtführers und die Genauigkeit der Planung. Woher beziehen Zu finden in den Modulen für Terminplanung oder Ladungsplanung von Blue Yonder TMS. Beispiele 2023-04-16T14:00:00Z2023-05-02T10:00:00Z | |||
| Pünktliche Lieferung IsOnTimeDelivery | Ein berechnetes Kennzeichen, das angibt, ob die Sendung am angeforderten Liefertermin oder früher zugestellt wurde. | ||
| Beschreibung Dieses boolesche Attribut wird durch den Vergleich von 'ActualDeliveryTime' mit 'RequestedDeliveryDate' berechnet. Es ist wahr, wenn die tatsächliche Lieferung am angeforderten Termin oder früher erfolgt ist, andernfalls falsch. Als berechnete Kennzahl vereinfacht es die Analyse und Visualisierung der KPI „Pünktliche Lieferquote“. Damit können Sie einfach filtern und aggregieren und Dashboards erstellen, die den Anteil pünktlicher Lieferungen im Zeitverlauf sowie nach Frachtführer oder Transportart zeigen. So unterstützt es direkt das Dashboard „Pünktlichkeit bei Abholung und Lieferung“. Warum das wichtig ist Damit lässt sich die Pünktlichkeit einfacher analysieren. Außerdem können Sie Daten in Dashboards und KPIs schnell filtern und aggregieren. Woher beziehen Dieses Attribut ist im Quellsystem nicht vorhanden. Es wird während der Datentransformation anhand der Formel berechnet: ActualDeliveryTime <= RequestedDeliveryDate. Beispiele truefalse | |||
| Tatsächlicher Abholzeitpunkt ActualPickupTime | Der tatsächliche Timestamp des Events „Ware abgeholt“. | ||
| Beschreibung Dieses Attribut erfasst genau, wann der Frachtführer die Sendung am Ausgangsort physisch übernommen hat. Damit beginnt offiziell die Transportphase. Dieser Datenpunkt ist wichtig für die Leistungsmessung des Frachtführers. Der Vergleich mit „ScheduledPickupTime“ ermöglicht die Berechnung der KPIs „Pünktlichkeitsquote bei der Abholung“ und „Durchschnittliche Abholverzögerung“. Eine Analyse der Abweichungen hilft, Probleme bei bestimmten Frachtführern oder Abholorten zu erkennen. Warum das wichtig ist Mit diesem Timestamp lässt sich die Pünktlichkeit der Abholung genau messen und Verzögerungen zu Beginn des Transportprozesses erkennen. Woher beziehen Dies ist der Timestamp der Statusmeldung „Ware abgeholt“. Er geht in der Regel per EDI vom Frachtführer ein oder wird manuell in Blue Yonder TMS erfasst. Beispiele 2023-04-16T14:30:00Z2023-05-02T10:15:00Z | |||
| Verzögerungsgrund DelayReason | Code oder Text, der den Grund für eine Verzögerung bei der Abholung oder Zustellung angibt. | ||
| Beschreibung Dieses Attribut erfasst den angegebenen Grund dafür, dass ein Sendungsmeilenstein nicht erreicht wurde. Beispiele sind „Wetterbedingte Verzögerung“, „Zollbedingte Verzögerung“ oder „Kapazitätsengpass beim Frachtführer“. Die Information stammt häufig vom Frachtführer. Das Attribut ist wichtig für das Dashboard „Leistung bei pünktlicher Abholung und Lieferung“. Es zeigt nicht nur, dass eine Sendung verspätet war, sondern auch warum. Die häufigsten Verzögerungsgründe helfen dem Logistikteam, Risiken frühzeitig zu mindern und wiederkehrende Probleme gemeinsam mit den Frachtführern anzugehen. Warum das wichtig ist Das Attribut zeigt die Ursachen von Verzögerungen auf und ermöglicht ein vorausschauendes Risikomanagement sowie gezielte Verbesserungen in der Zusammenarbeit mit Frachtführern. Woher beziehen Diese Daten werden häufig in den Bereichen für Ereignis- oder Ausnahmemanagement von Blue Yonder TMS erfasst. Oft stammen sie aus EDI-Aktualisierungen des Frachtführers, zum Beispiel über EDI 214. Beispiele WetterZollkontrolleVerspätung des FahrersÜberlastung des Umschlagplatzes | |||
Aktivitäten im Transportmanagement
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Sendung gebucht | Dieser Meilenstein zeigt an, dass ein Frachtführer das Angebot angenommen hat und die Sendung übernimmt. Der Sendungsstatus wird auf „gebucht“ oder „verbindlich zugesagt“ gesetzt. Damit stehen Frachtführer und Frachtrate für den Transport fest. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein schließt die Planungsphase ab und leitet die Ausführung ein. Anhand der Zykluszeit bis zu diesem Punkt lässt sich die Effizienz und Reaktionsfähigkeit bei der Buchung bewerten. Woher beziehen Dieses Event wird erfasst, sobald die Annahme des Frachtführers, zum Beispiel über EDI 990, eingeht und verarbeitet wird. Dadurch ändert sich der Status des Sendungsdatensatzes im TMS. Erfassung Erfassen Sie den Timestamp der Statusänderung zu „Gebucht“ oder „Verbindlich zugesagt“. Ereignistyp explicit | |||
| Sendungsanfrage eingegangen | Diese Aktivität kennzeichnet die Erfassung eines Transportbedarfs in Blue Yonder TMS. Sie wird in der Regel durch einen Auftrag aus einem vorgelagerten System wie einem ERP ausgelöst. Damit beginnt offiziell der Lebenszyklus der Sendung: Ein neuer Sendungsdatensatz wird mit dem Status „ungeplant“ oder „neu“ angelegt. | ||
| Warum das wichtig ist Dies ist das zentrale Start-Event des durchgängigen Transportprozesses. Die Zeitspanne zwischen diesem Event und den anschließenden Planungsaktivitäten zeigt, ob es zu Verzögerungen bei der ersten Bearbeitung kommt, und gibt Aufschluss über den Gesamtdurchsatz. Woher beziehen Dieses Event wird in der Regel anhand des Erstellungs-Timestamps des Sendungsdatensatzes in den zentralen Sendungs- oder Auftragstabellen abgeleitet. Es kann auch als explizites Event protokolliert werden, wenn eine Schnittstellennachricht aus einem ERP verarbeitet wird. Erfassung Verwenden Sie den Erstellungs-Timestamp des Sendungsdatensatzes. Ereignistyp inferred | |||
| Ware abgeholt | Diese Aktivität markiert den Beginn des physischen Transports. Der Frachtführer übernimmt die Ware am Abholort. Blue Yonder TMS erfasst dieses Event in der Regel anhand einer Statusmeldung des Frachtführers, etwa einer EDI-214-Transaktion. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein in der Ausführung bestätigt, dass die Sendung unterwegs ist. Er dient als Ausgangspunkt für die Berechnung der Transportzeit und den Vergleich der pünktlichen Abholung mit dem geplanten Termin. Woher beziehen Dieses explizite Event wird anhand von Statusmeldungen des Frachtführers erfasst. Das System speichert den Timestamp, zu dem die Abholbestätigung verarbeitet wird, zum Beispiel eine EDI-214-Nachricht mit dem Status „AF“ oder „X3“. Erfassung Verwenden Sie den Timestamp der verarbeiteten EDI-214-Nachricht oder einer anderen Abholbestätigung des Frachtführers. Ereignistyp explicit | |||
| Ware zugestellt | Dieser Meilenstein zeigt an, dass die Sendung am Bestimmungsort des Empfängers eingetroffen ist. Der Frachtführer bestätigt die Zustellung in der Regel über eine EDI-214-Nachricht, die den Sendungsstatus im TMS aktualisiert. | ||
| Warum das wichtig ist Dieser wichtige Erfolgsmeilenstein markiert das Ende des physischen Transports. Er bildet die Grundlage für die Messung der Leistung bei termingerechter Lieferung, einem wichtigen Indikator für Kundenzufriedenheit und Zuverlässigkeit des Frachtführers. Woher beziehen Dieses explizite Event wird anhand einer Zustellbestätigung des Frachtführers erfasst. Das TMS protokolliert den Timestamp, zu dem die EDI-214-Nachricht mit dem Status „D1“ oder eine entsprechende Nachricht verarbeitet wird. Erfassung Verwenden Sie den Timestamp der verarbeiteten Zustellbestätigung des Frachtführers. Ereignistyp explicit | |||
| Zahlung verarbeitet | Dies ist die letzte Aktivität im Lebenszyklus der Sendung. Sie bestätigt, dass der Frachtführer für die Transportleistung bezahlt wurde. Das Event stammt in der Regel aus einem externen Finanzsystem (ERP); der Status wird anschließend im TMS aktualisiert. | ||
| Warum das wichtig ist Diese Aktivität markiert den finanziellen Abschluss der Sendung. Die Zykluszeit von der Zustellung oder Rechnungsprüfung bis zur Zahlung ist wichtig für das Working Capital und die Zusammenarbeit mit den Frachtführern. Woher beziehen Dieses explizite Event wird in der Regel protokolliert, wenn eine Schnittstellennachricht aus der Kreditorenbuchhaltung oder dem ERP den Zahlungsstatus der Frachtrechnung im TMS aktualisiert. Erfassung Verwenden Sie den Timestamp der Zahlungsbestätigung aus dem Finanzsystem. Ereignistyp explicit | |||
| Zollabfertigung abgeschlossen | Bei internationalen Sendungen markiert diese Aktivität den Zeitpunkt, zu dem die Ware den Zoll an einer Grenze oder in einem Hafen erfolgreich passiert hat. Ausgelöst wird das Event durch eine Mitteilung des Zollagenten oder des Frachtführers. | ||
| Warum das wichtig ist Der Zoll ist eine häufige Ursache für erhebliche Verzögerungen in der internationalen Logistik. Die Dauer bis zur Zollfreigabe zu messen, ist wichtig, um Engpässe zu erkennen und die grenzüberschreitende Transportzeit zu verkürzen. Woher beziehen Dieses Event wird in der Regel explizit erfasst, wenn eine Nachricht des Frachtführers, zum Beispiel über EDI 214, oder eine manuelle Aktualisierung den Zollstatus der Sendung auf „freigegeben“ setzt. Erfassung Erfassen Sie den Timestamp, zu dem der Zollstatus der Sendung auf „Freigegeben“ gesetzt wird. Ereignistyp explicit | |||
| Frachtführer angefragt | Diese Aktivität findet statt, wenn die Sendung einem bestimmten Frachtführer verbindlich zur Annahme angeboten wird. Im TMS ist dies ein eigener Vorgang, der häufig eine Mitteilung an den Frachtführer auslöst, etwa per EDI-204-Transaktion, E-Mail oder Portalbenachrichtigung. | ||
| Warum das wichtig ist Dieses Event bildet den Ausgangspunkt, um die Reaktionszeit der Frachtführer und die Annahmequote von Transportangeboten zu messen. Die Zeit zwischen dem Versand des Angebots und der Antwort des Frachtführers gibt Aufschluss darüber, wie effizient die Zusammenarbeit mit den Frachtführern ist. Woher beziehen Blue Yonder TMS protokolliert diesen Vorgang wahrscheinlich als explizites Event in einer Sendungs- oder Angebotsverlaufstabelle, sobald ein Benutzer oder das System das Angebot versendet. Erfassung Wird im Sendungsverlauf protokolliert, sobald das Angebot versendet wird. Ereignistyp explicit | |||
| Frachtrechnung geprüft | Die Rechnung des Frachtführers wird systematisch oder manuell mit den vereinbarten Frachtraten, Zusatzkosten und dem Zustellnachweis abgeglichen. Bei diesem Schritt werden die Kosten geprüft, bevor die Zahlung freigegeben wird. | ||
| Warum das wichtig ist Dies ist ein wichtiger Kontrollpunkt für die Finanzen. Die Analyse des Prüfprozesses kann häufige Abweichungen bei Rechnungen aufdecken. Wiederholte Bearbeitung in dieser Phase weist auf Probleme hin, die den Verwaltungsaufwand erhöhen. Woher beziehen Dieses Event wird erfasst, wenn der Status der zur Sendung gehörenden Frachtrechnung im Frachtprüfungsmodul des TMS auf „Geprüft“, „Zur Zahlung freigegeben“ oder einen ähnlichen Status gesetzt wird. Erfassung Erfassen Sie den Timestamp der Statusänderung des Frachtrechnungsobjekts, das mit der Sendung verknüpft ist. Ereignistyp inferred | |||
| Sendung geplant | Kennzeichnet den Abschluss der ersten Planungsphase. Dabei werden eine Route, ein Transportmittel und mögliche Frachtführer für die Sendung festgelegt. Die Planungs-Engine des Systems erstellt einen Lösungsvorschlag und aktualisiert den Sendungsstatus, sobald ein Plan vorliegt. | ||
| Warum das wichtig ist Anhand dieser Aktivität lässt sich die Effizienz der Planungs- und Optimierungs-Engine messen. Verzögerungen oder Schleifen mit erneuter Bearbeitung können auf Probleme mit Stammdaten, der Verfügbarkeit von Frachtführern oder der Systemkonfiguration hinweisen. Woher beziehen Dieses Event wird wahrscheinlich aus einer Statusänderung des Sendungsobjekts abgeleitet, zum Beispiel von „ungeplant“ zu „geplant“. Der Timestamp der Statusänderung markiert das Event. Erfassung Erfassen Sie den Timestamp, zu dem sich der Sendungsstatus in „geplant“ ändert. Ereignistyp inferred | |||
| Sendung storniert | Kennzeichnet die Beendigung einer Sendung vor der Abholung. Gründe dafür können beispielsweise eine Stornierung des Kundenauftrags oder eine Planungsänderung sein. Die Stornierung bildet einen endgültigen, nicht erfolgreichen Endstatus. | ||
| Warum das wichtig ist Die Erfassung von Stornierungen ist wichtig, um Nachfrageschwankungen und unnötigen Aufwand zu verstehen. Eine Analyse der Stornierungsgründe kann Probleme in der Auftragsverwaltung oder Transportplanung aufdecken. Woher beziehen Dieses explizite Event wird erfasst, wenn ein Benutzer oder ein automatisierter Prozess den Hauptstatus der Sendung auf „Storniert“ setzt. Erfassung Erfassen Sie den Timestamp der Statusänderung zu „Storniert“. Ereignistyp explicit | |||
| Transportangebot abgelehnt | Dieses Event zeigt an, dass ein Frachtführer das Transportangebot abgelehnt hat. Die Ablehnung geht in der Regel elektronisch über eine EDI-990-Transaktion ein oder wird manuell im Frachtführerportal erfasst. Daraufhin wird ein Workflow zur Suche nach einem alternativen Frachtführer ausgelöst. | ||
| Warum das wichtig ist Die Erfassung abgelehnter Transportangebote ist wichtig, um Schleifen bei der Auswahl von Frachtführern zu erkennen. Eine hohe Ablehnungsquote kann auf Probleme mit Preisen, verfügbaren Kapazitäten oder ungenauen Ladungsdaten hinweisen. Das kann zu Verzögerungen und höheren Kosten führen. Woher beziehen Dieses Event wird in der Regel explizit erfasst, wenn das TMS die Ablehnung des Frachtführers verarbeitet und den Angebotsstatus der Sendung aktualisiert. Erfassung Wird beim Eingang einer Ablehnungsnachricht des Frachtführers als Event protokolliert, zum Beispiel über EDI 990. Ereignistyp explicit | |||
| Transportstatusmeldung eingegangen | Dieses Event kennzeichnet den Eingang einer Standort- oder Statusmeldung des Frachtführers während des Transports. Die Meldungen, häufig über EDI 214, geben Aufschluss über den Fortschritt der Sendung und mögliche Verzögerungen. | ||
| Warum das wichtig ist Diese Events sind wichtig, um den Fortschritt der Sendung zu verfolgen und Verzögerungen während des Transports zu erkennen. Fehlende Meldungen können auf Lücken bei der Sendungsverfolgung hindeuten. Häufige Verzögerungsmeldungen wiederum können auf Leistungsprobleme des Frachtführers hinweisen. Woher beziehen Diese expliziten Events werden jedes Mal in einer Sendungsverfolgungs- oder Ereignisverlaufstabelle protokolliert, wenn eine Transportmeldung des Frachtführers eingeht und verarbeitet wird, zum Beispiel eine EDI-214-Nachricht mit dem Status „X1“ oder „AG“. Erfassung Jede verarbeitete Transportmeldung des Frachtführers erzeugt einen neuen Eintrag im Event Log. Ereignistyp explicit | |||
| Zustellnachweis eingegangen | Diese Aktivität kennzeichnet den Eingang eines formellen Zustellnachweises, etwa eines unterschriebenen Frachtbriefs. Sie erfolgt häufig nach der physischen Zustellung und ist Voraussetzung für die Frachtzahlung. | ||
| Warum das wichtig ist Ein zeitnaher Eingang des Zustellnachweises (POD) ist wichtig, um Abrechnung und Zahlung zu beschleunigen. Verzögerungen wirken sich direkt auf den Cashflow aus und können zu Zahlungsstreitigkeiten mit Frachtführern führen. Woher beziehen Dieses Event wird in der Regel erfasst, wenn ein Benutzer den Eingang des POD manuell vermerkt oder das Dokument dem Sendungsdatensatz im TMS hinzufügt. Dadurch ändert sich der Status. Erfassung Erfassen Sie den Timestamp, zu dem das Kennzeichen oder der Status „POD eingegangen“ für die Sendung gesetzt wird. Ereignistyp inferred | |||
Anleitungen zur Datenextraktion
Die Extraktionsmethoden für diesen Prozess werden derzeit geprüft. Schauen Sie später wieder vorbei oder kontaktieren Sie uns wenn Sie Unterstützung benötigen.
Möchten Sie loslegen?
Beginnen Sie noch heute mit der Optimierung Ihres Transportmanagementprozesses. Mit diesem Template erkennen Sie Effizienzpotenziale und verbessern die Leistung Ihrer Logistik.
Steigern Sie jetzt die Effizienz Ihres Transportmanagements
Erkennen Sie Ineffizienzen, verfolgen Sie die Leistung und verkürzen Sie die Zykluszeit um 30 %.
Keine Kreditkarte erforderlich. In wenigen Minuten aktiviert.