BPM选型评估建议Word文档下载推荐.docx
《BPM选型评估建议Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《BPM选型评估建议Word文档下载推荐.docx（38页珍藏版）》请在冰豆网上搜索。
OSWorkflow
是完全用java语言编写的开放源代码的轻量型基于状态机的工作流引擎，选择理由：
普元BPS
普元BPS是上海普元公司提供的基于SOA架构的业务流程平台产品，选择理由：
国内流程平台领域的市场份额第一
国内大型客户采用的案例比较多
与上证所业务关系密切的中国结算上海分公司已经选择BPS
总部在上海，与上证所比较近
IBMWPS
WPS是IBM公司推出的基于SOA架构的业务流程平台产品，选择理由：
国际知名厂商
在国内BPM市场影响力较大
3评估模型说明
选择BPM产品开发业务流程应用，本质上是解决系统的整合与业务处置的标准性和弹性，因此，BPM产品专门大程度上决定了一个BPM应用的生命周期和质量，如此就意味着BPM产品的价值需要贯穿到BPM应用系统的全生命周期中，包括业务流程应用的设计、开发、运行、治理保护和流程调整，因此，选择一个BPM产品，不能单纯看那个产品支持什么特性，或不支持什么特性，除这些技术特性外，还需要关注包括效劳、产品延续性、利用本钱等多层面的问题。
因此，在功能特性上咱们除针对流程需求功能点的知足程度的评估外，还针对BPM应用的实现全生命周期来比较各产品的特性，也即需要流程产品在功能上能够较好支持流程的快速开发、快速部署、运维期敏捷应付业务流程变更的需求、高效稳固运行，这些时期对流程平台及提供流程平台厂商的都有较高的要求。
依照前面的选型目标及评估的标准，下面咱们给出本次流程平台产品选型的评估模型，本评估模型从流程平台技术特性（其中包括功能特性和非功能特性），支持与保证（包括本地化效劳支持，典型应用案例），商务本钱（包括购买本钱和拥有本钱）三个方面来展开。
具体如以下图所示：
流程技术特性。
要紧考察流程平台在功能和非功能方面的特性，功能特性方面包括流程的设计建模和开发能力、人工任务处置能力、与其它应用和工具的集成能力，运行期流程及效劳的执行监控能力和流程运维期的持续优化和调整的能力。
非功能特性方面要紧考察性能与稳固性、开放性与可扩展性、易用性、可保护性。
支持与保证。
关于大型企业级中间件的选择，支持与保证是超级重要的维度。
大型企业级应用一样比较复杂，而且贯穿在开发进程、运行期间、保护期间的应用全生命周期。
要想取得保证需要产品持续进展计划能力，典型案例证明，快速健全的效劳保证，专门是要能够有快速高效的效劳体系，不管开发进程仍是运维期间显现故障时能够取得平台软件厂商的快捷效劳保障。
商务本钱。
从购买本钱和拥有本钱（包括全生命周期的学习本钱、效劳本钱、迁移本钱和保护本钱）两个维度考察各产品的本钱。
下面针对评估模型中的各关键特性进行具体说明：
评估方面
评估特性
特性说明
技术特性（功能方面）
流程设计开发能力
1、流程的可视化建模与快速开发
2、流程的版本控制
3、流程模式的支持
4、流程的仿真
5、流程开发与应用开发框架的整合
人工任务处理能力
在业务流程应用中会涉及很多人工参与的长流程，并且在流程产品中人工流程领域是很大的一块，对流程的任意回退及业务补偿、对业务异常的处理、灵活的人工任务分派策略都有较高的要求。
应用集成能力
1、流程平台与用户组织机构的集成
2、流程平台与第三方系统的集成
3、流程平台与Portal、LDAP、影像、内容管理、规则引擎等平台的集成
4、流程平台与第三方工作日历结合进行KPI时间限制计算的能力等。
流程监控能力
主要考察实施和运维阶段对流程实例以及流程中所使用服务的运维情况的监控分析能力，重点关注对流程和服务的运维期监控能力
流程变更能力
流程变更是应用开发必须考虑的问题，该评估点主要考察流程平台对业务流程敏捷变更的支持能力
业务调整能力
该评估点主要考察流程平台提供了哪些业务层面可以对流程配置调整的能力
技术特性（非功能方面）
性能与稳定性
为了确保BPM支持未来流程化应用的建设，需要流程平台有高并发、海量业务量的支撑能力，主要体现在：
流程实例启动的性能
查询待办任务列表的效率
人工任务（或称工单）处理的效率
等
开放性与可扩展性
主要考察流程平台产品的开放性和可扩展性，包括：
所提供接口的开放性
数据结构的开放性
对第三方系统集成的方便性（如规则引擎产品、Portal等）
对特殊需求的支持的可扩展性等
易用性
主要考察流程平台产品在开发期、运维期的易用性，包括开发一个流程的周期、运维期故障定位的便捷性、运维期对流程配置便捷的调整能力等
可维护性
主要考察产品运维期间对故障定位、日常维护的支持能力
支持与保证
服务支持
主要考察在应用开发期间与运维期间产品提供方所提供的本地化服务支持的快捷性与解决问题的能力
典型案例
主要考察流程产品的典型案例
商务成本
购买成本
考察流程产品购买的成本
拥有成本
考察流程应用全生命周期的学习成本、服务成本、迁移成本、维护成本等
4评估结果
4.1评估进程说明
本次评估采纳指标应答和口头交流问答的方式来进行，进程中还结合部份DEMO的验证（另见《BPM产品技术验证的测试报告》），整个评估进程陆续进行了×
天左右的时刻，基于对各家产品的整体熟悉同时结合上证所对流程平台的要求咱们设计了相应的评估模型。
4.2评估结果分析
本章节将依照前面所概念的评估模型对四家产品进行逐项分析。
4.2.1技术特性（功能方面）
本章节将从一些重要的功能点上针对jBPM、OSWorkflow、普元BPS、IBMWPS这四款流程平台产品做深切比较。
这些特性包括：
流程设计开发能力、人工任务的处置能力、应用的集成能力、流程监控能力、流程变更能力、业务调整能力等方面。
4.2.1.1流程设计和开发能力
产品
技术特性
1、提供非常简易的基于eclipse插件的流程图设计，但不能满足完整流程设计功能，比如不能与组织模型结合，不能设计人工任务的页面等等。
2、开发人员必须利用有限的接口做大量的扩展来实现一个流程系统或项目，工作量很大。
如下图：
只提供了一个非常简易的基于Swing的流程设计器，只能简单绘制出流程的一些简单关系，后续需要开发人员做大量的手工文件编辑才能形成一个可运行的流程文件。
1、提供基于Eclipse的集成开发环境，功能较强，界面比较友好直观，如下图：
2、流程设计建模工具能够很容易嵌入到用户应用开发环境中、流程运行环境可以很方便与用户已有框架融合，支持应用与流程平台的集中部署和分布式部署；
3、流程模板支持版本管理
4、支持基于自动表单的流程仿真能力，能够快速构建业务流程的原型
5、BPS另外提供了基于WEB页面进行业务化流程开发的环境
6、支持的流程模式参见附件D的比较
1、提供了基于Eclipse的WID进行流程设计和建模环境，功能比较强大
2、流程仿真由另外产品modeler提供，功能比较强大，可以支持分析流程的瓶颈和耗时点，提供流程优化参考
3、流程开发工具与运行环境比较独立，与用户的开发环境和框架融合比较困难，应用与流程平台只能分布式部署；
4.2.1.2人工任务处置
1、支持人工任务分配，但本身没有第三方组织模型结构的支持接口，必须自己扩展AssignmentHandler接来做大量开发才能实现。
jBPM默认只提供了ExpressionAssignmentHandler接口来实现简单的user和group的分配，对于国内负责的组织结构关系性分配，则必须做大量扩展实现，甚至有可能需要改造其底层实现逻辑和代码框架。
2、支持人工任务列表查询，但仅提供简单查询接口，在实际应用中，必须进行大量扩展来支持诸如分页、按业务对象查询、复杂查询组合等情况。
3、支持任务提交，但不支持多工作项处理，也不支持任务递交多种策略，诸如“顺序执行”“全部提交”“百分比会签提交”等等不同策略。
4、不支持代理代办，必须自己做大量扩展。
5、不支持回退、自由流等国内应用模式
6、不支持工作日历，没有超时处理
没有人工任务这样的概念，也没有组织模型和用户组的支持接口，对于人工任务的处理，完全依赖于基于Action（是OSWorkflow特有的概念）接口做外围大量扩展；
没有超时概念。
1、国内研发的产品，支持灵活的人工流程模式，如流程的任意回退及业务补偿、对错误的处理、灵活的人工任务分派策略等；
2、支持基于机构、岗位、角色、人员甚至是动态Party模型的任务分配机制，完备的参与者模型，既可以设计时指定明确的参与者也可以运行时通过规则获取参与者，并且提供了一套标准的组织机构模型；
3、通过灵活的委托和代理代办模型，可以支持典型的分派、移交等业务处理需求；
4、对于流程的版本管理方面提供了“分水岭”、“一刀切”等灵活的策略选择；
5、存在时效控制概念，提供工作日历接口，提供预警超时机制，灵活的KPI时间限制计算模型。
1、国外通用产品，对灵活的人工流程模式支持较弱，如流程的任意回退、灵活的人工任务分派策略等；
2、支持机构、岗位、组等多种参与者的设置，可以通过接口的方式进行扩展，但不支持通过复杂的规则动态获取参与者；
3、流程变更所需要的版本管理功能支持不够；
4、业务上经常需要使用分派、移交模型，流程平台没有提供内置的支持，需要在业务功能中实现；
5、支持时效控制，没有工作日历接口。
4.2.1.3应用集成能力
1、产品没有提供完整的组织模型（只有user和group概念）实现和接口，需要大量外围扩展接口来实现人工任务的分配、获取和查询处理
2、完全依赖于通过注册相应事件处理类来实现对外围应用的集成。
1、产品没有提供完整的组织模型（只有owner概念）实现和接口，需要大量外围扩展接口来实现人工任务的分配、获取和查询处理
1、产品提供了一套组织模型的实现（提供了名为ABFrame的应用框架），也提供了组织模型扩展接口，可以非常容易的支持第三方组织模型，及已经存在的组织系统
2、提供基于自动活动和多种触发事件来实现对外围应用和平台（规则引擎、影像等）的集成
3、流程引擎提供的相关服务可以通过RMI、SOAP、HTTP、JMS、本地方法调用等多种协议进行访问；
1、提供组织机构模型的可扩展接口
2、流程服务接口主要通过SOAP、EJB、JMS等远程调用方式调用；
3、流程服务接口无法通过本地模式调用，可能会影响调用效率；
4、提供大量的适配器，方便和异构系统进行集成
4.2.1.4流程监控能力
提供简易的流程运行状态监控显示信息，但不能显示更详细的信息。
如下图
1、提供了基于WEB方式完整的管理监控工具，提供如下功能：
图形化监控流程实例、活动实例、工作项的执行情况，并提供流程干预能力，如流程中止、挂起、恢复、回退，任务改派等；
对业务流程的图形化调整，如重新设置参与者、操作时限等；
对工作项以及流程实例的复杂查询监控；
审计日志查询
代理人范围与代理关系、任务交接管理
配置历史数据迁移的功能
2、可监控活动中所调用服务的执行情况，分析执行效率和瓶颈
1、提供了强大的流程监控功能，但需要通过独立购买并安装的Monitor进行流程监控；
2、能做到对流程中所调用服务的监控和审计，启开这些功能会造成系统性能大幅下降。
4.2.1.5流程变更能力
1、流程变更需要开发人员重新开发流程，改变实现代码来支持
2、没有版本管理功能
1、提供基于web的可供业务人员操作的图形化操作功能，支持业务化的调整和设计，敏捷响应业务变更。
2、提供强大的版本管理功能，支持流程调整后按“一刀切”、“分水岭”、“特事特办”等策略来进行版本发布。
3、流程发布支持热部署。
1、流程变更必须开发人员重新在Studio中开发流程，变更周期比较长。
2、版本管理非常单一，只提供“一刀切”版本发布模式。
3、发布流程后，需重启应用服务器，使更新生效。
4.2.1.6业务调整能力
无
1、提供基于web的可供业务人员操作的图形化操作功能，支持业务化的调整和设计；
2、提供了流程测试与验证的功能，通过流程仿真，可对优化和调整的流程进行测试验证，确保其准确性；
提供可供业务人员操作的Modeler，但此流程调整后依然需要开发人员做大量实现才能运行，并不支持多版本策略。
不支持基于WEB方式的流程编排；
4.2.1.7中文环境支持能力
默认只提供英文界面
支持中文，符合国内语言习惯
支持中文
4.2.2技术特性（非功能方面）
本章节将从一些重要的非功能点上针对jBPM、OSWorkflow、普元BPS、IBMWPS这四款流程平台产品做深切比较。
这些非功能特性包括：
性能与靠得住性、开发与扩展性、易用性、可保护性等方面。
4.2.2.1性能与靠得住性
1、仅是一个轻量型引擎，内部架构和实现没有提供任何技术和模块来应对高并发的响应，需要应用时进行项目方案级实现。
2、没有大型案例系统的检验，对于性能和可靠性缺乏实际数据支持
1、性能处理不高，也没有提供任何技术和模块来应对高并发的响应。
1、内部提供高效缓存和线程池等技术来解决高并发响应能力。
参见附录中的性能测试报告
2、在证券、金融、保险、电信等行业有过大量高性能实施案例
3、提供性能监控和分析的工具支持
1、产品API接口都为EJB、JMS等远程调用方式，未提供本地调用方式，对性能有一定的负面影响；
2、产品结构过于复杂，产生性能问题后，较难进行问题定位和优化。
4.2.2.2开放性与扩展性
1、扩展性很好，提供了基于事件的扩展接口，及任务分配的扩展接口
2、开放性很好
1、扩展性很好，提供了基于Function及很多Action的扩展接口。
并提供了扩展的状态点。
1、扩展性很好，提供了基于事件的扩展接口，及组织模型扩展接口。
并提供条件和参与者等规则接口
2、开放性较好，数据模型开放。
3、遵循WfMC系列规范与标准
4、提供基于多种访问协议（SOAP、JMS、HTTP、JAVAAPI等）的BPSAPI，方便被本地以及远程客户端调用以及与其它应用的集成；
1、扩展性很好，遵循BPEL规范，提供了基于事件的扩展接口，及适配器接口扩展。
2、开放性很弱，数据模型封闭。
3、流程从国外环境发展而来，难以适应部分国内复杂的需求场景，并且厂商不可能提供定制化产品；
4.2.2.3易用性
1、产品一体化弱，流程设计器不完善，必须开发人员做大量二次开发。
2、流程API接口也不完善。
3、没有中文环境
2、无针对性的流程API接口。
1、产品一体化比较强，用户使用统一的环境实现流程的设计建模、调试、运行、监控和管理，比较容易使用；
2、从产品概念、使用习惯、文档等都相对比较简单，特别是符合国内用户的习惯；
3、产品易安装部署，易管理；
1、产品相关概念非常多，在流程实现时，需要深入理解方可熟练使用；
2、相关流程设计、监控、管理等功能都分布在多个环境中进行，需要安装和部署大量的工具；
3、产品一体化不强，众多组件需要单独安装，部署比较复杂；
4.2.2.4可保护性
无可实用的监控管理模块。
1、基于SOA与构件的思想设计开发，在运维期间可以通过监控和审计工具分析每个构件和服务的执行情况，分析系统的瓶颈，便于故障定位解决。
2、提供流程治理模块，可以对集群等环境进行管理。
3、提供业务人员参与的流程调整能力，便于应对后续业务流程变更
全是基于Java代码的方式进行功能逻辑的开发，运维期间出现问题很难定位解决；
4.2.3支持与保证
4.2.3.1产品进展
比较信息
产品发展依赖于开源社区的兴趣
产品的大版本之间不兼容，如即将发布的不兼容3版本
产品发展依赖于开源社区的兴趣，从2006年发布版本后，至今未作版本更新
1、产品从2003年推出后，持续进行研发投入，目前最新的版本为，一般2年发展一个大版本，每半年发布一个小版本
2、有专门的产品管理部门进行产品的规划和预研
1、版本更新相对较稳定，WPS从2006年初发布,到2008年5月发布;
4.2.3.2效劳支持与培训
产品由开源社区提供，无服务支持和培训
1、针对大项目，普元提供全程的保障――投入专业服务工程师，提供全程现场的保证，从设计、开发、培训、调优，联合组建应用实施队伍，联合组建解决方案开发队伍。
2、普元提供与合作伙伴开发工具和运行框架融合的定制化产品和工具；
3、普元提供快速的本地化响应，针对一般流程平台都满足不了的需求，普元甚至可以提供研发级的产品支持；
4、普元已经建立针对大客户的“大客户经理”制度，提供量身定制的、主动的咨询与服务；
5、在系统运维期间，普元提供主动的定期走访与系统巡检服务，访问故障预防与解决；
1、主要服务是通过远程支持的方式，本地化支持较少，特别是对于突发性服务支持，往往需要通过繁琐的区域甚至国外的服务申请流程，服务很难得到快速保障；
2、IBM的策略是提供面向所有用户一致的产品形态，与开发商开发工具和运行框架融合能力较差；
4.2.3.3典型案例
主要应用于技术性尝试的中小型项目，具体案例不详。
拥有较多的大型客户案例：
1）中国结算上海分公司、深圳分公司已经将BPS定位公司级的业务流程平台；
2）建总行、交总行、农总行、中国银行、太保等14家金融机构；
3）移动集团公司及广东、贵州等省投资计划管理；
4）联创在天津、陕西、新疆的集团客户端到端电子工单流；
5）广东移动、贵州移动等EOMS；
6）亿阳的移动与联通EOMS产品线；
7）电信集团公司、沪浙苏、甘肃、安徽、贵州、四川、青海、云南等省电子运维；
8）电信全网的长途资源管理；
9）日本、巴西、泰国、印尼、荷兰、冰岛等30多个海外电信客户；
银行、政府案例较多，电信案例较少，并且电信案例主要为信息门户类，没有核心系统类案例：
1）四川移动
2）重庆电信
3）上海电信客户响应平台
注：
WPS产品是IBM目前主推的BPM产品，但在国内的成功案例较少
4.2.4整体本钱
4.2.4.1产品购买本钱
免费
1、普元公司的公开商务模式是按应用服务器的CPU数量收费，但也提供了其他灵活的商务模式；
2、价格相对国际厂商优惠
提供单一的报价模式，并且产品组合中往往需要购买SOA平台相关产品组件（如ESB、MessageBroker等），无形增大了购买成本；
4.2.4.2学习本钱
1.无专业机构提供学习指导，学习质量完全由个人技术能力决定。
从入门到项目应用一般学习周期较长。
2.学习资料免费--大部分来源于网络。
资料内容相对较少、缺乏系统性、专业性。
同上
1、由于普元产品从国内发展起来，更贴近国内开发人员的使用习惯，相关概念较少，容易学习；
2、普元提供针对性的中级和高级培训课程与认证，学习难度
升级会员 