CHAPTER 2: SIAM ROADMAP

This roadmap outlines an example plan for the implementation of SIAM as part of an organization’s operating model.

Using a roadmap for the implementation has several benefits, including:

•Defining the SIAM requirements

•Providing a planning framework

•Determining the most appropriate SIAM structure and SIAM model

•Guiding the implementation

•Directing ongoing continual improvement

There are four stages in the SIAM roadmap:

1.Discovery & Strategy

2.Plan & Build

3.Implement

4.Run & Improve

For each stage, this section provides examples of:

1.Objectives

2.Triggers

3.Inputs

4.Activities

5.Outputs

While the activities are presented here in a sequential manner, many are likely to be iterative or may even be undertaken in parallel.

High-level requirements are defined in the first stage. These are then further developed in the second stage, before being implemented in the third stage. The fourth stage is where the SIAM model is operated and continually improved.

In many cases, the roadmap will be executed iteratively, with a checkpoint at the end of each stage. The checkpoint should review areas including:

•The actual outputs from the stage against those intended

•Risks

•Issues

•Plan for the next stage

This information should be used to validate decisions taken earlier in the roadmap. It might highlight potential issues, requiring a return to an earlier stage for further work.

Many organizations use outside assistance during the execution of their SIAM roadmap. This can be helpful during the transition to SIAM, but the customer organization needs to ensure that the model being used by the external organization is suitable for its needs.

If outside help is required, it is a good idea to have a commercial boundary between an organization that is assisting with the Discovery & Strategy and Plan & Build stages, and any external service integrator.

2.1 Discovery & Strategy

2.1.1 Objectives

The Discovery & Strategy stage initiates the SIAM transformation project, formulates key strategies, and maps the current situation. This enables the customer organization to:

•Determine what it intends to source internally

•Consider any additional skills and resources that may be required

•Determine what it would like to source externally

•Understand the expected benefits

The objectives for this stage are to:

•Establish the SIAM transition project

•Establish a governance framework

•Define the strategy and outline model for SIAM and the services in scope

•Analyze the current state of the organization, including skills, services, service providers, tools and processes

•Analyze the marketplace for potential service providers and service integrators

2.1.2 Triggers

There are many reasons organizations should consider adopting a SIAM model. These drivers are described in section 1.5.2.

2.1.3 Inputs

Inputs to this stage include:

•Enterprise, corporate and IT governance standards

•Current business, procurement and IT strategies

•Business requirements and constraints

•Current organization structure, processes, products and practices

•Existing service provider information, including existing contracts and agreements

•Understanding of market forces and technology trends

2.1.4 Activities

The activities in this stage are:

1.Establish the project

2.Define strategic objectives

3.Define governance requirements and the high-level governance framework

4.Define principles and policies for roles and responsibilities

5.Map the existing services and sourcing environment

6.Assess the organization’s current maturity and capability

7.Understand the marketplace

8.Define the strategy for SIAM and the outline SIAM model

9.Produce the outline business case

2.1.4.1 Activity: Establish the project

The SIAM transformation project should be formally established using the organization’s selected project management methodology.

This includes:

•Setting up a project management office

•Defining roles and responsibilities for the project

•Setting up project governance

•Agreeing the approach for managing project risks

The organization will also choose whether to adopt a waterfall or Agile project delivery approach.

2.1.4.2 Activity: Define strategic objectives

Strategic objectives are the long-term goals of the organization that SIAM is intended to support.

They are related to the drivers for SIAM and the SIAM business case. The objectives defined and agreed in this activity will be used as a basis for items including the:

•SIAM model

•SIAM governance framework

•Sourcing model

•Roles and responsibilities

2.1.4.3 Activity: Define governance requirements and the high-level governance framework

SIAM requires a specific governance framework that allows the customer organization to exercise and maintain authority over the SIAM ecosystem.

The model should be tailored to the specific SIAM structures, the SIAM model, and the customer organization’s overall appetite for risk.

At this stage, the SIAM governance framework will be defined at a high level. It should include:

•Specific corporate governance requirements that support any external regulations and legal requirements

•Controls to be retained and operated by the customer organization

•A definition of governance boards and governance board structures

•Segregation of duties between the customer organization and external organizations

•The risk management approach

•The performance management approach

•The contract management approach

•The dispute management approach

2.1.4.4 Activity: Define principles and policies for roles and responsibilities

In this activity, the key principles and policies for roles and responsibilities are created. They will take into account the governance requirements and strategic objectives.

The specific, detailed roles and responsibilities will not be defined or assigned until more detailed process models and sourcing agreements have been designed within the Plan & Build stage.

Two aspects should be considered here:

•Segregation of duties if one organization is operating in more than one SIAM layer

•Boundaries of delegated authority

2.1.4.5 Activity: Map the existing services and sourcing environment

Before a SIAM model can be designed, the current environment must be understood. This includes:

•Existing services and the service hierarchy

•Existing service providers (internal and external)

•Contracts

•Service provider performance

•Relationships with service providers

•Cost of services

The creation of the service hierarchy is a critical activity to support the design of the desired future state. The hierarchy enables the identification of essential business functions, critical service assets and dependencies across the ecosystem.

This activity will provide clarity on the current environment. It can also help to highlight issues including:

•Duplications in service offerings

•Misaligned contractual commitments

•Unused operational services

•Uneconomic services

•Service risks that require mitigation

Information about service providers can be used to decide whether they are to be retained in the current format, or whether their services should be sourced under new arrangements.

2.1.4.6 Activity: Assess the organization’s current maturity and capability

A baselining exercise should be carried out to understand the customer organization’s current capability and maturity in organization, processes, practices and tools. This will inform the next stage of the roadmap.

This exercise can also identify any issues that require a review of earlier decisions. For example, where there is insufficient capability to run the project management office, or insufficient maturity of the incident management process.

2.1.4.7 Activity: Understand the marketplace

It is important at this stage to understand the existence and capabilities of potential external service integrators and service providers. This will inform the strategy for SIAM and the SIAM model.

This activity should include a review of available technologies and services against the strategic objectives.

For example, a move to cloud services can support a strategic objective for reduced cost of ownership.

The service providers of commodity cloud services are unlikely to take part in the SIAM model’s boards, process forums and working groups. This could reduce the workload of the service integrator, to a level where an internally sourced service integrator may offer better value than an externally sourced service integrator.

2.1.4.8 Activity: Define the strategy for SIAM and the outline SIAM model

This activity will take the information and outputs from previous activities in this stage to define the strategy for SIAM, and an outline SIAM model.

These should include:

Strategy for SIAM:

•The vision for SIAM

•Strategic objectives

•Current maturity and capability

•Existing services and sourcing environment

•Marketplace analysis

•Governance requirements

•Proposed SIAM structure, including retained capabilities

•Proposed sourcing approach

•Justification for proposals

Outline SIAM model

•Principles and policies

•Governance framework

•Outline roles and responsibilities

•Outline of process models, practices and structural elements

•Outline of services

•Service providers to be retired

The strategy for SIAM and the chosen SIAM model both need to align with the original business requirements and the business strategy.

2.1.4.9 Activity: Produce the outline business case

This activity will take the information and outputs from all previous activities in this stage to produce an outline business case for SIAM.

This should include:

•Strategy for SIAM

•Outline SIAM model

•Current state

•Expected benefits from SIAM

•Risks

•Outline costs of the transition to SIAM

•High-level plan

The outline business case should be approved in accordance with the customer organization’s governance arrangements before the next roadmap stage begins.

2.1.5 Outputs

The outputs from the Discovery & Strategy stage are:

•An established SIAM transition project;

•Strategic objectives

•Governance requirements and a high-level SIAM governance framework

•Defined principles and policies for roles and responsibilities

•A map of existing services and the sourcing environment

•Current maturity and capability levels

•Market awareness

•An approved outline business case for SIAM

•A strategy for SIAM

•An outline SIAM model

2.2 Plan & Build

2.2.1 Objectives

The Plan & Build stage builds on the outputs from the Discovery & Strategy stage to complete the design for SIAM and create the plans for the transformation.

During this stage, all plans and approvals are put in place before the Implement stage begins. The main objectives for this stage are to:

•Complete the design of the SIAM model, including the services that are in scope

•Obtain full approval for the SIAM model

•Appoint the service integrator and service providers

•Commence organizational change management

2.2.2 Triggers

This stage is triggered on completion of the Discovery & Strategy stage, when the organization confirms its intention to proceed with a SIAM implementation.

2.2.3 Inputs

The inputs to this stage are the outline business case, and the high-level model and frameworks created during the Discovery & Strategy stage:

•Governance requirements and high-level SIAM governance framework

•Defined principles and policies for roles and responsibilities

•Map of existing services and sourcing environment

•Current maturity and capability levels

•Market awareness

•Approved outline business case for SIAM

•Strategy for SIAM

•Outline SIAM model

In this stage, work will be carried out to further define, refine and add detail to the outputs from the previous stage. Some organizations may choose to use an Agile approach for this.

2.2.4 Activities

The activities during this stage are:

1.Design the detailed SIAM model

2.Approve the full business case

3.Commence organizational change management

4.Appoint the service integrator

5.Appoint service providers

6.Plan for service provider and service retirement

7.Review stage and approve implementation

2.2.4.1 Activity: Design the detailed SIAM model

The SIAM model provides the detail for how SIAM will be applied across all parties in the SIAM ecosystem. It contains many elements, including:

1.Service model and sourcing approach

2.The selected SIAM structure

3.Process models

4.Governance model

5.Detailed roles and responsibilities

6.Performance management and reporting framework

7.Collaboration model

8.Tooling strategy

9.Ongoing improvement framework

Careful design of this model is critical to success. The design activities will not necessarily be sequential. There is more likely to be an iterative cycle, which starts with an initial definition, and becomes successively more detailed as each iteration is agreed.

There must be regular review and feedback across all the design activities. Agile approaches can be particularly useful for this. Consideration must also be given to interdependencies between the different design activities.

Organizations will determine the level of detail they require for their own SIAM model. This will depend on several factors, including:

•Strategic objectives

•Market conditions

•Services and service complexity

•Number of service providers

•Appetite for risk

•Resource and process capability and maturity

•Available tools

•Budget

2.2.4.1.1 Define service model and sourcing approach

This activity defines the services in scope for the SIAM model, the service hierarchy, and how the services are grouped for sourcing. Creating the service model is a critical activity for an effective transition to SIAM.

These areas must be clearly defined for each service:

•The service provider(s)

•The service consumer(s)

•The service characteristics, including service levels

•The service boundaries

•Dependencies with other services

•Technical interactions with other services

•Data and information interactions with other services

•Service outcomes, value and objectives

Services should be placed into groups, with groups assigned to specific service providers. The service model shows the hierarchy of the proposed services, and the service provider for each service. This forms part of the overall SIAM model.

The model should also include the expected process interactions between the services and service providers. Enabling practices like OBASHI¹³ can support this by mapping data flows between service providers.

The service model will help to identify omissions, single points of failure, and duplication.

The aim should be to achieve a balance between getting ‘best of breed’ services, the number of services and service providers, and the complexity of the service model and hierarchy. There also needs to be a balance between service complexity and integration complexity. Services should be designed to minimize interactions with other services, as these interactions drive complexity, risk, and cost.

Care should be taken when defining the services and assigning them to service providers. The number of contact points and interactions, and therefore opportunities for failure, will increase as the number of services and service providers increase.

Sourcing approach for services

The ability to source services in groups is one of the benefits of SIAM. Rather than having a single, monolithic contract with one service provider delivering everything, the full range of services can be broken down into the most efficient and best-value groupings. Each group is then individually sourced, externally or internally.

Common examples of service groups include:

•Hosting

•Application development and support

•Desktop support/end-user computing

•Networks

•Cloud services

•Managed services

Each group can be provided by one or more service providers. For example, a ‘hosting’ group could include Platform as a Service (PaaS) and Infrastructure as a Service (IaaS), sourced from one or multiple service providers.

The design of service groups should try to minimize any technical dependencies between services. Dependencies create interactions between service providers and potential points of failure, and can increase the workload of the service integrator.

There is no requirement within the SIAM management methodology to separate services that logically stay together. For example, there is no need to divide a SaaS offering into ‘hosting’ and ‘application development and support’ if it is more logical to source it as one group.

Unnecessary separation can cause issues, such as disputes about who is responsible for performance problems. This particularly applies to managed services, legacy services, cloud services and DevOps services.

There is no limit to the number of different groups within a SIAM model. However, integration complexity will increase as the number of service groups increases.

2.2.4.1.2 Select the SIAM structure

The selected SIAM structure determines the sourcing approach for the service integrator. This is a crucial decision that must be taken with care, as any changes to the structure after this point will result in rework and cost.

All the information gathered so far should be used to select the preferred SIAM structure. If this is different from the proposal created during the Discovery & Strategy stage, it may be necessary to repeat parts of that stage.

See section 3 for more information on the advantages and disadvantages of each structure.

2.2.4.1.3 Design process models

In a SIAM model, the execution of most processes will involve multiple service providers. Each service provider might carry out individual steps in a different way, but as part of an overall integrated process model.

Process models are therefore important SIAM artefacts; the individual processes and work instructions are likely to remain within the domain of the individual service providers.

The process model for each process should describe:

•Purpose and outcomes

•High-level activities

•Inputs, outputs, interactions and dependencies with other processes

•Inputs, outputs and interactions between the different parties (for example, between the service providers and the service integrator)

•Controls

•Measures

•Supporting policies and templates

Techniques such as swim lane models, RACI matrices, and process mapping are commonly used, and are helpful for establishing and communicating process models.

The process models will continue to evolve and improve as further activities are undertaken in this stage, and in the Run & Improve stage. This includes getting input from the selected service providers and service integrator.

2.2.4.1.4 Design governance model

The governance model should be designed using the governance framework and the roles and responsibilities. For each governance body, this model should include:

•Scope

•Accountabilities

•Responsibilities

•Meeting formats

•Meeting frequencies

•Inputs

•Outputs (including reports)

•Hierarchy

•Terms of reference

•Related policies

The governance framework should also be updated and more detail added. This is an iterative activity that should be completed before the end of this roadmap stage.

2.2.4.1.5 Design roles and responsibilities

Roles and responsibilities should be designed using the outline SIAM model and outline process models, the SIAM structure and the governance framework.

This should include the detailed design and allocation of roles and responsibilities to:

•Process models

•Practices

•Governance boards

•Process forums

•Working groups

•Organizational structures and locations for any retained capabilities

This work may highlight a need to review earlier designs and decisions.

Roles and responsibilities can be further developed in the Run & Improve stage, but the detail must be confirmed in this stage before any service integrator or service providers can be appointed.

2.2.4.1.6 Design performance management and reporting framework

The performance management and reporting framework for SIAM addresses measuring and reporting on a range of items including:

•Key performance indicators

•Performance of processes and process models

•Achievement of service level targets

•System and service performance

•Adherence to contractual and non-contractual responsibilities

•Collaboration

•Customer satisfaction

Measurements should be taken for each service provider and its services, but also across the end-to-end SIAM ecosystem.

Designing an appropriate performance management and reporting framework for a SIAM ecosystem can be challenging. It is usually straightforward to measure the performance of an individual service provider; the challenge is in measuring end-to-end performance as experienced by the users, particularly when there may be limited consistency in how each of the providers measure and report.

The framework should also include the standards for:

•Data classification

•Reporting formats and frequency

2.2.4.1.7 Design collaboration model

SIAM can only be effective when service providers, the service integrator and the customer can communicate and collaborate with each other.

Section 7 has some examples of how to encourage collaboration in SIAM ecosystems.

2.2.4.1.8 Define tooling strategy

A consistent and comprehensive tooling strategy is important within a SIAM ecosystem. The tooling strategy is influenced by:

•The selected SIAM structure

•The SIAM model

•Existing customer toolsets

•Service provider and service integrator toolsets

•Types of service provider

•Budget

The tooling strategy should focus on supporting the flow of data and information and process integration efficiently:

•Between the service providers

•Between service providers and the service integrator

•Between the service integrator and the customer

This is more important than focusing on technology alone.

Many organizations use more than one toolset in their SIAM ecosystem, selecting a range of ‘best of breed’ toolsets for:

•Supporting service management processes

•Data analysis

•Reporting and presentation

•Event monitoring

•Audit logging

There are four main options for toolsets:

1.A single toolset is used by all parties, mandated by the customer

2.The service providers use their own toolsets and integrate them with the service integrator’s toolset

3.The service providers use their own toolsets and the service integrator integrates them with its own toolset

4.An integration service is used to incorporate the toolsets of the service providers and the service integrator

The tooling strategy should include:

•Enterprise architecture

•Functional and non-functional requirements

•Integration requirements (technical and logical)

•Data mapping for each SIAM layer

•Data ownership

•Access control

•Measurement and reporting

2.2.4.1.9 Design ongoing improvement framework

An improvement framework needs to be developed and maintained in conjunction with all parties within the SIAM model. This will ensure a focus on continual improvement across the SIAM ecosystem.

Service providers should have incentives that encourage them to suggest and deliver improvements and innovation.

2.2.4.2 Activity: Approve full business case

At this point, the design should be detailed and complete enough to enable the full costs of the SIAM transition and the anticipated benefits to be determined.

The outline business case should be reviewed and updated with detailed information to create a full business case.

This should then be approved using the organization’s corporate governance and approvals process. The approval allows the start of procurement activities for any external service providers, service integrator, and tools.

2.2.4.3 Activity: Commence organizational change management

A SIAM transformation is a major business change, affecting the customer organization, service integrator and service providers at every level.

Organizational change management will be essential if the transformation is to succeed.

During any organizational change, it is important to protect the existing service and minimize the impact on the existing organization.

2.2.4.4 Activity: Appoint the service integrator

Ideally, the service integrator should be selected and in place before the SIAM model is finalized and before any service providers are selected.

If this can be achieved, the service integrator can be involved with the Plan & Build activities. The benefits of this approach are:

•The service integrator is involved with the design and selection of service providers, so it can use its experience to assist with these activities

•The service integrator is fully aware of the requirements placed on the service providers during selection and appointment

The selection process and contractual agreement for an external service integrator may take some time. On occasion, the customer might source the service integrator and the service providers simultaneously.

Alternatively, the service providers might already be in place or undergoing transition from legacy contracts before the service integrator role is confirmed.

2.2.4.5 Activity: Appoint service providers

Service providers cannot be selected until this point, as it will not be possible to fully document the requirements until the SIAM model has been fully defined.

The contracts in place in a SIAM model need to support the overall strategy for SIAM. It is important to ensure that they include appropriate targets and risk and reward models. Detailed requirements should be included in any contracts or internal agreements.

The challenge is to balance the customer’s desire for specific requirements against what is offered in the marketplace. Forcing service providers to customize their delivery models can result in increased costs and risks.

The procurement of external service providers can take some time, which needs to be included in any plan or timeline.

It is important to verify that the desired service providers can meet the full set of requirements in the SIAM model, particularly for strategic service providers. If there are issues or gaps, this may require a return to earlier lifecycle stages and activities.

In addition to the service providers that are appointed here, it is important to remember that service providers can be added and removed throughout the SIAM roadmap. Some service providers may not be appointed until after a legacy contract has expired.

2.2.4.6 Activity: Plan for service provider and service retirement

Planning also needs to address retiring services, and any resulting transfer of services to new service providers.

The relationships with any service providers, service dependencies, contract end dates and potential impact of retiring a particular service or service provider must be carefully considered.

Detailed plans should be developed for any decommissioning, discontinuation, and transfer of services. The plans need to include contractual restrictions, legal requirements, and lead times for service termination.

They must also detail how data, information, and knowledge will be transferred from retiring service providers, including:

•What needs to be transferred

•To whom it will be transferred

•When it needs to be transferred

•How to assess if the transfer is successful

2.2.4.7 Activity: Review stage and approve implementation

The outputs from this stage should be reviewed against decisions taken in the previous stage, to identify if there are any issues or necessary changes. The roadmap will then progress to the Implement stage if approval is given.

2.2.5 Outputs

The outputs from the Plan & Build stage are:

•Full design of the SIAM model including:

oServices, service groups and service providers (the ‘service model’)

oThe selected SIAM structure

oProcess models

oPractices

oStructural elements

oRoles and responsibilities

oGovernance model

oPerformance management and reporting framework

oCollaboration model

oTooling strategy

oOngoing improvement framework

•Approved business case

•Organizational change management activities

•Service integrator appointed

•Service providers appointed

•A plan for service provider and service retirement

There may be several iterations during this stage before the outputs are complete and the roadmap progresses to the next stage. The outputs from Plan & Build must be detailed enough to support the implementation activities.

2.3 Implement

2.3.1 Objectives

The objective of this stage is to manage the transition from the organization’s ‘as is’ current state to the ‘to be’ desired future state, the new SIAM model. At the end of this stage, the new SIAM model will be in place and in use.

2.3.2 Triggers

This stage is triggered when the organization completes all activities in the Discovery & Strategy and Plan & Build stages.

The timing for the start of the Implement stage can be influenced by events in the existing environment. For example, implementation could be triggered by:

•The end of an existing service provider’s contract

•An existing service provider ceasing to trade

•Organizational structure changes due to corporate restructure or takeover

The customer organization may have limited control over the timing of these events. It may need to react to them by completing as many of the Discovery & Strategy and Plan & Build activities as possible. There will be an increased level of risk if the activities from these stages are not fully completed owing to a lack of time.

2.3.3 Inputs

All the outputs from the Discovery & Strategy and Plan & Build stages form inputs for the Implement stage.

2.3.4 Activities

The activities in this stage focus on making the transition to the new SIAM model. They include:

1.Select the implementation approach

2.Transition to the approved SIAM model

3.Ongoing organizational change management

2.3.4.1 Activity: Select the implementation approach

There are two possible approaches to implementation:

1.‘Big bang’

2.Phased

2.3.4.1.1‘Big bang’ implementation

A ‘big bang’ implementation approach is one that introduces everything at once, including the service integrator, service providers (with new contracts) and new ways of working.

The ‘big bang’ approach can be high risk, because it affects the entire organization at the same time. The resulting impact on the customer’s business and the services provided can be very high, unless the risks are planned for and carefully managed.

Most organizations that adopt SIAM are introducing it into an environment with existing providers, contracts and relationships.

This can mean that ‘big bang’ is not possible, as different contracts expire at different times. The ‘big bang’ approach does provide an opportunity to make a ‘clean break’ from all legacy issues and behaviors at the same time and avoids the complexities of managing a phased approach.

2.3.4.1.2Phased implementation

A phased implementation approach makes the transformation to the new SIAM model in smaller, more easily manageable transition projects and iterations. This can be achieved in several ways, including:

•One service at a time

•One service provider at a time

•One practice at a time

•One process at a time

This phased approach to SIAM implementation can lower the level of risk associated with the transition, but can be more complex to manage and will extend the total time for implementation. Specific care needs to be given to define and understand the impact of each transition and to ensure that the delivery of existing services continues with no disruption.

2.3.4.2Activity: Transition to the approved SIAM model

The transition activities will be dependent on the selected approach: phased or ‘big bang’.

This activity involves:

•Establishing processes and supporting infrastructure

•Commencing transition activity to new service providers and services

•Removing service providers who are not part of the SIAM model

•Verifying the successful execution of the transition steps

•Toolset and process alignment between all parties

This is not a trivial activity. The number of service providers, services, processes and toolsets will all affect the complexity of the transition. It involves the transition to the full SIAM model, including the implementation of new:

•Service providers

•Services

•Service integrator

•Process models

•Roles and responsibilities

•Tools

•Practices

•Structural elements

•Contracts and agreements

•Governance framework

•Performance management and reporting framework

A robust methodology should be used for this transition, including:

•Testing (both functional and non-functional)

•Data migration

•Service introduction

•Deployment testing

•Service acceptance

•Post-transition support

The transition normally requires resources who are specifically dedicated to and focused on it.

The service providers selected during Plan & Build will need to be transferred into the SIAM ecosystem as part of the Implement stage.

Existing service providers that are taking on a new role in the SIAM ecosystem will need to understand fully their new role, relationships and interfaces. New service providers will need to undergo transition into the ecosystem in a managed way.

This activity should be managed by the service integrator on behalf of the customer. It is vital that clear ownership and roles and responsibilities are agreed, including reporting lines, escalation paths and mandates to ensure efficient and effective decision-making.

2.3.4.3 Activity: Ongoing organizational change management

Organizational change management started in the Plan & Build stage of the roadmap. It continues through this stage and into the next.

Specific activities in the Implement stage include:

•Conducting awareness campaigns throughout the organization

•Communicating with and preparing stakeholders for the change

•Ensuring appropriate training is completed

•Continuing with deployment of the organizational change plans

•Measuring the effectiveness of communications and organizational change activities

It is important to focus on protecting the existing service and minimizing organizational impact during this stage.

2.3.5 Outputs

The output from the Implement stage is the new SIAM model that is in place and operating, and supported by appropriate contracts and agreements.

2.4 Run & Improve

2.4.1 Objectives

The objectives of the Run & Improve stage include:

•Manage the SIAM model

•Manage day-to-day service delivery

•Manage processes, teams and tools

•Manage the continual improvement activities

2.4.2 Triggers

This stage is triggered when the Implement stage is completed. If the chosen implementation approach is ‘phased’, Run & Improve will take over elements of delivery in an incremental way, as each phase, service, process or service provider exits the Implement stage.

2.4.3 Inputs

Inputs to this stage will include:

•The SIAM model

•Process models

•Performance management and reporting framework

•Collaboration model for providers

•Tooling strategy

•Ongoing improvement framework

These inputs have been designed during the Discovery & Strategy and Plan & Build stages, and then transferred during the Implement stage.

2.4.4 Activities

The activities in this stage focus on providing consistent, guaranteed service outcomes to the business, which can be managed, measured and improved. They include:

1.Operate governance structural elements

2.Performance management and improvement

3.Operate management structural elements

4.Audit and compliance

5.Reward

6.Ongoing change management

2.4.4.1 Activity: Operate governance structural elements

Governance boards provide an important role in the control of the overall SIAM ecosystem.

During the Plan & Build stage, the high-level governance framework was created. In Implement, it was transferred to the live environment. In Run & Improve, governance board members adopt their new roles.

See sections 5 and 1 for more information about governance boards.

2.4.4.2 Activity: Performance management and improvement

The performance of all services and processes should be measured and monitored against key performance indicators and, where appropriate, service level targets. The measurements should be both qualitative and quantitative.

Measurements are used to create meaningful and understandable reports for the appropriate audiences. They provide visibility of performance issues, and support trend analysis to give early warning of possible failures.

Routine service improvement activities should include review and management of actions arising from the information and review of report relevance.

Within SIAM, reports also need to include feedback for how the service is perceived by users, referred to as qualitative reporting. For more information, see section 6.

Reports can be used to identify opportunities for improvement and innovation.

2.4.4.3 Activity: Operate management structural elements

Process forums and working groups are two of the structural elements that unite the service integrator, service providers and the customer.

They provide an environment to work collaboratively on the operation of a specific process or processes, process outputs, issue or project.

In this stage of the roadmap, these forums and groups should be actively working. The frequency and format of meetings will vary, but it is a good idea to have regular contact between the forum and group members in the early stages of implementation, as they will be instrumental in creating the necessary collaborative culture.

See sections 5, 7 and 1 for more information about process forums and working groups.

2.4.4.4 Activity: Audit and compliance

In addition to the review of reports that takes place in a SIAM environment, a more formal audit schedule should also be introduced.

This can include process audits, service audits, service provider audits – whatever is most appropriate for each organization and the SIAM ecosystem.

Some audits will be mandated by regulations, legislation or corporate governance.

These audits may be performed by an external organization.

Audits support ongoing assurance of compliance with the customer organization’s legislative and regulatory requirements. They can provide valuable information about whether elements of the model are working as they should and help to embed a culture of improvement.

2.4.4.5 Activity: Reward

A SIAM ecosystem can challenge all stakeholders to behave in new ways. Service providers must be encouraged to collaborate rather than protect their own interests. Reward mechanisms can be used to encourage collaboration and communication.

Good practices for creating a reward system include:

•Using small rewards often, linked to specific actions

•Giving rewards at unexpected times

•Rewarding the behavior, not just the results

•Rewarding all stakeholders, not just one layer of the SIAM model

•Rewarding publicly

2.4.4.6 Activity: Ongoing change management

After the SIAM model enters the Run & Improve stage, it will change and evolve as the sourcing landscape and business requirements change and evolve.

Ongoing change management will include the addition and removal of service providers, scaling the services if customer needs grow or shrink, and potentially changing the SIAM structure.

If major change is required, this can include going back to earlier roadmap stages, for example to revisit Discovery & Strategy.

2.4.5 Outputs

Outputs from the Run & Improve stage fall into two categories:

•Run outputs: business-as-usual outputs including reports, service data and process data

•Improve outputs: information used to evolve and continually improve the SIAM model

 

¹¹ www.lexico.com/definition/capability.

¹² Capability Maturity Model (CMM), https://en.wikipedia.org/wiki/Capability_Maturity_Model.

¹³ For more information, visit: https://obashi.co.uk/.