导航↓ 相册|收藏博客|加入友情链接|给博主留言
2011/10/19 22:03:30

谈BPM和工作流(1)

最近BPM业务流程管理越来越受到大家的重视,而BPM本身也用于后续基于SOA的流程整合,BPM如何用如何落地一直是我最关心的问题,BPM本身和工作流也存在较大的区别,如何更好融合也是一个需要考虑的问题。

企业信息系统构建本身就应该遵循流程分析,业务建模,子系统划分,系统功能建模的逐步分解过程。由于企业内职能部门的划分,而业务系统往往又需要一个归宿的主导部门,在企业发展大后一个业务系统也很难完全支撑到企业所有业务流程和业务活动。因此不可避免的导致了企业在各个业务域衍生了多个业务系统,业务系统主要实现价值链的一个核心业务域,但是业务系统必须要整合和集成才能够满足端到端流程的整合。

端到端流程整合出现断点或流程不畅通,一方面是业务系统本身的分解有问题,一方面则是业务系统之间集成有问题,业务部门各自为阵导致了系统集成这种中间地点没有一个主导部门去管理和负责。业务系统本身分解问题主要体现在没有一开始就从企业架构和应用架构出发来考虑业务系统建设,业务系统建设不是从顶向下的,而是完全根据业务部门需求各自建立。系统间集成问题则主要体现在了完全不考虑集成的标准规范,集成的方式,集成本身的可复用性,导致大量重复建设。

流程建模遵循高端建模逐层分解的思路,高端流程往往正是我们关注的业务流程,高端流程跨越了多个业务域,多个业务活动,多个业务对象和单据实体,最终完成了一个端到端业务。如供应链端到端,涉及到采购需求,采购计划,采购策略和实施,采购订单,采购执行诸多环节和业务对象。高端业务流程中采购订单生成只是一个业务活动或子流程,而采购订单制作和生成本身又需要根据订单类型或金额设计不同的审批流程,而采购订单拟制后的审批流程才是我们经常所说的工作流,人工工作流或审批流。

那么从这个意义上很容易看到业务流和工作流的区别如下:

 

  • 业务流往往会跨多个业务系统,而审批流往往主要涉及到一个系统。
  • 业务流往往会涉及到多个业务功能,多个业务对象,而审批流往往只涉及到一个关键业务对象。
  • 业务流涉及到的是不同业务单据之间的流转,而审批流往往是同一业务单据状态的变化。
  • 业务流中的活动既包括了人工活动也包括了自动的业务活动,而审批流一般为人工审批活动。


而对于BPM业务流程管理系统和工作流管理系统,可以再进行下分析。我们看到现在很多BPM软件也从工作流管理软件发展而来。不论是哪种,基本都包括了流程建模,流程执行,流程监控,流程分析等基本功能。包括了表单建模和数据建模,权限管理等扩展功能。可以讲一个完整的系统基本上可以实现简单的以审批流为主的简单业务功能模块的配置化开发。通过表单设计工具制定一个表单界面,绑定数据对象,挂接上自定义的流程模板,一个功能即开发完成,只要没有太多复杂的业务规则,基本上完全可以通过配置实现,这也是这类工具可以在类OA应用中大规模使用的原因。

对于流程建模,BPM关注的是业务流程建模,基于BPMN或BPEL进行,而工作流软件关注的是审批流建模。BPM建模需要考虑业务人员对建模需求和可用性,但是不可避免又导致建模的内容无法很好的落地。而工作流建模本身已经细化到一个功能模块中的审批流,相对来说简单很多而容易实施执行。

BPM业务流程往往跨越了业务系统,跨越了多个业务单据,需要处理不同的业务规则和逻辑。而工作流软件活动节点往往仅仅处理审批和会签任务,和外界交互相对较少。而BPM业务流程中由于存在业务活动和业务规则,而这些又需要外界提供数据支持,因此不可避免的在BPM流程建模中需要通过SOA服务方式调用各种可复用的服务来处理和转换数据。工作流软件发展到今天,我们看到也可以在表单建模,工作流设计过程中调用外部的SOA服务,这是一个很好的进步,使工作流软件不仅仅能够简单进行审批处理还能够增加较为复杂的业务规则判断。

业务流程建模中会出现业务规则,常规的工作流软件处理方式一般支持脚本代码进行简单业务规则的处理,而发展到BPM后为了保证规则本身的复用性和独立维护性,引入了规则引擎,规则引擎形成统一的规则创建和维护库,BPM本身不再负责规则的创建和维护,而仅仅是按需消费。这个分离本身意义也很重大,要知道业务规则又明确的业务系统开发商和业务主管部门,放到BPM系统中通过定制方式管理规则显然是很困难的。

传统的软件工程方法从业务流程分析到形成子系统和功能模块,有一系列的分析和设计过程,最终形成各个功能模块和协同应用。而BPM系统试图通过简单的业务流程建模和BPMN就能完成一个复杂业务流程到功能模块的转化,这是一个相当困难的事情。虽然BPMN2.0使这种转化成为了可能,但是要看到对于跨系统,跨多个业务对象实体的长流程,BPM系统可以进行流程建模和设计,但是很难直接转化为可实现的模型。这是到现在BPM系统也很难去解决的问题,如果该问题没有解决,BPM系统又沦落为一个业务人员建模的工具而已,BPM和实际的业务系统仍然是脱节的。

BPM重点是流程整合,而流程整合是多个业务系统中多个业务功能模块之间的协同,如果一开始想用BPM去实现这些业务功能,那么往往是适得其反,BPM切入的第一步仍然是在于跨业务系统的流程集成,而流程集成重点又在于流程间的数据传递。知道这个重点后BPM的关注点应该放到流程协同和监控上,而子流程或某个独立的业务模块实现仍然在原有的业务系统中,通过端到端流程整合实现了业务模块之间的系统,这个一方面最大限度的利用了已有的IT资产,又实现了流程整合的需求。

业务流程整合一定是涉及到自动化的业务流和人工工作流,原有的BPEL很难融入HWF导致BPEL只能应用到流程整合的一些点上而无法真正实现理想状态下的流程编排,最多算上服务编排。而引入人工工作流使BPM有了做端到端流程整合的能力,但是已有业务系统已经有工作流引擎或审批流实现,要完全抛弃已有的流程引擎又是一个很麻烦的事情。那是BPM来整合已有的流程引擎,还是流程引擎引入BPM的关键要素又成为一个需要考虑的问题。BPM之所以困难,不在于思路上,而在于实践和落地上,如果是全新构建业务系统还好办,特别是已有业务系统的IT环境改造。即时实现了流程整合,那么流程整合后的认责部门是谁?流程整合后对已有业务系统有哪些影响都需要考虑,而不是简单的想流程整合后放到门户系统了事。
 



查阅更多相关主题的帖子: bpmsoahwf流程 业务流程

评论


发布者 碌碌有为
2012/7/24 17:17:17


实际上bpm在国内企业可能面临的问题会突出一点。典型的二位不靠所以实施起来会有些基础的事情可能的靠甚至bpr。

发布者 CHAMPERLION
2014/10/18 20:42:03


您还未登录,不能对文章发表评论!请先登录