传统行业企业数智化转型的成功模式（上）

要想成功借鉴华为数智化转型的成功经验，就必须完整总结华为在工具阶段、信息化阶段和数智化阶段的经验与教训，取长避短，对其中走过的弯路提出新的解决方案。因此，我们认为：

可以学习华为，但不能照搬华为。

我们希望在归纳提炼华为经验的基础上，提出一个适合传统行业企业数智化转型的成功模式，其中包含总体蓝图与具体路径。

首先，我们不能局限在华为数智化阶段的经验，上一期推文已经提到信息化阶段对数智化阶段的重要意义。因此，我们需要保留华为数智化阶段之前的重要经验，把它视为数智化转型整体过程的具体阶段之一。

此外，我们需要构思一个完整的数智化总体蓝图，以终为始，指导设计该蓝图构建的具体路径，尤其是各个组成部分的轻重缓急。

换言之，我们需要首先规划总体蓝图，然后选择局部先行的具体路径，采取小步快跑方式，逐步构建数智化转型模式。这对于绝大多数传统企业来说，应该是更加切实可行的模式。

数智化总体蓝图由两类应用服务与一套数据底座共同构成（图2）：

如在线报价、客户合同录入等。这类应用最早大多是出于固化作业流程或提升工作效率而建，其自身其实并不需要太多数据支撑。

恰恰相反的是，这类服务客观上为支撑数智化转型提供了数据基础，华为在后期基于数智化转型对数据的需要，增加了很多数据采集工具的建设，也可以归属在这一部分。

对于业务产生的数据的充分应用，是一个数据业务化的过程。

其中包括构筑数字孪生，实现业务实时可视，从事后、到事中、再到事前的经营管理等。各种支撑预测和辅助决策等AI工具也包含在内。 

我们可以依据图2作为数智化总体蓝图指导如何选择数智化转型具体路径，为传统行业企业提供一个可供借鉴的数智化转型模式。

下面我们将详细介绍该总体蓝图的三大构成部分，尤其是从时间维度视角逐步解构三大部分构建的顺序路径，即从A圈到底座，再到B圈，最后形成互动融合的统一系统。

需要特别指出，目前流行的数字化转型模式在A圈构建方面存在严重缺陷，要么停留在信息化阶段，要么完全没有这部分内容。所以，在总体蓝图中A圈构建模式需要尽快纠错。

我们认为，A圈构建是数智化转型的重中之重。

一旦A圈成功，其他部分的构建必然事半功倍；如果A圈先天不足，则将导致事倍功半。为此，接下来重点聚焦A圈构建方面。

操作类应用服务是所有数智化转型的起点，这部分也是数字原生企业和非数字原生企业最大的不同，即是否“在线”。

为了阐明在线的重要意义，阿里CTO，阿里云创始人、中国工程院院士王坚专门写了一本书，就叫《在线》。

数字原生企业的业务天生就是“在线”完成，所以只要有业务就有数据，就像吃饭睡觉一样正常。“在线”听起来似乎没有什么特别之处，可是非数字原生企业业务的正常状态就是“离线”。

构建A圈内容，很大程度就是为了解决“在线”问题。

回顾华为历史，无论工具阶段还是信息化阶段都是为了解决图2中的A圈部分。这是因为数智化转型第一步就是要有数据。

最简单粗暴的解决方式就是要求业务人员录入数据，但这种方式给业务人员带来太多工作量，往往难以成功，而且录入数据的准确性、时效性和完备性都较差。

所以，我们一直追求像数字原生企业一样，把传统行业本身在“离线”完成的工作搬到“在线”，从而形成“操作即记录”与“操作即数据”。

操作类应用服务的成功除服务化的技术架构外，还有三个关键因素：

首先，从“数字孪生”视角来看，一个线下非常混乱的业务，搬到线上只能让业务更加糟糕。

因此，华为操作类应用服务系统从一开始就建立在业务变革项目优化完成的基础之上，其具体使命也是为了固化业务变革取得的成果。

但是，业务变革面临巨大挑战。

要想设计一个有效的业务运作模式，需要改变人的思维模式、行为习惯。

这往往需要花费数年时间，而且常常会出现反复。这可能是因为业务变革设计方案需要调整，也有可能是因为管理者和业务操作人员的固有思维模式和行为习惯导致业务回潮。

如何有效地优化业务，即如何主导业务变革，华为在这个阶段积累了大量实践经验与教训。

很多业务设计刚上线跑的时候可能看不出问题，但经过一段时间的实际运营才会发现问题发生在什么地方。

所以，这个阶段最为核心的学习内容之一就是线下业务流程的优化与运营，为向线上转型提供必要的基础。

其次，操作类应用服务另一个关键是需要既懂业务流程、又懂数智技术（包括IT技术与数据技术）的两栖型专家。

我们认为，一家公司业务部门的数智化能力决定了其数智化转型的天花板。

传统行业企业需要的操作类应用服务都是业务驱动的，这与其他操作系统或AI技术显著不同。

例如，我们之前提到的信息化阶段所面临的技术架构不灵活问题，一旦有了服务化的技术，大家都可以直接引用，也就是说它的通用性很强，引进借鉴也比较容易。

而真正构成操作类应用软件好用与否的分水岭是其中内含的业务设计。

业务人员需要把物理世界中你中有我，我中有你的业务，以及业务基础之上再叠加的多重管控、信息安全等要素，全部解耦成为一个个相对独立、又互相依赖的模块。

这需要对业务进行高度抽象，提炼成为各种相互作用的应用服务以及数据服务。这个抽象过程对业务人员个人能力的依赖很大。

具备数智化思维的业务人员不仅应富有业务实践经验、经历过各种纷繁复杂的业务场景，还要有能将实践经验归纳提炼，变成通用性较高的模块或组件，最终满足低成本、高效率支持业务的要求。

然而，现实的情况却是绝大多数的业务专家在业务实践中非常优秀，但无法完成总结解耦、抽象提炼的任务，也就是说不具备业务的数字化重构能力。

如果由这类专家主导，虽然技术层面可以完成服务化架构，但最终往往还是会建成一个刚性的系统，无法满足灵活适应业务发展的迫切要求。

换句话说，相对服务化这个较为通用的技术能力，业务的模块化和组件化这种业务能力才是数字化系统灵活好用的关键分水岭。

需要指出，具备数智化思维能力的业务专家一开始也只是普通的业务专家，很多也是在数智化转型过程中经历过很多失败，在多次实践中才慢慢构筑起数字化思维能力。

IT领域的专家也有可能在一个业务领域深耕多年后逐步对业务精通而成为两栖型跨界人才，但相对业务人员发展数字化能力而言，IT技术人员掌握业务的难度要更大。

对于企业来讲，需要尽快培养这些特殊人才，使其成为数智化转型的骨干，帮助企业尽可能避免数智化转型的弯路与陷阱。

最后，目前流行的数字化转型模式还存在一个重大缺陷，即将数据治理归到数据底座范围，而没有将其纳入A圈范围。我们认为，这是一个非常严重的谬误。

事实证明，此类数据治理模式往往导致失败，因为这在本质上是一种事后的数据处理模式，最多只能解决一些IT系统自身建设不完善所导致的数据问题。

我们在一家中国知名的传统行业企业做过详细调研，发现IT系统带来的数据质量问题大约仅占20%，而业务本身的问题却占44%，其他30%多的问题是数据口径、统计维度等其他原因。

换言之，流行的数据治理模式只能解决20%的数据问题，而对其他80%问题则无能为力。

华为LTC其实从2011年isales上线伊始就一直在解决数据质量问题，包括及时性、准确性、完整性、可用性，但直到2015年才实现“清洁”数据，为后期数智化转型奠定了重要基础（图3）。

图3：经营分析分维度分析示例

提供“清洁”数据，不仅仅是数据分析的需要，更是打通业务流程的要求。

整个数据治理的过程其实是伴随着业务流程的打通优化，操作类应用服务不断贴近业务实践，以及在不断提升业务体验的过程中完成的。

这个可能跟现在很多专业数据治理公司所讲的不同。数据治理的方法论导入看起来差不多，而且方法论为了适应各种情况不得不大而全，但在实际操作应用中不加选择地全盘套用，往往只是徒增不必要的工作量，而最为核心的问题却往往没有被识别与解决。

总之，数据治理也必须伴随业务治理，没有好的业务治理就没有好的数据治理。

这点对现在很多正在致力于数据治理的传统行业企业来说具有异常重要的警醒意义！这也可以解释为何众多传统行业企业在数据治理方面收效甚微。

数据治理除了上述清洁数据治理之外，还有另外两项重要工作，即主数据治理和基础数据（也称为参考数据）治理。

主数据和基础数据的治理与前面提到的另外30%多的数据口径、统计维度等数据问题紧密相连，也是确保交易数据（事务数据）准确有效的关键。同理，这两部分工作等到A圈建完之后才启动也已错过最佳时机，因此需要纳入A圈构建。

首先，统计维度问题大多与主数据相关。我们调研发现不少企业基本都没有统一的主数据系统，或者即使有主数据管理系统，但并没有提供统计维度服务，因此导致无法有效支撑管理者对业务数据按组织、客户、产品等关键统计维度进行汇总或深入分析。

其次，基础数据可以解决很多统计口径问题。比如统计今年合同中多少是按框架合同格式签的，而这部分金额最终是否都能形成收入尚不确定，还需继续落实；哪些是按标准销售合同签的，而这部分就是已经“落袋为安”的金额。

这些统计口径按照基础数据来建设会让交易数据（事务数据）更为准确，也更容易分析。

基础数据除了支持分析应用，还有一个特别重要的作用就是把很多业务管理动作真正做到了落地。

比如说我们把企业允许的商业模式（一次性付款、利润分成等）做成基础数据固化在数字化系统里，就可以比较好的控制签署未经企业许可的商业模式。

有些基础数据对于业务设计也有很好的指导意义。如商务优惠，华为通过对碰到过的各种各样的商务优惠进行了总结提炼，发现其实其最根本的就是几种，之所以在实际应用中出现了那么多，其实是优惠场景和多种优惠的组合。

找到这个本质并把它做成基础数据就可以很好地支撑未来的商务优惠业务管理和业务设计。华为LTC领域的基础数据也是后来才意识到这个问题，并且在2014年基本建设完成。

最后，还有一类数据质量问题是企业在A圈构建中特别容易忽视的，就是操作类应用服务产生的数据怎么让别人容易看懂，怎么方便业务分析。

在很长的一段时间里，华为都在苦恼找不到数据。一开始大家认为集中放到数据湖里就可以解决这个问题，后来发现这远远不够。

早期的数据定义和构建都是为了完成自己的操作类应用而定义和构建的，别说周边业务部门的人看不懂，就是本领域的业务人员想搞明白数据湖里自己领域的数据都非常困难。

所以这也是后来为什么华为特别强调业务人员转身去做数据，去定义业务元数据，并总结归纳周边领域对本领域的数据分析需求，把这些需求也考虑到数据的定义中去，让不仅本领域的业务人员看得懂数据，也要方便周边领域看得懂，找得到。

我们把业务活动直接产生的数据叫做OLTP（On-Line Transaction Processing）数据。这部分对数据定义的工作其实是OLTP数据资产化的重要组成部分。这部分工作也必须在A圈构建的同时完成，而不能等到数据底座阶段完成。

华为其实在数据治理这方面也走了很多弯路，有些是走到后面才意识到前几步的问题。可惜，鉴于调整成本和用户习惯等原因，华为已经丧失了修改弥补的最佳时机。

华为目前的数据资产里沉淀了大量的业务逻辑（这部分具有很高价值），但是在业务对象定义、逻辑实体定义及逻辑实体所包含的数据属性方面还有很多改进空间。

如果这方面直接全盘采用华为经验，那就可能抄了错误作业。

如何构建好数据底座？实现B圈闭环？更多精彩内容正在持续连载中，本文为系列文章的第2篇，欢迎关注。