Concept Modelling（概念建模）：业务分析师的“认知地图”

梳理复杂概念，建立清晰理解框架。

做需求分析的时候，有时候你会发现，每个人都在说“客户”“产品”“订单”……但他们的“客户”不一定是你的“客户”，他们的“产品”也未必包含你认为的“产品”。

这时候，Concept Modelling 就是我们的“认知地图”——用一张图，搞清楚大家脑子里的“关键概念”到底长什么样，互相之间是什么关系。

它是我在项目初期必用的工具之一。无论是梳理业务词汇、搭建数据模型、制定规则边界，还是对齐干系人的共识，Concept Modelling 都能帮我避开“词不达意”的陷阱。

---

什么是 Concept Modelling？

它不是流程图，不是数据表，而是：

• 从概念的角度出发，定义项目中关键的业务术语和它们之间的关系
• 把“说不清的东西”画清楚，让大家看到彼此认知里的差异
• 用结构化语言对齐认知，让讨论真正落地在“一个语境里”

换句话说： 它不是“做图”，是“统一语言”。更准确地说，是构建一套用于表达业务知识的“自然语言语义模型”。

---

常用的 Concept Modelling方法

在 Concept Modelling 中，我们的目标是构建一个清晰、连贯、可追溯的业务语义网络。这一过程通常从术语的规范化开始，逐步扩展为结构化的语义体系。主要包括以下几个关键构件和建模方法：

1. 术语表（Glossary）——语义建模的基础

提供每个核心业务术语的标准定义，确保沟通中不存在“同词不同义”或“同义不同词”的歧义。Glossary 是 Concept Modelling 的第一步，也是其他建模工作的基础，它回答了：“我们在讨论哪些关键概念？这些词分别是什么意思？”

2. 概念实体图（Conceptual Entity Diagram）——定义核心概念之间的结构关系

在术语表的基础上，明确核心“名词概念”（如客户、订单、渠道）之间的“动词关系”（如“一个客户可以拥有多个订单”），用于构建语义的主干框架。

3. 分层模型（Hierarchical Concepts）——组织上下级/泛化关系

将术语表中的概念进一步归类，构建主从或类别结构（如“客户”下可细分为“个人客户”与“企业客户”），用于表达概念之间的继承、分类、泛化等层级关系。

4. 关系图谱（Concept Map）——捕捉复杂、多维的语义关系

以可视化方式呈现概念之间更复杂的语义联结，包括“包含、依赖、等价、角色、组成”等非结构性或多对多的关系，帮助建立整体认知的全景视图。

小贴士：

Glossary 通常是 Concept Modelling 的起点，但两者并不等同。Glossary 是“名词”的标准化；而 Concept Modelling 是“这些名词之间语义结构”的整体构建。换句话说，Glossary 是语义的词汇表，而 Concept Modelling 是语义的认知地图。

这些模型共同组成业务系统的“概念蓝图”，为后续的流程设计、数据建模、规则定义等工作提供语言统一、逻辑清晰的基础。相比传统数据模型，Concept Modelling 更注重定义的独立性、语言的可读性与业务语义的完整性。

---

我的 Concept Modelling 实施流程

• 识别关键概念（名词概念）

  从访谈、文档、现有系统中提取“频繁出现但定义不清”的词汇。

• 澄清定义与边界

  对每一个概念提问：“它指的到底是什么？包含哪些？不包含什么？”

  确保它是清晰、无歧义、与技术实现无关的定义。

• 建立动词概念与其他语义关系

  梳理各概念之间的“动词连接”——例如“客户拥有订单”、“保单属于保险产品”

  并补充分类、组成、角色等非动词关系，为丰富语义做准备。

• 绘图可视化

  用清晰、通俗的结构画出来，一目了然（不是技术图，不是ERD）

  目的在于支持自然语言的陈述与规则表达。

• 对齐干系人

  带着图去讨论，确认“我们说的是同一件事”——通过一张图建立共同语境。

---

一个真实案例

我曾负责一个保险系统的理赔流程优化项目。初期会议上大家频繁提到“客户”“保单”“事故”“报案”，但每个部门理解完全不同。

比如：

• 市场部说的“客户”是潜在用户，已经填过问卷的也算
• 核保部说的“客户”是有有效保单的人
• 理赔部说的“客户”是报过案的被保险人

如果不澄清这些差异，流程怎么画都是错的。

我花两天时间整理了一张 Concept Map：

• 定义了“客户”“被保险人”“投保人”“受益人”等概念的边界
• 梳理了“保单”与“客户”“产品”的从属关系
• 标明了“事故”与“报案”之间的逻辑顺序和关联字段

这张图成为整个系统重构的“概念基线”。不仅让流程设计顺利进行，连后期的数据建模也大幅减少歧义。

---

Concept Modelling 的价值

• 消除“语言陷阱”：统一关键术语的定义，避免多义词引发误解；
• 提高系统建模效率：为数据建模和功能设计打下清晰概念基础；
• 拉齐干系人共识：不同部门通过同一张图建立“语义对齐”；
• 支持规则与流程设计：每一个业务规则，都必须基于明确的概念基础；
• 为后期测试和培训提供标准话术与用语规范；
• 应对监管与合规挑战：为需要精确表达、审计清晰的场景提供语言基础。

---

我的经验建议

• “词”比“图”重要：关键不是画得多花哨，而是定义要具体、清晰、可验证；
• 保持抽象层次一致：不要把“产品分类”跟“价格规则”混在一张图里；
• 每个概念都要问三个问题：它是什么？它不是什么？它和谁有关？
• 术语表是强制标配：每个关键概念都要有书面定义，项目交付必须包含；
• 尽早介入，持续更新：越早开始建模，越能避免后期大量返工；
• 动词概念不可忽略：名词之间的关系才是结构的核心，动词定义不清，规则就无法落地；
• 支持自然语言表达：所有建模成果最终都应能支撑业务人员自然语言的准确表达。

---

最后的共勉

我们 BA，不只是流程工程师，更是认知翻译师。

Concept Modelling 不是写术语，而是建立项目共识的“语义地图”。

只有当我们说的“客户”真的是“同一个客户”，一个系统才可能被共同构建出来。