采购到付款 (P2P) — 采购申请数据模板
采购到付款 (P2P) — 采购申请数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 提取指南
采购到付款 - 请购属性
| 名称 | 描述 | ||
|---|---|---|---|
|
Event 时间
EventTime
|
特定活动或事件发生的精确时间戳。 | ||
|
描述
事件时间(即时间戳)捕获了系统中记录业务事件的日期和时间。它是所有基于时间的流程分析的时间基础。 此属性对于计算活动之间的周期时间、持续时间和等待时间至关重要。它支持流程性能分析、瓶颈识别以及 SLA 合规性监控。准确的时间戳对于可靠的流程挖掘分析是必不可少的。
为何重要
它提供了事件的时间顺序,这对于计算流程持续时间、识别瓶颈以及分析随时间变化的性能表现是必不可少的。
获取方式
可在 Workflow 历史记录或单据日志表中找到,通常作为与每个状态变更或事件记录相关联的
示例
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
|
|||
|
活动名称
ActivityName
|
请购流程中发生的特定业务事件或步骤的名称。 | ||
|
描述
此属性记录在采购请购生命周期内执行的每个活动的名称。示例包括“请购已创建”、“审批步骤已通过”和“采购订单已创建”。这些活动构成了发现的流程图中的节点。 分析这些活动之间的顺序、频率和时长是流程挖掘的核心。它有助于识别瓶颈、返工循环以及与标准流程流的偏差,从而提供运营低效的见解。
为何重要
此属性定义了流程图中的步骤,使可视化、分析和理解请购工作流成为可能。
获取方式
这通常派生自 Microsoft Dynamics 365 中的状态变更日志、工作流历史表或特定事件表(如 WorkflowTrackingStatusTable)。
示例
请购单已提交审批审批步骤已批准请购单已修改
|
|||
|
采购请购ID
PurchaseRequisitionId
|
采购请购单的唯一标识符,作为主要的 case 标识符。 | ||
|
描述
采购请购单 ID 是连接与单次货物或服务请求相关的所有活动的中心键。从创建到最终审批和关闭的每个请购流程都在这个唯一的 ID 下进行跟踪。 在流程挖掘中,此属性是重建每个请购单端到端旅程的基础。它允许分析单个案例的流程变体、周期时间和合规性,从而提供请购生命周期的全景视图。
为何重要
这对于将所有相关事件归组到单个流程实例中至关重要,从而实现对每个请购单生命周期的完整端到端分析。
获取方式
这通常是采购请购主头表(如 Microsoft Dynamics 365 中的 PurchReqTable)的主键。
示例
PR-001254PR-001255PR-001256
|
|||
|
最后数据更新
LastDataIngestionTimestamp
|
数据最近一次提取并加载到流程挖掘工具的时间戳。 | ||
|
描述
此属性指示正在分析的数据的新鲜度。它显示了从源系统进行最近一次数据刷新的日期和时间。这不是 Dynamics 365 本身的字段,而是在数据接入期间添加的元数据。 此时间戳对于用户理解洞察的时效性至关重要。它能帮助用户了解他们查看的是实时数据还是特定时间点的快照,从而影响结论的相关性。
为何重要
它告知用户 data 的新鲜度,确保他们了解分析的时间范围以及洞察的相关性。
获取方式
此值是在数据接入或 ETL 过程中生成并附加到数据集的。
示例
2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
|
|||
|
源系统
SourceSystemId
|
提取 data 的记录系统。 | ||
|
描述
此属性标识事件数据的来源系统。在这种情况下,它是“Microsoft Dynamics 365”。在具有多个集成系统的环境中,此字段对于数据血缘和上下文至关重要。 在分析中,它有助于区分可能跨越多个系统的流程,或确认数据来自单一权威源。这对于数据验证和确保分析基于正确数据集非常重要。
为何重要
它提供了关于数据来源的背景信息,这对于数据治理、验证以及多系统集成的环境至关重要。
获取方式
这是一个静态值“Microsoft Dynamics 365”,在数据提取和转换过程中添加。
示例
Microsoft Dynamics 365 F&OD365MSD365
|
|||
|
处理时间
ProcessingTime
|
处理特定任务所花费的有效时长。 | ||
|
描述
处理时间(Processing Time)代表资源积极执行任务的持续时长。它计算为活动结束时间与开始时间之差。与周期时间不同,它不包括等待或排队时间。 这一计算指标对于理解资源效率以及每个流程步骤所需的实际精力至关重要。它通过区分长处理时间(可能表示任务复杂)和长排队时间(暗示资源可用性问题),为“审批步骤瓶颈分析”提供支持。
为何重要
它衡量各项活动的实际工作时长,有助于区分增值时间和等待时间,从而进行准确的瓶颈分析。
获取方式
这是在数据转换期间通过从活动的结束时间减去开始时间计算得出的。这要求每项活动都具有 StartTime 和 EndTime。
示例
864000003600000600000
|
|||
|
审批步骤
ApprovalStep
|
工作流中特定审批步骤的名称或阶段。 | ||
|
描述
此属性标识审批工作流中的具体阶段,例如“经理审批”或“财务审批”。它比通用活动名称提供更细粒度的细节。 此属性对于“审批步骤瓶颈分析”至关重要。通过跟踪每个独立审批步骤所花费的时间,可以精准定位到底哪些阶段导致了整体流程延迟。这实现了针对性的干预以提高工作流效率。
为何重要
它允许对审批工作流进行细粒度分析,从而使识别导致瓶颈的具体阶段成为可能。
获取方式
此信息包含在工作流历史表中(如 WorkflowTrackingStatusTable),该表详细记录了已配置工作流的每个步骤。
示例
经理审批部门负责人审批财务评审
|
|||
|
用户
User
|
执行该活动的人员的用户 ID 或姓名。 | ||
|
描述
此属性标识负责执行特定流程步骤(如提交请购或批准请求)的员工或系统用户。它可以是用户 ID、全名或电子邮件地址。 按用户分析活动有助于识别培训需求、高绩效个人或团队以及工作量分配。它对于合规性分析(如职责分离)以及理解不同用户角色如何与流程互动也至关重要。
为何重要
它支持分析特定用户的行为、工作负载和绩效,这是资源管理和识别培训机会的关键。
获取方式
通常见于工作流历史表(例如 WorkflowTrackingStatusTable)或链接到用户表(例如 UserInfo)的交易表(例如 PurchReqTable)。
示例
j.smitha.joness.patel
|
|||
|
紧急程度
UrgencyLevel
|
请购单紧急程度的分类,例如“高”、“中”或“低”。 | ||
|
描述
紧急程度或优先级表示所需货物或服务的迫切程度。此属性通常用于影响审批路径或为审批人分配工作优先级。 分析此属性有助于确定优先级系统是否有效。例如,您可以比较“高”紧急程度请购单与“低”紧急程度请购单的周期时间。如果没有显著差异,则可能表明优先级字段被忽略或误用,这是“紧急程度影响分析”仪表板的关键见解。
为何重要
它有助于评估优先级设置是否有效加速了关键请求的处理,并揭露潜在的紧急程度分类滥用情况。
获取方式
这可能是 PurchReqTable 上的标准或自定义字段。其存在和名称可能因系统配置而异。
示例
高中低
|
|||
|
请购总额
RequisitionTotalAmount
|
采购请购单的总金额。 | ||
|
描述
此属性捕捉采购请购单上所有行项目的总价值。金额通常会影响审批工作流的复杂度,价值较高的请购单通常需要更多的审批步骤。 在流程分析中,此属性对于基于价值的过滤和分析至关重要。它有助于回答诸如“高价值请购单的审批时间是否更长?”或“目前卡在流程中的请购单总价值是多少?”等问题。这为流程绩效提供了财务背景。
为何重要
它为分析增加了财务维度,从而能够优先处理高价值案例,并理解金额大小如何影响流程行为。
获取方式
该值通常位于采购请购单头表上,或者是根据采购请购单行表 (PurchReqLine) 的行项目金额总和计算得出的。
示例
1500.0025000.50500.75
|
|||
|
请购状态
RequisitionStatus
|
采购请购单的当前或最终状态。 | ||
|
描述
此属性指示采购请购单在任何给定时间点的整体状态,例如“审核中”、“已批准”、“已驳回”或“已关闭”。这通常是一个代表最终结果的 case 级属性。 分析最终状态有助于理解流程的整体结果。例如,大量的“已驳回”或“已撤销”请购单可能表明初始请求阶段存在问题或审批流程过于繁琐。它是衡量成功率和流程效率的关键。
为何重要
它为每个案例提供明确的结果,支持对审批率、驳回率和撤回率(这些是关键绩效指标)的分析。
获取方式
状态字段通常位于采购请购单头表 PurchReqTable 上,常被命名为“Status”或“PurchReqStatus”。
示例
已批准评审中已驳回草稿
|
|||
|
部门
Department
|
申请人的部门或与该请购单关联的成本中心。 | ||
|
描述
此属性指定发起采购请购的业务部门或成本中心,例如“市场部”、“IT 部”或“运营部”。此信息通常是请购头的一部分。 按部门细分流程对于对比分析至关重要。它允许您查看哪些部门的周期时间最长、驳回率最高或修改最频繁。这些见解有助于针对特定部门的需求量身定制流程改进方案。
为何重要
它允许过滤和比较不同业务单位的流程绩效,揭示部门特有的模式、瓶颈或低效环节。
获取方式
此信息通常存储在采购请购头 (PurchReqTable) 上,并链接到 Dynamics 365 中的财务维度配置。
示例
IT 部门财务运营
|
|||
|
修改次数
AmendmentCount
|
请购单被修改的总次数。 | ||
|
描述
这是一个计算数值属性,用于统计每个采购请购案例中“请购单已修改”活动的发生次数。 此属性对于“请购修改频率”仪表板和“请购修改比率”KPI 至关重要。它量化了每个案例的返工量,使您可以轻松识别哪些请购单、部门或用户与高度的变更和低效相关联。这有助于针对性地提高初始请求的质量。
为何重要
它量化了案例内的返工情况,使衡量和分析修改频率及其对流程效率的影响变得简单。
获取方式
这是一个计算属性。通过在数据转换期间统计每个唯一 PurchaseRequisitionId 的“请购单已修改”活动次数得出。
示例
013
|
|||
|
审批工作流路径
ApprovalWorkflowPath
|
审批步骤执行顺序的呈现。 | ||
|
描述
此属性是一个派生字段,它连接了给定请购单的一系列审批步骤,例如“经理审批 -> 部门负责人审批 -> 财务审批”。它有效地概括了审批子流程的流程变体。 这对于“合规偏差监控器”仪表板至关重要。通过将实际工作流路径与预定义的标准或预期路径进行比较,可以轻松标记出可能代表政策违规或运营风险的不合规或异常流程。
为何重要
它通过提供流程变体的清晰字符串表示来简化合规性分析,使识别偏离标准程序的行为变得容易。
获取方式
此属性不是标准字段。必须在数据转换期间,按时间顺序连接每个 case 的“ApprovalStep”值来派生。
示例
经理 -> 总监经理 -> 总监 -> 财务副总裁经理 -> 自动批准
|
|||
|
审批组 (Approver Group)
ApproverGroup
|
负责审批步骤的用户组或角色。 | ||
|
描述
此属性标识分配用于处理特定审批任务的小组、角色或队列,例如“财务审批人”或“IT 经理”。 按审批组分析流程绩效是理解工作量分配并识别哪些组可能资源不足或需要额外培训的关键。它直接支持“审批步骤瓶颈分析”仪表板,允许按负责审批的团队切分绩效数据。
为何重要
它有助于识别审批团队之间的绩效差异,突出特定组内潜在的资源限制或培训需求。
获取方式
此信息是工作流历史记录的一部分(例如 WorkflowTrackingStatusTable),记录了每个任务分配的用户或用户组。
示例
财务审批人IT 经理高层管理人员
|
|||
|
是否一次通过
IsFirstPass
|
一个标记,用于指示请购单是否在没有任何事先修改或驳回的情况下获得批准。 | ||
|
描述
这是一个计算布尔属性,如果请购单的审批路径中不包含任何“请购单已修改”或“审批步骤已驳回”活动,则为“true”;否则为“false”。 此属性直接支持“请购首次通过审批率”KPI。它通过提供清晰的 case 级返工指标,简化了流程效率分析。较低的首次通过率突显了初始数据质量或需求不明确的问题,预示着流程改进的机会。
为何重要
它通过识别需要返工的案例来直接衡量流程质量和效率,支持关注“一次成功率”的 KPI。
获取方式
这是一个计算属性。需要在数据转换期间分析每个案例的完整活动序列,以检查审批前是否存在返工活动。
示例
truefalse
|
|||
|
货币
Currency
|
请购金额的货币代码。 | ||
|
描述
此属性指定请购总额的货币(例如 USD、EUR、GBP)。这对于财务分析至关重要,特别是对于处理多种货币的跨国组织而言。 使用货币属性可以正确处理和汇总财务数据。它确保货币值得到正确解读,并支持转换为通用货币,以便在不同地区或业务单元之间进行准确的报告和比较。
为何重要
它为财务属性提供必要的背景信息,确保在多币种环境下对金额进行准确的解释和汇总。
获取方式
此字段通常位于采购请购单头表 PurchReqTable 上,与金额字段放在一起。
示例
美元EURGBP
|
|||
|
采购订单号
PurchaseOrderNumber
|
从该请购单创建的采购订单标识符。 | ||
|
描述
此属性存储从已获批采购请购单生成的采购订单的唯一 ID。它是请购流程与下游采购流程之间的纽带。 跟踪此编号对于分析“请购到 PO 转化时间”至关重要。它确认请购单已成功进入采购到付款周期的下一阶段,并允许进行涵盖请购单和采购订单的端到端流程分析。
为何重要
它将请购单与后续采购订单连接起来,支持对“请购到 PO”转化的分析,并联结 P2P 流程的不同阶段。
获取方式
此信息通常在创建 PO 后的采购请购行表 (PurchReqLine) 中找到,并链接回 PurchTable。
示例
PO-000987PO-000988PO-000989
|
|||
采购到付款 - 请购活动
| 活动 | 描述 | ||
|---|---|---|---|
|
审批步骤已批准
|
审批人完成分配的任务,批准其负责阶段的请购请求。这将使请购单进入下一步或最终审批环节。 | ||
|
为何重要
衡量每个审批阶段的处理时间,并帮助精准定位工作流中的高效环节。它是变体分析的关键组成部分。
获取方式
当用户完成结果为“批准”的工作项时,在
捕获
在 Workflow 历史日志中识别结果为“批准”的
事件类型
explicit
|
|||
|
已创建招聘需求
|
此事件标志着采购请购单记录在草稿状态下的初始创建。通过识别采购请购头的创建时间戳来捕捉。 | ||
|
为何重要
作为流程的起点,此活动对于衡量请购单的总体生命周期时间以及分析每日请购吞吐量至关重要。
获取方式
此活动是根据每个新采购请购单 ID 在“PurchReqTable”上的“createdDateTime”字段推断出来的。
捕获
使用 PurchReqTable 中记录的创建时间戳。
事件类型
inferred
|
|||
|
请购单已关闭
|
整个采购请购单被视为已完成,这意味着其所有行项目都已转换为采购订单或已取消。这是一个最终的成功结束状态。 | ||
|
为何重要
此活动标志着请购生命周期的成功完成。它是衡量端到端总流程时长的最终终点。
获取方式
此状态通常是计算或推断出来的。当所有关联的“PurchReqLine”记录都达到最终状态(例如“已关闭”、“已取消”)时发生。
捕获
通过检查
事件类型
calculated
|
|||
|
请购单已提交审批
|
用户提交填写完毕的请购单,从而启动正式的审批工作流。这是系统工作流引擎记录的明确动作。 | ||
|
为何重要
此活动是启动审批周期的关键里程碑。它是衡量“请购审批周期时间”和“首次通过审批率”的起点。
获取方式
从
捕获
在 Workflow 历史日志中筛选与请购单绑定的“提交”或“开始”事件类型。
事件类型
explicit
|
|||
|
请购单已驳回
|
请购单在审批工作流中被驳回,将不再进行处理。这代表请购单的最终失败状态。 | ||
|
为何重要
此结束事件对于分析整体驳回率以及理解失败请求对财务或运营的影响至关重要。
获取方式
当 Workflow 以“已驳回”状态完成时,从
捕获
筛选状态为“已驳回”的 Workflow“完成”事件,或追踪
事件类型
explicit
|
|||
|
采购申请已批准
|
请购单已成功通过工作流中所有必要的审批步骤。当工作流实例以最终获批状态结束时,系统将记录此活动。 | ||
|
为何重要
这是一个重要的里程碑,标志着审批周期的结束和采购阶段的开始。它是“请购审批周期时间”KPI 的结束事件。
获取方式
当 Workflow 完成时,从
捕获
筛选状态为“已批准”的 Workflow“完成”事件,或追踪
事件类型
explicit
|
|||
|
采购订单已创建
|
已批准的请购明细行被转换为采购订单(PO)明细行,标志着向采购团队的移交。通过将请购行链接到采购订单行来捕获此操作。 | ||
|
为何重要
这是连接请购单与下游采购流程的关键里程碑。对于衡量“请购到 PO 转化时间”KPI 至关重要。
获取方式
通过在
捕获
在关联引用字段(例如
事件类型
inferred
|
|||
|
审批步骤已开始
|
作为 Workflow 的一部分,单个审批任务被分配给用户或组。这代表了特定审批人等待或处理时间的开始。 | ||
|
为何重要
此活动对于“审批步骤瓶颈分析”至关重要,它可以衡量特定审批阶段的等待时间。
获取方式
当为请购单的 Workflow 实例创建并分配新的工作项时,从
捕获
在 Workflow 历史日志中识别特定请购单的
事件类型
explicit
|
|||
|
审批步骤已驳回
|
审批人驳回其分配的任务,通常会将请购单退回给发起人进行修正。这是由 Workflow 引擎记录的明确动作。 | ||
|
为何重要
此活动是计算“请购驳回率”并识别驳回最常发生阶段的基础,从而突出流程改进的领域。
获取方式
当用户完成结果为“驳回”的工作项时,在
捕获
在 Workflow 历史日志中识别结果为“驳回”的
事件类型
explicit
|
|||
|
请购单已修改
|
当用户从工作流中撤回已提交的请购单以进行更改时,会发生此事件。该活动通常通过识别撤销操作及其后的再次提交来捕捉。 | ||
|
为何重要
跟踪修改是识别返工、初始请求不清晰和流程低效的关键。它直接支持“请购修改频率”仪表板。
获取方式
可以通过检测“撤回”或“请求变更”动作,从 Workflow 历史记录(
捕获
在提交事件之间检测 Workflow 撤回事件或记录版本变更。
事件类型
inferred
|
|||
|
请购单已撤销
|
创建者或授权用户在提交请购单后将其取消。此操作将终止工作流和请求。 | ||
|
为何重要
跟踪撤销有助于识别需求计划问题或过于复杂的流程。这为“请购撤销见解”仪表板提供支持。
获取方式
这是根据“PurchReqTable”上的状态变更为“已取消”或“WorkflowTrackingStatusTable”中的“取消”事件推断出来的。
捕获
检测
事件类型
inferred
|
|||
|
请购行已关闭
|
请购单上的单个明细项被视为已处理完毕。这通常发生在明细项完全转换为采购订单之后。 | ||
|
为何重要
提供关于请购履行的详尽细节,帮助识别请购单是部分转换还是全部转换为了采购订单。
获取方式
根据单个
捕获
监控
事件类型
inferred
|
|||