Popp Supplier Relationships and Mergers & Acquisitions in the Software Industry

A Student Primer Second Edition
2. Auflage 2025
ISBN: 978-3-6951-5321-3
Verlag: BoD - Books on Demand
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Englisch, 204 Seiten

This book has been created to serve students of information systems and computer science to serve as a primer for getting acquainted with key concepts and mechanisms of software supply-chains and mergers and acquisitions. It contains scientific content, best practices as well as street smarts when dealing with these topics. Questions after each chapter allow the reader to see if the content was successfully acquired and can be applied.

Dr. Karl Michael Popp is a senior advisor at Lincoln International and a retired member of the Corporate Development M&A team at SAP SE in Germany. In his thirty-year career he has worked on over 50 acquisitions and successful merger integrations as well as a few divestitures.

Autoren/Hrsg.

Popp, Karl Michael

Leseproben

4. Supply side value chains in the software industry

As mentioned in the introduction of this book, software vendors collaborate and hence engage in value chains. We will separate two value chains in the software industry. One is the supply chain between software vendors, which allows a software vendor to get software from a supplier to use it as part of their offering. Software for internal use is disregarded here. With the advent of AI and generative AI, the supply of data is added to the supply chain. The other value chain is the value chain of supplying software from a software vendor to end customers, which is not covered here. When appropriate, we will look at degrees of freedom in business model design.

4.1 Software demand side value chains

Let us look at the demand side value chain in more detail. This value chain starts with a software vendor that provides software to customers for internal use (so called end customers) and goes upstream with the chain of supplying entities. This value chain equals a bird´s eye view of the software industry. In this value chain the software industry provides the following products and services to companies using the software (business model types are taken from [Popp11a]):

Supply software

• Create and provide the software to other software vendors

• Business models are Inventor, IP lessor, IP distributor

Customize and implement the software

• Consulting services for software vendors

• Business model: Contractor

Support the software:

• i.e. provide answers to software vendors’ product questions and help for problem resolution

• Business model: Contractor

Maintain the software

• i.e. providing updates to the software and bug fixes to the software vendor

• Business model: Contractor

Operate the software

• i.e. running the software for the software vendors

• Business models: Physical Lessor, Contractor

Figure 8: Software supply chain tasks

Digging deeper into supporting software

If a software vendor needs assistance to solve a problem with the software, the software vendor gives the supplying software vendor notice of this incident. The incident notice triggers the provisioning of the support services. The goal is a resolution of the incident. A resolution of an incident can be a workaround. If a workaround is not possible, the incident usually results in the delivery of a bug fix to the customer.

Support Services are usually structured in the following way: incidents are classified by urgency or business impact e.g. into level 1 (high urgency), level 2 (medium urgency) and level 3 incidents (low urgency). Service level agreements define “mutually agreed performance metrics to measure the licensor´s performance” [Class08,153]. Each of the levels has corresponding definitions and service level agreements. Other classifications with more levels are possible.

Figure 9: Software Support services

Definitions exactly describe for each incident how it is classified. The software vendor acknowledges that he has received the incident, figures out a solution and provides a solution to the customer. Usually, service level agreements describe the initial reaction time, time needed to provide a solution to the customer and other aspects like e.g. penalties. Incidents can trigger maintenance activities.

Digging deeper into maintaining software

Software is being maintained by the software vendor or by the customer and in some cases by both of them. Software maintenance contains the following activities: providing bug fixes to an existing release and version, providing new versions of an already installed release and providing a new release.

Figure 10: Maintaining software

After the bug fixes, versions and releases have been provided, they must be installed. Installation of a new version is usually called update, installation of a new release is usually called upgrade.

In the on-premise model the customer installs the bug fixes and executes the updates and upgrades, in the SaaS model, this is all done by the provider of the SaaS software. This shows that in the SaaS model the cost at the SaaS provider for a single support incident tends to be higher than in the traditional model.

In an open-source software model, the community of developers will provide bugfixes as well as new versions and new releases.

4.2 Supply chain between Software vendors

Now let us look at the supplier relationships between a software vendor supplying software components and a second software vendor making use of these software components.

In this section, we will answer questions like: How does the receiving software vendor make use of the software components coming from a third party? Which opportunities, risks and limitations come with such supply chains?

The receiving software vendor can provide unchanged components to customers, acting as a IP distributor, or he can integrate the components into products and provide the product containing the components to customers [Popp11a]. The receiving software vendor can provide the software on-premise or on a SaaS model to customers. Please note that there can be a supply chain for data, too, which we will cover later in this book.

Figure 11: Software supply chain

A software vendor A is dependent on entity B, if A uses or includes a software component or software solution of B in A´s products. Remember that B´s products might be software or hybrid products containing software and hardware components.

We are explicitly excluding software which the software vendor purchases for internal use. So, we only see software in the value chain that is passed on downstream until it reaches the end customer.

If you follow each of the supplier relationships of a software vendor backwards (upstream) and draw it as a directed graph, you get the supply chain of a software vendor. For the matter of simplicity, we will call it supply chain.

Figure 12: A simple software supply chain

Literature about software supply chains is scarce, but we will provide some insights from the existing literature and experience from dozens of supplier relationships and current research.

Motivations for supplier relationships

Why are software vendors engaging in supplier relationships? Let us look at motivations for suppliers and receiving software vendors. Receiving software vendors expect a benefit from using a supplied third-party component. The receiving software vendor´s benefits can be:

• increased competitive advantage, if the third-party component is a leading-edge solution, or

• reduced risk, because the software vendor avoids the failure risk of own development of the functionality, or

• leverage of third-party expertise, if the knowledge and skills of the software vendor are insufficient to build a similar solution, or

• lower time to market, because the software vendor avoids the time to build the solution inhouse and avoids the risk of being late to market, or

• lower cost, if the third-party component is provided below build cost, which very often makes the case for usage of open-source components or

• focusing on differentiating functionality by using third-party, esp. open-source software for non-differentiating functionality or

• a real or perceived increase in productivity of the software vendor and of course

• revenue expectations, especially if a complementing solution is resold by the software vendor and/or

• a higher customer value of the joint offering.

Suppliers are also looking for their benefit in engaging in supplier relationships. The expected supplier benefits are:

• Customer scale and gravity by increasing the number of direct and indirect customers of the supplier,

• Lower sales cost,

• Specialization on a niche in the software market, e.g. Stellent, Jaspersoft,

• Higher efficiency,

• Enlarged marketshare,

• New revenue stream for a company that had not acted as a supplier before,...