面向能力的企业架构规划

京鲁老宋 2023-03-27 发布于北京

展开全文

—

TOGAF中关键技术中，有一项叫“基于能力的规划”，其框架模型如下图所示，看后深感感共鸣：一是基于能力的规划是面向结果的，用户地图也是一种面向结果的产品设计模式，不同的是用户地图是面向用户/客户价值体现，而基于能力的规划是面向企业内部的价值创造，但对结果的强调是一致的。产品成败与否不是做了多少功能、上了多少个系统，而是完成了多少客户场景、满足了多少客户诉求，不被需要的功能是没有任何价值的。二是能力增量是需要过渡架构来承接的。规划总有现状调研阶段，但很多规划项目对调研情况只是汇总陈述，并不是总有架构性描述。想要夯实目标和实施路线，前提是对目标和现状都基于架构语言的描述，并通过差距分析形成工作任务，落实到项目计划中。

TOGAF把“业务能力”作为非常重要的一个架构模型，不仅在最新的TOGAF 10规范中有一个专题在讲述业务能力，还单独出了两个白皮书《基于能力的规划-战略与EA的联系》和《基于能力的规划使用TOGAF® 和ArchiMate® 标准支持项目/谱系和数字能力映射》，把业务能力从概念定义到和ADM各阶段之间的关系，以及和其他业务模型之间的关系说清楚，也通过一个企业架构的场景吧业务能力如何落地进行了串讲，同时用TOGAF的描述语言ArchiMate进行了全过程的描述。这两个白皮书都翻译了中文版，下载链接如下：

https://publications./g193 Capability-Based Planning Supporting Project/Portfolio and Digital Capabilities Mapping Using the TOGAF® and ArchiMate® Standards

https://publications./g193c Capability-Based Planning Supporting Project/Portfolio and Digital Capabilities Mapping Using the TOGAF® and ArchiMate® Standards (Chinese Translation)

借着热乎劲，把业务能力的前前后后做个简单的梳理。

—

业务能力的定义

企业架构中所说的能力，上下文一般指业务能力。Open Group引用Ulrich Homann的定义：“业务能力是企业为实现特定目的或结果而可能拥有或交换的特定能力。”所以业务能力虽然面向结果，但是不是目标或者目的，也不是结果本身，它对结果或目的的实现提供支撑。直白的说，业务能力是企业能干什么。比如“客户差异化定价”就是一个业务能力，不具备这个业务能力，企业只能对所有的客户执行统一定价，当出现一个优质客户而想要粘客、获客时，却发现企业的流程、机制甚至系统都做不到，就说明企业不具备这个业务能力。

在TOGAF架构元模型中，业务能力处在核心位置，它和组织架构图、价值流图、业务对象（业务信息）图构成了业务架构的关键内容。

业务能力的提出是为了承接从企业战略到可落地的业务流程和应用系统的过渡环节，相对于虚业务战略它是“实”的，它具体细化出企业需要具备什么“业务能力”才能实现这些战略，从战略到业务能力可以是推导或者分解、衍生关系；相对于业务流程、业务功能等实在的存在，它又是“虚”的，它不具体是某个流程、功能或者模块，而是贯穿于这些实在的业务概念中的“暗线”，它提供了业务模块和功能之外的视角，而又需要业务流程和功能的支撑来实现业务能力。比如我们说“精准营销的能力”，它可能体现在客户的售前流程，也可能是售后的产品推荐环节，也可能是客户主动接触前的定制化营销推荐……如此种种的流程、功能和场景支撑了业务能力。相对于业务流程和功能，业务能力是持久和稳定的；而流程和场景总需要根据业务调整被不断的调整优化来体现业务能力。

TOGAF给出的一些业务能力的好处：

提供关于业务的共同词汇或语言，同时与特定的组织单位、业务流程或技术无关
通过业务领域、业务组件与能力相关来理解业务关系
通过映射到相同的业务能力来集中投资和成本节约
通过映射到共同的能力视图来相互联系项目
在提出可能不正确或不完整的解决方案之前，确保利益相关者就交付给企业的能力达成一致
确定哪些功能为价值流的各个阶段提供了提供价值的手段

—

业务能力是有层次的

业务能力分层有两个含义，一是根据波特价值链理论，togaf把业务能力分为了战略层、核心层和支撑层；如果你要问，这个和波特价值链也不一样啊？波特价值链没有战略。不一样就对了，理论嘛，就是用来拿来做论据的，能为我所用就用，不能为我所用，那就改造它然后再用。如果你懂得了这一点，就可以跟我一起唱，onlyyou……

第二层分层的含义，是自上而下的业务能力分解。业务能力可以有不同的抽象颗粒度，在架构规划的不同阶段，能够细化的层次也不同；比如在愿景阶段，可能只能提出最上层的能力，可以参考上图；到了业务架构规划阶段，随着目标的澄清、战略的明确、业务现状及未来的输入增加，可以逐步将业务能力细化；如下图，是业务能力细化的一个例子。业务能力的分层，也是为了向不同的干系人展示能力的不同视图，比如对于高管，只需要关注上两层业务能力；对于条线负责人、业务架构师则需要关注三层能力等。

对于能力要细化到几层，是个哲学问题。参考某大行的能力分层，目标能力-战略能力-业务能力-能力需求。其中战略能力类似上图的一级能力，业务能力是二级、能力需求是三级。那么目标能力是啥？其实更多的相当于业务发展关键目标，是从战略能力向上聚合归纳而成的。

具体实施过程中，TOGAF的第一层更像是一个能力分类，而不是具体能力；我们更关注能力的第二层，也就是大行方法论中的第三层业务能力，这些业务能力可以通过业务战略解读、现状调研、先进实践、技术研究等方法进行归纳总结，形成面向未来发展需要的业务能力（记住，能力是面向结果的）。然后可以再对这些能力进行细化，形成可以在具体的业务流程和业务模板、功能中落地的能力需求。需要注意的事，一旦涉及到多层的问题，就需要考虑同一层次颗粒度的一致性问题。

—

业务能力的识别

能力的识别可以用上下结合的方式，这可能也是被最经常使用的方式。

自上而下，从企业战略的角度确定20-30个高阶业务能力。实际执行时，相当于高层管理者对于规划项目的一些目标要求，比如“支持利率市场化”，实现“在移动端再造一个XX银行”等等，继续高阶能力的输入，继续向下分解。所以在规划项目启动时，征求企业高级管理者对规划项目的诉求是非常重要的输入。

自下而上，就是从业务部门、科技系统等具体的业务场景中出发，发现需要提升的点，再自下而上进行能力的归纳聚合，这适合于没有明确目标的时候。当然更多时候，是两种方法互相结合，领导提出了一些目标，而现状和问题调研恰好验证了这些目标^_^

除此以外，TOGAF还给出了三个比较好的业务能力的来源，组织架构、商业模式和业务计划。

参考业务能力的分层视图就可以知道，业务能力的最上层和组织架构基本能对应起来，当然这是在组织架构布局良好的情况下。但实际情况往往与此相悖，尤其是银行业，部门间职能重复、交叉的现象比比皆是，所以才会存在部门银行、烟囱系统的问题。从企业能力出发梳理组织架构的职责边界，恰好可以解决组织架构定位交叉的问题。从这一点上可以验证上面的观点，业务能力是相对稳定的，而不论部门如何调整。

二是商业模式，对业务模式的解析可以推导出业务能力，从业务模式推导业务能力，确保组织的活动（业务能力的实现）与商业模式是一致的。从业务计划、财务计划等解读能力是最经常使用的能力拆解方式，这同样保证了能力的落地与经营计划的一致性，确保业务流程包括后续IT系统的实现是为了支撑企业经营计划的落地。

—

业务能力的关联要素

回到本文最上面企业架构元模型，业务能力与各种架构要素相关，其中与业务能力的落地实现相关的是四个因素：人、流程、信息和资源。这也是上面所说的，能力企业战略也具体的业务要素之间的过渡和桥梁。

人，这是TOGAF的新提法，原来叫组织单元，不知道为什么改成人（person），其实代表的还是各类自然人、组织、合作伙伴等，内涵没有变换。人是能力的提供者，这里的人不应该是与组织架构绑定的人，而是岗位和角色的代表。流程是业务能力实现的一个重要载体，一个业务能力可以通过多个流程进行提现，可以把能力需求与业务流程进行更细颗粒度的绑定。信息和资源我觉得可以归为一类，都是为了实现能力交付而需要消耗的数据资产，以及其他信息、实物等资产。

以上是TOGAF中关于能力的落地以及与其他企业架构要素的关系。再强调一遍，能力关联的要素可以变换，而能力本身是不变的。

实际执行中，为了实现从业务架构到IT架构的落地，我们还需要把业务能力和业务组件、业务领域相关联；与以上要素相比，这是更宏观颗粒度的关联，目的是为了定义业务组件和业务领域的内涵，并通过从组件和领域向IT应用的映射，实现业务能力向IT系统建设的传导。

—

业务能力的可视化

在TOGAF的专用建模工具ArchiMate中，制定了业务能力及其它各类要素的符号语言，见下图，图里面给出的要素很多，在TOGAF的两份白皮书中，相当细致的教大家如何使用这套描述语言进行建模。不过个人忠告，TOGAF本身就概念重大，ArchiMate的符号设计又过于相近，分辨性不高，所以基于ArchiMate进行建模一定要做好TOGAF方法论的裁剪定制，以及对于ArchiMate视图的选择，不然会迷失在各类模型的汪洋大海中。