In constructing the service model, an understanding of what the customer expects to be delivered will be negotiated, agreed to, and ultimately documented in a service level agreement. A key element of the SLA is defining the measures that will determine satisfaction of the agreement's terms. In fact, there may be layers of metrics that are not visible to the user , but support an overall measure of success. The metrics must not only be constructed to measure the success relative to a specific service and system's SLA, it must also be supportive of the overall business need that the IT service is supporting/enabling.
An initial step in establishing a set of metrics to measure and actually ensure success is to determine the level of service that must be provided by the functional service offering. Table 11-1 shows an example of a service level framework to use in determining the level of service that must be provided based on the system that is being supported.
Service Level | Level 1 | Level 2 | Level 3 | Level 4 |
---|---|---|---|---|
Example of Service Levels | Mission Critical | Business Critical/Effectiveness | BusinessOperational/Efficiency | Office Productivity/Administrative |
Financial Loss | significant | significant | nominal | nominal |
Recovery Cost | significant | nominal | significant | nominal |
Criticality to Product Delivery | significant | significant | nominal | minimal |
CustomerImpact | significant | nominal | nominal | minimal |
Based on the characteristics of the above service levels, systems must be classified in the minimum sufficient service level. However, this does not preclude a system from being promoted to a higher level of service if a client supports it or if one of the characteristics demands it. For instance, although a system may not have a significant impact on a customer, the exposure to financial loss may be so high that it must be handled at Level 1 service.
Each of the service levels listed above can be depicted as follows :
Level 1 ”Mission-Critical systems MUST be nonstop, and the loss of these applications will immediately affect the ability of the enterprise to deliver on its corporate mission. Virtually any cost is acceptable to maintain these applications against any likely risk.
Level 2 ”Business-Critical/Effectiveness business systems support the enterprise in the effective performance of the day-of-operations, but do not have a direct effect on operations (possibly because there are manual alternatives, etc.). These systems tend to be extremely time-sensitive and help the company avoid unnecessary crisis situations. The target availability for these applications is the same, nonstop. However, since the enterprise could function without these systems (maybe at considerably increased cost or effort), the effort to reach that target may be subordinated to maintaining mission-critical applications, or certain levels of risk may be acceptable due to extreme costs.
Level 3 ”Business Operational/Efficiency systems are used to run the business more efficiently . For short periods (e.g., less than a day), the loss of these applications will not prevent accomplishing the corporate mission package delivery. However, long- term loss of these systems will certainly impact the efficiency of the business, and cause large financial losses. Typically, these are planning and support operations and the activities they support are usually performed during normal business hours.
Level 4 ”Office Productivity/Administration systems provide the ability of employees to be creative, communicate, and productively work within the office environment. These systems do not have the compelling business importance to justify the costs and controls imposed by the higher service levels. However, this does not imply that some of the systems typically considered as part of this classification, such as e-mail and productivity applications, belong in this service level. If a system in a higher service level is highly dependent on such an application such as e-mail to deliver information, then the e-mail application components supporting this system must be classified in the same level of service as the system.
Guidelines will be specified at each level of service to determine the minimum acceptable metric that supports a given service level. It is the responsibility of the IT organization to ensure that these guidelines are met for systems in each level of service once a system is deployed into production.
Each service offering should have some method of being measured. The old management proverb of, "if you can't measure it, you can't manage it," is very true.
In order to capture the metrics of the services that will be used to support/enable, a table, similar to Table 11-2 below can be very useful.
Estimate | Unit of Measure | Additional Requirements | Metric ”How will this be measured | |
---|---|---|---|---|
Forecasted transaction volumes | ||||
On-line response time | ||||
Forecasted disk requirements | ||||
Report printing | ||||
Report delivery and performance | ||||
System availability | ||||
Tech support provided | ||||
Maintenance of user IDs | ||||
Backup & recovery requirements | ||||
Disaster recovery | ||||
Performance & tuning services |
Once the level of service for the system to be supported has been determined, a specific set of metrics can be established for the functional service to be offered . An example of the documentation of such a set of metrics is shown in Table 11-3.
|