Intro
We’ve recently been involved in a number of projects which share common characteristics. They’re not technology projects, they’re driven by the demand of real end-users, not by IT or business leadership typically as part of a digital transformation agenda. The projects are aimed at making IT services more accessible to an organisation’s employees and involve optimising the Service Request processes which enables end users to engage with IT more effectively.
User Demands
From our experience, end-users generally feel that it’s really hard to get IT to deliver anything to them. IT are great when there’s something to fix, or there’s a major incident to recover from, but they are poor at the basics such as provisioning a new user account, delivering some hardware or giving access to a new piece of software.
The Digital Transformation Agenda
I’m always surprised to hear that these basic principles still haven’t been addressed by the plethora of best practices and tools at the disposal of today’s IT leaders. And if we can’t do these “basics” well, how will we cope with the accelerated delivery cycles promised by agile development and the rapid deployment of services which will be possible as soon as cloud becomes more prevalent? How we can possibly expect to achieve our digital transformation agenda without the basic building blocks in place?
The basic principles of Service Request
I think it’s time to present some basic principles that we need to ensure we’re doing well, in order to support the delivery of more complex and time-critical services in the future. How does your IT department shape up against these maturity indicators?
- There’s a SINGLE portal where all end users can go to interact with IT, to report an issue, check knowledge articles to initiate Service Requests. Users seek simplicity, they want to engage with a simple portal through which they can quickly and easily engage with IT services
- End users are engaged with the service request process, they understand where they need to go, and they understand that circumventing the process is not in their interests. This point attempts to address the risk of untraceable, poorly structured communication, such as verbal or email requests, coming in to IT and simply not being logged. This type of inbound work is impossible to track, trace and measure
- There’s a clear delineation of what constitutes an incident, versus a service request, versus a system enhancement and an IT project. I often envisage a good inbound filtering process in the same way as an airport baggage handling system. It shares a lot of common characteristics, as each “bag” will have a destination, a unique reference, some form of lifecycle tracking and an established path of reaching its destination. Our end-user portals and systems should follow this route-based approach, routing incidents to resolver teams, requests to approval and fulfillment workflows, etc. Each incident and request should follow an established workflow. If these are understood and mapped, it’s easier to introduce efficient ways of recording, assigning, tracing and fulfilling them
- There’s an established workflow for common service request types, which describes the approval processes, fulfillment tasks, who does what and eliminates the need for manual intervention. These workflows can be codified within the service management toolset, allowing a degree of automation to the allocation of work
- Sometimes, approvals are sought where there is no justification for an approval to be required. Where possible, seeking approval should be an automated workflow task. Ask yourself whether the approval steps required for your various request types are really required, and if they are, whether they could be automated
- Are you exploiting workflow automation to the extent that approval and fulfillment tasks are sequenced automatically by the ITSM tool? There should also be a degree of logic built in to determine the path that requests will follow where exceptions occur, such as conditional approvals or rejection
- The end-user receives updates on their request at key points during the process. They’re so used to an Amazon or Dominoes-like order experience, they just won’t settle for anything less!
Conclusion
How many of the indicators above are incorporated into your processes, or within your improvement roadmaps? Without these basic principles in place, you will struggle to achieve digital transformation objectives. Are you ready to act to address these deficiencies? Feel free to contact us to discuss your specific challenges. We’d be delighted to help get you on track.
