M&A, Business Models and Ecosystems in the Software Industry

Karl´s blog

M&A digitization: comparing businesses of target and acquirer

Acquiring new business

These days, many corporates acquire other companies with new business models or are trying to integrate startups to extend the range of business models and to avoid disruption by other companies. But how do you analyze and compare businesses? Is a coarse analysis on the business model canvas sufficient to determine differences and derive activities for post merger integration? Are there any blind spots? Here are my thoughts:

Comparing businesses

In a holistic view three things describe their business of a company in a complete fashion. The strategy, the business model, and to be operational model.

The strategy defines strategic goals and measures. Strategic goals help to steer running the business, but some strategic goals also determine how to shape the business and how to create the operations for the business. I will discuss how to define and compare strategies in one of my upcoming posts, so let us focus on comparing business models and operational models.

Comparing business models

Using the Business Model Generation Methodology, you can compare two business models by comparing information from each of the model elements: value proposition,channels, customer segments, channels,revenue streams, key activities, key resources, key partners, cost structure. This gives you a set of differences on a type level, which is great. So, say, you find out that the channels are different, one is via a physical store, the other is via online store. Then you can think about leaving them separate or integrate both offerings. For department stores, we saw that combination of channels happening: buy in store, return online; buy online return in store; buy online, pick up in store.

Using the Business Model Generation methodology, you have to be aware that not only the degrees of freedom to build a business model can be the source of differentiation and disruption but also the degrees of freedom to build an operations model, which implements the business model. What is the difference? The business model is a type level model telling you what to do while the operations model is much more concrete model describing how you do it. For the department store example, the operations model would implement how you do online store ordering followed by in-store pick-up.

In addition, the strategic goals tell you how to shape the business model and the operational model. This relationship is not reflected in the Osterwalder model.

For more details on similarities of business models, please see my other blog post on elements and similarity of business and operations models

Detailing the operational model

To describe the operations model of the target and the acquirer we need details on the following core processes, their organizations and information systems:

  • Revenue generation and collection model or value to cash: how do we bring products to market via channels and how do we collect revenue.

  • Innovation processes: idea to customer value: how do we innovate.

  • Production operations model: supply chain to delivery.

  • Administration operations model: finance, controlling, facilities, HR and other administrative processes.

Keep in mind that the strategic goals and measures have to be applied to the operations model, since some of the goals help you decide how to structure the operations model. Just think about strategic goals “cost leadership” and “quality leadership”. These two goals might be operationalized by establishing operations that focus more on keeping cost low or on keeping quality as high as possible.

As we have shown here, bringing strategy, business model and operations models into one holistic model is a key ingredient for modeling a single business, but as well for comparing businesses while evaluating mergers and acquisitions. Stay tuned for more thought leadership - if you like, you can browse more thoughts on my blog page.

Denkfabrik Wirtschaft

M&A Aktivitäten sind für viele Unternehmen nach wie vor eine wichtige strategische Option zur Steigerung des Unternehmenswertes und des Unternehmenswachstums. Nichtsdestotrotz ist ein Unternehmenskauf aber oftmals eine große und risikoreiche Investition und stellt insbesondere in der Post Merger Integration eine große Herausforderung für Unternehmen dar.

Es lohnt sich, dieser Phase ein hohes Maß an Management-Aufmerksamkeit zu widmen, denn nachhaltige Wertschöpfung erfolgt nicht durch den Kauf an sich, sondern durch erfolgreiche gemeinsame Integrationsarbeit.

Der Jahreskongress PMI des Bundesverbandes M&A und der angegliederte interaktive Design Thinking-Workshop „Denkfabrik Wirtschaft“ beleuchten die kritischen Erfolgsfaktoren und typische Vorgehensweisen bei der Unternehmensintegration:

  • Standardisierung und Best-Practices für den Integrations- und M&A-Prozess

  • Transformation des Integrations- und M&A-Prozesses durch Digitalisierung und
    digitale Tools

  • Kulturelle Integration im M&A-Prozess

  • aktuellste Erkenntnisse aus der internationalen wissenschaftlichen Forschung und Beratung im Bereich M&A und PMI aus europäischer und amerikanischer Perspektive


Die Teilnehmer des Workshops können Ihre Themen und Fragen aktiv einbringen und zusammen mit anderen Teilnehmern Lösungen erarbeiten und haben so die Möglichkeit, von den praktischen Erfahrungen anderer Unternehmen zu lernen und diese für sich zu nutzen.

Zwei kurze Keynotes runden das Programm ab. Dieses Format gibt es seit drei Jahren und es hat hervorragende Bewertungen der Teilnehmer erhalten.

Und das Erlebnis endet nicht beim Workshop, die Teilnehmer können in dem Arbeitskreis PMI des Bundesverbandes M&A weiter mit den anderen Experten zusammen arbeiten und sich austauschen.

Agenda und weitere Informationen finden Sie unter www.mergerintegration.events

 

Building on the shoulders of giants. Shortcuts to Platform Business Success

Platform business

Say, you want to start a new two-sided platform business. This blog is about jumpstarting platform businesses from scratch by leveraging other platform

Gravity

Gravity is the number of participants you have on both sides of your platform. Gravity on each side of the platform is a key prerequisite for platform success. Platform success is dependent on gravity because the direct and indirect network effects for the participants of the platform depend on gravity. So how do you create instant gravity?

Usually, companies run advertising campaigns and start recruiting participants on each side of the platform. Under this approach, the focus should be on getting participants with high gravity. High gravity means that they are large companies or they bring their ecosystem on to both sides of the platform to massively increase the number of participants.

One example is SAP Ariba. It is a two sided platform with corporates on one side and suppliers of goods and services on the other side. When they added Rio Tinto on the corporate side of the platform, Rio Tinto brought in thousands of their suppliers and thus created massive gravity on the supplier side, too. So this is one reasonable approach to add gravity.

Free but paid with information

Another approach to create gravity is to offer free functionality on one side of the platform, but charge on the other sides of the platform. Perfect examples are Google and Facebook. Consumers are not charged, but they pay with their data. The price of zero for consumers has the potential to attract many consumers and creates gravity.

Leveraging the gravity of other platforms

Why should a platform company at all start to create gravity from scratch on their own? A new approach i am proposing is to leverage gravity of other platforms for your own platform. The idea is to combine other platforms for your success by building on top of them.

Examples: SAP acquired Coresystems. Coresystems had a crowdsourcing platform for field services, i.e. maintenance and repair scheduling. To get more gravity, the solution was integrated with SAP´s marketplace for temporary workers, SAP Fieldglass, which created massive gravity for crowsourcing field technicians.

Aktuelles zur Jahrestagung PMI des Bundesverbandes M&A!

Ein Update zum Jahreskongress Post merger integration

Hier ein paar Informationen zum Gesamtkonzept der zweitägigen Veranstaltung:
1. Tag des Jahreskongresses PMI: BM&A in Kooperation mit KPMG 24.10.
2. Tag des Jahreskongresses PMI: BM&A in Kooperation mit Denkfabrik Wirtschaft 25.10.
http://ewpmi.squarespace.com
Zwischen ersten und zweiten Tag gibt verbindende Abendveranstaltung durch Einladung der KPMG in Kooperation mit dem BM&A für Teilnehmer beider Tage

Die drei Schwerpunkt-Themen der beider Tage sind:
• Cultural Integration
• Best Practice Prozesse & Ansätze
• Digitalisierung & Digitale Tools im M&A Prozess

Der erste Tag wird von dem BM&A in Kooperation mit der KMPG gestaltet. Dieser Tag besteht vorwiegend aus Vorträgen.
Der zweite Tag, die Denkfabrik Wirtschaft ist arbeitsorientiert, die Schwerpunkt-Themen werden im Rahmen von Design Thinking Workshops interaktiv und gemeinsam diskutiert und erarbeitet.

How Real-Time Transparency Makes PMI Meetings Effective

Your Integration framework is in place. Functional leads are fully armed, and at their battle stations. Ready… Set… DAY 1!

As soon as the clock starts ticking, every second in a PMI project matters. Speed in M&A integration execution does bring value and it correlates to the success of M&A. With the ever-decreasing timeframe in which integration leads are expected to realize synergy targets, there are few things more important than a structured and diligent integration plan. But when day one hits and Pandora’s box is open, being able to track the success of your plan in real time is crucial to hitting your targets.

Weekly meetings are the lifeblood of most integrations, and have been the best practice until recently. Whether it is program meetings, project meetings, or Executive Steering Comittee meetings, there are a few data points that need to be tracked consistently at a high-level.

  • Issues

  • Task Status/Milestones

  • Timeline

  • Responsibility

Classically, the integration leaders ask for updates from each functional lead/project manager, and get a verbal play-by-play of the past week’s happenings. In our current, tech-driven world, there are now digital tools that can increase meeting productivity and give M&A teams instant transparency into their processes. Integration team members can see what’s happening prior to meetings, ensuring focus on how to address issues, decisions needed, cross-stream dependencies, etc. This means that meetings’ action items are clearer, and time is spent proactively working towards targets, rather than retroactively getting updates on who did what, when.

Each of the integration performance items above are affected by the PMI teams ability to have “real-time” visibility:

Issues

Having instant visibility into the status of any potential issue enables corporate development teams to address risks before they damage the deal. Any PMI project will run up against unforeseen challenges, but proactively resolving issues leads to an increase in deal speed and value realization.

Task Status/Milestones

Many teams have thousands of tasks per integration, but there are always key milestones against which success is measured. Having the opportunity to check on the mission-critical items at a moment’s notice shortens the feedback loop within teams and empowers integration leads with the information they need to benchmark their teams against their schedules in real time.

Timeline

Let’s face it. Integrations very rarely hit timeline expectations. But, knowing where you are in relation to your goal is crucial. Having that 1-week gap in status update between team meetings might just be the difference between being on time and falling far behind.

Responsibility

PMI projects have many moving pieces in play. Governance is complex. The PMI leads manage the functional leads, who in turn must allocate resources from within their teams. Having a central platform that acts as a single source of truth is invaluable. Immediately, it becomes clear who is responsible for a task, who has signed off on what action item, etc. When there are multiple chains of command, being able to see changes in real time gives Integration leads the bird’s eye view that is needed to execute.

To quote Mark Herndon of M&A Partners, "The time has come to upgrade M&A integration management processes with simple, secure and state-of-the-art software solutions." This real-time transparency gives cutting-edge PMI teams full visibility and control in the perfect storm that is integration.

Two best practices for managing the integration project

Best practices in merger integration have to include many aspects like timing, project management, handling exceptional situations and decisions and when to end the integration project.

In merger integration activities timing is essential. So when is the right point in time e.g. to merge teams of acquirer and target that do similar things? When is the knowledge of the acquirer complete to integrate HR functions of the acquired company? When is the right time to end the integration project?

Merger integrations are also high-risk, high effort topics that have to manage numerous exceptional situations. Project management practices are made for such projects. But there is the risk of keeping project members hostage in reporting activities instead of focusing on resolving issues and completing tasks. So a key aspect is to find the right dose of project management for keeping project control by providing appropriate follow-up and execution of critical tasks and minimizing the project management workload on project members.

Let us quickly look at the topics:  “When to mix up teams working on the same topics?” and “When to declare the end of the integration project?”

When to mix up teams working on the same topics?

So when is the right point in time e.g. to merge teams that are working on the same tasks, selling to the same customers, producing similar work results? We discussed different aspects.

The first one is that the acquirer has to have sufficient knowledge about all departments or teams that have to be integrated. Without that knowledge it is impossible to plan and execute change management needed for the transition into a merged team.

The second aspect is if the time is right to integrate if the immediate value of integration is maximized or the confusion and trouble is minimized. One example is the immediate integration of finance activities for maximizing the value for the acquirer to be in control of finance. Another one is integration of sales teams to avoid having two different, competing sales teams as “one” face to the customer.

When to declare the end of the integration project?

Ending the integration project makes sense when at least one or more of the following goals have been reached:

·         integration plan has been fully executed,

·         benefits of the acquisition have been reached or

·         organizational performance (fully functioning and stable merged organization) is ensured.

The selection of one or more of these goals depends very much on attributes of the merger, specifically on the department (or corporate function) to be integrated, on the culture of the target and the acquirer and on the integration strategy, like e.g. if the target should stay separate or should be fully integrated into the acquirer. Depending on the size of the M&A and merger integration team, the support of these teams might end earlier due to high workload or focus on new, different M&A and integration projects.

Find more information in the book “Mergers and acquisitions in the software industry” (click here for German version) and at the German Event Denkfabrik 2019

M&A digitization:Leveraging the domain model to map M&A data rooms, process tools easily

The domain model will consist at least of the following parts:

  • A data model that shows the data objects that are involved in M&A transactions and processes.

  • A Hierarchy of tasks in different phases of M&A Processes.

  • APIs for data objects and tasks.

The domain model is a programmable model. This means it is available electronically and can be navigated and displayed as you wish. It is implemented in a set of Prolog facts and rules.

Here is a first view at the phase Due Diligence. It consists of the tasks Target Due Diligence, Integration Approach Blueprint, Merger Integration Due Diligence, Deal Making and Finalize and Approve Due Diligence Business Case. Each tasks will be documented by its goals, the data objects used and a task description.Each of the data objects will be also represented in JSON notation as well as an API documentation.

duediligence.PNG

Here is an example of the documentation of each task. The task Review Merger Integration Project works on concepts

 Integration Project Plan, Integration Budget, Stakeholder, Integration Success, Integration Project, Integration Project Resources.

It has the goal (that describes the result):

Integration project: tested and verified

and the objectives, which describe the qualities of the result:

 Integration success: maximized
 Quality: maximized

It has the following task description:

We review the structure and behaviour of the merger project. It is important to remember that the word "project" means that we have a professional management of integration by professional project managers who are experienced with complex projects and equipped with the skills of a certified project manager. We should also set up a project steering committee that has comprehensive competencies and can make decisions quickly.
The word "project" means that we have a project structure plan with tasks to be performed in the project. Buying companies that make frequent acquisitions have a project structure plan template that they adapt to each of the new merger integration projects. This ensures completeness and also allows a correct assessment of whether we have sufficient resources and whether the resources know what to do in the merger.
But we also focus on providing answers to questions like: Do we have the right resources for the integration tasks in mergers? Are the resources able to perform the tasks assigned to them? Do the resources have adequate social skills to guide people and convince them to integrate?

So stay tuned for more information. One of the next blogs will talk about programming on top of the domain model.

M&A digitization: Imagine you can easily review existing tools to automate M&A...

Everybody feels the pressure to digitize. How can you best handle it when you are responsible for the M&A process? Say, you would like to get information which tools are available to automate this task. You could start searching, find some tool vendors, look at a few in more details by coordinating meetings. A tedious process.

Domain model can help

I am working on a domain model, which will be available in an online tool, that does two things: first, define all tasks in the M&A process. Second, it allows to map existing tools to this model, showing which tools are available for which tasks.

What would it look like?

Let us have a look at an example. In the early phase of the M&A process there is a task called pipelining. You want to automate it. This task aims at providing a long list of potential targets and ways to select a subset of targets resulting in a shortlist. So, how would the information about a tool look like? See the information below on a single tool that partially automates this task.

Tool/Service: EY Embryonic
Provider: EY
USP: EY has licensed all expensive databases like CapIQ, CBInsights, ThomsonReuters and has an impressive user experience.
EY Embryonic is offered as a consulting service. 

Great information right? This is just a snippet of the available information. The plan is to list several tools to enable you to select the right tooling to digitize the M&A process.

Stay tuned for more news about the domain model and its many uses. Like what you read? Click on one of the topics or buy one of my recommended books below.

M&A digitization: A first glimpse of the domain model

The domain model will consist at least of the following parts:

  • A data model that shows the data objects that are involved in M&A transactions and processes.

  • A Hierarchy of tasks in different phases of M&A Processes.

  • APIs for data objects and tasks.

The domain model is a programmable model. This means it is available electronically and can be navigated and displayed as you wish. It is implemented in a set of Prolog facts and rules.

Here is a first view at the phase Due Diligence. It consists of the tasks Target Due Diligence, Integration Approach Blueprint, Merger Integration Due Diligence, Deal Making and Finalize and Approve Due Diligence Business Case. Each tasks will be documented by its goals, the data objects used and a task description.Each of the data objects will be also represented in JSON notation as well as an API documentation.

duediligence.PNG

Here is an example of the documentation of each task. The task Review Merger Integration Project works on concepts

 Integration Project Plan, Integration Budget, Stakeholder, Integration Success, Integration Project, Integration Project Resources.

It has the goal (that describes the result):

Integration project: tested and verified

and the objectives, which describe the qualities of the result:

 Integration success: maximized
 Quality: maximized

It has the following task description:

We review the structure and behaviour of the merger project. It is important to remember that the word "project" means that we have a professional management of integration by professional project managers who are experienced with complex projects and equipped with the skills of a certified project manager. We should also set up a project steering committee that has comprehensive competencies and can make decisions quickly.
The word "project" means that we have a project structure plan with tasks to be performed in the project. Buying companies that make frequent acquisitions have a project structure plan template that they adapt to each of the new merger integration projects. This ensures completeness and also allows a correct assessment of whether we have sufficient resources and whether the resources know what to do in the merger.
But we also focus on providing answers to questions like: Do we have the right resources for the integration tasks in mergers? Are the resources able to perform the tasks assigned to them? Do the resources have adequate social skills to guide people and convince them to integrate?

So stay tuned for more information. One of the next blogs will talk about programming on top of the domain model.

M&A digitalization: We need a domain model for M&A

A domain model for mergers and acquisitions will save us.

The clash of domains

Two companies shall be merged. Two workforces and two administrations have to be aligned, changed and integrated. The first problem that comes up is corporate language and a missing joint domain model and integration plan for people involved but also for applications, companies, locations and countries.

Domain models

Domain models are semantic models that show objects and their relationship in a specific domain. For the M&A domain there will be representations of the M&A strategy, the business case, the integration plan and of course, of both companies to be merged. In addition we need a model of the integration project and all the tasks to be carried out in the different phases of the M&A process. The domain model does not only cover company data, but also data about the M&A process, the involved people and other attributes of the integration like goals and objectives and how they are measured.

Mapping out phases and tasks in the M&A process

Soon , the PMI workgroup of the German M&A association will publish a reference model for all tasks in the M&A process. Here is a short preview of what will be included:

  • Phases: are part of the M&A process like a due diligence phase or the phase between sign and close.

  • Tasks: describe the activities to be carried out during the M&A process. Plus there will be goals and objectives for each task that steer the execution of the tasks and measure success.

  • Concepts: Describe the domain data of the different companies, like companies, departments, the project management domain

Wow, that might be a lot of data types to be modeled, how can you ensure consistency? It all comes together on a task level. Tasks are executed to transform companies to reach an end state, called goal. Goals and objectives will be different by merger and companies involved.

In our case the goal is that the organizations are integrated. Success is measured with two objectives: integration success is maximized and risk is minimized.

task:             execute_merger_integration_project
phase:            merger integration
goal:             buyer and target organizations are integrated.
objectives:       integration success is maximized, risk is minimized.
task description: Resources for the project will be allocated.
                  and the integration project will be executed.
concepts:         target, buyer, organization, budget, project plan, resources

Domain model APIs foster integration of tool vendors

Domain models can be used to drive transparency in the heterogenous world of M&A tools. Tool vendors can easily show the coverage of tasks within the domain model

The description of phases, tasks, concepts, goals etc. will be formalized and can be easily used to generate API descriptions that could be used to integrate different tools in the M&A process like data rooms, project management tools etc. So stay tuned for more progress.


Software strategy selection: is build, buy, partner sufficient or do we have to add open source to the game?

Strategy selection

The best innovation and growth strategy is to combine organic and inorganic growth. SAP has successfully applied organic innovation and growth resulting e.g. in SAP HANA, SAP S/4 HANA as well as inorganic innovation and growth via acquisitions like Qualtrics and Calliduscloud. 

Build, buy, partner

  For me, the most important distinction between build or buy is the window  of opportunity that you have.  In technology markets, there are frequent changes of market direction. If you’re lucky, you had started  your solution  in time to build something that is en vogue  right now. But if you’re not lucky, you need to acquire capabilities that the market needs today.  But is this the only option you have?

Opportunity and risk in building  and acquiring solutions

To be frank,    with the current state of technology due diligence on to be acquired companies there is no difference in risk to build or to buy.  When building products, you trust your developers to build something great. The a priori likelihood of success is 50%. Same likelihood applies for acquiring technology. In addition, acquired technology exists, has customers, success and failure history. So, what is the impact of this statement on build decisions? 

Build decisions

Build decisions are made based on anticipated market trends. So don´t be suprised when you find out that you made the wrong decision. It is perfectly natural to take wrong decisions. But how can you fix such a wrong decision? I have two proposals: The first one is to start massive marketing to convince customers and markets that what you built is the right thing. Tough. The second option is to buy your way into front and center of the market.  What are these the only options you have?

 Outsource your worries

 What we need to look at is in another alternative.  You could leverage an existing open source solution with a license that permits commercial use to jumpstart your building efforts.   And you build differentiating, proprietary technology on top.

 If the open source community behind that solution is being active enough, you will save massive effort for support and maintenance of the solution.  

It also makes financial  and strategic sense to spend your money wisely on functionality where you can differentiate your offering from the competitors’ offerings.

Why don´t you choose one of the following topics to continue:

 

What is merger integration? What do i have to do?

The task of post merger integration

An important ingredient in acquisition strategy is how you integrate the acquired company. Let us describe the task of post merger integration with goals and objectives. You have to think well about goals and objectives, since these will define what is being done through merger integration.

Goal of the merger integration task

The goal of post merger integration is to plan and execute the integration of two businesses. WIthin each business, there is an organization and there are many processes, which are to be aligned and/or integrated.

Objectives of the merger integration task

  • Maximize likelihood of integration success: each merger integration tries to reach successful completion meaning that there is no failure of the integration.

  • Continue target operations: in most cases, it is important to not interrupt the target operations with merger integration activities.

  • Fit integration type: there are different ways to integrate two companies, which are determined in the integration strategy. more information about merger integration types can be found here: Merger Integration Types

  • Fulfill synergy objectives: every merger has synergy expectations and objectives. Merger integration is targeted at creating such synergies.

Decomposition of the merger integration task

There are three subtasks: designing the new entity, planning merger integration (project) and executing merger integration project.
The first two should be started during due diligence to ensure merger integration success.


MergerIntegrationTaskDecomposition.png
Scaling new business models in corporates: Similarity of M&A and digitization initiatives

Scaling new, unfamiliar  business models is a popular topic in large corporates. These new business models might originate from internal or external initiatives, even from acquisitions. How can corporates scale new business models successfully in such situations? Here are my views on it.

Not the usual merger

A widespread perception of mergers and merger integration is that an important objective of such activities is collecting cost synergies or consolidating industries or buying your way up and down the supply chain. Scale and growth are a second thought, if at all. This is different in high tech industries, such as pharma and software. This is different and even more challenging when acquiring and scaling new business models.

Similarity of M&A and Digitization initiatives

A large company acquires a small company to adopt a new business model. An intrapreneur tries to implement a new business model in a large corporate.  Both represent the same type of challenge:  making an existing organization adopt a new business model.  Both can be solved with appropriate, new approaches.

Modulating the corporate immune system

Integrating new business models needs new approaches. The acquirer has to ask the question: “Why have we acquired the company?” If the answer is: “Because they are different” or “Because they have a business model that is new to us”, the acquirer should carefully select integration speed and depth. The acquirer should also make sure that he is preparing his own organization to be ready and able to integrate the new business model. Getting prepared for that might take some time, which influences integration speed.

The acquirer also has to manage the “corporate immune system” which typically rejects new business models due to employee statements like “not invented here” and “that is not the way we do it”.

Change intensity in your court

While in usual merger integration most of the changes happen to the target, this is a different ballgame. A massive change in the operating model  of the acquiring organization is needed. Such change is only possible if the large organization is willing and able to change.  In addition strong empowerment and executive support is needed to establish such change.

Thoughts on merger synergies

A (positive) synergy is the increase in shareholder value coming from mergers and acquisitions activity. Below is a list of potential synergies that are usually considered for mergers and acquisitions. If a synergy applies for a deal and how big the synergy is has to be analysed and planned for each deal.

Keep in mind that synergies are not self-fulfilling prophecies. You need careful planning, execution and tracking of synergy related work to realize synergies.

Synergies seen from outside of the companies

Looking at a company from the outside, the synergies of a merger can come from the following sources:

Relationship to Suppliers

  • increased negotiation and purchasing power

  • consolidation of existing suppliers and contracts

  • leveraging better existing conditions for a supplier contract from target or acquirer

Supplied goods and services

  • increase in purchasing volume and potentially a decrease in price

Relationship to financial institutions

  • increased negotiation and purchasing power

Relationship to customers

  • increased negotiation and purchasing power

  • increased revenue from upselling and cross-selling opportunities

  • increase in portfolio assets to be sold to customers

  • increase in the number of customers and/or markets covered

Sold goods and services

  • revenue effects from broadened portfolio

  • faster time to market since acquired goods and services are available immediately for selling by the acquirer

Relationship to partners

  • increased number of partners

Relationship to government and states

  • potential synergies for corporate tax

 

Synergies seen from the inside of companies

Synergies for all corporate functions

  • Centralization of tasks and elimination of organizational and functional redundancies is often cited as a main source of synergies

 Synergies for the business models

  • The target introduces a new business model for the acquirer

Cost synergies

Looking at cost synergies, two main sources of cost synergies are often cited: elimination of redundancies and reduction of inefficiencies.

Learn more from my upcoming book on merger integration.....

 

(C) Dr. Karl Popp 2019

A practitioner´s view on risk, risk perception and risk handling in merger integrations

Every acquisition and merger integration carries numerous risks. Actually, acquisitions and merger integrations have a bad reputation due to risk. Many integrations fail or do not reach objectives in a sufficient manner. This is why it is important to detect, evaluate and to manage risk in M&A transactions and in merger integration.

Risks can e.g. originate from the target company, from the acquiring company and from the integration of the two companies. In the best case, these risks are determined in due diligence, mitigations are planned and all is being handed over to the integration team as soon as possible.

Risk discovery in due diligence

While the target related risks are analyzed in detail in due diligence, the risks related to the acquiring company and the risks related to the integration itself are often neglected. In addition, not all risks can be determined in due diligence alone, new undiscovered risks might come up during the integration.

What you see is all there is

We learn from Kahneman that the risks that are being found depends very much on the experience of the people looking for risk. He says that you will only find the risks that you have experienced, heard about or read about.

This is why it is very important to use risk catalogues, experienced integration managers and risk managers. Walk through the risk catalogue to see if there are applicable risks, use your own or somebody elses experience to determine additional risks and run a risk workshop with an experienced risk manager.

Key risks in merger integration

Experience shows there are risks in merger integration that occur in each acquisition. While there are many risks outside of companies, let us focus here on risks inside the involved organizations. From my point of view, these reoccurring risks are:

  1. Brain drain/Attrition: key employees or a large share of employees from the target are leaving.

  2. Cultural integration problems: people don´t feel at home, feel lost or frustrated and thus attrition increases and people are leaving.

  3. Wrong perception and estimation of integration complexity and effort: acquisitions can get complex on many dimensions like size of the target and acquirer business, number of companies, countries and locations involved. With the complexity, the effort may skyrocket.

  4. Bad management of the integration scope and integration project: these are generic project management problems revisited. They also occur in merger integration projects.

How to deal with risk

In my view, there are four ways to deal with risk: Ignore, monitor, mitigate and sell.

Ignoring risk is dangerous alternative. If at all, you should use ignoring only for a risk that you think has very limited impact on the success of the merger integration and very small likelihood. And you have to be aware oft he difference between probability and likelihood. Likelihood means you only have a guess about the chance of a risk to become true and impact the merger integration.

Monitoring risks is a slightly better approach to risks. In this case you simply watch the risks to see if the likelihood or the impact has changed. If a likelihood or impact increases, you might switch to one of the following alternatives.

Mitigating risk is the preferred approach. This means you are trying to establish counter measures to be able to avoid the risk or reduce the likelihood or the impact of the risk. Be aware that mitigations needs people, time and budget to work.

If certain risks are perceived to have a massive financial impact and cannot be properly mitigated you might want to sell these risks to insurance companies. One example might be environmental risks of manufacturing plants.


Change management in post merger integration and the role of the change manager

Change management in PMI is the process and methods (tools) to manage the people side of the integration to achieve the declared PMI goals. Therefore, it is important to link the change management to the PMI strategy and the project management in the PMI project. (integrated change management approach). Both change management and project management support the PMI transformation – moving from the actual organization of the Target through a change period (managed via the PMI project) to the future state (successful integration of the Target organization). Integrating the newly acquired company into your own organization, you are ultimately going to be impacting the following aspects: PMI Strategy, Structure (process organization and structural organization), People (like job roles) and Culture. Whenever you adjust those elements in your own organization or at the Target level you need to manage the technical side as well as the people side.

The role of the Change Manager

Experience has shown that it is supportive to inform the top and middle management upfront and to use them as multipliers. In that regard the preparation of Q&As is helpful and enables to speak the same language and to deliver equal key messages.
Who might be the adequate change agent? This depends on your own as well as on the Target organizations. Supervisors and Managers are Change Agents. Change Management is a leadership topic. Enable managers in their role as change agents through empowerment and awareness-raising workshops. However the concrete involvement and role depends on your specific PMI project. Undertake a stakeholder analysis as early as possible to identify the sponsors and other important multipliers.
The key element in change management is to set up a good communication from the start of the PMI process onwards. There is a need to effectively communicate the change to the employees – communication cannot be overdone. Set up a communication plan already during the due diligence phase. The main questions in that regard are:
• What is my PMI vision and mission? Is my message clear?
• Who is my audience, who is the right sender? (strategy issues should be communicated by the
Top Management level, personal topics (WIIFM=what is in it for me) as new job role by the
direct lead)
• What are the key messages? When is the right time to deliver the message? What is the right
delivery method and frequency?


Proceedings of the European workshop on software ecosystems, held as part of the Platform economy summit, are available

Dear all,

the European workshop on software ecosystems, this year held at the Platform Economy Summit in Berlin, was a huge success.

All the results are in the proceedings, so if you have not been participating, you can get a summary of the discussions in the workshop!

The proceedings are available in print and ebook with the ISBN 9783748140153

at amazon

at BOD, our publisher.

DETAILS

The workshop was held within two sessions of the second day of the First European Platform Economy Summit in Berlin. The first session was a workshop called “New Ecosystem Opportunities & 'White space' Opportunities in Software and High-Tech“ and the second session was a panel about “Network Effects, Data Effects & AI - Keys to the castle“ moderated by Slinger Jansen. You can find more details on both sessions below.
Session one: New Ecosystem Opportunities & 'White space' Opportunities in Software and High-Tech

This design-thinking based workshop featured three short motivating presentations by Peter Buxmann, Sebastien Dupre and Thomas Curran followed by topic-based, hands-on workshops.

Thomas captured the audience by describing his recent success with creating new cloud based ecosystems for digital business in the financial industry. In a traditionally closed industry, what do you do to turn a company into a digital, open platform? Thomas had done just that in a three year project and talked about how to do that successfully.

Peter reported about several studies on the value of data and the importance of privacy. He provided insights into challenges and success factors for software platform providers regarding the value of customer data, customer privacy and tradeoffs between data privacy and data farming by platform providers.

Sebastien showed how Uberization in field service management works by engaging a crowd of service technicians inside and outside of companies. He explained how companies can build an ecosystem connecting field service technicians, partners, own employees and customers to scale their field service operations, increase revenue and provide unmatched customer experience.

All presentations are in the proceedings. The proceedings are available in print and ebook with the ISBN 9783748140153, at amazon, and at BOD, our publisher.

Then we split the crowd of thirty people into three teams that worked together and discussed with the help of the moderators and our design thinking coach Olaf Mackert. First, we ran an introduction game called two truths and one lie, which created a lot of laughter and made everybody ready to work together trustfully.

Then everybody dumped his ideas, questions, issues he or she wanted to discuss on post-its, which were clustered into topics by the moderator. Then the teams voted on the topic to start with. The discussions went on in five minute slots. The team voted on either continuing the discussions on the topic or going to the next topic after each slot.

Thomas Curran´s team, which was the largest team, focused on the technical aspects of creating a platform and technology selection. They had lively and productive discussions leveraging the joint wisdom of the team.

Sebastien´s team of ten discussed topics around uberization of any industry and about changes in strategies for field service management.

Peter Buxmann´s team was a diverse team made up of members from venture capital, manufacturing, public administration which made discussions very interesting based on the different views. The team addressed question around motivations of people to share data, ways to create value from data and also around data protection impact on data-driven business models.

The results of each team are listed in the proceedings. The proceedings are available in print and ebook with the ISBN 9783748140153, at amazon, and at BOD, our publisher.

Session TWO: Network Effects, Data Effects & AI - Keys to the castle

John Rethans, head of Digital Transformation Strategy from Apigee/Google, brought everybody on the same page regarding APIs - what they are and what it means to implement an API driven strategy and technology.

Slinger Jansen from Utrecht University opened the panel with a short presentation about his research. The panel´s focus was on pragmatic aspects of creating successful API platforms. It covered questions like “What is the role of APIs for platforms? How do you build API-based platforms?  What are the success factors and pitfalls when building API-based platforms? How to explain their power to non-technical executives and shareholders?”

In addition to Slinger and John, the panel featured the following speakers: Nik Willetts - President & CEO, TM Forum, Andreas von Oettingen - MD of Factor10.

The presentations are in the proceedings. The proceedings are available in print and ebook with the ISBN 9783748140153, at amazon, and at BOD, our publisher.

best regards

Karl

M&A thought leadership: Frontloading makes sense in M&A processes

Failing early is cheap

We know from software engineering and design thinking that failing early in the process is cheaper than failing in later stages. We adapt this thinking to the M&A process and care for ensuring merger integration success during due diligence. I call this frontloading.

Successful integration and synergies as an objective in all phases of the M&A process.

So, why are we doing frontloading? Frontloading is driven by the objective to prepare and run a successful merger integration project. All detectable risks, efforts and obstacles are identified and taken care of during due diligence already. These risks, efforts and obstacles relate to the target and the acquirer, too.

Mitigations or eliminations for risks are planned or executed during due diligence. Merger integration efforts are being estimated and planned. Any obstacles we could run into during merger integration are being identified and elimination or mitigations are planned. Examples for obstacles are missing resources or missing budgets for merger integration. While missing resources could be mitigated by leveraging additional resources or adaptation of the merger integration plan, missing budgets could be planned for already during due diligence.

Effects of frontloading

There are several positive effects of frontloading for the operations of mergers and acquisitions business:

  • A more realistic evaluation if the merger makes sense at all. Clarity on adverse topics like risk and obstacles completes the managerial view to take an informed decision about a merger. Frontloading increases the ability to get a complete and holistic view of the planned merger and merger integration.

  • A more appropriate expectation setting with executives monitoring the merger integration. When the executives approve the merger, they know about the potential risks, issues and obstacles that were or were not mitigated.

  • More realistic integration plans and integration speeds. When you know what to do in merger integration and you have enough capacity and ability to integrate quickly, all is fine. If this is not the case, you risk failing during merger integration or creating bad integration decisions and results. Frontloading helps to avoid some of these adverse events.

  • Less bumping into obstacles. Let us be clear. Nobody likes to run into a roadblock like missing budgets and losing momentum of integration efforts. This is why we care for identifying and eliminating obstacles. Are we able to eliminate all roadblocks in merger integration? Definitely not. But we reduce the sheer number of obstacles and we can dedicate more of our time and attention to the remaining obstacles.

As a consequence, all companies should adopt frontloading in due diligence, no matter if the deal is an asset deal or a share deal, if the target is a public company or not.

How well does that resonate with you? Please let me know your thoughts.

Key questions regarding software tools for merger integration

Let us discuss tools for successful integration. We are not not referring to system integration, but tools for managing and supporting the Merger integration process from pre-deal through due diligence, up to and including post merger integration.

Today, Excel and Power Point are currently the most used tools in the M&A transaction/integration world. There are also several Virtual Data Room providers that offer solutions at a high cost.

For managing the end-to-end process, Excel, Power Point, and Share Point on their own do not really work. Every project is different and one needs to be aware of the complexity that tools bring with them. So do tools really work? Do they add value and justify the cost and time to introduce & maintain? Does email communication from a tool work?

We can at least specify a list of requirements that a tool should address:

  • Project / Deal based

  • Document repository capabilities

  • Project Management capabilities

  • Communication/collaboration capabilities (email/messaging/collaboration)

  • End-to-End process management (i.e. transition of Due diligence /Data Room info to integration team)

  • Reporting capabilities (i.e. on a project basis, and or for the entire deal pipeline/project portfolio)

  • KPI tracking capabilities

  • Knowledge bank capabilities

  • Highly performant and highly secure (especially with cloud based solutions)

  • Stable (i.e. updates must have no impact)

  • Highly configurable

  • Easy to deploy & configure

  • Easy to use with little/no training


M&A thought leadership: Integration of new business models: dimensions of similarity

No matter if you integrate a target running a business model that is new to your company or if you want to disrupt your business model or if you ask intrapreneurs to come up with new business models; you will face one big issue: how to integrate the business model that is new to your company. So, “new” means that the acquirer is not capable of running the processes that support such business model (yet).

Business models and operations models

I would like to separate two dimensions here: business models and operations models. A business model tells which goods or services are provided by a company and how the company is compensated for the goods and services. It is a model on a type level, like a company running field service management solutions in the cloud for a monthly license fee. It already describes on a general level what a company is doing. On this level of granularity, companies can easily be similar.

A business model can be implemented in an operations model. The operations model shows how the business is run and how the resources of the business run the corresponding business processes in the company. This model is very concrete, detailed and more complex and involves resources running and used in the business processes like employees or application systems. On this level of granularity, it is harder to tell if two operations models are similar.

In the following, I would like to share insights from integration acquired software companies about the impact of the similarity on merger integrations.

Similarity of business models

The more similar business models are, the better the operations of these business models can be integrated. The operations might be similar; sales and accounting processes might only need small changes to be adapted. But there might be issues with overlaps in organizations.

For software companies, this means easier integration in development and support but also in administrative functions. So you should look for similarities and differences by listing/modeling the business models of target and acquirer already in due diligence.

In contrast, if business models are very different, this might pose a challenge for integration. You would have to decide if you want to continue the different business models and if so, changes needed to continue both business models have to be executed in merger integration. For merger integrations targeting absorption, this might mean that the acquiring organization would have to adapt to a diverging business model of the target.

Similarity of business models enables higher speed of integration: The more similar business models are, the better the operations of these business models can be integrated. This enables higher speed. The reverse is also true. If business models are significantly different, this might impose slower speed of integration.

Similarity of operations models

Operations models are implementing business models. How a business operates is a key thing to understand for integrating a business. The closer two operational models are, the easier it is to integrate both businesses with each other. You may use operations maturity models to determine the current and desired state of target and acquirer operations.

An example for similar operations models is having the same objectives for procurement at the acquirer and the target. If both companies look for maximum quality of supplies in procurement it might be a lot easier to integrate procurement processes, to align demands, to analyze and plan cost synergies.

Similarity of operations models enable higher speed of integration. How a business operates is a key thing to understand and to integrate a business. The closer the operational models of acquirer and target are, the higher the speed of integration can be. There also i a higher likelihood of economies of scale effects and cost synergies in such cases.

For more insights, please refer to the book "Mergers and Acquisitions in the software industry: Foundations of due diligence"