The SIAM architecture is based on the previous model.
Business: The clients business
CIO: Chief Information Officer
BCIO: 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: 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: Managing contracts with Service Providers and other 3rd party suppliers not signed-up to the SIAM model
SEC: Information Security, considering Service Provider information collaboration, infrastructure, Service Management tool data transparency,GDPR compliance, etc
Service Owner: Represents the service to BCIO / CIO, Service Providers and Service Integrator regarding business service and IT service performance and development.
Portfolio: Portfolio Management - Governance. Liason between Service Owners, BCIO, CIO, Business processes and development
PMO: 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: Service Delivery reports compilation, measurements and reports on service demand and consumption, operational and tactical reports, standardisation across providers.
Governance, performance management: Operational governance processes, such as invoicing, charge-backs.
Service Management: 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: Assisting the Service Providers to collaborate on issues concerning several Service Providers.
SLA: 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: The SIAM model includes the common Service Desk (SD) service. SD is the SPOC for Incidents and Service Requests.
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 the Service Providers' CMDB.
The Customer owns all data in the IT Service Management tool
The Customer owns the tool
The Service Integrator owns the tool
One of the Service Providers owns the tool
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.
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...
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?
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.
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.
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.
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.
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.
Customary metrics may inlude:
Volumes by classification (proactive, preactive, based on major incident, risk for incident).
Volumes leading to Change, RCA not found, etc.
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.
Volume and listing of shared incidents, problems and changes.
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.
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.