“数字化重构系统，搞定 CEO 是第一步”

“任何行业，都值得用数字化再做一遍。”

这句话出自陆奇（奇绩创坛创始人兼CEO）之口，也是过去一年中，我引用最多的一句话。过去21年的IT职业生涯与近两年的数字化系统研发经历，使我对此深有体会。

极智嘉研发总监邱良军

2000年，我大学毕业进入外企，一待就是15年。回过头才发现自己错过了互联网发展的十年黄金期，也与移动互联网带来的风口擦肩而过。但有失亦有得，从事软件开发的十年和做技术管理的五年间，我从带领十多人的小团队到领导数十人的中型团队，并系统地学习了PMP（国际项目管理师）相关知识，为我在研发管理方面奠定了基础。此后三年，我在外包公司从零开始组建团队，也积累了管理近五百人团队和直面客户的经验。

如今，我身在创业公司，从组建异地研发团队并参与子公司的筹建，到负责公司数字化转型的系统研发，研发管理经历已涉及多个方面。在本文中，我总结了多年的研发管理经验和数字化转型管理经历，希望为当下处于数字化转型浪潮的众多技术管理者提供一些参考价值。

对数字化转型的认知

借用数字化转型机会重做一遍系统，是对系统覆盖的业务及涉及岗位的重新认识，通过对新技术的使用、逻辑的梳理、细节的打磨、流程的重构，能够激发每个参与者的能力，从而提升企业的整体竞争力。以往的数字化转型管理经历，使我深刻地感受到：

• 数字化转型正发生在每个人身边，它既不高深莫测，也非遥不可及；

• 数字化转型是企业的核心竞争力，是提升效率的关键因素之一；

• 数字化转型是社会信息化过程中的新阶段，是发展的必然；

• 数字化转型是循序渐进的过程，需要根据自身实际情况出发。

但是，许多企业在最初的信息化建设阶段通常只涉及一个部门或一个业务单元，推动相对容易，而在真正落地实施数字化时，往往会面临三个问题：

• 软硬件技术飞速发展让企业面临更多选择，很容易陷入选择困境；

• 规划很美好，落地过程却困难重重，短期效果不如预期；

• 转型涉及全过程、全业务，会带来利益的重新分配，以及对旧模式、部门壁垒的打破与重塑，因此会阻碍重重，必须从“灵魂”深处动手。

我一直坚信，一切问题归根到底都是管理的问题，这个道理在数字化转型上也同样适用，对于企业而言：

• 数字化转型势在必行，必须由企业一把手推动；

• 可以边规划、边落地数字化转型，从最易处入手，如远程会议、共享协作文档等；

• 以满足用户和实际业务需求为驱动，更容易达成转型目标；

转型过程没有“银弹”，必须从点点滴滴入手。每个企业都有自身特点（组织架构、业务模型、团队关系、企业文化都有所不同），成功的案例只能借鉴，不可完全照抄，可以在推动过程中不断进行微创新。

本文节选自《新程序员004》纸刊+电子刊同步上市

要和CEO及决策层讲ROI

在过去一年中，我最深刻、最痛切的领悟便是：要和管理层讲ROI（投资回报率）。即便曾经带领超300人的部门，直接面对客户，为公司..。我当时也没能理解“企业花费每一笔钱必须有商业逻辑”这句话。如今我才真正明白，必须简单明了地阐述企业的核心问题：如何创造价值、量化计算。

数字化的灵魂是业务，骨架是组织，手段是技术。在规划数字化转型时，必需计算ROI，这是企业管理层唯一能听懂及达成共识的语言。ROI的计算要简单且有说服力，通过量化ROI可以决定做哪些事、先做哪件事。优先级事项排列方法见表1。

看似简单的方法，却难在如何判断价值的大小和事情的难易。

首先，价值大小的计算公式为：总价值=降本+增效+提质。其中：

（1）降本=人力成本（发生频率*单个人效提升*人力单价）+ 其他节省（硬件成本降低+软件费用降低）

（2）增效=单位时间内产出（性能）的提升

（3）提质=产品良率提升+系统稳定性提升+产品更标准化+客户满意度提升

可以根据项目系统或功能做拆分和计算，产品价值计算案例见表2。

（1）“降人力成本（每年）”=（原处理时间－改进后处理时间）*单项目发生频次*项目数量*人力单价

（2）风险规避（每年）=（原事件发生次数－规避后发生次数）* 单次发生的平均损失

（3）初始投入（研发或采购软件成本）

（4）投入运营费用（每年）

表2 产品价值计算案例

合计后的ROI通常由财务人员计算，这里便不作展开。需要注意的是，如果初始投入是研发成本，可以把软件计入资产，分摊到多个年份折算，降低企业的税费。

对于业务价值的判断，业务部门拥有最大的话语权，转型负责人必须理解业务，和业务部门达成价值计算（即ROI）的共识，并得到业务部门的支持和背书。据我观察，之所以研发需求多到做不完，是因为有许多伪需求，通过ROI方式计算后，超半数的需求都不会再被提及。

其次，对于事情的难易判断比较主观，取决于个人能力。难易程度决定成本，而成本又是ROI的关键因素之一。从经验看，我们可以选择外采服务、SDK、SaaS、自研等模式，在预算有限的情况下，方案的选择会是决定性的因素。

在与管理层沟通时，需要把上级看得见的和看不见的联系起来，并说明之间的关系。

看得见的包括：

• 销售业绩增长了1倍，客户满意度提升了5%；

• 岗位人员效率提升，流程执行规范化；

• 日、周、月报表提交是否及时，是否有数据支撑的精细化管理；

• 高大上的数据大屏（这点尤为重要）。

看不见的包括：

• 技术术语、开发语言、前/后端分类、技术架构、业务拆解、设计模式等；

• 敏捷开发、代码规范、内存溢出、慢SQL、DevOps，数据中台、技术中台等；

• 架构、设计模式，以及重构、改进、优化等。

除了以计算ROI来驱动数字化转型的方式外，还可以采用问题驱动的方式，且这样的效果看起来更好。很多问题会在交付过程中引发故障或引起客户投诉，所以需要通过反向分析做出改进和预防。

业务痛点分三种

如果说获得企业决策层（尤其是CEO）的支持是数字化转型的起点或第一推动力，那么理解业务或由业务驱动便是转型成败的关键点，也是转型持久改进的动力源。

在数字化转型过程中会遇到各种奇葩问题，转型负责人必须和业务团队做深度沟通，理解业务痛点。

系统建设过程中，主要参与角色包括决策者（出资人）、需求方、系统使用方，以及产品系统的设计、研发、运维、运营。在复杂的ToB场景中，四方角色可能不在同一部门。而根据经验，各种情况都会存在，且直接影响转型成败。下面列举其中三种情况。

第一种情况：需求方（+客户）=用户方，是赋能的过程。

这种情况下，需求方、客户和用户是同一个人或同一团队，转型过程较容易推动，干扰和阻力较少。在成熟企业，该情况往往发生在信息化已完成阶段，需要做重构、持续优化、系统打通、数据治理等事项，主要考验团队的技术能力。不得不防的一种极端场景是，开发者担心自己的工作可以系统化后，职位的重要性降低，他们就会保留一些“秘诀”，导致系统化不彻底（根本原因是利益作祟）。

这是我遇到的真实事件：2009年在新加坡，我的印度同事做运维支持工作，负责人工监控日志和传输文件、进程等。因为工作强度非常高，所以我们作为开发工程师短期转岗支持他们，但对方却不愿意透露监控规则，最终出于业务压力才不得不说。为避免类似阻力，需要企业具备良好的文化和改革决心，建立起学习型组织。

第二种情况：需求方非用户方，能力转移，是革命的过程。

这种情况是将专家的能力赋能到系统中，普通用户通过使用系统即可获得专业能力，是能力转移或赋能的过程。听起来比较拗口，举例说明：360卫士对计算机做安全检查就是一个赋能过程，原本IT专业人士才能完成的工作，普通用户通过使用360卫士也能完成。在ToB场景中，有大量类似的情况，“专家们”在岗位上长期积累的经验不愿完全沉淀到系统中，总会有所保留。从理论而言，这是为了企业的发展，是应该做的，但在我负责过的部分系统中，这类项目的推进效果不佳。即便有CEO强力推动，也都是雷声大、雨点小，专家会有各种推诿、说辞，甚至故意相互抱怨。

究其原因，主要是在ToB场景下，从线索、商机、方案、订单、项目管理、供应链制造、交付实施、售后维修和运维支持，直到系统停止运行的链条较长（我们的研发链条包括将软、硬件结合，并需要做集成方案，管理整个生命周期），在此过程中涉及各阶段的领域专家协作，沟通协调很困难。如果这些能力可以下沉到系统中，将大幅提升协同效率。

实际上，多数需求方（即领域专家）的觉悟不高（自我保护意识太强），不愿