Outsourcing Monitor   -   November    2005 

The past and future of Outsourcing: from industry to the service sector

In 1913, Henry Ford designed the world’s first automobile assembly line for the Ford T. The product was innovative, by dropping the price of cars, Henry Ford tapped into a new market made up of people who could not afford to have a driver. The ships that docked next to the factory in Dearborn Michigan did not carry doors, tires or engines. Far from it, they didn’t even deliver steel; they carried all of the required materials in their rawest possible form.

There was a very good reason for Ford to opt for such a vertical integration: at the time there was no supply of tires or steel sheets! However for many years, Henry Ford still hang on to the vertical integration model until it began to endanger the company. Apart from being the only solution in those early days, vertical integration also sealed off supply of parts to other competitors and kept Ford in a monopolistic situation. When applied to a strategic advantage, insourcing can prevent competitors producing cheaper and better products.

 Nowadays, things are very different, automobile parts are widely available. The use of electronics in cars has boosted outsourcing even more basic parts such as clutches and engine parts are sourced by several manufacturers. Very different makes of cars are now made up from the same parts. Design and marketing are the main differentiators, nobody really cares who makes the engine that is under the bonnet and even a Rolls Royce is powered by a BMW engine.

 As information technology and seamless worldwide networks become part of normal business, in turn, back-office work that is frequently still performed in house will follow the same path. To do so, companies will first need to standardize business deliverables to be able to build entire services or products by using basic building blocks.

What fuels BPO? Drivers, trends and niches

In past issues, I have often mentioned that full outsourcing is losing steam, major contracts are being rethought and in some cases are being terminated.

In September 2004, JP Morgan Chase terminated a $ 5 Billion contract just one year after signing it. Normally companies start worrying about their outsourcing agreements two or three years into the contract. The situation changes, business objectives change and the people who believed in such a deal can also haved moved on. In this case, it was seemingly the merger with Chase that killed the deal. Nevertheless, the signal that the market heard was that outsourcing could be losing momentum.

The trouble is that other companies also terminated their outsourcing agreements, some where illegally set and had to be reissued, others were getting out of control and the new CIO had to act fast. In all cases, Full outsourcing was out and will not be back on the agenda of those companies before long time.  

Contract terminations last year

Notwithstanding the bad name that IT outsourcing may be getting in such corporations, there can be no question of returning to a vertically integrated model. Competition is fierce and other players will make the most of sourcing in a smart way. So many companies are turning to BPO because they believe that it is an alternative way of gaining economies of scale.

Such an assumption is very difficult to prove. Neverthless, service providers continue to offer business deliverables for a fixed price. Does it make sense? The problem is that, in most cases, such a unit price cannot be compared to in house costs.

For example, one BPO provider states that they can bill Euro 7 per employee paycheck. A recent PWC study shows that the average internal cost of a paycheck is Euro 12, but can a company base a major outsourcing decision on such a figure or study? They may not have any other alternative.

An example of a BPO niche: HR 

In the past, HR departments were not always user-oriented: as for many admin processes, service levels and clearly defined deliverables were not the standard. Just in the recruitment process, it was often the HR department which slowed up the process. Nevertheless, as we all know, human resources are the most precious asset of any company.

When downsizing, major corporations could no longer dare to keep on vast HR departments. For example, in 1990, British Telecom employed 15’000 people in HR for a global workforce of over 240’000 employees. As BT downsized, it cut even more of it’s HR staff and now only has 1’100 HR workers for over 100’000 employees.

The model that most corporations are using is a four tier model (see illustration below). Most queries can be dealt with by providing information on the user’s PC via an Extranet. Such a model may seem only adapted to office workers, however Volvo have equipped their factories with PCs and blue collar workers are using them to retrieve information just as well as their white collar colleagues. In fact, Volvo found that their blue collar workers in Brazil were the first to start using the system, sparking off interest and better acceptance by their Swedish colleagues.

Queries that cannot be satisfied by logging onto a PC are then routed to a call center. Attractive cities like Barcelona are now specialising in such companies, to such an extent that they can find native speakers of any European language in such locations.

Where should you build your call center to attract employees ?  

        London ?                                                                               or Barcelona …

In most cases between 25 and 30% of all calls are solved by such centers. Finally, only 5 % of all queries need to be dealt with by HR specialists.  

Using such an organization, companies have been able to drop their HR costs by up to 40%. At the same time, between 85 and 90% of all HR processes have Service Level Agreements.

Sources:

1. ADP Advisor Winter 2004, volume 4

2. Paul Taylor, March 2005,, Global Head HR BPO Siemens,  BME Global HR Conference Transforming and outsourcing HR Operations

Banks on the move: building new skills when migrating IS systems

Over the past few years, it has become more and more difficult to find a banker who is really happy with his information system. By enlarge most bank directors or chief operations officers complain about having an expensive and rigid Information System. Faced with fast moving business requirements and an ever increasing flow of new legislation, most Information Systems find it difficult to keep up. In the post 9/11 slump, banks struggled to cut their costs. They began to discover that an incompressible part of the budget was spent to simply keep their information system up-to-date. Designed in the 80’s most of their systems had been disorganised in the 90’s to be able to integrate unforeseen functions such as electronic trading or Internet banking.  

Ironically, until quite recently, not many banks have taken any major action to change Information Systems and to move to a more versatile and modern IS architecture. Nevertheless, there seems to be evidence that the situation is changing: now several financial institutions are undertaking major projects to migrate the very heart of the information system onto newer and more flexible systems. 

 Why are these projects being undertaken now?  What strategies should be used and what approaches are necessary when choosing a new system?  What are the major obstacles and how must banks learn to evolve to manage such projects correctly?

 A short study of several cases has revealed that there is a definite pattern and a set of approaches that are each adapted to different situations.

The reasons to change an information system.

 Cost

Maintaining an in-house system or an outdated package is far more expensive than running a modern package. However, given the risks involved in migrating an Information System, running costs alone may not be sufficient take such a major decision.

Time to market 

In many cases in-house systems are badly documented, the level of documentation dates back to a time when such issues were dealt with lightly. Knowledge and skills required to maintain and update such systems are beginning to be sparse.

 In addition, there is a vicious circle:  given that updating old systems take too long, there is no time left to work on the documentation. Therefore they become more and more difficult to update, each move makes the next one more difficult. After a while even small enhancements can take a considerable time to implement and changing the system can sometimes have some highly undesirable side-effects.

 Complexity

 The second law of thermodynamics states that the entropy of the closed system can only increase. In non-scientific terms, this means that disorder will always increase.  

In the case of Information Systems, a good initial design should allow evolutions and new functions to be integrated in a clean and efficient way. The trouble is that, under market pressure, in the 90’s, major extensions or extra parts were hastily added onto information systems. As a result, their capacity to continue to evolve in a clean and transparent manner has been considerably reduced. In addition, fashions and changes in information technology have also done some damage. It’s not uncommon to find a mixture of in programming techniques or languages within the same system.  

Considering that all of these reasons have existed for the last 10 years, why are banks now beginning to migrate?

Now is the time  

Over the past year, there have been an increasing number of major projects undertaken to replace in-house systems or switch towards more standard IS platforms. This activity contrasts greatly with the previous situation when many were complaining and almost nobody was moving. There is a set of reasons why the situation has changed.  

During the late 90’s, the Euro and year 2000 compliance projects had a double effect. On the one hand they prevented many banks from taking any radical steps to migrate Information Systems (the risk was too high). On the other hand, in some cases, they revealed just how difficult it was to update the existing Information System.

 After the year 2000, many banks launched studies to investigate how to migrate their Information System. The economic downturn in late 2001 slowed many of these projects down, but their determination remained. In some banks took another final look at incremental solutions such as partial reengineering but, by the year 2003 to 2004, several had already made up their mind to migrate.

Several ways, several strategies

 When studying the approach that various banks have taken to changing their Information System, it’s striking to see that there are several very different approaches. Each one seems to be appropriate for a specific situation. First let’s consider two different issues:

Does IT give the bank a competitive advantage?

 Information technology can be seen as a differentiator or not for the bank or financial establishment. For example, in the case of a partially competitive environment, such as that of state owned banks, information technology is not a market differentiator.  

For other banks who position themselves as business process outsourcers, information technology is a differentiator. Depending on their market position, Private banks use IT to support tailored solutions for their clients.

How wide is the range of services provided by the bank?

 The other major factor to bear in mind is the range of services provided by the bank. Private banks for example provide a narrow range of services whereas retail banks offer almost every kind of service. In turn this has an impact on the way that a major migration project should be designed.

 As described in the matrix above, depending on the degree to which IT is a differentiator and the range of services provided by the bank, the approach to changing the IS will be very different.

Business process reengineering approach.

Some banks provide the narrow range of services to their clients at the same time do not rely on IT to retain or gain new clients. Private banking branches of large European or international banks operating in Switzerland fall into this category.

 In such a case, the most widespread strategy is to integrate a package that has a good market share with as little as possible changes. In the case of the banks that we have mentioned, in the way of packages, there is one market leader and two challengers to choose from. As there should be no great need to tune the system to meet specific business processes, any sort of customisation will only increase costs and will not provide any gain for the bank.

 Depending on the size of the institution, it could even make sense to outsource part of the operations, provided of course that such a service is available. Choosing a very standard package will also ensure that there are sufficient skills and services available from third-party suppliers to help carry out the migration and provide support for the new system.

Integration approach

If IT is not a differentiator but the Bank has to cope with supporting a wide range of services, taking a package of the shelf and changing one’s business processes may not be sufficient. 

 As the range of services provided by the bank grows, the Information System invariably becomes made up of several systems or packages which are linked together. The Bank's information system is not homogeneous; instead it’s spread out within several packages or systems which are integrated together: the actual boundaries of the Information System can become pretty difficult to define.

 In this case the requirements of the future kernel of the Information System are easier to define by looking at the interfaces with each one of the other systems or packages. The successful system will have to be a package that is easy to interface with existing systems.

Toolbox approach

If IT is a definite differentiator and at the same time the scope of services provided by the bank is narrow, it makes sense to start by listing user requirements or functionalities that the future system should provide.

There will almost certainly be a considerable amount of customisation needed.  In this case, the most interesting system will be the most flexible one.

Development approach.

Banks for whom IT is a differentiator and who also provide a wide range of services are faced with the major issue: IT will remain a major cost.

It’s very likely that there is no package or off-the-shelf solution which can fit their needs. Outsourcing could reduce costs but it could also become a major problem: the outsourcer would inevitably try to gain new clients among the Bank’s competitors in order to become more efficient.

 Therefore IT remains an internal activity.

Each one of these approaches requires specific skills, processes and knowledge. It would seem that the main difficulty in migration project is being able to define which vital skills are needed. However well designed it may be, a project will fail if the wrong approach is being used or if crucial skills are lacking.

Personally, if I was going there, I wouldn't restart from here!

You may have heard the joke where a town dweller asks a peasant his way to a major City, after a while, the peasant calmly says “well quite frankly, if I was going there, I wouldn't start off from here!”. It may just be a funny story, but it also contains some wisdom. 

When changing their Information System, banks will also have to change their approach to the way that systems are implemented and supported. It’s just as important to know where you’re coming from as it is to know where you're going. Pictet's experience shows how vital it is to build up the right skills when carrying out such a project. Identifying missing skills and processes is a key success factor when implementing a new solution and they are not the same for all banks.  

There are many other interesting instances. For example, some banks are engaged in full outsourcing relationships and they could be tempted to move to a multiple sourced solution. The idea is pretty simple: buy the best of breed in the way of packages, integrators and hosting solutions. It all sounds very attractive; however, their current service levels are solely based on the availability of an application: they have no visibility of lower level service levels. In order to merely carry out a decent request for proposals they will have to master entire new fields. For example they will need to define and manage several layers of service level agreements for which they require new technical skills.

 However attractive the solution may be, it’s worthwhile taking some time to seriously evaluate the amount of new skills and processes that need to be implemented first.