Highlights for ITIL V3 Request Fulfillment (part 1)

I have been reading the 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 (which should have been called Request Management, because there's a lot more to Requests than just fulfillment) there they outline some of the technology requirements and /or practices needed.

The following is my list so far:

Web Self-Service in an intranet as a core function. Which seems obvious to us, but now it's recognized that a best practice for service request management is to enable a user to go to an intranet to search, compare, learn, decide, request, and track his or her request.  That in fact we want to reduce calls to  the help desk, and that there maybe many different types of fulfillment workflows needed depending on the service request type or content.

The use of a “menu” of choices for the user to select. As I've written before, it's annoying they don't call it a catalog, because it is a catalog -- it's another view into the master catalog and portfolio. Essentially, just like category-type-item is needed for incident management, a catalog of services available to users is core to request fulfillment.  In fact, you will need many different views into the catalog.

The use of a "shopping basket."  This is how the user will interact with IT. They will be a consumer and order services just like they use Amazon.  Of course, a shopping basket is just one function of an e-commerce interface.  You also need to think of category management, multi-channel management (which user sets see what services), search, service comparison, and guidance, status tracking, content management, account management and self-service configuration.  All of this is needed to create that shopping experience.  And you need corresponding management process --- the good news is that those are outlined in the new ITIL v3 catalog management process.

The need for authorization management.  Service requests are very very different from incidents. They often need to be authorized.  These authorizations vary from hierarchical to financial to other types.  In fact, in my experience, one of the most significant obstacles to success in a service request catalog is badly understood, poorly implemented authorization chains.  These can be quite complex for some services or can be complex because the organization itself is complex.  So it's great that this is now recognized and brought forward as a requirement.

The rest tomorrow.

Comments

[buzina]

Yes, it is nice to see ITIL v3 recognize the need for selection based service requests. Unfortunatly v3 has quite some shortcomings when it comes to how to define them (the service catalog example is more a joke than a piece of valuable information), it has a too simplified process (the interesting parts of the governance and the fulfilment are not detailed) and it does not provide enough integration.

I just hope that it is not seen as a tool issue, but as a process, governance and organisational issue.