Mergers acquisitions
1 / 16

Mergers & Acquisitions - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Mergers & Acquisitions' - mckayla-halligan

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Mergers acquisitions

Mergers & Acquisitions

Musings on the Role of I.T.


  • Differences

  • The base business model

  • Transition Planning

  • White rooms

  • Execution: Day 1 vs. Day 100

  • Example system


  • 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
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 model1
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 model2
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
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
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
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
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 1001
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
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
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
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
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