fbpx Skip to main content

Building an effective Service Request process in a SIAM model

Building a multi service provider or Service Integration and Management (SIAM) IT operating model has lots of potential benefits. For example, it gives organisations the opportunity to leverage commercial advantage from multi-sourcing, as well as buying best-of-breed services and ultimately improving the quality of IT services.

However, creating this operating model is not without its challenges.  We’ve written in the past about challenges in the area of Service Request/Request Fulfilment processes.  This is the process whereby user’s request services from IT.  These can be very simple, like a new laptop for example, or more complex “bundled” services, such as a new user, which could comprise multiple hardware items (e.g. laptop, phone, etc.) as well as access permissions and software installations amongst other things.

In a traditional monolithic sourcing model, or one where IT services are all sourced from a single internal provider, these requests are relatively simple to set up and execute.

However, in a SIAM model, they can become more complex, due to a number of factors:

  • Different services from different suppliers may need to be integrated to form one of the bundles described above
  • There may be numerous steps involved in approval of the request which will need to be orchestrated ahead of submitting it to the supplier(‘s) work queue.
  • There may be numerous fulfilment steps, some of which serial, and other’s parallel.

Here’s how we normally tackle this type of challenge.

We recently worked with two clients who both had a similar challenge; How to build an effective Request Catalogue in their Service Management tool.

In order to deliver this work, we followed a tried and tested approach which includes:

  1. Mapping the workflow for each request type by identifying the following requirements:
    • Business approvals
    • Technical approvals
    • Fulfilment/deployment steps
  1. Using a simple spreadsheet to log this data enables us to spot opportunities to rationalise approval or deployment steps.Often, clients can’t explain why a particular request requires 5 approvals, other than “it’s always been that way”!
  1. The completed spreadsheet provides the basis to categorise requests which can then be grouped together on the user’s request portal.This will make them easier to locate.

Other aspects to consider are:

  • Entitlement
    For each request type, is there a level of entitlement which may prevent certain user groups from being able to order that particular item? This can be enabled in the tooling through menu based options, or from a more sophisticated perspective using details of the user’s role or department from their ITSM tool record / Active Directory records.
  • Options / Variations
    For each request type, there may be a number of variations which can be requested. For example, if a user requests a laptop, there may be a small version for travelling staff, a standard model, and an enhanced specification for power users.
  • Sequencing
    With regards to the approval and deployment tasks, consider the sequencing in terms of whether they are performed in serial or parallel. It is important to streamline the end user experience of requesting IT services from the catalogue.
  • Adoption
    Consider the adoption strategy, through a combination of communication, incentives, and engaging with key influencers in the user community to spread the word.

If you are considering building a Service Request Catalogue, contact Syniad IT to discuss your unique requirements.

To find out how we help organisations like yours design and build highly effective operating models, read our ultimate guide to Design + Build.

To find out how we help organisations like yours optimise their processes, read our ultimate guide to process optimisation