Reading or Repairing Information Technology before or after a Merger or Acquisition

By Joseph Venturelli

 

Here I provide an approach to smooth the process of merging two IT organizations when their companies are contemplating or undergoing a merger or acquisition (hereafter called “merger”) The goal is to develop a working model that can be used in either situation.  This model can also be deployed when a manager or executive comes into an organization that simply lacks standards and suffers because of it.

 

Based on work that has been done, and drawing on research written by others, I present an approach called ICSO, which is explained below.  The goal of ICSO is to improve efficiencies in IT in order to get the house in order either before or after a merger or just because that needs to be done to drive business value.

 

As a preview, some actionable items we will highlight include:

 

• Focus on cultural integration.
• Find executive sponsorship with a steering committee.
• Migrate user provisioning and authentication systems (i.e., the user directory) to a single platform.
• Replace custom-code, where possible.
• Engage outside consultants, who are free from the burden of keeping current operations running, to guide the process.
• Appoint a strong team leader who has the personality to solve interpersonal and political issues.
• Capture metrics to track improvements.

 

 

The ICSO Process

I have taken past experience in merging IT operations and coined a term to describe it:  ICSO.

 

Don’t worry: ICSO is not another tedious acronym that you have to spend a lot of time to absorb.  It’s just what is called the on-the-ground approach of how to align the task of bringing the IT departments of two different companies together or readying IT at one company for a merger.

 

 

ICSO stands for:

 

• Integration: bringing together different systems into one.

 

• Consolidation: eliminating redundant systems.

 

• Standardization: implementing technical standards to help maximize compatibility, interoperability, safety, repeatability, and quality.

 

• Optimization: modifying a system to make some aspect of it work more efficiently or use fewer resources.

 

The goal is to build an enterprise class infrastructure to support growth and expansion through acquisition and to take advantage of the impetus for change, coming from the merger, to push that change and others through the organization.

 

 

 

Integration

First, let’s look at integration.

 

Different consultants often have different views as to what are the best practices for integrating two IT organizations.  This is good, as the superset of all their ideas lets one sort through what works best.  Here, we will look at several ideas and draw together their key takeaway messages.

The Intersect Group

The Intersect Group addresses integration in their document “Best Practices in Merger Integration.”

 

Here are some key points.

 

• Establish a strategic framework for decision making.
• Dedicate integration resources.
• Frequently assess cultural progress.
• Communicate early and often to measure hoped-for performance improvement versus realized performance improvement.
• Objectively and systematically identify the highest priority synergies (candidates for savings).
• Offer incentives to key people to stay on if there is an indication that the best people want to head for the door.

 

 

 

 

Here is a diagram from Intersect illustrating that the silo approach of yesteryear which is not the best way to move forward:

 

 

 

 

“The Wrong Approach,“ as you can see is department-by-department.  That cannot work, as a departmental manager, by definition, lacks the authority to make enterprise changes.  Instead a steering committee with executives on board should be brought together to ensure cross-departmental communications and to solve cross-departmental issues.

 

 

 

This leads us to what Intersect glowingly calls “The Right Approach:”

 

 

As you can see, the alignment here is across processes and not the departments.  For example, product development has to be plugged into changes in IT related to the products they are developing.  There is usually no one department called “product development,” unless it’s maybe a pharmaceutical business. As another example, “Operational Initiatives” can become drivers and guidelines for those changes.  And so forth.

Cultural Considerations

The Intersect Group makes the rather shocking conclusion that “80% of integration problems relate to culture issues.” We discuss that further below.

 

Imagine integrating two companies from two different countries with different languages and laws.  That would be a “cultural integration problem” in the Merriam Webster definition of culture.  But “culture” here means the way that the two organizations operate.  That includes what the process for escalating issues is, how the companies reward their employees, and everything from their dress code to whether or not employees have to pay for their own coffee.

 

 

McKinsey

The mighty McKinsey firm weighs in with their learned observations on how to find and create value in IT.

 

In a paper “Understanding the strategic value of IT in M&A” the author pens this phrase: “We’ve all heard about deals where the stars seemed aligned but synergies remained elusive.”

 

The author goes onto explain onto to say that:

 

“In these cases, the acquirer and target may have had complementary strategies and finances, but the integration of technology and operations often proved difficult, usually because it didn’t receive adequate consideration during due diligence.”

 

Ouch.  The strategic planners have just been being chastised for not doing due diligence.

 

McKinsey says that 50% to 60% of the synergies (i.e., cost savings that should arise from the merger) are “strongly related to IT.” So it is rather reckless if IT issues are not fully discussed in the talks leading up to that.

 

Here are the steps McKinsey cites to drill into and flush out those IT-related issues and opportunities:

 

• The merger specialists need to interview employees who actually work with the systems and not just the CIO or management. This would let them find out, for example, that it would take much more effort to integrate the supply chain systems than hoped for.  Or they might found out that the warehouse management system is riddled with problems and the vendors cannot fix those. Such interviews provides the merger specialist the chance to find out which systems don’t work well or whose architecture is too rigid to adapt to the merger and future changes in markets and product mix and the acquisition of additional companies down the road.

 

• These discussions lead to the decisions as to what systems to integrate, which to maintain as they are, and which should be consolidated. McKinsey suggests making these decisions quickly, but not in haste, to avoid a prolonged debate.

 

 

 

The importance of getting all of this correct is driven home in this graphic:

 

Graphic source: McKinsey

 

Here we see what one hopes to see when merging with another company:  lower costs. More than half of that comes from IT.

 

The McKinsey paper is written at a high level for the strategic planner, but among the specific items they cite that IT staff can relate to are:

 

• Use SOA. The service oriented architecture is the most flexible since it by definition has loosely coupled interfaces. Transactions are not popped off the JMS queue as with a JNDI model, but HTTP is used to retrieve transactions as JSON objects using REST.  That avoids the older way of using XML and SOAP which required some network changes. The internet requires no network changes. In other words, SOA using REST is not as complicated and is reusable. Plus it also lets a company more easily write mobile applications for existing web application, since the business logic is in the back-end application, as it is or should be with the web page.

 

• Some of what McKinsey says might be dated depending on what is the status of a company’s ERP system. Their paper was written in 2011, which is a long time ago for IT.  McKinsey says that synergies are realized when a company uses one over overarching system to run the whole business, i.e., the ERP system.  But Silicon Valley startups argue that a mix of SaaS components added onto some piece of the ERP system works best.  In other words, SAP does ABC best, but other applications do DEF and GHI better and cheaper.

 

Finally, McKinsey says that having a well-tuned IT organization can make a company a more attractive takeover target plus a company whose board of directors can command a higher price for their stockholders.

 

The opposite side of that statement is, “CEOs and CFOs should be wary of embarking on an M&A growth strategy that will require a lot of back-end integration if their corporate IT architectures are still fragmented: the risk of failure is too high.”

 

Consolidation

To achieve the realized cost savings from merging two operations requires collapsing different systems into one.  Consolidation is different than integration.  Integration means connecting systems whereas consolidation means shutting one down and then working on the necessary data conversion and user training to get everyone moved onto the new platform.

 

A consolidation is where cultural issues in IT can become an impediment.  Consolidation means that one department is going to feel threatened when the system they have been supporting for years is targeted for replacement. And then there are personalities. Lots of people do not adapt well to change, others embrace change, and then these are those with vested interests whose job is tied to running their fiefdom. This is where executive involvement and a strong team leader can keep the momentum moving forward. Employee incentives can also help.

 

Let’s take a look at one case study where both cultural and technical issues were a problem and how that situation turned out.

 

Case Study: Two Cellular Carriers

Here we describe a situation with two cellular companies that merged.  We will call them Company X and Company Y.

 

There was a bad omen hanging over this merger at the onset.  Their most basic asset, the cellular network, worked completely differently. Company X used the CDMA cellular standard while Company Y, with their walky-talky ability, used IDEN.  Neither used GSM, which is the main standard used around the world.  So the basic systems apart from IT could not be more different.

 

Beyond that their cultural was one company of grey haired managers running everything as they had done for decades versus a startup culture with lots of kids running around on skateboards, i.e., figuratively.

 

As to the IT integration and migration. That did not turn out well.  Someone made the ill-fated decision to integrate key sales and user provisioning systems.

 

The newly merged companies, having decided to integrate provisioning, was using both the Microsoft Identity Information Systems and Oracle Xellerate to onboard employees, contractors, store employees, and users at Walmart and other retailers where X and Y phones were sold.  The approach taken was to create interfaces between the user provisioning systems so that users provisioned in one system would be provisioned at the other company’s equivalent.

For example, there were two systems needed to sell phones, one for each company.  So an employee at each store needed access to both.  So users provisioned in Xellerate needed to be pushed to the MIIS System of the other company which would then provision them to that company’s cellphone sales system.

 

The systems basically fell apart because of load and because of software errors.  There were long delays in provisioning employees.  Support was so overwhelmed they simply quit reading all their email and responding to tickets.  Directors reached over the head of managers to work directly with the staff to firefight problems. Stores that had been newly opened had sales clerks standing idle, unable to sell phones because of days-long backlogs in the Microsoft system that could not handle the volume of data.  The Xellerate product at that time did not work well either.  It crashed multiple times per day.  That situation persisted for about a year.

 

In hindsight, the company in that case should have abandoned both systems and used something better.

 

Standardization

Open source software for programming and powering hardware has become so prevalent that it has educated people on the importance of standards.  Google, Yahoo, Amazon, and Netflix all have turned over key portions of their code to Apache where an army of developers from different companies and single individuals can contribute to that.  Ubuntu, which powers most Linux systems, Hadoop for big data, OpenStack VM operating system, and even some antivirus databases are delivered in this way.

 

Standardization also applies to processes, where it means using the same process across different departments. Finding those is tasked to the business process consultant working with IT.

 

Finding the Right Balance at Nestle

CIO magazine says that there is a balance between enforcing standards across the whole of the business and letting local organizations vary from rigid rules that do not work in all cases.  They point to Nestle as one company that has found the right balance.

 

One Nestle executive laid out the problem of disparate systems when he made the rather funny observation that, “We had 10 definitions of ‘sugar’ in Switzerland alone.” He went on to say, “There was very little global standardization of data, systems, or processes.”

 

Nestle took the difficult approach to enforcing standards, which was to adopt SAP, which is a heavy lift for any company.  But doing that led to developing standards.  Some of that was because they needed to change processes to fit into the software.  Other changes came from taking advantage of changes forced by the project to reengineer processes not directly related to SAP.

 

As the company moved from 30% to 80% of the company using standardized procedures, this had the added benefit of making it easier to acquire new companies.  Nestle backed off the goal of 95% for standardization when they realized that Swiss efficiency did not fit all situations and subsidiaries.

 

Among recommendations coming from CIO:

 

• Start with back office operations first.
• Pick good candidates for pilot tests.
• Get top management support.
• Build strong governance.

 

Past experiences have shown that if you are not familiar with the culture of the organization, you may find yourself struggling with the definition of the most simple of words like “done” and “everywhere”

 

Optimization

Optimization means modifying a system to make some aspect of it work more efficiently or use fewer resources.  Consultants like to say that, “Optimization drives business value.”

 

Optimization can apply to systems in different ways:

 

• Project management.
• Better integration between systems to reduce duplication and manual processes.
• Better utilization of computing resources–like moving networking, storage, and virtual machines to cloud vendors–to drive down cost per unit.
• Using SaaS components to lower costs yet obtain best-in-breed solutions.
• Training developers on new tools.
• Using Analytics.
• Taking inventory to see what can be cut.
• Paying close attention to security and cybersecurity as errors there run up costs and could lead to a potential disaster.

 

Project Management

There are a host of new project management techniques that speed the development of software and deliver results earlier in the project lifecycle.  Among these are Agile and Scrum and lots of other variations thereof. In addition to setting the focus on the most important items, these also push responsibility for testing onto the developers, thus gaining efficiencies with the testing effort by replacing the separate QA team with a smaller one integrated into the project team. Tests are also written as English-language programs before actual coding starts, further setting the focus on making the system work without spending time coding items not absolutely necessary.

Integration with Other Systems

Systems can be made better when manual processes are pushed onto the computer.

 

Better Utilization of Computing Resources

It may not not make financial sense anymore to buy your own storage array for archival when you can use Amazon Glacier for pennies per GB to do that.  And it may not make financial sense to make the capital expenditure to buy PCs to fill the racks in your own data center when you can rent virtual machines from cloud vendors.  Even DNS and failover can be pushed out to cloud vendors.

Using SaaS

You should not write your own shipping and receiving module when you can tap in UPS or FedEx logistics.

Train Developers on new Tools

Just when developers have learned Hadoop MapReduce, Apache Spark threatens to make it irrelevant.  The IT landscape is shifting constantly so skills need to adapt. There is no reason to write all your interfaces and new applications using Java, which is now 30 years old, when there are so many new tools that make programming quicker and less subject to errors.  One example is to use Node.JS for front-end programming.  It is an extension of JavaScript that makes creating web pages much easier than Java. Plus it addresses latency issues when one page handles multiple steps instead of transmitting lots of pages back and forth. Programmers should be free to use Ruby or Python or whatever gets the task done easier.  Plus it makes the developers happy to branch out.  Happy people do good work. If this sounds like it runs counter to the ideas of standards, it does not.  In this case the programmers are using international and not company standards.

 

It is not usually necessary to send developer to training, if you have good developers.  All you need to do is give them down time to watch tutorials and they will teach themselves.

Analytics

Analytics is the application of mathematics and statistics to business problems.  Analytics includes the more widely understood techniques of linear programming (optimization) and anomaly detection.

 

Analytics is widely used in application performance monitoring.  But it can also be used to measure the mean-time-to-close tickets and service level agreements. In order to measure progress with IT initiatives it is necessary to track such metrics.  Analytics also avoids turning lose resources to run down problems or issues that are not statistically important.

Taking Inventory

Datatrends mentions the common sense idea of taking an inventory of computing assets to see where there is more than is needed.  One target is software licensing.  Some products and cloud services are sold on a number-of-records, number-of-transactions, or number-of-users basis.  There is the potential for waste there.  Take the case of databases.  Old, stale records are not always purged from the system because it is difficult to do so due to the need to maintain referential integrity of just the difficulty of running that type of mini conversion.  So the customer is paying to carry data records that have gone stale.  That could be a good time to renegotiate with the vendor.

 

Summary

Getting ready for a merger or reacting to one lets a company focus on Integration, Consolidation, Standardization, and Optimization.  Having IT discuss their issues and involving them in the pre-merger studies warns strategic planners where they could be difficulties.  Having gone ahead with the merger it is important which systems can be consolidated and which should be shut down.  Any kind of change like this needs to be driven at the executive level and with outside management consultants who are freed from daily operations so have time to focus on integration.  Standards should be imposed across the organization on both systems and processes.  Leveraging the cloud is important by using SaaS components when possible.  All of this adds business value to the enterprise in both cost savings and negotiating the merger itself.

 

 

 

 

 

 

 

About the Author

 

 

Joseph Venturelli earned his degree in design from the School of Visual Arts in New York City.   His debut into Information Technology in healthcare began as a system administrator, concentrating on the technical oversight of information systems at Presbyterian Hospital in Charlotte, North Carolina in 1990.  Early on Joseph trained and became certified as a system engineer and certified trainer.  He has been responsible for leading teams of technologists including infrastructure, web services, data center operations, call centers, disaster recovery planning and help desk services, and has managed scores of system implementations over the past twenty five years..

 

Joseph co-led the creation and implementation of an electronic medical record system, which included full financial, transcription and scheduling integration.  Physicians were given office access to the scheduling and clinical documentation platforms.  This integration strategy created immediate medical record completion, eliminating the need for back end inspection and rework resources.  Joseph has consistently delivered efficiencies through standardization, recruiting and retaining key talent and launching enthusiastic customer service programs for a variety of professionals, patients and vendors.

 

Joseph has been published in numerous technical journals and industry magazines and has authored several books including one on patient advocacy.  A seasoned executive, Joseph has worked as the Chief Executive Officer for a Southeast Consulting firm, a Chief Information Officer for an Ambulatory Surgery Center company as well as the Chief Information Officer for a Midwest county hospital system and as the Chief Technology Officer for a New England Hospital System.