“Put Service Level Management in place for me.” It’s a request I get all the time. Typically, the problem is: there’s nothing to measure. What’s gone wrong?
What Are Service Levels Intended to Measure?
Service Levels measure how well a service provider has been able to keep to the agreement(s) made with service consumers; they do not describe the behavior of a piece of hardware or software. Individual hardware or software components can go to hell in a hand basket as long as service is maintained from a customer perspective.
A similar misunderstanding shrouds key performance indicators. KPIs connected to Service Levels are indicators of change in the quality of service delivery, often alerting managers to imminent problems when some measured value is moving outside of normal range. They do not monitor change in the performance of the technology. Service delivery can improve or degrade in performance owing to any number of factors: technological, environmental, staffing, data, processing, or some combination of all of these.
How should Service Levels be appropriately defined?
Service levels result from cumulative conversations and agreements between the service providers and the service consumers. The service providers need to understand the “voice of the process,” or what the innate capabilities of the service can be. They need also to understand the “voice of the customer,” or what range of values within that set of innate capabilities corresponds to customer’s business needs, and what the customer is willing to pay for. Clearly, promises of service levels that fall outside the range of the “voice of the process” are going to be impossible to meet – “I need 24x7 access” to a data feed that is produced only 6 days a week is impossible to fulfill. The desired outcome is that the “voice of the customer” describes a range within “voice of the process,” with a price that is within the bounds of what the customer feels it is worth paying, and the Service Owner feels comfortable promising to deliver according to those limits.
Dimensions of Service Levels
Specific dimensions of service levels are not properties of the service itself, but of the contractual agreement between provider and consumer. Consider, for example, a Foreign Exchange feed whose customers include people in Treasury, who are watching over corporate investments, and people in Engineering, who are purchasing components from global providers and looking for means of comparison. In this hypothetical situation, Treasury needs the service to be running between 8AM and 5PM Eastern Time on weekdays. It needs the feed to be no more than 10ms behind the actual market. Engineering needs the service 24x7, but if the data is three or four days stale it is not a problem. Dimensions need to be appropriately descriptive. It would be just as nonsensical to use “octane rating” for a network circuit as it would be to talk about “Megabits per second” for gasoline. The dimensions have to fit the service. For instance, the service “foreign exchange feed” might have dimensions such as “market lag time” or “availability of data” or “availability of application.” From those dimensions, two are critical to Treasury – “market lag time” and “availability of application” – while for Engineering the critical components are “availability of data” and “availability of application.” In principle, the service provider can meet the service levels for Treasury while at the same time failing for Engineering, or the other way around.
Service Level measures when creating a Service Specification
In completing the SLA section of a service specification, a Service Owner should think in terms of “What would indicate that this service level has been met?” The problem needs

You do not have flash or javascript support.

Average (0 votes)

Reply