Paul Hollingsworth looks at the transformation process across business and IT and asks why we continue to use old, high-risk procedures when lower risk and lower cost methods and tools exist.
Most Telcos live with support systems and processes that are too costly and insufficiently agile. As voice revenues diminish, Telcos are looking firstly, to replace lost revenues with new products and improved customer service and secondly, to reduce their historic cost base. The desired target requires transformation across the business and IT.
Neither business nor system transformation is easy. In fact it's frustrating that both have to happen simultaneously. Wouldn't it be much simpler to only concern oneself with migrating data to the new world without having a business to run at the same time?
In the Telco world, business and system transformation must be delivered together in tight synchronisation whilst maintaining customer service and enabling new products to be launched. Transformation must not chop off the revenue-hand that feeds it. Therefore, migration planning must take into account hundreds or even thousands of business users, tens or hundreds of systems, a challenging set of future product changes, and a large set of demanding customers.
Risks to the transformation include failed business processes, un-issued bills or product orders, customers who are left with partial service, inadequate business training and product launches that are delayed. Data can be difficult to cleanse and difficult to move to the new environment. All this often leads to stalled transformations with consequential dissatisfied customers, irate business teams and failed objectives.
No amount of planning or preparation can completely remove the risks,. The amount of effort and elapsed time required to prepared for migrations means that cleaned data can become inaccurate and new products can introduce problems that were not obvious when you started the project.
These problems, though, are all caused by the apparent necessity to move large amounts of data and business people in one go. Resulting in 'overnight' system and business process change, with all the risks and problems that are described above. However, if data and process is moved in small, manageable amounts which impact just a few people at a time then migrations of system and process can be made easily and with minimal chance of failure. If, in addition, an ability is provided to test and clean only small sets of data at a time and to be able to fall back to the old systems, then there is little chance of any negative impact on the business or customers.
This type of transformation is known generically as “progressive migration”. Progressive migration is not a new concept, but it's not the generally adopted approach because it's considered more work. Often it's not considered at all! The requirement introduced by a progressive migration is that, for a period, data and data type mastering is shared between multiple systems. For example, in a CRM migration, as customers are progressively moved to the new systems, some customers are live on the new systems and some are still live on the old. Data updates must be directed to the right place for the master data records to be kept accurately. Also, reference data must be updated on multiple systems. For example, in a billing transformation, a product's prices are required on the old and new billing system, whilst customers using the product are split between the two.
Migration teams have still chosen to deliver progressive migrations, often because the business impacts with the alternative big-bang approach are unacceptable. However due to the challenges described above, the cost and time of building the necessary data mastering management software has been high and has often extended project timescales.
The effort and risk associated with a custom-built progressive migration project can now be significantly diminished by use of a business transformation product. Furthermore, using a product, it's possible to reduce the total effort below that which would be required even for a simple big-bang migration. Thus delivering low-risk, managed migrations and at a lower cost.
So why are project teams still building migration plans around big-bang cutovers or writing their own custom code for migrations which are mostly thrown away after the project? Do we prefer these high risk, high adrenalin projects to a successful and easy life?
Paul Hollingsworth is the Director of Product Marketing for Celona Technologies, a provider of business transformation software for Telecommunications Service Providers. For more information, visit www.celona.com
"
