So you've read the ITIL book, been on the course, copied and tweaked the diagrams in PowerPoint/Visio and you have a bunch of things you can loosely term as service requests or standard changes.
Surely translating that into a singing, dancing process is comparatively easy?
Well I am not going to spout out what the good book says here—people are capable of reading for themselves.
But what I will say is that the key to any process implementation is your adoption of the guidelines to suit your requirements.
I am a very strong advocate of the need to really understand what the requirements are before you even tackle process, tool, organisation and who is in charge of the coffee.
In fact I would go as far as to say—the tool does not even matter at this point.
The reason an organisation is looking to implement (or improve) an existing process has a business rationale attached to it—more often than not to save money.
That may be through outsourcing, it may be through more automation to free up skilled staff to help meet other business drivers, but rest assured there is almost certainly a [/insert currency of choice] value behind it.
I am sure many of us have seen issues when trying to implement Request Fulfillment.
There are several approaches that ITSM consultants Ali Hirji and and Jennifer Gianfrancesco have found to help, and they have been kind enough to share them with us.
Part of a consultancy group to put together processes and procedures required in dealing with requests from large projects to routine day to day requests.
This activity eventually led to the development of a technical request catalogue, used to formalise routine activities.
The client was unhappy in the way in which requests were made, and the time being taken to deliver them.
IT personnel had little control over the time spent dealing with request activity, and the management did not have enough data to help structure and plan their teams more effectively.
They also did not have sufficient information on customers/requesters in order to re-bill the costs of their efforts.
"There was no structure at all.
"As and when people wanted things, they were requesting them via telephone/email.
"The delivery teams had little control over what came their way and therefore were not able to plan accordingly."
His team's approach was to classify activities that were Business-As-Usual maintenance tasks, and determine which were the small requests–those that take less than 50 man-days to execute.
The small requests were further divided into standard and non-standard requests.
The execution scenarios would be quite standard, formalised and could be quite easily documented, if they had not already been written up, along with a defined set of parameters.
As a result, the lead time and effort required to execute the request would be fixed and provided as part of the catalogue.
"The aim was to have as many standard requests as possible so for non-standard requests , we would try and identify what factor was stopping them from considering it as standard.
"We could then estimate effort and turnaround time based on that factor as a differentiator, for example the size of a database, therefore helping us provide a range of standard requests."
Their first iteration of the catalogue was very simple with free text fields and a very basic workflow, to encourage use with the intention of further maturing the tool as it was more widely adopted.
Jennifer offered an insight to her experiences and also advice on Request Fulfillment process implementation.
"Set-up really depends on what customers are looking for and could be around two weeks.
"It depends on if there are a lot of customisations required."
Jennifer has also found that higher management of customers feel comfortable with additional consultancy to help extend their use of the system, when they are ready to use more advanced features of the tool.
"Outsourcers look at it from a different perspective.
"KPIs and metrics may be different for them than for in-house service management."
"Too many people get hung up on what ITIL says."
Here are my key takeaways:
The overriding sentiment from practitioners is: Keep It Simple.