I'm reading all the ITIL V3 books. I will post some observations and notes as I go along. First up, Service Operations.
Good: We now have a request fulfillment process. Yes!
Better: The book clearly calls out the use of self-service portal.
Request Fulfilment offers great opportunities for self-help practices where users can generate a Service Request using technology that links into Service Management tools.
No so good: The book says the process starts with a service request, but service request is a process itself -- and it's implicit.
Never say die award: While Request fulfillment is a new processes, the book still tries to make it a kind of incident or pre-approved change process. What about just calling it work orders? A request may start because an incident, but they are a completely different processes; no need to make them an incident. Enough.
Best: Finally we have a unifying need for service requests that deal with access management! So access management and requests are tied.
Bester: And so is the automated provisioning of software and ID's and other goods.
More work to be done: It briefly mentions the need to tie Service Requests to the Portfolio; another time it ties to the Catalog but the book doesn't specify how services in a request catalog relate to the portfolio catalog -- only that they do. In other words, we need to tie the Request to the service, the service to a portfolio. I know how this needs to be done, but it's not in the book. The book says " Request fulfillment depends on ... The Service Portfolio , to enable the scope of agreed Service Request to be identified"
About time award: Financial approval is part of the request fulfillment process. This entails major changes as pricing is now part of the request process. This means modeling prices, tying it to GL codes, project codes, approval levels, and keeping prices dynamically update.
Call it out once and for all: The book describes self-help partly as follows:
Ideally, users should be offered a ‘menu’-type selection via a web interface, so that they can select and input details of Service Requests from a pre-defined list –where appropriate expectations can be set by giving target delivery and/or implementation targets/dates (in line with SLA targets).
Just call it a request catalog and be done, no need to introduce another element!
Misguided: Trying to somehow bring the request fulfillment process as being central to the Service Desk. With Service Fulfillment needing to incorporate approvals, catalogs, pricing, finance and a linkage to the service portfolio, we defining a different system than a service desk -- this is the domain of the service catalog system.
Legacy thinking. Incident management is 16 pages. Service Fulfillment is 4 pages. The people who wrote this book have never worked at Starbucks. It's all about the request, baby.
Curious confusion. The book talks about request fulfilment. In American english, we'd say fulfillment.
I've always struggled to make sense of this with ITIL. BMC seems to treat the service catalog as a request catalog, though a lot of documentation seems to talk about a service catalog as a service portfolio.
It has been difficult for me to bridge the gap elegantly.
Posted by: esteban | Wednesday, July 18, 2007 at 04:25 PM
Hi Rodrigo,
I always enjoy your blog so much. You are far more polite than me but I suspect we are sometimes fairly well aligned in thinking :-)
You might consider posting to the BOKKED database any errors, ommissions or confusions you find as you read V3
Cheers
the IT Skeptic
Posted by: The IT Skeptic | Wednesday, July 25, 2007 at 07:58 PM
I am tasked with generating a service catalog a North America software vendor, and I was trying to find a standard list of business services that a business would have under ITIL v3.
Could you provide me that list, and also help me to define what attributes the service catalog would have?
Regards...G
Posted by: Gerard Rendell | Monday, March 24, 2008 at 11:00 AM