The Story of 'Making SIAM Work - Adopting Service Integration And Management For Your Business

Service Integration And Management (SIAM) is unfortunately being used to replace ITIL® by many ITIL® practitioners. Many of them are packaging ITIL® or some of its processes as SIAM. It is unfortunate that people do not want to understand what SIAM is and try to position it in a way they want to in front of their customers. 

Some see SIAM as multi vendor or multi supplier management while many see SIAM as an approach to Major Incident Management in multi vendor environment. Does SIAM really stand for these adoptions or is it something more is what has been troubles many other practitioners whom I have come across?

These are some of the common questions that has been put forth:

Q. If SIAM is about managing multiple suppliers, what is Supplier Management process of ITIL® meant for?

Q, If SIAM is about managing major incidents in multi vendor or multi supplier environment then what is the purpose of Major Incident Management sub process within Incident Management process of ITIL®?

Q. If SIAM is about managing service levels in multi vendor or multi supplier environment then what is the purpose of Service Level Management process of ITIL®?

...the questions like these goes on...

These very questions had trouble me and Rakesh Kumar  approximately 3 years back. We were concerned why we need a new approach like SIAM when already these fundamental aspects are addressed  by ITIL®. More specific to addressing integration of multiple suppliers concepts like MSI (Multi Supplier Integration) and SMI (Service Management Integration) was already available.

• Business services

• Consolidation of business and IT services

• Integration of services to deliver THE business service

• Enable plug-n-play type of scenario for supplier services

• Enable consolidation/deconsolidation of services (Business as well as IT) along with the underlying supporting components during mergers & acquisitions or demergers & spin-offs

• Manage assets in the digital age addressing the need of multiple sourcing options that organizations has

• Manage knowledge spread across suppliers and ensuring that the same is retained with the business

• Enable effective evaluation of value that SIAM brings

So SIAM has to be something different. We tried to understand the reasons that triggered the need of SIAM starting with the observations from various research papers, OGC 's committee's report or initial concept outline on Service Integration and Management (SIAM) and the likes.

All of these led to creation of multiple models, discussions, brainstorming, chucking out one model after another and eventually post multiple iterations we finalized the Fluid-Pump Model. Now, was the time to test the model. Unfortunately a model for concept like SIAM will take years for successful testing in its entirety. This troubled us. How do we do it? We decided to split it into smaller modules and test the pieces across different engagements or customers. These led to further iterations and eventually the model took its final shape that it currently is in. 

We saw SIAM as a future approach or framework for Service Management and not simply IT Service Management. Some call this as Enterprise Service Management or Business Service Management. We call it Service Management in its purest sense. This is precisely what the businesses want and have started asking from its service providers.

SIAM has to enable:

... and many more.

This is what differentiates SIAM from other things that people confuse SIAM with.

Our book Making SIAM Work - Adopting Service Integration and Management addresses precisely the above points and that too not in theory. It provides a step by step guidance that can be used to adopt the model to an organizations specific needs. It provides the guidance for creating the organization for SIAM and then provides the steps that be used to adopt or tweak the governance structure as per the needs of the organization. We understand that SIAM cannot have one model fit all. Thus, the book addresses the need to design your SIAM organization based on the Fluid-Pump model (a mechanical analogy) that fits really well for SIAM. It provides templates that can readily used. We have done it all to make it practical and readily usable. 

It also provides the outline of processes that would enable SIAM besides the ones that can extrapolated or adopted from ITIL® along with the information systems that would enable SIAM. 

Book, next in the series will provide the SIAM process framework.

The Service-Mâché

By:
Rakesh Kumar 
Sumit K. Jha

A Papier-mâché is an amazing material. It can create amazing shapes that can surprise as well as astound you. After all, it’s just the pieces of paper bound with adhesives like glue and starch to produce strong material that can take any shape. While paper is the key ingredient, the art of creating a Mâché lies in preparing the binding material (can be a mixture of water and flour or other starch, mixed to the consistency of heavy cream or complex chemical glues) and smearing it along.

Future of products and services lies in our ability to integrate the capabilities. With more and more innovations connecting to each other, the venue for bigger innovations opens up. The idea of integration is not new, but this has always been understood in piece meals. Understanding it in the full, at all levels and developing frameworks for managing it is a prerequisite to fulfill the needs of next generation products and services.

It’s been already predicted by a few in the industry that the next path breaking products and services would come from small players. This just highlights the predicament that can be caused due to number of products that try to make sense for a business. While some of them can aim at specific customer needs, remaining and most of them would have to focus on how to integrate and collaborate. Like brokers!!

Variety of products and services with multiple suppliers pose challenges that do not meet the eye easily. While utility of services and products is enhanced by integration; the warranty, which includes availability, need to be maintained as per the business requirements.

A Gartner research estimated the hourly cost of downtime as USD 42,000 in 2005. Another study by Gartner in 2011 pegged the cost of IT downtime at USD 26.5 billion in lost revenue each year.  Neverfail’s Outages Report 2013 suggests that average cost of data center downtime across industries is approximately USD 5,600 per minute. This does not attribute the loss to brand value or reputation.

Unplanned downtime, an evil that is cursed by every business, feeds on underlying shortcomings of an IT organization to manage itself. These include:

• Reactive IT support and services
• Disintegrated processes
• Bad knowledge management across the organization
• Improper mapping of business needs and IT capability
• Lack of agility in IT to match business changes like mergers/demergers/acquisitions /spin-offs

All these get exaggerated in a multi-supplier (internal or external) environment and hence the need of integration ameliorates.

While there is a fair understanding of the need of integration in the market today, there is blatant confusion on the framework to be adopted. The frameworks too depict a conservative picture of their   applicability. Service providers have practically used their own capabilities as fences to the scope of integration frameworks, and this has resulted in restricted and rather insufficient research on the subject matter. That’s more so is a reason why we see so many frameworks, each, ironically, requiring a need of further integration.

The concept of integration has taken all these forms with one form differing from other in many aspects. The common concepts used are SIAM (Service Integration and Management), MSI (Multi-Supplier Integration) and SMI (Supplier Management Integration). Surprisingly, many use them interchangeably. Below is simple deciphering of a few:

1. Legacy SI: Typically such suppliers are traditionally responsible for some of the process of Service Operation and Service Transition. They drive CSI for the activities (or technical towers) they own. If organizational processes for these lifecycle phases are available, they would follow these processes else they would use their proprietary set of processes. In many cases it has been experienced that either the documented processes does not exist or it is not followed. We can say that in Legacy SI the degree of process maturity is low.

1. SMI: SMI are responsible for all processes of Service Operation and Service Transition besides most of the processes of Service Design. A matured SMI drives CSI for the processes that are in the scope of SMI across the suppliers. It is process driven as the basic building block is a centralized service management layer. It has a high degree of process adherence and process maturity.

1. SIAM: SIAM is responsible for the entire lifecycle of ITSM. It drives continual evolution across the lifecycle phases and the suppliers through CSI.

However, the standard approach or framework has still eluded the industry.

The future of services is demanding. While resting on the shoulders of multiple suppliers, these call for -  better customer focus, alignment of business strategies, policies & objectives, return on value (ROV), proactive operations, technically advanced tools & platforms, governance across all layers and heavy automation; a comprehensive framework is needed that can address all and has space for improvements.

Not just to achieve seamless integration, this framework must be practical and aim to enable organizations with:

• Ideation and conception of new products and services

• Innovations

• Faster response to market dynamics

• Smoother production and delivery of products  and services

• Satisfied workforce
• Cumulative knowledge for decision making
• Continual improvements

Meanwhile, should provide means to realise investment done in people, knowledge and technology.

SIAM is the concept that encapsulates all the above and when looked with broad sight, can reap benefits to businesses IT and Non-IT alike. SIAM must be implemented with a larger roadmap that looks at the strategic needs of the business while being able to deliver tactically. The suppliers must be enabled to work in tandem to yield synergy and innovation. The supplier’s addition and removal must be made efficient and so must be the creation of new products & services. A feedback mechanism should ensure that the right information flows for continual improvement of services. And the visibility of services must be ensured to business and management.

The Service-Mâché is going to be used to shape the businesses of future, with suppliers as paper strips and SIAM as the glue. How strong the glue is, depends on what it’s made up of.

The book on SIAM 'Making SIAM Work - Adopting Service Integration And Management For Your Business' from the authors tries to address the need of an approach or model for SIAM along with the above aspects of the Next Generation IT organization. It suggests a model for SIAM and the way it can be implemented in a practical manner.

Multi-Supplier Management: Supplier Engagement Model

SIAM and SMI will provide a service management layer that enables integration of multiple suppliers while for SI the outsourcing organization will have their internal framework or best practices that they adopt. In a multi-supplier engagement, irrespective of approach (SIAM /SMI/SI) you adopt the challenge always remains that how you manage your suppliers. This situation is complicated since no standard framework is available. Organizations have to entirely depend on want their consultant or service provider tells them.

Following figure depicts a vendor engagement model that can be used for any multi-supplier engagement approach:

Multi-Vendor Management Approaches - SI, SMI and SIAM

In continuation with the previous blog on Multi-Vendor Management Approaches, I would like to describe these approaches based on our understanding of how SIAM should be. I would reiterate that the way current models/approaches are designed, I do not see any significant differences between these models. Based on our research, myself and Rakesh have created our SIAM - Fluid Pump model. I would talk about it later as currently we are looking for publishing our model at a larger forum.

1. SI (System Integrator): This was the traditional approach whereby outsourcing was done to one or multiple suppliers and these suppliers were managed by the outsourcing organization themselves. There was minimal or no integration between the suppliers. Service Management existed in an ad-hoc fashion with each supplier having their own organization for service management. Matured organizations set up a Service Management Organization (SMO) to ensure some level of integration and manage the key operational service management processes (like incident, problem and change management) where interaction between multiple suppliers was required. From an organizational perspective the services provided by these suppliers predominantly lied in the operational layer of management. Some of the SIs eventually started playing the role of Service Integrator which was a precursor to SMI.

2. SMI (Service Management Integration): With the need to have a centralized service management and control on multiple vendors, one of the large suppliers started to play the role of a lead Supplier or lead Service Integrator and eventually the role of a lead Service Management Integrator. This approach is termed as SMI. In this case the overall strategic functions and some of the tactical functions are performed and managed by the organizations themselves. In most matured scenarios also all tactical functions (like managing overall service levels) are not performed by the lead service provider. But in maximum cases these have been limited to having a centralized service management tool and overall governance of operational processes. From an organizational perspective SMI lie in the operational and tactical layer of management.

3. SIAM Service Integration and Management: SIAM is an approach that drives service management from the strategic perspective. It provides greater control and flexibility to not only manage the suppliers but also the IT & business services. It is more like a mechanical control system. It creates a layer that establishes an effective communication, management, feedback and control between the business and suppliers. It ensures effective dissemination of organization's business direction and strategy across all suppliers. It provides the control that ensures governance, management and regulation of suppliers and business services. It offers the flexibility to simplify the transitions due to change of suppliers or due to change in business services, system and processes which may happen because of merges & acquisitions or demergers & spin-offs. It enables business oriented transformations across the suppliers and business services. From an organizational perspective SIAM spans across all the layers of management - operational, tactical and strategic.

This approach is applicable to the entire breadth of business and IT services that may be provided by multiple subsidiaries of business or suppliers of IT (internal IT or external suppliers) regardless of number of business or suppliers.

Evolution of Multi-Vendor Management Approaches - SIAM, SMI and MSI

For a significant time now we are seeing that businesses no longer depend on one IT service provider. There has been a shift whereby business relied on multiple service providers and in many cases there has been more than five IT service providers catering to a single business. Businesses reaped the benefits in terms of cost but what was overlooked was the complexity that would arise in managing multiple suppliers. The benefits were eventually offset by the complexity. This was a time when service integration as a concept evolved. Service providers started pitching themselves as service integrators.

As a result of the complexity in managing multiple suppliers, last couple of years has seen another shift whereby the businesses have started focusing on vendor consolidation and restricting the number of suppliers they engage with.  Gradually businesses have put forth a strategy whereby one of the suppliers is selected as lead supplier and are given an additional responsibility to manage other suppliers which is predominantly from operational perspective.

During this time concepts called Service Management Integration (SMI) and Multi-supplier Integration (MSI) evolved. Majority of leading service providers or service integrators have created their own approach or model around SMI.

Also, during 2012 OGC felt the need to have a framework or approach around service integration and management of service providers. They named this approach as Service Integration and Management (SIAM). Also, a work group was constituted to create and detail SIAM. This working group had come out with their initial work but before the concept could have seen the light-of-the-day Axelos was created (decision on formation of Axelos was taken in mid-2013). I do not have any information regarding what happened to the investments and work of the working group.

This also resulted in number of SIAM models or approaches coming to the market led by Accenture, IBM, TCS, Capgemini and Atos. Off-late other service providers like HP, Wipro, etc. have also been pitching-in.

Since the conception of the SIAM working group by OGC, I had been following the developments and doing my own research towards what business challenges are and what should be covered as part of SIAM. I have been working along with one of friends, another ITSM expert, Rakesh to create our own SIAM model. This model is based on our extensive research in this area. We are calling this model as SIAM Fluid-Pump model inspired by the mechanical concepts (Though we are not mechanical engineers J) we learnt during our engineering days.

Market already had SMI (MSI as an approach did not really convert into a model or approach adopted or named by IT service providers) and various service providers including Capgemini has their models named after SMI. Then, why do we need SIAM and SMI.  Are these two approaches same? Additionally number of organizations and service providers has Service Management Office (SMO) responsible for managing service management processes with some of the activities spanning across all the IT service providers for a customer. This threw up another question for us - How is SMO different?

These questions had troubled us a lot. We got our answers as our research progressed. I will describe these concepts in my next blog providing a clear demarcation between these approaches.

Please note that my descriptions are more from the way these approaches should be and may not fit into the way things currently are. In most of the models that I have seen, I do not see any difference between SMI and SIAM. At times SMO also looks too similar.