业务过程-关键活动-业务术语关系

步骤1：分解业务过程 → 识别关键活动 → 关联业务术语

1. 先纵向梳理（流程维度）
   • 将整体业务流程拆解为多个业务过程（如“企业信息管理”“客户洽谈”等）。
   • 针对每个业务过程，列出其关键活动（即“必须完成的具体动作”）。
2. 再横向关联（数据维度）
   • 从关键活动中提取业务术语（即活动中涉及的专用名词或数据对象）。
   • 最后映射到数据对象（如数据库表、文档模板）和DCMM能力域。

示例：客户洽谈与需求分析

步骤2：验证逻辑闭环（检查是否遗漏）

• 正向验证：
  • 业务过程 → 关键活动 → 术语 → 数据对象 → DCMM能力域，是否全部覆盖？
  • 例如：
    • 业务过程“合同管理”中，关键活动“合同变更审批”是否关联了术语“合同变更”？
    • 是否明确了对应的数据对象（变更记录表）和DCMM能力域（数据安全）？
• 反向验证：
  • 业务术语是否都能追溯到某个关键活动？
    • 例如：术语“企业公海”应关联到关键活动“公海客户分配”。

步骤3：输出交付物（可选）

1. 业务过程清单：明确每个过程的输入、输出、参与角色。
2. 关键活动流程图：用泳道图/BPMN展示活动间的顺序和逻辑。
3. 业务术语表：定义每个术语的含义、归属过程和数据类型。

业务过程清单

关键活动流程图（泳道图）

关键活动流程图（表格形式）

表格设计说明

1. 泳道映射：
   • 每行代表一个角色的活动，横向流动体现流程顺序（如从“数据管理员”到“客服团队”）。
   • 角色列明确责任边界，符合泳道图的核心逻辑。
2. 关键节点：
   • 分支逻辑：例如“客户洽谈”的输出可能是“报价”或“终止”，通过“下一步活动”字段体现。
   • 闭环反馈：回访后可能触发“合同变更”，形成流程闭环。
3. 与DCMM关联：
   • 数据流清晰：输入输出列体现数据资产（如合同、标签）的生成与流转，符合DCMM数据生命周期管理要求。
   • 角色权限：明确角色与数据的交互关系（如法务仅参与合同审核）。

业务术语表

为什么这样做？

1. 对齐DCMM要求：
   • 业务术语对应数据标准能力域，关键活动对应数据质量/安全等能力域。
2. 指导系统设计：
   • 关键活动需系统功能支持（如“合同审批”需工作流引擎）。
3. 规避风险：
   • 遗漏关键活动可能导致流程断裂（如缺少“客户资质审核”会引发合规风险）。

除了关键活动之外，非关键活动中也可能涉及重要的业务术语。以下是完整的梳理方法和解决方案：

1. 关键活动 vs. 非关键活动的业务术语关系

2. 完整梳理方法（关键活动+非关键活动）

步骤1：分层拆解业务过程

步骤2：术语捕获规则

1. 必捕获场景：
   • 术语被多个活动引用（如"客户等级"在签约/回访中均使用）
   • 术语影响系统字段设计（如"合同变更类型"需作为枚举值存储）
   • 术语涉及合规要求（如"敏感信息标记"）
2. 可选捕获场景：
   • 仅特定角色使用的内部俚语（如销售部门称潜在客户为"种子"）
   • 临时性数据项（如"活动临时编号"）

3. 实际案例演示（客户签约过程）

4. 术语管理推荐方案

分层术语表结构

# 业务术语词典
## 核心术语（DCMM重点管理）
1. 报价单  
   - 定义：包含服务明细和价格的正式文档  
   - 归属过程：客户洽谈→报价生成  
   - 数据字段：报价ID、有效期、版本号

## 扩展术语（可选管理）
2. 纪念日标签  
   - 定义：用于客户关怀的日期标记  
   - 归属过程：客户维护→生日提醒  
   - 备注：仅CRM系统使用

## 异常术语
3. 合同作废原因代码  
   - 定义：标识合同终止原因的编码  
   - 值域：01-客户取消,02-资质不符...

5. 特别注意事项

1. 避免术语泛滥：
   • 非关键活动的术语不超过总术语量的20%（帕累托原则）
2. 动态维护机制：
   • 每季度评审一次，将高频使用的辅助术语升级为核心术语（如"客户健康度"可能从扩展术语升级）
3. DCMM适配建议：
   • 核心术语对应数据标准能力域
   • 异常术语对应数据质量中的"问题数据管理"

执行建议

1. 先用矩阵表梳理关键活动+核心术语，确保主干流程完整
2. 再通过用户访谈补充非关键活动术语（重点问："您平时还会用到哪些特殊说法？"）
3. 最后用术语类型标签（核心/扩展/异常）进行分层管理

分层术语业务过程模板，包含 核心业务过程、关键活动、分层术语定义 及 DCMM映射，支持直接填充使用：

分层术语业务过程模板

1. 业务过程概览

2. 分层术语结构（以BP-002为例）

### **业务过程：客户洽谈与需求分析 (BP-002)**
#### **关键活动与术语映射**
| **关键活动**       | **核心术语**                          | **扩展术语**                  | **异常术语**                |
|--------------------|---------------------------------------|-------------------------------|-----------------------------|
| 标记关键联系人     | - 关键联系人<br>- 决策人标签          | - 部门影响力评分              | - 无效联系人标记            |
| 生成报价单         | - 报价单<br>- 服务套餐                | - 临时折扣码                  | - 报价作废原因              |
| 记录客户需求       | - 需求分类（专利/软著/财税）          | - 客户偏好记录                | - 需求冲突说明              |

#### **术语分层定义**
##### **核心术语**（必须管理）
1. **关键联系人**  
   - 定义：对业务决策有直接影响的客户方人员  
   - 数据字段：姓名、职位、联系方式、决策权重  
   - DCMM映射：数据标准 > 业务术语  

2. **报价单**  
   - 定义：列明服务内容与价格的正式文档  
   - 数据字段：报价ID、有效期、版本号、关联合同  
   - DCMM映射：数据质量 > 数据规范性  

##### **扩展术语**（可选管理）
1. **部门影响力评分**  
   - 定义：量化联系人在其组织内的影响力（1-5分）  
   - 使用场景：销售优先级排序  
   - 维护要求：每季度更新  

##### **异常术语**（需记录）
1. **报价作废原因**  
   - 定义：标识报价无效的原因分类  
   - 值域：01-客户取消, 02-超期未确认, 03-条款冲突  
   - 处理流程：需关联审批记录  

3. 全流程关联视图

4. 模板使用说明

1. 核心术语
   • 必须纳入企业数据字典，严格定义字段和规则
   • 示例：报价单需关联财务系统的价格校验规则
2. 扩展术语
   • 记录在独立附录中，标注适用场景
   • 示例：部门影响力评分仅销售团队使用
3. 异常术语
   • 与问题管理流程联动，保留处理痕迹
   • 示例：报价作废原因需匹配CRM系统的状态变更记录

5. DCMM能力域适配

交付物建议

1. 主文档：业务过程矩阵（含分层术语）
2. 附录：
   • 核心术语数据字典（Excel/专业工具）
   • 扩展术语使用指南（Markdown文档）
3. 可视化：
   • 术语血缘图（展示术语与活动/系统的关系）

如果需要，我可提供：

1. 该模板的Excel/Word可编辑版本
2. 某具体业务过程（如合同管理）的完整填充示例
3. 与DCMM等级评估的映射关系表

归类划分

在数据管理领域（特别是DCMM框架下），"合同变更"的归类需要根据具体使用场景和定义粒度来确定。以下是专业视角的清晰划分

1. 分层归类逻辑

2. DCMM中的推荐处理方式

（1）作为业务过程的条件

• 当需要描述包含多个步骤的完整流程时：

注册示例：

INSERT INTO 业务过程表 VALUES (
  'proc_ct_change', 
  '合同变更流程', 
  '合同执行期间条款修改的完整审批流程'
);

（2）作为关键活动的条件

• 当作为更大流程的一个环节时：

元数据关联：

UPDATE 业务过程表 
SET sub_activities = JSON_ARRAY('创建','执行','变更','终止')
WHERE process_id = 'proc_contract';

（3）作为业务术语的条件

• 当需要定义数据含义时：

INSERT INTO 业务术语表 VALUES (
  'term_ct_change',
  'proc_contract',
  '合同变更',
  '合同条款的正式修改行为，需记录变更前后状态',
  '必须包含变更审批单号',
  '变更记录完整性≥99.9%',
  NULL
);

3. 实际应用中的混合模式

场景：采购合同管理系统

4. 决策树：如何正确归类

关键结论

1. 三者可共存："合同变更"可以同时以不同形式存在于元模型中：
   • 作为过程（流程视角）
   • 作为活动（操作视角）
   • 作为术语（数据视角）
2. DCMM最佳实践建议：
   • 在业务元模型中注册为过程/活动
   • 在业务术语表中定义数据语义
   • 通过process_id字段建立术语与过程的关联

合同变更既出现在业务过程清单中，又出现在业务术语表中，这是两个不同维度的定义，但确实存在关联。这种现象是合理的，原因如下：

1. 两者的定位不同

• 业务过程清单中的合同变更：
  描述的是一个动态的活动（What to do），即“如何执行合同变更”（输入、输出、角色）。
  例如：输入是变更申请，输出是修改后的合同，参与角色包括销售、法务等。
• 业务术语表中的合同变更：
  定义的是一个静态的概念（What it is），即“合同变更是什么”（数据类型、业务含义）。
  例如：它是“对原合同条款的修改”，数据类型是“变更记录（日志）”。

2. 实际业务中的必要性

• 过程需要术语支撑：
  任何业务流程（如合同变更）都需要明确的术语定义，否则不同角色可能对“合同变更”的理解不一致（例如：是否包含口头变更？是否需要审批？）。
  术语表的作用是统一语言，避免歧义。
• 术语需要过程落地：
  光有定义不够，必须通过具体流程（如提交申请→审批→存档）实现术语的实操。
  过程清单的作用是明确执行规则。

3. 类比说明

就像“采购订单”既是一个业务术语（定义：记录采购需求的单据），也是一个业务流程（从创建到审批的步骤），二者互为补充：

4. 如何避免混淆？

如果觉得重复，可以调整呈现方式，例如：

• 在术语表中增加“关联过程”字段：

| 合同变更 | 对原合同的修改 | 合同变更流程 | 变更记录 |

在过程清单中引用术语：

| 合同变更 | 变更申请 | 修改后的合同 | 参见术语表“合同变更” |

总结

这种现象是业务分析与数据建模中的常见设计，目的是：

1. 术语表确保所有人对“合同变更”的理解一致；
2. 过程清单确保所有人知道“如何操作合同变更”。
   二者结合，才能实现业务标准化（DCMM的核心目标之一）。