某电信运营公司业务支撑系统设计与实施-27组工程实践报告.doc

北京航空航天大学软件学院北京航空航天大学软件学院 工程实践结题报告 课题名称 某电信运营公司业务支撑系统设计与实施课题名称 某电信运营公司业务支撑系统设计与实施 组组 别 别 27 组组 成成 员 员 吴威吴威 王宇王宇 朱璐朱璐 刘宇刘宇 专业方向专业方向 战略财务与金融信息化工程 战略财务与金融信息化工程 所属院系所属院系 北京航空航天大学软件学院 北京航空航天大学软件学院 指导老师指导老师 王宝会 王宝会 副教授副教授 实践起止时间 时间 2011 年年 7 月月 至至 2011 年年 8 月月 2 摘要 本报告中主要研究了某电信运营公司 以下简称 T 公司 业务支撑系统 的模型及定义 结构 功能 技术路线 建设实施等内容 通过深入分析研究 T 公司业务支撑系统的业务模型 技术架构 实施运 行 全面了解了电信运营商信息化建设的详细过程 熟悉了信息系统的设计 规划 建设 实施 测试 运行直到投入正式生产运营的全过程 进一步深 入了解了业务支撑系统对于 T 公司开展电信业务运营的重要性和必要性 也 深入体会到业务支撑系统对于 T 公司运营业务发展的重要性及对未来新型电 信业务拓展的支撑作用 本报告从应用角度 运用标杆对比 数据分析 文档分析 问卷调查等 方法 全面分析现阶段业务支撑系统的特点 提出业务支撑系统的建设需求 进而进行详细设计 系统开发 到系统建设 通过研究 基本了解了国内电信企业开展信息化建设的规律 及实际生 产系统软件开发从需求分析到版本管理的全部过程 同时 也分析了业务模 型 数据模型 软件总线架构模型对于构建强大 灵活 高效 专业的业务 支撑系统的作用 在研究过程中 实践了多种研究分析方法 练习了生产实 践型课题研究的一般方法和技巧 培养了团队合作精神 在研究中看到 T 公司业务支撑系统的建设是按照循序渐进 分步实施 先试点再推广的原则进行的 类似于其它的业务支撑系统或信息系统的建设 系统的新需求提出 设计实现 运行生产 版本更新 升级改造是一个循环 往复的过程 而系统的建设往往滞后于系统的开发与实施 业务支撑系统也 同样处于这样的状态 在全业务经营的新业务模式驱动下 在三家全业务电 信运营商的激烈市场竞争中 业务支撑系统必须依靠高度灵活 高度扩展的 基础系统架构 不断满足业务部门的新需求 不断增加富有弹性的然间功能 模块 业务支撑系统只有不断自我完善 才能更好地为业务开展做支撑 才 能具有更长久的生命周期 3 关键词 T 公司公司 业务支撑系统业务支撑系统 设计实施设计实施 目录目录 第一章 绪论 1 1 1 项目背景和意义 1 1 1 1 项目背景 1 1 1 2 项目意义 2 1 2 研究目的及内容 3 第二章 课题相关关键技术 4 2 1 系统接口规范定义核心技术 XML SOAP 4 2 1 1 XML 4 2 1 2 SOAP 4 2 2 操作服务接入核心技术 WEBSERVICES 5 2 3 业务过程流转核心技术 WORKFLOW工作流技术 6 2 4 数据共享核心技术 EAI 信息总线技术 7 第三章 现状与提出问题 9 3 1 目前信息化现状 9 3 1 1 国内电信企业信息化建设现状 9 3 1 2 T 公司信息化建设现状及进程 9 3 2 存在问题及分析 10 3 3 业务流程梳理及优化 11 3 4 功能需求 13 3 5 非功能需求 13 3 5 1 系统安全 稳定运营需求 14 3 5 2 系统扩展及功能发展需求 14 第四章 总体方案设计 15 4 1 设计思想 15 4 4 2 系统功能架构设计 16 4 3 系统逻辑架构设计 17 4 4 业务支撑系统的物理承载拓扑 19 4 5 关键技术在系统中应用 20 4 5 1 系统接口规范定义核心技术 XML SOAP 20 4 5 2 操作服务接入核心技术 WEB SERVICES 20 4 5 3 业务过程流转核心技术 WORKFLOW工作流技术 22 4 5 4 数据共享核心技术 EAI 信息总线技术 23 4 5 5 系统软件架构实现核心技术 J2EE NET 24 4 6 系统选型 24 4 6 1 软件选型原则 24 4 6 2 人机界面技术选型原则 25 4 6 3 系统可靠性实现技术造型原则 25 4 6 4 系统安全技术选型原则 25 第五章 系统测试 26 5 1 测试概述 26 5 2 测试目的 26 5 3 测试工具及测试环境 27 5 3 1 测试工具 27 5 3 2 测试环境 27 5 4 测试流程 28 5 4 1 功能域测试 28 5 4 2 性能测试 29 5 5 典型的测试用例及测试结果 30 第六章 系统实施 32 6 1 实施概述 32 6 2 硬件环境搭建 33 6 2 1 硬件的设备配置汇总表如下 33 5 6 2 2 功能模块软件安装配置 35 6 2 3 应用中间件配置 35 6 2 4 数据库软件配置 36 6 2 5 备份软件配置 36 6 2 6 安全软件配置 37 6 3 数据准备 37 6 3 1 数据准备的内容 38 6 3 2 数据转换及验证 38 6 4 系统配置 39 6 4 1 参数与基础档案配置 39 6 4 2 权限配置 39 6 4 3 资费策略配置 39 6 4 系统切换 40 6 4 1 初次数据同步 41 6 4 2 二次系统割接 42 6 5 上线支持 43 第七章系统验收及运行情况介绍 44 7 1 系统验收程序及情况 44 7 2 运行情况介绍 45 总结与展望 47 致 谢 50 1 第一章第一章 绪论绪论 1 1 项目背景和意义 1 1 1 项目背景 作为基础电信运营商之一 自 2000 年起 T 公司针对其核心业务 一直不 断致力于自身业务支撑系统的规划与建设 从而保证了以固网语音为主的基 础电信业务及增值类电信业务规模的快速发展 也实现了营业收入的稳定增 长 截至 2004 年 1 月 20 日 T 公司主营业务年增长率超过 35 固定电话用 户年增长率超过 40 宽带用户年增长率超过 300 用户总规模突破 500 万 户 截至 2006 年底 公司资产总额达到 553 亿元 比成立之初增长了近 3 倍 固定电话用户达 1820 万户 宽带用户达 314 万户 用户总规模超过 2000 万 户 但随着业务的发展 原有以业务为中心 计费功能为主的业务支撑系统 即 BSS 系统 已成为阻碍业务进一步发展的瓶颈 以及影响企业营业收入 和战略目标实现的关键 1 产品灵活度不足 终端用户对电信服务的要求越来越高 对更加灵活 的资费方案以及个性化优惠规则的产品需求逐渐增多 交叉销售 捆绑销售 等综合营销模式需求增大 BSS 系统已不能满足目前企业营销发展和行业竞 争的需要 2 系统支撑性能不足 随着用户规模的快速增长 BSS 系统原 500 万用 户承载量的系统基础远远无法满足目前约 2000 万用户的系统稳定运营需要 虽自 2004 年起 T 公司已对 BSS 系统多次扩容 但由于后期建设分散 硬件配 置及技术标准差异较大等问题 BSS 系统的系统综合性能压力较大 3 系统统一管理不足 针对新产品的烟囱式系统建设 导致与电信业务 相关的运营子系统及外部系统较多 系统整体管理分散 从而造成系统信息 共享困难 系统资源及成本浪费增大等问题 4 系统整体规划不足 随着企业经营理念的日趋成熟 产品规划 业务 2 重心等随之发生调整 BSS 系统以单一计价为主体的设计理念 缺乏对结算 多样性 产品灵活性 系统功能设置快捷性等业务支撑需求的总体规划 因此 为满足 T 公司未来业务的发展 服务水平的提高 营业收入的增 长需要 保证 T 公司企业战略目标的实现 T 公司于 2004 年提出建设业务支 撑系统并积极推动了此项工作 1 1 2 项目意义 T 公司业务支撑系统将信息化建设与业务管理模式紧密结合 并为其整 体业务支撑和信息化建设提供了一种总体设计方案 主要解决问题如下 1 增加与计费相关要素的层级设置 提供多样产品组合 业务支撑系统 通过计费类型 费率标准 优惠规则等要素的技术层级设置 形成更为灵活 个性化的组合计费模式 有利于满足不断增长的产品需求 提高产品竞争力 2 综合评估系统承载能力 提高系统支撑性能 受移动通信业务对固网 电信业务的冲击影响 自 2008 年起 T 公司用户量呈持续下滑趋势 故业务支 撑系统的承载容量设定为 1800 万用户 预计可稳定满足 T 公司业务处理压力 有利于其持续为用户提供快速 准确 及时的业务服务 3 建立统一业务支撑平台 制定总体规范 打破信息孤岛 通过统一标 准的系统设计 建设及管理 提高系统各业务功能处理能力 实现信息及资 源共享 有利于客户化营销 满足 T 公司未来 3 年业务的发展 并实现营业 收入的长效增长 增强企业自身的综合竞争能力 4 调整系统建设指导思想 建立整体规划目标 T 公司通过业务支撑系 统的建设 将 三户模型 概念引入系统设计 实现涉及计费 综合营业 综合客服 营销管理 支撑网管等 11 个功能域的全业务支撑体系打造 有利 于引入先进的观念以及流行技术 实践国际全业务经营理念 从而通过以市 场为导向 客户为中心 效益为目标的系统总体规划设计 最终实现 4321 总体目标 即实现四个特征 综合化 统一化 个性化 信息化 三个能力 实时处理能力 快速响应能力 集中管理能力 两级架构 集团 3 和省级 一个中心 T 公司统一的产品中心 1 2 研究目的及内容 通过研究 T 公司业务支撑系统的模型及定义 结构 功能 技术路线 接口实现 安全要求 建设实施等内容 深入分析研究 T 公司业务支撑系统 的业务规范 技术规范 全面了解电信运营商信息化建设的详细过程 同时 进一步认识到业务支撑系统对于 T 公司开展电信业务运营的重要性和必要性 也深入体会到该系统对于 T 公司运营业务发展的重要性及对未来新型电信业 务拓展的支撑作用 通过对 T 公司信息化建设的研究 熟悉了业务支撑系统从总体规则制定 业务需求分析 项目可行性研究 咨询 整体需求确认 到系统的设计 规 划 建设 实施 测试 运行 直至投入正式生产运营的全过程 同时 着 重对业务支撑系统的设计 测试 实施等环节进行了重点研究 4 第二章第二章 课题相关关键技术课题相关关键技术 2 1 系统接口规范定义核心技术 XML SOAP 2 1 1 XML XML 即可扩展标记语言 它与 HTML 一样 都是 SGML Xml 是 Internet 环境中跨平台的 依赖于内容的技术 是当前处理结构化文档信息的有力工 具 扩展标记语言 XML 是一种简单的数据存储语言 使用一系列简单的标记 描述数据 而这些标记可以用方便的方式建立 虽然 XML 占用的空间比二进 制数据要占用更多的空间 但 XML 极其简单易于掌握和使用 XML 与其他数 据表现形式最大的不同是它极其简单 这使得其易于在任何应用程序中读写 数据 并很快成为数据交换的唯一公共语言 XML 文档结构一般是由 XML 序言开始 代码中的第一行便是 document 序 言 这一行代码会告诉解析器和浏览器这个文件应该按照前面讨论过的 XML 规则进行解析 第二行代码 则是文档元素 它是文件中最外面的标 签 所有其他的标签必须包含在这个标签之内来组成一个有效的 XML 文件 第三行代码是注释 XML 文档结构如下图 2 1 2 SOAP SOAP 即简单对象访问协议 简单对象访问协议 SOAP 是一种轻量的 简单的 基于 XML 的协议 它被设计成在 WEB 上交换结构化的和固化的信息 SOAP 可以和现存的许多因特网协议和格式结合使用 包括超文本传输协议 5 HTTP 简单邮件传输协议 SMTP 多用途网际邮件扩充协议 MIME 它 还支持从消息系统到远程过程调用 RPC 等大量的应用程序 SOAP 包括四 个部分 1 SOAP 封装 它定义了一个框架 该框架描述了消息中的内容是什么 谁应当处理它以及它是可选的还是必须的 2 SOAP 编码规则 它定义了一种序列化的机制 用于交换应用程序所 定义的数据类型的实例 3 SOAPRPC 表示 它定义了用于表示远程过程调用和应答的协定 4 SOAP 绑定 定义了一种使用底层传输协议来完成在节点间交换 SOAP 封装的约定 值得注意的是 SOAP 消息必须用 XML 来编码 SOAP 的优点包括可扩展 简单 受限制小 与厂商 编程语言 平台无关 2 2 操作服务接入核心技术 WebServices WebService 是由企业发布的完成其特定商务需求的在线应用服务 其他 公司或应用软件能够通过 Internet 来访问并使用这项在线服务 它是一种构 建应用程序的普遍模型 可在任何支持网络通信的操作系统中实施运行 webservice WebService 是基于网络的 分布式的模块化组件 它执行特定的任务 遵守具体的技术规范 这些规范使得 WebService 能与其他兼容的组件进行互 操作 InternetInter OrbProtocol IIOP 都已经发布了很长时间了 但是 这些模型都依赖于特殊对象模型协议 而 WebServices 利用 SOAP 和 XML 对这 6 些模型在通讯方面作了进一步的扩展以消除特殊对象模型的障碍 WebServices 主要利用 HTTP 和 SOAP 协议使商业数据在 Web 上传输 SOAP 通 过 HTTP 调用商业对象执行远程功能调用 Web 用户能够使用 SOAP 和 HTTP 通 过 Web 调用的方法来调用远程对象 2 3 业务过程流转核心技术 WorkFlow 工作流技术 工作流 指的是一系列相互衔接 自动进行的业务活动或任务 工作流 技术起源于 20 世纪 70 年代中期对办公自动化领域的研究 1993 年 工作流 管理联盟 WorkflowManagementCoalition 成立 并发布了用于工作流管理 系统之间互操作的工作流参考模型 并制定了一系列工业标准 工作流技术 的应用对可视化设计流程 B S 结构 提高安全性等优点 工作流 Workflow 就是 业务过程的部分或整体在计算机应用环境下 的自动化 它主要解决的是 使在多个参与者之间按照某种预定义的规则传 递文档 信息或任务的过程自动进行 从而实现某个预期的业务目标 或者 促使此目标的实现 简单地说 工作流就是一系列相互衔接 自动进行的业 务活动或任务 一个工作流包括一组任务 或活动 及它们的相互顺序关系 还包括流程及任务 或活动 的启动和终止条件 以及对每个任务 或活动 的描述 工作流在大多数的实际应用中的情况可以这样来简单地描述 在网络 服务器和多台计算机客户端的硬件平台上 业务过程按照预先设定的规则并 借助应用程序和人对相关数据的处理而完成 例如 在日常办公中 当撰写 好某份报告之后 可能需要将其提交 步骤 1 给领导进行审阅或批示 审 批意见可能需要汇集并提交给另外一个人 步骤 2 3 以便对报告进行进 一步的修改 这样 可能会形成同一篇文档在多个人之间的顺序或同时传递 步骤 4 5 6 对于这样的情况 我们可以使用工作流技术来控制和管理 文档在各个计算机之间自动传递 而非手工传递 这就可以称之为工作流 7 实际上 工作流技术在现实生活中能够完成更多更复杂的任务 如企业 或机构 内部的各种数据 信息的自动化处理 多种业务流程的整合 企 业 或机构 之间的数据信息交换 借助 Internet 技术实现跨地域的数据传 输和处理等 2 4 数据共享核心技术 EAI 信息总线技术 EAI 是企业应用集成 EAI 是将基于各种不同平台 用不同方案建立的异 构应用集成的一种方法和技术 EAI 通过建立底层结构 来联系横贯整个企 业的异构系统 应用 数据源等 完成在企业内部的 ERP CRM SCM 数据 库 数据仓库 以及其他重要的内部系统之间无缝地共享和交换数据的需要 有了 EAI 企业就可以将企业核心应用和新的 Internet 解决方案结合在一起 EAI 包括的内容很复杂 涉及到结构 硬件 软件以及流程等企业系统的各 个层面 例如 业务过程集成 当对业务过程进行集成的时候 企业必须在各种业务系 统中定义 授权和管理各种业务信息的交换 以便改进操作 减少成本 提 高响应速度 业务过程集成包括业务管理 进程模拟以及综合任务 流程 组 织和进出信息的工作流 还包括业务处理中每一步都需要的工具 应用集成 为两个应用中的数据和函数提供接近实时的集成 在一些 B2B 集成中用来实现 CRM 系统与企业后端应用和 Web 的集成 构建能够充分 利用多个业务系统资源的电子商务网站 8 数据集成 为了完成应用集成和业务过程集成 必须首先解决数据和数 据库的集成问题 在集成之前 必须首先对数据进行标识并编成目录 另外 还要确定元数据模型 这三步完成以后 数据才能在数据库系统中分布和共 享 集成的标准 要实现完全的数据集成 必须首先选择数据的标准格式 集 成的标准化促成了信息和业务数据的共享和分布 构成了企业应用集成的 核心 包括 COM DCOM CORBA EDI JavaRMI 和 XML 平台集成 要实现系统的集成 底层的结构 软件 硬件以及异构网络 的特殊需求都必须得到集成 平台集成处理一些过程和工具 以保证这些系 统进行快速安全的通信 9 第三章第三章 现状与提出问题现状与提出问题 3 1 目前信息化现状 3 1 1 国内电信企业信息化建设现状 随着国内电信运营企业在网络覆盖 产品种类和服务质量等方面逐渐呈 现趋同性 中国电信行业的竞争逐渐趋于白热化 全业务运营模式将成为电 信企业的主导业务发展方向 通常电信企业信息化系统主要包括 3 个子系统 即 BSS 业务支撑系统 属于生产系统 包括主营业务的计费 营帐 客服 等内容 OSS 运营支撑系统 属于维护系统 包括各业务系统的网管 监 控 应急处理等内容 MSS 管理信息系统 属于管理系统 包括办公自动 化 财务管理和人力资源管理 采购 计划 项目建设等内容 相对于其他 行业 国内电信企业信息化程度较高 但由于国内各电信运营商的业务支撑 系统普遍是面向单一移动网或固定网业务运营而规划和建设的 在系统支撑 能力均不能满足全业务运营需求 故近年电信行业信息化建设如火如荼 中国电信 中国电信的业务支撑系统实现了全省集中 实现了电信现有业务的 融合业务支撑 中国移动 中国移动支撑系统以 BOSS 为核心 实现了全省集中的移动语音业 务及移动数据业务的支撑 中国联通 中国联通支撑系统实现了全省集中 实现了联通现有综合业务 包 括综合业 C 网业务 G 网业务 长途 数据专线 互联网业务等 多种业务 的支撑 中国网通 中国网通支撑系统到目前为止 完成了全省集中及现有融合业务的 支撑 3 1 2 T 公司信息化建设现状及进程 自 2004 年起 T 公司通过业务支撑系统建设 有效引入先进概念及技术 打破电信运营 网络管理 管理业务支撑等基础系统间的技术壁垒 在搭建 10 了稳定的综合业务支撑系统 促进营业收入获取的同时 实现信息 资源的 统一和共享 为满足了未来业务发展的需要 践行全业务经营理念提供了可 能 目前业务支撑系统已实现异地试点运营 可支持各项业务运营功能 初 步完成 T 公司信息化建设规划目标 T 公司原有的 BSS 系统是于 2000 年完成业务支撑建设 受当时整体发展 理念 业务范围等因素局限 该系统建设仅以电信运营计费为核心 满足以 固网语音业务为主体的需求 从而严重制约了 T 公司的当前业务发展及产品 重心转变 故 BSS 系统虽自 2004 年起经多次系统扩容及建设仍不能满足企业 业务发展及稳定运营的需要 2004 年 T 公司启动业务支撑系统项目 发起建设涵盖采集 计费 结 算等业务为核心 涉及采集 计费 综合帐务 综合结算 综合营业 综合 客服 大客户管理 决策支持 营销管理 渠道管理 支撑网管等 10 个功能 域的业务支撑系统 2006 年起 T 公司分别在北京 总中心 及河北 辽宁 省中心 针对业务支撑系统搭建环境模型 以便保障系统设计验证 测试 及试点实施等工作推进 截至 2010 年 T 公司已实现业务支撑系统上线及试 点运营 从而也完成了各功能域全面切换至新系统运行 3 2 存在问题及分析 随着 T 公司多年业务发展 基础电信业务及增值类电信业务种类增多 BSS 系统的业务支撑力不足问题已逐渐成为阻碍企业业务进一步发展的瓶颈 由于电信行业的经营特点 服务生产与收入实现周期较短 高效 稳定的计 费处理是企业收入实现的核心 因此信息化建设对计费系统的要求非常高 面对 T 公司发展现状 原有系统计费功能所存在的问题逐渐显现出来 1 以业务为中心的垂直系统设计 不能有效支持以客户为中心的业务需 求 由于原有 BSS 系统以用户业务为计费统计核心 忽视了用户的个人客户 属性 故不再能满足以客户为基础的捆绑销售 交叉销售等多元化营销模式 的发展需要 因此 T 公司在业务支撑系统建设中 科学引入由客户 用户 帐户构成的 三户模型 概念 为后期营销所需的客户群细分 消费习惯跟 11 踪 宣传促销等业务数据分析提供了可能 2 计费系统规则配置单一 不能满足全业务运营需要 交叉销售 产品 组合计费是未来电信业务运营的基本要求 原有 BSS 系统的计费标准及统计 规则单一 且只能按月进行汇总计费 不能根据客户需求对不同的服务类别 进行差异化计费或阶梯价格计费 从而缺乏对计费功能灵活配置的能力 丧 失其在套餐领域的竞争力 业务支撑系统通过计费类型 费率标准 优惠规 则等要素的组合设置 有效的弥补了这一不足 3 产品管理 计费分散 缺乏统一的产品中心支撑平台 由于 BSS 系统 的建设时间较早 系统当前功能 技术均已缺乏行业先进性 因此面对各省 分公司的特色产品需求 新产品 计费 系统的烟囱式建设现象十分普遍 个别省分公司的外围计费系统多达十几个 从而导致帐务 结算管理分散 基础系统重复建设 进而造成系统信息共享困难 系统资源及成本浪费增大 等问题 4 系统灵活度不足 功能优化及产品支持研发周期较长 由于互联网 移动业务的高速发展 电信产品更新周期缩短 业务支撑系统规范成熟 接 口标准 管理统一 较 BSS 系统更适用于未来产品组合 业务附加等需求的 实现 开发和接入 3 3 业务流程梳理及优化 经过对现有业务的深入分析 我们梳理 分析业务流程的过程就是发现 问题 优化提高的过程 也是重新还原业务本质 明确业务核心的过程 例 如业务支撑系统中计费功能域的业务流程梳理 优化 不仅涉及业务计费数 据的采集 预处理过程 对处理后的计费数据进行批价的过程 合并帐务处 理及对数据的备份与恢复等业务范围 还可涵盖 三户模型 计费体系建立 计费配置管理多元化 产品平台搭建等多方面核心内容 通常电信行业计费 方式可分为实时计费和非实时计费 鉴于 T 公司仅智能网 含预付费 业务 采用实时计费方式 其他业务均采用非实时计费方式 以下流程描述以非实 时计费方式为主 12 如图计费处理流程优化说明 1 数据采集 用户的产品协议生效期间 系统自动对产品使用记录进行 数据采集 数据采集对象 即计费统计依据为电话详单 以下简称详单 包 括主叫号码 被叫号码 通话起止时间 通话时长 计费类型等信息 每条 详单单独计费 不重复 不累计 采集途径为程控交换机定时生成原始数据 文件 采集系统通过前端的数据采集机与交换机直接连接 并自动定时采集 数据 2 预处理 采集到的数据需进行比对去重检验 以保证计费准确 预处 理过程中需检验内容主要有三方面 即计费系统接收到采集系统获取的计费 数据文件后 系统生成核对文件以进行总数核对 保证系统衔接无误 并在 发现已传送的话单丢失或被破坏时 系统需发送恢复信息 再次请求重新发 送这部分话单 系统还需要对数据的有效性进行检查 不但需对详单数据逐 条进行重复性筛查 去除 同时需将去重结果与历史数据进行比较 避免数 据文件重复处理 3 计费 预处理后的数据可根据其所对应的计费类型 按系统预先设定 的费率定价标准 优惠规则等要素进行自动费用计算 计费系统可通过费率 优惠规则 计算顺序等技术要素设定 支持灵活 多样的价目调整方案 对 预处理后的标准话单 计费系统可结合用户资料 根据设定的资费标准 协议 优惠文件 进行计费批价 同时形成符合标准的用户明细详单 4 帐务合帐处理 系统定期 每月 18 日 根据用户明细清单按客户进 行合帐处理 并可根据各种费用类型的付费方式 付费周期和付费帐户的不 同设置进行差异化计费汇总 生成帐单记录 以便客户灵活付费 同时系统 对计费帐务部门生成一套帐前报表 用于与之后生成的收入月报进行核对 该过程包含资料处理 固定月租费的计算 合帐处理 帐单级优惠处理 补 收补退处理 应收帐单的生成等环节 5 收入入帐 客户付费后 系统每月出具各类业务的收入汇总表 财务 13 人员将收入汇总表与帐前报表相核对 保证收入数据的一致性 并作相应财 务处理 3 4 功能需求 业务支撑系统需全面支持 T 公司业务所涉及的采集 计费 综合帐务 综合结算 综合营业 综合客服 大客户管理 决策支持 营销管理 支撑 网管等 10 大功能域 就业务支撑系统的核心计费功能而言 该系统需满足以 下基本要求 1 用户和帐户的多对多关系及客户化帐单 在用户和付费方均同意的情 况下 用户可以选择产品类型 如市内电话费 和帐户的付费关系 确定付费 关系后 用户可以对自己的帐单项予以定制并选择帐单的获取方式 如纸质 电子邮件 通知等 通过业务支撑体系的设计 建设 支持 三户模型 营 销管理核心 准确体现及应用客户的社会域信息 用户的业务域信息和帐户 的资金域信息 2 话费限额管理 对高额话费的监控分为电信企业防范措施和用户自我 保护措施 电信企业将每个用户的高额话费限制跟客户的付费信用度挂钩 对较差信用度的用户进行控制 以免产生大额话费流失 当电信企业为用户 设置的话费额度与用户自己设置的话费额度不一致时 以低的额度为准 该 管理可通过智能网业务中涉及计费 账务合帐处理功能的技术功能域实现 3 增强优惠处理 灵活的优惠策略和营销政策是电信企业制胜的一大法 宝 多元化的计费功能设计可支持准确 灵活的产品计费方案 例如 针对 计费和帐务合帐处理流程 可通过计费 付费账户处理规则中所涉及的计费 类型 付款周期等多重参数组合设置 实现多样 便捷的优惠产品支撑 3 5 非功能需求 除系统功能需求以外 T 公司业务支撑系统还需要满足以下非功能需求 14 3 5 1 系统安全 稳定运营需求 1 安全性 提供完善的信息安全机制 以实现对信息的全面保护 保证 系统的正常运行 不影响业务支撑系统和其它系统本身的安全性能和业务性能 要具有监控 告警机制 对于数据交换写日志处理 2 高效性 可支持 1800 万用户 容余不低于 30 承载 要保证接口 数据的及时传递 对于定时数据传递要提供告警机制 同时保证接口简单明 了 便于形成 操作和传输 3 完整性 应防止非系统级的数据丢失或出错 提供每个环节处理完成 后的总量审核机制 可按时间 阶段提供数据的备份与恢复 4 准确性 具备容错和自动恢复的功能 提供对数据正确性进行验证的 审核机制 5 可靠性 各省级系统既能进行统一处理 又能在发生故障时实现系统 独立运行 3 5 2 系统扩展及功能发展需求 1 开放性 系统应采用开放的体系架构 可保证不同厂商的不同部分产 品的有机集成 2 先进性 系统应参考成熟且先进的工业标准 3 灵活性 系统应满足未来灵活市场活动的需要 接口能灵活地支撑综 合营业 帐务系统和其它相关系统的业务需求 例如 支持灵活的产品和业 务种类的增加和变更 支持快速的配置优惠策略和计费方式等市场活动的实 施 支持工作流程的灵活定制 支持灵活的报表 决策支持 经营成本分析 支持对服务质量的量化管理等 4 扩展性 系统的架构 性能扩展能力和系统选型应能够支持 T 公司未 来 3 年可预见的业务发展的要求 15 第四章 总体方案设计第四章 总体方案设计 4 1 设计思想 某公司业务支撑系统的规划遵循某公司 IT 规划要求 受业务支撑系统 TOSS TMSS 相关的系统总体规范和业务技术规范的约束和指导 参考了电信 管理论坛 TM Forum NGOSS 知识库中的概念 结构和模型 按照四个特征 综合化 统一化 个性化 信息化 三个能力 实时处理能力 快速响 应能力 集中管理能力 两级架构 集团和省级 一个中心 某公司集 团公司统一的产品中心 的总体设计思想 以达到支持公司全业务开展和客 户资源的管理 统一架构和接口 统一数据模型和编码 提供账单 产品 自助服务等个性化的定制和全程全网业务分析能力 更好满足公司业务长期 发展需要的目的 业务支撑系统采用 一个体系结构 多个子系统 的设计原则 全面进 行规划 一个体系结构是指统一的电信业务支撑系统 多个子系统是指在一 个电信业务支撑系统中的各专业计费子系统 结算子系统 采集子系统 综 合客户服务子系统 综合帐务子系统 全面规划是为了明确目标和路线 突 出各应用系统之间的联系 便于持续推进 系统业务设计思想是以构建三户模型为核心 面向客户 构建业务核心 模型 1 客户是任何使用过 正在使用 计划使用 可能会使用本企业产品或 对本企业产品感兴趣的人或组织 他们在与本企业的商务往来中扮演消费者 的角色 2 用户是本企业根据与客户签订的协议 向客户提供具体产品 这个具 体产品与客户的关系及其相关的属性集合称为用户或产品实例 3 帐户是客户使用本企业产品的付费实体 为了计费帐务的需要 本企 业为客户在运营支撑系统中建立相应的内部帐户 16 4 2 系统功能架构设计 业务支撑系统是某公司集团信息系统规划的一部分 在设计上某公司业 务支撑系统参考了 eTOM 体系 采用全国 省两级的功能架构 全国系统和省 系统分别承担不同的支撑功能建设方式 全国系统负责为集团公司的业务部门提供支撑 完成跨省业务生产的支 撑 可以根据具体业务的实际情况将功能部署到各省级业务支撑系统系统 全国系统通过和各省级系统的接口实现全国到各省以及省间数据交换的枢纽 省级平台之间的数据交换必须通过全国系统完成 外部系统也可以根据实际 情况接入集团级系统 全国 省级业务支撑系统系统均划分为 10 个功能域 1 综合营业功能域 2 综合账务功能域 3 计费功能域 4 综合客服功能域 5 综合结算功能域 6 营销和渠道管理功能域 7 大客户管理功能域 8 采集功能域 9 决策支持功能域 10 业务支撑网管功能域 系统功能组成结构如图 4 2 1 所示 17 某公司业务支撑系统 计费 综合 账务 综合 结算 综合 客服 大客户 管理 综合 业务 营销 渠道 管理 采集 决策 支持 业务 支撑 网管 采采集集配配置置 预预处处理理 分分发发 预预处处理理 采采集集处处理理 账账务务管管理理 账账单单管管理理 网网内内结结算算 欠欠费费管管理理 账账务务处处理理 批批价价 资资费费管管理理 故故障障申申告告 其其它它结结算算 网网间间结结算算 功功能能展展现现 大大客客户户资资料料管管理理 大大客客户户分分析析 收收费费 业业务务受受理理 质质量量监监督督 投投诉诉及及建建议议 咨咨询询及及查查询询 主主动动服服务务 工工作作流流程程管管理理处处理理 大大客客户户资资料料管管理理 大大客客户户服服务务管管理理 大大客客户户营营销销管管理理 数数据据抽抽取取 数数据据处处理理 客客户户流流失失 市市场场信信息息管管理理 市市场场活活动动管管理理 市市场场分分析析管管理理 工工作作管管理理 任任务务管管理理 营营销销服服务务 代代理理商商管管理理 代代理理商商支支持持 合合作作伙伙伴伴管管理理 招招标标体体系系管管理理 质质量量状状况况分分析析 质质量量信信息息发发布布 业业务务分分析析 结结算算分分析析 客客户户情情况况 业业务务发发展展 收收入入发发展展 竞竞争争对对手手分分析析 服服务务质质量量 营营销销分分析析 大大客客户户分分析析 图 4 2 1 系统功能组成架构图 4 3 系统逻辑架构设计 业务支撑系统采用两级系统逻辑架构 全国业务支撑系统中心与省业务 支撑系统中心内部逻辑结构相同 全国业务支撑系统中心与省业务支撑系统 中心之间 各子系统客户端与业务支撑系统中心之间 业务支撑系统与外部 系统之间 采用某公司 DCN 网实现相互的网络连接 如下图 4 3 1 图所示 18 表表现现层层 业业务务逻逻辑辑层层 数数据据访访问问层层 数数据据访访问问组组件件 Data Access 某公司业务支撑系统 Web浏浏览览器器 HTML AJAX Java Applets 用户界面 J Ja av va a客客户户端端 业业务务平平台台 应应用用支支撑撑平平台台 J2EE应应用用服服务务器器 NET 数数据据交交换换平平台台 采采集集计计费费综综合合帐帐务务综综合合客客服服 综综合合营营业业大大客客户户管管理理 营营销销渠渠道道 管管理理 业业务务支支撑撑网网管管 工工作作流流引引擎擎报报表表引引擎擎 抽抽像像数数据据访访问问接接口口 D Da at ta aB Ba as se e P Pr ro ov vi id de er r X XM ML L P Pr ro ov vi id de er r O Ot th he er r P Pr ro ov vi id de er r 综综合合结结算算 决决策策支支持持 A AS SP P客客户户端端 图 4 3 1 业务支撑系统系统逻辑架构图 其中 数据层分为数据子层和数据操作对象两层 数据层是系统的基础 数据层的数据操作对象向业务层提供统一 规范的数据操作对象 用于屏蔽 业务数据的存储 组织和访问的细节 实现业务数据的充分共享 业务层必 须通过数据操作对象访问业务数据 业务层的业务逻辑通过数据层的数据操作对象访问业务数据 一组业务 逻辑过程实现具体的业务功能 业务层通过向接入层提供统一的业务逻辑过 程实现业务逻辑的共享 接入层实现系统与外部的数据交换 对于系统使用者 接入层接收使用 者的数据输入 通过调用业务层的业务逻辑过程实现具体的业务功能 并将 19 处理结果返回接入层 利用交互界面进行表示 对于外部系统 业务过程通 过接入层的接口服务完成与外部系统的数据交换 4 4 业务支撑系统的物理承载拓扑 全国业务支撑系统中心与省业务支撑系统中心物理承载拓扑相同 主要 由 计费 帐务 营业 结算 查询服务器 web service 中间件服务器 排队机 磁盘阵列 备份设备 光纤交换机 PC 服务器 运行维护终端 汇 聚交换机等硬件 以及数据库软件 分析软件和报表软件 采集 客服中间件 应用中间件 备份软件 应用软件 安全软件 第三方网管软件 DCN 网络 组成 详见下图 4 4 1 图 DCN D DC CN N网网 全全国国业业务务支支撑撑系系统统 省省分分公公司司业业务务支支撑撑系系统统 省省分分公公司司业业务务支支撑撑系系统统 图 4 3 1 业务支撑系统物理承载拓扑 20 4 5 关键技术在系统中应用 4 5 1 系统接口规范定义核心技术 XML SOAP 通过 XML 定义的 SOAP 协议数据来统一各功能域 以及业务支撑系统 与外围系统接口之间的标准数据格式 这些接口数据封装在 HTTP 协议包中 通过 Web Service 服务调用 如下图 4 5 1 1 图所示 XML 数据用于在不同的应用程序间交换数据 规范了各功能域应用之间的接口数据标准文本格式 使得不同厂商开发的应 用软件之间可以无缝连接 不需要任何格式转换软件 系系统统 2 XML 消消息息 系系统统 1 集集成成服服务务器器 系系统统 3 系系统统 4 图 4 5 1 1 4 5 2 操作服务接入核心技术 Web Services 对于同步 实时 小数据量接口 采用 WebService 技术实现 具体应用 有 综合营业 综合客服 营销渠道 大客户管理 专业计费与综合帐务之 间的接口 选择基于服务总线架构的 WebService 服务调用和 JMS 异步消息机 制实现 例如 综合客服功能域中客户服务处理工单状态查询和历史查询接口采 用 Web Service 方式详见表 4 5 2 1 接口描述接口描述接口类型接口类型实现机制实现机制消费者消费者 21 向客服查询客户的各种服务工单 记录 同步 Web Service 大客户 表 4 5 2 1 Web Service 调用的输入参数详见表 4 5 2 2 序序 号号 字字 段名称段名称 字段含义字段含义数据类型数据类型 长度长度可可 空空 取值说明取值说明 举例举例 1 客户标 识 CUST IDNUMBER 12 2 客户名 称 CUST NAMEVARCHAR2 60 注 客户标识和客户名称不能全 空 如果客户标识不空 才按客 户名称查询 3 开始时 间 START DATEDATETIME 4 结束时 间 END DATEDATETIME 表 4 5 2 2 Web Service 调用的输出参数详见表 4 5 2 3 序序 号号 字段名称字段名称字段含义字段含义数据类型数据类型 长度长度 可可 空空 取值说明取值说明 举例举例 1返回代码ERRCODENUMBER 8 N 2错误描述ERRMSGVARCHAR2 255 Y 3 工单记录个 数 CASE NUMNUMBER 6 Y 4工单记录 4 1工单编号CASE NBRNUMBER 10 Y 22 4 2 工单生成时 间 CREATE DATEDATETIMEY 4 3受理人CREATE USERVARCHAR2 60 Y 4 4客户标识CUST IDNUMBER 12 Y 4 5用户标识SERV IDNUMBER 12 Y 4 6 产品分类名 称 PROD TREE NAMEVARCHAR2 100 Y 4 7产品名称PROD NAMEVARCHAR2 100 Y 4 8工单类型CASE TYPEVARCHAR2 20 Y 4 9区号DIST NBRNUMBER 6 Y 4 10电话号码ACC NBRVARCHAR2 20 Y 4 11工单状态CASE STSVARCHAR2 20 Y 4 12工单内容CASE INFOVARCHAR2 1024 Y 4 13处理部门DEAL DEPTVARCHAR2 60 Y 4 14处理人DEAL USERVARCHAR2 60 Y 4 15处理时间DEAL DATEDATETIMEY 4 16所处环节DEAL STEPVARCHAR2 30 Y 表 4 5 2 3 全国中心与省中心之间的交易和查询类接口采用基于服务总线架构的 Web Service 服务调用和 JMS 异步消息机制实现 批量数据 如帐务清单 类接口采用基于接口文件机制实现 业务支撑系统与外部系统的接口要根据周边系统的实际建设情况 在保 证接口方案的可实施基础上 优先采用 WebService 服务调用和 JMS 异步消息 机制实现 4 5 3 业务过程流转核心技术 WorkFlow 工作流技术 工作流主要应用在信息调度系统中 订单 服务开通 建议投诉 如 图 4 5 3 1 所示 工作流的处理包括工作流的设计和控制 23 综合营业 服务开通 业务调度 综合客服 工单信息 投诉 申告 工单信息 业务受理服务开通 业务调度 工单信息 工单信息 工单信息 跨省业务 省省分分公公司司 业业务务支支撑撑系系统统 某某公公司司 全全国国业业务务支支撑撑系系统统 综合客服 投诉 申告 铁铁路路业业务务 调度监控 管理 调度信息 调度监控 管理 调度信息 图 4 5 3 1 工作流程图 设计工作流首先要根据具体业务的实际情况制定相应的业务流程 并尽 量优化业务流程 然后根据业务流程分析出业务流程中需要携带的业务数据 和处理这些业务数据的工作角色 并指定这些数据流向的依据 根据这些流 程数据和工作角色指定相应流程环节的数据交互和流程环节的工作角色 再 根据实际的业务流程和相关环节 指定相关的业务处理点和相应的调度规则 工作流中环节的定义尽量简单实用 而且要求完整 不要制定非常复杂 的环节也不能把一个完整的环节拆分为多个环节 4 5 4 数据共享核心技术 EAI 信息总线技术 从横向角度讲 业务支撑系统应用 BEA Web Logic 构建 EAI 信息总线 实现 10 个功能域之间通过数据总线共享接口数据 借助 Web Service 同步接 口调用机制 完成不同应用对 EAI 的通讯层中标准化数据进行请求和访问 从纵向角度讲 业务支撑系统全国中心和省中心之间综合营业 综合结 算 决策支持 营销渠道 综合客服 综合网管等功能域的小批量数据共享 24 与传递都通过 EAI 平台来实现 4 5 5 系统软件架构实现核心技术 J2EE NET 业务支撑系统应用软件采用 Java 技术开发 构建在 J2EE 平台之上 实 现 10 个功能域模块之间的跨平台特性 基于 J2EE 机构的软件 使业务支撑 系统的硬件平台可以不受操作系统选型以及应用开发语言选型的限制 提高 了硬件平台的广泛性和扩展能力 J2EE 是业务支撑系统全国中心与省中心 10 个功能域实现软件总线设计 思想的基础 例如 中间件采用了 J2EE 技术 详见表 4 5 5 1 所示 BEABEA WebLogicWebLogic WebLogic 通过 J2EE 兼容认证 基于 JMS 的消息传递 用户可以自由选择采用 WebLogic web server 或与其它 Web Server 集成 通过基于 Web 的管理界面方便的对 WebLogic 进行全面管理 性能监视管理功能有限 有广泛的开发工具支持快速应用开发 良好的技术支持 久经考验的稳定性 表 4 5 5 1 业务支撑系统全国中心与省中心 10 个功能域前台操作终端均采用 Web 界 面 应用了 NET 架构开发 Web 网站页面 使用 Microsoft Visual Studio 开 发 NET 的应用 以满足各应用软件对主流软件开发架构的支持和实现 4 6 系统选型 本着建设规模与某公司总体发展规模相适应的原则 业务支撑系统系统 选型遵循如下原则 4 6 1 软件选型原则 1 健壮性 软件具有处理各种非正常状态和事件的能力 25 2 开放性和可扩展性 系统采用多层开放体系结构 以适应传送网络技 术的演化和系统功能的扩展 并能遵循相应的国际标准 3 分布性 采用分布式协同处理技术 以提高系统的可伸缩性和可扩充 性 4 管理性 系统具有可监控 检测 分析能力 5 负载均衡性 系统具有负载均衡的处理计算能力 4 6 2 人机界面技术选型原则 1 应采用简洁 直观 友好的图形化中文界面 支持鼠标操作 2 对于业务处理界面 应保证操作人员能够完全利用键盘操作 3 对于常用环节 系统应设置快捷键以方便功能间的切换 操作及选择 键 热键 菜单选择等 的功能定义在全系统保持一致 4 应具备相应容错手段 允许操作人员有限范围的误操作 5