导图社区 战略级业务架构中
根据周金根战略级业务架构培训课程输出,将战略级业务架构中关于能力模型开发和战略路线图构建的相关知识进行了系统梳理和详细阐述,便于理解相关概念和方法。
编辑于2025-07-22 07:34:09战略级业务架构中
开发能力模型
 以架构思维学习就是要先建立起对整个知识体系的整体认识。将技术放在能力之后的目的是为了避免技术人员因技术思维导致的一上来就先考虑技术 业务洞察,形成改进建议,将其变为路线图,如果是纯业务的改进就给到业务部门,如果是IT信息化的就给到IT架构,IT架构就会做更细节的事,比如将信息衍生为数据架构和应用架构,将技术衍生为技术架构等 总结:  能力开发模型的输入是业务模型中的商业模式画布和战略地图中的客户价值主张,通过价值主张梳理出价值流,价值流分解价值阶段,根据价值阶段梳理流程,分解出流程活动,通过流程活动抽出对应的能力,对于能力通过利益相关者,流程,信息和技术四个方面进行完善,完善的目的是为了进行分析评估,从而产生业务洞察进行能力增量
价值流
  一个企业大概就是几十条价值流,如果你识别出来了上百条,说明你识别的不够抽象  value proposition是价值主张  价值流和流程的关系要注意区分,价值流和能力的映射,如果价值流不专注于价值,细化之后就是业务流程,业务流程就牵涉到组织,角色,数据,信息,技术等元素。 企业有多个价值流,价值流着眼点是价值,所以每条价值流都要有价值主张,都要有利益相关者,利益相关者可以是内部客户,也可以是外部客户。   描述可以足够复杂,这样就可以根据描述来解析到业务对象。根据描述可以推导出活动,根据活动可以抽象成能力,如果太细就很难推导出关心的要素出来。能力是后来放进去的,一开始可以不用放进来。  价值流能力映射是业务架构中很重要的一种输出物。在客户没有价值流能力映射图时你需要先梳理价值流,然后梳理能力,最后建立价值流和能力的映射关系。如果有,你只需要去评估价值流执行的怎么样,对能力进行评估。 用建模工具,比如Archi将其建模出来,建模的目的是为了分析,更是为了多个架构师之间便于共识,共享和沟通   画价值流的目的不是为了画而画,而是通过价值的视角,让企业内的各个部门由外而内的为了达成目标而对齐认知,形成共识。  逆向工程不是最优的,但却是一种方法【这也是很多IT部门总监了解公司流程的方式,让研发人员绘制流程图】。逆向话术如下 识别外部客户和内部客户:你的客户是谁, 识别价值:系统解决了他什么问题, 识别活动,进入和退出条件,通过活动来抽象出价值流阶段:他都是怎么操作这个系统 这样梳理出的价值流就形成了价值流的初版。我喜欢采用敏捷的方式,先出最小MV价值流 我们如果不想快速建模,可以先用Excel来梳理价值流,就像BA中给的通用模板一样。  先梳理外部客户的价值流,再梳理内部客户的价值流   基于战略去做价值流时,商业模式画布和战略地图是最重要的输入。 实在没有,你就只能用工具和方法将其引导出来.下面就是通过利益相关者和价值主张,梳理价值流的过程   商业模式变了,架构也就变了。所以架构都是动态的,要去实时更新。以前的架构是卖汽车,现在的架构价值主张都变了,比如维护,关键件回收,利益相关者多了很多  当一个图中内容很多时,我们要想办法用层的形式将内容展示出来,层的目的是能够很清晰的理解,很方便的达成共识    价值流包括价值流阶段,不同的价值流阶段对应相应的流程  分析价值流的目的是为了改进。改进的前提是分析。我们做架构不仅要对价值流分析,还会对利益相关者,业务能力等等进行分析。 价值流分析是基于价值流的,而价值流他给了我们一个线性视角,而不是让我们仅仅着眼于一个点。基于分析我们去做改进 
价值流和价值流阶段,价值流和能力的交叉映射, 价值流建模和常规价值流的来源
能力
   价值流能力映射是业务架构中的重要输出物。通过价值流我们得到能力矩阵,业务能力蓝图。而业务能力是对业务功能的抽象。一级业务能力对应业务系统,二级能力对应系统模块,三级业务能力对应的就是具体的业务功能。  对于规模较大的公司,三级能力图放到一块可能不太好展示,所以会进行拆分             
能力定义
    价值流-》价值流阶段-》词性分析法-》能力列表-》能力分组最后形成能力地图 上面得到的是能力的列表,我们还要将能力进行分组,    上述是从价值流推导出能力的例子          如何通过excel的方式表达能力 能力和战略,组织,价值流,应用架构,信息,成本和举措之间都有关系,所以在更详细的能力图里面,我们将不变的能力放到核心区域 
能力定义、能力建模、能力构成
能力分析
能力分析尽量做到最底层,这样可以向上汇总,从而帮助我们做决策,就像对数据分析一样,先有最底层数据,然后再向上做聚合  刚开始做的时候不会这么细,往往是个能力的描述,此时可以感性的做个能力成熟度评估。但是当时间充裕时可以做的详细点,这样有利于精准识别能力,并指导分析 能力成熟度示例:即给能力分级,一级低于一般水平,二级一般水平,三级超过一般水平,四级优秀  通过模型去做分级,分级的目的是为了站在业务架构师的角度,有前瞻性的对IT、流程等和业务相关的部门做出积极影响,比如如果知道供应商分为一般供应商,合作供应商和战略级供应商,对于不同的供应商就会延伸出不同的需求,在供应商管理策略和信息系统需求就会不同,不同的级别供应商需要IT的支持是不一样的,这些就是对能力进行成熟度分析带来的好处 但是能力提升意味着现状改变,当你在企业推广业务架构受阻时,其实并不是你方法不正确,而是利益相关者不想做出改变,或者不愿提升自己,所以懂他们的业务是前提,能够有效的引导他们【拿着科学的模型给他们讲】,能够通过向上一个层级来驱动利益相关者【通过项目的形式来落地】也是很重要的思考方向。 知道了能力分析的价值,那么如何展现呢?通过能力热图 能力热图都是通过底色,边框或图标这些展现形式来表现     
能力分析、能力成熟度评估、能力展现之能力热图的各种使用场景比如swot分析 |信息化依赖|战略主题|定义预算|应用程序和技术等关系、核心竞争力识别
能力增量
       
能力增量路线图和雷达图
业务能力的四个要素
角色:利益相关者和组织
     组织和能力是1对多的关系
流程
  这个图很好,业务能力和业务流程的关系很清晰,能力对应的什么流程,下面会详细说明流程的细节,将流程的细节也完善到表里面,那么这个就是个很重要的交付物   做流程时不是一步到位的,比如直接将流程图画出来,可以先输出excel流程表格,然后再梳理出流程架构  看图要看图中的元素,将能力和流程展现到一张图上,那么能力和流程的映射关系就会一目了然。  流程之间的串联就会形成场景分析。  业务架构中画流程图注意事项,不要花太多时间在先后顺序上,因为流程的先后顺序对业务架构师来说是易变的,我们前期又不是做流程的,也不是固化流程的,目的是将其包含的活动罗列清楚,所以要清晰何时应该做何事,什么阶段最重要的事是什么 业务架构中列出流程的目的是为了分析,而分析更多是流程架构师的活,我们作为参考即可   流程指导IT规划,通过分析流程成熟度和对IT的依赖度,从而去确定那些系统要重点做,那些系统要分段做,那些系统不用做,不用做的比如供应商战略规划,这些靠PPT就行了。 注重用户体验的客户旅程地图,如果你是家贴近客户的公司,那么这个是你做完流程之后必须要做的,而这个输出物体现了设计思维 
信息:信息来源(流程的输入和输出是重要的信息来源)和 信息建模
  信息如何展现呢,和能力一样也可以分层,分级   描述信息状态建议是信息已状态,这样更容易明确进入和退出条件。信息的来源有一个就是value stream价值流,进入和退出条件就是高优先级的信息。   
技术:应用合理化框架和技术热图
 通过业务架构做出来之后在变更时或追溯时能够很快的定位对其他的影响   企业架构学科其实对于IT专业知识要求并不太高,因为你做的不是开发,不是交付,不是实施,你只是做的是规划架构,定义和分析,而这些在大部分企业都是模糊的不清晰的,而很多IT软件重复建设,或者未达到能力标准的原因是因为规划不清,定义不清。这甚至有专门的定位,叫应用合理化。总之架构是管理工作而不是开发工作         
总结:理解能力,企业能力,业务能力,能力特征,能力分层,能力分级, 能力热图,能力分析,能力驱动的项目开发思维,能力建模
总结:从商业画布和战略地图抽出客户价值主张,通过客户价值主张梳理出 价值流,通过对价值流分解,分解为价值阶段,而价值阶段需要不同的能力支撑,而能力又分为一级二级和三级能力,我们用流程来实现三级能力的 落地,流程再细化为多个活动,具体的活动用IT系统来支撑,让流程指导IT规划
从商业画布或战略地图分解为客户价值主张,通过主张来连接利益相关者和价值主张的实现  建立价值流和能力的映射  从能力到流程,从流程到活动  根据流程的定位不同,从而指导IT规划 
构建对齐战略的路线图
 除了上面说的举措外,软件包,设计的流程也可以叫举措 如何捕捉项目和业务战略之间的关系?【如果说不出来就要思考你们的战略是否让每个人都清楚,你们的PMO部门是否做到了项目战略管控】 战略级的业务架构就要打通所有的不同阶段,直到举措这个阶段。根据举措上推要知道他实现的是什么能力,承接的是什么价值流和战略。 此时你可以思考你做的项目和项目集和公司的战略有啥关系?上图就很好的展示了能力,举措和成果之间的关系。 也就是说通过BMM商业动机模型和商业业务模型及商业能力模型,我们已经梳理出了从战略到能力增量的这样的一个过程,并且明确且细化了能力的不同要素需要做的增量,构建路线图这个步骤只是让我们确保我们的举措是和上面的结果是对齐的,不能出现流程上的脱节,通过项目能够向上定位到战略,通过战略能够向下找到项目的支撑,从而来保证战略到项目从上到下的真正有效落地。   之前的战略规划到项目是怎么做的?这样做带来的结果是什么?现在为何先从战略规划到架构,再从架构到项目,其底层逻辑是什么?这样做有什么好处?? 这是实施业务架构的人员所必须思考清晰的  下面展示下如何从战略主题到架构再到项目的整个概要流程。其中上图的架构对应的就是下面的行动  战略主题的另一种表达形式      明确了目标,有了手段,如何保证落地???借助敏捷项目的思想是一个好的途径,敏捷组织,敏捷产品开发是应对现在环境的最佳方式。其实不同的公司,不同的项目使用的手段应该是不同的,因为每个公司每个项目面临的外部环境不同,所以我们一定要做好分类分析,不可一招鲜。     我们发现没有业务架构的参与,项目中的人员在小的改进和bug上浪费80%的时间  项目部评的优先级永远是从局部优化的角度去评的,而业务架构是从企业整体角度去评优先级,这两者虽然都是评优先级,但是他说带来的结果以及对公司整体业务的提升是完全不一样的。所以业务能力地图做好之后,需要有架构师去提供指导而不是由项目部自己去做,项目部自己去做,它永远着眼于内部最优。举措建模的重要性就是将举措都看成一种投资,让其可以支持明智的商业决策。   项目人员往往不知道怎么填,或者不想填,或者不立项直接开干了。而我们业务架构师要做的就是对业务和项目人员进行培训,让其认识到战略到落地项目的过程中,业务架构的核心价值,在业务规划和项目落地中体现业务架构元素的必要性。 比如让他们知道能力从哪获得,战略从哪获得,能力差距如何评估等等 从能力到项目的落地上述给了6个步骤,接下来对步骤进行扩展  立项需要加入业务架构元素,此时我们要进行业务架构元素分析,比如用用能力热图做能力分析,能力评估,将要改进的能力用图形化方式标记出来,来做增量能力   通过这种能力地图和能力拆解为最细元素的详细的分析,这样保证了不重复,不遗漏,优先级明确,定义差距准确等 基于能力的改进落实到项目中,常见需求史诗  将史诗细化为故事,故事里的元素和业务架构中的元素也是对应的   所有的需求都在业务架构中体现,架构的治理中要保持业务架构和应用架构,数据架构,技术架构的对齐,从上可知项目组写的需求规范和业务架构是一致的,业务架构所做的东西可以作为项目组最高阶的需求。项目组可以通过业务架构对企业级需求和架构有个整体的认识,避免局部最优而导致整体不是最优。
从业务架构的企业角度框定举措,没有业务架构的举措 往往会加入很多小的改进,会使得局部最优但不是整体最优, 基于能力地图的拆解,能力的细化,找到要增量的能力 从而和敏捷结合来使项目落地