In This Chapter
CIBER, Inc.
Service providers are in the business of managing other companies' IT operations. By providing technology-based services to multiple customers, they offer economies of scale and skill. Rather than bearing the costs of IT specialists and infrastructure on their own, customers can turn over part or all of their IT operations to service providers that offer a pool of highly specialized technical talent, resources, capabilities, and processes. By spreading these investments out over many customers, service providers can offer reduced IT costs and higher-quality services.
Before turning over any part of IT operations to a service provider, however, a customer must have confidence that the provider will satisfy the company's unique business, technological, and governance requirements. To do this cost-effectively for a broad range of customers, service providers need an accountable, responsive organization, as well as the tools and processes that enable them to deliver flexible, streamlined services.
In this chapter, we profile CIBER, Inc., an international system integration consultancy and outsourcing company. By definition, the company must provide service management capabilities to its clients to ensure that customer expectations are being met. An important part of this service is delivering on service-level agreement (SLA) commitments. The company is evolving its SLAs from technically focused to business focused as the trend becomes more prevalent.
CIBER provides a wide variety of IT services, from physical data center services through different types of infrastructure software support to technical database administration, to customers throughout the United States, Europe, and Asia. Its IT Outsourcing Division (ITO) focuses on supplying operations and infrastructure outsourcing services to companies in a wide variety of industries.
In a typical scenario, an ITO transition project manager works with a new client to resolve architectural issues and optimize the IT environment before migrating to a hosted production environment. After a new customer's deployment is live, an ITO service manager takes over day-to-day management. As a primary component of the managed service, CIBER has implemented a robust monitoring and reporting capability to ensure that its SLAs are not being breached, as well as to prevent and remediate any incidents in the enterprise it is serving.
When ITO was formed, it used a basic service management solution. "This was good from a help desk perspective in terms of logging tickets but didn't give us a complete picture of the service," says Keenan Phelan, vice president of global managed services. As it grew, ITO needed a more robust, end-to-end solution that would give service managers the visibility to manage all aspects of daily service governance, satisfy SLA and key performance indicator obligations, and provide proactive guidance to clients.
In 2005, the organization chose an integrated service management solution to fulfill these requirements. Built on an information repository, the solution gives ITO ticketing and monitoring services that allow the team to react quickly to situations, as well as to govern and track information flow seamlessly to resolution. If a server goes down, for example, the system automatically alerts the Technical Operations Network Operating Center, which evaluates the alert. If something has failed, the center creates an incident ticket and routes it to designated ITO personnel, the customer, or a third party for resolution.
The integrated system also helps ITO troubleshoot and restore service as quickly as possible without affecting users. Recurring or major incidents are graduated to the problem management stage, at which staff members identify the root cause of the failure, whether it's a process, technology, or personnel. If a change is necessary, the problem rolls into the change management function, where staffers can make modifications and restore service. Along the way, Phelan says, "The system allows CIBER to react to the situation and govern communication to both end users and internal client IT contacts."
ITO uses the reports that the system generates about SLA metrics, such as reaction times to calls, response times to resolve issues, and information on infrastructure health to take a more proactive approach to managing service. "Reviewing service-level agreements on a proactive basis with our customers helps to avoid problematic situations down the road . . . by addressing questions and issues that can become contentious before they become problems," Phelan says.
Service managers use these reports, along with knowledge of new IT trends, to advise clients in quarterly business reviews. As an example, they might provide insight on the cost and reliability benefits of relocating systems to a CIBER data center or about using virtualization solutions to reduce an organization's physical IT footprint. Says George Maroulakos, director of global service management, "Many times, the CIO of an organization will ask us to protect him from himself. . . . The strategic direction we provide improves the level and value of the service we offer and helps them protect themselves."
ITO has always used technical SLAs — such as response times and availability levels — as measuring sticks for performance. CIBER, however, recently signed contracts with clients in the United Kingdom and United States to deliver jointly determined business SLAs. This type of SLA guarantees the outcome of a business process. A technical SLA might state that a system is up 99.9 percent of the time; the business SLA might state that the customer will get her report every day at 8 am. One SLA is technology-focused; the other is business-service-focused.
Tip
See Chapter 17 for a discussion of business service management.
ITO is finding that business SLAs can be double-edged swords. On the plus side, it can use the process of negotiating and fulfilling business SLA obligations to extend the client relationship beyond the IT organization and better understand client requirements. But business SLAs are more difficult for the service provider to craft and guarantee; they also carry more risk, because all the service levels that feed the business service must be met.
"Although business SLAs may appear simpler on paper, they don't simplify back-end requirements," Phelan says. For a client, the business SLA requirement for e-mail is simple: Users need to be able to send and receive e-mail and perform messaging activities around the clock. To provide this service level, ITO must meet the same technical SLAs for availability, reliability, and performance that it normally would.
Because measuring a business SLA is more binary — the provider either does or doesn't deliver on a single metric, rather than on a series of metrics — it's also more subjective. Notes Maroulakos, "You can look at a particular server or storage unit and say it was up or down; here's the data to prove it. But if, from a business perspective, a single user or a handful of users claim they can't use the service, how do you prove or disprove that?"
Furthermore, crafting penalties for a business SLA is much trickier. "In reality, no penalty can ever reimburse the client for a loss of service to a business-critical system, and for us, the potential damage to our reputation could be exponential," says Phelan.
ITO takes a proactive, collaborative approach to mitigate potential issues. It works with clients to develop precise SLAs that detail different levels of penalties and risk assignment. In the e-mail example from earlier in this chapter, for example, the client needs to give CIBER a wide range of authority; there is very little room for dependencies on internal IT or third parties. "If you're going to hold me responsible, you have to give me the authority to control the environment," Phelan says.
Even when the customer grants this authority, ITO still can't control everything. It can host the system in its data centers and control the network, server platforms, and software changes. It can hold dual contracts with carriers for redundancy, and it can control administration and management rights. But it can't control carrier failures or random acts of nature or man that could bring a system down.
Some customers also find it difficult to grasp the cost implications associated with guaranteeing higher levels of business service. "Sometimes a client starts off insisting on hyperavailability. But I can guarantee that they won't buy it, because when the CFO sees that if they accept three or four more hours of downtime, they can cut capital costs by up to 50 percent," Phelan says.
Although just a few customers have requested business SLAs to date, ITO sees increasing interest, particularly in industries such as retail, in which companies already use IT outsourcing extensively. In addition, Phelan says, "European countries have shown more interest — probably because they tend to be ahead of U.S. companies in ITIL [Information Technology Infrastructure Library; see Chapter 5] adoption and take a more disciplined approach." But, he adds, "If we were actively marketing it, a lot of U.S. clients would probably find it really interesting." Before it does this, however, ITO wants to make sure that it gets the details and processes right.
Through years of managing IT infrastructure for its clients, ITO has developed many insights about implementing an effective service management strategy. Some of its top guidelines follow:
Service management systems aren't cure-alls. Companies "can't take an environment that doesn't function well and put in a new systems management solution and suddenly make it function well," Phelan says. "You need to also resolve underlying architectural issues first."
Reality-check the cost of availability. Each 9 after the decimal point in 99.999 percent availability costs exponentially more than the preceding one. Take a pragmatic approach, and determine the point of diminishing returns.
Internal issues don't solve themselves. If you're planning to outsource infrastructure and service management, remember that internal operational issues won't automatically go away when you outsource. Work with the outsourcer up-front to identify architectural problems and address them before you hand off daily management.
Implement measurable technical SLAs before moving to business SLAs. If you haven't yet established an SLA culture, it will be difficult to go directly to the more subjective business SLA right out the gate.