It was early 2008 when Shanghai Mobile’s general manager of information technology, Xie Qin, realized that he would be facing some difficult times in the months ahead. The Chinese government had outlined plans to shake up the nation’s sprawling telecom industry—plans that included creating three integrated nationwide carriers and offering new third-generation (3G) licenses for high-speed mobile services. The upshot was that in early 2009, the existing fixed-line and wireless duopolies, which had divided up local markets, were set to disappear. At the time, Xie believed that competition would increase markedly. Soon after the new telecom regime was established, the offerings from the reconstituted rivals began to multiply, and Shanghai Mobile started seeing greater churn among its customers and rising threats of market share loss. With 20 million customers in China’s financial capital and most populous city, Shanghai Mobile is a key operating unit for the China Mobile group.
Even before the government’s plans took shape, Xie knew that Shanghai Mobile’s complex legacy architecture presented competitive problems that would create even greater stumbling blocks in the new era. First, the company’s IT systems were largely siloed by customer channels—local branch stores, call centers, and online stores—which had inconsistent business policies for common processes, such as approving a subscriber’s eligibility for new prices or services. That translated into costly duplication for writing and maintaining software applications and increased spending on IT infrastructure. Second, the complex IT systems were very challenging to maintain. Under the existing IT architecture, for example, it was difficult to monitor system performance issues and to diagnose root causes. IT normally took a long time to resolve service breaks.
By the spring of 2008, Xie launched what would turn out to be a ten-month overhaul of Shanghai Mobile’s IT systems to improve its sales and service capabilities and to make the system easier to maintain. The transformation required Shanghai Mobile to dismantle the existing architecture and to replace it with a new IT blueprint based on service-oriented architecture (SOA), which created a unified business-service layer for different front-end channel systems and allowed the channels to share customer information. The result: improved sales and service capabilities for the channel systems; an optimal use of program developers, data centers, and other resources of the IT infrastructure; and a more maintainable system.
Although Xie’s goals were straightforward, implementing SOA within a business in flux can be risky. In this interview with McKinsey’s Kevin Wei Wang, Xie explains how he executed the strategy and how it has changed the carrier.
The Quarterly: Tell us about some of the larger management lessons that resulted from a technology transformation on this scale.
Xie Qin: Change is inevitably painful and risky. Therefore, we needed a clear articulation of the business value. Once we were able to do that, we really got support from top executives. Secondly, you need to realign certain roles to ensure that people stick with the new approach. Finally, you need to have risk mitigation measures to ensure there is minimum disruption to the business.
The Quarterly: What was happening to Shanghai Mobile’s businesses that caused you to consider the new direction?
Xie Qin: The Chinese telecom market was becoming increasingly competitive. The quality of networks was converging, and product offerings were becoming more and more similar. So if you are a telecom operator, you need to differentiate yourself with superior customer service. After ten years of strong business growth where we rapidly expanded the capabilities of our systems, we started hitting a wall—the IT systems of Shanghai Mobile were falling short in delivering the level of services our business units need.
The Quarterly: How did the transformation address that?
Xie Qin: The improved capabilities of our channels allow us to launch every new product and price plan simultaneously across all channels. That reduces time to market by 30 percent. It also cuts our development effort by at least 50 percent by eliminating redundant coding across different channel systems. Our customer service agents across channels can readily pick up a customer complaint or an inquiry about a new product made in the past. So we can improve the customer experience and have better tools to improve sales conversion. As for system performance, we can now shorten the time it takes to diagnose a performance issue from an average of two hours to two minutes.
The Quarterly: What were the IT problems at the ground level?
Xie Qin: First off, there was inconsistent business logic and a lack of information sharing across our channels, including the branch service offices, call centers, and online. For example, customers using different channels to check their eligibility for a new pricing plan could experience different business policies. If a customer inquired about a new product in the call center and showed up a day later in a branch office, the branch service agent wouldn’t know the customer had already expressed interest in the new product and would miss the chance to follow up with a proactive sales effort. Also, system performance setbacks in certain areas sometimes escaped our centralized monitoring and caused customer complaints. For example, it took us months to find out that a few services on our online channel had an unsatisfactorily slow response after a system upgrade.
The Quarterly: How does SOA address this?
Xie Qin: First of all, it helps ensure that the business logic across all channel systems is consistent and that we have real intelligence on customer interactions. Second, we need a completely transparent reading of the performance of our business transactions. That means knowing what is happening across all business areas, channel interfaces, and transaction flows. We need to be able to diagnose the root causes of problems when they occur or even preempt them before users find them.
The Quarterly: How did you implement this?
Xie Qin: For the channel integration, we first created an SOA service layer that provides standardized business services, such as checking user eligibility for a new price plan or changing a customer’s billing address, to all front-end systems of the channels—those that touch customers. Then, one by one, we reengineered IT systems for each channel so they could all access this standard business service layer. In the meantime, we enabled each channel to access records of customer interactions and the history in other channels.
To manage system performance better, the key wasn’t just to build more monitoring tools but to improve the way we write business applications. In doing so, each step of a business transaction could be tracked, from the initial online request to the final update in the database. If I can get a bit more technical, we essentially created a “base-class library” for our programming efforts, with built-in performance-monitoring functions. Now, every new application we develop will automatically inherit the ability to monitor and generate a traceable log of the business transactions. That allows us to track down the bottleneck in every delayed business transaction and detect performance issues as they arise.
The Quarterly: Transforming a system on the scale you describe is a complex task. How difficult was it to push it through?
Xie Qin: We completed the whole transformation in ten months with an IT team of about 40 people. We knew it was complex and we didn’t want to cause unnecessary business breaks or problems. Therefore, we took a phased rollout approach, starting with the base-class library and the service layer. We then moved to the applications, transforming them gradually, channel by channel. We didn’t change the underlying database structure right away, so the old and new systems could run in parallel during the transition. This kept open the option of directing users back to the old system if there was a temporary glitch in the new system.
The Quarterly: An SOA transformation often means change and uncertainty in the business units. How did you convince them to go along?
Xie Qin: We had to present the business case in a tangible way. We got the buy-in by addressing the real business issue—inconsistent business logic and lack of information sharing across channel systems—which is a real concern for the customer experience across our channels. While an SOA transformation also reduces IT costs and improves system performance, I don’t think we would have gotten our business team as excited by addressing these two factors alone.
