浅析三方资料稽核
开篇：润墨网以专业的文秘视角，为您筛选了一篇浅析三方资料稽核范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
【摘要】 复杂的业务使得收入保障变得越发重要，三方资料稽核是收入保障的重要一环。而三方资料稽核方法也是多种多样，本文浅析了三方资料稽核的三种方法及其优劣。
【关键词】 运营商 收入保障 三方资料稽核 数据挖掘 BSS系统
近年来随着业务的全面发展，导致系统框架日益复杂，用户资料数据同时存储于多个相对独立的系统，比如BSS，HLR，OCS，VAC，Radius宽带认证平台，炫铃平台等，由于各个系统之间交换的用户数据量大，交易频繁，同时各系统间的协议功能日益复杂，各个系统之间的用户资料数据存在不一致的地方。不一致的数据，首先会影响用户服务水平，导致用户感知降低，引起用户投诉，其次各个系统数据的不一致会导致业务漏洞，导致收入流失。再次网元设备中存在无效数据，不能准确的进行资源回收，降低了资源的使用效率。同时还会影响业务营销推广。因此三方资料稽核非常必要，是收入保障减少流失的重要方法。
三方资料稽核的三方主要指的是营帐系统的营业受理侧（Crm）、营帐系统的计费测（Billing）和网元侧这三方，而三方资料稽核就是通过人工或者系统的方法对三方面的数据进行检查核对以及数据修复的操作，并通过稽核结果找出系统问题，保证数据准确。稽核对象为营业侧数据与账务侧数据进行稽核，营业侧数据与网元侧数据进行稽核。因营业受理侧保存用户的业务受理订购记录，因此稽核标准为以营业侧的数据为准，修复其他两侧的数据。三方资料稽核流程的生命周期包括发起任务、原始数据提取、差异数据生成、重复数据对比、差异/重复数据下发、整改、反馈发起者、整改总结、稽核任务优化等环节的闭环过程。
三方资料稽核的稽核内容包括，按照域来分可以分为移网域和固网域，按照业务角度来分可以分成GSM业务，PSTN业务，宽带业务，专线业务。而具体核对全量客户资料，包括用户账号、用户状态、资费计划、接入速率、国际长途及漫游开通状态、GPRS开通状态、增值业务平台用户状态和付费类型等信息，检查受理、计费、网络系统的用户存在情况、用户状态、业务订购关系、资费等信息是否匹配，检查增值业务平台与其他系统的用户存在情况、停开机状态、预付/后付属性等是否匹配。
第一，营业侧与账务侧的数据。目前运营商的营业和账务两个数据库在日常业务中通过中间件的方式来进行数据同步，但是随着数据的增加，数据库运行异常，存储过程编写的漏洞以及人为等其他原因，会导致两方数据不一致的情况。因此需要对关键表数据的进行数据稽核。营业侧和账务侧的核对放在出账前做比较。一般纳入到出账流程中。
第二，营业侧与网元侧之间的数据稽核是整个稽核的重点和难点，因为双方数据海量，数据提取遗漏或格式不一；口径繁杂，需要不断地数据分析与确认；数据需反复验证，稽核周期整体较长。因此目前这两侧的稽核的手段目前可以分为三种：
第一种全量比对，设定好核对范围和核对内容由计费系统和网元部分同时取原始数据，取出以后进行比对，并沉淀出差异数据1，由于原始数据数据量非常大，比对时间较长因此在比对出差异结果可能在这个时间段发生改变，因此采用多次比对取交集的办法来确认差异数据，连续五天取差异数据的交集得出最终结果，然后按照业务稽核规则进行数据修复，保存数据修复记录完成本次稽核过程。同时寻找差异数据产生原因弥补系统漏洞。
优点为内容全，业务详细，操作比较简单。缺点，时间周期长，耗时人力较大，协调部门较多。
建议：每半年或者一年为一次核对周期。适合比对用户属性等全量数据。
第二种增量比对，增量比对可以视为全量比对的补充，定期由计费系统沉淀用户产品订购关系的变更情况，以文件的格式将此时段的的数据传送给网元端，由网元端入库过滤并进行比对。比对后回复给计费系统，最后并进行存档。
优点，业务量小。缺点：需要网元设备具备相应能力能够文件导入文件和更新数据。
建议：可以按照业务重要情况分时段沉淀数据比对数据，按日周月比对数据。此类适合实时性较差的产品比对，比如增值产品。
第三种 实时比对。实时比对是由网元设备提供查询接口，以单个用户为单位向网元端发送查询指令，网元侧返回用户当前的状态信息，收到后与计费系统的状态进行比对。将差异化的状态、产品信息直接发送指令将两边属性修复成一致。同时在记录比对过程和修复过程。
优点，目标准确，能够选择比对用户号段范围用户比对属性范围。缺点，需要建立单独的比对系统，且查询和比对过程时间较长，直接修改用户属性对于风险较大，交换机压力较大。
建议：有条件的可以选择此类方法，并建议在计费系统与交换机闲时操作，避免因核对影响正常的业务受理。
稽核的主要工作在前期准备上统一口径方面，而风险则在数据修复这个方面。对于容易产生收入流失的部分要加强核查，并且发现问题要及时查询产生差异的原因，毕竟稽核只是补漏必须从源头纠正错误才能彻底解决问题。同时对差异数据的修复有可能会造成用户的投诉，因此在数据修复时要慎重避免产生大量投诉引起新的问题。