APPENDIX B: THE SIAM™ PROCESS GUIDES

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

Most business activities involve repeated tasks; for example, taking a phone call from a customer, raising an invoice or managing a complaint.

Documenting a process for a repeated task has several benefits:

•It allows the organization to define its preferred approach to managing the task

•The task will be carried out consistently

•It avoids staff wasting time recreating an approach each time the task is carried out

•New staff can be trained quickly to carry out a process

•It can be measured and assessed

•It can be used as a baseline for improvement

A process takes one or more inputs, performs activities on them and transforms them into one or more outputs.

A process description document will normally include:

•The purpose and objectives of the process

•The trigger for starting the process

•Process activities or steps

•Roles and responsibilities, including a RACI model

•Metrics for the process, including service levels, targets and key performance indicators

•Process inputs and outputs

•Escalation paths

•Associated toolsets

•Data and information requirements

Every process should have an owner. The owner is the single, accountable role that ensures the process is defined, executed and reviewed correctly. In larger organizations, process manager roles might also be part of the organizational structure; these roles are responsible for the execution of process activities.

For example, the process owner for change management might be the organization’s change manager, who could be supported by a number of change analysts. They, in turn, would be fulfilling process manager-type roles.

Processes are part of an organization’s SIAM model.

This document describes some common processes at a high level and includes SIAM considerations to help organizations adapt processes within a SIAM ecosystem.

This is not an exhaustive list of processes used within SIAM ecosystems; neither is it an in-depth process guide for commonly used service management processes that are fully described in other management practices, frameworks and standards like ISO/IEC 20000.

SIAM itself is not a process; however, to operate effectively, it relies on a number of processes. Within a SIAM ecosystem, processes are likely to be executed:

•Across different organizations in the same SIAM layer

•Across organizations in different SIAM layers

Processes need to be allocated to the appropriate layers in the SIAM model. This allocation may be different for each implementation of SIAM.

Many of the processes used within a SIAM ecosystem are processes familiar from other management practices, for example change management and business relationship management.

Within a SIAM model, these processes require adaptation and augmentation to support integration and coordination between the parties involved. They also require alignment with other parts of the SIAM model, including:

•SIAM practices

•SIAM layers

•Governance model

•Structural elements

The execution of many processes will span multiple layers and involve multiple parties. For example, the customer organization and 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.

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 that performs the activities.

Each party in a SIAM ecosystem should adapt and augment its 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. See the SIAM Foundation Body of Knowledge, section 2 for more information on process models and how to design a SIAM model.

As each SIAM model is different, this document cannot prescribe who will do what for each process. In all SIAM models, it is important to ensure that the roles and responsibilities, interfaces and dependencies of the customer, service integrator and service providers are mapped, defined clearly and understood by all.

2.1 Process guides

The process guides in this document provide a generic description for each process, plus an illustration of the considerations that should be made when designing and using the process in a SIAM ecosystem.

Each process guide includes:

•Process purpose

•SIAM considerations

•Generic process information:

oActivities

oExample roles

oExample metrics

oExample inputs and outputs

This section examines the considerations that are common for all processes in a SIAM ecosystem.

3.1 Complexity

In a SIAM ecosystem, processes can seem more complex owing to factors that include:

•Discrete layers having different accountabilities and responsibilities within the same process

•An increased number of parties involved in end-to-end process execution

•The need to integrate different processes from multiple organizations to support the end-to-end process

•The number of interactions between processes from different organizations

Complex processes are more difficult to understand and follow. Wherever possible, processes in a SIAM ecosystem should be designed to avoid complexity.

3.2 Who owns the end-to-end process?

Defining process ownership and levels of accountability and responsibility will also be important in a SIAM ecosystem. Common factors include:

•The customer is ultimately accountable for process outcomes, as it is the organization that commissions the SIAM ecosystem

•The service integrator is accountable for:

oThe overall design of the process models, supporting policies and data and information standards. It must ensure that the design will deliver required outcomes

oIts own local processes and procedures

•The service providers are accountable for the design of their own local processes and procedures, ensuring that they comply with the process models, supporting policies and data and information standards provided by the service integrator

3.3 Toolset considerations

The toolset(s) that will support processes need to be defined as part of the SIAM model. The decision confirming which toolset is to be used, and who will own it, is made during the Plan & Build stage of the SIAM roadmap.

The outcome of these decisions is documented in the tooling strategy. The decisions can only be made once the SIAM model has been finalized.

If the customer owns the toolset, it will make it less challenging to change the service integrator. Alternatively, using a toolset owned by an external service integrator might offer an opportunity to access a ‘best of breed’ toolset.

3.4 Data and information considerations

3.4.1 Who owns the data?

This decision needs to take into consideration what happens if a service provider or a service integrator is replaced. The customer organization should aim to have ownership of, or guaranteed access to, any data that is necessary to operate the services, for example incident records.

3.4.2 Who owns the intellectual property on artefacts?

As part of normal service operation in a SIAM ecosystem, artefacts will be created, for example knowledge articles in the knowledge management repository.

Intellectual property rights for these artefacts need to be defined and agreed in contracts or service agreements. There will be commercial considerations to take into account, for example a service provider may be unwilling to share its articles with another organization.

3.4.3 Is data and information consistent?

The SIAM model should include standards for data and information and supporting policies. A data dictionary will ensure all parties use common standards.

For example, there should be a minimum dataset for incident records and a standard definition of incident priorities and severities.

3.4.4 How is access to shared data, information and tools controlled?

Policies and processes for access control need to be defined and managed, taking into account security considerations.

3.4.5 Who is responsible for process improvement?

All parties in the SIAM ecosystem are responsible for improving their own processes and for improving the end-to-end processes, facilitated by the service integrator.

The service integrator is responsible for ensuring that the processes from different service providers continue to work together within the overall process models.

The service integrator’s process owners are accountable for end-to-end process improvement.

3.4.6 How will compliance and assurance be managed?

Compliance and assurance requirements should be included in contracts so that they can be enforced.

The service integrator is accountable for assurance of process outcomes across the end-to-end processes.

4.1 Process purpose

The purpose of the service portfolio management process is to maintain information on all services, to provide the customer organization with a better insight into ongoing spend and support business decisions on future investment in products and services.

The process creates a single source of service information and tracks the status of planned, current and retired services.

4.2 SIAM considerations

Service portfolio management considerations in a SIAM environment include:

•It is not possible to make the transition to a SIAM model without a clear definition of all services, service providers, dependencies and relationships between services and service characteristics. Service portfolio management information is, therefore, critical to any SIAM implementation.

•The customer organization should own the service portfolio. Responsibility for execution of the service portfolio management process can be given to the customer’s retained capabilities or delegated to the service integrator.

•The portfolio needs to be maintained with current information from all service providers, including potential new services arising from innovation opportunities. Service provider contracts need to include a requirement to provide this information.

•Data and information standards for portfolio records need to be agreed and consistent across all service providers.

•The service portfolio management process must be aligned with the processes for introducing and retiring new services and new service providers.

4.3 Generic process information

4.3.1 Activities

Service portfolio management activities can include:

•Creating a service portfolio

•Maintaining a service portfolio

•Reviewing a service portfolio

4.3.2 Example roles

Service portfolio management roles can include:

•Service portfolio manager

4.3.3 Example metrics

Service portfolio management metrics can include:

•The number of:

oPlanned services

oCurrent services

oRetired services

oPortfolio opportunities

•Commercial viability of services

4.3.4 Example inputs and outputs

Service portfolio management inputs can include:

•Customer strategy and requirements

•Demand management data

•Service portfolio reviews

•Service catalogs

•Service contracts

•New and changed services

Service portfolio management outputs can include:

•Service portfolio

•Service portfolio reports

•Approved services

•Terminated services

5.1 Process purpose

The purpose of the monitoring and measuring process is to:

•Monitor and measure systems and service delivery

•Monitor services against defined thresholds, creating alerts, identifying and predicting service affecting trends, and preventing service interruptions

•Measuring service utilization and performance

This process has relationships with other processes, including event management and service level management.

5.2 SIAM considerations

Monitoring and measuring considerations in a SIAM environment include:

•Assuring the ability of all service providers to monitor their services and underlying technical components

•The requirement for a data dictionary, data models, terminology, thresholds and reporting schedules that are consistent across the SIAM ecosystem

•Shared performance measures to enable end-to-end reporting

5.3 Generic process information

5.3.1 Activities

Monitoring and measuring activities can include:

•Service monitoring

•Threshold detection

•Incident detection

•Event creation

•Report creation

•Performance analysis

•Tuning

5.3.2 Example roles

Monitoring and measuring roles can include:

•Service level manager

•Service delivery manager

•Capacity manager

•Availability manager

•Event manager

•Performance manager

5.3.3 Example metrics

Monitoring and measuring metrics can include:

•Incidents related to capacity/availability issues

•Availability of services

•Performance of services

•Reports issued within schedule

5.3.4 Example inputs and outputs

Monitoring and measuring inputs can include:

•Contractual service levels

•Service thresholds

•Alerts

•Service provider data

•Reporting requirements, formats and frequencies

Monitoring and measuring outputs can include:

•Measurement reports

•Service measurements

•Service improvement opportunities

•Events

•Forecasts

•Change requests

6.1 Process purpose

The purpose of the event management process is to identify events through the monitoring of technology components, systems and services, and, where appropriate, action is taken.

The process seeks to provide early detection – and even avoidance – of system and service outages, and increase service availability for users. It is closely related to monitoring and measuring, incident management and availability management.

6.2 SIAM considerations

Event management considerations in a SIAM environment include:

•The organizational design should include the function responsible for managing events. This could be a central function provided by the service integrator, a virtual function provided by all service providers or individual functions in each service provider.

•The rules for managing event thresholds should be defined in a policy that is consistent across all service providers; for example, at what point do repeated events concerning slow performance result in an incident being raised.

•Specific tools may be required to collate events from multiple service providers, correlate the data and apply rules to identify end-to-end issues.

•Targets for event diagnosis and resolution should be common across service providers.

6.3 Generic process information

6.3.1 Activities

Event management activities can include:

•Record an event (often automatically created by monitoring systems)

•Diagnose and evaluate the event

•Create an associated incident, if required, and assign to the incident management process

•Close the event

•Configure and tune event management tools

6.3.2 Example roles

Event management roles can include:

•Event manager

•Operations team

•Service desk

6.3.3 Example metrics

Event management metrics can include:

•Number of events, by type

•Accuracy of event information, by type

•Number of incidents avoided

•Number of failures resolved

6.3.4 Example inputs and outputs

Event management inputs can include:

•Auto-generated alerts

•User reports of system failures

6.3.5 Event management outputs can include:

•Event data

•Trend reports

•Input to related processes, including incident and problem management

7.1 Process purpose

The purpose of the request management process is to manage the lifecycle of service requests from users. This may also be known as request fulfilment or request catalog management.

Service requests are a means of accessing standard services or service offerings from a service provider for which a predefined authorization and qualification process exists. Requests can be made in several ways, including contacting a service desk, sending an email or accessing a self-help portal.

Examples of requests include the provision of standard components, such as hardware or an application, to obtain information and advice or to log complaints or compliments regarding the services received.

The objective of the process is to provide efficient handling of all ‘in scope’ service requests.

7.2 SIAM considerations

Request management considerations in a SIAM environment include:

•Request management will typically be performed within each service provider, using mostly predefined and repeatable procedures:

oFulfilling some requests may require the involvement of more than one service provider, requiring integration between the specific process of each service provider and service integrator.

oThe service integrator’s responsibilities include acting as a point of escalation for request management issues and ensuring that request management operates effectively across the full ecosystem.

•The service desk plays a key role in coordinating service requests with, and across, the various providers. Therefore, the service desk should be tightly integrated with this process.

•As requests are typically predefined and repeatable, automation should be leveraged as much as possible to support consistent, efficient and effective fulfilment.

7.3 Generic process information

7.3.1 Activities

Request management activities can include:

•Request logging and validation

•Request categorization

•Request prioritization

•Request authorization/approval

•Request routing

•Coordination of fulfilment activities

•Escalation

•Status tracking

•Request review

•Request closure

•Managing and maintaining a request catalog

•Creating new request processes

7.3.2 Example roles

Request management roles can include:

•Request (fulfilment) manager

•Service desk

•Financial manager

•Service catalog manager

•Service level manager

•Release manager

•Deployment manager

•Capacity manager

•Change manager

•Access manager

•Incident manager

7.3.3 Example metrics

Request management metrics can include:

•Request fulfilment timescales against agreed SLAs

•Breakdown of requests (by category)

•Requests resolved through automation

•Costs per type of request

•User satisfaction related to request fulfilment

•Size of request backlog

7.3.4 Example inputs and outputs

Request management inputs can include:

•Requests from various sources, such as phone calls, forms, web interfaces or email

•Request models/templates

•Authorization

•Request for change (RFC)

•Request for information

•Request for updates on status

Request management outputs can include:

•Authorized/rejected requests

•Request management status reports

•Fulfilled service requests

•Incidents (rerouted)

•RFCs/standard changes

•Asset/configuration updates

•Updated request records

•Closed service requests

•Cancelled service requests

•Request catalog

•New request types for consideration

8.1 Process purpose

The purpose of the incident management process is to record and manage service issues (known as incidents) that are interrupting the availability of a service. The process also manages events that are degrading – or could degrade – service performance.

The process seeks to restore service. This is often within an agreed timescale, dictated by the priority of the incident, based on its impact and the speed by which it needs to be resolved.

8.2 SIAM considerations

Incident management considerations in a SIAM environment include:

•The incident management process model needs to support prompt restoration of service. This includes routing incidents to potential resolvers as quickly as possible and with the minimum number of parties involved. The associated service desk model needs to support this.

•Data and information standards for incident records, incident transfer and supporting tooling must be defined, to support the effective referral of incidents between service providers.

•Incident priorities and severities should be defined consistently across all parties.

•Roles and responsibilities must be defined for coordinating incident investigations that involve multiple service providers.

•Targets for incident resolution need to recognize that incidents may be referred between service providers. The referrals will take time and each service provider will have its own agreed targets. The end-to-end process needs to make sure that customer targets are not breached, even if every service provider achieves its own target.

•There is a risk that service providers may refer incidents to another service provider to avoid breaching a resolution time service level.

•Incident management teams from different providers are likely to be in different geographical locations, creating challenges for collaboration on incidents.

8.3 Generic process information

8.3.1 Activities

Incident management activities can include:

•Incident reporting

•Incident detection

•Incident categorization and prioritization

•Record creation

•Incident investigation

•Incident resolution

•Confirmation of resolution

•Incident record updated and closed

•Incident trend analysis

8.3.2 Example roles

Incident management roles can include:

•Incident manager

•Service desk

•Major incident manager

•Technical staff

8.3.3 Example metrics

Incident management metrics can include:

•Number of incidents (overall, by service, by site, etc.)

•Number of incidents resolved at first point of contact

•Incidents that needed to be reopened

•Customer satisfaction with the incident management process

•Incidents that have been assigned incorrectly

8.3.4 Example inputs and outputs

Incident management inputs can include:

•Events

•User reports

Incident management outputs can include:

•Incident records

•Resolved incidents

•Incident reports

•Incident metrics

9.1 Process purpose

The purpose of the problem management process is to manage the lifecycle of a problem, which is defined as the unknown underlying cause of an incident. It is also responsible for preventing incidents and problems from occurring or recurring.

The problem management process has both reactive and proactive aspects. The reactive aspect is concerned with solving problems in response to one or more incidents within an agreed timescale and based on the priority of the problem. The proactive aspect is concerned with preventing incidents from occurring in the first place.

9.2 SIAM considerations

Problem management considerations in a SIAM environment include:

•Getting all parties to take part in problem management working groups and forums, including joint working to resolve problems that involve multiple service providers

•Coordinating problem investigation and resolution activities across multiple service providers

•Encouraging and facilitating the sharing of data and information on problems with other service providers

•Aligning targets for problem resolution across service providers

•Creating and using common terminology, data, and information standards and problem classifications across service providers

9.3 Generic process information

9.3.1 Activities

Problem management activities can include:

•Review of incident(s) reported or trend analysis of incident records

•Creating problem records

•Categorizing and prioritizing problem records

•Identifying and communicating workarounds

•Identifying and addressing the root cause of a problem

•Proactively identifying and addressing potential problems

9.3.2 Example roles

Problem management roles can include:

•Problem manager

•Technical teams

9.3.3 Example metrics

Problem management metrics can include:

•Problems recorded per month – proactive and reactive

•Number of in-progress problems

•Number of resolved problems

•Number of recurring incidents while a problem is being investigated

9.3.4 Example inputs and outputs

Problem management inputs can include:

•Incident records

•Configuration management information

•Change records

•Workarounds

Problem management outputs can include:

•Problem records

•Problem reviews

•Resolved problems

•Workarounds

•Change requests

•Service improvements

•Knowledge articles

•Reports

10.1 Process purpose

The purpose of the change management process is to enable changes to be made to services with minimal amounts of disruption.

A release is a collection of one or more changes tested and deployed together. Release management ensures that the integrity of the live environment is protected and that the correct changes are deployed.

Together, the processes ensure that consistent methods are used to assess, approve and deploy changes.

10.2 SIAM considerations

Change and release management considerations in a SIAM environment include:

Change management:

•The scope of change management needs to be defined clearly. The process can encompass many areas, including:

oTechnology

oProcesses

oPolicies

oOrganizational structures

oThe SIAM model

•Common standards should be developed for data and information and included in a change policy. These include, for example, types of change, approval levels and notice periods.

•The roles and parties involved in reviewing and approving changes must be clearly defined and should include all organizations that may be affected by the change.

•Having different reviewers and approvers for different types and classes of change. Who approves a change should depend on risk and impact and if the change is an emergency.

•Allowing service providers to approve their own proven low-risk, repeatable changes that do not affect other service providers.

•Leveraging automated testing and deployment techniques to reduce the level of manual review required and improve change success rates.

Release management:

•Release planning and implementation needs to consider all the affected service providers, and the customer organization. This includes coordinating and scheduling releases to avoid negative impact.

•Responsibilities for testing integration between services from different service providers should be defined.

•Defined approaches for remediation to minimize business impact should the release implementation fail.

•There should be a consistent format and method for communicating information about releases.

10.3 Generic process information

10.3.1 Activities

Change and release management activities can include:

•Analysis of proposed changes

•Approving changes

•Scheduling changes

•Communication

•Packaging of releases

•Scheduling releases

•Testing releases

•Implementation and deployment

•Reviewing successful deployment

10.3.2 Example roles

Change and release management roles can include:

•Change requestor

•Change manager

•Release manager

•Test manager

•Product owners

•Change advisory board attendees

10.3.3 Example metrics

Change and release management metrics can include:

•Changes per month

•Successful changes/releases

•Emergency changes

•Failed changes/releases

•Number of incidents caused by changes

10.3.4 Example inputs and outputs

Change and release management inputs can include:

•Change policy

•Release policy

•Requests for change

•Incident and problem data related to changes

•Service targets

•Test results

•Configuration information

•Change and release plans

Change and release management outputs can include:

•Approved/rejected changes

•Change schedules

•Change/release communications

•Release plans

•Service availability plans

•Change reviews

11.1 Process purpose

The purpose of the configuration management process is to identify, record, maintain and assure data and information about configuration items (CIs).

A CI can be anything used to deliver or support the services, including:

•A service

•A software application or product

•A hardware component

•Documentation

The types of CIs in scope are tailored on a customer-by-customer basis. There can be many different types of CI.

CI details are often held in one or more configuration management database (CMDB). The aggregation of multiple CMDBs and other data sources is referred to as a configuration management system (CMS).

Configuration management records and maintains details of the relationships between CIs and documents how they interact and rely upon each other.

Configuration management has interfaces with other processes, including:

•Incident management, which registers incidents against CIs and uses CI information to identify existing incidents for the affected CI or recent changes that may have caused an incident

•Change and release management, which registers changes against CIs and uses configuration management data to assess the potential impact of changes and is updated through release deployment

•Problem management, which uses configuration management information to identify incident trends

11.2 SIAM considerations

Configuration management considerations in a SIAM environment include:

•The scope of the service integrator’s CMDB must be clear, and should only contain data that the service integrator needs to fulfil its responsibilities

•Service provider contracts and agreements need to stipulate the configuration management data they are required to provide

•Each organization is responsible for maintaining its own CMDB, containing the data necessary to support delivery of its own services

•Service providers need to share a subset of the data in their CMDB with the service integrator and other service providers, to support delivery of the end-to-end service

•A policy should be defined to specify common classifications and record contents for any configuration data that needs to be shared across parties in the SIAM ecosystem

•The approach, toolset integration and access control for sharing CMDB data between different parties needs careful consideration

•Where CMDB data is shared, responsibility for maintaining shared items must be defined

•Responsibilities for assessing and improving data quality and CMDB accuracy should be defined

11.3 Generic process information

11.3.1 Activities

Configuration management activities can include:

•Design and implementation of CMDB(s)

•Gathering data to populate CMDB(s)

•Updating data based on triggers including change management inputs

•Audit of configuration management data

•Documentation and investigation of any data discrepancies

•Providing reports as required

11.3.2 Example roles

Configuration management roles can include:

•Configuration manager

•Configuration analyst

11.3.3 Example metrics

Configuration management metrics can include:

•Number of CIs, by service provider, type, status, etc.

•Number of CI to CI relationships, by service

•Number of CIs with incomplete or missing information

•CIs that are verified/unverified

•CIs discovered that are not contained in the CMDB

•CIs in the CMDB that should be detected by automated discovery tools but have not

11.3.4 Example inputs and outputs

Configuration management inputs can include:

•Data from discovery tools

•Data and information from physical checks

•Incident records

•Change records

•Build information from infrastructure teams

•Application information from development teams

Configuration management outputs can include:

•CMDB records

•Verification schedules

•Verification reports

12.1 Process purpose

The purpose of the service level management (SLM) process is to ensure that service performance meets agreed requirements. These requirements are set out as service level targets in a contract or service agreement.

SLM contributes to, reviews and validates the service level targets against service provider capability and planned service provision.

Following the implementation of services, SLM will review, report on and drive performance against the targets continually.

12.2 SIAM considerations

SLM considerations in a SIAM environment include:

•Service providers need to recognize that the service integrator is acting as the agent of the customer and work with it on SLM activities and reporting.

•The scope of SLM should be clearly defined. Its activities need to be distinct from those of:

oSupplier management

oContract management

oPerformance management

oBusiness relationship management even if performed in the same layer. The interfaces between these processes should be mapped.

•SLM needs to include thresholds to define when a breach of performance should be escalated to supplier management, so the process can apply remedies.

•The SIAM model needs to reflect any service level targets that may have been agreed before the service integrator was appointed.

•The scope of the contracted services, and any dependencies on services from other service providers, must be clearly defined.

•An approach must be established to manage the situation where the failure of a service provider to meet its targets is due to another service provider’s actions.

•The service integrator will need information to verify the service providers’ performance reports. This may need to be sourced from other service providers and from service consumers.

•It can be challenging to produce consolidated reports unless the service level targets of all service providers are aligned. For example: a common definition and calculation of ‘availability’ and reports covering the same time periods.

•Consideration should be given to including internal service providers within the scope of SLM.

12.3 Generic process information

12.3.1 Activities

SLM activities can include:

•Tracking performance against service level targets

•Validating service reports from service providers

•Producing and publishing reports of service achievements against service levels and of trends

•Reviewing performance data to identify improvement opportunities

•Reviewing service level targets for ongoing alignment with business requirements

12.3.2 Example roles

SLM roles can include:

•Service level manager

•Reporting analyst

12.3.3 Example metrics

SLM metrics can include:

•Customer perception of the services

•Service level achievement against targets

SLM metrics are often trended on a monthly, quarterly and annual basis. This can highlight areas for improvement and successes.

12.3.4 Example inputs and outputs

SLM inputs can include:

•Contracts

•Service targets

•Service provider capabilities

•Service performance data

•Customer feedback

SLM outputs can include:

•Service level reports

•Trend analysis

•Service improvement opportunities

13.1 Process purpose

The purpose of the supplier management process is to define the supplier management policy and strategy, establish a management framework, and identify and manage service providers, to deliver value for money to the customer.

The process manages supplier performance, in conjunction with service level management and contract management.

13.2 SIAM considerations

The ‘suppliers’ in a SIAM ecosystem are referred to as service providers.

Supplier management considerations in a SIAM environment include:

•Effective supplier management is critical to the success of any SIAM implementation. Performance issues with one service provider can affect others, as well as affecting the end-to-end service.

•Supplier management is normally executed by the service integrator, acting on behalf of the customer.

•Supplier management should be clearly defined as separate from contract management and service level management, even if performed in the same layer. The interfaces between these processes should be clear.

•This process should manage service provider performance escalations received from the service level management process.

•A supplier management policy should be created that is appropriate for, and fair to, different types and sizes of service providers.

•The execution of the process should not favor one service provider over others. This can be a challenge if the service integrator is also a service provider or where some service providers are internal.

•There should be a clear definition for when the supplier management process can apply remedies and for when a breach of performance becomes a breach of contract that should be escalated to contract management.

•A mechanism should be developed to apportion remedies for failure to meet service level targets where multiple service providers contributed to the failure.

•Non-financial incentives can be as effective as financial remedies to drive appropriate service provider behavior.

•Supplier forums can assist in creating a collaborative culture.

13.3 Generic process information

13.3.1 Activities

Supplier management activities can include:

•Plan, produce and implement a supplier management policy and process

•Enforce the policy

•Design and implement a supplier management framework

•Apply remedies for failure to meet service level targets

•Identify and manage nonconformity to the policy and process

•Escalate to contract management as required

13.3.2 Example roles

Supplier management roles can include:

•Supplier manager

•Account manager

•Procurement manager

•Contract manager

•Service provider service manager

13.3.3 Example metrics

Supplier management metrics can include:

•Number of suppliers managed in accordance with the policy

•Supplier performance aligned to committed performance targets

•Reduction of service failures

•Accuracy of service reporting and conformity to service level agreements

13.3.4 Example inputs and outputs

Supplier management inputs can include:

•Business policy requirements

•Contracts

•Audit reports

•Regulatory and industry standards

•Previous breaches and achievements

•Customer and supplier requirements

•Planned changes

•Project plans and risk logs

Supplier management outputs can include:

•Supplier conformity reports

•Planned improvements and remediation activities

•Training needs

14.1 Process purpose

The purpose of the contract management process is to:

•Evaluate proposals from prospective service providers

•Negotiate and finalize contracts with service providers

•Verify if contractual requirements are being met, and trigger contractual remediation if required

•Assess if contracts are still relevant and advise on updates or termination if no longer required

14.2 SIAM considerations

Contract management considerations in a SIAM environment include:

•The customer is always accountable for contract management; it holds the contracts with the service providers. Some organizations delegate responsibility for execution of some activities to an external service integrator or use them as an advisor.

•Contract management should be clearly defined as separate from supplier management and service level management, even if performed in the same layer. The interfaces between these processes should be clear.

•A SIAM ecosystem requires appropriate contracts to avoid vendor lock-in, and provide for shared goals, shared risk and reward, end-to-end service levels and performance measures, collaboration and the right of the service integrator to act on behalf of the customer.

•Clearly define when a breach of performance becomes a breach of contract. This process is responsible for managing breaches of contract.

•Ensure that contract breaches are addressed consistently and fairly with all service providers.

•Implement practices to support management of multiple contracts, including a contract repository with associated access management.

14.3 Generic process information

14.3.1 Activities

Contract management activities can include:

•Negotiate and agree contracts

•Develop and implement sourcing strategies

•Manage contractual changes

•Verify delivery against contractual requirements

•Address contractual non-compliance

14.3.2 Example roles

Contract management roles can include:

•Contract manager

•Legal advisor

14.3.3 Example metrics

Contract management metrics can include:

•Contract renewals within schedule

•Service provider performance against contracts

•Contract breaches

14.3.4 Example inputs and outputs

Contract management inputs can include:

•New service portfolio entries

•Contract framework

•Contract change notices

•Escalations from supplier management

Contract management outputs can include:

•Service provider addition and removal plans

•Service improvement plans for underperforming service providers

•Contracts

•Warning notices

•Sourcing strategies

15.1 Process purpose

The purpose of the business relationship management (BRM) process is to build and maintain strong relationships between service providers and the consumers of their services.

BRM’s role is to understand how business processes are supported by a service provider’s services and processes. BRM is also responsible for ensuring the right messages are received by the right stakeholders at the right time.

BRM’s goal is to create convergence between IT services and business needs, acting as a strategic advisor, rather than a supporting function.

15.2 SIAM considerations

BRM considerations in a SIAM environment include:

•The retained capabilities within the customer organization are normally responsible for BRM with the service consumers

•The service integrator may have its own BRM function that has a relationship with the customer organization’s retained capabilities, but this is normally part of the service integrator’s commercial activities and does not necessarily form part of the SIAM model

•Service providers may also have BRM functions, which may also be outside the scope of the SIAM model

•A BRM policy should be developed to ensure consistent communication and stakeholder management

•The business areas that consume services must understand that their point of contact for services is via the customer’s retained capabilities, and not directly with the service providers

15.3 Generic process information

15.4 Activities

BRM activities can include:

•Developing and maintaining stakeholder engagement plans

•Developing and maintaining communication plans

•Meeting with the service integrator, service providers and customers

•Establishing and maintaining stakeholder forums

•Executing communication plans

•Reviewing customer satisfaction

15.5 Example roles

BRM roles can include:

•Business relationship managers

•Communication managers

•Service owners

•Service managers

•Stakeholders

15.6 Example metrics

BRM metrics can include:

•Delivery of communication management plan

•Delivery of communication improvement plans

•Number of improvement initiatives

•Number of satisfaction surveys

•Ratings from satisfaction surveys

15.7 Example inputs and outputs

BRM inputs can include:

•Communication standards, including templates, logos and style sheets

•Stakeholder map

•Communication plan

•Customer feedback

BRM outputs can include:

•Communication plan

•Business communications

•Minutes of meetings

•Customer satisfaction reports

•Improvement plans

16.1 Process purpose

The purpose of the financial management process is to oversee the management of the end-to-end financial function and the activities of collating, investigating, analyzing and presenting financial information to the customer.

16.2 SIAM considerations

Financial management considerations in a SIAM environment include:

•Maintaining commercial confidentiality across the ecosystem

•Being able to compare and contrast financial information from different services providers in a meaningful way

•Understanding the cost of a service provided by multiple service providers, including the cost drivers of different components

•Presenting consolidated financial information to the customer in an understandable format

•Maintaining traceability of financial information across the SIAM ecosystem

16.3 Generic process information

16.3.1 Activities

There are six main financial management activities:

•Costing

•Budget planning

•Monitoring of spend against budget

•Producing and maintaining financial reports and outputs

•Conducting financial impact analysis

•Processing invoices

16.3.2 Example roles

Financial management roles can include:

•Chief financial officer

•Management accountant

•Cost accountant

•Accounts assistant

16.3.3 Example metrics

Financial management metrics can include:

•Cost of a service

•Profitability of a service

•Comparison of costs and charges between services and service providers

•Spend against budget

•Accuracy of invoices

•Resolution of invoice discrepancies

•Outputs produced on time

16.3.4 Example inputs and outputs

Financial management inputs can include:

•Invoices

•Budget plans

•Contractual pricing models

•Purchase orders

•Service costs

Financial management outputs can include:

•Billing plan

•Reports

•Cost breakdown

•Spend and forecast data

•Financial risk and opportunity information

•Invoice

17.1 Process purpose

The purpose of the information security management (ISM) process is to set and monitor adherence to security policies and processes. It manages the confidentiality, integrity and availability of information, data, IT and people.

Its objective is to protect individuals, technology and organizations from damage caused by system outages, breaches of privacy, malicious attacks and loss or disclosure of protected data and information.

17.2 SIAM considerations

ISM considerations in a SIAM environment include:

•Defining who is accountable for establishing and managing the end-to-end information security process and policies

•Using consistent information security classifications and definitions. For example, what constitutes a security incident?

•Managing and communicating breaches and identified vulnerabilities across the ecosystem

•Defining responsibility for managing the investigation and resolution of security breaches involving multiple parties

•Including security targets within service provider contracts, for example giving the authority to suspend a service provider’s service if it is compromising other services

•Being aware of increased security risks when lower-level risks are aggregated across multiple parties

17.3 Generic process information

17.3.1 Activities

ISM activities can include:

•Plan, produce and implement an ISM policy and process

•Enforce the policy and monitor adherence

•Implement a security toolset

•Monitor security activity and take appropriate resolution or improvement actions

•Identify risks derived from aggregation of lower-level risks

•Raise incidents for breaches and failures using the incident management process and service desk

•Evaluate and update the policy, process and tools to ensure protection is maintained

•Plan and deliver training, audits, reviews and tests of the security framework

17.3.2 Example roles

ISM roles can include:

•Senior information risk officer

•Information security manager

•Service desk

•Incident manager

17.3.3 Example metrics

Information security management metrics can include:

•Number of security-related incidents

•Number of security breaches

•Percentage of users complying with security training and other requirements

•Availability and accuracy of security tools and systems

•Accuracy and outcomes of security audits and tests

•Percentage awareness of security principles throughout the organization

17.3.4 Example inputs and outputs

ISM inputs can include:

•Policy requirements

•Regulatory and industry standards

•Previous breach and ‘near miss’ information

•Planned changes

•Customer and service provider requirements

•Project plans

•Risk logs

ISM outputs can include:

•Security incident records

•Planned improvements

•Remediation activities

•Training needs

•Disciplinary and human resources actions

•Process and policy status reports

18.1 Process purpose

The purpose of the continual service improvement process is to provide a consistent method of quantifying, tracking and managing the delivery of improvement activity across an ecosystem.

Improvement activities can be applied to people, processes, services, technology, and the interfaces and relationships between them.

18.2 SIAM considerations

Continual service improvement considerations in a SIAM environment include:

•A common definition of continual service improvement across all parties in the ecosystem

•The inclusion of continual service improvement on the agenda of governance boards

•Continual service improvement should be the primary focus of the process forum structural elements

•All service providers should be encouraged and incentivized to contribute to continual service improvement activities

•There should be an approach to share lessons to be learned across all parties in the SIAM ecosystem

•There may be a need to establish a central database or register of continual service improvement activities

•The service integrator will be responsible for managing cross-service provider improvements

•There needs to be a mechanism in place to prioritize improvements to the end-to-end services and processes

18.3 Generic process information

18.3.1 Activities

Continual service improvement activities can include:

•Investigation: the improvement is identified and further information obtained

•Baseline: document current metrics

•Identify and quantify the expected or desired improvements and benefits

•Categorize and prioritize the improvement, to define the required level of governance and relative importance

•Approve improvement development and implementation activity

•Stakeholder management and communication planning

•Plan improvement

•Carry out improvement actions

•Review improvement

•Measure, review and quantify benefit

•Close improvement action, including documenting lessons learned

18.3.2 Example roles

Continual service improvement roles can include:

•Improvement initiator

•Improvement sponsor

•Improvement developer/implementer

•Governance board attendees

•Process forum attendees

18.3.3 Example metrics

Continual service improvement metrics can include:

•Number of improvements identified, active and completed

•Cost of improvement activities

•Increased value associated with improvement activities

•Improvements in achievement of service level targets and process performance indicators

18.3.4 Example inputs and outputs

Continual service improvement inputs can include:

•Management information, including service level reports, internal key performance indicator reporting and trend analysis

•Lessons learned reviews

•Audits

•Customer satisfaction reports

•Strategic drivers, including delivery model evaluation, industry benchmarking and governance board outputs

Continual service improvement outputs can include:

•Improvement register

•Management information and recommendations

•Status changes to logged improvements

•Implemented improvements and benefits achieved

19.1 Process purpose

The purpose of the knowledge management process is to capture knowledge and make it available to all appropriate people in a controlled and quality-assured manner.

19.2 SIAM considerations

Knowledge management considerations in a SIAM environment include:

•The provision of standardized templates and definitions for knowledge can be useful to assure consistent capture and dissemination

•Service providers should be encouraged to share knowledge with each other

•Responsibilities for creating, reviewing, approving, publishing and maintaining knowledge articles must be clearly defined

•Relevant parties must be able to access knowledge, either from a single knowledge repository or a virtual repository linking all service providers.

•Knowledge should be consistent across the SIAM ecosystem

19.3 Generic process information

19.3.1 Activities

Knowledge management activities can include:

•Knowledge identification, capture and maintenance

•Knowledge transfer

•Data and information management

•Evaluation and improvement

19.3.2 Example roles

Knowledge management roles can include:

•Knowledge creator

•Knowledge manager

•Knowledge editor

19.3.3 Example metrics

Knowledge management metrics can include:

•Number of knowledge users

•Reduction in incident resolution time owing to the use of knowledge items

•Percentage of incidents resolved by referral to knowledge items

•Number of active knowledge articles

•Frequency of updates

•Frequency of access by article

•Accuracy of repository content

•Reduction in time spent on knowledge rediscovery

19.3.4 Example inputs and outputs

Knowledge management inputs can include:

•Documented observations

•External knowledge sources

•Data and process information

•Data repositories

•Release notes

•Procedures manuals

•Training material

Knowledge management outputs can include:

•Knowledge articles

•Reports

•Updated knowledge management system

•Archived data and information

•Updated training materials

20.1 Process purpose

The purpose of the toolset and information management process is to provide toolset(s) to support the other processes, facilitate information sharing and manage data, information and knowledge.

20.2 SIAM considerations

Toolset and information management considerations in a SIAM environment include:

•Defining and managing the use of consistent standards for data, information and knowledge across all service providers

•Creating the toolset strategy for the SIAM model. In SIAM models, there may be a single toolset, or many toolsets

•Creating an enterprise toolset architecture for the SIAM ecosystem

•Selecting an appropriate toolset in line with the strategy and enterprise architecture

•Defining, implementing and maintaining integration between the different parties’ toolsets

20.3 Generic process information

20.3.1 Activities

Toolset and information management activities can include:

•Toolset selection

•Toolset implementation

•Toolset management and maintenance

•Data and information standards definition

•Toolset integration

20.3.2 Example roles

Toolset and information management roles can include:

•Toolset architect

•Toolset developer

•Toolset manager

•Data and information architect

•Data and information manager

•Toolset service provider

20.3.3 Example metrics

Toolset and information management metrics can include:

•Toolset availability

•Toolset reliability

•Toolset data quality

20.3.4 Example inputs and outputs

Toolset and information management inputs can include:

•Policies and processes for access control

•Configuration data

•Interface schema and designs

•User data

•Data repositories

Toolset and information management outputs can include:

•Toolset

•Performance reports

•Service level reports

•Data and information standards

•Data dictionary

•Data interchange standards

•Information classification

21.1 Process purpose

The purpose of the project management process is to provide a structured approach that delivers projects on time, on budget and at the appropriate and agreed level of quality.

21.2 SIAM considerations

Project management in a SIAM environment manages the end-to-end outcomes of projects across multiple service providers.

Considerations in a SIAM environment include:

•The increased complexity of project relationships within a SIAM ecosystem, managing the end-to-end outcomes of projects across multiple service providers

•Accounting for the fact that there is no direct contractual relationship between the service integrator and service providers

•Planning integrated projects involving multiple project teams in multiple service providers

•Obtaining consistency in reporting project status and progress

•Establishment of a collaborative culture to support cross-service provider project management

•Managing risks in integrated projects

•Ensuring effective acceptance into service criteria for project implementations across multiple service providers

21.3 Generic process information

21.3.1 Activities

Project management activities can include:

•Planning

•Adhering to organizational policies and requirements

•Directing actions

•Status reporting

•Risk and issue management

•Delivery of change requests

•Quality management of deliverables

•Managing stakeholders

21.3.2 Example roles

Project management roles can include:

•Project director

•Project manager

•Project management office

21.3.3 Example metrics

Project management metrics can include:

•Delivery against plan

•Delivery against quality requirements

•Delivery against budget

•Overdue products

•Customer satisfaction

21.3.4 Example inputs and outputs

Project management inputs can include:

•Proposals

•Purchase orders

•Project plans

•Project change requests

•Customer requirements

•Quality criteria

Project management outputs can include:

•Completed projects

•Delivered products

•Plans

•Tasks

•Lessons learned

22.1 Process purpose

The purpose of the audit and control process is to provide assurance that the services provided to the customer are being delivered in accordance with documented requirements. This can include contracted, legislative, regulatory and security requirements.

22.2 SIAM considerations

Audit and control considerations in a SIAM environment include:

•It is desirable to apply the same governance framework across all parties; however, this may not be possible for certain service providers, for example commodity cloud service providers

•Each organization should own its risks, but the overall accountability for who will ensure that these have been addressed needs to be clearly defined

•The roles of the customer and service integrator in ensuring security assurance and compliance need to be clearly defined

•Requirements need to be in a format that can be understood by auditors and must be clear enough to verify if they are being met

•Audits will need to take place across the whole SIAM ecosystem

•Audits should be conducted on integrated processes involving several service providers, as well as on individual service provider processes

•The rights of the service integrator (or another organization) to carry out audits should be included in contracts with service providers

22.3 Generic process information

22.3.1 Activities

Audit and control activities can include:

•Auditing an organization’s processes and systems

•Quality assurance planning

•Auditing services, processes and projects

•Identifying nonconformities against requirements

•Recording, presenting and managing audit findings

•Tracking nonconformities through to closure

22.3.2 Example roles

Audit and control roles can include:

•Quality manager

•Chief security officer

•Auditor

•Service owner

•Process owner

•Project managers

22.3.3 Example metrics

Audit and control metrics can include:

•Compliance against requirements

•Number of nonconformities identified, opened and closed

22.3.4 Example inputs and outputs

Audit and control inputs can include:

•Audit scope

•Requirements

•Policies

•Standards

•Processes

•Data and information records

•Performance reports

•Process metrics

Audit and control outputs consist of audit reports, including:

•Audit scope

•Nonconformities

•Evidence

•Observations

•Risks and issues

•Improvement opportunities