（业务管理）全局性业务架
构建模工作步骤
全局性业务架构建模工作步骤
执行业务建模以设计自己的业务时才增值。如果只是构造现有组织的图以得到系
统需求，则没有必要定义业务体系结构。
全局性业务架构建模的主要步骤如下：
1.生成业务体系结构的预览
业务体系结构概述于项目生命周期的早期创建，可能和建议的制定壹样早。它通
常是以图的形式，使用壹些非正式的表示法或演示图板技术进行描述。它代表业
务建模工作背后的意图和理念。起领导作用的业务流程分析人员通常和项目出资
方协作
2.生成业务体系结构概述。
概述图必须指示业务的主要元素及业务的环境，例如团队、业务工具和外部影响
源（例如，法规实体、合作伙伴和子市场）。概述图常常不着重于如此处所述的
整个业务体系结构。而是由大型工作（例如业务流程再造（BPR）项目）考虑整
个业务体系结构。业务体系结构的表示法于概念：业务体系结构中进行了描述。
考虑业务体系结构的目的及其目标用户是有用的。这确保了描述和表示业务体系
结构的方式适合于必须理解它的人员。目标用户能够分类到关心不同方面的不同
的组中。这些组中的每壹个组会对工作产品：业务体系结构文档的不同体系结构
视图感兴趣。
此时，业务体系结构概述是临时的第壹稿。不能基于此概述图作出任何承诺。初
始概述图能够作为工作产品：业务体系结构文档的壹部分包含，也能够不包含，
这取决于它给内容增添什么价值。
3.描述影响业务体系结构的因素
确定业务中的约束和趋势，以及业务的环境，它们可能对业务的结构或者工作方
式有重大影响。当定义业务体系结构时，必须分析这些因素，以确保业务能于合
理的时间内适应可能的变更，且抵抗住其他种类的影响。值得考虑的因素包括业
务策略和趋势，以及可能的将来事件，它们将影响组织的每壹部分或激进地变更
其重要的核心部分。另外，要考虑可能必须非常快速进行的变更，以及可能于将
来要施加的约束（这些约束可能改变业务的执行方式或带来新的机会），这壹点
很重要。
考虑发生这些事件或变更的可能性，且尝试使它们对业务的影响为人所见。壹旦
您了解了可能性和影响，您就能够划分这些因素的优先级，且作出关于如何处理
最高优先级问题的决策。处理每项变更的可用选项有：
•准备对变更作出快速响应。
•于变更已发生的情况下采取行动。
•将变更可能产生的影响降到最小。
•忽略变更发生的可能性。
将您的结果记录于工作产品：业务体系结构文档中关于体系结构推动因素和约束
的部分中。
4.概括高级组织
确定将构成组织的高级分组。它们能够是部门、事业部或业务单位，这取决于您
的组织使用的术语。当于业务分析模型（如果您有壹个非常大而且复杂的业务模
型）中确定壹组初始工作产品：业务系统时，这些高级分组能够用作输入。
如于工作产品：业务远景中所定义，考虑项目的范围。对于组织中于范围以外的
部分，没有必要探索它们的详细信息。另请参阅概念：对大型组织建模。
高级组织的草图应包含于业务体系结构文档的组织结构视图中。另请参阅指南：
业务体系结构文档中关于组织结构视图的部分。
5.识别业务系统
识别且简要描述正于建模的业务中的业务系统。业务系统其实只对大型的复杂业
务模型有用。根据业务建模场景以及您工作的范围，您可能决定完全不使用业务
系统。
业务系统代表组织内相对独立的能力。它定义了壹组职责，以及履行这些职责的
业务工作者、业务实体和业务事件。于这种方式下，业务系统是组织的结构部分
（例如壹个部门），但区别于于：业务系统内唯壹允许的交互是通过预定义的职
责。例如，考虑饭店里的服务窗口，或者带有服务目录的 IT支持部门。于这俩
个例子中，均有预定义的交互。例如，如果您走到饭店后面试着从厨房中某人处
取壹份菜，将发生什么情况？类似地，如果您请求计算机支持技术人员为您预订
航班，将发生什么情况？我们使用业务系统来禁止和其内部的业务工作者和业务
实体发生除指定交互以外的任何交互。这允许我们将大而复杂的业务模型进行分
区，以便能着重于详细描述模型的壹部分，而又能了解它于整体中的位置。
就哪些业务系统（如果存于）应包含于模型中进行讨论且达成壹致。壹些业务系
统可能于业务用例实现的环境中描述得不够详细。其他则可能提供重要输入或接
收输出，于这些情况下应将它们作为业务参和者进行建模。这意味着它们于正于
建模的业务之外。
您可能想要指示业务系统如何参和业务用例，而不显示业务系统内业务工作者和
业务实体之间的内部交互。如有必要，您能够“放大”业务系统，以将内部协作
作为业务用例的壹部分显示。
6.确定关键抽象－业务工作者和实体
对于到客户的关键接口以及（适用情况下）业务系统之间的关键接口，必须确定
主要工作产品：业务工作者和工作产品：业务实体。这仍对定义每个业务系统的
目的以及系统的能力有帮助。目的和能力的清晰定义有助于更好地理解业务系统
于业务用例实现中必须担当的角色。这样的定义仍有助于揭示业务系统必须和其
他业务系统交互的方式。
7.概述划分了优先级的业务用例实现
确定哪些工作产品：业务工作者和工作产品：业务实体参和执行每个划分了优先
级的业务用例。它们形成业务用例的业务用例实现。对于大而复杂的业务模型，
可用业务系统之间的交互表示业务用例的实现。
流程实现的草图应包含于业务体系结构文档的组织视图中。另请参阅指南：业务
体系结构文档中关于组织结构的部分。
8.定义分发（地理）视图
此视图描述部署业务的地理位置，以及组织结构和功能于这些位置上的分发。位
置视图对于评估时间和距离对业务流程的影响很有用。能够简化流程，或者能够
重构组织本身，以消除协调分布式任务的开销。而且，每个位置的唯壹属性（例
如法规、资源、可访问性或图像）能够影响于该处部署特定业务活动的决策。船
舶也能够视为位置。定义地理视图的流程由以下任务组成：
•确定执行业务活动的主要位置（国家／地区或城市）。
•确定这些位置之间的依赖关系和通信路径。
•将业务系统（从组织视图）映射到这些位置。
•评估每个位置关于于该处执行的业务活动的正面和负面的性质。
•评估分发对业务用例的总体影响。
•探索简化业务用例或者重构组织以消除开销的影响。
9.定义人力资源（工作者）和文化视图
定义业务的人力资源方面的流程包括以下任务：
•考虑组织内部存于的能力概要情况。定义将来必需的能力概要情况，或者定义
对现有概要情况的必要更改。将来的业务要求雇员独立性更强仍是更弱？他们需
要更高仍是更低的教育程度？
•讨论教育需要。定义俩个长期培训计划以克服当前能力和期望能力概要情况之
间的差别，以及和新的业务流程的引入关联联的所有初始培训需要。
•定义于适当的位置存于或者需要放于适当位置以提高技能水平的所有机制（奖
励结构、实习生计划、导师计划或其他刺激因素）。讨论每壹个的优缺点。
•探索由于职责的改变或加强沟通的需要而于组织中重新定位个人的可能性。
描述业务的文化方面的流程包括以下任务：
•确定文化的属性。
•确定这些属性中哪些对于组织是关键的，且必须保持原状。
•讨论哪些属性必须更改。
•确定已存于哪些机制来保持和发扬文化。讨论关于新的或更改的机制的设想。
•定义要为引入任何您认为必要的更改而采用的途径。
此步骤的结果应记录于业务体系结构文档的人力资源视图中。另请参阅指南：业
务体系结构文档中关于人力资源视图的部分。
10.评估结果
检查业务体系结构文档，验证您的工作是否处于正轨。请参阅核对表：业务体系
结构文档。
