运输管理数据模板
运输管理数据模板
- 全面分析的推荐属性
- 用于流程发现的关键跟踪活动
- Blue Yonder TMS 详细提取指南
运输管理属性
| 名称 | 描述 | ||
|---|---|---|---|
| 开始时间 EventTime | 指示特定活动或事件发生时间的时间戳。 | ||
| 描述 事件时间为装运流程中的每项活动提供精确的日期和时间。它是事件日志的时间主轴,用于对活动进行排序并计算各活动之间的持续时间。 在分析中,此时间戳对于计算所有基于时间的 KPI 至关重要,例如端到端装运周期时间、清关持续时间和准时交付表现。它能够识别延迟发生的时间点以及流程每个阶段所花费的时间。 为何重要 此 timestamp 对于事件排序、计算周期时间以及分析流程随时间变化的绩效至关重要。 获取方式 这通常存在于 Blue Yonder TMS 事务日志中的状态或事件记录旁。每个事件或状态更改都应有一个关联的 timestamp。 示例 2023-04-15T09:00:00Z2023-04-16T14:30:00Z2023-04-25T11:15:00Z | |||
| 活动 ActivityName | 运输过程中在特定时间点发生的特定业务事件或活动的名称。 | ||
| 描述 此属性描述了运输流程中的单个步骤,例如“运输计划已制定”、“承运商已招标”或“货物已交付”。这些活动构成了所发现流程图的节点,它们的顺序定义了每笔运输的流程流。 分析这些活动的顺序和频率是流程挖掘的核心。它有助于识别最常见的流程路径(变体)、发现活动发生延误的瓶颈,并精准定位重复执行(如“投标被拒绝”)的返工环节。 为何重要 它定义了流程步骤,实现了装运旅程的可视化并能识别流程中的低效环节。 获取方式 派生自 Blue Yonder TMS 各个模块中的事件日志、状态变更记录或交易代码。这通常需要将系统事件映射为业务通俗易懂的活动名称。 示例 发运计划已制定承运商已招标货物已送达付款已处理 | |||
| 运输件 ShipmentId | 单笔运输的唯一标识符,作为运输流程的 case ID。 | ||
| 描述 Shipment ID 是连接货物从起点到目的地移动过程中所有相关活动和事件的核心密钥。每个唯一的 ID 代表一个完整的运输案例,涵盖从初始请求到最终支付的所有环节。 在流程挖掘分析中,此属性是重构每件货物端到端路径的基础。它允许将“运输计划已制定”、“货物已提取”和“货物已交付”等事件分组为连贯的流程流,从而能够计算周期时间并识别单笔运输的流程变体。 为何重要 这是连接所有相关运输事件的核心 Case ID,使分析运输的整个生命周期成为可能。 获取方式 这是 Blue Yonder TMS 运输或配载管理模块中的主键。请参阅系统文档以获取特定表(可能与运输抬头相关)。 示例 SHP-0012845SHP-0012991SHP-0013054 | |||
| 最后数据更新 LastDataUpdate | 此记录的数据上次从源系统刷新或提取的 timestamp。 | ||
| 描述 此属性表示数据的时效性。它记录了事件日志上次从 Blue Yonder TMS 更新的日期和时间。 在分析中,这对于了解 dashboard 和 KPI 的实时性非常重要。它让用户知道自己看到的是实时信息还是上一个周期的数据,这对于做出明智的运营决策至关重要。 为何重要 它告知用户数据的实时性,这对于分析的相关性和准确性至关重要。 获取方式 这是一个元数据字段,通常在数据提取 (ETL) 过程中生成并添加。 示例 2023-05-20T02:00:00Z2023-05-21T02:00:00Z | |||
| 源系统 SourceSystem | 用于标识数据提取自哪个系统。 | ||
| 描述 此属性指定事件数据的来源,在本例中为 Blue Yonder TMS。在可能合并多个系统的数据以获得更广泛流程视图的环境中,它特别有用。 在分析方面,它有助于过滤数据并理解其上下文。保留此信息可确保数据血缘清晰,是数据治理的最佳实践。 为何重要 它提供了关于数据来源的关键背景,确保了可追溯性并有助于管理来自多个源的数据。 获取方式 这通常是在 data 提取、转换和加载 (ETL) 过程中添加的静态值。 示例 Blue Yonder TMSBY_TMS_NABY_TMS_EMEA | |||
| 实际送达时间 ActualDeliveryTime | “货物已交付”事件发生的实际 timestamp。 | ||
| 描述 此属性是专门与最终交付活动关联的 timestamp。它记录了货物到达目的地并确认交付的精确时刻。 它是衡量绩效的关键数据点。“准时交付率”KPI 是通过对比此 timestamp 与“要求交付日期”计算得出的。此外,它也标志着计算“整体交付吞吐量”KPI 的终点。 为何重要 此 timestamp 对于计算准时交付率和衡量总运输在途时间至关重要。 获取方式 这是“货物已交付”状态更新的 timestamp,通常通过承运商的 EDI 消息接收或在 Blue Yonder TMS 中手动录入。 示例 2023-04-25T11:15:00Z2023-05-11T09:30:00Z | |||
| 客户要求的交货日期 RequestedDeliveryDate | 客户要求或销售订单要求的交付日期。 | ||
| 描述 此属性记录了物流流程旨在达成的目标交付日期。它代表了客户的预期或该笔运输的内部服务水平协议 (SLA)。 该日期是计算“准时交付率”KPI 的基准。通过对比“实际交付时间”与“要求交付日期”,分析可以确定运输是提前、准时还是迟到。这是“准时取件和交付绩效”dashboard 的基础。 为何重要 它作为衡量准时交付表现和客户满意度的主要基准。 获取方式 这些信息通常源自 ERP 或订单管理系统等上游系统,并存储在 Blue Yonder TMS 的运输请求详情中。 示例 2023-04-25T23:59:59Z2023-05-10T17:00:00Z | |||
| 承运商名称 CarrierName | 负责运输货物的运输公司或物流提供商的名称。 | ||
| 描述 Carrier Name 标识负责执行货物运输的第三方公司。这可以是卡车公司、航空公司、航运公司或货运代理。 此属性对于绩效分析至关重要,特别是对于“承运商绩效对比”dashboard。它允许对数据进行过滤和细分,以便在准时交付率、取件依从性和平均延误时长等指标上对比不同承运商。这有助于战略性的承运商选择和关系管理。 为何重要 它支持不同承运商之间的绩效比较和分析,从而优化承运商选择并提高服务质量。 获取方式 位于 Blue Yonder TMS 的装运或负载详情中,通常关联自承运商主数据表。 示例 Global Shipping Inc.FastLane LogisticsAirExpress Cargo | |||
| 来源国 OriginCountry | 运输起始国家。 | ||
| 描述 此属性指定运输路径的起始国家。它源自发货人地址或取件地点详情。 在分析中,起运地国家是细分数据的强大维度。它有助于了解流程绩效、承运商可用性和周期时间方面的区域差异。例如,它对于分析国际运输的清关时间至关重要。 为何重要 它支持流程绩效的地理分析,有助于识别区域瓶颈或效率差异。 获取方式 存储为 Blue Yonder TMS 运输详情中起运地或发货人地址数据的一部分。 示例 美国德国中国 | |||
| 目的国 DestinationCountry | 运输送达国家。 | ||
| 描述 此属性指定货物的最终目的地国家,源自收货人地址或交付地点细节。 与起运地国家类似,此属性用于地理细分。它允许分析师对比不同贸易航线(例如,美国到加拿大 vs. 美国到墨西哥)的绩效,分析特定国家的交付挑战,并评估跨境复杂性对周期时间的影响。 为何重要 它支持按目的地进行绩效分析,这对于理解贸易通道的复杂性和区域交付挑战至关重要。 获取方式 存储为 Blue Yonder TMS 运输详情中目的地或收货人地址数据的一部分。 示例 加拿大墨西哥英国 | |||
| 运输方式 ModeOfTransport | 运输所使用的交通方式,如卡车、空运、海运或铁路。 | ||
| 描述 此属性指定运输方式。常见值包括零担 (LTL)、整车 (FTL)、空运、海运和铁路。 在流程分析中,运输方式是过滤和对比的关键维度。不同方式之间的流程、周期时间和成本可能存在显著差异。例如,“清关瓶颈分析”与空运和海运高度相关,但对国内卡车运输的相关性较低。按运输方式分析绩效有助于根据特定的物流背景定制改进方案。 为何重要 它支持细分分析,因为不同的运输方式具有不同的流程、成本和典型的周期时间。 获取方式 这是 Blue Yonder TMS 运输规划和定价模块中的标准字段。 示例 零担运输 (LTL)整车运输 (FTL)空运海运 | |||
| 运输状态 ShipmentStatus | 运输的当前或最后已知状态。 | ||
| 描述 Shipment Status(运输状态)表示货物在其生命周期中的当前状态,例如“已计划”、“在途”、“已交付”或“已取消”。它提供了货物在流程中所处位置的快照。 在流程挖掘中,分析 case 的最终状态对于结果分析至关重要。例如,通过对比“已交付”货物与“已取消”货物的流程流,可以发现导致不良结果的模式。这也有助于通过过滤尚未完成的货物来监控活跃的工作量。 为何重要 它提供了装运当前状态的快速概览,并有助于区分已完成、进行中和已取消的装运。 获取方式 这是 Blue Yonder TMS 中运输抬头或主状态跟踪表中的关键字段。 示例 已计划运输中已交付已取消 | |||
| 实际取货时间 ActualPickupTime | “货物已提取”事件发生的实际 timestamp。 | ||
| 描述 此属性记录了承运商从起运点实际提取货物的确切时间。它标志着在途阶段的正式开始。 该数据点对于衡量承运商绩效至关重要。通过将其与“计划取件时间”进行对比,可以计算出“准时取件率”和“平均取件延误时长”KPI。分析偏差有助于识别特定承运商或取件地点存在的问题。 为何重要 此 timestamp 用于准确衡量取件绩效,并识别运输流程初期的延误。 获取方式 这是“货物已提取”状态更新的 timestamp,通常通过 EDI 从承运商处接收或在 Blue Yonder TMS 中手动录入。 示例 2023-04-16T14:30:00Z2023-05-02T10:15:00Z | |||
| 延迟原因 DelayReason | 解释取货或送货延迟原因的代码或文本。 | ||
| 描述 此属性记录了未能达成运输里程碑的原因。例如“天气延误”、“海关留置”或“承运商运力问题”。这些信息通常由承运商提供。 这对于“准时取件和交付绩效”dashboard 至关重要。此属性不仅能反映运输延误,还能解释原因。通过分析最常见的延误原因,物流团队可以主动规避风险,并与承运商合作解决反复出现的问题。 为何重要 它解释了延迟的根本原因,实现了主动风险管理和针对承运商的有目标改进。 获取方式 这些数据通常在 Blue Yonder TMS 的事件或异常管理部分捕获,且往往由承运商 EDI 更新(如 EDI 214)自动填充。 示例 天气海关扣留驾驶员延误设施拥堵 | |||
| 是否按期交付 IsOnTimeDelivery | 一个计算出的标记,指示装运是否在要求的交货日期或之前送达。 | ||
| 描述 此布尔属性通过对比“实际交付时间”与“要求交付日期”得出。如果实际交付在要求日期当天或之前,则为 true,否则为 false。 作为一项计算指标,它简化了“准时交付率”KPI 的分析和可视化。它允许进行简单的过滤和聚合,以创建展示不同时间、承运商或运输方式下准时绩效百分比的 dashboard,直接支持“准时取件和交付绩效”dashboard。 为何重要 这简化了准时绩效分析,并允许在 dashboard 和 KPI 中进行快速过滤与聚合。 获取方式 源系统中不存在此属性。它是在数据转换过程中使用公式“实际交付时间 <= 要求交付日期”计算得出的。 示例 truefalse | |||
| 用户 User | 执行该活动的人员的用户 ID 或姓名。 | ||
| 描述 此属性标识负责在 TMS 中执行特定事件或状态更改的物流规划员、协调员或系统用户。对于自动事件,这可能是系统或服务账号 ID。 按用户进行分析有助于了解工作量分配、个人绩效和培训需求。它可以揭示某些用户是否与较高的返工率或延误相关,或者特定团队是否比其他团队更高效。这为资源管理和针对性的流程改进工作提供支持。 为何重要 它支持按用户或团队分析绩效和工作量,有助于识别培训需求和资源瓶颈。 获取方式 这些信息应存在于事务或事件日志中,通常表现为与每条记录关联的“修改者”或“用户 ID”字段。 示例 j.doea.smithTMS_AUTOMATION_USER | |||
| 计划取件时间 ScheduledPickupTime | 承运商计划从起运地提取货物的日期和时间。 | ||
| 描述 此属性存储了为提取货物而与承运商计划并商定的预约时间。它是运输计划中的一个关键里程碑。 此 timestamp 用作计算“准时取件率”和“平均取件延误时长”KPI 的基准。将其与“实际取件时间”进行对比,有助于识别运输初期发生的延误,这种延误通常会对后续里程碑产生连锁反应。 为何重要 它是衡量准时取货表现的基准,也是承运商可靠性和计划准确性的关键指标。 获取方式 位于 Blue Yonder TMS 的预约调度或负载计划模块中。 示例 2023-04-16T14:00:00Z2023-05-02T10:00:00Z | |||
| 运费账单差异 FreightBillDiscrepancyReason | 解释运费账单审计未通过原因的代码或描述。 | ||
| 描述 当运单审计结果出现偏差时,此属性会提供原因。例如“费率错误”、“重复发票”或“缺少交付凭证”。 此属性是“交付凭证与账单准确性”dashboard 和“运单返工率”KPI 的核心。分析各种偏差原因的频率有助于识别账单错误的根源(无论是源自承运商失误、合同不一致还是内部流程问题)。这为减少发票返工的针对性行动提供了依据。 为何重要 它提供了计费错误的根本原因,从而实现有针对性的改进,减少运费账单返工和付款延迟。 获取方式 位于 Blue Yonder TMS 的运费审计和付款模块中,与异常或拒绝日志相关联。 示例 费率应用错误重复发票杂费争议 | |||
| 运输周期 ShipmentCycleTime | 从第一个活动到最后一个活动的运输总时长。 | ||
| 描述 此计算指标衡量单笔运输 case 的总耗时。通常计算为最后一个事件(如“付款已处理”)与第一个事件(如“收到运输请求”)之间 timestamp 的差值。 此属性直接支持“运输端到端周期时间”KPI 和 dashboard。分析其分布有助于了解整体流程效率、识别异常值(运行时间异常长的 case),并跟踪改进措施对总流程时长的影响。 为何重要 它提供了整体流程效率的高级评估,是识别周期过长或存在问题的装运的关键指标。 获取方式 该指标在流程挖掘工具内或数据转换期间,通过从每个 case (ShipmentId) 的最大事件时间减去最小事件时间计算得出。 示例 10天4小时25天11小时15天2小时 | |||
运输管理活动
| 活动 | 描述 | ||
|---|---|---|---|
| 付款已处理 | 这是运输生命周期中的最后一个活动,确认已向承运商支付运输服务费用。此事件通常起源于外部财务系统 (ERP),并更新回 TMS。 | ||
| 为何重要 此活动标志着该笔运输在财务上的结案。分析从交付或审计到付款的周期时间对于管理营运资金和维护良好的承运商关系至关重要。 获取方式 这通常是一个明确事件,当来自应付账款或 ERP 系统的接口消息更新了 TMS 中运单的支付状态时记录。 捕获 使用从财务系统收到的付款确认消息中的 timestamp。 事件类型 explicit | |||
| 已清关 | 对于国际装运,此活动标志着货物已成功通过边境或港口海关。该事件由报关行或承运商的通知触发。 | ||
| 为何重要 在国际物流中,海关是常见的主要延误来源。衡量清关所需时间对于识别瓶颈和缩短跨境运输时间至关重要。 获取方式 这通常基于承运商消息(如 EDI 214)或手动更新被记录为明确事件,从而将运输的海关状态更改为“已清关”。 捕获 捕获装运的海关状态更新为“已清关”的时间戳。 事件类型 explicit | |||
| 收到运输请求 | 此活动标志着在 Blue Yonder TMS 中创建了运输需求,通常由 ERP 等上游系统的订单发起。它代表了运输生命周期的正式开始,此时会创建一个初始状态为“未计划”或“新建”的新运输记录。 | ||
| 为何重要 这是端到端运输流程的首要启动事件。分析从该事件到后续规划活动的时间,有助于识别初始处理延误并衡量整体吞吐量。 获取方式 此事件通常推断自核心运输或订单表中运输记录的创建 timestamp。它也可以是在处理来自 ERP 的接口消息时记录的明确事件。 捕获 使用运输记录的创建 timestamp。 事件类型 inferred | |||
| 订舱完成 | 此里程碑表示承运商已接受招标并承诺处理该笔运输。运输状态更新为“已订舱”或“已承诺”,从而锁定了运输的承运商和费率。 | ||
| 为何重要 这是一个关键里程碑,标志着规划阶段的结束,并将运输转入执行阶段。衡量到此点为止的周期时间有助于评估订舱效率和响应速度。 获取方式 当收到并处理承运商接受消息(如 EDI 990)时,将捕获此事件,从而触发 TMS 中运输记录的状态明确更改。 捕获 捕获状态变更为“已预订”或“已承诺”的时间戳。 事件类型 explicit | |||
| 货物已提取 | 此活动标志着运输在物理层面的开始,即承运商从起运地提取货物。此事件通常根据承运商的状态更新消息(如 EDI 214 事务)记录在 Blue Yonder TMS 中。 | ||
| 为何重要 这是一个关键的执行里程碑,确认运输正在进行中。它作为计算在途时间和衡量相对于计划日期的准时取件绩效的基准。 获取方式 这是从承运商状态更新中捕获的明确事件。当处理取件确认(例如,状态为 'AF' 或 'X3' 的 EDI 214)时,系统会记录该 timestamp。 捕获 使用已处理的 EDI 214 或其他承运商取件确认消息中的 timestamp。 事件类型 explicit | |||
| 货物已送达 | 此里程碑表示货物已实际到达收货人目的地。承运商提供此确认(通常通过 EDI 214 消息),并更新 TMS 中的运输状态。 | ||
| 为何重要 这是一个关键的成功里程碑,标志着物理运输的结束。它是衡量准时交付绩效的基础,也是客户满意度和承运商可靠性的关键指标。 获取方式 这是从承运商交付确认消息中捕获的明确事件。当处理 EDI 214(状态为 'D1')或等效消息时,TMS 会记录该 timestamp。 捕获 使用已处理的承运商交付确认消息中的 timestamp。 事件类型 explicit | |||
| 发运计划已制定 | 代表初始规划阶段的完成,在此阶段确定了货物的路线、运输方式和潜在承运商。系统规划引擎生成解决方案,并更新运输状态以反映计划已就绪。 | ||
| 为何重要 跟踪此活动有助于衡量规划和优化引擎的效率。涉及此步骤的延误或返工环节可能预示着主数据、承运商可用性或系统配置存在问题。 获取方式 这很可能是从运输实体的状态更改中推断出来的,例如从“未计划”变为“已计划”。该状态更改的 timestamp 即标记了此事件。 捕获 捕获装运状态变更为“已计划”状态的时间戳。 事件类型 inferred | |||
| 已收到交付凭证 | 此活动代表收到确认交付的正式文件,例如签署的提单。这通常是物理交付后的一个独立步骤,也是运费支付的前提条件。 | ||
| 为何重要 高效接收交货证明 (POD) 对于加速账单和付款周期至关重要。这一环节的延误会直接影响现金流并导致承运商付款争议。 获取方式 这通常在用户手动将 POD 标记为已收到或将文件附加到 TMS 中的运输记录时捕获,从而触发状态更改。 捕获 捕获装运上设置“收到 POD”标记或状态的时间戳。 事件类型 inferred | |||
| 承运商已招标 | 当货物正式邀约特定承运商接受时,会发生此活动。这是 TMS 中的一个独立动作,通常会通过 EDI 204 事务、电子邮件或门户通知触发与承运商的沟通。 | ||
| 为何重要 此事件是衡量承运商响应速度和投标接受率的起点。分析从招标到承运商响应之间的时间,是了解承运商关系效率的关键。 获取方式 当用户或系统执行招标操作时,Blue Yonder TMS 可能会将其作为显式事件记录在装运历史记录表或招标历史记录表中。 捕获 执行招标操作时记录在装运事件历史中。 事件类型 explicit | |||
| 投标被拒绝 | 此事件表示承运商拒绝了该笔运输的邀约。这种拒绝通常通过 EDI 990 事务以电子方式接收,或在承运商门户中手动更新,从而触发寻找替代承运商的工作流。 | ||
| 为何重要 跟踪投标拒绝情况对于识别承运商选择中的返工环节至关重要。高拒绝率可能预示着定价、承运商运力或载货信息不准确等问题,从而导致延误和成本增加。 获取方式 这通常在 TMS 处理承运商拒绝响应时被捕获为明确事件,从而更新运输的招标状态。 捕获 收到承运商拒绝消息(例如 EDI 990)时作为事件记录。 事件类型 explicit | |||
| 收到在途更新 | 代表收到承运商在货物运输途中的位置或状态更新。这些更新通常来自 EDI 214 消息,让货物的进度和任何潜在延误变得透明可视化。 | ||
| 为何重要 这些事件对于跟踪运输进度和识别在途延误至关重要。缺乏更新可能预示着可见性缺口,而频繁的延误更新则释放了承运商绩效问题的信号。 获取方式 这些是在每次收到并处理承运商在途消息(例如,状态为 'X1'、'AG' 的 EDI 214)时,记录在运输跟踪或事件历史表中的明确事件。 捕获 每条处理过的在途承运商消息都会创建一个新的事件日志条目。 事件类型 explicit | |||
| 运费账单已审计 | 承运商的发票或运单已根据合同费率、附加费和交付凭证进行了系统或人工审计。此步骤在批准付款前核实费用。 | ||
| 为何重要 这是一个关键的财务控制点。分析审计流程可以揭示频繁的账单偏差,而此阶段的返工则预示着会增加行政间接费用的问题。 获取方式 当与运输关联的运单在 TMS 货运审计模块中的状态更改为“已审计”、“已批准付款”或类似状态时,将捕获此事件。 捕获 捕获与装运关联的运费账单实体上状态变更的时间戳。 事件类型 inferred | |||
| 运输已取消 | 代表货物在提取前的终止。这可能由于各种原因发生,例如客户取消订单或计划变更,它作为最终的、未成功的结束状态。 | ||
| 为何重要 跟踪取消情况对于了解需求波动和流程浪费至关重要。分析运输被取消的原因可以揭示订单管理或规划流程中的问题。 获取方式 这是一个明确事件,当用户或自动化流程将运输的主状态更改为“已取消”时捕获。 捕获 捕获状态变更为“已取消”的时间戳。 事件类型 explicit | |||
提取指南
该流程的提取方法正在验证中。请稍后回来查看或 联系我们 寻求帮助。