您的费用管理数据模板
您的费用管理数据模板
这是适用于费用管理的通用流程挖掘数据模板。如需更具体的指导,请使用系统专用模板。
选择具体系统- 完整列出必需的数据属性。
- 涵盖费用处理中的关键活动和里程碑。
- 为在任意系统中开展详细流程分析奠定基础。
费用管理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 表示特定活动或事件发生准确日期和时间的时间戳。 | ||
| 说明 事件时间,即时间戳,记录活动发生的时刻。它为每份费用报告提供事件的时间顺序,是准确重建流程时间线的基础。 在流程挖掘中,时间戳是所有时间分析的基础。它用于计算活动间周期时间、端到端处理总时长和等待时间等关键指标。通过分析时间戳,企业可以识别审批流程中的延迟,衡量报销执行效率,并监控服务级别协议的达成情况。 为什么重要 该时间戳对于按时间顺序排列事件,以及计算周期时间、瓶颈等所有基于时长的指标至关重要。 获取位置 位于事件日志或交易数据中,常见字段名包括“创建日期”“时间戳”或“事件日期”。 示例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z2023-11-02T11:05:42Z | |||
| 活动名称 ActivityName | 费用报告生命周期中发生的特定业务事件或任务的名称。 | ||
| 说明 Activity Name描述费用管理流程中的单个步骤或状态变化。例如:'Expense Report Created'、'Manager Approved'、'Policy Violation Flagged'和'Reimbursement Executed'。这些活动按顺序构成每份费用报告的流程顺序。 对于流程挖掘分析,该属性是发现实际流程模型的关键。它使分析人员能够可视化流程图,识别活动耗时过长的瓶颈,发现'Report Sent For Revision'等返工循环,并定位非标准流程变体。活动名称的清晰度和粒度会直接影响流程洞察的质量。 为什么重要 该属性定义流程步骤,支持流程图可视化,以及工作流模式和偏差分析。 获取位置 来源于事件日志、状态变更表或与费用报告相关的交易记录。 示例 费用报告已提交经理已批准财务已拒绝报销已执行 | |||
| 费用报告ID ExpenseReportId | 费用报告的唯一标识符。该ID汇总所有相关活动,并作为主要案例标识符。 | ||
| 说明 Expense Report ID是分配给员工提交的每份费用报告的唯一键。它像一条主线,将从创建、提交到审批、可能的拒绝以及最终报销的所有流程步骤连接起来。 在流程挖掘中,该属性是重建案例的基础。每个唯一的Expense Report ID代表费用管理流程的一个实例。分析每个ID的处理历程,可以可视化流程顺序、计算单份报告的周期时间,并识别不同报告处理方式的差异。 为什么重要 这是连接费用报告整个生命周期中所有事件的核心案例标识符,可用于追踪端到端流程。 获取位置 通常位于费用报告的表头数据中,或费用流程的主交易表中。 示例 ER-2023-08-15-001EXP7891234500012345RPT-FY24-Q1-582 | |||
| 最后数据更新时间 LastDataUpdate | 表示该记录数据最后一次从源系统刷新时间的时间戳。 | ||
| 说明 最后数据更新时间戳表示数据最后一次从源系统提取或同步的时间。它为分析中包含的数据提供明确截止点,确保所有相关人员了解数据的新鲜度。 在流程挖掘场景中,该属性对数据完整性和报告至关重要。它帮助用户判断当前查看的是实时信息还是历史快照。对于时效性要求较高的持续监控仪表板,这一点尤其重要。它还可用于排查数据管道问题,确认数据刷新是否按计划进行。 为什么重要 确保数据新鲜度透明可见,这对于流程分析或监控仪表板的准确性和相关性至关重要。 获取位置 通常由数据集成或ETL(提取、转换、加载)工具在数据加载过程中生成并存储。 示例 2024-05-20T02:00:00Z2024-05-19T02:00:00Z2024-05-18T02:00:00Z | |||
| 源系统 SourceSystem | 提取费用管理数据的系统、应用或平台。 | ||
| 说明 源系统属性用于标识流程数据的来源。在现代企业中,费用管理可能涉及多个集成系统,例如用于员工数据的HR系统、用于提交报销的专用费用工具,以及用于财务过账的ERP。该字段有助于区分来自不同系统的数据。 这些信息有助于数据验证和了解流程的技术环境。如果流程问题集中在某个系统的数据中,可能说明该应用或系统集成存在问题。它还为数据提供上下文,确保分析人员了解不同流程步骤对应的事实来源。 为什么重要 标识数据来源,对于数据治理、问题排查,以及理解不同平台间的流程差异至关重要。 获取位置 通常属于数据提取过程或元数据的一部分,也可能在数据准备阶段添加。 示例 SAP ConcurExpensifyCoupaBrexRamp | |||
| 员工部门 EmployeeDepartment | 提交费用报告的员工所属业务单元或部门。 | ||
| 说明 该属性用于标识提交员工所属的组织单元,例如“销售”“工程”或“市场营销”。它通常与负责承担费用的成本中心关联。 员工部门是比较分析的重要维度。按部门筛选流程,可以发现不同部门在流程行为上的显著差异。例如,某个部门的政策违规率可能明显更高,或审批周期时间明显更长。这些洞察可以帮助管理层针对特定团队安排培训、调整流程或明确政策。 为什么重要 支持业务单元间的深入比较分析,帮助识别部门特有的行为、瓶颈或合规问题。 获取位置 通常来源于与费用报告关联的员工主数据记录。 示例 销售工程市场营销财务 | |||
| 币种 Currency | 费用报告总金额的货币代码,例如USD、EUR或GBP。 | ||
| 说明 币种属性指定总金额所使用的货币单位。在全球化企业中,员工可能使用不同币种提交费用,该字段为所有金额提供必要上下文。 在多国业务环境下,该属性对准确的财务分析至关重要。它确保金额能够被正确解读,并转换为统一币种用于汇总报告。如果缺少该属性,将日元报告的总金额与美元报告进行比较就没有意义。它也是展示不同地区总支出、平均成本和财务KPI的仪表板的基础。 为什么重要 为所有金额提供必要上下文,支持准确的财务报告,以及不同地区或国家之间的比较。 获取位置 通常与金额字段一起存储在费用报告表头数据中。 示例 USDEURGBPJPY | |||
| 总金额 TotalAmount | 提交报销的费用报告的货币总值。 | ||
| 说明 总金额表示单份费用报告中所有费用明细的合计,是需要审批并报销的总价值。 该属性对流程挖掘中的财务分析至关重要。它支持按金额区间划分费用报告,例如区分高金额和低金额报告,而不同区间通常对应不同审批路径。分析人员可以利用该属性计算每份报告的平均成本,调查返工和拒绝造成的财务影响,并识别支出趋势。将总金额与周期时间关联,还可以发现高金额报告是否需要更长审批时间。 为什么重要 支持财务影响分析,帮助识别支出模式,并根据报告金额对流程进行分段。 获取位置 位于费用报告数据的表头层级,通常通过汇总所有明细金额计算得出。 示例 150.752500.0085.5012500.20 | |||
| 报告状态 ReportStatus | 费用报告在生命周期中的当前或最终状态,例如“已提交”“已批准”或“已支付”。 | ||
| 说明 报告状态用于显示费用报告在任意时点所处的流程位置,或其最终结果。报告经过提交、审批、处理和付款等阶段时,状态通常会随之变化。 该属性可用于筛选案例并分析特定群体,例如仅关注“已拒绝”报告以了解拒绝原因,或关注“待审批”报告以调查当前瓶颈。在仪表板中,它可以概览当前工作负载和所有进行中费用报告的状态。它还可用于验证流程挖掘所生成活动的顺序。 为什么重要 概括报告当前状态,便于筛选案例,以及创建展示当前工作负载的运营仪表板。 获取位置 主费用报告表头中的字段,随着报告在工作流中推进而更新。 示例 待审批已批准已支付已拒绝已撤回 | |||
| 拒绝原因 RejectionReason | 经理或财务用户拒绝费用报告或将其退回修改时提供的原因。 | ||
| 说明 拒绝原因是解释费用报告未通过审批步骤的文本字段或预定义代码。常见原因包括“缺少收据”“类别错误”或“费用不符合政策”。 该属性对于流程返工的根因分析非常有价值。通过分析最常见的拒绝原因,企业可以识别系统性问题。例如,如果“缺少收据”是首要原因,企业可能需要加强凭证要求沟通,或简化收据附件流程。这些洞察可以推动有针对性的流程改进,提高一次审批通过率,减少返工并缩短整体周期时间。 为什么重要 解释流程返工背后的原因,支持有针对性的改进,以降低拒绝率并提高一次通过率。 获取位置 审批人执行“拒绝”或“退回”操作时,在评论字段或选项列表中记录。 示例 缺少收据费用类别错误超过每日补贴限额重复费用 | |||
| 提交人 Submitter | 创建并提交费用报告的员工的姓名或ID。 | ||
| 说明 提交人是实际产生费用并通过创建费用报告发起报销流程的员工。对于同一费用报告案例的所有相关事件,该属性通常保持一致。 “用户”属性标识每个步骤的执行者,而“提交人”提供一致的案例级属性,用于分析报告所有者的行为。它支持以员工体验为重点的分析,例如识别报告经常被拒绝或持续违反政策的员工。这些洞察可以指导定向沟通或培训,从流程起点提升整体效率和合规水平。 为什么重要 标识费用报告所有者,支持基于员工行为的分析,例如识别经常违反政策的人员或返工来源。 获取位置 位于费用报告表头数据中,与创建该记录的员工关联。 示例 Alice JohnsonRobert WilliamsEMP10234s.chen | |||
| 政策违规标记 PolicyViolationFlag | 布尔指示值;如果费用报告被标记存在一项或多项政策违规,则值为true。 | ||
| 说明 政策违规标记是一个简单的true或false值,用于表示费用报告是否被自动或人工识别为不符合公司支出政策。违规情况可能包括超出支出限额、使用未经批准的供应商,或缺少必要凭证。 该标记是合规分析的重要依据。企业可以据此计算总体政策违规率,并进一步查看哪些部门、费用类别或员工的违规最多。了解政策违规的频率和类型,有助于优化政策、改进自动检查,并开展针对性培训,从而减少不合规支出和流程例外。 为什么重要 直接支持合规监控,通过标记不合规报告,帮助衡量并减少政策违规。 获取位置 费用报告表头或明细数据中的标记或字段,通常由系统规则引擎设置。 示例 truefalse | |||
| 用户 User | 执行所记录活动的用户、员工或系统账户的名称或ID。 | ||
| 说明 用户属性用于标识负责执行特定流程步骤的人员或自动化代理。该主体可能是提交报告的员工、审批报告的经理,或处理报销的财务团队成员。 按用户分析流程,对于了解工作负载分配、个人绩效,以及识别可能造成延迟的具体人员至关重要。例如,它可以揭示某位经理是否成为审批链中的瓶颈。该属性还支持资源配置分析,并有助于确保整个流程中的责任追踪和可审计性。 为什么重要 标识每个步骤的执行者,支持工作负载分析、绩效比较,以及定位与特定人员或团队相关的瓶颈。 获取位置 位于事件日志或交易历史中,通常与用户ID或员工ID关联。 示例 john.doejane.smithapprover_team_leadsystem.batch.user | |||
| 付款方式 PaymentMethod | 费用的付款方式,例如“公司卡”或“个人垫付”。 | ||
| 说明 付款方式表示员工如何支付原始费用。通常分为使用公司发放的公司卡,或使用个人资金,即“个人垫付”,后者需要直接向员工报销。 该属性有助于区分两种主要流程变体。公司卡交易的数据直接来自发卡机构,通常具有更简化的核验流程。个人垫付费用则需要更严格的审核,并直接向员工付款。按付款方式分析流程,可以发现两条路径在周期时间、合规率和处理成本上的差异,并可能发现通过推广公司卡使用来提升效率的机会。 为什么重要 区分主要流程变体,即公司卡与个人资金,这两类流程通常在风险、效率和控制水平上存在差异。 获取位置 通常在费用明细层级指定,用于表示交易的资金来源。 示例 公司卡个人垫付每日补贴公司支付 | |||
| 审批人 Approver | 负责审批费用报告的用户的姓名或ID,通常为经理或财务代表。 | ||
| 说明 审批人属性用于标识在工作流中执行审批或拒绝步骤的人员。许多流程包含多个审批层级,例如直属经理之后由部门负责人或财务团队成员审批。 与“用户”属性类似,“审批人”专门用于分析流程的审批阶段,而审批阶段往往是延迟的主要来源。该属性支持按审批人衡量审批时长,帮助识别瓶颈。企业还可以创建仪表板,展示不同审批人的工作负载和绩效,为资源管理提供依据,并发现是否需要加强费用政策培训。 为什么重要 定位负责审批的具体人员,支持分析审批延迟、工作负载和决策一致性。 获取位置 记录在与审批相关活动的事件日志或交易历史中。 示例 David ChenMGR1056Finance_Approval_Queuesusan.g | |||
| 审计结果 AuditOutcome | 对费用报告执行人工或自动审计后的结果。 | ||
| 说明 审计结果记录流程中审计步骤的发现。审计可以由自动化系统执行,用于检查合规规则,也可以由财务或审计团队人工完成。结果通常包括“通过”“失败”或“有例外但通过”。 该属性直接反映内部控制的有效性。通过分析审计结果,企业可以评估风险敞口和提交质量,识别控制失效或政策持续被误解的领域。流程挖掘还可以将审计结果与其他属性关联,例如发现某些费用类别或部门的审计失败率更高。 为什么重要 直接衡量合规情况和内部控制检查结果,帮助评估风险及审计规则的有效性。 获取位置 由自动化规则引擎更新,或由审计或财务团队用户在完成审核后更新。 示例 通过未通过,缺少证明文件需要澄清通过,但有例外 | |||
| 费用类别 ExpenseCategory | 费用的分类,例如“差旅”“餐饮”“软件”或“办公用品”。 | ||
| 说明 费用类别是用于划分费用报告支出类型的维度。一份费用报告通常可能包含多个类别,因为其中可能有多条费用明细。 按费用类别分析流程,有助于企业了解支出模式并识别特定类别的流程行为。例如,“国际差旅”费用的审批流程可能比“办公用品”更复杂、耗时更长。该属性支持更细粒度的合规分析,帮助判断某些类别是否更容易发生政策违规,也是财务规划和预算管理的重要字段。 为什么重要 支持支出模式分析,并帮助识别不同类型的费用是否遵循不同流程路径,或具有不同的合规率。 获取位置 通常位于费用报告的明细层级。进行案例级分析时,可以汇总该属性,或使用占比最高的类别。 示例 机票餐饮和娱乐软件订阅办公用品酒店 | |||
费用管理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 已记入会计账 | 表示费用数据成功记入公司总账或ERP系统的最后一步,标志着费用报告的财务对账完成。 | ||
| 为什么重要 从财务会计角度标志流程真正结束。报销与该事件之间的时间,反映财务结账活动的效率。 获取位置 从ERP集成日志,或费用报告中表示已与会计系统同步的最终状态获取。 采集 使用集成日志中确认成功记入总账的时间戳。 事件类型 explicit | |||
| 报销已执行 | 标志着付款成功发放给员工的时刻。从员工角度看,这是流程成功完成的节点。 | ||
| 为什么重要 定义流程的关键终点,用于衡量总报销时间。这是影响员工满意度的重要指标。 获取位置 通常从付款处理日志,或集成付款系统发送的“已付款”或“已报销”等最终状态更新中获取。 采集 使用与费用报告关联的财务交易记录中的付款执行日期。 事件类型 explicit | |||
| 经理已批准 | 员工的直属经理或一级审批人已审核并批准费用报告。这是推动报告进入工作流下一阶段的关键决策点。 | ||
| 为什么重要 衡量首次审批阶段的持续时间和效率,是计算整体审批周期时间的关键里程碑。 获取位置 记录在审批历史或审计轨迹表中,其中包含审批人的操作和时间戳。 采集 在审批历史中筛选由具有经理角色的用户执行的首次“批准”操作。 事件类型 explicit | |||
| 财务已批准 | 财务或审计团队完成审核,并最终批准费用报告。这通常是报销处理前的最后一道审批关卡。 | ||
| 为什么重要 这是最终审批里程碑。从提交到该事件的时间代表总审批周期时间,是一项关键绩效指标。 获取位置 作为明确事件记录在审批历史或审计日志表中,并包含审批人详细信息。 采集 在审批历史中筛选最终“批准”操作,该操作通常由财务或审计角色用户执行。 事件类型 explicit | |||
| 费用报告已创建 | 标志着员工创建新费用报告记录,流程由此启动。这是记录的第一个事件,并建立用于跟踪的案例标识符。 | ||
| 为什么重要 定义端到端流程的起点,以便准确衡量从创建到最终结算的总周期时间。 获取位置 该事件通常从费用报告主数据中的创建时间戳获取。 采集 使用费用报告主表或主对象中的记录创建时间戳。 事件类型 explicit | |||
| 费用报告已提交 | 员工正式提交已完成的费用报告,审批工作流随之启动。此操作会将报告状态从草稿变为待审批。 | ||
| 为什么重要 这是一个关键里程碑,标志着数据录入阶段结束、审批周期开始。此节点之前的延迟主要由用户造成,之后的延迟则由流程造成。 获取位置 从状态变更日志或报告历史中的明确提交事件时间戳获取。 采集 识别报告状态从“草稿”或“打开”等状态变为“已提交”或“待审批”的事件。 事件类型 explicit | |||
| 已标记政策违规 | 自动系统检查或人工审核发现某项费用可能违反公司政策。当报告上设置具体政策违规标记或警告时,记录此事件。 | ||
| 为什么重要 突出显示合规问题,也是返工和拒绝的主要原因。分析这些标记有助于发现难以理解的政策或需要员工培训的领域。 获取位置 可在系统日志、异常表中找到,也可以通过跟踪报告或费用明细项首次应用违规标记的时间来获取。 采集 使用政策例外记录创建,或违规标记设为true时的时间戳。 事件类型 explicit | |||
| 已附加收据 | 表示用户将收据或其他支持性文件上传并关联到费用明细项的操作。通常,每次添加附件都会记录为一个独立事件。 | ||
| 为什么重要 跟踪用户行为以及资料提交可能出现的延迟。报告准备提交前,这可能是常见的瓶颈。 获取位置 通常可在系统审计日志或将文件关联到费用报告的专用附件表中找到。 采集 记录文件或附件相关表中每条新记录的时间戳。 事件类型 explicit | |||
| 报告已撤回 | 提交费用报告的员工在报告完全获批前将其取消。此操作会将报告从活跃审批工作流中移除。 | ||
| 为什么重要 表示终端用户发起的流程取消。了解报告被撤回的原因,有助于洞察用户体验和流程清晰度。 获取位置 通常作为明确事件记录在报告审计轨迹中,或通过状态变更为“已撤回”或“已取消”来获取。 采集 识别原提交人执行取消报告操作的事件。 事件类型 explicit | |||
| 报告已退回修改 | 审批人通常是经理或财务审核人员,将报告退回员工修改,但不作最终拒绝。此操作会启动返工循环,将报告退回草稿状态。 | ||
| 为什么重要 该活动是流程中返工循环的主要指标。分析其频率和原因,有助于发现流程低效和改进方向。 获取位置 从审批历史日志获取,或通过检测状态从“待审批”变回“草稿”或“打开”来识别。 采集 查找明确的“退回”事件,或表示报告返回提交人的状态转换。 事件类型 explicit | |||
| 报销已排期 | 获得最终批准后,费用报告会进入即将执行的报销批次,等待付款。该事件表示流程从审批阶段交接至付款系统。 | ||
| 为什么重要 衡量交接至付款流程的效率。此处的延迟可能表明批处理效率低下或付款系统集成存在问题。 获取位置 根据最终审批记录后的状态变更推断,例如变为“待付款”或“已批准付款”。 采集 使用报告分配到付款批次,或状态变更为可付款时的时间戳。 事件类型 inferred | |||
| 经理已拒绝 | 一级经理已审核费用报告并作出最终拒绝决定。此操作通常会终止该报告的流程,需要重新创建报告。 | ||
| 为什么重要 识别一级审批中的流程失败。较高的拒绝率可能表明政策理解不足或提交质量存在问题。 获取位置 可在审批历史日志中找到,或通过经理将状态最终变更为“已拒绝”来识别。 采集 记录审计轨迹中一级审批人执行最终“拒绝”操作的时间戳。 事件类型 explicit | |||
| 财务审核已开始 | 标志着费用报告进入财务或会计部门队列,等待最终审核和审计。通常可根据经理审批后的状态变更推断。 | ||
| 为什么重要 帮助衡量财务团队开始处理前的排队或等待时间。排队时间过长可能是流程中重要的隐藏瓶颈。 获取位置 根据状态变更日志推断,例如报告状态变为“待财务审核”或类似状态。 采集 使用将报告分配到财务或审计队列时的状态变更时间戳。 事件类型 inferred | |||
| 财务已拒绝 | 财务部门拒绝了费用报告,通常原因是严重的政策、合规或资料问题。这通常是终止流程的最终拒绝。 | ||
| 为什么重要 定位关键合规失败或流程中断。与经理拒绝相比,财务拒绝通常意味着更严重的问题。 获取位置 可在审批历史日志中找到,或通过财务用户将状态最终变更为“已拒绝”来识别。 采集 记录审计轨迹中财务或审计审批人执行最终“拒绝”操作的时间戳。 事件类型 explicit | |||
| 费用报告已关闭 | 所有操作完成后,系统会正式将费用报告标记为已关闭。这是最终终止状态更新,表示后续不应再有变更。 | ||
| 为什么重要 为流程提供明确的终点,确保分析不包含技术上仍处于打开状态但已不再活动的报告。 获取位置 根据最后记录的状态为“已关闭”或“已归档”等终止状态,且之后没有活动来推断。 采集 识别状态最终变更为“已关闭”等终止状态的时间戳。 事件类型 inferred | |||
数据提取指南
立即优化您的费用管理
发现隐藏的低效环节,确保所有费用流程符合合规要求。
无需信用卡•5分钟完成设置