中国电信计费模型-总论

中国电信计费模型-总论中国电信计费模型总论 中国电信集团各级分公司计费系统的建设规划、系统实现、阶段控制和实施方案。建议内容基于本次模型设计所确定的系统模型，并满足二或三级计费体制和业务支撑网建设需求。建议部分着重从以下几个方面描述有关计费系统建设实施办法：模型的实施原则和目标模型实施总体框架运作管理机制模型转换工程实施建议模型实施风险控制模型标准检测有关企业信息和系统建设总体规划可参考TMF的eTOM模型以及中国电信集团公司的ITSP规划文档，现有计费系统模型可参照《中国电信本地业务计费系统分析与设计》和当地需求设计实现文档。模型实施原则与目标为了保证各省的计费系统工程实施推广的顺利进行，保证系统上线后的稳定性、版本的一致性，系统的开发、推广工程需要遵循以下原则：集中化原则在系统建设中，应尽量按照省集中方向进行规划和实施，业务量特别大、业务种类多的省份可以继续保留三级模式，建议逐步按照大区集中思路进行生产和管理。网络化原则消除信息孤岛的方法在于打通应用系统边界、形成网络，而不是简单的集中。数据的分布策略、应用流程的贯通、共享数据模型等都是信息共享的要素，系统应该是应用网络中的元素而不是孤立点，标准交换协议和网络化管理是实现信息共享的基本保证。版本统一原则对于三级模式建设的情况，在推广过程中要保证核心软件版本的统一。推广完成后，通过一次统一的升级达到最终版本的统一。数据继承与转换系统实施、升级过程中一个关键要点是数据的继承和模型转换，在新的模型中最核心的是产品数据，以及帐户和客户数据，必须优先制定数据模型继承转换的实施方案。业务流程服从应用软件原则对于三级模式建设的情况，应用软件应该在业务管理顺畅的本地网进行试点，试点不仅评估应用软件，而且要评估管理流程对其他点的适应性。在此基础上，其他点的推广过程中，如果遇到需要修改业务流程才能使用应用系统的情况下，必须修改业务流程。保证生产平滑过渡在试点和推广过程中，不可避免要对原系统的使用造成一定的影响，在集中化和统一版本的前提下，业务需求的满足会受到一定影响。因此，在系统建设的过程中，对于一些严重影响业务发展、业务收入、客户投诉和资金回收的需求，要进行充分考虑，并通过外围系统和外围接口实现，保障生产的顺利进行。理顺流程，建立业务需求管理机制在试点、推广过程中，最容易影响进度和版本的就是需求，需求归根结底就是业务流程，因此必须加强需求的统一管理，需求的管理不仅包括实际的业务需要，而且还要制定配套的业务管理流程。二级模式下省与本地网间为保证本地业务及时开展，应在系统建设的同时建立需求申请、审批、下发和变更管理的整套机制建立完善的组织管理机制各省、本地网应建立完整的市场——运维——开发支撑管理组织机制，由统一的部门牵头进行系统建设，并制定明确的管理考核部门、岗位和集成开发商的办法。系统建设目标有如下几点：建设符合中国电信战略需要的计费系统中国电信集团的九大战略是总体发展的需求源泉，新的计费模型建设就是要支撑和符合这些战略的需要。建设融合的先进计费系统新的系统模型旨在指导建设多业务融合、多模式融合的计费系统，如全业务的融合计费和帐务处理，预付费模式和后付费模式的融合等。另外在实时计费、多方计费、移动计费方面有明确的融合支撑方式。并建立符合企业信息共享需求的灵活数据模型来支持上述融合过程的实现。建设符合BPR思想的计费系统新的模型在数据结构和功能流程设计上体现了中国电信BPR的思想和成果，在数据处理、事后管理和与生产管理流程结合等多方面进行具体设计体现。建设支撑市场营销的计费系统在计费模型中，从数据模型、功能流程、接口协议三个主要层面落实对营销策略的支撑。产品、商品、客户概念的强调和实例化和接口协议标准为企业信息共享和与其它支撑系统业务互连提供实现基础。对定价策略和定价计划的支持，结合灵活的客户化帐务数据模型使得套餐、组合营销等业务支撑明确可实现。逐步建成完善BSN网络计费系统是BSN网络的核心组成部分，在二、三级模式下完善本级计费系统建设和上下级接口的同时，结合新建的计费网管系统优先形成中国电信的计费支撑网，并以此为基础建设或整合符合BSN要求的其它业务支撑系统。在此过程中，从数据和标准着手，逐步转换和整合，建立系统入网、升级及退网的完整机制，提炼出一整套行之有效的规划、建设、管理及运行维护的办法与体制，最终建立全面的中国电信业务支撑网体系。模型实施方案中国电信计费体制目前存在二、三级两种多级模式，未来系统的规划应以集中化思路为准，以强化区域管控和业务统一实施能力，并减少地区差异和运维压力。对于业务规模较小的省份应尽量按照省集中的二级模式建设，沿海一些发达省份可以继续保留三级模式，但在本地网一级可以考虑以地区中心、业务中心为依据合并中小本地网，形成大区制格局，贯彻集中化思路。多级模式下，在实现本级系统建设规范化的同时，重点要保证多级间上下互连和同级系统间互连的畅通性，以及接口协议的完备性，贯彻上下打通和网络统一管理、统一调度的思想。典型的系统实施方案的主要工作分解（WBS）框架如下：建设BSN需要贯彻以下几个基本理念：BSN的建设过程是逐步建设、逐步完善、不断满足业务需求的过程；BSN的建设过程要树立网络化管理思想。建设BSN一方面是要打通系统边界，消除信息孤岛，另外一方面，也要形成全网统一管理、统一调度的机制，各应用系统都应建立对应的网管体系；建设BSN要实现四个打通；无论是采用两级还是三级，各级的纵向职能划分必须明确，在三级纵向网络职能划分中，集团、省主要负责网络规划及数据的管理、监控与加工，本地网的重点则是维护与使用的统一，这里包括用户界面、用户数据、接入平台的维护等；BSN中核心系统是一个整体，计费系统、CRM、结算系统、经营分析系统等在数据、流程等方面密不可分，同时都以数据平台为基础；垂直三层结构中数据平台仍然是基础核心；BSN建设过程中要注意系统网络边界的演变，比如与通讯设备、MSS、OSS的边界演变，做好对应功能和要求的适应调整；BSN建设过程是循序渐进的，1～2年内，进行深入广泛的培训，开展数据清理、整合工作，制订各层的数据和系统标准，完善基础设施，在总体规划的框架下本着急用先行的原则建设新系统，并逐步在现有数据的基础上经过转换、过渡、建立起共享的主题数据库，初步形成业务支撑网；3～5年内，进一步完善数据和系统标准，并在此基础上建立系统入网、升级及退网的完整机制，提炼出一整套行之有效的规划、建设、管理及运行维护的办法与体制，形成完善的业务支撑网。典型系统建设的过程可以分解为以下几个主要阶段：试点研发第一阶段工程准备规划论证第二阶段试点研发系统标准实现第三阶段系统割接模型转换系统割接第四阶段集中与推广分步实施集中与推广第五阶段运作维护事后控制运作维护详细业务需求调研省级计费迁移需求模型转换方案准备协议接口改造试点应用系统研发外围系统研发应用网管研发数据迁移方案准备系统割接方案准备风险防范措施准备试点研发第一阶段工程准备规划论证第二阶段试点研发系统标准实现第三阶段系统割接模型转换系统割接第四阶段集中与推广分步实施集中与推广第五阶段运作维护事后控制运作维护详细业务需求调研省级计费迁移需求模型转换方案准备协议接口改造试点应用系统研发外围系统研发应用网管研发数据迁移方案准备系统割接方案准备风险防范措施准备系统割接数据迁移业务调整割接制定需求及版本管理规范制定系统推广或分步集中方案运维机制调整支撑办法确定推广实施系统运作维护需求版本变更控制审核校验绩效考核标准检测支撑系统网络化建设管理思路总体业务需求调研系统技术需求调研系统体制要求BSN网建设需求模型差异分析全程管理工程准备依据新模型实施系统建设，关键要点是对数据模型和数据进行继承转换。新的系统模型立足点是数据模型，并以此为基础建立了新的功能流程模型、接口协议规范和应用网管规范，其中数据模型包含了传统意义上的计费数据和产品、客户主题数据模型。数据模型的转变导致现有系统换版和新系统建设规划上需要首先考虑全新的数据迁移转换方案，以便继承原有的生产数据，然后考虑在应用系统切换和业务功能开展、接口协议标准改造、应用网管机制建立等各阶段如何分步实施。新数据模型中最基本的核心数据模型相对原《中国电信本地业务计费系统分析与设计》规范的静态三户模型做了较大调整，强化了产品和客户的实体概念，形成“客户、帐户、用户（产品实例）和产品”的核心数据关系。要做好数据模型转换必须先了解新旧规范在核心数据模型上的差异和演变，然后根据新旧数据的具体情况制定具体的转换方案。建设新的计费系统，各地面临的现状和起点有很大区别，需要建立不同的实施方案和升级路线规划。各种因素是从不同的维度影响规划路线的，可能存在多个维度的因素同时存在的情况。维度可以分为三类：系统建设状况，系统版本基础，系统体制选取。考虑不同因素的影响可以制定不同的系统建设路线规划，典型情况如下所示：实施风险与控制系统在建设过程中需要建立风险控制机制，主要目的是及时识别实施过程中的风险因素并采取针对性的措施规避风险，确保项目顺利实施。各省在系统建设过程和运维过程中都必须根据所处的阶段提前分析可能的风险，并制定防范措施，有明确的风险规避和应急处理机制。实施建议中描述的实施风险控制内容主要包括：风险的量化描述、风险控制主要活动、风险分类检查表。实施风险划分为以下几个大类：技术实施类系统割接类运行维护类其中风险量化主要包括3个参数：风险严重性：指风险对项目造成的危害程度。风险可能性：指风险发生的几率。风险系数：是风险严重性和风险可能性的乘积。风险控制活动包括：风险识别风险分析风险规避风险跟踪另外系统建设过程中需要依据用户规模、业务量情况和系统性能要求选择合适的系统软硬件平台配置，并制定运作流程和技术支撑办法，本模型在实施方案中针对这些内容进行了建议描述。附录计费模型主要名词解释名称英文描述计费模型BillingModel计费模型就是计费系统如何工作的整体设计和系统描述。客户Customer指一个已获得或可能获得电信公司（包括第三方合作伙伴）所提供的产品和服务，并具有承担法律责任的能力的个人或者组织。产品Product指的电信企业销售给客户的原子级的，销售上不可再分的单元，产品又可以细分为主产品和附属产品，其中主产品是可以独立被客户购买的产品，(如普通电话)，附属产品是必须依附于主产品才能被客户购买的产品（如主叫显示，呼叫等待）；主产品产生计费事件，附属产品不产生计费事件，主产品具有相应的产品资源，一般体现为产品的接入手段，如普通电话，小灵通，附属产品依附于某种主产品并提供产品功能，比如本地通话，国内长途，国际长途，窄带上网等。产品包ProductBundle将两个或者两个以上的产品打包并可以定义特殊的定价计划的产品组合。商品ProductOffer指电信运营商运用营销手段针对不同的营销渠道、客户细分、地域细分和销售目标等，对产品/产品包、定价计划进行必要的包装的产物。所有产品和产品包必须封装成商品才能销售，产品和产品包本身不直接面向客户销售。服务提供Service描述提供给客户的一些手续和体力工作，其中一些服务提供和客户购买的产品有关（比如说装拆移改等等），一些服务提供和购买的产品无关（比如说，网络规划，咨询，文本需求，等等）产品资源Resource可分为物理资源和逻辑资源，物理资源是构成产品的各种类型的硬件，逻辑资源是构成产品的各类电信设备的逻辑层面。商品实例OfferInstance客户可以通过一定的服务提供方式订购电信商品，使用的电信提供的业务，一旦商品被客户购买，一个商品实例就形成了，也就是客户开通了电信业务。一个客户可以有多个商品实例。产品实例ProductInstance形成商品实例时，必然会产生一个或多个产品实例。一个主产品实例有对应的一种网络的硬性物理连接，用于识别该业务，具体表现为计费的唯一标识，并有相应的接入号码，比如电话号码，ADSL号等。一个产品实例通过帐务关系实体定义为其付费的帐户。产品实例信息ProductInstanceInfo产品的动态属性通过名/值对应方式在产品属性表描述，对应着产品实例后，都要记录该产品的实际值。该实体就是描述产品实例具体的动态属性。例如订购的ADSL产品是1M速率，其中的1M速率就表示为此产品实例的具体动态属性，其中1M速率信息就是记录在该实体中。产品目录ProductCatalog主要是将电信的所有产品、产品包和对外销售的商品进行排列，给出一个整体的目录。销售目录SalesCatalog从产品目录中提取部分产品，产品包提供组成销售目录，以支持营销和销售活动。销售目录通过某种销售渠道提供。定价计划PricePlan在产品成本、企业回报目的以及国家相关政策的基础上，针对产品/产品包制定的价格方案，它包含了资费标准和优惠计算规则。定价段落PricingSection资费的定义由定价过程、定价段落、资费标准三个层面的实体来表达，定价过程是最上一层的资费定义工具，它将一批相关的费率集成在一起，并与计费事件相关联，指示出某个定价计划下，某