This guest blog comes from Service-Flow’s Juha Berghäll. Juha looks at toolset considerations in a SIAM environment, and offers some pointers for successful service integration.
Service Integration and Management (SIAM), has held ITSM professional’s attention for some years now and it is beginning to establish itself with the publication of the SIAM Foundation Body of Knowledge and the introduction of a global SIAM training scheme. Yet, it seems that there are as many explanations of SIAM as there are explainers.
In this blog, I’m not going to try to explain what SIAM means and how it should be implemented. Instead, I will revisit the good old holy trinity – people, process and tools – from the Service Desk’s point of view in the context of operating in SIAM model or multi-sourcing in general. Many of these points can be adapted to both service buyer organisation and to service provider or supplier. The biggest difference is that when you are operating with multiple parties, there will be a multiple number of “people-processes-tools” implementations.
Let’s start with a SIAM framework design.
Service Integration Framework. Copyright Tata Consulting Services.
Many of these frameworks are very well defined on a high level. However, for Service Desk operations, the interesting part is those small arrows going “out” from the framework.
They are quite often neglected by just saying “…then you need to integrate”. Yet, reliable connections compose the foundation for a modern multi-provider/SIAM set-up and Service Desk operation with digitalized end-to-end ICT service processes.
So, how do people, process, and tools and SIAM sing-along?
People
With or without SIAM, you will still need people. At the end of the day, it is the people who run the processes and interact with end-users. By making the right choices you can reduce dull and repetitive tasks in your Service Desk function and save a lot of time and money. For the “people layer”, the goal should be ticket flow automation and better real-time information for Service Desk operators. Questions like “where’s my ticket?” or “what’s the status of my ticket” should never ever be asked again.
Process
You need to define your operational model for ICT. Based on your processes, you need to define use cases which are the definition of how you want to collaborate with external parties. For instance, a use case could be: “incident is opened in customer’s ITSM tool, escalated to a service provider and resolved in service provider’s tool”.
Use case example
Bear in mind that you should own the vision of running your ICT operations. Present the use cases, not processes, to your service providers and ask them to adapt. Use cases define the conditions for interactions and it is essential that all parties in a service supply chain understand the critical touch points of their processes and their role in the use cases.
Neither party should be pushing their whole process model outside their organisation. It won’t work, since all implementations (process+tools) are uniquely designed for internal use only; they serve organisation’s internal business objectives and can seldom be adapted to external party’s objectives. Remember also to bring ITSM tool and process owners around the same table in order to draw out understandable use cases and to ensure that they follow the workflow in the ITSM tool on both sides.
Tools
You will need the right toolset; in my opinion, now more than ever. The ITSM tool is your control tower (you can compare it to Air Traffic Control) and it has to be implemented so that it runs YOUR processes.
Many of your suppliers and your clients (if you’re a supplier) suggest or demand that you should use their ITSM tool, but don’t go down that road without careful consideration. You will lose control and transparency, and along the way, you will lose control. Losing control over the data and flexibility means that you will give up control of developing YOUR processes (and Tools) independently.
Bear in mind that the modern utilization of an ITSM tool can be done so that you don’t have to actually participate in running support processes in your ITSM tool; but you will get access to all data through real-time process integrations with your service providers. That approach enables you to keep your ITSM tool, your language, attribute namings etc. Keeping your own language makes your end-user support, SLA reporting etc. so much easier and smoother.
The thing is, that you cannot outsource responsibility, and that’s why you need to have control over outsourced services and transparency on them – you have to own the data. Your ITSM tool is your control point and assurance that you’re getting the service you’ve agreed upon.
People x Process x Tools x Integration. Impossible equation?
Service integration means that you will need those difficult integrations. You need to integrate your ITSM tools and processes with external parties. However, you and they have designed tools and processes for “internal use” only. And that is the root cause why these integrations fail. The other reason is that traditionally integrations are build as distributed model where everyone should customize and develop integration logic in their end. Integrating people, process and tools in a multi-sourced environment means a different language, different meanings, complex mappings, and even though it might sound complicated, that’s the way it should be.
If that’s the case, how to succeed? Well, thesame rules apply than in ITSM tool implementation: it should be iterative. And who has developed an ITSM tool from scratch by coding lately? That said process and tooling tracks should be run simultaneously. The thing is, that you should be able to start by defining use cases with people, not setting up technology.
An example of digitalized workflows using the Service-Flow solution. Centralized integration management and ecosystem.
You should be able to create integrations with iterative methods in order to fail fast and gain fast results; and be able bring in multiple service providers simultaneously. You should aim to continuous improvement; you should continuously evaluate your working methods (use cases) with you service providers and customers and fine tune your processes and tools accordingly.
The end result should be a set-up where you can keep your own ITSM tool and develop your people, processes and tools independently, no matter if you’re a service buyer organisation or a service provider. It is your business, your support processes and your people making it happen.
About Service-Flow:
Service-Flow Corp. is a software service provider specialized in developing and producing the world’s first SaaS solution for service integration. The Service-Flow all-inclusive solution enables outsourcing service buyers and service providers to integrate ITSM tools and digitalize service processes just by subscribing to Service-Flow SaaS. Service-Flow offices are located in Helsinki and in London. Certified partners are supporting the clients to use Service-Flow solution worldwide.
About the author:
Juha Berghäll is a visionary business leader and an experienced speaker and performer. He has a wide experience in ITSM domain from software development to consulting, software/solution sales & marketing. He has excellent track record of building and leading winning teams. Juha’s personal goal is to help business leaders see Information Technology as an organic and critical part of their businesses, not jut hard-to-understand-expensive-techie-driven-cost-center.
Juha.berghall@service-flow.com
Tel. +358405895121
Twitter: @jberghall
