Service Request or Change Record? The Grey Area Between

Keep It Simple

ITIL provides a framework not a doctrine. You may recall that on ITIL courses, debates arise due to ITIL interpretation varying between organisations. So the same set of steps may be classed as a Service Request in one business but as a Change record in the other. This is OK. Both businesses may have valid reasons for their approach. 

The definitions of Service Request  and Change - 

Service Request - A request from a user or a user’s authorized representative that initiates a service action which has been agreed as a normal part of service delivery.

Change - The addition, modification, or removal of anything that could have a direct or indirect effect on services.

- allow for some overlap (see Figure 1). 

Figure 1 - The grey area of overlap of Service Request and Change.

There are lots of Changes that will never be in that overlap. In practice, the overlap will predominantly be changes that arise from users approaching the service desk with Requests for Change. Since we expect the overlap to be user-driven requests, it may represent a way to influence Service Experience. The grey overlap in Figure 1 should be viewed as source of service improvement opportunity.  

It is a big jump to refactor a request from being handled as a Change to a Service Request. An intermediate step may be sensible. The progression from Change Request to Service Request may involve some time being a Standard Change. 

Standard Change - A low-risk, pre-authorized change that is well understood and fully documented, and which can be implemented without needing additional authorization.

Can you think of any examples of modifications in your business that have, over time, become Standard Changes or even Service Requests?

Examples will likely be generic requests for a resource or more resource. Maybe requests previously required a Change process approach to achieve budgetary approval.  But the availability of an Enterprise Resource Planning tool may enable budgetary authorisation to be streamlined - pre-approving small amounts. So a request for more space or access to a licensed software package may now be available via the request fulfilment. 

Conclusion

Those ITIL course discussions about the grey areas - the areas where there is debate about whether things are apples or oranges - are ripe for stimulating a service improvement conversation. The overlap areas may represent aspects of service that have become grey. This may have happened due to developments outside the scope of the service owner or even the business.  The overlap areas may be flags  indicating the prevailing wind. As such, they are worth noticing.

Related Topics - Shift Left; Agile; DevOps

The above blog is not intended to be a comprehensive view of either Request for Fulfilment or Change Management. It is more a call to look at the process overlaps that evolve.