您的采购到付款请购数据模板
您的采购到付款请购数据模板
这是适用于采购到付款-请购的通用流程挖掘数据模板。使用针对具体系统的模板,可获取更有针对性的指导。
选择具体系统- 标准化数据字段,便于在不同系统间进行一致分析。
- 列出需要跟踪的关键活动,全面了解流程。
- 灵活的基础框架,可根据您的采购到付款请购工作流进行调整。
采购到付款请购属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 活动发生的准确日期和时间,是事件排序的主要时间戳。 | ||
| 说明 事件时间通常也称为时间戳,用于记录活动发生的准确时刻。这项数据对于正确排列事件以及开展各类时间分析至关重要,包括计算周期时间、识别瓶颈和监控绩效。 在流程挖掘中,时间戳用于排列每个案例中的活动,并衡量不同步骤之间的耗时。分析这些时长有助于发现延迟、了解周期时间过长的原因,并评估是否达到服务级别协议要求。准确、完整的时间戳数据是开展有效绩效分析的前提。 重要性 此时间戳对于排列事件、计算周期时间、分析流程绩效和识别瓶颈至关重要。 获取途径 通常记录在系统审计轨迹或事件日志中,也可能作为事务记录的创建日期或变更日期保存。 示例 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:45Z | |||
| 活动名称 ActivityName | 请购申请在某个时间点发生的具体业务活动或事件名称。 | ||
| 说明 活动名称用于描述采购请购申请生命周期中的单个步骤或状态变更。它以易于理解的名称标记事件,例如“请购申请已提交”“审批步骤已开始”或“请购申请已拒绝”,构成流程图的基本要素。 此属性是流程发现与分析的基础。按顺序排列这些活动后,流程挖掘工具可以呈现实际流程,识别偏离标准过程的情况,并找出瓶颈或返工循环。活动名称保持一致且含义明确,才能建立易于理解并可用于改进的流程模型。 重要性 它定义流程中的各个步骤,是呈现流程图和分析流程顺序的基础。 获取途径 通常取自事件日志、状态变更表,或与请购单据关联的事务代码。 示例 创建采购申请批准审批步骤采购订单已创建 | |||
| 采购请购申请ID PurchaseRequisitionId | 每份采购请购申请的唯一标识符,也是流程中的主要案例标识符。 | ||
| 说明 采购请购申请ID是在创建请购单据时分配的唯一键。它是单个申请从发起到完成期间所有活动、变更和审批的核心关联标识。 在流程挖掘中,此ID对于案例关联至关重要。系统借此重建每份请购申请的端到端历程,将“请购申请已创建”“审批步骤已批准”和“采购订单已创建”等不同事件串联成连贯的流程。没有一致且唯一的案例标识符,就无法分析流程变体、周期时间和结果。 重要性 这是跟踪请购申请完整生命周期的关键标识,可将所有相关事件关联到同一个流程实例。 获取途径 通常位于采购请购申请事务或单据表的抬头数据中。 示例 PR-100567REQ00043218000123987 | |||
| 数据最后更新时间 LastDataUpdate | 表示此记录的数据最近一次从源系统刷新或提取的时间戳。 | ||
| 说明 数据最后更新时间戳用于说明所分析数据的新鲜度,显示记录最近一次从源系统提取并加载到流程挖掘环境的时间。 此属性对于运营监控至关重要,有助于确保分析基于最新信息。它也能帮助用户了解现实事件与流程模型中相应记录之间可能存在的延迟。跟踪日常运营的仪表板和KPI依赖此信息,以提供及时、相关的洞察。 重要性 它能让用户了解数据的时效性,这对于确保分析结果切合当前情况至关重要。 获取途径 通常由数据集成或ETL(提取、转换、加载)工具在加载数据时添加。 示例 2024-05-20T02:00:00Z2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| 源系统 SourceSystem | 标识数据提取自哪个信息系统,例如ERP或采购平台。 | ||
| 说明 源系统属性用于说明流程数据的来源。在使用多个系统的组织中,例如同时使用中央ERP和专用电子采购工具,此字段有助于区分不同来源的数据。 这些信息有助于验证数据、排查问题,并了解流程差异是否与系统有关。例如,来自某个系统的请购申请可能采用不同的审批路径,或比来自其他系统的申请周期更短。按源系统分析数据,可以发现集成问题或系统整合机会。 重要性 它说明数据来源,有助于验证数据并分析多个系统之间的流程差异。 获取途径 通常是在数据提取过程中添加的固定值,也可能存储在技术元数据字段中。 示例 SAP S/4HANAOracle FusionCoupa | |||
| 申请人姓名 RequesterName | 创建并提交采购请购申请的员工或用户姓名。 | ||
| 说明 申请人姓名用于标识发起采购申请的人员,通常是需要相关商品或服务的业务用户。 按申请人分析流程,有助于发现与特定个人或群体相关的规律。例如,您可以识别经常提交信息不完整或不符合要求的请购申请、导致返工的申请人。组织可据此开展针对性培训,或简化常见用户群体的申请流程,从而提升效率和合规水平。 重要性 它有助于识别特定用户的行为,从而为个人或团队提供针对性培训并改进流程。 获取途径 位于采购请购申请的抬头数据中,通常关联员工主数据。 示例 John SmithJane DoeMaria Garcia | |||
| 请购申请状态 RequisitionStatus | 采购请购申请在生命周期中的当前状态或最终状态。 | ||
| 说明 请购申请状态表示申请在某个时间点所处的状态或最终结果。常见状态包括“处理中”“等待审批”“已批准”“已拒绝”和“已关闭”。 此属性对于结果分析和运营监控至关重要。分析人员可以按请购申请的最终状态筛选数据,计算拒绝率或转为采购订单的比例等指标。在运营中,团队可借此了解当前工作量,例如等待审批的申请数量,从而合理安排优先级并有效管理资源。 重要性 它清晰呈现请购申请的结果,支持计算拒绝率等关键指标,并帮助管理运营工作量。 获取途径 通常位于采购请购单据的抬头状态字段中。 示例 已批准已拒绝等待审批已撤回 | |||
| 请购申请类型 RequisitionType | 请购申请的类别或类型,例如商品、服务或资本支出。 | ||
| 说明 请购申请类型根据采购申请的性质或用途进行分类,例如标准物料、服务、资本支出或特定目录中的商品。此分类通常决定审批工作流和会计处理方式。 按请购申请类型分析流程,有助于了解不同类型的申请是否采用不同路径或效率各异。例如,资本支出申请可能因需要额外审批层级而周期更长,而标准目录商品的申请则可能高度自动化。此类分析有助于设计并优化针对不同类型的流程变体。 重要性 它支持分析不同的流程路径,因为请购申请类型通常决定所需的审批工作流和流程复杂度。 获取途径 此信息通常以单据类型或类别代码的形式存储在请购申请抬头数据中。 示例 资本支出运营支出服务申请物料申请 | |||
| 请购申请金额 RequisitionAmount | 采购请购申请的总金额。 | ||
| 说明 请购申请金额表示采购请购申请中所有商品和服务的总金额,是采购流程中的一项关键财务指标。 在流程分析中,此属性对于按金额筛选和分析至关重要。您可以据此将请购申请划分为高金额和低金额等类别,这些类别通常对应不同的审批工作流和风险特征。按申请金额分析周期时间或拒绝率,可能会发现高金额申请的审批时间明显更长,或更容易被拒绝,从而为流程改进提供切入点。 重要性 它支持按金额开展分析,帮助您优先处理高金额请购申请,并了解金额如何影响流程表现。 获取途径 通常位于采购请购申请事务或单据表的抬头数据中。 示例 500.0012500.7599.95 | |||
| 货币 Currency | 请购申请总金额所用的货币代码,例如USD或EUR。 | ||
| 说明 货币属性用于指定请购申请金额的计价单位。跨国组织的请购申请可能使用不同货币,具体取决于申请人或供应商所在地区。 此字段对于准确的财务报告和分析至关重要。它能确保正确解读金额,并支持汇总不同地区的数据时进行适当换算。任何涉及请购申请金额的分析都必须考虑货币,避免直接比较不同计价单位的金额。 重要性 它为财务数据提供必要的背景信息,确保准确解读并汇总不同地区的请购申请金额。 获取途径 通常位于采购请购申请事务的抬头数据中,与金额字段相邻。 示例 USDEURGBP | |||
| 部门 Department | 请购申请所归属的业务部门、成本中心或组织单元。 | ||
| 说明 部门属性表示负责采购的组织单元,例如“市场营销”“IT”或“财务”。这是用于预算编制和成本分摊的重要财务与组织数据。 在流程挖掘中,按部门分析数据是一种常见方法。通过比较不同业务单元的绩效,可以发现哪些部门效率较高,哪些部门可能需要支持。此类分析还能揭示部门采购习惯或内部流程所导致的周期时间、审批率或合规情况差异。 重要性 它支持跨业务单元开展绩效对标和成本分析,揭示各部门特有的流程表现。 获取途径 通常可在采购请购申请的抬头或申请行数据中找到,并关联公司的组织架构。 示例 市场营销信息技术财务运营 | |||
| 采购订单ID PurchaseOrderId | 根据已批准的请购申请创建的采购订单标识符。 | ||
| 说明 采购订单ID是根据已批准的采购请购申请生成的采购订单单据的唯一编号。此字段将请购流程与后续采购和付款流程关联起来。 此属性对于分析请购申请转为采购订单的效率至关重要。它可以确认请购申请是否成功生成采购订单,并用于衡量转换所需时间。通过分析哪些请购申请有对应的采购订单,企业可以评估采购前阶段的成效,并找出已获批但最终未完成的申请。 重要性 它将请购申请与后续采购流程关联起来,支持分析请购申请转为采购订单的比例和所需时间。 获取途径 采购订单创建后,通常可在请购单据数据中找到,有时也会记录在相关单据表或单据流转表中。 示例 PO-4500012345ORD7890016000054321 | |||
| 审批人姓名 ApproverName | 负责执行审批或拒绝操作的用户或群组名称。 | ||
| 说明 审批人姓名用于标识在工作流中执行审批或拒绝步骤的个人、角色或群组,与申请人或执行其他活动的一般用户不同。 此属性是分析审批流程的关键。它有助于衡量审批人的绩效,例如审批人平均需要多长时间作出决定。它还可以显示工作量分布,找出流程中由哪些审批人造成瓶颈。此类分析有助于优化审批链中的资源分配和绩效管理。 重要性 它支持深入分析审批工作流,包括审批人的工作量和绩效,以及瓶颈识别。 获取途径 记录在审批相关活动的事件日志或审计日志中。可能需要与员工主数据关联。 示例 Alice JohnsonBob Williams财务审批组 | |||
| 拒绝原因 RejectionReason | 审批人拒绝请购申请或审批步骤时提供的原因。 | ||
| 说明 拒绝原因是用于说明请购申请未获批准原因的文本字段或代码。审批人会填写此信息,向申请人提供反馈,以便申请人修改并重新提交。 此属性对于分析流程失败的根本原因极有价值。通过分类和分析拒绝原因,组织可以发现常见问题,例如“总账科目代码错误”“超出预算”或“供应商不符合要求”。这些洞察可用于推动有针对性的改进,例如加强申请人培训、明确传达政策,或改进系统以避免常见错误。 重要性 它直接揭示请购申请未获通过的原因,有助于分析根本原因、减少返工并提高首次审批通过率。 获取途径 通常记录在与“已拒绝”活动或状态变更关联的评论或备注字段中。 示例 超出预算成本中心错误重复申请违反政策 | |||
| 用户名 UserName | 执行特定活动(例如创建、编辑或审批)的用户姓名。 | ||
| 说明 用户名用于标识流程日志中每项活动的负责人。这是一项通用属性,可记录申请人、编辑者、审批人或其他参与请购流程的人员。 这项属性对于资源分析和自动化分析至关重要。它有助于了解“四眼原则”(不同用户之间的交接),也可通过识别由系统用户或批处理用户执行的活动来计算自动化率。按用户分析活动,有助于了解不同角色如何参与流程。 重要性 这项属性对于了解用户交接、分析自动化情况,以及将具体流程步骤归属到正确的执行者至关重要。 获取途径 可在每笔交易的审计跟踪或事件日志数据中找到,通常以用户ID的形式存储。 示例 asmithjdoeBATCH_USER | |||
| 紧急程度 UrgencyLevel | 用于标记请购申请优先级或紧急程度的分类,例如“高”“中”或“低”。 | ||
| 说明 紧急程度有时也称为优先级,申请人可通过此字段说明所需商品或服务的紧急程度。此分类可能影响采购团队和审批人如何分派及优先处理请购申请。 按紧急程度分析流程绩效,有助于判断流程能否及时响应业务需求。例如,可以核实标记为“高”的申请是否确实比“低”的申请处理得更快。如果没有,可能说明存在瓶颈,或优先级机制未能有效发挥作用,需要进一步处理。 重要性 它有助于评估流程是否有效优先处理紧急申请,以及标记的紧急程度是否与实际处理速度相符。 获取途径 通常是创建请购申请表单上的可选或必填字段,存储在申请抬头中。 示例 高中低紧急 | |||
| 要求日期 RequiredByDate | 申请人要求交付货物或服务的日期。 | ||
| 说明 要求日期由申请人填写,用于注明需求完成的截止时间。此日期是整个采购流程的目标时间,涵盖从请购审批到最终交付的各个环节。 这项属性有助于分析流程是否及时,以及是否符合业务需求。将要求日期与实际创建采购订单或交付的日期进行比较,组织便可衡量自身是否达到内部服务级别协议。它还能帮助回答关键问题,例如采购流程能否及时满足业务期限。 重要性 它为衡量流程绩效是否符合业务期限,以及评估能否按时完成需求提供了基准。 获取途径 通常由用户在创建请购单时填写,并存储在请购单抬头或行项目明细中。 示例 2024-06-302024-07-152024-08-01 | |||
采购到付款请购活动
| 活动 | 说明 | ||
|---|---|---|---|
| 修改采购申请 | 申请人在提交后修改采购申请,通常是为了更正信息或回应拒绝结果。修改内容可能包括数量、价格或行项目等详细信息,也可能需要重新启动审批流程。 | ||
| 重要性 追踪修改对于识别返工循环、流程低效和初始需求不明确等问题至关重要。修改率高会显著延长周期时间。 获取途径 数据来源包括系统审计跟踪、变更日志,或采购申请单新版本的创建记录。 采集 从变更日志或审计日志中识别与首次提交后修改关键采购申请字段相关的事件。 事件类型 explicit | |||
| 创建采购申请 | 用户创建新的采购申请单,发起商品或服务申请。这标志着采购申请生命周期的开始,申请通常先处于草稿或未完成状态,之后才会正式提交。 | ||
| 重要性 这是流程的主要开始事件。分析从创建到提交的耗时,有助于发现申请准备延误或用户不确定等问题。 获取途径 通常从采购申请主表或记录中的创建时间戳获取。 采集 确定采购申请主记录的初始创建时间戳。 事件类型 explicit | |||
| 提交采购申请 | 申请人正式提交已填写完整的采购申请,进入审批工作流。此操作会使申请从草稿状态转为活跃状态,等待审核和批准。 | ||
| 重要性 此事件会启动正式审批流程。从提交到最终获批的时间,是整体周期时间的重要组成部分。 获取途径 通常从状态变更事件、用户操作日志或工作流引擎日志中获取,这些记录会显示审批流程的开始时间。 采集 记录采购申请状态从草稿变为待审批状态时的时间戳。 事件类型 explicit | |||
| 请购申请已关闭 | 请购申请已完成行政关闭,后续不再处理。通常,在所有申请行都已转为采购订单或取消后关闭。 | ||
| 重要性 这是流程的最终结束事件,表示请购申请的生命周期已完成,可避免旧申请长期处于未关闭状态。 获取途径 根据请购申请抬头的最终状态更新推断,或在所有关联申请行均标记为已全部订购或已关闭时推断。 采集 记录请购申请的最终状态设为“已关闭”或“已完成”时的时间戳。 事件类型 inferred | |||
| 请购申请已批准 | 请购申请已成功通过审批工作流中的所有必需步骤。达到此节点后,申请即可进入寻源环节或转为采购订单。 | ||
| 重要性 这是关键的成功节点。从申请提交到达到此状态的耗时,是衡量请购流程效率的主要指标。 获取途径 根据请购申请抬头的整体状态变化推断,例如工作流日志中的状态变为“已批准”或类似的最终批准状态。 采集 记录请购申请整体状态首次变为“已批准”或等效状态时的时间戳。 事件类型 inferred | |||
| 请购申请已拒绝 | 请购申请在审批过程中被最终拒绝,不会转为采购订单。这表示申请最终未获通过。 | ||
| 重要性 这是关键的失败节点。分析最终拒绝的原因,有助于改进前端流程并加强申请人培训。 获取途径 根据请购申请抬头的整体状态变化推断,例如状态变为“已拒绝”“未获批准”或类似的最终拒绝状态。 采集 记录请购申请整体状态首次变为“已拒绝”“未获批准”或等效状态时的时间戳。 事件类型 inferred | |||
| 采购订单已创建 | 根据一个或多个已批准的请购申请行生成正式采购订单。此事件标志着流程从内部申请转入外部采购。 | ||
| 重要性 这是请购流程的主要成功结果。从最终批准到创建采购订单的耗时,可用于衡量采购部门的效率。 获取途径 查找引用请购申请ID的对应采购订单,据此推断该申请发生了此事件。 采集 识别引用请购申请ID的采购订单的创建时间戳。 事件类型 inferred | |||
| 审批步骤被拒绝 | 审批人在指定阶段拒绝请购申请,通常会将申请退回给申请人修改。此操作会中断审批工作流的后续进展。 | ||
| 重要性 这类活动是返工的主要原因之一。跟踪拒绝情况有助于发现常见问题、培训需求和存在问题的审批环节。 获取途径 根据审批历史日志或工作流事务数据中记录的明确用户操作捕获。 采集 从审批历史记录或工作流日志中提取拒绝事件,包括审批人和时间戳。 事件类型 explicit | |||
| 审批重置 | 请购申请的整个审批工作流被重置,流程必须从头开始。通常,已在审批中的请购申请发生重大修改后会触发重置。 | ||
| 重要性 审批重置是周期时间延长的重要原因。了解重置频率和触发因素,有助于发现政策问题或修改流程中的问题。 获取途径 观察审批状态是否被清除或重置为初始步骤。如果此前已分配给后续审批人,则可据此推断发生了重置。 采集 识别审批工作流已进入后续步骤后,状态又返回初始状态的情况。 事件类型 inferred | |||
| 已分配供应来源 | 采购员或采购专员为已批准的请购申请行分配特定供应商、合同或价格协议。这是创建采购订单前的准备步骤。 | ||
| 重要性 此活动用于衡量战术采购团队的效率。此处的延迟可能造成请购申请获批到下达订单之间的瓶颈。 获取途径 请购申请行获批后,通过观察供应商或供应来源信息字段的更新来捕获此事件。 采集 识别已批准的请购申请行首次填入供应商或合同ID的时间戳。 事件类型 explicit | |||
| 开始审批步骤 | 作为多步骤工作流的一部分,采购申请会分配给特定审批人或审批组。此活动标志着该项审批等待期的开始。 | ||
| 重要性 此事件有助于细致分析审批链中的瓶颈,识别造成延误的具体审批人或阶段。 获取途径 根据工作流引擎日志推断,即系统创建新的审批任务并将其分配给用户或角色时记录。 采集 记录生成审批任务时的时间戳,或采购申请状态显示正在等待特定审批人处理时的时间戳。 事件类型 inferred | |||
| 批准审批步骤 | 审批人在工作流指定阶段批准采购申请。此操作会使申请进入下一步,或更接近最终批准。 | ||
| 重要性 分析审批步骤从开始到结束的耗时,可以了解各审批人的处理效率和工作量分布。 获取途径 根据审批历史日志或工作流事务数据中记录的明确用户操作捕获。 采集 从审批历史记录或工作流日志中提取审批事件,包括审批人和时间戳。 事件类型 explicit | |||
| 请购申请已撤回 | 申请人或授权用户在请购申请获得最终批准或转为采购订单前将其取消。此操作会终止该申请的流程。 | ||
| 重要性 这是一个终止事件,流程到此结束,但没有明确的成功或失败结果。撤回率较高可能意味着业务需求发生变化,或申请提交得过早。 获取途径 通常记录为明确的用户操作,使状态变为“已撤回”或“已取消”,也可能通过设置删除标记记录。 采集 记录请购申请状态更新为“已撤回”或“已取消”,或设置删除标记时的时间戳。 事件类型 explicit | |||
数据提取指南
不同系统的数据提取方式各不相同。详细说明请
优化P2P请购流程,立即提升效率
识别瓶颈、改善合规情况,并在P2P流程中节省成本。
无需信用卡,几分钟即可完成设置。