汽车金融发展新模式（调整好你的业务架构）
汽车金融发展新模式（调整好你的业务架构）曾经有个客户问我：我希望尝试新的东西，做出一些改变，但是我有时候不知道为什么要做这种改变，或者改变能带给我什么。业务架构从来都不是独立存在的。既然谈到了业务架构，先看看什么是业务架构。业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容。业务架构在不同角色视角中的定义不尽相同，包含的内容也比较广泛。而本文中所指的业务架构，更多的是指如何将战略拆解到系统实践中，而这里的实践并不是说采用什么技术栈，什么架构模型，这里是从战略，拆解到业务，再细分到业务模块和业务服务。到了这种颗粒度之后，技术如何支持将会变得相对明朗可见了。
编辑导语：业务的变更，会影响到我们的业务架构。那么，在面对业务大的调整的时候，我们的架构该怎么调整？本文作者从业务视角，分析应该如何应付业务模式变更，希望能给你带来帮助。
我们在遇到业务变化的时候，一定想过一个问题：系统能不能少改，或者不改，来满足业务需求。或者在面对业务大的调整的时候，我们都会问：这个影响架构么？架构要怎么调整？
如果业务调整如“汽车金融两种数字化业务模式创新”文中所说：我们业务模式需要变更，有更多的合作方提供价值支持；有更多种类的细分客户，需要我们从不同渠道服务，我们怎么来应对？
既然是业务的变更，首先受到影响的一定是我们的业务架构，本文中，我们先抛开技术架构，单聊业务架构，一起从业务视角，来看看，我们能做些什么。
一、什么是业务架构既然谈到了业务架构，先看看什么是业务架构。
业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容。
业务架构在不同角色视角中的定义不尽相同，包含的内容也比较广泛。而本文中所指的业务架构，更多的是指如何将战略拆解到系统实践中，而这里的实践并不是说采用什么技术栈，什么架构模型，这里是从战略，拆解到业务，再细分到业务模块和业务服务。到了这种颗粒度之后，技术如何支持将会变得相对明朗可见了。
二、汽车金融面临的挑战业务架构从来都不是独立存在的。
曾经有个客户问我：我希望尝试新的东西，做出一些改变，但是我有时候不知道为什么要做这种改变，或者改变能带给我什么。
这样的问题，其实很常见，现有的传统企业中，业务和技术往往是分开的。业务会定义大的方向和战略，技术也会有自己的技术目标，但两者怎么结合？业务的战略目标如何实现？技术的目标如何体现业务价值。搭在中间的，是一个拆解和匹配，而业务架构就架在了这两者之间。
我们再来看看汽车金融面临的问题，现如今，传统汽车金融需要考虑：如何支持直销业务流，如何支持多前端触点的趋势，如何应对多业务场景流程并行，如何快速调整我们的系统支持业务的多变？而问题存在于当下，同时也涉及到未来。
1. 业务模式的变化与细分
业务模式从传统的经销商模式，逐步向直销倾斜的时候，我们的业务和系统需要做双向支持，一方面，经销商属于专业人员，提供专业精准支持；另一方面，直销面对的普通客户，不具备专业知识，需要提供便捷易懂的服务。
而随着业务的成熟，业务划分也越来越精细，包括新车，二手车，展车，公司车，网约车。也包括乘用车、轻卡、重卡等。
显然，我们无法针对每一个细分做一套流程系统。当然，也不会为了应对新的模式新打造一套系统。
2. 触点的多样性
从经销商来讲，越来越灵活的服务方式已经不再局限在桌面办公，从网页端会慢慢地过渡到手机端，但这并不代表着网页端会废弃不用，我们就面临着多端支持。
同时支持直销的C端，支持客户自己完成，为了提供便利，我们根据业务的诉求和客户的场景细分，也许会支持客户的APP、小程序、公众号、网页端等方式。
当然，每增加一个渠道以及触点前端，都不会用单独的系统和流程支持。
三、以不变应万变的业务架构面对上文中提及的变化诱因和可能性，或者现在为了快速迎接不远的未来挑战，在我们构建，或者改善系统的时候，要如何应对。正如我们的共识，不会为每一个新增做全新构建，因此就要求我们的系统有足够的灵活性。
说到了灵活性，我们就需要提一提很火的名词：服务化。所谓的服务化是指把一个大型系统中的各个业务进行抽象以后，以服务为单位进行开发和管理的方法。因此，我们看到重点在抽象，和以服务为单位上。
1. 业务抽象
正如我们所说，汽车金融的业务场景有多种细分，而我们又无法针对每一个内容进行流程独立开发，因此就需要针对这些内容进行业务抽象。这就要求我们能够将所有的业务内容进行梳理，在这个过程中，我们不去想怎么合并，不去想怎么构建，只做一件事情——梳理。这个过程是一个寻找问题的过程，只有问题清晰了，解决方法才有的放矢。
而梳理的过程需要我们将所有的业务以及对应的上下游理清楚，从购买流程，到边缘场景，事无巨细的流程都展现出来。
在这之后，将每一个流程中涉及到的问题归纳到一起，成为我们的“抽象”，例如下图中的内容，抽象出来的结果看上去所有的业务流都或多或少的会涉及其中的几个或者所有“抽象”。
2. 业务架构
架构的关系其实就是在表达一种关系，从左到右（上下游关系）或者从上到下（架构层级关系），按照我们通常的理解，上下关系中，越往下越抽象越基础。
借用软件架构中的三层架构，三层架构的特点：高内聚低耦合，也恰恰符合了我们对于业务架构的期待，因此我们复用到业务架构中来。
对比三层架构：
- 表现层，相当于触点渠道，真正的触达用户
- 业务逻辑层，服务于特有的业务场景，和功能，相当于特有模块，只有特定场景和内容才会使用的内容
- 数据访问层，相当于共有能力，每一个业务逻辑都离不开数据支持，等同于业务中的共享模块，而共享模块并没有数据那么底层，还是在说业务逻辑，只不过这个业务逻辑会更通用
将我们识别出来的“抽象”对应到这三层是什么样的呢？举个例子来讲：
- 前台触点：我们可以有H5页面，小程序，网页，APP等等方式接触客户，同时也有需要我们提供服务的合作方。可以是自服务的方式，也可以是经销商渠道的方式。
- 特有模块：我们看到申请和激活过程属于贷前特有，而合同和日常服务属于贷后特有。当然，我们可以有别的划分方式，比如说根据上面说的车辆划分新车二手车，轻卡重卡等等。特有模块的划分方式不同，模块能力的组别划分也会随之改变。
- 共享模块：抽离我们的实际业务细分和车辆细分，公用的部分，比如说客户和线索，比如说文档报报表等，都属于可以剥离特有业务场景独立使用的能力。
这样的业务架构，可以更好地支持我们的现有业务，能做到资源的最大化利用而避免了重复建设。对于未来，也同样，可以很好地支持。
3. 灵活应变
对于未来业务模式的改变以及客户需求的改变，我们的业务架构也能够做到支持，当然灵活的调整是必然的。当我们新增了业务场景或者特有模块场景的时候，有些特有模块就会同时被新增场景使用，逐渐就会变成共有模块。当然，当我们做了业务调整，减少了特定场景之后，共有模块也有可能调整到特有模块中去。
同样，前台触点也会随着我们的业务调整进行适当的改变，每一个前台触点，会影响业务流和业务场景，因此也会间接的影响我们的模块分类。
当我们的“抽象”具备了高内聚低耦合的特征之后，调整就是基于“抽象”之间的，对于“抽象”本身，我们就可以在短时间内不做过多的关注了。而这个“抽象”就是我们识别出的能力，就是我们说的模块
写在最后，当我们的模块足够的独立的时候，每一个模块专注于自己的能力，不受前台触点的操作影响，单纯的新增触点或者业务流顺序调整，模块将不会受到影响。当然，没有任何一个结构能一直适用于各种潮流，我们能做的只能是尽量灵活适配，或者小步调整，支持未来的无限可能。
#专栏作家#
兔小吱，公众号：冬眠小记，人人都是产品经理专栏作家。探索数字化转型。
本文原创发布于人人都是产品经理。未经许禁止载。
题图来自Unsplash，基于CC0协议。
