The System Integrator support challenge

Typically, companies choose to partner with a Systems Integrator (SI) to help them with their transformation programme. And rightly so. The SI will have experience in running this type of transformation, the technology (regardless of what it is) and its subsequent configuration/setup. They also know how to support it, both in the short and the long term. They, or a combination of multiple SI’s, are probably the safest way to deploy and support large scale technology change and the associated business process change that inevitably accompanies it. 

However, before you jump into a long-term agreement regarding support you need to think differently. The requirement is not the same as delivery and there are a few challenges and a number of significant points that need to be explored and considered. Make sure you consider these – AND ADDRESS THEM – prior to jumping into a support offering.

SI Redundancy

Let’s imagine a scenario where your SI is supporting your solution from a technology angle. They may have a technical team monitoring and controlling the technical layer of the solution, whilst a handful of their function consultants help with 3^rd line support. On a day-to-day basis, you may have an SI team of 10-20 consultants involved in your solution. That’s a considerable annual cost. 

Now, in a perfect world, you need to be continually innovating all aspects of your solution – including the support model. New releases contain new functionality to be explored – at all levels of the solution. And here lies the problem. As more and more functionality is released, the support model needs to innovate with the product, eventually creating a need for less support staff. This ultimately reduces the cost of support for the client (yay!) and reduces the recurring revenue for the SI (boo!). Will an SI push for this? Maybe/Probably not… The innovation creates a conflict of interest for the SI.

Ultimately, the SI needs a sufficient level of maturity to make themselves redundant due to the introduction of technology. They need to be volunteering ways to do themselves out of a job. The SI needs to view this as for the good of the client, creating obvious self-sacrifice, enhancing the value of the relationship – deepening and increasing involvement in the future. 

Integration to BAU

Another key aspect is the levels of integration with business as usual. If you look at any organisation, especially one the size to need something like an ERP platform, they probably already run a service desk and various ITIL or SRE related concepts.

Logically then, as part of the transition to hypercare and then into BAU, the balance of responsibility and control of systems moves away from the programme team and they transition further down the support model - into 3^rd line support. In its place steps the existing BAU process and team. 

Now, this can be a challenge for the programme team. During the programme, the SI and implementation team had a set of systems and processes that they controlled entirely. If they wanted to break those (for example, for an urgent change/fix), they could – under a degree of governance. The systems and processes were set up to match their requirements exactly – whether system monitoring, process mapping, ticketing systems, works orders etc. They all were designed by the programme to meet the needs of the programme. 

The challenge is that as the programme transitions to BAU, there is a tendency to maintain all of those systems and processes and ‘call it’ BAU. This is the easy route that most SI’s will take. The alternative is hard – all the processes need to change, controls need to be relinquished, and all at a critical point in the programme where no one really has time. You might argue that it is okay to create an ERP support island but remaining as-per-programme is very short-sighted for several reasons…

A. The new technology is part of a value chain

Your technology solution will form part of a value chain running through your entire business. It is probably fed from various upstream systems and, in turn, feeds various other downstream systems. Those systems are (hopefully!) all running their support through the existing BAU/ITIL processes. It makes no sense whatsoever to have half a process in one system and the other half in another. If a process is broken, it needs managing and problem management will only be hindered by multiple systems and processes. 

To add greater complexity, as we move through an interconnected world of marketplaces and value centres, it is likely that the value chain/supply chain will also move outside the enterprise. Organisations connecting with other organisations is challenging and any support structures need to be lean, rationalised and transparent in order to problem solve or innovate quickly.

B. You are doubling up on processes (and perhaps technology)

This one should be simple. Two sets of processes are not only harder to manage and govern but assuming they have a technology solution, they have an ownership cost associated with them (perhaps even headcount cost). You need to minimise operating costs wherever possible.

C. The user experience is confusing / terrible

Lastly, you need to think of your users. My guess is that during your programme you went to some lengths to consider user experience or design. Don’t ruin all that good work by confusing the user and trying to signpost them to multiple processes and systems to get something done. Whether it is a bug or a change, regardless of the system, the user should have a seamless experience wherever they are in the enterprise. 

Total Cost of Ownership

The TCO features highly on any CIO’s radar and, now more than ever, they are under significant pressure to deliver more for a reduced cost. Support costs, in the eyes of many, are an insurance/mitigation cost, and many execs struggle to understand the value they bring to an organisation. It is critical therefore that when working with an SI, you have a clear cost reduction strategy as the organisation matures and more automated capabilities/AI/Machine learning functions come online. 

Another key issue to consider is the distribution of work throughout the existing IT infrastructure. Businesses are complex, and the systems supporting them even more so. It is likely that there will be specialists supporting various systems and potentially overlap throughout system silos. The system silos need to be cut through and joint technology roles explored and merged. Specialists are, by their nature, expensive and hard to find/recruit/keep and drive up the TCO. There is no need, at times, to have multiple system specialists with the same underlying technology skill set, supporting only one system. 

Fundamentally the support organisation chart needs to be crunched and roles/work shared amongst technology skills, rather than system skills.

Why SAP Automation is Key in a Digital World
Download the ITOM Whitepaper Today >>

What next? 

In conclusion, SI’s clearly have a seat at the table both in terms of deployment and support. That is without question. However, before jumping into a contract with them, there needs to be some very robust conversations with them to ensure they have your best interests at heart. They should be working with you to integrate fully into your BAU landscape, driving down your TCO over a specific time horizon, aiding the CIO in their quest of delivering more for less.

    About the Author:

    Neil How is the Founder of Limelight Consulting. With a background
    steeped in SAP transformation programmes, Neil has over 20-years of
    experience working as an end-user for clients, as a consultant for SI's
    and as a freelance contractor.