mergers acquisitions
Download
Skip this Video
Download Presentation
Mergers & Acquisitions

Loading in 2 Seconds...

play fullscreen
1 / 16

Mergers & Acquisitions - PowerPoint PPT Presentation


  • 40 Views
  • 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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.

outline
Outline
  • Differences
  • The base business model
  • Transition Planning
  • White rooms
  • Execution: Day 1 vs. Day 100
  • Example system
differences
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
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
ad