企业官网建设流程全解析

简介：这是一份聚焦业务架构设计方法的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架构师、合规人员、外部合作伙伴。

这张表的使用方式很直接：业务高管的关注点映射为顶层能力分组，流程所有者的关注点映射为能力之下的流程细化。如果某个干系人在整个流程里找不到对应的产出物，要么是方法缺了输出，要么是这个干系人在当前阶段本就不需要介入。

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打分：

评分的标准要在项目启动时确认，否则不同评审人打出来的分不可比。战略重要性建议参照年度战略主题，成熟度用“有明确责任组织、有系统工具、有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里。一个可落地的字段集合我推荐至少包含下面这些：

字段不在多，在于所有参与方都能认领责任。战略权重和成熟度必须在评审会上逐条过，宁可慢也要让评分有共识。

4. 业务架构设计方法在建模工具和交付物中的规范化表达

4.1 用ArchiMate表达业务架构设计方法产物的最佳实践

ArchiMate是当下做企业架构建模用得较多的语言，和BPMN相比，它更强调层次关系而不仅是流程顺序。业务架构设计方法产出的能力地图、流程骨架和业务对象，在ArchiMate里对应三组元素：Business Capability、Business Process、Business Object。

用Archi的脚本或者XML方式描述一个最小例子：

<element xsi:type="archimate:BusinessCapability" id="cap-01" name="客户获取"> <properties> <property key="level" value="1"/> <property key="domain" value="客户关系"/> </properties> </element> <element xsi:type="archimate:BusinessObject" id="obj-01" name="客户"> <properties> <property key="objectType" value="core"/> </properties> </element> <relationship xsi:type="archimate:AccessRelationship" id="rel-01" source="cap-01" target="obj-01" accessType="write"/>

AccessRelationship的accessType有read/write/access三种取值，在业务架构阶段更推荐只使用write和read，access含义模糊，后期容易变成两张皮。表达“该能力管理该客户对象”时用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 评审业务架构设计方法产出的七个检查点

评审时我用一份固定检查清单：

1. 能力是否有清晰的所有者描述，至少确定到业务域这个层级。
2. 能力命名是否避免组织称谓，页面上不允许出现“市场部能力”。
3. 是否存在重复能力，通过模糊匹配或关键词搜索。
4. L1根能力数量是否在8到12之间，超出就需要合并。
5. 是否存在孤岛能力，没有关联任何流程和对象。
6. 能力成熟度评估是否有数据支撑或评审共识。
7. 能力与业务对象的绑定是否能推导出后续的数据目录。

每个检查点都要留评审记录，尤其是第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'], c=df['gap'], cmap='coolwarm', s=100) ax.set_xlabel('当前成熟度 (score)') ax.set_ylabel('战略重要性 (score)') plt.colorbar(sc).set_label('差异 (Gap)') plt.show()

这段脚本把每条能力的两个维度和差距直接落到图上，横轴是当前成熟度，纵轴是战略重要性，颜色代表差距。颜色偏红且位置靠左上角的能力就是最需要优先投入的方向。热力图的价值在于把“哪条能力要优先投入”用一张图表达出来，比在评审会上念十条能力描述更高效。

第二个进阶技巧是业务路径验证。选三条最核心的端到端业务路径，比如“线索到回款”“订单到履约”“问题到解决”，然后把每条路径上经过的能力、业务对象、流程全部串联出来，逐节点走查。走查时只问两个问题：这个节点有没有明确责任能力，这个节点有没有对应的数据输入输出。凡是答不上来的节点，就是业务架构的断点。

这个走查方法看起来朴素，但在实际项目里比很多高级分析工具都管用。它能验证能力地图是否真的支撑业务运行，也能反过来检查流程骨架有没有漏掉关键环节。业务架构设计方法做完整套流程之后，用这两个手段做一次校验，交付物的可信度会明显提升。

本文还有配套的精品资源，点击获取