您的合同管理数据模板
您的合同管理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 源系统的提取指南
合同管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
合同 ID
ContractId
|
Icertis 平台中管理的每份合同的唯一标识符。 | ||
|
描述
Contract ID 作为唯一的 case 标识符,将与特定合同相关的所有事件和活动关联起来。这使得能够对每份合同从发起到解决的全过程进行全面的端到端分析。 在流程挖掘中,此属性是重建每份合同生命周期的基础。它确保所有相关活动(如起草、审阅、批准和执行)都能准确地与相应合同关联,从而实现周期时间的精确测量并识别流程差异。
为何重要
这是流程分析的主键,支持跟踪合同的完整历程并确保数据完整性。
获取方式
这是 Icertis 中“合同协议”对象的核心属性。
示例
CTR-2023-00123MSA-2024-589ANDA-FN-00451
|
|||
|
Event 时间
EventTime
|
指示特定合同活动发生时间的 timestamp。 | ||
|
描述
此属性记录活动开始或完成的精确日期和时间。它是流程挖掘的时间基础,为每个合同 case 提供事件的时间顺序。 Event Time 对于所有基于时间的分析都至关重要。它用于计算活动间的周期时间、识别等待期、测量谈判或审批等特定阶段的持续时间,并查明合同长时间停滞的瓶颈。
为何重要
此 timestamp 对于计算所有绩效指标(如周期时间和持续时间)以及理解事件顺序至关重要。
获取方式
这是 Icertis 审计跟踪或工作流历史日志中的标准字段,与每个记录的事件关联。
示例
2023-05-15T10:22:00Z2023-06-02T14:05:30Z2024-01-10T11:00:00Z
|
|||
|
活动名称
ActivityName
|
合同生命周期中某一点发生的特定事件或任务的名称。 | ||
|
描述
Activity Name 描述了合同管理流程中的特定步骤或里程碑。这些事件根据其 timestamps 排序,以构建每份合同的流程流。 分析此属性可以揭示操作顺序、不同活动的频率以及流程的整体结构。它用于识别常见的流程路径、偏离标准程序的行为以及导致返工或延迟的活动,例如多次修订循环。
为何重要
它定义了流程的各个步骤,这对于可视化流程图、分析流程流向以及识别瓶颈至关重要。
获取方式
此信息通常生成自 Icertis 内部的事件日志(event logs)或工作流历史表,这些表跟踪合同的状态变更和已执行任务。
示例
合同已起草已进行法务审核合同已执行修订已启动
|
|||
|
合同状态
ContractStatus
|
合同在其生命周期中所处的当前状态或阶段。 | ||
|
描述
此属性指示合同 case 的整体状态,例如“草案”、“审核中”、“等待签署”或“已执行”。这通常是一个 case 层级的属性,反映了已达到的最后一个主要里程碑。 这对于“合同状态与吞吐量”等运营仪表板(dashboards)至关重要,它们提供了合同管线的实时快照。它帮助管理者了解各阶段的合同数量,并识别工作积压的环节,从而实现对合同组合的主动管理。
为何重要
提供合同管线的宏观视图,对于运营监控和管理吞吐量至关重要。
获取方式
这是 Icertis 中“合同协议”对象的主要状态字段。
示例
草稿正在内部审核已执行已终止
|
|||
|
合同类型
ContractType
|
合同的分类,例如主服务协议或保密协议。 | ||
|
描述
Contract Type 根据法律或业务用途对协议进行分类。这是细分和比较合同生命周期的基础属性。 不同的合同类型通常遵循不同的流程路径,并具有不同的复杂程度和 SLA。按合同类型分析流程可以实现有针对性的改进,例如为 NDA 等大批量、低风险协议创建优化的工作流,而为复杂的、高价值的 MSA 创建另一种工作流。这对于“合同变体分析”和“政策合规得分”KPI 至关重要。
为何重要
支持流程细分,以便比较不同类型协议的生命周期和合规性。
获取方式
这是 Icertis 中“合同协议”对象上配置的标准属性。
示例
主服务协议 (MSA)保密协议 (NDA)工作说明书 (SOW)
|
|||
|
合同金额
ContractValue
|
合同的总货币价值。 | ||
|
描述
此属性代表合同的财务价值,如合同总额或年化价值。它是划分合同优先级和了解财务影响的关键业务指标。 在流程挖掘中,Contract Value 用于细分分析并关注高价值协议。例如,可以分析高价值合同是否需要更长的审批或谈判时间。它还有助于风险评估,因为高价值合同的延迟可能会产生重大的收入影响。
为何重要
支持优先级排序和基于价值的分析,有助于将改进工作的重点放在对财务影响最大的合同上。
获取方式
这通常是 Icertis 中“合同协议”对象上的标准货币字段。
示例
50000.001250000.002500.00
|
|||
|
活动负责人
ActivityOwner
|
负责执行合同活动的用户或资源。 | ||
|
描述
此属性标识执行特定活动的个人、团队或自动化用户。它可以是具体的用户名、员工 ID 或系统账户。 分析 Activity Owner 对于理解资源分配、工作量分布和绩效至关重要。它有助于回答诸如哪些用户或团队是瓶颈、谁是最有效的审核员以及工作如何分布等问题。这直接支持“审核员工作量分布”仪表板(dashboard)。
为何重要
支持按用户或团队进行绩效分析,帮助识别工作量失衡并发现培训机会。
获取方式
此信息通常可以在 Icertis 内部的工作流历史或审计跟踪数据中找到,并与每个事件关联。
示例
约翰·史密斯Legal.Review.QueueSystem.AutoApproveSarah Chen
|
|||
|
结束时间
EndTime
|
指示特定合同活动完成时间的 timestamp。 | ||
|
描述
此属性捕获活动的完成时间。StartTime 标记开始,EndTime 标记结束,从而定义活动的离散跨度。 同时拥有开始和结束时间对于精确计算每个活动的 processing time 或持续时间至关重要。这使得能够分析哪些步骤最耗时,并区分主动处理时间与步骤间的空闲等待时间。这对于“审批流程瓶颈”和“起草与修订效率”等仪表板(dashboards)至关重要。
为何重要
支持精确计算活动持续时间,有助于区分处理时间和等待时间。
获取方式
与 StartTime 类似,这可以在 Icertis 审计跟踪或工作流历史日志中找到。某些事件可能是瞬时完成的,即 StartTime 等于 EndTime。
示例
2023-05-15T18:30:00Z2023-06-03T09:00:15Z2024-01-10T11:00:00Z
|
|||
|
负责部门
OwnerDepartment
|
活动负责人所属的部门。 | ||
|
描述
此属性指定执行活动的用户所属的业务部门,如法务、销售或采购。它提供了流程中资源参与情况的聚合视图。 按部门分析是理解部门间协作和交接的关键。它有助于识别部门间的系统性延迟,例如销售提交后法务审核的长时间等待,这是“部门交接延迟”仪表板(dashboard)关注的重点。
为何重要
有助于分析部门绩效和交接效率,突出跨职能瓶颈。
获取方式
可能需要通过将 Activity Owner 作为关联键与 HR 系统或用户目录进行关联来丰富此数据。它也可能直接存储在 Icertis 的用户配置文件中。
示例
法务销售采购财务
|
|||
|
SLA 状态
SLAState
|
指示活动或 case 是否符合其服务水平协议 (SLA) 条款。 | ||
|
描述
此属性通过将某些流程阶段的持续时间与预定义的 SLA 目标进行比较而得出。例如,如果法务审核超过了标准的 48 小时周转时间,它可能会将其标记为“延迟”。 SLA Status 对于合规性监控和绩效管理至关重要。它支持创建警报和仪表板(例如“合同合规概览”),以立即突出显示违规情况。这有助于团队优先处理逾期任务,并使管理者能够根据关键目标跟踪绩效。
为何重要
实时展示服务水平目标的达成情况,有助于优化工作优先级并管理绩效。
获取方式
这是通过在流程挖掘工具中定义业务规则来计算的,该规则将 timestamps 与预定义的 SLA 阈值(例如,法务审核时长 > 2 天)进行比较。
示例
准时存在风险逾期
|
|||
|
业务单元
BusinessUnit
|
与合同关联的内部业务部门。 | ||
|
描述
此属性标识拥有或申请合同的内部部门或业务单位,例如“北美企业销售部”或“全球采购部”。 与 Department 类似,这允许对流程数据进行更高层级的聚合。它有助于比较组织内不同部分的流程效率和合规性,为高层管理人员提供有价值的洞察,并支持战略性资源分配决策。
为何重要
支持在不同组织单元之间进行高层级的流程绩效比较。
获取方式
这通常是合同协议上的关键元数据字段,将其链接到组织结构。
示例
北美业务部全球服务产品开发
|
|||
|
义务截止日期
ObligationDueDate
|
必须履行特定合同义务的截止日期。 | ||
|
描述
此属性跟踪合同执行后定义的关键义务、承诺和交付物的截止日期。一份合同可能有多个义务,每个义务都有自己的截止日期。 跟踪这些日期对于执行后的合规和风险管理至关重要。此属性是“义务履行率”KPI 的基础,使组织能够监控是否按时履行承诺,并主动应对潜在的违规行为。
为何重要
支持监控执行后的合规情况,这对于避免罚款和维护良好的业务关系至关重要。
获取方式
Icertis 拥有义务管理模块。这些数据将源自与合同相关的各项义务。
示例
2024-09-302025-01-152024-11-01
|
|||
|
交易方名称
CounterpartyName
|
合同中外部方的名称,例如客户或供应商。 | ||
|
描述
此属性标识协议中涉及的另一方。它为分析互动和谈判提供了必要的背景。 按交易对手分析流程可以揭示谈判周期的模式。例如,它可以显示与某些供应商的合同是否总是需要更长的谈判时间或更多的修订。这种洞察对于战略关系管理和定制谈判策略非常有价值,直接支持“谈判周期与返工”仪表板(dashboard)。
为何重要
允许分析谈判模式以及与特定外部方的合作表现。
获取方式
此信息作为合同元数据的一部分存储,通常链接到 Icertis 中的交易对手或供应商主数据对象。
示例
Acme CorporationGlobal Tech Inc.Innovate Solutions LLC
|
|||
|
修订次数
RevisionCount
|
合同经历的修订总次数。 | ||
|
描述
此计算指标为每个合同 case 提供修订相关活动(如“合同已修订或修改”)的计数。它是衡量流程摩擦的一个简单且强大的指标。 高修订计数信号起草或谈判阶段可能存在问题,如要求不明、初始草案质量差或谈判困难。此指标是“合同修订率”KPI 的直接输入,并用于仪表板中识别存在过度返工的合同和流程变体。
为何重要
量化合同生命周期中的返工情况,直接衡量起草和谈判阶段的效率。
获取方式
这是通过统计事件日志(event log)中每个 'ContractId' 对应特定修订活动的发生次数来计算的。
示例
1503
|
|||
|
最后数据更新
LastDataUpdate
|
流程数据最近一次刷新的 timestamp。 | ||
|
描述
此属性指示正在分析的数据的新鲜度。它记录了从源系统进行最后一次数据提取的日期和时间。 此信息对于用户了解仪表板(dashboards)中呈现的洞察的时效性至关重要。它帮助他们了解是在查看实时信息,还是数小时或数天前的数据,从而为决策设定正确的背景。
为何重要
提供有关数据新鲜度的背景,确保用户了解流程分析的实时程度。
获取方式
此 timestamp 在每次成功的数据刷新周期结束时由数据管道或 ETL 工具生成。
示例
2024-07-27T08:00:00Z2024-07-26T23:59:59Z
|
|||
|
到期日期
ExpirationDate
|
合同设定的到期日期。 | ||
|
描述
此属性存储合同期限的结束日期。它是管理合同执行后生命周期的关键日期,用于触发续约或终止活动。 此日期对于监控合同期末管理的有效性至关重要。它作为“按时续约/终止率”KPI 的基准,该 KPI 衡量续约或终止流程是否及时启动和完成,从而避免不必要的自动续约或服务中断。
为何重要
对于管理合同续约和终止至关重要,确保主动处理终期流程。
获取方式
这是 Icertis 中“合同协议”对象上的标准日期字段。
示例
2025-12-312026-06-302024-08-15
|
|||
|
区域
Region
|
与合同相关的地理区域。 | ||
|
描述
此属性指定合同适用的地理区域,如 EMEA、APAC 或北美。这对于在流程中存在地区差异的全球化组织非常重要。 按地区分析可以发现由当地法律和商业文化驱动的流程绩效、合规要求或谈判策略方面的差异。它支持特定地区的基准测试,并有助于识别可在全球范围内共享的最佳实践。
为何重要
帮助识别不同地区在流程绩效和合规性方面的差异,这对全球化企业至关重要。
获取方式
这通常是 Icertis 中合同对象的元数据字段,通常是标准配置的一部分。
示例
欧洲、中东和非洲北美亚太拉美地区
|
|||
|
处理时间
ProcessingTime
|
在一项活动上实际投入工作的时间长度。 | ||
|
描述
Processing Time 是计算出的从活动开始到结束的持续时间。它代表资源处理任务的实际时间,而非任务之间的等待时间。 该指标是绩效分析的基础。它有助于查明整个流程中最耗时的具体活动。例如,它可能显示虽然整体法务审核阶段很长,但实际审阅文档的时间很短,这表明大部分时间都消耗在了排队等待上。这对于几乎所有的仪表板(Dashboard)都至关重要,特别是那些关注周期和效率的仪表板。
为何重要
区分实际工作时间与空闲等待时间,为效率提升提供更准确的目标。
获取方式
这是根据数据集中的 'EventTime' (StartTime) 和 'EndTime' 属性计算得出的。
示例
2小时15分钟3 days 4 hours30 分钟
|
|||
|
文档版本
DocumentVersion
|
合同文档的版本号。 | ||
|
描述
此属性跟踪合同文档在起草、修订和更新过程中的迭代。它通常是一个整数或 major.minor 形式的版本号。 Document Version 是返工的直接指标。合同的高版本数意味着多轮修改,可以通过调查了解其根本原因。它是计算“合同修订率”KPI 以及“起草与修订效率”仪表板(dashboard)的关键输入。
为何重要
直接衡量合同经历的返工和修订量,突出起草和谈判中的低效之处。
获取方式
Icertis 维护所有合同文档的版本历史记录。此属性可以从文档的元数据或事件日志(event log)中提取。
示例
1.02.34.00.5
|
|||
|
是否为标准模板
IsStandardTemplate
|
一个标志,指示合同是否由公司标准模板创建。 | ||
|
描述
此布尔属性表示合同是源自预先批准的标准模板,还是作为非标准的定制协议创建。这是评估风险和合规性的关键因素。 基于标准模板的合同通常具有更快的周期和更低的风险。此属性是“合同模板采用率”KPI 的基础,有助于分析使用非标准文本对流程的影响。它可以突出显示经常偏离标准的部门或合同类型,从而指导提升模板使用率的工作。
为何重要
衡量对公司标准的遵循程度,这与流程效率和风险降低直接相关。
获取方式
这可以是合同上的复选框字段,也可以根据 Icertis 中的文档来源或元数据得出。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
提取合同数据的来源系统。 | ||
|
描述
此属性标识数据的来源,在本流程中为“Icertis”。它有助于数据治理和可追溯性,尤其是在可能从多个系统聚合数据的环境中。 在分析中,它可以用于将数据过滤到特定的源系统,或者在适用时比较不同系统的流程。在此视图中,它作为所有事件的固定标识符。
为何重要
确保数据血缘和可追溯性,这对于数据验证和管理来自多个源的数据非常重要。
获取方式
这通常是在数据提取和转换过程中添加的静态值,用于标记 data 来源。
示例
IcertisIcertisCLM
|
|||
合同管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
合同已执行
|
此活动标志着合同的正式执行,即各方均已签署。它是签署前流程的主要成功终点,通过与电子签名平台集成来捕获。 | ||
|
为何重要
作为主要完成事件,这是“平均合同周期时间”KPI 的终点。它标志着合同具有法律约束力并生效的时刻。
获取方式
一旦所有各方的签署流程完成,Icertis 会接收到来自电子签名平台的显式事件并进行记录。
捕获
来自电子签名平台集成的回调事件。
事件类型
explicit
|
|||
|
合同已终止或到期
|
标志着合同生命周期的结束,可以通过主动终止流程或到达到期日期。终止是一个明确事件,而到期则是根据合同元数据计算得出的事件。 | ||
|
为何重要
这是合同生命周期的终结事件。它对于分析续约率和衡量“按时续约/终止率”KPI 至关重要。
获取方式
当用户执行终止操作时,系统会显式记录终止事件。到期时间可以通过将当前日期与“到期日期”属性进行对比来计算。
捕获
通过对比系统日期与合同到期日期计算得出,或源自手动终止事件。
事件类型
calculated
|
|||
|
合同申请已发起
|
此活动标志着合同生命周期的正式开始,即业务用户正式申请新合同。这通常是在用户在 Icertis 平台内提交合同申请表时捕获的一个明确事件。 | ||
|
为何重要
作为流程的起点,此事件对于衡量整体合同周期时间至关重要。分析申请的数量和类型有助于资源规划和需求管理。
获取方式
这是在创建并提交“合同申请”对象时在 Icertis 中记录的一个明确事件。
捕获
提交合同申请表后记录的事件。
事件类型
explicit
|
|||
|
已收到交易方审批
|
此活动表示外部交易对手已同意条款并批准了最终版本的合同。这可以是来自协作门户的明确事件,也可以由合同负责人手动更新状态。 | ||
|
为何重要
这一里程碑标志着谈判阶段的结束。它作为计算“平均谈判周期”KPI 的终点,突出了外部互动的效率。
获取方式
如果交易对手使用 Icertis 门户进行批准,这可以是一个明确事件。否则,将根据手动更改状态为“交易对手已批准”进行推断。
捕获
从交易方门户记录的事件,或由内部用户手动更新状态。
事件类型
explicit
|
|||
|
已获得内部审批
|
标志着所有相关的内部利益相关者均已批准合同,合同已准备好进行外部谈判或签署。这是根据审批工作流(workflow)的整体状态达到最终“已批准”状态推断得出的。 | ||
|
为何重要
这是一个关键里程碑,标志着内部审核周期的结束。它是衡量“平均审批阶段时长”KPI 的终点。
获取方式
根据工作流(workflow)状态更改为“完全批准”或类似状态进行推断,表示所有审批任务已完成。
捕获
最后一次内部审批任务完成或整体工作流(workflow)状态更改的 timestamp。
事件类型
inferred
|
|||
|
已进行法务审核
|
表示法务部门已完成合同审核。这通常是法务审核人员在审批工作流(workflow)中完成指定任务时记录的明确事件。 | ||
|
为何重要
此活动对于衡量法务审核周转时间以及识别法务团队内潜在的产能限制至关重要。它支持“法务审核等待时间”KPI。
获取方式
当 Icertis 工作流中的法务评审任务被标记为“完成”时显式记录。也可以根据“法务已批准”等状态变更推断得出。
捕获
来自工作流引擎的事件,指示“法务评审”任务已完成。
事件类型
explicit
|
|||
|
义务监控已激活
|
此执行后活动表示合同义务和承诺已在系统中激活以供跟踪。这通常是合同执行后自动触发或由合同管理员手动触发的明确事件。 | ||
|
为何重要
此事件开启了执行后管理的时间。这对于通过“义务履行率”KPI 衡量并确保合规性至关重要。
获取方式
当合同状态变为“活跃”或“已执行”时,在 Icertis 义务管理模块中记录的显式事件。
捕获
自动或手动激活与合同相关的义务记录。
事件类型
explicit
|
|||
|
交易方谈判已启动
|
代表合同与外部交易对手共享进行审阅和谈判的时间点。这通常根据合同状态更改为“谈判中”或根据文档首次发送至外部的审核日志来推断。 | ||
|
为何重要
此活动标志着谈判阶段的开始。它是计算“平均谈判周期”KPI 的起点。
获取方式
通过手动将状态更改为“正在谈判”进行推断,或通过跟踪文档首次在外部门户共享的事件进行推断。
捕获
状态更改为“谈判中”或“已发送至交易对手”的 timestamp。
事件类型
inferred
|
|||
|
修订已启动
|
代表修订有效合同的正式流程开始。当用户创建链接到原始已签署协议的修订记录时,会捕获此事件。 | ||
|
为何重要
修订代表了重大的返工或范围变更。跟踪其频率和周期时间可以深入了解合同的稳定性和管理效率。
获取方式
当创建“修订”对象或类似记录并与现有合同关联时,系统会记录一个显式事件。
捕获
在 Icertis 系统中创建修订记录。
事件类型
explicit
|
|||
|
内部审核已开始
|
此活动标志着内部审阅和审批工作流(workflow)的开始。当合同草案正式提交给内部利益相关者(如部门负责人或财务部门)进行审阅时,会捕获此活动。 | ||
|
为何重要
这标志着审批阶段的开始,通常也是瓶颈的来源。分析自该事件以来的时间有助于识别内部协作启动中的延迟。
获取方式
当 Icertis 工作流中触发“提交评审”操作时记录为显式事件,或者根据状态变更为“内部评审中”推断得出。
捕获
在用户启动内部审核工作流(workflow)时记录。
事件类型
explicit
|
|||
|
合同已修订或修改
|
每当合同文档在内部审核或外部谈判期间被修改时,都会发生此活动。Icertis 会跟踪文档版本,因此签入的每个新版本都可以作为修订事件被捕获。 | ||
|
为何重要
统计每份合同的此类事件有助于计算“合同修订率”KPI。修订次数过多可能表明措辞含糊、谈判效率低下或利益不一致。
获取方式
每当上传或签入新版本的合同文档时,在 Icertis 文档管理模块中显式记录的事件。
捕获
为每个新文档版本号创建一个事件。
事件类型
explicit
|
|||
|
合同已发送签署
|
表示最终批准的合同已发送进行电子或纸质签署。这是通过与 DocuSign 或 Adobe Sign 等电子签名平台集成捕获的明确事件。 | ||
|
为何重要
跟踪此事件有助于分析最终执行步骤的效率。批准与发送签署之间的延迟可能揭示行政管理上的瓶颈。
获取方式
当从 Icertis 内部启动签署流程时,通过与电子签名解决方案的 API 集成显式记录的事件。
捕获
发送签名请求时,来自电子签名连接器的事件。
事件类型
explicit
|
|||
|
合同已续约
|
表示现有合同已成功续约。这是系统内执行的明确操作,通常会启动新的合同记录或更新现有记录。 | ||
|
为何重要
此活动是评估续约管理流程有效性的关键。它用于计算“按时续约/终止率”KPI。
获取方式
用户在 Icertis 中的合同记录上执行“续约”操作时生成的显式事件。
捕获
由用户发起的“续约”事务记录的事件。
事件类型
explicit
|
|||
|
合同已起草
|
代表初始合同文档的创建,无论是通过模板还是作为新文件。该事件通常根据与合同工作区相关的主合同文档的创建或首次上传来推断。 | ||
|
为何重要
跟踪此活动有助于衡量准备初始草案所需的时间。这是分析起草效率和模板采用率的关键步骤。
获取方式
根据 Icertis 合同工作区或协议对象中主合同文档的创建 timestamp 进行推断。
捕获
识别主合同文档第一版本的创建 timestamp。
事件类型
inferred
|
|||