Vihreä Ruusu - Service Request Portfolio

Vihreä Ruusu

Service Governance	Service Level	Processes and Practices
Mode of Operation	Vendor Relations	Availability

Suomeksi

Matti Grönroos CV

Matti Grönroos

Service Request Portfolio

A service request basically is an instrument to produce any IT services that other processes do not produce. This "dump yard thinking" is flexible, but in the longer run it may lead to an uncontrolled service suite in terms of cost and content.

ITIL declares a term Standard Service Request. It is a task included in the Service Request Portfolio, and it usually can be fulfilled quickly. The speed is not about being out of control: Even standard request may require authorization.

Companies are not always very eager to make their service requests standard ones. This is short-sighted.

Based on experience, all kinds of strange things accumulate in the service request portfolio over the years. In the worst case, it is questionable if all the requests in the portfolio are about IT at all.

The standardization of service requests aims both to serve users better and to create better visibility for what the service receivers want from the IT. Often the starting point is quite fuzzy, but then standardization work tends to reward itself.

Increasing the Share of Standard Service Request

A service request can basically be anything, from a request to change a password to ordering a new computer. It is up to the organization, what it wants to be delivered quickly, and what would be subject to more strict procedures.

The following attributes often apply to the standard service requests:

List price (or no charging)
Service Level Objective
Service Description
Order Form
Approval procedure, if significant cost
Repeatable

Better to use the language the service recipients understand: Give the services a reasonable name, tell what the deliverables are, avoid any techno jargon, do not focus on how the services are implemented, do focus on outcomes and benefits. It is essential to hide the complexity of the process map from the end-users: They usually do not what is an incident, what is a service requests, and what is a change. Never penalize the end-users for approaching though a wrong path.

This is not a crash action to be complete at once. Instead, it is better to be agile and remember how to eat an elephant: one piece at a time. Start small but aim for big: bring something new to the service receivers every two to three months and hit the marketing drum in between. Be prepared for changes and fine-tuning. Gradually close the unwanted channels, and kindly direct the service receivers to order forms and other preferred channels.

Do not make the end-users integrators. Most of them do not like jigsaw puzzles to make something useful. Instead, pack services as large entities as it makes sense.

Better to be aware of production costs. If you are not, how do you know if you are producing profitable and correctly priced services or not?

In the case of long lead times, it is good to create a function that allows the customer to see where they are going. The status text "In Progress" does not create any value: The requestor knows already knows it. In any case, automation should be preferred if there is a business case for it. If you are considering implementing service requests entirely or partially offshore, the business case should be evaluated more deeply: Offshore may be cheaper, but the speed and uniformity is created through automation.