略说数字化中的那些坎

天有不测风云，人有旦夕祸福，数字化有连绵之“坎”。数字化中的“坎”，没有发现之前是坑（洞），是风险和暗雷；发现以后就是坑（害），是伤疼或灾难。最近一次广为人知的数字化之“坎”，就是发生在年10月初的Facebook全网宕机事件，全网宕机近7个小时，给Facebook及其用户造成了难以估量的损失。

数字化中的“坎”无时无处不在，不仅在大公司会发生，小团队更是常常碰到。笔者之前担任某企业的IT负责人，基本上每天都会碰到这样或那样的“坎”，小的“坎”可能只是某个IT系统的小Bug，影响面极为有限；大的“坎”则可能导致系统不能正常访问或业务不能正常运营，影响到全公司或公司的广大客户。

数字化之“坎”的百态

数字化中的“坎”在形式上是多种多样的，可谓是举不胜举；而其发生的原因也是多种多样的，可谓是防不胜防。如果粗略地统计一下，有组织动荡之“坎”、需求不明之“坎”、团队协作之“坎”、供应商不力之“坎”、代码随意之“坎”、测试不全之“坎”、版本发布之“坎”、错误操作之“坎”、应急缺失之“坎”，等等。可以说，数字化建设的任何一个环节和任何一个要素，都可能存在或导致某种形式的“坎”。

组织动荡之“坎”

从某种意义上来说，任何数字化建设都是组织变革，而变革要想成功就需要持续的努力，需要有相对稳定的组织环境。笔者曾经碰到过一家企业，在ERP实施项目期间的不到1年内，总经理换了3任，相伴随的是关键业务部门主管的调整；在这样一个动荡的组织环境中，ERP要能实施成功那才真是怪事一件。

需求不明之“坎”

任正非先生说客户需求是个哲学问题，可这年头，真正的哲学家也不多呀！

数字化需求是数字化建设的源头。如果需求没有弄清楚，或是需求弄错了，后面的一切努力肯定是无用功。有些企业，有的部门，做数字化纯粹就是为了跟风，看到人家在做他（她）也要做，至于要做什么自己则一点头绪都没有，完全依赖乙方给方案。如果乙方的经验丰富，能力也比较强，给出的方案就可能对路，否则，项目的风险就非常大。

团队协作之“坎”

数字化建设中团队成员之间的协作也很重要，这不仅指业务与IT之间，也包含IT团队的内部。笔者曾经碰到过这样一个项目，有个项目组成员遇到问题就习惯自己研究，研究了一个星期都还没找到解决办法，最后还是业务部门上门投诉到项目组后笔者才知道。实际其他项目组成员对这类问题很熟悉，马上就把它解决了；如果这个成员一开始就把问题拿到项目组来讨论，也不会耽误这么长时间。

供应商不力之“坎”

笔者20多年来所学到的教训之一是大公司不一定就等于高质量。笔者前几年遇到过一个也可以称之为数字化转型的大项目，这个项目在业内是很有名的。项目的供应商是国际知名软件公司和国内某知名互联网大厂，可在项目实施时才发现，这些公司把项目的实施工作层层转包给他们的生态公司，甚至是社会上的小外包公司，导致大家原本寄以厚望的“白富美”项目做成了“矮矬穷”的效果。

代码随意之“坎”

IT业把程序员戏称为“码农”，那是因为很多程序员所做的工作在形式上就像建筑行业砌墙的泥瓦匠。同样是堆砌，泥瓦匠堆砌的是砖头，程序员堆砌的是代码。在没有钢筋混凝土做框架和固定的时代，砌墙是一个很难的技术活；如果砌得不好的话，墙是很可能会塌掉的，程序员写代码也是这个道理。有些程序员写代码，要么只考虑功能的实现而不考虑代码的复用，要么只考虑眼前的需求不考虑未来的扩展，要么只考虑正向流程而不考虑逆向操作，要么是无意中给软件留下这样或那样的后门。

测试不全之“坎”

本质上，软件测试是为程序员的代码质量再做个验证，是帮程序员发现和扫除代码中的“雷”。但是，有了软件测试，就不一定能保证给软件的质量上上“保险”。如果测试人员的工作不到位，或者说测试用例不全面、不合理，软件测试依然会留下很多漏洞，软件的质量依然无法保证。

版本发布之“坎”

有首歌的歌名叫“都是月亮惹的祸”，这句话如果借用到IT运维领域，很多运维工程师会说，昨天运行得还好好的系统突然不正常了，那往往是版本发布惹的祸。新的软件版本本来是为了让现有软件的功能更强大或是修复系统中现存的某些Bugs。但如果新版本的逻辑设计有问题，或是测试不充分，带病上阵的新版本就可能给现有系统带来伤害。

错误操作之“坎”

数字化工作中最让人无语的是因为错误操作所导致的“坎”。比如说，因为心不在焉或精神不在状态，把某条记录给删了，把某个数据库表给删了，把某个用户的账号给删了，导入了错误的数据，等等。错误操作中负面影响最大的要算是系统管理员的误操作，故而尤其要予以杜绝。

应急缺失之“坎”

即使是千防万防，也不一定能保证万无一失；因此，对于某个重要时刻或是重大事情，为了保证IT服务的连续性，一定要做好应急预案。笔者有一次就碰到过这样一个事件，CCTV1新闻联播中对笔者所在的企业有一个重要的正面报道，而那天正值全公司的干部开大会，大会有一项议程是全员收看新闻联播某个时段的新闻播报。新闻播报前，IT部门做了各种检查以保证网络的通畅。结果，正当一帮领导全神贯注地盯着电脑所投出来的屏幕等待播报时，正好到了那个时段，好死不死的，网络突然卡死了，电脑上收看不了新闻联播；然后，后果你们懂的……

如何规避数字化的“坎”

要想彻底，或是最大限度地规避数字化中的各种“坎”，我们可以采取“倒叙法”的方式来阐述具体的做法；总体上，它们遵循的也是PDCA管理循环，只不过，是从“A”做起，然后再去完善“P”、“D”和“C”。

首次，做好各种数字化之“坎”的记录。

医生看病要做好病情的诊断记录，以详细描述病人出现了何种症状，症状的持续时间有多长，犯病时患者的饮食起居睡眠大小便等如何，可能是什么原因导致的，医生建议服用何药或采用何种治疗，等等。诊断记录当然不只是用于看病时医生和化验室、药房、护士等之间的交流，它其实还能起到非常重要的备查和追溯等作用。如果用药或治疗有效果，那就可以作为成功经验，供其他医生在治疗同类疾病时参考。

做好数字化之“坎”的各种记录，其意义也在于此，而且记录得越详细越好。当前，很多人只是把这些记录当成短期的问题闭环机制，用于跟踪和督促问题的快速处理。实际上，它的用处可大了，基本上是后文中建立其他预防机制的基础，可以起到非常重要的参考作用。

其次，把问题记录转化为风险预防计划。

企业经营管理实践中所存在的问题及其解决办法，很多其实是相通的。就拿数字化之“坎”的预防来说，软件和IT服务行业当然有很多好的作法，而其他传统行业，比如汽车行业的作法同样值得借鉴。

在汽车行业的质量管理领域，有一个非常重要的管理工具叫FEMA（FailureModeandEffectAnalysis，失效模式和效果分析）；根据应用场景的不同，FEMA又可分为DFEMA（设计FEMA）和PFEMA（过程FEMA），分别用于产品设计环节和开发、制造等环节的风险识别和预防。

参考FEMA的理念，我们可以将数字化之“坎”的记录信息进行分类和整理，并将之转化为风险预防计划。这样一来，我们就可以在各种数字化之“坎”生成或爆发之前就将它们规避掉。

再次，通过管控体系来进行过程控制。

软件工程和IT服务领域有很多的管控体系，它们其实就是前人的教训提炼和经验总结，学习和使用好这些管控体系，就可以帮助我们来规避各种数字化之“坎”。

在这些管控体系中，最基本也是最重要的有：IT规划体系（ZachmanFrameworkforEA、TOGAF、BSP、SST等）、项目管理体系（PMP/PMBOK）、软件开发管理体系（CMMI）、IT服务管理体系（ITIL），等等。要想规避掉数字化之“坎”，学好、用好这些体系是最基本的要求。

以项目管理为例，我们前面不是说过因为需求不明所导致的“坎”吗，针对这种情况，项目管理体系就要求我们在需求收集之前要识别出项目干系人。干系人里有的是赞助人，有的是管理者，有的是IT系统的用户，他（她）们对数字化建设的诉求是不一样的；如果我们只是征求IT系统用户的意见所做出来的需求肯定是不完整的。

再以应急响应为例，根据IT服务管理体系的要求，企业要定期进行业务连续性测试，并对测试中所暴露的问题进行整改；可实际情况又是怎样呢？有多少企业会定期做业务连续性测试呢？根据笔者的了解，很少，很少。

要想管理体系发挥其作用，就必须把管理体系的内容转化为保准操作过程（SOP）或管理制度。比如，在做系统维护时，SOP要求要通过堡垒机来维护，还要采取双系统管理员制度：主系统管理员负责指令的录入，辅系统管理员负责录入指令的校对。又比如，为了防止错误版本发布而导致系统不能正常运行，SOP规定新版本发布前必须做内部或定向的小规模试运行，且新版本发布的时间必须是周六的23时~周日的凌晨3时之间，等等。

通过标准操作过程或管理制度来规避数字化之“坎”的做法，笔者称之为“管理归零”。

再次，建立完善的测试和验证能力。

任何人都不可能生而知之，也不可能只通过书本知识就能解决所有的问题。尤其是快速变化的数字化时代，新技术、新情况、新问题的变化和迭代实在是太快。能够提前预防并把风险消除于无形当然是极好的，如果这点做不到或做不充分的话，就要好做过程中的风险预防和问题管理，这就需要有完善的测试和验证等能力作保障。

在质量保证体系中，测试（Testing）和验证（VerificationandValidation）所讲的不是一回事。测试是根据测试用例的要求来看软件是否实现了设计规格书所设定的要求，而验证则是检查软件功能是否与需求相匹配。大体上，测试帮助我们正确地做事情，验证是确保我们做正确地事情。

软件的测试工作要想做到全面、有效，取决于测试用例的编写是否完整，是否涵盖了所有的应用场景，测试的逻辑是否正确（这类似于逻辑学上的批判性思维），是为了风险规避或问题的发现去做测试，还是只是为了测试而测试？

如何确保测试用例的质量呢？这就要有丰富的历史问题记录作参考。我们甚至可以这么说，对软件工程而言，测试用例就是企业非常重要的无形资产，是企业的Know-how。

在验证能力的建设方面，所包含的内容也非常广，比如快速原型的制作能力、虚拟验证能力、沙盘推演，等等，这也是个很大的课题，有兴趣的读者可以自行查找相关资料。

再次，可装配的应用架构和设计。

和其他行业的质量管理相类似，数字化之“坎”的雏形大多是在框架或软件设计环节就埋下了。为此，我们才提倡可装配（可配置）的应用架构和软件设计，具体的做法就是SOA、微服务，以及所谓的中台，等等。这时，笔者再借用三易之法的说法，以所谓的变易、简易和不易，来谈谈可装配的应用架构背后的哲学思想。

变易或变化，指的是数字化需求。不同的行业，同一行业的不同企业，同一企业的不同阶段，其数字化需求都是不一样的。针对这些需求，采用完全从无到有的方式来做显然是不行的，一者是不经济，二者是实现的周期太长和响应速度太慢。正确的是做法是继承式创新，关键在于继承什么和怎么继承？创新什么和怎么创新？

需要继承的是什么呢？具体来说，是数字化的基本构件（buildingblocks），它们就像盖房子的砖、瓦或钢筋。微服务就是数字化的基本构件。通过微服务，我们可以把某个程序块的内部逻辑封装起来，其他服务只需通过接口调用，就可以实现服务之间的协同，这就是所谓的不易，也就是标准化。

应用架构对微服务的基本要求是服务内部的功能高内聚，以及不同服务之间的关系低耦合。这样一来，我们就可以通过关系的修改或调整，来做各种微服务的灵活组合，从而满足快速多变的数字化需求。对数字化基本构件之间的关系做灵活的调整和适配，而无需影响或改变基本构件内部的代码和逻辑，这就是所谓的简变。

与推到重来或从无到有式的做法相比较，以三易之法做指导的可装配的应用架构或软件设计，在满足多变的数字化需求时所做的改动要少得多，简单得多，出错的几率也小得多，从而可以大幅度地规避各种数字化之“坎”，笔者称之为数字化之“坎”的“技术归零”。

小结

如果借用双因素理论来形容数字化建设，数字化创新是“激励因素”，类似于足球运动的进球员；数字化保障是“保健因素”，类似于足球运动的守门员；对于完整和高质量的数字化建设来说，这两者都不可或缺。如果只会进攻而不会防守，那数字化之“坎”一定是层出不穷，数字化建设的成效就将大打折扣，数字化之“坎”所引起的“救火行动”必将消耗掉大量的数字化资源，企业实际上也不可能有足够资源去做数字化创新。

另外，经常看到有人在媒体上疑问：数字化转型的浪潮中，CIO或IT经理们是不是要边缘化，甚至是不再需要？如果从数字化保障，从数字化之“坎”的规避等层面来看，CIO或IT经理们是不可能被边缘化。这是因为，做好数字化质量保障工作，需要的是丰富的软件工程和IT服务管理经验，需要有系统而全面的工程思维和架构能力，而这些经验，这些能力，显然不可能通过突击或在短时间内就能建立起来；实际上，业务部门的领导们或所谓的数字化转型领导者可能也不屑于去掌握它们。因此，企业的数字化转型至少是需要CIO或IT经理们以其丰富的软件工程能力和IT服务经验来保驾护航。

转载请注明：http://www.jinyawz.com/zflzy/10718.html