华为数字化转型之道详解笔记-方法篇

大家好，欢迎来到IT知识分享网。

这是我看了华为数字化转型之道后的读书笔记，原载于我的知乎号。这篇是全书的第二篇，介绍了华为数字化转型的理念，方法和实践，是本书的核心部分。本篇分为三章，分别介绍规划，变革项目和IT实施。通过战略驱动的合理规划形成变革项目，使用‘转人磨芯’的变革方案来确定规划落地，最终落到IT投资上，要用产品思维来管理。下面三章分别来介绍。

一套方法贯穿数字化转型全过程

（本系列图片来自于华章计算机，转载注意版权，后续不一一赘述）

第一章 愿景驱动的数字化规划

从业务战略出发，分三步：描绘愿景-设计架构蓝图-规划举措和项目。

以终为始，描绘数字化愿景

为什么说以终为始呢？因为我们愿景不是空头大话，应该有目标，有原则，有计划。关于如何基于数字化调整业务战略书中提了两点：1是调整数字化商业模式，比如汽车行业传统的4S购车体验已经被APP下单替代，2是提供数字产品和服务，比如我们汽车行业，特斯拉的OTA软件购买。再比如华为的从卖电信产品，到运营服务，到云服务以及咨询等等。

那怎么描绘愿景呢？首先搞明白愿景是什么：他是业务面向未来的关键变化，包括在客户界面带来的好处，内部业务运作层面将为企业带来的价值，为了应对这样组织要提升的关键能力。怎么绘制的，书中提到了‘五看’，就是从五个方面来看当前的现状，之前在埃森哲的报告里面也看了类似的描述，看来都是互相抄啊。看战略（公司的竞争定位），看客户（客群，业务模式和需求的变化），看行业（国家政策，行业发展），看自己（企业价值流），看技术（数字化技术的应用前景）。

华为的数字化转型愿景是“把数字世界带入华为，实现与客户做生意简单有效，内部运营敏捷，率先实现ROADS体验，成为行业标杆”，如下图所示：

可见华为的数字化愿景有两个重点：一是围绕客户，员工，合作伙伴的ROADS体验，一是大平台能力支撑

1. ROADS体验

实时（Real-time）：意味着信息实时获取，即业务对用户需求进行快速响应，让用户零等待；企业内部流程快速流转，业务快速运作。

按需（On-demand）：意味着按需定制，即让用户可以按照自己的实际需要定制各项服务，可以自由选择。

全在线（All-online）：意味着全在线，即让用户在线进行业务操作，实现资源全在线，服务全在线，协同全在线。

自助（DIY）：意味着用户可自助服务，即让用户拥有更多的自主权，提升用户的参与感。

社交（Social）：意味着社交分享，即让用户可以协同交流、分享经验和使用心得，增加用户归属感，增加用户黏性。

在传统制造行业，甲方的IT团队难以达到这个水平，很多数据都要隔天获取（不实时），数据权限混乱（不知道找谁要数据），烟囱系统多（数据不在线，或者在线不互联），用户体验差（用户不会用系统，难以自助），更不要说社交了，只能说勉强集成了门户。面对这种现状，不转变模式，是难以改变业务以及IT的现状。

2. 大平台能力支撑

未来企业之间的竞争，将不再只是一线“精兵”团队的竞争，更是精兵+管理体系/平台能力的竞争。如何使得一线精兵的能力不只依赖于个人经验，如何使得机关提供的服务更加高效并能满足一线需求，如何减少机关“管控”对一线作战的内耗和打扰，如何从全局来看资源调度更优，都是华为数字化转型要解决的核心问题。

从下图能看出来，不直接面对客户的机关团队，把知识，资源，能力等打包成黑盒的，服务化的系统也好，API也好，来支撑前台一线的业务部门。华为的机关团队对自己的定位是8分服务2分监管，而有些公司恰好是反过来，后台机关部门变成了公司资源调度的核心，让人不得不想起明朝宦官干政的情况，哈哈。

统一认识，设计架构蓝图

讲完愿景就要根据愿景来设计架构蓝图，讲的就是企业架构4A（业务/数据/应用/技术）的内容，这一部分相对比较专业，华为内部也有不少人是专门做架构工作的，其架构团队是很多甲方企业的数倍规模。这也体现了华为的优势，大平台能力支撑，如果没有这么多资深的架构师支撑，难以想象整个数字化的规划，以及变革项目的架构评审怎么做，这里简单介绍架构设计的原则和华为的数字化架构。

1. 架构原则：

• 以客户为中心，由外而内进行蓝图设计 。

围绕客户旅程，瞄准企业与客户的关键触点，思考如何改变与客户的交互方式，以及如何用数字技术做厚、做深客户界面的联接，使客户可以以最短路径接触到华为，提升客户体验和满意度，进而牵引内部交易流环节的快速流转，及时响应客户。

• 明确在哪些端到端流程提升业务效率

架构蓝图中需要标识出企业层面有哪些跨领域的流程，这些流程将是下一步数字化转型的重点。也就是通过流程数字化，将业务由线下转到线上，并实现流程端到端集成打通，进而改变业务运作模式，提升业务效率。

• 从内部视角，看从哪些关键环节入手提升业务能力

业务能力的提升是数字化转型的重中之重，通过架构蓝图，识别需要构建哪些关键业务能力，并形成服务；业务能力之间充分解耦，这些能力都是后续数字化转型的着力点。

• 各部门的责任分工和层级关系要清晰

数字化转型需要全公司上下一盘棋，各部门协同配合，“一张蓝图绘到底”。通过架构蓝图来明确各部门在蓝图中的位置、各业务部门承担什么责任，以及各业务部门之间的输入输出关系。

• 明确定义全局性工作

架构蓝图需要明确有哪些转型工作需要公司层面统一布局、统筹安排。比如安排IT平台、数据管理等统一由公司IT部门负责，根据各业务部门提出的需求，按需调用相关的服务和能力。

• 体现架构的演进方向

架构蓝图瞄准未来，而不是描述现状。所以，蓝图应该明确架构演进方向和趋势。比如，通过数据驱动，实现信息实时、透明可视，进而通过大数据分析和实时智能创造价值。再比如，通过应用现代化，推动应用服务化并迁移上云等。

2. 华为的数字化架构

下图是华为2016年绘制的数字化转型架构蓝图，整个图分为5层，每层还要具体的细节：

第一层：客户连接。面向客户的全连接平台，根据客户旅程达到ROADS体验。

第二层：一线作战平台。有两个主线，一个是面向客户的业务流，这个是保障公司当前的业务。一个是面向市场创新的，这个是保障公司技术先进性的。

第三层：能力数字化。流程是底层业务能力在不同场景下的组合，把能力服务化包装，才能共享和重用，要不然数字化变成了重复的开发和烟囱。

第四层：数字化运营。流动的数据中提取就是指标，指标支持公司决策（有利于AI智能决策及减少管理层级）。这部分内容还包括数据资产管理。

第五层：云化的IT平台。数字化最终的技术支撑和承载。

把握节奏，规划举措和项目

蓝图做完就要开干了，此时华为的三步是：定举措，定项目，定节奏

举措：就是目标，我们蓝图达到的目标。华为的举措是：客户交易简单高效，一线作战灵活，平台能力提升，基于清洁数据的数字化运营，云化和服务化的IT基础设施和IT系统。大家注意下红色字体就是举措，非常简单和直接。

项目：我们打算开发那些变革项目才能达到上述的举措。识别项目要搞清楚下面这些内容：目标和范围，我们的问题以及与先进水平的差距，涉及的业务能力，具体的关键任务，业务价值和指标（就是这个项目我达到了什么程度，具体的指标是什么，比如提升客户体验，那么客户操作减少了多少秒，就是个指标。很多企业的指标都是做些假指标忽悠领导），最后是项目的风险和依赖

节奏：就是那些先干，那些后干。这些要综合考虑，重要性，难度，相关依赖等。华为建议适当提取建设公供能力，瞄准高优先级的变革项目，做出试点和样板。

总结：三阶十二步法

最后上面三节说了那么多，总结下来共12步，他们的内容和关系见下表和图，前面都略微有点涉及。

第四章 用变革的方法确保规划落地

再好的规划，也要落地才行，要不然靠咨询公司就能把公司干起来了。华为总结了他们数字化变革的方法和实践，认为需要依靠：创造价值的能力和改变人的能力，这两种最关键的能力。本章分为三节：第一节讲如何识别危机，营造组织变革的氛围。第二节讲如何用项目的模式来管理变革。最后说如何对变革进行评估。

变革管理实现转人磨芯

华为认为变革最大的阻碍就是人的观念，意识和行为。所谓转人磨芯，转人就是人的能力和知识上的不断进步，以适应新的岗位和形势。磨芯就是指人的思想，意识的转变。没有变革的数字化转型就是骗人，而变革就意味着旧势力利益和格局的变化，势必带来中层以及部分底层的阻碍，如何让他们支持变革，转人磨芯是本节探讨的内容。

变革船模型：领导是船头要把好方向，还要破除关键障碍。教育和沟通是船帮保驾护航。关系人分析和评估是核心，如果搞不清楚涉及那些人的利益，挖掘不出变革的阻碍和根本原因，变革是干不成的。日常的工作是项目组，组织，绩效等一系列工作。搞清楚变革模型，那就可以开干了。

第一步：洞察危机，选择时机。除了领导层的决心和勇气，还需要组织准备度，紧迫性，资源准备度进行评估。至于怎么评估，书中未涉及，网络上有很多评估模型供大家选择。

第二步：营造紧迫感，目的是统一意识，达成共识。举了任总治理仓库帐外物料管理的例子。

第三步：搭好板子，选对人。业务负责人要承担owner，要投入业务骨干，要注重业务体验，让业务深度参与。反观笔者之前参与的一些项目，业务出一两个KBU，可能是业务骨干，更多的时候不是，因为业务不舍得让骨干来干副业，更不用说发动更多的业务深度参与，这些的项目是不可能干好的。

第四步：读懂人心，消除变革阻力。书中用8问来指导大家如何识别变革影响，识别利益干系人。提出了一些行之有效的策略：有战略耐心，拉长变革时间让大家适应。保障利益。通过快赢方案增强变革信心（也让领导们有点功绩）。主动沟通及时关怀。教育和培训，帮助员工提升技能。最后还要识别盟友：响应者，跟随着，消极反对者，积极反对者。要分化，团结，利用。

第五步：调整组织文化。具体的措施包括：促进组织扁平化，改变原有的职位要求，重构分工和协同模式。

项目式推动变革

前面介绍了变革的大致过程，那怎么开展变革项目呢，华为提出了七横八纵的变革管理框架，七纵是变革管理的各个层面，八横是变革管理的过程。

下面分三个点来详细描述变革项目管理。

第一 立一个高质量的项目

要做好预研工作，搞清楚为什么变，变什么，怎么变。

组建优秀的项目团队，要从利益相关方考虑，还要选择优秀的变革经理带动各个业务部门的人协同工作，保障交付

第二 以价值为导向管理

华为提出了TAM变革价值度量模型，来评估变革的价值目标，分为：结果类，能力类和管理类。

华为在实际项目运营中，始终以价值承诺书(value book)为抓手，在立项决策到部署运营，每个阶段都要对value book进行评审。value book在编制时也要瞄准变革的业务价值实现，而不是项目目标。既有要定量目标，也有定性的描述。书中给了一个华为的例子，大家可以去参考。

第三 持续运营，防止回潮

项目有明确的时间要求，但是项目结束并不意味着变革结束，需要持续的项目运营来固化组织能力。

变革评估

华为成立了单独的变革项目评估组织来对变革项目进行评估，类似变革项目的监理。

从能力构建，价值实现，使用者视角等三个方面对变革进行评估。

第五章 视IT为投资，用产品思维管理IT

核心观点：IT系统不再只是固化流程的工具，更是业务开展的“作业平台”。

数字时代IT系统的重新定位

下面这个图是华为的总结，这个转变意味着IT不再是一个支撑部门，管理部门，他要和业务一起创造价值，解决“慢，贵，难”的问题。结合我自己的体验，一起分析一下：

1. 管理系统到作业平台的转变。甲方的IT需求往往来自于管理部门，往往不是数据产品的部门，也就不是真正开展作业的部门。这就导致需求往往是流程固化，信息记录，指标管理等。比如交付物管理，提需求的往往是项目管理和研发质量部门，而真正开发交付物的工程师没机会提需求，这样开发出来的系统往往沦为交付物收集，催促，报警的系统，而不是一个交付物的作业平台，工程师岂会对他有好感？
2. 只强调功能不管用户体验。曾经有工程师评论开发出来的系统是反人类的，不是给人用的。这里面很多问题，缺少总的产品经理协调，IT只重视功能，因为功能和预算挂钩，功能的改变意味着成本的改变。笔者曾经看到有的系统，需要用户一次填写十几个tab，，每个tab又十几个字段，这确实要搞死人呀，这种系统只能说明显拖累工作效率。
3. 全生命周期管理。传统甲方企业领导认为上线项目就结束了，发一波新闻，领导的成绩也有了，后续人力的投入明显减少。第一，我们不可能一次就开发一个完美的系统，需要持续改善用户体验。第二，专业系统用户需要培训和支持，不可能上手就能使用，会使用，需要稳定的支持。
4. 快速响应。笔者曾经看到一个项目立项花三年，采购流程3个月，开发3个月，1年半之后系统弃之不用。甲方有冗长的上线流程，冗长的立项流程，这些不改善，数字化不会快速深入业务的。
5. 数字世界的模拟推演。这里的意思又深了一层，我们不能只做记录，更多的要拿数据去做分析，从感知智能到认知智能。

华为达到了什么程度？1.持续价值创造，对产品进行持续管理，不是开发一个项目。2.敏捷业务响应，过去两个月以上的需求交付周期变成以周，天来计算。3.IT产品是投资，根据产品来规划，投入有保障，不是按照项目预算来。4.构建产品团队，不会出现项目结束，团队解散的窘状。据笔者了解，华为有IPD解决方案团队，SAP的，CRM的等等，基本上一个大的领域，都会有一个产品团队在支持。

IT产品全生命周期管理

过去IT部门交付压力大，业务提的需求源源不断，面对业务压力往往只管生，不管养。这样容易形成系统刚上线，用户投诉修改的恶性循环。

1. 从被动响应到主动产品规划。

要有架构视角，从一定高度来规划产品。要总结前期产品建设和运营情况；要加强与业务的产品规划输入；要有架构视角，规划产品特性和路标。数字化规划不只是IT的工作，是属于业务规划的一部分。

2. 价值与体验驱动的产品运营

这里华为强调了亮点，一是业务价值，一是体验驱动。前面业务价值已经有所介绍，华为有value book来衡量。体验驱动就要求产品经理以用户为中心，在运营过程中对用户进行精细化画像，倾听业务声音，快速闭环。

那如何运营呢？华为从三个方面开展：a.业务运营：主要指标有流量（承载业务量，比如多少业务已迁移到新系统，产生多少数据等等），流速（流程活动节省时间，等待时间，决策时间等），流效（运作质量，差错率，决策率等）。b系统运营：主要指标有：服务水平（数据服务掉用次数），质量（页面响应性能，服务调用成功率，生产环境缺陷率），工程能力（需求实现周期，页面一致性等）。贝索斯在亚马逊的系统建设中提到过一些准则，其中一条无人调用服务的系统不要建设。c用户运营：关注用户体验，分析用户行为，组织用户大会等活动。

业务与IT一体化团队

业务部门与IT部门有一道鸿沟，业务抱怨IT不懂业务，慢贵难，衙门思维，系统做的太差；IT部门抱怨业务部门需求没想清楚，需求变化快。有的大甲方设置了数字化部门，这个部门就更难了，业务和IT都可以甩锅给他，声称是铁三角，实际是一锅粥。华为的经验是什么呢？

1.产品经理是IT产品团队的核心。优秀的产品经理往往来自于业务，因为业务理解IT的技术手段简单，IT想要理解业务里面的弯弯绕绕很难，场景越复杂越难。业务部门也要转变观念，把IT视为业务的一部分，选择优秀的业务专家参与到系统设计中。传统的业务部门派一两个KBU参与的方式无法建设优秀的系统。

2.能力融合。也就是培养既懂IT又懂数字化的复合型人才，华为开设了几十门数字化相关的课程，真正实现从两张皮到一体化

V模型指导服务化设计

服务化是IT的术语，华为把服务化架构作为企业架构演进的原则。这一节是比较偏向于IT设计的，需要有开发经验才能理解。服务化是双刃剑，他解耦业务，减少直接接口集成，编排灵活，扩展性好，开发速度快这是他的优势。但是微服务要求设计能力高（比较流程的领域驱动设计DDD），运营成本高（尤其是在有前后关系的服务编排上），需要甲方服务的维护团队多。很多甲方缺少开发能力，或者说缺少高水平的开发团队，是难以开展这样的开发工作的，买成熟的产品是更适合的选择。

怎么评价服务化水平高，华为提出了4个维度：数据维度（物理模型规范性，元数据完整性等），数据要体现高内聚低偶和；服务维度（API认证率，调用次数等）重点考虑服务共享，服务质量和服务的响应情况；代码维度（代码规范，重复率，代码质量）开发的维度看；收入与成本维度（服务单次调用成本，硬件成本等）主要看服务虚拟结算情况。

华为提出了以服务化理念为核心，以数据为锚点，将自顶向下的业务设计方法和IT应用规划设计方法相结合的V模型设计。IT和业务需要用统一的语言交流，以避免产生歧义，以及全公司内的数据共享和交流。华为的这套方法像是bizbok以及ddd等理念的一个结合体，具体概念大家可以看bizbok和togaf等书本，涉及的主要概念有价值流，业务能力，业务场景和业务流程，业务活动，业务对象，应用服务，应用系统模块，产品/子产品。

具体操作方法如下：1确定业务能力；2分析业务场景，定义并收敛业务活动；3.识别BI，定义业务对象；4.识别应用系统模块，以及应用服务/特性；

至此本篇的学习笔记就结束了，先介绍如何做规划，再介绍如何用变革的模式管理规划出来的项目，最后介绍IT开发的模式去落地项目，下一篇将重点介绍华为数字化转型的实践。