Implementing a Single Point of Configuration Includes Billing

Billing may be functionally separate from provisioning and assurance, but the configuration of billing is an important part of fulfillment. Billing configuration used to be easy – start on this day, stop on that day, or change to a new pricing plan. Needless to say, billing isn’t what it used to be. There is now a variety of complex products, offers, and billing thresholds. There is dynamic pricing, time-of-day pricing, bundled offers, and volume and quality adjustments.

A centralized catalog and order management strategy establishes a single source for the creation, configuration, and pricing of products. It would follow then that it should also be the source that ensures billing and policy management are configured correctly when the order is placed or a change is made. Pricing plans, component pricing, offer pricing, and billing plans are all included in the product catalog. Dynamic variables and thresholds, like time-of-day discounting or location-specific plans, are executed by the service catalog; and resource inventory is the source for what, where, and how a customer is configured and activated. In a catalog-driven architecture, the product, service, and resource catalogs are aligned with customer and transaction data. An integrated catalog simplifies operational processes and ensures that fulfillment and assurance functions are consistently configured using a common data source. That same centralized catalog can also be harnessed to support billing configuration.

There is little value in segregating billing when implementing a core catalog strategy. Centralized alignment of product and service catalogs with resource inventory enables abstraction of products, services, and customers from network and IT infrastructure. Transaction data that was previously only used to calculate bills is now being required by other OSS/BSS and is being centrally stored within the catalog architecture for distribution to multiple systems. As customer transactions are correlated with the product and service catalogs, operators are getting a better view of the customer experience not just calculating a bill. As demand grows for access to the same transaction data, there is no longer a compelling reason to isolate billing functionality from the rest of operations.

Every order and every change affects multiple OSS/BSS. Order orchestration based on centralized product, service, and resource federation ensures that all affected systems are configured and activated in the right way at the right time. Using a centralized, catalog-driven single point of configuration brings products to market faster while activating customers (and billing) with fewer errors and less fall out.