从实际操作的角度讲，企业级业务架构设计及其建模过程是一个充满可能性和争议的过程，并没有一个直观的量化标准能够用于判断一个架构方案的好坏，下面通过一个虚拟的例子体会一下这种“难标准”的标准化过程。

 

假定为A商业银行设计企业级业务架构，为了集中感受组件和标准化的过程，我们跳过战略分析，不导入更多目标，比较单纯地从简化的现状入手，推导可能的目标架构。

 

 

1 价值链设计

 

假定只分析存款和贷款这两个各位读者耳熟能详、无论做没做过银行系统都能基本了解的业务，并且假定产品只面向对公客户。首先派出我们的架构设计团队，设计团队的组成人员最好是具有丰富项目设计、实施经验的人员，了解业务分析、数据分析、架构设计，由他们与业务人员（或者叫需求方）共同组成工作团队。  

 

团队搭好后，按照套路，既然做企业级，就先设计那一“横”——价值链，我们先暂定A行价值链由5个环节组成：产品设计、客户营销、运营管理、风险控制、统计分析5大环节。 

 

l  产品设计主要指金融产品上市前的设计过程，包括分析客户需求、开发系统、配置参数等；

l  客户营销则包括客户信息管理、细分客户、销售产品、签订合约等；

l  运营管理一般指需要后台集中处理的业务或者配送服务；

l  风险控制是银行业务的重点领域，通常考虑各类风控模型的设计、风险视图的构建等；

l  统计分析是指各类报表，包括业务报表、分析、监管报表等。

 

这5个环节基本可以构成金融产品从设计到销售再到售后管理的完整过程。从这五部分的定义可以看出，价值链侧重于划定业务环节并分析环节包括的业务能力。由于是虚拟案例，我们只考虑前2个环节的简化分析，不对整个价值链做展开。

 

 

2 存款领域的模型设计

 

设计了价值链之后，先从存款领域开始分析。

 

2.1 产品设计环节的分析

 

存款领域的“产品设计”环节中我们可以先定义一个活动，将这个活动起名为“设计上架产品”，其大致流程可以如图1所示。

 

 

图1  存款领域产品设计流程图

 

在这个活动中有3个角色：产品经理、IT人员、业务人员；这3个角色分别有3个任务：设计产品、实现产品、上架产品。

 

产品经理负责分析产品需求，设计并运用产品模板为业务部门整理业务需求，并提交给IT人员去开发。这个岗位在不少银行的开发团队中其实是需求分析岗，但某宇宙行确实具有此类岗位。产品经理设计好产品模板之后交给开发团队，由于实现产品的过程是个复杂的开发过程，因此，在业务模型中可以用一个虚拟的任务代表。

 

开发完成后，业务人员添加关于产品的基本信息、标签信息等，做上架前的最后配置，配置完成后就成为了一个待售产品，可以随时出售。这个活动中，我们主要关注产品需求、产品模板、待售产品这3个实体，前2个由任务“设计产品”创建，最后1个由任务“上架产品”创建。

 

2.2 客户营销环节的分析

 

营销中我们通常会遇到“获取新客户”、“维护老客户”、“存款”这3个活动，第1个活动当然是面向银行刚刚“挖门子盗洞”抢来的新客户，第2个活动则是已有的存量客户信息发生了变动，第3个活动就是营销的目的了——拉存款。这3个活动简要情况如图2所示。

 

 

图2  获取新客户、维护老客户、存款的简要流程

 

对公客户信息在银行，尤其是规模较大的银行中通常是由管户的客户经理负责录入，一般也无需审核，自己搞定。客户信息发生了变动自然要维护，比如联系信息。这两个活动都可以只包含一个任务，至于是否是分成两个活动，其实取决于建模习惯，当然，合并成一个活动就需要更改活动的定义和范围了，毕竟这两个活动中的任务都是在围绕同一个实体做文章，“录入客户信息”是创建“客户信息”实体，“维护客户信息”是变更“客户信息”实体。

 

客户信息建好以后，就进入业务办理过程。客户到会计柜台去开立对公存款账户，开户是个麻烦的过程，要审一堆证件，不过这里我们略过这些内容，仅关注“开立账户”任务对“账户信息”实体的创建。完成账户开立后，就是存入存款了，其实客户无论是存活期还是存定期，都是跟银行建立了一个“存款合约”，代表了一种债权债务关系，而合约主要记录的要素其实来自我们在上一个环节中创建的“待售产品”。因此，“存入款项”这个任务读取了“待售产品”实体，将其实例化建立了“存款合约”、“账户变动”这两个实体，由于余额的变化，该任务还变更了“账户信息”实体。

 

以上这两个价值链环节的分析虽然简单，但也包括银行业务的基本过程：设计金融产品、营销客户、销售产品。由于是企业级设计，我们先不急着分析组件结构，可以再分析下贷款领域再做决定。

 

 

3 贷款领域的模型设计

 

3.1 产品设计环节的分析

 

从产品设计的抽象流程来看，存款与贷款这两个领域在产品设计过程上并没有太大差别，是产品结构、参数项和功能上的差异。因此，从业务模型的角度，二者在设计阶段可以共用一套模型，如图3所示。

 

 

图3  贷款产品设计流程

 

这实际上表示，当把开发过程剥离出去时，负责产品设计的组件可以是企业级的，其核心是产品配置的管理。

 

3.2 客户营销环节分析

 

接下来进入“客户营销”环节，可以理解，“获取新客户”、“维护老客户”也是一样的过程，区别在于销售产品，如图4所示。

 

 

图4  获取新客户、维护老客户、贷款的简要流程

 

让客户签订贷款合约是我们的“终极目标”，但是贷款不同关于存款，客户要提供一定的保证，保证通常有抵押、质押、担保等形式，对公客户中，非常优质的客户也可以采用信用贷款的形式，不提供任何保证。本例我们假定是由其他客户为该客户提供了担保，在贷款合约之外签订了附属合约——担保合约，合约中记录了担保人信息、担保比例等。对公贷款通常是签订贷款合约之后再开立贷款账户，然后才是发放贷款。数据实体就不再一一介绍。

 

 

4 跨领域的标准化

 

如果不搞企业级，就是竖井式开发，那这样两套业务模型就可以分别使用了，各自构建一个业务系统；但是搞企业级，就需要一起分析了。

 

4.1 产品设计环节的标准化与组件分析

 

对于“产品设计”环节，我们之前已经分析了，可以放在一起，这样就可以有一个“产品管理”主题域，包含“产品需求”、“产品模板”、“待售产品”3个实体；处理这3个实体的是“设计产品”、“上架产品”这2个任务，后者可以聚合成“产品管理”组件。这样我们就根据数据关系的紧密程度将与之相连的任务设计成了组件，这个组件的定义和范围就是对这些任务和实体的概括。

 

4.2 客户营销环节的标准化与组件分析

 

按上文方法类推，“客户营销”环节中“客户信息”实体可以构成“客户”主题域，而“录入客户信息”、“维护客户信息”则可以聚合成“客户信息管理”组件，但是故事并没有这么简单，我们开始进入贷款和存款领域主要差异的分析。

 

（1）担保合约带来的差异

担保合约中的担保人信息与客户信息非常类似，维护需求也类似，而且这种维护可能会不必要地造成担保合约的变化，因此可以考虑将其从担保合约中剥离，但是直接交给客户信息实体处理在概念上又不合适，因此，可以增加一个“角色信息”实体，专门记录客户在银行中不同业务领域可能承担的不同角色。

 

但是这样原来的“客户信息”实体再叫客户信息也就不太合适了，所以我们可以在抽象程度上上升一格，将其改为“参与人信息”，这个实体应当是一个“客户”在银行有且仅有一个，并且是与具体业务无关的，其在各种业务中承担的角色由“角色信息”实体记录，这样也有利于为“客户”构建更完整的全景视图。一个比较容易理解的比喻就相当于一个初创企业的领袖——董事长兼CEO，这种情况下，人都是这一个人，但是有两个不同的身份、不同的职责，所以，把他本人定义为“参与人”，而把他担任的两个不同职务定义为“角色”，没准儿哪天他又兼任了CTO，我们都可以很方便从他本人的信息出发，看到“角色”实体记录了哪些角色，而不用把董事长、CEO、CTO的个人信息拿过来比较看是不是一个人。当然，这种抽象不是一层不变的，取决于实际需要和系统建设目标。优化后如图5所示。

 

 

图5  第一次优化后的获取新客户、维护老客户、贷款流程图

 

（2）工作流带来的差异

工作流的顺序中，存款开户在前，签约在后，贷款则相反。从实际业务中考虑，首次开户时，开户和存入款项的顺序一定是开户在前，贷款实际上也是开户在前，涉及记账的放款在后；除去首次开户外，都是利用已有账户存钱或放款，并不需要考虑开户问题，因此，不考虑合约时，两个领域间的流程也是可以整合的。

 

那么引入合约之后呢？其实这就遇到了企业级设计很常见的一类问题，涉及跨领域整合时，流程可以调整吗？这不是指建模能不能改，在图上改当然很容易，但是实际业务能不能改？愿不愿意改？有的时候读者会觉得，既然都决定做企业级了，那不是有了"尚方宝剑"了，实际工作还真未必，想想之前举的综合积分的例子，如果搞不定利益分配，企业级也不是那么容易做到。

 

回到当前的例子，我们可以设想，把存款合约部分从“存入款项”任务中分离出来，考虑建立一个签订存款合约的任务，实际执行过程中其实客户还是无感的，毕竟无论开户在前还是签订存款合约在前，客户都是提交了申请之后就在柜台前边等着，是柜员在里边操作；那么对柜员而言呢？如果是账户开立在前，那就意味着不管客户存活期还是存定期，都是先审核开户资料，再选择存款产品。如果签订存款合约在前，那就是客户先选择存款产品，建立合约信息，如果系统发现客户没开户，那就弹出开立账户界面，或者存款签约界面中直接嵌入开立账户功能，如果客户没有账户，展开这项功能；如果有账户，这部分就不展开。也就是说，其实也可以调整流程，那么存款流程就跟贷款流程很类似了，具体的流程图我们就不再画了。

 

 

5 组件设计

 

根据上述过程，我们在可以把数据实体“贷款合约”、“存款合约”、“担保合约”都放在“合约”主题域下，而与之相关的“签订存款合约”、“签订贷款合约”任务聚合成“合约管理”组件；数据实体“账户信息”、“账户变动”放在“账户”主题域下，而与之相关的“开立账户”、“存入款项”、“发放贷款”任务可以聚合成“账户管理”组件。业务架构设计如图6所示。

 

 

图6 组件划分示意图

 

这只是一种设计方式，也可以根据客户实际需要等其他因素变更设计。比如，将“存入款项”和“发放贷款”中的记账动作分离出来，增加一个“记录账务”的任务，这样“存入款项”和“发放贷款”将更加关注流程，也就是“交易”，而“记录账务”会更加关注记账，于是账户管理组件中就会变成“记录账务”“开立账户”2个任务，而在合约管理组件中填入“存入款项”和“发放贷款”，延长了合约管理的范围；进一步，如果并不关注企业级合约管理，更关注的是产品级的合约管理，则可以将合约管理组件拆分成存款和贷款2个组件，存款组件下放入“签订存款合约” “存入款项”，贷款组件下放入“签订贷款合约” “发放贷款”2个任务。

 

可见，根据关注点、设计思路的不同，架构设计也会有变化，并没有绝对的对错之分。此外，上述划分产生的组件，是不是也有“中台”的意思呢？我们可以清楚地看到一个用于今后中台沉降过程的起点。让我们再次将业务架构图按照之前的整体逻辑图重新描绘一次，体验下企业级的感觉，如图7所示。

 

 

图7 企业级业务架构的逻辑关系示意图

 

图7中可以清楚看到以下企业级业务架构设计结果：

1）企业唯一的价值链结构：产品设计、客户营销、运营管理、风险控制、统计分析；

2）依据价值链展开的2个垂直业务领域：存款、贷款；

3）在2个垂直业务领域中共用的3个业务活动：设计上架产品、获取新客户、维护老客户；

4）在2个垂直业务领域中共用的5个任务：设计产品、上架产品、录入客户信息、维护客户信息、开立账户；

5）4个基于数据主题域聚类任务后构成的面向各垂直业务领域开放自身能力的企业级业务组件：产品管理、客户管理、合约管理、账户管理，其中，产品管理在价值链环节“产品设计”下，其余位于价值链环节“客户营销”。

 

通过观察上述设计结果，读者也可以体会到业务架构设计与产品设计、需求分析的主要区别，业务架构更关注的是企业的整体设计，是典型的“不谋全局者不足以谋一隅”。

 

如果加上对战略的分析，就可以形成以战略为导向的整体企业能力规划，这种分析方法非常适合做企业转型规划，尤其是适合传统企业进行数字化演变。企业可以根据这一设计结果启动整体转型，也可以在通盘考虑的基础上进行试点建设。

 

 

6 案例总结

 

本章的例子是为了说明问题而虚拟的例子，实际业务场景比例子中复杂的多，但是通过这个简单的模拟，我们可以意识到：

1）业务架构设计并没有简单的衡量标准；

2）设计思路和关注点对架构方案有很直接的影响；

3）架构设计需要迭代和反复，虽然我们不情愿，但是实际操作中是难免的；

4）基于第3点，架构师经验很重要，可以减少反复，尤其是关键设计的反复。