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 3 rd party (white room) The 3 rd 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 1 st 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