您的报销管理数据模板
您的报销管理数据模板
- 详细分析的推荐属性
- 费用生命周期中需要跟踪的关键活动
- SAP Concur 数据提取指南
费用管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
事件timestamp
EventTimestamp
|
特定 Activity 发生的精确日期和时间。 | ||
|
描述
此 timestamp 标记了费用管理流程中某个 event 发生的精确时刻。它是 Process Mining 的关键组成部分,因为它确定了 activities 的时间顺序。此 data 的准确性对于计算各步骤之间的周期时间、持续时长和等待时间至关重要,而这些对于识别流程中的延迟和性能瓶颈必不可少。
为何重要
它为所有 event 提供了按时间顺序的排列,使得计算持续时间和分析随时间变化的流程绩效成为可能。
获取方式
可在 SAP Concur 中每份报销报告的审计轨迹或 event log data 中获取,并与每个记录的操作相关联。
示例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
报销报告 ID
ExpenseReportId
|
报销单的唯一标识符,用作主要的 case 标识符。 | ||
|
描述
Expense Report ID 是将单笔报销申请的所有相关 activities 分组的唯一键。它可以全程追踪报销单从创建到最终报销和会计入账的完整生命周期。在 Process Mining 中,此 ID 对于重建每份报销单的端到端路径至关重要,是所有流程分析和变体探索的基础。
为何重要
这是分析的基石,因为它将所有单个 events 链接到每份报销单的统一流程流中。
获取方式
这是大多数 SAP Concur 费用报销 data 提取和 API 中的主键,通常显示为“报销单 ID”或“报销单 Key”。
示例
C6B2F1A8-4D4F-4C8D-9E9C-1F0D5B5A4B3CER-2023-08-1001400012345
|
|||
|
活动名称
ActivityName
|
在费用管理流程中特定时间点发生的业务 event 的名称。 | ||
|
描述
Activity Name 描述了报销单生命周期中的特定步骤或里程碑,例如“报销单已提交”或“经理已审批”。此属性对于 Process Mining 至关重要,因为它定义了流程图中的节点,从而实现了流程流的可视化和分析。通过分析 activities 的顺序和频率,有助于识别常用路径、偏差和瓶颈。
为何重要
它定义了流程图中的步骤,支持对报销报告旅程的可视化和分析。
获取方式
源自 SAP Concur 内部的 event logs 或审计轨迹,这些记录跟踪了报销报告的状态变化和所执行的操作。
示例
报销报告已提交经理已审批财务已批准报销已执行
|
|||
|
最后数据更新
LastDataUpdate
|
指示此 record 数据上次从源系统刷新的 timestamp。 | ||
|
描述
此属性记录了上一次从 SAP Concur 提取或更新 data 的日期和时间。它是了解所分析 data 新鲜度的关键元数据。这有助于分析师和业务用户了解流程洞察的实时程度,对于维护 data 完整性和安排 data 刷新至关重要。
为何重要
提供关于 data 新鲜度的关键背景,确保分析是基于最新信息的。
获取方式
此 timestamp 是在 data 摄取过程中生成并添加到数据集中的。
示例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
源系统
SourceSystem
|
用于标识数据来源的系统。 | ||
|
描述
此属性指定生成费用管理流程 data 的源应用程序,在本例中为 SAP Concur。这对于 data 治理和上下文非常重要,尤其是在可能合并来自多个系统的 data 以进行更广泛分析的环境中。明确标记来源有助于维护 data 血缘并解决 data 质量问题。
为何重要
确保 data 的血缘关系和清晰度,这在集成多个企业系统的数据时至关重要。
获取方式
这通常是在 Data 提取和转换过程中添加的静态值,用于标记数据集的来源。
示例
SAP ConcurConcur Expense ProfessionalConcur Standard
|
|||
|
员工部门
EmployeeDepartment
|
提交报销单员工所属的部门或成本中心。 | ||
|
描述
此属性标识提交报销单员工的组织单位。它用于财务分配以及分析业务不同部门的流程绩效。通过筛选或比较部门,经理可以识别审批时间、政策合规性和返工率方面的差异,从而帮助将流程改进计划对准最需要的环节。
为何重要
支持按业务单元进行流程分析,有助于识别特定部门的行为、瓶颈或合规问题。
获取方式
此信息通常源自 SAP Concur 中的员工档案 data,该 data 通常与 HRIS 同步。
示例
销售市场营销研发财务
|
|||
|
处理人用户 ID
ProcessorUserId
|
执行该 Activity 的员工或系统用户的标识符。 | ||
|
描述
此属性标识负责特定 Activity 的人员,例如提交报销单的员工、审批的经理或处理的财务团队成员。分析处理人可以进行工作量分配分析、用户或团队之间的绩效比较,并了解工作的路由方式。这是审批人绩效和财务工作量相关 dashboard 的关键。
为何重要
支持分析工作量分布、用户绩效和资源分配,这对于识别培训需求和流程改进至关重要。
获取方式
在报销报告的审计轨迹 data 中可以找到,通常与审批或提交等 workflow 步骤相关联。
示例
j.doe789123asmith
|
|||
|
审批人 ID
ApproverId
|
负责审批报销单的经理或财务用户的标识符。 | ||
|
描述
此属性捕获执行审批 Activity 的人员的用户 ID。它与通用的“处理人用户 ID”不同,因为它专门针对审批步骤。这些 data 对于“审批人绩效与路由”dashboard 至关重要,可用于分析每位审批人的审批时间、拒绝率和工作负载。它有助于识别不一致的路由以及平衡工作负载的机会。
为何重要
支持对审批人绩效进行详细分析,有助于优化审批 workflow 并识别培训机会。
获取方式
此信息是 workflow 或审计追踪 data 的一部分,并关联到 SAP Concur 中的审批步骤。
示例
m.joness.lee987654
|
|||
|
报销总金额
ReportTotalAmount
|
报销单的总金额。 | ||
|
描述
此属性捕获单份报销单中申请的所有费用总和。它是财务分析的基础指标,允许按金额对报销单进行分层。高额报销单可能会走不同的审批路径或需要更严格的审查,分析此金额有助于了解成本驱动因素、合规风险和财务影响。
为何重要
提供关键的财务背景,支持基于金额的分析,例如识别可能需要额外审计的高额报告。
获取方式
这是报销单上的标题级字段,可在 SAP Concur 的标准 data 提取中获取。
示例
150.752500.0089.50
|
|||
|
政策违反标识
PolicyViolationFlag
|
指示报销报告是否因违反政策而被标记。 | ||
|
描述
一个布尔属性,如果自动或人工检查发现报销报告中存在违反政策的行为,则该属性为 true。这可能涉及超出支出限制、使用非首选供应商或缺少必要文件。该标识对于“费用政策合规概览” dashboard 和“政策违反率” KPI 至关重要,可帮助组织监控并执行其费用政策。
为何重要
直接支持合规分析,有助于衡量并提高对公司费用政策的遵守程度,降低财务风险。
获取方式
这通常是 SAP Concur 根据配置的费用政策生成的系统标志。可以在报销单级 data 中找到。
示例
truefalse
|
|||
|
费用类别
ExpenseCategory
|
费用的分类,例如差旅、餐饮或办公用品。 | ||
|
描述
费用类别(也称为费用类型)用于对支出性质进行分类。这些 data 是财务预算、报告和分析的基础。在 Process Mining 中,它有助于分析某些类别是否更容易出现政策违规、审批时间延长或返工。此属性是“费用分类准确性”dashboard 的基础。
为何重要
提供了一种按支出类型分析流程行为的方法,这可以揭示特定类别在合规性或效率方面的问题。
获取方式
这是 SAP Concur 中的行项目级详细信息。对于 case 级分析,它可能会被聚合,或者使用出现频率最高的类别。
示例
机票酒店客户餐费软件订阅
|
|||
|
付款类型
PaymentType
|
指示费用的支付方式,例如公司卡或自费。 | ||
|
描述
此属性用于区分使用公司信用卡支付的费用与由员工个人垫付(自费)并等待报销的费用。支付类型会显著影响流程流。例如,公司卡交易可能需要额外的对账步骤,而自费报销则通过报销速度直接关系到员工满意度。
为何重要
有助于区分公司卡和自付费用的流程变体,这两者通常具有不同的处理要求和风险。
获取方式
这是 SAP Concur 费用条目级的标准字段。
示例
公司卡自付费用预支现金
|
|||
|
员工所在国家/地区
EmployeeCountry
|
提交报销单员工所属的国家/地区。 | ||
|
描述
此属性标识员工所属的国家/地区。它是全球化组织进行分析的关键维度,允许比较不同地区的流程绩效、合规率和成本。各国的法规、政策和用户行为可能会导致显著的流程差异,理解这些差异至关重要。
为何重要
支持地区和国家维度的流程绩效与合规基准测试,这对于全球流程的一致化至关重要。
获取方式
这些 data 是 SAP Concur 中员工用户档案的一部分,通常从中央 HR 系统同步。
示例
美国DEUGBRJPN
|
|||
|
审批周期时间
ApprovalCycleTime
|
计算出的从报销单提交到财务最终审批通过的持续时间。 | ||
|
描述
此计算指标用于衡量“报销单已提交”与“财务已批准”activities 之间经过的总时间。它是对“费用审批周期时间”KPI 的直接衡量。分析此时长有助于识别审批链中的瓶颈(无论是经理级别还是财务级别),对于旨在加速审批流程的项目至关重要。
为何重要
量化核心审批流程的效率,直接影响员工获得报销的速度以及等待审批所需的人工投入。
获取方式
此指标是在 data 分析期间通过计算每个 case 的“财务已批准”与“报销单已提交”events 之间的 timestamp 差异得出的。
示例
2 天 4 小时1 天 8 小时 30 分钟5天
|
|||
|
审计结果
AuditOutcome
|
报销单人工或自动审计的结果。 | ||
|
描述
此属性记录审计审查的最终决定,可以是“通过”、“失败”或“通过但有警告”。它是“审计发现频率”KPI 的直接输入。分析审计结果有助于识别审计失败的常见原因(如缺少票据或违反政策),并为改进前端控制和员工培训提供反馈闭环。
为何重要
直接衡量合规控制的有效性,对于监控和降低审计相关风险及成本至关重要。
获取方式
此信息来自 SAP Concur 内部的审计模块或审计服务。如果组织使用了此功能,则该信息可用。
示例
已通过失败 - 缺少收据带警告通过未审计
|
|||
|
报销单状态
ReportStatus
|
报销单在其生命周期中的当前状态。 | ||
|
描述
此属性指示报销单 case 的当前状态,例如“等待审批”、“已批准支付”或“已支付”。虽然 Process Mining 主要使用 activities 的顺序,但 case 的最终状态对于筛选和细分报销单非常有用。例如,分析可以仅关注已完成的报销单(“已支付”),或调查长时间卡在特定状态的报销单。
为何重要
提供 case 当前状态的快照,有助于过滤进行中与已完成的报告,并用于运营监控。
获取方式
这是 SAP Concur 报销单标题级的主要状态字段。
示例
已提交,等待审批已批准并处于财务审核中已付款已驳回
|
|||
|
报销币种
ReportCurrency
|
提交报销单时使用的币种。 | ||
|
描述
此属性指定报销单中申请总额的货币代码,如 USD 或 EUR。这对于任何财务分析都至关重要,以确保金额得到正确解读和比较。在全球化组织中,按币种分析费用可以深入了解区域支出模式和汇率影响。
为何重要
这对于准确的财务报告和分析至关重要,特别是对于处理多种货币的跨国公司。
获取方式
这是 SAP Concur 报销单上的标准标题级字段。
示例
美元EURGBPJPY
|
|||
|
是否返工
IsRework
|
一个计算出的标识,用于指示报告是否在任何时间点被退回修改。 | ||
|
描述
这是一个派生的布尔值属性。如果报销单经历了至少一次修订周期(通过是否存在“报销单已退回修订”Activity 来识别),则该值为 true。此标志简化了“报销单返工率”KPI 的计算,并允许在首轮获批的报销单与需要返工的报销单之间进行轻松的筛选和比较。分析这些 case 有助于精准定位拒绝的常见原因,并提高一次性通过率。
为何重要
通过直接标记需要额外工作的 case,简化对流程效率低下的分析,有助于量化并减少返工。
获取方式
此属性在源系统中不存在。它是在 data 转换期间通过检查给定 Case ID 是否存在“报销单已退回修订”Activity 计算得出的。
示例
truefalse
|
|||
|
端到端周期时间
EndToEndCycleTime
|
从创建报销单到最终会计入账的总时间。 | ||
|
描述
此计算指标用于衡量单份报销单的整个费用管理流程时长。通常计算为第一个 event“报销单已创建”与最后一个 event“会计过账”之间的时间差。这提供了流程绩效的全局视图,是“平均端到端周期时间”KPI 的基础,用于跟踪整体流程效率的改进。
为何重要
提供了对从开始到结束的整个流程速度的高维度衡量,这是整体效率的关键指标。
获取方式
此指标是在 data 分析期间通过计算每个已完成 case 的最早与最晚 events 之间的 timestamp 差异得出的。
示例
10 天 2 小时15 天8天12小时
|
|||
费用管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
会计已入账
|
报销的财务交易正式过账到公司的总账。这最后一步通常在 data 被提取并加载到 ERP 系统时记录。 | ||
|
为何重要
这是端到端流程中的最后一个 Activity。它对于衡量整个流程周期时间和会计过账滞后时间至关重要。
获取方式
通常来自连接的财务 ERP 系统。此 event 是根据与报销单日记账分录关联的过账日期捕获的。
捕获
从财务系统中的过账日期捕获的 event,并链接回报告 ID。
事件类型
explicit
|
|||
|
报销已执行
|
付款已处理,资金已发放给员工。这通常是由支付系统触发的显式 event,随后会更新 SAP Concur 中的状态。 | ||
|
为何重要
标志着支付步骤的完成,对员工满意度至关重要。它是衡量报销效率的终点。
获取方式
从支付处理日期字段或集成支付系统的状态更新中获取。通常使用报告中的“支付日期”。
捕获
从支付处理日期字段或集成支付系统的状态更新中获取。
事件类型
explicit
|
|||
|
报销报告已创建
|
标志着员工发起了一份新的报销报告。当用户第一次保存新报告时会捕获此 event,并生成唯一的报销报告 ID。 | ||
|
为何重要
这是所有端到端周期时间计算的起点。它为衡量整个流程时长提供了基准。
获取方式
通常在 SAP Concur 的审计跟踪表(如报销单标题表)中明确记录,并在生成新报销单 ID 时带有创建 timestamp。
捕获
创建新报告条目时记录的 event。
事件类型
explicit
|
|||
|
报销报告已提交
|
员工正式提交填写完毕的报销单以供审批。这是由用户驱动的关键操作,会将报销单状态从“草稿”更改为“已提交”,并触发审批 workflow。 | ||
|
为何重要
此 Activity 是标志审批周期开始的关键里程碑。它对于衡量经理和财务的审批时间至关重要。
获取方式
显式记录在 SAP Concur 审计轨迹中。报告头状态发生变化,并记录提交 timestamp。
捕获
从报告的提交 timestamp 字段或 workflow 日志中捕获的 event。
事件类型
explicit
|
|||
|
经理已审批
|
直属经理审核并批准报销单,将其推进到 workflow 的下一步。此操作被捕获为状态更改,并记录审批人详情和 timestamp。 | ||
|
为何重要
这是一个关键的审批里程碑。追踪此项有助于分析经理审批周期时间,并识别第一级审核中的瓶颈。
获取方式
记录在 SAP Concur 的 workflow 或审批历史表中,并关联到报销单 ID。其中包含审批人身份和审批 timestamp。
捕获
经理执行审批操作后,在审批历史中记录的 event。
事件类型
explicit
|
|||
|
财务已批准
|
财务或审计团队完成审核并给出最终报销批准。这是一个关键里程碑,在审批历史中被记录为一个显式的 event。 | ||
|
为何重要
此 event 标志着整个审批周期的结束。它是衡量整体审批周期时间的终点,也是报销流程的触发点。
获取方式
记录在 SAP Concur 的 workflow 历史记录表中。此 event 包含审批人身份和最终审批的 timestamp。
捕获
财务团队执行审批操作后,在审批历史中记录的 event。
事件类型
explicit
|
|||
|
已标记政策违规
|
系统自动化规则或人工审核员将报销报告标记为违反政策。这可以从应用于报告或单项费用的特定标识或异常代码中推断出来。 | ||
|
为何重要
此 event 对于政策合规概览 dashboard 至关重要。它可以分析频繁出现的违规类型,并有助于提高政策遵循度。
获取方式
从报告 data 中的政策违反标识或异常代码字段的变化中推断。这可能不是一个离散的 event,而是属性状态的变化。
捕获
从“策略违反标识”属性由 false 变为 true 中推断。
事件类型
inferred
|
|||
|
开始财务审核
|
报销单进入财务或应付账款团队的队列进行最终审核。此 event 是根据报销单状态更改为“等待财务审核”或类似状态时的 timestamp 推断出来的。 | ||
|
为何重要
标志着财务审核周期的开始。这是衡量财务团队工作量和效率的关键起点。
获取方式
从 workflow 日志或状态历史记录中推断,特别是与报告进入“财务审核待处理”或类似状态相关的 timestamp。
捕获
根据状态更改为“财务审核待处理”时的 timestamp 推断。
事件类型
inferred
|
|||
|
报销单已退回修订
|
审批人(经理或财务审核员)将报销报告退回给员工进行更正。这是一项显式操作,会将报告状态改回草稿或员工待处理状态。 | ||
|
为何重要
此 Activity 是返工和流程效率低下的主要指标。分析其频率有助于识别常见错误并提高首轮审批通过率。
获取方式
在 SAP Concur workflow 历史记录中捕获。系统会记录带有 timestamp 的“退回”操作,并且通常要求审批人填写意见。
捕获
当审批人执行“退回”操作时,从 workflow 日志中捕获的 event。
事件类型
explicit
|
|||
|
报销已排期
|
最终审批后,报销报告将发送至支付系统并进入报销队列。这通常是在报告进入“待支付”或“已批准支付”状态时推断出来的。 | ||
|
为何重要
此 Activity 标志着从审批到支付的转变。它是衡量报销执行时间的起点。
获取方式
可以从状态更改为“已发送支付”中推断。在集成系统中,这可能是支付批次创建时的一个显式 event。
捕获
根据状态更改为待支付状态时的 timestamp 推断。
事件类型
inferred
|
|||
|
票据影像已附上
|
代表用户上传票据影像并将其附加到报销单的操作。对于每个附件,这通常作为系统审计日志中的显式 event 被捕获。 | ||
|
为何重要
分析此活动的时间和频率有助于了解用户行为,并识别从报告创建到准备提交之间的延迟。
获取方式
记录在 SAP Concur 的影像或附件日志中,并关联到特定的报销单 ID。系统的审计跟踪通常会记录此用户操作及其 timestamp。
捕获
当图像文件成功 upload 并链接到报告时记录的 event。
事件类型
explicit
|
|||
|
经理已拒绝
|
直属经理拒绝报销单,除非可以重新提交,否则通常会停止流程。这是当前 workflow 的终止 event,以最终的“已拒绝”状态捕获。 | ||
|
为何重要
此 Activity 代表流程异常或失败。分析拒绝情况有助于了解违规或无效申请的原因。
获取方式
在 SAP Concur 审批历史记录中记为“已拒绝”状态并带有 timestamp。该报告的 workflow 终止。
捕获
经理执行拒绝操作后,在审批历史中记录的 event。
事件类型
explicit
|
|||
|
财务已拒绝
|
财务团队拒绝报销单,这通常会终止该笔申请的流程。这是最终的负面结果,被捕获为财务审批人的“已拒绝”状态。 | ||
|
为何重要
代表最终审批人对流程的强制停止。分析这些拒绝情况是提高合规性和 data 质量的关键。
获取方式
在 SAP Concur 审批历史记录中记录“已拒绝”状态、timestamp 以及财务审批人的身份。
捕获
财务团队执行拒绝操作后,在审批历史中记录的 event。
事件类型
explicit
|
|||
|
需要审计审核
|
报销单被发送至审计或合规团队进行额外审查。这通常由特定的费用类型或金额触发,并通过指示其已进入审计队列的状态更改来捕获。 | ||
|
为何重要
识别流程中一个额外的、通常很耗时的步骤。分析这条路径对于理解特定报告类型的延误非常重要。
获取方式
从报告 workflow 的状态变化中推断,例如进入“待审计”或“审计队列中”状态。
捕获
源自报告状态字段更改为审计相关值。
事件类型
inferred
|
|||