简介
业务流程是一组逻辑上相关(并且通常是顺序)的活动,它们使用组织的资源来提供已定义的结果以支持组织的目标 -
以产品或服务的形式交付价值,并通常交付给外部某一方(例如客户或合作伙伴)。该流程(可能分解为若干子流程)拥有相关的组织、资源和数据模型来捕获流程的所有方面,不仅包括执行角色、还包括所需/已用的资源、资源的所有权、责任制度、传入和传出任务的各项的定义等等。
这是对流程的非常具体的观点,因而我们采纳下列观点:业务流程是限定业务系统的业务用例的实现。因此,可以对业务流程应用与业务用例相同的分类法(请参阅指南:业务用例模型),即:
-
核心,针对那些提供价值链的面向外部的业务流程
-
管理,针对那些协调价值链的内部业务用例
-
支持,针对那些支持价值链的内部业务用例
我们也允许流程是事件驱动的,即:它们由业务执行过程中出现的条件(形成工件:业务事件)触发。
流程级别
在概念:对大型组织建模(下文用引号作了摘要)中,我们通过以两种详细级别来定义业务用例,来描述用于包容行政管理层以及业务流程所有者的需求的方法:
“一个模型针对行政管理人员,将包含一组显示了组织意向和目标的高级别的业务用例。 另一个模型针对流程所有者,将包含一组详细的用例,这组用例可帮助阐明组织内部需要如何运作。
对于每个高级别的业务用例,可以定义一个或多个代表组织中相同活动的详细业务用例......”
下图说明了用例的这一优化。
请注意,低级别的更详细的用例仍是高级别用例的那个业务系统的用例,即:它们仍代表该业务系统行为的黑匣视图。对于每个级别的用例,都有一个相对应的实现,我们可以称之为业务流程,因此可以将此类分析视为流程分解。
流程分解按某一详细级别分析业务流程和子流程,在这个详细级别上,构造子流程的活动图将是可行且有效的。流程分解的输入可来自第 1
层业务流程模型,该输入可能只是一些书面叙述,且通过实现关系与相应的第 1 层业务用例相关联。第 1
层流程是对业务系统功能的高级别描述,符合上述的行政管理层需求。
流程分解的结果是一组记载的第 2 层流程,这些流程作为业务用例实现捕获到业务分析模型中 - 在第 2 层,通常可以构造流程的活动图,因此根据经验,我们就有了三个级别的分解:第 1 层流程、第
2 层流程和活动(由活动节点组成)。有几个方法可以说明业务用例实现,我们在这里重点讲述活动图(请参阅 指南:业务分析模型中的图),因为活动图的形式和语义是大多数从事业务流程建模的业务分析员所熟悉的。此类模型在识别当前流程中存在的低效率情况时特别有用,并能由此识别自动化和业务变革的机遇。
SOMA 中映射到用例优化的业务流程分解。
IBM Global Business Services(GBS)面向服务的建模和体系结构(SOMA)是用来将业务与
IT 进行桥接的 SOA 方法。
在下列各图中,我们通过使用业务用例优化,将 SOMA
显示的流程分解结果映射为业务建模中的等价结果。我们包含这一映射是为了说明这两种方法实际上只是对相同的概念使用了不同的术语和表示法,最终将产生相同的结果,即:可以用来缩短自动化差距的一组业务流程描述,例如在面向服务的体系结构(SOA)启动计划中使用 IT 系统或服务。
上图以 SOMA 中所用的表示形式显示了流程到子流程的分解以及用例。子流程概念是一种方便的构造,用于表示以递归方式对流程作级别上更深入的优化,直至到达其组成部分(子流程)。
一旦我们到达可开始查看用户系统交互的级别时,我们停下来将该子流程标为叶级别的子流程。叶级别的子流程可能是系统用例的某一组合,例如:流程“订单”的叶级别子流程可能有“获取客户姓名”、“获取客户地址”和“获取订单商品”这三个用例。
下图显示了用 RUP 业务建模表示法表示的等价结构。
该结构显示了相同的三个级别,其中叶级别的子流程由活动图中的行动节点表示。
请注意:SOMA 作为最低级别的用例所显示的内容并不是我们这里定义的业务用例,它们作为业务用例实现中的相应活动节点(行动节点),是可能与 IT 系统进行交互的位置。SOMA 的用例因而更接近于应用程序开发中产生的用例,如
RUP 中所述(请参阅指南:从业务模型到系统)。
如果使用 UML 活动图来对业务流程建模,可以识别关键业务工作者、业务重大里程碑以及事件、任务顺序和相关性、已修改和交换的业务实体以及组织内部和组织之间的交互。流程模型应该具体确定需要发生“什么”,而不是任务应该“如何”执行,因为那是业务流程的一个方面,可随时间变化,特别是对业务环境或技术中的变更作出响应时。
|