| 转自:ZDNet 软件频道 作者:梁宝先
这次我想跟读者谈BPMS的架构、组成模块及其各自功能,让读者有全盘性的了解,希望能破除一般人对BPMS的迷思。
关于BPM,坊间有些迷思。例如,常听到有人说BPM = EAI + Workflow;PBMS只不过Workflow厂商的旧瓶新酒,换汤不换药,只要原来WfMS加上系统整合的Adaptors就变成BPMS;或是EAI厂商加上Activity Modeling的工具或者是Routing Engine重新包装一下,也可以称作BPMS 。
必也正名乎,我认为BPMS不只是如此,而是一个生命周期。顺着BPM生命周期了解使用者的操作情节(Scenario),是理解BPMS的组成全貌最好且最直觉的方式。在本文中,我借着介绍完整BPM生命周期,并从其中的每一步骤顺着介绍工作内容、使用到的工具及其功能、与用户的角色。最后,我会以一张完整的BPMS架构图,详细介绍其中组成的模块功能。
BPM:也要谈生命周期 (Life Cycle)
BPMS强调让企业可以灵敏反应外部环境的变动并快速变动企业内部的流程作业,所以生命周期所强调的是持续性改善与周而复始的循环。BPM生命周期另一个含意就是,它是BPMS工具导入的方法论 (Methodology)。BPMS解决方案最重要的核心就是方法论,它至少要包含思考哲理(Philosophy)、方法/步骤 (Methods / Steps )、与伴随的工具(Tools/Utilities)。因为没有任何两家的流程,组织,策略目标是全然一样的,因此怎样才能从策略目标规划到最后系统导入执行连贯一体,成功而有效地完成建置所依赖的才是合适的方法论。
目前各家BPM厂商所提出的生命周期不尽相同,乃是因为解决方案所诉求的产业或应用领域不同,所以有了各自强调与专注的重点。例如,IBM HoloSofx 提出的是:建构 (Create)、管理(Manage)、自动 (Automate)、协同 (Collaborate);Howard Smith & Peter Fingar在 『BPM - The Third Wave』一书所提出的是;建模 (Model)、布署 (Deploy)、与管理 (Manage);Italio 提出的是发掘 (Discovery)、建模 (Modeling)、支援(Supporting)、Monitoring (监控)、及Improvement (改善)。在此我会提出较为完整的流程步骤,但不见得每家BPM厂商的都符合,读者可参考下图-BPM生命周期。

阶段一、 流程发掘 (Discovery): 要导入BPM第一步骤当然要先清楚知道现行流程的作业方式与状况,尤其是流程内的讯息流 (Message flow)、事件流(Event flow) 、或控制流 (Control flow)。哪些流程可以自动化?哪些是人工流程?有哪些人参与?流程是在组织内部或外部被执行?BPMS在此步骤的主要特征是如何自动找出系统的商业逻辑。通常企业会聘请外部顾问师或领域专家来协助辅导,这个动作有人称为流程评估 (BPA, Business Process Assessment),评估范围可能涵盖策略与管理目标与流程的链接。同时企业也会配合导入一些管理的主题而作流程再造(BPR, Business Process Reengineering),例如评分计分卡 (BSC, Balance Score Card)、六个标准偏差 (Six Sigma) 、或 ISO 9000质量管理系统。
阶段二、 流程设计 (Design): 此阶段是一个包含四几个步骤的反复式的小循环 (Iterative mini-cycle):建模(Modeling)、 (分析Analyzing)、模拟 (Simulation)、重构(Redesigning) 流程。如前所述,面对外部的竞争压力与商机,为了让企业可以快速重构流程, 因此一些细致的流程变革(Fine-grained process change)只需利用此阶段的步骤就能作出实时的反应。
流程建模 所运用的工具称作Process Designer 通常包含三个模块:组织(Organization Chart)、流程图 (Activity Diagram) 、与窗体(e-Form)设计工具。它们分别对应流程中三个最重要的元素:人、活动与文件 (有兴趣的读者可参阅Process Modeling Conceptual Framework有关的资料,后续容我在适当机会再做介绍)。建模之后可以作执行动作前的分析与仿真来验证设计的流程是否正确合适或优化;此外它能还提供现行流程可能遇到的瓶颈信息,以避免执行后才发现问题进而导致很大的营运损失。如果分析模拟出来的结果并不满意,可以反复重构 流程直到产出满意的结果。分析指的是从流程定义的语意与理论上的推论分析,仿真则可设定机率变量与行为假设让系统自动跑出期望值或变异差数据,有些则仅提供自动执行(Animation)或手动逐步执行以观测流程行为。
此阶段BPMS的主要特征是图形化的接口,让非IT背景的使用者可藉由拖曳方式也能轻松组装或分解流程;此外运用流程资产(Process assets) 的观念,让流程定义隐含业界的最佳实务(Best practices)或流程样版 (Process Pattern),并且储存于流程仓储 (Process Repository)以供随时再利用 (reuse)。
阶段三、流程执行(Execution): 意指新上线的流程能被参与者顺利执行完成。负责控制执行的模块可称为工作流程引擎(Workflow Engine)或流程服务器(Process Server)。在此阶段BPMS主要的诉求是分布式交易(Distributed transaction)的管理,因为这些交易可能是复杂度高的跨巢状流程(Nested process)而且交织着新旧系统,甚至将既有的应用系统当成流程组件来执行。至于流程的执行者通常多是应用系统,可以不用人的参与(human intervention)而自动执行,也就是一般所称流程自动化 (BPA, Business Process Automation)。
此外,排程工具(Scheduler) 可以应用来设定自动启动流程的时间与周期频率。有些BPMS的产品会提供规则引擎 (Rule Engine)来负责商业规则判别与推理。此阶段另一个重要的特点就是在不用技术人员的参与下,依然可以让流程用户自行编辑与修改商业逻辑。例如,代理人的指派规则通常相当复杂,背后就需要有Rule-based的机制来支持。
流程布署(Deployment):意指将设计好的流程推出上线让所有参与者(Participant,可能是人,应用系统,或其他流程)来执行。这个步骤的主要特征就是能以最小的力气﹙effort﹚达成运算资源(Computing Resource)与组织人员的结合(binding),如事先整合应用系统组件(Application components)。
与人互动(Interaction):在流程的执行中很重要的就是与人的互动。并非所有流程都可以自动化,所以BPMS让人能管理自动流程与人工流程之间的接口。负责与人互动的接口称为工作项目的处理程序 (Workitem Handler)。有时候流程接口本身也是一个流程,例如动态加会签或在窗体输入下一步流程的分派。过去Workitem Handler相当简单,然而现在有倾向丰富化与细致化的趋势。必要的时候还能让使用者客制化或整合在不同系统的接口中。由于这个需求有快速提升的趋势,所以各家厂商纷纷提出丰富且个人化的流程入口网站(Personalized process Portal)。
在这篇文章中我会继续将最后两个阶段介绍完,并把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系统需由流程设计环境(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的方式,实时地追踪目前流程的进度或进行例外的处理以能做到修正或变动的因应。也就是说活动的监控对流程范例的执行提供了一个绩效量测的准则。最后透过上述工具使流程作到实时的修正达到优化让工作更有效率。 |