1 / 16

Mergers & Acquisitions

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.

phelan-vaughn
Download Presentation

Mergers & Acquisitions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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.)

  9. 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”

  10. 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

  11. 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)

  12. 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

  13. 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

  14. 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

  15. 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

  16. Summary CRM Data Model

More Related