数据中台这一名称容易被理解为一套独立的技术形态。就设备资产管理而言，它的职责限于三项： 采集、清洗、存储。三项职责的顺序固定，前一项的规则决定后一项的对象。
采集的接口决定清洗要处理哪些数据与哪些字段；清洗的口径决定进入存储的数据是否只有一套含义； 存储的索引方式决定上层能否按单台资产检索到完整记录。 三项职责中的任一项缺失，上层获得的都是看似完整、实际无法相加的数据。
需要说明的是，本层只负责把数据整理为可用的形态，不负责解释数据的含义。 解释数据含义的工作由分析引擎承担，此项分工是本专题六层划分的依据之一。
资产数据所涉及的业务系统通常不少于三个，各系统保存的资产数据如下：
| 系统 | 其中与资产相关的数据 |
|---|---|
| EAM 系统 | 设备台账、维修记录、保养计划 |
| 财务系统 | 折旧数据、费用归集、预算执行 |
| 采购系统 | 合同信息、供应商资料、价格数据 |
| 生产执行系统 部分企业建有 | 设备运行数据、产出数据 |
采集的动作是把上述系统中的数据按统一规则集中到一处。此处所指的采集有明确边界： 其内容是定义每一类数据需要哪些字段、在什么时间采集、以什么频率采集， 并非把各系统的数据库内容全部复制过来。字段的取舍决定汇聚之后的数据量，采集时点与频率则决定数据的时效。
按数据的性质与使用方式，采集分为三类接口。三类的分工并不相互替代： 触发类事件的价值随时间快速衰减，批量数据的变化周期较长，跨系统查询的需求则既不属于前者也不属于后者。
| 接口类型 | 适用的数据 | 采集时机与频率 |
|---|---|---|
| 实时接口 | 触发类事件：验收通过、调拨审批、工单关闭 | 事件发生后秒级同步至数据中台，不等月底批量抽取 |
| 定时接口 | 批量数据：折旧汇总、盘点结果、月度成本归集 | 每日一次或每周一次即可满足需要，无需实时同步 |
| 查询接口 | 按需查询的数据：某台设备的全生命周期数据 | 由调用方通过接口从中台调取，不直接访问 EAM 系统的数据库 |
三类接口中的第三类容易被忽略。财务系统需要查询某台设备的全生命周期数据时， 若直接读取 EAM 系统的数据库，两个系统之间就形成一条不受中台约束的直连； 经由中台的查询接口调取，取数口径才与本层保持一致。
采集进入中台的原始数据并不能直接使用——其质量取决于各源系统的录入方式与管理水平。 同一城市名称在不同系统中会写作「北京市」「北京」或「BJ」； 同一台资产在 EAM 系统中的编码为 VDL-850，在财务系统中的编码为 FIX-2019-0042。 两者若按字符串比对，同一台设备会被识别为两台。
| 工作 | 具体内容 | 完成后的状态 |
|---|---|---|
| 格式标准化 | 日期统一为 YYYY-MM-DD 格式；金额统一为两位小数；编码统一为大写字母与数字 | 同一字段在各系统中的取值形式一致，可逐字段比对 |
| 去重 | 同一台设备在多个系统中均有记录 | 以唯一来源系统的数据为准，删除其他系统中的冗余副本 |
| 口径对齐 | 业务系统的「原值」含运费与安装费，财务系统的「原值」只含购置价 | 在统一模型下只保留一个标准口径 |
口径对齐需要说明一处细节：两份原值数据都被保留，并分别标注「用于业务分析」与「用于财务核算」； 统一模型中的标准口径只有一个。保留两份数据的意义在于，业务分析所需的构成信息与财务核算所需的入账依据都不丢失， 而两者之间的换算关系由中台承担——换算规则一旦变更，只在中台调整一次，不需要各系统分别修改。
去重与口径对齐的处理顺序同样固定。先以唯一来源系统确定记录主体，再对其余字段做口径对齐； 若顺序颠倒，同一台设备的副本会先按统一口径被改写，其来源便无法追溯。
指标口径、报表清单与数据范围均可由演示环境实时导出，无需申请。 查看核验方式 →
清洗之后的数据存放在资产全生命周期数据仓库之中，不存放在一个独立的业务数据库里。 两者的差别在建库方式：数据仓库以资产编码为索引，把这台设备从采购到处置的全部数据串在一起。 资产编码由此成为跨系统唯一的关联键——各系统无论如何编号，数据进入本层后都归到同一个编码之下。
| 来源单证 | 归集到该资产的数据 |
|---|---|
| 采购合同 | 合同编号、供应商、采购价格 |
| 验收单 | 到货日期、验收结果、原值构成 |
| 工单系统 | 每次维修的日期、金额、类型 |
| 财务系统 | 入账日期、折旧政策、累计折旧 |
| 处置单 | 处置日期、处置方式、处置损益 |
归集之后，跨系统的资产问题可以在一次查询中回答。 以「这台设备从购入到处置一共发生了多少支出」为例，答案来自数据中台的一次查询， 不需要分别调取采购、工单、财务三处的记录再人工拼接。 拼接动作由系统承担之后，同一问题的答案不再随提问人而异。
本层之上汇聚的是三类对象：主数据、资产卡片与业务动作。 三者要汇聚为同一份数据，需要分别有对应的机制，这也是本专题把数据中台单列一层的原因。
| 对象 | 在本层承担的内容 |
|---|---|
| 主数据标准 | 字段定义与取值口径的来源。28 项主数据标准决定同一台设备在各系统中的名称、分类与位置是否指向同一对象 |
| 资产卡片 | 业务动作的记录处。维修、调拨、盘点与处置在各系统中发生，相关记录最终归集到同一张卡片上 |
| 集成接口 | 数据进入系统的通道。45 个系统集成接口按对接系统划分，覆盖 ERP、SRM、OA、MOM 等系统；通道的完整程度决定上层分析能够取到什么 |
三者的关系可以简要表述为：主数据标准定义字段，资产卡片记录业务动作，集成接口负责把两侧的数据送进来。 三者缺一，数据仓库中的记录都会留下空缺——字段未定义则取值无法比对， 卡片未建立则业务动作无处归集，接口未开通则本层看不到该系统的数据。
口径：28 项主数据标准与 45 个系统集成接口为本专题沿用的蓝图口径；接口按对接系统归类，方向与典型内容以项目蓝图的接口清单为准。本层陈述的范围限于资产事务，不替代 ERP 的财务账。
传统做法中，财务部门每月底需要完成一次对账：将 EAM 系统的资产台账与财务系统的资产台账逐项比对， 核对数量是否一致、原值是否一致。这项工作之所以长期存在，原因是两个系统的数据并不同步， 一致性只能靠人工在特定时点确认一次。
数据中台同时连接 EAM 系统与财务系统，两侧数据实时同步。 月末关账之前，系统自动比对两侧的资产数据，将不一致项标记出来并推送差异原因。 以一条差异为例：EAM 系统中 3 台设备显示「已调拨」，财务系统中尚未更新使用部门，需要确认。
这一变化消除的是人工对账中约 90% 的工作量；剩余约 10% 属于系统无法自动判定的边界场景， 仍需人工参与。剩余部分的存在有其必然性：判断本身依赖于具体情形，例如某一差异究竟属于数据滞后还是属于处理错误。 对账机制的目标是让差异集中到少数需要判断的事项上，而非使差异不复出现。
依据：某集团 EAM 一期蓝图（2024）中的数据迁移与接口规划——EAM 资产卡片与 ERP 资产卡片以接口方式推送，保证账账一致；本层引用的对账口径与差异推送规则取自该规划的月结相关流程。
数据中台在平台化能力各层中的位置是基础层。缺少这一层，分析引擎的分析对象是碎片化数据， 决策应用所展示的各项数据彼此之间不可比较——同一张看板上的利用率与维修成本可能取自两套口径， 数值各自正确，组合起来没有含义。
这一层的进度因此决定上层各层的可验收程度。口径未统一之前建设分析看板，看板上的数值会随取数口径变化； 集成通道未建立之前推广决策应用，推送给决策层的差异清单会持续包含由数据不同步造成的假异常， 接收方在数次核对之后便不再查看该清单。
在本专题的六层顺序中，数据中台为第 2 层：其前置条件为设备分级与主数据口径的统一， 其后依次为分析引擎、决策应用与场景应用，持续迭代则贯穿各层。 层与层之间的依赖是单向的，本层的口径变更会向上传导至全部结论。
采集接口的类型与频率、清洗规则、资产履历的归集字段、月末自动比对与差异推送—— 上述内容均无需采信本文陈述，可由演示环境自行核实。