中移动某公司BOSS系统2010年发展演进规划

中移动 XX公司 BOSS系统 2010年发展演进规划 2 目 录 BOSS发展驱动力 2 XX移动 BOSS发展现状分析 1 4 3 XX移动 BOSS发展演进的建设措施 XX移动 BOSS发展规划的总体目标 XX移动 BOSS发展演进的建设路线规划 5 3 XX移动 BOSS系统近年来的发展回顾 建设目标： 提升处理能力 主要项目： BOSS集中化改造项目 项目内容： 全省 11个地市的 BOSS业务集中处理 建设目标： 提升处理能力 提升容灾能力 主要项目： BOSS二期扩容工程（包含计费软件升级） B-BOSS 项目内容： 计费 帐务优化 容灾系统建设 B-BOSS 综合查询 充值 01-03年 03-04年 建设目标： 提升处理能力 主要项目： BOSS三期扩容工程（包含代销渠道改造） 结算二期 项目内容： 神州行、 VPMN迁移 代销渠道改造 科目整合 梦网稽核 收入保障财务项目 多帐户整合 结算功能改造 统一开通及二期扩容 04-05年 BOSS集中化改造阶段 枢纽楼 BOSS中心建设阶段 学院路中心扩容及 改造阶段 集中 整合 /优化 整合 /优化 建设目标： 解藕 能力提升，为 NGBOSS准备 主要项目： BOSS四期扩容工程 多帐户（帐务优化）改造 计费能力提升 BOSS应急系统 BOSS2.0 项目内容： 产品管理 统一门户 计费能力提升 多帐户（ BOSS帐务优化） BOSS应急 集团门户 解耦、能力提升 0607年 解藕，能力提升 BOSS系统已从以计费帐务为主的单一系统转变为集客户服务、市场、销售、计费帐务、渠道管理、日常运营统计分析等多功能于一身的全面运营支撑体系 建设目标： 更大规模支持（双中心） 处理能力全面能力 BOSS3.0支撑能力建设 主要项目： BOSS五期扩容工程 BOSS3.O! 项目内容： BOSS拆分（双中心） 应急系统 开通能力提升 定制终端管理（资源） 渠道管理二期系统建设 BOSS3.0建设项目 07 全面提升系统处理能力，系统架构优化，能力提升 ， 优化架构、全面提升系统性能 4 XX移动 BOSS系统体系架构 渠道人员 统一业务门户服务视图 统一门户展现框架 营业员 大客户经理 市场人员 公共 基础 数据 维护 服务 统 一 权 限 管 理 统 一 接 触 管 理 统 一 产 品 管 理 市场与 营销管理 订单 管理 客户 管理 客户 服务 计费 帐务 渠道管理 合作伙伴管理 综合结算 服务 开通 服务问题 管理 服务 批价 服务质量 管理 公共数据库 营业数据库 帐务数据库 计费数据库 帐户资金 MDB 双 中 心 话务员 客服系统 C/S前台框架 客服系统展现页面 知识数据库 客服数据库 业务应用 服务请求 知识库 接触管理 基础应用 现场管理 排班 /质检 权限管理 呼叫中心基础平台 WEB页面融合 5 XX移动 BOSS系统现状分析 成功支撑了 3400万用户的业务运营，月处理话单量超过 85亿条，月处理工单量超过 1.4亿笔 成功实施了 BOSS双中心拆分，有效降低了单中心规模，较大程度提升了系统稳定性，降低了故障发生时的影响面 经过对系统专题性、持续性的优化，进一步增强了运维管控能力，巩固了系统业务的可持续运营能力 AppFrame技术架构的进一步深入运用，增强了一些关键业务子系统的支撑灵活性及可配置化手段，实现了 BOSS功能域的初步解藕 系统持续优化建设 所取得的成绩 BOSS3.0工程的实施进一步统一了系统体系架构，调整和规范了系统的功能边界，较大程度提升了客户服务水平 6 系统核心业务的实现仍然采用垂直式的功能开发模式 ,服务复用度较低，耦合性较强，存在同一业务功能重复建设的问题 系统业务流程及业务规则不可见，整体呈现出支撑灵活性不足，可配置化能力较低，造成新需求的响应周期较长，开发成本过高 BOSS业务数据缺乏分级管理机制，大量业务历史数据仍然保存在生产系统中，导致系统的数据规模有增无减，越趋膨胀 对数据类产品营销的支撑能力有待提升，现有的产品订购模型及业务处理流程已无法满足越趋丰富的产品营销需求 系统亟待改 进提升的地方 现有一些关键子系统由于是在不同时期所建设，其在系统可维护性、可管理性方面已无法满足日益提高的系统运维管控要求，需要进一步优化和改进 在取得成绩的同时，我们还要看到系统仍然存在一些亟待优化提升的地方 7 目 录 BOSS发展驱动力 2 XX移动 BOSS发展现状分析 1 4 3 XX移动 BOSS发展演进的建设措施 XX移动 BOSS发展规划的总体目标 XX移动 BOSS发展演进的建设路线规划 5 8 BOSS发展演进的驱动力 新的技术标准、技术规范推动系统向前发展 BOSS发展驱动力 企业内部管理需要系统具有更高的业务管理能力 市场竞争环境的加剧，对系统灵活性、快速响应机制提出更高的要求 新的业务需求对系统提出了更高的要求 由于不同时期分别建设的多个系统参与营销和服务支撑，造成相同业务功能分散在多个系统中，急需进行系统融合 由于功能不断堆叠，原有技术架构不能满足业务发展需要 9 目 录 BOSS发展驱动力 2 XX移动 BOSS发展现状分析 1 4 3 XX移动 BOSS发展演进的建设措施 XX移动 BOSS发展规划的总体目标 XX移动 BOSS发展演进的建设路线规划 5 10 一个理想的 BOSS系统目标体系架构应具备： 业务完整性 包含了正确的并全面的业务概念，支持所有相关的业务活动； 系统灵活性 支持业务规则的多变性，以最少的改动可以支持业务的变化和发展； 技术前瞻性 除了支持现有的业务需求、解决短期问题外，还可以支持行业里的先进规范（如中移动 NGOSS）与企业里未来的需求（如 3G、融合计费等） 架构合理性 依照业务功能相关度、数据相关性和独立性分析等，决定模块的划分，及各模块的耦合程度，并体现模块间松耦合的思路。这同时也是制定系统间接口和接口重用性的重要基础 安全健壮性 作为最关键的业务支撑系统，规划设计从结构上是否足够安全、健壮，在体系架构上保证业务连续运营； 数据集成性 目标体系架构中的数据框架与数据流程具有连贯性和一致性，由于单独的数据所体现的价值往往比相关联的数据来的少，数据间的连贯性可加强数据的未来作分析的价值，并形成了清晰的业务支撑网数据视图 接口规范性 模块间耦合的好坏都取决于模块间接口的稳定性和接口的效率。不论是同步、异步、实时还是批量接口，其设计必须要符合规范和标准，更重要的是还要形成接口的体系框架 用户友好性 系统是否能方便业务操作，降低用户使用成本、提高业务效率、方便业务管理，从而提高是否能提高客户满意度； 8个纬度 5个视角 1. 客户视角 2. 系统使用者、操作者视角 3. 市场人员视角 4. 系统建设者视角 5. 系统维护者视角 通过 5个视角对 8个纬度的分析，理想 BOSS系统系统架构应具备的能力 11 业务种类和业务容量增长及对 BOSS业务灵活性、规则可见的要求，为保证系统的稳定和可持续发展 , 可以从以下几方面进行控制 行动措施 保证保证 BO SSBO SS 系系统的稳定性和统的稳定性和持续性发展持续性发展技术管理技术管理业务流程的业务流程的优化设计优化设计 基于 SOA 架构的设计 , 保障服务之间的低耦合 基于三层结构的系统架构 , 可扩展性强 各层次间互不影响的负载均衡能力 , 有效地对系统数据进行分流 , 减轻运营压力 BOSS 的应用和存储都支持集群 ( c l us t er)技术 , 可以线性增加节点来缓解压力数据模型设计的前瞻性以及数据模型设计的前瞻性以及数据分布规划的合理性数据分布规划的合理性系统架构的先进性和可系统架构的先进性和可扩充性扩充性 模型需要具有一定的前瞻性 , 符合国际标杆 借鉴国外先进运营商经验 BOSS 的数据模型设计都应该经过充分的业务验证 规范系统开发和维护流程的制定和实施 制定完善的系统变更流程规范 系统间的流程设计需要粗粒度 , 便于理解和监控 核心的业务流程要具有可配置性在明确 BOSS总体发展目标后，需要从数据模型、业务流程、系统架构、运维管控层面来规划现有系统的演进目标 12 翻译 /适配器数据管理数据管理服务开通翻译/适配器资源管理C o n n e ct io nid : intsp e e d : intcl a ssO f Se rvi ce : St ri n gt yp e : St ri n gin ve n t o ryR e q u e st C o d e : S t ri n ga ct iva t io n St at u s : St ri n gse rvi ce Pro f ile I d : St ri n go rd e rI d : intt e rmi n a t io n I d 0 : intt e rmi n a t io n I d 1 : intSu b n e t w o rkid : intca p a ci t y : St ri n gco n n e ct io n T yp e s : St ri n g0 . . *Pro d u ctid : intsp e e d : intcl a ssO f Se rvi ce : St ri n gt yp e : St ri n gse rvi ce Pro f ile I d : St ri n glo ca t io n I d 0 : S t ri n glo ca t io n I d 1 : S t ri n gC u st o me rid : intO rd e rid : inta ct iva t io n D a t e : D at eb ill in g St a t u sC o d e : S t ri n g1 . . *0 . . 11 . . *Pri ci n g Pl a nid : intn a me : S t ri n g翻译/适配器融合计费翻译/适配器客户用户服务资源帐户产品资费客户用户服务资源帐户产品资费翻译 / 适配器业务规则管理业务规则管理CRM翻译/适配器CRM 综合客服 订单管理 营销与销售 客户管理 计费帐务 资源管理 帐单 帐单 资源信息 Transportation Distribution Order Tracking Demand Visibility Inventory Management Capacity Planning Production Planning Segmenting MRP Sequencing 合作伙伴与结算 帐单管理 Revenue Management Pricing Costing Invoicing 销帐 B2B Exchange 银行邮储 Treasury 自助服务门户 经营分析 订单 订单、帐单 帐单 业务咨询、业务订单 订单 帐单 客户 资源 订单 发票 业务订单 Common Information models 订单 产品 资费 服务 基于 SID的 共享信息模型 呼叫中心 优化现有系统业务处理流程，逐步解藕系统功能模块 改进提升 BOSS核心业务模型，基于 SID规范设计各系统间可共享的信息数据模型 构件化系统功能服务，在共享信息数据模型上，以 SOA架构来部署 BOSS各系统应用 融合计费帐务 在系统体系架构演进方面 要逐步实现松散耦合的系统交互，逐步构件化BOSS业务服务，最终推动 BOSS体系架构向 SOA方向演进 13 三户创建 套餐变更 服务开通 计费上发 计费出帐 规则库 集 成 总 线 业务规则模板 IT人员 规则引擎 业务人员 业务规则 开发管理工具 业务规则实例 运行监控界面 定义业务参数 业务规则呈现 运行期 规则构建期 通过构建基于规则引擎的业务流程处理模式， 逐步实现代码与业务流程的分离、业务数据 与流程的分离，适应快速业务开发的需要， 降低代码上线的频率，增强 BOSS系统运行的 稳定性及支撑灵活性 在系统业务流程实现方面 逐步引入规则引擎，实现业务流程及业务规则的灵活配置，提升 BOSS系统的业务支撑能力 14 目 录 BOSS发展驱动力 2 XX移动 BOSS发展现状分析 1 4 3 XX移动 BOSS发展演进的建设措施 XX移动 BOSS发展规划的总体目标 XX移动 BOSS发展演进的建设路线规划 5 15 08年 BOSS系统发展演进的建设措施规划 系统体系架构演进方面 系统业务支撑能力优化方面 系统运维管控能力提升方面 需进一步论证和探讨的优化措施（暂无结论 ) 需求已明确，待重点建设的优化措施 需求已明确，建议实施的优化措施 按地市继续纵向拆分 BOSS系统 按功能域 (营业 /帐务 )拆分系统 引入新的技术架构及业务架构， 逐步重构营帐核心服务，实现系 统业务支撑模式的全面转型 构建 BOSS营帐历史库，实现业务数据的分级管理 综合查询系统能力提升 统一资源管理平台建设 用户对帐单规范化建设 产品营销的支撑能力提升 渠道营销能力完善和提升 CBOSS系统的功能优化 业务受理规则的集中管控平台建设 MDB容灾能力建设 业务模块编译、发布管理系统建设 BOSS业务自动化测试系统的建设 面向运维管控的内部门户系统建设 系统服务集成配置支撑平台建设 16 BOSS体系架构演进方面的 3个探讨性课题 17 系统体系架构演进方面的探讨性课题 1按地市继续纵向拆分 BOSS系统，形成三中心或多中心架构 WEB界面控制层 业务落地路由层 EJB服务 接口 EJB服务 接口 EJB服务 接口 BOSS统一业务门户 营帐应用服务 （分中心 1应用组） 营帐应用服务 （分中心 2应用组） 营帐应用服务 （分中心 3应用组） WTC连接 BOSS营帐子系统应用功能域 营帐 DB1 营帐 DB2 营帐 DB3 计费 DB1 计费 DB2 计费 DB3 数据中心 1 数据中心 2 数据中心 3 5 、三中心体系架构在应用部署方面、数据域之间交互方面会更加复杂，这对B O S S 向C R M 演进会产生一定的技术障碍，不利于系统可持续发展继续拆分劣势2 、分散的数据部署增大了异地业务数据同步，以及跨地市三户关系管理的支撑复杂度，数据的一致性保障能力降低3 、随着后续集团类业务的增多和丰富，过于分散的数据域对其支撑能力会出现一定的局限性4 、在目前双中心较低系统性能压力的情况，再实施三中心建设，所带来的系统性能提升效果已不再明显2 、核心实体表的数据量进一步降低，有利于提升B O S S 应用服务的处理效率，增强系统运行的稳定性3 、三中心的数据、应用分布部署，较大程度降低了单个中心数据库、B O S S 应用服务的业务处理压力，系统性能的提升空间进一步增大4 、三中心建设，B O S S 故障发生时的影响面进一步缩小，业务的可持续运营能力得到较大程度增强1 、三中心部署虽然降低了单中心数据规模，但是业务数据过于分散，带来了系统运维难度和工作量的大幅增加4 、拆分工作主要集中在地市业务数据的搬迁，以及应用分组的新增部署5 、W E B 服务层需要新增E J B 业务接口组，同时需要调整“用户- 中心”映射配置以及异地业务数据同步的各项参数可行性1 、B O S S 核心数据库的业务数据规模更大幅度降低，数据库的可管理性、可维护性增强继续拆分优势纵向三中心拆分的可行性及优劣势分析1 、目前B O S S 系统已按地市双中心拆分部署2 、系统的应用体系架构已具备多中心建设基础3 、继续纵向拆分，对B O S S 营帐应用不会产生较大影响18 BOSS系统横向拆分的驱动力分析 外部视角 NGBOSS目标架构 集团公司对 BOSS未来发展的规划 由 OneCM企业战略推动 BOSS向NGBOSS演进，发挥规模优势 通过 C/P拆分，提升支撑系统的营销能力，加强客户关系的管理 系统体系架构演进方面的探讨性课题 2推动 BOSS向 CRM方向演进，按功能域营业、帐务计费横向拆分 BOSS系统 19 BOSS系统横向拆分的驱动力分析 对 BOSS的再认识 BOSS系统的建设，强调的不是端到端的流程定制 ,而是实现复杂资费的业务能力，是典型的以业务计费为核心的系统。 表驱动：强结构，业务逻辑的强制绑定 运算效率优先： CDM与 PDM的惊人相似 对 CRM的再认识 CRM系统的建设，强调的不是业务的实现，而是业务的语义表达。关注的不是业务本身，而是面向客户的端到端的营销流程。因此，是以客户营销为核心的支撑系统。 规则驱动：弱结构映射 系统业务无关性的设计： CDM与 PDM的完全分离 既然 BOSS是面向生产的系统，其核心价值在于复杂资费条件下的高效业务计费能力 CRM是面向营销的系统，其核心价值在于多变营销环境下的快速语义表达和服务提供能力 在同一套系统中实现两套完全不同的数据核心建模，必然顾此失彼 那么 为什么不能结合 BOSS与 CRM的优势，采用某种方式的融合，继续发挥 BOSS作为生产系统的复杂资费下的高效业务计费能力，让 CRM发挥在多变营销环境下的快速语义表达和服务提供能力？ 从而使两个系统在不同建设目标指导下，设计发展不同的数据核心模型，以及不同的应用实现框架，在整体层面上去提升 BOSS系统的业务支撑能力以及产品营销能力 内部视角 系统体系架构演进方面的探讨性课题 2推动 BOSS向 CRM方向演进，按功能域营业、帐务计费横向拆分 BOSS系统 (续 1） 20 BOSS按功能域横向拆分的总体建设思路 确定横向拆分后 的 BOSS功能架构 根据接口方式，调整现有营帐业务的逻辑处理流程，实现 BOSS营业应用与帐务应用的逻辑分拆 依据目标功能架构 制定营帐核心数据域的拆分方案 依据数据域拆分方案 定义前端营业系统与后端 融合帐务计费系统间的接口方式 根据逻辑分拆后营帐应用， 实现营业、帐务应用服务的 独立部署 根据数据分布方案及应用服务部署方案，调整BOSS系统对外服务接口 在双中心内完成营业、帐务的数据拆分及应用服务的部署 系统体系架构演进方面的探讨性课题 2 BOSS系统横向拆分总体建设方案 21 客户关系管理市场营销营销活动计划管理销售销售机会管理 销售力管理销售活动管理报价管理 销售协议管理交叉销售 / 扩展销售营销渠道管理渠道信息管理渠道费用管理渠道业务支持客户管理客户档案管理潜在客户管理客户统一信息视图密码管理订单管理订单生成 订单分解 订单调度订单变更 订单完成 订单查询客户知识库知识管理知识搜索帐务管理欠费管理帐单管理销帐处理帐务处理用户帐务处理 客户帐务处理帐户帐务处理余额控制资费预先告知产品管理产品生命周期管理产品目录管理产品规格管理资费管理科目管理资费管理合作伙伴关系管理资质管理 资料管理投诉管理 需求管理结算网间结算 漫游结算C P/ SP结算集团公司结算合作伙伴管理资源管理资源生成资源信息维护收入保障欺诈管理帐户资料管理信用度管理信用度管理积分管理黑名单管理余额提醒产品与资费管理批价VA S 批价采集采集预处理过滤与合并开通开通工单管理统一开通管理服务与资源管理业务功能合作伙伴产品和定价管理渠道考核管理产品资费模拟批价余额预留充值充值基础应用工作流管理内容管理搜索引擎用户权限管理业务规则管理稽核 接口 组织机构管理系统管理统计分析营销活动执行管理分发格式化资源调配资源使用资源管理规则维护资源查询用户认证管理客户服务业务受理 客户投诉管理 客户咨询管理客户 SL A 管理缴费与预缴 催缴 积分服务 主动服务管理异地服务客服力管理预约服务信息查询协议管理考核与评估客户关系管理客户关系管理产品管理产品管理融合计费帐务融合计费帐务资源管理资源管理统一门户与系统管理统一门户与系统管理接口管理接口管理开通开通通用工具通用工具统计分析统计分析BOSS横向拆分的目标功能架构 系统体系架构演进方面的探讨性课题 2 BOSS系统横向拆分总体建设方案（续 1） 22 BOSS系统横向拆分总体建设方案 营帐核心数据实体的拆分方案 帐户、客户归属关系用户、客户归属关系用户、帐户默认付费关系R e la t io n sh ip _ 4R e la t io n sh ip _ 5R e la t io n sh ip _ 6R e la t io n sh ip _ 7指定帐户 指定用户客户帐户用户业务工单 业务资源用户终端、预缴用户促销用户产品用户积分代付关系R e la t io n sh ip _ 1 0R e la t io n sh ip _ 1 1帐单帐本欠费催缴计划表欠费催缴工单催缴规则资金交易记录A C C _ I D帐户信用度拆分后的营业子系统数据域 拆分后的帐务子系统 目前 BOSS营帐子系统中涉及客户资料和营销资料的数据库实体全部划到营业子系统，从系统层面只有营业子系统才保留完整的客户资料； 把目前 BOSS营帐子系统中涉及资金、帐单、催缴计划的所有实体都划入帐务管理子系统，在帐务管理子系统中这三个核心模块之间通过各自实体上的 ACC_ID进行关联，各实体上的ACC_ID也是帐务管理子系统与营业子系统中核心资料联系的唯一纽带； 23 拆分后营业和帐务子系统之间接口方式及原则 序号 接口方式 使用途径 典型业务举例 1 表接口 针对需要有跨库事务操作的业务，采用表接口方式 用户预缴充值、欠费停复机 2 corba查询接口 针对前台需要跨库查询数据判断和展示的，采用 corba接口 过户中的欠费判断、用户预缴充值时客户身份确认 3 API查询接口 针对 BOSS对外服务接口中业务逻辑内部需要跨库查询资料，采用 API查询接口 IVR语音、银行充值、黑名单检查时报损帐单查询 帐务处理 计费子系统 营业子系统 帐务管理 子系统 送资料和免费资源给计费： 表接口 实时监控费用： socket 日帐单费用： dbconnect 月帐单确认： 表接口 送已批价详单： 表和文件接口 停复机工单 ： 表接口 查询客户资料 ： API接口 业务中的充值 ： 表接口 余额、费用查询 ： CORBA接口 BOSS系统横向拆分总体建设方案 拆分后前端营业系统与后端融合帐务计费系统间的接口方式及原则 24 BOSS系统横向拆分总体建设方案 营帐数据域拆分后原有营帐关键业务的实现流程 25 BOSS系统横向拆分总体建设方案 营帐数据域拆分后原有营帐关键业务的实现流程（续 1） 26 系统体系架构演进方面的探讨性课题 3对引入新技术平台、业务架构的总体考虑 新业务快速上线 灵活的业务流程支撑 快速的产品推广支撑 灵活的资费政策支撑 系统具有良好的稳定性 降低系统间关联度， 降低故障影响范围 系统具有较高的可配置 能力业务流程及规则可 管理、可配置 系统可维护 具有运行监控能力 系统具有良好扩展性 技术可管理性， 业务规则可见 人员合理投入， 开发成本可控 新业务快速部署 （工期尽可能短） 市场人员 维护人员 建设人员 对于系统架构的发展演进，各相关人员所提出的能力 要求最终聚焦在两个方面： 系统具备较高稳定性 系统支撑具备较高灵活性 07年我们通过 BOSS双中心拆分 ，较大程度增强了系统 稳定性， 那么 08年我们是否可以通过新技术架构 、 业务 架构的深入应用 ，在提升系统支撑灵活性方面来做出有价值 的实践和探索 27 系统体系架构演进方面的探讨性课题 3新技术架构、业务架构的支撑能力度分析 BOSS新体系架构的组成 基于新的体系架构，我们能够实现： 将现有面向功能垂直式的系统开发模式转变为流程导向，面向服务的开发模式 实现业务规则可配置及检测点的动态定义 实现业务流程与业务数据的分离，从而支撑业务流程的灵活配置 实现业务过程的可视化开发，及服务组件的规范化管理 从而，我们能为系统相关人员带来 ： 满足市场人员 新需求的快速上线，极大缩短响应周期 业务流程的灵活配置，支持市场营销的快速变化 快速的产品推广，缩短产品上市周期，增强市场竞争力 满足维护人员 系统具有较高的配置能力 系统服务间松散耦合 系统具有运行监控能力 满足建设人员 服务组件可管理，业务规则可见 配置多于代码开发，新业务实现快速部署 开发成本可控，人员投入合理 28 系统体系架构演进方面的探讨性课题 3新技术平台及业务架构的演进实施策略 J2EE SERVER BOSS CORBA服务的 EJB接口层 BOSS业务处理流程组装层 EJB服务层 EJB服务接口 BOSS WEB服务层 BOSS CORBA 服务层 BOSSWEB服务层 EJB服务接口 流程组装 CORBA封装 流程规则定义 J2EESERVER EJB服务层 BOSS CORBA 服务层 营帐数据库 BOSSWEB服务层 EJB服务接口 流程组装 流程配置 规则定义 J2EESERVER BOSS业务服务层 营帐数据库 产品管理平台 资源管理平台 业务规则平台 SOA总线 第一阶段 在 WEB服务层与 CORBA层间引入 EJB服务层 基于 APPFRAME平台的构建 EJB服务层 实现部分核心业务流程的重构和前移 在 EJB服务层实现资源平台、规则平台服务接口的应用集成 第二阶段 EJB服务层实现 BOSS全部对外服务接口的封装 实现 CORBA服务接口的全部迁移，统一由 EJB层对外提供 基于 AppFrame业务架构完整构建部分业务的整体处理流程 仍需继续保留的 CORBA接口以系统内部服务组件的形式纳 入 EJB层注册管理 第三阶段 在 EJB服务层全面重构 BOSS后台服务，实现 系统体系架构的最终转型 逐步将系统 CORBA服务全面迁移至 EJB服务层，完成 BOSS业务处理流程的完整重构 利用 APPFRAME平台提供业务框架、流程框架实现流程驱动的业务处理模式，以及面向服务的业务过程组装模式 这种体系架构的演进过程，也是 NGBOSS的建设过程；发展演进的结果不仅实现了 BOSS体系架构的整体转型，同时也满足了 NGBOSS的建设目标 29 BOSS营帐历史库的总体建设思路 30 系统体系架构演进方面 营帐历史库的建设 历史归档数据 BOSS营帐历史库 营帐历史库建设定位 营帐历史库建设目标 历史数据归档的定位 历史库只针对过往业务历史数据中已超过生命周期的历史数据实施归档和存储 而当前业务数据以及还在生命周期内的历史数据仍保存在生产库中 历史库使用的定位 历史库主要针对系统维护人员及营业人员提供用户的相关历史信息查询 ,用于报障处理及问题分析 历史库不直接面向客户为其提供信息查询 通过营帐历史库的建设，实现BOSS业务历史数据的分级管理和存储，保障生产库数据规模维持在一定的增长水平，从而提高 BOSS系统的总体运行效率 通过构建历史数据迁移控制平台，实现对迁移目标、规则、及迁移方式的配置，并通过自动化的数据迁移模块实现营帐历史数据的自动迁移，提高历史数据维护的工作效率，降低迁移过程的复杂度 31 BOSS营帐历史库建设 历史数据迁移控制平台建设方案 执行计划 配置模块 控制平台界面展现 迁移目标 配置模块 迁移操作模板 配置模块 数据迁移规则 配置模块 数据迁移脚本 生成模块 数据迁移 日志查询模块 数据迁移调度模块 数据迁移规则管理控制域 数据迁移执行服务功能域 中心 1数据 迁移执行服务 历史数据迁移控制平台 中心 2数据 迁移执行服务 迁移规则、计划 日志等数据 公共数据库 当前数据 历史数据 BOSS营帐数据库 历史归档数据 BOSS营帐历史库 历史数据归档 . 主机文件 系统 为每个待迁移 数据的实体生 成的迁移执行 脚本 依据迁移操作模板以及规则为每个待迁移数据的实体生成迁移操作脚本 脚本 获取 1 1 2 3 4 5 6 32 BOSS系统业务功能支撑能力提升建设措施 33 详单查询子系统 提供历史详单、 实时详单查询 帐单查询子系统 提供月帐单和即时日帐单 的费用信息查询 综合查询子系统 集成完善各类业务平台的查询功能， 提供一个完整的查询环境 外围系统接口 系统功能域 BOSS综合查询系统现状 系统体系架构 存在的主要问题 现有系统功能模块在运行期间缺乏必要的日志、状态等信息输出，造成系统的运行期管控能力较低，可维护手段较为有限，对故障的定位及解决周期较长 由于存储方式的限制，造成详单查询应用存在单点故障隐患，整个综合查询系统的容灾能力、连续运营能力无法得到有力保障 现有详单数据导出导入周期较长，且容易出错，造成 BOSS系统对外提供历史详单查询的时间无法较好控制，对客户的服务承诺也无法获得保障，降低了客户服务满意度 当前的综合查询系统与 BOSS营帐数据库间的耦合性较强，营帐库的不稳定会直接导致查询系统的服务中断 综合查询系统支撑能力提升 现有系统的发展现状及问题 34 综合查询系统支撑能力提升 改造详单文件的存储集成方式，优化详单数据的导出导入流程，提高系统服务的高可用性及数据对外提供的及时性 引入 VERITAS CFS系统软件，实现详单查询应用的分布式部署，解决系统单点故障问题，提升系统的整体容灾能力 应用主机 1 应用主机 2 应用主机 3 详单查询应用 主机文件系统 VERITAS CFS 详单查询应用 主机文件系统 VERITAS CFS 详单查询应用 主机文件系统 VERITAS CFS SAN网络 存储阵列 统一目前系统中实时详单和历史详单的文件存储格式，当月及上月数据不压缩，历史数据实施压缩 基于统一的文件格式，重构系统的详单查询应用；同时完善错单、迟到话单、入库失败话单的处理流程，实现查询时的动态数据调整 单独设计实现详单接收及存储管理模块，负责接收计费系统分发过来的计费话单，进行相应的数据格式转换并存储 BOSS计费系统 话单接收及 存储管理模块 详单文件 （以号段形式） 索引文件 详单文件 （以号段形式） 索引文件 当月详单数据 错单文件 入库失败 文件 迟到话单 文件 上月详单数据 上月以前 详单数据 压缩存储 综合查询文件存储系统 详单号段文件创建 详单索引文件创建 当月及上月 详单查询服务 历史详单查询服务 SAN 35 综合查询系统支撑能力提升 优化现有系统体系架构，增强系统运行期的管控能力 J2EE SERVER AIAppFrame平台 查询应用服务 内部服务调用总线 系统基础服务 前台界面服务 对外接口服务 综合查询 WEB服务层 详单查询服务 历史详单 查询服务 帐户余额 查询服务 综合查询应用服务层 客服系统 自助终端 业务门户 综合查询 DB BOSS营帐 DB 营帐 BC 数据库 历史库 基于 AppFrame平台重构综合查询系统 WEB服务层，实现查询应用服务的集中部署 借助 Appframe平台所提供的服务运行状态监控机制，来实现查询系统服务的运行期管控，以及异常情况下的问题快速定位 重新梳理和部署系统对外提供的查询接口，减少服务接口间的相互影响，增大数据查询处理的吞吐量 充分利用营帐 BC库，降低查询系统与营帐生产库的耦合性 36 CBOSS系统业务支撑能力的优化提升 优化现有系统架构，增强系统服务的可持续运营能力，提高集团考核成绩 采用系统专人负责制，一老带新，全面提高全体组员的维护能力 系统耦合性强 采用系统专人负责制，一老带新，全面提高全体组员的维护能力 落地方业务服务过于集中，单个业务的问题会导致整个 CBOSS异常 采用系统专人负责制，一老带新，全面提高全体组员的维护能力 应用系统版本混乱，测试环境不完整，不利于上线版本的稳定 采用系统专人负责制，一老带新，全面提高全体组员的维护能力 应用系统灵活性不够，新功能开发周期长 采用系统专人负责制，一老带新，全面提高全体组员的维护能力 应用系统本地业务过度依赖主机资源 系统发展现状及问题 37 CBOSS系统的优化建设总体思路 高灵活性 高可用性 可维护性 采用系统专人负责制，一老带新，全面提高全体组员的维护能力 降低系统服务间的依赖，避免单个业务的问题导致全系统运行的中断 采用系统专人负责制，一老带新，全面提高全体组员的维护能力 针对系统各个环节实现相应的故障应急处理功能，保证集团考核成绩稳定 采用系统专人负责制，一老带新，全面提高全体组员的维护能力 完善系统的监控预警能力，保证在出现故障时能快速定位和处理 采用系统专人负责制，一老带新，全面提高全体组员的维护能力 构建完整的业务测试验证功能，保证上线后系统的稳定运行 采用系统专人负责制，一老带新，全面提高全体组员的维护能力 基于新的技术架构实现业务流程的灵活配置，提高新业务需求的响应及时性 38 构建统一资源管理平台，提升 BOSS系统营销资源的运营管理能力 目前 BOSS系统重点实现了对号码、 SIM卡、有价卡、发票、手机终端、积分兑换实物等资源的管理 目前资源管理功能与上层业务应用服务间耦合性较强，资源的功能调整会影响业务的稳定运行 目前 BOSS系统营销资源的管理现状及问题 目前营销资源数据并未实现集中化管理，一些资源数据仍然散落在业务子系统中 现有系统对营销资源管理的功能建设较为分散，缺乏统一的规划和定义；同时在对资源管理流程方面系统缺乏灵活的规则配置 39 BOSS统一资源管理平台建设思路 资源管理 WEB服务层 (BOSS业务门户 ) 资源管理功能服务接口层 号码 管理 SIM卡 管理 终端 管理 。 资源业务统一处理流程框架 工作流平台 资源管理平台应用服务层 BOSS营销资源 DB （公共数据库） BOSS营业 功能域 渠道功能域 其他外围系统 资源业务 服务调用 （分布式服务） BOSS营帐 数据库 资源状态同步 管理服务 异步将资源最终的订购状态 同步回资源数据库中 资源数据域 改造 梳理和调整现有资源实体模型，增强实体对资源生命周期流程管理的支撑能力，并形成较为独立的资源实体数据域 资源业务功能域改造 收敛各业务系统中的资源管理服务，构建独立部署的资源业务功能域；并引入工作流平台，实现面向各类资源业务的统一处理流程框架，并支持流程规则的灵活配置 资源业务服务接口改造 梳理整合现有资源服务接口，在其平台中构建统一的资源服务接口层，并采用分布式服务模式来降低与业务模块间的耦合度 40 BOSS系统产品受理业务支撑功能的优化建设思路 BOSS产品受理支撑的发展现状 BOSS3.0实施前 BOSS3.0建设 BOSS3.0实施后 语音产品、数据产品的受理仍然由不同功能域来支撑，未实现融合 用户订购关系分散在不同业务系统中 对语音、数据产品的组合营销缺乏有效支撑 41 BOSS系统产品受理业务支撑功能的优化建设思路 同一客户统一的产品管理融合的业务受理全量的订购关系BOSS 营业库 统一产品 管理平台 BOSS 营业库 统一的产品 订单处理 流程 产品受理优化建设总体思路 用户产品订购关系管理方面 扩展现有营业系统内的用户订购模型，针对数据类产品以及产品组合包新增对应的订购关系实体，从而实现用户订购关系模型的统一以及订购数据域的统一 产品受理支撑流程方面 基于产品管理平台，融合语音产品、数据产品的订购业务流程，实现统一的产品订购支撑功能域，对外提供统一的产品的订购服务接口 针对数据产品，以及数据产品的组合营销包，引入订单处理模式，从而实现对长业务流程的支撑 产品配置及销售方面 基于统一产品平台，实现各类产品组合包的定义，允许不同产品间进行组合打包销售 在产品前台受理方面，提供目录化的产品查询、展现方式，并实现产品查找的关键词定位或拼音定位，提高产品营销的服务效率 42 用户对帐单规范化建设，提高客户话费信息满意度 在对帐单上体现用户通信使用量、免费资源使用情况 在对帐单上体现账户资金期初、期末以及进出情况 修改对帐单外观，增加套餐说明，修改优惠体现方式 制定资费配置规范，对不规范套餐重新配置并迁移用户 支持产品包概念，改进新业务包类业务的帐单展现 允许在一、三级科目间配置多种二级科目（或彻底梳理科目体系） 用户对帐单规范化 改进方向 43 用户对帐单规范化建设，提高客户话费信息满意度 用户对帐单规范化总体实施思路 实现系统后付费保底类套餐向包打套餐模式的迁移 统一采用免费资源来实现预付费套餐中的话费优惠，同时免费资源只体现对通信量的优惠 基于产品受理支撑优化的成果，实现用户对帐单中全面体现产品组合包 新增用户通信量的计算汇总科目，能够按照不同通话类型将用户的通信量体现在对账单上 构建一套完整、清晰的科目体系；明确各科目的定义及科目间的关系，将现科目间的网状关系梳理优化成层次关系 针对各类套餐模板设计其专属的对帐单科目体系；并可以根据用户层面的需求分为较粗粒度的科目展现以及细颗粒度的科目展现 44 BOSS系统渠道营销能力提升建设思路 BOSS系统渠道营销 能力提升建设 构建完整的客户信息模型，明确客户信息分层展现的内容和规则，并制定不同业务场景下客户信息展现和使用规范 整合各系统域客户信息，构建统一客户视图，实现在各类服务渠道窗口的统一展现 在 BOSS系统中逐步引入订单流程模式 ，实现对系统部分核心和主流业务的预约受理功能 满足进一步捆绑客户的业务需求以及系统中断时，核心业务可持续受理需求 基于统一资源管理平台，重构现有系统中的“直供号码包”功能，切实满足实际生产需求 实现渠道管理系统的WAP门户，支持操作人员的 WAP方式接入 完善客户统一信息视图， 提升客户信息管理能力 优化渠道营销资源的支撑能力，实现渠道 WAP方式接入 建设实现对预约营销模式的支撑 ，提升客户服务质量 45 BOSS系统运维管控能力提升建设措施 46 构建业务受理规则集中管控平台，提升 BOSS系统业务规则的可维护性及业务