华为企业架构方法论:业务架构四层建模与可评审落地
简介「华为企业架构之业务架构设计方法」PPT课件面向企业架构师、数字化转型负责人及智慧城市业务规划者。内容系统梳理TOGAF语境下业务架构的定义与价值给出华为视角的实施路径——价值流梳理、业务能力梳理、业务流程梳理、业务对象识别与关键要素梳理五步递进并提炼战略驱动、反映业务本质、提升业务能力、促进业务集成、弱耦合组织、信息贯通、稳定与持续改进七项设计原则配企业级与专业级价值流图示把宏观战略分解为可执行的运营动作。包内共1个pptx文件约2.98MB以图集和清单方式呈现涵盖业务能力框架、流程架构图、指标清单、角色清单等交付物范例可直接用于内部培训或方案编写参考。目前已有210人学习对需要理解业务架构方法论并结合智慧城市场景落地的读者是一份轻量但结构完整的入门与对标材料。1. 业务架构不是画完的而是对齐出来的很多团队做完一堆架构图评审时却答不上一个最朴素的问题这套业务架构支撑的是哪条战略、哪条价值流、哪个部门的哪项考核图很漂亮落不了地。华为企业架构方法论里业务架构设计方法的核心价值恰恰不在图形本身而在于把战略、业务、IT 三层语言对齐形成一套可评审、可迭代、可追溯的结构化资产。本文讨论的不是某份 PPT 的逐页复述而是按这套方法论最常见的落地路径把业务架构从战略解码到流程建模、再到与 IT 衔接的完整做法讲清楚它包含哪些层次、每层的产出物是什么、用什么工具画、参数和字段怎么定义、评审时看哪些硬指标。适合正在做数字化转型规划、企业架构治理、流程重塑的架构师、产品负责人和业务分析师也适合准备架构类认证与面试的人补齐方法论骨架。2. 业务架构的四层结构与建模前必须先定的参数2.1 从战略到流程业务架构的四层拆解按企业架构的惯常分层业务架构通常处在战略与 IT 之间向下衔接应用架构和数据架构。落到可操作的粒度一般拆成四层战略层、业务能力层、业务流程层、业务对象与角色层。四层不是并列关系而是层层分解、逐层可追溯。战略层回答为什么做产出通常是战略目标、关键举措、成功衡量指标。业务能力层回答靠什么做把企业能力拆成能力地图比如营销能力、供应链能力、交付能力。业务流程层回答怎么做把能力落到端到端流程用 L1 到 L4 的层级展开。业务对象与角色层回答谁在做、操作什么定义业务实体、组织角色、权限边界。四层之间要建立映射关系每个关键举措对应若干能力每个能力对应若干流程每个流程对应若干业务对象这条链路断了架构就只是装饰。我在实际项目里最常用的检查方式是反向追溯随便挑一个业务对象能不能顺着链路回到最上层的战略举措。做不到说明中间某一层是拍脑袋补出来的。2.2 建模前必须锁定的六个参数动手画之前有几个参数要先定死否则到后期返工成本极高。参数说明常见取值流程分级标准L1~L4 的划分口径L1 价值链级L2 流程组L3 流程L4 活动能力颗粒度能力地图拆到几级一般 3 级最多 4 级业务对象命名规范实体命名与唯一标识名词短语全局唯一禁止同义多名角色定义来源岗位还是职责优先职责角色不直接绑岗位版本与编号规则资产编号方式域码层级码流水号评审门禁什么条件才能进入评审追溯链路完整、无孤立节点这里面最容易出问题的是能力颗粒度。拆太细会变成流程活动清单拆太粗又无法指导系统建设。我的经验是一个能力如果无法独立定义负责人和衡量指标就说明颗粒度太小如果一个能力跨越三个以上部门且无法拆开说明太大。提示能力地图和能力清单是两回事。地图用于沟通和规划清单用于治理和考核不要用一张图同时承担两个职责。2.3 业务能力地图的构建步骤与校验能力地图的构建可以用一套固定动作推进避免陷入无限讨论。第一步从战略举措中提取动词和名词动词指向能力名词指向业务对象。第二步按业务域聚类形成一级能力域通常 8 到 15 个之间。第三步向下拆二三级能力每级控制在 5 到 9 个符合认知负荷。第四步给每个能力标注成熟度等级一般用 1 到 5 表示现状与目标之间的差距。第五步做完整性校验确保能力之间不重叠、不遗漏覆盖全价值链。# 业务能力地图完整性校验检查重叠与孤立节点 capabilities [ {id: C01, name: 客户洞察, domain: 营销, level: 2, parent: C00}, {id: C02, name: 客户洞察分析, domain: 营销, level: 3, parent: C01}, {id: C03, name: 需求预测, domain: 供应链, level: 2, parent: C00}, {id: C04, name: 订单履行, domain: 交付, level: 2, parent: C00}, ] # 参数level 表示能力层级parent 表示父能力编号 parent_ids {c[parent] for c in capabilities} orphans [c[id] for c in capabilities if c[id] not in parent_ids and c[level] 1] print(孤立节点无下级也无上级关联:, orphans or 无) # 命名重叠检查同一父节点下名称包含关系视为潜在重叠 from collections import defaultdict by_parent defaultdict(list) for c in capabilities: by_parent[c[parent]].append(c[name]) for p, names in by_parent.items(): for i, a in enumerate(names): for b in names[i1:]: if a in b or b in a: print(f潜在重叠: 父节点 {p} 下 {a} / {b})这段脚本做两件事一是识别孤立节点业务能力如果既没有父级引用也没有子级引用说明它没有接入整体结构二是识别同一父节点下的名称包含关系名称互相包含往往意味着两个能力边界没划清。实际使用时把 capabilities 换成从表格导入的数据即可字段名按自己团队规范调整。2.4 从能力到端到端流程的映射做法能力层确定后下一步是把它落到端到端流程。这里的关键是区分能力视角和流程视角能力是静态的、聚合的流程是动态的、按时间展开的。映射的做法是先识别企业的主价值链也就是从需求到交付的主干流程通常三到五条比如线索到回款、问题到解决、采购到付款。然后为每条主干流程定义流程组和子流程把上一步识别的业务能力挂到对应流程节点上。一个能力可能被多条流程复用这很正常但要在映射表里标注清楚是主用还是支撑。映射完成后要检查两件事每条主干流程是否都能找到能力支撑每个关键能力是否至少在一条流程中落地。如果某个能力在所有流程里都找不到落点要么是能力定义有问题要么是流程覆盖不全。这个检查用一张二维交叉表就能做行是能力列是主干流程交叉点标注主用、支撑或空白。3. 用业务流程建模标准把架构图画到可评审的粒度3.1 建模符号的选择与统一口径业务架构落到流程层必须有一套统一的建模语言否则图与图之间无法拼接评审时各说各话。业界最通用的做法是采用业务流程建模标准符号事件、活动、网关、泳道这几类元素基本够用。选型上的原则是如果流程要交付给 IT 做系统实现用标准符号如果只是业务内部沟通用简化的框图也可以但要在一开始声明口径不要中途换。统一口径里要明确的细节包括网关用哪一种排他、并行、包容分别对应什么业务语义泳道是按角色分还是按系统分异常流用单独的子流程还是主流程里加分支。这些细节不定两个团队画出来的图就无法合并。?xml version1.0 encodingUTF-8? !-- 业务流程片段泳道按角色划分网关使用排他网关 -- definitions xmlnshttp://www.omg.org/spec/BPMN/20100524/MODEL targetNamespacehttp://example.com/business-arch process idorderFulfill name订单履行流程 !-- 泳道1业务受理角色 -- laneSet idlanes lane idlane_sales name销售代表/ lane idlane_ops name运营专员/ /laneSet !-- 起始事件客户提交订单 -- startEvent idstart1 name客户提交订单/ !-- 排他网关判断库存是否满足 -- exclusiveGateway idgw_stock name库存满足?/ sequenceFlow idf1 sourceRefstart1 targetRefgw_stock/ !-- 活动运营专员确认发货 -- userTask idtask_ship name确认发货/ sequenceFlow idf2 sourceRefgw_stock targetReftask_ship/ /process /definitions这段 BPMN 片段展示了最小可评审的结构泳道按角色划分起始事件、排他网关、用户任务通过顺序流串起来。实际项目中不需要手写 XML用建模工具导出即可但理解这段结构有助于排查工具导出的图为什么在另一款工具里打不开。关键参数是 id 唯一性和 sourceRef、targetRef 的闭合性任何一条顺序流的起止节点都必须存在否则文件校验直接失败。3.2 流程分级与编号规则的落地流程分级最常见的做法是四级L1 价值链L2 流程组L3 流程L4 活动。编号规则要能一眼看出归属比如域码-层级码-流水号的形式。L1 用两位大写字母表示业务域L2 到 L4 依次递增两位数字。层级编号示例说明责任人L1MK营销域价值链域负责人L2MK-01线索管理流程组流程组负责人L3MK-01-02线索分配流程流程 ownerL4MK-01-02-03线索自动分配活动岗位/系统这套编号的好处是任何一条活动都能反推回价值链汇报和评审时不需要额外解释。编号一旦发布就不要随意变更否则历史版本的追溯会断掉。如果流程重组新增编号比修改旧编号更稳妥。3.3 流程与业务能力的关联矩阵关联矩阵是评审时最有说服力的证据。用一张表把主干流程和能力对齐交叉点标注关系类型。能力 \ 流程线索到回款采购到付款问题到解决客户洞察主用空白支撑需求预测支撑主用空白订单履行主用空白支撑服务响应空白空白主用评审时重点看三列一列全是空白的流程说明流程没有能力支撑要么是虚构流程要么能力遗漏一行全是空白的能本文还有配套的精品资源点击获取