The degree of change required to transform service provision from a prime model to one that engages multiple suppliers is significant. The many strands involved mean that it is not a simple issue that can be bought-in and forgotten. In this article, I concentrate on the job of implementation rather than sourcing and seek to point to some areas that are worth thinking about.
Why do it?
In any major change, it is well worth being really careful first to make sure that the reasoning is clear, that this is shared and that it is never forgotten. It is common for effort to be expended in drafting a beautiful business case to gain funding, only to see it locked away, never to be used. Beware of unidentified and unquantified savings, particularly those that have no clear contributory link to operational improvements.1
The senior leadership team of a client some time ago had a huge diversity of views of what the future should look like. There was no shared picture. The rate of progress was glacial, much to their frustration. Every issue prompted a different response from each member of the team. There was no consensus on the route to implementation. Rather than solve the root issue, the dominant character sought to wade in and impose his view. This was greeted by howls of protest from others who could see its flaws. It did not take long for the imposed solution to fail.
Gaining real agreement is hard, but it is ultimately far easier than the alternative.
What does the Answer Look Like?
The major functions of a SIAM are fairly common to all organisations, although some may decide to draw the line between each element differently. I have seen a tendency to do everything at a very high level in some organisations, but that they have found it helpful to go to a medium level to become specific about which jobs should be done by each party. This brings clarity and stops a lot of arguments because there is greater common understanding. We undertook this by two of us first having a go at drawing the line between what should be done in each area. We worked from a small number of principles, as is common in Architecture development. This provided a “starter for 10” for a more broadly constituted workgroup. They quickly and efficiently shot through the suggestions, endorsing most, debating the few. This produced consensus and strong buy-in.
Having defined the boundaries at this mid-level, the next step is to identify options for the overall high-level Target Operating Model (TOM). Then evaluate these to identify the preferred and then overlay transition and risk before making a final decision on the lot structure and grouping of functions. I have seen this done well, and through less organised means. The latter produced a series of hotly debated stages supported by little evidence and many issues. The solution seemed to lurch from side to side in its approach like a drunken youth staggering home on New Year’s morning. It got there eventually, having gone out of its way to hit every conceivable obstacle, was thoroughly uncomfortable and rather bruised. The recommended approach is to start with the business case and the objectives it contains, using this as input to derive principles for selection. Generate options, evaluating each against the principles to find the best fit. The use of benchmarking can quickly and effectively give a rough indication of the financial aspects. The evaluation of risk requires the generation of an outline approach and cost for delivery. The recommendations and options are then walked around the organisation to test them before going for final approval.
Building it
The question of how many suppliers to engage will arise together with the grouping of Towers to Lots for procurement. It is likely that the achievement of savings and effective operation are likely to be important in any solution. Where the number of suppliers is small, the revenue for each is relatively high, so they gain economies of scale from the ability to automate and to recover fixed costs such as account management. This is to the advantage of the customer, who also has few suppliers to manage so saves on supplier management, reporting costs, and benefits from the simplicity of interactions. As the number of suppliers rises, these economies of scale rapidly decline in a non-linear fashion. Against that, the whole basis of multi-supplier thinking is that by engaging a number, each can be more easily replaced than where there is only one or few. Thus commercial competition is more likely to lead to sharper pricing. With few suppliers, the consequence of losing one is serious, declining rapidly as the number increases. These factors combine to point to an optimum number of suppliers that can be quantified based on benchmark evidence (at least for the first factor).
The process of changing over from a single prime contractor to an environment with many suppliers is a significant one. This is further complicated if there are multiple services (e.g. ITO, HRO, F&A) or a diversity of competences (e.g. SMEs with depth but not breadth). The approach that is recommended is to treat it as a business transformation combining:
- Strategy and governance to set the direction, define the benefits, control progress;
- Architecture, project and programme management, process improvement and people change to design and plan;
- Build and deliver the new state under project management. Transition the current work to the new suppliers; and
- Continual improvement over the life of the operation.
The engagement of competent suppliers can help greatly in this, but the customer will still find that it needs to commit significant internal resources. Governance and direction setting cannot be outsourced, although they can be informed by others. It is also likely that the customer’s retained organisation will need to go through significant changes of role. Many of the duties and accountabilities that were formerly performed by the Prime transfer to the customer.
There is a huge number of issues to be coped with concurrently. The number of stakeholders rises rapidly as the design is fleshed out. It is at this point that the quality of the original ground-work comes to the fore.
Some aspects are initially outside the control of the transformation team. These include regulators and potential suppliers. Such players cannot be ignored as success depends upon them. Some aspects of their behaviour can be predicted by turning to precedent in other implementations. Unless the planned approach works with these players and accommodates their interests, it is unlikely to be robust and viable.
The role of the SIAM concentrates on ensuring that the whole system works coherently. I have seen a range of approaches to supplier relationships. One was particularly robust and interventionist, admittedly following disastrous initial supplier performance. Another thought that to get the best out of the suppliers, it needed to create the right operating environment and take the suppliers’ lead. Love and peace would flow. Contracts did not really matter to them as these could be written as they went along. The tone needs to be set from the top, the governance body. If wise, they will take good advice on the implications of the choices made before settling on them.
The job of specifying the SIAM needs to start with a clear definition of what is most critical. What does it have to do really well? Where are the dependencies between the parties in the new world? Just as any good Systems Integrator concentrates on specifying the interfaces in a technical delivery, so must the builders of a SIAM in building a service operation. We put a lot of effort into identifying these dependencies, capturing them within our ITIL Framework for service management and our Governance Framework. Many of them came down to information flows. We reasoned that without knowing how the parties were to collaborate effectively in delivering end-to-end service, we could have no assurance that this would be achieved. This could not easily be bolted on after the initial construction. It had to be part of the operating environment before the arrival of the first player.
Some SIAM tasks are known to, but not really considered by the service managers I have dealt with. These include the validation of invoices, financial planning, tracking commercial obligation fulfilment and the preparation of issues for Governance meetings. ITIL talks in broad terms of many things, without their being within the comfort zone or experience of many service managers. To be effective, the SIAM must look both to the Towers it supports and to the Governance bodies it reports to, and ensure that their needs are supported.
Supplier change
The old world regarded contractual change as a horrible experience, to be avoided if at all possible. This was informed by the pain and grey hairs of customer operations staff and project managers, and by the understandable wish of suppliers to maximise the contracted revenue through writing long lasting agreements. Some of this pain was associated with building a new IT operating environment. Moving all the servers and network kit of a data centre is not a trivial task. Some of this will be reduced by the new world of the Cloud through the support of automation. I still shudder at the thought of getting all the firewalls right. That still leaves the process of knowledge transfer, operational process definition and training, contractual conclusion and people change. Most of this will be easier in the new world than the old. Contractual alignment will be harder, as the whole idea is that these are standardised. One supplier’s standard will not align to that of another to deliver end-to-end obligations or service.
The old prime contractors had banks of specialist staff on which to call. I know that many customers are rude about staff quality, but it is still one up on an SME or IaaS specialist who knows what its sweet-spot is and will not step outside it. The old world could flex to accommodate misalignment. The new world is standardised and far more rigid. It is undoubtedly a quick and simple process to stand up a new standard cloud SaaS service. It took me minutes with SalesForce, followed by the simplest of configuration for my modest needs. There is nothing in this that gives me faith that standing up custom line-of-business services will be much faster than the two years that it took a recent client to iron out their end-to-end service issues with their then new prime. Most legacy systems are not architected for deployment to the Cloud. It is worth being careful in the field of tooling as this makes a huge difference to the speed of setup.
In a world where there were few suppliers and long contracts, supplier change management was a skill that customers could afford to ramp down. Where contracts are short and suppliers numerous, supplier change will be a constant. This places increased demands on the quality of initial exit planning, writing in knowledge retention terms and buildingoperating and information infrastructure that will persist through the departure of any supplier (even the party that built it). This then needs to be kept clean and populated at all times. The old days of finding six months before contract termination that you have none of the design documentation relating to a critical service has never been good, now it will be fatal.
Will it Work?
The degree of change underway in the IT market at the moment is extreme. This creates risks. We are used to this. Enough have been working in a multi-supplier environment for long enough for it to be evident that the model can be made to work. In some markets, such as UK Government, early experience has shown more of what not to do than what good looks like. The management of multiple strands will mean that such a transition is never simple, but programme and management science has identified the essential elements necessary for success. So this can be managed reliably. Knowing this, the wise Sponsor will concentrate on ensuring that the A Team is ready and available to make it happen.
………………………
This article was first published in Outsource Magazine 2013 August 09 and is reproduced with permission.
