您的合同管理数据模板
您的合同管理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 数据提取指南
合同管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
合同 ID
ContractId
|
系统中管理的每份合同的唯一标识符。 | ||
|
描述
合同 ID 作为最终的 Case 标识符,将特定合同从启动到解决的所有 Event 和活动唯一地关联起来。在 DocuSign CLM 中,这可能对应 Envelope ID 或自定义合同标识符字段。 此属性对于 Process Mining 至关重要,因为它允许重构每份合同的端到端旅程。通过将所有相关活动归集到同一个合同 ID 下,分析人员可以可视化完整的流程流,衡量周期时间,并分析不同合同之间的差异。
为何重要
它是连接所有相关流程事件的主键,使得追踪和分析单个合同的完整生命周期成为可能。
获取方式
这通常是 DocuSign CLM 中合同或信封对象的主要标识符。它可能被标记为 Envelope ID 或配置为合同识别的自定义字段。
示例
CON-2023-03-112MSA-4815162342NDA-CORP-9981
|
|||
|
开始时间
EventTime
|
指示特定活动或事件开始的时间戳。 | ||
|
描述
此属性记录活动发生的精确日期和时间。它是 Process Mining 的时间基础,支持分析流程绩效随时间的变化。 通过根据“开始时间”对 Event 进行排序,可以为每个 Case 创建按时间顺序排列的日志。从而可以计算活动间的周期、每个步骤的时长以及整体端到端耗时。这对于识别瓶颈、衡量等待时间以及根据 SLA 评估效率至关重要。
为何重要
此 timestamp 对于按时间顺序排列事件以及计算所有基于时间的指标(如周期时间和持续时间)至关重要。
获取方式
此信息是 DocuSign CLM 中任何 Event Log 或审计轨迹的标准组成部分,与每项记录的操作相关联。
示例
2023-04-15T09:00:00Z2023-05-20T14:35:10Z2023-06-01T11:21:05Z
|
|||
|
活动
ActivityName
|
合同生命周期中发生的特定 Task 或 Event 的名称。 | ||
|
描述
此属性描述了合同管理流程中的单个步骤或里程碑,例如“合同已起草”、“法务审查已开始”或“合同已执行”。这些活动是流程图的基础构件。 分析这些活动的顺序和频率是 Process Mining 的核心。它有助于识别真实的流程流,发现偏离标准流程的情况,并查明哪些活动最耗时或重复最频繁。
为何重要
它定义了流程中的步骤,支持对合同工作流、瓶颈和变体进行可视化分析。
获取方式
这通常派生自 DocuSign CLM 中的 Event Log 或审计轨迹 Data,记录了对合同文档或 Workflow 执行的操作。
示例
合同已起草内部评审已开始已发至交易对手合同已执行
|
|||
|
最后数据更新
LastDataUpdate
|
此属性指示data最后一次从Salesforce Financial Services Cloud提取的日期和时间,为分析数据“新鲜度”提供背景。这对于dashboard用户理解分析时效性至关重要,有助管理数据及时性预期,并验证data pipelines是否按计划运行。 | ||
|
描述
此属性指示数据集的最后更新时间,为分析的时效性提供参考,让用户了解 Data 的新旧程度。 在 Dashboard 和报告中,此信息对于 Data 治理和建立用户信任至关重要。它能帮助分析师判断是在查看实时信息还是特定时间点的快照,这对于做出明智、及时的决策非常关键。
为何重要
提供关于 Data 时效性的关键上下文,确保用户了解流程分析的最新程度。
获取方式
这是一个元数据属性,通常在 Data 摄取过程中由 ETL 工具或 Data 管道生成并存储。
示例
2023-10-26T08:00:00Z2023-10-27T08:00:00Z
|
|||
|
源系统
SourceSystem
|
用于标识数据提取自哪个系统。 | ||
|
描述
此属性指定流程 Data 的来源。在此视图中,该值通常为“DocuSign CLM”或类似标识符。 虽然在单一系统分析中这看似多余,但包含此字段是最佳实践。在合并来自多个系统的 Data 时(例如将 CRM 的合同 Data 与 DocuSign 的 Workflow Data 相结合),它变得至关重要,能确保清晰的 Data 血缘和可追溯性。
为何重要
确保数据可追溯性,对于结合多个企业系统数据的分析至关重要。
获取方式
这通常是在 Data 提取和转换过程中添加的静态值,用于标记数据集的来源。
示例
DocuSign CLMDocuSign CLM v24.1
|
|||
|
交易对手
Counterparty
|
涉及合同的外部方,如客户或供应商。 | ||
|
描述
此属性标识参与协议的其他组织。不同的交易对手可能有不同的谈判风格、法务要求和响应速度,这会显著影响合同生命周期。 按交易对手分析绩效有助于识别哪些合作伙伴更易配合,哪些则经常导致延误。此信息可用于改善关系管理,并为未来的谈判设定切实的预期。它是“合同返工与修订频率”分析的关键维度。
为何重要
有助于分析与不同外部方的交互如何影响谈判时间、修订次数和整体周期。
获取方式
此信息是合同记录的核心部分,通常存储在专用的“交易对手名称”或“公司”字段中。
示例
鼎盛工业 (Acme Corporation)环球有限公司 (Globex Inc.)Stark Industries
|
|||
|
到期日期
ExpirationDate
|
合同到期的日期。 | ||
|
描述
此属性存储合同到期日期。它是主动管理合同组合的关键元数据,特别是对于经常性收入或长期服务协议。 此日期是“合同续约与到期展望”Dashboard 的主要驱动力。通过监控即将到期的合同,组织可以及时触发续约 Workflow。它也是计算“合同按时续约率”KPI 的核心输入,有助于防止收入流失和服务中断。
为何重要
对于主动合同管理至关重要,支持及时续约并防止合同意外失效。
获取方式
这是一个标准的元数据字段,应捕获 DocuSign CLM 中任何具有明确期限的合同。
示例
2024-12-312025-06-302026-01-15
|
|||
|
合同价值
ContractValue
|
合同的总金额。 | ||
|
描述
此属性代表协议的财务价值,可以是单次金额或经常性数值。合同价值通常决定了所需的审查级别和审批路径的复杂程度。 按“合同价值”分析流程,对于优先处理高价值交易以及识别是否存在不必要的延误至关重要。它还可以用于合规性检查,例如验证超过特定阈值的合同是否获得了 CFO 审批。此属性有助于将优化工作的重心放在财务影响最重大的合同上。
为何重要
支持优先级划分和风险评估,因为高价值合同通常需要更严格的审查,且对业务的影响更大。
获取方式
这通常是 DocuSign CLM 合同元数据中的数字或货币字段。
示例
500002500001200000
|
|||
|
合同所有者
ContractOwner
|
负责在合同生命周期内进行管理的用户或员工。 | ||
|
描述
合同所有者是合同推进的主要联系人和负责人。通常是发起合同请求或负责维护该业务关系的人员。 按合同所有者分析绩效可以揭示效率、返工率和周期时间的模式。这有助于识别表现优异的个人或团队,以及可能需要额外支持的成员。它是 Dashboard(如“合同周期时间分析”)中细分 Data 的关键维度。
为何重要
支持按个人或团队进行绩效分析,有助于识别最佳实践以及用户驱动型活动中的待改进领域。
获取方式
这通常是与合同对象关联的用户字段,通常填充有创建或拥有该 Workflow 的用户姓名。
示例
Alice SmithBob JohnsonCharlie Brown
|
|||
|
合同状态
ContractStatus
|
合同在其生命周期中的当前状态。 | ||
|
描述
此属性指示合同在特定时间点的总体状态,例如“草稿”、“审查中”、“待签署”或“已执行”,提供流程进度的概要。 在 Process Mining 中,分析状态有助于过滤 Case 并构建用于跟踪各阶段合同量的 Dashboard。“实时合同状态追踪”Dashboard 直接依赖此属性来呈现活动合同组合的透明度,并识别工作积压点。
为何重要
提供合同进展的快照,这对于状态跟踪、工作量管理和识别瓶颈至关重要。
获取方式
此信息通常作为 DocuSign CLM 中合同或 Workflow 对象的主要属性提供。
示例
草稿内部评审中待签署已执行已终止
|
|||
|
合同类型
ContractType
|
合同的分类,例如 NDA、MSA 或 SOW。 | ||
|
描述
此属性根据合同的法律或业务用途进行分类。不同类型的合同往往遵循不同的 Workflow,且在审批要求和复杂程度方面各不相同。 按合同类型细分流程分析是理解绩效差异的基础。它允许分析师比较不同协议的周期时间、合规率和谈判模式。例如,NDA 的周期理应比复杂的 MSA 短得多,而此属性使这种对比成为可能。
为何重要
支持比较不同类别合同的流程绩效,这些合同通常具有独特的工作流和复杂程度。
获取方式
这是一个关键的元数据字段,通常在 DocuSign CLM 中创建合同时从下拉列表中选择。
示例
保密协议 (NDA)主服务协议 (MSA)工作说明书 (SOW)
|
|||
|
周期时间
CycleTime
|
从合同请求发起直到最终归档所经过的总时长。 | ||
|
描述
此属性衡量每个合同 Case 的端到端时长。计算方式为第一个 Event(如“发起合同请求”)与最后一个 Event(如“合同存入存储库”)之间的时间差。 周期时间是衡量流程效率的核心 KPI,提供完成合同所需的整体耗时视图。该计算指标是“平均合同周期时间”KPI 和“合同周期时间分析”Dashboard 的基础,支持深入分析合同类型或价值等因素如何影响整体效率。
为何重要
这是衡量整体流程效率的主要 KPI,反映了处理一份合同从开始到结束的总耗时。
获取方式
该指标不在源系统中,而是由 Process Mining 工具根据 Case 的开始和结束 Timestamp 计算得出的。
示例
15天4小时32 天 8 小时7 天 2 小时
|
|||
|
结束时间
EndTime
|
指示特定活动或事件完成时间的精确时间戳。 | ||
|
描述
此属性记录活动结束的精确日期和时间。“开始时间”标记启动,而“结束时间”标记完成,从而支持对单个活动的耗时进行精确计算。 分析“结束时间”对于计算活动的“处理时间”(即在 Task 上花费的实际工作时间)至关重要。这有助于区分实际工作与等待时间,从而深入了解资源效率和延迟的真实成本。例如,它可以用于计算“法务审查”活动的确切时长。
为何重要
支持精准计算单个活动的持续时间,有助于区分实际处理时间与空闲等待时间。
获取方式
在 DocuSign CLM 等系统中,这可能显式记录在审计轨迹中,或者可能需要根据后续事件的开始时间进行推断。
示例
2023-04-15T17:30:00Z2023-05-21T10:00:15Z2023-06-01T11:55:00Z
|
|||
|
审批状态
ApprovalStatus
|
审批步骤的状态,例如“待处理”、“已批准”或“已拒绝”。 | ||
|
描述
此属性提供专门针对合同生命周期审批阶段的细分状态。虽然“合同状态”是高级别的 Case 状态,但“审批状态”跟踪的是具体审批活动的结果。 这对于“合同审批瓶颈报告”和“实时合同状态追踪”至关重要。它能清晰显示哪些合同正在等待审批、哪些已被拒绝需要返工,以及哪些已成功通过审批。分析这些状态之间的转换有助于精准定位审批链中的失败点或延迟点。
为何重要
提供关于审批阶段的详细洞察,从而识别出哪些合同卡住了以及具体原因。
获取方式
这是 DocuSign CLM 中审批任务或 workflow 步骤的处理结果。
示例
等待法务审批财务部已批准被销售副总裁拒绝
|
|||
|
审批阶段耗时
ApprovalPhaseDuration
|
在所有与审批相关的活动中花费的总时长。 | ||
|
描述
该指标计算合同在审批阶段的总时长,即从发起第一次内部审批到获得最后一次必要审批的时间。计算方式可以是所有审批活动时长的总和,也可以是第一次审批开始与最后一次审批结束之间的时间差。 此属性是“平均审批阶段时长”KPI 的核心衡量标准。它有助于隔离专门由审批流程(而非起草或谈判)造成的延迟。通过跟踪该时长,组织可以更清晰地了解审批矩阵的影响,并寻找简化流程的机会。
为何重要
分离出审批所花费的时间,从而更容易识别并解决审批链条中的特定瓶颈。
获取方式
由流程挖掘工具通过识别所有与审批相关的事件(例如“Internal Approval Sent”、“Internal Approval Received”)并测量每个案例中第一个和最后一个此类事件之间的时间计算得出。
示例
5天2小时10 天 1 小时2 天 6 小时
|
|||
|
文档版本
DocumentVersion
|
合同文档的版本号。 | ||
|
描述
此属性在合同文档经过修订和红线标记时跟踪其迭代次数。每次上传或保存新版本时,此数字应递增。 跟踪文档版本是衡量返工和谈判复杂性的直接方式。合同版本过多通常意味着各方之间存在大量的沟通反复。此属性是计算“平均文档修订次数”KPI 和分析“合同返工与修订频率”Dashboard 的核心输入。
为何重要
通过追踪文档修订次数,直接衡量返工量和谈判投入。
获取方式
DocuSign CLM 内置了文档版本控制。该属性将从文档的版本历史记录中提取。
示例
1234
|
|||
|
是否电子签名
IsESigned
|
指示合同是否通过电子签名签署的布尔标志。 | ||
|
描述
此属性跟踪合同是使用集成的电子签名工具(如 DocuSign eSignature)签署的,还是通过线下方式(如手写签名并扫描)执行的。 该属性直接支持“电子签名采用率”KPI。通过分析电子签署合同的比例,企业可以衡量数字化转型计划的成效。较高的采用率通常意味着更快的执行速度、更低的行政成本以及更优的合规性和文档追踪能力。
为何重要
衡量数字化流程的采用情况,并量化使用集成电子签名功能带来的效率提升。
获取方式
这可以通过检查“合同已执行”Event 是否源自集成的 DocuSign eSignature 服务来确定。
示例
truefalse
|
|||
|
是否返工
IsRework
|
指示合同是否经历了显著修订循环的布尔标志。 | ||
|
描述
此计算属性用于识别经历过返工的合同,例如在获得内部批准后又被退回进行红线修订。它通常通过查找特定的、非理想的活动序列来推导。 该标记简化了流程低效环节的分析。它支持直接计算“合同返工率”KPI,并方便用户筛选和分析那些需要额外投入的合同。这有助于查明返工的根源,例如初始需求不明确或谈判难点。
为何重要
有助于量化和分析返工频率,这是衡量流程效率低下和隐性成本的关键指标。
获取方式
此属性是在 Process Mining 工具内通过定义规则来计算的,用于识别返工循环,例如在“收到内部批准”Event 之后又出现了“合同红线标记”Event。
示例
truefalse
|
|||
|
法律顾问
LegalCounsel
|
被分配审查该合同的法务专业人员或团队成员。 | ||
|
描述
此属性标识负责审查和批准合同的法务部门具体人员,这与通常来自业务部门的合同所有者不同。 将审查分配给特定的法务顾问,可以对法务审查步骤进行详细的绩效分析。它有助于构建“法务审查绩效”Dashboard,衡量并对比不同法务成员的吞吐量和周期时间,从而助力工作负载均衡,识别法务部门内的效率提升空间。
为何重要
支持对法务审查阶段进行详细分析,有助于平衡工作负载并衡量法务团队的绩效。
获取方式
该信息源自 DocuSign CLM workflow 中的任务分配数据,指明了“法务审查”任务的负责人。
示例
Jennifer WaltersMatt MurdockHarvey Specter
|
|||
|
部门
Department
|
拥有该合同的内部业务部门。 | ||
|
描述
此属性指定发起或负责合同的内部部门(如销售、市场或 IT)。部门级的流程和需求各异,会导致不同的合同管理模式。 按部门细分分析,对于了解不同业务部门如何利用合同管理流程至关重要。它有助于创建针对性报告(如“合同审批瓶颈报告”),以识别延迟是否集中在特定业务单元,从而让流程改进方案更贴合部门需求。
为何重要
支持不同业务单元之间的绩效比较,突出效率、合规性和工作负载方面的差异。
获取方式
这可能是合同上的元数据字段,也可能派生自合同所有者所属的部门。
示例
销售法务采购市场营销
|
|||
合同管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
合同已发送待签署
|
此活动标志着最终获批合同的电子签名流程启动。这是 DocuSign 的核心功能,在用户通过 DocuSign eSignature 信封发送文档时记录。 | ||
|
为何重要
这是执行前的关键里程碑。分析从此时到执行的时间,有助于了解签名收集效率并支持“电子签名采用率”KPI。
获取方式
这是记录在文档详细历史或审计轨迹中的明确核心 Event,通常被称为“信封历史 (Envelope History)”。
捕获
当电子签名信封创建并发送时,由系统直接记录。
事件类型
explicit
|
|||
|
合同已执行
|
代表合同的成功签署,发生在最后一位必需签署人在文档上签字时。这由 DocuSign eSignature 平台明确记录。 | ||
|
为何重要
这是合同创建流程的主要成功终点。它对于计算“平均合同周期时间”和衡量整体流程吞吐量必不可缺。
获取方式
当 eSignature Workflow 完全完成时,该 Event 的 Timestamp 会记录在完成证书和文档的审计日志中。
捕获
当应用最后一个签名时,由电子签名组件自动记录。
事件类型
explicit
|
|||
|
合同已终止
|
此活动代表合同生命周期的正式结束,无论是到期、取消还是双方协议。通常通过系统中的手动状态更改来捕获。 | ||
|
为何重要
这是流程的一个替代终点。跟踪合同终止和到期对于了解完整的合同生命周期以及续约分析至关重要。
获取方式
当用户将合同的状态字段更新为“已终止”、“已过期”或“已取消”时,将捕获此 Event。使用该状态更改的 Timestamp。
捕获
根据合同的主要状态字段变更为终止状态推断得出。
事件类型
inferred
|
|||
|
合同申请已发起
|
此活动标志着合同生命周期的正式开始。通常在用户提交合同请求表单或在 DocuSign CLM 中创建新合同记录并触发关联 Workflow 时捕获。 | ||
|
为何重要
这是流程的主要开始 Event。分析该活动对于衡量整体合同吞吐量和端到端周期时间的起点至关重要。
获取方式
此 Event 捕获自审计日志或 Workflow 历史记录,对应合同记录的创建 Timestamp 或 intake 表单的提交。
捕获
从提交合同发起表单或创建新合同对象记录。
事件类型
explicit
|
|||
|
已收到内部审批
|
该里程碑表示所有必需的内部审批人均已批准合同。当 Workflow 中最后一位必需审批人完成其 Task 时记录。 | ||
|
为何重要
这是一个关键里程碑,表明合同已准备好进行外部谈判或执行。在此之前的任何延迟都凸显了内部协作的一致性问题。
获取方式
当审批 Task 达到最终的“已批准”状态时,此 Event 会记录在 Workflow 历史中。
捕获
当串行或并行审批 Workflow 中的最后一位审批人完成审批时记录。
事件类型
explicit
|
|||
|
法务审查已启动
|
标志着合同正式提交给法务部门进行审查和反馈。这是合同进入 Workflow “法务审查”阶段时记录的关键步骤。 | ||
|
为何重要
法务审查是合同管理中常见的瓶颈。衡量其时长是“法务审查绩效”Dashboard 的核心,有助于识别提速机会。
获取方式
该 Event 捕获自 Workflow 审计轨迹,记录了 Task 分配给法务团队或合同状态变为“法务审查中”的时间戳。
捕获
当合同被分配到法务审查任务或队列时,从工作流引擎记录。
事件类型
explicit
|
|||
|
义务监控已开始
|
此活动标志着执行后管理的开始,用于跟踪关键日期和交付成果。当启动监控合同义务的 Task 或子流程时,即会捕获该活动。 | ||
|
为何重要
这对“执行后义务履行率”KPI 至关重要,该活动展示了合同签署后的承诺是否得到了妥善管理。
获取方式
需要系统分析。这通常通过创建特定的义务跟踪 Task 或与主合同关联的 Workflow 来捕获。
捕获
从创建与义务管理相关的执行后任务或工作流记录。
事件类型
explicit
|
|||
|
内部评审已开始
|
此活动表示已起草的合同已提交给财务、运营等内部业务相关方进行审查。在用户启动 Workflow 中的“内部审查”Task 时捕获。 | ||
|
为何重要
这标志着审查阶段的开始,该阶段通常是瓶颈的来源。分析其耗时有助于查明利益相关者反馈中的延误。
获取方式
当合同转为“内部审查”状态或将审查 Task 分配给非法律部门的内部用户时,记录在 Workflow 历史中。
捕获
当 Workflow 转入分配给内部业务审查的状态或 Task 时记录。
事件类型
explicit
|
|||
|
合同已修订留痕
|
此活动代表在谈判或审查周期内对合同文档进行的修订或修正。每当上传或保存文档的新版本时,都会捕获该活动。 | ||
|
为何重要
跟踪修订次数对于“合同返工率”KPI 而言至关重要。大量的修订可能意味着条款不清晰、谈判效率低下或初稿质量欠佳。
获取方式
源自与合同关联的文档版本历史。初始草案之后创建的每个新版本都可以被视为“Contract Redlined”事件。
捕获
当在 DocuSign CLM 存储库中上传或生成新的文档版本时记录。
事件类型
explicit
|
|||
|
合同已存入库
|
这是最后的行政步骤,执行完毕的合同会自动归档到中央合同存储库中。该 Event 通常由签名流程的完成触发。 | ||
|
为何重要
确保流程以妥善的记录保存结束。它标志着执行前生命周期的结束和执行后阶段的开始。
获取方式
从工作流历史中获取,标记为归档已签署文档的最终步骤完成。
捕获
作为执行成功后的最后一个自动化步骤,由工作流引擎记录。
事件类型
explicit
|
|||
|
合同已起草
|
代表合同文档初始草案的创建和完成。当系统上传或生成并保存文档的第一个版本时,即可捕获该活动。 | ||
|
为何重要
跟踪此项有助于了解在评审开始前,用于起草和准备工作的时间。这为衡量后续修订频率提供了基准。
获取方式
根据合同文档历史中第一个文档版本的创建时间戳,或状态变更为“起草完成”推断得出。
捕获
识别与合同 ID 关联的首个文档版本的创建事件。
事件类型
inferred
|
|||
|
对方谈判已开始
|
指示对方已做出回应,通常是提供反馈或合同的修订版本。当外部方上传新文档版本或状态恢复到内部评审阶段时,可推断出此事件。 | ||
|
为何重要
此活动对于分析“每份合同的谈判交接次数”KPI 至关重要。内部团队与交易对手之间的频繁循环通常意味着谈判过程存在阻力。
获取方式
根据收到外部来源的新文档版本,或用户手动更改状态以反映已收到对方反馈推断得出。
捕获
根据合同在对方处处理后状态变回“内部评审”或“起草中”推断得出。
事件类型
inferred
|
|||
|
已发至交易对手
|
代表将合同文档分享给外部交易对手以供审查和签署的操作。该操作通过 DocuSign CLM 中的“发送”或“共享”动作记录。 | ||
|
为何重要
此活动标志着向外部方的交接,此时流程控制力有限。了解在交易对手环节耗费的时间是识别外部延迟的关键。
获取方式
从审计轨迹中获取,该轨迹记录了诸如从 CLM 发送带有文档的电子邮件或通过外部门户共享文档等操作。
捕获
从通过平台功能向外部共享文档的特定用户操作记录。
事件类型
explicit
|
|||
|
已发起合同续约
|
标志着现有合同续约流程的开始。该活动通常由合同所有者手动触发,或根据合同到期日自动触发。 | ||
|
为何重要
此活动对于跟踪“合同按时续约率”KPI 至关重要。它能让您了解组织管理到期合同的主动程度。
获取方式
在执行特定的“续约合同”操作时获取,该操作可能会创建与原合同关联的新合同记录,或启动续约工作流。
捕获
从特定的用户操作或旨在启动续约工作流的自动化触发器记录。
事件类型
explicit
|
|||
|
已发送内部审批
|
此活动发生在合同完成审查并发送给指定的内部授权方进行正式审批时。在启动审批 Workflow 时捕获。 | ||
|
为何重要
这标志着最终内部签核阶段的开始。其耗时是“平均审批阶段时长”KPI 的核心组成部分。
获取方式
当用户发送合同进行审批并触发审批人分配时,Workflow 历史中会记录这一明确动作。
捕获
执行“发送审批”或类似的 Workflow 操作时记录。
事件类型
explicit
|
|||