BPM是与非-什么是BPM,如何识别是否是BPM产品,以及如何选择BPM产品(2)

如何辨别一个产品是否BPM产品

由BPM的设计目标——业务流程管理决定,BPM不仅仅是一个IT工具,它必然要和企业运营紧密结合在一起,是企业管理运营的直接映射,而不需要等待把业务需求翻译为IT需求再用技术定制实现的周期。企业需要的是可以直接将业务变成可执行流程的技术,需要由业务人员直接建立、管理、优化流程,希望流程管理系统建设后可以直接在执行过程中监控企业绩效,更希望企业的战略意图可以直接与具体的执行层联系起来。

要满足这样的需求,BPM工具必须彻头彻尾的面向业务人员而不是IT人员,用业务语言去建模而不是IT语言,由业务人员驱动BPM的建设而不是IT驱动。换句话说,如果有一个所谓的BPM产品,但它被设计为面向IT人员,靠IT人员定制开发而不是业务人员建模、其设计无法对接战略层和执行层(最明显的判断是:是否能够说明和测量流程中的某一个活动针对哪个战略目标,某个实例贡献值如何);或者它被设计为针对业务执行问题(需求从基层来)而不是业务管理本身问题(需求必须自顶向下)的,即可怀疑为伪BPM或说是不完整的BPM。

最容易混淆的便是工作流与BPM,OA与BPM,ERP与BPM。首先,不论是OA还是工作流,其设计目标并不是管理业务而是通过IT手段协调和分配工作任务和资源,提升工作效率、优化资源利用率和工作规范化。其次,ERP是面向工作流的,它实现了信息的最小冗余和最大共享,将企业内部所有资源整合在一起,对采购、生产、成本、库存、分销、运输、财务、人力资源进行规划,从而达到最佳资源组合,取得最佳效益。换言之,不论是OA也好,工作流也好,ERP也罢,它们都关注在执行层面。

一方面,其活动或操作的粒度是针对业务人员执行的具体工作任务,并不追究该工作任务与企业整体业务之间的横向关联和企业战略目标之间的纵向关联。其突出的特点是直接面对最为具体的业务操作,但无法说明和测量该业务操作指向哪一个企业战略目标,更无法衡量该业务操作向特定的企业价值贡献了多少指标。其项目特点是不需要端到端的流程梳理(自顶向下定义,纵、横向贯通)作为必要的需求输入,只需要某个局部的需求便可完成项目。

另一方面,其技术基础针对的是IT人员,必须将流程的业务含义转化为IT含义,由IT人员进行建模和实施。其突出的特点是,在项目中,业务人员只能够承担需求提供者和软件使用者这两个角色,而无法承担流程建模者、流程监控者、流程改进者、流程管理者等角色。

这些非针对BPM的设计带来两个明显的局限,其一,系统的建立尽管使得工作效率有所提高,但对于衡量企业的整体绩效来说,每个这些系统内容是一个黑盒子,无法在执行过程中监控并得到企业整体绩效乃至战略的反馈;其二,由于架构和设计的方向不同,业务人员被排除在流程的建立、管理、监控、调整之外,必须通过IT人员来进行。这使得业务敏捷成了一句空话。

总结下来,辨别一个产品是否是真正的BPM产品,可以从以下几个关键特征出发:

  1. 该产品是否有着极强的导向性à面向价值增值(战略目标)而非仅仅实现当前业务。

此特征意味着每个业务流程和每个活动都可以明确的指出其针对的战略目标,并可以用指标衡量其价值贡献(相对于战略目标)。BPM的建设成功与否可以用企业最为熟悉的商业价值评估体系来评判并优化调整。

如果一个所谓BPM产品不能够直接实时的提供业务执行时对战略目标的贡献值,仅能够提供IT级别的运行测量结果,或者只能通过滞后的报表统计,再通过诸如BI工具等来估算业务效益。它将无法支持BPM的面向价值。

  1. 该产品是否以端到端的业务流程为中心而非仅仅用于实现局部业务

此特征意味着流程梳理是BPM建设的前提条件。BPM实施的同时必然带有流程梳理、测量、优化或改造等活动,基于片断化的,局限于部门内部的所谓BPM建设难以获得BPM带来的价值。

如果一个所谓的BPM产品从建模到实施到管理,仅需要或仅支持局部的业务需求,在必要时,只能通过其它技术手段(如WebService、JMS、Rest)来与其它部门或系统做散列的点状集成,而不是像真正的BPM那样需要端到端的流程梳理结果作为必要条件,在业务流程建模过程中没有所谓的“与其它集成”的明显概念,所有活动都是端到端流程中一个自然的节点。那么,它将无法支持BPM中的战略落地。

  1. 该产品是否由业务人员驱动而非IT驱动

此特征这意味着业务人员将从单一被动的需求提供者和业务流程执行者的角色增加为更积极主动的业务流程构建者、业务流程监控者、业务优化者和业务流程管理者角色。业务人员和IT人员将密切配合起来。

如果一个所谓的BPM产品仅面向IT人员,业务人员不能深度参与业务流程建设,只能将业务需求翻译为IT语言再实现,那么很难做到IT资产与真实业务流程的高度同步。该产品将无法支持BPM的业务监控、改进、优化等管理需求。

  1. 该产品的流程实现是否支持粗粒度的服务编排而非从头定制开发

此特征意味着BPM产品必须支持通过编排粗粒度的服务集成并整合利用企业资产(包括IT和非IT),以快速、敏捷的建设和变更业务流程,从而有效支持业务敏捷和业务改造。

如果一个所谓的BPM产品在项目中需要大量的定制开发,其架构不支持服务编排或者只能通过外挂的标准协议调用服务而不是在架构内形成一个有机的整体,那么它将无法支持业务敏捷和快速的业务改进。就目前的IT界的技术来看,产品是否全面支持SOA甚至直接架构在SOA上,是判断是否符合此特征的重要依据。

 

BPM是与非-什么是BPM,如何识别是否是BPM产品,以及如何选择BPM产品(1)

BPM方兴未艾,然而眼见市场上BPM产品一片混乱,你方唱罢我上场,各色产品、各种概念粉墨登场。虽然百花齐放,但真正有志于实施BPM的客户却被这乱花迷了眼,实在搞不清楚BPM该怎么去做,最终失去对BPM的信心和关注。这于BPM的发展并无益处。由是撰写此文,从BPM的基本概念出发,讲解了一些如何辨别和选择BPM产品的建议。希望能为BPM市场的进一步发展带来一点帮助。

什么是BPM

BPM(Business Process Management)其实并不是近期出现的新概念,从本质上说,BPM并不是一个IT术语,更不是因技术的发展而起源的,相反,BPM至始至终都是管理学术语和概念。BPM的核心是通过对企业运营的业务流程的梳理、改造、监控、优化来获得利益的最大化。要达到这一目的,必须把企业资源和管理方法从纵向的战略到业务的执行打通,使得企业业务流程当中每一个活动都能够明确的指向特定的战略目标并且可以测量和评估,从而获得改进的方向;同时必须把企业资源和管理方法从横向的各部门、职能甚至第三方职能整合为一个有机的整体,使得企业业务流程可以以端到端的方式,即从业务目标的提出(业务流程建立)到业务执行结果(业务活动的测量),来管理企业的运营以获得最大的利益。

而BPM软件产品则是针对这种管理方式的一种构造工具——一种令人异常兴奋的工具,可提供更快更好更便宜的解决方案。它致力于将IT 与业务之间的对话变成一种用于构建解决方案的交互式连续迭代方法。 BPM将IT会话转变成业务语言——解决IT长期存在的一个问题:业务-IT之间的沟通障碍,帮助企业改进效率、使流程可视化、使流程敏捷化并帮助企业进行业务变革。

可见,BPM不是因为IT技术而出现的,正相反,是因为有了BPM这样的管理理论,而企业又希望通过IT工具来帮助他们实施BPM管理,才相应的出现了BPM软件。现在普遍的把BPM理解为一个IT术语,更多的理解为一类IT产品,这样的理解是不全面的。在BPM里,业务应当占据主导地位,软件或说技术是辅助地位。从业务上说,完整的BPM应该覆盖企业战略管理、战略流程定义、业务构建、业务流程定义、业务服务定义和编排、业务执行和监控、业务流程优化改进以及战略调整等等几乎企业管理的方方面面。从IT角度说,BPM所集成的一系列软件和专业技术要能够支持上述的业务生命周期使之落地。最重要的是,这些软件和专业技术必须是面向业务人员的。即,BPM的实施将由业务来驱动BPM的建设,由业务人员来主导整个业务流程管理体系的建立而不是由IT来驱动。

当前BPM市场和产品的混乱

与其它革命性的IT变革一样,我们需要从方法、架构和实现技术三个方面去理解和掌握BPM产品。方法对应产品的设计目标——企业的管理理论和相应的实施方法论;架构表示软件产品的设计如何匹配该设计目标;实现技术则表示采用何种IT技术去实现相应的架构设计。三者缺一不可,然而长久以来,人们习惯于用实现技术去分辨和解释BPM,以至于到现在为止,人们仍然无法正确的理解BPM。由此也造成了BPM市场和产品的混乱。

其实这个问题并不是BPM独有的。举例来说,作者在培训面向对象的分析和设计方法时发现,相当大比例的程序员,哪怕他已经工作了很多年,哪怕他拥有丰富的项目经验,也精通一门或多门面向对象的语言,但他们并没有真正的掌握面向对象的方法。掌握面向对象方法的关键不在于是否采用了面向对象的语言和工具(如UML或java),也不在于是否掌握了面向对象的编程技巧(如设计模式),而是,你是否真的在用面向对象的思维去思考,从需求,到分析设计,到编码实现。它体现在项目的整个过程而不是仅仅是结果的表象。

SOA也面临同样的问题。是否掌握了SOA,其关键不在于是否采用了支持SOA的应用架构(如WebSphere Application Server),也不在于是否把某些代码逻辑封装成了符合SOA规范的服务(如Webservice)。而是,你是否真的采用面向服务的方法去分析需求、设计架构、抽取服务、把业务服务化,从项目开始到结束的整个过程都应该面向服务的,而不仅仅是产出物。

回到BPM产品上来,如果仅从实现技术去理解,人们就会陷入这样的混乱: BPM与工作流有什么差别?都有流程引擎,都可以自动化运行,都有流程编排器,也都能对流程进行监控。凭什么工作流就不是BPM?如果辩解说BPM能比工作流能做更多的事,比如服务编排和集成,工作流会说只要是开放的通讯标准,不论是WebService还是JMS,工作流同样可以集成第三方服务,BPM可以做的,工作流同样可以做到,无非只是技术实现的方式不一样而已,并不是本质的差别。你还可以争辩说BPM是面向业务的,而工作流不是,但你如何解释什么是业务?难道BPM里一个审批申请的活动是业务,工作流里一个审批申请活动就不是业务?什么道理?

同样的混乱还有很多,例如ERP会争辩说ERP也有其内部的工作流,也可以把客户的业务流转起来,ERP也是BPM;办公协同类软件也会争辩说BPM不就是资源共享和工作协作么?从这个角度说,我也是BPM,有何不可?

而客户就更加混乱了。从通过流程来实现一项业务的实际需求出发,上述的任何一门技术似乎都可以实现他们的需求,怎么选择?何况凡是带个流的,都说自己是BPM,似乎谁谁也差不到哪里去。至于那些花了大价钱进行了流程梳理的企业,费了牛大的劲梳理出来的流程却停留在Visio里,写在word文档里,有什么用?以至于许多客户最终消极起来:我只知道我得审批信用卡,我得处理投诉,只要管用好用就行,只要能解决我现在的问题,是不是BPM又有何妨,who care?

看,一旦陷入这样的技术细节比较,就是比上个三天三夜,吵个天翻地覆也不会有结果,市场继续混乱,产品继续混乱,客户继续混乱……

 

甄别产品类型应从方法和架构入手

要辨别一个产品是否是BPM产品,我们还是得回到方法和架构上来。正本清源,我们得承认这样一个事实:业务驱动架构,架构驱动技术,而不是相反。判断一个产品是不是真正的BPM,应该从源头往下看,看它的设计目的是不是为了解决业务流程管理,看它的架构是不是从业务流程管理方法论当中推导出来的,是不是符合业务流程管理方法规范,其针对的用户是不是业务用户。而不是看它是否包含了BPM的某些技术特征,也不是看它是不是能做到一些BPM声称应该做到的事情。

一方面,技术的堆砌无法形成架构(技术架构必须指向特定的业务领域,解决特定的业务问题),拼凑出来的所谓架构也无法完整的解决业务问题。能够做到某些事情并不表示它就是解决这类问题的恰当的工具!比如,扳手和锤子都可以用来砸钉子,但扳手本身不是锤子,它们被设计为服务于不同的业务领域。另一方面,同样的方法和架构允许不同的实现技术。例如,如果你的架构就是要解决砸钉子的业务问题,由于某种原因无法使用锤子,必要时,你可以把扳手集成进来,作为一种可能的实现技术。

这表示了两层含义。其一,某种技术手段的加入不能决定或改变产品所针对的业务领域,更不能改变产品的本质。上述例子中的架构是为砸钉子设计的,其设计目标并不会因为产品具备了板手的某些特征就变成了修水管的工具。因为扳手在这里明确的指向砸钉子的业务问题,产品会忽略掉其它与砸钉子无关的扳手的其它特征。其二,不能因为某项技术最终解决了某个业务问题,就认为该项技术就是针对该业务问题的正确工具。上述例子中,在解决砸钉子业务问题的工具里,扳手是一种可能的实现办法,但它仍然是扳手,不能够说因为扳手也可以砸钉子了,所以它根本就是锤子。

回到BPM上来,上述的例子想要表达的意思是:如果一个产品的设计理念和相应的架构不是针对BPM的(例如工作流、OA),即使其加入了符合BPM的某些技术实现特征(例如流程监控、流程生命周期管理),它仍然不是一个BPM产品,它只是能够额外做一些BPM所需的功能(上述例子中的扳手)而已;另一方面,如果一个产品的设计理念和相应的架构是针对BPM的,即使其加入了其它一些技术使得它能够支持诸如工作流或OA的应用,它也不会因此就变成工作流或OA产品。它只是扩展了更多的支持而已。

有人要问,我为何要如此纠结和矫情一个产品到底是不是真正的BPM呢?管它什么产品,只要技术上能解决实际问题不就行了吗?我要如此较真的原因在于,业务驱动架构,架构驱动技术,这是一套符合科学方法的体系:首先提出问题,然后分析问题,最后解决问题。从方法到架构到实现,它是一套自洽的、因果的、能自我发展完善的体系。随着问题的深入和变化,整个体系也会随之修改或者进化,但始终是一套完整的处于相应理论指导下的体系,直到该问题不再有价值时被抛弃或者被另一套更好的体系或理论所替代。在整个产品生命周期中,其目标始终清晰、体系始终完整、进化始终有序。所以,如果一个产品是真正的BPM,意味着该产品会随着整个BPM理论和体系进化,获得稳定的、可靠的升级和改进;而如果它只是披着BPM的马甲,通过勉强的定制或拼凑某些技术手段去解决BPM的问题,则意味着该产品无法针对业务流程解决方案提供有效和持久的改进。因为对一个软件来说,如果一个软件设计最初的目标与应用目标不符,而硬逼迫它往应用目标去变更和定制,该软件必然变成打满补丁的袍子和胡乱嫁接的内衣,总有一天它不但再也无法解决这些业务问题,恐怕连它的本职工作都无法再胜任了。

是,还是不是BPM,真的是问题的关键!自底向上的堆砌技术,随波逐流的往架构上随意嫁接技术,见风使舵的把产品改头换面去制造与业务需求的匹配,终究不是长远之计。

windows2012下配置好的ibm bpm8.5环境虚拟机下载

本博主在windows2012下配置好的IBM BPM8.5环境虚拟机下载,链接:https://pan.baidu.com/s/1uNlya2b-cc756wIyifbQCA
提取码:cccm 下载后,用Vmware Workstation打开就可以正常使用。

IBM的BPM流程管理体系,是一套面向企业整体运作的、自上而下的、结构化、体系化的流程设计理论,其拥有科学严谨的方法论。

第一章 流程基本理论

1.1 概念

流程是为达成某一特定的结果所必须之一系列作业活动的串联,而这些作业活动集合了所需的人员,设备、材料,并应用特定的作业方法,以达成为顾客创造更多价值的结果。

1.2 流程分类

一般流程分为业务流程和管理流程;

业务流程就是“工作的流动”(WORK FLOW),是业务与业务之间的传递或转移的动态过程。体现为市场导向、用户为中心的流程。如客户开户流程、系统运行与维护流程、新产品研发与推广流程等。

管理流程就是“管理工作的流”,是管理工作之间的传递或转移的动态过程。管理流程支撑业务流程,面向内部管理,体现效益为中心。如预算与经营规划流程、资金管理流程、代理开户管理流程等。

1.3 流程的功能和作用

1.3.1 企业实施业务流程管理的功能体现在:

  • 强化对客户有价值的业务流程,提高客户满意度;
  • 强化企业风险管理;
  • 优化成本,优化资源配置;
  • 缩短工作完成时间,提高工作效率。

1.3.2 业务流程管理的作用体现在:

  • 实现从职能管理到面向业务流程管理的转变;将业务审核与决策点定位于业务流程执行的地方,缩短沟通渠道与时间,提高反映速度;
  • 注重整体绩效最优的系统思想;
  • 建立扁平化组织,业务流程管理要求先设计流程而后根据流程建立企业组织,尽量消除纯粹的中间环节,有效降低管理费用和成本;
  • 充分发挥每个人在整个业务流程中的作用。业务流程管理要求将决策点定位于业务流程执行的地方,这就强调业务处理流程上的人员素质,并强调团队合作精神。
  • 充分利用IT工具协调分散与集中的矛盾 ,在设计和优化企业的业务流程时应进行IT实现整合和信息共享机制,将串行工作流程变成并行工作流程,协调分散与集中的矛盾。

第二章 流程优化设计方法

企业流程优化设计实施过程一般分为发起阶段、关注阶段、发明阶段、推行阶段;

发起阶段实施内容包括:明确目标→优化范围→资源计划

关注阶段实施内容包括:现状分析→最佳实践分析→差距分析→改进机会

发明阶段实施内容包括:流程框架设计→流程设计→流程KPI→IT固化

推行阶段实施内容包括:流程培训→上线辅导→推行评估

2.1 目标和优化范围

在作企业的业务流程改造项目之初,我们必须明确企业实施流程建设的目标和范围,这是与企业的发展战略相关的,一般会由企业领导来把握和确定。

2.2 资源计划

资源计划是指在流程项目实施过程中投入的人财物。其中关键因素在于人力的投入。一般建议企业投入最好的人力资源参与流程设计,将最终决定流程交付的质量及流程的落地。

2.3 现状分析

本博主在windows2012下配置好的IBM BPM8.5环境虚拟机下载,链接:https://pan.baidu.com/s/1uNlya2b-cc756wIyifbQCA
提取码:cccm 下载后,用Vmware Workstation打开就可以正常使用。

现状流程的调研、梳理和问题点(流程断点)的分析,作为未来流程项目实施评估的底稿。

调研主要侧重流程断点的梳理和分析。主要的流程断点包括:业务活动的断点、组织的断点、岗位断点、人的能力断点、输入和输出断点、系统断点、流程监控断点、流程接口断点等。

2.4 最佳实际分析

借鉴,即在具体流程设计过程中主动导入行业内、组织体系内、标杆优秀经验。

2.5 差距分析、改进机会

根据资源配置情况及现状分析,决定流程设计的优先顺序。

2.6 流程框架设计

流程框架和流程清单的设计过程。

  • 企业流程框架反映企业业务运营中的价值链(主流程)构成及逻辑关系;其包含的职能模块,应涵盖企业的所有业务管理活动,通过分解和细化就可以形成企业的完整流程体系,流程框架设计中应反映外部联系接口。
  • 框架设计一般包括核心流程设计及支持流程设计,核心流程反映核心业务活动链,包括影响部门运营的主要经营活动和管理活动;支持流程是指那些通过向主流程提供必要的基础信息、辅助要素、协助手段等, 以支持主流程的有效运行的流程。
  • 框架设计是进行企业流程设计的核心环节,是管理思想建模的过程,是进行操作级流程设计的基础;其将有助于从整体上把握流程的相互关联性。
  • 框架设计中应充分借鉴行业标杆企业的优秀管理经验;框架直观展示了整体与局部的业务结构和业务逻辑关系;且对比标杆模型,能够明确缺失的管理职能。

2.7 流程设计

操作层级的流程设计,即流程文件的设计,流程文件包括流程图、流程说明书、模版。

2.8 流程KPI设计

通过流程节点分析,设计流程的绩效指标。

2.9 IT固化

IT固化即为流程的IT实现,IT固化是保障流程有效执行的工具,但不是所有流程必须实施IT固化,大部分操作性流程应实行IT固化。

2.10 流程培训、上线辅导、推行评估

在流程推行阶段,需要进行流程培训,充分沟通;并进行上线辅导,推行评估。

第三章 流程结构化设计方法

阅读更多