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

Karl´s blog

Posts tagged business models
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.

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.

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"

Open Source business models

Open Source business models

Open source business models are commercial business models based on open source software. This webpage contains a short version of a chapter in the book Advances in software business.

Commercial use of open source

For a commercial company, Open Source Software is software that is licensed to that company under an open source license. The commercial company may make use of the open source, like usage or redistribution of the open source free of charge, but it also has to fulfill the obligations, like delivering a copy of the license text with the software.
So the rights and obligations have to be analyzed diligently to make sure there is no violation of the license terms.

Suppliers of open source software

Open Source software can be supplied by a community or by a commercial company. We speak of community open source and commercial open source respectively. For community open source, a community of people provides creation, maintenance and support for an open source software. In most of the cases the community provides these services free of charge.

There are, of course, differences between a company and the open source community. These differences are important to understand, because they influence a customer´s supplier decision and they also create niches for companies to establish a business in that niche.

Commercial open source vs. community open source

So a customer might decide for commercial open source if he needs customized license terms, runs open source in a mission-critical environment and thus needs service level agreements in support or if he needs maintenance provided in a different way than via the open source community.

In many business contexts it makes also sense to have liability and warranty provisions from a supplier when using open source. In most of the existing open source licenses there is exclusion of any warranty or liability (3). This is another reason why companies might choose commercial open source over community open source. Please find more information in the book “Best practices for commercial use of open source software”.

Classification of open source business models

Based on a classification of business models (Weill et al.) we will have a look at open source business models.

Open source usually is free of charge, but that does not necessarily mean there is no compensation for using the open source component.
The next figure shows a classification of generic business models. The business models relevant for commercial open source business are marked in bold. In this general classification of business models, software classifies as an intangible product, see the corresponding column “Intangible”. Software can be created or written (“Inventor”), distributed (“IP Distributor”) or licensed or rented to customers (“IP Lessor”). In addition, the customer needs services to run and maintain the software, like implementation, support and maintenance services. These classify as “Contractor” business. We assume here that all open source businesses make use of at least a subset of these four business models.

No matter if it is a community or a commercial software vendor, one or many of these business models are applied. By choosing a specific selection of business models, so-called hybrid business models are created. Creating hybrid business models means combining different business models with their specific goals, requirements and cost structures.

Since these business models are models on a type level, there might be different implementations of how a certain business models are run. An open source community might run the Inventor business for creating software in a different way (leveraging the community) than a commercial software vendor (leveraging a development team), from a process as well as from a resource perspective. But on a type level, both run the same type of business called Inventor.

So going forward, we will analyze commercial and community open source business models as a selection of a subset of the business models identified here: Inventor, IP Lessor, IP distributor and Contractor.

Community open source business model

The open source community business model usually makes use of the following business models: Inventor, IP Lessor and Contractor.

For the community, the Inventor business is what the community is most involved in. It is about creating open source software and engaging with the community members to coordinate the work and collect the contributions of the community members.

The IP Lessor business is also important for the community. The IP lessor business defines the terms and conditions of the open source license and makes the software available to customers. The license is defined by the community and all customers using the software have to comply with it. In some cases, there are multiple different licenses for an open source software that a customer can choose from.

The Contractor business contains all human services to customers. The community typically provides these via email and they contain services like maintenance, support, translation for country specific versions and the like. They are all carried out by community members. In almost every case, the customer does not pay for these services, but the customer has no rights to enforce any of these services and he does not have service level agreements, like a definition of minimum answer time for support incidents.
The community can serve two types of customers: software vendors and (end) customers. For software vendors, the open source community works as a supplier of software, for the customer, the open source community works as a software vendor licensing software to the customer.
These two relationships differ in the way that customers and software vendors might make use of the software. Customers usually license the software for internal use only. Software vendors license software for internal use and/or for distribution to customers. Often open source software is included in commercial software and provided to customers by the software vendor. In this case, the software vendor has to make sure he complies with all licenses of all open source software he is including in his software product. Please find more information in the book “Best practices for commercial use of open source software”.

Commercial open source business models overview

In the last section we described the community business model, now we turn to the commercial open source business model. Figure 4 shows the typical business models implemented by commercial software vendors. As mentioned before, a commercial software vendor does not have to implement all of these business models, but can rather build unique business models by selecting a subset of available business models. One basic difference to community open source is that the IP Distributor business model is an option for commercial companies.
The history of commercial open source companies shows that in the beginning the companies focused on services around open source software, which matches the Contractor business.

The next step was to build distributions for open source software, like e.g. for Linux. This matches to the IP Distributor business model.

Today, we find all kinds of hybrid business models around open source. Companies are building software and donate it, completely or partially to the open source community (Inventor business model). Commercial software vendors often package or change or extend existing community open source software, so the community acts as a supplier of open source software to the software vendor. In some cases the software vendor does not use existing open source software from a community, but chooses to offer its proprietary software under a dual licensing strategy, e.g. under a commercial and an open source license. Please find more information in the book “Best practices for commercial use of open source software”.

Commercial services for open source

Since open source licenses are free of charge, commercial companies first and foremost focused on providing services around open source software. The expectation was simply that customers would still need services and since the license was free, that customers would have more money to spend on services.

Commercial open source companies provide the following services for open source software: Maintenance, Support, Consulting and Extension or adaption of open source software to a customer´s needs.

Maintenance services consist of the following activities: building future versions, bug fixes and upgrades and providing them to the customers.

Support services contain of accepting, maintaining and resolving incidents that the customer has while using the software.

Consulting services mean planning and executing the installation and go-live of customers´ system landscapes containing the software.

Extension or adaption of open source software based on customer´s requests is designing, programming, testing and delivering open source software that has been modified or expanded. Examples for extensions and modifications are:

  • Functional Extensions for open source applications with country-specific functionality or customer specific functionality;

  • Extending the usage scenarios for open source to additional countries by adding additional translations of user interfaces;

  • Adapting open source software means to make open source software run on customers´ hardware and software platforms.

Summary and outlook

The evolution of open source and commercial open source business is still underway. In the future we will see additional varieties of open source business licenses, such as in open source hardware or designs, and new open source business models, like in open source on demand applications or open source software in cloud environments. Please find more information in the book “Best practices for commercial use of open source software”.