《某省移动业务支撑系统业务与体系规划项目-对业务需求管理和组织结构的建议》由会员分享，可在线阅读，更多相关《某省移动业务支撑系统业务与体系规划项目-对业务需求管理和组织结构的建议（32页珍藏版）》请在金锄头文库上搜索。
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 广州市调研反
5、映其需求满足率50，其它地市更低 因为需求难以满足，各地市已大幅减少了需求的提出,数据来源：省业务支撑中心AMS系统,存在问题,需求管理流程的具体问题分析,一级流程:,需求确认,需求分析,需求实现,需求交付,需求评估,需求优化,需求管理,二级流程:,需求描述不清楚，没有严格遵守需求说明文件，且需求说明文件的描述范围和详细程度等指标有待进一步优化 需求申请后仍多次修改，需求确认往复多次 需求申请没有成本考虑，所以往往提出的需求数量偏多 需求没有投资收益分析，能带来多少价值不清楚 需求优先级的确定没有衡量标准及责任部门，各业务部门往往夸大需求的重要性和紧迫性，有时依靠领导拍板,业务支撑中心资源投入
6、不足，难以及时处理众多需求 技术部门与业务部门之间缺少有效沟通，存在理解的偏差，系统需求有时不能符合业务原来的要求 技术部门与业务部门的职能划分上欠明确 技术室对需求复杂度评估没有权威性，开发商在开发成本确定上相对处于强势 对需求缺乏抽象、前瞻性考虑，导致开发零散，缺乏系统的规划,开发商的资源投入不足 与开发商缺乏长期战略合作模式，开发商缺乏优化系统架构的动力 开发商主要定位在系统开发、运营维护，对需求分析参与不足 多个开发商间的职责划分尚不明确,没有完善的测试体系和完整的测试平台 系统测试不充分，测试报告不全 地市只能测试本市需求，不能测试全省范围的需求和对外接口需求 测试资源不配套 省提出
7、的部分需求缺少与各地市的沟通，其适用性低，各地市推广积极性低,需求上线后缺乏正式的交接过程，运维缺乏对需求开发质量进行评估 缺少需求上线情况分析 缺少业务运行情况、收益及问题原因分析,没有建立一整套的针对省、各地市、各部门及全员的“持续改进”激励制度 没有真正形成需求管理闭环流程,各步骤具体问题分析:,为了保证需求管理的高效顺畅，需要从以下几个方面加以保证：,需求管理全程流程,需求确认,需求分析,需求实现,需求交付,需求评估,需求优化,二级流程,需求优化,系统架构优化,需求管理过程优化,业务模型优化,结束,需求提出,需求评估,收益/风险预测,需求提交,开始,需求调研,需求审计,需求管理流程,各
8、方角色定位,控制指标和控制点,需求进行分类评估,开发商管理,开发、测试、生产三大环境分离,三级流程,需求管理流程分解需求确认,需求提出,需求调研,需求评估,收益/风险预测,各地市提出地市需求 省各业务部门提出的需求 集团下发规范中的需求 支撑内部提出完善的需求 其它系统改造产生的需求,对需求实现后所能带来的价值进行预测分析，即收益分析 对新需求可能存在的风险进行分析,业务部门对需求的重要性和紧迫性进行分析，评估需求业务优先级 对需求的合理性、与其它业务的关联性、互斥性进行分析,对需求进行调研、细化，根据根据模板形成需形成需求调研报告，对需求进行详细描述,三级流程:,一级流程:,二级流程:,说明
9、:,需求提交,确定需求是否需要实现（做还是不做），以及期望完成时间 将明确的需求调研报告、需求评估报告和需求收益/风险预测提交业务支撑部门,成果：,需求确认,需求分析,需求实现,需求交付,需求评估,需求优化,需求管理,需求申请表,需求调研报告,需求评估报告,需求收益/风险预测报告,需求提交表,需求管理流程分解需求分析,一级流程:,二级流程:,需求确认,需求实现,需求交付,需求评估,需求优化,需求管理,业务需求分析,系统需求分析,需求复杂度分析,需求版本制定,对业务需求进行细化，分析对现有业务规范的影响，并提出对业务规范的修改建议方案 业务可扩展性分析，对类似需求进行合并、抽象,结合需求业务优先
10、级评估和需求复杂度评估，进行需求排期，确定版本计划,对需求内容多少、难易程度、是否适合系统架构等进行分析 预测需求实现的工期和成本（工时）,对业务需求进行系统化分析，评估对现有系统架构的影响，并提出需求实现的初步建议方案,三级流程:,说明:,成果：,业务需求分析书,系统需求分析书,需求复杂度分析书,需求版本计划,需求分析,需求管理流程分解需求实现,一级流程:,二级流程:,需求确认,需求实现,需求交付,需求评估,需求优化,需求管理,设计,开发,系统测试,明确系统需求和业务需求，对方案进行设计 对设计方案进行评审 制定测试计划并设计测试方案,全面质量管理的一环，对开发结果进行系统测试，从技术层面上
11、把握质量控制,制定开发计划及测试上线计划 对需求进行开发，管理开发质量、进度,三级流程:,说明:,成果：,设计方案 方案评审表,开发计划 测试上线计划 单元测试报告,集成测试报告,需求分析,业务测试,全面质量管理的一环，对开发结果进行业务测试，从业务使用层面上把握质量控制,业务测试报告,正式上线,部署到正式环境进行测试，业务正式运行,上线测试报告,需求管理流程分解需求交付,一级流程:,二级流程:,需求确认,需求实现,需求交付,需求评估,需求优化,需求管理,三级流程:,说明:,成果：,需求分析,移交维护,系统培训,业务推广,将正式上线运行的功能模块或系统，以及全部相关文档移交给维护部门，由运维部
12、门进行日常维护,新业务上线后，省和地市可以采取相应的新业务推广计划,对省和地市公司的系统相关使用人员进行系统操作培训,移交确认文件 需求上线通知单,系统培训计划,业务推广计划,评估需求完成的及时率、质量、故障率等，并查找原因，提出改进措施 核算需求实现的实际成本 业务部门评审需求是否达到预期目标,需求审计报告,需求审计,需求管理流程分解需求评估,一级流程:,二级流程:,需求确认,需求实现,需求交付,需求评估,需求优化,需求管理,需求分析,业务情况分析,收益分析,改进建议,对业务运营情况进行定期的跟踪、分析,对运营情况未能达到预期收益的新业务需求，进行根本原因分析（市场问题、需求实现的问题、业务
13、推广问题等），并对此业务提出应对措施（改善、退出、保持等）,对需求的收益情况进行分析，并与需求申请时的需求收益预测进行对比，评估需求提出的质量,三级流程:,说明:,业务运作情况分析报告,收益分析报告,改进建议报告,成果：,需求管理流程分解需求优化,需求优化,系统架构优化,需求管理过程优化,对某个或某类需求进行业务或系统层面的优化,对需求申请、分析、开发、上线、评估、优化的需求管理全过程进行优化,根据已有的系统架构修改建议，并考虑未来业务的变化和系统发展趋势，对系统架构进行优化,三级流程:,说明:,业务模型优化,根据已有的业务模型修改建议，并考虑未来业务的变化，对业务模型进行优化,一级流程:,二
14、级流程:,需求确认,需求实现,需求交付,需求评估,需求优化,需求管理,需求分析,需求优化文件,业务模型优化文件,系统架构优化文件,需求管理过程优化文件,成果：,“我不清楚谁最后作出决定“ “我发现我应该早点通知那个部门“ “其实我可以提供参考建议，但是没有人问我“ “我觉得我有责任做这件事，但我没有权限“ “没有人愿意进行决策“ “我做的事情应当是别人的责任“,RESPONSIBLE,执行方执行某项任务的角色，可以多个执行方共同执行某项任务,ACCOUNTABLE,决策方最终决策并负责的角色，一项任务只能存在一个决策方,CONSULTED,参与方在执行某项任务时，或者做出最终决策前，被咨询的角
15、色,INFORMED,知晓方做出最终决策后或者执行某项任务后，被通知的角色,XXRACI模型,为了保证需求管理流程的高效顺畅，需要明确各方职责,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
16、,A,R,A,R,A,R,A,R,R,省业务部门,省业务支撑中心技术室,省业务支撑中心运维室,省业务支撑中心业务室,集团公司,I,A,R,A,R,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,
