对于中国电信来说，如何对运营风险，欠费控制做到很好的控制。随着各种各样业务的变化，使得对于系统的实时性有很大的挑战。对于预付费本身实际上是一个实时系统，可能准实时基于话单级的准实时系统。对于后付费，我们目前越来越多的后付费提出实时性的要求，包括后付费用户的消费控制的能力，包括对于运营商来说，对客户信用控制的能力，这些能力都是要求我们的系统能够对于所有的用户，进行一个实时的控制。从运营商的角度来说，要设置一定的信用度，根据用户实时消费的情况，达到一定的程度之后，要控制用户的消费习惯。还有消费控制的罚值，会根据用户自己的需求，设定效应的消费罚值，对于不同的业务设置不同的罚值，达到某一个程度的时候，需要运营商提醒我，我可以控制好自己的消费。使得大家对于后付费的业务来说，实时性的控制变得越来越重要，并且对于系统要求变得越来越平常。
随着我们3G业务的发展，随着互联网业务的不断新兴，整个运营商到客户之间的价值链当中，不断涌现出来各种各样的第三方加入到业务价值链当中来，这样使得我们的收入结算和分摊模式变得越来越复杂。基本上都是按比例分摊的方式。如果有更多的厂商和服务提供商加入进来，使得我们业务结算和分摊的时候，可能不是跟一方进行结算、分摊，可能恩最终用户收到最后一笔钱之后，可能进行四方五方多样的分摊，可能根据你这个服务提供商跟我签订的服务协议的长短，我的分摊的比例不一样的。或者从运营商带来的整个收入的收入总量的多少，来进行分摊比例的实现。这些可能都是我们计费帐务系统发展会产生一些需求，并且是我们计费帐务发展的一个趋势。
经过这么几年的发展，我们的计费系统不断发展，并且也初具成效，但是这些趋势还是我们最终一直不断追求的目标。比如说计费系统，通过OCS，跟网络结合更紧密。融合计费也是一个很大的话题，也是我们讨论的主要的话题。用户种类，付费方式，用户管理来说，融合都是一个很重要，并且很迫切的需要实现的一个方式。
那么另外就是说扩展计费的边界，计费帐务实际上是一个网络的服务，不是后端的IT计帐系统。实际上要满足各种各样不同的维度，从运营商维度，消费者的角度也好，对于融合计费帐务系统的需求，今天不多讲了。其实很多人已经讲过融合计费系统的定义。实际上从不同人的角度，从不同的方面去看，实际上对于融合计费都有不同的要求。
那么融合计费帐务系统，整个发展过程当中，基本上经历了三个阶段。
第一个阶段基本上两套独立系统，没有太多的关联。无非经过一些简单集成，实现一定程度的客户管理和帐务上的一些集成，无非把两个业务进行帐单简单合并。
第二阶段会把两个系统建立的更加耦合，不管通过统一充值平台，还是通过SID也好，这样的方式使得几个不同系统，进行深度耦合和集成，实现集成化的产品目录和统一开放的接口，跟其他的系统进行集成。
第三阶段是我们不断追求也是我们想实现的目标，就是一个真正的融合。真正融合实现的方式，不管哪个角度来看，底层实现的数据模型是一套。所带来的好处你各种各样的不同应用，对于不同业务的支撑，大概通过相同的语言来进行相互的沟通，实现一套系统能够支持多业务、多支付方式和多种余额管理的一个基础。
另外一个方面统一的产品目录，我们怎么样能够实现一套产品目录的管理。从计费帐务角度来讲，目前现实的情况来说，我们的产品目录管理，还是分散在各个系统里面。包括OCS有一套系统，我传统BOSS有一套计费帐务系统，可能根据不同业务进行产品目录、产品资费、折扣的配置，可能两个系统之间通过认为的影射，使得建立一些联系，进行一些捆绑打包，或者资费优惠套餐。我们最后实现的这个计费帐务系统就是一个统一的产品目录，不管是新的资费套餐，新的预付费业务，或者后付费业务，你只需要一个单一的接入点进行接入，并且产品目录的结构是一样的，使得如何使预付费业务享受后付费业务的能力变成可能。使得各种各样不同的业务，不同的支付方式的客户可以享受各种优惠的能力。
那么这一套融合帐务系统，第一需要一套统一的数据模型，底层的含义就是说不管是什么样的业务，什么样的支撑方式，产品目录里面相应的一套产品定义，相应的产品属性的配置。使得你在进行新的业务管理，包括后端的帐务管理，都是使用一套相应的统一的数据模型。大家知道传统的宽带和固网来说，由于系统、数据模型是分散的，我们想把两个系统关联在一起的业务实现的时候，会变得非常困难和复杂。包括小灵通和固话的捆绑和优惠，都会变得非常复杂，系统模型不一样，产品制式的能力不一样，产品的定义方式属性不一样，使得我们没有办法实现更多的产品目录的统一的数据模型带来的好处。
那么同一个数据模型另外的好处在系统进行快速升级和容量提升的时候，会有很大的好处，不需要考虑各种很多不同的独立的系统，如何对他们各个系统之间进行容量和性能的支撑，并且如何把他们进行集成工作的接口进行支撑，而是有一套统一的数据模型，使得系统进行升级和容量扩容的时候，你会非常方便地需要专注于一套系统的扩容能够实现整个系统的扩容。
另外计费帐务系统必定要跟很多其他的应用系统，包括综合结算，包括BI数据仓库综合打交道，当我有一套相应的数据模型的时候，使得我的数据元变得简单，数据接口变得简单，整个不同应用系统之间的集成会变得非常简单，实际上也降低我们整个系统的部署的成本，提高这个系统的效率。
实际上产品目录是非常重要的环节，当我们实现融合计费帐务产品的实现方式来说，你一定要有一个统一的产品目录，这样可以降低整个系统运维的压力，可以减轻你的系统的实现的复杂程度，可以使得你的市场营销的部门和相关的客户管理的部门，都有统一的视图，能够对产品目录有个了解和接触。当你进行业务捆绑、交叉组合优惠促销的时候，这个单一的目录可以有一个简便的实现方式。包括预付费业务怎么样享受现有的后付费业务的资费套餐和业务能力。都是通过统一的产品目录实现的。
还有客户管理，随着我们业务种类的复杂，现在客户跟运营商进行交互的渠道变得越来越多，我们现在有语音的IVR等等的不同渠道需要跟运营商进行交互，因为我的后端的系统是一个统一的模型，是一个统一的产品目录，客户资料也是统一的，这里可以看到用户使用一个运营商使用所有业务的使用情况，订购套餐的情况，使得我基于统一的数据模型，统一产品目录，统一客户资料的前提下，能够对各种不同的交付渠道提供一个统一的客户视图，可以实现一个客户完整的生命周期的管理。不需要跨越更多的系统。通过不同的渠道对用户进行交互的时候，可以提供一个连续的客户体验，不管通过什么渠道跟客户进行交互的时候，都有一个统一的一致性的客户信息。可能会更少的发生或者避免。
另外实时地优惠和促销。我们需要一套统一的评价引擎，不管预付费、还是后付费你需要一个统一的批价引擎来应对，也是靠统一的产品目录和统一的数据模型来支撑的，只有这样我们才能应对实时性的要求。对于后付费用户来说，能够做到很好的复杂的优惠和折扣的能力，但是没有办法提供很快速地批价的能力。只有我们通过一套统一的批价的引擎和统一的数据模型和商业目录，使得提升批价引擎的速度基础之上，可以完成对于预付费业务、后付费业务的不同的要求。财务和帐务管理的需求非常弱的，实际上我们没有帐单，顶多是查详单。我需要对于后付费用户，提供对预付费用户提供的这个产品的服务。我还需要一个大容量的系统，因为融合计费系统，因为有一个统一的产品目录，使得配置和衔接，还有功能实现方式方面，变得非常高速、简便，并且非常简捷，基于这样的情况，才使得我们对于大的系统容量进行支撑的时候，有一个很好的方式。
对于融合计费方式来讲，目前国内的运营商也看到，越来越重要的是客户自动服务。无论长尾效应也好，最终的实质在我们结束粗放型的服务之后，我们需要提供更好的个性化服务，来为细分的用户市场提供颗粒化的服务，满足用户的不同需求。颗粒度提供的越细，给客户服务带来的压力越大。每个人的资费套餐可能不一样的，每个人享受的服务不一样的，如果大家都期望于传统的IVR渠道，或者10086，承接用户的查询和受理的话，可能量非常大。我们需要更好地用户自服务的能力，可以使得为用户自动查询的能力，可以使得用户自己在网上定制自己的套餐。我们不仅给用户提供的资费的选择权，还提供定制权，才使得我们对于每个用户的满意度，能够有一个很大的提升。
