Operators are increasingly finding themselves under pressure from agile new entrants capable of undercutting their prices. To remain competitive,operators must be able to leverage economies of scale, keep up with intense competition, engage with increasingly technology-aware consumers and deploy innovative services.
The lynchpin to all these activities is the consolidation and automation of processes across different services and networks with the latest generation systems, including Operational Support Systems (OSS).
However, updating a legacy OSS, or any other system, can be a significant challenge – after all, they are highly complex, critical systems that are integrated into every aspect of an operator’s business.
Often multiple systems have evolved organically over time, resulting in a tangle of business critical processes and disparate data. This can make the implementation of a new OSS a foreboding challenge indeed.
The Tipping Points for Change
Since a protracted period of transition or, worse still, a failed deployment, can cost operators considerable amounts of time and money, many hesitate to modernise their OSS.
Operators with systems that do not meet their requirements often find themselves unable to deploy new market strategies, even when the business case for them is clear, due to the cost and risk of supporting the change in the OSS. They notice that they are constantly being outpaced by competitors, who seem to be much faster at launching products and capturing market share in new areas. Meanwhile, they find their profit margins are dangerously thin, despite having higher prices than their main competitors, due to a lack of automation in cross-product processes.
One of the most hazardous areas in an OSS refresh is the migration of data. Automation demands data accuracy, so legacy data must be taken from many disparate structures and formats and compiled into one consolidated database. To achieve this, data analysis should be addressed right from the start of the project so that adequate time is allowed for successful cleansing and migration activities. One successful approach is cleaning data before migration to the new OSS, rather than as part of the migration process.
For example, an operator may have regional deployments of their legacy OSS, each very similar, but with their own customisation. By getting this data cleansed and in a consistent format within each system before it is migrated takes great pressure off the OSS migration. It means that there needs to be only one data migration process, rather than several variants.
Even if there is only one existing OSS, prior data cleansing makes sense. Most importantly, it means that the expert users of the system can quickly resolve any data discrepancy issues – after all, they have used these systems and processes for many years.
Put those same experts in the alternative scenario of a new OSS being delivered at the same time, and the data discrepancies get entangled with the changed processes – making it very hard to pinpoint the root cause of fallout. The resulting frustration impacts user buy-in to the new system and the fallout in processes until issues are resolved can greatly impact critical business operations and customer satisfaction.
Reaping the rewards
Of course, data migration is by no means the only hurdle faced when migrating to a new system. The project roll-out strategy needs to be an optimal balance of minimising impact to the business, whilst providing benefits upfront to drive the transformation forward.
Phasing the introduction of the OSS, for example, by service or by functionality, allows the delivery team to focus on delivering initial phases quickly. In doing so, the program demonstrates to the business sponsors that it can meet the demands of the business case, and sets a positive momentum for change across the organisation.