那个要了半个月的数

这些年我去的很多大型企业，信息系统基本都建全了。

ERP、MES、PLM、SRM…主价值链上的活，件件都在系统里跑，数据也确实一条一条存进了系统。

可只要领导开口要个数，比如：这个月的已发生成本、某张订单的利润——底下立刻忙成一团：导表、对口径、开会。

最后递上去的，往往是个连汇报人自己心里都没底的数。

为什么系统一茬接一茬地建，数据就是上不来？

这是谁的锅

很多人第一反应是怪系统不行，或者怪底下人不用心。

我得说句公道话：这锅，系统不背，员工也不背。

数据上不来，很可能是建系统的时候，根本没人管过“数据贯通”这件事。

问题到底在哪

先看最表面那层：各家公司的系统一般都是按部门建的：销售部门提销售的需求，生产部门提生产的需求，各管各的事，各建各的系统。

所以，系统中产生的数据也就顺着这条边界走——数据在本部门内部流通没问题，但是跨部门流通就很有问题。

再往深一层更扎心：不同部门之间，连最基础的数据都无法对齐。

同一件事，大家的理解不一样、口径不一样、维度不一样、颗粒度也不一样。你按订单管理、我按批次记录，他按序列号查询，数据到一块儿根本对不上。

同一件事，不同部门的数据根本不一样——不是谁对谁错，而是没有对齐。

有些需求，单个部门提不出来

那为什么会这样？是各部门没有做好自己的工作吗？不是。

这就是最深的一层，也是真正的病根：有些需求，单个部门根本就提不出来。

比如集团需要对经营数据做统计分析、做穿透式管理——这种需求，站在某个业务部门的位置上是看不见的，它不在任何一条业务流程里，是企业的顶层需求。

再比如颗粒度要对齐、维度要统一、口径要一致——这种跨部门、跨系统的技术要求，哪个部门会替别的部门操这个心？

这些需求，不该由某个建系统的部门提出，这个部门也提不出来。

这些需求需要有人站在公司层面统一协调、统一校准。

缺的是公司的那只手

可当年建系统的时候，偏偏没有这个角色。于是已经建成的业务系统基本满足了一个个“提出明确需求的人”，却无法满足“公司级的数据贯通”需求。

本质上，就是企业本身没有做好企业级的需求与规划。

本来，每做一个项目、每上一个系统，都是对公司业务能力的增强，都应该从一张公司级的总体规划蓝图里，挑出一块来实现。

每一个项目，都应该从属于公司级的蓝图，而不是另起炉灶。

每做一个数字化项目，本质是补齐公司的一块能力，而不是又立起一座新的烟囱。

没有这张总体蓝图，所谓的数字化，就是各部门各自为战的堆叠。无论堆多少，数据也天然是断的。

接口救不了数据

也有企业不甘心，喊着把接口打通，可这事多半是白忙。

接口是技术活，数据能不能通，卡点根本不在技术。

口径、维度、颗粒度没对齐，数据就算流过去了，接收方拿到的也不是他要的那个数据，照样用不了。

打通接口，不只是把数据连起来，而是要把业务需求对齐。

这类问题，怎么解决

很多公司都或多或少出现过这类问题：主价值链全上线，数据都在系统里，可公司要个数就是出不来。

我在这些企业做的事往往不是梳理接口——数据对不齐，接口做了也用不上。

我会用企业架构的方法，从业务架构出发，梳理业务能力、明确业务场景、核对业务规则；再通过数据架构，把这些业务规则转化成数据标准和数据模型；最后站在应用架构的视角，去考虑应用功能如何优化、应用集成怎么实现。

前面的业务规则明确了、数据标准清晰了，系统才能有目的地优化，这样，接口才会有用，数据才能贯通。

这么走了一遍，公司级的数据汇聚、统计分析、数据自动引用，才可能真正跑通。

领导要的那个数，也不用再开会，系统直接给。

这套打法，叫企业架构

企业架构不是又一个要买的系统，而是那张“公司级总图”。

企业应该先有公司级的架构，每个项目是从公司级架构中取一块去实现。

取出来的这块，天然自带了业务架构、应用架构和数据架构。

这样长出来的数据，在需求阶段就已经设计了贯通，而不需要事后拿接口硬连。

这，就是我们自己总结的企业架构双翼法里的存量翼：让数据贯通。

写在最后

所以，数据上不来，一般不是多加几个接口就能解决的。

很多企业缺少一套公司级的企业架构——那张一开始就该画、却一直没人画的总图。

把企业架构补上，才能更好地让需求落地，让数据贯通。