业务怎么看、流程怎么串、账怎么算、战略怎么做，这四个问题的答案都要落在同一批数据上。 数据的定义与口径不统一时，四个环节各自得出的结论无法相互引用—— 同一项指标可以得出不同的数值，同一台设备的归属可以出现不同解释。
本专题的位置在此：前四个主题解决的是业务层面的方法论，数据模型解决的是这些方法论共同依赖的基准。 基准不统一时，前面各环节投入的工作量越大，最终被口径分歧消解的比例越高。
需要先明确统一的对象。统一的是定义与口径，并非把所有资产并入同一张表。 资产分为哪些类、每一类使用哪一张卡片、每个字段由哪一个系统提供权威值，这些规则确定之后， 通用卡片与专项卡片的分工随之明确，资产的描述方式在各系统之间保持一致。
相当数量的企业已经做过数据统一的工作，其做法是把财务的资产台账、设备部的维护台账与生产部的使用台账 合并成一张汇总表。这张表在逻辑上合并了三个系统的数据，但问题并未解决—— 三个台账的数据口径仍然不一致。
数据模型并非数据表格。它是三样内容的集合：
| 组成部分 | 定义 | 示例 |
|---|---|---|
| 数据结构 | 核心业务对象有哪些，每个对象包含哪些字段，每个字段的数据类型与取值范围是什么 | 资产卡片的「使用部门」字段由组织架构下拉选择，不允许自由文本 |
| 业务关系 | 对象之间如何关联：一对一、一对多或多对一 | 固定资产与采购合同为一对一，与维修工单为一对多，与使用部门为多对一 |
| 业务规则 | 在数据层面固化的管理逻辑，由系统按规则执行，而非由人工按制度执行 | 维修费用超过原值 20% 时自动触发资本化判定流程 |
三者缺一，模型即不成立。
数据结构回答的第一个问题是核心业务对象有哪些。在固定资产管理中，核心业务对象至少包括： 资产卡片、采购合同、维修工单、调拨单、处置单与盘点单。
第二个问题是每个对象包含哪些字段，以及每个字段的数据类型与取值范围。字段的标准化并不只是命名统一， 更关键的是取值受约束：资产卡片的「使用部门」字段不能是自由文本，必须从组织架构中下拉选择。
取值范围的约束同样体现在状态字段上。「资产状态」的取值只能是「在用／闲置／维修／报废」四个值之一， 不允许出现「使用中」「停用」「已处置」等非标准表述。取值集合受限之后，按状态汇总与筛选才可能在各系统之间得到一致的结果。
业务关系回答的是对象之间如何关联。固定资产与采购合同为一对一（一台设备对应一份合同）， 与维修工单为一对多（一台设备对应多张工单），与使用部门为多对一（多台设备对应一个部门）。
这三类关系在数据模型层面被明确定义后，系统之间的引用不再依赖人工推断。 若关系未定义，判断「这项资产编码对应的是哪个部门的哪份合同」只能由人工完成， 判断结果无法追溯，也无法在不同系统之间复用。
关系定义的另一处作用体现在汇总与穿透上：分类树的多级汇总与按合同追溯设备清单， 均以对象关系为依据。
业务规则是把管理逻辑写进数据模型，使其在数据层面生效，而不是写在制度文件中依靠人工执行。 两者的差别在于一致性：写入模型的规则，无论由谁触发、经由哪个入口触发，结果相同。
以固定资产管理中的两条规则为例。其一，维修费用超过原值 20% 时，自动触发资本化判定流程—— 判定条件与触发时点由系统确定，不依赖财务人员对单据的逐笔判断。 其二，资产调拨审批通过后，使用部门字段自动更新，折旧分摊部门随之同步调整—— 调拨单的状态变更直接驱动财务侧的归属变更，中间不设人工同步环节。
这一处理方式与财务规则统一专题所讨论的问题同源：同一台设备在不同工厂算出不同成本， 其成因通常并非会计人员的判断不一致，而是判定规则没有落在数据层面—— 每次判定都由人工重新执行一遍，口径因此随时间漂移。
数据结构、业务关系与业务规则三项之间是递进依赖的关系：字段定义使记录可读，关系定义使记录可关联， 规则定义使关联可驱动业务动作。只有字段定义时，跨表的汇总仍需人工拼接；补上关系定义之后， 汇总可由系统完成，但业务动作仍须由人工发起——调拨完成后，折旧分摊部门的变更仍需有人在财务系统中修改； 再补上规则定义，业务动作才会自动驱动相关的数据变更。
判断企业是否需要统一的数据模型，可以对照下列五类现象。 五类的共同特征是：每一类都可以被解释为人为失误，而实际成因均在数据模型。
| 序 | 现象 | 实际成因 |
|---|---|---|
| 一 | 同一台设备，财务台账与设备部台账的数量对不上 | 两个系统的统计口径不同：一方按发票金额 ≥ 5000 元认定固定资产，另一方按使用年限 ≥ 1 年认定 |
| 二 | 编制一份全生命周期成本分析，需人工从三个系统拼数据 | 数据未在同一模型内沉淀，拼完之后仍需讨论口径是否正确 |
| 三 | 资产调拨之后，财务侧的折旧仍按原部门计提 | 调拨单的状态变更未同步到财务系统，业务动作与会计归属之间缺少规则连接 |
| 四 | 管理层询问近三个月的资产利用率，不同部门给出两个数 | 计算方法不同，且指标没有唯一的官方定义 |
| 五 | 系统上线一年多之后，数据准确度持续下降 | 缺少数据治理机制，不符合口径的数据进入系统后无人清理 |
五类现象的成因各不相同，指向的结论是同一处：问题出在数据的定义与规则上， 而非某一位经办人的认真程度。五类之中命中两项以上者，所需并非更换新的系统，而是统一的数据模型。
「共同体系」是一个管理概念：全公司的业务活动基于同一套数据语言运行， 部门之间不再因为口径不一致而争论。数据模型是该体系的技术实现。
若把共同体系比作一栋房子，数据模型就是房子的钢筋骨架。骨架搭对之后，墙面、门窗与管线才能有序安装； 骨架不正，墙面再美观也不解决问题。
落到具体字段上，数据模型解决的是使所有人在同一个基准上对话的问题： 财务所称的「原值」与采购所称的「采购价」被定义为同一个字段，口径一致； 设备部所称的「利用率」有了官方定义，各系统按该定义计算，不允许多个口径并存； 资本化判定规则已在模型中固化，由谁执行结果相同。
统一数据模型并非把台账合并成一张表，而是把定义、关系与规则固定下来。
台账合并处理的是存量数据；定义、关系与规则处理的是数据的产生方式。
前者需要反复执行，后者建立之后长期有效。
资产编码、卡片字段与业务规则应在系统实施之前确定， 并在实施过程中作为验收对象逐项核对。若贵方正处于选型阶段， 可基于贵方现有资产分类做一次口径对照。