某省移动业务支撑系统业务与体系规划项目对业务需求管理和组织结构的建议.ppt

《某省移动业务支撑系统业务与体系规划项目对业务需求管理和组织结构的建议.ppt》由会员分享，可在线阅读，更多相关《某省移动业务支撑系统业务与体系规划项目对业务需求管理和组织结构的建议.ppt（31页珍藏版）》请在三一办公上搜索。

1、某省移动业务支撑系统业务与体系规划项目,对业务需求管理和组织结构的一些建议,目录,需求管理,需求管理的重要性,满足业务需求是业务支撑部门的主要职能之一支撑能力的强弱表现在需求的满足比率、及时性、合格率及需求的成本收益情况,业务支撑系统已经越来越成为某省移动的核心能力，业务的创新和改进已经离不开业务支撑系统的支持快速市场响应能力越来越成为市场竞争的制胜因素，实际上就是对新需求的快速支撑能力,需求管理的重要性表现在四个方面：,具体分析：,对业务发展产生直接影响,是业务支撑能力的重要表现,需求实现要投入大量的人力、物力、财力，需要加强成本管理需求实现的资源是有限的，需要加强需求质量控制和优先级管理，

2、确保“好钢用在刀刃上”。,需求实现是一种“稀缺资源”,全省集中的支撑系统必然要求全省集中、统一的需求管理，那么需求的实现将对全省的业务开展造成影响如何既能够满足省级业务需求能够统一、有效的在各地市推广，又可以及时满足各地市差异化的需求做好全省集中、统一的需求管理，需要省各业务部门、各地市分公司和业务支撑部门的共同努力,全省集中、统一的需求管理,需求管理的复杂性,需求来源多,多开发商管理,需求确认,需求分析,需求实现,需求评估,需求交付,需求产生,需求优化,跨多个知识域,涉及市场营销、移动业务、IT技术、通信技术、项目管理等多方面知识对人员的经验积累要求高,需求管理生命周期,多个开发商/联合体（

3、A、B）的协调、合作、考核、激励,BOSS智能网网站管理经分系统,需求管理的整个生命周期包括6个二级流程，25个三级流程（详见需求管理流程分析）,流程复杂,需求类别多,功能优化功能扩展新业务需求流程优化,沟通涉及到十几个部门/科室,多部门协同,集团公司省公司地市公司支撑部门内部,跨多系统开发,实现要求高,需求数量多要求快速支撑,从05年12月至06年5月，有65的需求提交超过1个月才进入版本，31超过2个月，5超过3个月实际版本的实现时间也往往超过预定时间有的需求从提出到最终上线超过5个月对需求管理各环节缺乏时间跟踪和评估,需求实现周期长,从业务的视角反映出需求管理中存在的问题,需求管理各环节

4、间，缺乏明确的职责定义和输出成果的定义，无法保证整个过程中对需求理解的一致性需求实现过程是“黑箱的”，只有在上线后，才暴露出开发结果与实际需求不符有时由于上线时间紧，不做测试或测试不充分，导致开发结果质量控制不严,开发结果与需求不符合,需求满足率低,近8个月来，各地市提出的需求占总需求的74，而进入版本的不到60排入版本的地市需求占比还在降低，前四个月（05.1006.01）占64，近四个月（06.0206.05）降到仅占50,地市差异化需求满足差,从05年12月至06年5月，省和各地市一共提出需求656个，进入版本258个，不足40广州市调研反映其需求满足率50，其它地市更低因为需求难以满足

5、，各地市已大幅减少了需求的提出,数据来源：省业务支撑中心AMS系统,存在问题,需求管理流程的具体问题分析,一级流程:,需求确认,需求分析,需求实现,需求交付,需求评估,需求优化,需求管理,二级流程:,需求描述不清楚，没有严格遵守需求说明文件，且需求说明文件的描述范围和详细程度等指标有待进一步优化需求申请后仍多次修改，需求确认往复多次需求申请没有成本考虑，所以往往提出的需求数量偏多需求没有投资收益分析，能带来多少价值不清楚需求优先级的确定没有衡量标准及责任部门，各业务部门往往夸大需求的重要性和紧迫性，有时依靠领导拍板,业务支撑中心资源投入不足，难以及时处理众多需求技术部门与业务部门之间缺少有效沟

6、通，存在理解的偏差，系统需求有时不能符合业务原来的要求技术部门与业务部门的职能划分上欠明确技术室对需求复杂度评估没有权威性，开发商在开发成本确定上相对处于强势对需求缺乏抽象、前瞻性考虑，导致开发零散，缺乏系统的规划,开发商的资源投入不足与开发商缺乏长期战略合作模式，开发商缺乏优化系统架构的动力开发商主要定位在系统开发、运营维护，对需求分析参与不足多个开发商间的职责划分尚不明确,没有完善的测试体系和完整的测试平台系统测试不充分，测试报告不全地市只能测试本市需求，不能测试全省范围的需求和对外接口需求测试资源不配套省提出的部分需求缺少与各地市的沟通，其适用性低，各地市推广积极性低,需求上线后缺乏正式

7、的交接过程，运维缺乏对需求开发质量进行评估缺少需求上线情况分析缺少业务运行情况、收益及问题原因分析,没有建立一整套的针对省、各地市、各部门及全员的“持续改进”激励制度没有真正形成需求管理闭环流程,各步骤具体问题分析:,为了保证需求管理的高效顺畅，需要从以下几个方面加以保证：,需求管理全程流程,需求确认,需求分析,需求实现,需求交付,需求评估,需求优化,二级流程,需求优化,系统架构优化,需求管理过程优化,业务模型优化,结束,需求提出,需求评估,收益/风险预测,需求提交,开始,需求调研,需求审计,需求管理流程,各方角色定位,控制指标和控制点,需求进行分类评估,开发商管理,开发、测试、生产三大环境分

8、离,三级流程,需求管理流程分解需求确认,需求提出,需求调研,需求评估,收益/风险预测,各地市提出地市需求省各业务部门提出的需求集团下发规范中的需求支撑内部提出完善的需求其它系统改造产生的需求,对需求实现后所能带来的价值进行预测分析，即收益分析对新需求可能存在的风险进行分析,业务部门对需求的重要性和紧迫性进行分析，评估需求业务优先级对需求的合理性、与其它业务的关联性、互斥性进行分析,对需求进行调研、细化，根据根据模板形成需形成需求调研报告，对需求进行详细描述,三级流程:,一级流程:,二级流程:,说明:,需求提交,确定需求是否需要实现（做还是不做），以及期望完成时间将明确的需求调研报告、需求评估报

9、告和需求收益/风险预测提交业务支撑部门,成果：,需求确认,需求分析,需求实现,需求交付,需求评估,需求优化,需求管理,需求申请表,需求调研报告,需求评估报告,需求收益/风险预测报告,需求提交表,需求管理流程分解需求分析,一级流程:,二级流程:,需求确认,需求实现,需求交付,需求评估,需求优化,需求管理,业务需求分析,系统需求分析,需求复杂度分析,需求版本制定,对业务需求进行细化，分析对现有业务规范的影响，并提出对业务规范的修改建议方案业务可扩展性分析，对类似需求进行合并、抽象,结合需求业务优先级评估和需求复杂度评估，进行需求排期，确定版本计划,对需求内容多少、难易程度、是否适合系统架构等进行分

10、析预测需求实现的工期和成本（工时）,对业务需求进行系统化分析，评估对现有系统架构的影响，并提出需求实现的初步建议方案,三级流程:,说明:,成果：,业务需求分析书,系统需求分析书,需求复杂度分析书,需求版本计划,需求分析,需求管理流程分解需求实现,一级流程:,二级流程:,需求确认,需求实现,需求交付,需求评估,需求优化,需求管理,设计,开发,系统测试,明确系统需求和业务需求，对方案进行设计对设计方案进行评审制定测试计划并设计测试方案,全面质量管理的一环，对开发结果进行系统测试，从技术层面上把握质量控制,制定开发计划及测试上线计划对需求进行开发，管理开发质量、进度,三级流程:,说明:,成果：,设计

11、方案方案评审表,开发计划测试上线计划单元测试报告,集成测试报告,需求分析,业务测试,全面质量管理的一环，对开发结果进行业务测试，从业务使用层面上把握质量控制,业务测试报告,正式上线,部署到正式环境进行测试，业务正式运行,上线测试报告,需求管理流程分解需求交付,一级流程:,二级流程:,需求确认,需求实现,需求交付,需求评估,需求优化,需求管理,三级流程:,说明:,成果：,需求分析,移交维护,系统培训,业务推广,将正式上线运行的功能模块或系统，以及全部相关文档移交给维护部门，由运维部门进行日常维护,新业务上线后，省和地市可以采取相应的新业务推广计划,对省和地市公司的系统相关使用人员进行系统操作培训

12、,移交确认文件需求上线通知单,系统培训计划,业务推广计划,评估需求完成的及时率、质量、故障率等，并查找原因，提出改进措施核算需求实现的实际成本业务部门评审需求是否达到预期目标,需求审计报告,需求审计,需求管理流程分解需求评估,一级流程:,二级流程:,需求确认,需求实现,需求交付,需求评估,需求优化,需求管理,需求分析,业务情况分析,收益分析,改进建议,对业务运营情况进行定期的跟踪、分析,对运营情况未能达到预期收益的新业务需求，进行根本原因分析（市场问题、需求实现的问题、业务推广问题等），并对此业务提出应对措施（改善、退出、保持等）,对需求的收益情况进行分析，并与需求申请时的需求收益预测进行对比

13、，评估需求提出的质量,三级流程:,说明:,业务运作情况分析报告,收益分析报告,改进建议报告,成果：,需求管理流程分解需求优化,需求优化,系统架构优化,需求管理过程优化,对某个或某类需求进行业务或系统层面的优化,对需求申请、分析、开发、上线、评估、优化的需求管理全过程进行优化,根据已有的系统架构修改建议，并考虑未来业务的变化和系统发展趋势，对系统架构进行优化,三级流程:,说明:,业务模型优化,根据已有的业务模型修改建议，并考虑未来业务的变化，对业务模型进行优化,一级流程:,二级流程:,需求确认,需求实现,需求交付,需求评估,需求优化,需求管理,需求分析,需求优化文件,业务模型优化文件,系统架构优

14、化文件,需求管理过程优化文件,成果：,“我不清楚谁最后作出决定“我发现我应该早点通知那个部门“其实我可以提供参考建议，但是没有人问我“我觉得我有责任做这件事，但我没有权限“没有人愿意进行决策“我做的事情应当是别人的责任,RESPONSIBLE,执行方执行某项任务的角色，可以多个执行方共同执行某项任务,ACCOUNTABLE,决策方最终决策并负责的角色，一项任务只能存在一个决策方,CONSULTED,参与方在执行某项任务时，或者做出最终决策前，被咨询的角色,INFORMED,知晓方做出最终决策后或者执行某项任务后，被通知的角色,XXRACI模型,为了保证需求管理流程的高效顺畅，需要明确各方职责,

15、RACI模型,在需求管理过程中各部门的职责（一）,需求确认,需求提出,业务活动,层级与部门,需求调研,需求评估,需求分析,业务需求分析,系统需求分析,收益/风险预测,需求提交,需求复杂度分析,需求版本制定,需求实现,设计,开发,部署,系统测试,业务测试,A,R,C,A,R,A,R,A,R,A,R,C,A,R,A,R,A,R,A,R,A,R,C,I,A,R,A,R,A,R,A,R,A,R,A,R,A,R,A,R,A,R,A,R,C,R,C,I,C,A,C,A,R,A,R,A,R,A,R,R,省业务部门,省业务支撑中心技术室,省业务支撑中心运维室,省业务支撑中心业务室,集团公司,I,A,R,A,R

16、,A,R,A,R,C,A,C,C,I,A,C,A,C,R,C,C,I,C,A,R,R,R,A,R,C,A,R,A,R,C,A,R,A,R,A,R,C,C,C,C,C,I,C,开发商,地市公司业务部门,地市公司业务支撑部门,A,R,A,R,需求确认,需求提出,需求调研,需求评估,需求分析,业务需求分析,系统需求分析,收益/风险预测,需求提交,需求复杂度分析,需求版本制定,需求实现,设计,开发,正式上线,系统测试,业务测试,A*,R,C,A,R,A,R,C,A*,R,C,A,R,A*,R,A,R,A*,R,A,R,C,I,A*,R,C,C,C,A,R,C,C,C,C,A,R,C,C,A,I,A,A

17、*,R,A*,R,A*,R,A*,R,A*,R,I,A,A,R,R,C,C,I,A,I,C,C,R,R,R,I,R,A,R,A,R,R,R,R,A*,R,R,C,R,R,I,C,C,C,C,C,I,C,注：A:决策方（ACCOUNTABLE）R:执行方（RESPONSIBLE）C:参与方（CONSULTED）I:知晓方（INFORMED）,R,C,需求的提供可能会有多个来源，不同来源有不同的决策方，所以A*表示某一类需求的决策方,R,I,I,I,I,I,I,在需求管理过程中各部门的职责（二）,I,C,I,R,I,R,R,R,R,R,R,C,C,开发商,地市公司业务部门,地市公司业务支撑部门,省

18、业务部门,省业务支撑中心技术室,省业务支撑中心运维室,省业务支撑中心业务室,C,R,I,R,C,I,I,R,R,R,A*,R,C,R,R,R,A,R,C,R,R,C,A.R,C,A,R,C,A,R,A,R,A,R,A,R,C,A,R,业务活动,层级与部门,需求交付,移交维护,系统培训,需求评估,业务情况分析,收益分析,需求审计,改进建议,需求优化,需求优化,业务模型优化,系统架构优化,需求管理过程优化,A,R,A,R,A,R,R,A*,R,R,A*,R,C,C,C,R,C,C,C,RACI模型,注：A:决策方（ACCOUNTABLE）R:执行方（RESPONSIBLE）C:参与方（CONSUL

19、TED）I:知晓方（INFORMED）,业务推广,C,I,C,R,R,R,需求的提供可能会有多个来源，不同来源有不同的决策方，所以A*表示某一类需求的决策方,C,通过分析RACI，得出一些结论,在需求分析阶段，需要两个部门共同负责完成需要实现过程对于业务室是”黑箱“的；而和业务部门的沟通对于技术室也是”黑箱“的谁对全过程的需求质量负责？,业务室参与需求管理的全过程，并需要协调各相关各部门需求管理中，40的活动由业务室负责（决策方）在需求上线后，业务室的后续工作尤为重要,结论,说明,业务室在需求管理中发挥重要作用,业务室和技术室的职责难以明确分离,业务部门决定需求的重要性、紧迫性，支撑部门决定需

20、求的复杂性由这两方面共同决定需求如何实现（需求版本）业务部门要保证”好钢用在刀刃上“，支撑部门通过“收益分析”过程进行监督支撑部门要保证”用在刀刃上的是好钢“，业务部门通过”需求审计“过程进行监督,业务和支撑共同努力并相互监督,对开发商缺乏统一的质量管理策略,需求最终是由开发商开发完成的，而且开发商将参与更多的需求管理活动但技术室负责开发商的考核和管理，但业务室负责需求的最终测试，如何考核开发商的需求开发质量？,根据业务优先级、系统实现复杂程度，对需求进行分类管理,业务紧迫程度高中低,需求实现,系统实现复杂程度高中低,项目开发型,配置型,版本开发型,规划开发型,集团下发的规范,1、BOSS1.

21、5规划和规范,省业务部门提出业务需求,2、关于BOSS渠道管理子系统接口开发需求3、营收稽查二期,地市公司提出业务需求,4、分销商电子易支付5、增加智能网预存话费优惠功能,支撑内部提出改善需求,6、智能网客户GPRS业务优化7、清单查询短信通知优化,根据关键维度对需求进行分类评估，不同类型的需求，其响应时间、需求实现的生命周期存在很大的差异,需求来源,需求分类举例说明：,5,1,2,3,4,6,7,不同类型的需求，有着不同的实现过程和实现周期，应通过不同方式实现,提高系统灵活性、可扩展性,提高业务前瞻性、可规划性,通过“定期版本开发方式”实现,通过“项目建设方式”实现,当前，定期版本开发方式中

22、存在的问题,活动,部门,表示各部门负责的活动,存在问题,整个需求分析过程（2、3、4、5）联系紧密，难以进行明确的职责划分2、3、6都存在需求传递和需求理解的过程，导致协调的时间长，对需求理解产生偏差110各个环节，各部门各管一段，缺乏统一的需求管理，没人对最终的需求质量负责68由开发商负责，对业务室是“黑盒的”，直到9才发现问题，影响需求的质量和上线时间,需求上线的时间,影响,需求实现周期长需求质量难以保证职责不明确资源得不到保障,对定期版本开发方式的改进建议,活动,部门,表示各部门负责的活动,需求上线的时间,目标,措施,稳定,固定的版本上线周期，把版本开发变成日常工作设置固定职能负责版本开

23、发，确保内部资源稳定与开发商签订长期合同，对开发商资源有明确要求，确保外部资源稳定,高效,减少中间环节，将串行方式改为Team方式由专人负责对需求进行全程管理，确保需求按时完成开发商尽早参与需求分析过程，并有专职项目经理控制版本进度,高质量,由专人负责对需求进行全程管理、监督，对需求的质量负责将需求质量要求量化，并与开发商绩效挂钩提高地市分公司参与程度，提供业务测试质量,当前，项目建设方式中存在的问题,活动,部门,表示各部门负责的活动,存在问题,项目建设过程与版本开发过程有很大的区别（25），不能同样对待可行性分析（2）目前由业务室完成，但其中也会讨论技术可行性，甚至技术方案，但缺乏技术方面的

24、支持集团的规范直接由技术室负责实施，没有充分考虑对业务的影响项目对资源的要求是突发的，由于项目建设和版本开发没有有效分离，对资源的需求产生冲突，相互影响（包括开发商资源）,需求上线的时间,影响,项目目标不明确，没有充分考虑业务目标项目中，业务与技术没有很好的结合项目延期,当前，项目建设方式中存在的问题,活动,部门,表示各部门负责的活动,目标,措施,规划性,项目应该尽量按3年滚动规划来实施,按时保质,项目应该有明确的目标，明确的计划，高质量的项目管理并按照项目计划达到预期的目标,有效的资源管理,项目对资源的要求是动态的通过PMO做项目组合管理，保证资源的合理有效利用项目组是根据项目对资源的需求，

25、由多个部门临时组建的（包括开发商）,需求上线的时间,目标,优化全部项目组合，而不是对单个项目在统一的一套评估标准的基础上，定义项目的优先级保证关注的是公司的战略目标和财务目标，而不是单个业务部门的目标通过建立项目组合管理的透明度，对优先级高的项目进行大力支持，保证其成功保证资源配置的效用和效率,战略影响,高,财务影响,低,低,高,项目A,项目B,项目C,项目D,项目F,项目E,预算控制基线2)内部资源/技能控制基线,2),1),有效的项目组合管理是为了判别业务的优先级、优化投资,项目组合管理流程示例,需求管理对组织结构的影响,业务支撑部,其它部门,新业务开发,PMO,PM1,PM2,PM3,P

26、M4,其它部门,其它部门,对组织结构的建议将新业务开发（版本开发）和项目建设分离由固定的职能负责新业务开发的全流程，开发商也应建立相应的固定职能建立PMO负责项目的规划和建设，根据项目情况临时组建项目组，项目由项目经理负责,为了保证需求管理的高效顺畅，需要考虑增加以下控制点：,1、规定每月计划内上线2次，紧急上线1次，紧急上线需部门领导审批,3、每次上线后须进行回归测试，确保上线稳定,4、每项开发需求必须对维护人员进行培训，确保维护人员对系统新增功能的维护能力,2、建有对立测试用例库，每次上线逐步丰富测试用例库中的测试用例，提升测试质量,需求确认,需求分析,需求实现,需求评估,需求交付,需求产

27、生,需求优化,需求管理生命周期,为了保证需求管理的高效顺畅，需要设置各项开发控制指标,1、开发故障次数当月（或近2月）因需求开发原因、程序原因导致系统故障的次数2、开发成本/收益率对以往开发的需求（一般不超过4个月）可以评估其收益的，分析其成本/收益率,1、开发及时率当月（或近2月）上线需求中按时需求数（需求实际上线时间早于等于需求计划上线时间）/当月（或近2月）上线需求总数,指标维度,关键指标,开发效率,开发质量,1、文档提交及时率当月（或近2月）按时提交需求开发文档的需求数/当月（或近2月）上线需求总数。需求文档包括：需求、改造方案、单元测试报告、集成测试报告，业务测试报告2、代码提交及时

28、率当月（或近2月）按时提交代码的需求数/当月（或近2月）上线需求总数3、缺陷修复及时率当月（或近2月）按时修复集成测试中发现的程序缺陷数/当月（或近2月）集成测试中发现的程序缺陷总数,开发规范,为了保证需求管理的高效顺畅，需要全方位加强开发商管理,人员数量,人员资质,需求覆盖率,测试BUG修复及时率,上线稳定性（如：2次系统故障间平均时间）,系统可维护性（如：系统事故平均修复时间）,人员工作规范性,文档完整率,文档提交及时率,代码提交及时率,开发及时率,问题解决及时率,负责程度,积极程度,合作程度,人员投入,开发质量,合作满意度,支撑有效性,管理规范性,开发维护成本/收益率分析,地市系统用户满

29、意度,问题复发率,问题解决质量指标（如：系统可用率增加率）,开发商管理维度：,关键指标：,为了保证需求管理的高效顺畅，需要系统支撑的改进,不是所有流程都严格走AMS电子流，AMS系统数据并不精确 没有严格规定的流程角色和职责定义，现在的流程的执行者并不是按角色职责分配责任和权限的 AMS对应的是旧的组织结构，流程责任角色并不对应新的组织结构，所以流程执行的并不严谨 AMS对配置管理支持力度不够，对系统资源的具体情况，状态和审计历史纪录没有详细记录，没有和变更请求结合起来，配置项之间的关系看不到 变更管理，没有明确的变更重要性评级活动和角色责任体制对开发商管理流程基本靠AMS，只能对开发商的开发

30、结果作管控，对开发流程执行度缺乏掌控 需求流程中，在需求评审前，没有需求提出方对需求的再确认活动；评审只是支撑中心内部流程，存在支撑中心和需求方对需求理解不一致，而双方都未意识到的情况,流程执行,配置管理,变更管理,运维流程,升级AMS系统，使其工作流流程上的角色设置对应相应的现实组织结构 在AMS中将角色职责进一步细分，比如需求业务分析专家，需求系统分析专家，等；在实际组织流程上，有相应的人员分配到这些角色 AMS改进，对系统资源的具体情况，状态和审计历史纪录，和其他配置项的关系，版本信息等作记录和及时升级 AMS应支持变更管理，采用类似变更单流程，对变更级别，变更参与角色，变更影响等予以纪录并分配相应角色建议将开发商内部开发测试流程关键步骤整合到AMS上，使开发流程对支撑中心更加透明 建议将如前所述的需求审计，改进建议和收益分析活动等加入到AMS需求单管理流程,改进方案,问题,BOSS系统开发建设人员,BOSS系统测试人员,BOSS系统维护人员,操作,操作,操作,代码提交,版本发布,为确保BOSS系统的安全，开发、测试、生产三大环境需要在物理和人员上分离,举例：系统建设开发人员不能访问、操作生产环境维护人员不能修改代码,