您的报销管理数据模板
您的报销管理数据模板
这是我们针对报销管理的通用流程挖掘数据模板。使用我们针对特定系统的模板以获得更具体的指导。
选择特定系统- 一份核心数据属性的完整清单。
- 报销处理过程中的关键活动与里程碑。
- 为跨系统的深度流程分析奠定坚实基础。
报销管理属性
| 名称 | 描述 | ||
|---|---|---|---|
| Event 时间 EventTime | 指示特定活动或事件发生的准确日期和时间的时间戳。 | ||
| 描述 “事件时间”即 timestamp,记录了活动发生的具体时刻。它为每张报销单提供了按时间顺序排列的事件记录,这对于准确重建流程时间线至关重要。 在 Process Mining 中,时间戳是所有基于时间的分析的基础。它们被用于计算关键绩效指标(KPI),例如活动间的周期时间、端到端总处理时间以及等待时间。通过分析时间戳,组织可以识别审批流程中的延迟,衡量报销执行效率,并根据服务水平协议 (SLA) 监控绩效。 为何重要 此时间戳对于按时间顺序排列事件以及计算所有基于时长的指标(如周期时间和瓶颈)至关重要。 获取方式 存在于事件日志或交易数据中,通常标记为“创建日期”、“时间戳”或“事件日期”。 示例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z2023-11-02T11:05:42Z | |||
| 报销单 ID ExpenseReportId | 报销单的唯一标识符。此 ID 将所有相关活动分组,并作为主要的 case 标识符。 | ||
| 描述 “报销单 ID”是分配给员工提交的每张报销单的唯一标识符。它是一条中心主线,连接了从创建和提交、审批、可能的拒绝到最终报销的所有流程步骤。 在 Process Mining 中,此属性是 case 重建的基础。每个唯一的报销单 ID 代表报销管理流程的一个实例。分析每个 ID 的流转过程可以实现流程流的可视化,计算单个报销单的周期时间,并识别不同报销单在处理方式上的差异。 为何重要 这是核心的 case 标识符,它连接了报销单生命周期中的所有事件,使追踪端到端流程成为可能。 获取方式 通常位于报销单的抬头级数据中,或位于报销流程的主交易表中。 示例 ER-2023-08-15-001EXP7891234500012345RPT-FY24-Q1-582 | |||
| 活动名称 ActivityName | 报销单生命周期内发生的特定业务事件或任务的名称。 | ||
| 描述 “活动名称”(Activity Name)描述了报销管理流程中的单个步骤或状态变更。例如“创建报销单”、“经理已审批”、“策略违规标记”和“报销已执行”。这些活动序列构成了每份报销单的流程流转。 在流程挖掘分析中,该属性对于发现真实的流程模型至关重要。它允许分析人员可视化流程图,识别活动耗时过长的瓶颈,发现诸如“退回修改”之类的重复劳动循环,并定位非标准的流程变体。活动名称的清晰度和颗粒度直接影响流程洞察的质量。 为何重要 此属性定义了流程的步骤,支持流程图的可视化以及对 workflow 模式和偏差的分析。 获取方式 提取自事件日志、状态变更表或与报销单关联的交易记录。 示例 报销单已提交经理已审批财务驳回报销执行完成 | |||
| 最后数据更新 LastDataUpdate | 指示此 record 数据上次从源系统刷新的 timestamp。 | ||
| 描述 “最后数据更新”时间戳指定了数据从源系统提取或同步的最后时间。它为任何分析中包含的数据提供了明确的截止点,确保所有利益相关者都了解数据的时效性。 在 Process Mining 背景下,此属性对数据完整性和报告至关重要。它能帮助用户判断所看的是实时信息还是历史快照。这对于时效性要求极高的持续监控 Dashboard 尤为重要。它还有助于通过确认数据刷新是否按计划进行,来排查数据管道中的故障。 为何重要 确保数据时效性的透明度,这对于流程分析或监控仪表板的准确性与参考价值至关重要。 获取方式 通常在数据加载过程中,由数据集成或 ETL 工具生成并存储。 示例 2024-05-20T02:00:00Z2024-05-19T02:00:00Z2024-05-18T02:00:00Z | |||
| 源系统 SourceSystem | 提取报销管理数据所属的系统、应用或平台。 | ||
| 描述 “源系统”属性标识了流程数据的来源。在现代企业中,报销管理可能涉及多个集成系统,例如用于员工数据的 HR 系统、用于提交的专用报销工具以及用于财务过账的 ERP。此字段有助于区分来自这些不同来源的数据。 此信息对于数据验证和了解流程的技术架构非常有价值。如果流程问题集中在来自特定系统的数据中,则可能指向集成问题或该应用内部的问题。它还为数据提供了背景,确保分析师了解不同流程步骤的“事实来源”。 为何重要 识别数据来源,这对于数据治理、故障排查以及理解不同平台间的流程差异至关重要。 获取方式 此信息通常是数据提取过程或元数据的一部分,也可能在数据准备阶段添加。 示例 SAP ConcurExpensifyCoupaBrexRamp | |||
| 合规违规标记 PolicyViolationFlag | 布尔值指标,如果报销单被标记为违反一项或多项合规政策,则为 true。 | ||
| 描述 “政策违规标识”是一个简单的真/假值,表示报销单是否被自动或人工识别为不符合公司支出政策。违规行为可能包括超过支出限额、使用未经批准的供应商或缺少必要的证明单据。 此标识是合规分析的关键驱动因素。它允许组织计算整体政策违规率,并向下钻取以查看哪些部门、费用类别或员工的违规行为最多。了解政策违规的频率和性质有助于完善政策、改进自动检查,并提供针对性培训,以减少违规支出和流程异常。 为何重要 通过标记违规报销单直接支持合规监控,助力评估并减少政策违规行为。 获取方式 报销单抬头或行项目数据中的标记字段,通常由系统规则引擎自动设置。 示例 truefalse | |||
| 员工部门 EmployeeDepartment | 提交报销单的员工所属的业务单位或部门。 | ||
| 描述 此属性标识提交报销的员工所属的组织单位,如“销售”、“工程”或“市场”。它通常与负责该费用的成本中心挂钩。 “员工部门”是对比分析的主要维度。它支持按部门过滤流程视图,从而突出行为上的显著差异。例如,某个部门的政策违规率可能远高于另一个部门,或者审批周期更长。这些洞察可以帮助管理层识别是否需要针对特定团队开展针对性培训、流程调整或政策澄清。 为何重要 支持在各业务单元之间进行深度对比分析,助力识别特定部门的行为模式、流程瓶颈或合规隐患。 获取方式 通常源自员工的主数据记录,该记录与报销单相关联。 示例 销售工程部市场营销财务 | |||
| 总金额 TotalAmount | 提交报销的报销单总货币价值。 | ||
| 描述 “总金额”代表单张报销单中包含的所有个人费用明细的总和。这是需要审批和报销的总价值。 此属性对于 Process Mining 中的财务分析至关重要。它支持将报销单划分为不同的价值区间(如高价值与低价值),这些区间通常遵循不同的审批路径。分析师可以利用此属性计算每份报销单的平均成本,调查返工和拒绝产生的财务影响,并识别支出趋势。将总金额与周期时间关联起来,可以揭示高价值报销单是否需要更长的审批时间。 为何重要 支持财务影响分析,助力识别消费模式,并允许根据报销金额对流程进行分段研究。 获取方式 位于报销单抬头层级的数据,通常由所有行项目金额汇总得出。 示例 150.752500.0085.5012500.20 | |||
| 报销单状态 ReportStatus | 报销单在其生命周期中的当前或最终状态,例如“已提交”、“已批准”或“已支付”。 | ||
| 描述 “报销单状态”提供了特定时刻报销申请在流程中所处位置的快照,或其最终结果。随着报销单经过提交、审批、处理和支付等不同阶段,其状态会发生相应变化。 该属性对于筛选 Case 并分析特定人群非常有用。例如,可以只关注“已驳回”的报销单以查明原因,或关注“待审批”的报销单以排查当前的瓶颈。在仪表板中,它提供了当前工作负载和所有进行中报销单状态的全局视图,还可用于验证流程挖掘(Process Mining)生成的活动序列是否正确。 为何重要 提供报销状态的高层级概括,便于筛选 Case,并为当前工作负载创建运营仪表板。 获取方式 报销单主表头中的一个字段,随着报销单在工作流中的推进而更新。 示例 待审批已批准已付款已驳回已撤回 | |||
| 拒绝原因 RejectionReason | 经理或财务人员拒绝报销单或要求退回修改时提供的理由。 | ||
| 描述 “拒绝原因”是一个文本字段或预定义代码,用于说明报销单未通过审批的原因。常见原因包括“缺少收据”、“类别错误”或“报销超标”。 此属性对于流程返工的根因分析极具价值。通过分析最常见的拒绝原因,公司可以识别系统性问题。例如,如果“缺少收据”是首要原因,公司可能需要加强关于单据要求的沟通,或简化收据上传流程。这些洞察有助于实施针对性的流程改进,从而提高一次通过率、减少返工并缩短整体周期时间。 为何重要 阐释流程重复劳动背后的原因,从而通过针对性改进来降低驳回率并提升一次性通过率。 获取方式 当审批人执行“驳回”或“退回”操作时,从备注字段或选项列表中捕获。 示例 缺少发票/收据费用类别错误超过日补贴限额重复报销 | |||
| 提交人 Submitter | 创建并提交报销单的员工姓名或 ID。 | ||
| 描述 “提交人”是产生费用并通过创建报销单发起报销流程的员工。对于单个报销单 case 相关的及其所有事件,此属性通常是一致的。 虽然通用的 'User' 属性可以标识每个步骤的操作者,但“提交人”提供了一个一致的 case 级属性,用于分析报销单所有者的行为。它支持专注于员工体验的分析,例如识别那些报销单经常被拒绝或持续违反政策的员工。这可以为针对性的沟通或培训计划提供依据,从而从源头提高整体流程效率和合规性。 为何重要 识别报销单的所有人,支持基于员工行为的分析,如识别频繁违规者或重复劳动的源头。 获取方式 存在于报销单抬头数据中,与创建该记录的员工关联。 示例 爱丽丝·约翰逊Robert WilliamsEMP10234s.chen | |||
| 用户 User | 执行所记录活动的特定用户、员工或系统账户的名称或 ID。 | ||
| 描述 “用户”属性标识了负责执行特定流程步骤的人员或自动化代理。这可能是提交报告的员工、审批报告的经理,或者是处理报销的财务团队成员。 按用户分析流程对于了解工作量分配、个人绩效以及识别可能导致延迟的特定操作者至关重要。例如,它可以揭示某位特定经理是否是审批链中的瓶颈。它还支持资源分配分析,并有助于确保整个流程的可追溯性和可审计性。 为何重要 识别每一步的操作者,从而支持工作量分析、绩效对比,并锁定与特定个人或团队相关的瓶颈。 获取方式 存在于事件日志或交易历史中,通常与用户 ID 或员工 ID 关联。 示例 john.doejane.smithapprover_team_leadsystem.batch.user | |||
| 货币 Currency | 报销单总金额的货币代码,例如 USD、EUR 或 GBP。 | ||
| 描述 “币种”属性指定了“总金额”的货币单位。在全球化组织中,员工会提交各种币种的报销,该字段为所有货币价值提供了必要的上下文。 对于准确的财务分析(尤其是在跨国背景下),此属性至关重要。它确保了货币价值能被正确解析并转换为通用货币进行汇总报告。如果没有它,将日元报销单与美元报销单的“总金额”进行比较将毫无意义。它是展示总支出、平均成本以及跨地区财务 KPI 的 Dashboard 的基础。 为何重要 为所有货币数值提供必要的上下文,支持准确的财务报表编制以及不同地区或国家间的对比。 获取方式 通常与报销单抬头数据中的金额字段存储在一起。 示例 美元EURGBPJPY | |||
| 付款方式 PaymentMethod | 费用的支付方式,例如“公司卡”或“个人垫付”。 | ||
| 描述 “支付方式”显示了员工最初支付费用的方式。通常分为公司发放的“公司卡”支付,或被称为“个人垫付”的个人资金支付(需直接报销给个人)。 此属性有助于区分两个主要的流程变体。公司卡交易通常具有更简化的核实流程,因为数据直接来自卡片供应商。然而,个人垫付的费用则需要更严格的审查和直接支付给员工。按支付方式分析流程可以揭示这两条路径在周期时间、合规率和处理成本方面的差异,从而发现通过鼓励使用公司卡来提高效率的机会。 为何重要 区分主要的流程变体(如企业卡与个人垫付),这些变体在风险等级、处理效率和管控要求上通常有所不同。 获取方式 通常在费用明细行级别指定,指示交易的资金来源。 示例 企业公务卡个人垫付日补贴公司已支付 | |||
| 审批人 Approver | 负责审批报销单的用户(通常是经理或财务代表)的姓名或 ID。 | ||
| 描述 “审批者”属性标识了在 workflow 中执行审批或拒绝步骤的个人。在许多流程中,审批可能包含多个层级,例如直属经理审批后,再由部门负责人或财务团队成员审批。 与 'User' 属性类似,“审批者”对于分析流程的审批阶段(这通常是导致延迟的主要原因)特别有用。它支持衡量每位审批者的审批耗时,帮助识别瓶颈。您可以创建 Dashboard 来展示不同审批者的工作量和表现,从而为资源管理提供依据,并明确是否需要针对报销政策开展额外的培训。 为何重要 精准定位具体的审批责任人,从而分析审批延迟、工作量分布以及决策的一致性。 获取方式 在事件日志或交易历史中捕获与审批相关的活动。 示例 陈大卫MGR1056Finance_Approval_Queuesusan.g | |||
| 审计结果 AuditOutcome | 对报销单执行的人工或自动审计结果。 | ||
| 描述 “审计结果”记录了流程中审计步骤的发现。这既可以是检查合规规则的自动化系统审计,也可以是财务或审计团队的人工审查。结果通常包括“通过”、“未通过”或“带异常通过”。 此属性提供了衡量内部控制有效性的直接指标。通过分析审计结果,公司可以评估其风险敞口和提交质量。它有助于识别控制措施失效或政策被持续误解的领域。Process Mining 可以将审计结果与其他属性相关联,例如发现某些费用类别或部门是否具有更高的审计失败率。 为何重要 直接量化合规性与内控检查结果,有助于评估风险水平及审计规则的有效性。 获取方式 该字段由自动规则引擎更新,或由审计及财务团队在完成审核后手动更新。 示例 已通过未通过 - 缺少证明文件需澄清说明带异常通过 | |||
| 费用类别 ExpenseCategory | 费用的分类,例如“差旅”、“餐饮”、“软件”或“办公用品”。 | ||
| 描述 “费用类别”是用于对报销单上的支出类型进行分类的维度。如果一张报销单包含多个明细项,则通常会涉及多个类别。 按“费用类别”分析流程有助于组织了解支出模式并识别特定类别的流程行为。例如,“国际差旅”费用的审批流程可能比“办公用品”更复杂、耗时更长。此属性支持更细致的合规性分析,展示哪些类别更容易出现政策违规。它是财务规划和预算编制的关键字段。 为何重要 支持对消费模式进行分析,帮助识别不同类型的费用是否遵循不同的流程路径,或在合规率上是否存在差异。 获取方式 通常出现在报销单的明细行级别。对于 case 级别的分析,可以进行汇总,或者使用主要的类别。 示例 机票餐饮娱乐软件订阅办公用品住宿/酒店 | |||
报销管理活动
| 活动 | 描述 | ||
|---|---|---|---|
| 会计已入账 | 代表报销数据成功过账到公司总账或 ERP 系统的最后一步。这标志着报销单财务对账工作的完成。 | ||
| 为何重要 从财务会计角度标志着流程的真正终结。报销打款与此事件之间的时间间隔反映了财务结账的效率。 获取方式 从 ERP 集成日志或报销单的最终状态中捕获,表明数据已同步至会计系统。 捕获 使用集成日志中确认成功过账到总账的时间戳。 事件类型 explicit | |||
| 报销单已创建 | 当员工创建新的报销记录时,标志着流程的开启。这是首个记录事件,并为此建立了用于追踪的 Case ID。 | ||
| 为何重要 定义端到端流程的起点,以便精确测量从创建到最终结算的完整周期时间。 获取方式 此事件通常从主报销单抬头数据中的创建时间戳获取。 捕获 使用报销单主表或对象中的记录创建时间戳。 事件类型 explicit | |||
| 报销单已提交 | 当员工正式提交填写完毕的报销单以开启审批流时发生。此操作将报销单状态从“草稿”转为“待审批”。 | ||
| 为何重要 这是一个关键里程碑,标志着数据录入阶段的结束和审批周期的开始。此节点之前的延迟是由用户驱动的,而之后的延迟则是由流程驱动的。 获取方式 这是从状态变更日志或报销单历史记录中明确的提交事件时间戳获取的。 捕获 识别报销单状态从“草稿”或“待处理”变更为“已提交”或“待审批”的事件。 事件类型 explicit | |||
| 报销执行完成 | 此活动标志着款项成功支付给员工的时刻。从员工的角度来看,这代表流程已圆满完成。 | ||
| 为何重要 定义流程的关键终点,以便衡量报销总耗时。这是影响员工满意度的核心指标。 获取方式 通常从付款处理日志或集成付款系统发送的最终状态更新(如“已支付”或“已报销”)中获取。 捕获 使用与报销单关联的财务交易记录中的付款执行日期。 事件类型 explicit | |||
| 经理已审批 | 员工的直属经理或一级审批人已审核并批准报销单。这是推动报销单在 workflow 中向下流转的关键决策点。 | ||
| 为何重要 衡量第一级审批阶段的耗时与效率。这是计算整体审批周期时间的关键里程碑。 获取方式 记录在审批历史或审计轨迹表中,包含了审批人的操作及对应的时间戳(timestamp)。 捕获 从审批历史中筛选由经理级别用户执行的首次“批准”操作。 事件类型 explicit | |||
| 财务审批通过 | 财务或审计团队完成审核并对报销单给予最终批准。这通常是处理报销款项前的最后一道审批关卡。 | ||
| 为何重要 这是最终审批里程碑。从提交到此事件之间的时间代表了总审批周期时间,是一项关键绩效指标。 获取方式 作为明确事件记录在审批历史或审计日志表中,包含审批人详细信息。 捕获 从审批历史中筛选最终的“批准”操作,此类操作通常由财务或审计人员执行。 事件类型 explicit | |||
| 报销单已关闭 | 所有操作完成后,系统会将报销单正式标记为已关闭。这是最终的终结状态更新,表示后续不会再有任何变更。 | ||
| 为何重要 为流程提供明确的终点,确保分析不会计入那些虽然仍处于开启状态但实际已无活动的报销单。 获取方式 通过最后记录的状态为“已关闭”或“已归档”且随后无进一步活动来推断。 捕获 识别状态最终变更为“已关闭”等终态时的时间戳(timestamp)。 事件类型 inferred | |||
| 报销单已撤回 | 提交报销单的员工在报销单获得最终批准前将其撤回。此操作会将报销单从活动审批 workflow 中移除。 | ||
| 为何重要 代表由最终用户发起的流程取消。了解报销单被撤回的原因有助于洞察用户体验和流程清晰度。 获取方式 这通常是记录在报销单审计追踪中的明确事件,或者是通过状态变更为“撤回”或“取消”来捕捉的。 捕获 识别原始提交人取消报销单的操作事件。 事件类型 explicit | |||
| 报销单退回修改 | 审批人(通常是经理或财务审核员)将报销单退回给员工修改,而非直接驳回。此操作会触发重复劳动循环,将报销单状态重置为草稿。 | ||
| 为何重要 此活动是流程中返工循环的主要指标。分析其频率和原因可以揭示流程效率低下的问题和改进方向。 获取方式 通过审批历史日志或检测状态从“待审批”变回“草稿”或“待处理”来捕获。 捕获 寻找特定的“退回”事件或状态转换,表明报销单已返回给提交人。 事件类型 explicit | |||
| 报销已排期 | 获得最终审批后,报销单将进入下一批次支付队列。此事件代表流程从审批阶段正式移交给支付系统。 | ||
| 为何重要 衡量移交给支付环节的效率。此处的延迟通常预示着批处理效率低下或支付系统集成存在问题。 获取方式 通过最终审批后状态变更为“待付款”或“批准付款”来推断。 捕获 使用报销单被分配到付款批次或状态变更为“待付款”的时间戳。 事件类型 inferred | |||
| 标记为违反政策 | 系统自动检查或人工审核发现某笔费用可能违反公司政策。当报销单被设置特定违规标记或预警时,系统会捕获此事件。 | ||
| 为何重要 突出合规性问题,这是导致重复劳动和驳回的主要原因。分析这些标记有助于识别表述不清的政策或需要加强员工培训的领域。 获取方式 存在于系统日志、异常表,或通过追踪违规标记首次出现在报销单或行项目上的时间点来确定。 捕获 使用创建政策异常记录或违规标识被设置为“真”的时间戳。 事件类型 explicit | |||
| 经理已驳回 | 一级经理已审核报销单并执行了最终拒绝。此操作通常会终止该报销单的流程,若需继续则必须重新创建报销单。 | ||
| 为何重要 识别一级审批阶段的流程失效。高驳回率通常预示着员工对政策理解有误或提交质量欠佳。 获取方式 存在于审批历史日志,或表现为经理将状态变更为终态“已驳回”。 捕获 在审计轨迹中捕获一级审批人执行最终“驳回”操作的时间戳(timestamp)。 事件类型 explicit | |||
| 财务审核开始 | 标志着报销单进入财务或会计部门队列进行最终审计。通常通过经理审批后的状态变更来推断。 | ||
| 为何重要 帮助衡量财务团队开始处理前的排队或等待时长。过长的排队时间往往是流程中被忽视的关键瓶颈。 获取方式 从状态变更日志中推断,当报销单状态转入“待财务审核”或类似状态时触发。 捕获 使用报销单分配给财务或审计队列时的状态变更时间戳。 事件类型 inferred | |||
| 财务驳回 | 财务部门拒绝了该报销单,通常是出于严重的政策、合规或单据原因。这通常是最终拒绝,会终止整个流程。 | ||
| 为何重要 精准定位关键的合规失效或流程崩溃点。与经理驳回不同,财务驳回通常预示着更严重的问题。 获取方式 存在于审批历史日志,或表现为财务人员将状态变更为终态“已驳回”。 捕获 在审计轨迹中捕获财务或审计审批人执行最终“驳回”操作的时间戳(timestamp)。 事件类型 explicit | |||
| 附件已上传 | 代表用户上传发票或其他证明材料并将其关联至报销行项目的操作。通常每次添加附件都会被捕获为一个独立的事件。 | ||
| 为何重要 追踪用户行为以及单据提交中潜在的延迟。在报销单准备好提交之前,这通常是一个常见的瓶颈。 获取方式 通常可以在系统审计日志或将单据链接到报销单的专用附件表中找到。 捕获 捕获文档或附件相关表中每条新记录的时间戳(timestamp)。 事件类型 explicit | |||