We will soon begin our review of Request Fulfilment offerings in the ITSM market place. Our goal is to highlight the key strengths, competitive differentiators and innovation in the industry.
In my previous article I looked at what ITIL 2011 had added to the process, and some of the pitfalls we may have seen in trying to implement Request Fulfilment in the past.
I would now like to take a look at what this means, in practical terms, when approaching Request Fulfilment – what should we be looking for?
At the recent UK itSMF ITSM Software Tools Forum event in Manchester, vendors spoke to the audience at length about transitioning from IT focussed decisions, to business outcomes, and this is an area where Request Fulfilment could come into its own, especially in the sphere of interaction by non-IT users.
But a transition is a gradual thing, and the importance of the concept of conformance should not be forgotten. I think it remains an important element for any vendor’s toolset to be comparable to identified, accepted benchmarks, as well as unpicking the practicalities of deployment a solution.
Principles vs. Process
What is more important at this stage, is the ease of which a tool’s capability can be displayed.
Demos at shows are slick and well prepared and I dare say a lot of us have had to go through the rigours of setting up demos and knowing what to click, how and where.
What we are looking for vendors to do is demonstrate to us how easy is it to start from scratch, ideally with meaningful options for an end user to start with.
It is probably too much of an extreme to launch from recognisable standards and certification/verification platforms, to merely focussing on the look and feel of menus and options for end users in one fell swoop.
So for that reason, I am including a need to understand how vendors align to accepted best practice standards.
- Have our target vendors aligned to ITIL and if so, to which version?
- How do the set up roles and users to perform functions?
- What demo capabilities can they offer potential customers?
- What request workflows are available out-of-the-box
- How easy is it to develop more specific workflows?
- What additional administration is required for deeper customisation? At what cost?
- How is your self-help portal set up?
- How do you incorporate new service descriptions for your users?
- How much administration is needed to do the more bespoke work?
Request Status Tracking
- Show us how any request is tracked throughout its lifecycle?
- Who can see it, and when, and which teams can change it/move it on its way?
Prioritising & Escalating Requests
- Show us how your tool prioritises requests and how they can be escalated?
- What kind of other factors can affect a ticket (for example breaching SLAs and the escalation from that point)?
- If a request becomes something more complex, how does your tool allow the alteration of the request (for example, a Change)
Financial & Other Approvals
- Demonstrate a request model that includes alternative approvals (other than immediate manager)
End-to-End Co-ordination to Closure
- We don’t expect tools to prescribe exactly how organisations manage their Request Fulfilment processes, just as we don’t follow ITIL blindly BUT during the course of the review, we want to understand how a request can move through its lifecycle, end-to-end.
- We want to understand the simple (out of the box), the medium and the complex (and the related additional costs that might be involved to get an organisation there).
I think it is rare that anything is utilised completely “out-of-the-box” these days, and that organisations will always have a requirement for some level of customisation. Request Fulfilment is certainly a process that could lend itself to quite intricate customisation, to the point of over-complication.
What is your view? What have we missed?
Please leave a comment below or contact us. Similarly if you are a vendor and would like to be included in our review please contact us. Thanks, Ros.