Companies have long embraced a range of IT application-development offshoring programs while keeping work on the IT infrastructure—data center and network management, end-user desktop services, security, and other core IT functions—firmly planted onshore. Then, over the past few years, increasing confidence in remote management, as well as the spread of low-cost bandwidth and the wider availability of high-speed networks, spurred the expansion of offshoring in India (and other parts of Asia) and in Europe. Buoyed by these advances, the offshoring of IT infrastructure work has grown at a compound annual rate of 80 percent since 2005. There have been some notable successes. One global financial-services institution achieved labor cost savings of more than 20 percent just halfway through a 36-month program. Organizations in industries such as pharmaceuticals and investment banking have moved 40 percent of their infrastructure labor to low-cost locations, reducing overall infrastructure costs by about 10 percent.
Yet as the shift intensified, problems associated with the transition to offshoring began to appear. Our most recent experiences1 helped us identify the common problems and ascertain the steps companies can take to deal with them and to raise the overall value of offshoring programs. The more difficult issues include a tendency to ignore the specific needs of offshoring infrastructure work, inadequate rigor in handling process flows and service hand-offs with partners, and a lack of clarity about the end-state operating model—what the operation will look like in 36 months. When plans stumble along these lines, implementation is delayed, service problems proliferate, and savings are deferred or minimal. One large media company learned all this the hard way when a piecemeal, ad hoc approach to an infrastructure-offshoring program forced its reimplementation from the ground up, with significant cost and time overruns. This company is not alone.
Our experience working with clients across a broad range of offshoring programs suggests that to reduce infrastructure labor costs significantly, companies must take an integrated approach to the global infrastructure delivery model—an approach that fuses long-term operating strategy with the practical mechanics of moving critical infrastructure components offshore. In a recessionary environment in which offshore programs could be politically sensitive, it’s more important than ever to proceed deliberately. Through our work and our interviews with CIOs, vice presidents of infrastructure, senior finance executives, and others, we have formulated six principles for implementing successful infrastructure-offshoring programs.
Don’t let short-term pressures obscure strategy.
In a difficult economic climate where cash is king and cost cutting reigns, short-term fixes may supplant longer-term considerations. A patchwork approach to offshoring can result from the pressure to resolve resource constraints and simultaneously address a range of end-user support, network-management, and other infrastructure challenges. In the absence of a clear perspective on the end-state infrastructure model, the employees responsible for executing the offshoring program may lack the compass needed to guide which functions and roles to include in it. That can complicate the deployment process significantly and limit the savings potential.
The first step in an integrated approach is to assess which functions must remain physically close to assets (the physical provisioning of servers, deskside end-user support), to the applications-development and maintenance staff (business analysis, high-end systems administration), or to vendors (vendor management). Also, some functions, such as those with access to client data, have to remain within the home country for regulatory reasons. All others can be performed remotely (exhibit).
Defining the opportunity
Consider alternatives before going the captive route.
Selecting an appropriate sourcing model can be daunting. To simplify the decision making, best-practice companies examine both the types of offshoring arrangements available and the staffing and service provisions that make the most sense for them.
For starters, a company must determine whether its business objectives call for a captive model, in which it owns the offshore entity, or a third-party model, in which it partners with one or more entities. Our experience has shown that all but the largest companies should call on the services of an external vendor or a group of vendors. Unless a company is very big and has significant reasons for wanting a presence under its own name in the chosen destination, recent experience demonstrates that it is very difficult for the economics of captive operations to work, given India’s rising salaries and tight labor market for certain high-demand skills. In fact, many companies that had successful captive operations for noninfrastructure functions have sought to get cash from these investments by selling them to outsourcers building scale.
For each of the sourcing choices, a company has two options. It can either augment its own staff by subcontracting the work to an offshore partner while retaining overall project management—without any formally guaranteed service levels—or it can negotiate a service-level agreement with its vendors. Under the latter arrangement, which has the advantage of shifting some or all of the delivery risk, the vendor must meet agreed-upon performance milestones or face penalties.
Adding offshore capacity through the staff augmentation model is the easiest way to move infrastructure offshore. But our experience indicates that guaranteed service levels make for greater satisfaction and savings in the medium and long term. Additionally, they drive the incentive to continue to improve efficiency, something of a benefit in the short term (in a captive situation) and at the point of contract renewal (in an outsource situation).
Look beyond traditional offshoring destinations.
Despite the increase in the level of offshoring, many companies still go to the standard locations, particularly India. This narrow footprint can be risky; as the volatile economic climate of the past couple of years has shown, sharp swings in currency and wage rates can wreak havoc on business planning. One organization, intent on using India as its offshore base, had an unexpectedly hard time drafting the business case—in the span of eight months, wage and currency rates each moved up by double digits. The company maintained its plans for India but had to reopen negotiations with its vendor and revise its rate-of-return assumptions.
Meanwhile, promising new locations for offshoring have become available. Unlike India, whose talent pool for mainframes is limited (though growing rapidly), Brazil has strong capabilities in this area, and a number of global vendors run mainframe centers of excellence there. Pan-European companies that require French- or German-speaking support staff should consider their sourcing options in Africa and Eastern Europe, which may have deeper pools of talent to meet these specialized needs.
When a company chooses its vendor, it’s doubly important to match needs with capabilities; the critical nature of many IT infrastructure functions raises both the performance bar and the risk. As some companies have learned to their cost, a vendor that is suitable for applications development may not be for infrastructure support. Special care must be taken to assess not only a vendor’s technical competencies but also its overall business model, since it would be running highly visible assets that might well have an impact on end customers.
Vendors must show that they have the recruiting, training, and retention capabilities to ensure appropriate staffing levels. To minimize attrition, leading companies actively support their vendors’ talent-management efforts, aiding in retention and, where possible, ensuring a portfolio of challenging work for top performers.
Redesign roles to free additional functions for offshoring.
Not all functions or roles are suitable for offshoring. Some activities, such as trade floor support, require physical proximity to end users. In other cases, specialized forms of knowledge, such as architectural skills for platforms outside the mainstream, may not be sufficiently available in the desired offshoring location.
Despite such problems, our research shows that some large organizations now locate 50 percent or more of their IT infrastructure workforce offshore. They achieve these rates by separating roles that are sufficiently stable and mature to be offshored without modification from those whose regulatory, security, or technical constraints make them hard or impossible to offshore. Then they isolate and unbundle the nonoffshorable functions.
For instance, the highest level of technical support, a Level-3 team, might be viewed as impossible to offshore because engineers occasionally need access to confidential information and may therefore be subject to regulatory constraints. To get around these limitations, a financial-services company split its L3 team into two groups: one focused on customer support, which stayed onshore; the other focused entirely on engineering, which could then be offshored.
Fit the offshore service model to the size and needs of the business.
For truly global enterprises with operations running 24 hours a day, seven days a week, the “follow the sun” model (with regional handoffs at shift changes) offers the attractions of real-time, anytime availability, as well as lower costs. Few companies, though, have the scale or budget for such a solution. Most find that the center-of-excellence model (with staffing pools concentrated in centralized hubs) offers the advantages of global reach and concentrated expertise, making it possible to leverage staffing, standardize processes, and develop deeper competencies in key skills. One European bank with a number of infrastructure sites, for example, decided to centralize these operations at one location in India. This consolidated structure, which helped the company serve the same customer base with fewer resources, yielded significant cost savings even before the benefits of labor arbitrage were factored into the business case.
Don’t move before defining responsibility for coordination and service levels.
The decision about how fast to offshore infrastructure work depends on a company’s need for cost savings and its appetite for risk. Our experience suggests that it generally makes sense to move quickly and thus avoid the loss of momentum that can result from the quest for process perfection. Two issues should be considered nonnegotiable. First, there must be a clear delineation of each party’s responsibilities. If a company uses a number of vendors (say, for a mix of application-development and infrastructure activities), it must have a single point of contact. This would, in the event of an outage, ensure responsibility for coordination and escalation of issues that may fall in a gray area of infrastructure or application management. Second, in either an outside-vendor or a captive environment, there must be accord on the level of performance expected, the way it is measured, and what happens when it isn’t met.
Once these two issues have been resolved, arguments about whether to ship operations abroad first and then fix them (or vice versa) should be replaced by discussions about what must be changed in order to move. With few exceptions, the business case overwhelmingly favors gaining the benefits of less expensive offshore labor rapidly, before addressing other process changes.
When leading companies address the offshoring of IT infrastructure, they craft a comprehensive enterprise-wide strategy for it by blending top-down decision making with bottom-up guidance and analysis. Clarifying the key cost, performance, and location drivers at the outset helps these companies reduce the risk of offshoring and improve their sourcing choices. The old adage “spend time to save time” still holds true. Companies that plan carefully put themselves in the best position to maximize the return on their offshoring investment.