前面的文章中我们分析了企业战略、理清了组织结构，是不是就该进入业务分析了呢？先别急，业务分析，特别是对于具有多个不同业务线的企业而言，是一种垂直式的分析，如果直接开始业务分析，那就走上了竖井式开发的老路，就算有共同的战略目标，也未必建得出企业级的业务架构和业务系统来。业务架构强调的是横向视角，强调通观整个企业的生产过程，因此，展开垂直的业务分析之前，我们必须先确立一个统一的业务分析框架做为观察各个业务线的统一方法，这样才能将企业需要的业务能力进行分类汇集，产生合理的组件结构。

价值链分析

我们首先讲一下这个用来做横向分析的方法，通常管理学上分析企业竞争力多是使用价值链模型。价值链(value chain)概念首先由迈克尔·波特(Michael E.Porter)于1985年提出。最初，波特所指的价值链主要是指针对垂直一体化公司的，强调单个企业的竞争优势。随着国际外包业务的开展，波特于1998年进一步提出了价值体系(value system)的概念，将研究视角扩展到不同的公司之间，这与后来出现的全球价值链(global value chain)概念有一定的共通之处。之后，寇伽特(Kogut)也提出了价值链的概念，他的观点比波特的观点更能反映价值链的垂直分离和全球空间再配置之间的关系。2001年，格里芬在分析全球范围内国际分工与产业联系问题时，提出了全球价值链概念。全球价值链概念提供了一种基于网络、用来分析国际性生产的地理和组织特征的分析方法，揭示了全球产业的动态性特征。具体采用哪一种价值链模型，要看企业的实际需要，比如，是否更关注上下游关系等。这种模型的建立往往不是企业自身能简单搞定的，可能需要一定的咨询或者学习过程。波特价值链如下图所示：

价值链主要包括基本活动和支持性活动，基本活动是主要生产过程，支持性活动则是对基本活动起辅助作用及维持企业基本运转的各类活动。实际使用中不必完全一模一样的照搬，因为波特价值链一看就知道偏重制造业，偏重生产类型的企业，对于服务业而言就需要适当变形，其实，价值链主要描述的是企业的价值创造过程，引入价值链分析主要是为企业横向审视自身业务能力提供分析框架，因此，价值链如何设计，完全是可以个性化的，只要确认好能够符合企业特点，覆盖其价值创造过程即可。

业务领域设计

做好这一“横”之后，我们就可以画出多个“竖”了。科学地讲，业务领域的划分取决于企业的战略和价值定位，企就是业打算为什么类型的客户提供什么类型的服务或产品，比如，银行为个人客户提供金融服务，就产生了个人金融业务线，这里边存款、贷款、金融市场、非金融服务等等，会有一大堆东西，而如果觉得这样划分依然太粗，那么很有可能私人银行这类高端客户服务就会独立出来，为其设计的一些业务功能聚类成的业务组件可能不会为普通客户提供服务。划分领域其实可以有两种方式，从客户出发和从产品出发，选择哪一种，要看企业的特点以及企业更关注什么。还以银行业为例，银行业有不少产品是同时适用于个人和企业客户的，因此，从客户出发，很多产品会交叉；而从产品出发，会避免这一问题，毕竟业务系统的设计多数还是以产品为主线的，但要注意，这里指的不是具体的某一个产品，而是一组同类产品的集合，比如存款、贷款、托管、资管、投行等。选好维度之后，就有了横轴——价值链和纵轴——业务领域两个维度，接下来就可以去分析业务流程了。

业务流程分析

业务流程的分析实际上就是将一个业务领域中的所有业务处理过程按照价值链约定的分解方式分解，形成每一个价值链环节中的一个或者多个工作流，具体每一个工作流程的设计可以采用常见的VISIO设计工具，可以遵循BPMN语法标准，也可以采用其他制作工作流的语法标准，但是要注意，必须整个企业统一采用一种，不然是没法整合的。以BPMN语法为例，一个工作流在BPMN语法中称为一个活动，每个活动可能会有多个不同的角色共同参与，具体涉及到哪些角色就又涉及到企业的组织结构了。每个角色在活动中承担的职责称为任务，其实工作流分析重点在任务，活动的范围并不那么严格，甚至不是非常重要，活动之间在BPMN语法中是可以靠事件串接起来的，既然能够串接，那么范围或者说流程图的长度就不是特别重要。我们甚至可以把一个业务领域中不同价值链环节下的所有活动都连接成一个特别复杂的活动，只不过这样可读性会非常差。所以，操作上，还是建议活动尽可能在每个价值链的范围内，而每个价值链内有多少个活动，可以自由些，可以多参照对业务场景的划分。业务流程的分析重点在任务，因为任务在后续设计中对功能、组件内部结构的影响比较大，这个后边章节还会陆续介绍。一个常见的BPMN工作流如下：

综上，业务领域其实是企业确定以某类产品服务某类客户的一个业务范围，在建模上，它表现为，为实现这一价值定位，企业在整个价值链上的各种业务活动的有机结合，一个业务领域实际上就是由一组业务活动构成的，通过活动中的角色和任务，体现了所有参与到价值创造过程中的组织单元的分工协作关系。

要注意的是，这一阶段完成的模型通常是不够准确的，因为还没有经过“精炼”的过程，其对企业级设计的贡献还只是个开始。业务领域及流程的分析中，还有一点要强调的是，别在忙于细节时忘了大方向，业务架构设计是从企业战略开始的，那么做到业务领域分析时，要时刻提醒自己，业务领域内的活动是否能够有力地支持战略的实现，是否能够有效地服务客户，是否能够有效地应对行业竞争，也就是先进性的衡量，把这三个问题如同曾子三问一样看待，“日叁省乎己，则知明而行无过矣”。

上一章概述了业务流程建模的过程，流程建模其实“一言难尽”，需要不断的练习、摸索，自己总结套路，也就是之前说过的，模型质量严重依赖建模者的经验。软件设计主要研究的是行为和数据，流程模型分析了行为，数据模型当然就是要分析数据。数据模型在很多系统分析、软件工程的教材上都有介绍，所以我不去赘述三范式之类的数据建模规则，而是从企业级数据模型、业务模型与数据模型协作关系的角度，讲讲数据模型。

企业级数据模型

提起数据模型大家可能第一反应都是ER图，实体关系图是我们做关系型数据库设计的基础。实体图是按照对业务对象的划分，将数据属性按照实体聚类，并描述实体间的关系，从而指导程序设计和数据库设计。我们通常做ER图是面向单个系统构建的，而要构建企业级数据模型时，就需要横向分析所有业务领域的ER图，所以，我们也需要以一种总体结构先建立分析框架，比如金融类企业常用的FSDM(financial services data model)，它是IBM的一个企业级数据模型，囊括了银行约80%的业务数据。FSDM将数据分为九大类，分别是参与人、合约、条件、产品、分类、时间、资源向、位置、业务方向，具体定义如下：

分类名称	简称	定义
关系人	IP	银行的业务开展过程中的相关各方，个人、机构、柜员。。
合约	AR	参与者之间达成的合约、合同、协议等
条件	CD	描述银行的业务正常开展，所需要的前提条件、资格标准和要求
产品	PD	产品是为客户所提供，以换取利润的产品和服务，产品也包括合作伙伴或竞争对手的产品和服务，是金融机构销售或提供的可市场化的产品、组合产品和服务。
地点	LO	参与人相关的所有地址，如家庭地址、公司地址、邮政信箱、电话号码、电子地址、网址等或地理位置区域。
分类	CL	适用于其它数据概念的分类或者分组。
业务方向	BD	银行或参与人开展业务所在的环境和方式
事件	EV	是参与人和银行的交互，以及银行内部的业务交互，它包含最详细的行为和交易数据，例如存款、提款、付款、信用/借记卡年费、利息和费用、投诉、查询、网上交易等。
资源项目	RI	是银行有形或无形的有价值资源项目，是银行拥有，管理，使用的，或支持特定业务目的的．

通过这个框架可以将数据实体、数据属性进行归类，形成统一的企业级逻辑模型。做为企业级模型，数据实体和属性都要保证唯一，这一点在建模中好说，通过工具筛查就可以比较出名称、定义、取值重复的数据项，从而保证数据唯一性。但是重点在于生产阶段的管控，而非建模阶段。生产阶段要通过数据管控平台或工具对数据字典进行严格管理，没有进数据字典的数据项，无法生成企业唯一的数据项ID，无法在设计时被使用，从而达到严防死守一般的控制，虽然也让生产上一顿抱怨，但这个方法很有效。企业级数据模型说起来容易，做起来难，要首先对业务数据进行全面建模，再对生产进行严格管理，并对历史数据进行处理。本人原所在单位经历了两年多的努力，成为行业内首家真正建成企业级数据模型、真正实现企业级数据管控的大型金融机构。

与流程模型的配合

流程模型与数据模型是描述业务需求的一对儿“难兄难弟”，流程模型表达的是“处理”，数据模型表达的是“输入”和“输出”，合起来就是计算机的基本工作流。数据模型和流程模型的组合，可以清楚的描述出，什么样的事件或条件可以触发一组业务活动，业务活动需要的输入有哪些，经过业务流程的处理，输出又有哪些。如果将该业务系统化，就成为实现业务活动的计算机程序是在什么样的场景（事件）下开始执行，程序需要读取哪些数据（实体），依据什么样的顺序（活动）、规则（任务）由谁（组织、角色）执行，执行之后产生哪些数据（实体）。任务会直接处理数据，而这种处理通常分为增加、修改、删除、查询四类。

一个业务领域是由一组活动构成的，而这些活动分布在价值链的不同环节，如果粗糙地划分业务组件，则将每一个价值链环节设为一个业务组件也未尝不可，不过这样未免太“偷懒”，对于业务复杂的大型企业而言，组件的内聚性会很差，所以我们需要更为精细的划分。数据模型都有主题域这个层级，就是将关系较近的数据实体聚合成一个分类，这种关系我们可以给出一个主题名称，比如，当按照产品划分主题时，FSDM中产品分类下就可以建立一个“存款”主题域，将存款业务相关的数据实体放入其中，并使用ER图的方式表达。

在软件设计上，是可以考虑将关系较近的数据实体聚在一起，按照行为接近数据的原则，再将相应的功能聚合成一个组件。结合业务模型，就可以将与主题域中与实体相关的任务聚在一起构成业务组件。聚类过程中要注意：

数据主题域中的数据实体可能存在引用其他主题域数据实体的情况，这种情况下，在进行任务聚类时不会考虑此类数据实体，因为它们应当由其所在的数据主题域相关的组件创建，以保证在企业级业务系统中，数据生成职责的唯一性，这是应用企业级数据模型时非常重要的一点。
与数据实体相关的任务主要指对数据实体进行新增、修改、删除的任务，对同一数据实体进行新增、修改、删除操作的任务应当归属同一组件。只有这些任务具有数据的写权限，其他任务只具有读权限，这也是保证企业级数据一致性的重要措施。

上述原则会在一定程度上影响任务边界的划分，是否需要因为在任务中要表达对不同主题域数据实体的写操作，就需要将任务切分开，或者直接复用其他组件中已有的对该数据实体进行写操作的任务？表达上，当然切分开或复用任务最好，甚至可能复用活动，但是实际建模过程中则要具体问题具体分析了，这一方面是建模的问题，但另一方面其实也是应用模型过程中很重要的一个环节——解读模型的问题，如果两者比较统一，那模型具体长成什么样子就不必太纠结了。所以，该如何处理，同时取决于这两方面的情况，考验的是“统一语言”是否真的建立了。

熟悉DDD的朋友可能会问，任务与实体的关联主要基于对实体的增删改，这不是有点儿“贫血模型”的意味吗？其实不然，流程对数据的更丰富的处理规则其实可以包含在任务的描述中，从而摆脱“贫血模型”的问题。

企业级数据模型与企业级流程模型相互支持，而其中最重要的概念都是企业级，企业级在操作层面上，说到底是个标准化问题，我们将在下一讲阐述这个问题。

相关文章：
中台之上（一）：重视业务架构，不要让“业务的归业务、技术的归技术”
中台之上（二）：为什么业务架构存在 20 多年，技术人员还觉得它有点虚？
中台之上（三）：战略和组织结构，业务架构设计中不应被忽视的关键因素

作者介绍：付晓岩，原国有大行资深业务架构师，负责业务架构设计、项目管理，热衷新技术探索与实践，具有丰富的银行业务经验和企业级项目业务架构设计经验，曾主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计。公众号：晓谈岩说。

创作场景

中台之上（四）：面对复杂的流程和数据，我们总结出了一个分析套路