渠道经营分析IT支撑系如统设计方案.docVIP

渠道经营分析 IT支撑系统设计方案 项目背景 目前，各电信运营商之间的竞争日益激烈，竞争的手段多种多样，并且正在从一个粗放的竞争方式慢慢向细分的市场竞争方式转化。从中国电信的角度来讲，也正在从以往的区域经营模式向聚类渠道的模式转变；从管理原来的公众、大客、商客向更细分化的社区、校园、政企、农村等等渠道延伸；从过去的大而全的经营模式向划小经营分析单元、精细化营销的经营模式转变。在这种背景下，以往的生产经营分析系统已无法提供为了支撑和满足市场竞争所需要的各种翔实准确的数据。 系统需求 作为新形势下的经营分析IT支撑系统应该满足以下需求： 从行政管理属性方面，上至市公司层面、下至各类经营管理单元（社区的家庭客户、农村的统包员、校园、政企等最小单位的聚类客户群）都要能层层展现各类市场运营的数据，甚至直到清单级的用户层面的各类数据的挖掘。 从经营分析属性方面，要能根据业务发展、收入及欠费等几大块的工作，提供各种各部门的需求报表。 从渠道属性方面，要能提供社区、校园、农村等现有渠道的管理分析功能，同时，要具备能快速根据相关聚类客户的定义，迅速生成相应模块，纳入渠道管理的功能。 用于查询管理的维度有： ●从产品归属：产品、产品包、套餐。 ●从业务属性：欠费、通话费收入、按受理时间/竣工时间的业务发展量。其中，业务发展量还需要统计套餐及产品包的情况。 ●从行政管理属性：市公司→区县分公司→二级管理局（可选。虚拟聚类管理需要，不同的渠道可能是不同的定义，比如社区就是各个社区名称，校园就是校园名称。）→接入网→交接箱（可选）→最小管理单元（虚拟聚类管理需要，不同的渠道可能是不同的定义，可选）。 ●从时间属性：每日、每周、每月、每年。 能管理到用户清单，并能通过操作员以产品、套餐、家庭等多维度查看相应对象的消费历史情况。 能管理用户欠费情况，并提供管理界面给社区管理员进行人工和自动外呼催欠（可选。需要语音平台支撑）。 提供人工外呼界面给各级管理员根据显示的清单开展人工外呼营销工作（可选。需要语音平台支撑）。 设计方案 设计原则 本系统是现有生产系统(九七及计费系统)的寄生系统，即最大限度利用现有生产系统的数据资源，包含其数据库、表结构、表关联关系等，同时又根据需求建立本系统独立的数据库及相关表结构。 采用每日凌晨同步生产系统数据的方式，将之前的数据同步到本地服务器后，再根据相应的需求对数据进行处理。以避免生产系统的资源限制及安全等问题。 采用B/S结构实现系统功能。 管理体系架构 在行政管理的结构上，架构比较清晰的是用户（user_id）-母局或接入网（user_branch_no）-区域公司（bureau_no）。其中，对于固网产品，在user_id和user_branch_no之间还有一个层――交接箱层。该层可以通过97系统相关的表获取。但交接箱层对于移动产品则无法表现出对应的属性。而移动产品在系统中一般只有一个对应于区域的统一的接入网编码。 支撑系统的客户体系架构 根据设计原则，结合现有生产系统的客户体系架构和各种渠道的特性，建议支撑系统的体系按如下方式建立： 在现有的九七系统用户层serv_id层之上定义一个片区或者管理单元的层，我们可称之为管理单元（manage_unit）。管理单元之上为交接箱。定义manage_unit的目的是为了划小经营管理单元的需要将交接箱划分成较小的片，以方便管理。各地使用时，可以根据实际情况决定是否使用该属性。当不使用该属性时，建议其值等价于交接箱值。 在定义管理单元的范围时，应尽量以现有的电信固话网络的物理结构为准，采用交接箱的方式来划分。这样做的优点是能直接从现有的九七系统中直接将现有的固话和宽带用户导入支撑系统，避免人工处理大量的基础资料。同时也方便将来自动处理新增的客户资料进入系统。 对于移动产品，可以设置新的管理单元标志属性，从而解决其管理的归属地问题。这个也可以在受理时根据号码池来解决其归属问题。移动产品的交接箱层的值应等于固网产品的管理单元对应的交接箱值。 交接箱之上为接入网层。 在接入网和分局之间增加一个二级局（minor_bureau_no）的管理层。一个二级局可以由1个到n个接入网组成。增加该层的目的是解决在区县公司层面上管理的客户过多，而在接入网层进行管理客户可能又太少的问题。这也和现实情况下的分片管理的模式相吻合。在未定义二级局的时候，一个二级局就只管理一个接入网。 每日对系统产生的新装或拆机用户，能自动根据相关规则进行处理和归并，不能自动处理的，要能给出相应的提示。 系统软硬件需求分析 数据库采用与生产系统相同的数据库及版本，即ORACLE 9.2X。 数据库服务器采用高档PC服务器。建议采用HP DL380 G5或DELL