EPC 事件驱动过程链

EPC 事件驱动过程链1EPC基本介绍事件驱动过程链（Event‐Driven Process Chain）是企业建模的核心模型。

EPC模型通过将商业过程中的静态资源（系统、组织、数据等）组织在一起形成一个能够完成特定任务或者活动（流程）的动态模型——体现了商业业务的增值过程。

企业建模中的其他各种模型通常只是在EPC所体现的基本信息和关系的不同呈现方式——视图。

EPC的核心是四种类型的对象：●事件Event●功能Function●规则Rule●资源Resource图1展示的是使用这四种对象组成的一个EPC模型片段。

2事件Event所谓事件，是指通过一个流程符号显示出来触发某种行为的消息或请求，通常也可理解为现实世界中某种状态的改变（如客户订单到达、产品设计完成等）。

一般有如下三种情况：●能够触发某个流程开始的外部改变（比如，客户订单到达）●流程内部处理状态的改变（比如，产品制造完毕）●带有外部影响的最终结果（比如，订单送到了客户的手中）借用软件工程的术语，事件迹象每个流程中每一步的前提条件或者后果。

所谓前提条件是指在一个活动能够进行之前必须出现或者已经发生了的事情，而后果就是一个活动的结果。

事件可以是某人为事件或者是计算机系统操作的结果。

每个流程的最终事件，除了作为本流程的一个重点外，还可以作为下一流程的触发事件，以这种方式就可以将流程的不同部分通过事件连起来，形成一个大的端到端流程图。

事件的描述，通常是采用一个“主谓词”形式的短语来表示一个状态，按计算机的方式就像：“什么‐怎么样”，比如“订单到达”，“成本计算完成”。

3功能Function功能表示业务流程中的某个行为或者完成特定任务的活动。

理想情况下，流程中的每一个活动都应该是增值过程，他们是进行流程分析和BPR的最终目标。

对应于事件，功能可能由人或者由计算机系统完成。

每个功能都包含有输入（信息或者物料），经过处理后创造出输出（不同的信息或者是产品），同时在处理过程中可能会消耗一定的资源。

要想在一个复杂模型中准确描述清楚某功能具体做什么不是一件简单的事情。

图1典型EPC流程图功能的描述，通常是采用一个“动宾”短语来表示一个状态，按计算机的方式就像：“完成‐什么”，比如：“输入订单”，‘计算成本’。

在下层的比较详细的模型图中，功能会表示成更明确，更好理解的活动（“输入订单”）。

这种模型中最好不要使用不明确的比较模糊的功能描述，要能让看这张模型图的人一眼就能看清你说的功能是干什么，尽量避免使用如“销售”之类的缩略词。

4事件驱动过程链EPC功能由一个或多个事件触发，事件激活功能而功能又会产生一个或多个事件。

事件依次触发更多的功能，这样依次下去就形成了一个事件和功能组成的链——事件驱动过程链（见图2）。

事实上，更确切地说事件驱动过程链称为事件驱动功能链应该更合适。

在实际的建模中当然不能总如图2所示的那么简单，这时我们就需要引入“决策”和“多流程路径”的概念。

改变业务流程的“决策”通常都是由功能完成的，但是为了能够表示可能产生的结果和多事件触发的情况，必须引入规则Rule，后面将有有关规则的详细解释。

对于使用过其他建模方法和建模功能的人员来讲最想知道的可能是在事件驱动过程链中引入“事件”的价值所在，因为其他的建模方法中大多直接使用一系列的功能来表现一个流程。

事件最常见的一种用法是串接功能。

5事件命名事件的命名需要做一些专门的解释。

在模型中对待事件的看法更事件在模型中出现的位置是有关系的，这里位置是指它们是出现在流程的开始，还是结尾或者是流程中间部分。

流程的开始事件，很明显是流程跟外部打交道的地方，也就是即将引发下面整个流程的外部世界的改变。

它将触发流程中第一个功能，他的名字通常会选择一个相对于整个流程有意义而不仅仅是针对紧接其后的第一个事件，这样阅读者能对整个流程是在讲什么样一个事情一目了然。

比如，“受到客户订单”对整个流程而言肯定要比“在邮箱中的信件”更有意义。

图2事件驱动过程链流程的结束事件表示整个流程（或者是某一模型中他所描述的那部分流程）的结束，或者这个结束事件同时作为另一个流程的开始事件。

对这样的事件选择一个对本模型和它所触发模型都有意义的事件会更好，而不比只限于表现引起这样一个事件的那个功能的结果。

在图2的示例中最后一个事件称为“成本计算完毕”，但是实际上，在完成“成本计算”后接下去还会有进一步的流程，所以业务选用“订单输入完毕”会更好地表现该流程和下一流程。

而在流程过程中出现的事件，用来连接功能的事件往往既是一个功能的结果又是一个下一功能的触发事件，那么此时该怎么办了，是表现结果还是说明下一个功能的起因？通常的做法是说明上一个功能的结果，在后面我们会看到，这样做对我们正确地描述功能和组织流程是有帮助的。

在单一流程，这里指没有很多控制分支的流程，事件的命名通常不会产生大的影响。

但有时事件会标志流程一个阶段的完成，此时，对这样的事件选择一个有意义的名字，就像在选择结束事件的名字一样，会更能说明问题。

现在，我们已经可以了解事件的命名是跟它所表现的流程有关的（见图3）。

在最初使用企业建模的时候，这也许会带来一定的困惑，但是如果你能坚持这些命名规则，那么在你建模后期你会发现错误会很少。

这样做的目的就是让你时刻在保证流程的合理性——通过名称约束。

也行，此时你已经开始感到困惑了，既然事件可能既是终结又是开始，那么在建模的时候是不是可以用单一的大模型来表现整个流程还是就像上面那样用一系列的小的、相对独立的模型共同表现一个流程了。

这是一个非常重要又有点无聊的问题，在后面会有进一步的讨论。

6为什么使用事件在前面曾经提到对于刚接触企业建模的人，尤其是那些曾经使用过其他的业务流程建模方法和工具的人而言，最想知道的是企业建模为每一个功能都相应的引入事件的意义何在。

为什么不如图4(a)所示的那样直接使用功能与功能相联？之所以要在功能与功能之间引入事件是有其原因的：●可以很方便地检查功能定义的正确性。

●能够很好地检查整个业务流程的正确性。

图3事件命名使用事件的第一个原因是，不允许功能直接相连。

通过在功能后面附加特定事件能够很好地检查功能是否合理定义。

在复杂模型中，有时候要搞清一个功能到底在做什么是件很头疼的事情，所以此时仔细检查这个功能所需要完成的任务以及触发这个功能的那个事件是很有帮助的。

其实，此时你可以这样问自己：真的是这个事件触发这个功能吗？这个功能是很自然的就发生了还是需要有更多的条件满足才会发生？然后再看紧接着这个功能的事件是否足够描述执行功能后所引起的各种改变的结果。

如果你不能说出该功能到底引起什么发生了改变，功能的定义也许就是错误的。

如果你发现该功能引起了许多东西发生了改变，此时，你应该仔细考虑是否所有的这些改变都是功能的结果，它们是完全由单一功能引起的，还是由几个功能（并行或是串行）引起的。

如果是数个功能的结果，就有必要检查这些功能的重要性和间隔粒度是否与模型中其他部分的功能相似。

然后再决定是否有必要将这些功能分开或是用一个子流程图来代替单一功能。

图4事件的作用使用事件的第二个原因是：仔细考虑功能引起的事件会使得业务流程中那些改变流程的决策变得更清楚。

同样，还是看图4(a)，这是一个由输入订单，检查订单和制造产品三种行为组成的链。

接着看图4(b)，此时在功能之间加入了事件，但是在功能“检查订单”之后的那个事件该称为什么了，称为“订单检查完毕”。

乍一看，这个事件好像是正确的，但是真是如此吗？在订单检查之后什么发生了改变？为什么要检查订单？只有在知道了为什么要检查订单之后功能才能对业务流程产生增值。

在刚刚接触企业建模时，经常会有此类不知道该怎样命名的错误。

在建模的过程中，我常常会问他们“为什么要检查订单”，大部分情况下他们也能回答（比如：为了查看订单是否可用），但是他们却并没有将这种理由体现到模型中去。

那么他们很明显的就忽略了“检查订单”这个功能的一种可能结果——订单不可用。

之所以会这样是因为，这个功能不仅仅执行“检查”这样一个行为，同时他还决定了下一步会发生何种结果，图4(c)示例的是一个正确的业务流程模型。

在图4(c)中可以看到，在功能“检查订单”后面多了一个规则“异或”，它将检查订单的结果分成了两种情况：订单可用与订单不可用，分别展示了检查这样一种行为可能发生的结果。

很多新手在流程建模时往往只考虑到了某种行为可能带来的部分好的结果，而对于这样一个可能的否定的结果往往会忽略，而这真是建模最容易导致错误的地方。

我想大部分人可能都碰到过这样一种情况，我们所建的流程一直运行的很好，直到有一天发生了一个问题而且在我们的流程模型中却怎么也找不到到底是该在哪儿发生。

此时，通常都是在建模的过程中考虑不全面造成的。

在图4的示例中我们假设“输入订单”只有一个结果：订单输入完毕，而在“检查订单”后认为会发生两种情况：订单有效与订单无效。

但是，对于你也许会发现，其实输入订单也可能发生两种结果，是否有必要也将他们表现出来了？这种情况应该根据你实际建模来决定的。

如果可能发生的这种结果对整个流程的运转而言不会产生关键的影响，那么此时就不一定要考虑。

因为考虑的因素越多就意味着所建的模型越复杂，当太多的时候会严重影响模型的可读性和可理解性。

记住建模原则：“不要对所有东西建模”，“知道什么时候建模已经足够”，“制定一个标准并坚守这个标准”。

事件的使用，在一定程度上给建模附加了一定的约束，这对我们建出那些真正发生的事件的模型是有帮助的。

同样，事情有利必有弊，事件的导入自然的使所建模型变得臃肿，精确描述也会有一定的困难。

所以在真正需要的时候，可以取消事件，而直接以功能相连。

7规则和业务流真实世界的业务流程很少只由串行的步骤组成的，多数情况下都要利用如并行分支、决策、多事件触发、混合流程等综合进行建模。

许多人也许对类似图5所示流程图会比较熟悉，企业建模使用了与此类似但一种更有效的方法来描述业务流程。

在图4(c)中我们看到检查订单有两种可能结果，但是对每一个具体单据而言他只可能出现一种情况，要么合格要么不合格。

要体现这种情况必须借助于类似图5所示的某种规则，为了满足利用EPC建模的目的需要对基本规则进行扩展，考虑如下几点：●每一个模型必须至少包含有一个开始事件和一个结束事件。

●功能与事件交替着出现。

●事件和功能永远只有一个输入和一个输出连接。

●流程路径使用规则进行分离与合并。

●功能的多事件触发也是通过规则表达。

●决策必须是由功能作出的。

●凡是作出了某种决策的功能，后面总是紧跟着规则。

●通过规则体现某个决策之后的各种可能路径。

●紧跟在规则之后的事件表示了决策的一种可能结果。

●规则不能同时有多个输入和多个输出。

图5标准流程图8规则Rule在企业建模的规则体系中，有三个基本的规则：与、或、异或。