中国联通2010年需求管理现状及改进方案汇报2012-.ppt

业务视角 * 应用系统功能的视角 * * 客户经理日常工作支持 客户经理考核 * 总部应急需求管理流程 总部前台 业务部 ① 我的需求是什么 ② 总部业务 支撑部 你们的需求我的意见是什么 ③ 我的需求是什么，业务支撑部的意见是什么 总部 市场部 ④ 审核用户 需求书 需求分析 专家 制定系统需求分析计划 ⑤ 需求分析 ⑥ BSS合作 伙伴厂商 31省分 支撑部 审核通过，发布省分及厂家进行研发支撑 第一部分 需求管理现状 第二部分 存在的问题及改进方法 第三部分 业务场景需求确认方法 第四部分 下一步工作建议 目录 需求管理问题（一） 需求繁多、时间紧迫： 需求提出方较多：业务支撑部面对前台八大业务部门，每个部门又有很多处室，需求提出方较多 需求支撑时间要求紧迫：每个需求方都认为自己的需求优先级较高，要求很快要上线支撑 需求变更频繁：业务部门的需求还没有支撑结束，需求又变了，或者是刚支撑好，又要改需求 需求分析工作量大：对业务部门的需求，要从每个业务流程、业务规则、业务信息进行分析，同时要考虑该需求与其他业务的关系 需求管理问题（二） 需求分析人员不稳定 省分人员：省分人员工作较多，对于总部统一组织的需求分析工作经常换人，导致需求分析工作、系统需求编写工作质量不高，效率较低。 厂家人员：厂家人员对总部统一组织的需求分析工作不重视，人员不是很稳定，导致对需求理解不透彻，对需求分析工作、系统需求编写工作质量不高，效率较低。 需求质量不高 用户需求：业务部门的用户需求表达不准确、业务关系、业务规则不明确 系统需求：由于对用户需求理解有偏差，导致系统需求不能满足业务需求 新增需求处理不及时 需求流程：若在每个环节中都不按时限处理，导致需求流程过长 5. 省分本地化需求的规范管理问题 解决方法-优化需求团队管理 需求分析输出成果： 1、点对点分析； 2、系统需求书； 3、支撑方案； 4、接口规范； 需求获取输出： 1、OA公文； 2、需求交互单 3、业务规范； 4、用户需求书 工程测试输出： 1、测试用例； 2、测试评估； 需求确认及业务验证问题 需求确认存在的问题描述： 通过功能的方式来描述流程 关注的用户角色不够 可能对某些业务流程有所疏漏 针对系统划分来写用户需求书，系统规划未确定的情况下，用户需求书无法编写 业务验证存在的问题描述： 由需求确认不准确导致的问题 需求确认与需求实施存在差异 总部需求大于省分实际需求，厂商对该部分需求不开放，导致测试时与总部不一致 省分的需求不同于总部的需求，为了能够按照省分实际需求，导致测试时与总部不一致 省分个性化需求没有在总部需求中涵盖 厂商开发过程中对需求按照优先级分步上线 牵头部门：市场部 参与部门：信息化/前台业务 解决业务验证存在问题的方案 需求提出 需求确认 业务验证 需求分析 1、OA公文 2、需求交互单 3、业务规范 4、用户需求书 业务需求书（业务场景） 1、点对点应答 2、系统需求规格说明书 3、技术规范 系统开发 说明：通过完善的业务场景作为需求确认的手段及业务验证的输入 牵头部门：信息化部 参与部门：市场部/前台业务 牵头部：市场部 参与部门：前台业务部门 第一部分 需求管理现状 第二部分 存在的问题及改进方法 第三部分 业务场景需求确认方法 第四部分 下一步工作建议 目录 第一部分 需求管理现状 第二部分 存在的问题及改进方法 第三部分 业务场景需求确认方法 如何获得业务场景 如何编写业务场景 第四部分 下一步工作建议 目录 eTOM（level2视图） BSS MSS SC OSS 中国联通新一代BSS系统规划 Uni-TOM示意 中国联通业务过程框架Uni-TOM（BSS部分） 遵循eTOM的经验（level2视图基础上增加竞争对手视角）、结合中国联通多年总结的BSS规划架构、探索三维度（客户、产品、运营过程）的理论体系，总结出适合中国联通业务支撑系统（BSS）的业务过程框架，即业务场景集合。 客户 产品 F A B OSR 运营过程 面向集团客户业务场景分类汇总（示意） 序号 业务能力 场景编号 场景名称 1 客户关系 1.1 名单制客户维护 1.2 客服自服务支撑 1.3 客户问题处理 1.4 客户忠诚度和流失率 1.5 客户经理日常工作支持 1.6 客户经理考核 2 产品管理 2.1 产品推出、优化、退出 2.2 套餐方案管理 3 营销销售 3.1 营销活动管理 3.2 销售管理 3.3 售前需求响应 3.4 折扣审批 4 订单及服务开通 4.1 客户订单生成（订购与服务变更） 4.2 订单处理 4.3 售中业务配置和激活 4.4 定单调度 4.5 跨域及异地处