作者:梁宾先

转载自:http://taiwan.cnet.com

在这篇文章中我会继续将最后两个阶段介绍完,并把 BPMS 的系统架构与各功能模块作个整理,让读者有全盘性的了解。

第四阶段、管理维护 (Administration) :

当流程上线后伴随产生了管理维护的问题,如例外状况的介入处理、组织人员的变更、流程重新分派、或流程版本升级的影响。在此,有个重要的模块称作流程活动监控 (BAM, Business Activity Monitoring) ,它可以随时回报流程的执行状态与过程,而且用户也可以设定流程要追踪的关卡并主动回报,具有预警功能并能随时掌握问题处理的时效。另外服务器的流量与执行监控及流程仓储的数据维护的效能也相当重要。

第五阶段、流程最佳化 (Optimization) :

流程改善 (Improvement) 是个持续性的活动,不断反复朝向最佳化迈进。流程测量 (Measurement) 能提供流程的执行绩效 (Performance) ; BPMS 的报表工具 (Reporting Tools) 能让企业对自己的组织行为充分了解作为持续改善的依据,如此方能策划出改善与最佳化的策略。流程分析 / 仿真着重在执行前的分析,例如自动侦测瓶颈 (bottleneck) 、死结 (deadlock) 与流程定义的不一致 (Consistence) ;而流程测量则是执行后实际资料的分析,可以清楚知道流程消耗时间与资源。这个阶段跟商业智慧 (BI, Business Intelligence) 的技术与主题相似性很高的,差异在 BPMS 可以自动纪录与收集流程相关的数据。尤其 BPMS 所附含的流程绩效仪表版 (Dashboard) ,它提供一个全面式的概观让主管简单掌握且一目了然哪些流程是在标准差内,哪些是在失控状态。当然这些报表,都是用户可以自行定义或查询的,不用 IT 人员的参与。

BPM > Workflow +EAI

相信从上述的介绍,读者可以清楚认识到 BPM 绝对大于 Workflow 加 EAI 。 BPM 的主要精神在于企业流程的管理,且主要的焦点在于业务性用户 (business users) 而非技术性用户 (technical users) ;在于流程弹性实时调整而非数据与应用系统的整合。所以仅是工作流程自动化加上 EAI 企业应用软件的转换机制是不足以的涵盖企业管理流程中所有必要的环节。例如尚有让管理主管能实时掌握流程成本效率 (cost/effective) 评量与流程绩效 (Performance) 管理,业务性用户可以轻易调整组装流程以提供客户最佳业务服务,等等。

我将上述中的工具整合起来,架构如图二所述:

BPMS 系统架构 (System Architecture)

BPMS 系统架构图

图二、 BPMS 系统架构图

一个完整的 BPMS 系统需由流程设计环境 (Process Design Environment) 、流程仓储或储存库 (Process Repository) 、流程服务器 (Process Server) 、用户执行环境 (User Execution Environment) 等主要元素所架构而成。

· 流程设计环境 (Process Design Environment)

流程设计环境扮演着流程设计阶段中最重要的流程建模工作,通常包含了「组织图」 (Organization chart) 、「电子化窗体」 (e-form) 、活动图 (Activity Diagram) 、与商业规则 (Business Rule) 等相关元素,并可透过直觉图形化的接口,协助流程设计者进行企业流程的建构。

组织图部份大多与组织目录服务系统 (Directory system) 相结合,以协助企业进行组织的调整与管理,如支持 LDAP 、 AD 等相关目录服务。而电子窗体指的是信息呈现的接口,一般而言可将应用系统的数据与流程相关的数据,透过所谓的电子窗体来展现,便于处理与人互动的部分,而呈现的方式可透过特定的工具快速的订制。在了解流程整体运作与规划中,透过活动图可清楚地规划与了解流程中的各个活动彼此的先后顺序与关联,并订定流程的运作条件与事件触发的相关动作,再透过结合商业逻辑( Business Rule )的方式,让企业更清楚流程的运作方式且易于修改,在采购流程中,若采购金额大于 100,000 台币者需签核至协理,其余仅需签至经理,就是个明显的例子。

流程仿真( Simulator )与流程设计分析( Analyzer ),则是透过流程数据的仿真得以事先验证流程执行时的结果与流程设计关联的分析(如在复杂的流程中,重要的流程元素或关联未建立),达到流程执行前事先的预防,并确认设计的流程是否正确合适或最佳化。

· 流程数据储存库 (Process Repository)

流程仓储包含了流程定义 (Process Definition) 、流程执行纪录 (Execution Log) 、与应用数据 (Application Data) 。流程定义包括了流程运作所有相关的数据,最明显的就是流程三要素:人、活动与文件,都纪录在流程定义中,藉由流程的规则引擎 (Rule Engine) 的参数即数据的变异数或是各个节点所制定的活动时间限制等定出合适的流程定义,最后透过流程服务器执行定义好的流程;流程执行纪录指的是流程执行过程中所有的纪录,有的 BPMS 将此部份内建于系统中,有的则是需另行将所需纪录抄写到数据库中;应用数据则是指在流程执行的过程中,所使用到其它系统的相关数据并随着流程纪录下来或有所关联,如请采购流程执行中,需依照既有 ERP 系统的相关数据进行逻辑判断,甚至需将其抄写至流程窗体中。而在此所指的应用性数据并没有只局限在内部数据库,也包含了根据流程的定义向组织外可能以 web service 的方式呼叫外部数据来应用。

· 流程引擎 / 服务器 (Process Engine/Server)

流程引擎是整个 BPMS 中最重要的一环,它负责正确无误地将流程在正确的时间传送给正确的人或系统,而由于流程的运作为企业营运的核心,因此能处理复杂且大量的流程工作是流程引擎所必备的条件。分布式交易 (Distributed transaction) 的管理与负载平衡( Load Balancing )将是考量的重点。

· 用户执行环境 (User Execution Environment )

这边所说的用户环境指的就是用户与流程沟通的接口。一般简易的用户接口多藉由待办事项( Work lists )让用户使用流程工作。而由于企业入口网站的风行,一个面面俱到的 BPM 产品通常透过 Web-based 接口,并加入口网站( Portal )的概念,提供所谓的流程入口网站接口( Process Portal )作为用户使用流程的沟通接口。如此除了可清楚地看到透过流程引擎指派而产生的的各项任务或工作事项 (work items) 外,并可结合其它入口网站与应用系统整合的机制,如使用协同工作功能促进员工彼此沟通与交流,像是公布栏、行事历或讨论区等。另外也可透过待办事项的启动 (trigger) 能够呼叫 (invoke) 与之相关的应用程序 (applications) 甚至根据各清楚定义的个别关卡 (activity) 自动以 web service 的方式来跨组织地呼叫 (invoke) 外部数据作交易 (transaction) 达到名副其实的 SOA 技术架构概念。

此外藉由流程网站接口用户 ( 通常指中阶以上主管或部门主管 ) 可利用行政管理工具 (Administrator Tools) 与报表工具 (Reporting Tool) 。就行政管理工具来说,进入流程数据储存库捞取流程定义的信息所作出的制式化报表可以清楚的知道员工的工作负荷量的轻重程度;而各种的统计量表包含热门排行、单位时间工作量统计、单位工作量统计、部门工作量统计、流程工作量统计、项目工作量统计提供管理者使用,使管理人员随时了解企业流程运作的各种情况。用户也能以 web service 的方式捞取应用数据作出动态分析。而流程的监控与管理 (Activity Monitor) ,亦可让用户或管理者透过 Web 的方式,实时地追踪目前流程的进度或进行例外的处理以能做到修正或变动的因应。也就是说活动的监控对流程范例的执行提供了一个绩效量测的准则。最后透过上述工具使流程作到实时的修正达到最佳化让工作更有效率。