建设业务本体时，企业很容易先整理字段、指标和规则，却忽略一个更基础的问题：这些信息究竟在描述谁？
业务人员真正关心的通常不是某张表，而是一个具体对象：这位客户最近是否减少采购，这款商品在哪些门店出现积压，这笔订单为什么还没有交付。只有先确定客户、商品、订单等业务对象，分散的数据才可能围绕同一件事被理解、关联和使用。
**表记录数据，业务则围绕对象发生。** 这也是建设业务本体时，需要先从“对象”开始的原因。
对象不是一个字段，也不只是一行记录
以一款商品为例。商品主数据保存名称、编码和品类，库存系统记录各门店的库存数量，销售系统记录销量，活动系统记录促销信息，售后系统还可能保存退货原因。
这些记录分布在不同系统和数据表中，却都在描述同一个业务对象。只查看其中一张表，能够回答的问题十分有限；把它们围绕商品组织起来，企业才能进一步判断库存是否合理、销量为什么变化，以及后续应该采取什么行动。
因此，本体中的对象不是某个字段名，也不是任意一行数据。它表示企业需要持续认识和管理的一类业务事物，以及其中可以被明确识别的具体实例。
• “商品”是一类对象，某个具体编码的商品是一个实例；
• “客户”是一类对象，某家与企业持续交易的公司是一个实例；
• “订单”是一类对象，某笔具有明确订单号和来源的交易记录是一个实例。
只有区分类与实例，系统才能既理解一类业务对象的共同结构，也能准确定位需要分析和处理的具体事项。
确定对象，首先要回答“它到底是谁”
一个对象要被系统持续使用，首先需要拥有稳定的识别方式。
同样叫“经典咖啡”的商品，可能存在不同容量、包装或规格。如果只按名称统计，它们很容易被错误合并；如果不同系统采用不同编码，同一商品也可能被识别为多个对象。
因此，定义对象不能只给出名称，还要说明通过什么信息确认其身份。商品可能依靠统一编码和规格识别，客户可能需要关联统一客户编号及主体信息，订单则需要明确订单号、来源和版本。
**对象识别是否稳定，直接影响后续关系能否连对、指标能否算准。** 如果对象没有识别清楚，即使销量、库存和订单都能被查询，也可能被归到错误的对象上。
在跨系统场景中，还需要进一步处理同一对象的多种标识。例如，同一个客户可能在销售、财务和服务系统中拥有不同编号。企业需要明确这些编号之间的对应关系，并说明哪个标识承担统一识别作用，避免把同一客户拆分计算或把不同客户错误合并。
对象需要带着属性、关系和状态被理解
确认“它是谁”以后，还要继续说明“它是什么样”“与谁有关”以及“现在处于什么状态”。
一笔订单可以包含金额、下单时间和约定交期等属性；它与客户、商品、合同和门店存在关系；随着业务推进，还可能经历待确认、已审批、已发货和已完成等状态。
属性描述对象本身
属性用于记录对象相对稳定或可以直接观察的特征。例如，客户所属行业、商品规格、订单金额和设备型号，都可以帮助系统形成对对象的基础描述。
关系把对象放回业务网络
客户发起订单，订单包含商品，订单又可能对应合同。关系让单独存在的对象形成业务链路，也让系统可以沿着这些链路寻找分析和判断所需的依据。
状态说明对象当前发生了什么
业务对象会随时间发生变化。订单从待确认进入已审批，设备从正常运行转为异常，合同从待生效转为有效。状态不仅需要记录当前结果，还要说明状态变化的时间和依据。
**业务判断并不是针对抽象数据作出的，而是针对某个对象在特定关系和状态下作出的。** 如果只保留“订单金额”和“交付天数”两个数字，却不知道它们属于哪笔订单、对应哪个客户，也不知道订单是否发生过变更，这些数字就很难支持具体决策。
不是所有名词都需要建成对象
业务本体并不是把企业中出现过的每个名词都收录进来。对象过多会增加识别、维护和关系管理成本，反而让模型失去重点。
判断一个概念是否适合建成对象，可以结合以下问题：
• 它是否需要被单独识别；
• 企业是否需要持续观察和管理它；
• 它是否具有自己的属性和状态；
• 它是否会与其他对象建立稳定关系；
• 业务最终是否会围绕它进行分析、判断或采取行动。
例如，企业需要持续查看某个客户的交易变化，并由客户经理负责跟进，那么客户就是需要管理的对象。企业需要观察某台设备的运行指标，并在异常时生成工单，那么设备也适合作为对象。
反过来，一个只在单次计算中临时出现、没有独立身份，也不需要持续管理的中间结果，未必需要被建成对象。**对象范围越清楚，本体越容易维护，后续分析也越容易聚焦。**
从业务问题反向确定核心对象
企业不必先把所有系统中的对象一次性整理完成。更可行的方式，是从明确的业务问题出发，识别问题最终指向什么对象，再逐步补齐相关属性、关系和状态。
例如，企业希望分析订单交付异常，可以先确定订单、客户、商品和合同等核心对象，再梳理订单状态、约定交期、实际交付时间以及对象之间的关系。与当前问题没有直接关联的对象，可以在后续场景中逐步补充。
这种方式能够让本体建设与实际业务价值保持联系，也有助于验证对象定义是否足以支持查询、分析和行动。
让数据真正围绕业务对象工作
企业的数据通常按照系统、部门和表结构保存，而经营问题往往围绕客户、商品、订单、设备和项目展开。
业务本体从对象开始，就是先明确企业究竟在管理什么，再把分散的属性、关系、状态、指标和规则逐步连接到这些对象上。
当对象被清楚识别后，系统才有可能继续回答：眼前的数据属于谁，它与哪些业务事项相关，现在发生了什么，以及接下来应该关注哪个具体对象。
**对象是业务本体组织数据、指标、规则和行动的起点。** 对象定义得越清楚，后续关系越容易准确建立，经营判断也越容易落到真实、可处理的业务事项上。