BPM业务流程管理系统建设和实施.docx

BPM业务流程管理系统建设和实施BPM的概念与起源BPM,即业务流程管理，是一种以规范化的构造端到端的卓越业务流程为中心，以持续的提高组织业务绩效为目的的系统化方法，是一种管理原则。BPM通常也代指BPMS(BusinessProcessManagementSuite),是实现整合不同系统和数据的流程管理软件套件。针对流程管理的信息化系统，特点是注重流程驱动为核心，实现端到端全流程信息化管理。从具体实施的层面看，BPM可分为流程定义、流程测试、流程执行、流程分析、流程管理、流程质量与效率监测、流程优化等环节。20世纪90年代，MichaelHammer和JameSChampy的成名之作公司再造引发了业务流程改进的浪潮。两位管理学大师展示了这样的观点：重设公司流程、结构和文化能够带来绩效上的显著提高。20年后的今天，业务流程改造有了新名字：业务流程管理(BPM),再次流行。很多公司再次把业务流程管理，这种通过分析、建模、监控持续优化业务流程的实践，当作解决业务难题和帮助公司实现财务目标的系统方法。关于业务流程管理业务流程(也叫做经营流程)是为了实现一定的经营目的而执行的一系列逻辑相关的活动的集合，业务流程的输出是满足市场需要的产品或服务。根据功能、管理范围等的不同，企业的流程管理一般分为四个层次：生产流程层运作层计划层战略层管理层次功能管理范围影响时间范围使用方法信息系统支持生产流程设备和工艺的实时控制具体设备很短流程控制理论现场总线、数据采集和监控系统运作层制作执行流程管理车间较短调整和优化理论制造执行系统、车间调度系统计划层资源能力计划和预算部门至企业较长统计和随机模型、优化理化企业资源计划战略层战略调整、流程设计和资源类型确整合企业长经济模型、决策模型知识管理、决策支持系统流程管理的各层次均有相对独立的、特定的方法，但层次之间也有着密切的联系。、首先，高层的管理目标最终要通过低层的业务活动来实现；其次，当低层的管理解决不了实际问题时，就需要引入高层的管理，例如：运作层的调度无法解决资源的配置问题时，就说明分配给该流程的资源数目需要修改，此时需要引入计划层的管理，重新进行资源能力计划的计算；最后，低层的数据为高层的管理决策提供依据，企业的策略管理和战略管理中的模型和参数来自对企业实际经营活动统计数据的积累。从整个企业流程管理的角度来看，有必要将这四个层面上的流程管理统一和企业的信息系统联系起来。从企业信息系统的角度来看，办公自动化系统、事务处理系统和决策支持系统等都是常见的企业信息系统，但这些系统并没有加入流程的因素，只是用来帮助员工完成某些特定的任务。工作流系统的出现使得整个流程的自动流转或自动执行成为可能，但是工作流一般只解决生产流程层的问题，与企业的计划和战略决策还存在一定的脱节。另外，随着企业业务流程向企业外部(供应商和客户)延伸，传统的工作流系统无力解决跨企业的流程集成问题。BPM对业务流程管理的作用帮助企业降低成本当企业有一套合适的BPM系统时，每个业务流程都已经确定并且实行，通过流程系统我们可以清晰地了解到各个业务流程的短板，从而进行调整，避免过多的损失。帮助企业认识和响应客户需求成功的企业必须有回应。他们必须能够识别不断变化的客户需求和偏好，并迅速做出反应。这是成功的BPM策略真正可以提供帮助的另一个领域。它迫使决策者注意。我们查看流程管理方式的最新变化之一是，流程本身正变得越来越以客户为中心，而不再以生产力为中心。利益相关者现在不再想问如何改进流程以更快，更高效地推出产品，而是希望改进流程以更好地满足客户的需求。这直接影响到诸如客户满意度和保留率之类的指标。此外，修改业务流程以使其满足客户的需求通常会导致其他重要的改进，从而带来更高的生产率和效率。提局企业的生产力随着竞争的加剧和生存条件的要求越来越苛刻，公司必须尽力而为。BPM可以帮助提高生产力，并使公司能够为客户提供更多服务。具体来说，可以通过减少订单下达之间的延迟时间以及系统中订单的可见性。这样可以更快，更高效地完成订单。所有这些都归功于良好的业务流程管理带来的那种客观分析。没有业务流程管理，公司可能不会意识到这种低效率。保持企业的核心竞争力当您的流程重复且效率低下时，它们就会充满浪费，这意味着您没有时间专注于研发或其他步骤，从而使您的公司能够更好地抵御竞争。这是因为在不简化业务流程的情况下，您将始终专注于运营。限制了创新并允许废物积累，进一步降低了您的速度。当业务流程可靠且高效时，您的业务将有更多资源用于增长和发展。流程管理(BPM)软件产品目标BPM的主要特点是流程导向、通过强大的集成能力、端到端连接使效率提升。BPM软件主要通过帮助企业将流程做为切入点，梳理企业业务，极大地减少了业务实现时间，从内部管理角度实现降本增效。从企业内部实现：1、组织管控能力升级管理上的地域间隔、层级限制和系统隔离等问题在BPM平台上迎刃而解，借助BPM赋能平台的多租户模式和接口整合能力，企业内的管控得到全方位升级；2、业务管理绩效提升业务流程的复杂多变和流转困难等行业痛点和难点在BPM平台上得以攻克，借助BPM赋能平台的可视化配置模式和流程引擎的诸多中国特色，企业业务流程的规范性和高效性得到充分保障；3、IT的赋能价值呈现信息化建设的成本导向在BPM平台的应用过程中得到扭转，借助BPM赋能平台以“流程”为核心的整套引擎式开发套件和方法论，企业在流程管控可持续发展的路上有了更强大的工具武装。产品设计思路BPMl软件以打通企业服务流程为核心，建立有效的业务流程线。而业务流程线的建立即是工作环节的建立，促进端到端(EndtoEnd)的业务对接，打破部门间“数据孤岛''，使企业真正实现“客户为中心”的落地服务体系。同时，BPM软件还需要具备强大的集成能力，实现OA、CRM>ERP等多个系统的整合。BPM产品在市场中通常以套件形式出现，构成的组件包括：流程设计器流程引擎表单业务规则引擎组织模拟测试看板/仪表盘工作区集成层行业解决方案BPM产品在设计中以流程中心的方式，对企业业务流程进行全流程管理企WI?烽,二：TmWM将征分析/ aww*. wwawjm 舞艮京,存在"WwtX祭/ JWMI由mwt成，产品体系架构与核心模块BPM软件需要根据企业业务环境的变化推进人与人之间、人与系统之间以及系统与系统之间的整合及调整，打破传统“工作流”的流程传递、流程监控的范畴，实现灵活、易用、互通的信息化整体架构和环境，帮助企业跨部门、跨组织、跨业务线提局执行力。E3的算SXiTP I 税的户 I PTFj I fcP供国«申请翟谢格 发货X程中心对企业内部及外部的业务流程的整个生命周期进行建模、自动化、管理监控 和优化，使企业成本降低，利润得以大幅提升。应实现模块包括：BPM生命周期管理：开发符合国际BPM规范，严格按照流程管理的完整生 命周期方式管理流程。从流程的调研设计到系统建模实现，再到上线运作执行，最后通过系统执行 分析报表来确立流程是否有优化的空间。真正带来企业效率提升。内置企业应用：为提供企业经营活动、行政管理等方面的常用业务流程应用的功能。增值模块功能，可以为客户带来更多管理上的帮助高效开发：企业个性化业务流程实现，可通过系统自带的表单流程设计师实现，无需复杂的大规模开发，成本低，实现度高，为企业长期发展系统内部应用深度，提供的经济好用的帮手。BAM业务流程监控：应用流程规范管理化，节约时间成本、提高服务质量、进而给客户带来效率提升。为用户提供流程监控的有效工具，依据BPM中进行流程积累的数据，以图形化方式展现数据分析结果，为客户进一步优化流程提供数据依据。MMj目二-l-三二二二三_I_HRBBH检流程关卡运行状况，提供统计数据，以供流程优化(BPR)之依据BPM(业务流程管理)实施策略1 .确定BPM项目的轻重缓急BPM的常见错误是没有把BPM应用系统与项目实施部门及整个企业最重要的战略目标紧密联系起来。BPM关注的“流程效率”应当与更重要的战略目标结合起来，譬如提供效率更高的客户服务。IT组织以及来自每个业务部门重要的利益相关者应当就项目的轻重缓急达成一致，所选的项目不仅能给单个部门直接带来好处，还能给多个部门或者整个组织直接带来好处。2 .确认BPM试点项目一旦确定了BPM项目的轻重缓急，就应当选择针对某个部门的特定项目作为正式行动前的试点。成功的项目试点不仅会证明BPM的成功，还有助于证明有必要在整个企业扩大部署策略。因此，所选择的试点应当直接支持企业最紧迫的战略目标，提高客户服务、更快地推出新品，缩短流程时间帮助企业获得竞争优势。3 .成立亲合团体组织需要有精心设备、分阶段进行的部署计划，还要考虑到有缓急之分的BPM项目以及有密切关系的亲合团体(affinitygroup)o亲合团体是指共享流程、文档/文件和数据的部门。譬如，有着共同管理职能的几个部门，如财会、营销和客户服务部门。这些部门或者业务单位可以重复使用流程的相同部分，从而能够获得跨部门的流程效率，降低实施、支持及培训成本。亲合团体里面的主要部门实施BPM应用系统后，它可以指导实施类似应用系统的下一个部门。这种方法促进了整个团体共享流程自动化知识。4 .进行必要的组织变化成功的企业BPM策略可能需要报告职能关系和对职责方面进行调整，事先进行这种改变很重要。如：BPM策略会影响多个系统和应用软件，包括ERP系统、财务应用软件、内容管理系统以及集成服务。BPM策略还需要改变人们的办事方法以及使用系统的方法，即使核心流程根本上没有变动。今天准备谈下BPM业务流程管理系统的建设和实施方面的内容。首先还是从BPM的基础概念入手进行介绍，然后重点解释下BPM和工作流引擎的区别，最好谈下BPM软件的应用和实施场景。企业JKg福告理合日偿覆密S芸灼订空处理住产解IflBE ½7=W)设备售理人力资源5JH.计划&83B Accounts ReceivableMgmt/ DSO Expense Management. Accounts Payable Invoice Matching发的由fit.借款亩批BPM业务流程管理概述 ?sw.新员工人服、员工奢SP 先效考核 鳍申请 员工信息充更值感科技市场, Lead Ttackina & Fulfiknent Campaign Management S9cifflEvwt Management & RegtStrdt)On Trade Spena1Expense Mgmt网站内答发布价格申谙新增客户处理流程客户刎客户投诉/服努管理客户若通做事件8KS&扁决IaUeTracking & Resolution客户画流程遍布企业生产管理的各个领域和层面 HelpDesk 项目计划&管理 ResourceAiiocatton *Tme&Billing' AppiicatjonManagement 巡员工安置 员工离职处理业务流程管理是将生产流程、业务流程、各类行政申请流程、财务审批流程、人事处理流程、质量控制及客服流程等70%以上需要两人以上协作实施的任务全部或部分由计算机处理，并使其简单化、自动化的业务过程。20世纪90年代，MichaelHammer和JameSChampy的成名之作公司再造（ReengineeringtheCorporation）一书在全美公司领域引发了一股有关业务流程改进的汹涌浪潮。这两位管理学大师在书中展示了这样一个观点重新设计公司的流程、结构和文化能够带来绩效上的显著提高。但是由于缺少对变革管理以及员工变革主动性的关注，在很多致力于把他们的理论付诸实践的公司身上产生了反作用的结果。而如今，公司再次把业务流程管理这种通过分析、建模和监控持续优化业务流程的实践，当作一种解决业务难题和帮助公司实现自己财务目标的系统方法。业务流程管理（BusinessProcessManagemenLBPM）不是一个新概念，甚至不是一个新名词。它是从相关的业务流程变革领域，如业务流程改进（BPI）、业务流程重组（BPR）、业务流程革新中发展起来的。流程管理技术也是从早期的工作流管理、EAk流程自动化、流程集成、流程建模、流程优化等技术中发展起来的。从管理理论或战略的层面看，业务流程管理（BPM）就是在一个存在内部事件和外部事件的环境中，由一组相互依赖的业务流程出发，对业务进行描述、理解、表示、组织和维护。从具体实施的层面看，BPM还可分为流程分析、流程定义与重定义、资源分配、时间安排、流程管理、流程质量与效率测评、流程优化等。GartnerInc,给出的BPM的定义是：BPM是一个描述一组服务和工具的一般名词，这些服务和工具为显式的流程管理（如流程的分析、定义、执行、监视和管理）提供支持。上LWM之出？(Portal, SOA. IDRS, LDAP. EAI, E-mail. ITSHK)真实的业务洞g都是跨系桀跨组织跨应用的业务流程管理是跨业务组织结构，跨业务系统，跨应用的软件和方法论,从而实现自动化管理,优化动态业务,产生真正的业务价值。更多体现的是跨业务域,端到端业务流程的管理和整合。BPM和HWF人工工作流引擎企业信息系统构建本身就应该遵循流程分析，业务建模，子系统划分，系统功能建模的逐步分解过程。由于企业内职能部门的划分，而业务系统往往又需要一个归宿的主导部门，在企业发展大后一个业务系统也很难完全支撑到企业所有业务流程和业务活动。因此不可避免的导致了企业在各个业务域衍生了多个业务系统，业务系统主要实现价值链的一个核心业务域，但是业务系统必须要整合和集成才能够满足端到端流程的整合。端到端流程整合出现断点或流程不畅通，一方面是业务系统本身的分解有问题，一方面则是业务系统之间集成有问题，业务部门各自为阵导致了系统集成这种中间地点没有一个主导部门去管理和负责。业务系统本身分解问题主要体现在没有一开始就从企业架构和应用架构出发来考虑业务系统建设，业务系统建设不是从上向下的，而是完全根据业务部门需求各自建立。系统间集成问题则主要体现在了完全不考虑集成的标准规范，集成的方式，集成本身的可复用性，导致大量重复建设。流程建模遵循高端建模逐层分解的思路，高端流程往往正是我们关注的业务流程，高端流程跨越了多个业务域，多个业务活动，多个业务对象和单据实体，最终完成了一个端到端业务。如供应链端到端，涉及到采购需求，采购计划，采购策略和实施，采购订单，采购执行诸多环节和业务对象。高端业务流程中采购订单生成只是一个业务活动或子流程，而采购订单制作和生成本身又需要根据订单类型或金额设计不同的审批流程，而采购订单拟制后的审批流程才是我们经常所说的工作流，人工工作流或审批流。 跨系统:工作流引擎一般不跨系统，BPM则会跨多个业务系统 单据:工作流引擎针对单一业务对象单据，BPM针对端到端流程中多个单据 节点类型:工作流引擎一般只包含人工节点，BPM包括人工和业务自动节点 流程:工作流引擎一般针对三到四级流程，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和实际的业务系统仍然是脱节的。 实施范围：既支持业务单据审批流，又实现端到端流程整合和协同管理 实施效果：管理者可以对业务端到端全流程监控，流程本身分解支持逐层下钻 实现关舞：打破原有业务系统内流程概念，可以实现跨业务的流程触发和驱动任务触发,流程驱动,全程控制,智能交互业务端到端流程1.evel2-单据审批流层BPM重点是流程整合，而流程整合是多个业务系统中多个业务功能模块之间的协同，如果一开始想用BPM去实现这些业务功能，那么往往是适得其反，BPM切入的第一步仍然是在于跨业务系统的流程集成，而流程集成重点又在于流程间的数据传递。知道这个重点后BPM的关注点应该放到流程协同和监控上,而子流程或某个独立的业务模块实现仍然在原有的业务系统中，通过端到端流程整合实现了业务模块之间的系统，这个一方面最大限度的利用了已有的IT资产，又实现了流程整合的需求。业务流程整合一定是涉及到自动化的业务流和人工工作流，原有的BPEL很难融入HWF导致BPEL只能应用到流程整合的一些点上而无法真正实现理想状态下的流程编排，最多算上服务编排。而引入人工工作流使BPM有了做端到端流程整合的能力，但是已有业务系统已经有工作流引擎或审批流实现，要完全抛弃已有的流程引擎又是一个很麻烦的事情。那是BPM来整合已有的流程引擎，还是流程引擎引入BPM的关键要素又成为一个需要考虑的问题。BPM之所以困难，不在于思路上，而在于实践和落地上，如果是全新构建业务系统还好办，特别是已有业务系统的IT环境改造。即使实现了流程整合，那么流程整合后的责任部门是谁？流程整合后对已有业务系统有哪些影响都需要考虑，而不是简单的想流程整合后放到门户系统了事。HWF人工工作流引擎在这里先谈下我们常说的人工工作流引擎，这个其实是现在大多数应用系统都必须具备的基本业务管理功能。正是由于每个系统都需要该功能，那么每个系统如果都单独建设必然带来重复的成本投入，同时带来了各个业务系统间的工作流交互标准语言不统一。在谈企业私有云PaaS平台建设的时候我们谈到了，基于平台+应用的构建思路，企业流程平台作为底层技术平台统一建设。企业内部的统一流程平台建设，不仅仅是功能的迁移，更加重要的是数据的迁移，对于流程来讲我们所说的数据即是流程建模数据和流程执行数据的迁移。在统一流程建模和统一流程执行的基础上，提供统一的流程监控和流程绩效管理。很早我们就在谈流程不能脱离组织，岗位角色，权限等基础而存在。进行组织，人员，岗位权限等基础主数据的管理和整合又是建立内部统一流程平台的基础。因此我们可以看到内部的主数据管理，组织引擎和权限引擎等内容。这些都是为流程平台做准备。流程建模全统一在统一流程平台进行，因此BPM需要有统一的组织，人员和权限数据，这是各个系统能够完全互通的基础。在流程建模的时候，不仅仅涉及到常用工作流模型中的串行，并行，条件分支，聚合，子流程，回退等基本流程功能。更加重要的我认为还是流程活动节点和组织权限内容的结合，否则流程很难适应组织权限调整带来的影响和变化。粗一点的流程建模可以只控制到表单级权限，而细化点的流程建模则可以控制到表单输入的每一个数据项的权限。流程活动节点往往很多时候都具有条件判断，条件判断往往又涉及到外部调用，因此流程活动节点支持脚本代码的编写，支持对外部接口和服务的调用又是最基本的功能。工作流产品本身的设计包括了静态数据建模和动态数据建模两方面的内容。涉及到流程模板，活动节点，连接弧，分支判断，流程图形化展示元数据等多个方面的内容。动态数据建模又涉及到流程执行实例数据的记录，这方面的内容后续单独描述。流程平台用户点面流程客户端BPS Studio业务潦程定制与管理业务流程建模/定方口【流程测试与蛉证L流程部署业务表单模拟|服务库管理I环节库管理潦程业务规则引孥BusinessProcessServerKernelDeve-Oper 一 -nor-aceWorkflowEngineOrg-UserInterfaceRuntimeEnvironment/SCAContainer海界SS控分析OQCO- -OJ6OC-统一流程平台需要实现的就是统一流程建模，统一执行和统一监控，只要是涉及到流程建模和执行的数据都不在原有的各个业务系统中，而是全部集中到统一流程管理平台进行管理。按这个思路自然带来新问题即BPM系统如何与原有的业务系统集成。业务系统和BPM的集成最佳的效果就是对于用户感受不到BPM系统的存在，不能因为系统内的集中化和云化带来用户使用上面的差异。简单点的描述,使用具体包括如下几个方面的内容：1.各业务系统单独的多租户账号登录BPM系统，进行系统流程建模，BPM系统已有在各个业务系统完全统一的组织，用户和权限数据。这个不统一BPM系统无法真正落地。2.在流程建模完成后，对于每次流程建模系统会建立单独的流程模板ID供业务系统使用。3.业务系统各业务表单使用统一的流程启动接口调用BPM系统提供的服务启动工作流。4.BPM系统中的流程待办，流程已办，流程处理等各个关键业务功能用UI组件的方式形成UI组件后内嵌到各个业务系统中使用。在这里又需要企业内业务系统间实现统一认证和SSO单独登录。5.BPM系统提供流程执行，流程监控，流程查询等多个服务接口供业务系统使用。USW 5tfi 9 *999«fi¾ . RM - . H±MM 心丽31 gt%a?ms日班丽” QMnbB 卿I»««： Mt S KU :史SW.>sftite*icMx*suVB2oi3-m-29 2g 上 w½awu8avnax>u»» imG)RrHIWRStE848ffKS2011SXlia4 Q9%Skt*MXK' MKBBjg二JOB <a 10 1J51统一流程平台首先要实现的是替代原有业务系统内的人工工作流引擎，实现 流程的统一管理，同时在组织，用户和权限集中的基础上，形成系统基础管理, 权限管理和流程管理的通用语言。这样就很容易过渡到跨系统间的流程整合，在这种情况下的跨系统流程整合 只需要再考虑如何与标准的BPEL进行集成，使流程整合即具备人工审批流节 点，又具备根据业务规则自动进行处理和流转的自动化业务节点。基于工作流引擎的接口服务集成源程启动服务 流程终止服务 待办专询服务 状态查询服务 流防史苴询 工作要派服务 任务指派服务 权限设M服务ESB集成平台业务组件和工作流的集成包括了服务集成和界面集成两部分的内容。对于服务集成则是将工作流平台组件提供的工作流管理能力服务统一接入到SOA服务总线，并供业务组件在使用时候调用；对于界面集成主要是对于工作流平台实现的可复用界面直接通过单点登录的方式进行集成。对于服务集成，主要包括的接口服务有：启动进程StartprocessInstanceByQueue获取实例信息getProcessInstance静态启动工作流createProcessInstance进程查询IistprocessInstance删除进程实例deleteProcessInstance在与流程平台的集成中，一方面是通过流程平台暴露的服务接口进行程序集成；一方面是通过流程平台提供的标准Ul组件进行界面集成。可以看到对于待办，已办，流程监控等核心界面不适合下放到各个业务组件自行开发，而是应该通过抽象后统一有流程平台来实现，业务组件在使用过程中通过界面集成的方式进行嵌入。具体可以考虑的界面集成内容主要包括：我的待办和我的已办功能集成图形化流程查看界面集成流程监控界面集成（暂停、重启、终止、完成）流程流转和处理信息界面集成任务处理信息界面集成BPM和HWF人工工作流引擎很早以前在谈BPR业务流程重组的时候，其要点就在于打破职能部门界限,形成跨越业务职能边界的端到端流程。而对于BPM同样道理，即在业务职能部门各自为阵建设自己业务系统的情况下，需要跨越业务系统边界进行端到端业务流程的整合。BPM首先是一个公司管理问题，其次才是一个业务问题，其次才是一个系统问题。抛开了业务和管理，企业本身组织架构和战略来谈BPM基本都是无法落地，有时候期望通过BPR和BPM来改善公司管理和组织也是适得其反。根深蒂固的职能部门边界，利益和绩效KPI不可避免的会导致流程割裂，业务流程衔接点成为三不管地带，没有谁来关心端到端流程，更谈不上来系统化思考全流程的优化和改进。在这种情况下出现了流程管理部门，专门负责公司流程改进和优化，流程管理部门独立在业务部门之外，这种情况下虽然可以全局的思考流程问题，但是流程优化结果如何落地，流程管理部门不存在具体的业务KPh而各业务部门有各自利益，虽然有很好的流程优化和改进，但是没有强有力的执行力仍然难以解决落地问题。组织，战略和业务目标来推动业务流程改进，业务流程改进推动IT的建设,流程和IT融合，IT建设和实施过程中又进一步固化流程，通过IT系统的建设和实施加快流程和标准规范的落地。先固化，再优化，持续改进。华为公司推行实施的ISC和IPD,中兴推进的HPPD和项目化运作基本都是这种模式和思路。在面对市场竞争需要快速高质量交付的时候，必须有整合高效的端到端流程，在端到端流程下没有割裂的部门，更没有割裂的系统。BPM的推进和建设任重道远，因为其本质是一个业务问题，而非系统问题。BPM系统实施的两个层面阶段1阶段2阶段3阶段4阶段5对于BPM软件前面已经谈到过一定是包括了自动化的业务流和人工工作流引擎两部分的内容，同时为了更好的处理在业务流程建模中的业务规则往往还需要有单独的规则引擎子系统或模块。一个完整的BPM系统往往包括了流程建模和设计，数据建模，界面设计，基础数据和权限设计，流程执行和监控，流程仿真，流程绩效评估多个方面的内容。由于BPM主要完成的流程组合和编排是是整个SOA架构的上层内容，因此一个完整的BPM系统设计和构建本身就是组件化和SOA服务化思想进行的。对于BPM软件的实施,我们从通过BPM系统全新构建业务应用和基于BPM系统进行流程整合两个场景来讨论BPM软件实施过程中的异同。Ol-全新构建业务应用一个完整的BPM系统本身就可以理解为一个既开放，又相当封闭的SOA架构平台。开放主要是说该系统能够很好的集成和复用已有的SoA共享服务能力，封闭则是说BPM软件可以从设计建模，到测试，到部署上线端到端的完成一个业务应用的构建。可以看到全新构建业务应用相当来说反而容易，这个时候没有和企业内部遗留IT系统集成和协同的麻烦。在这种情况下4A基础数据完全可以以BPM系统为最初的源头，很多跨流程的业务单据信息也直接在BPM系统中进行建模和设计。对于界面和展现即完全利用BPM软件本身提供的一整套快捷开发工具进行,本身也不存在单独构建一个IT系统时候还需进行基础技术框架构建的问题。但是在这种场景下构建BPM,仍然存在一些问题无法解决，具体包括如下：首先对于业务系统，我前面分过类，即以工单和流程驱动的系统，还有就是以核心共享数据为基础驱动的系统。前者类似0A,ITIL类业务系统；后者类似资产，资源管理等系统。注意对于后者我们期望的一个完整的全局数据模型，这个数据模型往往会应用到多个业务流程中，而不是简单的工单。在这种情况下采用BPM软件是能够实现完整的业务功能的。因此BPM更多的还是适用于流程驱动的业务应用。其次，通过BPM软件构建出来的系统往往是跨越了多个业务部门的一个端到端业务流程管理，在这种情况可能并不会再具备原有的项目系统，采购系统，物流系统等严格的业务系统划分，而是这些业务都完整的实现在了一个短到短的业务流程上。那么这个BPM系统的业务管理和责任部门是谁？这个时候我们往往找不到一个主导的责任部门，那么这个BPM系统后续如何推广实施？靠IT部门的力量往往是很难真正落地的。这也是我们常说的BPM系统的推广难点已经不在技术上，而在于业务上。最后即使是流程驱动的业务系统，如果期望通过BPM软件提供的功能完全通过可配置和可视化设计的方式完全实现出来还是存在困难，即使有相关的规则引擎，但是仍然很难做到完全可配置的快速开发。这就自然涉及到了即使全新构建BPM系统，在BPM的底层仍然需要有实现核心能力和业务组件和技术组件，这些组件重点变成提供领域服务能力，而不是前台界面展现和协同。这个点必须要意识到，否则容易理解为BPM是万能的，啥流程都可以很简单的建模和配置设计出来，那就大大的犯错了。02-遗留系统通过BPM来整合场景这个相当于前者来说往往更加困难，困难点就在在于期望通过BPM来解决原有的端到端流程中的协同断点，同时又需要最大化的保留历史遗留系统的IT资产。大家看SOA架构好像觉得这个问题已经很简单的解决了，即历史的遗留系统都会识别为组件，组件应该将遗留系统的业务和数据服务能力提供出来，然后通过BPM层对服务进行组合，服务进行编排，形成一个端到端的完整流程。但是这个本质问题还是BPM和遗留业务的关系问题。如果基于BPM是来实现一个完整的端到端流程，这个端到端流程在构建过程中确实可以调用遗留系统的服务能力，但是这个端到端流程是否涉及到单据和数据的产生，是否涉及到人工流程的处理？如果流程会产生单据和数据信息，那么根据原有IT架构这些业务单据仍然应该产生和存储在IT系统而不是BPM系统，对于人工流程的处理同样的道理，仍然应该是在原有业务系统中统一处理而不是在BPM系统。这个一分析清楚我们就容易理解，遗留系统场景下BPM进行整合，不能凭空的再找出一个BPM系统出来，BPM的重点是将原有业务系统中的单据和流程整合和集成起来，而不是替代原有系统的能力。最终集成的效果可以通过Portlet形式展示到门户，而不是新增加一个业务系统。把这个理解清楚了，就清楚在这种场景下BPM实施的重点应该是由业务系统提供完整的领域服务层能力出来，而BPM重点是来统一实现界面层和展现，实现各个业务系统中服务能力的组合。即使在这种情况下都还需要考虑如何解决门户层应用功能和原有IT系统间功能的统一工作台展现，这个问题没有解决好就会变成业务部门人员需要两处处理业务，现在在实施层面是很难推广的。还有就是我看到，实施BPM有个很重要的内容，就是4A系统或者叫模块的实施，以及原有的工作流引擎是否已经成功实施。如果这些没有实施，那么BPM将作为为4A和工作流的基础支撑,如果已经实施那么就存在如何同步原有的4A数据，是弃用原有各个业务系统不统一的流程引擎还是保留资产进行整合的问题。对原有的IT资产保留的越多，你会看到BPM本身在实施过程中能够用到的能力越是减少和退化。那么对于一个己经相当成熟的内部IT来说，BPM还存在哪些价值和意义。针对这个问题，我前面也有文章谈到过，在这种场景下BPM的价值重点体现在两个方面。第一个方面是通过BPM来实现端到端流程执行的监控和流程绩效评估，注意这本身在完整的应用架构里面就是在执行层上面的事情，这样可以减少和已有的业务系统之间的功能性冲突。第二是对于企业内部的很多职能管理部门，如审计部门，风控部门，流程管理部门等，这些部门本身不承载核心业务价值链上的单据产生和业务，而重点是基于已有业务系统能力进行的IT管控和治理，因此对于这些部门新建设的业务系统是最适合通过BPM工具来完成的。对于BPM本身在进行流程建模设计的时候，也要注意到最好采用子流程的模式进行分层建模和设计，即对于BPM流程的顶层重点是自动化的端到端业务流，而对于下层才是人工审批流流程，否则一个完整的端到端BPM流程将很难进行后续的执行监控。当前很多企业就IT成熟度来说都没有到能够理解和实施BPM的程度,这也是为何很多企业的BPM实施仅仅变成了一个企业内部的统一工作流引擎平台实施的原因。BPM系统实施演进思路对于通过BPM工具并结合服务层来实现端到端流程监控这个话题，前面文章已经提到过了，这个相当来说比较容易实现，即这种最终编排出来的BPM流程视图更多的都是通过服务读数据而不会涉及到写操作。同时原有的各个业务流程还是在各个遗留的业务系统里面，对业务系统本身的改动也相当较小。那现在的问题还是，对于一个完整的业务能否全部依赖BPM产品提供的能力来实现，各个大型厂家的BPM产品基本都覆盖了流程建模设计，流程执行监控，Ul和权限建模等各个方面的内容，基本已经是一个完整的基于