企业官网建设流程全解析

简介：一份面向ARIS业务架构初学者的快速入门手册，适合需要系统学习业务流程建模、对象事件与连接配置的顾问、流程管理人员及信息化实施人员。内容从安装激活、基本设置、创建数据库等准备环节讲起，逐步覆盖模型创建、对象与属性设置、事件触发、重命名、对象安排与分组、连接和链接建立等操作，并包含应用模板、置入属性、模型保存与打印等实用功能，有助于零基础用户快速建立整体操作认知并上手实践。压缩包内为单个docx文档，资源大小约2.76MB，结构清晰、目录完整，便于按章节查阅和对照练习。目前已有114人浏览学习，适合用于日常自学、内部培训或作为ARIS项目启动前的快速预研资料。

1. ARIS业务架构为什么值得单独写一份“快捷入门”

很多团队引入ARIS的初衷是整理流程，画了半天EPC和图册后发现：业务侧不认可、IT侧只把它当成截图工具，真正该回答的“为什么有这个流程、由哪个能力支撑、对应哪套系统”反而没人说得清。ARIS里“业务架构”不是一个报告主题，而是对象池中从能力、价值流到应用系统的这段数据链条。它决定了流程图、组织图和系统图能不能被自动追溯和计算。这篇内容不讨论咨询方法论，只讲在ARIS里“业务能力-价值流-流程-系统”这套对象怎么建、怎么连、怎么查，适合已经把库打开但还没把业务架构做成主线的架构师、流程负责人和数据治理同事。

2. ARIS里的业务架构建模层次：从业务能力到流程对象池的映射

ARIS和Visio最大的不同在于：Visio保存的是形状，ARIS保存的是对象。你在业务能力图上看到的每个能力方块，在ARIS对象池中都是一个有独立ID的数据库记录。业务架构的第一步不是画图，而是搞清楚哪些对象类型属于“业务架构”这个语义包，不然查询、追溯和合规检查都会变成在一堆图里捞数据。下面先给出一张常用对象类型映射表，再讲行为层连接和对象池机制。

2.1 ARIS业务架构语义层：六类对象构成的主干

常见做法是在一个业务架构数据库中维护六类对象：业务能力组、业务能力、价值流、业务对象、组织单元、业务服务。它们的关系是：能力组包含能力，价值流跨多个能力，组织单元被分配执行，业务服务支撑能力，业务对象是能力和流程之间的数据触点。

这里有个特别常见的误区：把“业务能力”当成流程中的一个阶段。业务能力回答“企业能做什么”，不回答“按什么顺序做”，所以能力图里不应该出现带箭头的流程顺序；端到端顺序是价值流的事。ARIS的业务能力图模型类型默认不展示连接器，目的就是防止把它画成流程图。

2.2 行为层连接：价值流、触发事件与流程如何串联动态视角

业务能力是静态的“能做什么”，价值流是动态的“怎么交付”。ARIS里价值流图是一套独立模型类型，包含价值流阶段和触发事件。把业务能力用“实现”连接器挂到价值流阶段上，表示“这个阶段落地需要哪些能力做支撑”，这是业务架构与流程层衔接的关键。

很多团队一上来就在ARIS中建EPC，结果业务说逻辑太细，IT说看不到系统边界，项目立刻沉掉。更稳的顺序是先定价值流层，再把EPC流程“分配”到价值流阶段。EPC里的事件，在价值流层对应“触发事件”。这两层不是父子结构，而是分配关系：一个价值流阶段可以分配多个流程，一个流程也可以被多个价值流阶段复用。

2.3 对象池与视图分离：理解ARIS“一个对象多处引用”的模型

对象池是ARIS导航器里的根存储区，所有模型实例都以对象的形式存在这个池中。在图中新建一个能力时，实际是先在对象池里创建对象，再在当前视图中生成一个引用。同一个业务能力对象可以出现在能力组图、价值流分配图和多张流程图上，改一次属性，全库同步。

理解这一点后，操作习惯必须改：不要每画一张图就新建同名对象，而是先搜索对象池有没有已存在的对象。ARIS的查找对象默认全库搜索，支持通配符匹配。对大型业务架构库，我一般把对象池分组与能力组结构做一一对应，一个能力组对应一个分组文件夹，这样后续授权和引用管理都更顺。对象池是主仓，图是投影，主仓乱了，画再漂亮的架构图也是在错误数据上做可视化。

3. 从空白库到第一张业务架构图：ARIS最小建模路径与连接器实操

ARIS用“数据库”保存模型，数据库又通过“方法过滤器”控制你能看到哪些模型类型。最直接的切入方式是从一个带业务架构预置过滤器的数据库开始，而不是选“全方法”再一个个关掉。过滤器决定了菜单里有哪些模型类型，看不到的类型自然不会被误建。下面按一个最小闭环走一遍：建库、建能力组、建能力、建价值流、连接器、再挂接流程层。

3.1 建库时怎么选择模型类型与过滤器

连接ARIS服务后，新建数据库时，系统会要求选择方法过滤器。优先选名称里带“业务架构”或“Business Architecture”的过滤器；如果版本里没有，再选“企业架构”并在管理后台启用业务能力建模相关选项。数据库命名不要直接叫“ARIS”，建议用“EA_能力与价值流_2025”这类带边界信息的名称，名称会出现在所有导出报表里，多库环境一下子就能分清。

建库后第一件事不是画图，而是进入管理面板把模型类型收敛到业务架构需要的那几类：业务能力图、价值流图、流程图、组织图、应用系统类型图。这一步的价值在于限定用户可见范围，避免同一库里混入大量细节流程和网络拓扑，影响后续查询和矩阵分析的正确性。

3.2 建立业务能力组与业务能力的最小步骤

ARIS里画图遵循“先建模型，再建对象，要么在图内新增对象，要么从对象池引用”的顺序。一个最小能力的操作序列是：在模型列表右键新建模型 -> 模型类型选“业务能力图” -> 命名“售后能力图” -> 打开模型 -> 从符号面板拖出“业务能力” -> 命名“工单接收”。此时这个对象会被放到对象池的“未分配对象”目录，后续可以拖进其他视图复用。

如果嫌鼠标点击太慢，改用ARIS Scripting（VBScript）批量建对象是更可靠的维护方式。下面的脚本常见于项目初始化阶段，从一个CSV文件读取能力清单，在指定分组下批量创建业务能力对象：

' ARIS 脚本示例：批量创建业务能力对象 ' 前置条件：ARIS Scripting 模块可用；cs 为Project实例引用 Dim row, capName, capPath Dim newObjDim, groupPath For Each row In csvRows capName = row(0) ' CSV 第一列：能力名称 capPath = row(1) ' CSV 第二列：对象池分组路径，格式如 "\能力组\运营能力" Set groupPath = cs.FindGroup(capPath) If groupPath Is Nothing Then MsgBox "分组不存在: " & capPath Exit For End If Set newObjDim = groupPath.CreateObjectByType("Business Capability", capName) newObjDim.Attribute("BT", "业务能力说明") = row(2) ' 这里可继续给“成熟度”“热度”等属性赋值 Next

代码里的CreateObjectByType第一个参数是对象类型的技术名称，在ARIS对象池中为Business Capability，第二个参数是对象名称；FindGroup按路径定位分组，避免生成“未分配对象”目录下的孤儿。实际生产环境会再包一层异常处理，并对“同名对象已存在”的情况做合并，而不是无脑新建。写脚本时要注意：Attribute("BT", "业务能力说明")中的BT是业务属性分组编码，不同版本对中文属性字段的编码略有差异，建议先手工建一个对象，查看对应属性的内部编码后再固化到脚本里。

3.3 连接器选型：实现、分配、触发与有向连接

业务架构涉及的连接器不多，但语义容易被混用。ARIS的连接器是带语义的连线，不是美术箭头。按实践中最常遇到的四个连接器来看：

实操建议是：同一张价值流图上，不要同时混用“有向连接”和“实现”两种连接器。阶段之间用有向连接形成主链，能力与阶段之间用“实现”。如果一张图里既挂能力又挂组织，通常说明模型已经过载，组织信息应该放到组织图里用“分配”表达。还有一种情况值得注意：连接器呈灰色不可用，大概率是首尾对象类型与该连接器定义不匹配，比如把“有向连接”接到了能力对象上。

3.4 把第一张图“接上”流程层

业务架构如果只停在能力图和价值流图，它只是静态目录。常见做法是把价值流阶段分配到EPC流程：在价值流阶段对象上右键 -> 分配 -> 流程，选择已有流程模型或新建。这个动作不会在价值流图上画线，而是在数据库里建立一对多引用关系。随后用ARIS的分配矩阵或影响分析，就能从价值流穿透到流程，再穿透到系统。

需要留意的是，ARIS默认一次只能分配一个流程对象。多个价值流阶段批量关联多条流程时，我一般用脚本或“批量编辑”功能，按“源对象路径-目标流程名-分配关系”的映射表做批处理。分配关系本质上也是一种连接器语义，批量导入一旦源或目标定位不准，会在错误分组里创建对象，跑完一定要复查“未分配对象”数量。

4. 用ARIS做业务架构的两类主干分析：孤儿对象检查与业务-IT对齐矩阵

连接器建完后，ARIS的分析价值才开始体现。业务架构能被业务负责人接受，不是靠某张图多漂亮，而是靠它自动回答问题：哪些能力没有流程支撑？哪些流程没被任何业务能力覆盖？哪些系统没有被业务服务关联？下面两类分析最常用，第一类偏数据质量，第二类偏架构决策。

4.1 用ARIS查询工具做“孤儿对象”覆盖度检查

ARIS内置查询工具，可以按对象类型、属性、引用数做过滤。对于业务架构库，最值得先跑的三个查询是：未分配对象查询、无流程引用的能力查询、无能力引用的流程查询。这三个查询能直接指出对象池里哪些节点是“孤儿”。

操作方法是：打开查询面板，新建查询，对象类型选“业务能力”，条件区添加“被使用次数等于0”。如果版本支持，再按图类型排除“业务能力图”本身的显示次数，只统计它在价值流、流程图中的应用。导出成Excel后按能力组做透视。容易忽略的是：ARIS的“被使用次数”统计对象在所有模型中的出现次数，同一张图里出现两次也会重复计数。如果某个能力只在能力图上出现、从没被价值流引用，业务上等于没有落地。因此光看次数不够，还要结合连接器类型过滤：只有存在“实现”关系的能力才算被价值流采用。

如果当前版本的查询面板不支持按连接器类型统计，退一步用分配矩阵：菜单“模型比较/影响分析”中，选择能力组作为行、价值流作为列，生成分配矩阵。矩阵里空行越多的能力组，就是细化流程时被跳过最多的部分，优先补。

4.2 按能力组看“业务覆盖热图”：如何挑候选能力做流程细化

覆盖度分析的输出是一张按能力组统计的流程覆盖表。常规操作是运行报表“业务能力覆盖度报告”，参数设成：行是能力组，列是“已分配EPC流程的模型数”，阈值设为1。某个能力组下已分配流程数量低于阈值时，在热图上标红。

要让这张热图被业务负责人接受，建议把“流程数量”换成“流程成熟度”，也就是给每个能力分配一个成熟度属性。属性编码建议：0=未建模，1=存在流程草图，2=EPC已建，3=已完成角色与系统分配。手工逐个设置分支太慢，更稳的做法是用脚本统计流程分配数量后回填属性：

Dim cap, val, link For Each cap In capObjList val = 0 For Each link In cap.AuxObjectTypes("Process") If Not link.Obj Is Nothing Then val = val + 1 Next If val = 0 Then cap.Attribute("BT", "成熟度") = 0 If val >= 1 And val < 3 Then cap.Attribute("BT", "成熟度") = 1 If val >= 3 Then cap.Attribute("BT", "成熟度") = 2 Next

AuxObjectTypes("Process")读取与当前能力对象存在分配关系的所有流程对象，link.Obj是实际流程引用，统计数量后按阈值写入“成熟度”属性。该脚本适合季度刷新，比人工维护成熟度属性省出大量时间。

4.3 业务-IT对齐矩阵：能力、业务服务、应用系统三角映射

最常用的一类分析是把业务架构与IT关联起来：业务能力 -> 业务服务 -> 应用系统。常见做法是为每个应用系统建“应用系统类型”对象，挂对应的业务服务，业务服务再“实现”业务能力。做影响分析时，选中一个业务能力作为受影响点，顺着“被谁实现”下钻到业务服务，再到应用系统，就能得到“该能力下线会影响哪些系统”的清单。

生成业务能力与应用系统的矩阵时，报表参数里的“聚合方式”建议选择“最大值”，不要用“平均值”。IT风险往往由一个低分能力决定，平均值会掩盖单点故障。矩阵结果输出到Excel后，直接作为跨部门评审的输入。

5. ARIS业务架构模型的质量治理：命名规范、校验规则与批量维护

一个业务架构库跑一年后，最常见的失控不是模型级联，而是对象池里出现四个“客户管理”：一个叫“客户管理”，一个叫“Customer Management”，一个叫“客户管理工作流”，一个叫“客户信息维护”。它们都是手工新建的结果。治理第一步是建命名规则，第二步把规则变成ARIS可执行的校验，第三步才是清理。

5.1 用校验规则自动拦截不符合业务架构规范的模型

ARIS的方式里，“方法过滤器”控制哪些对象和连接器可用，但它不检查命名。命名校验通常在“模型审查”或“模型校验器”中配置规则表达式。我一般先定三条基线：能力名称不允许包含“流程”二字；价值流阶段命名禁止连续两位数字；业务服务名称只允许中英文与空格。校验跑完后把结果导出为Excel，由架构师逐个确认是否修名或合并。

5.2 批量合并与替换：处理重复对象的最稳妥路径

清理重复对象时，不要先删后建。合并的正确操作是在源对象上下文菜单中选择“替换对象/合并对象”，目标对象指向规范对象。ARIS会保留所有图内引用指向新对象。如果源对象与目标对象存在属性差异，唯一需要谨慎的参数是“以目标属性为准”还是“保留源属性”。我通常选择保留新版本属性，避免销毁被业务确认过的字段。

5.3 定期导出对象池快照，建立“业务架构台账”

每月导出一次全库对象清单，字段包含对象类型、名称、所在分组、最后修改时间。导出后在Excel里按三个维度筛选：最近30天未修改、无连接器对象、能力名称含空格。这三个维度基本能暴露模型中大多数的退化信号，不需要额外脚本，ARIS报表引擎默认的“对象列表”报告就够用。如果团队已有数据仓库，这份导出物也可以作为次日分区的输入数据。

最后提醒一个粒度问题：如果某张业务能力图超过60个对象，说明该层级的粒度已不适合做主图分析，应该按能力组子域拆成多张图，每张控制在10到20个对象之间。对象过多时ARIS的图性能会明显下降，更重要的是，评估和评审时人的认知负担会失控。拆完图后重新跑一遍第4章的覆盖度矩阵，修正结果再落回对象池，这条闭环就真正转起来了。

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