IS FRONT-OFFICE OUTSOURCING POSSIBLE? Reply

In a word – Yes. Although it is probably not possible to outsource an entire front office capability it is possible to outsource key elements so that the capability is (i) better supported, and (ii) more effective.

OUTSOURCING TEENAGE PREGNANCY

In a particular UK outsourcing company the account manager of a Local Government account in a in a poor area once asked the CEO of the Council if he felt that more IT would help him. The CEO snapped back that unless the account manager could solve teenage pregnancy with his IT then to stop bothering him! The question remained: could we help reduce teenage pregnancy through the use of our services? At the time no single process or set of processes existed which was particularly focused on the reduction of teenage pregnancy. Social workers merely had a bag of blunt tools which they applied on a case by case basis, usually after the fact (or in cases of extreme and obvious risk).

It would be ambitious. The area in question had the UK’s youngest grandmother. She was 28. Many young girls saw their only way out of the poverty cycle was by falling pregnant in order to get a council house and benefits. Regardless of the social problems this causes the sheer drain on the public purse is immense.

On an investigative trip to India where the outsourcing delivery partners were visited the Use Case was put to them. 3 areas were focussed on:

  • Analytics. Analysing and correlating large volumes of data is key. This is not something that social services did nor could they do. Analysis would not only require the infrastructure but it would also need the personnel to input and interpret the output.
  • Security. Data security and anonymity is critical. Employing local people was a key differentiator of the vendor and sending personal data offshore would be sensitive. Data would need to be cleaned, anonymised and then transmitted. Only when analyses were made and returned would results be matched with identifying indicators.
  • Reporting. Reporting needs to be intelligent and intuitive. The analysis could not spit out typed reports but rather would need to target social workers directly and inform them of specific risks and link the risks to benefits, programs, policies and guidance in and around the entire area.

CONTRACTING FOR COMPLEXITY

Being part of such a complex capability would be very daunting for a business. Outsourcing vendors typically eschew complexity. Profit is based not only on an economy of scale but also on lower pay-band workers performing the tasks (typically in countries where labour is cheaper). Any increase in complexity adds the need for managerial oversight which adds the indirect (non-chargeable) costs of higher pay-band workers. Complexity is not good.

In order to avoid this in front-office outsourcing the vendor needs to get the customer to perform service orchestration. This is where the customer performs the oversight and configures the services as they wish. This does not mean that the vendor is just crunching numbers in the background. Rather, the vendor provides a level of human interpretation on the analysis as well as feeding them back into a vendor rep in the social services environment who can then ‘push’ the information. This last part is essential because the vendor is likely only to be financially incentivised on the basis of lower teenage pregnancy. Dealing with public service apathy and stagnant processes at a personal level is critical.

LEGAL LIABILITY

What if it goes wrong? Vendors are now part of vulnerable people’s lives. If something goes wrong who carries the liability? Should the vendor provide warranties for the services? Or simply guarantee results year by year? These areas are untested. However, it is likely that vendors will only warrant the technical aspects of the services which is not really front-office outsourcing. One way around this is to ‘own’ a number of key roles or at least the role specification. In this way they can realistically provide warranties for some of the outcomes.

In the end, front-office outsourcing is not only possible but it will be increasingly necessary in the future in order to provide vendors with the differentiators necessary to maintain profits. The most critical issues will be getting vendors to deal with complexity without paying too much for the additional risk and in a way which allows them to take on the overall liability as well. The front office is a prime source of differentiation but it can be ground captured by outsourcers so long as they are smart about both complexity and liability.

CONTRACTING FOR CAPABILITY: the future of outsourcing Reply

Outsourcing only works for vendors. It does not work for customers. Revenue curves for vendors show a slight increase since 2008 for global outsourcing growth but the picture is less clear for customers. When looking at the economic-value-added (EVA) for businesses before and after outsourcing deals most show a nett decrease, which is to say only that they are weaker after the deal but not necessarily because of it.

The reasons are myriad however there are a few standard reasons:

  1. outsourcing is usually part of cost reduction activities of panicking organisations.
  2. there is usually a nett decrease in headcount which wipes out the value-added aspects of reduced costs.
  3. the customer’s SG&A costs usually rise due to the increased management activity needed in finding and using information.

Due to these reasons there is a feeling in the market that outsourcing does not work despite the claims of vendors. Therefore, vendors have increasingly (certainly since 2007) seen themselves fighting for an ever shrinking slice of the economic pie. The greatest sources of competitive advantage have been reputations and economies of scale. All, however, have been scrambling for a differentiator that does not involve reducing their own profits.

MIDDLE-OFFICE OUTSOURCING

One large UK outsourcing outfit saw the writing on the wall. It felt that it would not be able to compete with the lower labour (and similar outputs) of India-based companies. It rationalised that eventually it would be squeezed out of the back-office (i.e. highly standardised financial processes) outsourcing and infrastructure hosting markets. It would, it rationalised, need to move into middle-office outsourcing. Front-office outsourcing, on the other hand, is largely fictional as it encompasses the customer-facing aspects of a business which is where the key differentiators are.

Middle-office outsourcing (such as a council planning approvals process) is unique because it involves less repetitive processes and sometimes ad hoc activities.  Success here is necessarily predicated on a flexible IT infrastructures (often service-based, i.e. SOA) and a sophisticated management which is able to choreograph technology-based processes and services.

COMMERCIAL CAPABILITIES

Being able to outsource the middle-office involves positioning the vendor into a customer’s capability. A capability is the ensemble of systems, processes, people and information/data necessary to do something. In business terms this means all the stuff that is necessary to perform a process. Technically, capabilities are specifications of an enterprise’s Value Chain, so in broad terms a business will have about 20-ish key capabilities. All capabilities are, necessarily, linked. The closer one gets to the front-office the more these capabilities need to (i) be performed and supported in real-time, and (ii) they also need to consume information and services from elsewhere in the business. For instance, in our planning approvals process example the vendor will have to (a) log approvals in real-time, (b) consume up to date information on structures and utilities, as well as (c) access information on business rules (i.e. council policy, governance, law etc). As with any outsourcing activity, more narrowly focused personnel on lower pay bands are used to perform tasks more ably supported by better technology. All these aspects not only add to the complexity (and therefore the price) but also to the potential liability. When offering low pay band workers to crank the handle on repetitive processes liability is something a vendor wishes assiduously to avoid.

DEFENCE CAPABILITIES

Capability is a term much abused but little understood in Defence circles. Much of this is because Defence does not use a standard value chain. Although there is a business model for most western Defence communities (Inform > Project > Operate etc) there is no need for a value chain because there is (i) no need to differentiate, and (ii) planning and financing is based on the use of ‘unlimited’ funds to confront external threats (i.e. Treasury tends to play second fiddle during war).

The military user will often class themselves as a ‘special’ customer. The defence industrial complex is a special environment for the simple reason that they are providing equipment which – if the enemy is successful – is useless to the customer by the time it enters service. Unlike the commercial enterprise, where such a situation would mean they lost some competitive advantage/margin, in the military such a situation is untenable. The purpose of a military capability is therefore to change quickly and radically over time in line with the threat. Corporate structures are notoriously incapable of maintaining the same tempo of development, even with lavish operational funding. The purpose of ‘Contracting for Capability’ is to solve the problem of commercial-lag whilst still providing a cost effective and commercially robust means of contracting.

THE CONTRACT: A COMPLEX ADAPTIVE SYSTEM

This is possible by viewing the capability environment as a complex evolving system which requires the commercial deal to be a complex adaptive system. This is not new to the law. Building and construction deals have been taking this approach for years and German franchising law has excellent precedents showing how risk may be judicially assessed throughout a large, distributed network of commercial entities – for a common purpose or effect.

Figure 1 – Shows how commercial deals fail to keep pace with and support military capabilities.

‘ROLES’ – The Key to Capability

The key difference between commercial and military capability is that in the military environment the vendor cannot own the people. In business, the customer will transfer the roles over to the vendor. In the military equivalents of the middle and front offices (i.e. front line and forward echelons) the vendor will never own the people. Soldiers will always perform critical tasks. This will remain a constant for some time to come as soldiers do not say (i) “the computer isn’t working”, or (ii) “do I get overtime?” etc.

Although a vendor cannot own the people it can own the ‘Role’ or the role specification, i.e. the processes, information and systems that a role uses. In this way, a vendor can support the core functions of a role without hindering the actual person’s ability to go outside the boundaries of that specification to ensure that something is done. For instance, a aeromedical evacuation must take place regardless of whether a computer is not working. The airman performing the tasking may have at their disposal a sophisticated orchestration of processes based on flight availabilities, supporting gunships, bed availability and surgeons on duty. However, if the network is down it is unacceptable to let a soldier die just because the computers are not working. That airman must now use their deep knowledge to work the radios and help save a life. On the other hand the military is largely incapable (and unwilling) to integrate the vast array of ICT necessary to develop the initial systems.

Figure 2 – ‘Contracting for Capability’ using commercial communities to support capability clusters.

COMPLEX CAPABILITY

The example of an aeromed evacuation is somewhat simplistic. The example above refers to the Deep Target Attack capability. This capability may be performed by submarine/ship-launched missile strike, aircraft or even Special Forces. The choice is a military judgement. In the case of a submarine launched method the enemy will try to prevent this through anti-submarine naval activity (ASW). The submarine needs to close to striking distance, reach launch depth and then withdraw safely. How is it possible to support such a process which involves very long and expensive R&D lead times, long into-service acceptance testing, new training and tight export controls as well as restrictions on the use and sharing of sensitive information?

The trick is to incentivise the commercial community to do some of the thinking for the military. Instead of having to wade through the commercial treacle of Defence procurement the following steps could be taken:

  1. Base contracts on Capability Increments. In this way, the vendor is obliged to keep pace with threat evolution and the development of capabilities.
  2. Outsource the Role Specification. This will ensure that the military community is forced to involve its commercial delivery partners (without being hamstrung by systems).
  3. Create Commercial Communities around the support to certain key systems/clusters of technology. This is similar to German franchise systems whereby all parties are legally obliged to discharge their contractual obligations in line with a common purpose. This will circumvent the horrific impasses usually experienced in alliance contracts.

Contracting For Capability is a logically sensible concept which simply builds upon the work already achieved in the Enterprise Architecture community (especially MoDAF, MoDEM and the IDEAS Group). It is not overly complex nor is it a step too far. Once again, the real question is whether Defence and industry have the sophistication and diligence to complete the task.

Develop Capability Not Architecture: the next frontier in ICT delivery Reply

In our previous blogs we outlined the key problems facing enterprise architecture, namely:  (a) overwhelming complexity, (b) poor integration of concepts, (c) lack of financial relevance, and (d) poor program choice.  The real problem with enterprise architecture is, however, architecture.  Rather it is the focus on architecture, equipment, kit or stuff which is the real problem.  Engineers do what engineers like to do best – build things.  Yet, in focusing on structures enterprises fail to take heed of the things that matter financially – functions.

In order to deliver benefit and value enterprise architecture must create a language whereby the ‘objects’ of financial analysis may be moved directly to the design community within a single model.  This may be as simple as the numbers on a spreadsheet or as complex as objects within a UML model.

One solution is through capability.  Capability provides us with the means to bridge the gap between the design structures of an organisation/enterprise and its functions – the primary functional model being the value chain.

The first level of decomposition from the value chain is the set of Value Activities (Porter provides no further guidance on decomposition and cost allocation).  A value activity is the key to differentiation, i.e. by arranging value activities in a unique way companies achieve a competitive advantage through differentiation of their value chains.  The specification of a value activity, however, is a capability.

Capability is already accounted for within defence architectural frameworks such as MoDAF and is defined as “the specification of an enterprise’s ability to do something.” Capability is the sum total of all people (roles), processes, systems and infrastructure necessary to perform a function.

Companies and government departments/agencies have many capabilities but all of them should be described at the same level (i.e. primary capabilities) and seen as the instantiation of value activities.  Otherwise, the term capability may inspire higgledy-piggledy capability and sub-capability definition.  It is our experience that deriving them directly from value activities is the easiest and most efficient means of capability definition.

Once performed, capability definition may be visualised similar to Figure 1.  Capabilities stretch over many functions and may not necessarily include all in between.  Moreover, once performed, capabilities mustbe checked against financial cost allocation to ensure that they match.  There is little point coming up with an ontologically correct definition of an operational asset if the finance department have assigned its costs elsewhere.  Given that the primary means of a capability model is for the efficient investment of capital it is best that the work is performed in conjunction with the CFO’s office.

Capabilities are powerful concepts yet poorly understood and implemented worse.  Capabilities have the ability to empower enterprise architecture and finally make it commercially relevant.

Enterprise architecture will fail to gain any traction within the corporate environment so long as it cannot achieve a meaningful link between finance and ICT.  When it does, enterprise architecture will hold the key to dealing with commercial complexity and organisational entropy.