Does ServiceNow do SIAM?

I’ll start this post with a nice stock image of ITSM processes.  It shows loads of ITIL terms.  But it misses something really important – the suppliers.

SIAM – Service Integration and Management – is a term which is very popular at the moment.  The idea is not new; what’s new is the implementation and terminology, and getting an ESM tool like ServiceNow to fully support it.

The SIAM model shows services to the organisation divvied up into Service Towers.  One supplier could have one tower or multiple towers; and may subcontract, outsource or otherwise engage multiple other suppliers in the provision of that service.

ServiceNow provides a great platform but out of the box it’s wide open – it assumes effective collaboration and separation of duties are implemented by policy, procedure and work order.  In other words : everyone can see everything; everyone can update everything.

There’s exceptions of course, but focusing on the core IPCC (Incident, Problem, Configuration and Change) modules, that’s how it works.

Implementing SIAM role separation is a great middle ground between the out of the box functionality and going for domain separation.  Domain Separation provides total isolation between domains, at the high cost of no collaboration between domains.  SIAM permissions bridge the gap.

Reference : Domain Separation

So what’s the problem with Out of the Box?

A typical ServiceNow deployment assumes that the ‘itil’ role is shared amongst all the resolver groups.  The permissions assigned to itil mean they can raise tickets, be assigned tickets (via their resolver group and directly) and can edit those tickets.

Catch 1 : All itil users can see AND EDIT everyone else’s tickets.

In addition to itil users, a standard concept is that of a senior user with additional rights can oversee the work of the teams – an incident manager in other words.  Thus your permissions might be expanded as follows:

  • itil can edit, when active = true and “assignment group” is one of my groups.
  • incident_manager can edit, when active = true.

The same logic could apply to the first line helpdesk, to allow them to route tickets between teams – effectively giving them access to tickets which aren’t assigned to them.

Catch 2 : incident managers can be given access to all tickets based on available parameters – but what happens when a supplier has incident managers and they need to have this access too?  They will get access to all tickets from other suppliers too.

TL;DR – Whats the solution?

To make the permissions flexible you need to move away from the simplistic view of permissions which come out of the box.

Expand the logic of user roles vertically across service towers – and make it flexible such that one supplier organisation could have ownership of multiple towers within your company, and their incident managers (and other privileged roles) may be shared across the towers.

To do this you must design the user, group and role model to include the concept of service towers, then code the ACLs to use this.

My most recent design uses a custom field on the Group table (sys_user_group) called Group Type.

Groups can then be flagged with their intended purpose, and assignment group fields can be filtered to only allow tickets to be routed to Resolver Groups, not Approval Groups for example.

Service Tower groups represent the contractual Service Towers and they could be internal or external.  An organisation may find the Finance team run their own IT systems for a specific system, and need to assign tickets between themselves.  Thus a senior manager may become an Incident Manager only for their internal Tower.

To allow us to differentiate, we add a secondary field and use both UI and Data Policy to ensure it’s used : The Service Tower type.

This allows permissions for an internal Incident Manager in the Service Integration team to have wide reaching access across all towers, but a supplier Incident Manager to only have access to incidents owned by their tower.

The additional requirement here is that users and Resolver Groups must be linked to these Service Tower Groups – and that’s mainly driven by policy and good reporting to identify exceptions.

That’s it for now – I’ll deep dive into the implementation of this logic in my next post.

Comments and questions are always welcome – and thanks for reading this far!

Leave a Reply

Your email address will not be published. Required fields are marked *