企业架构助力业务流程管理

金晔

摘 要：本文阐述TOGAF业务架构梳理方法，描述业务架构梳理过程和注意点，总结通过业务全景图发现并优化业务流程问题的方法。

关键词：企业架构;业务架构;TOGAF;ARIS;业务全景图;流程管理;流程优化

1 引言

在制造业向数字化、智能化转型的背景下，某公司整车制造工程部与公司IT部门联合，在部门内部的两个科室（车身工艺和项目管理），开展了企业架构试点项目，并采用业界广泛使用的方法论TOGAF（The Open Group Architecture Framework）作为理论指导。在项目进行过程中，我们发现，企业架构的业务架构阶段，不但是TOGAF四大架构领域之首，是后续IT系统规划和实施的基础步骤;同时也为业务部门梳理、优化业务流程，进行流程再造提供了系统全面的方法论。

2 业务流程管理的痛点

业务流程是确保企业日常工作的正常开展、各部门的顺畅对接的基础和依据。因此，流程的好坏是衡量公司管理水平的一个最佳的标准。

在实际工作开展中，经常会遇到3类流程问题，导致工作无法顺利推进下去。

2.1 流程缺失

员工在执行某项工作时，找不到流程文件，员工就会按照各自的理解开展工作，无法保证最终交付物的质量。

2.2 流程内容重复，职责定义不一致

同一件事情，交付部门写在流程A中，接收部门写在流程B中，不同的流程中职责定义不同，就会造成问题扯皮推诿，影响解决效率。

2.3 流程不合理

有的流程看似洋洋洒洒写了十几页，却没有写清楚输入、输出、各部门职责和具体业务步骤，员工在实际执行时就会产生各种偏差。

在业务流程管理和优化上，不同岗位的需求是不一样的。作为高层管理者、业务流程架构师，通常希望从全局的角度横向扁平化地了解每一个流程之间的关系。而基层管理者和具体业务执行人，又需要从单个或某几个流程出发，纵向了解流程中各项任务的相关职责方、输入输出和操作方法。这就好比是盲人摸象，每个人摸到的部位都不一样，没有人能知道大象真正的样子。

如果能有一个统一的流程管理平台，既能从纵向展示单个流程的所有要素，又能从横向展示所有流程之间的关系，就能避免“盲人摸象”的发生，快速发现并解决以上3类问题。

3 企业架构在业务流程管理上的帮助

随着数字化转型工作的开展，企业架构成为公司、部门系统性管理提升的常用方法论。借助企业架构，能够构建业务与IT的桥梁，使IT与业务对齐，促进业务与IT的融合，助力数字化转型。在利用TOGAF方法论，为企业规划数字化系统的同时，我们发现，其业务架构的梳理和建模的过程，对业务流程本身也能够起到非常好的管理和展示作用。利用业务架构全景图，将业务需求结构化展示，部门管理层和业务架构师不但能轻易获得全局视角，对每一个流程之间的关系一目了然，还能深入下钻到每一个流程中，管理单个流程的所有要素。利用ARIS（企业架构工作常用工具软件），甚至可以将业务流程文件半结构化管理，使用数字化手段对组织、岗位、输入输出信息集等共用要素进行统一管理。

4 业务架构梳理和建模过程

按照TOGAF架构开发方法（图1），围绕需求管理，一共分八大步骤（不包括预备阶段）。本案的目的是形成业务与IT相结合的数字化系统规划蓝图，因此经过裁剪，选择了业务架构、信息架构两个阶段作为项目范围。本文将着重阐述业务架构部分的工作。

在实际操作的过程中，由于TOGAF对如何做业务架构没有详细的方法指南，我们通过本次试点项目，自己摸索总结了一套在ARIS软件中业务架构建模的具体执行方法和注意点。

4.1 确定企业愿景和价值链

不管是以公司产品为中心的传统价值链，还是以客户为中心的新价值链，在业务架构梳理的范围内，必须要有一个统一的价值链视图，以便对具体业务进行统一的归类，方便后续对标、合并。

以本案为例，由于是在整车制造工程部范围内的试点，因此我们首先重点讨论统一了整车制造工程部部门级的价值链视图（图2）。参考国际通用型流程架构，又将价值链分为核心业务、管理业务、支持业务三类。

在定义整车制造工程部价值链之前，我们曾试图参考美国生产力与质量中心（APQC）针对汽车行业的框架模型。但由于试点项目范围为整车制造工程内部，APQC定义的颗粒度就不够细了。因此，我们又参考了公司内部的整车开发流程，最终形成了整车制造工程部的价值链。

其中，整车制造工程部的核心业务有多个主要价值链：产品项目开发、非产品项目开发、样车试制、工厂运维支持等。以产品项目开发价值链为例，从头到尾又分为多个领域：同步工程、工艺开发、工艺验证、工装及设备实施、车型启动支持等。而项目管理、知识管理等都属于管理业务。

4.2 确定业务清单/矩阵

有了统一划分的价值链后，整车制造工程部内各个科室就能以此为依据，罗列出各自的业务，通常最终会形成一张业务清单。比如项目管理中包含哪些业务，工艺开发中的同步工程领域又包含哪些业务。

整车制造工程部的内部按照制造工艺的不同，划分成了不同的科室，各个科室分别管理自己的业务。在同一个价值链、领域中，各个科室有其特有的业务，也有相似或完全相同的业务。因此，我们使用了矩阵图法，将业务领域作为一个因素群（竖坐标），科室作为另一个因素群（横坐标），形成了業务矩阵（图3）。

这样，就可以在前期快速梳理出各个科室的业务，而不是将大量时间浪费在讨论不同科室业务的相似性上。将各科室的业务全部罗列出来后，后续可以再考虑优先在相同的领域中进行同类项的合并。比如，冲压和车身在造型审核领域，都有流程，就可以考虑整合为整车制造工程部部门级的造型审核流程。

4.3 确定业务描述图、业务流程图、任务描述图

罗列出各科室的所有业务后，还需要进一步梳理每个业务的各项要素进行梳理，比如流程中各组织/岗位的职责分工、输入/输出信息集、使用的系统等，并在ARIS软件中建模，称为业务描述图（图4）。此外，还需要通过业务流程图（图5），描绘每个业务中的任务，以及这些任务之间的关系。然后再对业务流程图（图5）进行细化，对每一个任务都进行详细的描述，形成任务描述图（图6）

这部分工作的目的，是要将文字描述型的流程文件转化为半结构化的模型，以便后期对更细颗粒度的流程要素进行同类项合并。同时，在上一步工作的业务矩阵中，不同科室间的业务究竟是否相似、能否合并，也必须在业务描述图、业务流程图、任务描述图都完成后，再进行对比后决定。

理论上说，只要完成业务描述图的梳理，就可以生成业务全景图，并不需要绘制业务流程图。然而，上文中已经提到，业务流程图是不同科室间业务合并的重要参考。且在实际操作中，我们发现，如果不绘制出业务流程图和任务描述图，业务描述图中的要素（如参与人、输入信息集等）很可能会与实际情况产生偏差（主要是遗漏）。因此，业务描述图、业务流程图、任务描述图这三者应该不断相互参考优化，确保与实际业务完全吻合。

4.4 生成业务全景图

最后，我们在ARIS软件中开发了脚本，通过识别业务描述图中共有的输入输出信息集，软件可以自动将业务前后连接起来，形成了一张网状的业务全景图（图7）。然后将流程文件覆盖到全景图上，就可以发现各种流程管理上的问题。

5 业务架构梳理的注意点

5.1 业务架构的工作团队

以车身工艺为例，光科室级的业务流程和工作指导文件就有几十个，部门级、公司级流程与之相关的还有几十个。业务架构梳理涉及到科室所有的业务，很难能有一个人对这些业务流程都非常熟悉。发现流程问题后，还需要相关负责人进行流程文件的修改和更新。

因此我们建议，业务架构的梳理需要由熟悉科室整体业务的管理者（如体系专员、各科室技术管理岗）和编写具体流程的专家共同参与，这样才能同时确保业务梳理的完整性和业务流程的正确性。

5.2 针对相同的业务、组织、岗位、输入输出信息集等流程要素，使用相同的描述

举个最简单的例子，由于历史原因，本公司内部对于产品工程师有很多表达形式，DRE、PE、SMT都可能指代产品工程师。如果不事先统一名称，在梳理的时候就可能“百花齐放“，导致系统无法识别这些相同的要素并自动整合。因此在开始梳理业务清单的过程中，通过团队分析和理解，对这些要素不断统一和优化。

5.3 清晰的价值链视图

在业务架构梳理的范围内，必须遵循从上至下的原则，首先要根据业务流分析归纳成确定一个清晰的价值链视图，再由各个科室进行具体业务的梳理。否则相同的业务可能被放到不同的业务领域中，业务划分的颗粒度和层级也容易产生比较大的差异，这些都不利于后期不同科室間业务的对标和整合。

5.4 业务清单的梳理以流程文件为基础，但也要考虑其他因素

在罗列业务清单的时候，我们最初是以流程文件为基础进行梳理。然而，在讨论的过程中，发现有一些业务是由外部门的拉动的，本部门并没有流程文件;有一些业务仅依靠操作指导书、模板等形式进行工作的标准化;甚至可能有个别新业务，还没有使用任何标准化文件进行规范。另外，现有的流程文件可能会存在重叠、颗粒度不一致等问题。因此，有必要从实际情况出发，对业务清单进行补充和调整。

5.5 业务流程图、任务描述图的梳理顺序

业务流程图和任务描述图的关系，也必须遵循从上至下的原则，先确定好业务流程，再进行流程内各个任务的描述。如果从一开始就梳理出每一个任务的详细信息，一旦业务流程需要更改、整合，后期的更改量就会很大。

5.6 信息集颗粒度尽量打散，剔除不必要的信息

在不同业务中，可能发生同一类信息集的颗粒度不一致的情况。如在图8中，产品数模由零件数模、焊点数模和涂胶数模组成。在业务A中，输入输出信息集可能是整个“产品数模”;而在业务B中，可能仅需要“零件数模”，那么就没有必要使用整个“产品数模”。通过事先对信息集的定义，软件可以自动识别这些情况，并做必要的合并或打散。因此，建议根据对业务的理解，将信息集颗粒度尽量打散，只列出对本业务来说必要的信息。

6 利用业务架构全景图发现流程问题

生成全景图后，接下来就可以对业务流程文件进行复核。我们采用的方法是，用不同的颜色代表不同的流程文件，根据对流程文件的分析，覆盖在全景图对应的业务上。由此可以发现以下3类问题：

（1）流程缺失：业务没有被流程覆盖。（2）流程冗余/越权：现有流程文件在全景图中没有可覆盖的区域。（3）流程重复：同一业务被多个流程覆盖。

另外，通过对输入输出信息集的追溯、业务流程图的对比，可以发现流程的潜在优化点：

（1）建议流程整合：同一个信息集经过多个流程定义和指导。（2）建议流程合并：同一业务领域中，业务流程图相似。

7 管理层的支持和坚持

考虑到涉及人员范围较广、工作量巨大，在开始梳理之前，必须先得到管理层的支持;在梳理的过程中，可以通过项目计划制定和跟踪、阶段性成果汇报，使管理层对整个梳理过程和收益有更清晰的了解，从而获得管理层的持续支持。

8 结语

TOGAF是一个非常好的企业架构框架，其业务架构的梳理全面诠释了业务的开展过程和需求，不但能为IT架构规划提供良好的基础，也为业务流程提供了一体化的展示、管理平台。此外，我们也将进行更深入的探索，尝试将业务架构作为部门知识管理、专业技术人员发展等方面的基础架构，推动业务快速实现数字化、智能化。

参考文献：

[1]TOGAF 9.1，The Open Group.

[2]Automotive Process Classification Framework Version 7.0.4，APQC.