Integrating Service

Service Integration and Management (SIAM), and the closely-related multi-sourcing, are all the rage. What is the essence of integration, what do you get from it and how do you make it work?

I am suspicious of fashion, as anyone who has seen my wardrobe will attest. That there is a new management fad promotes interest in why it has arisen and what benefits it brings. It is not in itself a valid reason to adopt it. Pity those in sectors where a regulator or other centralised control unit imposes one model to fit all. It often appears that their rationale is unlikely to coincide with your benefit. Adopting a mode of apparel on the grounds of fashion may be forgivable, even elegant. Adopting an operating model on these grounds is neither.

A recap

In days of old when the mighty titans of IT ruled supreme, before the Indians had emerged from the primordial data-centre, the rule was that one outsourced to a big company who did everything for you. One-throat-to-choke. There was then little discussion of service integration. It was just that the one party was accountable for everything. Sometimes the costs for this hide within an un-specified element of the monthly charge, discrete from transactions such as desktops supported, MIPS delivered. Some argue that multi-supplier management has been around for years in happy obscurity. Yet, the emphasis on integration and contractual forms are new.

As cloud services and shadow purchasing emerged, some private sector innovators started to break up the old contracts and integrate themselves. At first this was done by the larger, better resourced and generally competent IT groups. The integration activity seemed to be large, expensive, non-transactional and of doubtful value to those who followed.  A great target to cut.

Early lessons

One of my first jobs as a freshly-minted graduate engineer was in the integration group of a machine design and development facility. Photocopiers and printers were designed as sub-systems: optics, document handling, output, electronics, software. The integration group ensured that all the sub-systems worked effectively as a unified whole.

The task of integration is a challenging one. In machine design, one starts by specifying the functional requirements, envelopes (space constraints) and interfaces for the sub-systems. The elemental teams go off to do their bit and pretty quickly come back asking for changes so that their sub-systems can be made to work in the context of their neighbours. A little more space here, a peak power requirement there, a tweak to the interface. Design is an iterative process. Anyone who believes that perfection can be reached in a complex machine or integrated service suite when the design is still on the page (e.g. after proposal and contract) is mistaken. Anyone who believes that perfection, once reached, will remain immutable is similarly one core short of a processor. Businesses change. Good plans and contracts are still important and serve as the basis of change, just recognise their limitations.

The outcomes

Businesses obtain value from IT when they use it. Service integration is one step removed from transaction processing. It does not in itself represent value delivered to users; its absence makes the product useless. Engineering in general has established that some degree of control and coordination are required if the sub-systems are to work coherently end-to-end. This is what users need of their systems.

ITIL suggests the definition of service management as “a set of specialised organisational capabilities for providing value to customers in the form of services.” Value is in turn seen through the achievement of business objectives. ITIL has not yet defined “Service Integration”, although the publication committee have doubtless spotted the opportunity to increase the library by another book, umpteen courses and doubtful qualifications to do so. The rest of us just do it.

Suggested Outcomes for SIAM

I suggest the following as desired outcomes of generalised service integration:

1. The services operate effectively in concert with assured customer utility, warranty and value.
2. Changes to services and to contracts are assessed, coordinated and implemented.
3. The levels of service provided continually improve and remain aligned to the business. Incidents that span services are effectively managed to resolution.
4. The parties work in a coordinated manner through the use of common process, consistent with their defined and accepted roles, the use of common information standards, data and tools, retained knowledge and contractual obligations.
5. Relationships and behaviours between suppliers and with the customer sustain services and the delivery of value to users.
6. The definition and consistent application of architectural standards support a coherent approach, infrastructure and interface.
7. All parties consistently deliver their commercial obligations and service levels.
8. The financial management of the service effectively allocates resource and validates expenditure.

The over-arching business objectives of going to a multi-supplier model are likely to include elements such as agility, economy, business alignment, speed of reaction and management of operational risks. COBIT is a useful source for the more generalised control objectives for IT.¹

The challenges

Whilst the above outcomes could equally apply to any model of service delivery, there are some challenges that become particularly acute where there are multiple suppliers:

1. Competition for budget. Where there is diminishing budget, competing business units who call for increased functionality and multiple suppliers fighting for revenue, peace and consensus are rare commodities.
2. Supplier turn-over. Customers used to be able to rely on rare, if traumatic, supplier changes. They could get away with paying scant attention to exit provisions in contracts (until it was too late) and where staff tenure was shorter than contract duration, knowledge retention seemed dispensable.
3. Service fragmentation. Suppliers receive payment in return for fulfilling their own obligations. Attempts to provide incentives based on end-to-end performance have a patchy record.  This leaves a dangerous gap between what has been contracted and business need.
4. Commercial management. Multiple suppliers, each with a thick contract, means a lot of detail to manage in performance management, deliverables & obligations and financial management. G4S, Serco, The Home Office and the Ministry of Justice jointly demonstrated the consequences of neglect.²
5. Customisation vs Standardisation. The capture of economy relies upon the use of standardised services, architecture and contracts. There is a tension between the adoption of market standards and the maintenance of customer intimacy. The deviation from standards can give short term benefit and flexibly at the cost of long-term complexity in maintenance and change.
6. Doing vs Assuring. If the retained function does not do enough, knowledge and skill wither. If the retained does too much, they risk undermining suppliers’ accountability. It inhibits supplier initiative and the quality of service suffers.

Coordinating mechanisms

I am occasionally reminded of what I was taught long ago in lectures. The research of Professor Henry Mintzberg was seminal at the time of publication.³ He reviewed the great expanse of literature on organisational structures and control mechanisms. Much of what he found is usefully informative of multi-sourcing arrangements, as it was in its original context of corporate organisation design.

Mintzberg identified five types of control mechanism and found them variously applicable to different parts of the corporation:

1. Direct supervision. Characterised by behaviour formalisation, vertical and horizontal job specialisation, usually functional grouping, vertical centralisation and limited horizontal decentralisation, action planning. It works well in young, small organisations notably those lacking heavily formalised and automated processes and dynamic environments. Mintzberg called this the “Simple structure”. Think boss – subordinate as a relationship.
2. Standardisation of work process. Characterised by behaviour formalisation, vertical and horizontal job specialisation, functional grouping, limited horizontal decentralisation. Commonly encountered in old, large, regulating environments with non-automated technical systems, simple, stable environments with external control. Minzberg named this the “Machine bureaucracy”. Think about production line operators working to procedure.
3. Standardisation of skill. Characterised by training, horizontal job specialisation, professional qualification, vertical and horizontal decentralisation. Commonly encountered in complex, stable environments. They are non-regulating , complex and suited to stability. Called the “Professional bureaucracy”. Think about lawyers or accountants exercising professional judgement in serving clients.
4. Standardisation of outputs. Characterised by market groupings, performance control systems, limited vertical decentralisation. Commonly encountered in diversified markets (particularly products or services), old, large organisations. Called the “Divisional structure”.
5. Mutual adjustment. Characterised by the use of liaison devices, organic structure, selective decentralisation, horizontal job specialisation, training, functional and market division simultaneously. Well suited to young, sophisticated and often automated technical systems. Called the “adhocracy”. Think about an advertising agency with teams coming together to run a campaign.

If measures and performance matter, it is wise to base the selection of these at least party to promote the behaviours and types of control that you wish to see as well as the outcomes you wish to attain.

Applying control mechanisms to multi-supplier services

The appropriate use of any management model is to bring clarity to the question “what are we trying to achieve here?” and thus “how best should we go about it?” and finally “How do we control it when we have it?”⁴

I have made an attempt to define the desired outcomes for generalised service integration earlier in this article.

As to the how, the typical multi-supplier model includes the following elements:

• Tower or other services.
• A retained direction-setting, governance, architecture and control function.
• Service management, commercial management, financial management, supplier management and relations with the sourced services (SIAM).

Applying Minzberg’s Model to SIAM

Applying Minzberg’s approach to these one sees:

• SIAM and Towers. Commonly purchased-in services (some may be internally provided with SLAs) managed as divisional structures. Principally governed through contracts to deliver standardised outputs, supported through standardised interfaces and processes. Traditional outsourcers are familiar with this as they are suited to stability (inflexibility). They set up once, running the structure efficiently.
• Within the Towers. Most suppliers run their accounts as semi-autonomous units for clarity of accountability, accounting and performance. In some suppliers this causes problems with their obtaining access to appropriate resources. Within the Tower, most operate by standardisation of work process with elements of standardisation of skill.
• Between the Towers. As for SIAM and Towers this uses standardised outputs, governed by contracts with the customer for dependencies and interfaces and by standard operating procedures.
• Retained governance to SIAM. Due to the dynamic nature of the need, a relationship close to Direct Supervision is likely to be applicable. Governance sets the direction and asks the questions (ideally prompted by SIAM), SIAM does the leg-work, research and deploys the direction. Contracts are present but are not flexible enough to govern much although they can limit elements of risk.

What many customers often appear to want is complete flexibility, characterised by the “adhocracy”. This they never see. Yes it is immensely creative, but it is also chaos on legs. It never does the same thing twice, a direct consequence of its creativity. If once they had this, they would instantly fire it for non-conformance. It can be brilliant, but awful too.

So what?

The essence of integration work is that it is focused on the outcome far more than the means. This is difficult to specify in terms of input resources, and thus to cost. It is difficult to measure in terms of transactions and outputs, so output-based pricing is tricky too. This makes lawyers and financial modellers nervous (if they look at it at all). If however outcomes such as lost service hours from failed change are used, it is far easier to measure the value delivered by SIAM. The alignment of interest would suggest that contracting on outcomes is the way to go. This takes a degree of confidence and experience, making input-based (rate card) pricing look more attractive to many. I can suggest; the choice is yours.

At the heart of effective operation has to be sound management, governance and judgement. If your organisation is one of those that turned to SIAM because it recognised (or was told) it lacked these three graces, you have a conundrum. The likely outcome is that you will find that the small number of talented and qualified people you need to exercise judgement is expensive, but it may just be worth it.

………………………

A version of this article was originally published in Outsource Magazine and is reproduced with permission.

References

1. COBIT 5, ISACA, https://www.isaca.org/resources/cobit ↩︎
2. A Contract To Transform ↩︎
3. Structure in Fives: Designing effective organisations. Henry Mintzberg. Prentice Hall International 1983 ↩︎
4. Business Models: A Compelling Story ↩︎