When ITSM is (mis)sold as SIAM

The Problem

Recently, I went in for a proposal discussion with a large business whose incumbent had already deployed SIAM for them. In their Request for Proposal, they had asked for a SIAM solution and had laid out the challenge in their current solution. Furthermore, the delivery team helped with insights into the operations, which pointed to very basic operational issues. As it is not common for issues to surface easily, I was not surprised.

Their issues involved:

  • A deceptive view of service performance. All their Service-Level Agreements (SLA’s) metrics were green, while customer experience was declining (Watermelon effect).
  • A very long time before requests were fulfilled (internal or external)
  • Lack of basic tools to resolve supplier dependencies
  • Overall Slow-moving processes
  • ITSM tool workflows making the overall process very complicated

Additionally, there were Supplier management challenges, which included:

  • No clear accountability on Supplier Services. In fact, the SIAM layer caused a loss of accountability
  • No reports to reflect the overall health of services
  • Aging tickets that had no mechanism for correction or control
  • A collaboration agreement with terms for penalties, but no means of enforcing them

Overall, their services struggled with basic service management, under the wrapper of SIAM. And this is not uncommon, it is something we see a lot. I am not very surprised either.

SIAM and ITSM

While many would agree that the difference between the two is big, some may say that they are the same (except for the additional topic of supplier management). The uncertainty relating to the definition and positioning of SIAM is widespread. IT service providers have used ITSM and SIAM interchangeably to suit their own needs. This lack of distinction has helped a lot of service providers sell ITSM as SIAM. Customers buy into this, purely due to their pressing challenges in managing supplier services.

So, what’s the clear distinction between the two? The simple answer lies in the mindset with which these two need to be deployed in the organizations. While ITSM was established to manage IT services for the business, SIAM is aimed at providing governance and control to these services on behalf of the business. This makes them very different.

The Reasons

Replacing ITSM with SIAM without adopting the SIAM way of working or its thought process, may not have been intentional by the service providers. The IT service providers wanted to adopt this concept as it suddenly became a hot topic. Although it conceptually remains simple at a high level, it needed a lot of work for building practices and a support model. This would, however, be time-consuming and cost-intensive. Just replacing the terms would have been an easier option.

However, what worsened the problem is a simple lack of governance and focus on updating the concepts and practices as SIAM evolved, during the contract period. Service providers wait for the contract to end or be renewed. This usually can take about 5 years, which is enough of a period to cause the problem.

Also, SIAM is usually sold as a cure for customer pains, which undermines the importance of participation of the internal stakeholders in the overall scheme of things. If not structured correctly, the customer tends to lose control and visibility on overall services, leading to the ‘Watermelon Effect’. The changing and increasing focus to get up to speed with the technology, usually, keeps managing the technology at the back burner, and such problems get swept under the carpet.

The Solution

There is not a simple answer to this complex scenario. What makes it complex is that the ‘watermelon effect’ takes time to get visible. By then the problem gets seeped into the roots of services and recovery becomes difficult. Also, it’s usually difficult for service providers to acknowledge the key issues, while they are in the same frame of reference. An outside view becomes necessary. So, the follow-up steps for customers (businesses) and service providers to improve should be:

Service Providers:

  • Invest in periodic assessments of current services: This helps in understanding the delivery challenges while increasing the overall maturity of services
  • Adopt SIAM practices not as a deployment but as an evolution. Ask for experts to help and create a clear roadmap for achieving your target SIAM state. This cannot be done in one day, no matter how mature you may think you as a service provider are.
  • Update and upgrade the workflows of SM tools regularly with the evolving processes. This is the most neglected thing once the tools are configured. Usually, Out of the Box (OOB) workflows, don’t naturally cater to SIAM scenarios
  • If you are not owning SIAM, make sure you have a robust model for fitting into an existing SIAM, this would at least keep your services out of the rot and help you take up the lead role in the future

Customer (Businesses):

  • Ensure your IT personnel play an active role in the overall use of SIAM. If that is not a part of the model, insist that it does. You can’t win a race by just cheering for the horse.
  • Get the help of experts in setting up collaboration agreements between the suppliers, and get them in place as early as possible
  • Invest in good SIAM partners, those who understand SIAM separately from ITSM
  • Understand that the contract is the only stick you have, so make sure the contracts contain the ways to use that stick as well.

Conclusion

Interchanging SIAM with ITSM has already caused a lot of challenges to the reputation of SIAM as a discipline. And avoiding this is a responsibility of both the customer (Businesses) and service providers. Both need to act if they really want to improve their services. The sooner it’s done, the better!!

About the Author

Rakesh Kumar is a Digital Transformation professional as well as a SIAM and ITSM author. He has 15+ years of experience in providing quality Service Management driven digital solutions to customers from various business verticals. Rakesh also has a background in architecture and design of next-generation technology governance. He has led teams of consultants in designing and deploying integrated automation, SIAM, processes, governance models, continual service improvement initiatives, and corresponding technologies for various clients across the globe.