In my last IT service management (ITSM) industry blog, I looked at how to control your ITSM and other IT management tools in a service integration and management (SIAM) environment. In this blog, I look at how to develop a SIAM process model, i.e. how best to work in a multi-vendor operating model.
What’s a process?
A dictionary definition will say something like:
“A series of actions or steps taken in order to achieve a particular end.”
So, let’s start with the basic concept that organizations use processes to produce outputs.
For ease, over the years, in ITSM we’ve developed a common language and some best practice process models, and these are encapsulated within ITIL, PRINCE, and the whole wealth of other ITSM frameworks and process models available to us. I’m not here to debate the benefits of any particular framework over another, but merely to establish that IT organizations use processes to get work done.
The power of processes
When done well, processes enable us to work consistently, to defined quality standards, and deliver outputs with a predictable level of efficiency and quality.
And having established that IT organizations use processes, if we add SIAM to the mix, things get a lot more complicated. With the problem with multi-vendor operating models being that each organization involved in a SIAM eco-system will have their own process standards and frameworks. And each one will have been refined over many years, and will take account of any unique organizational requirements, constraints, tools, and ways of working.
Which processes are in the scope of a SIAM operating model?
It’s easy to get fixated on the primary processes of incident, problem, and change management. These are important, but we must broaden our line of vision to include all the ITSM processes described in ITIL (or the practices in ITIL 4). If we don’t do this, processes will not be optimized to work in a SIAM operating model, and will not take account of the multitude of potential organizations involved in its implementation.
In addition, we should be thinking about the processes that will be impacted by the introduction of a multi-vendor operating model, such as the project lifecycle – right from the idea stage, through demand management, into project delivery and the Project Management Office. (I’ve written a paper describing “Why you Need a Single PMO in your SIAM model”, which you can read here.)
The wider process impact of SIAM
But it’s not just ITSM and project management processes that will be impacted by the SIAM operating model. You should also consider contract and commercial management, supplier management, and the overarching process governance model, as all of these will be impacted by the introduction of a SIAM operating model.
Then, in a SIAM model where we bring organizations together and each with their own processes, the service providers will likely want to preserve their process models with very little changes. Mainly because one of their main drivers will be the ability to operate processes which are consistent from one customer to another. This facilitates their economies of scale, consistency, and – critically for the service providers – the ability to move their staff between the customers without having to retrain them.
So, how do you integrate all of these processes into a single, coherent process model?
In my experience, following the three steps below will contribute to the definition of a clear and coherent process model.
Agree the process scope
Agree collectively which processes will be in scope, using my guidance above. You might also want to reference the excellent SIAM Body of Knowledge, available in print or as a download.
Define the IT operating model
This involves determining who will be involved in performing the processes in the future. Key questions to ask in this context are:
- Who will perform the service integrator role? Will it be done in-house, or by an external provider?
- Who are the other players in the SIAM model? Which other service providers will be involved?
- What existing process standards and documentation exists across the various stakeholders?
Define the Process Model
The process model will describe the various steps in each process, identify the stakeholders, and the responsibilities for performing process tasks. In order to define a process model, we need to start with some high-level process planning. Imagine a graphic equalizer from the 1970’s hi-fi era. At the bottom end of the audio range are the service providers, in the middle the service integrator, and at the top the retained customer organization. Imagine that each channel in the graphic equalizer is a process. The adjuster is a “slider” which moves up and down. It’s not a switch that is “on or off”. This is analogous to my approach to defining the SIAM process model in many ways:
- Processes contain many actors. You cannot say that a process is wholly performed by one supplier or another. But you can indicate where the majority of the tasks are performed using the “slider” approach (i.e. the customer, the service integrator, or the service providers).
- The “tuning” of the graphic equalizer is not prescriptive. Just as what sounds good to you will not sound good to a friend or relative, the position of the sliders in our SIAM process model will vary from one organization to another.
- Using something “graphical” to define the process ownership, at a very high-level like this, will drive out any major issues at a very early stage.
Having defined the high-level process design principles, you can get to work on defining the detailed process model.
What’s in a process model?
The process model describes who-does-what once your SIAM operating model is live. You could consider it as the process run-book.
The development of the process model will give the service providers, the service integrator, and the customer the opportunity to bring their best practice process models to the table, and enable the collaborative development of a future state model.
One critical word of warning here: if there’s an existing model which would appear to produce the required outputs and meets with general approval, use it. Don’t re-invent the wheel just for the sake of your SIAM model, or you’ll never succeed!
In my experience, a good process model comprises:
- A cross-functional “swim lane” process flow and supporting documentation. The process flow should contain numbered process boxes, which can be referenced in supporting documentation that not only describes the process step, but also how it’s performed, what collateral is performed, and what guidance might be available.
- A RACI (responsible, accountable, consulted, informed) chart. Yes, I know some of you will groan at this suggestion. However, I firmly believe in the power of a good RACI chart which describes the process tasks and clearly defines responsibilities and involvement from all parties. However, many organizations fail to realize the key value of one of these documents. Always, always, always develop the RACI chart collaboratively with all parties involved. Often, the act of debating the RACI chart content will drive out inconsistencies and issues, and is more valuable than the resulting document!
- Example templates and guidance. This will ensure consistency of the outputs produced, and enable outputs to be measured against a quality baseline.
Processes are critical to the smooth running of your IT organization. Don’t cross your fingers and hope that it’ll all just come together. The customer must take the initiative and bring the service providers, service integrator, and customer stakeholders together to develop a process model that works for everyone. And remember, the act of developing the content can be more valuable in terms of driving out any issues, than the value of the final set of deliverables!
Plus, prior to go-live of a SIAM operating model the process models can be used as the basis for desktop-based testing. This should be seen as a critical step in ensuring that the SIAM operating model goes live without a hitch.
Do you want to read about the software request process?