上一篇《本体建模前的业务调研：如何把模糊需求变成清晰业务场景》讨论了如何从真实任务中发现业务摩擦，筛选值得建模的场景，并通过价值叙事和边界定义形成场景定义卡初稿。

但场景清楚，并不代表已经可以直接打开本体工具。

“帮助客户经理及时识别订单履约风险”仍然只是一项目标。它还没有完整说明：

• 当前判断的是订单、合同，还是一项风险任务；
• 哪个事件触发检查，哪个过程改变哪个对象的状态；
• 交付日期、延期审批和交付记录之间是什么关系；
• 哪些条件构成风险，证据冲突时如何处理；
• AI、规则引擎、业务人员分别做什么；
• 什么样的结果才算模型通过业务验证。

这正是业务调研与本体建模之间最容易断裂的地方。

调研结果不能直接翻译成类、属性和关系。中间还需要一层经过业务确认的业务模型，把真实案例中的对象、过程、状态、规则、证据和行为组织起来。

概念说明： 本文所说的“业务模型”，不是讨论企业如何盈利、服务哪些客户的商业模式，而是对业务对象、关系、事件、过程、状态、规则、证据和行为的结构化表达。

本文继续沿用订单履约风险案例，具体说明如何完成这层转换。

场景定义卡还不是业务模型

场景定义卡解决的是价值和边界问题，业务模型解决的是业务如何运行的问题。

如果跳过业务模型，技术团队只能根据自然语言自行推断。最终很容易把数据库表当成业务对象，把流程节点当成对象状态，把模型输出当成确定事实，或者把一个 API 调用误认为完整业务行为。

因此，从场景定义进入本体建模之前，还要完成一次结构化业务建模。

第一步，从真实案例中抽取九类业务要素

前面的“本体驱动的数据治理”系列曾把业务建模归纳为对象、过程、状态、规则、数据来源和 Agent 辅助机会点六类要素。为了便于具体场景的建模、交付和验收，本文把其中容易混在一起的内容进一步展开为九类。

九类要素不是另起一套体系：业务对象被展开为对象与关系，业务过程被展开为事件与过程，数据来源被深化为证据与依据，Agent 辅助机会点被落实为角色权限与业务行为，状态和规则则继续保留。

这九类要素是一套面向场景落地的操作框架，不是新的通用本体标准。实际项目可以根据复杂度合并或扩展，但对象身份、状态归属、规则适用范围、证据来源和责任边界不能因此被省略。

这里还要特别区分业务过程、业务行为和工程动作。业务过程描述多个活动如何共同推动业务结果；业务行为是过程中的一个可明确分配给角色或系统、具有输入、输出和业务效果的执行单元；工程动作则是业务行为进入运行系统后形成的 API、MCP 工具或动作契约。一个过程可以包含多个业务行为，一个业务行为也可能由多个工程动作协同实现，三者不能直接画等号。

这九类内容不是让业务人员直接填写一张术语表。建模人员应该围绕真实案例持续追问，再把答案整理成结构，让业务人员根据模型确认和修正。

第二步，先识别业务对象，再确认对象关系

业务对象不是数据库表，也不是材料中出现的所有名词。

判断一个概念是否值得作为当前场景中的业务对象，可以连续追问：

• 它是否具有可以识别的业务身份；
• 它是否在一段时间内持续存在；
• 它是否拥有属性、状态或生命周期；
• 业务是否会围绕它作出判断或执行动作；
• 它是否需要被单独追踪、授权或审计。

例如，“风险”可能只是一种判断结果，而“风险任务”则具有创建时间、当前状态、责任人、证据清单和处理结果，更适合作为需要管理的业务对象。

对象识别后，还要确认关系的业务含义。

“合同关联订单”仍然不够。至少还要说明：

• 是哪一份合同版本约束哪一个订单；
• 关系从什么时间开始生效；
• 延期审批是否改变原关系中的交付约定；
• 关系由哪个系统、文档或人工确认支撑；
• 关系失效或冲突时如何处理。

本体中的关系不是为了把对象连成一张图，而是为了支撑当前场景中的判断、查询和约束。

第三步，分清事件、过程和状态

事件、过程和状态经常在需求文档中混在一起。

• 事件 表示某件事在某个时间发生，例如“到达每日检查时间”或“延期审批生效”；
• 过程 表示系统或人员为了产生变化而执行的活动，例如“校验履约风险”或“确认延期例外”；
• 状态 表示某个对象在一段时间内所处的情形，例如订单“待履约”、风险任务“待确认”。

它们之间的基本关系是：

事件触发过程，过程读取或改变对象，对象进入新的状态。

订单履约场景可以拆成：

状态必须属于明确对象，不能把多个对象的状态混成一条流程线。

更准确的表达是：

• 订单状态： 待履约 → 已交付／已取消；
• 风险任务状态： 待生成 → 待确认 → 已预警／已排除／待人工复核。

订单仍然处于“待履约”时，风险任务完全可以已经进入“待确认”。如果不区分状态所属对象，后续规则、字段映射和动作接口都会产生歧义。

第四步，把价值、规则和行为分别定义

价值、规则和行为相互衔接，但回答的是三个不同问题。

价值叙事已经在场景调研阶段形成，进入业务建模后，要重点把规则和行为展开。

业务规则怎么定义

业务规则公式

当【适用对象】处于【业务状态】，并且【触发条件】成立时，应作出【业务判断】或施加【业务约束】；如果存在【例外条件】，则转入【例外处理】，并由【责任角色】进行【确认、审批或处置】。

一条完整规则至少包括：

适用范围 → 前置状态 → 触发条件 → 判断或约束 → 例外处理 → 责任主体 → 依据与留痕

例如：

当订单处于“待履约”状态，当前日期晚于当前有效交付日期至少 3 个工作日，且没有有效交付记录时，应识别为履约逾期风险。当前有效交付日期应优先采用已批准且适用于该订单的延期日期；如果原合同与延期材料冲突，或者延期的适用性无法确认，则不直接形成预警，转由客户经理复核并记录判断依据。

规则不能只写成“逾期就预警”。至少还要说清适用于什么订单、使用哪个合同版本、如何计算工作日、延期何时生效、证据缺失或冲突时怎么办，以及由谁确认例外。

业务行为怎么定义

业务行为公式

由【执行角色或系统】针对【业务对象】，在【触发时机】使用【所需数据和规则】执行【具体动作】，产生【输出结果】，并在需要时创建【结果对象】或推动【业务对象】从【当前状态】转变为【目标状态】；涉及【风险或权限边界】时，必须经过【人工确认或审批】，并记录【执行结果和证据】。

一个完整行为至少包括：

执行主体 → 操作对象 → 触发时机 → 输入数据与规则 → 执行动作 → 输出结果 → 对象创建或状态变化 → 权限与人工确认 → 审计留痕

有些业务行为只读取信息或生成结果，并不改变原有对象的状态。此时应明确它创建或输出了什么，不能为了套用模板而虚构状态变化。

订单履约场景可以这样定义：

由风险识别服务针对“待履约”订单，在每日履约检查时读取订单记录和交付日志，引用 AI 从有效合同及延期审批材料中提取并经过校验的交付约定，执行确定性逾期规则，生成风险提示和证据清单，将风险任务标记为“待确认”；客户经理确认后，任务才能转为“已预警”或“已排除”，证据不足或互相冲突时进入“待人工复核”，全程保留数据来源、规则版本和确认记录。

需要快速汇报或跨团队对齐时，可以把三者组合成一段场景主定义：

为了帮助【角色】，在【业务场景】中，把【当前工作方式】转变为【目标工作方式】，并将【指标】从【基线】改善到【目标值】。当【对象状态及触发条件】成立时，依据【规则及来源】作出【业务判断】；由【执行主体】使用【数据和能力】执行【动作】，产生【结果】并推动【业务对象】进入【新状态】。若出现【例外、风险或权限条件】，则由【责任角色】确认或审批，并保留【数据来源、规则版本和执行记录】。

这段组合定义用于抓住场景主线，不能替代详细的对象模型、规则例外、证据清单和验证样例。

其中，“当前工作方式”和“目标工作方式”描述业务价值变化；“对象状态”和“新状态”必须归属于明确的业务对象，两者不能混用。

第五步，明确数据来源如何成为业务证据

“数据来自订单系统”只说明去哪里取数，还没有说明数据能够证明什么。

业务模型至少要建立下面这层关系：

证据还要区分几个层次：

• 权威源数据与经过加工的派生数据；
• 可直接观测的源数据事实、规则计算形成的派生结论、经授权人员作出的业务认定与模型生成的候选结论；
• 当前有效证据与已经失效的历史记录；
• 能够直接证明事实的主证据与只提供参考的辅助证据。

AI 提取结果可以作为候选事实、候选断言或证据线索，但其本身通常不是原始证据。模型需要保留对应合同段落、文档版本、日志或记录位置等来源引用，不能因为模型表达得很确定，就自动变成确定性业务事实。是否需要规则校验或人工确认，也要在模型中明确。

第六步，把自然语言转成可确认的符号化模型

自然语言需求说明是必要的，但它很容易隐藏歧义。

例如，“审批完成后进入处理”至少存在三个问题：哪个审批对象完成、什么结果算完成、哪个对象进入什么状态。仅靠增加文字，往往不能真正消除不同角色的理解差异。

更好的方式，是把前面识别出的九类业务要素转化为可视化、符号化的业务模型。至少应表达四个视图：

• 场景边界视图： 角色、触发事件、起点、终点和排除范围；
• 对象关系视图： 核心对象、对象关系及其适用范围；
• 过程状态视图： 事件如何触发过程，过程如何改变不同对象的状态；
• 规则行为视图： 规则、例外、证据、执行动作和人工确认点。

可以使用 OPM、BPMN、事件风暴、领域模型或其他适合团队的方法。OPM 的优势是可以在同一套表达中呈现对象、过程和状态变化，比较适合承接后续本体建模；BPMN 更擅长表达流程、角色和分支；领域模型适合澄清对象和关系。

关键不在于工具名称，而在于业务人员能否看懂、指出错误并确认模型。

也不应该要求业务专家先掌握 RDF、OWL 或其他本体标准。更合理的分工是：

业务专家提供真实案例、规则依据和异常经验，建模人员将其转化为符号模型，业务专家再根据模型确认和修正。

这一步形成的是业务模型，不是直接生成最终本体：

真实案例 → 场景定义卡 → 符号化业务模型 ↔ 业务确认 → 能力问题与边界样例验证 → 业务模型基线 → 本体语义模型

第七步，用业务问题和边界样例验证模型

业务人员说“看起来没问题”，不等于模型已经可以进入下一阶段。还要用问题和样例检验它是否真的支撑业务判断。

先提出这个场景必须回答的业务问题：

• 今天有哪些订单进入待确认风险，为什么；
• 每个风险结论依赖哪个合同版本、交付记录和延期审批；
• 延期信息缺失、失效或互相冲突时应该如何处理；
• 谁可以确认、排除或升级风险，哪些动作不能自动执行；
• 规则、数据或合同版本变化后，哪些结论需要重新计算。

进入本体建模前，应把这些业务问题进一步整理为可参数化的能力问题（Competency Questions），并建立能力问题到模型要素、真实证据、适用规则、预期结果和验证状态的追踪关系。

再准备至少五类真实样例：

验证时不能只看正常流程。异常和边界样例更容易暴露对象混淆、状态错误、规则缺口、证据不足和权限越界。

一次模型共创应该如何组织

业务模型不能由建模人员关起门来完成，也不能在一次会议上边听边定稿。

更稳妥的方式是：

1. 建模人员根据场景卡和真实案例形成第一版对象、过程、状态、规则和证据模型；
2. 业务人员检查流程、对象边界、规则和例外是否符合真实工作；
3. 数据与系统人员确认关键事实是否存在可用证据，但不直接用表结构替代业务模型；
4. 风控或合规人员确认规则依据、权限、人工接管和高风险动作边界；
5. AI 与工程人员确认模型输出是否能够被实现、测试和审计；
6. 团队用正常、异常和冲突案例共同走查，形成版本基线和待决事项。

每次评审都应区分已确认事实、暂定假设和未解决问题。没有事实证据或正式规则依据的内容，不能因为画进模型，就自动成为已确认的业务事实或业务规则。

业务模型最终要交付什么

一套可以进入本体建模的业务成果，至少包括：

• 场景边界和价值叙事；
• 核心业务对象及其关系；
• 事件、过程、状态及合法变化；
• 业务规则、适用范围、依据、例外和责任主体；
• 业务行为、输入输出和权限边界；
• 业务事实与数据证据映射候选清单；
• 符号化业务模型及版本记录；
• 能力问题到模型要素、证据、规则、边界样例、预期结果和验证状态的追踪矩阵；
• 未决问题、阻断级别、责任人和确认计划。

交付物齐全不等于已经可以发布正式基线。进入本体建模前，未决事项还要区分阻断项和非阻断项：如果核心对象身份无法确认、状态归属仍有争议、关键规则没有权威依据、核心证据不可获得，或者高风险行为的责任与权限尚未明确，可以继续制作探索性模型，但不能把暂定内容固化为正式本体语义基线。

这些成果进入本体驱动的数据治理后，可以继续转化：

这里要保持三个边界：

• 识别业务对象，不直接把它等同于数据库表；
• 确认业务逻辑，不急着把所有内容写成 OWL、规则代码或 Prompt；
• 说明“什么证据证明什么事实”，再进入具体字段和数据血缘映射。

小结

业务调研结果不能直接翻译成本体模型。中间需要一层可被业务确认、被数据验证、被工程实现的业务模型。

更完整的路径是：从真实案例中提取对象、关系、事件、过程、状态、规则、角色、证据和行为，分别定义价值、规则和业务行为，通过符号化模型消除自然语言歧义，再使用能力问题和边界样例验证模型，形成可交付给本体工程的业务模型基线。

通过这七步形成并验证的业务模型，不是本体本身，而是本体工程的输入基线。下一阶段，团队可以把经过确认的对象、关系、事件、过程、状态、规则、证据和行为进一步形式化为可计算、可查询、可约束的语义资产，并继续完成数据映射、服务发布和运行治理。

可进入本体建模的业务模型，不是画出了一张完整的图，而是关键业务问题能够被回答，规则和状态能够被验证，结论能够追溯到证据，动作能够找到明确的责任与边界。