Common sense or best practice?

Our latest blog is by guest author Michelle Major-Goldsmith.  A member of the SIAM Foundation Working Group, Michelle offers a pragmatic look at SIAM and best practice in general.econsultant-headshot-michelle-major-goldsmith-new

Michelle is a member of Scopism’s team of eConsultants – view Michelle’s profile to learn more.

“Common sense is genius dressed in its working clothes”

Scopism recently launched the much anticipated Service Integration and Management (SIAM®) Foundation Body of Knowledge, with the associated SIAM® Foundation course and certification from EXIN and BCS to follow on March 1st 2017.

With the free download, an additional document was supplied – Service Integration and Management (SIAM®) Foundation Process Guides, a great addition to what is essentially well conceived, comprehensive and free knowledge. That lead me to think that perhaps now would be a good time to administer a cautionary tale about using best practice frameworks, and methodologies correctly.

I love best practice, I love process and I am a fan of anything to do with the plethora of disciplines, frameworks, standards, approaches, ethos and methodologies available to IT and service management practitioners today. Like most practitioners what I don’t love is when I see, too often, that use is made of these practices and methods without reason or consideration of context and circumstance.

I see continued examples of failure to adopt and adapt and instances of assumption that codification and cataloguing of the practices of high performing or long established approaches will lead to similar success when applied in all environments and under any circumstance.

First, more about SIAM

SIAM is, at first, a seemingly obvious adaption of the ITIL® best practice framework that seeks to provide the key to the effective management of the multi-provider model in existence in most modern enterprises. It differs from traditional multi-sourced ecosystems with one customer and multiple suppliers, because it adds a service integration layer. This layer provides governance and coordination to ensure the customer organisation gets maximum value from their service providers.

Additionally, SIAM includes functional and structural elements. These differentiate it from other methodologies and frameworks used for IT management which mainly focus on providing guidance, largely in the form of processes (activities) to allow an organisation to identify, plan, deliver and support IT services.

A function is an organizational entity, typically characterized by a specific area of knowledge or experience. Examples of functions within a SIAM environment are a knowledge management forum or an integrated Change Advisory Board. Functions are made up of a team or group of people with specific expertise, working toward a common goal. The functional elements of SIAM include the introduction of more formalized and specific organizational and team structures. This structural description facilitates the definition of teams and their responsibilities, more so than other enabling frameworks.

But back to the processes, everyone loves those…
…and why not! Good processes, correctly applied can bring a host of benefits.

A process is “a documented, repeatable approach to carrying out a series of tasks or activities”

Most business activities involve repeated tasks; for example, a chef following a recipe to make a meal, a service desk agent taking a phone call from a customer or an accounts clerk raising an invoice.

Documenting a process for a repeated task has several benefits:

Where SIAM differs from much of the best practice guidance available is that, although it talks about necessary processes, it doesn’t mandate process activities.  Instead, it focuses on the process outcomes. The SIAM model seeks to empower providers, not restrict them with defined processes. It achieves this through the effective control and governance of the process interfaces, setting quality criteria and ensuring ongoing compliance to said criteria across provider groups. For the provider, this establishes a mandate that allows them to do the job they are obliged to do, without a detailed, procedural specification of how to do this.

SIAM and processes

Looking after the success of these processes is a SIAM role. Within a SIAM environment, the service integrator manages a governance framework. This includes defining and reviewing policies and processes (with customer agreement), setting agendas, ensuring quorums are met and ensuring quality and audit trails throughout. Operationally, SIAM governance performs an audit function (evidence of action and not just intent) and also provides a quality oversight across the providers.

The key point is that processes are of course a key pillar in SIAM, that withstanding the SIAM approach very much recognises that one size certainly does not fit all! It would be a nonsense to engage with different providers for specialised services to enable a business to secure best-in-class capabilities, systems and services and then force them to follow a strict process or indeed a defined methodology, framework or practice. It is incumbent upon the service integration layer in a SIAM model to create a delivery structure that supports process inputs and outputs, lays down governance, standards and controls but does not stifle the individual procedural activities that will be proprietary to each service provider in the model.

Back to that SIAM Body of Knowledge

Within the Foundation BoK, it was a very deliberate action to create the process guides as a separate document to the core BoK. It was furthermore deliberate not to outline detailed process activities ‘per se’, rather to define process intent as well as some specific application guidance to support implementation and management of processes within a SIAM environment.

So, each party in a SIAM ecosystem (customer, service integrator, service providers) should adapt and augment their own processes to integrate with the relevant process models, as part of the overall SIAM model.

The detail of the process models, and the allocation of activities to the different layers in the SIAM structure, will vary for each implementation of SIAM.

Some processes will span multiple layers. For example: the customer organization and the service integrator can both carry out elements of supplier management; the service integrator and service providers will each have responsibilities in the end to end change management process. Since each SIAM model is different, it is important to ensure that the roles and responsibilities, interface and dependencies of the customer, service integrator and service providers are mapped, clearly defined, and clearly understood.

Each service provider might carry out individual process steps in a different way, but as part of an overall integrated process model. Process models are therefore important SIAM artefacts; local processes and work instructions are likely to remain within the domain of the individual organization who performs the activities.

‘Why?’ not ‘What’!

The key point here is that when using processes to guide outcomes, ones should never blindly follow the ‘how’ (of a pre-defined process flow) without understanding the ‘what’ (what does the outcome need to be)?

Traditional methods of process creation focus on waterfall processes. They tend to be sequential, with progress flowing steadily downwards (like a waterfall) without any real consideration of complexity and multiple stakeholders.

In the SIAM BoK the guidance extends from the usual process definitions, to actually provide guidance on how to allow providers to handle their own processes and tools, as long as the delivery of the ‘what’ or the outcome is aligned to the needs of the customer.

Most management approaches expect processes to be executed within one organization. Within a SIAM ecosystem, processes are likely to be executed:

Within the BoK Process Guides, there is less information about process activities and much more about real life application; consideration of how to get people working well together by considering the inherent process complexities such as ownership, supporting toolset and data considerations, IP challenges, making improvements, compliance and assurance.

“Common sense is genius dressed in its working clothes” (Ralph Waldo Emerson)

Why is this important for best practice frameworks, standards, methodologies, principles and ideologies? Well, it seems common sense is NOT common practice! There are likely to be difficulties in implementation success with any approach and so it’s important to understand that that one size does not fit all. As the number of structures and parties involved in service delivery increases, so does the requirement for collaboration and cohesion.

The SIAM Foundation BoK and the Process Guides are valuable tools for anyone involved in a multi-provider model. Information on relevant processes is featured, but more relevant guidance on the challenges of managing process flows across multiple providers is included.

Using any best practice guidance correctly takes some more in-depth consideration than reading and copying a process flow. It requires the implementer to consider any necessary changes in attitude, behaviour and culture, processes and procedures, capabilities, organizational structures, resources, knowledge, tools and contracts.

The SIAM BoK as a source of ‘Best Practice’ is ‘common sense written down’. Let’s hope that common sense becomes common practice through thoughtful application!

Service Integration and Management (SIAM®) Foundation Body of Knowledge
Service Integration and Management (SIAM®) Foundation Process Guides
Who is the King of SIAM? Simon Dorst, Michelle Major-Goldsmith, Steve Robinson

Download your free copy of the SIAM Foundation BoK and Process Guides today.