中国联通需求管理现状及改进方案汇报.ppt
内部资料 注意保密,信息化部2010年02月,需求管理现状及改进方案汇报,第一部分 需求管理现状需求管理内容需求管理成果需求管理流程第二部分 存在的问题及改进方法第三部分 业务场景需求确认方法第四部分下一步工作建议,目录,需求驱动的产品版本管理体系,需求筛选与规范,用户需求书,需求分析,需求规格书,标准规范,软件研发,软件产品,实施,应用系统1,应用系统2,应用系统n,缺陷管理,问题管理,需求变更管理,新一代BSS需求与软件版对应关系,第一部分 需求管理现状需求管理内容需求管理成果需求管理流程第二部分 存在的问题及改进方法第三部分 业务场景需求确认方法第四部分下一步工作建议,目录,需求管理内容,根据业务需求实现是否需要系统开发，分为开发类需求和配置类需求：开发类需求管理流程包括：年度需求管理流程、应急需求管理流程配置类需求管理流程包括：日常维护需求管理流程。,需求管理职责分工,总部/省分市场部,公司市场部为全部业务需求的归口管理部门，负责收集审批各业务部门需求并审批,总部/省分前台部门,公司各专业部为业务需求及下级业务需求初审部门，负责审核下级公司对口部门提交的需求，根据需求管理流程要求提出本部门的需求申请，统一提交到市场部,总部/省分支撑部门,负责参与需求编制并进行需求分析，对经市场部审批后的业务需求，负责工程建设和日常维护的实施工作,总部/省分计划/财务部,需求计划列入投资预算，审查是否能够进行需求季度调整或绿色通道，审核成本效益分析,需求管理内容展示,用户需求,需求管理内容展示（续）,用户需求点对点分析,需求管理内容展示（续）,系统需求规格书,共1523个用例,需求管理内容展示（续）,系统需求规格书主文档状态视图,第一部分 需求管理现状需求管理内容需求管理成果需求管理流程第二部分 存在的问题及改进方法第三部分 业务场景需求确认方法第四部分下一步工作建议,目录,用户需求成果,系统需求编制成果-CRM系统,系统需求编制成果Billing系统,系统需求编制成果其他系统,第一部分 需求管理现状需求管理内容需求管理成果需求管理流程第二部分 存在的问题及改进方法第三部分 业务场景需求确认方法第四部分下一步工作建议,目录,处理需求进行分类需求处理紧急程度用户需求书完善,开发需求设计与开发需求测试需求上线与验收,需求管理流程,获取 省分业务部门提出省分市场部上报总部市场部审批,分析确定需求系统界面确定需求实施程度编制系统需求书,后评估需求业务验证方案需求业务验证需求验证报告,需求获取,需求实施与验证,需求后评估,需求处理,需求分析,中国联通需求管理流程,需求管理总体流程说明,需求编制方式：总部统一管理，省分及厂家抽调专家参与配合需求编制工作；对年度需求，每年10/11月份，由省分前台部门及总部前台业务部门集中提出需求，报市场部审批。审批通过后，采用封闭集中编制年度需求的方式；对应急需求，省分通过需求管理系统填报，总部审核处理；,需求编制问题管理机制：对需求编制过程中存在的问题进行记录，并跟踪问题解决情况；链接机制：在需求书之间及需求书与问题集之间建立链接，可追溯需求的来源和去向.,省分应急需求管理流程全国部署需求,省分应急需求管理流程省分保留需求,总部应急需求管理流程,第一部分 需求管理现状第二部分 存在的问题及改进方法第三部分 业务场景需求确认方法第四部分下一步工作建议,目录,需求管理问题（一）,需求繁多、时间紧迫：需求提出方较多：业务支撑部面对前台八大业务部门，每个部门又有很多处室，需求提出方较多需求支撑时间要求紧迫：每个需求方都认为自己的需求优先级较高，要求很快要上线支撑需求变更频繁：业务部门的需求还没有支撑结束，需求又变了，或者是刚支撑好，又要改需求需求分析工作量大：对业务部门的需求，要从每个业务流程、业务规则、业务信息进行分析，同时要考虑该需求与其他业务的关系,需求管理问题（二）,需求分析人员不稳定省分人员：省分人员工作较多，对于总部统一组织的需求分析工作经常换人，导致需求分析工作、系统需求编写工作质量不高，效率较低。厂家人员：厂家人员对总部统一组织的需求分析工作不重视，人员不是很稳定，导致对需求理解不透彻，对需求分析工作、系统需求编写工作质量不高，效率较低。需求质量不高用户需求：业务部门的用户需求表达不准确、业务关系、业务规则不明确系统需求：由于对用户需求理解有偏差，导致系统需求不能满足业务需求新增需求处理不及时需求流程：若在每个环节中都不按时限处理，导致需求流程过长 5.省分本地化需求的规范管理问题,解决方法-优化需求团队管理,需求分析输出成果：1、点对点分析；2、系统需求书；3、支撑方案；4、接口规范；,需求获取输出：1、OA公文；2、需求交互单3、业务规范；4、用户需求书,工程测试输出：1、测试用例；2、测试评估；,需求确认及业务验证问题,需求确认存在的问题描述：通过功能的方式来描述流程关注的用户角色不够可能对某些业务流程有所疏漏针对系统划分来写用户需求书，系统规划未确定的情况下，用户需求书无法编写业务验证存在的问题描述：由需求确认不准确导致的问题需求确认与需求实施存在差异总部需求大于省分实际需求，厂商对该部分需求不开放，导致测试时与总部不一致省分的需求不同于总部的需求，为了能够按照省分实际需求，导致测试时与总部不一致省分个性化需求没有在总部需求中涵盖厂商开发过程中对需求按照优先级分步上线,牵头部门：市场部参与部门：信息化/前台业务,解决业务验证存在问题的方案,需求提出,需求确认,业务验证,需求分析,1、OA公文2、需求交互单3、业务规范4、用户需求书,业务需求书（业务场景）,1、点对点应答2、系统需求规格说明书3、技术规范,系统开发,说明：通过完善的业务场景作为需求确认的手段及业务验证的输入,牵头部门：信息化部参与部门：市场部/前台业务,牵头部：市场部参与部门：前台业务部门,第一部分 需求管理现状第二部分 存在的问题及改进方法第三部分 业务场景需求确认方法第四部分下一步工作建议,目录,第一部分 需求管理现状第二部分 存在的问题及改进方法第三部分 业务场景需求确认方法如何获得业务场景如何编写业务场景第四部分下一步工作建议,目录,eTOM（level2视图）,中国联通新一代BSS系统规划,Uni-TOM示意,中国联通业务过程框架Uni-TOM（BSS部分）,遵循eTOM的经验（level2视图基础上增加竞争对手视角）、结合中国联通多年总结的BSS规划架构、探索三维度（客户、产品、运营过程）的理论体系，总结出适合中国联通业务支撑系统（BSS）的业务过程框架，即业务场景集合。,客户,产品,F,A,B,OSR,运营过程,面向集团客户业务场景分类汇总（示意）,第一部分 需求管理现状第二部分 存在的问题及改进方法第三部分 业务场景需求确认方法如何获得业务场景如何编写业务场景第四部分下一步工作建议,目录,业务场景建模,业务场景定义UNI业务场景（Uni-Scenarios）场景是联通电信运营图（Uni-TOM-BSS）的组成部分，是由特定的角色按照既定的流程、事件生成的一系列活动集合的总称。UNI业务场景实例（Uni-Scenario Instance）场景实例是对场景指定具体的参数（例如：客户、产品、区域等）而形成的实例化场景。说明我们主要编写的是业务场景，业务场景是抽象出来直接面向业务需求的，具有普适性某些重点的业务场景需要结合业务场景实例来共同阐述，不同的场景实例来验证普适的业务场景，,业务场景建模需要包含的内容,场景建模,N 场景名称3WWHO 涉及到哪些角色（内部、外部）WHAT 场景里发生了哪些事情WHY 目的是什么2HPROCESS 流程是什么RULE 规则是什么,编写示例（1）,编写示例（2）,编写示例（3）,第一部分 需求管理现状第二部分 存在的问题及改进方法第三部分 业务场景需求确认方法第四部分 下一步工作建议,目录,需要领导决策的问题及建议,1、需求改进方法论是否可行2、集团客户需求是否按照该方法进行编制,需要领导决策的问题,下一步工作建议,1、与市场部就新的需求管理改进方法进行沟通，并达成一致意见。2、就集团客户需求按照该方法论进行编制，在实践中对方法论进行改进与完善。3、与市场部共同修订需求管理办法并下发,集团客户业务需求前期已完成工作,需求提出集团客户提出加强集团客户业务支撑能力的需求，并探讨业务需求提出的方法和系统建设的思路；业务调研集团客户部牵头到河北调研，详细调研了售前需求相应的业务过程；方法论提出梳理业务场景的需求描述方法的方法论，在eTom的指导下，结合实际工作提炼了业务能力范围和场景颗粒度的方法；场景示例按方法论，实际编写了业务场景的示例；,集团客户业务需求后续工作计划,方法论的确认与沟通（本周,3月12日）业务场景的需求描述方法的确认；与市场部、集客部就需求描述方法进行沟通并达成一致；需求调研与确认（四周，3月15日4月9日）三部门和厂商、省分专家一起对业务场景确认模板并进行分工；根据分工分头到省分调研集团客户业务场景；集中办公，按业务场景的方式编制集团客户业务需求书；业务需求书的评审需求分析（三周，3月29日4月16日）参考集团客户的业务需求书，编制集团客户支撑系统建设方案；根据业务需求书进行需求分析，给出集团客户支撑系统系统需求书与技术规范；,44,谢谢！,
