Mergers Acquisitions Musings on the Role of I

Mergers & Acquisitions Musings on the Role of I. T.

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

Differences n In an acquisition, the buying organization absorbs whatever assets from the selling organization that it chooses ¡ n Selling stockholders & SEC must approve In a merger both organizations & cultures attempt to merge into a new or third entity ¡ In a merger, both shareholder sets approve

The base business model n n n 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 n Start with a no-bid vs. combined pro-forma EPS. XLS projection ¡ n 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 n n As the negotiations continue the “purchase price” & model deepens Valuation teams set-up to confirm & refine assumptions ¡ Fixed asset valuations n n ¡ ¡ Plants, land & buildings Data centers, equipment & systems Contract (labor) audits Intellectual property

Transition Planning n Different teams each take a part of the base plan to flesh out ¡ ¡ ¡ n 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 n n 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 n 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 n n n Mergers take much longer Strategy exists but less defined Need to confirm planning assumptions ¡ ¡ ¡ n 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 nontrivial and high risk

Execution: day 1 vs. day 100 n n 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)

Topic 2: Example System n n n Rapid. Commerce is an ASP (Application Service Provider) concept It provides the equivalent of a custom webbased catalog order system at a fraction of the cost 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 Office. Max for Industrial Supplies

System Development Life Cycle Bus. Case Vision Project Charter Project Estg/Plan Assess Budget Reqts. Defn. B. Reqts U. A. T. S. R. S/ Arch. Spctns Tbls & Src. Code Sign-Offs & Chk. Lst Tech. Design Acquire / Build Debug Deploy Plan Test Build Tests Exec. Test Assess & Post Mortem

Version 1. 1 Requirements n n 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 n Face to face meetings required ¡ ¡ ¡ n What was really wanted (vs. kitchen sink) What was the business value What is in the application (vs marketing) Confirmed V. 1. 1 ¡ ¡ Realistic iteration (Must, Should, Might) Black & white testable requirements Building block for future updates Use case oriented

V. 1. 1 Technical Design n Both Data Model & conversation architecture ¡ n 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 Used proven design & construction patterns

Summary CRM Physical Model (only 25% of tables)