今天准备再跟大家讲一讲，我们在做企业架构规划的时候，在业务架构设计里面的业务能力地图和业务流程图两者之间的一些关系。

我个人做完整的IT信息化规划，可以追溯到2009年当时去做电网相关项目的时候，需要去输出完整的信息化架构规划这么一个事情。我印象比较深的就是，当时是参考了IBM的CBM组件化业务模型来做这个事情。

但是刚开始对电网行业不太熟，不可能马上就能够输出组件化的业务模型，所以更多参考的方式仍然是去梳理电网行业的业务和电网行业的端到端流程，把这个事情做完以后最终才能够形成我们常说的CBM组件化业务模型。所以在09年左右的时间，我的概念里面组件化业务模型就是相当重要的一个业务架构输出。

到了2010年到2011年左右，开始接触电信运营商相关的一些项目，包括跟埃森哲一起会去做一些基于企业架构相关的企业架构规划和设计的工作。埃森哲在这一块做相关的企业架构规划输出的东西就相当的系统，包括对整个电信行业的MSS管理域做了完整的企业架构规划设计。

当时我们再去看相关的规划输出报告的时候，就看到了关于业务架构规划这个地方，实际上就包括了两类关键的输出，第一个就叫业务能力地图，第二个就叫详细的业务流程图。

但是它的整个的顺序，它反而是如何的呢？

在去做顶层设计的时候，从价值链到能力的分类，一级的能力分类、二级能力分类，在这个时候他更多的都是用业务能力地图在做表示。只是拆解到最细化的一级到四级的业务能力分类的时候，它才会进入到详细的流程图的建模，包括用的EPC基于事件链的流程图的分析方法。

所以埃森哲这个项目做完以后，给我最大的一个疑问，也是你的业务能力地图和流程图之间究竟是什么样的一个关系？因为开始我可能不清楚这个行业，我其实没办法输出完整的业务能力地图，而且在去做顶层建模的时候去做业务能力地图，它是一个静态的地图，所以说从埃森哲的输出里面，你其实很难看到完整的端到端的流程图，这个也是我一直以来有的一个疑问。

所以到了2013、2014年再去做其他的一些SOA架构规划、企业架构规划的时候，除了借鉴前期项目的经验以外，更重要的就是结合了SOA和云计算的思想，包括当时我们去做底层的技术架构规划的时候，已经不是简单的做IT基础设施架构的规划。已经会去做整个云平台，包括PaaS平台的整个技术架构的规划设计，同时原来在企业架构规划里面它会有应用架构规划，在应用架构规划里面涉及到应用之间的集成架构规划，但是相对于服务架构规划这个地方一直就比较弱。

所以说结合了SOA横向分层接口服务可复用的思想，其实我们会去把服务架构规划的内容进一步去加深。但是实际做的时候，我们仍然一直以来的问题就是，我的业务能力地图和业务流程图之间究竟是什么样的一个关系？

在去年的时候，我专门录过一个视频来讲业务架构图里面的业务能力地图和业务流程图。我强调了一个观点就是从企业顶层的战略和业务目标展开，它会涉及到一个最最顶层的企业核心的价值链模型。

这个价值链模型我们在去做分析的时候，它可以两条线路去做展开。第一条线路其实就是走业务能力的架构规划、业务能力的分析去展开，你可以有一级分类、二级分类、三级分类，另外一个线路就是走流程这条线，你开始可以有端到端的流程，然后有一级流程二级流程三级流程四级流程。

所以这个其实一直是我强调的一个关键的思路，因为业务能力地图和业务流程图都是业务架构重要的一个输出。那这两者之间究竟是什么样的一个关系？我们究竟应该谁先谁后或者是还是两个可以同时进行？

我们来看一下里面的一些关键点。

拿顶层的业务价值链，比如从波特的业务价值链来说起，其包括了研发、物流、供应链、生产制造、市场营销、售后服务这个核心价值链，这个核心价值链你既可以说它是最最顶层的端到端流程，你同时也可以说这个东西就是一个业务能力的顶层的图。因为它看起来不像流程图，它只是一个大的阶段的一个图。

所以说到了顶层的时候业务能力地图和顶层流程图这两者往往是合二为一的。最最顶层涉及到有供应链管理，供应链管理展开二级能力的时候，它可能就会拆分了，在二级的业务能力地图里面可能就包括了供应商管理、合同管理、采购管理、库存管理，这个是二级能力的拆分。

那么到了供应链管理的时候，有没有一个相应的流程跟它对应呢？答案是有可能有一个端到端流程，比如说供应链你可以结合供应链SCOR模型有一个端到端的供应链流程，但是答案也有可能是没有一个端到端流程和二级的业务能力对应，因为这个时候二级的能力地图它往往对应过来，它很可能是在我流程建模里面多个子流程的一个合集而已，它仅仅是一个合集，不会有一个端到端流程和它对应。

再拆到后面的时候，你在采购管理再拆的时候，你可能拆出了采购订单管理，采购订单管理已经到三级了，采购订单管理很有可能也没有一个流程跟它对应，它也是流程的一个合集。

但是采购订单管理再朝下拆解能力的时候，你可能就会看到有采购订单的申请，有采购订单的变更，有采购订单的废弃，这个已经拆到四级能力了，拆到四级能力以后很明显的变化就是采购订单申请会对应到申请流程，变更会对应到变更流程。也就是说我业务能力地图拆到最底层，业务流程对应到最底层以后，最底层的业务能力的这个模块跟我的业务流程才能够做到一对一的对应，我的业务能力分析到这个地方已经足够了，我知道你具备了采购订单申请采购订单变更的能力就足够了。

但是采购订单的申请采购订单的变更这个能力要怎么实现？它具体涉及到哪一些操作步骤活动？哪一些组织角色参与有哪一些细化的业务规则？这个不是已经业务能力地图关心的事了。

业务能力地图只关心有这个能力，并不关心能力如何实现。

这个是业务流程建模你做到四级做到五级的时候要去详细梳理的事情，为什么要去梳理这个事情？因为业务流程只有梳理到这个事情，才能够去作为我后面IT应用架构的关键的输入，业务能力地图只知道我具备这个能力，业务流程详细的梳理才知道我怎么样去实现这个能力。

所以说到了最细致的流程的建模，它已经有点类似于我们在软件系统开发里面的需求的分析需求的开发，稍微再细化一点已经可以输出相应的软件需求文档，这个地方才能够指导我后续应用架构的设计和开发工作。

但是到了业务能力地图我只需要知道有这个能力就足够了，所以这个才是我们讲的业务能力地图和业务流程图相关的一个关系。如果你对这个行业相当熟悉，你当然是可以先去做业务能力地图，展到最下面以后再用业务流程建模去做详细的展开。

但是如果你对这个行业不熟，你开始没办法做业务能力地图，你仍然是需要基于企业端到端流程的梳理和分析，逐渐的分析完所有的流程以后，再去通过聚合的方式形成业务能力地图。业务能力地图在顶层和底层都有相应的对应关系，但是在业务能力地图的中间层，往往是会对应到相应的端到端的流程，这个就是我们讲的在企业架构规划里面业务能力地图和业务流程图，它之间应有的一些衔接关系，究竟怎么用还是要结合你实际的业务架构规划、实际的项目去思考。

好了，今天的简单分享就到这个地方，希望对大家有所启发。