在谈完 BPM 相关标准之后，这次我想跟读者谈 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 生命周期。
图一、 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 的系统架构与各功能模块作个整理，让读者轻易了解，下回待续.
在这篇文章中我会继续将最后两个阶段介绍完，并把 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 的方式，实时地追踪目前流程的进度或进行例外的处理以能做到修正或变动的因应。也就是说活动的监控对流程范例的执行提供了一个绩效量测的准则。最后透过上述工具使流程作到实时的修正达到最佳化让工作更有效率。
文章来源:
http://www.01g.net/blog/default.asp?id=6