Mergers & Acquisitions

Musings on the Role of I.T.

Outline

Differences The base business model Transition Planning White rooms Execution: Day 1 vs. Day 100 Example system

Differences

In an acquisition, the buying organization absorbs whatever assets from the selling organization that it chooses Selling stockholders & SEC must approve

In a merger both organizations & cultures attempt to merge into a new or third entity In a merger, the buying shareholders must also

approve

The base business model Keep all current customers happy

(from both sides) Use combined organization to cross

sell Selectively raise rates where you can Eliminate redundancies & use scale

economies to reduce costs Become one culture as fast as you can

The base business model Start with a no-bid & combined pro-forma

EPS XLS projection Transition costs accrued & expensed up front

Combined model high lights savings & revenue gains Time phased by quarter Assumptions noted Sometimes you’ll see probabilities & ranges in

the formulae

The base business model As the negotiations continue the

“purchase price” & model deepens Valuation teams set-up to confirm &

refine assumptions Fixed asset valuations

Plants, land & buildings Data centers, equipment & systems

Contract (labor) audits Intellectual property

Transition Planning

Different teams each take a part of the base plan to flesh out Are the assumptions correct? Go through each staff profile to confirm

gross head count numbers Go through each budget line item > 1%

Need to consider retirement planning sequence & interim systems

White rooms

Useful before M&A consummation Both organizations submit details

(with a key) to a 3rd party (white room) The 3rd party also receives a rigorous

matching algorithm The white room returns the keyed results

(e.g., joint customer list with defined overlaps by area, product line, etc.)

Execution: Day 1 vs. Day 100

Standard acquisition plans go quickly Strategy defined during plan 3 teams (front, back & plant) Simultaneous staff interviews based of file

reviews in one week Stay, transition or immediate termination 90-day switchover time frame is typical Almost always the buyer’s systems absorb the

acquisition’s “needs”

Execution: Day 1 vs. 100

Mergers take much longer Strategy exists but less defined Need to confirm planning assumptions

White rooms can speed it up Still need to review all contracts & trade

practices Transition teams go through a more involved

interview set as both firms are in play Switching over entire system sets is

non-trivial and high risk

Execution: day 1 vs. day 100

Even smaller firms can have 250+ separate systems

Each can integrate to several others and the well-defined interfaces may not be that “well defined”

Start at the front and work to the back-end systems looking for 1st order savings

Then reverse flow for final pass (or switch)

Example System RapidCommerce is an ASP (Application

Service Provider) concept It provides the equivalent of a custom web-

based catalog order system at a fraction of a single F.T.E. engineer

Focus on industrial suppliers of maintenance and repair items Lots of small firms with small budgets All have similar needs with many customers and

repetitive orders Think OfficeMax for Industrial Supplies

Version 1.1 Requirements What follows are the business

requirements Developed by Product Management

Input from key account sales calls Also based on his industry knowledge Also based on competitive product

reviews

V.1.1 Confirmed Requirements Face to face meetings required

What was really wanted What was the business value

Confirmed V.1.1 Realistic iteration (Must, Should, Might) Black & white testable requirements Building block for future updates

V.1.1 Technical Design Both Data Model & conversation architecture

DBA design too physical Sample design

Open Source oriented throughout Used the struts model Needed architecture statements for key pieces first Named Functional Specifications to not scare

people

Summary CRM Data Model