About SIAM  
 

1 SIAM model

The SIAM architecture is based on the following model:

SIAM architecture.jpg

Figure 1 - SIAM model

1.1 Model description

Business

o    The clients business

CIO

o    Chief Information Officer

BCIO

o    The business is divided to several business area, and BCIO is the Business Chef Information officer for the particular business area. The BCIOs report to the CIO. BCIO is responsible for the Service Level Agreements (SLA) for their business area.

Policies

o    Outsourcing policies (in accordance with Portfolio Management), Service Management policies, Supplier policies (in accordance with Supplier Management), Security policies (in accordance with Security  Management), Project Management policies, Financial policies, Compliances to standards and regulations, etc.

Supplier

o    Managing contracts with Service Providers and other 3rd party suppliers not signed-up to the SIAM model

SEC

o    Information Security, considering Service Provider information collaboration, infrastructure, Service Management tool data transparency,GDPR compliance, etc

Service Owner

o    Represents the service to BCIO / CIO, Service Providers and Service Integrator regarding business service and IT service performance and development.

Portfolio

o    Portfolio Management - Governance. Liason between Service Owners, BCIO, CIO, Business processes and development

PMO

o    Project Management Office is responsible for coordinating development of major changes and coordinating improvement projects. Coordination is both across Service Providers and Service Integration. Assures the quality of Service Design Packages (if applicable) and coordinates Service Transition.

Reporting

o    Service Delivery reports compilation, measurements and reports on service demand and consumption, operational and tactical reports, standardisation across providers.

Governance, performance management

o    Operational governance processes, such as invoicing, charge-backs.

Service Management

o    Major Incident Management,  Problem Management, CSI Management, Change Management, Knowledge Management and SIAM Configuration Management, Service Design and Transition quality assurance, Processes / Procedures / ITSM tool development, maintenance and operation.

Service Provider collaboration

o    Assisting the Service Providers to collaborate on issues concerning several Service Providers.

SLA

o    Service Level Agreement between the BCIO / CIO and the Service Providers. Means also that the SIAM function is not responsible for the agreements. Depending on agreement, the SIAM function can take responsibility for the SLA fulfilment. That requires that SIAM is the owner of the Service Management processes and policies.  

 

Service Desk

o    The SIAM model includes the common Service Desk (SD) service. SD is the SPOC for Incidents and Service Requests.

 

1.2 Customer Service Catalogue (CSC) and Service Provider Service Catalogue (SPSC)

Customer Service Catalogue includes the IT services related to Business processes.

Service Provider Service Catalogue includes the IT services or service components provided by the Service Provider, related to the services listed in the Customer Service Catalogue. The service components may be related to other Service Providers ' service components, thus making up the complete, contracted  IT service (which  is defined in the Customer Service Catalogue).

Service Providers have most often several customers, delivering the same IT Service or service component to them. Thus, the Service Provider may opt for separate Configuration Management Database (CMDB) for each of their customers or, bundle the provided services and relate these bundles or packages to the Customer Service Catalogue items.

Service Provider Services and/or service components and the relations to the Customer Service Catalogue items are registered in the Service Provider's CMDB. These need to be visible at the Service Integrator end. Thus, defined CMDB information need to be transferred from the Service Provider to the Service Integrator's CMDB.

Alternatively, the Service Integrator needs to define a Configuration Management System that can access information in t he Service Providers' CMDB.

1.3 ITSM Tools

1.3.1 Tool overview

Figure 2 - Tool overview

Options:

         Service Provider 1 uses its own ITSM tool, with integration to the Service Integrator's ITSM tool.

         Service Provider 2 uses its own ITSM tool, and a messaging solution is implemented - requiring 'copy and paste' handling.

         Service provider 3 uses the Service Integrator's or Customer's ITSM tool.

1.3.2 Data ownership

The Customer owns all data in the IT Service Management tool

1.3.3 Tool ownership

o    The Customer owns the tool

v  The Customer funds any modifications and development of the tool. The Customer can place specific requirement on the tool's function. Operations and maintenance of the tool may be outsourced to Service Integrator or to any other party.

v  Recommended: The Customer does not have any dependencies. The Service Integrator can be replaced easier.

v  Risk: Extensive modifications may cause higher maintenance costs and issues with tool update / upgrade.

v  Customer skills may need to be developed in the tool's development and maintenance.

o    The Service Integrator owns the tool

v  Funding of any modifications need to be negotiated between Service Integrator and Customer.

v  Changes in functionality may be limited, as the Service Integrator might use the same tool for several Customers. May require Customer specific installation and operation.

v  Recommended: The Service Integrator has experience and  knowledge and possible modifications in the tool for the successful Service Integration function.

v  Recommended is to  have a separate installation for each customer, to avoid issues of effective shielding of customer / service provider data. Also, easier to adapt to the Customer specific processes.

v  Risk: Replacing the Service Integrator will be difficult and expensive.

o    One of the Service Providers owns the tool

v  Not recommended. The Service Provider may have visibility into other Service Providers' data.

v  Funding and modification requirements might meet unsolvable disputes

v  Service Providers processes might not meet the process requirements from the Customer, thus the tool might not support the Customer's service management process

1.3.4 Integration software between ITSM tools

v  Requires clear data dictionary and flexibility  for differences between the tools. Not all fields can be mapped and not all mapped fields mean the same on both sides.

v  The processes may need to be modified to  accommodate the tools' integration. E.g.  the process might use 'tasks and subtasks', but not both end of the tools will do that. Mapping of tasks to 'tickets' and vice-versa can require extensive integration  development.

v  Measurements of incident leadtimes, problem solutions, changes, availabiity will all be affected by the integration method. 

v  Any modifications may affect the integration, introducing risks.

 

1.3.5 Swivel chair solution

 

If the Service Provider will not take the risk and costs of tool integration and will continue to  use their own tool, then one option is the 'swivel chair' solution. This effectively means that the Service Provider receives information from the Service Integrator's ITSM tool in form of a message. That message needs to be copied and pasted into their own tool. Likewise, when resolving a service issue in their own tool, they will need to copy and paste into the messaging system, that forwards the information to the Service Integrator's tool.

1.3.6 Direct access to the Service Integrator's ITSM tool

 

Most convenient - however, a Service Provider with maybe 100s of customers may  not want to implement this solution, as that would require a separate logon for a separate tool from their own. Also, they might not be able to use the same functionality that they are used to, e.g for monitoring, reporting, event management, etc...

1.3.7 Visibility

By default, Service Providers cannot see each other's activities, incidents, problems, changes, CMDB, etc....

The Service Integrator has access to all data from any Service Provider.

The Customer should not need to have visibility into the ITSM tool data, even if they own the data.

There are situations though, when visibility is required between the Service Providers and also the Customer need to have access to certain information.

The major ITSM tools are role based, meaning, that different roles define what is visible and to whom. This is opposed to the need, where individual cases need to be decided to  be public to others or not. It requires a modification of the tool to introduce a method to publish certain information (that is, accessible by other Service Vendors and Customer) and keep others confidential to the Service Provider. Another solution to this is the introduction of a shared surface, that is visible to everyone. Sharing would  be controlled and manual in some cases, but can be made automatic for e.g. Change Schedules.

What information would be shared and who would use these?

v  Incidents and alerts that are or may be dependent or related to other Service Providers' service components.

v  Problems that need to be analyzed by several Service Providers, in collaboration.

v  Pro-active Problems that need approval for Root Cause Analysis by the Service Owner.

v  Planned Changes that may be related to other Service Providers' service components.

v  Change Schedules

Not the least, the Service Integrator needs to have access to this shared surface, in order to be able to carry out the integration activities and help the collaboration between Service Providers.

Service Owners in the Customer's retained IT organization might also need to have detail  information e.g. for an ongoing incident or need to negotiate with the business regarding the scheduled changes. As for pro-active problem investigations, the Customer needs to agree with the continuation, since pro-active problem investigations are often funded by the Customer. Also, the Customer Portfolio Manager may have information about plans with the service or service component.

The Service Provider Change Manager, Service Integrator Change Manager, Service Owners and Change Advisory Board need to have access to the shared information about the planned changes, in order to be able to make informed decisions.

2 Service Level Agreement - SLA

According to  the SIAM model, the Customer's retained IT organisation has the SLA with  the Service Providers.

It needs to be considered that most often than not, Service Providers' Service deliveries  are only service components and the complete IT Service (supporting the Business process) is a sum of several service components. That means, that the SLA can only cover the service levels of service components, not the IT Service. There usually is no SLA for that.

The Service Integrator may be contracted to manage the service providers' delivery according to the SLA, but not for the complete IT service - as there is no SLA for that.

In the same time, Service Integration and Management is also a service, that needs to deliver according to an SLA. This SLA targets the performance of the Service Integrator, not the IT Services.

The Customer's retained IT organisation includes Service Owners. It is their responsibility to negotiate the SLAs for the service components such that the IT Service will deliver value to the business. The risk with this is the so called 'water melon' effect, that is, everything seems to be green from the outside, however, it is red in the inside.

 

3 Reporting

Reporting puts even more focus on the agreed Data Dictionary.

The SIAM function 'Reporting' is responsible to compile the metrics and reports to a unified reporting structure. 

3.1 CMDB query

The Customer can query the CMDB for any Configuration Item (CI), groups of CIs, statuses, baselines, changes in CMDB. Pre-defined query procedures and ad-hoc queries are both possible.

3.2 Incident Management

 

Customary metrics may include:

Statistics on volume, leadtimes, escalations, related incidents, incidents related to  Changes, Classification (Major), Priority, Impact, Service based, KPI, Service Provider solution, etc

 

Typically Created by Service Desk on a periodic schedule. Depending on contract, the Customer or/and the Service Integrator may request metrics any time, by any specifications.

 

Metrics and reporting are different in that the report includes also analysis, options and recommendations (Data dictionary!).

 

In the SIAM model, particular analysis required for each incident where several Service Providers are involved in the trouble shooting and resolution. The Service Integrator needs to help the collaboration.  SLA metrics in these cases can be misleading, as individual Service Providers may report that they have done their part within SLA but the IT service may still be unavailable over the SLA stipulated times.

Also, when an incident regards a component that  is not part of the service delivery at the time - the Data Dictionary need to define what is unavailability and what needs to be reported on.

3.3 Problem  Management

 

Customary metrics may inlude:

Volumes by classification (proactive, preactive, based on major incident, risk for incident).

Volumes leading to  Change, RCA not found, etc.

 

3.4 Change Management

Customary metrics:

Volume of not approved / approved changes, volume of implemented changes, planned / unplanned  downtime caused by changes.

SIAM related metrics may include changes concerning several Service Providers.

3.5 Shared

Volume and listing of shared incidents, problems and changes.

4 Configuration Management Database - CMDB

The SIAM CMDB contains all configuration items from the Service Providers. These CIs are updated as part of the Change process. The update is requested by the Service Provider and it can then be manually or bulk performed.

Also the Customer may need changes in the CMDB - e.g. foundation data changes about the Customer's organisation, service portfolio changes, application development.

Any request - outside of the Change process -  to update the CMDB is ordered and performed by Standard Service Requests.

5 Cost impact on Service Providers

Collaboration has a cost. The Service Integrator has this cost budgeted and charged for. However, the Service Providers also  need to count on additional costs for their service delivery. Some of these costs have always been there, but some new or increased costs are definitely the result of the SIAM implementation. Thorough accounting will help in charging the Customer for these increased costs.

-          Costs for the ITSM tool integration / modification / validation / training / implementation/ license / CMDB / etc

-          Adjustment to  the common tool (if that is used), e.g. populating with Service Provider foundation data, but also including populating with Knowledge articles, Standard Change templates.

-          Costs for incident / problem / change new  or modified collaboration method

-          Longer and wider CAB meetings, extended multi-vendor meetings, (e.g. count 50 Euro / hour per participant)

-          Process / procedure changes, documentation, implementation

-          Service Request automation, modification and adjustment to the common Service Desk flow and tasks.

-          Adjusting measurements and reports to the Service Integrator directives.