6 Features Every SIAM-Compliant Service Management System Must Have
Many enterprise service management tools claim to be SIAM compliant, but most are not. This white paper explains which requirements must be met to be SIAM compliant and how this can be tested.
When SIAM Is a ‘Hamlet Without a Prince’
When transforming a traditional IT organization to a SIAM-based organization, the IT leadership team must often make a tough decision on how to organize the service integration layer. One of the decisions they may be debating right now is whether the service integration function should use the legacy ITSM toolset already in place, or whether to implement a new SIAM-compliant tool to support the service integration layer.
For those who are wondering why a SIAM-compliant service management tool might benefit their organization, the bottom line is this: The service integration layer cannot do without.
According to the Global SIAM Survey 2018 from Scopism, 53% of organizations desire to have more control or achieve better performance from their vendors as their most important strategic driver for implementing SIAM. More control and better performance from vendors is what a SIAM-compliant service management tool is built for. Organizations that do not have the right toolset are constantly struggling with a lack of collaboration between the different actors and with inadequate reporting to understand where things are going wrong. They typically spend a lot of time collecting data and preparing reports instead of discussing the quality of the services being provided. These SIAM organizations perform in a ‘Hamlet without a prince’, i.e. a performance that is taking place without its principal actor.
But how can one distinguish between tools pretending to be SIAM compliant and tools that are SIAM compliant? The following sections review the 6 features that distinguish a SIAM-compliant service management tool from a non-compliant one.
1. All About Service Orchestration
A service offering should include service level targets in concise and simple terms. For example:
A ‘high’ impact incident should be responded to within 1 hour and be resolved within 4 hours, and this during business hours defined as ‘Mon-Fri: 8am-5pm EST’ excluding banking holidays.
Such simple target definitions are possible when there is a common set of rules for tracking the actuals so that they can be compared with the targets. In an environment with multiple service providers these rules need to be accepted by all stakeholders. It starts with the agreement on the start- and end-points that define when a response and a resolution have been provided. And it should include rules on when the clock can be stopped.
Imagine, for example, the following ‘real-life’ scenario:
- A ticket is created and assigned to the (external) service desk.
- The service desk determines the service and the impact so that the priority is calculated, and assigns the ticket to service provider A.
- Service provider A declines the ticket.
- The service desk asks the customer a question.
- The customer answers the question the next day.
- The service desk once more assigns the ticket to service provider A.
- Service provider A assigns the ticket to service provider B.
- Service provider B decreases the impact of the ticket.
- Service provider B resolves the ticket.
To deal with this scenario, the rules need to answer the following questions:
- What happened to the completion target when the ticket was reassigned for the second time to service provider A? Is the start time for calculating the completion target the moment that the ticket was originally assigned to service provider A or the moment that its was assigned for the second time? And should the duration that the ticket was returned to the service desk be excluded for the completion target calculation?
- What happened when service provider B modified the impact? Should this affect the completion target for the customer?
- What if the new impact level stipulates different support hours (for example, a high impact dictates 24×7 support hours, while a low impact requires support during office hours only)? Is the completion target recalculated?
In a SIAM environment, all these questions and many more need to have a clear answer for all internal and external providers. So it is not enough to define for each service in the organization’s service hierarchy what the response and resolution targets are, along with the support hours, for each impact level. That is an important part of setting up the SLAs, OLAs and underpinning contracts. But it is just as important to ensure that all providers agree on the orchestration rules. The collection of all these rules makes up the service orchestration layer. In order for a service management tool to be considered SIAM-compliant, it has to provide a complete and tested set of rules to deals with all the complex scenarios that happen in real-life.
2. Dynamic Data Segregation
In a SIAM environment, many service providers may need to work together on the same ticket. This means that they need to share information on the ticket with other providers. But a ticket should be shared only with the providers that are involved in its resolution. The other providers should not have any access to this ticket.
This requires dynamic data segregation. At the start, a given ticket may be visible only for service provider A. Then, when the ticket is reassigned to service provider B, access to the ticket is given to provider B. When service provider C is involved, provider C also gets access.
In an environment with 3 providers, there are 7 data segregation possibilities (tickets visible only for A, B or C, tickets visible for A and B, A and C or B and C, and tickets visible for A and B and C). Having 4 providers causes the number of combinations to increase to 15. With 5 providers the number of possible combinations is 31. In a system with static data segregation (which most tools offer with their support for ‘multi-tenancy’) a ‘tenant’ needs to be defined for each combination. The number of providers that a modern enterprise relies on is gradually increasing as more SaaS solutions are introduced, which means that the number of ‘tenants’ quickly becomes unmanageable. With dynamic data segregation, only 1 ‘tenant’ needs to be set up for each service provider. The tool dynamically provides a provider access to a ticket when the provider’s support is needed.
3. Process Segregation
In a SIAM environment the service providers will be working together within the same core processes (incident management, request fulfillment, and change management), but each provider needs to have the freedom to organize itself differently to ensure that it can continue to optimize itself. A SIAM-compliant system allows the core processes of the different providers to be integrated, while giving the individual providers full control over their internal support structure, workflows, detailed instructions, escalation rules, and automated provisioning.
4. Integrated Dashboards
SIAM is all about understanding how the different service providers work together and the quality of the services they provide. This insight is not given by traditional reports, such as ‘tickets created and completed during the last month’ or ‘SLA targets met and violated’. It requires integrated dashboards that make the complete service orchestration context visible and reveal how the tickets flow from one service provider to another, and how each provider performed. These integrated dashboards not only show the information on a global, consolidated level; they also provide drill-down options to the level of the individual providers and tickets.
5. Service Integration by Proxy
Some of the service providers in a SIAM context will continue to work on their own service management system. In such cases, the SIAM-compliant service management system acts as a proxy for the service management system of the service provider. The service providers may work in their own service management system, but the rule set that governs the calculations for SLA reporting is defined at the proxy layer that connects the different service management systems of the individual providers.
This means that the dashboards that the service integrator relies on present information that is calculated using a consistent rule set that is independent of the service management system that the providers use.
But even though some providers may use a different tool, the SIAM-compliant service management system needs to give each provider access to the reports and dashboards that the customer uses to track its performance, while ensuring that providers cannot see each other’s performance. Being able to see how well they are performing for their customer makes for more constructive service review meetings.
6. Agility in Onboarding new Customers and Providers
The stakeholders in a SIAM ecosystem tend to change rapidly. Customers and Service Providers join or leave the ecosystem at a rapid pace. The SIAM-compliant service management system should not be a bottleneck in the onboarding (and offboarding) process. It must be an agile system where a new customer or a new provider can be onboarded in a matter of minutes, without the need for technical integrations. The cost and effort of connecting with new provider should never be the reason to stay with a provider that does not perform. It should also not slow down the introduction of new services from new or existing providers when the business needs them. Even a small provider with only a handful of staff members should be cost-effective to integrate into an enterprise’s ecosystem.
Service Management Toolboxes Are Not SIAM Compliant
So, a SIAM-compliant service management system needs:
- A service orchestration layer
- Dynamic data segregation
- Process segregation
- Integrated dashboards
- Service integration by proxy
- Agility to onboard new customers and providers
Most enterprise-class service management tools are essentially software development environments, also known as toolboxes. They can claim to be SIAM compliant because they allow organizations to build these capabilities in them. Such a development initiative would, however, exceed the competence of all but the most experienced tool experts. The time and money it takes to build a system that effectively supports service integration is enormous and the risk of failure high.
Also, it is important to understand that such service management systems do not support the dynamic data segregation requirement, which takes any project to build a SIAM-compliant system with a toolbox on an expensive path to failure.
That is why a system should not be considered SIAM compliant unless it provides the above capabilities out-of-the-box.
Why Not Build a SIAM Data Warehouse?
Would an Integrated Data Layer be enough? Would it not be sufficient to collect the data from the different systems of the service providers and merge this data in a ‘SIAM Data Warehouse’?
Unfortunately, it is not. When the data from the different service management systems is collected in a single SIAM data warehouse, this warehouse will contain multiple tickets that reference the same issue. But much of the context would be missing. For example, when the end-to-end completion target was violated in the request that was submitted by an employee, but the assistance of multiple external providers was needed to resolve this request, it is not possible to determine whether the responsibility for the target violation lies with an internal support team or one of the external providers.
But there are other reasons why collecting the service management data from the different systems into one central SIAM data warehouse is simply not practical. It brings together inconsistent data based on different rule sets. Although some of the inconsistencies may be resolved by data mapping, this makes the set up and maintenance of the SIAM data warehouse complex and expensive.
Validation by a Proof of Concept
It is easy to test whether a service management system is SIAM compliant by requiring a simple proof of concept. Ask for a test system with at least 2 external service providers, and check if the system can deal with the real-life scenario described at the top. Check if the data and processes are kept segregated. Then add another service provider. This should not take more than a few hours. Then, check the scenario again. Verify that the dashboards and reports from the business and service provider perspective are consistent.
Such a simple proof of concept allows organizations to verify whether a vendor’s claim, that its software is SIAM compliant, is based on facts or slide ware.