您的合同管理数据模板
您的合同管理数据模板
这是我们针对合同管理的通用流程挖掘数据模板。使用我们针对特定系统的模板以获得更具体的指导。
选择特定系统- 合同管理流程的通用数据模型。
- 建议用于深入分析的属性和活动。
- 适用于提取事件日志的通用指南,无论您使用何种源系统。
合同管理属性
| 名称 | 描述 | ||
|---|---|---|---|
| 事件开始时间 EventStartTime | 指明特定活动或事件开始的精确日期和时间的 timestamp。 | ||
| 描述 事件开始时间标志着合同生命周期中一项活动的开始。此 timestamp 对于按时间顺序排列事件以及计算活动持续时间和整体流程周期至关重要。它提供了理解随时间变化的流程流向所需的临时背景。 在分析中,此 timestamp 用于构建流程图并计算关键绩效指标(如“平均合同周期”和“平均审批时长”)。它通过揭示哪些步骤最耗时来实现瓶颈分析。通过比较活动之间的开始时间,可以详细检查流转时间,从而突显流程步骤之间的延迟。 为何重要 此 timestamp 是对事件进行排序、计算流程周期时长以及识别基于时间的 bottleneck 的基础。 获取方式 可从系统审计日志、交易记录或记录流程步骤 timestamp 的事件历史表中获取。 示例 2023-03-15T09:00:00Z2023-05-20T14:30:15Z2023-06-01T11:22:05Z | |||
| 合同 ID ContractId | 每份合同的唯一标识符,作为关联所有相关活动和文档的主要 case 标识符。 | ||
| 描述 合同 ID 是分配给单个合同生命周期的唯一主键。它充当核心纽带,将从最初申请到最终到期或终止的每一个事件连接起来。所有活动(如起草、审核、审批和执行)都与此特定 ID 关联。 在流程挖掘分析中,合同 ID 是重构每份合同端到端路径的基础。它允许工具将相关事件归组为单个 case,从而实现整个流程流向的可视化和分析。如果没有一致的合同 ID,就无法准确测量周期时间、识别瓶颈或分析流程变体。 为何重要 此标识符对于跟踪合同的整个生命周期至关重要,能够实现准确的流程发现和绩效衡量。 获取方式 通常位于合同生命周期管理 (CLM) 系统中合同对象的抬头或主记录中。 示例 CTR-2023-00123MSA-98765-ACMENDA-GLOBAL-4510 | |||
| 活动名称 ActivityName | 合同生命周期中发生的特定业务事件、任务或里程碑的名称。 | ||
| 描述 活动名称描述了合同管理流程中的一个步骤。这些活动代表了所执行的具体任务,例如“合同已起草”、“法务审核完成”或“合同已执行”。给定合同 ID 的这些活动的按时间顺序排列,构成了流程流向。 此属性对于构建流程图(流程挖掘的核心可视化内容)至关重要。通过分析不同活动的顺序和频率,分析师可以了解实际的流程流向,识别与标准程序的偏离,并精准定位重工或低效区域,例如重复的修订周期。 为何重要 它定义了流程步骤,支持合同生命周期的可视化呈现,并用于识别流程偏离和瓶颈。 获取方式 通常见于与主合同记录关联的 event log、审计追踪或状态历史表。 示例 合同已起草内部审批完成合同已发送待签署 | |||
| 最后数据更新 LastDataUpdate | 指示该事件数据最近一次从源系统刷新或提取的时间戳。 | ||
| 描述 “最后数据更新” timestamp 指明了所分析数据的时效性。它显示了数据提取、转换和加载(ETL)过程最后运行的时间,为分析的即时性提供了参考。这与记录业务活动发生时间的 event timestamp 不同。 在分析中,此属性对于数据治理以及向利益相关者展示洞察的实时性至关重要。它帮助用户了解他们所看到的是实时信息,还是前一天或前一周的快照。这些信息对于基于 Process Mining dashboard 做出及时且明智的决策至关重要。 为何重要 提供关于数据新鲜度的关键背景,确保相关方了解流程洞察的时效性。 获取方式 此 timestamp 通常在数据加载过程中由数据集成或 ETL 工具生成并存储。 示例 2023-10-26T02:00:00Z2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 源系统 SourceSystem | 提取合同数据的 IT 系统或应用程序的名称。 | ||
| 描述 Source System 属性标识了 event 数据 的来源。在许多组织中,合同生命周期可能跨越多个系统,例如用于发起的 CLM 平台、用于启动的 CRM 以及用于财务数据的 ERP 系统。为每个 event 指定源系统对于数据验证和了解流程的技术布局至关重要。 在 Process Mining 分析中,此属性有助于识别跨不同系统的流程碎片化。它可以揭示延迟或问题是否与特定应用程序之间的数据交接有关。这对于数据治理以及追溯数据质量问题的根源也同样重要。 为何重要 识别数据来源,这对于数据验证、了解流程碎片化以及排查数据质量问题至关重要。 获取方式 此信息通常在数据提取过程中添加,或者作为系统日志中的标准字段提供。 示例 AgiloftSAP AribaDocuSign CLM | |||
| 事件结束时间 EventEndTime | 指明特定活动或事件完成的精确日期和时间的 timestamp。 | ||
| 描述 事件结束时间标志着一项活动的完成。通过与事件开始时间配对,可以精确计算合同生命周期中每个单独步骤的处理时间。这种粒度对于详细的绩效分析至关重要。 此属性用于计算活动持续时间,这是瓶颈分析的基础。诸如“审批与审核瓶颈分析”之类的仪表板依靠此数据来突出合同发生延迟的步骤。通过了解每项活动的持续时间,组织可以将改进工作集中在流程中最耗时的部分,例如法务审核或谈判环节。 为何重要 支持计算活动层级的持续时间,这对于精准定位流程瓶颈的确切位置至关重要。 获取方式 见于系统审计日志或事件历史表。如果没有显式记录,可能需要从后续事件的开始时间中推导得出。 示例 2023-03-15T17:30:00Z2023-05-22T10:15:45Z2023-06-01T11:55:10Z | |||
| 交易对手名称 CounterpartyName | 参与合同的外部方、公司、客户、供应商或合作伙伴的名称。 | ||
| 描述 交易对手名称识别了组织与之签订协议的外部实体。这可以是客户、供应商或合作伙伴。它提供了关于合同所管辖业务关系的关键背景。 作为分析维度,交易对手具有极高的价值。它允许企业按供应商或客户分析流程绩效。例如,分析可能会显示与某些交易对手的谈判时间始终高于平均水平。这一洞察可以指导未来的谈判策略,有助于关系管理,并可用于为战略合作伙伴创建定制的合同模板,以加速流程。 为何重要 识别外部方,从而能够按客户或供应商分析周期时间和谈判模式。 获取方式 合同记录中的标准字段,通常关联到客户或供应商的主数据记录。 示例 Acme CorporationGlobal Tech Inc.Innovate Solutions LLC | |||
| 合同价值 ContractValue | 与合同相关的货币总价值,可代表收入、支出或承诺金额。 | ||
| 描述 合同价值量化了合同的财务重要性。此金额是核心业务背景,有助于对合同进行优先级排序并了解其对组织的影响。它通常以特定货币表示。 在流程挖掘中,此属性用于分析流程绩效对业务的影响。“业务影响与吞吐量”仪表板利用此数据展示正在处理、停滞或已执行的合同价值。它支持对高价值合同进行优先级排序,并有助于回答诸如“我们最有价值的合同是否卡在审批环节?”或“错过续约日期的合同价值是多少?”等问题。 为何重要 量化合同的财务影响,从而能够对高价值协议进行优先级排序并分析流程低效对其产生的影响。 获取方式 位于 CLM 或 ERP 系统主合同记录的财务详情部分。 示例 100000.0025000.505000000.00 | |||
| 合同状态 ContractStatus | 合同当前的生命周期阶段或状态,例如“草稿”、“审批中”、“已执行”或“已到期”。 | ||
| 描述 合同状态提供了合同在特定时间点所处生命周期阶段的快照。随着合同通过各个主要里程碑,此属性通常会随之更新。它提供了合同进度的高级摘要。 此属性对于过滤 case 以分析合同组合的特定部分非常有用。例如,分析师可以专注于“活跃”合同以进行义务管理,或关注“停滞”合同以了解延迟原因。它是“合同生命周期绩效”仪表板的核心组件,有助于可视化每个阶段的合同数量并衡量“合同停滞率”KPI。 为何重要 提供合同当前阶段的高级视图,支持按生命周期阶段对合同组合进行过滤和分析。 获取方式 这是 CLM 系统中主合同记录上的一个主要状态字段。 示例 草稿审核中已执行已终止 | |||
| 合同类型 ContractType | 合同的分类,例如主服务协议 (MSA)、保密协议 (NDA) 或工作说明书 (SOW)。 | ||
| 描述 合同类型是根据法律性质和用途对合同进行分类的属性。常见类型包括 NDA、MSA、SOW 以及销售或采购协议。这种分类为合同生命周期提供了核心业务背景。 该属性是进行对比分析的有力维度。它允许分析师过滤流程图和 KPI,以查看特定类型的合同是否具有不同的流程流向、更长的周期或更高的重工率。例如,分析可能会发现 MSA 在法务审核阶段花费的时间明显长于 NDA,从而促使针对更复杂的协议类型进行流程重新设计。 为何重要 支持流程的细分和对比,揭示不同合同类型对周期、复杂程度和风险的影响。 获取方式 这是任何 CLM 系统中主合同记录上的一个标准字段。 示例 保密协议 (NDA)主服务协议 (MSA)工作说明书 (SOW) | |||
| 用户名称 UserName | 执行或负责某项合同活动的 user、员工或资源的名称或 ID。 | ||
| 描述 User Name 标识了负责完成合同生命周期中特定任务的人员。这可以是合同所有者、法务审核员、审批人或签署人。此属性将流程活动与执行这些活动的人员联系起来。 在 Process Mining 中,此属性提供了团队和个人绩效的视角。它被用于“团队工作量和生产力”等 dashboard,以分析工作分配情况、识别负担过重的员工或团队并评估绩效。它还有助于了解不同的用户行为如何导致流程变异或延迟,从而实现有针对性的培训或资源分配。 为何重要 将流程活动关联到个人,从而能够分析工作负载分布、团队绩效和资源分配。 获取方式 通常可在源系统的交易记录、审计日志或任务分配字段中找到。 示例 约翰·史密斯j.smith@example.comUSER12345 | |||
| 部门 Department | 负责该合同的内部业务单元或部门,例如销售、法务或采购部门。 | ||
| 描述 部门属性识别了负责该合同或与之关联的内部团队或业务单元。这通常是合同负责人所属的部门或发起合同申请的团队。 这是内部基准测试和工作负载分析的关键维度。它有助于了解合同管理流程在组织不同部分之间的差异。“团队工作负载与生产力”仪表板可以按部门过滤,以比较绩效、识别资源需求并突出显示可能需要额外培训或流程支持的部门。它有助于回答诸如“哪个部门的审批周期最长?”或“销售部门的流程与采购部门相比如何?”等问题。 为何重要 支持对比不同业务部门之间的流程绩效,有助于识别内部瓶颈并分享最佳实践。 获取方式 通常与合同所有者的 user profile 相关联,或作为合同记录本身的一个字段指定。 示例 销售法务采购IT | |||
| 修订次数 RevisionCount | 记录合同文档在谈判和审核周期中被修订或批注次数的计数器。 | ||
| 描述 Revision Count 跟踪合同在执行前经过的重做量。每次编辑文档并创建新版本时,此计数都会增加。它可以作为衡量谈判过程复杂程度和争议程度的指标。 此属性是效率的直接衡量标准,用于计算“合同重做率”KPI。“谈判与重做效率” dashboard 利用这些数据来识别需要过多修订的合同、交易对手或合同类型。高修订次数通常与较长的周期时长相关,可能表明需求不明确、谈判策略激进或需要更好的标准 template。 为何重要 衡量重工水平和谈判复杂度,有助于识别导致低效和长周期的诱因。 获取方式 可以从合同文档的版本号字段中获取,或通过计算每个 case 中“合同已修订”活动的数量来得出。 示例 135 | |||
| 到期日期 ExpirationDate | 如果未续约或终止,合同预定到期的日期。 | ||
| 描述 到期日期是一个关键的日期字段,标志着合同期限的结束。它管理着活跃合同的生命周期,是续约或终止活动的主要触发因素。妥善管理到期日期是避免意外服务中断或收入损失的关键。 在流程挖掘中,此属性对于“义务与续约管理”仪表板至关重要。通过将续约活动的日期与到期日期进行比较,它被用于计算“按时续约率”KPI。通过分析即将到期的合同,组织可以主动管理其续约 pipeline,并防止收入流失或运营中断。 为何重要 此日期对于续约管理和风险缓解至关重要,有助于跟踪合同里程碑并确保采取及时行动。 获取方式 这是 CLM 系统中主合同记录上的一个关键日期字段。 示例 2024-12-312025-06-302026-01-15 | |||
合同管理活动
| 活动 | 描述 | ||
|---|---|---|---|
| 内部审批完成 | 此里程碑表示所有必要的内部利益相关者已批准合同的最终版本。它标志着组织内部已达成一致,准备好向外部展示合同。 | ||
| 为何重要 这是流程中的一个主要关口,标志着内部谈判的结束。达到这一阶段所需的时间是衡量内部效率的关键绩效指标。 获取方式 当合同状态进入最终审批状态(如“完全批准”或“准备签署”)或完成最后一项审批任务时,通常可以推断出这一点。 捕获 识别整体审批状态变为完成或记录下最后一项必需审批时的 timestamp。 事件类型 inferred | |||
| 合同已到期 | 此事件表示合同已到期且未续签或提前终止。这代表了合同生命周期的自然、计划内结束。 | ||
| 为何重要 跟踪到期情况对于管理续签以及避免服务或协议无意中断至关重要。未续签的到期合同数量过多可能预示着业务流失。 获取方式 此事件通常不会被显式记录,而是通过将合同的到期日期字段与当前日期进行比较计算得出的。 捕获 当系统日期大于或等于合同记录上的“到期日期”字段时,通过创建 timestamp 来派生此事件。 事件类型 calculated | |||
| 合同已发送待签署 | 此活动标志着最终获批的合同已发出供各方执行。它代表所有谈判的结束以及最后执行步骤的开始。 | ||
| 为何重要 这是一个关键里程碑,开启了最后签署周期的计时。分析从这一时刻到执行的时间可以揭示签署过程中的延误。 获取方式 在集成了电子签名的系统中,这通常是一个触发签署流程的显式操作,并记录在系统的审计追踪中。 捕获 查找与发起电子签名工作流相关的事件日志或 API 调用 timestamp。 事件类型 explicit | |||
| 合同已执行 | 这是一个重要的里程碑,各方均已签署合同,使其具有法律约束力。它代表了合同生命周期签署前阶段的成功完成。 | ||
| 为何重要 作为核心成功指标,执行日期对于计算从申请到执行的整体周期至关重要。它是进行绩效和吞吐量分析的关键事件。 获取方式 这通常通过与电子签名平台的集成来显式捕获,或者当用户手动将状态更新为“已执行”并输入执行日期时捕获。 捕获 使用电子签名系统的完成 timestamp,或手动将状态更改为“已执行”的日期。 事件类型 explicit | |||
| 合同已激活 | 代表合同开始生效并具有法律约束力,这可能发生在执行日期当天或之后。此事件会触发义务管理和绩效跟踪的开始。 | ||
| 为何重要 激活标志着合同从签署阶段转入管理阶段。这是跟踪合规性、续约情况和履行义务的真实起始日期。 获取方式 这通常在系统中记录为状态从“已执行”变为“生效中”或“活跃”,有时会与指定的“生效日期”字段关联。 捕获 使用状态变更为“生效中”的 timestamp,或使用“合同生效日期”(如有)。 事件类型 inferred | |||
| 合同已终止 | 代表已激活合同在其计划到期日前提前终止。根据合同条款的允许,这可以是由于违约原因或为了方便而终止。 | ||
| 为何重要 此事件标志着业务关系的提前终止。了解终止的频率和原因对于风险管理和业务健康至关重要。 获取方式 这是一个显式事件,通常由用户将合同状态更改为“已终止”来记录,且通常伴有原因代码或注释。 捕获 获取已激活合同状态变为“已终止”时的 timestamp。 事件类型 explicit | |||
| 合同已续约 | 代表合同期满后成功续约。这是一个延长协议期限的关键业务成果。 | ||
| 为何重要 续约率是客户留存和满意度的直接衡量标准。跟踪此事件对于了解长期业务成功和收入连续性至关重要。 获取方式 这通常是一个明确的用户操作,用于更新合同状态或为续约期创建新的合同记录,该记录将接替原始合同。 捕获 寻找状态变更为“已续约”的情况,或寻找作为续约而关联到原合同的新合同创建记录。 事件类型 explicit | |||
| 已发起合同申请 | 这是合同生命周期的第一个活动,代表对新合同的正式请求。它通常捕获为在系统中创建新合同记录或工作区。 | ||
| 为何重要 此活动标志着流程的正式开始,其 timestamp 对于计算合同总周期时长至关重要。分析请求量有助于资源规划和需求管理。 获取方式 此事件通常是从源系统主合同表或审计日志中主合同记录或对象的创建 timestamp 中获取的。 捕获 识别与唯一合同 ID 关联的创建事件或最早的 timestamp。 事件类型 explicit | |||
| 义务监测已开始 | 此活动标志着执行后管理的开始,此时将积极跟踪关键日期、交付成果和其他承诺。这是确保签署后合规的第一步。 | ||
| 为何重要 此活动对于了解签署后的治理至关重要。跟踪这些任务有助于确保从合同中获得价值并降低风险。 获取方式 当创建或启动用于监控合同义务的任务、检查清单或子流程时,会捕获此信息,通常可以在任务管理日志中找到。 捕获 获取已激活合同在义务或合规跟踪相关的任务或事件创建 timestamp。 事件类型 explicit | |||
| 内部审核已开始 | 此活动标志着合同草案正式发送给内部利益相关者进行审核和反馈。它代表内部协作和审批阶段的开始。 | ||
| 为何重要 这是衡量整个内部审核周期的起点。分析在此阶段花费的时间有助于识别利益相关者协作中的 bottleneck。 获取方式 这通常通过 workflow 中的状态更改(例如从“草拟”移至“内部审核”)或审核任务的创建来捕获。 捕获 获取合同状态变为“审核中”或分配第一个审核任务时的 timestamp。 事件类型 explicit | |||
| 合同已修订 | 代表在谈判或内部审核期间合同文档被修订或批注的情况。每次修订都会创建一个新的文档版本。 | ||
| 为何重要 修订频率(即重工率)是流程效率和合同复杂程度的关键指标。高重工率可能预示着初稿或谈判策略存在问题。 获取方式 每当将主合同文档的新版本上传或保存到系统的文档库时,通常会显式捕获此信息。 捕获 获取初稿之后上传的每个新文档版本的 timestamp。 事件类型 explicit | |||
| 合同已发给交易对手 | 此活动表示合同已发送给外部交易对手进行审核和谈判。它标志着从内部流程向外部互动的转变。 | ||
| 为何重要 此事件是衡量外部谈判周期的起点。发送合同的延误会延长整个交易周期。 获取方式 这可以是一个明确的用户操作(如“发送至谈判”),也可以根据状态变更为“谈判中”或“外部审核”来推断。 捕获 获取“发送给交易对手”事件或状态变更为外部审核状态时的 timestamp。 事件类型 explicit | |||
| 合同已撤回 | 表示合同申请或处理中的合同在执行前被主动取消。这是一个会终止流程的终态。 | ||
| 为何重要 分析合同被撤回的原因可以揭示资质审核流程中的问题或业务优先级的变化。这是一个需要监测的重要负面指标。 获取方式 这是一个明确的结束状态,通常由用户在系统的状态历史日志中将合同状态更改为“已取消”或“已撤回”来捕获。 捕获 获取合同状态更新为“已取消”或“已撤回”终态时的 timestamp。 事件类型 explicit | |||
| 合同已起草 | 代表合同初稿的完成。通常在合同文档的第一版被上传或生成并关联到合同记录时捕获。 | ||
| 为何重要 跟踪从请求到草拟的时间可以深入了解初始设置和起草效率。此阶段的延迟可能是流程出现 bottleneck 的早期指标。 获取方式 通常可在与合同记录关联的文档管理或附件日志中找到。也可以从“起草完成”等状态变更中推断出来。 捕获 使用第一次文档版本上传的 timestamp,或状态变更为“已草拟”的时间。 事件类型 inferred | |||
| 已发起修订 | 此事件标志着现有活动合同正式修订流程的开始。它表示对原协议条款的变更请求。 | ||
| 为何重要 频繁的修订可能表明原始合同不够全面。通过分析修订情况,可以观察到业务关系演变的过程。 获取方式 这通常通过创建与原始合同相关联的新“修订”记录或工作区来捕获,见于系统的主数据表。 捕获 识别关联到父合同 ID 的“修订”类型记录的创建事件。 事件类型 explicit | |||
| 法务审核完成 | 表示法务部门已完成合同审核。这是合同进入更广泛审批或外部谈判之前的关键检查点。 | ||
| 为何重要 衡量法务审核的持续时间有助于量化法务团队的工作量,并发现精简法务流程的机会。它通常是影响整体周期的主要因素。 获取方式 通常在法务团队更新合同状态(如变更为“法务已审批”)或完成系统工作流日志中的特定审批任务时捕获。 捕获 寻找分配给法务部门的任务完成 timestamp,或表示法务已审批的状态变更记录。 事件类型 explicit | |||
| 谈判已开始 | 表示与交易对手的往复谈判已开始。这通常以收到外部方的第一份反馈或批注后的文档为标志。 | ||
| 为何重要 跟踪谈判开始对于分析谈判周期时长以及了解交易对手的回应时长至关重要。 获取方式 当外部方上传新的文档版本或合同状态更改为反映主动谈判时,通常可以推断出这一点。 捕获 使用从交易对手处收到的第一份文档的 timestamp,或状态变更为“谈判中”的时间。 事件类型 inferred | |||