Ihr Daten-Template für das Transportmanagement
Ihr Daten-Template für das Transportmanagement
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten zur Erfassung
- Hinweise zur Datenextraktion
Attribute für das Transportmanagement
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name eines bestimmten Ereignisses oder Meilensteins im Transportprozess einer Sendung. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt im Transportzyklus, zum Beispiel 'Sendung geplant', 'Ware abgeholt' oder 'Ware zugestellt'. Jede Aktivität steht für ein eigenes Geschäftsereignis, das die Sendung ihrem Abschluss näherbringt. Die Analyse der Abfolge und Dauer dieser Aktivitäten bildet den Kern von Process Mining. Sie zeigt den tatsächlichen Prozessablauf, macht Engpässe zwischen den Schritten sichtbar und misst, ob die Standardarbeitsanweisungen eingehalten werden. Abweichungen im Aktivitätsablauf können auf Ausnahmen, Nacharbeit oder Abweichungen vom optimalen Prozessweg hinweisen. Warum das wichtig ist Damit werden die Schritte in der Prozesslandkarte festgelegt. So lassen sich der Transportweg der Sendung, Engpässe und Abweichungen visualisieren und analysieren. Woher beziehen Diese Informationen stammen aus Ereignistabellen oder Statusänderungsprotokollen in Oracle Transportation Management. Der konkrete Aktivitätsname kann aus Ereigniscodes und Beschreibungen zusammengesetzt sein. Beispiele Sendung geplantWare abgeholtZollabfertigung abgeschlossenWare zugestellt | |||
| Ereigniszeit EventTime | Das genaue Datum und die genaue Uhrzeit, zu denen eine bestimmte Transportaktivität oder ein Ereignis stattgefunden hat. | ||
| Beschreibung Dieser Timestamp gibt den genauen Zeitpunkt an, zu dem eine Aktivität wie 'Frachtführer zugewiesen' oder 'Zustellnachweis eingegangen' im System erfasst wurde. Timestamps sind für Process Mining grundlegend, da sie die chronologische Abfolge der Ereignisse für jede Sendung festlegen. Ihre Genauigkeit ist für alle zeitbasierten Analysen entscheidend. Anhand der Timestamps werden Durchlaufzeiten zwischen Aktivitäten berechnet, Prozessdauern gemessen, Verzögerungen erkannt und Leistungen mit Service-Level-Vereinbarungen verglichen. Die Analyse der Ereigniszeit zeigt, an welchen Stellen im Prozess Zeit verloren geht. Warum das wichtig ist Dieser Timestamp ist entscheidend, um Ereignisse chronologisch zu ordnen und alle Leistungskennzahlen wie Durchlaufzeiten und Verzögerungen zu berechnen. Woher beziehen Stammt aus den Timestamp-Feldern zu Ereignissen in den Tabellen zum Ereignis-Tracking oder Statusverlauf von OTM. Beispiele 2023-10-26T08:00:00Z2023-10-27T14:30:00Z2023-10-28T09:15:00Z | |||
| Sendung ShipmentId | Die eindeutige Kennung einer einzelnen Sendung. Sie dient als primäre Case-ID, um alle zugehörigen Transportaktivitäten nachzuverfolgen. | ||
| Beschreibung Die Shipment-ID identifiziert eindeutig einen einzelnen Warentransport vom Absender zum Empfänger. Dieses Attribut bildet die Grundlage der Prozessanalyse: Es fasst alle zugehörigen Ereignisse wie Planung, Buchung, Abholung, Transport, Zustellung und Rechnungsstellung in einem Case zusammen. In Process Mining ermöglicht die Analyse nach Shipment-ID einen vollständigen Überblick über den gesamten Transportzyklus jeder einzelnen Sendung. Damit lassen sich wichtige Kennzahlen wie die gesamte Durchlaufzeit, die Leistung bei termingerechter Lieferung und die Kosten pro Sendung berechnen. So gewinnen Sie einen umfassenden Einblick in die Prozesseffizienz und den Kundenservice. Warum das wichtig ist Diese zentrale Case-ID verknüpft alle Prozessschritte und ermöglicht eine vollständige Analyse des gesamten Transportwegs jeder einzelnen Sendung. Woher beziehen Dies ist ein Primärschlüssel in Oracle Transportation Management, der üblicherweise in Tabellen zur Sendungs- oder Auftragsverwaltung zu finden ist. Die genauen Tabellen- und Feldnamen finden Sie in der OTM-Dokumentation. Beispiele SH-0012345SH-0012346SH-0012347 | |||
| Angefordertes Lieferdatum RequestedDeliveryDate | Das vom Kunden gewünschte Lieferdatum und die gewünschte Lieferzeit oder der als Ziel in der Service-Level-Vereinbarung (SLA) festgelegte Termin. | ||
| Beschreibung Dieses Attribut erfasst den angestrebten Liefer-Timestamp einer Sendung. Er bildet die Zusage an den Kunden ab und dient als wichtigste Vergleichsgröße für die Messung termingerechter Lieferungen. In Process Mining wird dieses Datum mit dem tatsächlichen Liefer-Timestamp aus der Aktivität 'Ware zugestellt' verglichen. So lässt sich feststellen, ob eine Sendung pünktlich oder verspätet war. Dieser Vergleich bildet die Grundlage für die Kennzahl zur Quote termingerechter Lieferungen und ist entscheidend für das Dashboard zur Lieferleistung. Die Analyse von Abweichungen hilft, systematische Verzögerungsursachen zu erkennen und die Kundenzufriedenheit zu verbessern. Warum das wichtig ist Dies ist die wichtigste Vergleichsgröße zur Messung termingerechter Lieferungen, einer entscheidenden Kennzahl für Kundenzufriedenheit und operative Exzellenz. Woher beziehen Diese Information ist üblicherweise auf Auftrags- oder Sendungsebene in OTM gespeichert, häufig in Feldern zu Lieferterminen oder vereinbarten Terminen. Beispiele 2023-11-15T17:00:00Z2023-11-20T12:00:00Z2023-11-22T09:00:00Z | |||
| Name des Frachtführers CarrierName | Der Name des Frachtführers oder Dienstleisters, der für den Transport der Sendung verantwortlich ist. | ||
| Beschreibung Dieses Attribut bezeichnet den Logistikpartner, der mit dem Transport der Ware beauftragt wurde. Dazu zählen große Frachtunternehmen, lokale Kurierdienste und Reedereien. Die Analyse der Leistung einzelner Frachtführer ist ein wichtiges Ziel von Process Mining im Transportwesen. Mit diesem Attribut lassen sich Sendungen nach Frachtführer gruppieren und Kennzahlen wie die Quote termingerechter Lieferungen, Kosten pro Sendung, Transportdauer und Häufigkeit von Problemen wie Verzögerungen oder Abweichungen bei der Abrechnung vergleichen. Diese Erkenntnisse unterstützen die Auswahl von Frachtführern, Vertragsverhandlungen und das Leistungsmanagement. Warum das wichtig ist Ermöglicht den Leistungsvergleich verschiedener Frachtführer. Das ist entscheidend, um ihre Auswahl und Vertragsverhandlungen zu verbessern und Kosten zu senken. Woher beziehen Zu finden in den Sendungsdetails in OTM, verknüpft mit den Datensätzen des zugewiesenen Frachtführers oder Dienstleisters. Die Angaben können in Tabellen zu Sendungen und Dienstleistern gespeichert sein. Beispiele FedEx FreightUPS Supply Chain SolutionsMaersk LineKnight-Swift Transportation | |||
| Sendungskosten ShipmentCost | Die gesamten Frachtkosten oder der für den Transport der Sendung berechnete Betrag. | ||
| Beschreibung Dieses Attribut umfasst die gesamten Kosten einer Sendung, darunter Frachtkosten, Treibstoffzuschläge und weitere Zusatzgebühren. Es ist eine wichtige Kennzahl für die finanzielle Leistung des Transportprozesses. Mit den Sendungskosten lässt sich die Kennzahl zu den durchschnittlichen Frachtführerkosten pro Sendung berechnen. Eine Aufschlüsselung nach Frachtführer, Route, Transportart oder Sendungstyp zeigt Einsparmöglichkeiten auf. Außerdem dienen die Kosten in der Analyse von Abweichungen bei Frachtrechnungen zum Vergleich geplanter und tatsächlicher Beträge. Warum das wichtig ist Liefert die Finanzdaten, die zur Analyse der Transportausgaben, zur Ermittlung von Einsparmöglichkeiten und zur Messung der finanziellen Auswirkungen ineffizienter Prozesse erforderlich sind. Woher beziehen Diese Information findet sich üblicherweise in den Finanz- oder Kostenangaben einer Sendung in OTM. Sie wird häufig nach der Frachtkostenberechnung und Abrechnung eingetragen. Beispiele 250.751200.00545.50 | |||
| Transportart TransportationMode | Die für eine Sendung verwendete Transportart, zum Beispiel Lkw, Bahn, Schiff oder Flugzeug. | ||
| Beschreibung Dieses Attribut ordnet eine Sendung nach Transportart ein. Übliche Transportarten sind Full Truckload (FTL), Less Than Truckload (LTL), Seefracht, Luftfracht und Bahntransport. Die Transportart ist ein grundlegendes Merkmal einer Sendung und beeinflusst Kosten, Transportdauer und Komplexität. In der Analyse ist die Transportart eine wichtige Dimension für die Segmentierung. So lassen sich Prozessleistung und Kosten verschiedener Transportarten vergleichen. Beispielsweise können Sie ermitteln, bei welchen Transportarten häufiger Verzögerungen unterwegs auftreten oder die Kosten pro Meile höher sind. Das unterstützt strategische Entscheidungen zum Logistiknetzwerk. Warum das wichtig ist Ermöglicht die Aufschlüsselung von Leistung und Kosten nach Transportart. So werden Erkenntnisse zu Lkw-, Luft-, See- oder Bahntransporten sichtbar. Woher beziehen Dies ist ein Standardattribut auf Sendungsebene in OTM. Es findet sich häufig in einem eigenen Feld für 'mode' oder 'transport type'. Beispiele FTLLTLSEEFRACHTAIR | |||
| Verzögerungsgrund DelayReason | Ein Code oder eine Beschreibung, die den Grund für eine Verzögerung der Sendung angibt. | ||
| Beschreibung Bei einer Verzögerung gibt dieses Attribut den Grund an, zum Beispiel 'Wetter', 'Zollsperre', 'Hafenüberlastung' oder 'technischer Defekt'. Die Information stammt aus Aktualisierungen des Frachtführers oder manuellen Einträgen in OTM. Dieses Attribut ist für die Ursachenanalyse verspäteter Lieferungen entscheidend. Durch die Kategorisierung und Zählung der Verzögerungsgründe können Unternehmen die häufigsten Probleme in ihrer Lieferkette erkennen. Das ermöglicht gezielte Verbesserungsmaßnahmen, etwa die Auswahl zuverlässigerer Frachtführer für bestimmte Routen oder bessere Dokumentation zur Beschleunigung der Zollabfertigung. Warum das wichtig ist Zeigt die Ursachen verspäteter Sendungen auf und ermöglicht gezielte Maßnahmen, um häufige Probleme zu verringern und die Pünktlichkeit zu verbessern. Woher beziehen Wird üblicherweise in den Details zu Tracking-Ereignissen in OTM erfasst. Der Grund kann bestimmten Ausnahme- oder Verzögerungscodes zugeordnet sein. Beispiele WETTERBEDINGTE_VERZÖGERUNGZOLLKONTROLLEHAFENÜBERLASTUNGVERKEHR | |||
| Abweichung bei der Frachtrechnung FreightBillDiscrepancy | Kennzeichnet, ob bei der Prüfung der Frachtrechnung eine Abweichung festgestellt wurde. | ||
| Beschreibung Dieses boolesche Attribut erhält den Wert „true“, wenn die vom Frachtführer eingegangene Rechnung nicht mit den in OTM berechneten erwarteten Kosten übereinstimmt. Abweichungen können durch falsche Tarife, Zusatzkosten oder andere Abrechnungsfehler entstehen. Dieses Attribut bildet die Grundlage für die KPI „Abweichungsquote bei Frachtrechnungen“. Wenn Sie die Häufigkeit dieser Kennzeichnungen nach Frachtführer, Route oder Sendungsart auswerten, können Sie die Ursachen von Abrechnungsfehlern ermitteln. Das unterstützt Maßnahmen zur Verbesserung der Datenqualität, zur Vereinfachung der Rechnungsprüfung und zur Vermeidung von Überzahlungen. Warum das wichtig ist Kennzeichnet Sendungen mit Abrechnungsfehlern und unterstützt so direkt die Analyse von Abweichungen bei Frachtrechnungen. Dadurch lassen sich Überzahlungen verringern und Finanzkontrollen verbessern. Woher beziehen In der Regel handelt es sich um einen Status oder eine Kennzeichnung, die während der Frachtabrechnung und des Rechnungsabgleichs in OTM gesetzt wird. Beispiele truefalse | |||
| Ausgangsland OriginCountry | Das Land, in dem der Transport der Sendung beginnt. | ||
| Beschreibung Dieses Attribut gibt das Ausgangsland der Sendung anhand des Standorts des Absenders an. Es ist eine wichtige geografische Information für die Logistikanalyse. Die Analyse nach Ausgangsland zeigt regionale Unterschiede bei der Prozessleistung. So können sich Zollabfertigungszeiten, Frachtführerkosten und Transportdauer je nach Herkunftsland deutlich unterscheiden. Diese Segmentierung ist entscheidend für die Steuerung internationaler Transporte und das Erkennen regionaler Engpässe. Warum das wichtig ist Ermöglicht die geografische Analyse des Transportprozesses und hilft, regionale Engpässe, Kosten und Leistungsunterschiede zu erkennen. Woher beziehen Abgeleitet aus den Adressdaten des Ausgangsorts oder Absenders der Sendung, die in den Standortstammdaten von OTM gespeichert sind. Beispiele USADEUCHNMEX | |||
| Benutzername UserName | Name oder ID des Benutzers, der eine bestimmte Aktivität ausgeführt hat oder dafür verantwortlich ist. | ||
| Beschreibung Dieses Attribut gibt an, welcher Benutzer oder Systemagent ein bestimmtes Ereignis ausgelöst hat, zum Beispiel „Sendung geplant“ oder „Frachtführer zugewiesen“. So lässt sich nachvollziehen, wer am Prozess beteiligt war. Wenn Sie Aktivitäten in Process Mining nach Benutzern auswerten, können Sie die Arbeitslastverteilung nachvollziehen, Schulungsbedarf erkennen und die Leistung verschiedener Benutzer oder Teams vergleichen. Außerdem lässt sich unterscheiden, ob Aktivitäten manuell oder automatisch vom System ausgeführt wurden. Warum das wichtig ist Sorgt für klare Verantwortlichkeiten und ermöglicht die Analyse von Arbeitslast und Leistung einzelner Benutzer oder Teams. Woher beziehen Stammt aus Benutzer-ID-Feldern, zum Beispiel INSERT_USER, die in OTM den Statusänderungen oder Ereignissen in Verlaufs- oder Protokolltabellen zugeordnet sind. Beispiele JSMITHLOGISTICS_PLANNER_ASYSTEM_AUTO | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten zu diesem Ereignis zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden. | ||
| Beschreibung Dieses Attribut erfasst, wann die Daten zuletzt aus Oracle Transportation Management abgerufen wurden. Es gibt die Aktualität der analysierten Daten an, nicht den Zeitpunkt des Geschäftsereignisses. Dieser Timestamp ist wichtig, um die Aktualität der Process-Mining-Analyse einzuschätzen. Er zeigt Benutzern, ob sie aktuelle Informationen oder einen Datenstand von einem bestimmten Zeitpunkt betrachten. Außerdem hilft er, Aktualisierungszyklen zu steuern und sicherzustellen, dass Entscheidungen auf aktuellen Informationen beruhen. Warum das wichtig ist Die Angabe zeigt, wie aktuell die Daten sind. So wissen Benutzer, auf welchem Stand die Analyse ist und wann die nächste Datenaktualisierung erwartet wird. Woher beziehen Dieser Timestamp wird üblicherweise während der Datenübernahme oder des ETL-Prozesses vom System erzeugt. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Pünktliche Zustellung IsOnTimeDelivery | Eine berechnete Kennzeichnung, die angibt, ob die Sendung am gewünschten Zustelltermin oder früher zugestellt wurde. | ||
| Beschreibung Dieses boolesche Attribut ergibt sich aus dem Vergleich des Timestamps der Aktivität „Ware zugestellt“ mit dem Attribut „Gewünschter Zustelltermin“. Es erhält den Wert „true“, wenn die Zustellung pünktlich oder früher erfolgt ist, und „false“, wenn sie verspätet war. Dieses Attribut fließt direkt in die KPI „Pünktliche Zustellquote“ und in das Dashboard „Übersicht zur Zustellleistung“ ein. Es vereinfacht die Analyse der Zustellleistung, da für jede Sendung eindeutig festgehalten wird, ob sie pünktlich oder verspätet zugestellt wurde. So können Sie die Sendungen einfach filtern, aggregieren und visualisieren. Warum das wichtig ist Diese berechnete Kennzeichnung vereinfacht die Messung der KPI „Pünktliche Zustellung“ und ermöglicht eine einfache Filterung und Analyse pünktlicher und verspäteter Sendungen. Woher beziehen Dieses Attribut ist im Quellsystem nicht vorhanden. Es wird bei der Datentransformation berechnet, indem der Timestamp der Aktivität „Ware zugestellt“ mit dem Attribut „RequestedDeliveryDate“ verglichen wird. Beispiele truefalse | |||
| Quellsystem SourceSystem | Gibt an, aus welchem System die Ereignisdaten stammen, zum Beispiel aus Oracle Transportation Management. | ||
| Beschreibung Dieses Attribut gibt die Quellanwendung an, in der die Daten erzeugt wurden. In einer komplexen Logistikumgebung können die Daten aus OTM, einem Lagerverwaltungssystem (WMS), dem System eines Frachtführers über EDI oder anderen integrierten Plattformen stammen. Das Quellsystem zu kennen, ist wichtig für die Data Governance, die Qualitätsbewertung und die Fehlerbehebung. Es hilft, den Datenkontext zu verstehen und Unterschiede bei Detailgrad oder Aktualität der Daten zu erklären. Für Analysen können Sie damit Ereignisse herausfiltern, die ausschließlich aus einem bestimmten, vertrauenswürdigen System stammen. Warum das wichtig ist Die Angabe der Datenherkunft liefert wichtigen Kontext für die Datenvalidierung und Analysen in Umgebungen mit mehreren Systemen. Woher beziehen Dieser statische Wert wird üblicherweise während der Datenextraktion hinzugefügt, um die Herkunft der Datensätze zu kennzeichnen. Beispiele Oracle OTMOTM CloudSAP TM | |||
| Sendungsstatus ShipmentStatus | Der aktuelle Gesamtstatus der Sendung im Prozess, zum Beispiel 'Geplant', 'Unterwegs' oder 'Zugestellt'. | ||
| Beschreibung Dieses Attribut gibt einen Überblick über den aktuellen Stand der Sendung im Gesamtprozess. Anders als eine Aktivität, die ein Ereignis zu einem bestimmten Zeitpunkt bezeichnet, beschreibt der Status den Zustand des Sendungs-Cases. Process Mining konzentriert sich auf den Ablauf der Aktivitäten. Der Gesamtstatus eignet sich dagegen zum Filtern von Cases und als Kontext in Dashboards. Eine Analyse kann sich beispielsweise auf 'Abgeschlossene' Sendungen beschränken oder untersuchen, warum viele Sendungen ungewöhnlich lange den Status 'Unterwegs' haben. Warum das wichtig ist Gibt einen Überblick über den Fortschritt einer Sendung und eignet sich zum Filtern und Segmentieren von Cases in der Analyse. Woher beziehen Im Hauptdatensatz der Sendung in OTM verfügbar. Er gibt den aktuellen Status im Workflow an. Beispiele GEPLANTGEBUCHTUNTERWEGSZUGESTELLT | |||
| Sendungstyp ShipmentType | Eine Klassifizierung der Sendung, zum Beispiel nach Serviceniveau, Warenart oder Geschäftseinheit. | ||
| Beschreibung Dieses Attribut ordnet die Sendung einer geschäftsspezifischen Kategorie zu, zum Beispiel „Standard“, „Express“, „Gefahrgut“ oder „Konzernintern“. Die Klassifizierung ermöglicht es, unterschiedliche Geschäftsregeln, Prioritäten oder Auswertungen anzuwenden. Wenn Sie den Sendungstyp in Process Mining als Dimension verwenden, können Sie die Abläufe verschiedener Sendungsarten vergleichen. So lässt sich feststellen, ob bestimmte Arten häufiger verspätet eintreffen, höhere Kosten verursachen oder von den üblichen Prozesspfaden abweichen. Diese Erkenntnisse helfen Ihnen, die Abläufe gezielt an die Anforderungen der jeweiligen Sendungsart anzupassen. Warum das wichtig ist Ermöglicht eine nach Geschäftskontext segmentierte Analyse. So können Sie nachvollziehen, ob verschiedene Sendungsarten unterschiedliche Abläufe durchlaufen oder sich in ihrer Leistung unterscheiden. Woher beziehen Dabei handelt es sich in der Regel um ein konfigurierbares Feld oder Attribut im Sendungs- oder Auftragsdatensatz in OTM. Beispiele StandardExpressInternationalInland | |||
| Umgeleitet IsRerouted | Kennzeichnet, ob die Route der Sendung nach der ursprünglichen Buchung geändert wurde. | ||
| Beschreibung Dieses boolesche Attribut erhält den Wert „true“, wenn eine Sendung nach der Planung und Buchung wesentlich umgeleitet wird. Gründe dafür können Kundenwünsche, unerwartete Störungen oder Optimierungsmöglichkeiten sein. Das Attribut unterstützt direkt die KPI „Umleitungsquote bei Sendungen“ und das Dashboard „Umleitungen und Expresssendungen“. Wenn Sie die Häufigkeit von Umleitungen verfolgen, können Sie zugrunde liegende Probleme bei der Planung oder Ausführung erkennen. Das macht betriebliche Instabilitäten und damit verbundene Kosten sichtbar und hilft Verantwortlichen, kostspielige und störende Änderungen zu verringern. Warum das wichtig ist Hilft dabei, Häufigkeit und Auswirkungen betrieblicher Ausnahmen wie Umleitungen zu messen und Ineffizienzen bei Planung und Ausführung sichtbar zu machen. Woher beziehen Diese Kennzeichnung wird abgeleitet, indem bestimmte Umleitungsereignisse im Event Log erkannt oder die endgültige Route mit der ursprünglich geplanten Route verglichen werden. Beispiele truefalse | |||
| Zielland DestinationCountry | Das Land, in dem die Sendung zugestellt werden soll. | ||
| Beschreibung Dieses Attribut gibt das Zielland der Sendung anhand des Standorts des Empfängers an. Es ergänzt das Ausgangsland bei der geografischen Prozessanalyse. Wie das Ausgangsland ist auch das Zielland wichtig, um Leistungsunterschiede auf verschiedenen Handelsrouten zu verstehen. Besonders relevant ist es für die Analyse von Zollabfertigungszeiten, der Zustellleistung auf der letzten Meile und der regionalen Leistungsfähigkeit von Frachtführern. So lassen sich Logistikstrategien an die Anforderungen der jeweiligen Zielmärkte anpassen. Warum das wichtig ist Wichtig für die Analyse der Leistung auf bestimmten Handelsrouten und für das Verständnis von Herausforderungen durch Zoll, Frachtführer und Vorschriften in den Zielmärkten. Woher beziehen Abgeleitet aus den Adressdaten des Zielorts oder Empfängers der Sendung, die in den Standortstammdaten von OTM gespeichert sind. Beispiele CANFRAJPNBRA | |||
| Zollagent CustomsAgent | Zollmakler oder -agent, der für die Zollabfertigung der Sendung zuständig ist. | ||
| Beschreibung Bei internationalen Sendungen bezeichnet dieses Attribut den externen Agenten oder das interne Team, das die Zolldokumentation und -verfahren bearbeitet. Die Leistung des Agenten kann die gesamte Transportdauer erheblich beeinflussen. Wenn Sie die Zykluszeit der Zollabfertigung nach Zollagent auswerten, können Sie die Leistung vergleichen. Dabei zeigt sich, welche Agenten in bestimmten Ländern oder für bestimmte Warengruppen besonders effizient arbeiten. Diese Erkenntnisse helfen Ihnen, geeignete Zollpartner auszuwählen und mit weniger leistungsstarken Agenten an Verbesserungen zu arbeiten. Warum das wichtig ist Ermöglicht die Leistungsmessung von Zollmaklern. So können Sie effiziente Partner ermitteln und zollbedingte Verzögerungen verringern. Woher beziehen Diese Information kann in OTM bei den Angaben zur internationalen Sendung als Dienstleister oder Partnerrolle gespeichert sein. Beispiele Global Customs ServicesLivingston InternationalFlexport | |||
Aktivitäten im Transportmanagement
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Sendung geplant | Diese Aktivität steht für die erfolgreiche Planung eines oder mehrerer Order Releases zu einer umsetzbaren Sendung durch die OTM-Planungsengine. Sie wird erfasst, wenn das System den Sendungsstatus auf einen geplanten Status setzt, zum Beispiel 'PLANNING_PLANNED FINAL'. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein trennt die Bedarfsphase von der Ausführungsphase. Die Analyse der Zeit bis zu dieser Aktivität zeigt, wie effizient die Planung ist und wo die Leistung der Planungsengine zum Engpass wird. Woher beziehen Lässt sich aus dem Statusverlauf des Shipment-Objekts in der Tabelle SHIPMENT ableiten. Suchen Sie nach einem Statuswechsel, der den Abschluss der Planung anzeigt. Erfassung Ermitteln Sie den Timestamp, zu dem SHIPMENT.SHIPMENT_STATUS_VALUE_GID in den Status 'Planned' wechselt. Ereignistyp inferred | |||
| Transportanfrage eingegangen | Diese Aktivität kennzeichnet die Erfassung eines Transportbedarfs im System, in der Regel als Order Release. Das Ereignis wird erfasst, wenn in Oracle Transportation Management ein neuer Order-Release-Datensatz angelegt wird. Er bildet den ursprünglichen Transportbedarf ab. | ||
| Warum das wichtig ist Als Startpunkt des Prozesses ist diese Aktivität entscheidend, um die gesamte Durchlaufzeit zu messen und Nachfragemuster zu verstehen. Sie ermöglicht die Analyse der Zeit von der Anfrage bis zur Planung. Woher beziehen Dieses explizite Ereignis wird anhand des Erstellungs-Timestamps des Order-Release-Datensatzes in der Tabelle ORDER_RELEASE erfasst. Dafür können INSERT_DATE oder bestimmte Erstellungsdatumsfelder verwendet werden. Erfassung Verwenden Sie den Erstellungs-Timestamp des Order Release in der Tabelle ORDER_RELEASE. Ereignistyp explicit | |||
| Ware abgeholt | Diese Aktivität markiert den Beginn des physischen Transports, wenn der Frachtführer die Ware am Ausgangsort abgeholt hat. Das Ereignis wird erfasst, wenn der erste Stop der Sendung als 'DEPARTED' gekennzeichnet wird. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein kennzeichnet den Beginn des Transports. Er ist entscheidend, um die Abholleistung des Frachtführers und die tatsächlichen Transportzeiten zu verfolgen. Woher beziehen Lässt sich aus dem Statuswechsel des ersten Stops in der Tabelle SHIPMENT_STOP zu 'DEPARTED' oder aus einem Sendungsstatusereignis zur Abholung ableiten. Erfassung Verwenden Sie den ACTUAL_DEPARTURE-Timestamp des ersten Datensatzes der Sendung in der Tabelle SHIPMENT_STOP. Ereignistyp inferred | |||
| Ware zugestellt | Diese Aktivität steht für die erfolgreiche Zustellung der Sendung an den Empfänger am Zielort. Sie wird erfasst, wenn für den letzten Stop der Sendung eine tatsächliche Ankunftszeit eingetragen wird. | ||
| Warum das wichtig ist Dieser zentrale Meilenstein dient zur Messung der termingerechten Lieferung und der gesamten Durchlaufzeit. Er bildet den Abschluss der Transportabwicklung. Woher beziehen Lässt sich daraus ableiten, dass das Feld ACTUAL_ARRIVAL für den letzten Stop-Datensatz der Sendung in der Tabelle SHIPMENT_STOP befüllt wird. Erfassung Verwenden Sie den ACTUAL_ARRIVAL-Timestamp des letzten Datensatzes der Sendung in der Tabelle SHIPMENT_STOP. Ereignistyp inferred | |||
| Zahlung verarbeitet | Diese letzte Aktivität steht für die erfolgreiche Verarbeitung der Zahlung an den Frachtführer für seine Leistungen. Damit ist die finanzielle Abwicklung der Sendung abgeschlossen. | ||
| Warum das wichtig ist Diese Aktivität schließt den Transportzyklus ab. Sie ist wichtig, um die Bearbeitungszeiten für Zahlungen an Frachtführer zu messen und die Geschäftsbeziehungen zu ihnen effektiv zu steuern. Woher beziehen Lässt sich aus dem Statuswechsel des zugehörigen Vouchers oder Bills zu 'PAID' ableiten. Die Daten finden Sie in den Tabellen VOUCHER oder BILL. Erfassung Ermitteln Sie den Timestamp, zu dem VOUCHER.VOUCHER_STATUS_ID zu 'PAID' wechselt. Ereignistyp inferred | |||
| Zustellnachweis eingegangen | Diese Aktivität steht für den Eingang und die Erfassung einer offiziellen Bestätigung der erfolgten Zustellung, zum Beispiel eines unterschriebenen Dokuments. Häufig wird sie als bestimmter Dokumenttyp zur Sendung gespeichert. | ||
| Warum das wichtig ist Der POD ist für die Abrechnung und die Klärung von Streitfällen entscheidend. Die Nachverfolgung seines Eingangs unterstützt die Einhaltung der Prozessvorgaben und verkürzt den finanziellen Abwicklungszyklus. Woher beziehen Dabei kann es sich um ein explizites Ereignis handeln oder um eine Ableitung aus dem Erstellungsdatum eines mit der Sendung verknüpften POD-Dokuments. Suchen Sie in der Tabelle DOCUMENT nach Dokumenten des Typs POD. Erfassung Verwenden Sie den Erstellungs-Timestamp eines POD-Dokuments, das der Sendung zugeordnet ist. Ereignistyp explicit | |||
| Abholtermin vereinbart | Diese Aktivität zeigt an, dass ein konkretes Datum und eine Uhrzeit für die Abholung vereinbart und erfasst wurden. Die Daten stammen häufig aus den terminbezogenen Angaben auf Stop-Ebene der Sendung. | ||
| Warum das wichtig ist Die Terminvereinbarung ist ein wichtiger Schritt bei der Koordination. Ihre Analyse zeigt, wie effizient die Terminplanung ist und wie sie sich auf die Pünktlichkeit der Abholung auswirkt. Woher beziehen Lässt sich aus dem Befüllen der Datums- und Uhrzeitfelder für den ersten Stop der Sendung, also den Abholort, in der Tabelle SHIPMENT_STOP ableiten. Erfassung Verwenden Sie den Timestamp, zu dem die Terminangaben für den Abhol-Stop erstmals eingetragen werden. Ereignistyp inferred | |||
| Frachtführer zugewiesen | Dieser Zeitpunkt zeigt an, dass ein bestimmter Frachtführer mit einer Sendung beauftragt wurde und den Auftrag angenommen hat. Er lässt sich am Wechsel des Tender-Status der Sendung zu 'TENDER_ACCEPTED' oder einem vergleichbaren Status erkennen. | ||
| Warum das wichtig ist Die Nachverfolgung unterstützt die Analyse der Effizienz bei der Auswahl und Beauftragung von Frachtführern. Verzögerungen in diesem Schritt können den Gesamtzeitplan erheblich beeinträchtigen, noch bevor die Sendung unterwegs ist. Woher beziehen Lässt sich aus dem Statusverlauf in der Tabelle SHIPMENT_TENDER ableiten. Maßgeblich ist der Timestamp, zu dem der Status die Annahme durch einen Frachtführer anzeigt. Erfassung Verwenden Sie den Timestamp des Statuswechsels zu 'TENDER_ACCEPTED' im Tender-Verlauf der Sendung. Ereignistyp inferred | |||
| Frachtrechnung geprüft | Diese Aktivität markiert den Abschluss der Prüfung der Frachtrechnung. Dabei wird die Rechnung des Frachtführers mit den Sendungsdaten abgeglichen und verifiziert. Sie wird erfasst, wenn der Abrechnungsstatus der Sendung zu 'VOUCHER_AUDITED' oder einem vergleichbaren Status wechselt. | ||
| Warum das wichtig ist Die Prüfung ist wichtig für die Finanzkontrolle und das Erkennen von Abweichungen bei der Abrechnung. Die Analyse dieser Aktivität hilft, den Ablauf von der Prüfung bis zur Zahlung zu verbessern und die Kennzahl zur Abweichungsquote bei Frachtrechnungen zu verfolgen. Woher beziehen Lässt sich aus dem Statuswechsel des der Sendung zugeordneten Bill-Objekts ableiten. Suchen Sie in der Tabelle BILL nach Statusaktualisierungen, die den Abschluss der Prüfung anzeigen. Erfassung Ermitteln Sie den Timestamp, zu dem BILL.BILL_STATUS_VALUE_GID in den Status 'Audited' wechselt. Ereignistyp inferred | |||
| Liefertermin vereinbart | Diese Aktivität kennzeichnet den Zeitpunkt, zu dem mit dem Empfänger ein konkretes Datum und eine Uhrzeit für die Lieferung vereinbart wurden. Das Ereignis wird anhand der Termindaten für den letzten Stop der Sendung erfasst. | ||
| Warum das wichtig ist Dieser Schritt ist wichtig für die Koordination der Zustellung. Die Analyse der Zeit zwischen Ankunft und vereinbartem Liefertermin kann Engpässe auf der letzten Meile aufdecken. Woher beziehen Lässt sich aus dem Befüllen der Datums- und Uhrzeitfelder für den letzten Stop der Sendung, also den Lieferort, in der Tabelle SHIPMENT_STOP ableiten. Erfassung Verwenden Sie den Timestamp, zu dem die Terminangaben für den Liefer-Stop erstmals eingetragen werden. Ereignistyp inferred | |||
| Sendung gebucht | Diese Aktivität steht für die verbindliche Buchungsbestätigung des Frachtführers nach erfolgreicher Beauftragung. Sie wird üblicherweise erfasst, wenn der Sendungsstatus auf 'SECURE RESOURCES_BOOKED' oder einen gleichwertigen Status gesetzt wird. | ||
| Warum das wichtig ist Damit bestätigt der Frachtführer die Übernahme und die Sendung geht offiziell in die Ausführungsphase über. Dieser Schritt ist entscheidend für die Kennzahl zur Planungszykluszeit der Sendung. Woher beziehen Lässt sich aus einem Statuswechsel des Shipment-Objekts in der Tabelle SHIPMENT ableiten. Dabei wird erfasst, wann die Sendung nach der Zuweisung eines Frachtführers in einen bestätigten oder gebuchten Status wechselt. Erfassung Ermitteln Sie den Timestamp, zu dem SHIPMENT.SHIPMENT_STATUS_VALUE_GID in den Status 'Booked' wechselt. Ereignistyp inferred | |||
| Sendung storniert | Diese Aktivität steht für die Stornierung einer bereits geplanten Sendung, wodurch ihr Lebenszyklus vorzeitig endet. Sie wird durch einen Statuswechsel des Shipment-Objekts in einen stornierten Status erfasst. | ||
| Warum das wichtig ist Die Nachverfolgung von Stornierungen hilft, Ausnahmen und Fehler im Prozess zu verstehen. So lassen sich Stornierungsgründe wie Änderungen des Bedarfs oder Planungsfehler erkennen. Woher beziehen Lässt sich aus dem Statusverlauf des Shipment-Objekts in der Tabelle SHIPMENT ableiten. Suchen Sie nach einem Wechsel zu einem Status wie 'PLANNING_CANCELED'. Erfassung Ermitteln Sie den Timestamp, zu dem SHIPMENT.SHIPMENT_STATUS_VALUE_GID in den Status 'Cancelled' wechselt. Ereignistyp inferred | |||
| Sendung unterwegs | Die Ware wurde abgeholt und ist auf dem Weg zum Zielort. Dabei handelt es sich nicht um einen einzelnen Zeitpunkt. Der Beginn dieses Status wird unmittelbar nach der Aktivität 'Ware abgeholt' erfasst. | ||
| Warum das wichtig ist Diese Aktivität markiert den Beginn des Transports. Sie ist entscheidend, um den Lieferfortschritt zu überwachen und Verzögerungen unterwegs zu erkennen. Sie bildet die Grundlage für das Dashboard zu Verzögerungsschwerpunkten während des Transports. Woher beziehen Dies ist dasselbe Ereignis wie 'Ware abgeholt', wird in Prozessmodellen aber häufig als eigene Aktivität dargestellt, um den Beginn einer neuen Phase zu kennzeichnen. Grundlage ist die Abfahrt vom ersten Stop. Erfassung Wie bei 'Ware abgeholt': Verwenden Sie den ACTUAL_DEPARTURE-Timestamp des ersten SHIPMENT_STOP. Ereignistyp inferred | |||
| Zollabfertigung abgeschlossen | Bei internationalen Sendungen bezeichnet diese Aktivität den Zeitpunkt, zu dem die Ware den Zoll an einer Grenze oder in einem Hafen erfolgreich passiert hat. Sie wird häufig über ein bestimmtes Sendungsereignis oder eine Statusaktualisierung erfasst. | ||
| Warum das wichtig ist Die Zollabfertigung ist bei internationalen Transporten eine häufige Ursache für erhebliche Verzögerungen. Mit der Nachverfolgung dieser Aktivität lassen sich die Durchlaufzeiten der Zollabfertigung messen und optimieren. Woher beziehen Dieses Ereignis wird üblicherweise über ein manuell erfasstes oder integriertes Sendungsereignis vom Typ 'Customs' erfasst. Suchen Sie in der Tabelle SHIPMENT_STATUS nach Ereigniscodes zur Zollabfertigung. Erfassung Ermitteln Sie den Timestamp eines Ereignisses 'Customs Cleared' in der Tabelle SHIPMENT_STATUS. Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
- BI Publisher öffnen: Melden Sie sich bei Ihrer Oracle Transportation Management-Anwendung (OTM) an. Navigieren Sie zu Business Process Automation und anschließend zu Reporting. Wählen Sie Report Manager aus. Dadurch wird die Oberfläche von Oracle Business Intelligence Publisher geöffnet.
- Datenmodell erstellen: Klicken Sie in BI Publisher auf die Schaltfläche New und wählen Sie Data Model aus. Der Editor für Datenmodelle wird geöffnet. Dort legen Sie die Datenquelle für Ihren Bericht fest.
- SQL-Abfrage festlegen: Klicken Sie im Editor für Datenmodelle im Diagramm Data Sets auf das Plus-Symbol und wählen Sie SQL Query aus. Geben Sie dem Datensatz einen Namen, zum Beispiel „OTM_Process_Mining_DS“. Wählen Sie Ihre OTM-Datenbank als Data Source aus. Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt „query“ dieses Dokuments und fügen Sie sie in das Textfeld SQL Query ein.
- Parameter hinzufügen: Die Abfrage verwendet Parameter für den Datumsbereich und den Domain-Namen (:P_START_DATE, :P_END_DATE, :P_DOMAIN_NAME). BI Publisher erkennt diese automatisch. Sie können die Eigenschaften konfigurieren, zum Beispiel den Datentyp der Datumsparameter auf Date setzen.
- Datenmodell speichern: Klicken Sie auf das Speichern-Symbol. Wählen Sie einen Speicherort im BI-Publisher-Katalog, geben Sie einen aussagekräftigen Namen wie „OTM Shipment Process Extraction“ ein und speichern Sie das Datenmodell.
- Bericht erstellen: Navigieren Sie zurück zum Katalog, klicken Sie auf New und wählen Sie Report aus. Wählen Sie im Assistenten zur Berichtserstellung die Option „Use Data Model“ und suchen Sie das soeben gespeicherte Datenmodell.
- Berichtslayout konfigurieren: Der Assistent führt Sie durch die Erstellung eines Layouts. Ein einfaches Tabellenlayout genügt. Ziehen Sie alle Spalten aus Ihrem Datensatz per Drag-and-drop in die Tabelle. Verwenden Sie keine Gruppierungen oder Aggregationen.
- Bericht speichern: Wenn das Layout fertig ist, fahren Sie mit dem letzten Schritt fort und speichern Sie den Bericht. Wählen Sie einen Namen, der dem Namen des Datenmodells ähnelt.
- Bericht ausführen: Öffnen Sie den neu erstellten Bericht. Sie werden aufgefordert, Werte für die Parameter Start Date, End Date und Domain Name einzugeben. Geben Sie den gewünschten Zeitraum ein.
- Daten exportieren: Sobald der Bericht ausgeführt wurde und die Daten angezeigt werden, öffnen Sie das Menü Actions und wählen Sie Export aus. Wählen Sie das CSV-Format. Dadurch wird eine CSV-Datei mit dem Event Log heruntergeladen.
- Upload vorbereiten: Öffnen Sie die heruntergeladene CSV-Datei. Prüfen Sie, ob die Spaltenüberschriften den erforderlichen Attributen entsprechen:
ShipmentId,ActivityName,EventTimesowie den empfohlenen Attributen. Achten Sie darauf, dass die SpalteEventTimeein einheitliches Datums- und Zeitformat verwendet. Die Datei kann jetzt in ProcessMind hochgeladen werden.
Konfiguration
- Datenquelle: Führen Sie die Abfrage im primären operativen OTM-Datenbankschema aus, das in der Regel GLOGOWNER heißt.
- Berichtsparameter:
P_START_DATE: Beginn des Berichtszeitraums. Verwenden Sie das Format „YYYY-MM-DD“.P_END_DATE: Ende des Berichtszeitraums. Verwenden Sie das Format „YYYY-MM-DD“.P_DOMAIN_NAME: Die OTM-Domain, aus der Daten extrahiert werden sollen. Verwenden Sie „[Your Domain Name]“.
- Datumsbereich: Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten. So bleibt das Datenvolumen überschaubar und die Leistung angemessen. Für den Produktivbetrieb empfiehlt sich eine monatliche oder vierteljährliche Extraktion.
- Berechtigungen: Der OTM-Benutzer, der den Bericht ausführt, benötigt bestimmte Rollen, zum Beispiel BI PUBLISHER DATA MODEL DEVELOPER und BI PUBLISHER REPORT DEVELOPER, um Datenmodelle und Berichte zu erstellen und zu ändern. Außerdem ist Lesezugriff auf die zugrunde liegenden Datenbanktabellen erforderlich.
- Leistung: Die Abfrage verknüpft mehrere große Tabellen. Bei hohem Datenvolumen empfiehlt es sich dringend, den Bericht außerhalb der Spitzenzeiten auszuführen, damit die Systemleistung nicht beeinträchtigt wird. Halten Sie den Datumsbereich möglichst kurz, damit der Bericht zeitnah abgeschlossen wird.
a Beispielabfrage sql
WITH SHIPMENTS_BASE AS (
SELECT
S.SHIPMENT_GID AS ShipmentId,
SP.SERVPROV_NAME AS CarrierName,
S.TOTAL_ACTUAL_COST AS ShipmentCost,
TM.TRANSPORT_MODE_NAME AS TransportationMode,
(
SELECT MAX(ORL.LATE_DELIVERY_DATE)
FROM SHIPMENT_S_SHIP_UNIT SSU
JOIN S_SHIP_UNIT SU ON SSU.S_SHIP_UNIT_GID = SU.S_SHIP_UNIT_GID
JOIN ORDER_RELEASE ORL ON SU.ORDER_RELEASE_GID = ORL.ORDER_RELEASE_GID
WHERE SSU.SHIPMENT_GID = S.SHIPMENT_GID
) AS RequestedDeliveryDate,
S.DOMAIN_NAME
FROM SHIPMENT S
LEFT JOIN SERVPROV SP ON S.SERVPROV_GID = SP.SERVPROV_GID
LEFT JOIN TRANSPORT_MODE TM ON S.TRANSPORT_MODE_GID = TM.TRANSPORT_MODE_GID
WHERE S.INSERT_DATE BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD') + 1
AND S.DOMAIN_NAME = :P_DOMAIN_NAME
)
-- 1. Transportation Request Received
SELECT
SB.ShipmentId,
'Transportation Request Received' AS ActivityName,
MIN(ORL.INSERT_DATE) AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
NULL AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN SHIPMENT_S_SHIP_UNIT SSU ON SB.ShipmentId = SSU.SHIPMENT_GID
JOIN S_SHIP_UNIT SU ON SSU.S_SHIP_UNIT_GID = SU.S_SHIP_UNIT_GID
JOIN ORDER_RELEASE ORL ON SU.ORDER_RELEASE_GID = ORL.ORDER_RELEASE_GID
WHERE SB.DOMAIN_NAME = ORL.DOMAIN_NAME
GROUP BY SB.ShipmentId, SB.CarrierName, SB.RequestedDeliveryDate, SB.ShipmentCost, SB.TransportationMode
UNION ALL
-- 2. Shipment Planned
SELECT
SB.ShipmentId,
'Shipment Planned' AS ActivityName,
SS.STATUS_CHANGE_DATE AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
NULL AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN SHIPMENT_STATUS SS ON SB.ShipmentId = SS.SHIPMENT_GID
WHERE SS.STATUS_CODE_GID = 'PLANNING_PLANNED FINAL'
UNION ALL
-- 3. Carrier Assigned
SELECT
SB.ShipmentId,
'Carrier Assigned' AS ActivityName,
ST.UPDATE_DATE AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
NULL AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN SHIPMENT_TENDER ST ON SB.ShipmentId = ST.SHIPMENT_GID
WHERE ST.TENDER_STATUS_GID = 'TENDER_ACCEPTED'
UNION ALL
-- 4. Shipment Booked
SELECT
SB.ShipmentId,
'Shipment Booked' AS ActivityName,
SS.STATUS_CHANGE_DATE AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
NULL AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN SHIPMENT_STATUS SS ON SB.ShipmentId = SS.SHIPMENT_GID
WHERE SS.STATUS_CODE_GID = 'SECURE RESOURCES_BOOKED'
UNION ALL
-- 5. Pickup Appointment Scheduled
SELECT
SB.ShipmentId,
'Pickup Appointment Scheduled' AS ActivityName,
SST.APPOINTMENT_START_TIME AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
NULL AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN SHIPMENT_STOP SST ON SB.ShipmentId = SST.SHIPMENT_GID
WHERE SST.STOP_NUM = 1 AND SST.APPOINTMENT_START_TIME IS NOT NULL
UNION ALL
-- 6. Goods Picked Up
SELECT
SB.ShipmentId,
'Goods Picked Up' AS ActivityName,
SST.ACTUAL_DEPARTURE_DATE AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
NULL AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN SHIPMENT_STOP SST ON SB.ShipmentId = SST.SHIPMENT_GID
WHERE SST.STOP_NUM = 1 AND SST.ACTUAL_DEPARTURE_DATE IS NOT NULL
UNION ALL
-- 7. Shipment In Transit
SELECT
SB.ShipmentId,
'Shipment In Transit' AS ActivityName,
SST.ACTUAL_DEPARTURE_DATE AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
NULL AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN SHIPMENT_STOP SST ON SB.ShipmentId = SST.SHIPMENT_GID
WHERE SST.STOP_NUM = 1 AND SST.ACTUAL_DEPARTURE_DATE IS NOT NULL
UNION ALL
-- 8. Customs Cleared
SELECT
SB.ShipmentId,
'Customs Cleared' AS ActivityName,
SE.EVENT_DATE AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
SE.EVENT_REMARK_TEXT AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN SHIPMENT_EVENT SE ON SB.ShipmentId = SE.SHIPMENT_GID
WHERE SE.EVENT_CODE = '[Your Customs Cleared Event Code]'
UNION ALL
-- 9. Delivery Appointment Scheduled
SELECT
SB.ShipmentId,
'Delivery Appointment Scheduled' AS ActivityName,
SST.APPOINTMENT_START_TIME AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
NULL AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN SHIPMENT_STOP SST ON SB.ShipmentId = SST.SHIPMENT_GID
WHERE SST.STOP_NUM = (SELECT MAX(SST2.STOP_NUM) FROM SHIPMENT_STOP SST2 WHERE SST2.SHIPMENT_GID = SB.ShipmentId)
AND SST.APPOINTMENT_START_TIME IS NOT NULL
UNION ALL
-- 10. Goods Delivered
SELECT
SB.ShipmentId,
'Goods Delivered' AS ActivityName,
SST.ACTUAL_ARRIVAL_DATE AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
NULL AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN SHIPMENT_STOP SST ON SB.ShipmentId = SST.SHIPMENT_GID
WHERE SST.STOP_NUM = (SELECT MAX(SST2.STOP_NUM) FROM SHIPMENT_STOP SST2 WHERE SST2.SHIPMENT_GID = SB.ShipmentId)
AND SST.ACTUAL_ARRIVAL_DATE IS NOT NULL
UNION ALL
-- 11. Proof of Delivery Received
SELECT
SB.ShipmentId,
'Proof of Delivery Received' AS ActivityName,
SE.EVENT_DATE AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
SE.EVENT_REMARK_TEXT AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN SHIPMENT_EVENT SE ON SB.ShipmentId = SE.SHIPMENT_GID
WHERE SE.EVENT_CODE = '[Your POD Received Event Code]'
UNION ALL
-- 12. Freight Bill Audited
SELECT
SB.ShipmentId,
'Freight Bill Audited' AS ActivityName,
B.UPDATE_DATE AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
NULL AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN BILL B ON SB.ShipmentId = B.SHIPMENT_GID
WHERE B.BILL_STATUS_GID = 'VOUCHER_AUDITED'
UNION ALL
-- 13. Payment Processed
SELECT
SB.ShipmentId,
'Payment Processed' AS ActivityName,
B.UPDATE_DATE AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
NULL AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN BILL B ON SB.ShipmentId = B.SHIPMENT_GID
WHERE B.BILL_STATUS_GID = '[Your Payment Processed Bill Status]'
UNION ALL
-- 14. Shipment Cancelled
SELECT
SB.ShipmentId,
'Shipment Cancelled' AS ActivityName,
S.UPDATE_DATE AS EventTime,
SB.CarrierName,
SB.RequestedDeliveryDate,
SB.ShipmentCost,
SB.TransportationMode,
NULL AS DelayReason
FROM SHIPMENTS_BASE SB
JOIN SHIPMENT S ON SB.ShipmentId = S.SHIPMENT_GID
WHERE S.SHIPMENT_STATUS_GID = 'SHIPMENT_CANCELLED' Schritte
- Datenbankverbindung herstellen: Besorgen Sie sich schreibgeschützte Zugangsdaten und die Verbindungsinformationen (Host, Port, Service-ID) für die Oracle-Transportation-Management-Datenbank. Sie benötigen Zugriff auf das Schema
GLOGOWNER. - SQL-Client konfigurieren: Richten Sie einen SQL-Client wie Oracle SQL Developer, DBeaver oder Toad mit den Verbindungsinformationen aus dem vorherigen Schritt ein.
- Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus diesem Dokument in den Abfrageeditor Ihres SQL-Clients.
- Abfrageparameter festlegen: Suchen Sie in den
WHERE-Klauseln der Abfrage nach Platzhaltern. Ersetzen Sie[START_DATE],[END_DATE]und[YOUR_DOMAIN_NAME]durch die passenden Werte für Ihre Datenextraktion. Legen Sie zum Beispiel einen Zeitraum von 3 bis 6 Monaten fest und geben Sie die zu analysierende operative Domain an. - Abfrage ausführen: Führen Sie die angepasste SQL-Abfrage aus. Je nach Datumsbereich und Systemgröße kann dies mehrere Minuten dauern.
- Ergebnisse prüfen: Prüfen Sie nach Abschluss der Abfrage kurz die Ausgabe in Ihrem Client. Vergewissern Sie sich, dass Zeilen zurückgegeben werden und wichtige Spalten wie
ShipmentId,ActivityNameundEventTimeWerte enthalten. - Als CSV exportieren: Exportieren Sie das vollständige Ergebnis in eine CSV-Datei. Verwenden Sie die üblichen CSV-Einstellungen: Komma als Trennzeichen, doppelte Anführungszeichen für Text und UTF-8-Codierung.
- Spaltenüberschriften prüfen: Vergewissern Sie sich vor dem Upload, dass die Spaltenüberschriften in der CSV-Datei exakt den erforderlichen Attributnamen entsprechen:
ShipmentId,ActivityName,EventTime,CarrierName,RequestedDeliveryDate,ShipmentCost,TransportationModeundDelayReason. - In ProcessMind hochladen: Die vorbereitete CSV-Datei kann jetzt in ProcessMind hochgeladen und analysiert werden.
Konfiguration
- Datenbankschema: Die Abfrage ist für das standardmäßige Oracle-Transportation-Management-Datenbankschema ausgelegt, das in der Regel
GLOGOWNERheißt. - Erforderliche Berechtigungen: Sie benötigen einen Datenbankbenutzer mit Lesezugriff auf die in der Abfrage verwendeten Tabellen. Dazu gehören
SHIPMENT,SHIPMENT_STOP,ORDER_RELEASE,SHIPMENT_STATUS,SERVPROV,SHIPMENT_COST,DOCUMENT,BILLundVOUCHER. - Filterung nach Domain: In einer OTM-Umgebung mit mehreren Mandanten ist es wichtig, nach
DOMAIN_NAMEzu filtern. Die Abfrage enthält den Platzhalter[YOUR_DOMAIN_NAME]. Konfigurieren Sie ihn so, dass Daten der richtigen Geschäftseinheit extrahiert werden. - Datumsbereich: Legen Sie ein Start- und Enddatum fest, um Leistung und Datenvolumen zu steuern. Es empfiehlt sich, nach einer indizierten Spalte wie
SHIPMENT.INSERT_DATEzu filtern. Für eine erste Analyse ist ein Zeitraum von 3 bis 6 Monaten üblich. - Anpassung der Statuscodes: Die Abfrage verwendet gängige Standardstatuscodes, zum Beispiel
PLANNING_PLANNED FINALundTENDER_ACCEPTED. Ihre OTM-Implementierung kann angepasste Statuscodes verwenden. Passen Sie gegebenenfalls die Werte in denWHERE-Klauseln an Ihre Systemkonfiguration an.
a Beispielabfrage sql
WITH ShipmentBase AS (
SELECT s.SHIPMENT_GID, s.SERVPROV_GID, s.LATE_DELIVERY_DATE, s.TRANSPORT_MODE_GID, sc.TotalShipmentCost
FROM GLOGOWNER.SHIPMENT s
LEFT JOIN (
SELECT sc.SHIPMENT_GID, SUM(sc.COST) as TotalShipmentCost
FROM GLOGOWNER.SHIPMENT_COST sc
GROUP BY sc.SHIPMENT_GID
) sc ON s.SHIPMENT_GID = sc.SHIPMENT_GID
WHERE s.INSERT_DATE BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
AND s.DOMAIN_NAME = '[YOUR_DOMAIN_NAME]'
),
OrderReleaseInfo AS (
SELECT ssu.SHIPMENT_GID, MIN(orl.INSERT_DATE) as Earliest_OR_Date
FROM GLOGOWNER.S_SHIP_UNIT ssu
JOIN GLOGOWNER.S_SHIP_UNIT_LINE ssul ON ssu.S_SHIP_UNIT_GID = ssul.S_SHIP_UNIT_GID
JOIN GLOGOWNER.ORDER_RELEASE_LINE orl ON ssul.ORDER_RELEASE_LINE_GID = orl.ORDER_RELEASE_LINE_GID
GROUP BY ssu.SHIPMENT_GID
)
-- 1. Transportation Request Received
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Transportation Request Received' AS "ActivityName",
ori.Earliest_OR_Date AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN OrderReleaseInfo ori ON sb.SHIPMENT_GID = ori.SHIPMENT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE ori.Earliest_OR_Date IS NOT NULL
UNION ALL
-- 2. Shipment Planned
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Shipment Planned' AS "ActivityName",
ss.INSERT_DATE AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.SHIPMENT_STATUS ss ON sb.SHIPMENT_GID = ss.SHIPMENT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE ss.STATUS_CODE_GID = 'PLANNING_PLANNED FINAL'
UNION ALL
-- 3. Carrier Assigned
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Carrier Assigned' AS "ActivityName",
ss.INSERT_DATE AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.SHIPMENT_STATUS ss ON sb.SHIPMENT_GID = ss.SHIPMENT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE ss.STATUS_CODE_GID = 'TENDER_ACCEPTED'
UNION ALL
-- 4. Shipment Booked
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Shipment Booked' AS "ActivityName",
ss.INSERT_DATE AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.SHIPMENT_STATUS ss ON sb.SHIPMENT_GID = ss.SHIPMENT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE ss.STATUS_CODE_GID = 'SECURE RESOURCES_BOOKED'
UNION ALL
-- 5. Pickup Appointment Scheduled
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Pickup Appointment Scheduled' AS "ActivityName",
stp.APPT_START_TIME AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.SHIPMENT_STOP stp ON sb.SHIPMENT_GID = stp.SHIPMENT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE stp.STOP_NUM = 1 AND stp.APPT_START_TIME IS NOT NULL
UNION ALL
-- 6. Goods Picked Up
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Goods Picked Up' AS "ActivityName",
stp.ACTUAL_DEPARTURE_TIME AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.SHIPMENT_STOP stp ON sb.SHIPMENT_GID = stp.SHIPMENT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE stp.STOP_NUM = 1 AND stp.ACTUAL_DEPARTURE_TIME IS NOT NULL
UNION ALL
-- 7. Shipment In Transit
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Shipment In Transit' AS "ActivityName",
stp.ACTUAL_DEPARTURE_TIME AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.SHIPMENT_STOP stp ON sb.SHIPMENT_GID = stp.SHIPMENT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE stp.STOP_NUM = 1 AND stp.ACTUAL_DEPARTURE_TIME IS NOT NULL
UNION ALL
-- 8. Customs Cleared
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Customs Cleared' AS "ActivityName",
se.EVENT_DATE AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
se.REMARK_TEXT AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.SHIPMENT_EVENT se ON sb.SHIPMENT_GID = se.SHIPMENT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE se.EVENT_CODE_GID = '[Your Customs Cleared Event Code]'
UNION ALL
-- 9. Delivery Appointment Scheduled
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Delivery Appointment Scheduled' AS "ActivityName",
stp.APPT_START_TIME AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.SHIPMENT_STOP stp ON sb.SHIPMENT_GID = stp.SHIPMENT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE stp.STOP_NUM = (SELECT MAX(s2.STOP_NUM) FROM GLOGOWNER.SHIPMENT_STOP s2 WHERE s2.SHIPMENT_GID = stp.SHIPMENT_GID)
AND stp.APPT_START_TIME IS NOT NULL
UNION ALL
-- 10. Goods Delivered
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Goods Delivered' AS "ActivityName",
stp.ACTUAL_ARRIVAL_TIME AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.SHIPMENT_STOP stp ON sb.SHIPMENT_GID = stp.SHIPMENT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE stp.STOP_NUM = (SELECT MAX(s2.STOP_NUM) FROM GLOGOWNER.SHIPMENT_STOP s2 WHERE s2.SHIPMENT_GID = stp.SHIPMENT_GID)
AND stp.ACTUAL_ARRIVAL_TIME IS NOT NULL
UNION ALL
-- 11. Proof of Delivery Received
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Proof of Delivery Received' AS "ActivityName",
d.INSERT_DATE AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.DOCUMENT d ON sb.SHIPMENT_GID = d.OBJECT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE d.OBJECT_TYPE_GID = 'SHIPMENT' AND d.DOCUMENT_TYPE_GID = 'POD'
UNION ALL
-- 12. Freight Bill Audited
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Freight Bill Audited' AS "ActivityName",
b.UPDATE_DATE AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.BILL b ON sb.SHIPMENT_GID = b.SHIPMENT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE b.APPROVAL_STATUS_GID = 'VOUCHER_AUDITED'
UNION ALL
-- 13. Payment Processed
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Payment Processed' AS "ActivityName",
v.UPDATE_DATE AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.BILL b ON sb.SHIPMENT_GID = b.SHIPMENT_GID
JOIN GLOGOWNER.VOUCHER v ON b.BILL_GID = v.BILL_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE v.VOUCHER_STATUS_GID = 'VOUCHER_PAID' -- This status may vary based on configuration
UNION ALL
-- 14. Shipment Cancelled
SELECT
sb.SHIPMENT_GID AS "ShipmentId",
'Shipment Cancelled' AS "ActivityName",
ss.INSERT_DATE AS "EventTime",
sp.SERVPROV_NAME AS "CarrierName",
sb.LATE_DELIVERY_DATE AS "RequestedDeliveryDate",
sb.TotalShipmentCost AS "ShipmentCost",
sb.TRANSPORT_MODE_GID AS "TransportationMode",
CAST(NULL AS VARCHAR(255)) AS "DelayReason"
FROM ShipmentBase sb
JOIN GLOGOWNER.SHIPMENT_STATUS ss ON sb.SHIPMENT_GID = ss.SHIPMENT_GID
LEFT JOIN GLOGOWNER.SERVPROV sp ON sb.SERVPROV_GID = sp.SERVPROV_GID
WHERE ss.STATUS_CODE_GID LIKE '%CANCELLED%'; Möchten Sie loslegen?
Mit diesem Template bereiten Sie Ihre Rohdaten so auf, dass daraus konkrete Erkenntnisse entstehen und Sie Ihre Transportprozesse gezielt verbessern können. Beginnen Sie noch heute mit der Optimierung.
Optimieren Sie Ihr Transportmanagement noch heute
Verkürzen Sie die Zykluszeit um 30 % und beseitigen Sie Engpässe in Oracle OTM.
Keine Kreditkarte erforderlich • 14 Tage kostenlos testen