01
Management presentations
Global applications, technology operations, security and governance were reviewed with integration counterparts and company leadership.
Technology baseline← M&A Integration & Value CreationIntegrate first.
M&A Integration & Value Creation · Executive case study
Integrate first.
Transform with intention.
My journey through a multibillion-dollar global technology acquisition. Integrating two established multinational businesses required evaluating strategic alternatives, Day 1 and Day 100 execution, protecting customers and daily operations, managing cross-functional execution, and building the enterprise technology organization needed to support business value creation & synergy objectives.
$2.1BTransaction value (announced)
~$8BProjected combined annual revenue
~8,500Approximate combined workforce
01 / The business situation
Two global companies.
One operating future.
The combination expanded the business across broadband, satellite, video, networking and connected devices. Underneath the product portfolios were different processes, legal entities, systems, supply chains and ways of working. The challenge was to bring those operations together without making integration itself a source of business instability.
Commercial complexity
Customers could not wait
Quotes, orders, credit, delivery commitments, services and partner relationships needed to keep functioning throughout the transition.
Operational complexity
Global supply chains
Regional manufacturing, outsourced partners, logistics, sourcing, planning, quality and repair depended on different business processes.
Enterprise complexity
Systems behind every decision
ERP, PLM, CRM, HR, reporting, identity and infrastructure had to evolve together, with shared data and controls.
“The question wasn't just how to merge the systems. It was how to keep the business running while deciding what the combined company should become.”
The strategic tension
Integration speed versus enterprise risk
A fast technical consolidation could concentrate process, customer and financial risk. Excessive coexistence could perpetuate duplicated costs and operational complexity. The execution approach had to balance both.
Editorial synthesis of documented program tradeoffs, not a verbatim historical quote.
02 / Understand before you integrate
Understand the business before choosing the architecture.
The difficult work started before legal close: understanding two different operating models, presenting the acquired company’s technology landscape, testing process assumptions, and translating competing integration options into executable choices. The work took place under strict pre-close information-sharing rules.
02
Process gap analysis
Teams compared create, plan, source, make, deliver, returns and support—surfacing differences that software names alone could not explain.
Business process evidence03
Six integration alternatives
ERP and order-processing scenarios were evaluated for time, cost, continuity, tax/legal entities, change risk and future scalability.
Decision framework04
Governed Day 1 planning
Workstreams translated choices into readiness responsibilities, milestones, critical dependencies and legal boundaries.
Execution preparationExplore the integration journey
A new global business, before integration began
EVIDENCE BASIS
Why the pre-close legal boundary mattered
Joint planning could begin before closing, but the companies had to remain independent competitors until legal clearance. The kickoff materials established information-sharing restrictions and distinguished permissible planning from post-close implementation. Management teams could examine architecture and process issues without treating the businesses as already combined.
What the teams actually compared
Systems of record, automation levels, process owners, manufacturing differences, supplier collaboration, order promising, invoicing, planning, inventory, product data, finance, legal entities, tax impacts and migration cost. Sharing a software vendor did not make the operating models identical.
Management presentations and IT baseline
The May management sessions documented the acquired enterprise’s global infrastructure, corporate applications, BI, information-security and risk controls, Oracle EBS and product lifecycle management environment. The purpose was to expose operating dependencies early and make readiness requirements visible to the combined leadership group.
Process comparison: create to support
The July two-day workshops examined Create, Plan, Source, Make, Deliver, Returns and Support, including order flow, outsourced manufacturing, supplier collaboration, inventory practices, credit and billing, automation gaps and cross-border operating requirements.
What made the ERP decision consequential
The team assessed six initial alternatives, including consolidating on the parent or acquired enterprise ERP, adding an interim common order layer, and accelerating a future Oracle version. It had to manage costs, schedule, legal/tax processes, customer obligations and potential throwaway work.
How planning became an execution system
A joint integration kickoff established functional workstreams, initial Day 1 needs, a steering structure, a program office and action reporting. These processes were then carried into the post-close integration management cadence.
03 / The defining choice
Transfer, not transform.
The joint teams evaluated six initial systems integration scenarios. By January 2016 the program had aligned on transferring the acquired business into the parent's existing Oracle 11i operating environment rather than attempting a full simultaneous enterprise redesign.
POTENTIAL BUSINESS ADVANTAGE
COST / RISK TO CONSIDER
Decision principle: Choose an executable integration path for the immediate business, while retaining a separate longer-term architecture roadmap.
What changed immediately
Common customer order handling, financial and tax alignment, data conversion, process adoption and a common system strategy became central to the integration program.
What deliberately waited
Broad business process redesign, a future ERP generation and functionality unrelated to the initial consolidation were not the immediate integration objective.
Based on contemporary integration plans, program reporting, public disclosures and first-hand leadership experience. Certain financial and cutover outcomes require confirmation before production publication.
04 / Operate from the first day
Day 1 was a beginning.
Not a finish line.
The legal close took place on January 4, 2016. The integration team used January 5 as operational Day 1, supported by readiness checklists across IT, HR, finance, operations, sales and communications. Selected systems continued to coexist as longer migrations proceeded.
GATE 01
Readiness
Email, collaboration, employee access, networks, support paths, financial and customer continuity.
GATE 02
First 100 days
Owners, workplans, milestones, risks, training, issue management and cross-functional communication.
GATE 03
Core integration
ERP and product data conversions, finance and supply chain changes, testing and cutover planning.
GATE 04
Stabilization
Operational support, reconciliations, handoffs, remaining work and eventual retirement of legacy systems.
Continuity was designed in, not assumed.
The January 7 IMO materials marked the Day 1 readiness checklist complete. They also documented active follow-up for access provisioning, collaboration and business systems. That is normal for a staged integration: readiness to operate is not identical to full platform convergence.
By April, unresolved activities were explicitly tracked beyond the first 100 days rather than simply treated as completed.
Concrete example
One identity, multiple systems, controlled coexistence
Employees received access to the parent organization's collaboration environment while some devices, networks, applications and helpdesks remained in place during transition. Cross-company permissions were provisioned in stages with ongoing support.
05 / Execution discipline
A governed program.
Visible progress and risk.
The Integration Management Office connected executive decisions with functional workstreams. Its cadence made ownership, dependencies and exceptions visible. A dedicated systems integration program then coordinated the extended ERP and application transition.
Executive steering and business leadership
Business priorities · Decision rights · Escalations · Synergy objectives
Integration Management Office
Joint workplans · 100-day milestones · Risk and dependency tracking · Communications · Scorecards
Technology & dataFinance & taxSupply chainOrder to cashPeople & HRSales & customerProcurementLegal & complianceOperationsSpecialized programs
Historical progress snapshot
Execution tracking, March 3, 2016
Select a workstream to see reported tasks started and due-date performance.
Technology
88%
Planned tasks started
85%
Due tasks completed on time
These are reported workplan measures, not a measure of how much of the entire acquisition was integrated or how much savings had been realized.
Project controls that mattered
Alignment
Workstream plans with named owners
Business and IT teams carried interdependent milestones and functional approvals.
Visibility
Weekly status and exceptions
Reported task progress, critical dates, non-green areas and decisions requiring escalation.
Change adoption
Training and communication plans
Business users, partners and operations teams needed to understand what was changing before the systems changed.
Systems integration required another level of rigor
Selected approach: Initial consolidation into existing parent-company ERP and related applications.
Execution disciplines: Master data mapping, legal entity requirements, design approval, conversions, integration testing, user readiness and downtime communication.
Target evolution: An original July 2016 ERP target moved to an August 22 target in subsequent plans.
Evidence boundary: Available decks establish that target and extensive preparation; they do not independently verify the actual cutover and hypercare exit.
Explore a specific business-critical dependency
Open orders, customer credit, pricing, legal-entity changes, inventory and receivables had to be reconciled before conversion. The teams considered whether to migrate or allow some orders to run down in the legacy environment. The March workplans recorded agreement on the general approach while business approvals and detailed execution continued.
06 / My expanded global mandate
Integrating a business while building the team to run it.
Alongside the integration, I was responsible for forming a global organization spanning the technology capabilities behind the combined company's front office, back office, analytics and product engineering. This meant balancing migration work with daily business service and an enterprise-wide direction for systems and architecture.
01 · Core operations
Business Systems & Applications
ERP, finance, procurement, supply chain, quality, customer applications and Salesforce CRM.
02 · Information
Business Intelligence
Operational reporting, analytics, data integration and management visibility.
03 · Strategy
Enterprise Architecture
Business and application architecture, data, integration, technology standards and future-state roadmaps.
04 · Delivery
Project Management Office
Portfolio alignment, delivery methodology, project controls and execution coordination.
05 · Partnership
Business Relationship Management
Connecting enterprise priorities and business requirements with accountable technology teams.
06 · Product capabilities
Engineering Services
Information technology and services supporting product development and engineering operations.
The business journey these capabilities supported
Commercial demand
Sales, quoting, customer and partner engagements
Product & supply
Engineering, PLM, sourcing, planning and manufacturing
Execution & finance
Orders, inventory, fulfillment, invoices and control
Intelligence
Shared information, reporting, metrics and decisions
The value chain is a simplified conceptual view. It illustrates the functions our organization supported, not a claim that every process was on one fully connected platform.
Explore the business technology landscape
How enterprise architecture became a management discipline
The architecture work established a framework covering business, applications, information, technology and governance, along with an application portfolio process assessing value, health, total cost, and risk. Proposed portfolio dispositions included remove, remain, redevelop and replace. Integration work and future ERP initiatives were explicit candidates for applying the framework. Actual adoption outcomes require separate verification.
07 / Business value creation
Business value was the purpose.
Integration was the work.
The acquisition's strategic case was about scale and capability, supported by a substantial enterprise-wide synergy agenda. Technology and business systems integration were enablers of that strategy, but program delivery measures, projected savings, and corporate financial results must not be confused.
Strategic context
~$8BPro forma revenue at announcement
The illustrative combined annual scale, not actual annual performance or individual contribution.
Management target
$200MAnnualized operating expense exit-rate objective
Corporate-wide target presented in March 2016, not validated savings attributed to IT.
Documented corporate status
2016Substantial operational integration reported
The company reported substantial operational integration during 2016. Detailed program cutover outcomes remain separately verifiable.
Management also targeted approximately $135M in-year 2016 operating expense savings and approximately $75M in-year cost-of-goods-sold savings. The $200M figure has a different time basis and should not be added to the other two as a single annual savings result.
What integration work was designed to enable
What the evidence demonstrates: An accountable integration program with explicit business priorities, measurable delivery progress and a clear architecture and organization mandate. Savings were managed as enterprise-wide objectives; the precise financial return of individual technology activities is not separately quantified in the available records.
08 / What followed
Stabilize today.
Build capacity for tomorrow.
Acquisition integration establishes the combined business. A later transformation asks how that business could operate more effectively. Those are related challenges, but they are not the same program.
The leadership principles I take from this experience
01
Sequence the change
Protect immediate operations without confusing the integration platform with the final enterprise architecture.
02
Make ownership visible
Milestones, dependencies, business process decisions, training and escalation require clear cross-functional accountability.
03
Measure value, not just activity
Task completion tells you whether work is moving. Business performance and validated synergies tell you whether it created value.
The next enterprise chapter
Business 2.0
A subsequent and separate enterprise transformation initiative addressed broader process, data and operating-model complexity. Its $40–57M estimated annual run-rate benefit opportunity was a projected transformation business case, not a documented acquisition synergy result.
Explore Business 2.0The larger point
The real work was turning transaction value into operating value: integrating people, processes, technology and governance while protecting the business, supporting the synergy agenda and building the capabilities to operate at global scale.
Research and publication note: This preview is reconstructed from contemporaneous corporate materials, public filings, and firsthand leadership recollection. Proprietary slide content is paraphrased, not reproduced. Exact post-close role chronology, actual core ERP go-live and stabilization measures, and finance-validated functional savings remain open for final verification. The interpretive leadership principles should be approved before publication.