您的订单到收款流程:销售订单处理数据模板
您的订单到收款流程:销售订单处理数据模板
这是适用于订单到收款-销售订单处理的通用流程挖掘数据模板。使用针对具体系统的模板,可获取更有针对性的指导。
选择具体系统- 列出构建完整事件日志所需的关键数据属性。
- 概述流程中的主要活动和里程碑。
- 为流程挖掘提供通用起点,可适配任意系统。
订单到收款流程:销售订单处理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 具体活动或事件发生的准确日期和时间。 | ||
| 说明 事件时间是记录活动准确发生时刻的时间戳。此属性为流程提供时间背景,可按时间顺序排列与销售订单相关的所有事件。 所有基于时间的分析都离不开此时间戳。它用于计算任意两项活动之间的周期时间、确定具体步骤的耗时,以及定位延误或瓶颈。例如,“订单履约周期时间”KPI通过计算最终交付活动与初始订单创建活动的事件时间差得出。“销售订单周期时间概览”等仪表板也完全依赖此属性。 重要性 此时间戳对于计算周期时间和持续时长等绩效指标至关重要,这些指标有助于识别瓶颈。 获取途径 通常与每条交易记录或状态更新记录一同保存,字段名称可能为创建日期、更改日期或过账日期。 示例 2023-03-15T09:30:00Z2023-04-01T14:05:10Z2023-04-10T11:00:00Z | |||
| 活动名称 ActivityName | 销售订单流程中某个时间点发生的具体业务事件或任务的名称。 | ||
| 说明 活动名称用于描述销售订单生命周期中的步骤或里程碑,例如“销售订单已创建”“信用审核已执行”或“货物已发运”。每项活动都代表针对销售订单采取的一项具体操作,是流程图的基本组成部分。 流程分析高度依赖此属性来呈现流程走向、识别常见路径并发现偏离标准过程的情况。通过分析活动顺序,分析人员可以定位瓶颈、返工循环(例如反复出现“销售订单已更改”)以及不符合规范的流程变体。此属性也是“流程一致性与偏差”仪表板及“销售订单返工率”等KPI的基础。 重要性 此属性定义流程中的各个步骤,便于呈现流程图、分析流程走向并识别返工或偏差。 获取途径 通常根据源系统销售、交付和开票模块中的凭证状态变更、事件日志或交易代码生成。 示例 销售订单已创建货物已发运已收到付款销售订单已取消 | |||
| 销售订单ID SalesOrderId | 销售订单的唯一标识符,也是订单到收款流程的主要案例标识符。 | ||
| 说明 销售订单ID是订单到收款流程挖掘的基础,可唯一标识从创建到关闭的每个流程实例。它作为主键,将所有相关活动、事件和数据点关联起来,构成单个订单的完整端到端历程。 分析时,此属性可用于还原每个销售订单的生命周期,追踪事件顺序、衡量活动间隔时长,并按订单汇总指标。例如,计算“订单履约周期时间”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)用于说明所售商品。销售订单可能包含多种产品,此属性通常代表主要产品,也可以汇总为产品类别,用于高层次分析。 此属性支持从产品维度分析订单到收款流程。分析可以揭示某些产品是否与较长的履约时间、更频繁的交付问题或较高的取消率相关。这些洞察对于供应链规划、库存管理和产品组合策略至关重要。例如,如果发现某条产品线在“已下达至仓库”步骤中持续延误,就可以进一步调查其库存水平或仓库位置。 重要性 支持分析不同产品或产品组的流程绩效,帮助识别特定产品相关的瓶颈或问题。 获取途径 位于销售订单的行项目级别。进行案例级别分析时,可以使用最重要的行项目,或使用衍生出的产品类别。 示例 PROD-5540-XLMAT-009871SVC-CONSULT-HR | |||
| 客户标识符 CustomerIdentifier | 下达销售订单的客户的唯一标识符或名称。 | ||
| 说明 此属性用于标识销售订单所服务的外部对象,可以是唯一客户编号、公司名称或其他可区分客户的标识。 在流程挖掘中,客户标识符是数据分组分析的重要维度。分析人员可以筛选流程图,查看特定客户的流程表现,也可以比较不同客户群体(例如战略客户与偶尔购买的客户)的流程走向。这有助于发现定制流程,或识别经常导致流程偏差或延误的客户,为客户关系管理提供有价值的洞察。 重要性 支持按不同客户或客户群体筛选和比较流程,从而识别定制流程或问题客户。 获取途径 位于销售订单抬头数据中,并关联到源ERP或CRM系统中的客户主数据。 示例 CUST-10023Global Corp Inc.758991 | |||
| 用户名 UserName | 执行活动的用户、员工或系统代理的姓名或ID。 | ||
| 说明 用户名属性用于标识负责执行某项活动的个人或自动化代理。例如,创建订单的销售代表、批准订单的信用经理,或自动过账付款的系统用户。 此属性支持以人为中心的流程分析,可用于分析工作量分配、比较团队或个人的绩效,以及发现培训机会。它对于合规和审计追踪也很重要。按用户分析活动,有助于发现参与返工循环或存在不合规行为的人员,也是计算“人工干预率”KPI的基础。 重要性 此属性用于识别执行活动的人员或系统,从而分析工作量、团队绩效、自动化程度和合规情况。 获取途径 通常可在交易日志或凭证更改历史中找到,字段名称可能为“创建者”或“更改者”。 示例 John.SmithBATCH_USERAlice.JonesUSER_API | |||
| 订单金额 OrderValue | 销售订单的总金额,通常以凭证币种表示。 | ||
| 说明 订单金额表示销售订单的总价值,是衡量每个案例实例规模的重要财务指标。 此属性对于基于价值的流程分析十分重要,可帮助您优先关注高价值订单,从而确定问题的处理顺序。例如,分析人员可以调查高价值订单的周期时间或返工次数是否高于低价值订单。此属性还可用于量化流程低效造成的财务影响,例如计算某个瓶颈导致延误的订单总金额,为流程改进举措提供有力的商业论证。 重要性 支持基于价值的分析,帮助您优先改进高价值订单相关流程,并量化延误造成的财务影响。 获取途径 可从销售订单抬头数据中获取,通常由所有行项目净额相加得出。 示例 15200.50500.00125000.75 | |||
| 销售渠道 SalesChannel | 接收销售订单的渠道,例如网站、直销或合作伙伴。 | ||
| 说明 销售渠道表示订单的来源或下单方式,例如在线门户、直销团队、与合作伙伴的EDI连接或零售门店。 按销售渠道分析流程,可以发现效率和一致性方面的显著差异。例如,网站渠道的订单可能高度自动化、处理速度快,而直销订单可能需要更多人工更改,审批周期也更长。此类分析有助于企业优化各渠道的具体流程走向,并更有效地分配资源。它也是“订单履约瓶颈”等仪表板的重要分析维度。 重要性 支持比较不同渠道的流程绩效,揭示效率、自动化程度和一致性方面的差异。 获取途径 此信息通常保存在销售订单抬头数据中,并且往往是录入订单时的必填字段。 示例 网络门户直销EDI合作伙伴网络 | |||
| 付款到期日 PaymentDueDate | 客户应支付发票款项的截止日期。 | ||
| 说明 付款到期日根据发票日期和客户约定的付款条款计算,用于设定按时付款的截止日期,也是应收账款流程的重要组成部分。 此属性是分析订单到收款周期中财务环节的基础。它是判断付款是否按时的基准,也是“按时付款率”KPI的直接输入。“发票至付款周期”仪表板高度依赖此日期来分析付款行为并有效管理营运资金。将发票创建到付款之间的延误与此日期进行比较,有助于识别付款较慢的客户。 重要性 此日期对于财务分析至关重要,是计算按时付款率和管理应收账款的基准。 获取途径 通常位于客户发票凭证中,根据发票日期以及客户主数据或销售订单中指定的付款条款得出。 示例 2023-12-152024-01-302024-02-28 | |||
| 实际交付日期 ActualDeliveryDate | 货物实际交付给客户的日期,标志着流程中的履约部分已完成。 | ||
| 说明 实际交付日期是记录货物成功交付给客户的时间戳,通常依据承运商提供的交付证明确定。 此属性是衡量履约是否成功的最终依据。计算“按时交付率”时,会将其与要求交付日期和确认交付日期进行比较。分析“货物已发运”活动与实际交付日期之间的时间差,也有助于了解物流合作伙伴和运输方式的绩效。 重要性 这是履约完成的最终凭证,对于准确计算按时交付率和订单履约周期时间至关重要。 获取途径 通常来自外部物流或运输系统,并集成回ERP。也可以根据“货物已交付”活动的时间戳推导。 示例 2023-11-172023-12-022024-01-14 | |||
| 拒绝原因 RejectionReason | 说明销售订单或订单行项目被取消或拒绝原因的代码或描述。 | ||
| 说明 销售订单被取消或订单项被拒绝时,拒绝原因可说明这一结果背后的业务情况。原因可能包括“客户取消”“价格错误”或“缺货”。 此属性对于分析流程失败的根本原因至关重要。通过分析各类拒绝原因的发生频率,企业可以发现系统性问题。例如,因“价格错误”而取消的订单数量较多,可能意味着报价或主数据流程存在问题。这类分析有助于提高“一次做对率”,减少流程浪费。 重要性 说明订单失败的原因,帮助您分析根本原因并解决定价、库存或客户沟通方面的问题。 获取途径 通常位于销售订单行项目级别;订单项取消时,可从预定义代码列表中选择原因。 示例 客户要求产品停产定价错误超出信用额度 | |||
| 是否自动执行 IsAutomated | 用于标记某项活动是由系统自动执行,还是由用户手动完成。 | ||
| 说明 此布尔属性用于区分由用户执行的任务和由系统自动化执行的任务,例如后台作业、API或RPA机器人。例如,信用检查可能是自动步骤,而解除信用冻结通常需要手动处理。 从自动化角度分析流程,是数字化转型项目的关键。此标记是计算“人工干预率”KPI的主要数据点,可帮助您识别流程中自动化程度较高和仍依赖人工操作的环节。分析结果有助于发现进一步自动化的机会,从而降低成本、减少错误并缩短周期时间。 重要性 区分手动任务和自动化任务,是衡量自动化水平、发现流程改进机会的关键。 获取途径 此信息可从“用户名”属性推断,例如识别“BATCH_USER”等系统用户;也可从事件日志中记录执行上下文的特定字段获取。 示例 truefalse | |||
| 确认交付日期 ConfirmedDeliveryDate | 公司向客户确认并承诺的交付日期。 | ||
| 说明 检查库存和生产计划后,公司会提供确认交付日期。这代表公司对客户作出的承诺,也是衡量履约绩效的内部基准。 此属性对于评估内部运营效率至关重要。在“按时交付率”KPI中,确认交付日期会与实际交付日期进行比较,以判断公司是否履行了承诺。如果大量订单的要求交付日期与确认交付日期存在明显差异,可能说明可承诺量(ATP)计算或产能规划存在系统性问题。 重要性 此日期代表公司对客户作出的承诺,是衡量按时交付和履约可靠性的内部基准。 获取途径 位于销售订单的计划行数据中,通常会在可用性检查或生产计划运行后更新。 示例 2023-11-182023-12-012024-01-15 | |||
| 要求交付日期 RequestedDeliveryDate | 客户要求的订单交付日期。 | ||
| 说明 此日期表示客户期望的交付时间,是流程开始时记录的重要信息,也是衡量客户对交付时效满意度的主要基准。 在流程分析中,要求交付日期会与确认交付日期和实际交付日期等关键日期进行比较,以衡量服务水平。它是“按时交付绩效”仪表板的重要输入,用于判断交付是否符合客户预期。分析要求交付日期与确认交付日期之间的差距,也有助于发现计划和排程方面的问题。 重要性 此日期代表客户对交付时间的预期,是衡量按时交付绩效和客户满意度的基准。 获取途径 通常位于销售订单抬头或行项目详情中,在创建订单时录入。 示例 2023-11-152023-12-012024-01-10 | |||
| 订单状态 OrderStatus | 事件发生时销售订单的状态,例如“未结”“处理中”或“已完成”。 | ||
| 说明 订单状态反映销售订单在特定时间点所处的生命周期阶段,是概括订单当前状态的分类标签。 活动顺序可以呈现详细的流程图,而订单状态属性则适用于创建简化的高层次流程视图。您可以筛选出当前处于特定状态的所有订单,例如所有“信用冻结”订单。分析订单在不同状态下停留的时间,也有助于发现瓶颈,例如订单在“等待批准”状态下停留过久。 重要性 此属性概括订单状态,便于筛选和分析状态,并识别停滞在特定阶段的订单。 获取途径 这是大多数ERP和CRM系统中销售订单凭证抬头的标准字段。 示例 未结进行中信用冻结已完成已取消 | |||
订单到收款流程:销售订单处理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 发票已创建 | 此活动表示已为发出的货物或提供的服务生成客户发票。这是一项核心财务交易,用于正式记录客户欠款,并启动付款周期。 | ||
| 重要性 从发货到开票的间隔称为“开票至收款”延迟,会直接影响现金流。分析这一间隔有助于发现开票流程中的延误。 获取途径 这是一个明确记录的事件,取自财务模块中发票或账单凭证的创建时间戳。 采集 使用应收账款或开票表中的发票凭证创建日期和时间。 事件类型 explicit | |||
| 已收到付款 | 此活动表示已收到、处理并核销客户的发票付款。该事件通常发生在应收账款模块,用于结清未清账的财务项目。 | ||
| 重要性 这是最终创造价值的步骤。衡量从开票到收款的时间,对于分析应收账款周转天数和现金转换周期效率至关重要。 获取途径 这是一个明确记录的财务过账事件,取自应收账款凭证的清账日期,或付款核销记录的创建时间。 采集 使用结清未付发票金额的财务凭证过账日期或清账日期。 事件类型 explicit | |||
| 货物已发运 | 这一关键事件表示订单中的包装货物已发出并实际离开仓库。这是重要的物流和财务里程碑,通常会触发开票流程。 | ||
| 重要性 这是衡量按时交付绩效和履约周期时间的核心里程碑。从订单创建到发货的耗时是关键绩效指标。 获取途径 通常会在运输或物流模块中明确记录此事件,名称可能为“货物发出过账”或“发货确认”。 采集 使用发货确认或货物发出交易的时间戳,通常可在交付或履约单据中找到。 事件类型 explicit | |||
| 销售订单已关闭 | 这是成功处理的订单的最后一项活动,表示订单已全部发货、开票并收款。此状态意味着该销售订单不会再产生其他交易。 | ||
| 重要性 此活动标志着流程成功完成。从创建到关闭的总时长代表完美订单的端到端周期时间。 获取途径 通常根据销售订单抬头中的最终状态推断,例如所有子交易完成后显示“已关闭”或“已完成”。 采集 确定销售订单抬头的整体状态更新为最终完成状态的时间戳。 事件类型 inferred | |||
| 销售订单已创建 | 此活动表示系统中首次创建销售订单,正式记录客户对商品或服务的需求,也是订单到收款流程的起点。 | ||
| 重要性 这是流程的主要开始事件。从此时起进行分析,有助于衡量整体订单履约周期时间和初始数据录入效率。 获取途径 此事件通常取自主销售订单抬头记录的创建时间戳,或相关交易日志。 采集 在系统订单抬头表或单据中,找到与新销售订单ID创建相关的首个时间戳。 事件类型 explicit | |||
| 销售订单已取消 | 此事件表示销售订单在全部发货和开票之前被取消。这是流程未成功结束的一种情况,可能发生在不同阶段。 | ||
| 重要性 这是一个严重的失败结果。分析订单取消的时间和原因,有助于发现客户满意度、库存可用性或数据录入错误方面的问题。 获取途径 通常通过销售订单抬头或行项目上的“已取消”或“已拒绝”状态记录。 采集 记录销售订单凭证中填写取消原因或设置最终“已取消”状态的时间戳。 事件类型 inferred | |||
| 销售订单已批准 | 此里程碑表示销售订单已通过信用和配置审核等必要的内部检查,并正式确认进入履约流程。通常会有明确的审批操作或状态变更。 | ||
| 重要性 这是启动履约流程的关键控制点。分析审批前的耗时,有助于发现订单验证和审核环节的延误。 获取途径 通常会在销售订单状态字段或工作流历史记录中,记为“已批准”“已确认”或“已登记”等特定状态。 采集 找到销售订单状态变更为可履约状态的时间戳,例如“已批准”或“已登记”。 事件类型 inferred | |||
| 发票已发送给客户 | 表示已创建的发票发送给客户付款的时间点。发送渠道可以是电子邮件、电子数据交换或邮寄。 | ||
| 重要性 这标志着客户付款期限正式开始计算。从发票创建到发送之间的延误会对现金转换周期产生不利影响。 获取途径 数据来源包括输出管理日志、通信记录,或发票凭证上的特定状态更新。 采集 记录系统输出日志中显示发票凭证已成功发送的时间戳。 事件类型 inferred | |||
| 已下达至仓库 | 此活动表示销售订单已正式移交仓库进行实物处理,仓库团队可据此开始拣货和包装。 | ||
| 重要性 这是部门间的重要交接点。分析此步骤的耗时,有助于发现销售与物流之间的沟通瓶颈。 获取途径 通常在生成拣货单,或订单状态更新为“待拣货”或“已下达”时记录此事件。 采集 找到销售订单行项目状态变更为可由仓库处理状态的时间戳。 事件类型 inferred | |||
| 已完成信用检查 | 此活动表示已对订单关联客户的信用状况进行检查。检查可以由系统自动完成,也可以通过人工审核进行,通常会更新订单的信用状态。 | ||
| 重要性 这是常见的瓶颈。衡量其耗时和结果,有助于分析信用管理效率及其对整体订单周期时间的影响。 获取途径 通常可根据销售订单状态变更、信用冻结解除,或特定信用管理日志中的记录推断此事件。 采集 记录订单信用状态字段更新为“已批准”或“已检查”的时间戳,或信用相关冻结解除的时间戳。 事件类型 inferred | |||
| 库存已预留 | 此活动表示已为销售订单行项目分配或预留所需库存,确保商品可用并专供该订单,避免被分配给其他订单。 | ||
| 重要性 跟踪库存预留有助于分析物料可用性和潜在的库存相关延误。订单批准到库存预留之间的耗时可以揭示采购或调配问题。 获取途径 这通常是系统自动记录的事件,记录在库存交易表中,或通过销售订单行项目的状态变更体现。 采集 从库存交易日志中,记录与特定销售订单行项目库存承诺相对应的时间戳。 事件类型 explicit | |||
| 货物已交付 | 此活动表示货物已成功送达客户指定地址。相关信息通常根据外部物流承运商提供的数据更新,也可能通过人工确认更新。 | ||
| 重要性 跟踪交付情况有助于全面了解客户体验,并准确衡量订单履约周期时间。 获取途径 通常来自外部承运商数据,这些数据会集成回核心系统;也可能来自“交付证明”确认记录。 采集 记录承运商提供的交付确认时间戳,或手动录入的“交付证明”记录中的时间戳。 事件类型 explicit | |||
| 货物已包装 | 此活动表示包装流程已完成,拣出的商品已汇总、包装并准备发运。通常还包括生成装箱单并确认最终发运信息。 | ||
| 重要性 分析拣货到包装之间的耗时,有助于优化工作站布局和包装流程。这也是发货前确保订单准确性的关键步骤。 获取途径 此事件可能作为WMS中的独立状态记录,也可根据装箱单的创建时间推断。 采集 找到履约单据状态变更为“已包装”的时间戳,或使用装箱单的创建时间戳。 事件类型 inferred | |||
| 货物已拣选 | 此活动表示已从仓库库位拣出订单所需的全部商品。通常在仓库操作员确认拣货任务完成时记录。 | ||
| 重要性 衡量拣货耗时对于分析仓库效率、识别实物履约环节的瓶颈至关重要。 获取途径 通常记录在仓库管理系统模块中,也可根据交付或履约单据的状态更新推断。 采集 记录关联拣货单或履约单据状态更新为“已拣选”或“已完成”的时间戳。 事件类型 inferred | |||
| 贷项通知单已创建 | 此活动发生在向客户开具贷项通知单时,通常用于处理产品退货、价格争议或其他调整。它表示冲销或减少此前已开票的金额。 | ||
| 重要性 分析贷项通知单的频率和原因,有助于发现产品质量、发货准确性或定价错误等系统性问题。这是流程失效的重要指标。 获取途径 这是一个明确记录的财务事件,取自开票或应收账款模块中贷项通知单凭证的创建时间戳。 采集 使用贷项通知单凭证的创建日期和时间。该凭证通常关联到原始销售订单或发票。 事件类型 explicit | |||
| 销售订单已变更 | 此活动表示销售订单创建后发生的重大修改,例如数量、商品、价格或要求日期变更。通常通过跟踪系统审计轨迹或变更日志中的更新记录来捕获。 | ||
| 重要性 跟踪订单变更对于识别流程返工、了解低效来源和衡量首次正确率至关重要。频繁变更可能表明初始订单准确性存在问题。 获取途径 数据来源包括系统变更日志表、审计轨迹,或对比销售订单单据的不同版本。 采集 筛选系统变更日志,查找销售订单抬头或行项目关键字段的更新记录,并将变更时间戳作为事件时间。 事件类型 explicit | |||
数据提取指南
不同系统的数据提取方式各不相同。详细说明请
立即开始优化销售订单处理
快速获取洞察,消除延误,改善现金流。
无需信用卡,几分钟即可完成设置。