|
|
# 14 | 架构规划：如何用企业架构连通技术和业务？
|
|
|
|
|
|
你好，我是付晓岩。
|
|
|
|
|
|
上节课，我们学习了几种可以用来推动企业数字化转型，并带来差异化体验的技术，这些技术值得我们长期关注。但是，数字化不是单靠这几项技术建立起来的，而是要靠很多技术综合发挥作用，这就要求企业具备综合运用各种技术的能力，要能够从整体上规划自己需要的技术体系，这样才能找准自己的发展路径。
|
|
|
|
|
|
另外，数字化也绝对不是个单纯的技术问题，技术转型是为了给业务转型开辟想象空间，也是为了有能力把业务想象给落地实现，不但要有整体规划技术的能力，还要有把业务和技术打通的能力。
|
|
|
|
|
|
所以，今天我就来介绍下用企业架构联通业务和技术的过程。
|
|
|
|
|
|
数字化转型涉及企业的方方面面，咱们不可能在一节课里把所有细节都概括到，因此，我会聚焦在非常重要的、与客户交流的数字化转型上，毕竟，这是各行各业几乎都存在的业务活动。通过这个焦点，你就能理解怎么通过企业架构落实这个转型方向，也就能够用企业架构实现自家企业的数字化转型，就不会去搞千篇一律的模仿了。
|
|
|
|
|
|
接下来，我会分成业务架构、技术架构和应用架构三个部分，给你讲一讲企业架构是如何完成这个过程的（注意，[第5讲](https://time.geekbang.org/column/article/363521)里我说过了，我的企业架构里没有单独的数据架构）。
|
|
|
|
|
|
好，先从做客户交流的业务架构设计开始吧。
|
|
|
|
|
|
## 如何通过业务架构把战略落下去？
|
|
|
|
|
|
首先，我们来回忆下我在[第6讲](https://time.geekbang.org/column/article/364888)跟你说的业务架构总体逻辑图：
|
|
|
|
|
|
|
|
|
|
|
|
我一直强调，**战略必须分解细了，落到实处**。这个实处主要就是指这张图上的活动、任务、实体。这些是实实在在地会被转化成业务处理或业务系统的东西，包括我们之前用价值链串起来的那些能力，也都要转化成实实在在的流程或数据，才算落实到位。
|
|
|
|
|
|
下面来看看客户交流这个过程如何数字化吧。
|
|
|
|
|
|
### 以客户交流为例的现状业务架构
|
|
|
|
|
|
我们都知道，与客户的直接交流很重要，不管是做产品调查、营销，还是售后服务，交流越直接，获取的信息和业务机会就可能越多。那客户交流过程怎么体现在业务架构上呢？为了做好深度融合，我们假定分析这个问题的过程，是业务人员与技术人员一起参与的。
|
|
|
|
|
|
业务架构分析一般会先从现状做起，再把希望实现的目标融合进来，找到实现目标的路径。所以，我们先从现状起步。
|
|
|
|
|
|
现在，假设一个在线客户交流过程是这样的：客户登录-发起交流-客服识别交流内容-客服收集交流信息-客服组成反馈信息-客户判断反馈信息-结束或者继续交流。根据这个过程，任务大致分为6个。
|
|
|
|
|
|
这个看似简单的过程，如果从充分提升体验、形成更好的直接交流的目标去看的话，可能一点儿都不简单。我来分步骤给你介绍下。
|
|
|
|
|
|
1. **客户登录**。交流可以在很多渠道上发起，比如聊天工具、App、邮件、电话等。通过这些渠道，客户会登录或者把请求递进来，如果是老客户，系统会读取到已经存在的客户信息；如果是新客户，就要去建立客户信息了。
|
|
|
2. **发起交流**。登录之后，客户会反馈自己的问题，这就涉及信息采集了。如果企业有产品目录，能引导客户按照产品或者类似的维度进行反馈，那定位问题的效率会高些。信息采集后会记录在问题单上，以供后续跟踪。
|
|
|
3. **客服识别交流内容**。客户做完了自己的事情，就轮到客服了。客服要先识别客户反馈的问题是什么，问题单上可能只关联了客户发来的视频、语音或者文字，要进一步分析问题内容并对应到具体的产品或者服务上。
|
|
|
4. **客服收集交流信息**。根据识别的内容，客服要开展相关信息收集，这可能涉及客户跟企业发生过的业务记录，看看知识库中是否有问题涉及的内容，尤其是预设的标准答案，也可能会涉及临时收集外部信息。
|
|
|
5. **客服组成反馈信息**。信息收集筛选完毕后，客服会组成反馈信息，提供给客户。
|
|
|
6. **客户判断反馈信息**。客户收到信息后，会判断是否符合要求，不符合就再来一轮。
|
|
|
|
|
|
需要注意的是，这里边的客服可以是人工也可以是机器，角色是一样的，都是客服。
|
|
|
|
|
|
到这里，我们就把业务过程和涉及的主要业务数据梳理完了。按照[第6讲](https://time.geekbang.org/column/article/364888)的业务架构设计方法，我相当于做完了现状的业务设计。
|
|
|
|
|
|
为了建立起完整的业务架构，我还要把数据分类到不同的业务组件上，比如：
|
|
|
|
|
|
* 把客户信息、问题单、反馈信息这些与客户相关的数据归类到客户关系管理组件；
|
|
|
* 把产品目录、业务记录这些与业务相关的数据放到业务运营组件；
|
|
|
* 把知识库信息、外部信息这些知识类的数据放到知识管理组件。
|
|
|
|
|
|
这样，企业当前的业务活动和业务组件也就都有了。不过，**业务组件中不只有数据，还得有流程，也就是任务**。所以，接下来就是以数据线索，把相关的任务分配到组件上。
|
|
|
|
|
|
客户交流过程中提到的这些任务，其实都是在做客户服务工作，产生的数据主要也是客户关系类数据。按照基于数据的组件划分原则，可以归纳到客户关系管理组件。
|
|
|
|
|
|
用到的其他业务组件的数据，严格来讲是调用其他业务组件中的任务或者是抛出一个业务事件，触发其他领域的某个业务活动来完成的。不过，这里我不建议你去纠结这个切分过程，因为那是更细节的业务架构了。毕竟，我们要聊的是数字化转型，要重点专注企业架构方法如何支持转型过程，而不是架构里的一些过于细节和繁琐的决策过程。
|
|
|
|
|
|
我画了一张图，汇总了刚刚分析的内容：
|
|
|
|
|
|
|
|
|
|
|
|
其实，这也就是用我们在第6讲介绍的方法做的业务架构设计。
|
|
|
|
|
|
接下来，咱们以这个图为基础，来看看结合数字化转型目标应该要做的设计，也就相当于设计目标业务架构。
|
|
|
|
|
|
### 面向数字化转型的目标业务架构
|
|
|
|
|
|
面向未来的数字化转型，我们应该把渠道那一层改叫“空间”，让自己有点儿立体概念。未来应该是面向3D的，而不是平面的，我们希望与客户的交流更有真实感。但是，目前技术不完全成熟，我们把它列为发展方向，也就是上节课所说的数字孪生、数字人类。
|
|
|
|
|
|
在与客户交互的过程里，我们希望把客户提供的视频、音频、文字都换成我们可以理解的信息。这当然需要采用人工智能技术，比如现在已经在用的NLP（自然语言处理）等。
|
|
|
|
|
|
但是，我们希望更进一步，最好能包括一定的情感识别，比如客户现在是什么状态？是不是已经暴怒了？还是没事儿在跟客服消磨时间呢？
|
|
|
|
|
|
这需要用到更多的行为分析能力，分析结果也会补充到客户画像中，比如这个客户是不是易怒？还是经常装怒？因为针对不同的行为有不同的反应，沟通才更真实和有效。
|
|
|
|
|
|
那我们的客服，尤其是智能客服，如何更有情感呢？除了给合成语音外，也得有适当的情感模拟。当然，我们不会对客户暴怒，但是只让客户听见个没有抑扬顿挫的机器播报，也没啥意思。
|
|
|
|
|
|
如果客户对回答不满意，再来一轮的话，谁也不愿意机器总是重复给出类似的答案。目前很多聊天机器人给人的感觉都是根本不知道客户前边说过什么，因为大部分机器人都没有很强的多轮对话能力，不像是两个人在聊天，更像是一句一句地去接收指令，所以，得发展多轮对话能力。
|
|
|
|
|
|
分析到这里，我们就可以再丰富下刚刚的图片：
|
|
|
|
|
|
|
|
|
|
|
|
在这张图里，“空间”概念加强了。总体而言，我们改进体验的努力，其实并不一定要大幅改变原有的业务过程，尤其是客户感受不到的那些过程。
|
|
|
|
|
|
那区别在哪里呢？对客户而言，体验的改进非常大，比如3D空间的视觉效果、有情感因素的可持续对话过程；对企业而言，你的智能客服也会迎来一个全面的体验升级。
|
|
|
|
|
|
当然，实现目标架构是需要时间的，这不是今年就能做、明年就能用的，这是持续升级、走向超级体验的过程。
|
|
|
|
|
|
通过这种方式，业务和技术共同想象未来，业务架构可以帮助业务侧结构化地分解战略和战略能力，通过包含战略能力的流程分析，对技术的实现能力提出挑战；技术侧也可以理解业务过程，通过业务想象知道技术要努力的方向，比如刚刚提到的行为分析模型、情感模拟、多轮对话、数字孪生等。这就有可能是技术要持续关注和发展的能力，这会驱动IT架构的升级，是帮技术找用武之地。
|
|
|
|
|
|
这样的业务架构设计过程，**既分析了业务改进目标，也形成了对技术能力改进的要求，这才是企业做数字化转型时该用的方法**。这是实现业务与技术融合的方法，而不是业务与技术各搞一套，各自发挥想象力，最后却整合不到一起，那样的数字化转型注定失败。
|
|
|
|
|
|
既然有了对技术能力的要求，咱们就接着来聊聊技术架构设计吧。
|
|
|
|
|
|
## 如何通过技术架构把新技术整合起来？
|
|
|
|
|
|
技术架构是用来做啥的呢？其实就是用来指导技术平台建设的，是企业架构中比较纯粹的技术部分。你可能听说过人工智能平台、大数据平台、区块链平台，这些都属于技术架构要规划的范畴。
|
|
|
|
|
|
但是，**架构设计不是去罗列一堆技术平台，而是要确定谁来负责干什么活儿，按照分层的原则把各平台的职责定义好**。
|
|
|
|
|
|
有些企业会觉得自己的平台很混乱，其实就是因为没做好架构分工，平台职责互相重叠，甚至搞出重复的平台来。所以，要想让技术管理更成体系，就得做好架构管理。科技企业普遍比较重视架构管理，你经常听说的架构大牛主要指的也是负责架构管理的技术架构师。
|
|
|
|
|
|
除了刚刚提到的客户交流过程需要的技术能力，我在前面的课程里提到的很多能力也都需要技术平台的支撑。
|
|
|
|
|
|
把技术能力归类到技术平台上，多数是从实现角度去看的，比如：
|
|
|
|
|
|
* NLP、多轮对话、情感模拟，属于人工智能技术，一般都会放在人工智能平台上进行实现；
|
|
|
* 也有按照编程语言类型进行设计的平台，比如C语言、Java语言平台等。
|
|
|
|
|
|
所以，现在，我结合我介绍过的数字化转型方向，给出个总体技术架构。我建议你参考下这个架构图，然后再结合自家企业的特点和战略，来设计更合适的技术架构。
|
|
|
|
|
|
|
|
|
|
|
|
为了帮助你理解怎么选择新技术，我来解释下这张图里的内容。
|
|
|
|
|
|
从上往下来看，第一层空间体验层是我们未来要着力打造的，人工智能技术当然少不了。但是，做体验的和做业务分析的，还是可以分开的，毕竟关注的职责不一样。所以，空间体验层和业务处理层分别有不同的人工智能平台。
|
|
|
|
|
|
**人工智能是形成差异的技术，而非搞通用功能的技术，所以，我建议自主搞**。自主不是从头自建的意思，你可以买平台、用开源，但是无论平台是怎么来的，你都得能够自己搞二次开发、维护，而不是总依赖服务商。数字孪生也一样，对于体验类的东西，你一定要具备自主能力。
|
|
|
|
|
|
再来说说第二层，业务处理层。
|
|
|
|
|
|
在这一层，人工智能将来是处处离不开、用得越多越好的。不过从分布上看，未来很可能是中央集中处理与边缘分布式处理结合的架构，中央集中处理部分的技术要求高，也具有一定的通用性，自主与外部依赖结合的方式更好些；在边缘部分，处理的功能一般不会特别复杂，但跟客户距离比较近，也可能关系到体验问题，自主可能会更好些。
|
|
|
|
|
|
**数字身份**必然会有部分外部依赖，因为要注入国家的权威认证。企业的各类业务处理平台应该融合RPA（流程自动化机器人）理念去做，也就是做可配置的全流程自动化业务平台。
|
|
|
|
|
|
**智能合约**是基于区块链或者可信连接方式提供的自助式服务方式，如果自主设计的话，会更容易把自家业务的特色融进去。
|
|
|
|
|
|
除此之外，在RPA的高级阶段，也就是充分融合了人工智能的IPA（智能流程机器人）阶段，智能合约概念到底还需不需要，可以再讨论。
|
|
|
|
|
|
第三层是资源管理与连接层。
|
|
|
|
|
|
**混合云应该是未来的趋势**，毕竟，很多企业都会有一些更愿意在本地保管的商密类信息，而其他的信息和服务都可以用行业云。因此，混合云管理是常见的资源管理模式。
|
|
|
|
|
|
物联网管理平台未来会很重要，因为物联网设备越来越多，可穿戴设备也是未来主要的空间入口。
|
|
|
|
|
|
区块链平台或者可信连接平台未来是生态连接的重要方式，这方面可能是区块链，也可能是某种更适合承担可信连接任务的技术。
|
|
|
|
|
|
关于这一层的技术，**我建议你都采用自主加外部依赖的方式。因为偏底层的能力，企业与外部合作伙伴共建更经济**。
|
|
|
|
|
|
最后一层是基础设施层。
|
|
|
|
|
|
在这一层中，虚拟空间需要庞大的算力，企业自己未必搞得定。而且，量子计算机一时半会儿也不是企业负担得起的，算力的获取很可能是内外部混搭的。
|
|
|
|
|
|
高速传输未来也不只是5G，现在也有提6G的，这种网络建设必然是依赖外部的，因为它属于国家的基础设施。数据平台也可以是内外部混搭，毕竟，数据越来越多，都自己存，将来可能谁也存不起。
|
|
|
|
|
|
**总体来讲，越是上层的体验类技术，我越是建议你加强自主能力；越是底层的基础技术，越是建议你平衡内外部混搭**。
|
|
|
|
|
|
这个技术架构覆盖了能力分解和价值链中提到的线上化、平台化、新技术应用、自研、直接交流、运营、持续改进、流程再造等需要应用的技术能力，属于比较完整的目标技术架构了。
|
|
|
|
|
|
有了业务的目标架构，也有了技术的目标架构，还缺什么？缺的是功能分布，也就是用来实现业务流程、操作业务数据的功能都分布在哪些技术平台上，这就是应用架构做的事情。
|
|
|
|
|
|
接下来，我给你介绍一下目标应用架构的设计。
|
|
|
|
|
|
## 通过应用架构把业务架构和技术架构连起来
|
|
|
|
|
|
简单地说，**应用架构就是把业务架构的设计成果转化成系统的服务或者功能设计，再根据技术架构确定功能的分布**。这就相当于把业务需求转化成了技术需求，最后由技术架构通过技术平台去实现了。
|
|
|
|
|
|
继续以客户交流过程为例，这样咱们才能完整地把企业架构设计过程串起来，让你更好地掌握这个设计方法。
|
|
|
|
|
|
咱们按照业务活动的顺序分析下应用架构该怎么设计吧。
|
|
|
|
|
|
1. 搭建虚拟空间场景。这个任务由数字孪生平台负责。
|
|
|
2. 客户接触。进入到场景中，交互体验是空间体验层的人工智能平台负责建立的，比如数字客服出来跟客户打招呼。
|
|
|
3. 业务引导。比如在这个例子中，客户有问题要问，人工智能平台就可以根据客户的需要，调用客户服务平台进行处理。
|
|
|
4. 身份认证。如果客户服务平台需要认证身份再提供服务，就由客户服务平台调用数字身份平台，去进行客户的身份认证。
|
|
|
5. 提供服务。根据客户提出的问题，客户服务平台开始找答案，这可能会用到业务层中央人工智能平台。找到答案后，反馈给空间体验层的人工智能体验平台。
|
|
|
6. 反馈信息。空间体验层的人工智能体验平台把答案包装成对话之后，由数字客服反馈给客户。
|
|
|
|
|
|
这里需要注意的是，应用架构的服务串接与技术架构的设计是相对应的。如果在技术架构上，人工智能是分散部署，允许业务平台自建，比如，客服平台允许自建一部分人工智能，那应用架构就会是另一种模式了。
|
|
|
|
|
|
同样，我还是用一张图来汇总下中咱们刚刚分析的内容：
|
|
|
|
|
|
|
|
|
|
|
|
到这里，企业架构基本完整了。现在，你应该就能理解企业架构如何把战略和战略能力，也就是价值链里边的东西，拆解到业务和技术的实现上了。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
今天，我们学习了怎么通过企业架构设计，把价值链分析中分解出来的能力落实到位。
|
|
|
|
|
|
我特意挑选了一个在各行业中覆盖度最高的业务活动“客户交流”，以提升交流体验为目标，手把手带你设计业务架构，通过业务架构分析推导出对技术的能力要求，再把技术能力归纳到技术架构上。在技术架构部分，我把之前提到的其他能力也都放进来了，这样就比较完整了。业务架构不是直接对应技术架构的，需要应用架构做个连接，把业务需求转换成技术需求之后，再交给技术架构去实现。
|
|
|
|
|
|
最后，我还想再强调一下，架构思维在数字化转型中非常重要，我们构建方法论时会用到它，具体做设计还会依赖它，它连接了方法论和具体设计两部分，所以应该被我们重视。
|
|
|
|
|
|
我建议你也花些时间多研究下企业架构，你的思维很有可能会因此变得不太一样，会更全面地认识企业，会在更完整的视角下思考数字化转型，而不被各种概念带着跑。
|
|
|
|
|
|
实际上，从[第8讲](https://time.geekbang.org/column/article/366322)到这节课，我完整地介绍了用企业架构实现数字化转型的过程。我用一张图把这个过程串起来，你可以对照着这张图，结合自己企业的情况，从设计战略开始，再通过价值链进行能力分解，再通过企业架构设计具体的实现方式，从而形成一个可以落地的数字化转型方案。
|
|
|
|
|
|
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
你觉得，你所在的企业需不需要建立一套自己的企业架构，用来设计自家的数字化转型方案呢？
|
|
|
|
|
|
欢迎你畅所欲言，和我一起交流讨论。如果你觉得今天的内容对你有所帮助，也欢迎你把今天的内容分享给你的朋友或同事。
|
|
|
|