数据模板:订单到收款(O2C)- 销售订单处理
订单到收款:销售订单处理数据模板
这是我们针对从订单到收款——销售订单处理的通用流程挖掘数据模板。使用我们针对特定系统的模板以获得更具体的指导。
选择特定系统- 明确完整事件日志所需的关键数据属性。
- 概述流程中的关键活动与里程碑。
- 作为流程挖掘的通用起点,可适配任意系统。
从订单到收款——销售订单处理属性
| 名称 | 描述 | ||
|---|---|---|---|
Event 时间 EventTime | 特定活动或事件发生的精确日期和时间。 | ||
描述 Event Time是记录某个活动发生确切时刻的时间戳。该属性为流程提供时间维度,使与销售订单相关的所有事件可以按时间顺序排列。 该时间戳对所有基于时间的分析至关重要。它用于计算任意两项活动之间的周期、衡量特定步骤的持续时间,并定位延误或瓶颈。例如,“Order Fulfillment Cycle Time” KPI就是最终交付活动与初始创建订单活动的Event Time差值。“Sales Order Cycle Time Overview”等仪表板完全依赖该属性运行。 为何重要 此时间戳对计算各类绩效指标至关重要,例如各环节周期和持续时长,这些指标是定位瓶颈的基础。 获取方式 通常与每条交易或状态更新记录一起出现,常标注为创建日期、变更日期或过账日期。 示例 2023-03-15T09:30:00Z2023-04-01T14:05:10Z2023-04-10T11:00:00Z | |||
活动名称 ActivityName | 销售订单流程中在某一时间点发生的具体业务事件或任务的名称。 | ||
描述 活动名称用于描述销售订单生命周期中的步骤或里程碑,如“Sales Order Created”“Credit Check Performed”“Goods Shipped”。每个活动代表对该订单的一次具体操作,是流程地图的基本单元。 分析高度依赖该属性,用于可视化流程走向、识别常见路径并发现偏离标准的情况。通过分析活动序列,分析师可以定位瓶颈、识别返工循环(例如重复出现的“Sales Order Changed”)以及发现不合规的流程变体。该属性也是“Process Conformance and Deviations”等仪表板和“Sales Order Rework Rate”等KPI的基础。 为何重要 它定义了流程中的各个步骤,从而可以可视化流程图、分析流转路径并识别返工或偏差。 获取方式 通常来源于源系统销售、发运与开票模块中的单据状态变更、事件日志或事务代码。 示例 已创建销售订单货物已发运已收款销售订单已取消 | |||
销售订单ID SalesOrderId | 销售订单的唯一标识,作为订单到收款(O2C)流程的主要流程实例标识。 | ||
描述 销售订单ID是订单到收款中流程挖掘的基石,能唯一标识自创建至关闭的每次流程实例。它作为主键将所有相关活动、事件与数据点串联,形成单个订单的端到端旅程。 在分析中,该属性用于重建每张销售订单的生命周期:追踪事件序列、衡量活动间的持续时间,并在订单层级聚合指标。例如,计算“Order Fulfillment Cycle Time” KPI需要按销售订单ID分组所有活动,并计算首末事件的时间差。 为何重要 该ID用于在流程中追踪单个订单,支持在实例级别分析周期时长、瓶颈与偏差。 获取方式 通常位于来源ERP或CRM系统的销售订单抬头表。 示例 SO-001234598004567ORD-2023-54321 | |||
最后数据更新 LastDataUpdate | 用于指示数据上次从源系统刷新或抽取时间的时间戳。 | ||
描述 此属性提供上次将数据加载到流程挖掘环境时的时间戳,反映当前分析数据的新鲜度,与记录业务活动实际发生时间的事件时间不同。 该信息虽不常用于直接的流程走向分析,但对数据治理与结论可靠性至关重要。它让分析人员和业务用户了解洞见的时效性。比如,如果上次数据更新是在一周前,那么关于当前绩效的结论就需要结合这一事实进行说明。 为何重要 该字段反映数据的新鲜度,确保分析基于最新信息,结论更具参考价值。 获取方式 这通常由数据抽取(ETL)工具或流程挖掘平台在数据导入时生成并存储。 示例 2023-10-27T02:00:00Z2023-10-26T02:00:00Z2023-10-25T02:00:00Z | |||
源系统 SourceSystem | 指明数据来源的信息系统,例如ERP、CRM或遗留平台。 | ||
描述 来源系统属性指明事件数据的产生系统。在现代企业中,订单到收款等端到端流程通常跨越多个应用,例如使用CRM创建订单,使用ERP完成履约和开票。 在分析中,该属性有助于理解流程的技术版图,识别系统间的集成点和潜在的数据一致性问题。按来源系统分析活动,可揭示某些步骤是否因执行系统不同而处理方式有别,或更容易出现延迟。 为何重要 它提供数据来源的上下文信息,这在多系统环境中尤为关键,可用于追溯数据血缘并识别各系统特有的流程变体。 获取方式 此信息通常在数据抽取(ETL)过程中添加,或作为数据仓库中的标准字段提供。 示例 SAP S/4HANASalesforce Sales CloudOracle NetSuite | |||
产品标识 ProductIdentifier | 销售订单中主产品或服务的唯一编码或名称。 | ||
描述 产品标识(如物料号或SKU)用于标识所售产品。尽管一张销售订单可以包含多个产品,该属性通常表示主产品,也可聚合到产品类别用于高层分析。 该属性支持从产品视角审视订单到收款流程。分析可揭示某些产品是否关联更长的履约周期、更频繁的交付问题或更高的取消率。这些洞察对供应链计划、库存管理和产品组合策略至关重要。例如,若发现某产品线在“Released To Warehouse”步骤持续延迟,可据此排查其库存水平或仓位布局。 为何重要 支持按不同产品或产品组分析流程绩效,帮助识别特定产品的瓶颈或问题。 获取方式 通常位于销售订单的行项目层级。用于流程实例级分析时,可由最重要的行项目或派生的产品类别来表示。 示例 PROD-5540-XLMAT-009871SVC-CONSULT-HR | |||
客户标识 CustomerIdentifier | 下达该销售订单的客户唯一标识或名称。 | ||
描述 此属性用于标识该销售订单对应的外部客户,可为唯一的客户编号、公司名称或其他用于区分客户的关键标识。 在流程挖掘中,客户标识是进行数据分段的有力维度。分析人员可以在流程图中按客户过滤,查看针对特定客户的流程表现,或比较不同客户群体(如战略大客户与偶发买家)的流程差异。这有助于发现定制化流程,或识别经常导致流程偏差或延迟的客户,为客户关系管理提供有价值的洞见。 为何重要 支持按客户或客户组筛选并对比流程,识别定制化流程或存在问题的账户。 获取方式 位于销售订单抬头数据中,并与源ERP或CRM系统的客户主数据相连。 示例 CUST-10023Global Corp Inc.758991 | |||
用户名称 UserName | 执行该活动的用户、员工或系统账号的姓名或ID。 | ||
描述 用户名属性用于标识执行某项活动的个人或自动化代理。可能是创建订单的销售代表、完成审批的信控经理,或自动过账付款的系统用户。 该属性支持以人为中心的流程分析:用于分析工作量分布、比较团队或个人绩效、识别培训机会;同时也是合规与审计追溯的关键。按用户分析活动有助于发现谁参与了返工循环或不合规行为,并且是计算“Manual Intervention Rate” KPI的基础。 为何重要 标识执行该活动的人员或系统,便于分析工作量、团队绩效、自动化程度与合规情况。 获取方式 常见于交易日志或单据变更历史中,通常标注为“创建人”或“变更人”。 示例 John.SmithBATCH_USERAlice.JonesUSER_API | |||
订单价值 OrderValue | 销售订单的总金额,通常以单据币种计价。 | ||
描述 订单金额代表该销售订单的总价值,是衡量每个流程实例规模的关键财务指标。 该属性对基于价值的流程分析尤为重要。它有助于将问题优先聚焦在高金额订单上。例如,分析师可以研究高金额订单的处理周期是否更长、返工是否更多;也可用于衡量流程低效的财务影响,如某一瓶颈导致延迟的订单总金额。由此可形成有力的业务论证,推动流程改进。 为何重要 支持基于价值的分析,聚焦高价值订单并量化延迟带来的财务影响,从而优先推进流程改进。 获取方式 可在销售订单抬头数据中获取,通常按各行项目净额之和计算。 示例 15200.50500.00125000.75 | |||
销售渠道 SalesChannel | 接收销售订单的渠道,如网站、直销或合作伙伴。 | ||
描述 销售渠道表示订单的来源或下单方式,可能来自在线门户、直销团队、与合作伙伴的EDI连接,或零售门店。 按销售渠道分析流程,常能发现效率与合规性上的显著差异。例如,Web渠道的订单自动化程度高、处理更快;而直销订单可能涉及更多人工变更和更长的审批周期。该分析有助于优化各渠道的专属流程并更有效地配置资源,也是“Order Fulfillment Bottlenecks”等仪表板的关键维度。 为何重要 可在不同渠道间对比流程绩效,洞察效率、自动化程度与合规性的差异。 获取方式 此信息通常存放于销售订单抬头数据,且在订单录入时多为必填项。 示例 网络门户直销EDI合作伙伴网络 | |||
付款到期日 PaymentDueDate | 客户需在此日期前支付发票款项。 | ||
描述 付款到期日基于发票日期和与客户约定的付款条款计算,设定按时付款的最后期限,是应收账款流程中的关键要素。 该属性是分析订单到收款财务环节的基石。它是判断付款是否准时的基准,直接用于“On-Time Payment Rate” KPI。“Invoice to Payment Cycle”仪表板也高度依赖该日期来分析付款行为并有效管理营运资金。可将发票创建至付款的延迟与该日期对标,以识别慢付客户。 为何重要 对财务分析至关重要,该日期是计算按时付款率并管理应收账款的基准。 获取方式 通常位于客户发票上,依据发票日期以及客户主数据或销售订单中设定的付款条款计算得出。 示例 2023-12-152024-01-302024-02-28 | |||
实际交付日期 ActualDeliveryDate | 货物实际送达客户的日期,标志着履约环节完成。 | ||
描述 实际交付日期是记录货物成功送达客户的时间戳,通常依据承运商提供的签收凭证。 该属性是衡量履约是否成功的最终标准。通过与客户要求的交付日期和公司确认的交付日期对比,它作为计算“On-Time Delivery Rate”的最终数据点。分析“Goods Shipped”活动与实际交付日期之间的时间差,也能评估物流伙伴与运输方式的表现。 为何重要 这是履约完成的最终凭证,对准确计算准时交付率和整体订单履约周期至关重要。 获取方式 通常来自外部物流或运输系统,并回写至ERP。也可能取自“货物已送达”活动的时间戳。 示例 2023-11-172023-12-022024-01-14 | |||
客户要求交货日期 RequestedDeliveryDate | 客户要求的交付日期。 | ||
描述 该日期代表客户期望的交付时间,是流程开始时采集的重要信息,也是衡量交付及时性的主要基准。 在流程分析中,会将期望交付日期与确认交付日期、实际交付日期等关键日期进行对比,以衡量服务水平。它是“按时交付表现”仪表板的核心输入,并用于判断从客户视角看是否按时交付。分析期望与确认日期的差距也能暴露计划与排程方面的问题。 为何重要 体现客户对交付的期望,是衡量准时交付表现与客户满意度的基准。 获取方式 通常位于销售订单抬头或行项目明细,在创建订单时录入。 示例 2023-11-152023-12-012024-01-10 | |||
拒绝原因 RejectionReason | 用于说明销售订单或行项目为何被取消或拒绝的代码或描述。 | ||
描述 当销售订单被取消或行项目被拒绝时,“拒绝原因”为这一结果提供业务背景。常见原因包括“客户取消”“价格不正确”“无库存”等。 该属性是进行流程失败根因分析的关键。通过分析不同拒绝原因的出现频率,企业可以识别系统性问题。例如,如果由于“价格不正确”导致的取消数量偏高,可能指向报价流程或主数据流程存在缺陷。这类分析能直接支持提升“一次正确率”,并减少流程浪费。 为何重要 说明订单失败的原因,便于开展根因分析,解决定价、库存或客户沟通中的深层问题。 获取方式 通常位于销售订单行层级,在取消行项目时从预设代码列表中选择。 示例 客户请求产品已停产定价错误超出信用额度 | |||
是否已自动化 IsAutomated | 标识某项活动由系统自动执行还是由用户手动完成的标记。 | ||
描述 此布尔属性用于区分由人工用户执行的任务与由系统自动化完成的任务,如后台作业、API或RPA机器人。例如,信用检查可能是自动步骤,而解除信用冻结通常需要人工处理。 从自动化视角分析流程是数字化转型的关键。该标记是计算“人工干预率”KPI的主要数据点,帮助识别流程中高度自动化与仍依赖人工的环节,从而发现进一步自动化的机会,以降低成本、减少错误并加快周期。 为何重要 区分人工与自动化任务,这对衡量自动化水平并发现流程改进机会至关重要。 获取方式 此信息可从“User Name”属性推断(例如识别系统用户“BATCH_USER”),或来自事件日志中用于跟踪执行上下文的特定字段。 示例 truefalse | |||
确认交付日期 ConfirmedDeliveryDate | 公司已确认并向客户承诺的交付日期。 | ||
描述 在核对库存与生产计划后,公司会给出“确认交付日期”。这代表对客户的承诺,也是衡量履约表现的内部基准。 该属性对于评估内部运营效率至关重要。它用于“准时交付率”KPI,通过与“实际交付日期”对比,判断企业是否兑现了承诺。如果大量订单的“客户要求交付日期”与“确认交付日期”差异显著,往往意味着ATP(可承诺量)计算或产能规划存在系统性问题。 为何重要 代表公司对客户的承诺,是衡量准时交付与履约可靠性的内部基准。 获取方式 位于销售订单的计划行数据中,常在可得性检查或生产计划运行后更新。 示例 2023-11-182023-12-012024-01-15 | |||
订单状态 OrderStatus | 事件发生时的销售订单状态,例如“Open”“In Process”或“Completed”。 | ||
描述 订单状态是在特定时间点对销售订单所处阶段的快照,是概括当前订单状态的分类标签。 相比活动序列提供的详细流程图,订单状态更适合构建简化的高层视图。它可用于筛选处于某一特定状态的订单,例如所有“On Credit Hold”的订单。分析各状态的停留时长也能揭示瓶颈,例如订单在“Waiting for Approval”状态停留过久。 为何重要 提供订单状态的总体概览,便于筛选、状态分析,并识别卡在特定阶段的订单。 获取方式 在大多数ERP或CRM系统的销售订单抬头中,这是标准字段。 示例 未结进行中信用冻结已完成已取消 | |||
从订单到收款——销售订单处理活动
| 活动 | 描述 | ||
|---|---|---|---|
发票已创建 | 此活动表示已为发运的商品或服务生成客户发票。作为核心财务交易,它正式记录客户应付款项并启动收款周期。 | ||
为何重要 从发货到开票的时间差(也称“bill-to-cash”时滞)会直接影响现金流。对此进行分析有助于识别开票流程中的延迟。 获取方式 这是一个显式事件,取自财务模块中发票或计费单据的创建时间戳。 捕获 使用应收或计费表中发票记录的创建日期和时间。 事件类型 explicit | |||
已创建销售订单 | 此活动标记系统中首次创建销售订单,正式记录客户的商品或服务需求,也是订单到收款流程的起点。 | ||
为何重要 这是流程的主要起点。从这一刻起的耗时,有助于衡量整体订单履约周期以及前端录单效率。 获取方式 该事件通常取自主销售订单抬头记录或其关联交易日志的创建时间戳。 捕获 在系统订单抬头表或单据中,找出与新建销售订单ID关联的最早时间戳。 事件类型 explicit | |||
已收款 | 此活动表示客户针对发票的付款已接收、处理并入账。该事件通常发生在应收账款模块,进而关闭相应未清项。 | ||
为何重要 这是最终的价值兑现步骤。衡量从开票到收款的耗时,对分析应收账款天数(DSO)和现金转换周期效率至关重要。 获取方式 这是一个显式财务过账事件,来自应收单据的清账日期或收款核销记录的创建时间。 捕获 使用用于结清未清发票金额的财务凭证的过账日期或清账日期。 事件类型 explicit | |||
货物已发运 | 此关键事件表示该订单已完成打包的货物已发运并实物离开仓库。作为重要的物流与财务里程碑,它往往会触发开票流程。 | ||
为何重要 这是衡量按时交付表现与履约周期时长的核心里程碑。订单创建到发运的用时是关键绩效指标。 获取方式 这通常是在发运或物流模块记录的显式事件,常见名称为“Post Goods Issue”或“Ship Confirmation”。 捕获 使用发运确认或发货过账交易的时间戳,通常保存在交货或履约单据上。 事件类型 explicit | |||
销售订单已关闭 | 这是订单成功处理后的最终活动,表示已完成发货、开票并收款。该状态意味着此销售订单不再发生后续交易。 | ||
为何重要 此活动表明流程顺利结束。从创建到关闭的总用时即为完美订单的端到端周期时长。 获取方式 通常在所有子交易完成后,从销售订单抬头的最终状态推断,例如“Closed”或“Complete”。 捕获 确定销售订单抬头的整体状态更新为最终“已完成”时的时间戳。 事件类型 inferred | |||
销售订单已取消 | 该事件表示销售订单在完全发运与开票之前被取消。这是一种未成功的流程终点,可能出现在流程的不同阶段。 | ||
为何重要 这是一种关键的失败结果。分析订单取消的时间点与原因,可揭示客户满意度、库存可用性或录入错误等问题。 获取方式 通常通过在销售订单抬头或行项目上标记特定状态(如“已取消”或“已拒绝”)来记录。 捕获 记录在销售订单上填写取消原因或标记为最终“已取消”状态时的时间戳。 事件类型 inferred | |||
销售订单已批准 | 该里程碑表示销售订单已通过所有必要的内部检查,如授信与配置审核,并已正式确认进入履约。通常伴随明确的审批动作或状态变更。 | ||
为何重要 这是把控履约流程的关键控制点。分析审批前的耗时,有助于找出订单校验和审核环节的延误。 获取方式 这通常在销售订单状态字段或工作流历史中以“Approved”、“Confirmed”或“Booked”等特定状态记录。 捕获 确定销售订单状态转为可履约的时间戳,例如“已审批”或“已预订”等。 事件类型 inferred | |||
发票已发送给客户 | 表示将已开具的发票发送给客户以便付款的时间点。该动作可通过电子邮件、电子数据交换(EDI)或邮寄等多种渠道完成。 | ||
为何重要 这标志着客户付款账期正式开始。开票到发送之间的滞后会对现金转换周期产生负面影响。 获取方式 可来源于输出管理日志、通信记录,或发票单据上的特定状态更新。 捕获 从系统输出日志中获取发票文档成功发送的时间戳。 事件类型 inferred | |||
已下达至仓库 | 此活动表示销售订单已正式移交至仓库进行实物处理,触发仓库团队开始拣货与打包。 | ||
为何重要 这是部门间至关重要的交接节点。分析该步骤所耗时间有助于发现销售与物流之间沟通的瓶颈。 获取方式 通常在生成拣货清单时,或当订单状态更新为“Ready to Pick”或“Released”时记录该事件。 捕获 确定销售订单行状态变更为可进行仓库处理状态时的时间戳。 事件类型 inferred | |||
已执行信用审核 | 此活动表示已对该订单关联客户执行信用检查。可由系统自动完成,也可人工审核,通常会更新订单的信用状态。 | ||
为何重要 这一环节常常成为瓶颈。衡量其耗时和结果,有助于分析授信管理效率及其对整体订单周期时间的影响。 获取方式 常由销售订单状态变更、解除信用冻结,或信用管理日志中的记录来推断。 捕获 记录订单授信状态字段更新为“已批准”或“已核查”,或移除与授信相关的冻结时的时间戳。 事件类型 inferred | |||
已预留库存 | 此活动表示销售订单行所需库存已被分配或预留,确保物料可用并已承诺给该订单,避免被其他订单占用。 | ||
为何重要 跟踪库存预留有助于分析物料可得性以及可能的库存相关延误。订单审批到预留之间的间隔可揭示供给问题。 获取方式 这通常是系统自动的事件,记录在库存交易表中,或通过销售订单行的状态变更体现。 捕获 从库存交易日志中提取与该销售订单行对应的锁定库存动作的时间戳。 事件类型 explicit | |||
货物已打包 | 此活动表示打包已完成:已将拣选的商品合并、包装并准备发运,通常会生成装箱单并最终确定发运明细。 | ||
为何重要 分析拣货与打包之间的用时,可优化工位布局与打包作业;这一步对发运前确保订单准确性至关重要。 获取方式 在WMS中该事件可能以独立状态记录,或可由装箱单文档的创建时间推断。 捕获 确定履约单据状态变更为“已打包”时的时间戳,或使用装箱单的创建时间戳。 事件类型 inferred | |||
货物已拣货 | 此活动表示已从仓库库位完成该订单所有物料的拣货。通常由仓库操作员在确认拣货任务完成后记录。 | ||
为何重要 衡量拣货耗时对于分析仓储效率、发现履约作业中的瓶颈至关重要。 获取方式 通常记录在仓库管理系统(WMS)模块中,或可根据交货或履约单据的状态更新推断。 捕获 记录相关拣货清单或履约单据状态更新为“已拣货”或“已完成”时的时间戳。 事件类型 inferred | |||
货物已送达 | 此活动表示货件已成功送达客户指定地址。该信息通常根据外部物流承运商返回的数据更新,或由人工确认后录入。 | ||
为何重要 跟踪交付可完整还原客户体验,并使整体订单履约周期的测量更准确。 获取方式 通常来源于外部承运商数据(回写至核心系统),或来自“签收证明”(Proof of Delivery)的确认记录。 捕获 获取承运商提供的交付确认时间戳,或手动录入的签收证明记录的时间戳。 事件类型 explicit | |||
贷项通知单已创建 | 当向客户开具贷项凭证时会发生此活动,常见于退货、价格争议或其他调整。它表示对已开票金额的冲销或减少。 | ||
为何重要 分析贷项通知单/红字发票的发生频率及原因,有助于识别产品质量、发运准确性或定价错误等系统性问题,这是衡量流程失效的重要指标。 获取方式 这是一个显式财务事件,取自计费或应收模块中贷项通知单的创建时间戳。 捕获 使用贷项凭证的创建日期和时间,通常会关联到原始销售订单或发票。 事件类型 explicit | |||
销售订单已变更 | 此活动表示销售订单在创建后发生的任何重要变更,如数量、物料、价格或需求日期的调整。通常通过跟踪系统审计日志或变更日志来获取。 | ||
为何重要 跟踪订单变更对于识别返工、理解低效来源、衡量一次正确率至关重要。频繁变更往往意味着最初录入的订单不够准确。 获取方式 可来源于系统变更日志表、审计追踪,或通过对比销售单据的不同版本获得。 捕获 过滤系统变更日志,捕捉销售订单抬头或行项目关键字段的更新,并以变更时间戳作为事件时间。 事件类型 explicit | |||
