您的采购到付款-请购数据模板
您的采购到付款-请购数据模板
- 用于全面分析的推荐属性
- 需要跟踪的关键流程活动
- 实用的数据提取指南
采购到付款-请购属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间
EventTime
|
活动发生的准确日期和时间。 | ||
|
说明
事件时间(即时间戳)记录了采购请购单活动的确切发生时刻。这些数据对于按时间顺序排列事件、还原流程的流转情况至关重要,也是所有时间分析的基础,包括计算周期时间、通过测量活动间隔识别瓶颈,以及了解不同时期的流程绩效。准确且精细的时间戳是开展有效流程分析的必要条件。
重要性
此时间戳对于正确排列事件,以及计算周期时间、瓶颈分析等所有基于时长的指标至关重要。
获取途径
此信息记录在Coupa中每张请购单的审计跟踪或历史记录里,通常对应每项操作的“created_at”或“updated_at”字段。
示例
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
|
|||
|
活动名称
ActivityName
|
请购单在某个时间点发生的具体业务活动或事件名称。 | ||
|
说明
此属性记录采购请购单生命周期中的各个步骤,例如“请购单已创建”“审批步骤已批准”和“请购单已进入寻源”。每项活动都代表请购单上的一个具体里程碑或操作。分析这些活动的顺序和频率是流程挖掘的基础,有助于绘制流程图、识别常见路径,并发现偏离标准过程的情况。
重要性
此属性定义流程图中的步骤,便于直观呈现和分析请购单的流转情况。
获取途径
此属性通常取自Coupa系统中的事件日志、状态变更记录或审计跟踪。可能需要根据状态字段或操作代码进行映射。
示例
创建申请单提交申请单审批步骤已批准请购单被拒绝采购订单已创建
|
|||
|
采购请购单ID
PurchaseRequisitionId
|
每张采购请购单的唯一标识符,也是流程的主要案例标识符。 | ||
|
说明
采购请购单ID是关联单个商品或服务请求相关活动的核心键。每张请购单创建时都会分配一个唯一ID,并在整个生命周期中保持不变。借助此ID,可以端到端跟踪请购单,从最初创建和提交,到各个审批或拒绝步骤,再到最终寻源和关闭。在流程挖掘中,每条事件日志记录都与此ID关联,因此可以还原每个案例的完整历程。
重要性
这是关键的案例ID,可关联所有流程步骤,从而完整分析请购单从开始到结束的生命周期。
获取途径
这是Coupa请购单模块及相关数据导出中的主键字段。
示例
PR-102934PR-102935PR-102936
|
|||
|
数据上次更新时间
LastDataUpdate
|
标明上次从源系统刷新数据的时间戳。 | ||
|
说明
此属性记录最近一次从Coupa提取数据的日期和时间,让您了解所分析数据的新鲜度。了解数据的时效性至关重要,这样用户才能判断洞察反映的是当前运营状态还是过去某个时点的情况。对于监控持续运营情况的仪表板,这一点尤为重要。
重要性
告知用户数据的时效性,帮助他们了解分析所涵盖的时间范围,并依据最新信息做出决策。
获取途径
数据管道或ETL工具会在成功完成数据提取后生成并添加此时间戳。
示例
2024-05-21T02:00:00Z
|
|||
|
源系统
SourceSystem
|
标识数据提取自哪个源系统。 | ||
|
说明
此属性指定流程数据的来源记录系统。在本次分析中,该值始终为“Coupa”。尤其是在数据可能来自多个系统的环境中,纳入此字段是一项最佳实践。它能提供必要的数据沿袭信息,并有助于管理数据治理和质量规则。
重要性
提供清晰的数据沿袭信息,这对于数据治理以及整合多个企业系统的数据至关重要。
获取途径
此值通常在数据提取和转换过程中作为静态值添加,用于标记数据集的来源。
示例
Coupa
|
|||
|
审批人
Approver
|
负责审批活动的用户或用户组。 | ||
|
说明
此属性标识分配到某个审批步骤的具体人员或审批组。对于“审批步骤已启动”“审批步骤已批准”和“审批步骤被拒绝”等活动,此属性会有相应值。按审批人分析数据,是构建“审批人绩效与工作量”仪表板的关键。此分析有助于衡量个人审批耗时、识别特定审批人造成的瓶颈,并评估工作量分配情况。
重要性
对于分析审批人绩效、平衡工作量,以及识别与特定人员或审批组相关的瓶颈至关重要。
获取途径
此信息位于Coupa中与每张请购单关联的审批链详情中,可能需要与用户数据联接。
示例
David Miller财务审批组L2Susan Chen
|
|||
|
总金额
TotalAmount
|
采购请购单的货币总额。 | ||
|
说明
此属性表示请购单中所有商品和服务的总成本。金额是流程分析的重要因素,因为它往往会影响审批工作流的复杂程度;金额较高的请购单通常需要更多审批步骤。按金额区间(例如<$1000、$1000-$10000)分析流程指标,可以了解流程如何处理不同金额的请购单。
重要性
有助于分析不同金额的请购单在流程上的差异,因为金额较高的请购单通常会触发更复杂的审批工作流。
获取途径
这是Coupa请购单对象头中的标准字段,通常名为“total”或“total_amount”。
示例
500.0012550.7599.99
|
|||
|
申请人
Requester
|
创建并提交采购请购单的员工。 | ||
|
说明
此属性标识发起请求的人员。按申请人分析数据,有助于发现特定用户的行为模式,例如频繁修改或多次被拒绝,这可能意味着需要提供额外培训。此属性还可用于分析不同用户或用户组的请购单数量和流程行为。
重要性
支持按用户分析流程行为,帮助识别培训需求,并了解不同人员如何参与流程。
获取途径
这是Coupa请购单对象中的标准字段,通常关联到用户对象,字段名为“requester”或“created_by”。
示例
Alice JohnsonBob SmithCharlie Brown
|
|||
|
请购单状态
RequisitionStatus
|
采购请购单的当前状态或最终状态。 | ||
|
说明
此属性表示提取数据时请购单的整体状态或最终结果。常见状态包括“待审批”“已批准”“已拒绝”“已撤回”和“已关闭”。这是筛选和分析的重要维度,可用于计算批准率和拒绝率、监控未关闭请购单的当前工作量,以及了解请求的最终处理结果。
重要性
对于了解请购单结果、计算批准率和拒绝率,以及监控正在处理的请购单当前状态至关重要。
获取途径
这是Coupa采购请购单对象中的标准字段,通常名为“status”或“state”。
示例
待审批已批准已拒绝已撤回已关闭
|
|||
|
部门
Department
|
请购单所归属的业务部门或成本中心。 | ||
|
说明
部门属性将每张请购单关联到特定组织单位或成本中心,是开展对比分析的重要维度。通过按部门筛选和细分仪表板及KPI,管理者可以比较组织不同部门的审批周期时间、拒绝率和合规情况,从而发现部门特有的问题或最佳实践。
重要性
支持比较不同业务单元的周期时间、拒绝率等流程KPI,帮助发现改进机会。
获取途径
这是Coupa请购单对象中的标准字段,通常关联到申请人的用户资料,或在请购单行项目中指定。
示例
市场营销IT运营设施管理研究与开发
|
|||
|
供应商名称
SupplierName
|
为请购单选定的供应商名称。 | ||
|
说明
此属性标识所申请商品或服务的目标供应商。申请人可以指定供应商,也可以在后续寻源过程中添加。按供应商分析流程指标,有助于评估供应商绩效,并发现与特定供应商的互动是否导致周期时间延长或其他流程低效问题。此属性也为采购策略和供应商关系管理提供重要背景信息。
重要性
支持根据选定供应商分析流程绩效,为寻源策略和供应商管理提供参考。
获取途径
此信息位于Coupa的请购单行项目对象中,字段通常名为“supplier”或“vendor”。
示例
StaplesDell TechnologiesAccentureCDW
|
|||
|
商品类别
Commodity
|
所申请商品或服务所属的高层级类别。 | ||
|
说明
商品类别属性为请购单中的项目提供标准化分类,例如“办公用品”“计算机硬件”或“市场营销服务”。这有助于根据采购内容分析采购模式和流程差异。某些商品类别可能有专门的审批要求或寻源策略,按商品类别分析流程有助于优化不同支出类别的采购。
重要性
有助于分析支出类别,并了解流程行为(例如审批时间)是否因所购商品或服务的类型而异。
获取途径
这是Coupa中的标准字段,通常位于请购单行项目级别,可能需要汇总到头级别。
示例
办公用品计算机硬件市场营销服务差旅
|
|||
|
审批工作流路径
ApprovalWorkflowPath
|
标识应用于请购单的具体审批链或工作流模板。 | ||
|
说明
此属性标识请购单应遵循的预设审批人顺序。该顺序由业务规则确定,通常取决于金额、部门和请购单类型等因素。此属性是“请购单政策合规”仪表板的核心。通过比较实际审批人顺序与指定的工作流路径,可以发现偏差、衡量一致性,并识别未受管理的例外情况。
重要性
支持合规分析,通过比较预期与实际审批步骤,发现流程偏差。
获取途径
请查阅Coupa文档。此属性可能根据请购单触发的审批链名称或工作流规则推导得出。
示例
标准审批<$5kIT硬件审批>$10k资本支出CFO审核
|
|||
|
审批步骤数
ApprovalStepCount
|
一项请购单经历的审批步骤总数。 | ||
|
说明
此计算属性会统计每项请购单中不同“审批步骤已批准”活动的数量,用于量化每个案例的审批工作流复杂度。这是“平均审批步骤数”KPI的计算依据,也有助于识别审批路径异常冗长或复杂的请购单,判断是否需要简化工作流。
重要性
量化每项请购单的审批工作流复杂度,帮助识别需要精简的过度复杂路径。
获取途径
此指标在流程挖掘工具中计算,方法是统计每个案例ID对应的“审批步骤已批准”活动次数。
示例
253
|
|||
|
审批步骤耗时
ApprovalStepDuration
|
请购单在单个审批步骤中等待的时间。 | ||
|
说明
此计算指标衡量“审批步骤已启动”与对应的“审批步骤已批准”或“审批步骤被拒绝”活动之间的时长。它单独统计审批链各个阶段的等待时间。这对于“关键审批步骤瓶颈”仪表板至关重要,因为它能准确指出哪些审批人或审批阶段导致了流程中的主要延迟。
重要性
通过衡量每个审批步骤的等待时间,而非只看总周期时间,精准定位审批工作流中的具体瓶颈。
获取途径
在流程挖掘工具中,通过计算“审批步骤开始”与后续最终审批事件(已批准/已拒绝)之间的时间差得出。
示例
1.2天4小时3.8天
|
|||
|
拒绝原因
RejectionReason
|
审批人拒绝请购单或审批步骤时提供的原因。 | ||
|
说明
审批人拒绝请购单时,通常会说明原因。此属性记录该文字说明。分析拒绝原因可以直接了解请购单未获批准的定性原因,对于根因分析非常有价值,有助于发现编码错误、预算不足或理由不充分等常见问题,进而通过培训或流程改进加以解决。
重要性
直接揭示流程未能成功完成的根本原因,帮助确定用户培训或流程说明方面的改进方向。
获取途径
此信息通常记录在请购单审批历史中,与“已拒绝”状态变更关联的评论或备注字段内。
示例
成本中心错误超出本季度预算重复请求提供的理由不充分
|
|||
|
是否修改过
IsAmended
|
布尔标记,若请购单在首次提交后修改过一次或多次,则值为true。 | ||
|
说明
此计算属性是一个简单标记(True/False),用于表示某个案例是否发生过“请购单已修改”活动。该属性便于用户筛选和分析需要修改的请购单,可用于计算请购单修改率KPI,并支持“请购单修改量”仪表板,帮助找出返工的根本原因并提升首次处理质量。
重要性
简化修改率KPI的计算,并便于区分需要返工和无需返工的案例。
获取途径
流程挖掘工具会检查每个案例的事件日志中是否存在“请购单已修改”活动,并据此计算此属性。
示例
truefalse
|
|||
|
紧急程度
UrgencyLevel
|
用于表示请购单紧急程度的分类,例如“高”“中”或“低”。 | ||
|
说明
紧急程度通常映射到优先级字段,申请人可借此标记需要加急处理的请求。此属性是“紧急请购单处理时间”仪表板的重要依据。比较高紧急程度请购单与普通请购单的周期时间,有助于组织评估优先级机制是否有效,以及紧急业务需求能否得到及时满足。
重要性
支持分析紧急请求是否比普通请求处理得更快,从而验证优先级政策是否有效。
获取途径
这可能是Coupa请购单对象中的标准字段或自定义字段。请查阅Coupa文档或系统配置。
示例
高中低
|
|||
|
请购单类型
RequisitionType
|
请购单的类别或类型,例如“资本支出”“运营支出”或“软件”。 | ||
|
说明
请购单类型用于根据业务目的或采购性质对请购单进行分类。此属性有助于开展合规分析,并了解不同类型的请求如何在流程中流转。例如,资本支出请求的审批路径可能比普通运营支出更严格、耗时更长。按请购单类型分析流程,可以发现有助于优化流程的重要洞察。
重要性
支持按请求的业务目的细分分析,因为不同类型的请求可能遵循不同的流程和政策。
获取途径
这可能是Coupa请购单对象中的自定义分类字段或标准分类字段。
示例
资本支出运营支出IT硬件专业服务
|
|||
|
货币
Currency
|
请购单总金额所使用的货币代码。 | ||
|
说明
此属性指定请购单总金额所使用的货币,例如USD、EUR或GBP。对于使用多种货币的跨国组织而言,这是财务分析的重要背景信息。它能确保正确解读金额,并支持财务报告和仪表板中的货币换算与汇总。
重要性
为“总金额”属性提供必要背景信息,确保在多币种环境中准确开展财务分析。
获取途径
这是Coupa请购单对象中的标准字段,通常名为“currency_code”或类似名称。
示例
USDEURGBP
|
|||
|
采购订单ID
PurchaseOrderId
|
根据已批准请购单创建的采购订单标识符。 | ||
|
说明
请购单全部获批并完成寻源后,通常会创建采购订单。此属性保存生成的PO的ID,是连接上游请购流程与下游采购订单流程的重要纽带。它可用于计算“请购单获批至PO创建的时间”KPI,并支持对整个订单到付款周期进行更广泛的端到端分析。
重要性
将请购单与后续采购订单关联起来,以便分析交接耗时,并开展更全面的端到端订单到付款分析。
获取途径
这是Coupa请购单对象中的标准字段,PO创建后会填入相应值。
示例
PO-45000123PO-45000124PO-45000125
|
|||
采购到付款-请购活动
| 活动 | 说明 | ||
|---|---|---|---|
|
创建申请单
|
用户发起新的采购申请单并将其保存为草稿。这是每个申请单案例的起点,通常可根据申请单记录本身的创建时间戳推断。 | ||
|
重要性
此活动标志着申请单生命周期的开始。分析从创建到提交所用的时间,有助于发现用户不确定或系统复杂造成的延误。
获取途径
对于指定的采购申请单ID,此事件取自“requisition_headers”表中的“created-at”时间戳。
采集
使用申请单头记录的创建时间戳。
事件类型
inferred
|
|||
|
提交申请单
|
申请人正式提交已填写完成的申请单,进入审批工作流。可通过系统审计日志或历史记录表中申请单状态从“draft”变为“pending_approval”来推断此事件。 | ||
|
重要性
提交申请单会触发审批流程,是衡量“申请单平均审批周期时间”关键绩效指标的重要节点。此节点之前的延误与用户有关,之后的延误则与流程有关。
获取途径
可根据“requisition_headers”表中的状态变更推断,具体为“status”字段变为“pending_approval”时。此变更的时间戳可在相关审计记录中找到。
采集
确定申请单状态首次变为“pending_approval”的时间戳。
事件类型
inferred
|
|||
|
请购单已关闭
|
请购单正式关闭,表示后续不会再采取任何操作。这可能发生在PO创建并履行之后,也可能发生在请购单获批后、下单前取消时。 | ||
|
重要性
此活动为请购单生命周期划定明确的终点,确保每个案例都有清晰结局,避免在流程分析中一直显示为“活跃”。
获取途径
当“requisition_headers”表中的“status”字段更新为“closed”时,根据状态变化推断此事件。时间戳记录在相关审计跟踪中。
采集
确定请购单整体状态变为“closed”的时间戳。
事件类型
inferred
|
|||
|
请购单已批准
|
请购单已成功完成审批工作流中的所有必需步骤。根据请购单头的整体状态变为“approved”推断此事件。 | ||
|
重要性
这是一个关键的成功里程碑,标志着审批周期结束。到达此活动所需的时间是主要KPI,也会触发后续采购操作。
获取途径
当“requisition_headers”表中的“status”字段更新为“approved”时,根据状态变化推断此事件。时间戳记录在相关审计跟踪中。
采集
确定请购单整体状态变为“approved”的时间戳。
事件类型
inferred
|
|||
|
请购单被拒绝
|
请购单在审批过程中被最终拒绝,不会转为采购订单。根据请购单头的整体状态变为“rejected”推断此事件。 | ||
|
重要性
此活动代表流程以失败告终。分析这些事件有助于降低“请购单拒绝率”,并找出违反政策或预算不足等根本原因。
获取途径
当“requisition_headers”表中的“status”字段更新为“rejected”时,根据状态变化推断此事件。时间戳记录在相关审计跟踪中。
采集
确定请购单整体状态变为“rejected”的时间戳。
事件类型
inferred
|
|||
|
采购订单已创建
|
系统根据已批准请购单中的信息成功生成采购订单(PO)。创建的PO记录引用了源请购单ID时,可推断此事件。 | ||
|
重要性
这是请购流程的主要成功结果,标志着流程交接至订单到付款的下一阶段。分析从“请购单已批准”到此事件的耗时,有助于发现执行延迟。
获取途径
根据“purchase_orders”表中新建的记录推断,该记录包含指向原始“requisition_headers”或“requisition_lines”ID的引用。
采集
使用与请购单ID关联的PO记录中的“created-at”时间戳。
事件类型
inferred
|
|||
|
修改申请单
|
申请单提交后,申请人或其他获授权用户对其进行编辑。Coupa会将此操作明确记录为新版本或审计条目,且通常会重置部分或全部审批工作流。 | ||
|
重要性
跟踪修改情况是了解流程返工和低效的关键。大量修改可能说明初始要求不明确或采购政策复杂,并影响“申请单修改率”关键绩效指标。
获取途径
此信息取自与“requisition_headers”表关联的审计记录表,其中记录了版本变更或具体的“edit”操作。
采集
在申请单提交后的历史记录中查找明确的“edit”或“update”事件。
事件类型
explicit
|
|||
|
审批步骤已批准
|
工作流中的审批人批准请购单。系统会记录这一明确操作,并附上具体时间戳和用户信息。 | ||
|
重要性
此活动可细致呈现审批流程。汇总这些步骤后,可计算“每个审批步骤的平均等待时间”,并分析审批人的表现。
获取途径
根据“approvals”表或其审计跟踪中记录的明确“approve”操作获取,并关联到相应请购单和审批人。
采集
在请购单的审批历史中筛选“approve”事件。
事件类型
explicit
|
|||
|
审批步骤被拒绝
|
审批人在工作流的相应阶段拒绝请购单,通常会将其退回给申请人修改。Coupa会记录这一明确操作。 | ||
|
重要性
任何步骤的拒绝都会造成返工并延长周期时间。分析拒绝发生的位置和原因,对于改进流程和开展用户培训至关重要。
获取途径
根据“approvals”表或其审计跟踪中记录的明确“reject”操作获取,并关联到相应请购单和审批人。
采集
在请购单的审批历史中筛选“reject”事件。
事件类型
explicit
|
|||
|
开始审批步骤
|
审批任务分配给特定审批人或审批组,申请单进入等待审批状态。可根据与申请单关联的审批记录创建且状态为“pending”来推断此事件。 | ||
|
重要性
此节点标志着特定审批的等待时间开始。测量此节点与相应的“审批步骤已批准/已驳回”节点之间的时长,有助于识别审批链中的具体瓶颈。
获取途径
可根据“approvals”表中与申请单关联的记录创建时间戳推断,审批人的操作状态为“pending”或等效状态。
采集
使用审批链中个人待审批记录的创建时间戳。
事件类型
inferred
|
|||
|
请购单已撤回
|
原申请人在请购单获得最终批准前将其取消。这是由用户发起的明确操作,会终止该请购单的流程。 | ||
|
重要性
撤回可能意味着业务需求发生变化、请求重复,或用户绕过流程。跟踪撤回情况有助于了解需求信号的波动,以及流程遵循方面的潜在问题。
获取途径
根据审计跟踪中记录的明确用户操作,推断“requisition_headers”表的状态变为“withdrawn”或类似状态。
采集
确定请购单状态变为“withdrawn”的时间戳。
事件类型
inferred
|
|||
|
请购单已进入寻源
|
已批准的请购单被送入寻源活动,例如询价或竞拍,而不是立即转为采购订单。当请购单关联到寻源活动对象时,可推断此事件。 | ||
|
重要性
此活动揭示了采购流程中的一条重要替代路径。它将简单采购与更复杂的战略寻源活动区分开来,便于更细致地分析周期时间。
获取途径
通过检测状态是否变为“sourcing”,或识别“requisition_lines”表与寻源活动表之间是否建立了关联来推断。
采集
检查状态是否变为“sourcing”,或是否创建了指向寻源活动ID的关联。
事件类型
inferred
|
|||
数据提取指南
优化Coupa P2P请购流程,立即缩短周期时间
精准发现低效环节,将P2P请购周期时间缩短30%。
无需信用卡,几分钟即可开始优化。