Welcome to the cloud and service catalog blog. This blog and its LinkedIn communityare dedicated to the creation, sharing and distribution of cloud management and service Catalog best practices, ideas and trends

Service Catalog Community

stats

ITIL V3 readings, part 1

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.