《中国移动管理信息系统统筹规划BPM整合专题研究.ppt》由会员分享，可在线阅读，更多相关《中国移动管理信息系统统筹规划BPM整合专题研究.ppt（45页珍藏版）》请在三一办公上搜索。
1、中国移动管理信息系统统筹规划BPM整合专题研究,2010.3,2,目录,BPM整合的建设思路和切入点,业务流程承载的整合分析方法,II,III,业务流程承载现状及问题分析,I,业务流程整合现状,3,但在实际流程支撑中，很少看到完整的端到端流程，流程散落、功能重复、缺乏衔接。,在MSS规划中，已经制定了战略管理与决策支持、计划与项目管理、供应链管理、财务管理、人力资源管理、企业综合管理六大业务流程领域。,仅战略管理与决策支持、计划与项目管理、供应链管理这三个业务流程领域就有40个左右的四级流程，ERP领域、企业综合管理领域会有更多的业务流程，相加超过数百个。,流程需要得到整合，但该如何去分析、整
2、合、承载和建设，还有很多的疑问要探索解决。,六大业务流程领域,数百个四级流程,很少端到端实现,很多整合疑问,4,应用系统及流程引擎建设现状（以某省为例）,计划与预算管理,人力资源管理,财务管理,供应链管理,门户（Portal）,ERP接口平台,计划与项目管理系统（在建）,战略管理,物资采购管理系统,ERP财务核心,银企互联,管理决策支持系统,OA/邮件,文档管理,档案管理,办公资源管理,合同管理,综合统计,全面预算管理系统（在建）,报账平台,ERP人力核心,绩效管理,人力自助,薪酬（在建）,BPM,统一信息平台,综合分析与决策支持平台,ERP平台,统一支撑平台,ESB（在建）,已建,在建,法律
3、风险管理（在建）,科技创新,图例：,工作流引擎,5,流程引擎使用详细现状（以某省为例）,10个不同的流程引擎，涉及厂家9个，启用流程引擎8个，闲置2个 10个不同的流程引擎，6个自主研发类，3个套装平台类，1个公文流转类,6,BPM的建设使用情况一瞥（以某省为例）,现有BPM产品使用中主要存在的问题,BPM定位不清晰：目前某省已使用了一套BPM产品，但并未发挥MSS域企业级业务流程管理平台的作用，未明确BPM与应用工作流的角色和职责。流程平台产品集成能力较差，无法有效支撑跨应用流程衔接：当前BPM产品平台的异构系统的接入扩展性较差，且开发难度大、成本较高，目前其上承载的仍然是应用内封闭的专业业
4、务流程。MSS域内基本上未建设跨应用跨领域的整体流程，应用与应用间的流程衔接多半靠手工异步操作。,举例,目前BPM只接入了少量综合管理类系统，且并未整合流程。,档案,办公,合同,项目,采购,合同,BPM使用现状,BPM未承载跨系统流程,问题分析（一）：跨应用的流程的衔接严重不畅，无法形成端到端流程,7,以业务需求线条规划的业务系统通常特别关注业务功能的实现，而在业务流程贯穿及业务协同方面关注较少。,为什么跨应用流程衔接不畅？,业务部门在应用建设发展的初期时，往往更关注其对部门职能的支撑，而对企业流程和部门协作较为忽视。各应用系统的建设均是从自身立场和角度出发，未从企业级流程的角度审视业务流程在
5、IT系统中的承载，造成流程以系统边界分裂。各应用系统往往都自带流程引擎，与自身应用耦合相对较紧，也不具备实现端到端流程的能力。,跨域跨应用流程,跨域跨应用流程,系统平台,系统平台,系统平台,系统平台,.,阻隔,阻隔,阻隔,阻隔,【项目立项流程】：项目立项流程与采购执行未衔接,【物资采购到货入库流程】：PLIS中的订单接收与ERP中的订单接收未衔接,问题分析（二）：工作流引擎能力重复建设，没有得到汇聚和统一,8,为什么重复的能力没有得到统一？,以目前的支撑情况来看，业务流程活动还存在较多的手工交互，这些在系统范围外实现的活动存在较大的不确定性。由于多个应用系统都有自己的流程引擎来支撑自身的业务流
6、程流转，这些流程引擎都会有一定的功能相似性，比如都具备人机交互能力，但实现又各不相同，用户体验也各不相同。目前如果应用系统需要实现跟外围系统的流程衔接或交互，往往都是自行通过接口建设的方式与对端交互，规划不一模式不一标准不一。,在某省已知的十个工作流引擎中，每个引擎都是具备工作流基本工作功能的，每个引擎都可以实现流程流转、人机交互（Worklist/审批等），也存在大量的应用交互模式。以人机交互为例，各个应用系统中都具有审批流程的能力，各个应用系统中也都具有人员待办的活动节点，且如此大量的人机交互能力散落在各应用系统，也必然导致各应用系统对用户角色组织信息的配置和同步要求。,应用系统1,应用系
7、统2,应用系统N,流程引擎1,流程引擎2,流程引擎N,审批流,应用系统3,流程引擎3,审批流,审批流,审批流,问题分析（三）：繁多的流程引擎采用的技术标准不一，实现程度不一，使用方式/用户体验也各不相同,9,为什么使用的流程引擎繁多且标准不一？,随着多年来的技术发展，流程引擎也经历了一系列变革，概念从Workflow走向BPM，标准规范繁多诸如WfMC/XPDL、BPEL、BPDM等等。随应用一起建设的流程引擎，往往与应用系统本身耦合较紧，不具备通用的流程平台性质，只能上一个应用系统附带一个流程引擎。大量系统的建设，存在大量厂商的参与，而不同厂商对流程规范/标准的遵循程度、实现程度、以及提供的
8、使用方式，都各不相同。,在某省已知的十个工作流引擎中，使用SOA/BPEL流程标准的1个，使用WfMC/XPDL流程标准的5个，自设计未使用技术规范标准的（含套装封闭流程引擎）3个，文档流程类型1个。这些工作流引擎互相间较难实现衔接、结合和集成，即使是都是使用WfMC/XPDl规范实现的引擎，它们之间也没有很好的办法直接进行流程集成。即使是使用同一种标准实现的工作流引擎，如采购物资和ERP扩展使用的工作流引擎都是基于WfMC/XPDL标准实现的，各自对引擎能力的建设程度也不一，局限在满足自身应用需求，使用方式和API也各不相同。,标准不一，较难结合,引擎功能实现程度不一，使用方式也各不相同,整
9、体解决思路,10,从现状、需求和使用问题入手，审视BPM整合这个系统工程；从规划和计划的层面，提供规范、方法、建议、样例等的统筹支持；从建设改造方面，启动BPM整合的试点工程，着手解决具体问题。,11,目录,BPM整合的建设思路和切入点,业务流程承载的整合分析方法,II,III,业务流程承载现状及问题分析,I,流程对象解析,12,流程流转的总体控制、流程活动的调度、状态的记录和更新等等的工作在哪里做？,流程活动/子流程等的处理和计算工作、工作任务的派发等的具体工作在哪里做？,人工审批、处理、操作界面，流程的查询和展示界面等等这些又该在哪里做？,流程是一系列业务活动的串接，在信息化的今天往往通过
10、相关技术以端到端的方式处理业务事件及管理必要的资源。流程具体要落实到信息系统中，需要有良好的业务与技术相结合的设计，并且弄清楚以下三个方面的问题。我们目前正在谈论的BPM整合，也需要从这三个方面去审视去整合。,明确流程如何落地如何运转，推进后一步具体设计,流程流转在何处控制？,流程活动具体在哪里做？,流程界面在哪里体现？,流程整合分析方法框架总览,13,流程承载整合的分析方法,BPM,应用,当前MSS业务流程已得到梳理和规划，下一步即要对流程进行设计执行层面的分析，结合BPM整合平台，给出流程具体整合承载的高阶设计，进而指导和推进流程的落地实施。方法的目的和意义:该整合分析方法，将从一般性的流
11、程设计入手，经过一套规范的流程和完整的分析，得出整合后的、带流转/活动/界面承载指导的、结合BPM平台可具体落地的新型流程设计。此方法的实施将把BPM整合工作落到实处，理清流程各层面的关系，有效指导后续工作的展开。方法中将定义的内容：确立分析的原则和阶段；制定分析方法的操作步骤；设定说明各种判别的条件和准则；给出具体的操作示例；,业务流程执行原型,流程具体整合承载设计,方法框架总体说明,14,输入阶段,1.2.调研流程承载现状,1.1.分业务领域设计业务流程的执行原型,分析阶段,2.2.判别流程子段具体承载,2.1.输入流程切割,2.3.服务抽象，流程重新拼装,2.4.用户体验判别,输出阶段,
12、1.2.整合后的流程承载落地,1.1.流程服务化设计,方法制定的原则：以方法的可操作性、输出结果的可落地性为指导方针；以流程整合、平台统一、能力复用、应用与流程引擎解耦为方法操作准则的导向；,流程整合分析方法将大体上划分为三个阶段：输入、分析和输出阶段。并进一步深入地在每个阶段规划具体的工作步骤，明确每个步骤的输入、输出、运作流程等等。,输入阶段：设计和整理业务流程的执行原型及承载现状,分析阶段：通过一系列步骤将流程执行原型加工为整合承载设计,输出阶段：用流程整合承载分析结果指导后续的技术设计及实施,对输入阶段的阐述,15,战略 计划项目 人财物 综管,输入阶段,1.2.调研流程承载现状,1.
13、1.分业务领域设计流程,输入的范围：按业务领域分，战略、计划与项目、供应链、人力资源、财务、综管六大业务领域的部分或全部流程。按流程类型分，申请审批类、业务处理类、管理管控类的流程更适用于流程整合的分析。公文流转类、信息发布类的流程优先级稍低。准入的标准：该方法要求的输入是流程执行设计模型构建的流程设计。偏业务操作的四级EPC流程设计是不适用的，因为输入的流程必须带有一定的技术实现性，可判断具体系统承载的。例如BPMN样式的流程设计。同理，要求现有已承载流程的输入也是执行模型的，若无可反向设计得出。,申请审批类 业务处理类 管理管控类,输入,方法使用示例：输入阶段,16,合同传送,订单录入,合
14、同签订,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,订单同步,S,End,物资采购的业务流程执行原型设计（示例）：,已实现承载的流程子段梳理：,发起请购,各级领导审批,PLIS,OA,合同,订单录入,合同签订,寻源谈判,上会决议,形成商务报告,手工在处理的流程子段：,合同传送,订单同步,目前合同通过手工录入至PLIS,目前订单需要在PLIS和ERP中两次手工录入,注：此示例的设计不一定最优，仅供参考,分析阶段步骤一：,17,分析阶段,2.2.判别流程子段具体承载,2.1.输入流程切割,2.3.服务抽象，流程重新拼装,2.4.用户体验判别,输出：,输入：,说明：,与已承载流程叠加,
15、切割未承载活动为单节点子段,已承载部分是否改造？,继续切割为单节点子段,保留已承载部分为一个子段,流程设计,已实现流程,输出流程子段,工作流程：,切割后的流程子段,流程执行原型及现有流程输入后，作为分析阶段的前序工作，需要对流程进行分割，分割为可判别具体承载的流程子段。输入为偏执行模型的流程设计图，以及现有在应用系统中已承载流程的流程设计图或反向设计图。输出为按照一定切割规则离散的流程活动或子段。,方法使用示例：分析阶段流程分割,18,合同传送,订单录入,合同签订,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,订单同步,S,End,与已承载流程叠加，并分割未承载活动,决定对子段1和
16、2进行改造升级，对其进一步分割,1,2,3,4,5,6,合同传送,订单录入,合同签订,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,订单同步,S,End,1,3,7,8,6,2,4,5,9,将分割好的流程子段作为输入进入下一环节,注：此示例的设计不一定最优，仅供参考,用颜色区分,分析阶段步骤二：,19,分析阶段,2.2.判别流程子段具体承载,2.1.输入流程切割,2.3.服务抽象，流程重新拼装,2.4.用户体验判别,逐个进行判别比对,子段合并调整,切割后的流程子段,承载整合判别矩阵,输出承载关系,流程子段承载关系矩阵,合并调整原则,在这个步骤中，将输入逐个代入到整合承载判别矩阵中得
17、出承载关系，并进行适当的合并调整，最终得到该步骤的输出。输入为上一步骤分割离散好的流程子段。输出为流程子段整合承载关系矩阵。,输出：,输入：,说明：,工作流程：,流程子段类型的分析,20,活动需要人工参与，各类审批。如会签、顺序审批、并行审批等。,需要人工录入信息或状态的活动节点。如起草合同、手工回退流程等。,不需要人工干预，依赖于应用环境的由业务系统自行计算处理的活动。如生成项目编号。,不需要人工干预，不依赖于应用环境的由服务器自行计算处理的活动。如数据类型映射。,串接在流程上的应用系统间的交互活动，一般为信息传递。如合同签订流程中，传递合同信息给ERP/PLIS。,流程子段整合承载判别矩阵
18、,21,注：在BPM整合的背景下，把流程流转总控都归总到BPM作为前提条件。当然也会存在流程子段的流转控制保留在应用系统的引擎上，通过服务串接到BPM。,除上一步骤识别为保留的应用已承载流程子段外，其余流程子段将分类型使用以下整合承载判别矩阵进行流程整合承载的判断：,流程子段合并调整原则,22,应用系统中承载的子段类型A,应用系统中承载的子段类型B,应用系统中承载的子段类型C,在上一矩阵中，已经分析了会在应用系统中承载的三种子段类型，我们姑且定义为类型A、B、C。,合并调整原则：若A、B、C类型的流程子段在流程过程中是连续出现的，则将其合并调整为一个流程子段。因其串接本质上会是应用系统的一个子
19、流程，将来也只会作为一个服务节点接入BPM。具体举例如右图所示。,A,B,C,A,B,C,B1,B2,B1,B2,子段1,子段2,合并调整为一个流程子段,合并调整为一个流程子段,子段1,子段2,子段3,方法使用示例：分析阶段流程子段活动承载判别,23,发起请购,各级领导审批,寻源谈判,形成商务报告,上会决议,注：此示例的设计不一定最优，仅供参考,合同传送,订单录入,合同签订,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,订单同步,S,End,1,3,7,8,6,2,4,5,9,方法使用示例：分析阶段流程子段活动承载判别（续）,24,合同签订,合同传送,订单录入,订单同步,上从分析表
20、中看出，并无两个相邻的应用系统承载子段，故不需要进行合并调整。,注：此示例的设计不一定最优，仅供参考,合同传送,订单录入,合同签订,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,订单同步,S,End,1,7,8,6,4,5,9,分析步骤三：,25,分析阶段,2.2.判别流程子段具体承载,2.1.输入流程切割,2.3.服务抽象，流程重新拼装,2.4.用户体验判别,输出分析后的流程设计,带承载整合分工的流程设计,流程子段承载关系矩阵,在这个步骤中，主要任务是将分析过的流程子段重新拼装成完整的、带承载关系的流程设计，并对非BPM承载的流程子段进行服务抽象。输入为流程子段整合承载关系矩阵。
21、输出为带引擎整合承载分工的流程设计。,输出：,输入：,说明：,工作流程：,将子段重新拼装成分析后的流程,对非BPM承载的流程子段进行服务抽象,方法使用示例：分析阶段服务抽象流程重组,26,PLIS,合同,OA/审批中心,合同签订,BPM,系统流转,外部流程服务,应用承载活动,BPM承载活动,服务调用,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,发起请购,合同签订,合同传送,订单录入,订单同步,订单录入,图例,注：此示例的设计不一定最优，仅供参考,分析步骤四：,27,分析阶段,2.2.判别流程子段具体承载,2.1.输入流程切割,2.3.服务抽象，流程重新拼装,2.4.用户体验判别,
22、带引擎承载分工的流程设计,界面承载判别矩阵,经过整合梳理可落地的流程设计,界面承载判别矩阵,在上一步骤中，已经得到一个相对完整的流程设计，在这一步骤中，将继续对展现层的承载进行判别。输入为带引擎整合承载分工的流程设计。输出为带界面承载关系、引擎整合承载分工的详细流程设计。,输出：,输入：,说明：,工作流程：,输出分析后的流程设计,对应用系统上承载的人工节点进行界面判别,对BPM上承载的人工节点进行界面判别,人工界面承载判别矩阵,28,一般来讲，只有人工活动才会有界面，服务器自动计算是不需要界面的。所以矩阵仅对人工活动进行分析。BPM作为一个后台性质的流程支撑平台，原则上来讲，其系统本身是不带流
23、程操作界面的。在后台流程流转和活动承载已经整合的情况下，前台界面的承载选择很多也较为灵活，下表供参考，实际判别可根据现实情况（如使用习惯、建设现状等）进行调整。,方法使用示例：分析阶段用户体验判别,29,PLIS,合同,OA/审批中心,合同签订,BPM,系统流转,外部流程服务,应用承载活动,BPM承载活动,服务调用,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,发起请购,合同签订,合同传送,订单录入,订单同步,订单录入,图例,发起请购,各级领导审批,谈判状态录入,附上商务报告,上会审批,合同签订,合同审批,无界面,无界面,人工界面,注：此示例的设计不一定最优，仅供参考,订单录入,对
24、输出阶段的阐述,30,输出阶段,1.2.整合后的流程承载落地,1.1.流程服务化设计,流程流转的技术设计（BPEL、XPDL等）,具体业务活动、人工活动、应用子流程的技术设计,流程/子流程/应用活动/人工等的服务抽象（Web Service）,统一审批、统一界面、各专业应用界面等的界面设计,到输出阶段，我们已经得到一个整合分析后的、非常详细的流程设计，下一步的工作即是对照分析结果进行细化和开发操作层面的设计，并进而进行落地实施承载。具体来讲，该方法输出的内容将对以下几个方面形成直接指导：1.流程流转的技术设计（BPEL、XPDL等）2.具体业务活动、人工活动、应用子流程的技术设计3.流程/子流
25、程/应用活动/人工等的服务抽象（Web Service）4.统一审批、统一界面、各专业应用界面等的界面设计,BPM,应用,指导下一步的工作内容,方法使用示例：输出阶段,31,注：此示例的设计不一定最优，仅供参考,按照分析输出的流程承载规划图，使用流程设计工具设计BPM上的业务流程流转。,按照流程承载规划图，规划应用系统的改造、设计相关服务抽象及服务串接至BPM流程,按照流程承载规划图，对BPM承载的流程节点进行服务设计和内部功能实现设计,按照流程承载图上对界面的规划，对相应的人工界面和交互体验进行设计,32,以下完整地重复一遍操作示例,方法使用示例：输入阶段,33,合同传送,订单录入,合同签订
26、,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,订单同步,S,End,物资采购的业务流程执行原型设计（示例）：,已实现承载的流程子段梳理：,发起请购,各级领导审批,PLIS,OA,合同,订单录入,合同签订,寻源谈判,上会决议,形成商务报告,手工在处理的流程子段：,合同传送,订单同步,目前合同通过手工录入至PLIS,目前订单需要在PLIS和ERP中两次手工录入,注：此示例的设计不一定最优，仅供参考,方法使用示例：分析阶段流程分割,34,合同传送,订单录入,合同签订,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,订单同步,S,End,与已承载流程叠加，并分割未承载活动,决定
27、对子段1和2进行改造升级，对其进一步分割,1,2,3,4,5,6,合同传送,订单录入,合同签订,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,订单同步,S,End,1,3,7,8,6,2,4,5,9,将分割好的流程子段作为输入进入下一环节,注：此示例的设计不一定最优，仅供参考,用颜色区分,方法使用示例：分析阶段流程子段活动承载判别,35,发起请购,各级领导审批,寻源谈判,形成商务报告,上会决议,注：此示例的设计不一定最优，仅供参考,合同传送,订单录入,合同签订,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,订单同步,S,End,1,3,7,8,6,2,4,5,9,方法使
28、用示例：分析阶段流程子段活动承载判别（续）,36,合同签订,合同传送,订单录入,订单同步,上从分析表中看出，并无两个相邻的应用系统承载子段，故不需要进行合并调整。,注：此示例的设计不一定最优，仅供参考,合同传送,订单录入,合同签订,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,订单同步,S,End,1,7,8,6,4,5,9,方法使用示例：分析阶段服务抽象流程重组,37,PLIS,合同,OA/审批中心,合同签订,BPM,系统流转,外部流程服务,应用承载活动,BPM承载活动,服务调用,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,发起请购,合同签订,合同传送,订单录入,订
29、单同步,订单录入,图例,注：此示例的设计不一定最优，仅供参考,方法使用示例：分析阶段用户体验判别,38,PLIS,合同,OA/审批中心,合同签订,BPM,系统流转,外部流程服务,应用承载活动,BPM承载活动,服务调用,发起请购,各级领导审批,寻源谈判,上会决议,形成商务报告,发起请购,合同签订,合同传送,订单录入,订单同步,订单录入,图例,发起请购,各级领导审批,谈判状态录入,附上商务报告,上会审批,合同签订,合同审批,无界面,无界面,人工界面,注：此示例的设计不一定最优，仅供参考,订单录入,方法使用示例：输出阶段,39,注：此示例的设计不一定最优，仅供参考,按照分析输出的流程承载规划图，使用
30、流程设计工具设计BPM上的业务流程流转。,按照流程承载规划图，规划应用系统的改造、设计相关服务抽象及服务串接至BPM流程,按照流程承载规划图，对BPM承载的流程节点进行服务设计和内部功能实现设计,按照流程承载图上对界面的规划，对相应的人工界面和交互体验进行设计,业务流程整合带来的变化和收益,40,流程平台将规范流程的运作模式和交互模式，给用户统一的使用体验。可真正实现审批待办的统一和集中，相应的用户角色配置也可集中，而不需各系统大量维护。后台工作模式的集中，将便利前台使用方式的丰富，随着接入渠道的扩展，用户将可实现随时随地办公。,整合的设计开发环境，降低学习成本，缩短开发周期；整合的运行维护环
31、境，降低运维管理难度和工作量；统一流程平台通过整合流程承载能力，逐步弱化甚至替换应用中各型各色的流程引擎，避免重复建设；,统一流程平台的建设工作，需要实现各类流程的集成，具有技术前瞻性；统一流程平台的建设工作，以流程集中承载为目标，具有可持续发展特性；BPM涵盖流程的全生命周期循环管理，促进业务流程的不断循环优化；,统一流程平台的强大能力将支持实现更多的业务流程在IT系统中的支撑；能力的集中和标准化的使用方式，将支持业务需求的快速响应和开发上线；实现企业级流程，实现部门间业务协作；业务活动监控将实现对流程KPI的监控和人员效率的展示；,提高管理效率,促进可持续性发展,降低使用成本,提升用户体验
32、,整合的设计开发环境,整合的运行维护环境,整合的监控优化环境,整合的流程辅助环境,变化和收益,41,目录,BPM整合的建设思路和切入点,业务流程承载的整合分析方法,II,III,业务流程承载现状及问题分析,I,BPM整合的建设思路,42,第一阶段,第二阶段,第三阶段,主要任务：参照集团BPM规范，以及后续的指导意见，评比选择合适的BPM平台产品；规划和建设BPM平台的基础能力，形成BPM的支撑服务层；规划和分析流程整合承载设计,建设BPM平台,流程整合，交互集中,最终实现流程平台整合,主要任务：实现流程活动的服务抽象和服务注册；实现流程活动对于系统间交互能力的集中；实现流程无边界，衔接跨应用跨
33、系统流程并统一承载；集中人工审批等人机交互能力，整合和提升用户体验,主要任务：弱化应用系统对于应用内置引擎的严重依赖，尽量复用流程平台的支撑能力；实现业务流程基本由流程平台统一承载；推进流程平台向云计算发展，提供流程SaaS服务,BPM能力的不断发展是实现流程整合承载的建设主线,43,业务流程在现实世界中是一连串有序的业务活动，需要多个人员甚至部门使用不同的工具配合完成。同样，实现流程在IT系统中的整合承载，需要多条线的建设努力：BPM统一流程平台的能力建设和发展，按照规划和演进，逐步建设和完善以达到流程的整合和统一支撑。业务应用的改造：业务活动节点对外的暴露和共享；改造应用为统一使用集中的流
34、程人机交互能力（统一流程平台提供或集中的人机交互节点）；逐步弱化应用系统中的内置引擎，统一使用流程平台能力。应用集成能力和SOA服务化工作的推进和深化：统一流程平台的建设，部分依赖于SOA的架构和ESB的建设。流程辅助能力的建设和发展：流程的完美支撑不仅仅只是流程的正确流转、业务活动的精确计算，也包括更多辅助能力如用户体验等方面的因素。,实现流程统一支撑的核心支撑能力是BPM平台，BPM平台的建设和能力发展是工作的中心。在建设和工程配合方面，以BPM平台的建设和发展为主线，规划BPM平台的方向和演进思路（后续章节阐述），分步建设。其它条线的建设工作依托BPM平台的发展和演进，相配合逐步展开。,
35、实现流程整合支撑需要多条线的协力建设,BPM能力的不断发展是建设的主线,该从什么地方入手,44,从衔接应用间流程入手,从集中人机交互能力入手,从建设通用流程引擎入手,从衔接应用间流程入手，建设BPM流程平台，梳理跨应用流程，并将其在BPM上实现,适用场景：业务应用系统建设已经齐备，具备一定的应用集成基础，流程衔接需求迫切,建设模式：梳理跨应用流程，将应用活动服务化，建设BPM平台实现流程衔接,风险分析：跨应用流程的梳理质量应用系统的改造程度和业务活动的服务化程度,从集中人机交互能力入手，建设BPM流程平台或人机交互节点，统一审批模式和能力或统一Worklist工作流任务模式和能力,适用场景：需
36、要统一审批功能和使用模式，或需要集成工作流任务待办,建设模式：规划审批能力模型或集中Worklist模型，建设具备相应功能的BPM平台，改造和迁移应用系统中的人机交互,风险分析：集成人机交互能力模型的合理性和通用性改造和迁移的工作量和工作难度,依托新建业务应用系统，从建设通用流程引擎入手，将该业务系统的工作流程交由统一流程平台承担,适用场景：需要新建某个应用系统的同时，打算建设统一流程平台，能将其二者的工作统一规划、统一设计和统一建设,建设模式：梳理该应用领域流程，搭建流程平台的通用服务能力，在可行可用的原则下尽量多地由通用平台承担流程工作,风险分析：技术较超前，完全实现有一定困难，在某些流程场景可能仍然需要使用到应用内置流程引擎,45,结束,Thanks,
