To get a grip on IT suppliers, organizations have to learn to exercise chain management. This means organizations taking responsibility for the functioning and performance of IT processes, and maintaining strict control over all the suppliers involved. How do you exercise successful IT chain management? What are the pitfalls and the quick wins?
A frequent error made when hiring in external parties is that one relinquishes ultimate responsibility along with the outsourced activities. In the event of poor IT performance, incidents or changes in the IT ecosystem, organizations expect the supplier to make an effort to maintain the guaranteed quality – and hence to take responsibility. However, the supplier only supplies part of a longer IT chain, and so frequently looks only to the SLA. How his component subsequently functions within the rest of the ecosystem falls beyond the scope of his responsibility.
Think in terms of chains
The reason organizations achieve success with IT chain management lies precisely in the two words of ‘chain’ and ‘management’. By a ‘chain’ we mean the entire IT ecosystem that is connected with the provision of a certain IT service. Take a service department, for example; in addition to all the links with the IT infrastructure, multiple applications and departments have to communicate with each other in a shared IT chain. During his customer journey, the end user depends on the entire chain, consisting of separate components. In the chain, some components are outsourced and some are managed in-house.
For example: the mobile service app was developed and is managed offshore (location A), and sends messages to the service desk application, which is managed by an IT department at location B. This application is also used by call center staff at location C, and the follow-up to service requests is in turn pushed to a workflow at location B. All the collected data is processed and stored in the data center at location D, while the infrastructure is outsourced at location E.
Such IT chains support primary business processes and, in doing so, are entirely dependent on IT components, outsourced or not. This makes it even more important to understand what the chain consists of and how the various components work together. To get a good overview of your IT chains, it’s a good idea to start with business processes: which service or process is supported by this chain?
More than the sum of its parts
When outsourcing IT components, the client and the supplier enter into standard SLAs. Among other things, the agreements cover availability ratios within business and service hours, and how long an incident is permitted to last. With the help of technical monitoring, both the customer and the supplier can keep a good eye on this. In practice, however, these agreements prove inadequate. End users still experience slowness, the cause of incidents is unclear, or the service goes down at busy times.
And then the game starts: the outsource partner says that all the lights are showing green, and other suppliers (application, network, VDI, database, etc.) are also complying with the SLA for their part in the chain. None of the suppliers feels responsible for the functioning of the entire chain, let alone for the performance of this chain. In the meantime, a business process breaks down, with all the consequent loss of revenue or harm to image.
When multiple suppliers or technologies are involved in a chain, the likelihood of malfunctions rapidly increases and the IT chain becomes greater than the sum of its parts. If, in accordance with the SLA, components A and B are each allowed 10% downtime and the service desk application’s functionality depends on both components, the likelihood of downtime increases to A + B = 20%. The problem gets bigger as the number of dependencies in the chain increases.
Keep the control
Because your own organization remains responsible for a successful business process, including the underlying IT chain, it is important to keep the reins in your own hands. Arguments and blame games with suppliers and partners cost a lot of time (and hence money) and, in most cases, lead only to patches. There are various ways to keep the reins in your own hands, and that already starts before anything is actually outsourced. Make sure you know how the chain was performing, and at what expense, before it was outsourced. Then the functioning of the outsource partner can subsequently be compared with the previous situation.
You can also make specific agreements with the supplier, based on the chain instead of the individual component. An eXperience Level Agreement (XLA) can help here. In an XLA, agreements are made on how optimum customer satisfaction can be achieved. In this respect, it stands back from technical components and looks at the chain from the end user’s perspective. With an XLA, value takes priority over legally covering risks. XLAs are becoming increasingly common, including for major sourcing parties. Specialized parties can assist in drawing up such documents
Of course, this has to be measured in order to subsequently keep a grip on what was agreed upon. Ideally, this involves monitoring both the IT chain and the business process from start to finish. When end-to-end monitoring is set up, all components in the chain are monitored from the end user’s perspective. It is not the individual components which determine whether the light shows green, but rather the combination of components in the chain – and hence the end result of these components. If components in the chain are taken from the cloud, this forms no limitation.
Quick win: A single point of truth
The great advantage of combining end-to-end monitoring of IT with monitoring of the business process is that the information is suitable for both IT and the business, and for the outsource partner. Everyone looks at a single point of truth, which prevents arguments. This immediately gives the manager of the chain a powerful steering tool. Whether it is a matter of accounting to the business, giving an assignment to the IT department or managing the outsource partner, there is objective evidence in support of the actions to be performed.
Furthermore, with outsourcing there is always the risk of quality loss. By objectivizing the functioning of processes, the migration to a sourcing partner can be better guided. As for IT, when a malfunction occurs, the domain can be quickly identified. After all, one can see clearly where in the chain a delay is occurring, which means it is also immediately clear which IT components are involved. This shortens resolution times, saves hours and can even acquire preventive value in the long term. If a chain component gets slower and slower, one can take action before it has an impact on the process.
Pitfalls of IT chain management
For successful chain management a new mind-set is required and a product that gives a detailed view of the performance of the chain (end-to-end monitoring). Once this is in order, the major pitfall comes: are the right people involved, and have processes been set up to enable chain management to work in practice? Because once that single, objective point of truth is on a dashboard, there have to be people there to see it and respond to it.
This means the chain philosophy has to spread beyond the chain director alone. What is expected of an application manager when the process is slowed? Which departments and parties are responsible for which component, and how are the processes around this organized? When is a role assigned to the business owner? And when is ‘good’ actually ‘good enough’?
All in all, IT chain management is not only important for keeping a grip on suppliers; it is much more than that. With the increasing number of IT-directed processes, the organizational ecosystem increasingly acquires the role of ‘director’ instead of ‘producer’, and IT chain management therefore becomes an indispensable competency.
Contact our experts!
More about this topic? Contact our experts to find out!
