purebill.com

Stephen Jones writing on billing and application migration

subscribe to purebill link
. Home . About . Archive . Links . Billing . Reference . Subscribe . Search . .
. The Billing Notes Index . Operating Multiple Billing Systems .

Note 5: Why multiple billing platforms are used

Posted: 01 October 2005

Why multiple systems are used

A network business may have multiple billing instances because of strategic policy decisions, corporate mergers, and/or separately conceived product or service development. Complex billing environments can use different billing platforms to support solutions and cost structures for different market segments. The causes of multiple billing instances include:

  • Time pressures: New products or services introduced quickly are given a separate (new) billing instance where the use of an existing billing platform would delay introduction or subsequent modifications.
  • Product Maturity: Mature products are likely to have stable billing requirements that can use a less sophisticated billing platform whilst new products and services may undergo frequent marketing changes and so will need a billing platform that can be changed quickly and easily.
  • Market segmentation: Different market segments may need to be billed on separate billing platforms in order to support their different configurations and independent development needs. e.g. wholesale / retail, residential / small business / corporate
  • Product segmentation: A business with different networks may have siloed billing systems aligned with each network. e.g. internet / fixed phone / mobile phone, gas / electricity
  • Geography: A business operating in different regions may operate regional billing instances. Foreign currency processing may also require separate billing.
  • Capacity: The same billing platform may need to be replicated because of performance or size limitations.
  • Business Continuity: The same billing platform may be replicated to maintain business continuity. This can be done by operating multiple live systems, or by having a 'mirror' site that can be brought online if required. Operating redundant systems can be expensive, but may be less expensive than the lack of a business continuity plan.
  • Regulation: Regulators may require that product or market segments use separate billing systems.
  • Transition: This can occur where an older billing system is migrating into a newer system, or several billing systems are being consolidated into one.
  • Capability: Specific billing systems (or sub-systems) may be tuned or designed to operate for a limited function set. For example, such systems might be employed for real-time transaction pricing, high-volume batch rating, or pre-paid balance management.
  • Role: Rather than having one billing system do everything, different billing systems may be tasked with different scope responsibilities. This approach can allow a biller to provide customised solutions for their hardware, software and service level agreements. e.g. content settlement, interconnect billing and reconciliation, retail billing
  • Security: Regulatory or marketing considerations may require a biller to provide separate billing repositories enabling data environments to be demonstrably 'secure' physically rather than logically isolated within the one database.
  • Buy versus Build: Historically, many billing system were developed in-house, but may be replaced in the future by vendor software packages. A biller may choose to deploy a software package for new products whilst retaining its in-house billing system for existing products.

The most effective number of billing instances will, of course, vary from biller to biller, and depend on the biller's historical position, available opportunities, and goals. The best billing solution will proceed from a clear statement of a biller's strategic direction, rather than simply be a result of historical decisions.

From an operational point of view, it is essential to ensure that the chosen solution can do the jobs required of it. A reduction of billing instances based solely on financial considerations or an arbitrarily determined environment number can limit a biller's ability to respond to market changes if the jobs that need doing can't be supported. For complex networks, it is likely that several billing instances will be required, particularly where there are competing business priorities.

Nevertheless, multiple billing instances pose risks and issues that need to be addressed, such as:

  • Potentially increased costs: Multiple billing environments can generate some dis-economies of scale with each environment requiring its own suite of staff, hardware, software, and licence fees. When separate instances operate the same software and/or hardware (operating environment), some costs can be reduced by resource sharing or negotiated volume discounts.
  • Staffing contention: Separate billing environments with a development program reflecting new business initiatives may be limited in their ability to share their staffing expertise. Busy staff working at capacity may have limited scope to leverage their skills across other billing platforms. Separate, vendor-specific development teams operating at capacity may moderate cost arguments associated with separately staffed billing systems (since the same number of staff are busy doing the same volume of work). Where billing platforms are provided by different software vendors, staff may be able to leverage functional knowledge but not vendor-specific implementation experiences. Billers with a wholesale division may be required by regulators to provide some separation between their wholesale and retail billing staff.
  • Internal environmental complexity: Billing changes can require a more careful design when many separate applications are impacted. Whilst some initiatives may be specific to a market segment, corporate-wide initiatives may need to be developed and separately applied to each billing environment.
  • External environmental complexity: External applications interfacing with billing must handle multiple billing systems to perform their job. e.g. corporate GL receiving feeds from different billing systems.
  • Speed of Change: Where multiple systems must be updated to implement a change, the deployment rate may be reduced due to the coordination overhead. This can be moderated where changes are limited to one billing environment's market segment.
  • Functional limitations: Locating a customer's products on many billing systems can restrict the billing options that a customer can be provided. e.g. when multiple systems are involved the biller may be unable to discount across the products' billing silos.

Vendor choice

The most complex networks generally have multiple billing systems provided, at least in part, by outside vendors. Billing systems from multiple vendors can reduce a biller's business risk by avoiding a software monoculture, by providing competitive vendor choice, and by reducing the business impact of a defective system. Smaller networks or government agencies may be able to address their needs with a single system, often developed in-house.

A software monoculture generates business risk if the outside vendor is unable to meet the biller's subsequent development needs. Without development alternatives, a biller's ability to respond to market or regulatory change is dependent on the efforts of a single outside vendor, which may go out of business, or be acquired, leaving the purchased software unsupported. The use of (software) code escrow will only limit damage here.

Where a biller uses several vendors, competitive pressures are likely to produce better platforms at a lower cost. If different vendors construct the several billing platforms of a network, there will be integration issues. However, careful management can normally resolve these issues.

If a network's single billing environment fails, the biller's cash needs will be dependent on service restoral. With multiple billing environments, part of the biller's network can continue to operate. Where multiple billing environments use different vendors, cross system comparisons over time can provide supporting data for the biller's future platform choices.

There is no 'correct' solution for all billing situations. Each network must find its own balance of marketing, regulatory, performance, staffing, and financial requirements to achieve the best possible outcome. Practical considerations may place limitations on what is possible. Any future solution's starting point will be the biller's present systems, and this may limit what can be cost effectively achieved. As well, historical technical (e.g. preferred vendor), political (e.g. management political capital) and strategic business choices (e.g. billing consolidation) may be too entrenched to support some recommended 'green field' solutions.

'Billing' as a marketable offering

Once a network biller develops billing expertise it can offer to provide managed billing services to third parties. These services can be offered on a wholesale or retail basis.

A network biller offering its billing services on a wholesale basis ('billing on behalf of...') does so as a 'value-added' service (for a charge) avoiding the need for wholesale purchasers to develop their own capabilities. These purchasers are then free to focus on their own marketing and customer-facing tasks. Typically, the scope of the billing provided would be limited to the network biller's products that the purchaser is reselling, but a more sophisticated wholesale purchaser may require that third party products also be included.

Billing can be a businesses' core product offering. Such a 'billing bureau' processes and bills for the products and services of other parties, and provides an alternative to purchasing billing on a wholesale basis from a network provider.

Modern billing platforms can operate logically separate billing instances within one software and hardware platform without the need to deploy several physically separate billing systems. This approach allows the biller's existing infrastructure to be leveraged (reused) without the need to deploy separate billing instances for each sale of 'billing' to a new customer.

Convergence

Traditionally, the billing function was performed by specialised, smaller applications that each delivered part of the billing solution, but with limited additional functionality. As information technology has matured, software vendors have consolidated functionality and capabilities into their core software packages so that now fewer application need to be deployed to achieve a more capable result.

Modern billing software can perform more of the end-to-end billing tasks (functional scope), operate across a biller's more diverse market offerings (product scope), and process the larger and more complex billing required by today's billers (performance). A biller can choose to operate multiple environments based on strategic criteria (e.g. by customer segment), rather than be forced into that situation to achieve sufficient coverage of their business requirements.

Billing is converging from many directions including:

  • Payment methods: One platform offering pre-paid and post-paid billing for the same products using the same infrastructure. The same billing options can be offered consistently across the biller's entire customer base. However the network requirement to terminate pre-paid access when the pre-paid balance is exhausted still remains.
  • Consolidated (single) invoice: Historically, a customer received separate invoices for each product suite (e.g. fixed phone, mobile phone, internet). Billing platforms now provide the ability to consolidate all this information onto one customer invoice supporting a biller's cost reduction and customer service goals.
  • Credit management: The use of a single whole-of-customer debt balance, rather than multiple debt balances by product silo, supports consolidated credit management processing. The biller can use this better view of the customer's debt and payment history to reduce their bad debt risk by identifying non-payment across all of a customer's services, and supports the full disconnection of a customer for non-payment rather than isolated services.
  • Real-time versus batch: This supports the biller's ability to market the same rating and pricing plans across their entire product suite. Customers can be offered the same marketing message regardless of the underlying technology.
  • Cross product pricing: Using one billing system that contains all of a customer's product information enables pricing across products to be performed. Marketing can use this to support sales of new or less popular products, or use bundles to attract and retain more of a customer's expenditure.

Tags: , , , ,

[ Share with others ]

Post this page to a social bookmarking site:

delicious logo delicious diggit logo Digg it furl logo Furl google logo Google
reddit logo reddit stumbleupon logo StumbleUpon technorati logo Technorati yahoo myweb logo Yahoo MyWeb

 

Links to other Notes

Previous - Note 4: Billing within the Business: Service Assurance and Data Analysis

Next - Note 6: A Business' Key Billing Functions

Recent Updates

Sign up to receive a brief text email when new purebill postings are published.

JUMP TO TOP go to top of page
.
Comments welcome: stephenjones(at)purebill.com Stephen Jones © 2004-2010 - Copyright and reprint rules | Sitemap .