12、信息架构实践篇：为什么说业务应该对数据负责

根据上篇所介绍的信息架构方法，由技术实现视角转换为业务管理视角，改良后的信息架构方法大大降低了业务人员理解数据的门槛，统一了彼此之间工作的语言。

但是，正如我的一位同事曾经所说：“不是因为数据语言太专业而看不懂；而是因为业务人员认为数据工作跟他们无关。”

当初，华为数据质量问题的主要矛盾是系统性、架构性的问题所导致的，而往往非业务执行不到位的原因。正因为如此，一旦遇到出现数据质量问题，业务部门往往会将责任推到IT部门。“挨踢”部门往往因为其天然的弱势位置，而无可辩驳。

那究竟谁应该对系统性的数据质量问题负责呢？接下来介绍华为结合信息架构工作，从业务本质上来阐释为什么业务应该对数据负责。

01

“事后诸葛亮”

“2006年前后，华为在海外获取订单的金额已经远远超过其在国际化初期所获取的订单金额。订单数量的增多和金额的增大，使华为面临着巨大的现金流压力。很多订单的销售回款较慢，应收账款积压较多，有些还有成为坏账的风险。由于财务管理能力不足，2003—2006年，华为的利润率呈现下降趋势。”（《华为管理变革》吴晓波）

从数据视角如何看待这一问题呢？下面列举发生在公司内部非常有名的两个案例。

案例一、PO（客户采购订单）打包

所谓PO打包，在进入华为内部的订单系统之前，同一个客户的多个PO打包成一个华为内部合同。在华为内部制造、发货、开票等相关的IT系统中，记录的是华为内部合同信息。到了向客户开票环节，财务人员根据客户的要求，手工找到相应的客户PO。

但随着订单量越来越大，客户的要求越来越严格，同一合同遭到客户多次退票的情况非常普遍。开票效率直接影响到回款效率，从而影响到公司的现金流。现金流乃是每一家企业的生命线。

这是一件在如今看来很难想象的事情，但确实是发生在公司十几年前的业务运作中。

为什么前端订单处理环节不按照客户采购订单一一对应生成华为内部合同呢？

首先是每一个客户采购订单某种意义来说都是一个合同，公司内部有非常冗长而复杂的评审流程，而且采购订单的设备配置也非常复杂。对于销售部门来说，同一客户的多个订单打包成一个内部合同，自身业务环节的效率得到大大的提升。

案例二、S2B转换

注意了，不是SB，也不是2B。2是Two ，也就是To。

S2B转换，即从销售Item（Sales Item）到制造Item（Build Item）转换。

华为最早的业务主要是面向电信运营商提供网络设备。销售模式、产品配置非常复杂。

举个大家容易理解的例子，非华为自己的。我们自己家用购买硬盘时，上电商平台通常下单，购买若干块容量确定的硬盘，如1T。但是如果是公司建设机房，那往往是购买上P的存储容量，我们就不一定要数多少块的，而是按多少钱1T算即可。

无论客户按硬盘个数采购，还是按存储容量采购，通过配置器一律转化为硬盘个数。再导入公司内部的订单系统，下游按此进行制造、发货。

关键的问题是，由于转换关系过于复杂，据说有些产品配置算法包含上千条“IF...THEN...”，从销售Item到制造Item转换不可逆！这意味着，货发到客户之后，需要投入大量的人力手工将装箱单的制造Item转换成客户认可的销售Item，方才进入验收、开票环节。

案例分析

这两个案例都有一个共同点，看起来都是数据关系不清晰所导致的，但需要业务做出重大改变才能解决，而不是数据、IT部门从技术角度可以解决的。

另一方面，尝试进一步假设，如果当初在业务方案设计时，将类似数据关系清晰作为一个基本原则，问题会不会发展到如此严重程度呢？

我的分析也只是纯粹根据逻辑推理的妄自猜测，相信事实会比所猜测的更加复杂。如果要验证的话，至少要追溯到20多年前。这个已经不重要了。

另外，案例涉及到太多受人尊敬的前辈。之所以强调是“事后诸葛亮”，至少打心里表明我绝对不比他们聪明。

02

案例研究：产品基本信息架构变革

所谓的产品基本信息，打个比喻，就像我们每一个人基本身份信息，诸如身份证号码、姓名、性别、民族、籍贯、出生日期等等。

阶段一：没有业务负责的IT系统

产品基本信息系统是2003年研发IT部门自发性开发的一个小系统，管理了产品、研发项目、研发团队等基本信息。

到了2005年，被研发、工程交付、销售、财经、供应链等部门的IT系统广泛调用。与此同时，陆续收到来自各上述使用部门的投诉，反映数据质量差、定义含糊不清、维护不及时等等问题。

众所周知，华为自1999年从18M引入IPD（集成产品开发）流程。从流程管理角度看，产品管理责任归属非常明确。那为什么依然会出现这样的问题呢？

这里引用XX总在某次讲话中的一段总结：“IPD 变革虽然进行了十多年，也有力地支撑了公司的发展壮大，但是在早期对数据的关注不够，因此没有系统的梳理产品的信息架构和数据的标准，也没有对业务流中的数据流进行系统的梳理。从而没有基于梳理的数据来定义IPD流程各环节的交付件和数据，也没有基于数据流的梳理来定义IPD领域的IT应用架构和接口，导致前期IPD领域的IT和工具建设非常的凌乱，不集成。”

阶段二：不改变业务运作现状的“变革”

2005年，产品基本信息变革项目组成立，旨在解决产品基本信息的乱象问题。

项目组理在理清业务现状的基础上，发现研发、销售、财务三个业务部门的产品都有一定的差异，数据并不完全一致。

用手机产品（那时候华为还不出手机）举个简单的例子帮大家理解。

对于手机产品，研发部门往往不会因手机制式、颜色不同而按不同的产品进行管理。但对于销售来说，不同颜色的价格因受欢迎程度不同而定价不同（记得苹果就干过这事），不同制式自然不同。到了财务核算环节，可能因为需要区分贴牌还是自己品牌，核算也不一样。于是，一款型号636手机（为了体现历史感、真实感，举一款华为早期手机的例子），在销售，财务环节衍生出不同的产品名称出来，诸如636-CDMA，636-GSM，636-深蓝等等。

于是，项目组根据业务实际运作的情况，总结和定义了研发产品、销售产品、（财务）产品三个概念来。并且进一步分别明确了相应管理责任部门，维护流程。在IT系统方面，努力的记录和管理三种产品之间的转换关系，以满足各个业务环节的需要。

但是，系统上线后，由于没有规则约束，研发产品、销售产品、财务产品三者关系错综复杂，而导致无法真正运作下去。

后来偶然看到一段项目组当初提出的相当于设计原则的文字，足以说明一切。

“信息架构的正确性和复杂性问题，是与目前的实际业务及应用情况相匹配的。本次基本信息的优化项目，不是要将基本信息做得完全简单和清晰（这样对公司的运作就是变革的改变，是灾难性的），而是要尽量支持目前的运作方式。”

事实证明，“存在即合理”这句老话，并不是永恒的真理。

阶段三：统一产品信息架构

2008年，重新成立产品基本信息架构优化项目组。项目组总结了一期项目的教训，如果业务上不做出改变，是无法解决问题的。

在调研了全流程业务场景的基础上，提出必须统一产品的定义。按照IPD流程的规定，产品由产品规划部门负责。产品规划部门在做产品规划时，不仅仅只考虑如何研发，还要考虑如何销售，如何进行财务核算。例如，对于因为销售、核算原因必须分开成两个产品而研发特性相近的情况，就按两个产品规划，而通过一个项目完成研发工作。

在理清楚业务规则和流程的基础上，按照主数据管理模式重构PBI系统，通过数据服务（web service）方式实现一点录入，多点调用。

PBI一直沿用至今，中间因为业务发生变化（单业务板块发展为多业务板块），在信息架构方面进行了微调。

正如XX总所说：“数据是在流程中跑的信息，IT 是用技术手段来固化流程。...IPD 的经验与教训告诉我们，对业务流中信息的梳理是流程定义的前提，是IT应用架构定义的基础，也是IT系统开发的前提，主流程集成贯通，本质上是数据的集成贯通。数据管理在流程与IT中处于最核心的位置，因需要对数据给以足够的重视。"

03

企业信息架构的定位

一边在具体工作中实践，一边从理论依据方面探索信息架构在企业架构中的定位。

在企业架构理论中，下面的示意图是早期大部分同行的理解和观点。既然如此，又有什么理由让业务对数据负责呢？于是，突破这一传统框架成了我们在数据工作初期“布道”的任务之一。

参考一、TOGAF

相信在企业从事架构工作的朋友如今对TOGAF有所了解，自然也非常熟悉下面所示的架构方法框架。

其中，信息架构（数据架构）属于信息系统架构的一部分。如果对TOGAF历史有所了解的朋友或许清楚，这是一个从IT系统架构发展起来的组织，带有强烈的IT思维。

不符合我们所推行的理念，自然被我们弃之不用。

最近看到，TOGAF9.2版本的业务架构中开始出现关于information map的论文。说明业务架构终于开始从业务视角关注数据元素。

参考二、NGOSS

NGOSS，即Next Generation Operations Software and System。这是国际电信行业的一个参考架构。非电信行业的朋友比较陌生。

eTOM:  Enhanced Telecom Operations Map

SID: Shared Information & Data Model

在参考架构中，eTOM代表了流程架构，SID代表了信息架构，二者共同构成了业务视图（Business View）。

由于华为本身是电信行业起家的，大部分人对NGOSS都有所了解。要是自称专家的话，不懂NGOSS，甚至会被笑话。在信息架构工作起步阶段，我们每次必搬出NGOSS这一理念“宣贯”（教育）一番。对方即使内心不认同，嘴上也不便反对。

参考三、Zachman Framework

Zachman老先生是企业架构理论的鼻祖。但是其影响力仅仅限于专业领域范围内。

四、华为数据管理的主张

朋友们试想一下，我们如何了解一个陌生企业内部是如何运作的呢？

对于一般企业，我们往往从该企业的组织架构及其组织职责开始入手。

华为自2000年引入IPD流程以来，逐步建设成流程型组织。组织架构设置是按照流程运作需要而定的。因此，通过流程架构便可以相对清楚的了解华为的业务如何开展的。后来流程架构又逐步扩展为业务架构。

但在公司开展数据工作之前，一直认为数据设计是IT的事。为改变业务的认知，开始倡导：

信息架构是描述企业业务运作的视图之一。不仅如此，相比于流程架构、组织架构，信息架构更加稳定。

如果要说有政治的话，这或许就是技术人员脑子里的仅有的“政治”思维吧。

04

案例研究：用信息架构跟高层“讲故事”

下面展示的这张数据资产视图是2008年我们按照18M公司顾问提供的方法，仿照顾问提供的参考样例，”照猫画虎“输出的。当向公司高层汇报汇报时，被XX总批得体无完肤，”这不是架构，简直就是肠子肚子一摊！“极其形象而又难听。虽然同样的形式，在2015年再次汇报时被重新接受，但用途发生了变化，此是后话。

（数据资产全景图，来自网络，侵删）

我们在前宣传信息架构的价值包括：统一语言、消除歧义；统一业务规则；指导IT系统设计与集成等等。事后我们总结，向高层领导所展示的数据资产全景图很难直接阐释上述价值。而且高层领导看了之后，也很难说对或者错。

或许许多朋友很难想象，公司高层会关注到如此具体的工作。

如何向公司高层讲清楚信息架构？最终还是在高层领导的“示范”之下得到突破。

2010年，F总作为流程IT总裁，从任老板那里领了PO打通的“军令状”。于是F总亲自坐阵到海外某代表处，跟IFS项目组一起制定解决方案。F总提出，PO打通就是对准开票，并提出为实现准确开票的“诸要素”。

一、数据的三点核心价值

二、两条主线

三、企业核心数据

接下来从两条主线分别展开逻辑推导，识别了企业核心数据，综合起来如下图所示。

经过精心准备，借助2010年中期工作总结机会，数据部门再次向XX总进行汇报。

这次首先在工作思路方面得到领导认可。清楚的记得，在介绍企业核心数据时，XX总还提出挑战，“为什么没有把研发项目纳入核心数据？”我们解释，我们是从从全流程视角梳理核心数据，而研发项目主要影响研发过程管理。

记得XX总听完汇报之后，当场肯定：“第一次把信息架构讲清楚了。”

这是一次成功向公司管理层”推销“信息架构的经历。

当然，不仅仅停留在”讲故事“的层面。明确指示，接下来的三年数据工作，围绕这些核心的数据开展。在当初数据质量四处冒火，而数据能力和人力都不足的情况下，可以让我们聚焦最有价值的数据工作，起到至关重要的作用。

在结束前必须说明的是，华为在信息架构实践方面的发生在内部变革的各个角落，上面仅仅总结了本人所经历的其中一部分。

END

数据之于企业，或轻或重；我之于世界，或重或轻？在不断的数据工作实践与内省中找到属于自己的答案。

您的关注，

我分享的动力

---

关于公众号：数据不能承受之重

米兰.昆德拉在《生命不能承受之轻》中灵魂拷问般的写道：最沉重的负担压迫着我们，让我们屈服于它，把我们压在地上。同时，最沉重的负担，也成了最强盛的生命力的影像。负担越重，我们的生命越贴近大地，它就越真切实在。相反，当负担完全缺失，人就会变得比空气还轻，就会飘起来，就会远离大地和地上的生命，人也就只是一个半真的存在，其运动也会变得自由而没有意义。那么，到底选择什么？是重还是轻？