mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-11-20 08:03:43 +08:00
del
This commit is contained in:
116
极客时间专栏/geek/说透数字化转型/基础篇/01 | 历史思维:什么是数字时代和数字化转型?.md
Normal file
116
极客时间专栏/geek/说透数字化转型/基础篇/01 | 历史思维:什么是数字时代和数字化转型?.md
Normal file
@@ -0,0 +1,116 @@
|
||||
<audio id="audio" title="01 | 历史思维:什么是数字时代和数字化转型?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fd/ce/fd4745b174ea4352c3e3998e50537ace.mp3"></audio>
|
||||
|
||||
你好,我是付晓岩。
|
||||
|
||||
“数字化”如今是个大热门了,聊天不谈数字化可能会让别人觉得你都落后于时代了,大到企业战略,小到铺天盖地的公众号文章,“数字化”估计都快刷爆你的手机屏幕了。当然,你也可能听过N种对数字化的解释了,比如:
|
||||
|
||||
- 有人从商业模式的改变上谈数字化,把用数据去驱动业务当作数字化;
|
||||
- 有人从技术方面去谈,用5G、中台、云上企业、物联网、人工智能社会、区块链社会等,去定义数字化;
|
||||
- 有人觉得跟信息化没啥区别,已经搞了几十年的信息化也是数字化;
|
||||
- 也有人觉得未来变数太多,没法预测,应该“摸着石头过河”,探路探出数字化。
|
||||
|
||||
你有没有发自内心地接受某种解释呢?如果某一天,你被同事或者领导叫住了,让你给他讲讲到底什么是“数字化”,到底怎么做“数字化转型”,你打算怎么讲呢?
|
||||
|
||||
数字化怎么说都是个面向未来的话题,未来也还没真来,谁也难说自己解释的就一定是对的,所以,这就需要咱们广泛地思考下。面对复杂问题的时候,咱们都清楚,切忌跟风跑、人云亦云,得静下心来深入思考。
|
||||
|
||||
这个时候,就要用到历史思维了。我在开篇词里讲过,历史思维就是指从历史发展的角度来看问题,毕竟,数字化技术不是从石头里蹦出来的,前面还有农业、工业和信息化三个技术时代,只有与历史做比较,我们才能纵深地去思考和看待数字化。
|
||||
|
||||
那么,今天我们就一起到历史中找找规律,看看这三个时代都有什么特点、有什么趋势;然后,从这些趋势和特点中,看看能不能找到数字时代应有的方向。“日光之下并无新鲜事”,人类社会的发展是“螺旋式上升”的,历史总会给我们提供一些关于未来的线索。多了解了解历史,你对数字化肯定会有更深入的理解。
|
||||
|
||||
## 已有的三个技术时代
|
||||
|
||||
我们知道,农业时代、工业时代和信息时代,是从技术的角度来划分的。那我们就先从技术的角度,去看看它们对人类生活和生产方式的影响吧。
|
||||
|
||||
农业时代最漫长,最早的种植性农业大约出现在1万年以前。农业时代的主要特征,当然是社会经济以农业为主,是**土地密集型和劳动密集型**的,国家实力的象征往往是土地和人口。
|
||||
|
||||
从技术角度看,农业是要在一块比较固定的土地上工作,所以,除非发生大的自然灾害或者战争,否则,“老守田园”“日出而作、日落而息”,跟随季节变化安排农活儿,就是最常见的生活方式。因为技术发展慢,所以社会的变化也慢。
|
||||
|
||||
工业时代的历史就短得多了,公认的开端是18世纪60年代。从棉纺织业开始的技术革新,使得社会转变为**资本密集型和劳动密集型**,工业逐渐取代农业成为社会经济的支柱。只用了200年左右的时间,工业时代就魔术般地彻底改变了人类社会的面貌,不断出现的千奇百怪的机械设备带给人们强烈的时代冲击,蜡烛变成了电灯,马车变成了火车、汽车,真人表演的歌剧变成了留声机中的唱片。
|
||||
|
||||
从时间上衡量,工业社会变化比农业社会快得多。即便只以人类平均60岁左右的寿命去衡量,也可以很直接地感受到从农业时代进入工业时代的转变。任何一个普通人都能见证到,时代不同了。
|
||||
|
||||
信息时代是最后出现的,我倾向于认为开始时间是1946年,也就是世界上第一台可编程电子计算机的诞生时间,毕竟是计算机让信息化具备了可能性。信息时代发展的速度比工业时代更快,在这70多年的时间里,计算机和网络已经大幅改变了我们的生产和生活模式,大到军队作战、企业生产,小到点个外卖,**信息化、网络经济带给我们的变化都是清晰可见的,而且变化也是频繁的**。
|
||||
|
||||
信息时代的特征是网络密集型和信息(知识)密集型的。掌握了网络和信息这两个资源,就意味着拿到了快速成长的钥匙。这是互联网企业的成功带来的启示,也是我们常说的平台化的意思,通过网络把更多的参与方连接起来,获得更多的信息,让交易更快达成,也就产生了“增长飞轮”。
|
||||
|
||||
不信的话,你就盘算下咱们今天看到的国内外互联网头部企业的年龄,大多数只有十几、二十岁,还有些不到十岁,“增长飞轮”效应带来的成长速度是信息时代特有的。
|
||||
|
||||
经过刚刚的简单回顾,我们可以意识到这样一个问题:**想界定一个新的时代,我们最好是去观察人们生产和生活的变化,抓住对人们的生产和生活产生最大影响的技术特征**。如果是一个新的时代,那就必须像农业时代走进工业时代、工业时代走进信息时代那样,确切地给人们的生产和生活方式带来普遍的变化。
|
||||
|
||||
这样,我们也就掌握了判断数字时代的标准,也知道了“转型”是要改变人们的“行为习惯”。否则,人们对转型的获得感、参与感又从何而来呢?老百姓都感受不到变化,也就谈不上走进新时代了。
|
||||
|
||||
到这里,你再听别人讨论“数字时代”“数字化转型”的时候,就可以用“是不是足以广泛改变人们的生产和生活”去判断他们的定义是否合适了。
|
||||
|
||||
## 时代中表现出的趋势
|
||||
|
||||
你肯定会问,只要看清楚历史就能彻底理解数字化时代、做好数字化转型吗?当然不是。除了要清楚地知道时代特征,我们还必须找到发展的规律。只有这样,我们才能清楚朝着什么方向推进数字化转型。
|
||||
|
||||
那么,要正确地实现数字化转型,我们该掌握什么规律呢?我认为,主要有两条。
|
||||
|
||||
**第一,人们一直在努力打破空间对人类活动的限制,尤其是距离上的限制**。
|
||||
|
||||
我们看一个例子。假设你现在在上海,要和一个北京的朋友当面讨论一个重大问题。农业时代,我们得使用步行、骑马、坐马车或者坐船等方式来解决长途旅行的问题,从上海到北京大概得用一个多月的时间;到了工业时代,我们有了火车、飞机,使得京沪间的当日往返成了可能;而到了信息时代,我们可以直接通过视频聊天,来达到面对面沟通的效果。
|
||||
|
||||
距离给人们带来了很大的不便,仔细观察你就可以看到,人们无论是在生产还是生活方面,都在持续努力突破这种限制。所以,数字化转型也需要保持这个方向。
|
||||
|
||||
**第二,个体能力在持续增强。**
|
||||
|
||||
在农业时代,尽管传统文化看起来光芒灿烂,但是大多数劳动者的受教育水平并不高。毕竟农业时代基础教育差,东西方社会都可以说是以文盲为主的社会。知识有限,每个人能做的事情也就有限。
|
||||
|
||||
但是工业时代,教育水平提升了,人们的自然科学知识、技能都有了很大提升,对社会和事物的认知和改造能力都变强了,自我意识也逐渐增强。
|
||||
|
||||
信息时代,不仅义务教育普及,大学教育也增多了,人们的知识越来越丰富,可自由获得的信息也越来越多,我们看到越来越多的个体创业者、创造者。随着个体能力的增强,个体经济、弹性工作逐渐成为发展的趋势,而这种趋势要求人们必须具备高效获得更多信息的能力,同时又不会被爆炸的信息压垮。
|
||||
|
||||
数字时代也应该延续这个趋势,软件可以很好地封装人类已有的知识和技能。所以,在数字时代,软件会比今天多得多,而软件增多的目的,其实就是为人们赋能,让人们可以节省学习时间,更快地做更多的事情。
|
||||
|
||||
这两个发展规律,不管你有没有注意到,都已经融入到了我们的日常生活中,改变了我们生产和生活方式。所以你看,在我们思考时代这样的“大问题”时,这才是我们应该注意的“小细节”。如果说我们要从技术发展的角度去考虑时代问题的话,也可以从这些“细节”中观察出,技术应该沿着什么样的方向发展,才可以给我们带来符合历史发展规律的帮助。
|
||||
|
||||
从农业时代、工业时代和信息时代的历史回顾,以及这三个时代趋势的分析中,我们已经知道,**时代的变化应当是可以被确切感知的,还要满足一些规律性的发展方向**。那么,到底什么是数字时代呢?啥是数字化转型呢?
|
||||
|
||||
首先,我还是得强调一个事实:对数字化转型和数字时代的认知,不能局限在某项技术或者某个企业的范围内,否则自己的视野就会被限制住了。
|
||||
|
||||
这就像我们技术人常说的“拿着锤子到处找钉子”。但钉子不是未来,我们更不是在给锤子找未来,而是要琢磨未来还有没有钉子,还要不要锤子。
|
||||
|
||||
未来永远是“想象密集型”的,但我们要合理地去“想象”,而不是空想,这就是为什么我特别强调,一定要结合历史看这个问题。
|
||||
|
||||
这个逻辑在你的头脑里扎根以后,就可以跟着我一起从时代特征、时代发展趋势的维度,去给“数字时代”和“数字化转型”找到一个合适的定义了,也看看是不是数字化真的会带来一个新时代。
|
||||
|
||||
## 到底什么是数字时代和数字化转型?
|
||||
|
||||
**首先,从时代的特征来讲,数字时代是数据密集型和软件密集型的**。
|
||||
|
||||
数据是最重要的生产资料,这不仅是因为数据可以用来分析和驱动业务,更重要的是,从技术角度来讲,以软件为基础的一切都是用数据建造的,包括软件自身的存在形式也是数据。数据就像今天的砖瓦灰沙石、钢筋混凝土,是建筑材料,这是数字时代不同于以往的一个特点。
|
||||
|
||||
而海量的数据要被技术手段处理,尤其是软件,所以,**软件是这个时代最重要的生产工具**,生产工具和生产要素的变化合起来就是生产力的变化。
|
||||
|
||||
这也是跟信息时代最大的不同。在信息时代,数字经济还没有成为最主要的经济形态,没有达到工业的地位,但是在数字时代,数字经济将成为最主要的产业。当然,这不意味着工业的消失,因为工业还是维持社会运转的基础,但是工业也将成为数字化工业,就像农业在工业时代升级为机械化农业一样。
|
||||
|
||||
**其次,从发展方向上看,数字化会通过虚拟空间和体验类技术充分赋能个体**。
|
||||
|
||||
数字化包装过的知识,可以作为软件能力被人们更好地应用。当然,这不会像电影《黑客帝国》中的主角们瞬间学会开飞机、格斗术那么酷炫,但是,像手机逐步替代单反相机这样,让更多人具备基本摄影能力是没问题的。
|
||||
|
||||
数字化可以极大程度地打破空间限制。与物理世界具有良好互动能力、可以有更好全真体验的数字化,至少会让我们居家办公也一样能感受办公室环境,没必要为了见个面跑上半个中国。逼真的体验会形成有史以来最为灵活的生产组织形式、社会活动方式,这是生产要素流动最便捷的方式,尤其是对人这个最重要的生产要素而言。这是可以预见的、突破空间限制为个体赋能的最强形式。
|
||||
|
||||
不要小看《头号玩家》中那个眼镜的力量,它背后连接的是广袤的、无所不达的虚拟空间。它所代表的数字社会形态,是未来20~30年技术上可以初步实现的,能够给生产和生活形态带来巨大改变,并且可以被大家直接感受到,让大家有充分的参与感和获得感。
|
||||
|
||||
虚拟现实、数字孪生等技术可以带给我们的不只是游戏,**高水平的数字化完全有能力保证人们在虚拟空间中获得与物理世界相同甚至更好的体验,所以,数字时代一定是个超级体验时代**。而围绕超级体验,企业的服务模式也必然会发生很大的变化。
|
||||
|
||||
分析了这么多,咱们最后给数字时代和数字化转型下个定义:数字化就是指通过各类手段,将人类行为最大限度地向虚拟空间转移,并在虚拟空间中完成与物理世界的必要互动,这里既需要技术手段,也需要业务、法律等非技术手段的支持,数字时代就是以智能体验类技术为特征的技术时代;而数字化转型指的是从当前信息化环境下的人类行为、组织形态向数字化环境下的人类行为、组织形态的转变过程。
|
||||
|
||||
## 总结
|
||||
|
||||
**数字化是人类社会的进化,它绝不仅仅是一个企业的问题,也不是某一项技术的问题,而是时代的变迁**。这一点是我们在谈论数字化、数字时代、数字化转型时,要首先弄明白的一个问题。
|
||||
|
||||
所以,今天这一讲,我们从时代发展历史和规律的逻辑出发,一起分析了农业时代、工业时代和信息时代的特征,以及三个时代表现出的两个发展趋势,同时我也跟你分享了我理解的数字时代和数字化转型。
|
||||
|
||||
我把这一讲的核心知识点总结到了一张图片里,供你随时学习:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/7e/64/7eaf945c9b29dc7983c2ef46b3170264.jpg" alt="">
|
||||
|
||||
最后我要再强调下,技术也有技术的历史,它是更大范畴的人类历史的一部分,或者说一个视角。孤立地看技术,会迷失方向,容易犯拿着技术到处找场景的老毛病。都要见证新时代了,还是要目光长远些、宽广些,多想想北宋文学家王安石《登飞来峰》中的那句诗:“不畏浮云遮望眼,自缘身在最高层”,站得高,自然看得远。
|
||||
|
||||
## 思考题
|
||||
|
||||
请你尝试下深度思考,然后自己给数字化转型和数字时代下个定义,或者是转发下你所认同的定义。
|
||||
|
||||
欢迎你畅所欲言,和我一起交流讨论。如果你觉得今天的内容对你有所帮助,也欢迎你把它分享给你的朋友或同事。
|
||||
143
极客时间专栏/geek/说透数字化转型/基础篇/02 | 生态思维:企业怎么找准自己的定位?.md
Normal file
143
极客时间专栏/geek/说透数字化转型/基础篇/02 | 生态思维:企业怎么找准自己的定位?.md
Normal file
@@ -0,0 +1,143 @@
|
||||
<audio id="audio" title="02 | 生态思维:企业怎么找准自己的定位?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e1/5a/e1426454e12e4f2b98ff08b8d777eb5a.mp3"></audio>
|
||||
|
||||
你好!我是付晓岩。今天,我想和你聊一聊,在数字化转型中,企业必须要用到的生态思维。
|
||||
|
||||
说到生态,也许你立刻想到的就是跟每个人都息息相关的环境问题,比如小河的污染、气温的持续上升、沙漠化等,可以说,这些问题很大程度上都是粗放的、单纯求快的发展思路导致的。这种因果循环不是自然界才有的东西,在我们的商业领域、企业管理,甚至是技术领域,都是存在的。
|
||||
|
||||
每个企业都生活在一个超级大的生态里,无论是世界500强,还是街边小店,如果处理不好自己的商业环境,都很难经营下去。进行数字化转型,更是牵一发而动全身的事情,要想获得长远的发展,就必须用到生态思维。所谓的生态思维,也就是以互相影响为前提、以互惠互利为目标的思维模式。
|
||||
|
||||
所以,今天,我们就来了解下企业经营中的生态思维。我会借助实际的例子,帮助你理解正确运用生态思维所产生的效果。同时,我还会告诉你怎么运用生态思维,包括在生态中找到自己的核心能力、建立良好的生态关系。
|
||||
|
||||
## 企业经营中的生态思维
|
||||
|
||||
任何一家企业,无论是否明确地提倡生态思维的理念,实际上都在实践着这样的发展思路,比较典型的2个表现就是供应链和平台模式。
|
||||
|
||||
**先说供应链**。供应链代表了商业环境中跟你关系最密切的一群小伙伴,这些小伙伴发展得好不好,你如何处理跟他们的关系,都会影响到自身发展的稳定性和服务能力。所以,企业都很重视供应链管理,越大的企业越是如此。
|
||||
|
||||
这么说可能不是特别容易理解,我借助苹果公司的例子来给你解释下。
|
||||
|
||||
苹果公司可以说是供应链管理中的典范,全球著名顾问机构Gartner每年会选出全球25家供应链管理最优秀的企业,苹果公司连续10年入选,可见功力深厚。
|
||||
|
||||
苹果公司的供应链至少涉及200家企业、800多个工厂,分布在20多个国家、几百个城市,可以说是相当复杂。而他们的管理相当深入,他们会对合作企业的产品设计进行控制,不允许合作方有“黑盒”存在,合作方对苹果公司几乎是透明的。据说,他们曾经派驻2000多个工程师到富士康工厂,对他们进行设计、生产等细节的深入管理。控制得越深入,他们的设计要求也就越容易得到满足,生产组织能力也就更强。
|
||||
|
||||
你想,如果苹果公司要发起某种企业级的转型变化,那这些受到其深入控制的供应商也很难不受其影响;反过来,如果这些供应商的某些能力跟不上,也会制约苹果公司的战略实现。
|
||||
|
||||
所以,在互相影响的生态下,任何一家公司都不能只考虑自己家的事情,而忽略了别人可能带来的影响。供应链管理,是我们做数字化转型不可忽视的一环。
|
||||
|
||||
**除了供应链管理,平台模式也是必须要考虑的因素。**
|
||||
|
||||
平台模式现在非常流行,很多商业平台都是在努力连接更多的交易方,所以平台模式的本质其实是生态构建。
|
||||
|
||||
这是什么意思呢?我借助电商App的例子来解释下。
|
||||
|
||||
电商App就跟我们身边的菜市场一样。它们通常会提供去菜市场买菜的三个基本功能:
|
||||
|
||||
- 提供各种商品,满足你的挑选需求;
|
||||
- 提供聊天功能,满足你砍价的需求;
|
||||
- 提供支付功能,让你可以支付菜钱。
|
||||
|
||||
阿里最初的淘宝、阿里旺旺、支付宝就是这样的组合。不过,这些电商App的功能远远超过了菜市场。比如说:
|
||||
|
||||
- 它们会通过增加App的功能、增加商品种类、举办促销活动等方式,去优化购买者的用户体验;
|
||||
- 它们还会通过帮助零售商优化在线店面设计、提供营销分析、库存管理、商业导流等方式,优化销售者的商户体验;
|
||||
- 还会通过加强物流管理、连接更多技术服务商等方式,提高配送能力和技术供应能力。
|
||||
|
||||
你看,这就相当于通过平台把所有相关的参与方都连接起来,形成一个各方都可以获得利益的生态圈子。参与的人越多、体验越好,平台发展就越快;平台发展越快,各方从平台上获得收益的能力就会越强。这跟建立生态环境是一样的,都是在努力形成广泛连接和正向反馈。
|
||||
|
||||
了解了供应链和平台模式的重要作用,相信你对企业所处的生态环境就有了明确的认知。各个相关方不仅会相互影响,也会有各自的分工和位置。而**决定分工和位置的,就是企业的核心能力**。
|
||||
|
||||
## 如何在生态中找到核心能力?
|
||||
|
||||
其实,找核心能力就是在决定什么东西应该自己做,什么东西要留给别人做,也就是在定义自己跟别人的关系。从生态的角度看,就是在定义自己跟别人的生态联系。
|
||||
|
||||
要找到核心能力,你必须要清楚3个问题。
|
||||
|
||||
**1.企业不可能什么都做**
|
||||
|
||||
这一点看起来就是个常识,但遗憾的是,仍然有很多企业因为盲目扩张业务,走了不少弯路。
|
||||
|
||||
举个小例子,美国就曾有一些制造业企业试图进行水平方向的扩张,将重要的上游生产能力吸收到自己的集团内,完成集团化的供应链整合,结果却导致了巨大损失。比如说,美国的福特汽车曾经拥有钢铁企业和矿山,以更好整合自己的供应链上游,但是经营管理成本却超过了收益,最终又放弃了这种模式。
|
||||
|
||||
所以,无论你是什么样的企业,大包大揽、什么都做只会让自己的精力过度分散,让企业内部的结构过于复杂,这样不仅会消耗大量宝贵的资源,而且收益甚小。
|
||||
|
||||
**2.企业的核心能力不太好定义,而且还会发生变化**
|
||||
|
||||
既然不要什么都做,那自己做什么呢?答案似乎很简单,核心能力留给自己,其他留给别人。但是怎么判断什么是核心能力呢?
|
||||
|
||||
这个问题比较主观,对于不同企业来说,核心能力自然不同。我来跟你分享一下我的思考。
|
||||
|
||||
因为我长期在银行工作,所以,我就老是在想,什么是银行的核心能力呢?
|
||||
|
||||
是服务吗?如果是服务,那我们专心提升网点服务品质、柜员服务能力、客户经理的服务技巧、手机银行的用户体验,客户量和业务量就会显著上升吗?答案似乎又不是。因为不断有银行在这方面推陈出新,但是,这么多年来,国内银行中的圈层排名很少有变化。
|
||||
|
||||
是风控能力吗?似乎也不是。相同规模等级的银行,风控能力都接近,即便超越了相应规模等级的水平,也很少有银行可以跃升到上一圈层。
|
||||
|
||||
所以你看,即使你在这个行业深耕多年,也很难定义核心能力。而且,核心能力还很容易变化,即使你当下的定义是正确的,也会随着形势的发展进行调整。
|
||||
|
||||
还是以苹果公司为例。苹果公司一度将手机设计作为自己的核心能力,但是后来,它又把核心能力向硬件制造上拓展了。截至目前,苹果公司已经搞了10多年芯片研究,至少收购了6家企业。在2020年11月,还发布了首款自主研发的功能强悍的Apple M1芯片,这导致其与Intel将近15年的合作要结束了。为了保持对硬件的控制,苹果公司的“自研”也是越来越多,这也说明,它对核心能力的定义在变化。当然,苹果公司即使变“重”了,也不会什么都自己造,那是没有必要的,它只是从整个生态的角度不停地观察,什么东西掌握在自己手里更合适。
|
||||
|
||||
通过这两个例子,你应该也感觉到了,核心能力不好定义,而且还会发生变化,所以,我们需要**放眼整个生态,做好自己的权衡**,案例只能用来说明道理,却不是你可以简单照搬的,因为案例往往只能介绍亮点,而真正铸就这个亮点的很多细节问题谁都讲不出来,这也是我认为对标分析要谨慎的原因。
|
||||
|
||||
数字化转型这个大工程往往需要数年之久,所有参与方在战略制定、方法讨论、架构设计、项目执行、任务协调、工程返工等方面都有着企业特有的烙印,可以参考,但不能盲目模仿,而且还要随着时代而变。
|
||||
|
||||
**3.企业的核心能力也有可能来自最初的弱项**
|
||||
|
||||
很多人都认为应该从成功处下手找核心能力,把一技之长做到无人能及,是建立核心能力的不二法门。这个思路没问题,但是可能并不全面,因为“胜利”容易冲昏头脑,找准成功的原因还真没有那么简单。
|
||||
|
||||
反过来看,从“痛”的地方寻找可能会更准确,因为痛觉往往会更清晰。
|
||||
|
||||
比如互联网公司大力发展X86的分布式架构、发展云计算,不是因为他们擅长,毕竟他们原来也是小白,只是因为他们在发展初期资金有限,实在是买不起那么多的大型主机,大型主机就是他们的痛处。如果都是通过持续采购大型主机去承担业务扩展的要求,那可能业务还没做大,公司就先破产了,所以,弱项经过长期努力,反倒可能成为“绝技”。
|
||||
|
||||
总之,核心能力是决定企业生态地位、适应生态变化的关键,企业不可能什么都做,因此务必要做好对自己最重要的事情,而这个事情的确定必须从整个生态去看,而且还要动态调整。
|
||||
|
||||
数字化转型是全社会的转型,不是只有你自己的企业想这么做,在这个大背景下,生态可能又会发生很大的变化,“不变”真的应不了“万变”,一定要在新生态下找好自己的核心能力。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/7b/1b/7b0256a917f0a93e6a755c166cacd81b.jpg" alt="">
|
||||
|
||||
## 如何建立符合一般生态思维的外部关系?
|
||||
|
||||
有了核心能力,还得做好跟别人的连接,处理好跟别人的关系,才能保持健康的生态,那咱们就来看看怎么建立外部关系才合适。在我看来,主要是两个原则:开放边界;互惠互利。
|
||||
|
||||
**原则一:开放边界,互相连接**
|
||||
|
||||
作为一个大生态来讲,这个世界是普遍联系的,我们都不可能脱离别人而实现自我成功。闭门造车,是做数字化转型的大忌,所以,我们必须要开放边界,重视和相关方的连接。
|
||||
|
||||
近两年很火的“开放银行”,就是传统行业认识到开放边界重要性的一个好例子。
|
||||
|
||||
商业平台和银行服务的是同一个客户,都讲体验至上,那么,如果在它们之间搞水火不容的业务边界,显然是在割裂以客户为中心的“生态”。而开放银行这种理念,就意味着银行把自己的业务能力API化,封装成可供调用的服务,嵌入到其他商业平台中,结合场景提供更及时的金融服务。
|
||||
|
||||
毕竟,对银行来说,把老百姓的生活场景数字化不是它的强项,如果要发展起来,就必须搞实打实的跨界,但是隔行隔山,没那么容易的;对于商业来说,金融服务的监管越来越严格,如果不好好联合银行,平台的生态也无法完整。所以开放银行,不仅解决了银行现在由于客户生活场景大量数字化,而导致的银行离客户有点远的问题,也提高了平台的用户体验,对双方都好。
|
||||
|
||||
不仅是开放银行,对于任何企业来说,开放边界都是现在的大势所趋。只有良好的边界连接、场景连接,才能不断提升客户体验,以客户为中心建立360度的客户服务能力,任何一个企业的“缺席”,都可能会造成客户体验的“割裂”。
|
||||
|
||||
**原则二:互惠互利,而非“赢者通吃”**
|
||||
|
||||
很多人认为,自然进化是一种单纯的竞争,生物生存下来就是竞争获胜的表现。其实,这种理解有点儿偏差,物种之间既相互制约,又相互受益。进化中既有通过竞争夺取资源的一面,也有通过共同节约资源保持关系稳定的一面,绝不是“有你没我”。说白了,自然界不是只有简单粗暴,还有“和谐发展”。
|
||||
|
||||
对于企业来讲,“赢者通吃”也许会带来一时的豪爽,但是,物极必反,没有所谓的“强者恒强”。数字化转型过程中,谁都有可能暂时领先,但如果因为领先就为所欲为,则有可能导致“生态失衡”,最终祸及自己。
|
||||
|
||||
比如,国外的科技巨头们都曾获得过某些方面的垄断优势,从而开始进行捆绑销售、滥用信息、不正当竞争等行为,也都曾经或者正在应对持久的反垄断调查与诉讼,这对国内企业的发展也是个启示。企业搞数字化,还是应该以互惠互利为目标,这才是长久之计。
|
||||
|
||||
总之,任何一家企业都不是孤立的,在进行数字化转型时,必须要在整个生态中考虑问题,积极开放边界,以互惠互利为目标,这样才能获得长远的发展。
|
||||
|
||||
为了能够更好地帮助你理解生态思维,我画了一张可以用来做生态分析的业务背景图,你可以用它来帮助自己建立一个观察生态的视图,而不是只看到自己的左邻右舍。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/c1/98/c1eda2dc729c571b70d5d492e6591498.jpg" alt="">
|
||||
|
||||
我简单解释下这张图。最内圈的是围绕个体消费的生活网络,第二圈就是支持生活网络的生产网络,第三圈是同时支持两个网络的金融网络,最外圈是关注着整个社会的治理网络。你可以对照着看看你所在的企业以及你自己在什么网络中,看看跟哪些类型的企业有联系,他们有什么能力,你的企业有什么能力,怎么定位自己、发展自己,是不是有机会建立更广泛的连接,拓展新的商业机会。
|
||||
|
||||
## 总结
|
||||
|
||||
好了,我们来小结一下。
|
||||
|
||||
数字化转型要用到生态思维,生态思维强调的是万事万物互有联系,互相影响,所以关起门来搞数字化不是正道。
|
||||
|
||||
既然互有联系,那就要考虑好什么是自己的核心能力,而且还得经常思考,因为核心能力不仅不好定义,还会发生变化。基于核心能力的定位,处理好与他人的关系,这需要保持开放,同时也要避免过度的竞争。过于强烈的竞争意识,无论是对企业,还是对个人而言,都是不必要的。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/5f/6d/5f85f60b3f0e23bd93f7baf2421bc66d.jpg" alt="">
|
||||
|
||||
## 思考题
|
||||
|
||||
学完了今天的内容,你应该很清楚生态建设的重要性了。那么,你知道什么得益于生态建设的企业的成功案例吗?
|
||||
|
||||
欢迎你在留言区跟我们分享你知道的案例。如果你觉得今天的内容对你有所帮助,也欢迎你把它分享给你的朋友或同事。
|
||||
154
极客时间专栏/geek/说透数字化转型/基础篇/03 | 架构思维:数字化转型如何落地?.md
Normal file
154
极客时间专栏/geek/说透数字化转型/基础篇/03 | 架构思维:数字化转型如何落地?.md
Normal file
@@ -0,0 +1,154 @@
|
||||
<audio id="audio" title="03 | 架构思维:数字化转型如何落地?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e8/58/e89aac12ac90ab102d7a7976868cc758.mp3"></audio>
|
||||
|
||||
你好!我是付晓岩。
|
||||
|
||||
前面两节课,我们学习了历史思维,弄清楚了数字时代的特征和要注意的发展趋势,同时,我们还学习了生态思维,找到了建立核心能力和生态关系的思路,那么,我们怎么把这些认知和思路落地呢?这就要用到架构思维了。可以说,架构思维是这门课里最核心的、起到方法论与实践连接作用的思维模式。
|
||||
|
||||
所谓的架构思维,就是采用架构的视角去思考问题。简单来说,架构就是结构和关系,包括一个事物由几部分构成,各部分之间是什么关系,设计这些关系和演进的原则是什么。那架构视角,也就是从结构和发展的角度看待事物,不仅要看到当前的结构,也要看到未来的结构,并搞清楚怎么从当前的结构走向未来的结构。能这么看问题呢,就是架构思维了。
|
||||
|
||||
数字化转型其实也是企业从当前状态走向目标的过程,也需要在一定的指导原则下进行演进,所以,架构思维是做数字化转型必不可少的一环。
|
||||
|
||||
那怎么把架构思维应用到转型上呢?具体点说,就是关注两个层面,一个层面是架构设计,要关注全面和结构这两点,架构设计要具备全局视角,结构要清晰;另一个层面是架构管控,要关注灵活和演进这两点,要注意短期的应变与长期的求变。数字化转型是企业整体的马拉松式转型,架构思维的全面、结构、灵活和演进这四个关键点给我们提供了方向。
|
||||
|
||||
接下来,咱们就先聊聊第一个特征,全面。
|
||||
|
||||
## 全面
|
||||
|
||||
所谓的全面,就是你要努力从全局视角看问题,以充分识别会对设计产生影响的东西,避免遗漏掉关键环节。我们来重点聊聊全面的重要性,以及如何做到全面。
|
||||
|
||||
### 为什么要全面:范围决定设计
|
||||
|
||||
一提到架构,很多人会想到在网上搜出来的那些画得很牛的架构图,别管多大的企业、多少信息,都能浓缩在一张图里,所以,人们经常会觉得抽象能力是架构首先关注的。但实际上,全面才是最重要的,因为**你看到的范围,决定了你的设计会是什么样子**。
|
||||
|
||||
举个通俗的例子。这就像你梳理手边工作的优先级一样,当你有5件事要做时,你会给它们排个序,如果这时候,你突然有了10件事,你还会保持原来的5件事的排序吗?估计会变。如果很不幸,塞给你20件事儿,那排序又得变了。你看,范围不同,事情之间的权重,也就是它们在整体中的位置就不一样了。
|
||||
|
||||
在设计企业架构时,你梳理一个环节和多个环节,所对应的设计目标也注定是不一样的。
|
||||
|
||||
就拿汽车生产企业来说,如果你只梳理轿车的生产线,会得到一个设计结果;如果你再梳理越野车的生产线,并尝试进行整合设计,你会得到另外一个设计结果;如果同时梳理了汽车的设计过程、生产过程、销售过程、售后客户信息的持续采集,并尝试进行打通的设计,你又会得到一个设计结果。
|
||||
|
||||
这些结果会分别对应不同的设计目标,比如,单一生产线的优化、多生产线的协同优化、企业生态视角的全局优化,显然,最后一个目标才是数字化希望达成的,同时也是企业架构最有价值的目标。
|
||||
|
||||
架构思维的全面性,简单来讲就是一句话,“不谋全局者,不足谋一域”。每个企业的价值创造都是一个完整的过程,比如从客户分析到产品设计到销售,再到售后服务,这就是企业的价值链,任何一个环节的缺失都可能导致客户服务能力的欠缺。只有在价值链的引导下,对每个环节进行充分分析,才是真正做到了全面。
|
||||
|
||||
### 如何做到全面?
|
||||
|
||||
看到这里,你可能会问,这么多东西,怎么可能一次就想全呢?
|
||||
|
||||
其实,这个问题正是对做企业架构设计的一个严重的认知误区。很多人都把企业架构设计当成了请咨询公司搞一次企业架构项目的交付物,但实际上,这种最初的集中性设计只是起点,**企业架构需要持续的积累和完善**。
|
||||
|
||||
人的能力总是有限的,哪怕把很多人加起来,也不可能把能力放大到无限,所以,每一次的架构设计都有可能是不完整的。
|
||||
|
||||
有的时候,是“**看不到**”导致的不完整。比如,有个业务环节或者规则被“集体遗忘”了,直到新的业务人员做测试时才发现,甚至有可能上线了之后才发现。这种事情对任何一种设计模式而言,都是有可能出现的,什么模式也解决不了“看不到”的东西。
|
||||
|
||||
有的时候,是“**看到了但做不到**”导致的不完整,尤其是在处理跨部门需求时,比如银行中常见的信贷类客户限额的集中管理,如果找不好牵头部门,或者各部门对原有管理模式的改变意见不统一,那首次架构设计中集中的限额管理就会成为一个空缺,只能等以后再填补了。毕竟,每次做项目都有时间限制,谁也不能一直等下去。
|
||||
|
||||
这样的情况会有很多,所以,要持续对首次设计达成的企业架构进行迭代,形成无限接近完整的企业架构。依靠这样持续完善的企业架构,整个企业对架构师都是可视的,这能够更好地保证架构师每次设计的合理性。而每次的合理设计,也会对企业架构的完整性形成有益的补充,形成良性循环。
|
||||
|
||||
所以,要做到全面,一是要靠价值链搭建起完整的分析框架,二是靠架构自身的持续完善来保证。
|
||||
|
||||
但是光把东西看全了还不行,还得理出关系来,下面咱们聊聊第二个关键点,结构。
|
||||
|
||||
## 结构
|
||||
|
||||
架构这个词是来自于建筑行业的,原本指的就是房子的结构,所以,一谈架构就离不开结构。关于结构,有两点你应该记住,结构分析的目标是为了更好地实现业务的想法,而做好结构分析,靠的是有目标地拆解。
|
||||
|
||||
### 没有结构就没有实现
|
||||
|
||||
我们不仅要全面地看一个企业,更重要的是,看到企业准确或者合理的结构,这是由架构的目的决定的。毕竟,我们不是为了画架构图而去研究架构的,是要通过架构设计准确地理解企业的内部结构和构成部分之间的关系,这样才能确保我们的需求实现是准确的。
|
||||
|
||||
这么说可能有点儿抽象,我拿买房子这个事情来解释下。假如你买了一所房子,那怎么让房子的具体使用符合你的美好设想呢?这就开始进入架构设计阶段了。
|
||||
|
||||
首先,你要考虑,哪个房间是主卧、哪个是次卧、哪个是书房,这算是粗粒度的架构设计。在粗粒度设计之后,你还得考虑更细节的架构设计,比如,沙发怎么摆、电视怎么摆、放不放鱼缸,等等,这些问题可能是关联的。假如你希望客厅放个大鱼缸,那冰箱可能就未必放得下了,得换个地方安排冰箱。
|
||||
|
||||
企业架构也一样,价值链的基本活动上有企业的核心生产过程,比如产品设计、产品制造、质量控制,支持活动上有客户管理、财务核算、营销管理等内容,可能都需要设计不同的业务系统进行支持,系统与系统之间也会有相互关系,比如数据的共享、业务的协同等,就跟你设计房间一样,需要给不同的需求安排个位置。
|
||||
|
||||
做好结构设计,就是确保你的想法会落实到各个组成部分上,通过考虑它们之间的相互关系和搭配,确保实现你的预期目标。
|
||||
|
||||
### 一定要有目标地拆结构
|
||||
|
||||
说到这儿,问题就来了,企业的结构一般很复杂,规模也不小,怎么才能实现对结构的清晰梳理呢?这就要提到结构化的核心了:有目标地拆解。
|
||||
|
||||
结构化是我们应对复杂事物的有效办法,太复杂、规模太大的东西,要想搞明白,就要拆碎了看,大事化小才行。
|
||||
|
||||
咱们继续来设计房子。如果让你一下子说出你要买多少家具,你能说出来吗?估计挺难,但是,你可以通过定义好每个房间的设计,再统计出你最终要买的家具,这就是通过结构化把复杂问题分解开来处理的思路。
|
||||
|
||||
结构化能同时降低你想法的复杂度和企业的复杂度,因为你把它们都拆碎了,但是也保证了你不会因为拆得太碎而忘记了最初的、最顶层的设计目标。因为**架构思维的拆不是乱拆,而是逐层分解、由粗到细、有结构地拆,最终会把理想的目标落到具体的细节上**。
|
||||
|
||||
比如,想提高企业的生产效率是不是一件很复杂的事情?对某些行业来讲,复杂度甚至有可能超乎你的想象,你只有把企业所有业务环节都梳理出来,一环一环地去拆解,去奔着提高效率的目标进行改进,才有可能最终实现这个目标。比如丰田的精益生产,那是细致到一个操作动作的级别的拆解,没有同样的付出,就别指望同样的效果。
|
||||
|
||||
回到数字化转型这件事上,我们的转型战略、企业的结构,都是挺复杂的东西,如果不尽可能完整地分析我们的企业,那数字化转型可能就会有盲点。比如说像安全保障、远程办公之类的事情,你之前可能觉得影响不大,但是在疫情防控时期,它们就非常重要了。如果不结构化地分解我们的企业,那就很难形成具体的、可落实的设计。
|
||||
|
||||
全面和结构,是做架构设计的核心。可以说,做到了这两点,你的架构就考虑到了大多数相关方的利益,能够为技术侧提供良好的指导了。
|
||||
|
||||
但是,环境一直在变,任何架构都不会是一成不变的,从短期来看,好的架构必须具备灵活性,从长期来看,必须是不断演进的。下面我们就先来聊聊什么是架构思维的灵活性。
|
||||
|
||||
## 灵活
|
||||
|
||||
传统架构的管理有严格的变更控制,这经常会让人觉得架构很死板,一旦做出来轻易就不能变更。这其实是误解。管理严格是希望变更不要过于随意导致整体设计混乱,但不是不允许变,尤其是在思维层面,架构的灵活指的就是要及时接纳变化。因此,对架构思维的灵活性,你要注意两点,一是架构需要经常调整,二是别把架构搞成呆板的管理。
|
||||
|
||||
### 架构是需要经常调整的
|
||||
|
||||
架构思维要考虑全面、要关注结构,从实操上来讲,这要求挺高的。你想想房间设计这个事儿,夫妻俩都有可能在装修上存在巨大分歧,更何况一个复杂的企业呢?设计本身要覆盖的范围越大,考虑得越多,引起变化的因素也会越多,所以,灵活就很重要了。
|
||||
|
||||
我来举个例子说明一下这个事情。假如B部门的一些需求可以与A部门进行业务整合,你提出了解决方案,评审也通过了,但是,在实际执行的时候,B部门却发现与C部门的部分业务活动做整合也可以,而且实施起来更方便,比如这两个项目团队之间更熟悉,沟通更方便,A部门在具体做的时候也出现不太愿意配合的苗头,等等。
|
||||
|
||||
这个时候,怎么做呢?那就调整一下呗。这种等效的变更应该是随时允许的。
|
||||
|
||||
另外,有时也会出现一些与设计目标不符的情况。比如说要替换一个遗留系统,大家都挺用心,但是,无论是业务分析,还是逆向工程都搞不定。如果不是迫在眉睫,这种也可以停掉。
|
||||
|
||||
当然,在现实的架构工作中,设计目标与实现条件有严重冲突的事情相对比较少,架构师对自家的实现能力不至于心里没数。往往是架构设计完成后,实现过程中发现了更多的细节需求、新需求而产生的架构调整,只要经过适当的评估,这都是可以灵活接受的。
|
||||
|
||||
不能总想着架构是不能轻易调整的,灵活对架构思维而言非常重要,甚至可以说是架构思维的生命之源。这么说并不夸张,谁愿意花大价钱搞个做出来就不能动的东西呢?这也是我做企业架构越久,体会越深的东西。
|
||||
|
||||
### 不要把架构搞成刻板的管理
|
||||
|
||||
很多人都把架构看成是一种管控,甚至抱怨架构的约束、限制、死板,这其实是把架构的执行问题当成了架构的缺陷,这是非常不正确的架构观。
|
||||
|
||||
曾经我也以为架构离不开严格的管控,不然,搞具体实现的人想怎么干怎么干,那我还做整体设计干嘛呢?架构考虑了全面和局部的关系,具体实现的人往往只考虑局部,不是应该听架构的吗?就像打仗,前线的小分队确实更了解自己的战况,但是都让小分队说了算,还要总参谋部干什么?还有人能对整个战场负责吗?局部胜利未必会赢得全局胜利,有时候还需要让出局部利益才能达成全局胜利。
|
||||
|
||||
但事实是,这么想的话可能就搞错了路径,架构要保证落地,不是单靠对大家的严格管理做到的,是因为架构设计本身适应了环境和目标的要求才做到的,也就是说,是因为设计正确而做到的。可以用企业管理再类比下,企业经营的得好,不是因为所有人对总经理都唯命是从,而是因为决策本身是正确的,大家顺着正确的方向才把事情做对了,单纯的严格管理并不能保证方向的正确。
|
||||
|
||||
所以,架构不是为了控制,更不是为了追求所谓的稳定,而是为了适应,这就是架构思维强调灵活的原因。管理上经常讲弹性、柔性,其实架构思维也一样,也是很需要弹性的。
|
||||
|
||||
但是,这种灵活性总体来讲还是一种“应变”,是架构为了实现当前目标而需要具备的弹性,属于局部的微调。灵活可以看成是处理当前困难的原则,但是处理长期问题,就要讲求演进了。
|
||||
|
||||
## 演进
|
||||
|
||||
就算你灵活处理完了当前问题,架构也不是可以躺在那里高枕无忧了,世界每天都在变化,你肯定不能停留在原地。
|
||||
|
||||
举个例子。互联网公司的架构管理能力还是很强的,他们很善于灵活应对当前的变化,但是即便如此,还是会5年左右出现一次大的整体架构层面的调整,这种调整经常被称为“架构演进”。这种调整都是以满足快速增长的业务目标为导向的,毕竟,支持1万用户与支持100万用户、1亿用户,所需要的架构有天壤之别。
|
||||
|
||||
以前,这种调整经常被解读为技术层面的,比如从单体架构转进到微服务架构,从使用主机到使用X86,从集群到云,但是随着“中台”的出现,渐渐把业务、组织结构和技术架构的变化也放在一起解读了,还扩展到了企业文化。
|
||||
|
||||
所以,这些互联网公司的演进,其实也可以看成是企业架构的整体演进,而不只是技术架构的演进。
|
||||
|
||||
这个道理也可以用于解读传统企业的架构演进。传统企业之所以演进没有互联网公司快,其实也是因为业务增长速度没有互联网那么快。
|
||||
|
||||
那么,这几年为什么又纷纷提出要更新架构,搞数字化转型呢?其实也是因为互联网公司带动了社会环境的变化,太多的人和企业都在网上活动了,这种环境的变化必然导致业务的变化,进而催生架构的演进,这也可以算是一种主动和被动交织的“求变”演进。
|
||||
|
||||
数字化转型不正是这样吗?有些行业有比较成熟的信息化建设,就像银行业、制造业、通信行业等等,也有常年耕耘在这片领域上的技术服务商,但是,信息化还没有达到全行业都过剩的时候,数字化就已经悄然启动、加速快跑了,原有的系统我们会因为建好了就不再动了吗?
|
||||
|
||||
你不敢,因为只有努力提供最好的服务,你才能在生态中保持合适的位置,才会在历史中延续下去,这是运用架构思维时必须掌握的点。
|
||||
|
||||
架构思维不是追求一次设计任务的完成,而是考虑持续的适应和生存,演进的方向就是持续满足业务或者说战略的目标,而能够为此主动发起变化,才是最好的演进方式。这里我给你提供3个方向。
|
||||
|
||||
- **关注未来**:无论分析结果对错,都要结合历史思维,始终关注对未来方向的研判,这一点没有大小企业的差别,时代淘汰谁是不设门槛的。看不到未来,其实也就找不到战略和演进方向。
|
||||
- **主动求变**:预测未来最好的方式,就是你自己要主动寻求理想的变化,并且朝着这个目标靠近,这才是最保险的。亚马逊和阿里巴巴对云的执著,分别造就了世界第一和我国第一的公有云服务供应商。虽然你的企业未必有这么大的目标,但是,任何一个企业的目标实现都不能指望别人白送。
|
||||
- **打牢基础**:架构演进可不是灵机一动,需要很好的知行合一能力,把理论和实践结合起来,才能推动自己的架构演进。很多企业只看实践,不注重理论,所以经常把对标分析摆在前边,总指望拷贝成功经验,而不是创造成功经验,这是没法持续推动创新的。
|
||||
|
||||
## 总结
|
||||
|
||||
架构思维是帮助数字化转型落地的重要一步。这节课,我们主要学习了架构思维的四个关键点,现在我总结下。
|
||||
|
||||
- 全面:运用架构思维,首先要求你全面地看待企业,只有尽可能完整地看待企业,才有可能准确地进行分析。
|
||||
- 结构:在尽可能掌握全貌的基础上,要结构化地分析事物的内部组成,确定好组成部分之间的关系,这样我们才能在逻辑上准确把握事物的结构。无论是要做软件设计,还是学习其他东西,这样做都是最科学的方法,结构化有助于降低事物的复杂性,更容易实现目标。
|
||||
- 灵活:做很多事情都未必能一蹴而就,架构更是这样。在架构实施过程中,我们要接纳变化,因此架构思维要保持灵活而不要僵化、官僚化。
|
||||
- 演进:面向长期来看,再好的架构都有一定的适用时间,早晚还得再调整,所以架构思维要注重演进,而且应该是有方向性的演进。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/11/16/1150d0835b14e91dfca9064b71bf6d16.jpg" alt="">
|
||||
|
||||
## 思考题
|
||||
|
||||
你能不能结合今天学习的架构思维,全面地分析一下你的工作,分析下你的工作涉及多少相关方,并且对照着企业的组织结构图,看看有没有平时遗漏的关联关系。
|
||||
|
||||
欢迎你畅所欲言,和我一起交流讨论。如果你觉得今天的内容对你有所帮助,也欢迎你分享给你的朋友或同事。
|
||||
131
极客时间专栏/geek/说透数字化转型/基础篇/04 | 破除误解:企业架构真的做不做都行吗?.md
Normal file
131
极客时间专栏/geek/说透数字化转型/基础篇/04 | 破除误解:企业架构真的做不做都行吗?.md
Normal file
@@ -0,0 +1,131 @@
|
||||
<audio id="audio" title="04 | 破除误解:企业架构真的做不做都行吗?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a5/e8/a5b328553b341d8f7f0b385bc3a4bce8.mp3"></audio>
|
||||
|
||||
你好,我是付晓岩。
|
||||
|
||||
上节课,我介绍了构建数字化转型方法论最核心的思维模式,也就是架构思维,它是负责连接方法论与实践的。毕竟,光有思维模式还不够,得能融入到实践中才行,最直接的方式就是做架构设计了。架构思维,就是通过对企业架构的设计和实施,去指导企业数字化转型。
|
||||
|
||||
但是,很多人都不太清楚到底什么是企业架构,觉得企业架构就是个“花架子”,很虚,很抽象,对实践的指导意义不大,做不做都没问题,照样可以搞企业端的软件开发 。
|
||||
|
||||
其实,这正是做数字化转型非常大的误区。如果没有整体观念,只是孤立地看待每次开发任务和每一个子系统,最后会导致你花了大价钱开发的各类系统之间互不协调,不但形不成合力,甚至会导致数据的不一致,使企业反倒被自己开发的系统所累。
|
||||
|
||||
数字化转型注定是企业的整体转型,**如果不了解企业架构,你或许能帮助企业实现一些很不错的数字化创新点,但是无法帮企业实现整体转型**。
|
||||
|
||||
所以,今天,我就跟你介绍下企业架构,包括它的发展历程和未来的方向,打破你对企业架构的误解,帮你建立起正确的认知,以免被某一种架构理论限制住自己的思维,阻碍了数字化转型的进程。
|
||||
|
||||
首先,我来给你讲一讲,为什么需要企业架构,它是怎么发展的。
|
||||
|
||||
## 为什么需要企业架构?
|
||||
|
||||
这里我们要先明确一个问题,不是所有的软件都会用到企业架构。虽然软件都有架构,但不同类型的软件考虑架构的视角不太一样。
|
||||
|
||||
从最终用户的角度看,软件大致有2种类型,给个人消费者用的,就是C端软件;给企业用户用的,也就是B端软件。
|
||||
|
||||
C端软件的使用者是个人,所以,我们就不需要考虑企业架构的问题了,应该把个人使用习惯和感受放在第一位。但这不意味着C端软件的开发者就不必了解企业架构了,因为不少C端软件是企业开发出来的,作为企业来讲,还需要关注如何提升自己的开发效能,这也会用到企业架构。
|
||||
|
||||
而B端软件是给企业用的,设计得对不对、好不好,就得考虑企业到底是什么情况了。而且,每个企业都会用到很多软件,往往企业规模越大,用的软件就会越多,软件之间的协作也是一个必须考虑的问题。比如,中小银行可能会有100~200个业务系统,大型银行则会有800~1000个业务系统。那么,这些系统在业务协同和数据一致性方面怎么保证呢?
|
||||
|
||||
要想解决这个问题,就要用企业架构这种“顶层设计”了。不过,要是你以前没怎么接触过企业架构,可能一下子不太好理解我为什么这么讲,那咱们接下来就从软件行业的发展历程,来看看企业架构是怎么诞生的。咱们软件行业的前辈们可是没少吃缺乏顶层设计的亏,不然,真的认识不到企业架构的重要性。这个问题,你一定要重视。
|
||||
|
||||
早期的编程工作真的是“先写了再说”,毕竟每个行业一开始都是很懵懂的,没人知道怎么做合适。结果,这么搞了差不多20年,到上个世纪60年代,软件危机爆发了,软件开发的四大关键问题:**时间、成本、范围和质量全面失控**。人们对软件开发工作的不满越来越大,于是把建筑业、制造业的经验向软件行业引入,这就是引进工程化思想的开始。
|
||||
|
||||
大名鼎鼎的第一个软件工程模型“瀑布模型”就诞生于1970年,是温斯顿∙罗伊斯提出的。“瀑布模型”本身是一个观察结果,它指出软件开发包括系统需求、软件需求、系统分析、程序设计、编码、测试、运营等若干环节,这是第一次有人说清楚软件制作过程到底是怎样的。
|
||||
|
||||
工程化思想确实可以提高单个软件的质量,但是企业需要的通常是一堆软件,你现在可能就用过办公邮件、文件管理、ERP、CRM、MIS,等等,银行里更是会有几百个系统。
|
||||
|
||||
所以,单个软件质量的提升不会解决整体设计的缺陷,比如各系统间不能互相协同、数据定义不一致,出现业务孤岛、数据孤岛,你今天听说过的这些B端软件问题多数都是由来已久的,而不是刚刚出现。
|
||||
|
||||
B端软件的生命周期也可能很长,加上软件之间需要协作,如果没有良好的架构设计做顶层指导,那升级、运维的复杂性对技术人员而言,也可能是“灾难性”的。
|
||||
|
||||
这就说明,光是工程化,加强对制作过程的管理还不够,还得加强设计能力,知道如何在企业这种复杂环境下设计系统。于是,一个从整体视角看问题的软件架构设计思路就应运而生了,它就是企业架构。
|
||||
|
||||
## 企业架构是什么发展的?
|
||||
|
||||
其实,“架构”这个词也是从古老的建筑行业引进来的,不是软件行业自己搞出来的。我来介绍下它的发展历程。
|
||||
|
||||
### 提出与完善
|
||||
|
||||
企业架构思想诞生于1987年,这时候,工程化已经搞了快20年了,但大家还是没有搞清楚,在B端怎么设计软件合适。
|
||||
|
||||
IBM的雇员Zachman先生在IBM的内部刊物上发表了一篇文章《信息系统架构框架》,谈到了“架构”这个词在软件行业应用上的混乱,并提出了自己的架构设计思想,这篇文章后来被奉为企业架构的开山之作。
|
||||
|
||||
Zachman的思想最重要的一点就是,**架构是多视角的集合**,是“一套架构(a set of architecture)”,而非“一个单一的架构(a single of architecture)”。架构是从多个视角观察企业得到的结果的总和,这实际上也是上一讲中提到的架构思维的全面性。
|
||||
|
||||
换句话说,**我们不应该总抱着自己认定的视角去跟别人争,而是要努力去看看,到底需要多少种视角,才能理清企业的全貌,这样才能让我们设计的系统与企业的实际环境匹配上**。
|
||||
|
||||
Zachman的思想后来在Open Group(开放组)的努力下发扬光大了。Open Group在1995年提出了一个体系结构非常完整的方法论The Open Group Architecture Framework(开放组架构框架,简称TOGAF)。
|
||||
|
||||
TOGAF首次正式定义了什么是企业架构,他们提出,企业架构就是“具有共同目标的组织集合体的基本组成部分及其内外部关系与治理原则”。这个很怪异的“组织集合体”指的就是企业,只不过它比你平时理解的企业范围大些,能被一个目标圈进来的组织,都可以被当成一个企业看,所以,TOGAF是支持建立跨组织的架构的。
|
||||
|
||||
TOGAF认为企业架构包括业务、数据、应用、技术四部分,也称“4A架构”,实际上是4种架构视角。Zachman主张的多视角架构,在这里算是成型了,做企业架构就要完整地做出这4种架构。
|
||||
|
||||
简单地说,企业就是处理了一堆数据的一堆业务活动,这些业务活动和数据被一堆功能实现,这堆功能又被部署在一堆技术平台上。
|
||||
|
||||
除了解释企业架构是啥,TOGAF还给出了企业架构的完整开发过程,包括预备阶段、架构愿景、业务架构设计、信息系统架构等诸多过程和内容,算是跟大家说明白了企业架构该怎么去做。
|
||||
|
||||
企业架构理论在国内外还是有一定认可度的,尤其是在传统行业,制造、能源、金融、航空等领域,不少大企业都在用这个方法论指导他们的IT规划。不过,这也经常使人认为,企业架构是大企业才能搞的东西。但实际上,作为一种指导复杂环境下多系统协同设计的理念来讲,企业架构理论是不区分企业规模的。对于企业而言,没有企业架构思想,连系统的内部协同都做不好,又怎么进行数字化转型呢?
|
||||
|
||||
好,知道了企业架构的必要性,你可能会觉得,这东西你说得这么好,还有很多大企业支持,怎么我好像就没听过呢?或者说,听过的可能也觉得没有那么好。其实,这就是企业架构目前略有尴尬的处境了。
|
||||
|
||||
### 现状
|
||||
|
||||
TOGAF诞生后,企业架构理论就在一路争论中缓缓前进了。这主要是因为,并不是有了方法论,企业架构的搭建就变简单了。实际上,人们反倒是充分地看到了企业整体架构有多复杂,这也导致了很多疑虑。
|
||||
|
||||
首先就是对方法论的质疑。
|
||||
|
||||
一方面,如果企业本身很复杂,一次性梳理企业全貌的话,投入的人员太多、周期太长,不仅会增加失败的风险,也容易跟不上业务的快速变化。
|
||||
|
||||
另一方面,这种设计复杂度太高,很多人都担心容易设计不到位,变更也麻烦。不知道怎么克服这些现实问题,很多企业就产生了顾虑。
|
||||
|
||||
其次,还有很多来自于对传统软件工程的质疑。
|
||||
|
||||
一提到传统的瀑布式开发,大家觉得又慢又容易落后,所以敏捷开发兴起,敏捷开发通常会搞短周期迭代,这就意味着,没给企业架构这种长周期的梳理工作留时间。
|
||||
|
||||
但是实际上,敏捷开发本身也需要关注企业全局。就像我在上节课说的,你给5件事排序,跟你给10件事排序,结果是不一样的。对敏捷开发来讲,过于强调快速设计,考虑问题的范围就可能会比较狭窄,那得出的设计方案也可能是有问题的,并非所有需求都是“火烧眉毛”的。
|
||||
|
||||
除此之外,也出现了否认企业架构可以整体设计的方法,比如领域驱动设计(DDD)的提出者Eric Evans就曾在对“总体规划”方法表示了一种委婉的不信任,也提出“使用不合适的结构还不如使用它,因此最好不要为了追求设计的完整性而勉强去使用一种结构,而应该找到尽可能精简的方式解决所出现的问题。要记住宁缺毋滥的原则”。
|
||||
|
||||
但是,现在国内的一些DDD应用发现,如果没有自上而下的考虑,不与企业战略、组织结构适当结合,做架构设计还是很困难的,所以,国内最近这些年的DDD应用,也在往结合企业整体分析的路线上走。 除了怀疑之外,还有积极的进展,有一些新方法论陆续诞生,其中影响最大的莫过于从互联网领域发展出来的、以能力复用为主要目标的中台架构。
|
||||
|
||||
中台设计其实也是考虑企业全局的设计思路,从互联网企业一开始的猛打猛冲,走向了提倡节省资源、内部复用的中台化,实际上是选择了企业架构方向,尽管走的不是传统路线。
|
||||
|
||||
虽然2020年底又传出了阿里巴巴集团“拆中台”的声音,但是,你也不用太在意,中台的走势就像软件行业发展历程的缩影:从乱中取胜搞出软件危机,到强调秩序,诞生软件工程,再从单纯强调秩序转向自由选择,一切从实际出发,不对复用或不复用搞“一刀切”,就是跟着企业自己的需要在变而已。
|
||||
|
||||
虽然有各种声音,但是,随着数字化转型的到来,包括互联网公司在内,很多企业也在重新认识企业架构,大家越来越认可全局视角对数字化转型的价值,**不考虑整体而获得的局部灵活性,一定程度上也是在给未来积累技术债务**,这是阿里巴巴集团搞中台的“初衷”之一,也是很多互联网企业随后都发布了自己家的“中台”的原因吧。
|
||||
|
||||
### 未来
|
||||
|
||||
那么,企业架构要怎么发展,才能支持数字化转型呢?这里有两个重要的方向,分别是更好地适应企业生态越来越开放的发展要求,以及充分提升软件开发效率,才能让软件生产速度跟得上软件需求的疯狂膨胀。这两个方向的应对之道,分别是开放式架构和行业级标准化。接下来,我分别来讲一讲。
|
||||
|
||||
**1.开放式架构**
|
||||
|
||||
数字化时代的到来,会让大家的连接越来越容易,持续打破空间限制,人与人之间、企业与企业之间的协作也会更容易,至少在技术层面是这样。
|
||||
|
||||
这意味着,不用区分企业内外,大家可以更好地连接彼此的能力了。这种连接,也**要求我们在设计企业架构时,不能只盯着企业内部,要放眼整个生态进行设计**。像现在搞供应链管理、平台生态那样,处理好彼此关系,进行总体规划,定位好自己在生态中的位置,开放式架构是大势所趋。
|
||||
|
||||
现在,国家在“十四五”规划中,也非常重视产业链、供应链的建设,这个是更广泛的全球视野下的规划,大到国家,小到企业,道理都是一样的。“治大国如烹小鲜”,跟着国家政策走,错不了的。
|
||||
|
||||
**2.行业级标准化**
|
||||
|
||||
除了开放式架构,还有一个重要的方向是行业级标准化。关于这个方向,提的人不多,你可能听着有些陌生。实际上,企业架构理论中是考虑过这个问题的,比如TOGAF中就认为在企业自身的特定架构之上是可以存在行业架构的。
|
||||
|
||||
这种行业架构其实符合企业的长远利益,你想想,现在同一行业内的企业,软件功能存在大量相近甚至相同的东西,但是经常要重复开发,这部分的比例有可能达到开发量的60%以上,尤其是中后台业务,如果企业软件中这60%的重复部分可以开源,那对企业而言会有多大的益处!国家也是看到了开源的价值,才在“十四五”规划中鼓励企业开源自己的软件。
|
||||
|
||||
企业如果能够大胆开源自身的一些应用设计,也有助于提升自身的行业地位,接受你设计的企业越多,你与别人的连接也会更容易,对生态建设也更有利。此外,有人多帮你看看设计、看看代码,对软件质量提升也有好处。
|
||||
|
||||
## 总结
|
||||
|
||||
今天,我讲了企业架构的发展历程。到现在,这个理论才30多年,就是个青年,真算不上老,不要总被快节奏带着跑,很多事儿都需要沉淀,尤其是企业架构这种要把企业总体都看透的方法论,无论是方法论自身,还是学习者,都需要好好修行,这不是快餐,得和时间做朋友。
|
||||
|
||||
企业架构的流派虽然不止一个,但是总体来讲不算多,要想不被概念忽悠,最好的办法是花点时间,把这些理论都看看,自己心里有个数,才不会“中招”。
|
||||
|
||||
面向未来,企业架构的发展方向是开放式架构,也就是说,做企业架构不但要熟悉自家的事情,还要了解整个生态的事情。未来还要注重推动行业级标准化,这样才能不浪费大家宝贵的青春。
|
||||
|
||||
企业架构中还有一个重要话题,就是业务架构,业务架构是数字化转型的关键,是架构思维进入企业管理层乃至各个层面的关键,下节课我会重点给你讲一讲业务架构。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/4c/2d/4cbe0e0e1f993652323b1a567c2ed32d.jpg" alt="">
|
||||
|
||||
## 思考题
|
||||
|
||||
课后希望你可以结合今天所学的内容,分析一下自己的公司,如果推行企业架构,是不是可以把软件做得更好?
|
||||
|
||||
欢迎你畅所欲言,和我一起交流讨论。如果你觉得今天的内容对你有所帮助,也欢迎你分享给你的朋友或同事。
|
||||
154
极客时间专栏/geek/说透数字化转型/基础篇/05 | 业技融合:如何打破技术和业务的壁垒?.md
Normal file
154
极客时间专栏/geek/说透数字化转型/基础篇/05 | 业技融合:如何打破技术和业务的壁垒?.md
Normal file
@@ -0,0 +1,154 @@
|
||||
<audio id="audio" title="05 | 业技融合:如何打破技术和业务的壁垒?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e4/5f/e4c7e30f330c6afddaa79cde4879c45f.mp3"></audio>
|
||||
|
||||
你好,我是付晓岩。
|
||||
|
||||
你可能经常听到人们说业技融合,那什么是业技融合呢?简单来说,就是业务和技术一起想办法解决问题。
|
||||
|
||||
不过,业务和技术一起谈如何解决问题,并不是现在常见的业务给技术提个需求、技术听完了去开发个软件这么“流程化”的事情,而是大家都把技术作为重要手段,一起去想怎么解决业务问题最好,这才是所谓的业技融合。能这样坐在一起聊,双方最好有个互相接近的思维模式,有点儿“共同语言”。不然,业务敞开了聊业务,技术满脑子都是技术,沟通效率自然很差,而业务架构就是一种能够提升效率的共同语言。
|
||||
|
||||
但是,目前我们对业务架构的实践普遍比较少,很多人不太清楚业务架构到底是啥,具体怎么做。所以,这两节课,我就来详细地给你讲一讲业务架构。
|
||||
|
||||
今天,我会先跟你聊聊业务架构是什么、有啥不足,以及它对数字化转型的独特价值。知道了这些,你就建立起了对业务架构的基本认知,下节课我再跟你聊聊具体要怎么做业务架构。
|
||||
|
||||
好,接下来我就先来说说业务架构到底是啥。
|
||||
|
||||
## 业务架构是什么?
|
||||
|
||||
业务架构是TOGAF最早定义的,**指的是企业的战略、组织结构、关键流程等内容**。
|
||||
|
||||
TOGAF给的是个枚举型的定义,也就是举例子说明业务架构应该包括什么,有什么样的战略有什么样的组织架构,遵循哪些业务规则,有什么样的关键流程。
|
||||
|
||||
TOGAF 9.0之后的版本,重点加强了对业务架构的介绍,它约定的业务架构设计阶段交付物有很多,如下图所示:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/bf/f8/bf282062710yyb4a202cf1d856fbbcf8.png" alt="">
|
||||
|
||||
从这个清单中,你应该能感受到,业务架构设计要是实实在在地做下来,一点儿都不虚,很实,还很有难度。
|
||||
|
||||
这里面的流程梳理、岗位角色识别与设置、数据建模、业务组件设计,都是既需要架构设计技巧又需要管理智慧的。因为大家争的往往不是你要梳理的那个流程,而是这个流程会代表的内部分工、责任边界。有时候,还会遇到没人拍桌子就会一直扯不清的东西。
|
||||
|
||||
你是不是还觉得这个定义还是不太好理解,没关系,我根据自己的业务架构工程经验,总结了一个偏操作性的定义:
|
||||
|
||||
>
|
||||
业务架构是以实现企业战略为目标,构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法。
|
||||
|
||||
|
||||
这里有三个关键词,“整体”、“结构化”和“传导”,这是业务架构的特点。我来重点分析下。
|
||||
|
||||
**1.整体**
|
||||
|
||||
业务架构看问题要全面,要从企业整体出发去设计业务架构。
|
||||
|
||||
以往的竖井式开发,我们通常都把业务所需要的东西全都做在一个系统内,不管各个业务领域之间是否有重复,这样的架构格局必然是重复较多,不太合理的。现在很多企业都意识到自己家的众多系统之间不协调、不一致,其实这个问题不在系统,而在于没有统一的业务架构设计,没有明确系统间的横向关系,没有把重复部分(比如客户、销售等公用功能)整合起来,而是把业务分散在各个领域进行完整而又封闭的设计,这就会导致很多问题。
|
||||
|
||||
对于这一点,业务架构的解决之道就是从整体出发进行合理布局。这样的设计是最经济的,但是难度相对也是高的,业务分析上,每个领域都不能只看自己家的领域。只要是跟你的领域相关的,都要横向考虑到。
|
||||
|
||||
此外,要落地企业战略,也需要看到企业的全貌,完整知道企业各个部分之间的相互关系,这样才好分解战略,不然,就可能出现对战略分解上的盲区,影响战略的落地。
|
||||
|
||||
全面是架构思维的首要特点,业务架构也是如此。
|
||||
|
||||
**2.结构化**
|
||||
|
||||
结构化是业务架构分析问题的方式。有了刚刚的对业务横向拉通的全面认知,还要把你的认知结果表达出来,这样才能把它们传导给要去做开发的技术人员。
|
||||
|
||||
表达可以有很多种方式,而用来跟技术人员衔接的最好方式莫过于结构化地表达,通过模型之类的手段,把业务架构设计成果表达成技术人员比较好理解的形式。在做模型的时候,如果有设计系统的支持就更好了。如果总是把方案搞成一大堆Word文档和PPT,谁也不好查找。
|
||||
|
||||
现在也有一些可用的建模工具和架构管理工具(比如可以用来与TOGAF过程配合使用的ArchiMate建模工具,有一套标准的、可相互集成的软件工具集支持的ARIS模型框架,等等),有些是架构管理的,有些是流程管理的。不过,相对来说,工具还是比较缺乏的,这主要是因为架构方法论的实践不够充分,再加上架构管理工具与软件开发全生命周期管理的衔接本身也不容易,所以这方面还需要逐步完善。
|
||||
|
||||
**3.传导**
|
||||
|
||||
**把自己对业务的认知准确地传导给技术,也是业务架构的任务**。
|
||||
|
||||
实现好的传导需要两个条件:
|
||||
|
||||
- **优质的内容**;
|
||||
- **相应的机制**。
|
||||
|
||||
要注意的是,这两个不是并列的条件,而是相辅相成的。
|
||||
|
||||
在内容方面,业务架构要先帮助业务理清自己的环境、搞清业务痛点、设计出解决方案,这样才能向技术传导准确的东西,不然,大家都是一头雾水,就没办法进行下一步了。如果不能帮助业务一侧找到合理的解决方案,就不会有什么好的技术方案诞生。
|
||||
|
||||
但这一点,也正是机制上的一大缺陷。业务架构的工作方式没有走出技术圈子,没有走到业务人员中间去。实际上,应该让业务架构思维在业务一侧被广泛接受、使用,这样才能保证持续产生好的业务架构解决方案,促进业技融合,这并不是有了业务架构师就万事大吉了。
|
||||
|
||||
目前能做这种架构思维推广的人还很少,而人少的原因其实就是企业本身没有采用这种工作机制,自然也就培养不出这样的人。
|
||||
|
||||
现在,有了业务架构,战略、业务、技术这三个在企业管理中很容易出现衔接问题的东西,就被一根绳子串起来了,自然也就可以帮助业务人员找到可落地的业务解决方案,帮技术人员理解战略和业务到底要怎么实现,从而找到更好的技术解决方案。这就是业务架构的价值所在。
|
||||
|
||||
你想想,这不就是数字化转型的要求吗?大家要通过数字化创造新模式、新业态,要加强技术对业务的支持作用,要实现业务和技术的深度融合,说到底不也是这些东西吗?
|
||||
|
||||
当然了,业务架构不是“银弹”,更不是“无懈可击”,无论是企业还是个人,如果想有持续的进步,一定要有能力去发展和改进自己的工作方法。
|
||||
|
||||
想把它用好,也要清楚如何去完善它的不足,这样才能进一步提升你的数字化能力。那怎么改进呢?
|
||||
|
||||
## 业务架构的改进方向
|
||||
|
||||
以往的业务架构比较偏重于流程分析,对于现在这种极度追求软件开发效率的工作模式来讲,总会觉得花这么大精力去做个偏流程的分析,跟最后技术想拿来搞实现的东西是有差距的,作用不直接。
|
||||
|
||||
此外,业务架构要想发挥更大的作用,必须能被更多的业务人员使用才行。不然,它就是一个架构师圈子里小范围应用的技术工具,没法为实现业务和技术深度融合发挥更大作用了。
|
||||
|
||||
所以,关于业务架构的改进,主要有2个方向:一是业务架构设计思路的改善,二是建立合适的工作机制。
|
||||
|
||||
### 如何进一步改善业务架构的设计思路?
|
||||
|
||||
不知道你有没有想过这样一个问题:业务架构为什么很小众,不太受重视呢?
|
||||
|
||||
其实,这是因为“硬核”的技术专家们往往对这个不感兴趣。很多技术人员觉得它很“虚”,也就是跟软件详细设计的关系不紧密。技术人员好像可以通过这个更好地了解企业,但是又认为梳理出来的东西往往是偏宏观、偏业务的。可以当个背景资料参考,但是如果用它继续去做详细设计,总觉得差点儿意思。
|
||||
|
||||
这个问题的根源是,**当前的业务架构设计实践**没能把数据和流程很好地结合起来。
|
||||
|
||||
现在,大家都知道数据很重要,是新的生产要素,甚至还有“一切业务数据化,一切数据业务化”的口号。但是,具体怎么做呢?
|
||||
|
||||
当然得用笨法子一点一点做,骐骥一跃,也不能十步啊,咱们只能一个流程一个流程地去分析,把流程中要用到的、会创建的数据找出来才行。
|
||||
|
||||
虽然传统的需求分析也会这么做,但是做出的成果是分开的,流程的归流程,数据的归数据,该一起做的事情,却分成了两块。不仅分析过程可能浪费了时间,也达不到理想的效果。要是数据分析直接跳过与业务过程的衔接,跑到数据库表的设计层面,那就更糟糕了。
|
||||
|
||||
其实,**软件设计的核心就是分析行为和数据**,也就是软件的功能以及这些功能要涉及到什么数据。**把数据和流程一起说明白,是技术人员最愿意看到的业务分析结果**。
|
||||
|
||||
所以,**业务架构的改进方向之一,就是将原有的业务架构和数据架构融合起来,形成新的业务架构**。可以考虑把TOGAF中原来的业务、应用、信息(数据)、技术四个架构视角,去掉一个,让数据架构融入其他架构视角中。
|
||||
|
||||
当然,这不是说数据模型没了,而是业务模型和数据模型应该一起建,两者结合在一起考虑流程怎么切分、数据实体怎么切分,切分后的流程和数据实体到底是什么关系,这样才能更有利于对技术的衔接,同时又不至于失去业务友好性,让业务人员不好理解。
|
||||
|
||||
### 如何改进工作机制?
|
||||
|
||||
如果只改进设计思路,还不足让业务架构得到广泛使用,业务架构总在技术圈子里的打转儿是没前途的,得走出来,才能真正发挥出作用。
|
||||
|
||||
业务架构以往的工作方式,尤其是在TOGAF体系中,经常被认为是为了构建企业级系统而延伸出来的一个分析业务的环节。这就导致,在很多时候,业务架构会被当作企业级工程的一部分,采用的是类似于需求分析工作的管理模式,按流程坐等需求上门,忽略了独立应用业务架构方法,去解决业务人员落地企业战略、搞业务创新的可能性。
|
||||
|
||||
实际上,业务架构的核心价值,包括推动企业战略落地、通过架构设计提升业务协同性、促进业务与技术融合,这些都不是待在技术圈子里可以解决的问题,也不是待在技术圈子里就能培养出来的能力,必须得走到业务中间去。
|
||||
|
||||
那咋做呢?很关键的一点就是把业务架构师派到业务部门去工作,让业务架构师第一时间接触到业务人员的各类创新想法,并用企业的业务架构合理引导业务创新落地,帮助业务人员更好地理解技术可以带来的想象力。
|
||||
|
||||
当然,这也面临一个问题:现在大家都觉得好的业务架构师很少,无人可用,这个问题怨不得别人,只能怨我们自己,不培养,怎么会有呢?挖墙脚都没地方挖去。不能等有合适的人了再去做,而是要通过做起来去培养人。
|
||||
|
||||
而且,对于个人来说,这么好的时代机会摆在面前,在业务架构师如此稀缺的情况下,你具备了这样的能力,自然也就能走在别人的前面,关键是要有前瞻性。所以,你要经常训练自己的结构化思维和沟通能力,看到啥都想着用结构化的思路拆解下,经常模型化地思考问题,好好把自己的思路传达给别人。
|
||||
|
||||
通过设计思路和工作机制的改善,业务架构的桥梁作用还可以发挥得更好,而这座桥正是业务人员面向数字化转型最需要的。接下来,我再来说说业务架构对数字化转型最独特的一个价值。
|
||||
|
||||
## 业务架构对数字化转型最独特的价值
|
||||
|
||||
在数字化转型过程中,最艰难、最痛苦的很可能是现在的业务人员。现在技术变化太快,技术对原有业务形态的冲击很大。
|
||||
|
||||
比如,移动互联网兴起大约也就十年的时间,移动端的开发技术、安全技术变化都非常快,在业务侧,网约车、社区团购、黑客增长、私域流量等玩法纷纷涌起。技术的变化速度让搞技术的专业人员都应接不暇,感叹自己职业寿命太短,学不过来,那业务人员情何以堪啊?哪些技术哪天会替代一个旧工种搞出一个新工种,谁也说不清。
|
||||
|
||||
现在人们常说,“最可能击败你的不是对手,是新手”。一些跨界而来的人,带着新思维、新手段,还没有旧包袱,占尽天时地利人和,传说中的“降维打击”也都是这个道理。无论是企业还是个人,都会面临这样的冲击。
|
||||
|
||||
那数字化转型是要业务人员现在转行去学技术吗?当然不是,**提升对业技融合的支持能力才是出路**。就像我一开始提到的,想要实现业技融合,形成合力,就需要相近的思维模式和共同语言,这就是业务架构能做的事情,不然就会像修“通天塔”的故事那样,各说各话,最后导致修塔失败。
|
||||
|
||||
**提升业务与技术之间的沟通效率,是未来企业竞争的焦点**。你想想,如果经过数字化转型,大家都成为具有一定科技实力的数字化企业了,那最终我们要比拼什么?是不是又回到了谁家的业务人员能帮技术人员更快了解市场这个点上?而这个拼的就是沟通效率。
|
||||
|
||||
只要业务人员能够适当结构化自己的思维,好好利用、打磨业务架构方法,在不转行学技术的前提下,也能更好地跟技术人员沟通。
|
||||
|
||||
## 总结
|
||||
|
||||
我们来小结下。业务架构最早是TOGAF定义的,关注的是企业的战略、组织结构、关键流程等内容。我结合自己的实践经验,给出了一个操作性的定义:“业务架构是以实现企业战略为目标,构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法。”
|
||||
|
||||
现在,业务架构的作用被忽视了,需要改进。方向有2个:一个是要把业务架构与技术设计衔接得再紧密些,把数据架构吸收进来;另一个是改进工作机制,走到业务人员中间去,把业务架构思维推向业务人员,帮助业务人员进行数字化转型。
|
||||
|
||||
这种两边“讨好”的方式,正是业务架构的价值所在,当然,它对业务架构师们也提出了不小的挑战,你要培养好自己思维的逻辑性,还要把自己打造成业务和技术两边都具备适当深度的复合型人才。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/8d/74/8d529c15ff3cf6cd7196651507e95074.jpg" alt="">
|
||||
|
||||
## 思考题
|
||||
|
||||
你自己在工作中遇到过业务架构图和业务架构师?你是怎么看待他们的呢?
|
||||
|
||||
欢迎你畅所欲言,和我一起交流讨论。如果你觉得今天的内容对你有所帮助,也欢迎你分享给你的朋友或同事。
|
||||
151
极客时间专栏/geek/说透数字化转型/基础篇/06 | 玩转业架:怎么设计业务架构?.md
Normal file
151
极客时间专栏/geek/说透数字化转型/基础篇/06 | 玩转业架:怎么设计业务架构?.md
Normal file
@@ -0,0 +1,151 @@
|
||||
<audio id="audio" title="06 | 玩转业架:怎么设计业务架构?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f0/11/f0bbedee3ff95e7f90603ba15579f711.mp3"></audio>
|
||||
|
||||
你好!我是付晓岩。
|
||||
|
||||
上节课,咱们重点学习了业务架构和业技融合的必要性,你现在一定迫不及待地想知道具体怎么推动业务和技术的持续融合了。其实,这个问题并没有很多人说的那么复杂。
|
||||
|
||||
我认为,持续推动业技融合,就是通过业务架构来让业务人员和技术人员采用相同的认知方式去认识企业和业务,形成类似共同语言的沟通基础,从而更高效地商量如何用技术手段解决业务问题。
|
||||
|
||||
接下来,我就重点跟你聊一聊怎么设计业务架构、业务架构怎么连接业务和技术,又怎么推动业务和技术的持续融合。
|
||||
|
||||
## 怎么设计业务架构?
|
||||
|
||||
业务架构设计包含四个环节:战略设计、组织设计、业务设计和组件设计。因为业务架构的目标要落地战略,自然要包含战略设计;要分解企业架构,这离不开组织设计;要设计业务和分析业务能力布局,这就要做业务设计和组件设计。
|
||||
|
||||
下面先说说战略设计。
|
||||
|
||||
### 1.战略设计
|
||||
|
||||
所谓的战略设计,也就是企业对自身发展所做的长期、全面的考虑或想法。
|
||||
|
||||
其实,不管企业是大是小,都有自己战略,无非是你用不用这么“高大上”的词来描述而已。就算是个路边摊,如果你希望通过让自己的“麻辣烫”味道与众不同来实现收入翻倍,这也是个战略,算是以客户体验为中心的差异化战略,只不过是看起来很简单而已。
|
||||
|
||||
**没人说过,简单就不是战略,倒是有人说过,战略应该简单**。
|
||||
|
||||
业务架构设计是为了实现企业战略的全面落地,所以,设计的起点就是企业战略。不知道战略,就没有了评判价值的标准。如果架构设计的过程中遇到问题,我们经常要从“哪个方案更符合战略要求”的角度来做决策,所以,绝对不能忽视战略。
|
||||
|
||||
成功企业都挺重视战略管理。头部科技企业,比如说阿里巴巴、腾讯、字节跳动、华为等,都有自己的战略管理,传统企业就更不用说了,大型银行一般都有自己的战略规划部。越是这种成功企业,越害怕自己是在没有方向地乱闯、碰运气,他们很关心自己的战略,还经常晒到网上,公开立下“flag”。最近,很多企业都在晒自己的数字化战略,比如,中广核、中国石化、南方电网等央企都明确表示,将数字化转型工作定为“十四五”时期的重点任务。
|
||||
|
||||
### 2.组织设计
|
||||
|
||||
业务架构设计的第二步是组织设计,组织设计就是明确企业的内部组织结构与分工,也就是确定企业有多少部门、团队、岗位,等等,组织设计主要目的是通过分工建立协作。
|
||||
|
||||
新战略通常会带来对现有组织结构的改变,因为战略也是一种任务,对于企业而言,不管是完成什么任务,都需要聚集一定的资源,尤其是人这个最宝贵的资源,人的聚集就是组织结构。
|
||||
|
||||
在新战略制定前,组织结构都是根据过去的战略要求建立的,跟新战略未必匹配。所以,很多企业一发布新战略,接着就调整组织结构,保证有合适的人对新战略负责。
|
||||
|
||||
组织设计是很难的事情,因为没有太合适的原则能够帮助我们判断设计是否合理,没有人真能告诉你一个企业设置多少个部门、团队、岗位是合适的,往往要通过对调整结果的事后观察,才能判断。比如说,观察新组织单元协同是否顺利,战略目标是否如期实现等,如果观察结果不理想,那也只能再调整。
|
||||
|
||||
对于数字化转型而言,很多人也在谈到底什么样的组织模式适合数字化企业,目前没什么定论,但可以肯定的是,一定要具备灵活多变的调整能力。
|
||||
|
||||
### 3.业务设计
|
||||
|
||||
业务架构设计的第三步就是业务设计了。有了战略设计,我们就知道企业的发展方向是什么,有了组织设计,我们就可以去识别每个部门、每个岗位有什么职责。这样,我们就可以着手去设计企业的业务了。
|
||||
|
||||
简单来说,**业务设计就是把企业的业务流程和涉及的数据规范地梳理出来**。一般这会包括两个阶段,首先梳理现状模型,也就是业务当前什么样,之后就是第二段,把战略导入进来,看看要怎么调整现状业务,这就产生了目标模型,最后我们要用来落地战略的就是目标模型。
|
||||
|
||||
我举个小例子你就明白了。
|
||||
|
||||
一个汽车销售企业,大致的业务会包含进货、营销、沟通、卖车,里面可以设计出很多业务活动,每个活动下还可以再细分成由各个岗位执行的不同任务。比如市场部门的营销岗可能会组织一个营销活动,做了个营销方案,借此收集了一些客户信息,销售顾问岗就可以通过这些客户信息去跟客户沟通,进行推销。
|
||||
|
||||
企业这种基于一定的数据完成业务活动的过程其实就是业务能力,也就是说,业务能力包含两部分,业务数据和处理这些业务数据的业务活动。对数字化企业而言,这个描述非常适用。
|
||||
|
||||
刚刚介绍的就相当于现状建模,在这个阶段,不需要粉饰问题,因为这样才知道准确的出发点。把数字化战略带入到现状模型中,识别当前业务需要调整的部分,该增加数据的增加数据、该增加流程的增加流程,就得到了目标模型。
|
||||
|
||||
比如,刚才的汽车销售企业,如果把数字化转型目标定位在通过互联网实现更大规模的销售,那企业原来没有的线上销售渠道、业务流程等,都要作为新需求设计出来,这样才能整理出企业未来的业务模式。
|
||||
|
||||
**需要注意的是,业务架构设计过程中,最麻烦的是流程标准化和数据标准化**。因为要做很多跨领域、跨部门的横向比较和整合,企业规模越大、复杂度越高,为此消耗的时间也就越多。但是,不管有多困难,这些标准化工作对我们要在数字化转型时所做的流程自动化、智能化,是非常重要的基础工作,一点也不容马虎。
|
||||
|
||||
### 4.组件设计
|
||||
|
||||
业务架构设计的最后一步,也就是组件设计。
|
||||
|
||||
业务组件是啥呢?就是业务能力的分组。业务能力包括数据和流程两部分。在业务设计阶段,我们做了标准化,把重复的流程和数据统一了。那么,为了进一步规划该把哪些能力设计到一个业务系统里合适,我们就需要进行业务能力的分组了。
|
||||
|
||||
从设计上看,业务能力的分组就是先把关系相近的数据聚在一起,再把处理这些数据的流程聚在一起,这些关系近的数据和流程就形成了业务组件。业务组件就像一个一个“抽屉”,把业务能力分类装在“抽屉”里,用的时候好找。
|
||||
|
||||
你可能会问,业务设计已经说明了面向数字化的业务流程和业务数据,我们为什么还要设计业务组件呢?
|
||||
|
||||
其实,这是为了帮业务侧更好地了解企业业务能力的分布情况。
|
||||
|
||||
业务设计是一直分析到业务活动和数据的,这些分析的颗粒度比较细,如果企业太大,那流程模型可能有数百甚至上千个业务活动,数据模型可能有几千个数据实体,如果不把它们归归类,你手里就只有一个充满各种细节的小比例尺地图。
|
||||
|
||||
但很多时候,业务分析、业务规划都是先从大比例尺地图开始的。就像省政府安排工作时,一般不会直接布置到街道、社区,而是会先在地级市层面分工,再逐级向下。
|
||||
|
||||
所以,业务架构在整理好细节后,也应该提供大比例尺地图给业务侧,只有把粗的地图和细的地图都准备好,才能更好地支持业务设计。而业务组件就是这个大比例尺地图。
|
||||
|
||||
业务设计和组件设计这两个阶段,描述了数字化转型目标下的企业业务模式和能力分布。有了这两个设计,企业就能在各个业务环节上落实数字化战略了。
|
||||
|
||||
为了帮助你理解,我画了一张图,来展示业务架构设计的一般过程:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/f6/09/f6007068e1ee5788a25fa0a5a0564409.jpg" alt="">
|
||||
|
||||
学到这儿,你可能会想,这个业务分析过程是不错,跟我现在做的需求分析、产品设计是不太一样,但是我也没看出来,为啥这么做,就一定能促进业务和技术融合啊?其实,这里还有一个更深层次的设计逻辑。下面我就来讲讲,业务架构是怎么连接业务和技术的。
|
||||
|
||||
## 如何能够连接业务和技术?
|
||||
|
||||
咱们怎么才能把业务和技术衔接起来呢?答案就是沟通,简单点儿说就是“聊”。听上去好像很简单,但是做到这一点是很不容易的,我们需要自己创造条件。
|
||||
|
||||
在数字化转型中,企业面对的很重要的一个问题就是如何在一个企业内同时管理两个行业,一个是业务、一个是技术,还得把它们搞到一起去。我们经常会在建立内部的管理机制、项目的开发模式、各种技能培训上下功夫,但是却会忽略一个很简单的事实:**业技融合最离不开的是沟通,因为这是人们之间能够协作的基础**。
|
||||
|
||||
业务人员会用自己的“语言”描述自己的业务,比如流程图、制度、手册等;技术人员会采用用户故事、类图、时序图等“语言”描述自己对业务的理解。
|
||||
|
||||
对技术人员而言,业务人员的那些“语言”就是帮助他们了解业务背景,并不会深入应用到设计中,因为这些语言比较偏向于描述过程,而技术人员需要的是对流程和数据相结合的分析,毕竟这样更有利于进行设计。也正因为不能深入应用到设计中,很可能业务人员的真实诉求也没有完整地传导到技术侧。
|
||||
|
||||
对业务人员而言,技术的“语言”也缺乏“友好性”,他们很难理解,这就导致他们无法判断系统的设计是不是能适应业务的灵活变化。
|
||||
|
||||
最终,系统设计可能跟业务的需要是有偏差的,根源就在于双方无法深入沟通。而数字化转型需要业务与技术之间进行深度合作,不解决“语言”问题,转型风险很大。
|
||||
|
||||
怎么填补“语言”上的空白呢?业务架构正好有这个能力。学习了刚刚的设计业务架构的过程,你应该可以发现,业务架构是按照业务人员的习惯梳理的,而且做了一件很重要的、以前业务人员不会去做的事情,就是**把流程模型和数据模型的分析结合起来**。
|
||||
|
||||
这种结合实际上是一个面向“技术”设计的分析,为双方的沟通建立了一个很关键的连接点,让业务分析更轻松地过渡到技术设计。我非常建议业务人员和技术人员一起做这个环节,可以加深双方的相互理解,减少数字化转型过程中的“误解”。
|
||||
|
||||
同样,我还是画一张示意图来帮助你理解,这张图是对业务架构内在逻辑的描述。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b8/ae/b8a47766478c50dec6bf098e545389ae.jpg" alt="">
|
||||
|
||||
从纵向看,它显示了业务架构是怎么通过对业务的分析,把企业的价值创造过程从最粗的价值链分解到最细的任务和数据的;从横向看,它显示了业务是怎么把价值链的各个环节、活动、任务串连起来的。
|
||||
|
||||
从上往下看,是业务视角的,反过来,从下往上看,是技术人员的视角。业务组件中任务和数据的结合,给技术人员提供了分析功能时所需要了解的行为和数据的关系。顺着任务再往上,还可以通过活动找到应用场景,可以看到,底层设计如何一层层地向上支持业务,支持价值创造。
|
||||
|
||||
一张图兼容了业务和技术的视角,你想想看,如果企业能够有效执行这套方法,不是只把它当成企业开发软件用的东西,是不是业务和技术就找到了共同语言?
|
||||
|
||||
## 如何持续推动业技融合?
|
||||
|
||||
既然业务架构是推动数字化转型的共同“语言”,我们可以利用它持续推动业务和技术的深度融合。
|
||||
|
||||
共同“语言”得被更多人掌握才会更有价值,尤其是业务人员。数字化转型对业务人员的挑战是更大的。毕竟技术人员本就属于搞数字化的,而业务岗位随着数字化程度的提高,会需要越来越多的数字化技能,这属于时代进步的要求。
|
||||
|
||||
而作为衔接业务和技术两端的人,业务架构师要率先发力。我们可以通过推动企业架构项目、开展业务架构培训等方式,先培养足够的业务架构师,再把他们派到业务部门去。在业务部门工作有以下3个好处:
|
||||
|
||||
1. 可以在部门需求形成初期就用架构思维进行引导,以免部门想法已经成熟、时间已经花了之后,再跟部门去争论、修改,那就比较难了。
|
||||
1. 可以更快地收集业务信息和变化,有利于加快IT反应速度。
|
||||
1. 没事儿坐在一起聊天,可以普及新技术方向、用法,帮业务找痛点,帮技术找场景。
|
||||
|
||||
不要小看聊天,从管理学角度讲,企业中的非正式沟通比正式沟通量更大,解决的问题更多,聊天是非正式沟通中的重要手段。而且,**聊得越多,帮得越多,融合也更容易实现**。
|
||||
|
||||
另外,业务架构师在业务部门的工作可以定期轮换,这有助于帮助他们更好地建立企业级思维和认知。经过业务架构师梳理的需求再有序传导给开发团队,有问题再找企业架构进行决策,形成一个良好的工作链条,如下图所示:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/7c/56/7c7a68f79f5b5043afd3a0d96052c956.jpg" alt="">
|
||||
|
||||
## 总结
|
||||
|
||||
这节课,我们学习了设计业务架构的四个环节,分别是战略设计、组织设计、业务设计和组件设计。同时,我还讲到了怎么衔接业务和技术、怎么持续推动业技融合。通过这些,我们快速地了解了业务架构该怎么玩。
|
||||
|
||||
不过,这不是要你死记硬背、僵化执行,搞架构最难的是灵活应对,架构可不是“一招鲜吃遍天”,架构可以参考,但不能简单抄袭,抄袭有点儿拿别人的药方子抓药给自己吃的意思,容易出问题。
|
||||
|
||||
到这儿呢,我已经把构建数字化转型方法论需要的思维模式、理论基础都跟你讲了一遍。我再简单带你回顾下。
|
||||
|
||||
数字化转型是一个企业的整体转型,是从信息时代跨越到数字时代的转型。这个转型不仅是企业自己的事情,还是整个社会的事情,全社会都要走进数字化,这会带来环境的大幅度变化。所以,你需要从一个面向长期的方法论和战略中获得指导,以免掉队。
|
||||
|
||||
数字化转型方法论是基于历史、生态、架构三个思维去构建的。历史思维,也就是寻找发展趋势,明确数字化目标;生态思维,也就是寻找与别人协同发展的思路;架构思维,也就是全面、结构、灵活、演进地看待数字化和自己的企业。
|
||||
|
||||
通过企业架构,尤其是业务架构,我们可以将数字化战略完整地落实到业务活动中,转化成有效的IT需求,实现深度的业技融合。这样跟自己的企业实际相结合的方法论都是独一无二的。数字化时代是更有个性的时代,希望你能够多多思考,可以参考别人的,但是不要照搬别人。
|
||||
|
||||
从下一讲开始,我就带你正式进入指南部分,带你去看看实现数字化转型的路径、能力、资源、人才等。
|
||||
|
||||
## 思考题
|
||||
|
||||
今天,我讲到了业务设计中的流程梳理,也提到了标准化。但是,可能很多企业都没做过大范围的流程梳理工作,只是在开发系统或者培训业务时画画图,还有很多人觉得现在业务变化快,梳理流程好像没有太大价值。但是,在数字化转型中,流程自动化是一个很重要的方向,那么, 你是怎么看待流程梳理这个事儿的呢?
|
||||
|
||||
欢迎你畅所欲言,和我一起交流讨论。如果你觉得今天的内容对你有所帮助,也欢迎你分享给你的朋友或同事。
|
||||
Reference in New Issue
Block a user