Mergers & Acquisitions
Today, globally, many mergers and acquisitions are happening in the telecom space to help companies reduce cost, gain significant market share, offer multiple services to customers, and venture into inaccessible markets.
Mergers are complex, especially in the underlying IT space, and involve the following challenges:
- Integration of different IT landscapes
- Identifying and decommissioning redundant applications
- Merging and aligning business processes
- Migrating customer data
- Increasing infrastructure capacity and performance
This paper analyzes the impact of targeted telecom billing stacks during such mergers, preparing one for new customer acquisitions, and migrating existing customers within one.
Objective
Telco B acquires Telco A and decides to migrate all existing postpaid GSM customers of Telco A from Billing System A to Billing System B.
Assumption:
Telco A uses Billing System A
Telco B uses Billing System B
Solution:
We broadly divide the requirement into two phases.
Phase 1: Building Capability + New Acquisition --> Prepare Billing System B to accept new Telco A Customers
Phase 2: Migration --> Migrate Existing Telco A Customers from Billing System A to Billing System B
PHASE 1: Prepare Billing System B for new Telco A Customers
The first step is to enable or prepare Billing System B to accept Telco A customers. Think of the IT landscape as a house; this is equivalent to creating a new room to store/process the other company’s customers in the same house and involves:
- Creating a separate unit or stream for Telco A customers
The primary step is to create a separate unit within Billing System B for Telco A customers. This unit will help identify Telco A customers across Telco B’s entire IT landscape, be it in CRM, portals, provisioning chains, invoice print applications, Finance, or Dunning applications. In billing, such a unit enables different brands, lines of business, or even operators managing the product, pricing, invoicing, and payments of its customers in the same instance yet separated from each other.
- Creating a product portfolio for Telco A customers
Define Telco A product structures, services, bundles, discounts, pricing, etc., which are straightforward configuration activities in any billing system. Ideally, it is best to use Telco B’s product baseline in such a setup to ensure design simplicity.
- Defining separate billing cycles for Telco A customers
Define how to bill Telco A customers, whether a separate billing cycle or an integrated one with Telco B’s billing cycle. We recommend creating a new billing cycle for Telco A customers in Billing System B but with the same invoice period as Billing System A.
- Defining resources (MSISDN/SIM) for Telco A customers
Resources, mobile, and SIM, are the core identity of any GSM customer and the telco operator. If you intend to keep them separate after the merger, map a separate DEALER/FLAG to them.
- An INVOICE for Telco A customers
Configure a new invoice template (Telco A design or logo) in the invoice printing application. Pass the new business unit created in Step 1 above as a tag in Invoice XML generated by Billing System. This will enable the printing application reading the XML to differentiate between Telco A and Telco B customers and apply different templates accordingly. Additionally, Telco A’s invoice may provide customers some additional details in its invoice. In such scenarios, it may be necessary to pass additional parameters or customer-specific messages in existing XML.
- Interfaces and satellite applications
It is important to prevent adding new interfaces with Billing System B in mergers for new operator customers. If possible, use existing interfaces and processes. Also, analyze all satellite applications surrounding the existing legacy billing systems to validate if they need any changes.
PHASE 2: Migrate Telco A customers from Billing System A to Billing System B
Migration is a complex process, and many different techniques exist, such as “Big Bang Data Migration using ETL,” “Application Migration,” and “Trickle or Parallel Run Migrations.”
However, performing a “Business Migration” is more preferable. The idea is to create a setup that enables migrating customers when needed using standard business processes. Instead of a big bang approach, staggering it across a few months in batches reduces development time and ensures zero failure. Start with smaller batches (100 customers) and gradually increase to a few thousand. The setup involves:
- Mapping Telco A’s product portfolio
The most important step here is to agree on how many products or tariff plans to migrate. This is an excellent time to review Telco A’s product portfolio and decommission old products. The outcome is to identify Telco A’s products or tariff plans to create in Billing System B and map them against each other.
- Resource mapping in Billing System B
Telco A customers already have the MSISDN and SIM mapped. During migration, those customers may get a new SIM or continue using an existing SIM. Regardless of the option chosen, resources once configured in Billing System B should not be available to the existing provisioning chain.
- Migrating existing Telco A customers
Create new customers in Billing System B using existing customer details from Billing System A (preferably usingexisting APIs). To generate an invoice for the entire billing period, create (backdate) customers with an activation date of the first day of their billing cycle. Then update Billing System B with any rating and billing time discounts and promotions from the previous month. Once migrated, move the customer to dummy billing cycle in Billing System A.
- Usage (CDR) migration
To invoice customers for their entire invoice period from Billing System B, migrate their usage captured in Billing System A for that period. It is best to migrate the customers’ CDRs in an unrated format to ensure rating and discount consistency. Billing System B would then rate, charge, and apply a discount on those CDRs as if it received them directly from a network via mediation. Roaming CDRs tend to cause some delays, which must be accounted for during migration.
- Migrating other credits/charges/payments and open invoice amounts
Like usage, any events, charges, credits, and discounts applied to migrated Telco A customers in Billing System A in the same bill period needs to be migrated to Billing System B. Most billing applications have exposed APIs to perform such activity.
Performance is always an essential factor in mergers during the migration run and after its completion. Special attention is needed for increasing hardware capacity and tuning.
Billing being the core application in today’s legacy telco stacks, it becomes even more critical to handle them with the utmost care during mergers and acquisitions. The approach covered in this paper enables reducing development and migration time and minimizes business and customer impact.