Highlights of ITIL V3 Request Fulfillment (part 2)

Here is part two of Highlights of ITIL V3 Request Fulfillment.  As I wrote previously, I have been reading the ITIL V3 books and one thing strikes me as a positive step forward: there's more how-to prescriptive guidance than in ITIL v2. 

Specifically, looking at Request Fulfillment there they outline some of the technology requirements and /or practices needed.  So here are the rest of the notes I took.

Separate request fulfillment from incident and change.  We have always known that it made no sense to have requests be part of incident.  For one, it messed up reporting because we want to reduce incidents, but service requests will keep growing.  So no more mess and we'll have clean reports.  But theres more.  Requests are how customers interact with a supplier; it leads to an experience from which the customer makes a quality assessment.  Different types of requests have their own completely different delivery workflows; with different steps that often span both approvals, delivery, and suppliers. It just makes sense to have requests be its own separate process.

Integrate Requests with ITIL operation processes such as change, asset and configuration. Some requests trigger changes downstream, some require new assets to be added, some change assets and / or configurations.  I was with a a customer recently and they have requests to manage system monitoring and to request that availability be monitored for specific applications.  Having a record of who made the request, what was the promise, and what process was triggered brings both visibility and accountability to this process.  It makes sense to tie requests to some of our ITIL processes.

Integrate request processes with non-ITIL processes such as procurement, suppliers, and provisioning systems.  In my experience, there are a number of non-ITIL processes such as procurement;  departments outside of IT such as facilities, HR, telco; suppliers and manage service providers.  As more IT departments outsource to multiple providers, the catalog should sit in the middle, shielding the users from having to know who the provider is. 

As more IT departments become part of shared services, certain requests such as "set up a new vendor in the extranet" cross procurement, accounts payable, and IT security.  Meeting this requirement is super important to have a scaleable service catalog.

In fact, more and more customers are taking the help desk out of the request equation by providing a strong, self-service experience, automated authorization processes that work (so many just don't... it's embarrassing), and connected to provisioning software. So they go from request to approval to automated provisioning of id's, software, servers, telco, etc. Never touches the help desk. Very cool. 

The service request catalog views needs to be driven by “agreements” that exist in the business service catalog.  This requirement separates the first generation service request systems from the industrial-strength service catalogs.  I will explain.

In large organizations, there will be multiple organizational units, each requiring different service offerings and entering service agreements with different sla's, configurations, etc.  We want to automatically populate that organizations service request catalog from the agreements entered from the business service catalog. 

A practical example.  Our Industrial Sales Organization enters into an agreement for a business service called "mobile sales services." This business service includes laptops, blackberry, sprint cards, on-site repair by Compusa, and access to Kinko's for printing on demand presentations, etc, etc.

The  business service catalogue  would automatically populate the service request catalog so that  it would now display for the Industrial Sales organization, and only them, request such as "Add blackberry," "Set up kinkos account," "Upgrade laptop." We can even set up bundles, such as "New sales person" to provision new sales people with everything they need in one swoop. 

This is a powerful concept. It's not just a convenient time-saver, but this process now closely integrates the business process to the specific expenditure.  Which is what ITIL v3 is all about: business and IT integration.

A single point of contact.  The end user view of the service catalog needs to be the one place for all service requests. If you have multiple channels, you will not get adoption.  That is, nobody is going to buy from your store.  As I've written before, adoption will be your single biggest challenge post implementation.  Here are 10 best practices to consider, and some common pitfalls to avoid.

If you read all these requirements, you see that the catalog system is a lot more than a list of services. In fact, the service catalog system needs to be wholly separate from the help desk.  For starters,  the ROI from self-service comes from bypassing the manual steps of the help desk.  Also, the request management process needs to be managed, regardless of how owns the help desk.  This is a topic for another post.

Your thoughts are welcome.

Comments

[Prashant Bhardwaj]

In addition to above, the Service Catalogs in future can also be used in Strategic outsourcing accounts for requesting new services by the clients from Vendors....
thing like renegotiations of the contracts, enhancements in business applications, or introduction of new business applications etc can all be treated as a Service Request and the Request Fulfilment process can govern the entire request fulfilment lifecycle.

[Rodrigo Flores]

You make an excellent point.

My note was really about how ITIL v3 sees Service Fulfillment... But as you point out there is a lot of strategic opportunities in a well managed service request process.

We have seen customers using the catalog to manage both the day to day service requests with their managed service providers (MSP)as well as managing the addition of new services to the contract.

In fact, in a few, we are seeing both the customer and the MSP using our service catalog to manage the relationship. The customer cares about control, governance, and making life easier for their users. The MSP cares about efficiency and customer satisfaction.