中国移动管理信息系统统筹规划BPM整合专题研究.ppt
《中国移动管理信息系统统筹规划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类型的流程子段在流程过程中是连续出现的,则将其合并调整为一个流程子段。因其串接本质上会是应用系统的一个子
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 中国移动 管理信息系统 统筹 规划 BPM 整合 专题研究
链接地址:https://www.31ppt.com/p-2939863.html