|
|
# 06 | 玩转业架：怎么设计业务架构？
|
|
|
|
|
|
你好！我是付晓岩。
|
|
|
|
|
|
上节课，咱们重点学习了业务架构和业技融合的必要性，你现在一定迫不及待地想知道具体怎么推动业务和技术的持续融合了。其实，这个问题并没有很多人说的那么复杂。
|
|
|
|
|
|
我认为，持续推动业技融合，就是通过业务架构来让业务人员和技术人员采用相同的认知方式去认识企业和业务，形成类似共同语言的沟通基础，从而更高效地商量如何用技术手段解决业务问题。
|
|
|
|
|
|
接下来，我就重点跟你聊一聊怎么设计业务架构、业务架构怎么连接业务和技术，又怎么推动业务和技术的持续融合。
|
|
|
|
|
|
## 怎么设计业务架构？
|
|
|
|
|
|
业务架构设计包含四个环节：战略设计、组织设计、业务设计和组件设计。因为业务架构的目标要落地战略，自然要包含战略设计；要分解企业架构，这离不开组织设计；要设计业务和分析业务能力布局，这就要做业务设计和组件设计。
|
|
|
|
|
|
下面先说说战略设计。
|
|
|
|
|
|
### 1.战略设计
|
|
|
|
|
|
所谓的战略设计，也就是企业对自身发展所做的长期、全面的考虑或想法。
|
|
|
|
|
|
其实，不管企业是大是小，都有自己战略，无非是你用不用这么“高大上”的词来描述而已。就算是个路边摊，如果你希望通过让自己的“麻辣烫”味道与众不同来实现收入翻倍，这也是个战略，算是以客户体验为中心的差异化战略，只不过是看起来很简单而已。
|
|
|
|
|
|
**没人说过，简单就不是战略，倒是有人说过，战略应该简单**。
|
|
|
|
|
|
业务架构设计是为了实现企业战略的全面落地，所以，设计的起点就是企业战略。不知道战略，就没有了评判价值的标准。如果架构设计的过程中遇到问题，我们经常要从“哪个方案更符合战略要求”的角度来做决策，所以，绝对不能忽视战略。
|
|
|
|
|
|
成功企业都挺重视战略管理。头部科技企业，比如说阿里巴巴、腾讯、字节跳动、华为等，都有自己的战略管理，传统企业就更不用说了，大型银行一般都有自己的战略规划部。越是这种成功企业，越害怕自己是在没有方向地乱闯、碰运气，他们很关心自己的战略，还经常晒到网上，公开立下“flag”。最近，很多企业都在晒自己的数字化战略，比如，中广核、中国石化、南方电网等央企都明确表示，将数字化转型工作定为“十四五”时期的重点任务。
|
|
|
|
|
|
### 2.组织设计
|
|
|
|
|
|
业务架构设计的第二步是组织设计，组织设计就是明确企业的内部组织结构与分工，也就是确定企业有多少部门、团队、岗位，等等，组织设计主要目的是通过分工建立协作。
|
|
|
|
|
|
新战略通常会带来对现有组织结构的改变，因为战略也是一种任务，对于企业而言，不管是完成什么任务，都需要聚集一定的资源，尤其是人这个最宝贵的资源，人的聚集就是组织结构。
|
|
|
|
|
|
在新战略制定前，组织结构都是根据过去的战略要求建立的，跟新战略未必匹配。所以，很多企业一发布新战略，接着就调整组织结构，保证有合适的人对新战略负责。
|
|
|
|
|
|
组织设计是很难的事情，因为没有太合适的原则能够帮助我们判断设计是否合理，没有人真能告诉你一个企业设置多少个部门、团队、岗位是合适的，往往要通过对调整结果的事后观察，才能判断。比如说，观察新组织单元协同是否顺利，战略目标是否如期实现等，如果观察结果不理想，那也只能再调整。
|
|
|
|
|
|
对于数字化转型而言，很多人也在谈到底什么样的组织模式适合数字化企业，目前没什么定论，但可以肯定的是，一定要具备灵活多变的调整能力。
|
|
|
|
|
|
### 3.业务设计
|
|
|
|
|
|
业务架构设计的第三步就是业务设计了。有了战略设计，我们就知道企业的发展方向是什么，有了组织设计，我们就可以去识别每个部门、每个岗位有什么职责。这样，我们就可以着手去设计企业的业务了。
|
|
|
|
|
|
简单来说，**业务设计就是把企业的业务流程和涉及的数据规范地梳理出来**。一般这会包括两个阶段，首先梳理现状模型，也就是业务当前什么样，之后就是第二段，把战略导入进来，看看要怎么调整现状业务，这就产生了目标模型，最后我们要用来落地战略的就是目标模型。
|
|
|
|
|
|
我举个小例子你就明白了。
|
|
|
|
|
|
一个汽车销售企业，大致的业务会包含进货、营销、沟通、卖车，里面可以设计出很多业务活动，每个活动下还可以再细分成由各个岗位执行的不同任务。比如市场部门的营销岗可能会组织一个营销活动，做了个营销方案，借此收集了一些客户信息，销售顾问岗就可以通过这些客户信息去跟客户沟通，进行推销。
|
|
|
|
|
|
企业这种基于一定的数据完成业务活动的过程其实就是业务能力，也就是说，业务能力包含两部分，业务数据和处理这些业务数据的业务活动。对数字化企业而言，这个描述非常适用。
|
|
|
|
|
|
刚刚介绍的就相当于现状建模，在这个阶段，不需要粉饰问题，因为这样才知道准确的出发点。把数字化战略带入到现状模型中，识别当前业务需要调整的部分，该增加数据的增加数据、该增加流程的增加流程，就得到了目标模型。
|
|
|
|
|
|
比如，刚才的汽车销售企业，如果把数字化转型目标定位在通过互联网实现更大规模的销售，那企业原来没有的线上销售渠道、业务流程等，都要作为新需求设计出来，这样才能整理出企业未来的业务模式。
|
|
|
|
|
|
**需要注意的是，业务架构设计过程中，最麻烦的是流程标准化和数据标准化**。因为要做很多跨领域、跨部门的横向比较和整合，企业规模越大、复杂度越高，为此消耗的时间也就越多。但是，不管有多困难，这些标准化工作对我们要在数字化转型时所做的流程自动化、智能化，是非常重要的基础工作，一点也不容马虎。
|
|
|
|
|
|
### 4.组件设计
|
|
|
|
|
|
业务架构设计的最后一步，也就是组件设计。
|
|
|
|
|
|
业务组件是啥呢？就是业务能力的分组。业务能力包括数据和流程两部分。在业务设计阶段，我们做了标准化，把重复的流程和数据统一了。那么，为了进一步规划该把哪些能力设计到一个业务系统里合适，我们就需要进行业务能力的分组了。
|
|
|
|
|
|
从设计上看，业务能力的分组就是先把关系相近的数据聚在一起，再把处理这些数据的流程聚在一起，这些关系近的数据和流程就形成了业务组件。业务组件就像一个一个“抽屉”，把业务能力分类装在“抽屉”里，用的时候好找。
|
|
|
|
|
|
你可能会问，业务设计已经说明了面向数字化的业务流程和业务数据，我们为什么还要设计业务组件呢？
|
|
|
|
|
|
其实，这是为了帮业务侧更好地了解企业业务能力的分布情况。
|
|
|
|
|
|
业务设计是一直分析到业务活动和数据的，这些分析的颗粒度比较细，如果企业太大，那流程模型可能有数百甚至上千个业务活动，数据模型可能有几千个数据实体，如果不把它们归归类，你手里就只有一个充满各种细节的小比例尺地图。
|
|
|
|
|
|
但很多时候，业务分析、业务规划都是先从大比例尺地图开始的。就像省政府安排工作时，一般不会直接布置到街道、社区，而是会先在地级市层面分工，再逐级向下。
|
|
|
|
|
|
所以，业务架构在整理好细节后，也应该提供大比例尺地图给业务侧，只有把粗的地图和细的地图都准备好，才能更好地支持业务设计。而业务组件就是这个大比例尺地图。
|
|
|
|
|
|
业务设计和组件设计这两个阶段，描述了数字化转型目标下的企业业务模式和能力分布。有了这两个设计，企业就能在各个业务环节上落实数字化战略了。
|
|
|
|
|
|
为了帮助你理解，我画了一张图，来展示业务架构设计的一般过程：
|
|
|
|
|
|
|
|
|
|
|
|
学到这儿，你可能会想，这个业务分析过程是不错，跟我现在做的需求分析、产品设计是不太一样，但是我也没看出来，为啥这么做，就一定能促进业务和技术融合啊？其实，这里还有一个更深层次的设计逻辑。下面我就来讲讲，业务架构是怎么连接业务和技术的。
|
|
|
|
|
|
## 如何能够连接业务和技术？
|
|
|
|
|
|
咱们怎么才能把业务和技术衔接起来呢？答案就是沟通，简单点儿说就是“聊”。听上去好像很简单，但是做到这一点是很不容易的，我们需要自己创造条件。
|
|
|
|
|
|
在数字化转型中，企业面对的很重要的一个问题就是如何在一个企业内同时管理两个行业，一个是业务、一个是技术，还得把它们搞到一起去。我们经常会在建立内部的管理机制、项目的开发模式、各种技能培训上下功夫，但是却会忽略一个很简单的事实：**业技融合最离不开的是沟通，因为这是人们之间能够协作的基础**。
|
|
|
|
|
|
业务人员会用自己的“语言”描述自己的业务，比如流程图、制度、手册等；技术人员会采用用户故事、类图、时序图等“语言”描述自己对业务的理解。
|
|
|
|
|
|
对技术人员而言，业务人员的那些“语言”就是帮助他们了解业务背景，并不会深入应用到设计中，因为这些语言比较偏向于描述过程，而技术人员需要的是对流程和数据相结合的分析，毕竟这样更有利于进行设计。也正因为不能深入应用到设计中，很可能业务人员的真实诉求也没有完整地传导到技术侧。
|
|
|
|
|
|
对业务人员而言，技术的“语言”也缺乏“友好性”，他们很难理解，这就导致他们无法判断系统的设计是不是能适应业务的灵活变化。
|
|
|
|
|
|
最终，系统设计可能跟业务的需要是有偏差的，根源就在于双方无法深入沟通。而数字化转型需要业务与技术之间进行深度合作，不解决“语言”问题，转型风险很大。
|
|
|
|
|
|
怎么填补“语言”上的空白呢？业务架构正好有这个能力。学习了刚刚的设计业务架构的过程，你应该可以发现，业务架构是按照业务人员的习惯梳理的，而且做了一件很重要的、以前业务人员不会去做的事情，就是**把流程模型和数据模型的分析结合起来**。
|
|
|
|
|
|
这种结合实际上是一个面向“技术”设计的分析，为双方的沟通建立了一个很关键的连接点，让业务分析更轻松地过渡到技术设计。我非常建议业务人员和技术人员一起做这个环节，可以加深双方的相互理解，减少数字化转型过程中的“误解”。
|
|
|
|
|
|
同样，我还是画一张示意图来帮助你理解，这张图是对业务架构内在逻辑的描述。
|
|
|
|
|
|
|
|
|
|
|
|
从纵向看，它显示了业务架构是怎么通过对业务的分析，把企业的价值创造过程从最粗的价值链分解到最细的任务和数据的；从横向看，它显示了业务是怎么把价值链的各个环节、活动、任务串连起来的。
|
|
|
|
|
|
从上往下看，是业务视角的，反过来，从下往上看，是技术人员的视角。业务组件中任务和数据的结合，给技术人员提供了分析功能时所需要了解的行为和数据的关系。顺着任务再往上，还可以通过活动找到应用场景，可以看到，底层设计如何一层层地向上支持业务，支持价值创造。
|
|
|
|
|
|
一张图兼容了业务和技术的视角，你想想看，如果企业能够有效执行这套方法，不是只把它当成企业开发软件用的东西，是不是业务和技术就找到了共同语言？
|
|
|
|
|
|
## 如何持续推动业技融合？
|
|
|
|
|
|
既然业务架构是推动数字化转型的共同“语言”，我们可以利用它持续推动业务和技术的深度融合。
|
|
|
|
|
|
共同“语言”得被更多人掌握才会更有价值，尤其是业务人员。数字化转型对业务人员的挑战是更大的。毕竟技术人员本就属于搞数字化的，而业务岗位随着数字化程度的提高，会需要越来越多的数字化技能，这属于时代进步的要求。
|
|
|
|
|
|
而作为衔接业务和技术两端的人，业务架构师要率先发力。我们可以通过推动企业架构项目、开展业务架构培训等方式，先培养足够的业务架构师，再把他们派到业务部门去。在业务部门工作有以下3个好处：
|
|
|
|
|
|
1. 可以在部门需求形成初期就用架构思维进行引导，以免部门想法已经成熟、时间已经花了之后，再跟部门去争论、修改，那就比较难了。
|
|
|
2. 可以更快地收集业务信息和变化，有利于加快IT反应速度。
|
|
|
3. 没事儿坐在一起聊天，可以普及新技术方向、用法，帮业务找痛点，帮技术找场景。
|
|
|
|
|
|
不要小看聊天，从管理学角度讲，企业中的非正式沟通比正式沟通量更大，解决的问题更多，聊天是非正式沟通中的重要手段。而且，**聊得越多，帮得越多，融合也更容易实现**。
|
|
|
|
|
|
另外，业务架构师在业务部门的工作可以定期轮换，这有助于帮助他们更好地建立企业级思维和认知。经过业务架构师梳理的需求再有序传导给开发团队，有问题再找企业架构进行决策，形成一个良好的工作链条，如下图所示：
|
|
|
|
|
|
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
这节课，我们学习了设计业务架构的四个环节，分别是战略设计、组织设计、业务设计和组件设计。同时，我还讲到了怎么衔接业务和技术、怎么持续推动业技融合。通过这些，我们快速地了解了业务架构该怎么玩。
|
|
|
|
|
|
不过，这不是要你死记硬背、僵化执行，搞架构最难的是灵活应对，架构可不是“一招鲜吃遍天”，架构可以参考，但不能简单抄袭，抄袭有点儿拿别人的药方子抓药给自己吃的意思，容易出问题。
|
|
|
|
|
|
到这儿呢，我已经把构建数字化转型方法论需要的思维模式、理论基础都跟你讲了一遍。我再简单带你回顾下。
|
|
|
|
|
|
数字化转型是一个企业的整体转型，是从信息时代跨越到数字时代的转型。这个转型不仅是企业自己的事情，还是整个社会的事情，全社会都要走进数字化，这会带来环境的大幅度变化。所以，你需要从一个面向长期的方法论和战略中获得指导，以免掉队。
|
|
|
|
|
|
数字化转型方法论是基于历史、生态、架构三个思维去构建的。历史思维，也就是寻找发展趋势，明确数字化目标；生态思维，也就是寻找与别人协同发展的思路；架构思维，也就是全面、结构、灵活、演进地看待数字化和自己的企业。
|
|
|
|
|
|
通过企业架构，尤其是业务架构，我们可以将数字化战略完整地落实到业务活动中，转化成有效的IT需求，实现深度的业技融合。这样跟自己的企业实际相结合的方法论都是独一无二的。数字化时代是更有个性的时代，希望你能够多多思考，可以参考别人的，但是不要照搬别人。
|
|
|
|
|
|
从下一讲开始，我就带你正式进入指南部分，带你去看看实现数字化转型的路径、能力、资源、人才等。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
今天，我讲到了业务设计中的流程梳理，也提到了标准化。但是，可能很多企业都没做过大范围的流程梳理工作，只是在开发系统或者培训业务时画画图，还有很多人觉得现在业务变化快，梳理流程好像没有太大价值。但是，在数字化转型中，流程自动化是一个很重要的方向，那么， 你是怎么看待流程梳理这个事儿的呢？
|
|
|
|
|
|
欢迎你畅所欲言，和我一起交流讨论。如果你觉得今天的内容对你有所帮助，也欢迎你分享给你的朋友或同事。
|
|
|
|