阿里、蚂蚁、晟腾、中科加禾精彩分享 AI 基础设施洞见,现购票可享受 9 折优惠 |AICon 了解详情
写点什么

数字化转型迷思

  • 2021-06-15
  • 本文字数:14289 字

    阅读完需:约 47 分钟

数字化转型迷思

数字化转型是国家级大风口、史诗级大转型。错过了移动互联网的风口,那企业该如何抓住数字化转型的机遇?


其实这个标题并不妥,因为国家政策已经指明了数字化转型方向,而且一系列对数字化转型基础设施建设非常重要的文件已经陆续出台,除了今年三月份最为重要的、超过 5 万字的《中华人民共和国国民经济和社会发展第十四个五年规划和 2035 年远景目标纲要》(以下简称“纲要”)全文外,《中华人民共和国数据安全法(草案)》、《关于加快构建全国一体化大数据中心协同创新体系的指导意见》、《全国一体化大数据中心协同创新体系算力枢纽实施方案》等对全社会数字化底盘构建意义重大的法规、文件也相继问世,加上各部委、各地区出台的“十四五规划”,面对国家如此快速地推进数字化建设,事实上,数字化转型已经不应当再用“迷思”这个词了。但是,对于很多企业而言,受各种主客观条件制约,还无法迅速、切实理解新的发展方向。

 

一、迷思的原因

 

为什么政策如此明确还是有很多企业会有疑问,搞不清什么是数字化呢?笔者认为,这是由于两个“双期叠加”造成的困扰。

 

(一)信息化与数字化的双期叠加

 

笔者 2020 年在《银行数字化转型》一书中对信息化和数字化的定义分别做了阐述,其中信息化定义引用了国际公认的日本学者梅棹忠夫(Tadao Umesao)于 1963 年提出来的定义,“信息化是指通信现代化、计算机化和行为合理化的总称”,其中,行为合理化是指人类按公认的合理准则与规范行事;通信现代化是指社会活动中的信息交流基于现代通信技术基础上进行的过程;计算机化是社会组织和组织间信息的产生、存储、处理(或控制)、传递等广泛采用先进计算机技术和设备管理的过程,而现代通信技术是在计算机控制与管理下实现的。因此,社会计算机化的程度是衡量社会是否进入信息化的一个重要标志。

 

数字化定义则是笔者自己提出的,“数字化是指通过各类手段,将人类行为最大限度的向虚拟空间转移,并在虚拟空间中完成与物理世界的必要互动,这其中,数字化技术将起到关键性作用,因为数字化技术是最主要的生产力”,“数字化应当保证人能够在虚拟空间中获得与物理世界相同甚至更好的体验;数字化的目的是最大限度地赋能个人,打破空间限制,形成有史以来最为灵活的生产组织形式、社会活动方式;数字化转型指的是从当前信息化环境下的人类行为、组织形态向数字化环境下的人类行为、组织形态的转变过程”。笔者后来又将数字时代的技术特征归结为智能体验类技术和虚拟空间的持续扩展。

 

在笔者看来,数字化是信息化的“第二曲线”,这意味着,技术角度,数字化有对信息化大量的继承,今天我们广泛谈到的人工智能、大数据、云计算、区块链、边缘计算等等,是信息化技术也是数字化技术,而数字化和信息化主要区别在于“体验”和“效率”的提升,这一点又来自于虚拟空间对物理空间限制打破能力的持续增强,“数字化是信息化基础上的延续,是基于信息化的成果产生的,更强调的是虚拟化,或者称之为‘数字孪生’,也就是通过数字化技术对人类社会的仿真,是将物理世界‘数字化’。从工程的角度讲,信息化阶段更关注‘实现’,而数字化阶段应更关注‘现实’,是科技与社会更深度的融合” 。

 

但是这就造成了一个问题,因为很多企业信息化建设尚不充分,对信息化的理解、对企业应该信息化到什么程度尚未形成准确的认知,然后数字化的发展理念已经涌进了大脑,这确实会造成一定的迷思,甚至让企业产生可以忽略基础建设,直接“跨越式发展”错觉。同时,由于一些对数字化的宣传、讲解似乎看不出来二者的区别,也加大了很多企业疑惑。

 


(二)生态连接与超级体验的双期叠加

 

如果在信息化和数字化之间增加一个小周期的话,那非“移动互联网”时期莫属了,智能手机和互联网的合璧之作,让掌间的方寸之地串联起了整个世界,移动电子商务几乎渗透了绝大部分行业,不只是外卖、打车,连业务管理非常严格的企业和银行之间也可以通过手机处理业务,“云钉一体”这类互联网移动办公服务覆盖了更多的商务场景。很多企业刚刚被“连接”改变世界“洗脑”,认为“一切都值得用移动互联网”重做一遍。

 

然而,这个决心刚刚建立不久,毕竟,从 2010 年开始算,移动互联网也刚刚走过自己的“黄金十年”。接着,除了笔者书中主张的“虚拟空间”、较早在金融领域提出“数字孪生”,强调关注体验外,2020 年底腾讯的“全真互联网”、2021 年 3 月华为提到的“超现实体验”,这些从 2D 向 3D 的突进设想在大厂也已经轰然而至了。确实,跟 3D 体验比,今天的移动端产品更像是以对颈椎的“体罚”来交换内容上的“体验”,上升不到真正的“感觉”层面,还得以“脑补”居多。

 

如同信息化一样,很多企业的移动化生态连接刚刚起步,立足未稳,超级体验又来了,为“连接”而发起的“重做”还没完成,是不是又要着手为“体验”重做了?

 


这两个“双期叠加”确实让企业困惑,信息化还没深入,已经被“带节奏”开始做基于移动互联网的“连接”,接着,以智能化超级体验和虚拟空间活动为基础的数字化又已经开始加速了,而且还是国家级的加速,不是单纯的商业概念,不得不让很多人感慨,时代变化太快了。

 

其实在这两个“双期叠加”的背后,还有很多国家在治理方面的思考,这些也是当前数字化进程明显加快的原因,比如对待“卡脖子”问题、公平竞争问题、经济增长模式转型问题等等,更多的思考可以认真学习国家政策。笔者始终认为,数字化转型不仅仅是一个企业自己的事情,所以企业也不能仅仅盯着自己内部做数字化,不关注国家政策,再勤奋也有“跑输大盘”的可能性,而我国基础设施建设能力和速度是有目共睹的,即便是数字化基础设施,也一样有能力快速推进。

 

二、如何在思维层面破除迷思

 

迷思,顾名思义,首先就是思维层面的“迷”,这是看数字化的“姿势”问题,要破除对数字化认知的“迷思”应该先从思维层面开始。笔者甚至认为,各企业、各位读者应该把今年当做数字化“启蒙年”,认真研读国家政策,认真回顾信息化、移动互联网发展过程,认真思考自己企业选择什么样的数字化方向,思考自己锻炼什么样的数字化技能,认真想想到底该怎么看待数字化,好好想一年,想到明年也行,这是一场时代切换的转型马拉松,对于大部分企业和个人来讲,不需要用百米冲刺的速度去践行数字化,而是把方向想明白,再坚定、灵活地走下去。

 

笔者认为,可以多尝试辩证地思考以下问题,真正把思维整理清楚。

 

(一)是该务虚还是务实地看待数字化

 

如笔者前文所述,今年先务虚地看待数字化。数字化是企业转型,它可以是个战略,不像有些人讲的,数字化就不该是战略,只是工具。战略就是凝聚行动的,而凝聚行动需要一个直观甚至是热门的词,让大家快速聚焦,“数字化”如今绝对担得起这个大任,毕竟,战略的关键是想清楚自己要干啥,而不是它叫啥。所以,不必教条地对待“口号”,让大家动起来的“口号”就是好“口号”。

 

务虚也要务的明白,什么是务的明白呢?就是企业内部达成一致认知,形成企业意识。所以,笔者建议企业搞清楚“数字化”的通识,国资委文件中倡导“一把手”带头讲数字化,这是很有必要的,如果领导者没有在通识上搞清楚,那是没法带领企业朝一个方向去聚集力量的。当然,这不是要领导们把数字化技术都搞个通透,其实很多架构师也没办法覆盖这么宽,但是数字化的发展趋势,架设起来的未来方向,尤其是与国家政策推进方向一致的认知,必须要在企业领导层建立起来。

 

“全国一盘棋”,每个企业都在棋盘上,棋盘的变化,是影响所有人的。时代的切换,需要所有人积极行动,“搭便车”的思维适合在每个时代的中期,也就是环境相对稳定、容易预判方向的时候,而在过渡期,只想着“搭便车”,需要的就是高度的运气了,不然很容易“搭错车”。所以,真希望借力“顺流而下”地走向数字化,是需要很好地解读国家政策才做得到的。这就是今年先务虚的必要性。至少未来十五年,数字化转型中必备的一项重要能力就是政策解读能力。

 

务虚之后才是务实,每个企业的务实方向在“纲要”中都有所指,地方政府和部委配套措施到位之后,企业可以有很好的政策支持去开展自己的“务实”。“务实”的最终目标就是客户体验,“高品质”生活。这不是只有 C 端企业才需要考虑的,对于 B 端企业,客户的客户就是你的客户,最终都会传导到 C 端,整个社会就是一个“P(个人)-C(消费)-B(供给)-F(金融)-G(政府治理)”的生态循环,每个企业所谓的“务实”,都是在这个大生态循环中定位自己的小生态循环,服务好你的客户,最终服务好老百姓。

 

数字化的演进方向也是如此,通过技术让生态循环更顺畅、让老百姓体验更好。如果老百姓没有感知,那对数字化的所有定义都没有什么落脚点了,搞一堆太高深的技术定义没有必要,体验应该是检验数字化的唯一标准,也就是数字化时代的生活、工作跟当前信息化、移动互联网时代相比是什么区别,这也是时代改变的最终检验方式,是务虚也是务实,这与直接告诉企业该怎么改变不一样,而是要企业先想要去改变什么、创造什么。这个事情以前是很难的,因为很少有企业有机会遇到“纲要”这种又全面、又长期的指导文件,这是“好风凭借力,送我上青云”的机会。

 

(二)该长期还是短期地看待数字化

 

必须是长期的,“纲要”面向未来十五年,所以,数字化一定是长期的。那问题就转化到怎么分阶段看待数字化,而这个又得回到数字化很能会怎么演进这个问题了。

 

笔者把这个时间段看的较长,分成“信息化”和“数字化”两个阶段,“信息化”下又分成“组件化”、“自动化”、“数智化”三个阶段,每个阶段五年,之后才是全面的数字化。之所以这么分,其实是从目标倒推回来的,因为要想实现高度发达的数字化生产、生活方式,我们需要先实现人工智能和大数据的广泛应用,这个阶段就是笔者说的“数智化”,大数据加人工智能。

 

但是这个阶段实现的前提是流程首先能够自动化,只有流程充分自动化了,大数据加人工智能才能更好地发挥作用,全是断点的流程,把大数据和人工智能放进来也不会有什么出奇的效果。流程自动化是很重要的基础,而实现全流程自动化对目前很多企业来讲还有很大距离。对于这一点可能也有人会有疑问,要不要实现这样的自动化,有必要吗?这其实不是一个问题,就像问在工业化社会到底要不要实现机械化农业一样,这是生产工具的自然进化,太较真儿的思考这个问题,试图精确地给技术应用画个边界确实没什么必要。

 

但是自动化也是有前提条件的,就是基于组件的流程标准化和数据标准化,没有这两个标准化,高度自动化的业务系统是很难形成和管理的。今天在企业端开发中已经“横行”了五六十年的“孤岛问题”,未来就是我们搞自动化最大的障碍和隐患,这也是 RPA 最近比较流行的原因之一,但是面向未来,RPA 应该成为一个泛化的设计理念而不仅仅是技术实现方式,也就是说,每个系统都应该做好自己的标准化,把自己做成 RPA。不过,这件事说起来容易做起来麻烦,需要很好的设计自律。当前软件行业对“快”的追求,即促进了自己的发展,也把自己局限在“大规模小团队手工作坊”的困境中。不能够充分发挥标准化的作用,已经成为了软件行业,乃至几乎所有应用软件的行业前进的瓶颈,这不应当称为创造力的体现,而是行业不成熟的体现。

 

很多企业即便对于笔者说的“组件化”这个阶段而言,也仅仅处于起步状态,如果认真做,确实每段都需要三至五年左右,因为每一段对企业而言都意味着一次架构重构,这里边还包含着对业务流程和业务组织的重构,尤其是到数智化阶段,这个时候才是人和机器重新分工的开始。自动化阶段,人机分工还比较清晰,只是重复劳动的替代,而数智化的替代可以有更宽的范围,这意味着就不再是替代这个概念,而是真正的分工概念,系统逐渐成长为助手型系统。

 

经历过这十五年,企业的信息化深化才可能完成,真正进入笔者定义的“数字化”阶段,这也是笔者经常说现在并没有很好的“数字化”企业范例可以借鉴的原因。不过,关于进入“数字化”阶段的这个说法,读者不要简单的“线性”理解,因为很多“数字化”理念和技术不是只有这时才会出现,而是在信息化深化阶段已经出现,甚至有可能具备一定的成熟度,只是到数字化阶段才有条件广泛应用。

 

正因为如此,企业也不要急于对标,而是多做些独立思考,数字时代既然是体验时代,那模仿的价值会大幅度降低,而个性化的价值大幅度上升,这不仅是差异化的问题,而是企业有多了解客户的问题,有在客户身上花费多大精力的问题,没有这种投入,就没有好的产品出现,也就会失去“入口”的位置,成为“被调用方”,成为“被调用方”并不是不好,只是“入口”的附加价值更大,毕竟,“入口”永远是少量的。

 

综上,数字化是要长期看的,但是眼前要做的事情很清楚,也很麻烦,就是把企业自己的流程和数据管好,这对很多企业都通用,金融、制造、物流、旅游等等,因为所有这些行业都在提升自动化水平,即便互联网企业,成长到一定规模也离不开内部的规范化,无论是人员还是系统。离开了企业治理、数据治理,不会有理想的数字化转型,先把眼前缺的课补好吧,无论有多羡慕科技企业,都应该明白,苹果公司最强大的武器是供应链管理而不只是“黑科技”,否则,就算乔布斯在世的时候,苹果也差点儿消失。

 

搞数字化一点儿也不神秘,而且,离开这些看似很“low”的业务线上化、流程标准化、数据标准化,企业根本无从走向最终的数字化。

(三)该从明确的价值还是趋势上看待数字化

 

当年最早做信息化的企业到底是从趋势还是价值的角度看待信息化的?也许无从考证,但是,笔者的经验是,信息化最大的特点就是花费好算,价值不好算,这对数字化也一样。笔者自己从事的企业架构、业务架构工作更是如此,很多人觉得有价值,但从来没有人算清楚它的价值;很多人批评它,往往指向的就是不知道对企业的价值但很清楚企业的花费,尽管这些花费中相当一部分即便不搞企业架构也会换个方式花出去,并不会真的省下来。

 

算不清就不要算了,因为这就说明在这种事情上谈明确的价值本身就是不可行的,这是问题导向和趋势导向的,不是明确的可计量的价值导向。无论怎么做,都没有人能拍着胸脯担保做个系统能增长多少业务量,毕竟多数业务系统本身不是产品,而且,传统企业往往不会做一个全孤立的产品系统,以便去衡量它的产出,系统跟系统之间早晚要产生基于企业业务的联系。互联网企业做一个全孤立的产品系统也越来越难了,所以才有互联网中台的出现。

 

很多企业曾感慨自己错过了移动互联网的风口,没做大,成了“被调用方”,场景不在自己手里。那当年为啥错过,是太糊涂还是价值论的太明白?以至于让别人抢先了,实现手段对大家都是平等的,技术就摆在那里,谁都看得见,早鸟最多也就早起了半个小时,但是当早鸟都飞远了才看见飞过的距离和代表的价值,那样的价值,论明白了也没啥用了。如今这一幕可能又会出现在数字化和超级体验上,而且搞不好还是双期叠加的落后。

 

当然,数字化转型这件事情,如果劝企业不顾一切地投入,肯定是不负责任的,就算是笔者自己做企业架构也经常跟客户说“问题决定工具”,而不是简单地就是劝客户去做。对于舍不得投入、看不清价值的企业,那就慢点儿做吧,多注意环境的变化,毕竟有数年时间可以观察,如果环境变化太快,就别再算账了,算清了小算盘,打输了大算盘,是不会有个“重启”键可用的。做自己力所能及的最大改变,持续地做下去,毕竟,做企业本来就不太可能靠“躺平”活下去,无非是怎么折腾自己好点儿。

 

如果实在执著于算账,那也可以想想笔者前边讲过的第二曲线,毕竟企业目前要做的第一曲线上的工作还很多,这方面可借鉴的做法也是有的,第一曲线适合算算账。而第二曲线,企业要自己多想想明白,哪些事情要放在第二曲线上,这条曲线不适合清清楚楚地算账,需要些创业者视角。把曲线划分这件事情做好也不简单,需要管理层有良好的战略思维,因为,第一、第二曲线上都有战略部分,而战略部分往往都不适合算账。

 

这方面,《EDGE:价值驱动的数字化转型》一书中有个观点很值得参考,“可以考虑将客户价值和速度/适应性视为主要目标,将 ROI 和成本/效率视为限制因素”,通俗地讲,就是在可以承受的最大限度内,从客户价值和提升企业能力上看待数字化成本,而不是简单地看投入产出。其实,很多转型都是个思维方式、是个态度的转型,笔者一直认为,转型转的就是人的行为方式,而检验转型最简单方法也是这个,没有新的行为方式,就根本谈不上做了转型。

 

(四)该从整体上还是局部上看待数字化

 

这个问题在笔者从事的企业架构领域中也一直有此类问题,是不是可以在局部上尝试企业级?能不能简化点儿做企业级?结合上一个问题,很多企业想的也是,能不能先做一个点看看数字化的效果?

 

这个问题很难回答,或者说很难说服有疑虑的人,这也许跟思维模式有一定关系。

 

笔者是一个坚定的全局主义者。笔者在以往做过的企业架构设计中,也偏重整体设计,基于整体去看待局部设计,自己也曾经以“PDCA”模型为指导,两天完成过一个新领域的基础设计,都是自上而下逻辑推导的。所以,骨子里,笔者相信,没有一个好的整体设计或者整体视图在脑子里,也很难通过点上的尝试去获取该不该做一个全局改变的参考。“问题决定工具”也是这个意思,全局问题很难用局部工具解决,不然在“竖井式”开发之外,为什么要诞生“企业级”开发这个方式?

 

这也像军事战术上的火力侦察,通过火力试探找到对方防线弱点进行突破,但是,这种火力侦察的背后是己方军队的部署和展开已经基本完成,只是在选择突破点,决定全军的进攻路线,否则,火力侦察下来,半天没行动,不但可能暴露意图,敌方自己也可能知道缺点了。而很多企业做试点的时候,并没有这种全局动员在背后做支撑,企业并没有做好跟进的准备,仅仅是在“尝试”,这很难会有什么真正的效果。

 

也有很多企业把“特种部队”作为“敏捷”的象征,希望自己从业务到技术都能够像“海豹小队”一样灵活强悍,但是,企业忽略掉的是,“海豹小队”后边有航母舰队、有庞大的作战指挥系统在做支持,是“地海空天”一体的作战指挥系统,而对这套系统的建设努力,已经持续 30 年以上了,只不过“高光时刻”落在了“海豹小队”身上。没有这些,“海豹小队”可能派出去就回不来了。

 

所以,点上的数字化尝试,如果没有一个全盘的设想做基础,是很难评价其结果的,是不是碰巧有了好结果?好结果有推广潜力吗?更何况,好多企业也不区分清楚自己的试点到底是在做信息化还是数字化。而没有一个全局推动的计划或者准备跟在后边,突破也有被浪费的可能。

 

自古以来,军队最不愿意打遭遇战,最愿意打伏击战,或者更进一步说,更愿意通过策略不战而胜,所以,还是不要带着疑虑的心,总抱着试试看的想法去对待一个即将成为趋势的事情,还是多研究研究,打有准备之仗吧,“多算胜少算,而况于无算乎”。

 

(五)该从信念上还是投机上看待数字化

 

作为一个长期国家政策而言,所有人都应当从信念上去看待数字化,这是国家新发展理念的一部分,或者说重要实现策略。“纲要”是凝聚了众多人的智慧和调研形成的,其知识密度是需要一定时间去学习的,笔者认为,在叙述具体转型方向上,文中每一句都能够代表一个细分市场,蕴含大量市场机遇,是很多企业和个人可以努力的方向。

 

数字化部分在“纲要”是一个独立章节,超过 3000 多字,可以从中认真体会数字化转型方向,并寻找企业长期的市场机会与发展目标,再为此做数字化转型。按照笔者主张的“战略转型-架构转型-技术转型-业务转型”这个数字化转型通用套路,将企业战略和国家战略、地区战略、行业战略叠加起来,确立自己的方向,根据这个方向在通过企业架构方法分解转型战略,落实到技术转型和业务转型上。但这是路径,不是答案,答案要自己找,而找答案应该先从信念出发,你相信什么?为了信念要去做什么?以数字中国、数字社会、高品质数字生活的愿景为目标,为了这个提升企业能力,这才是该做的数字化转型,否则就变成了一堆不明就里、云山雾罩的技术采购、技术升级,做了很多却不知道路在哪里。数字化转型不是无路可循、无迹可循的。

 


既然要从信念上看待数字化,就尽量不要从投机的角度看待数字化了,虽然这在商业层面很难避免,毕竟很多负责提供技术产品、技术服务的企业需要在这个标题下包装自己的产品,甚至为此“大打出手”,但只要不过度包装、不偏颇讨论就没问题。要将对数字化的认知统一到国家政策上来,将分阶段可以实现的技术目标说清楚,比如,根据企业实际情况判断企业该把组件化做到什么程度,之后把自动化做到什么程度,再把数智化做到什么程度,不要一上来就“跨越式发展”、“银弹式推销”。特别重要的是,不要仅仅赋予企业工具,未来大家都是数字化企业,都需要一定的自主研发能力,帮助企业培养队伍、搞好方法论建设才是对客户的长程陪伴。数字化转型之路是长跑,谁是真伙伴,谁是假朋友,什么是吐槽,什么是道理,什么真有用,什么真没用,时间长了,大家都分得出来。

 

(六)该简单要答案还是自己多探索

 

笔者目前在咨询行业工作,从业务角度来讲,企业都来要答案才是最好的,但是,没有人能给所有人提供答案,没有全知全能的人,只有持续地探索和思考。

 

企业要适应的环境千差万别,同一个行业内不同规模的企业、相同规模不同地区的企业、相同地区不同管理风格的企业,都有差别,所以,数字化转型通用路径有,大方向也有,但是到每个企业的具体操作却是不同的。

 

笔者是做企业架构设计的,最常说的一句话就是,别把别人家的架构拿过来直接套在自己身上,所以笔者并不看重对标,因为多数企业仅能从标杆企业身上获得一点儿灵感,详细的做法即搞不懂也未必学得了。即便你找到了标杆企业本尊,能手把手地教你,也未必真会向华为当时引入 IBM 那样“削足适履”地去学,真“削”起来就没那么容易了。

 

既然无法这样做是普遍的,那企业就要把精力放在自己身上,不要简单地去要答案,而是自己多探索,咨询最大的价值是对咨询对象能力的提升,这种提升不是单单搬进某种做法、某种思路,而是在咨询过程中逐步培养应用方法论去出找答案的能力。“1+1=2”这个结果很简单,但是,无论从应用还是从理论层面而言,想出来“1+1=2”的过程才是真正困难的,也是所谓的核心竞争力。

 

此外,数字化是个性化时代,需求也是个性化的,但是为了适应这种个性化,我们最需要的却是在规模化、标准化中融入个性化,这是非常矛盾又非常正确的要求,软件行业跟工业化的发展路径没有什么本质区别,都要通过这种看似矛盾的做法解决大规模的需求。要想能够在这种矛盾中前进,是没法总靠别人给答案的,还是要自己多探索,加强自己的设计能力,尤其是整体设计能力。不然,企业自己独立存在的价值又该如何回答呢?

 

(七)对数字化转型而言逻辑与实操哪个更重要

 

一般都会说两个都重要,这很讨巧,也是事实,但是在当前这个短暂的时间窗口里,笔者认为逻辑更重要,因为这是个短暂的务虚阶段,逻辑与实操如同人的两条腿,走路总是会交替前进的,目前是逻辑该先迈出一步。

 

现在大家还有些搞不清数字化转型是啥,“只管低头走路,不管抬头看天”应该是不对的,别急着往前跑,毕竟信息化、移动互联网这些课已经知道有明显不足了,那可以先补着,在数字化转型这块,把大逻辑和方法论搞清楚。

 

数字化转型是企业整体转型,而且是配合社会转型的企业转型,很多企业在信息化阶段都还没有形成自身的整体设计能力,自然也很难应对众说纷纭的数字化,这个条件下仓促上阵,容易收获“负反馈”,也就是,没理解大方向,没找对路径,没有具备分阶段实现能力,结果在实操上出现问题,导致对方向产生怀疑,这就错远了。

 

只有先把逻辑搞清楚,才能摆布本来就有限的资源,才能客观对待成功路上难免会遇到的失败情况。

 

方法论是将经验转化为知识的有力方式,数字化转型还是先以方法论,尤其是企业架构这类以往过于忽视的现代企业 IT 治理方式为基础开始企业的探索,就像跑步之前怎么也得学点儿少受伤的基本知识一样,否则,各种伤病也会伴随着跑步过程找上门来。

 

数字化转型对很多企业而言,要解决的是如何在一个企业中同时管理好原来的主业和 IT 这两个行业的问题,这是传统管理学方法暂时做不到,需要改进的地方,而目前也只有企业架构能提供将业务和 IT 进行整体的系统性连接的思维模式,企业管理面向数字化转型必需要先从这个转型做起,不然,管理层无法理解新技术的价值和应用方式,中层、基层无法理解如何借助技术进行创新,而技术人员成天疲于奔命做各种缺乏业务创新思路的基本实现,整个企业的 IT 投入尽管花费不小,却始终达不到预期效果。这个问题的根源必然出在思维融合上,双方没法想到一起,也没法到一起想,这也会制约数字化转型的效果。

 

所以,逻辑很重要,很多学科最终都会上升到历史和哲学这两个方向上,本学科的发展历史,解决了哪些问题、还有哪些问题、做过哪些尝试等;本学科的思维逻辑,基本的思考逻辑,逻辑上的不足等,很多问题的解决,都是源于这两个方向的。这两个方向也是方法论进步的基础,企业搞方法论来指导自己,也要靠在这两个方向上努力。

 

(八)对数字化转型而言质量与速度哪个更重要

 

这是一个崇尚敏捷的时代,但是笔者其实最怀疑的理论就是“快鱼吃慢鱼”,如果生物进化简单遵循这个基本规律那生物多样性早就没了,也不称其为生态了。生态总体上是倾向于维持平衡的,除了“快鱼吃慢鱼”,还有“大鱼吃小鱼”,也有食人鱼这种“群鱼吃单鱼”,行军蚁就更是这种极端了,另外,“快鱼”、“大鱼”都是少数派,“慢鱼”、“小鱼”则是多数派,“快鱼”、“大鱼”数量失衡就得“内卷”,自己吃自己,最终生态垮掉,谁都活不好。

 

现在社会节奏很快,以至于很多人怀念“车马很慢、书信很远”的“慢时光”,但这个确实回不去了。不过,回不去是不是意味着就要永远变得更快,目前有这种倾向,但这个符合长期发展模式吗?未必。像改革开放初期能够靠规模实现简单线性增长的时代已经过去了,国家经济增长目标也从速度优先逐步转变为质量优先,这也意味着靠规模吃饭的行业要面临深刻转型,深耕将是价值的主要来源。

 

实现深耕靠的是追求质量而非把速度放在第一位的增长模式,需要有对客户的深度理解和分析,才能有好的服务。当速度和规模无法提供简单的利润来源时,企业在经营上必定会转向跨界和集约,对外的跨界可以提供附加价值,属于开源;对内的集约可以控制成本,属于节流。这两者与速度没有必然联系,与深入、细致则有天然联系,这要求的是“慢”而非“快”,是专注而非频繁“试错”,是思考而非“模仿”,未来会有越来越多通过“深耕”这个模式取得成功的企业,而不是总靠跑得快。

 

规模的荣光已经不在了,速度的荣光也在飘忽。

 

总结下,笔者从几个维度发散地思考了下如何认识数字化转型,数字化转型是该先务虚再务实,学好国家政策,理清数字化方向;要以长期视角对待数字化转型,现在是做长期战略最好的时期;要从时代发展的趋势上看待数字化,而不是当做明确项目建设去看待数字化;数字化转型需要从整体上认识,不要总想着在没全盘计划的情况下搞个试点,这种情况下,往往都说不清试的到底是什么;要从信念上研究数字化,从对社会发展愿景的相信上找数字化方向,这样反而能看到更大的商业;企业对待转型这种“灵魂问题”,还是要学会自己找答案,这一点不是仅对数字化转型适用,也适用于所有转型;对数字化转型而言,企业要面对的是管理模式的升级,所以,关注方法论,尤其是企业架构方法论很重要,学会业技融合,而且,学习花不了多少钱,这个成本远低于试错;数字化转型靠的是质量而非速度,当然,这不是说可以“蜗速”前进,但确实不需要长年累月地搞“996”,太着急反而会失去“深耕”的机会。

 

三、如何在行动层面破除迷思

 

“学而不思则罔,思而不学则殆”,迷思困扰的不仅是认知,还有行动。认知其实也是个行动,所以,单纯的把认知当成务虚也是不对的,而是要把务虚做实,通过行动加深认知,破除迷思。那可以现做哪些行动呢?

 

(一)内部充分研讨

 

务虚阶段就要把务虚该做的事情做实了,实实在在地、有结果地务虚,无论是听外部培训、引进外脑还是内部研讨,系统性进行务虚来解决以下这些问题:

 

1.      企业所在的行业走过什么样的路?

2.      企业所在的行业受科技的影响有多大、多深?

3.      企业所在的行业是否受到了跨界冲击的影响?

4.      企业所在的行业生态会发生什么样的变化?

5.      “纲要”中为企业所在行业指明的方向是什么?企业还应该补充哪些方向?

6.      企业当前最主要的痛点是什么?

7.      企业的客户最需要什么?

8.      企业的客户会发生什么样的变化?

9.      企业有能力或者应该为客户带来什么样的改变?

10. 企业对外部的依赖有哪些?怎么争取?

11.企业当前信息化水平如何?走到了哪个阶段?

12.企业最需要改变的思维是什么?

 

问题肯定不仅限于此,这些都需要企业深入思考,如果找不到自己认可的答案,那别人给你的答案你可能也坚持不了多久。通过深入思考,总结一个与社会长期发展方向一致的数字化发展蓝图,并通过实践去完善和调整它。有时候转型只需要适当转变下看问题的角度,比如对待蓝图的看法。蓝图的作用与架构一样,目的都是为了更好地适应、评估变化带来的影响,计划不只是用来执行的,也是用过来合理评价调整方法的。

 

思考也有方法,价值链分析、SWOT 这些方法都很有益处,觉得他们无用,很可能是因为没结合深度思考去用。

 

针对第二部分阐述的内容,可以通过充分务虚,解决从趋势上、探索上、逻辑上看待数字化的问题。

 

(二)建立从上到下的全局观

 

建立全局观这件事情本是传统企业经常讲的,但是现在一些互联网企业也在搞,还有一位著名的老板辞了职专门去搞,说明这个东西有用。笔者作为一个企业架构理论的坚定拥护者和实践者,认为企业应该尽早引入企业架构这种整体管理思维模式,无论是做企业架构项目还是只作为思维方式引入。为此,也要破除几个对企业架构的认知误区:

 

1.企业架构复杂。复杂的不是企业架构,而是企业,企业简单,企业架构也不会复杂,因为企业架构反应的是企业的结构和组成部分之间的关系,做企业架构不是搞艺术加工,是反映现实,寻找不足,建立演进路径,所以,如果觉得企业架构复杂,那是把企业复杂的账错算在了架构身上。

 

2.搞企业架构折腾。其实不搞企业架构也一样折腾,只要企业的业务系统多了,有孤岛问题要解决,有旧系统要升级,有新需求要处理,搞不搞企业架构都会折腾,区别是,是有规划的折腾还是没规划的折腾,是为了把系统连接的更好去折腾还是继续竖井式地增加新系统而把包袱甩给后来人。读者可以观察下,不采用企业架构方法做的企业,是否成功地解决了孤岛问题,或者是不是最终又转向了某种尝试做全局设计的方法。

 

3.企业架构没用。数字化必然要求长流程自动化、智慧化,要求更强的整体设计能力,但是长期对企业架构的忽视、怀疑甚至贬低,已经导致了整体设计能力的缺失,这样是很难走向数字化的。未来需要的不仅仅是能把“井”打好的竖井式项目架构、项目经理,而是能把企业设计整体打通的企业级架构师和能同时指挥多项目协同施工的项目经理,当然这还需要有架构思维的企业领导、全体员工的共同努力,企业架构不是架构师的架构,是企业的架构。对大多数企业而言,企业架构不是没用,而是没用好,没敢用。

 

4.没人会照着企业架构方法论做。这个问题稍微复杂些,因为不同的企业架构方法论主张的实现方式不大一样,很多是时候因为 TOGAF(开发组架构框架,the open group architecture framework,目前国际最大的论坛性企业架构组织)名气最大,这个问题往往指向了 TOGAF。TOGAF 以一套严谨的流程和大量的交付物导致的“沉重”闻名,国内曾有一个著名的外资咨询企业的团队试图在其上进行改进,但终因其体系的完整性而放弃了修改努力,另辟蹊径了。

 

确实很少有企业会一五一十地照着 TOGAF 做,但是它本来也不是法律文件,而是个执行参考,它的价值就在于给大家说清楚,规模这么庞大的一件事,该把人怎么组织起来去干,否则一大堆人聚在那里要怎么做事呢?参考这个过程就可以向下执行,不参考,企业就得自己摸索一套,而实际情况是,很多不参考的企业自己也摸索不出来另一套实施企业级工程的方法,毕竟 TOGAF 也是集合了众多工程智慧、持续发展了 26 年的产物,不是没做过工程的人编的“花架子”。

 

TOGAF 中非常值得尊重的是尝试为了让理论能够更广泛地适用而进行的逻辑建设,这是完善人类认知的基本方法,它反映的也是对企业复杂性的认知过程,而非很多人口中的“虚”。笔者常说,没人会因为自己一公里都跑不完而去批评马拉松运动有问题。

 

要是能够破除这些片面的认知,引入企业架构,那到底该怎么用呢?

 

1.建立全局视图。这是企业架构的基础任务,解决孤岛问题靠的就是这种全局视图,不然谁能说得清业务到底有没有横向联系,系统要不要打通,数据到底是不是一致的?没有全局的业务视图、数据视图,就没法真正解决孤岛问题,“竖井式”建设产生的问题,显然无法采用“井”里的视角解决,而只能走到“井”外去看问题。不解决孤岛问题,数字化远景也就无从实现,外购一个系统不一定能解决自己家里现有的一锅“乱粥”,除非那个系统是用企业级视角建立的。“九尺之台,起于累土”,还是先做好基础工作,而且,这种全局视图也是业务和技术两侧各层级人员都可以共用的统一视图,建立企业从上到下的一致的全局观。

 

2.建立业技融合的工作方式。企业架构的设计过程强调业务和技术一起做,向数字化企业的目标迈进,并不是技术人员多了、技术实力强了就够了,而是业务和技术的沟通是否顺畅,企业架构实施方式能够提供的良好的融合与接近的机会,并为今后长期的业技融合建立工作模式。

 

3.建立演进思维。企业架构提供的是一个从现状到目标的路径分析和设计方法,因此,架构是一种阶段性演进目标和常态化需求实现相结合的管理方式,既可以通过企业架构做常态化的需求管理,也可以承载阶段性的战略发展要求,这是很多企业面临的如何看待稳态和敏态的问题。常态化需求用敏态开发,因为比较熟悉;战略性需求用稳态,因为影响大,这种搭配方式也体现了对数字化转型而言,质量比速度重要。这种演进思维是企业战略得以在业务和技术两侧能够贯通落实的基础。

 

对于企业架构方法论,企业一定要边做边照着自己的实际情况去调整,最后形成一套自己企业的方法论来指导自己今后的实践,培养自己的人,这才是最正确的实施方法,回顾下中国革命史,革命也是这样成功的。

 

通过建立全局观,可以解决从整体上、长期上、质量上看待数字化的问题,也可以逐渐为企业的业务资产、技术资产建立清晰的视图,并逐步形成行业级标准化构件,支持实现灵活、智能的组装式、构件化企业,这是数字化企业该有的 IT 建设方式。

 

总体而言,笔者认为,至少当前的行动先以这些有助于破除迷思的、基础性的行动为主,把这些做好了,企业应该能自己找到答案和路径,毕竟,数字化是个性化的,不是千篇一律的,没有这些基础能力,很难做到创造一个富有特色的数字化企业。

 

综上,对两个“双期叠加”的认识,加上八个方向的思辨和两个基础性的行动,希望能帮广大读者进一步认识数字化转型这件事情。“独立思考、形成套路、以人为本、灵活实践”,这是笔者对数字化转型关键理念的总结,愿大家在数字化转型这个长期的国家级大风口、史诗级大转型上,都能有所收获,“面壁十年,御风而起”。


作者简介

付晓岩,IBM 副合伙人,极客时间《说透数字化转型》专栏作者,全球企业咨询服务部大中华区金融核心锐变团队业务发展和交付总监,机械工业出版社《银行数字化转型》和《企业级业务架构设计:方法论与实践》作者。

2021-06-15 16:355032

评论 1 条评论

发布
用户头像
感觉造成数字化转型迷思很大一部分原因是即使是行业内的专业人士也无法用一个通俗易懂的表达把数字化转型讲清楚,讲不清楚还不如直接采用类似阿里“ 一切业务数据化,一切数据业务化”这样比较简单、直白的描述,但是很多专家又喜欢造一些概念出来,或者和很多其他概念掺杂在一起说,导致越说越糊涂。

个人的尝试:其实数字化转型就是沿着和“数据——信息——知识”相反的方向,直接聚焦在数据上来重构业务的过程,包括数据思维和工具两个层面。

为什么现在数据能够成为生产资料爆发威力?2个关键因素:在线和智能。互联网/移动互联网/物联网让数据能够实时在线(背后就包括了数据的采集、计算和处理能力的支持),人工智能等的发展让数据有了智能(背后逻辑是把智能问题变成了数据问题)。

推荐2本书《在线》和《智能时代》,正好比较清晰地阐述了在线和智能这两个方面。
展开
2021-06-18 01:45
回复
没有更多了
发现更多内容

架构师训练营第 1 期第 8 周作业

业哥

医疗界“最强大脑”落户杭州!阿里巴巴联合浙大一院共同打造

互联网

数据结构与算法系列之链表操作全集(三)(GO)

书旅

数据结构 Go 语言

go-zero如何追踪你的请求链路

万俊峰Kevin

Trace microservice Go 语言

阿里云官方推出操作系统“等保合规”镜像 -- Alibaba Cloud Linux 等保2.0三级版

阿里云基础软件团队

内核

技术分享:WebAssembly能否重新定义前端开发模式?

葡萄城技术团队

webassembly

终于啃完了这份Java核心原理+框架“面试圣经”,成功五面上岸美团

Java架构追梦

Java 架构 面试 微服务 框架开发

每周一看:16份文档资料,程序员软硬实力全概览,总有一个适合你

小Q

Java 学习 程序员 架构 面试

架构师训练营第 1 期第 7 周作业

owl

极客大学架构师训练营

嗯,查询滑动窗口最大值的这4种方法不错...

王磊

Java 数据结构和算法

移动安全加固助力 App 实现全面、有效的安全防护

蚂蚁集团移动开发平台 mPaaS

安全攻防 App风险 mPaaS

【云小课】版本管理发展史之Git+——代码托管

华为云开发者联盟

git 代码管理 托管

分库分表的 9种分布式主键ID 生成方案,挺全乎的

程序员小富

分库分表 Java 分布式

接口测试如何在post请求中传递文件

测试人生路

接口测试

简析低代码开发与传统开发的区别与优势

Marilyn

敏捷开发 低代码

【涂鸦物联网足迹】API及SDK介绍

IoT云工坊

软件开发 物联网 API sdk 云平台

《迅雷链精品课》第一课:认识区块链

迅雷链

区块链

第 7 周 性能优化(一)总结

蓝黑

极客大学架构师训练营

数据结构与算法系列之栈&队列(GO)

书旅

数据结构与算法 Go 语言

“开源软件供应链点亮计划-暑期2020”公布结果 基于ChubaoFS开发的项目获得最佳质量奖

京东科技开发者

大数据 开源 云原生

会展云技术解读 | 面对突发事故,APP如何做好崩溃分析与性能监控?

京东科技开发者

云计算 云服务

mongodb 源码实现系列 - 网络传输层模块实现三

杨亚洲(专注MongoDB及高性能中间件)

MySQL mongodb 分布式 高性能 分布式数据库mongodb

重磅解读:K8s Cluster Autoscaler模块及对应华为云插件Deep Dive

华为云开发者联盟

容器 k8s 服务

解决大中型浏览器(Chrome)插件开发痛点:自定义热更新方案——2.基于双缓存更新功能模块

梁龙先森

Java chrome 大前端 浏览器 技术方案

全面解析ArrayList,超详细!

程序员的时光

面试 ArrayList JAVA集合

2020LF AI&DATA DAY(AI开源日):中国开源社区迈入全球化新征程

架构师训练营第八周总结

邓昀垚

天啦撸!打印日志竟然只晓得 Log4j?

沉默王二

Java 日志 log4j

DB-Engines 11月数据库排名:PostgreSQL坐稳同期涨幅榜冠军宝座

华章IT

数据库 postgresql

tomcat打包成rpm包

lee

tomcat rpm

架构师训练营第八周作业

邓昀垚

极客大学架构师训练营

数字化转型迷思_语言 & 开发_钰湚—付晓岩_InfoQ精选文章