“变得数字化”实际上是什么意思？-InfoQ

主要结论

变得数字化已经成为一个势在必行的目标

变得数字化需要将客户置于一切工作的中心

变得数字化意味着要打造更优质的服务

变得数字化并不是要变得偏向于技术本身

成功的数字化转型需要具备恰当的人员

我刚刚采访完一位架构师。采访中我问了一个自己最喜欢的问题：“变得数字化到底有什么意义？”类似的问题我们也经常听到，人们本应该对“数字化”这个概念理解得更充分，但实际上并非如此。在大量不同情景下把这个问题问过多遍后，我可以很确信地说，大家对这个概念还没有达成统一共识。实际上很多时候大家被问及这个问题后，更多的表现是困惑或盲目的恐慌。大家似乎突然之间发现，虽然已经把工作搬到了数字化环境中，嘴上将数字化转型称作自己最重要的目标，但脑海中甚至对数字化转型没有一个清晰的定义。他们的数字化旅途始于将原本线下的服务迁移到线上……但过去 15-20 年来我们不是一直都在这么做吗？

对于抛出这样一个棘手的问题，我感觉有些愧疚。同时我也觉得，如果没有经过彻底的深思熟虑，自己被问到这个问题后一样会感受到相同的恐慌。有时候，无法清晰表达出数字化转型的真实含义，并不一定说明对方真的没想过这个问题。但以我在网上的声誉打赌，我敢说，无论过去或现在，我的大部分同事也是这样的，他们也许无法给出清晰的定义，但正在朝着这个目标努力。

但是充分理解数字化，明确数字化是什么以及不是什么，对于这些能力也不能掉以轻心。毕竟我们需要向股东、董事长、CEO、CTO、分析师、开发者、架构师，以及其他所有有关人员解释这些概念。同样重要的是明确数字化转型成功的标准是什么。而充分理解变得数字化的具体定义，理解数字化这个概念本身，至少可以确定出正确的方向。

那么如何才能“变得数字化”？组织如何能实现数字化转型并从中获益？

本次采访对这些问题提供了很棒的答案。

字典上的定义

先来看看字典上对于“数字化”是这么说的吧：

形容词：数字化

以一系列数字 0 和 1 的形式呈现（的信号或数据），通常由电压或磁性极化强度等物理量的值所代表。

以数字信号的方式关联、使用，或存储数据或信息。
需要或涉及计算机技术的使用。

最后一条解释很有趣对吧！或大或小不同规模的组织使用“计算机技术”已有数十年的历史，如果这就是“数字化”的含义，那么现在的组织为何还要花费大量时间和精力进行数字化转型？很多东西字典是无法给出足够解释的。

我在 2016 年对“数字化”的定义

“变得数字化”实际上就是对业务过程进行的重塑，通过重塑使其默认就更加适应更全面的在线环境，从最终用户的接触到后端的办公室工作，全面实现无需人工介入的过程自动化。

为何要变得数字化

任何组织都应该首先问问自己这个问题。通往数字化的道路并不是免费的……需要大量投入，因此出钱的人必须能全面理解数字化所能带来的收益。

投资回报这种东西非常难以计算，并且只能针对每家公司的具体情况分别进行衡量。原因可以列出很多条，然而最终还是要由你自己来归纳，并汇总成一点：

如果不进行数字化转型，业务就完蛋了。如果不能认真对待数字化，就会被竞争对手超越……然后业务一样会完蛋。Blockbusters 的故事你总听说过吧！（译注：Blockbusters 是一家线下的 VHS 录象带和 DVD 影碟租赁连锁店，2004 年全盛时期有 6 万员工和 8 千家店，客户横跨全北美。Netflix 曾主动提出被并购但被拒。Blockbusters 已于 2010 年破产，Netflix 如日中天。）

数字化到底是什么

客户为先的文化—你的客户是谁？他们是你数字化服务的用户。那么为什么把他们称作“客户”而非“用户”？长久以来我们都坚持“客户始终是对的”这样的心态，如果将自己的用户视作客户，无论对方是否为服务付费，那么我们就会尽一切努力吸引他们，维系他们，取悦他们。为了变得数字化，必须打造可以满足客户需求的企业文化，可以另客户获益的功能，可以快速改变客户或帮助客户降低成本的服务。无论做什么，必须将客户放在首位。
即时反馈 —在数字化世界中，客户都期待着自己的请求能够立刻获得反馈。客户不会再等待几分钟、几小时甚至数天，仅仅为了知道自己的请求是成功或失败。数字化世界的响应时间已经开始用毫秒作为单位来衡量。
实时 — 数字化系统应该能全天候接受请求，应该能按需可用，应该能使用／返回最新数据。最终一致性是一种行之有效的架构方法，但应该按照网络和自动化处理延迟，而非业务过程延迟进行衡量。
自动化 —听起来很明显，数字化服务应该包含尽可能多的计算机处理过程（最理想状况是 100% 由计算机处理），需要的人工介入越少越好。
智能 —繁琐的工作都应交给数字化服务处理，将客户或其他方面人员需要付诸的精力和所需的理解减至最低。这里说的“智能”是指服务应当能够帮助客户处理最原始的信息并进行相关运算、汇总、提炼和转换，这一切都无需用户操心。同时这种智能也意味着服务应当能预测客户的下一步操作，并提前做好准备，提供建议。
在线 — 数字化系统应该能通过互联网从任何地点访问，不应对设备和使用情况进行任何限制。
美观 — 美观的界面和构造优美的 API，数字化时代的任何服务都应具备这样的特征。某种程度来说，美观与否是观察者的主观结论，但也意味着易用、直观，以及能满足客户的需求。这意味着可以将对客户而言最重要的内容直接交付到客户面前。
推进改变 — 应该是由数字化服务定义业务过程，而非业务过程定义数字化服务。数字化意味着业务过程需要作出改变，以便适应计算的世界，而非反其道行之。绝不能用在线的方式继续沿袭以往离线时代的做法。
定期改进— 你觉得 AWS 新功能发布的频率如何？我简单统计了一下 2016 年 11 月 21 日到 2016 年 12 月 5 日之间的改动，两周时间，28 次发布！这就是 AWS，可能是全球最大规模的数字化平台。大部分客户对技术并不十分精通，他们并不清楚进行这样的软件改进做起来到底有多难……其实他们也不需要关心这些。他们只是希望能看到改进。数字化平台应该尽可能以必须的频率完善自己。

数字化不是什么

批处理 —在数字化时代，我们不应该继续依赖离线的数据馈送和调度处理。机器之间的通信应该通过 API 进行，应通过推送方式在信息可用的那一刻立即进行。这样可以确保信息始终保持最新状态。
手工处理 —数字化过程的默认形态不应包含任何人工介入或处理。任何离线的介入都应视作一种例外，例如无法使用数字化服务，或面对某些任务，机器学习／处理技术还不够成熟。例如欺诈检测，目前依然离不开人工的介入。
技术刷新 —技术并不能让你变得数字化。步入云端不能让你变得数字化。使用微服务架构不意味着你已经变得数字化了。使用 NoSQL 也不意味着数字化。如果你看到某家组织通过强调自己的技术成果表达对数字化转型进程的支持，那么也许可以假设他们的数字化之路选错方向了。

助力转型

云 —上一节内容已经明确提出：技术本身并不是数字化的目标，本节将开始（并持续不断地）介绍为什么技术的恰当选择可以帮你顺利实现数字化转型。众所周知，云计算可以帮助用户获得数字化服务所需的缩放性，以及性能和规模。云计算的背后是一套复杂的分布式系统，但可以良好配合帮你确定最正确的方向。
持续集成／持续交付 — 从我在 1999 年开始程序员的职业生涯以来，CI/CD 也许是软件开发领域最大的收获之一。当时团队和团队成员需要分别编写代码，很少进行合并，最终上线前需要多天忙碌的工作，通过繁琐的操作将大家的代码合并到一起。然后他们悲剧地发现代码无法集成并配合工作。（实际上我作为开发者参与的第一个项目甚至没有使用 VCS，但这又是另一个故事了）。CI/CD，配合定期进行（通常至少每天一次）的提交和小型（如果需要的话）合并，有助于快速安全地开发出高质量代码。团队将能有更多时间专注于开发客户真正需要的数字化功能。
敏捷 —作为一种方法论，也许并不完美。但该方法的基本原则与数字化观念相当匹配，可以促进以客户需求为基础的定期交付。不以敏捷为核心的数字化程序必须付诸更多努力才能满足转型的需求。如果敏捷方法论不可行，至少一切行事需要首先考虑到敏捷的基本原则。以人员而非资源为中心，即时（Just in time）设计，不断演化的架构。无论选择哪种方法论，这些基本原则都是适用的。
用户研究 —虽然最近才开始研究这一点，但对这方面有很多第一手体验，同时与很多非常天才和娴熟的专家有过合作，他们向我证明了只要做得对，用户研究将成为数字化服务的核心，甚至远比代码、架构、方法论更重要。用户研究可以引导你实现数字化涅槃。为什么？因为如果“用户”觉得更易用，你的服务就会更可用，被更多人所使用……最终你也会更加成功。这里用了“用户研究”而非“客户研究”这个词，因为业界就是这样称呼的。
简化设计 —作为架构师，我经常会拥护一件事：我们的设计要尽可能简洁。若非必要，不要让设计变得更复杂。不要试图去解决那种绝对不会自行显露出来的问题。网上有很多文章解释了原因，但从数字化的角度来说，简单的设计可以让每个人更加关注手头的事情，进而改善客户体验。复杂的设计意味着需要更多维护，可能出错的东西变得更多，用于确保服务正常运转所花费的时间远多于改善数字化体验所用的时间。

是时候变得数字化了

组织迈向数字化世界的旅途充满了挑战和艰辛，甚至可能存在不小的争议。在这段旅途中，肯定需要面对针对各种收益所提出的质疑，实际上你可能一开始也有不少疑问。

心态从非数字化到数字化的转变可能是其中最难的部分。任何能够屹立不倒的组织都有多年来一起同舟共济的核心员工，这些员工很了解业务，对企业很忠诚，正是这些员工树立了组织的文化和观念。然而这些员工面对变动也是最不容易动摇的，需要说服他们相信客户不是组织内部的“业务”，而是组织所提供服务的用户。他们需要习惯于每周定期发布，甚至每日发布。他们需要理解，以往的业务过程是针对巨型机的世界，而非针对互联网或智能手机创建的。那个世界中的所有查询都是通过代理程序（Agent），而非设备进行的。这样做并非因为他们缺乏智能和能力，而是因为已经获得成功，现在希望实现数字化的组织，恰恰都是曾经以某种特定方式成功过的组织，因此他们可能会问：为何还要改变？

此外还会遇到技术挑战。运行诸如云端微服务 RestFul 架构这样的分布式系统当然能获得不菲的收益，但还会在延迟、数据一致性、无状态，以及下游服务失败等方面遇到挑战。你的组织中肯定还在使用一些必不可少的遗留系统，这些系统从开发时就没有考虑过大容量低延迟事务。你的数字化战略中考虑过如何替换这类系统吗？如果考虑过，又打算如何进行切换或将数据从老系统迁移到新系统中（想想 Strangler 模式吧）。但这个过程代价不菲，因此如果不打算替换，遗留的平台又如何融入你的数字化愿景？也许数字化平台已经全面做到了实时低延迟运转，但你依然在使用古老的记录系统。

在考虑对数字化转型进行投资时，CEO、CIO，或其他 CXO 需要抓住机会将组织所获得的成功下沉到员工身上。让产品负责人的所有工作都以客户为中心，并要跳出定势进行创造性思维。理解这些信条重要性的技术和软件架构师，同时也要更深入地意识到这些信条会受到业务和客户目标，而非其他因素的驱使。开发者不能将高质量代码视作一种负担，而是应该视作创作和创新方面的自由。测试驱动的开发（TDD）可以提供最无拘无束的 Bug 修复和支持。同时业务分析师需要能够将需求解释为数字化过程，而不是反其道而行解释为离线的过程。

要想变得数字化，这本就不易，但只要具备恰当的人员和耐心，所有在时间和精力方面的投入都会获得回报。

关于本文作者

Reda Hmeid是一位自由职业技术架构师兼数字化顾问，自从 1999 年为初出茅庐的 ba.com 平台编写代码后就一直在从事数字化方面的工作。从令人望而生畏的 Java 1.4 开始编程的 Reda 非常喜爱 Java 编程语言，但最近已将关注点转向 Scala 和 NodeJS 以及其他技术。目前 Reda 在 HMRC Digital 担任解决方案主管的职位，这是英国最大的数字化程序开发公司之一。Reda 曾任职于英国航空和 IBM，德意志银行也曾是他的客户。