现有ERP系统的设计，实际上采用的是一种基于功能分解的系统构造方式，将经过实践检验的“最佳业务”解决方案固化在ERP软件模块中。但现有的绝大多数ERP软件刚性太强，不能满足业务过程持续改进的需要。为此，一些国内外ERP厂商和研究人员从多个方面进行了积极的探索。如国际著名的ERP软件厂商BaaN提出了动态企业建模(Dynamic Enterprise Modelling，DEM)方法，其基本思想就是通过提供一套层次化的、可相互关联(通过一定的规则)的企业建模工具，在现有的企业参考模型(如业务功能模型、业务过程模型、业务机构模型等)的基础上进行定制和细化，并映射到功能广泛的BaaN ERP应用模块上，由此获得可执行可定制的ERP系统。利用DEM，可大大减少ERP系统构建的复杂性，并能在一定程度上增加ERP系统的柔性。但是，该方法只能允许对已有业务过程进行微调，仍然不能满足企业业务过程持续改进的需要。

国内的某些ERP软件厂商(如金蝶和用友)推出了自主版权的ERP应用平台。该平台在应用软件层与应用服务器平台层之间提供了一个业务基础软件平台层，并采用模型驱动体系结构(Mode Driven Architecture，MDA)的设计思想，提升了ERP系统构建的抽象层次，实现了ERP系统的快速构建。另外，由于采用了组件技术，在很大程度上提升了系统的可演化性，使ERP系统能够伴随企业的成长而不断演化。一种基于版本批量定制的ERP产品及实施服务的新构想。ERP系统实质上是一个嵌入式的工作流系统，业务过程中蕴涵的各业务活动及业务规则固化在ERP应用模块中，可以通过分离流程逻辑与功能实现，极大地增强ERP系统的柔性。SAP R/3的业务蓝图只是对现有的ERP产品中固化的业务过程的文档进行说明。IBM在旧金山项目中开发了一个用于辅助开发人员快速创建企业应用的层次化的框架体系结构。从现有的文献来看，虽然对基于组件的开发(Component Based Development，CBD)方法学及业务过程建模方法的研究较多，但从业务过程的角度探讨如何获取业务组件，进而驱动基于组件装配方式的ERP系统构造方面的研究却不多见。

随着现代企业对业务过程管理的重视，以及客户要求对订单执行等业务过程的了解日益增强，ERP系统的设计视角也应该转移到以业务过程为中心，探索并实施业务过程驱动的系统设计方法。采用业务过程驱动的ERP系统设计，使软件结构反映业务过程，有利于增强ERP系统的业务柔性。结合对象组件技术，对支持业务过程的相关业务类组件化，可进一步提高ERP系统的柔性及可演化性。这将在很大程度上克服现有ERP系统普遍存在的刚性太强的缺陷。

1 业务过程驱动的ERP系统组件化内涵

业务过程驱动的ERP系统组件化的内涵是：打破传统的基于功能分解的系统构造方法，以共性的企业业务过程为中心和出发点，对企业经营的业务过程进行抽象，通过层次化分解组成业务的各个子任务，直到能够充分地描述各个子任务。在业务过程分解的每一层次，根据组成业务过程的每个任务，分析并补充支持任务实现的各个业务对象类，并在后续的各个层次逐步细化设计，直到可根据现有的组件模型方便地组件化该层次的对象类。在分解业务过程的基础上，对组成模型的业务对象按照某种组件模型进行组件化。在组件组装平台工具的支持下，参照业务过程分解阶段获取的业务过程模型，以组件组装的方式创建可运行的ERP系统。

业务过程驱动的ERP系统组件化的最大特点是以业务过程为重点，并以此驱动ERP系统的需求获取、系统设计与构造。业务过程驱动的ERP系统组件化包括三个方面：①业务过程驱动的业务过程建模；②获取基于某种主流组件模型的业务组件；③基于业务过程模型构建组件化的ERP系统。

2 业务过程驱动的ERP系统业务过程建模

2.1 基本概念

定义1 业务功能：指从企业整体角度对所从事的经营活动的功能描述，阐述企业必须做什么(what)。同一类型的企业业务功能相似，且具有稳定性。如制造企业的业务功能包括采购、销售、制造、人力资源管理、财务管理等。

定义2 业务过程：指企业为了实现特定业务功能，需要组织一系列串行或并行的任务，每一项任务实现一项子功能，并为每个任务分配必须的资源。资源可以是时间、场所、部门、人员、资金等。业务过程阐述如何做(how)。如为了完成采购业务功能，可以把采购分解为采购需求获取、选择供应商、制定并发出采购订单、采购过程控制、采购货物接收、发票处理等任务。

定义3 业务事件：指驱动任务执行的激励。业务事件分为外部事件和内部事件两种，内部事件指由被建模的信息系统在执行过程中产生的事件；外部事件指系统外部产生的事件。例如，“采购货物到达”是外部事件，而“货物接收处理已完成”是内部事件。业务事件驱动业务任务的执行，任务执行过程中会产生新的业务事件。因此，业务过程的执行表现为事件和任务相交错的串行或并行的序列。

2.2 业务过程驱动的业务过程建模

业务过程驱动的业务过程建模，解决的是在业务层面上的建模问题，所建立的业务过程模型与具体平台技术实现无关。业务过程驱动的业务过程建模提供了一种获取ERP系统各类业务组件的自然的方法，业务过程模型是以业务过程视角构建组件化ERP系统的前提和基础。

2.2.1 业务过程驱动的业务过程建模层次与内容

企业的经营战略与经营目标最终由一系列具体的业务过程来体现。业务过程建模是实现有效地对业务过程管理与过程优化的前提和基础。业务过程驱动的业务过程建模包括三个层次，即业务功能层、业务过程层和业务任务层。

(1)业务功能层 从企业战略的层次，对企业应该做什么(what)的概括。企业必须在综合考虑企业的经营类型、特点、外部环境、发展战略的基础上，识别业务范围、功能，并确定其重要程度。

(2)业务过程层 从业务过程的层次，解决企业怎样做(how)的问题。业务功能最终由一系列的任务实现，任务执行产生事件，事件触发任务的执行。任务与相关的业务对象关联，任务的执行涉及资源的分配。因此，业务过程建模包括对任务、与任务相关的业务对象、业务事件、以及与任务相关资源的建模。

(3)业务任务层 从组成业务过程的具体任务的层次，解决针对具体任务的执行内容(do)的问题。

2.2.2 业务过程驱动的业务过程模型

常见的业务过程建模方法有Petri-Net，FlowChart，EPC，UML等。对业务过程驱动的ERP系统组件化而言，理想的建模方法应该既能阐述业务过程本身，又能支持与特定业务过程中各个任务相关联的业务对象及资源分配，而且也要有利于向业务对象类的组件化平滑过渡。可见，现有的Petri-Net，Flow Chart，EPC建模方法不能满足业务驱动的ERP系统组件化建模的需要。UML作为一种可扩充的建模语言，可用于系统的静态、动态建模。UML和EPC在业务过程建模方面各自的优势与不足，以现有的EPC建模方法为基础，引入了面向对象建模中的类、对象、继承、封装、消息等概念，以解决业务过程的建模问题。在现有研究工作的基础上，本文提出与业务过程驱动的ERP系统组件化相适应的建模方法元模型，如图1所示。

该模型所表达的语义简要解释如下：

业务功能由执行具体的业务过程来实现，一项业务功能可与多个业务过程相关联，一个业务过程也可参与并支持多项业务功能。业务对象对业务功能的实现提供支持。业务过程可以分解为多个业务任务，业务过程由外部业务事件触发。一个业务任务可以是复合任务，也可以是原子任务。原子任务是可以直接执行，不需再分的业务活动；复合任务是可进一步分解的业务任务，它通过提升任务的粒度简化对任务的管理。业务任务在执行过程中会产生多个业务事件，业务事件会触发新的业务任务的执行。业务事件触发业务任务的执行是通过触发规则决定的，触发规则决定了新业务任务的执行应满足的条件及执行方式(如并行执行、执行多条任务分支中的一支等)。业务任务由执行代理来执行，执行代理可以是执行具体任务的组织、人员角色或计算机应用程序等。业务任务的完成，是由相关的业务对象的功能(操作)实现的。业务对象类方法必须支持对业务事件的响应，从而要受业务事件影响。业务事件及业务任务会影响相关业务对象的状态。可以封装为业务组件的对象可以是业务任务、业务对象甚至是业务过程。根据组件实体类型(表达内容)的不同，业务组件可简单分为原子组件和复合组件。原子组件是不需进一步细化的组件，是复用的基本单位；复合组件是由成员组件构成的大粒度的可复用组件类型，其成员组件可以是原子组件，也可以是复合组件。业务组件的获得是建立在对业务过程、业务任务、业务对象的识别、概括与提炼的基础上，并对业务组件进行充分描述。建模阶段获得的业务组件与具体实现平台技术无关。

2.2.3 业务过程驱动的业务过程建模步骤

业务过程驱动的、与ERP系统组件化相适应的业务过程建模是一个自顶向下的、分层次的、迭代的、渐进的过程。这里分为业务功能规划、业务过程流程分析和业务任务分析三个阶段。

(1)业务功能规划 业务功能规划阶段解决ERP系统所支持的高层功能定位。传统的ERP系统主要从企业内部供应链的角度，对企业的采购、生产、销售：人力资源等各个方面进行集成管理。目前，越来越多的企业更加重视以持续提高顾客满意度为目标，通过整合企业内外部的各种资源，开展基于时间的竞争。因此，在业务功能规划阶段，应充分吸收先进的管理理念、管理方法，合理界定、配置ERP系统所覆盖的业务功能范围，构建ERP系统功能框架，阐明各功能之间的主要联系，标识出与各主要业务功能领域相关的领域对象，并对业务功能规划的结果进行归档。

(2)业务过程分析 针对业务功能规划阶段获得的每一项业务功能，从业务过程的角度对业务功能进行分析。分析步骤如下：

步骤1 给出业务过程中所涉及的业务任务列表。

步骤2 对每一项业务任务，识别触发该任务执行的业务事件，执行该任务需满足的前提条件，以及在该任务执行过程中所产生的业务事件。

步骤3 利用所得到的业务任务、业务事件、任务执行约束条件，绘制初步的业务过程流程模型。

步骤4 对业务过程进行优化，包括流程重组、业务柔性能力优化。流程的重组，即通过对现有业务过程进行分析、抽象，调整执行路径，去除不增值的业务活动及环节，以提高业务过程执行效率；业务柔性能力优化，即通过研究不同企业的业务过程特点，进行业务过程、业务任务的可变性设计及变体设计，增强ERP系统的行业定制能力。

步骤5 若某一业务任务需要进一步细化，则通过把该业务任务进一步分解为一系列的子任务，并按步骤2～4进行细化，直到认为业务任务不需再进一步细分为止。

步骤6 对分析结果进行归档。

(3)业务任务分析 业务任务分析是获得业务对象类的重要手段，是构造灵活的基于组件的ERP系统的基础性工作。该阶段在业务过程分析的基础上，对组成业务过程的各个业务任务进行深入分析。对每一业务任务，识别相关联的业务对象类，确定业务任务执行代理的类型、角色，识别业务对象类的方法，标志业务对象类需要持久化的相关信息及要求。如果必要，对业务对象的状态进行建模。最后，对业务任务分析的结果进行归档。

由于管理理念、管理方式、管理范围是动态变化的，基于业务过程驱动的ERP系统组件化建模方法所获得的业务模型也需要不断演化。基于业务过程的视角，便于分析和定位各类变化对现有业务支持能力造成的影响，而迭代的、渐进的分析方法支持对ERP系统模型的逐步完善。

3 ERP系统业务组件的分类与获取

软件组件是可独立开发、独立部署并通过特定的外部接口进行组装的软件单元。组件的接口定义了所有对外交互的信息，包括其对外提供的功能和要求的外部功能，从而显式地表达了组件对环境的依赖。

基于组件组装方式构造的ERP系统，极大地提高了系统本身的灵活性，支持ERP系统的快速定制，并允许以组件修改或替换的方式实现ERP系统的演化。ERP系统的组件化策略应在考虑主流分布式计算构架及现有组件模型共性的基础上，侧重于对领域知识与业务规则的封装。在业务过程建模阶段获得的模型可以作为组件化工作的起点。

3.1 业务组件的分类与描述

3.1.1 业务组件的分类

按照业务组件的粒度从小到大来划分，业务组件可分为业务对象类组件、业务任务类组件和业务过程类组件。

业务过程类组件的粒度最大，它对企业的核心业务过程提供支持，反映了企业信息系统以业务过程为核心的设计理念。业务过程对象类是构造业务过程框架的依据，在逻辑上通常由多个相互协作的业务任务类组件构成。业务过程组件通常都是复合组件，可尽量运用设计模式来改善业务过程组件的设计。

业务任务类组件提供对业务任务的封装。根据任务的复杂程度，这类组件可以是原子组件，也可能是复合组件，视业务任务的类型，参与完成业务任务的业务对象类型的数量及性质而定。

业务对象类组件提供对基础业务对象的封装。业务对象类组件与业务对象类之间既可能是一对一关系，也可以是一对多的关系。若干联系紧密的业务对象类可封装在一个业务对象类组件中。为了满足不同行业的业务特色，业务对象类组件的接口也可有不同实现(如对于BOM对象类组件，由于存在行业类型差别，其接口支持不同的实现以支持流程型BOM和离散型BOM)。根据业务对象类组件的通用性，还可进一步划分为业务基本对象类组件与业务支撑对象类组件。业务基本对象类组件封装了业务领域中支撑业务任务实现的基本概念实体对象，并提供了与外界交互的功能接口。业务支撑对象类组件通常是一族工具类组件。各类业务组件的例子如图2所示。

3.1.2 业务组件的描述

为了便于以组件组装的方式创建组件化的ERP系统，需要规范描述业务组件，以满足ERP系统组件化对基于接口信息装配的需求。与组件化信息系统相适应的组件模型描述如下：

业务组件：＝<组件规约，组件实现>

组件规约：＝<组件接口，组件结构>

组件接口：＝<对外提供的功能集合，对外请求的功能集合，接收的外部事件集合入口，对外发送的事件集合入口>

组件结构：＝<原子组件结构>|<复合组件结构>

原子组件结构：＝<组件实现的引用>

复合组件结构：＝<引用的组件类型集合，实例声明，实例连接，映射>

组件模型描述表明：接口是外部环境与组件交互的唯一途径，这里的组件接口不仅包括对外提供(provided)的功能集合，也包括对外请求(required)的功能集合，同时兼顾了组件对事件的需求描述，从而可以满足事件的发布及订阅处理。复合组件结构表明原子组件能够组装成大粒度的复合组件，满足组件框架(component-based framework)、组件子系统直至组件软件。

3.2 业务组件的获取策略

可购买合适的商业业务组件，如COTS(commercial off-the-shelf)组件，或基于主流的组件模型，在现有开发平台的支持下创建目标业务组件。主流的分布式计算组件标准有Microsoft的COM+，SUN的EJB，0MG的CCM等。COM+是在COM基础上发展起来的，主要用于Windows平台，是面向对象的组件模型标准，在融合了COM及MTS编程模型的同时，又增加了一些新特性。EJB是一个基于Java RMI(remote method invocation)的服务器端组件模型标准，与COM+相比，EJB支持更丰富的组件型，但EJB具有编程语言依赖性，只能运行在Java虚拟机之上。CCM(CORBA component model)是0MG在CORBA规范第三版中开发的一个组件模型标准，它吸取了COM+及EJB模型的优点，具有编程语言无关性，提供了丰富的服务器端组件框架，并支持到EJB的映射，但是CCM较COM+及EJB出现的时间都晚，其发展成熟尚需时日。

在创建业务组件时，可结合软件企业自身的市场定位、技术条件、平台策略等，选择合适的分布式对象组件标准，对各类业务对象进行封装、归档，建立可复用资产库，为基于组件装配方式的ERP系统快速开发奠定基础。

4 组件化ERP系统构建的体系结构框架

ERP系统本质上是把企业业务过程固化在软件中，从而实现对企业业务运作的支持。随着企业持续地调整、重构、优化，相应地要求提高ERP系统的业务柔性及系统重构能力。笔者认为，可以从三个方面改善ERP系统的构造：①基于业务过程的建模，降低ERP系统基本构造块的粒度，对基本构造块进行组件化，通过组装的方式构造ERP系统，通过增删或替换组件的方式实现ERP系统的演化；②提高ERP系统构造的抽象层次，从业务模型的角度实施行业化解决方案，采用业务平台技术，实现业务系统构造与特定技术平台的分离，实施模型驱动的ERP系统构造；③系统化地采用软件复用技术及软件产品线技术，建立企业参考模型及行业参考模型，建立组件库，按行业解决方案实施基于版本管理的ERP系统支持及演化管理。本文给出组件化ERP系统构建的体系结构框架，如图3所示。该体系结构框架由四部分构成：

(1)技术支持平台层技术支持平台层包括应用服务器及以下层次的各类技术平台，包括操作系统平台层、主流的中间件及应用开发平台、分布式数据库、各类应用协议和应用服务器等。技术支持平台层的各组成部分中，应用服务器的层次最高，它通过各种应用协议，支持对各种分布式数据库的透明访问，同时负责实现各类公共服务。

(2)业务架构平台层业务架构平台层位于技术支持平台层与ERP批量定制层之间，实现了软件系统的业务过程支持与软件实现技术的分离。从而实现了基于业务和管理的层面来构架和集成ERP系统的目的。业务基础平台提供了统一的组织机构、分工权限、资源要素、业务过程、信息处理、功能运行、业务调度等基础环境，对业务和管理的各项需求提供全方位的支持，以满足企业快速变化的、个性化的用户需求。业务架构平台层实现了ERP系统在业务层面的真正集成，并在持续完善的业务过程中保持高效的业务协作。通过进一步与资产库及相关工具集的结合，对实现基于版本批量定制的ERP系统构造提供平台支持。

(3)资产库及资产库工具集资产库包括组件库及企业参考模型库。企业参考模型库包括企业通用参考模型和特定行业参考模型，这些参考模型是以业务过程模型为中心组织的，并在充分考虑业务过程驱动的ERP系统组件化需要的基础上建立的。组件库是在对业务过程进行建模的基础上，对获得的组件化对象(如业务对象、业务任务、业务过程等)按照某种组件模型，在考虑复用而进行变型设计的基础上建立的。对组件及模型库的元数据、组件及模型的相关文档也进行存储和分类索引，并通过资产工具集访问及维护。资产库工具集包括建模工具、仿真工具、配置工具和维护工具等，这些工具负责完成对资产库的日常维护、组件演化、访问控制、特定行业业务解决方案的配置及优化、过程驱动的特定企业业务模型适配及仿真等。

(4)ERP批量定制层该层次由特定行业企业信息系统解决方案构成，是在资产库及业务构架平台的支持下，针对具体行业的批量定制型ERP系统的具体实现。

5 结束语

企业经营目标的实现最终是由各项业务过程体现的，不同类型企业间的业务过程既有共性又有差异。从业务过程驱动的ERP系统建模出发，面向不同行业，实现可批量定制的组件化ERP系统，增强ERP系统的可演化性及ERP系统与企业的适配性。本文从业务过程的视角出发，提出了业务过程驱动的ERP系统组件化的研究框架，为解决目前ERP系统的整体式构架所带来的问题提供了一种新思路。