We’re delighted to welcome 4me as one of our Service North sponsors in 2019 – their second time at our event. In this blog, Wouter Wyns talks about the challenges related to tooling and automation in a SIAM ecosystem.
About 4me
4me allows an organization’s internal and external service providers to collaborate seamlessly, while the level of service that each party provides is tracked in real time. The unique features that 4me provides for Service Integration and Management (SIAM) dramatically improve the success of selective outsourcing.
The self service capabilities of 4me make it possible for organizations to offer their employees online support for any type of question, issue or order. 4me makes it easy for all functions that support the core business – such as IT, HR and Finance – to increase their support efficiency and, in turn, improve the productivity of all employees.
When SIAM Is ‘Hamlet Without a Prince’
When transforming an IT organization to a SIAM-based organization, the leadership team must take tough decisions on how to organize the service integration layer. One decision may debate whether the service integration function uses the legacy ITSM toolset or implements a SIAM-compliant tool that recognises the service integration layer. According to the Scopism Global SIAM Survey 2018, 53% of organizations wanted more control and better vendor performance as the most important strategic driver for implementing SIAM. Control and performance management are what a SIAM-compliant service management tool is built for. Organizations without the right toolset lack collaboration between the different providers and inadequate reporting to pinpoint where things go wrong. Time is spent collecting data and preparing reports instead of assessing the quality of the services provided. These SIAM organizations perform ‘Hamlet without a Prince’.
The following defines the cast for a SIAM-compliant service management tool.
Service Orchestration
Service offerings should include service level targets in concise terms. For example: a ‘high’ impact incident should be responded to within 1 hour and resolved in 4 hours, during business hours, ‘Mon-Fri: 8am-5pm’. Such definitions are possible with a common set of rules for tracking the actuals. In an environment with multiple service providers the rules must be accepted by all stakeholders. It starts with the agreement on the start and end points that define response and resolution rules.
Imagine this scenario:
• A ticket is created and assigned to an external service desk
• The service desk determines the service and the impact, so the priority is calculated, and assigns the ticket to service provider A
• Provider A declines the ticket
• The service desk asks the customer a question, which is answered the next day
• The service desk again assigns the ticket to service provider A
• Provider A assigns the ticket to specialist provider B
• Provider B decreases the impact and resolves the ticket
To deal with this, the rules need to address what happened to the completion target when the ticket was reassigned for the second time to A. Is the start time for calculating the completion target the moment the ticket was originally assigned to service provider A or when it was assigned the second time? And should the duration for which the ticket was returned to the service desk be excluded from the completion target calculation? What happened when service provider B modified the impact, and should this affect the completion target for the customer? And so on.
In a SIAM environment, these questions need a clear answer for all internal and external providers. It is not enough to define response and resolution targets for each service in the organization’s service hierarchy, along with the support hours, for each impact level. This an important part of setting up the SLAs, OLAs and underpinning contracts and all providers must agree on the rules as these make up the orchestration layer. In order, for a service management tool to be SIAM-compliant, it must provide a complete and tested set of rules to deal with the complex scenarios that can occur.
Dynamic Data Segregation
Service providers could work together on the same ticket, so they need to share the ticket. But a ticket should only be shared with providers involved in its resolution, other providers should not access the ticket. This requires dynamic data segregation. At the start, a ticket may only be visible to service provider A. Then, when the ticket is reassigned to service provider B, access to the ticket is also given to provider B and so on, as other providers are involved.
With 3 providers, there are 7 data segregation possibilities (tickets visible only for A, B or C, tickets only for A and B, A and C or B and C, and those visible for A and B and C). With 5 providers, there are 31 possible combinations. In a system with static data segregation (which most tools offer to support ‘multi-tenancy’) a ‘tenant’ must be defined for each combination. The number of providers a modern enterprise relies on is increasing as more Cloud services are introduced, which means the number of ‘tenants’ becomes unmanageable. With dynamic data segregation, only 1 ‘tenant’ is set up for each service provider. The tool dynamically gives access to a ticket when a provider is needed.
Process Segregation
In SIAM service providers will work together within the same core processes (incident management, request fulfilment and change management), but each one has the freedom to continuously organize and optimize itself. A compliant system allows the core processes of the different providers to be integrated, while giving individual providers full control over their internal support structure, workflows, detailed instructions, escalation rules, and automated provisioning.
Integrated Dashboards
SIAM allows service providers to work together and improve the quality of the services they provide. This insight is not available from traditional reports, such as ‘tickets created and completed during the last month’ or ‘SLA targets met and violated’. It requires dashboards that make complete service orchestration visible and reveal how the tickets flow from one service provider to another, and how each provided performed. These integrated dashboards show information on a global consolidated level and provide drill-down options to individual providers and tickets.
Service Integration by Proxy
Service providers can continue to work in their own service management system. As such, 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.
Agility in Onboarding new Customers and Providers
Customers and Service Providers can join and leave the SIAM ecosystem at a rapid pace. The compliant service management system will not be a bottleneck to onboarding (and offboarding). It must be an agile system where a new customer or provider can be onboarded in minutes, without technical integration. The cost and effort of connecting a provider should never be the reason to stay with a provider that does not perform. It should never slow down the introduction of new services either, when the business needs them. Even a small provider should be able to cost-effectively integrate into an enterprise’s ecosystem.
Service Management Toolboxes Are Not SIAM-Compliant
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, known as toolboxes. They claim to be SIAM compliant because organizations can build these capabilities. Such a development initiative would exceed the competence of all but the most experienced tool experts. The time and money to commission a system to support effective service integration is enormous and the risk of failure high. It is important to remember that service management systems do not support dynamic data segregation, so an investment is needed to become SIAM-compliant.
Validation by Proof of Concept
It is easy to test if a service management system is SIAM compliant. Ask for a test system with 2 external service providers, and check if the system can deal with the earlier scenario. Check if the data and processes are kept segregated. Then add another service provider. This should not take more than a few hours to check the scenario again. Then verify the dashboards and reports from the business and service provider perspective are consistent and the vendor’s claim that its software is SIAM compliant is validated.
About the Author
Wouter Wyns has worked in the service management industry for companies like Siemens, Fujitsu, Atos and InfraVision where he assisted large enterprises with their implementations of HP Service Manager, ServiceNow and 4me.
