电信重组后业务支撑面临的挑战

综合运营与多业务支撑的挑战
全业务要求业务支撑系统具备提供移动、固话、宽带等业务的受理、计费、账务处理等能力。各种业务的使用，很可能是同一个自然用户，用户需要获得统一的服务体验；运营商也需要从各种业务使用中，看到一个统一的客户视图。
多业务运营支撑
重组后全业务竞争形势的形成，要求运营商在考虑市场策略、资费政策时，需要将各种可以提供的业务进行统一考虑和设计，为客户提供整合的业务包，而不是单独的一种业务。因此，业务支撑系统要具备多业务运营的支撑能力。
首先，计费系统面临巨大挑战，融合计费是必然的要求。未来网络全IP化后，在软交换模式下，实时计费系统和软交换网元的联接，可实现核心网和支撑网之间的信令交互。同时，内容计费、复杂的定价策略和计费费率即时更新等也是计费系统要面临的挑战。
其次，业务支撑系统要具备强大的产品管理和CRM管理能力。3G网络支持功能多样、内容丰富的产品，这就要求运营支撑系统有效地对3G产品特别是数据业务产品进行管理。3G客户群体庞大，运营商要对业务的整个生命周期进行管理，保证快速、准确地找出适合用户需要的服务，并及时推向用户。
第三，账务处理的新要求。完成固网、移动通信、专网、互联网的计费，账务系统要处理来自多种业务的计费结果，并为客户提供统一的账单。
总体来看，现有2G业务支撑系统并不能充分地支持3G业务，必须进行升级。电信重组后，随着3G进程的加快，3G特有的业务特性以及由此延伸出来的市场、营销策略，要求业务支撑系统进行快速支撑，使运营商尽可能高效快速地推出能赢利的新业务，赢得市场竞争的主动权。
价值链的延长和扩展
重组后每个运营商将提供全业务服务，与重组前的单业务或多业务运营相比，业务和产品大大增加，相关价值链将延长和扩展，运营商必须整合整个产品链条，为客户提供统一的业务和服务。
价值链的延长和扩展，必将要求业务支撑系统考虑更多的价值链环节，管理更多的实体或虚拟合作对象。除了要提供各个价值链上产品的统一管理外，结算系统也必须进行升级以应对价值链延伸所带来的结算关系、结算模型的挑战。网内与网间的结算、同一运营商不同网之间的成本核算与结算、内容提供商的结算、其他价值链对象的结算等，都会导致结算关系、结算规则比现有2G结算系统更为复杂。
业务支撑系统调整
电信管理论坛（TMF，TeleManagementForum）对业务支撑系统的功能进行了划分：业务提供（ServiceFulfillment）、业务保障（ServiceAssurance）、业务计量（Service Usage）。从电信管理角度看，业务支撑系统主要处在三个管理层面：客户服务层、业务管理层、网络管理层。
根据多业务运营、业务融合和客户服务统一性要求，无论从概念上或者产品架构上，业务支撑系统均应支持前后台分离的CRM（客户关系管理）和Billing（计费）架构，CRM提供整合的服务流程，Billing实现所有后端计费、信用控制、账务处理的要求。
多业务融合、各业务综合资费套餐策略、复杂的财务要求和客户化个性账单的生成，使得账务处理系统将变得比计费系统更为复杂。从采集、计费、批价、信控、合账、账务处理、客户服务等业务支撑数据流来看，架构上，计费系统在整个后台系统的末端，账务系统则处于中间环节，是贯穿前后台子系统的关键部分，同时也是运营商市场策略、业务策略、资费政策实现的重要落地点。
实时欠费控制的要求，使业务支撑系统必须具备与网络实时进行话务控制的能力。随着3G新业务的推出，业务支撑系统在功能上或架构上必须要进行大的调整，这样的调整速度有多快，将很大程度取决于业务支撑系统框架设计的合理性。
人才的挑战
就目前来说，业务支撑团队中对3G运营较为熟悉的人才少之又少，一些前期的探讨更多的是“纸上谈兵”。真正的3G来临以后，业务模型和市场策略，包括3G网络提供的各种产品，究竟如何使用？如何包装？如何推送给客户？无人说得清楚。
由于电信重组导致的市场竞争格局变化，以及国家宏观调控政策的变化，各个运营商的具体策略还处于摸索中，无法成型。在这种情况下，具有快速学习能力、熟悉3G业务并具有相关知识背景的业务支撑开发人员，将成为业务支撑活动中的“香饽饽”。另一方面，无论是开发商还是运营商，能否在尽可能短的时间内，构建适应范围较广的支撑系统框架，是后续业务和市场发展需求能否快速响应的关键。
重组后，各个运营商固有的技术领域、业务模式将产生较大变化，业务支撑团队不得不面对大量新业务、新技术所带来的学习和实践的压力。对于业务支撑相关的开发人员和使用人员来说，这样的过程将逼迫技术人员不再局限于已有的、熟悉的技术路线，转而向其他技术和业务领域拓展。
再有，不同的技术引入，以及价值链的延长，使得业务支撑系统不再是铁板一块，有可能会被大大地解耦（中国移动计划中的NGBOSS，其最重要的概念就是对现有支撑系统进行解耦）。这样，必然要求不同风格和技术领域的团队和个人进行合作与融合，大量的协调、沟通增加了交互成本。
开发商的挑战
重组后，没有一个健康的、行动迅速的合作伙伴，运营商在市场竞争中将处于下风。在一个充分竞争的环境里，业务支撑的丰富程度、客户化服务的手段、业务推出的速度决定了竞争主动权的归属。运营商之间的竞争，也包括对优质业务支撑系统提供商（即开发商）的争夺。
但是，对在这个行业摸爬滚打的业务支撑系统开发商、集成商来说，重组打开了局面，带来了机会，但重组带来的更多是挑战。开发商不能有豪气冲天、大干一场的想法，更多的是要扎扎实实将产品质量落实到实处，迅速升级产品以轻松支撑3G的业务和运营模式。
随着业务支撑系统的解耦，将多个开发商的产品进行集成以实现对整个业务的支撑将变得越来越可行。以前开发商占据了业务支撑系统的一角，只要无“大过”就可以安然无恙的情况不会再出现了。电信重组将国内多家运营商合并成三家，直接导致了市场需求的下降，开发商之间的大洗牌不可避免。重组给一些开发商带来了新的机会，也让另外一些开发商感受到了冬天般的寒冷。开发商的新旧更替，给运营商的合作伙伴选择带来了更高的风险。
由于运营商的市场和业务营销策略，几乎完全以业务支撑系统为载体。开发商在支持运营商的运维活动中，不知不觉地就会掌握很多商业机密。运营商和开发商实际上有很深的业务依赖性，一旦运营商选择开发商失误，更迭业务支撑系统将面临业务无法连续等风险，这样的风险，运营商将越来越难以承受。因此，运营商要好好放低身姿，找一个放心的业务支撑合作伙伴。
业务支撑系统本身的挑战
大数据量处理
重组后，目前的多家运营商合并成3家，相对来说，每个单体业务支撑系统的用户数、系统容量、数据量大量增加。无论多小的业务规则，当面对大数据量的时候，任何风险都会被放大。无论多么简单的业务处理，在大数据量面前都会使系统的压力增加。
同时，丰富的3G业务、政策的变化、业务竞争的加剧也在导致业务支撑系统的数据量在不断增大。
重组后要发放3G牌照，3G业务将得到市场应用。相比传统的2G业务，3G业务非常丰富。面向流媒体的各种业务、面向交互式的业务，甚至传统的语音也有很多的扩展。对这些丰富的3G业务的采集、计费、查询、账务处理，及在这些业务上开展的业务活动，再加上价值链本身的延伸，由此带来的结算模型的复杂化，将大大拓展业务支撑系统的数据量。
随着电信资费平均单价的进一步降低，用户的通话行为将呈递增趋势。2008年3月，由工信部、发改委等发起的漫游资费调整，使长途漫游时的资费由每分钟1.3元下降到0.6元或0.4元，下降了一半以上，这必然会使用户的通话次数越来越频繁，通信消费欲望必然得到大量释放。从长远看，目前电信资费还有进一步下调之势，这就必然带来通话量大量增加，从而导致业务支撑系统采集、计费、信控、账务处理、详单查询、分析等数据量加大。
另一方面，由国家实名制、信用信息交换等政策带来的对用户资料详实性的要求，对用户通信消费信用度的信息记录，也必将增大业务支撑系统的数据量。
重组后，号码携带成为呼声最高的电信政策，也是非对称管制的一个重要手段。该政策除要求业务支撑系统记录更为详尽的网间用户交换信息外，由此带来的复杂的结算模型、大量的网间数据交换处理也会给业务支撑系统带来巨大挑战。
服务的竞争，必然导致支撑系统对客户信息进行更详细地记录，以提供差异化的、精细的、全方位的服务。这些信息包括客户轨迹、更详尽的用户资料、接触信息、服务日志等，同时需要越来越多的历史记录，来加以分析和决策。
此外，大数据量带给业务支撑的压力，不仅是业务支撑系统硬件资源上的压力，也包含大数据量带来的大量维护工作的压力，这给业务支撑人员带来了更高的工作负荷和挑战。同时，在大数据量的情况下，要解决性能问题，不能单纯依靠增加硬件设备，还必须要求业务支撑系统有合理的系统架构以及进行持续不断的优化。
产品化、标准化路漫漫
现有业务支撑系统如果仍然无法设计出成熟的容量模型和业务规则，就不可能从根本上从容应对海量服务计费、大量业务请求，以及其他复杂的系统要求等导致的性能冲击，这不是设备容量是否足够的问题（况且从成本等因素考虑也不可能满足“足够”的资源要求）。没有成熟的规则和模型，就不可能对市场和用户的活动进行标准化，就不可能规范作用于业务支撑系统上的各种行为，从而在某个时候产生无法预料的后果。
如果用交换机话务模型来对比，就能很清楚地明白业务支撑系统的压力所在。传统交换机（即使是3G网络）建设时，对话务容量、峰值等都有预期设计，用户的呼叫模型都处于规划模型中，信令交互是标准化的、格式化的，一旦超出设计的阀值，就会采用限呼等手段来保障整个系统的运行安全。
业务支撑系统的容量概念，更多的是一个法律、产品销售的概念，非实际系统运行容量模型。并且，从目前国内的业务支撑产品来看，还没有一家厂家提供的业务支撑产品具有明确的容量模型规划。常见的现象是业务支撑系统一旦形成性能瓶颈，整个系统呈现雪崩式的性能故障。
作用于业务支撑系统上的用户行为（包含服务使用用户和系统使用用户）并不规则，可以说完全没有明确的行为预期（有预期也很难真正约束）。常见的现象是：一个临时的报表统计行为可能就会导致严重的性能问题。另外，一旦发生了性能问题，也很难真正查找和定位原因。不错，最后“一根稻草”压垮了业务支撑系统，但是，以前放上去的“稻草”难道不是导致性能灾难的原因之一吗？
对业务支撑系统的要求越来越高
电信重组后，在同样的全业务运营情况下，初期主要在网络设备能力、产品价格等方面进行“短兵相接”的竞争，但度过短暂的“原始”阶段后，各方会很快趋于同质化。运营商之间的竞争，将主要是在服务上进行竞争。
随着业务支撑系统越来越成为关键系统，运营商相关的业务、营销、市场、渠道、客户服务、电子渠道等活动，都离不开业务支撑系统的IT实现。业务支撑系统既是运营商服务人员使用的工具（例如营业受理、呼叫中心等），也是客户的接触渠道（例如网上营业厅、短信营业厅、充值等），更是客户接触记录的载体。同时，业务支撑系统也是运营商了解客户反应的通道。
运营商服务的推出，除可能需要网络提供的物理通道外，还必须通过业务支撑系统进行IT实现，并通过合适的方式到达用户。因此，业务支撑系统成为运营商竞争力不可分割的部分，其运行质量、稳定性、业务支撑速度、服务准确性等都是客户满意度的主要来源。
一个基站退服，不会对整个运营商的正常运营导致大的冲击；而一个集中的业务支撑系统退服，将导致运营商所有的服务渠道无法运转。这样的故障，在服务要求越来越高的情况下，没有一家运营商能够容忍和承受，业务支撑系统正在受到运营商越来越高的关注。