IT key to integration success

How do you decide what level of IT integration is appropriate after a company merger?

How do you decide what level of IT integration is appropriate after a company merger?

Catherine Doran is European CIO of online financial services company Capital One. She has worked in IT for more than 20 years and has been involved in a number of high profile mergers and acquisitions, writes Ross Bentley.

She says that the main IT considerations in a take-over revolve around what level of integration is planned for the IT systems. "The cost of the technology integration should always be taken into account when looking at the feasibility of a merger or acquisition, although it should not be the determining factor," says Doran.

"Companies merge for a whole raft of reasons and if the margins are so tight that you cannot incorporate the appropriate technology integration - I would tend to think that the deal is not suitable anyway."

But once the decision has been made to merge two or more companies there are several types of integration models to choose from.

One is to bring the target company in as part of the group but maintain it as a stand-alone business in its own right. Here the level of integration involved is quite small.

But, says Doran, "If the plan is to acquire a company and to bring it in as part of your stable then there could be different levels of integration involved."

For instance the back-ends can be kept separate but have an integrated, customer-facing front-end.

"I tend to think this is not really a long-term strategy," says Doran. "It is more of a phase one integration stage that makes the customer feel that he or she is talking to a combined entity because the customer-facing front-end is consistent, while under the covers there are two separate back-ends."

However in the long term the costs involved in maintaining two systems make this model impractical.

"One reason that companies merge is to reduce costs through economies of scale. Running two systems will incur more cost. If, for example, you wanted to launch a product you have to update two systems," says Doran.

Another option is to go for total integration at the back-end. One way of achieving this is to take what Doran calls a "pick-and-mix" approach. "For example, one side may have the best ordering system and the other the best complaints system. You develop one system by combining the best of each."

While it may sound appealing to take the best from both worlds, it is complicated because there will inevitably be lots of interfaces to be developed between systems. Doran says that in this situation, it is usual to find that different data fields purporting to hold the same data will have defined things differently and will have stored them in different fields. Trying to integrate disparate systems can be a technical nightmare.

Another model for back-end integration is to choose one whole system to apply across the whole new company. But how do you decide which one to choose?

Doran says, "Looking at the technology you must ask yourself how old is it? How costly will it be to maintain? How clean is the data? Is the system future-proof? Will the system scale?

"Take, for example, a scenario where a small and a large company merge. It could be that the system belonging to the smaller company has cleaner technology but the larger system is more scalable. When faced with these dilemmas, you must base your decision on what is the best system for the business."

Once a merger has been agreed the next step is to decide how to allocate work to your IT team and to set down a timetable for the integration work.

"When you merge two companies you have two lots of IT, two IT departments," she says. "Within each of these you will have people who tend the day-to-day IT and those who work on business development projects.

"After a merger some projects will not be relevant and you can use this slack in the system to redirect people towards integration work."

Doran is quick to emphasise that managing the people issues is an important part of spearheading any merger. "It is an uncertain factor in the whole process and you must prepare for these issues," she says. "You can rest assured that IT people in general take a pride in the systems they have developed and that there will be an emotional attachment as well as an intellectual one."

But, she says, at the same time people can be enormously pragmatic and they will put their shoulder, to the wheel if asked to do so.

"My philosophy is that 'people are all grown up' and it is best to be honest and up front with them, obviously taking into account commercial and other confidential considerations."

Post-merger integration options
  • Stand alone: if the newly-acquired business retains its identity as a separate company within the group the amount of technical integration required will be minimal

  • Front-end integration: a first phase integration that makes the customer feel that he/she is dealing with one merged entity. With two back-end systems maintenance costs will be high

  • "Pick and mix": take the best applications from each system and integrate them. Because of the many interfaces that will have to be developed this can be complicated and expensive

  • Wholesale adoption of one system over another: before you decide which systems to go with you will have to conduct some in-depth evaluation based on the business needs of the newly-formed company.

Read more on IT for small and medium-sized enterprises (SME)