业务架构的起点：解读企业战略
业务架构最大的特点就是要从企业整体视角出发思考问题，要有居高临下的俯视视角，时刻有一张企业整体的业务能力地图印在脑子里，而企业的业务能力是服务于业务目标的，业务目标有不同的层次，高级管理者、中层管理者、操作层都有不同的目标诉求，但是所有的目标都会聚焦在最高层次的企业目标——企业战略上，所以，企业战略也就自然成为了企业级业务架构设计的起点和检验标准。
企业战略听起来是一个非常“高大上”的词汇，也有人会觉得企业战略有点儿画大饼的嫌疑。其实企业战略没有那么神秘，也不是非得智商 180 的人中龙凤才配谈起，企业无论大小，都有自己的目标、路线、方法，企业战略就是对这些内容的提升性描述。随着研究的不断深入，企业战略也有了更加丰富的内容和种类，但是说到底，企业战略仍是企业为达成某项目标而确定的过程与方法。关于企业战略的各类资料已经浩如烟海，我也无意在这里喧宾夺主、浪费时间，我还是介绍一个设计企业战略或者说分解战略目标的有效方法，毕竟从目标出发引导出业务架构设计才是我们关心的内容。
盖个房子
我介绍一个很容易掌握的企业战略设计模型，该模型应该是由 BMGovernance 公司设计的，模型如下图所示：
该模型从企业愿景、使命这种相对宏观的概念入手，向下分解出可度量的目标，这三部分做为“屋顶”，描述的是企业为自身发展所设定的目标和成功的标准，无法衡量的目标只能是个精神口号，不能被转化为行动。这不是说不能喊口号，而是这个口号必须能够被分解成可以指挥行动的具体度量，比如，愿景定义为“让全世界都使用清洁能源”，使命就是 “逐步使用风电、太阳能、水电等能源取代具有污染及潜在污染可能性的火电、核电等能源”，那目标自然就是“清洁能源使用量占世界能源使用量的百分之百”。衡量起来也容易，看统计数据就行了。
无论是世界级企业给自己定下的改变全人类的宏大誓愿，还是小企业只盼明天还能够生存的小梦想，都必须要“量化”出来，成为可执行的目标。这一点是业务架构设计人员在设计企业战略时必须特别注意的，千万不要把战略只当口号，漂亮就行，而是要能够做为一个参天大树的根，可以坚实地向上生长、开枝散叶。
愿景、使命、目标这三个经常被大家诟病为“假、大、空”的战略元素在一个可靠的业务架构设计中，被如何强调都不过分，因为它是“屋顶”，搞错了，就成了“上梁不正下梁歪”，所以务必与企业的管理者沟通清楚，务必让所有参与方都达成一致认识。这是项目中最高层级的概念一致性，绝对不能“输在起跑线上”。不少技术人员不重视企业战略，认为跟开发人员无关，这是大错特错，如果一个企业的战略会让员工觉得跟自己无关，那只能说明这个战略本身以及对战略宣导的失败。不落实到流程中的战略是无法被执行的战略，而跟战略落地无关的流程到底是在干什么呢？创造的是什么价值呢？为这样的流程开发的系统又是在干什么呢？如果一个企业花了几百万、上千万开发的业务系统，其设计人员连企业的战略都不知道，那这个系统能支持企业的发展吗？业务与技术的融合就更无从谈起了。
屋顶之下左侧是战略、右侧是战略能力。战略是为了完成上边提到得目标所需要采取的路线、方法，这类似于银行的分行每年为了完成总行下派的经营指标所制定的各种经营策略，比如大力挖潜，激活存量客户。战略能力则是为了完成这一策略需要的能力，比如为了采取激活存量客户的行动，需要的客户分析、营销组织、渠道应用、业务处理、合作伙伴管理等。
再下一层级就涉及到了具体工作，左侧表述的是为实现战略而在客户一侧采取的行动，包括渠道、客户关系、客户细分，实际上就是指面向哪一类客户、在什么渠道上、如何为其提供服务。继续上边的例子，激活存量客户要先考虑激活哪类客户，是一般客户还是高端客户，不同的细分客户需要不同的策略。现在大家都讲求精准营销，在大数据、人工智能的加持下，从“千人千面”一路飙升到“亿人亿面”。选择了客群之后就要考虑渠道类型，是通过互联网渠道、电话渠道、手机银行渠道、微信渠道还是柜面服务。确定了渠道之后，还要考虑激活行动的消息如何送达客户、如何让客户愿意接受以及相应的售后服务，这些属于客户关系范畴。
左侧最下边的是收入，也就是说上述行动成功后，应当产生预期的收入。右侧对应的三个方块则是在企业内部还需要采取的行动，关键活动是支持激活客户战略所必备的业务处理过程，包括交易流程、积分规则调整流程、积分兑换流程等。
关键资源则是为支持促销战略需要提供的资金、人员、物品、参加活动的网点等；合作伙伴则是为了补充银行能力的不足引入的外部力量，比如为了激活一般客户所提供的交易积分兑换电影票、为了奖励高交易量客户提供的体检、高尔夫球等活动，都需要与第三方合作才能办到。右侧最下边的是成本，也就是说上述行动会带来合理的成本支出。收入与成本的差额就是收益了，这就是对激活存量客户策略的最终检验。
居中的是价值定位，企业为什么类型的客户提供什么类型的服务就是企业的价值定位，方块左右两边描述的其实就是这个含义，企业的价值定位是否准确、可持续，也就是看左边的活动产生的收入是否能覆盖右侧的活动带来的成本，如果是，企业就能够长期发展，如果否，企业就需要重新思考价值定位了，而这种反思很可能带来“屋顶”的变化。
在这个模型中，大家可以看到上一讲中提到的三角形也包含其中，如果说那个三角形是“大道至简”，那这个模型就可以看作是“衍化致繁”了。
廉价沙盘
这种建模过程也是对战略的一次“廉价”沙盘推演，能够衡量战略的合理性、可行性，这种分析是非常有价值的，可以避免工作的盲目性。相信大家在日常工作中都遇到过“不计成本”、“不计代价”的“强硬”需求，那么今后大家可以试试通过这个模型对“强硬”需求做个全面的合理分析，也许能够帮助需求方发现战略缺陷，找到改进方法，使业务方案更符合各方的期望。否则，一个连沙盘推演都走不通的战略如何能指导业务发展呢？更别提去为此开发系统了。
经过之前建模大家已经能够看到隐藏其中的业务架构了，渠道管理、客户信息管理、客户细分、客户关系管理、金融产品组件、合作伙伴管理、财务核算、绩效考核等业务能力组件已经呼之欲出，你心心念念的“中台”也是若隐若现，就等更为细化的建模工作了。此外，大家也不妨思考一下，既然企业战略没那么神秘，那无论对于各种规模的客户，是不是都该鼓励大家享受一下战略的“乐趣”呢？
不可回避的问题：组织对架构设计的影响
前面提到过，业务模型描述的就是企业的组织和运作过程，可见组织在业务架构中的地位。有些了解过业务建模或者企业级架构理念的小伙伴可能会问，既然业务架构要横向看问题，那做企业级不是更应该要打破部门限制，实现企业级的统一吗？是的，但那是目标，不是过程，也未必真能是结果。下面我们就来谈谈组织结构对业务架构设计的影响。
组织要背 “锅”吗？
说到组织结构对系统设计的作用，很多人都会想起“康威定律”。Melvin Conway 于 20 世纪 60 年代后期确定的 Conway 法则告诉我们，任意一个软件都反映出制造它的团队的组织结构，这是因为人们会以反映他们组织形式的方式工作。换句话说，分散的团队可能用分散的架构生成系统。项目团队的组织结构中的优点和弱点都将不可避免地反映在他们生成的系统中。这个规律延伸到需求方身上也一样适用：需求方的组织结构不可避免地会影响到系统的组件结构。俗话说：“干活儿不由东，累死白搭工”，简直是对这个问题最直观的解释。
做业务模型，我之前说过，有两个原则要注意，其中之一是整体性，设计业务架构，我们当然希望能够整个企业通盘考虑，不要因为部门利益影响组件边界的划分，影响功能设计，做出来的东西，凡是公用的部分，应该照顾到所有利益相关方的需求；凡是已实现的功能都应该对新的需求方开放并支持必要的扩展，这是企业级设计应该追求的目标，但是，实现上常常很困难。企业无论大小，一旦系统的设计边界跨越了单个部门的职能范围时，都会出现部门利益问题，无非是企业规模、文化差异造成的协调难度的差别。
在企业内部，部门利益是部门需求的天然边界，即便要做企业级，大家肯定也是先要说清楚自己的需求，才能考虑别人的需求，种了别人家的田，荒了自家的地是绝对不行的。所以，大家在坐到企业级这个谈判桌上来的时候，都是先揣了自家账本的，首先要满足自己的业务诉求。这就要求，做为业务架构的设计者，你拿出来的方案最好是以一种更有效的方式满足所有相关方的需求，而不是单纯做抽象、归并，要大家你让一陇地，他少一棵树的方式搞折衷，这样实际上失去了做企业级的核心价值，因为这样的折衷即无法保证系统先进性的，也无法保证用户体验，甚至可能退步。部门利益是做企业级最大的障碍，跨越这个障碍是对业务架构师设计能力的最高挑战，当然，要客观，没有更好解决方案时，不动也是一种选择，因为，同样接受这个挑战的还有企业文化。
举个例子，银行都有积分系统，近年来大家也都做了综合积分，其实这里边的难度很大的，主要问题不在技术而在业务。理想的综合积分是企业只有一个积分系统，支持所有产品的不同积分规则，对不同客户群、不同营销方案可以进行参数化配置，最重要的是，支持以单一积分形式统一用于奖励兑换，而不是要换个包包，得分别去花信用卡积分、黄金交易积分、基金业务积分，这样客户会疯掉。但是都用一个积分，内部问题就上来了，信用卡部门为了促销，提高积分发放，这样信用卡用户就在兑换奖励时占了便宜，黄金交易就可能下去，黄金交易的管理部门一激动，也开始刷积分，结果会造成积分的营销费用提前被花光，反应慢的部门已经没机会促销了。说到这里，大家也就明白了，综合积分背后的博弈是营销费用，搞综合积分以前，这个费用其实是划分到各部门的，各部门自行支配，蛋糕先分好，如果综合积分设计不考虑清楚这个问题，就会动了大家的蛋糕。所以，如果能解决这个问题，综合积分就能真正做到一个组件里，解决不了，就还是各自为政，那放不放在一个组件中就没有实际意义了，只是解决积分综合查询问题的话，有很多方法都好过功能迁移。
组织问题会延伸到项目上
即便设计好了上层的业务架构方案，是不是就能顺利实现企业级了呢？也未必。企业的组织结构会影响其内部沟通效率，壁垒森严的大型企业，沟通效率通常较低。大家可能知道，组织的沟通方式主要是正式和非正式两种，其中，正式沟通在大企业中最常见的方式就是开会。如果项目少可能还好些，但是大型企业通常会有多个项目同时施工，一般都是项目群、项目组合的方式，而如果下决心搞企业级转型项目，十几个、甚至几十个项目长年同时施工也是很正常的，互联网企业相信更是如此，每天都在挑灯夜战。那么由此带来的一个问题就是项目组之间为执行企业级设计蓝图，在开发过程中可能需要对组件协同问题、边界问题频繁沟通，项目经理、业务经理、技术经理这些角色甚至会成为职业开会人，如果会议效率难以保证，一个问题久拖不决，就会产生两种结果，一是项目组担心工期延误直接改变架构方案；二是采用非正式沟通方式，项目组间通过私下交流解决问题，而后者也极有可能是以改变架构方案为代价的。
这两种结果都会令企业架构很“尴尬”，导致架构失灵。而应对这种问题并没有特别好的方法，只有加强企业级架构人员的能力与数量，让企业级架构人员以 BP（合作伙伴）的方式走入项目组，在项目组间搭建起企业级架构协作网络，提升架构决策效率，才能不让企业级架构成为瓶颈。当然，有个牛人居中，在最高层领导的支持下，强行拍定各种决策，也是一种选择，但是，企业越大，尤其是业务居于主导地位的企业中，这种结构也很难形成。
企业的组织结构在业务架构的设计与实现中具有很重要的影响，其实，理想的企业级系统建设与组织结构转型是相辅相成的，一个在组织结构上高度部门化的企业是很难建成一个真正的企业级业务系统的，这一点在做业务架构设计时务必要考虑，方案与组织结构要匹配，否则很可能在落地时困难重重、面目全非。企业级转型多数是需要时间的，休克疗法、瞬间跨越很难，这一点上，业务和技术要通过业务架构设计过程互相影响、互相协作、互相改变。阿里的“中台”建设也经历了一个“砸烟囱”的过程，其实无论你砸的多卖力气，“烟囱”总还是会有的，对于企业级设计来讲，这是大家必经的“坑”。
