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