Modeling Service Delivery Management

 < Day Day Up > 



Every type of enterprise today requires some level of IT enablement. The vendor community, and at times IT leadership, tend to oversell the value and understate the required investment and difficulties in bringing enabling technologies to bear. In truth, enterprisewide IT deployments are complicated and resource intensive — at the outset and in terms of ongoing maintenance and support. Indeed, once IT solutions are operational within an enterprise, they must run continuously, with the IT organization adjusting on the fly to added users, new user requirements, and changes in the direction or the nature of the business. Unfortunately, too much tends to be promised by the IT organization and its external partner providers, and too much is assumed by the end-user community. These circumstances can lead to misunderstandings, disappointed expectations, waste, and even poor performance results. On the flip side, too often good services come through heroic effort rather than a routine, predictable, and manageable process.

To better align end-user expectations with IT organization capabilities, many IT executives employ customer relationship executives (CREs), as described in Chapter 2, to serve as the voices and the ears of the IT team in dealing with its business unit counterparts. To complement this personalized approach to communication, some IT organizations also employ service level agreements (SLAs), as briefly described in Chapter 1, to communicate with their customers and to educate them on the nature and extent of the relationship between the specific business units and IT services. Together, the CRE and SLA processes help shape and inform customer expectations about service, thus functioning as a safety valve in a well-managed delivery process. To achieve their operational objectives, both are supported directly by PMO personnel.

The interactions between the CRE and SLA processes are easily described. First, IT management must identify its key customers, typically the senior executives of the business or operating units served by the IT organization. Second, the CIO or his or her designate should visit with each executive and his or her management team. In these preliminary sessions, the senior IT executive outlines the intentions of the service delivery management process, reviews the actual SLA form (described below), and considers an appropriate CRE to serve as a liaison with that business team. As an outcome of this effort, each business unit's leadership will have some sense of the IT organization's service level management process; the scope, nature, and current capabilities of IT in the service of the business unit; and the role of the IT CRE who will serve its interests.

The CRE will then help to prepare a complete SLA for the review of his or her assigned business unit. To do so, the CRE will turn to the PMO for information concerning the history of that customer's prior year of work for that business unit. The CRE will also request a catalog of all the products and services delivered to that business unit during the course of the year, as well as their associated costs. In an organization in which the business unit is paying directly for IT services, accurate cost and service delivery information is essential. In organizations in which IT is funded directly by the enterprise to provide IT services, however, cost information may only confuse the issue. The SLA process and form should fit the particular circumstances and culture of your enterprise.

Last but not least, the CRE works with the PMO and key IT service managers to establish all the appropriate IT service level metrics that quantify IT performance as these relate to the business unit in question. This data will be employed both in the SLA document and in conversations with business unit leaders to establish mutually agreeable service delivery expectations.

Once the CRE, with the assistance of the PMO, has done his or her due diligence within the IT organization to prepare the SLA, the document should be reviewed carefully while it is still in draft by the CRE's business unit counterparts. After the draft has been properly vetted, the CRE will more formally present and review the SLA, which now serves as a service delivery contract, with business unit management. Again, given the culture and internal business practices, the nature and form of this contract will vary from enterprise to enterprise. Thereafter and on a regular basis (e.g., monthly), the CRE will sit down with his or her business unit customers to discuss how well the IT organization is performing against the metrics set forth in the SLA. During these discussions, the CRE will also listen for opportunities to improve or enhance existing services and for new business opportunities (e.g., product or service enhancements and projects).

Because the SLA includes actual performance metrics, these metrics will provide a quantifiable basis to assess the quality of IT service delivery. In large IT organizations, problem ticket systems are often employed to monitor the status of problem resolution (i.e., repairs to existing IT services) and service requests (i.e., customer requests for access to or enhancements of existing IT services). [2] These systems track the history of a customer ticket from its point of entry, usually through the IT help desk or call center, to the point when it is closed (i.e., when the customer's needs have been addressed). To work properly, any tracking system must be built on a foundation of agreed-to workflows and handoffs. The standard for each step's delivery is time-based and assumes satisfactory results at the close of each step in the process. Typically, these rules and metrics are captured in the system, and actual performance is then recorded and compared to these metrics. To facilitate this effort, I suggest modeling these processes in PowerPoint or Visio and then marketing them across IT to establish a consensus on their accuracy and their practical implementation. [3] In each instance, your help desk people would log the problem incident or the service request into the tracking system before passing it on to an IT service provider for processing. By way of illustration, here are two performance metric standards. The first addresses problem resolution, and the second addresses service requests. See Exhibit 1.

Exhibit 1: SLA Problem Resolution Metrics

start example

Severity Level

Customer Impact

Customer Response

Max. Resolution Time

Code 1 — catastrophic

Global service shutdown

Within 30 minutes

ASAP

Code 2 — urgent

Failure of a major enterprise system or network leg

Within 60 minutes

ASAP

Code 3 — high priority

Individual or team severely impacted

Within 4 hours

2 business days

Code 4 — important

Individual or team minimally impacted

Within 3 business days

As scheduled

end example

In the problem resolution metrics table, help desk personnel create and rate problem tickets based on their perceived level of severity (i.e., the extent to which the customer and the enterprise are impacted). As this table suggests, the IT organization commits to getting back to the customer within a prescribed period of time after receipt of the problem ticket from the help desk; IT also commits to resolving that ticket within a given timeframe. Each metric is based on customer input and enterprise needs, but each is also based on the history of past IT team performance. [4] Of course, these are averages, but in quantifying how well the IT organization actually performs against these metrics, the CRE has a clear and concise tool for communicating to his or her customer both the value of IT services as delivered and any actual performance issues. Similarly, IT can identify problems in its own performance and measure improvements once corrective actions are taken.

Similarly, your help desk process and the associated SLA document must address the topic of service request metrics. Although Exhibit 2 appears to be the same as its predecessor, the underlying activities and participants in each of the coded service request workflows are somewhat different from the problem resolution model.

Exhibit 2: SLA Service Request Metrics

start example

Severity Level

Customer Impact

Customer Response

Max. Resolution Time

Code 0 — VIP request

Request is from a senior executive who needs an IT service unexpectedly and right away

Within 2 hours

ASAP

Code 1 — urgent request

Request is time-sensitive and must be completed or it will impact a large subset of the enterprise

Within 4 hours

1 business day

Code 2 — high priority

Request is time-sensitive and must be completed or it will impact an enterprise team or service

Within 1 business day

2 business days

Code 3 — standard request

Request is for some routine service in the future

Within 2 business days

5 business days

Code 4 — special request

Request requires specialized assistance and a considerable amount of work but is not time-sensitive

3 business days' notice at a minimum

As scheduled

end example

Like the problem resolution matrix, the service request matrix prioritizes work based on the highest value to the greatest number, concluding with requests that almost verge on a project status but that IT has agreed to address through more routine maintenance and enhancement activities. The key to success in either of the these measurement models is adequate discussion before rolling out the service management model, to ensure that the levels, as set, are acceptable to customers. Here, the IT organization may offer a level of service based on available resources and reasonableness, allowing the business units to negotiate higher levels of service if need be (and if realistic) for increased levels of business unit contribution. In reality, from time to time IT must deliver on service requests at the eleventh hour and usually at the behest of a senior enterprise executive. Some of these requests are driven by unforeseen business opportunities or crises. Others are merely due to poor planning. Whatever the reason, will your CIO say no to the president of the enterprise in such a circumstance? Service providers should anticipate these events and account for them in the overall SLA schema, just as the IT organization will need to accommodate such requests in its allocation of personnel and other IT resources.

No service level commitment will hold unless the IT service providers in question can validate their own ability to meet the service levels offered in the SLA. To that end, they must decompose their processes and measure process outcomes, adjusting metrics as needed and, one hopes, before presenting them to the customer for approval. Even so, the final test is in the doing. Do not be surprised if your initial foray into SLA metrification requires a midcourse correction or two. As your problem tracking system compiles data, your team will learn how long it truly takes to resolve particular problems and deliver support and maintenance services. The averages that come out of your measurement tools will let you know. Perhaps you will need to reengineer processes for efficiency or add resources because of increased demand. Sometimes, you will need to find other ways to provide needed services, such as outsourcing a particular service to a more proficient third party. Do not be afraid to admit that your IT organization is not all things to all people. Your performance measures will assist you in justifying your course of action and in building customer support for that course of action. Your organization's CREs will provide an essential role in managing the ongoing expectations of business unit customers and ensuring high quality, continuous communication among all parties in this service delivery management process. Thanks to the tools at hand and the analytical and operational support of the PMO, the CREs will have an advantage in dealing with your key customers.

Truly effective IT service organizations get that way in part due to collaboration among their service delivery units. For example, the help desk or call center must maintain an effectual intake process. To the extent possible, customer issues should be addressed then and there, rather than being passed off to another IT team. When others beyond the help desk or call center must address the customer's need, handoffs should be timely and properly directed. The receiving IT team must address customer problems and requests in keeping with the priority codes and service levels agreed to within the process. To ensure that these activities are well coordinated, IT organizations may even rely on internal SLAs to set clear, measurable performance standards among IT service units. [5] The author certainly endorses this approach, but it may not be realistic for enterprises in which the culture of collaboration is more informal. [6] Whatever form the effort takes, the IT team must agree on service levels, the timing of handoffs, and measurement and reporting standards.

In many instances, IT organizations address problem resolution and service delivery management through a three-tier model, in which the help desk or call center serves as Tier 1. At the Tier 1 level, IT personnel do the entire intake process with an objective of addressing 80 percent or more of all problems over the phone. When resolution by phone is not possible, the problem or request is escalated. A field support team, also possibly operating within Tier 1, [7] may be dispatched to address desktop and printer issues and to install hardware and software locally. See Exhibit 3. For those problems requiring a higher level of expertise than that found within the help desk and field support teams, tickets will be forwarded to Tier 2's internal teams of specialists (e.g., network services, client server systems, and application development teams). These experts will provide the fixes required to get a particular IT product or service back online.

Exhibit 3: A Three-Tier Service Delivery Model

start example

click to expand

end example

When the issue suggests a larger hardware or software problem, requiring the replacement, upgrade, or reengineering of an IT product, the ticket will escalate to Tier 3, where IT vendors and other external partner providers may get involved. From the perspectives of cost and customer satisfaction, it is far better to address an issue in Tier 1 rather than to have that issue work its way to Tier 3. Invest in a skilled and highly cross-trained help desk team and build IT solutions around standardized and well supported technologies. If your service teams are meeting 80 percent of customer needs through Tier 1 services, 15 percent through Tier 2 services, and 5 percent through Tier 3 services, you are doing very well indeed, especially when the knowledge gained from these experiences is recycled across the IT organization in the spirit of continuous improvement. Employ the PMO to codify and disseminate this learning.

By measuring and reporting on performance, IT management has an advantage in dealing with overall customer satisfaction. And this is the name of the game. To ensure that IT comes away appreciated and respected by the customer, take care to ensure the quality of the Tier 1 experience. Complement this effort by making it crystal clear what your business colleagues should expect in service through an SLA process. In this manner, IT will be managing the situation from both the bottom up and the top down. Together, these processes will make it easier to work in partnership with the business side of the enterprise and to gain the recognition that your IT team deserves. Let us now consider the SLA document in more detail.

[2]Most organizations will set a threshold on the costs and risks associated with a service request. Any request that exceeds this hurdle rate (e.g., the project is either high risk or exceeds a cost of, say, $100,000) is treated as an IT project and undergoes the kind of scrutiny and management rigor appropriate to larger, riskier IT undertakings.

[3]For a graphical representation of the workflows and associated measures for the problem resolution and service request processes, see The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt4~1~Service Delivery Workflows with Metrics~example. For a template with examples see chpt4~2~Service Level Management~example with templates.

[4]Your organization's problem ticket system will usually provide reports that may serve as the basis for setting performance levels. In the spirit of continuous improvement, choose a level of performance measure somewhere above the mean. Whatever level you choose, it must align with the IT resources devoted to delivery. Otherwise, your SLA process is bound to disappoint your customers.

[5]In getting Northeastern University's IT service providers all on the same page, information services (IS) adopted performance standards and metrics as a team process and then employed staff training to educate each member of the IT staff about how his or her work would be measured according to these new standards. For an example of the associated training tool, see The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt4~3~SLA~template. For an illustrated application, see chpt4~4~SLA~example. For a hardcopy version of this tool see Appendix D.

[6]Some IT executives worry that establishing internal SLAs will provide their people with an excuse to perform only at the levels set in the agreement, or that service personnel will hide behind an internal SLA when services fail. These concerns may be addressed as part of the process, but it will not be easy. The IT management team must first create an environment in which collaboration is rewarded and performance measurement is viewed as an essential tool for continuous process improvement. Although this is a challenging undertaking, the rewards of a successful application of the principles embodied in this process are great.

[7]In typical IT parlance, Tier 1 support refers to help desk or call center intake support. Tier 2 support refers to work done by the internal IT support unit responsible for that product or service. Tier 3 support refers to a service need that typically exceeds in-house expertise and thus involves both the internal IT service unit and an external technology partner provider in addressing the customer need.



 < Day Day Up > 



The Hands-On Project Office(c) Guaranteeing ROI and On-Time Delivery
E-Commerce Security: Advice from Experts (IT Solutions series)
ISBN: N/A
EAN: 2147483647
Year: 2006
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net