浅析数字化转型

大佬都在说数字化转型,但您真正理解什么就是数字化不？

充分理解数字化,明确数字化就是什么以及不就是什么,明确数字化转型成功的标准就是什么,对于一个技术领导者来说非常重要。

我刚刚采访完一位架构师。采访中我问了一个自己最喜欢的问题:“数字化转型到底有什么意义？”类似的问题我们也经常听到,人们本应该对“数字化”这个概念理解得更充分,但实际上并非如此。

在大量不同情景下把这个问题问过多遍后,我可以很确信地说,大家对这个概念还没有达成统一共识。实际上很多时候大家被问及这个问题后,更多的表现就是困惑或盲目的恐慌。

对于抛出这样一个棘手的问题,我感觉有些愧疚。同时我也觉得,如果没有经过彻底的深思熟虑,自己被问到这个问题后一样会感受到相同的恐慌。有时候,无法清晰表达出数字化转型的真实含义,并不一定说明对方真的没想过这个问题。

充分理解数字化,明确数字化就是什么以及不就是什么,对于一个架构师来说非常重要。毕竟我们需要向董事长、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修复与支持。同时业务分析师需要能够将需求解释为数字化过程,而不就是反其道而行解释为离线的过程。

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