简介这是一份聚焦业务架构设计方法的PPT适合企业架构师、业务分析师、IT规划人员及智慧城市相关项目从业者学习。内容以华为企业架构实践为基础系统梳理业务架构的定义与价值明确其是企业治理结构、业务能力与价值链的正式蓝图详细阐述战略驱动、反映业务本质、提升业务能力等七项设计原则并给出价值流梳理、业务能力梳理、业务流程梳理、业务对象识别、关键要素梳理的设计步骤以及业务能力框架、流程架构图、角色清单等关键输出物同时介绍企业级价值流图、专业级价值流图、操作指导输出等应用场景。全套资源仅含1个PPTX文件压缩包约2MB内容结构完整便于直接查阅与复用目前已有596人学习下载适合需要快速建立业务架构设计方法论框架的读者。1. 企业架构项目里业务架构最容易被做成一堆漂亮的流程图我在不少企业架构项目里见过同一个结局业务架构的交付物描了一整面墙的流程图评审时大家都点头落地时完全找不到抓手。华为企业架构的实践里业务架构设计方法之所以能被单独拿出来讲是因为它先回答一个更底层的问题——“企业有哪些业务能力”而不是“企业有哪些流程”。这个标题展开后的核心价值就在这里业务架构不是画图手的练习而是一套可推导、可拆解、可计算的设计方法把战略意图翻译成能力地图、业务对象和流程骨架再往下才能接数据架构和应用架构。适合的读者是正在做企业架构规划的人以及写方案写到发现“流程好画、能力不好拆”的顾问和业务分析师。2. 华为企业架构中业务架构的定位与能力中心的设计方法2.1 业务架构在华为EA四层框架中的位置企业架构通常在TOGAF、Zachman之类的框架里谈得比较多华为在企业数字化推进中更强调四层结构战略层、业务架构层、信息架构层、技术架构层。技术架构在最底下信息架构在中间业务架构在最靠近业务决策的那一层。很多人一上来就套TOGAF把业务架构描述成流程加组织其实不够。华为的做法我更愿意理解为“双向翻译”战略层拆出战略主题、关键战役和考核目标业务架构把这些翻译成能力、流程和业务对象信息架构再往下把业务对象翻译成数据实体和数据流转关系。如果业务架构只画流程信息架构就无法直接推导数据实体因为流程和组织都是易变的业务能力才是相对稳定的。2.2 业务架构设计方法的核心逻辑业务能力分解而非流程分解常见的业务架构设计方法有两条路线流程中心法和能力中心法。早期企业架构项目里流程中心法很流行把端到端流程逐层细化成流程图。问题在于流程天然跟组织绑在一起组织一变、系统一变流程图很快失真。能力中心法的逻辑正好相反。业务能力是企业为了达成战略意图所必须具备的能力它不依赖于具体的组织和流程。比如“客户信用管理”是一个业务能力不管它落在销售部还是风控部都存在“信用审批流程”则是流程。业务架构设计方法在华为语境下明显更倾向于能力中心因为这跟华为强调的“以客户为中心”的运作方式一致能力地图天然可以按客户价值链条组织。2.3 业务架构设计方法和其他架构设计方法的关系一套完整的业务架构设计方法并不是只产出能力地图它与信息架构、应用架构的边界必须在设计初期就划清楚。常见做法是用RACI矩阵驱动协作业务架构负责定义能力、对象和规则数据架构负责把这些对象沉淀为数据资产并补全数据分布关系应用架构再把能力与数据资产的纽带落成应用功能和服务。这里我一般会用一张“业务能力登记表”作为源头所有后续设计都围绕这张表展开。表里每条能力带一个编码、一个名称、一段描述和一组所属业务域编码规则采用多级分段例如CRM-CAP-01表示客户关系域下的第一个能力。这套编码在后续翻到数据实体、应用模块、接口清单时都是唯一的锚点。2.4 业务架构设计方法的输入与输出物方法落地要断开明确的输入输出。输入一般是三样企业战略目标和年度关键任务、商业模式画布或业务模式说明书、干系人诉求清单。输出物则是五个分层业务能力地图、业务对象清单、端到端流程骨架不是详细流程图、组织与角色清单、能力与流程矩阵。这五件输出物里业务能力地图是全集业务对象清单是数据架构的入口端到端流程骨架按价值流组织避免变成无边界的大网状。组织与角色清单专门用来做能力与组织的映射孤悬在能力地图之外方便组织调整时比对差异。提示业务架构设计方法及时做对后续应用架构会省掉大量返工。能力地图没建对后面每一轮系统规划都在补东墙。3. 业务架构设计方法实操从战略意图到能力地图的落地步骤3.1 第一步识别利益相关方并定义业务范围任何业务架构项目的失败大多不是方案错而是边界没放对。设计方法的第一步不是画图而是明确这次业务架构设计覆盖的业务域和干系人。常见的错误是上来就把全公司所有业务都装进一张地图结果能力列表膨胀到几百条评审会开不完。我会先用一张干系人矩阵收敛范围。矩阵列出业务高管、流程所有者、数据所有者、IT架构师、合规人员、外部合作伙伴。干系人关注点业务架构中对应的输入/输出参与阶段业务高管战略目标对齐考核指标战略主题关键任务初步设计流程所有者流程效率和瓶颈端到端流程骨架能力拆解后数据所有者数据标准与一致性业务对象清单对象识别IT架构师应用映射系统边界能力与服务清单能力建模合规人员合规要求风险点能力清单中合规字段评审这张表的使用方式很直接业务高管的关注点映射为顶层能力分组流程所有者的关注点映射为能力之下的流程细化。如果某个干系人在整个流程里找不到对应的产出物要么是方法缺了输出要么是这个干系人在当前阶段本就不需要介入。3.2 第二步用业务能力分解法逐层拆分业务能力业务能力分解最常见的套路是把企业顶层的价值主张作为根能力往下按“价值流需要的支撑”而不是“组织职能”来拆。我一般会把根能力控制在8到12个比如客户获取、客户履约、客户服务、产品管理、供应链管理、财务管理、风险与合规管理等。再往下每一层用“动词名词”的方式命名保证能力名称不是筒仓名称。比如“客户获取”下面可以拆“市场活动管理”而不是“市场部工作”。每层拆解后验证一个标准如果在同一层出现的能力数量超过12个说明本层粒度过细应当回到上层。这个验证标准我会固化到模板里。下面这段JSON是业务能力字典的示例片段可以直接作为能力登记表的初始结构{ businessCapability: [ { id: CRM-CAP-01, name: 客户获取, description: 面向潜在客户通过市场活动、营销跟进、商机管理获得有效客户的过程, level: 1, parentId: , domain: 客户关系, isCritical: true, associatedProcesses: [P-1001, P-1002], associatedObjects: [OBJ-CUSTOMER, OBJ-LEAD] }, { id: CRM-CAP-01-01, name: 市场营销活动管理, description: 策划并执行市场活动收集客户线索并评估效果, level: 2, parentId: CRM-CAP-01, domain: 客户关系, isCritical: true, associatedProcesses: [P-1001], associatedObjects: [OBJ-MARKET-EVENT, OBJ-LEAD] } ] }这段结构说明几个参数字段的含义id是唯一标识level代表能力层级parentId用于描述父子关系domain标记业务域associatedProcesses和associatedObjects是后续与流程、数据架构衔接的桥。如果能力由多个系统承载不一定在JSON里直接写系统因为系统归属是应用架构成熟后再回填的。3.3 第三步业务能力与战略价值映射能力地图不能只是目录必须有价值导向的评估。我一般会引入两个属性战略重要性和当前成熟度形成热力图的原始数据。这一步的价值是把“每条能力都要建系统”的错误观念破除。评估参数如下表每项按1到5打分能力名称战略重要性当前成熟度差异优先级建议客户线索管理523优先补齐订单履约541保持优化供应商协同321择机建设合规审计支持431保持合规评分的标准要在项目启动时确认否则不同评审人打出来的分不可比。战略重要性建议参照年度战略主题成熟度用“有明确责任组织、有系统工具、有KPI”三个维度加权三项都有的算4分缺一项减分全没有算1分。这样算出来的差异就是规划应用架构的优先级依据。3.4 第四步业务对象识别与数据实体关联业务对象是从业务能力推导出来的而不是从数据库表推导出来的。每个能力在描述中如果提到“对XX进行管理”这个“XX”通常就是候选业务对象。比如“信用风险管理”能力会识别出“客户信用档案”“授信额度”“风险事件”三类对象。得到候选业务对象清单后我通常会用一张矩阵表把对象和能力关联起来。下一步再把这层对象交给数据架构师去设计数据实体。此处可以用一个简短的SQL示例来说明能力对象与数据实体的映射在架构仓库中如何持久化-- 业务能力与业务对象映射关系表 CREATE TABLE capability_object_mapping ( capability_id VARCHAR(50) NOT NULL, object_id VARCHAR(50) NOT NULL, mapping_type VARCHAR(20) NOT NULL, -- direct / derived / shared created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (capability_id, object_id) );mapping_type字段值得注意direct表示对象由该能力直接管理derived表示对象由能力计算或统计产生shared表示对象被多个能力共享。共享对象往往就是未来数据治理要重点盯的对象也是应用架构中判断主数据归属的关键。3.5 第五步生成业务能力字典标准字段最后把能力字典标准化成固定字段结构。这一步是华为风格很强的点架构资产必须是结构化的不能只存在于PPT里。一个可落地的字段集合我推荐至少包含下面这些字段名属性必填说明capability_code字符串是多级编码层级之间用短横线capability_name字符串是建议动词名词capability_desc文本是描述能力承担的职责避免使用组织名strategic_weight整数1-5是战略重要性maturity_score整数1-5是成熟度process_ref字符串数组否关联的流程编号object_ref字符串数组否关联的业务对象编号org_responsible字符串否责任组织允许为空字段不在多在于所有参与方都能认领责任。战略权重和成熟度必须在评审会上逐条过宁可慢也要让评分有共识。4. 业务架构设计方法在建模工具和交付物中的规范化表达4.1 用ArchiMate表达业务架构设计方法产物的最佳实践ArchiMate是当下做企业架构建模用得较多的语言和BPMN相比它更强调层次关系而不仅是流程顺序。业务架构设计方法产出的能力地图、流程骨架和业务对象在ArchiMate里对应三组元素Business Capability、Business Process、Business Object。用Archi的脚本或者XML方式描述一个最小例子element xsi:typearchimate:BusinessCapability idcap-01 name客户获取 properties property keylevel value1/ property keydomain value客户关系/ /properties /element element xsi:typearchimate:BusinessObject idobj-01 name客户 properties property keyobjectType valuecore/ /properties /element relationship xsi:typearchimate:AccessRelationship idrel-01 sourcecap-01 targetobj-01 accessTypewrite/AccessRelationship的accessType有read/write/access三种取值在业务架构阶段更推荐只使用write和readaccess含义模糊后期容易变成两张皮。表达“该能力管理该客户对象”时用write“该能力引用数据但非owner”时用read。4.2 业务能力地图的绘制规范能力地图画得好不好直接决定这张图在会议上的说服力。常见绘制规范我总结为五条按层级分泳道L1在顶行L2和L3逐层向下每个能力格子内只写名称和编码描述别放图上同层格子数量控制在4到8列一页放不下就分域多页能力格子的颜色只用于战略重要性和成熟度不用于组织归属跨域依赖用虚线箭头标出但每张图箭头不超过10条。如果使用绘制工具可以用PlantUML的ArchiMate插件快速出初稿。下面是一个可以直接在PlantUML里跑的示例脚本startuml !include archimate/Archimate Archimate(BusinessCapability, 客户获取, 客户获取) Archimate(BusinessProcess, 市场活动执行, 市场活动执行) Archimate(BusinessObject, 客户线索, 客户线索) Rel_Access(customerACQ, customerLead, write) Rel_TriggeredBy(customerACQ, marketingExec) enduml这个脚本的价值是让画图进入版本管理而不是停留在画布上。能力地图如果只在PPT里更新版本多了之后就没人知道哪张是权威。4.3 业务架构设计方法模板的内容结构业务架构设计方法的PPT模板一般按七页来组织顺序是背景与目标、设计范围与干系人、业务能力总图L1、能力拆解明细L2/L3、业务对象清单、流程骨架与能力矩阵、后续实施建议。每一页对应的评审问题也要写进模板备注否则交付物无法答辩。模板里的“流程骨架与能力矩阵”页是最容易做错的。正确做法是把流程按价值流分组每一个价值流列出核心流程再标注每个流程由哪些能力支撑。这样能同时回答“流程怎么走”和“能力怎么复用”两个问题评审会上不会僵持在流程图细节里出不来。4.4 评审业务架构设计方法产出的七个检查点评审时我用一份固定检查清单能力是否有清晰的所有者描述至少确定到业务域这个层级。能力命名是否避免组织称谓页面上不允许出现“市场部能力”。是否存在重复能力通过模糊匹配或关键词搜索。L1根能力数量是否在8到12之间超出就需要合并。是否存在孤岛能力没有关联任何流程和对象。能力成熟度评估是否有数据支撑或评审共识。能力与业务对象的绑定是否能推导出后续的数据目录。每个检查点都要留评审记录尤其是第5个孤岛能力。孤岛能力往往意味着业务域之间的断点也是后续流程再造和系统整合的潜在风险。5. 业务架构设计方法中常见的失败模式与正确出路5.1 拿组织架构冒充业务架构这是最常见的一种失败模式。企业画出来的所谓业务架构本质上是公司组织架构图的翻版按部门分区按汇报线画线。这样做的结果是能力清单跟着部门调整走组织一换架构资产立刻失效。出路只有一个把组织因素从能力分解逻辑中剥离。能力分解的依据是“客户价值和业务规律”不是“汇报关系”。在能力地图评审时多问一句“如果这两个部门合并图上有多少地方要改”就能测出这张图到底是组织图还是业务架构图。5.2 端到端流程图堆成巨型网状图和上一类相反另一类失败模式是把所有流程画成一张巨大的端到端流程图希望用一张图表达全部业务。问题很明显流程图一旦超过一个屏幕它的唯一用途就是挂在墙上当装饰品。业务架构设计方法中流程表达是有明确粒度的。价值流级别用泳道图流程级用BPMN逻辑流程细节不展开到每个岗位操作。如果一张流程图中包含超过30个节点说明要么拆分粒度不对要么混入了流程细节。5.3 能力拆解数量失控能力地图拆到几千条常见于追求“全面”的大型项目。能力拆得越细后期维护成本越高评审时也越难对齐。正确的做法是先管住一级和二级能力三级能力只对重点领域展开。数量失控还有一个内因缺少编码前缀和归属规则。每一条能力都要能对应一个业务域前缀比如CRM-CAP-01-01只要域归不进去说明粒度或分类有问题。把前缀当作一种分形约束能有效避免能力清单无限膨胀。5.4 业务对象与数据架构脱节有些项目把业务能力做得很完整但业务对象清单只是一张命名的表格没有和数据模型产生关联更谈不上数据分布。最后数据架构师还是从头设计数据模型业务架构的沉淀就白费了。我一般会在业务对象清单里直接增加“数据实体候选名称”字段业务架构评审之后数据架构师可以基于这个字段做物理建模。候选名称用业务学的语言而不是开发语言例如“客户信用档案”对应后续的customer_credit_profile表这个映射如果前置完成信息架构推导的链路就通了。6. 业务架构设计方法的进阶用能力热力图和业务路径做验证业务架构设计方法走到验证环节有两个常用手段能力热力图和业务路径分析。热力图用能力评估分生成操作上可以用Excel透视表完成也可以用Python快速输出。下面是一个用表格作为数据的Python示例import pandas as pd import matplotlib.pyplot as plt df pd.DataFrame({ capability: [客户获取, 客户履约, 服务支持, 产品管理, 财务管理], strategic: [5, 5, 4, 3, 4], maturity: [2, 4, 3, 3, 4] }) df[gap] df[strategic] - df[maturity] fig, ax plt.subplots(figsize(10, 4)) sc ax.scatter(df[maturity], df[strategic], cdf[gap], cmapcoolwarm, s100) ax.set_xlabel(当前成熟度 (score)) ax.set_ylabel(战略重要性 (score)) plt.colorbar(sc).set_label(差异 (Gap)) plt.show()这段脚本把每条能力的两个维度和差距直接落到图上横轴是当前成熟度纵轴是战略重要性颜色代表差距。颜色偏红且位置靠左上角的能力就是最需要优先投入的方向。热力图的价值在于把“哪条能力要优先投入”用一张图表达出来比在评审会上念十条能力描述更高效。第二个进阶技巧是业务路径验证。选三条最核心的端到端业务路径比如“线索到回款”“订单到履约”“问题到解决”然后把每条路径上经过的能力、业务对象、流程全部串联出来逐节点走查。走查时只问两个问题这个节点有没有明确责任能力这个节点有没有对应的数据输入输出。凡是答不上来的节点就是业务架构的断点。这个走查方法看起来朴素但在实际项目里比很多高级分析工具都管用。它能验证能力地图是否真的支撑业务运行也能反过来检查流程骨架有没有漏掉关键环节。业务架构设计方法做完整套流程之后用这两个手段做一次校验交付物的可信度会明显提升。本文还有配套的精品资源点击获取