前言

 BPM(企业流程管理,Business Process Management)技术 与 SOA (服务导向架构,Service Oriented Architecture)各自历经多年的发展,至今成为广为业界接受的技术架构。本文将从 BPM & SOA 的历史演进开始,深入浅出描述各标准的发展过程与彼此的关系,让读者轻松了解其应用范围与来龙去脉。另外,也将以相关标准组织的最新资料为基础,介绍当前制定中的新技术标准以及其演进。

 以流程为中心的管理思潮

 BPM 的范畴涵盖企业营运的各项构面,如研发、生产、行销、业务、人事、财务等企业营运活动,甚至往上下游扩及供应商与经销商,以及客户端的客服活动。诉求是企业应以流程化的思考方向,串连原本各自独立而未协调的营运活动,使串连后之营运活动成为具有步步加值效果的企业营运流程,并辅以各项管理手法使其落实运行,达成企业流程管理目标。

 1990年麻省理工学院 Hammer、Champy,哈佛大学 Davenport 等人,相继在学术刊物发表企业流程再造(Business Process Re-engineering)观念。1993年 Hammer  与 Champy 继续发表《企业再造》一书,强调 BPR 的重要性,以及 IT 技术在 BPR 过程的角色,使 BPR 成为当时的热潮。1997年,Hammer 又发表《企业再造之后》,宣告了流程化组织的必然性与重要性,并且预言 BPM/BPR 将改变人的工作方式。

 2003年,Smith 与 Fingar 发表《企业流程管理:第三波》,预言往后50年BPM仍将是企业经营的重要议题,也指出21世纪BPM的型态与新特征,并给予可行的教战守则,更罗列数十个企业运行BPM的实际案例与经验,让推行BPM的蓝图更加具体,使本书成为当年企管领域的畅销书,让BPM的风潮持续不灭。

 BPM的推行观念的改变与进程

 根据1993年《企业再造》一书的调查,当时企业推行 BPR/BPM 有高达5~7成的失败率。因为这么高的失败率,所以即使BPM是企业势必要面对的议题,也让他们把BPM的推展视为畏途,甚至抱持负面的看法。之后,整个BPM产业继续历经十几年的学习经验,与前仆后继的推行案例,不断从许多案例归纳关键的成功或失败因素,让推展BPM的蓝图逐渐浮现。在蓝图中,错误的作法逐步被修正,更多的BPM管理工具被界定(identified)出来而丰富了整个蓝图。众人慢慢认同,一个成功的BPM推行,是由以下金三角共同构成:

• 明确而有共识的组织流程规范

• 成熟的BPM软件系统架构与建置

• 企业主管与员工的认同与运行力

 从变动幅度来看,以往革命性大刀阔斧的BPR(流程再造)口号,已转变为温和的BPM(流程管理)实践。这种务实的作法,事实上是察觉到组织变革、流程思考企业文化的形成,需要一年到数年的时间;革命性的快速改变,若无充分的准备与良好管理体质,反而让企业乱了原有的脚步。所以一步一脚印的务实作法,渐渐获得认同。企业从核心BPM流程的落实与推行开始,逐步拓展到外围系统与业务伙伴,将可降低失败机率。

 而从管理成熟度来看,过去企业推行BPM,多半以流程计算机化这种短程目标为主,却忽略了BPM的终极目标在于「管理」,而非计算机技术,也非流程细节。所以高阶经营决策的需求常常被忽略而缺乏规划。而因为缺乏指导目标,在BPM的需求导引过程当中,企业员工常会无明确的指导目标,而以为工作流程计算机化就是把自己手边的工作巨细靡遗计算机化,而模糊了BPM的管理焦点。当这些与终极BPM管理目标无关的软件需求被列入计画讨论,不仅模糊焦点,也无形地垫高BPM的整体成本。

 事实上,BPM的管理可以归纳为以下几个可逐步提升的层次,从这些层次也可了解一般组织推行BPM的成长历程:

• 混沌阶段:没有明确的企业流程定义。

• 明文定义:具有书面的企业流程定义或标准作业程序,但没有根据正规的记号(notation),因此规则也许含混不清。

• 验证与共识形成:定义的企业流程,通过公司组织政策的验证,如质量政策,市场策略,管理原则,并获得高层决策通过,达成组织共识。

• 组织人员的流程准备:组织成员经过教育训练,认同组织制定的企业流程,并且具备运行的能力,包含专业基本技能的养成,并习惯流程化、信息化的作业方式。

• 企业本身的流程准备度:现行的企业组织架构,若与流程化的思考方式冲突,则应及早准备组织架构的调整,特别是毫无章法的职务与部门阶层架构(hierarchy)。良好的组织设置与权责划分,可以使流程定义更为精简易懂、便于遵循,也容易分析企业规则之间是否相互矛盾;同时可降低BPM软件系统的开发成本。

• 采用标准的企业流程表示法:使用一致的标准记号与格式来表达企业流程的内容。这里的标准记号应该是广被业界采用的格式,例如OMG在UML所定义的活动图(activity diagram)、BPMI (现已并入OMG) 组织所定义的BPMN,以及OASIS组织的BPEL。当然,企业流程的内容确实相当复杂,单一标准记号或格是通常只能描述部分构面,所以仍会有些构面暂时没有业界共同认可的记号或格式可供选用。

• 流程自动化:使用软件系统落实企业流程的运行流程。包括使用流程定义工具来定义企业流程内容,以及使用工作流程管理系统(WfMS ? workflow management system)来运行定义的企业流程。

• 进度监管:企业流程的运行进度可以被监看(monitored)与追踪管理。

• 流程集成:流程运行过程中,能进一步与其他内外部的流程互通,或者与既有应用系统(legacy system)交换资料,以延伸流程的触角,发挥综效。

• 流程绩效评量:企业流程的运行效能可以被测量(measured),并且透过公式计算,以报表呈现有意义的管理指针。

• 流程分析与仿真:持续搜集企业流程的运行资料,分析组织的流程运行瓶颈,并回馈到流程定义,调整业务的运行方式。另外,也根据历史资料与预测参数,透过仿真分析试算,比较不同流程调整方式所获得的改善程度。

• 智慧型流程环境:透过流程资料的资料采撷(data mining),主动分析流程统计数据,并回馈至流程系统。举例来说,在客服流程系统中,主动归纳顾客过去使用服务的频率与分布状况,归纳未来的趋势与规律(pattern),并根据现有流程环境的现况(如现有承接量,以及可动用的客服人力资源),自动调度客服人力分配策略,或向资源管理者建议客服人力调度策略。

 企业推展BPM不见得要立刻从IT工具的选择开始,前期的充分准备可缩短软件系统的分析时间。企业流程自动化之后,则有更多的管理辅助工具可供搭配,强化企业流程的运行绩效,提升企业的BPM成熟度。企业决策主管则可从以上层次分析,清楚得知达成不同层次的BPM进程,所能获得的管理效益,以及相对的BPM技术解决方案需求。

 BPM的技术现况与趋势

 BPM的其中一个技术构面是流程,它的IT技术解决方案的来源可追溯到1970年代晚期的文档传阅(routing)应用系统,主要目的是让商业文档与图象能在不同计算机间传递,使文档能从输入或扫描人员,传递到审核人员与其他角色。典型的应用流程包括保险公司的保单资料处理作业,或者银行的融资申请与签约作业。这些需求促成了工作流程(workflow)技术的崛起,而软件业也开始把工作流程技术应用到这类应用系统,成为核心组件。

 工作流程技术是中立的角色,随着不同应用领域的兴起而有不同的运用方式,在办公室自动化、公文系统、研发专案管理、制程管理、品保系统,或者客户服务系统等等,都可以查找工作流程技术扮演的重要角色。即便是面对企业管理领域被炒得火热的BPR/BPM,或者在IT/Web Services领域被当成新兴技术议题讨论的Web Services Orchestration、Choreography与企业流程运行语言(BPEL-Business Process Execution Language) ,只要详细分析其技术本质,仍不脱工作流程技术既有的范畴。这些当红的企管或技术名词,一旦底层抽离工作流程技术,就无法独立存在。

 然而,狭义的工作流程技术并不是推行BPM所需的IT技术的全部。早期工作流程技术与图象扫描与辨识技术结合,造就了文档图象流程系统。近年,工作流程从BPM领域切入,成为解决方案的重要一环;狭义的工作流程技术,历经多年汇流了多项技术元素,成为当代的BPM解决方案,主要特色如下:

• IT技术面:采用工作流程技术为主体,结合入口网站(Portal)、企业应用集成(EAI-Enterprise Application Integration)、报表与商业智慧(BI-Business Intelligent)工具、流程模型分析(process model analysis)、与仿真(simulation)技术。这些现成(COTS——commercial off-the-shelf)软件组件结合运作,可大幅降低信息系统的建置成本、时程,以及开发风险。 

• 管理活动面:可提供策略地图、平衡计分卡、六个标准差、TQM等管理活动的必要管理信息,搭配合适的管理决策工具呈现企业整体的BPM成效。

• 贴近特定产业的流程需求:每个产业都有其特有的企业经营模式与参考模型,如制造业、买卖业、医疗业、物流业等产业,都存在产业专属的流程模型与标准。像是 RosettaNet 替电子商务交易的询价、下单、交货、付款等流程作业,制定了日常实际应用的参考模型;而供应链协会(Supply Chain Council)则在供应炼与物流领域,制定SCOR流程运作模型(Supply Chain Operation Reference)。若流程定义工具能够直接提供这些参考模型的语意支持,或者提供现成可套用的流程样板(template),将可以减少开发这些特定产业应用所需的成本。

• 服务接取(access)面:解决方案能满足不同的使用者,如习惯大量资料输入作业的专业使用者、少量资料操作的一般使用者、偏重BPM绩效报表的主管,或者行动装置的使用者。也就是说,可提供不同的操作界面,如常规桌上型应用程序、Web Browser应用程序、PDA,或者Smart Phone等装置,给参与BPM系统的各种人员使用。

• 交互情境面:BPM技术解决方案需同时兼顾「人对程序」、「人对人协同作业」,以及「程序对程序」等交互情境。

 鉴往知来,BPM解决方案的风貌将持续纳入更多的元素而显得多样化,不管是因应管理哲学的革新、应用情境的延伸,或者新技术的崛起,只要有道理,没什么元素不可以纳入的。虽然没有一个独立的BPM产品能同时满足以上所有特色(事实上,企业BPM规划者也不见得要贪心得一次全部用上),但企业BPM架构规划者,仍可根据BPM导入步骤,按部就班先进行组织改革与训练,然后根据管理需求与现有的IT解决方案,参考本文所述的各项BPM特点,逐一评估挑选合适的IT模块,纳入为自己企业量身打造的BPM运行蓝图。

 由于BPM解决方案并不是一次到位的架设,而是持续多年的活动,因此整体BPM蓝图必须考虑分期开发,渐进导入的特性,建议BPM的IT规划者应参考本文稍后所提的SOA架构当成蓝图的基础。

 PM与工作流程相关标准组织

 想深层了解一个专业的产业发展,透过产业标准组织是一个不错的方式。对技术底层感兴趣的BPM技术人员来说,以下的列表可以作为探索的起点。

表一:现行BPM与工作流程技术标准一览表

WfMC是比较专注于工作流程的组织,它的WfMC workflow reference model是最常被引用的工作流程管理系统的参考模型。虽然WfMC的工作小组数目较少,但因为起步较早,旗下的XPDL与WfXML标准,有相当多的工作流程厂商支持。WfMC替工作流程的技术发展奠定了早期的基础,它界定了BPM与工作流程领域的大框架,也持续不断的推广BPM与工作流程,让众人清楚这个领域的体系与架构。

 OASIS与OMG的技术小组数目比较多,工作焦点也不仅限于狭义的工作流程技术。因为涵盖的范围较广,而且背后的支持厂商规模较大,所以整体影响力也较大。OASIS旗下的BPEL取自IBM、微软等公司,而ebXML则是OASIS与UN/CEFACT这两个组织共同成立的工作小组。OASIS藉由充沛的技术发展动能,为工作流程技术领域开拓更大的视野,在流程定义格式、流程运行层面,以及复杂的流程交互机制等领域,提供了宝贵的技术解决方案。

 OMG在BPM领域掌握了标准记号(notation),包含UML,以及从BPMI并进来的BPMN。同时,OMG也积极以塑模(model)的角度,切入工作流程定义的其他构面,如共通模型表示法BPDM、流程语意BSBR、组织架构OSM、业务规则BRM等等。OMG的强项之一就是在塑模(model)技术,它的UML广受软件领域接受;在BPM与工作流程的领域,OMG持续发展BPMN与等其他BPM各构面的塑模技术,未来将使BPM的其他构面(如业务规则,或组织架构)也能使用像UML或BPMN这种等级的表示记号来进行塑模,让复杂企业流程的塑模工作更加容易而清楚明确。

 W3C的强项在于Web领域,HTTP是最知名的代表作。而XML与Web Services是BPM在SOA领域的基础建设。其它相关的BPM技术,如WS-CAF, WS-RM, WS-CDL等等,都奠基于W3C的Web Services技术。

 OAGi、RosettaNet,以及Supply Chain Council,则是特定产业领域的代表。它们的贡献在于替特定产业界定共通的BPM运作规范,也就是说,定义属于他们产业特色的应用流程参考模型与共通的术语,让这个特定产业在推展BPM时,就有基本的需求大纲与基础架构,也让同产业体系内的厂商可以透过共通的产业模型与共通术语沟通,避免不同BPM应用系统之间生成各自为政而无法互通的障碍。如同前文所述,RosettaNet在电子商务领域已经广为人知,SCOR模型则在于物流领域。虽然OAGi在国内的能见度没有 RosettaNet高,但它涵盖的范围相当深远,号称涵盖电子商务、制造、物流、航太、汽车、医药、零售、能源等32种产业。以OAGi 9.0版为例,就涵盖61种流程情境(scenario definitions,像是订单管理、应收帐款、供应链集成、销售管理、客户服务)与434种商业文档(BODs, 像是订货单、维修单、捡货单、零件物料列表等,在流程当中传递的文档)的正规定义。

 表一列出的各项技术标准,是以标准组织为分类依据,我们再以其他观点来呈现其中几个重要技术标准,以便读者能够更清楚了解这些标准的定位。

表二:依功能分类的BPM/工作流程技术标准一览表

服务导向的企业

 过去几十年间,企业经营的焦点随着市场趋势而演化,60年代谈的是提升量产,70年代谈的是降低成本,80年代谈的是提升质量,90年代谈的是产品推出速度,而跨入21世纪,谈的是如何给客户更多样的服务。不管重心怎么改变,在21世纪之前,改善的重心仍落在产品实体;直到21世纪,重心已开始从产品延伸到购买产品的顾客,强调顾客是怎么样获得产品与服务。

为了提供多样化的服务,许多企业活动将被解构后再重组为新的营运模式,而这代表位居幕后支持的IT技术,必须能迅速配合这样的营运模式改变。也就是说,所有的IT技术与信息系统,都能够像变形虫一样,随时解构后再重组,在短时间内提供新营运模式所需的信息服务,这包括企业后台营运所需的信息系统,以及面对客户所需的前台服务界面。

 在十倍速的时代,企业无法等待。常规为了新营运模式而大规模更改 (而非重组) 信息系统的方式,过于牛步化无法满足要求。下一节提到的SOA架构,替服务导向的企业,提供了很好的解答。

 天生一对的企业流程管理(BPM)与服务导向架构(SOA)

 SOA的IT技术本质单纯而不难理解,个别的技术元素分别理解还算容易。对于SOA,大家联想到的就是Web Services,谈到Web Services,我们就直接脱口而出:WSDL、UDDI,以及SOAP,然后就是一系列的WS-*的技术标准。对很多人来说,只了解个别技术单元,并无法领会到SOA世界的美好。就好像只看得到调色盘的每个颜色,却看不到美丽动人的画作。所以,让我们先把无趣的技术名词摆一边,这无助于我们了解SOA的美好世界。

 首先,我们需先认识SOA世界里的企业流程运作方式,以及SOA的技术元素可以互相彼此串接而形成丰富的生态;如此,就可知道为什么BPM与SOA是天生一对——SOA 架构总存在美妙的答案来满足BPM变化多端的环境。

 一般来说,真实世界的BPM,具有以下的IT需求特征:

1. 它的运作是分布式的:多数企业流程都是由多个参与者共同运行,参与者可能来自不同办公室,甚至不同的地域区域,打破部门藩篱,甚至跨越公司的疆界;因此,跨因特网环境的应用系统支持,以及网络环境下的安全性,都必须列入考量。

2. 它可以进行工作协调与应用程序集成:大部分的企业流程并不只是运行单一业务功能,而是多个业务功能互相协调后的成果;因此,原本独立支持某项业务运作的应用系统,也必须跟其他业务的应用系统相互集成。

3. 它是动态的系统:企业流程中的各项元素经常动态改变。工作串连方式会随着环境改变、人员角色扮演会异动,工作的运行地点也会改变。因此,BPM环境中的应用程序模块,必须演化成快速适应变动的动态系统,可以轻易透过设置或配置的改变行为模式,甚至调整运行地点,以因应企业流程的变动。

4. 它的构成元素种类繁多而复杂:BPM系统内含分布于各模块的企业逻辑与规则、各种不同安装与监管模式的应用模块,以及众多模块之间的串联与相依关系设置。因此,BPM环境中的软件模块,需要让模块变得可以被BPM配置机制管理,这包含模块的启用停用、健康状态回报,以及系统安全政策,都应有一致的管理方式与技术标准。如此,整个复杂的BPM环境运作才可列入掌握而不致失控。

5. 它可以渐进式地成长:企业可以从最简单的BPM活动开始着手,再演进到成熟复杂的BPM系统;因此,整个系统架构必须能提供清楚的进步蓝图,允许企业按部就班投入IT资源,并逐渐提升BPM成熟度来运行BPM。

 以上五个特征,刚好可用来陪同我们探索SOA的技术世界。

 针对特征一,SOA技术架构可提供安全的网络传输与运行环境。主要技术有二:一是软件模块互相通讯时,所需的保密需求,这可由WS-Security来达成。另一个则是组织成员在环境中的权限控管方式,这可在SOA架构内,采用LDAP、集成单一帐号登录、PKI架构与数位签章等机制来配合。

 第二个特征引发的议题是SOA工作协调与应用系统集成。常规应用模块在SOA的世界里,可以采用SOA规定的服务界面(Services Interfaces)对外开放模块的功能。应用模块之间,透过SOA的服务界面标准互传资料,就是最简单的Web Services应用案例。此机制的主要意义在于:所有SOA内的应用模块,只要提供SOA的标准服务界面,就可以不受开发语言限制,互相调用或传递资料。这里的服务界面,讲的就是WSDL(Web Service Description Language);而SOAP(Simple Object Access Protocol)则是规定应用模块之间互相调用或互传资料时的封包格式。至于WSDL或SOAP的内容与格式应该长怎样,大部分技术人员可以让中介软件或者EAI系统代劳,透过Service Adaptor直接把常规应用模块包成Web Services模块,并不需烦恼内容的细节。

 第三个特征引发的议题是SOA的服务组合弹性与松散耦合(Loosely Couple)的特性。SOA内的应用模块若要能轻松改变组合方式,或者改变运行位置,就要藉助SOA的两个技术特性:松散耦合,以及UDDI(Universal Description, Discovery, and Integration)机制。因为松散耦合,所以某一模块抽离或添加系统,并不影响其他模块;因为有UDDI机制,所以新应用模块添加时,只需跟UDDI服务器登记新服务的界面与所在地点,即可被其他应用模块搜寻到,并且开始交互。因为有UDDI,所以当某项应用模块迁离位置,原有使用此应用模块的其他模块,可以透过UDDI查找服务的新位置,然后用新位置连结即可。这种特性满足「经常需要把服务节点拆解再重组」的BPM服务导向经营模式。

 第四个特征谈到的是可管理的SOA Web Services。这是系统管理与软件管理的议题,虽然当前没有统一的标准来规范管理软件与被管理模块的行为,但当前稍具知名度的SOA环境(特别是Application Server)多半会提供系统管理工具给系统管理员使用,协助管理SOA架构下所有列管模块的安装、移除、启动、停用,以及应用模块的状态监控与安全机制。

 第五个特征,谈的是SOA技术架构是模块化又可弹性串接的特性,在原有SOA环境添加新的技术模块,即可渐进式提升BPM技术的成熟度。我们从ZapThink整理的SOA蓝图中,可以得知达到不同SOA成熟阶段所需具备的SOA技术。举例来说,假设SOA有阶段实施的计划,那中间过程可以从「点对点集成」开始,进步到「提供松散耦合的服务」,再来是「稳定而可搜寻发现的服务」,接着「提供可组装与再利用的服务」,进而达到最终目标——「全公司的SOA」。当然,也可从蓝图中得知,不同SOA阶段所能获得的投资回报(ROI),刚开始只能是「降低应用程序的维护成本,达成点对点的集成」,接着是「透过服务再利用提升效率」,再来是「提升管理能见度与控制力」,最后才是「改善组织的敏捷度」。

 结语

 其实,即使是资深的BPM/SOA规划者,想要跟决策主管解释清楚SOA的博大精深以及其效用,都是很大的挑战。主要原因在于其中大大小小的技术条目,以及其相当复杂的关联。虽然大家都知道,画出一张易懂的图解,胜过千言万语,然而好图难求,幸好今年(2005)十月ZapThink公司推出一张令人深刻的SOA蓝图海报。这张呕心沥血之作,让人能从各个构面、由入门到高级,逐步探索SOA的世界,而且过目难忘,却又能够不失BPM/SOA技术的深度与完整度,实在非常难得,在此推荐这张海报作为延伸阅读,也当作本文的尾声。

 附注

 1. T.H. Davenport and J.E. Short, "The New Industrial Engineering: Information Technology and Business Process Redesign,", Sloan Management Review, pp. 11-2, Summer 1990. 

 2. Michael Hammer, “Reengineering Work: Don’t Automate, Obliterate ”, Harvard Business Review, Jul 1990. 

 3. Michael Hammer and James Champy, Reengineering the Corporation : A Manifesto for Business Revolution, Harpercollins, 1st ed.,May 1993. 

 4. Michael Hammer, Beyond Reengineering : How the Processed-Centered Organization is Changing Our Work and Our Lives, Collins, Sep 1997. 

 5. Howard Smith and Peter Fingar, Business Process Management: The Third Wave, Meghan-Kiffer Press, 1st edition, Jan 2003. 

 6. 参阅 Derek Miers, “BPM -- Too much BP, not enough of the M,” WfMC Workflow Handbook 2005, Future Strategies, 2005. 

 7. Web Services Orchestration,简单说法:使用流程技术来描述并控制Web Services的调用顺序,使多个?eb Services依序发生,运行事先安排的工作顺序。 

 8. Web Services Choreography,简单说法:在跨流程的情境中,以Web Services技术,描述流程个体之间的消息传递关系(多半是网状结构),以及流程状态的控制与查询方式。 

 9. 参阅本文「天生一对的BPM与SOA」小节 

 10. BPDM的目的在于提供可通用于多种流程塑模方法的中介模型(meta-model),以便不同塑模方法生成的流程定义可以互相转译。如UML、BPMN,或者其他厂商的专属表示法,能够对照到此中介模型,然后互相转译;或者让流程定义转译成底层的可运行格式,如BPEL原始码,乃至于J2EE或 .NET的运行码。 R. Schmelzer and J. Bloomberg, ZapThink's Service-Oriented Architecture Roadmap, URL: http://www.zapthink.com/report.html?id=ZTS-GI103