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"

Skills of Integration Managers

The success of a merger integration program highly depends on the skills of integration managers and the integration team´s skills. So, what are these skills?

Skills of Integration Managers:
Managers that assign responsible for managing an integration project on a day-to-day basis require various personal skills, such as listening, communication, stakeholder management and people skills. However, in addition to these “soft skills” Integration Manager require also more “harder skills” such as project management, business know how and organizational know how. The entire skill-set that is required for successfully managing a post merger integration can typically be acquired only through first hand experience on-the-job. Therefore a valid question in many cases is, if one single individual should manage an integration project alone. A team of people with complementary skills that is led by a senior executive might be a more appropriate solution for integration management in many cases. However, taking into consideration that corporate top performer are typically not sitting on the bench waiting to be assigned to any post merger integration project (but are rather already busy with other important tasks) staffing of Integration Management is a often marked by compromises.

Skills of integration team members:
Skills that are required on the level of integration teams might include among others leadership, operative know-howand team management. Different to Integration Management where only few peoplemight get involved (often located within one corporate center) 100 and more operationalmanagers across various geographic regions are easily tight up as team members in a post merger integration. This includes typically not only managers and staff from the buying company but also managers and staff from the target company. Therefore PMI training with regard to team members is often more complex than with regard to Integration Management. Due to confidentiality aspects, time constraints and geographic spread in many cases pure digital courses that are accessible across multiple technical devices and teaching environments are the only way to train 100 and more operational manager from both the buyer and target being.

Come to the European workshop on merger integration and learn more

Relevance of open source licensing for commercial software

Open Source Licensing

This page shows you why you should carefully consider using open source software in commercial software: Advantages and disadvantages of open source usage, why open source is used in commercial software and how to manage open source licensing and to control open source usage.

Most important is professional management of open source usage by defining an open source policy for your software company and by following structured processes for open source licensing approval and control. Rest assured that attorneys, consultants and tool vendors are there to assist you.

Advantages of Open Source usage

Simple and fast access to open source are often named as key advantages. Low cost and high quality are additional reasons to consider open source. For a software vendor, there might also be a strategic advantage to use open source software to provide the "non-competitive" part of a solution, while the developers care for the competitive part of the solution.

Motivation for open source usage in commercial software

Usually there are numerous open source components used in commercial software. It makes sense to use open source in commercial software if and only if you can comply with the open source license attached to that open source software. If you do so, you can leverage open source to quickly create functionality and to build on trusted functionality that is provided by software vendors or the open source community.

Relevance of Open Source Licensing

Open source components like the International Components for Unicode, ICU,or Hibernate are used in many commercial software solutions. Non-compliance with the license terms can have dramatic consequences. To avoid these open source licensing consequences, a software vendor has to install an open source licensing policy and practice. But what are the negative aspects and side effects of open source licenses?

Potential disadvantages of open source

Use of open source in commercial software can show the following disadvantages:

• Missing commercial services, like support and service level agreements impact the ability to run in commercial environments;

• Commercialization of software might be blocked;

• Missing or incomplete license attributes, like e.g. for sublicensing software or running software in an on demand environment;

• Missing warranty and liability;

• Non-compliance with license terms might lead to litigations.

Open Source licenses and software supply chains

Usage and licensing rights are transferred between players in the software supply chain. Software passed along the supply chain might contain open source software, too. Due to the copyleft effect in certain licenses, the non-compliance of one supplier might impact all other software companies down the supply chain.

So software vendors should diligently check which open source components are contained in the software supplied to them and which license terms apply.

The use of tools eases the work on this problem. You can use open source scanners to find open source code and the corresponding license terms.

Sollen Roboter Beiträge zur Rentenversicherung bezahlen?

Roboter

Unter Robotern verstehe ich physische Roboter und Software-Roboter, die Entscheidungsaufgaben übernehmen. Software-Roboter basieren häufig auf predictive analytics oder machine learning oder einer Kombination daraus. Mit Hilfe von data augmentation sind die dem Menschen bei der Entscheidung möglicherweise überlegen, da Ihnen mehr Daten zur Verfügung stehen und diese auch schneller verarbeiten können.

Während Sherry Turkle sich mit der Frage beschäftigt, ob ihre Patienten Roboter heiraten sollten, beschäftigt mich die Frage, ob Roboter in die Rentenversicherung einbezahlen sollten.

Warum sollten Roboter in die Rentenversicherung einbezahlen?

Durch Machine Learning nimmt die Automatisierbarkeit von betrieblichen Aufgaben dramatisch zu. Roboter werden stetig zunehmend Aufgaben von Menschen übernehmen. In allen Branchen, unabhängig vom Ausbildungsgrad und ja, auch in Berufen von Akademikern, wie z.B. Ärzten und Anwälten.

In Kürze führt das aus meiner Sicht zu drei Effekten:

1. zu einer Erhöhung der Automatisierungsgrade aller Aufgaben in Unternehmen. Ich vermute, dass langfristig die Anzahl der automatisierten Aufgaben extrem zunimmt und der Bedarf an Arbeitskräften extrem abnimmt. Das betrifft insbesondere Aufgaben, deren Aufgabenträger Entscheidungen treffen sollen.

2. Die intellektuellen Anforderungen an die verbleibenden Arbeitnehmer werden stark zunehmen. Diese Arbeitnehmer werden die Aufgaben teilweise oder vollständig übernehmen, die nicht durch Roboter und auf machine-learning basierenden Software-Roboter erledigt werden können.

3. Die auf machine-learning basierenden Software-Roboter lernen anhand von Beobachtung der in 2. genannten Arbeitnehmer, lernen daraus und werden auch diese Aufgabenträger vollständig ersetzen können.

Schlussfolgerung

Die Beiträge zur Rentenversicherung werden von Arbeitenden getragen. Dazu zählen heute auch Roboter in Form von physischen Robotern und Software-Robotern. Deswegen lasst uns dafür plädieren, dass sie auch in die Rentenversicherung einbezahlen.

Ich freue mich über Kommentare. #robotsaresavingus

Merger integration success based on best practices

Merger integration success based on best practices

With all the mergers and acquisitions activity going on in the markets, it is paramount to perfectly manage the planned integration of targets into the acquiring company.

The integration strategy and the integration approach is different for each merger and each merger has different synergy objectives.

This page is meant to shed light on recent state of the art knowledge and business practices for post merger integration. It tries to structure the problem and thus to provide a way to find the best approach for post merger integration.

When to start with merger integration related tasks

We introduce merger integration due diligence as a new type of due diligence that arises from the objective “Maximize likelihood of integration success”. See the separate page for this topic.

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.

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 are:

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

The four Merger Integration Types

In the high level model below, you end up with four generic types of post merger integration:

1. Preservation: The target company is preserved meaning that you leave the target company autonomous. Nevertheless, integration of financial reporting and financial processes might make sense.

2. Holding: The acquiring company just keeps the ownership of the target company, but does not integrate the target company.

3. Symbiosis: In this merger type, you decide where integration is needed to reach the objectives of the merger integration.

4. Absorption: the acquiring company fully absorbs the target company. All organizations and processes of the target company are to be fully integrated into the acquiring company.

Stay tuned, listen in on twitter @karl_popp and connect with me on Linkedin for more best practices.

---

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”.

Die Weiterentwicklung der Post Merger Integration

Arbeitskreis PMI des Bundesverbandes M&A

Am 16.1. hatte der Bundesverband M&A seine konstituierende Sitzung. Er geht aus der Gesellschaft für PMI hervor. Der Gastgeber Prof. Feix begrüßte Vertreter von Firmen, darunter Ardex, SAP, vom Bundesverbandes M&A, darunter Herr Prof. Lucks sowie  Vertreter aus  Hochschulen an der Hochschule Augsburg.

In agilen, design-thinking-basierenden Workshops wurden  aktuelle Themen und Probleme erörtert sowie Ziele und  Themen für neu zu bildende Arbeitsgruppen definiert.

 Es wurden Themen diskutiert wie zum Beispiel  Standardisierung und Best-Practices für den M&A-Prozess  sowie Berücksichtigung von Integration Fragestellungen in allen Phasen des Prozesses, Transformation des M&A-Prozesses durch Digitalisierung,  Transformation und Digitalisierung von Unternehmen durch Firmenkäufe, kulturelle Integration, Ökosystem-Integration,  Kooperation mit Hochschulen,   Wissensdokumentation und Wissenstransfer sowie  Veranstaltungen  Des Arbeitskreises. 

Nächste Schritte sind die Aufnahme der Arbeit in den Arbeitsgruppen  sowie die Planung einer Veranstaltung, in der das Wissen des Arbeitskreises an die Öffentlichkeit weitergegeben

wird. 

Does somebody miss Klout? new scores of social influence

How do you rate your social influence across multiple social networks?

After Klout has been shut down, the search began. Let me share some of my experiences with Kred and Linkedin Social Selling Index.

There is Kred, my score is 989 out of 1.000. Seems to be calculated based on several social networks. But it is hard to tell how this is calculated.

Then there is the Linkedin Social selling index. Here is my result. This index is a summary of four sub-ratings that rate different ways to engage with the business audience on Linkedin only. Other social networks are not covered.

The Linkedin Social selling index also offers a comparison with industry and people in your network, which is great.

Any proposals for other indexes to be used? please let me know in the comments. thank you.

Events, papers and books in M&A and software business ahead of us

Dear readers,

thank you for your interest in my blog. I wish you a merry christmas and a happy New Year!

What will 2019 bring? More robots in our homes ? We already have two. One vaccum and one mopping robot. More robotic process automation at work combined with Machine Learning ? Sure. More electric cars (Maybe one for me?)? Sending an avatar to work instead of me ? Probably not. We don´t know and that makes life interesting.

Here are some things i will be working on in 2019:

Papers and books

I have the honor to co-edit an issue of IEEE Software:

Michael Cusumano, Slinger Jansen, Karl Michael Popp (eds.), IEEE Software special issue on Managing Software Platforms and Ecosystems, to be published 2019.

I will work on completing the book:

Karl Michael Popp, Successful Post Merger Integration:  State of the art and Innovations in M&A processes, Books on demand, to be published 2019.

We had a great European workshop on software ecosystems at the Platform Economy SUmmit in Berlin and will publish the proceedings asap:

Peter Buxmann, Thomas Aidan Curran, Gerald Eichler, Slinger Jansen, Thomas Kude, Karl Michael Popp (eds.): European workshop on software ecosystems 2018, Books on demand.

With the help of machine learning based translation robots, i might publish another German book, too.

Events

Besides the usual European workshop on software ecosystems and Denkfabrik Wirtschaft, a new workshop will come up, which is a discussion battle between researchers and practitioners in the topic of mergers and acquisitions in London. Xperience Connect will host several thought leadership events on Digitization of M&A and more.

All the best for you and your families in 2019

Always look to the future

Karl

A recap of the European workshop on software ecosystems 2018

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.
What made this workshop successful were the discussions about the presentations but also the interactions in breaks and during lunch. A big thank you goes out to all presenters, helpers and participants!

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.

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 will be provided in a short writeup from the moderator.

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

Program of the European workshop on software ecosystems as part of the Platform Economy Summit

The European Workshop on software ecosystems will be held as part of the Platform Economy Summit in Berlin, we will have two sessions on the second day of the European Platform Economy summit.

November 21st

11:15am Challenges and success factors for creating digital platforms

14:30 Network Effects & APIs: Their role in driving platform value

The first session is called “Challenges and success factors for creating digital platforms”, moderated by me: Insights from studies, real life projects and Uberization“ and will feature three short motivating presentations by Peter Buxmann, Thomas Curran and Sebastien Dupre followed by topic-bases workshops.

Peter Buxmann, Head of Software & Digital Business Group at Technical University of Darmstadt, will present the topic “Data Economy, Platforms, and Privacy: Insights from multiple empirical studies“. He will provide 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.

Thomas Curran will present the transformation of a financial industry heavyweight to becoming an open, digital platform. In a traditionally closed industry, what do you do to turn a company into a digital, open platform. Thomas has done just that in a three year project and will talk about how to do that successfully.

Sebastien Dupre from Coresystems (now SAP) will present the topic “Uberization of field service: a software platform for crowdsourcing service technicians and show 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.

The second session in the afternoon is called “Network Effects & APIs: Their role in driving platform value “ and will be moderated by Slinger Jansen - Software Ecosystems Research Lab, Utrecht University. It will focus on 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?”

The session will start with a short introduction about APIs in general by John Nethans from Google. Then Slinger will present the essence of latest research on API approaches. After that, the panel will focus on pragmatic aspects of creating successful API platforms. After a short while, the panel will open up and take questions from the audience.

This session will feature the following speakers:

Slinger Jansen - Software Ecosystems Research Lab, Utrecht University

John Rethans - Head of Digital Transformation Strategy, Apigee, Google

Nik Willetts - President & CEO, TM Forum

Andreas von Oettingen - CTO Factor10

This session will start with short statements from the panel and will transition to a discussion with questions from the audience.

hope to see you there. please make use of discounted tickets as of below.

Dr. Karl Popp

Join now and you get a special 15% discount off the booking fee. Just quote the discount VIP Code: FKN2652EWOSEL to claim your discount.
 
For more information or to register for the Platform Economy Summit Europe, please contact the KNect365 team on: Tel: +44 (0) 20 3377 3279 | Email: gf-registrations@knect365.com | Register here.
 
Remember to quote the VIP code: FKN2652EWOSEL to claim your 15% discount.

Digitalization of M&A: robots are boosting M&A process performance

While we are used to physical robots vacuuming our homes, software robots are not in widespread use yet. The term used for software robots is robotic process automation. (RPA)

What is RPA? 

RPA is defined as tools to build automation for everyday tasks and processes  on a computer screen using Software Robots.   This can start with a simple sequence of clicks on the screen that you can replay automatically. But RPA can also cover more complex workflows with decision points. RPA  tools usually contain a recorder that tracks  certain work sequences on your computer screen and can replay it this sequence later.

What is RPA combined with machine learning? 

Recording workflows with current RPA tools is a manual process. If combined with machine learning, a digital assistant will track your online work and will propose automation of routine processes you do every day. This will lead to a step by step increase of the level of automation in processes.

How does RPA help in M&A processes?

 It frees up time to focus on the really important topics instead of routine tasks  and sequences of clicks on a computer screen.

Digitalization of M&A: See what is possible today in just one afternoon

Corporate M&A teams don´t have the time and bandwidth to research and follow up with a number of vendors and service providers to get an overview of the latest and greatest innovations for M&A processes.

To solve this issue within one afternoon, Xperience Connect organized an event at Frankfurt School of Finance last week providing several pitches of innovative products and services for next generation M&A processes.

So twenty-two corporates met to have a look at ten vendors, 15 minute pitches by the vendors helped getting an overview within an afternoon, followed by a joint dinner to discuss.

Here are my four highlights of the afternoon:

Target screening

• an interesting presentation from a researcher how to reduce the number of potential targets based on acquisition goals, they also use an augmented set of company data. This is a startup in stealth mode but they presented anyway…

Automatic contract analysis

• RR Donnelley, a vendor of data room called Venue, showed their product eBrevia, which is a tool to automatically analyze contracts in many different languages based on machine learning.

• eBrevia contains about 150 provisions it is able to find and analyze, customers can build AND share new provisions with other customers if they like to.

• eBrevia can be used with Venue, but also with other data rooms.

Digital valuation

• PWC has an open platform for valuation of startups, https://www.pwc-evaluation.com/

Smart M&A

• Midaxo did a very interesting presentation of their innovative, cloud-based, end-to-end M&A process platform.

• With this platform, all parties collaborate seamlessly following repeatable, systematic processes based on their specific, corporate playbooks.

• Several large corporates, including Daimler and Philipsh have adopted this solution.

Thank you, Stefan Gerhard Schneider for organizing this event. He offered to have follow-up meetings with deep dives, which was well received by the corporates.

If you like this content, please also have a look at www.digitalmergers.com

New video for Platform Economy Summit!

Managing the Dark Side of Software Ecosystems

The emergence of platforms is significantly changing the organizing logic of software

development. Platform owners are increasingly engaging vibrant ecosystems around

their platform to foster third-party innovation. Despite all the potential benefits for

complementors, however, innovation in platform ecosystems also introduced essential

new risks that remain under investigated.

Find more information here: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3245777

Talk about it and discuss at Platform Economy Summit https://goo.gl/GAJmg1

Proceedings of the European Workshop on Software Ecosystems 2017

The proceedings of EWSECO are out now! The European Workshop on Software Ecosystems http://www.ewseco.org is an annual event which connects researchers and fellow professionals in the field of software ecosystems.
Presentations in 2017 included:

1. Software M&A Ecosystems -- Industry Keynote by Julis Telaranta, Corum

2. Sandbox vs. Toolbox - Analyzing boundary Resource in B2B Software Platforms -- Maximilian Schreieck, Robert Finke, Manuel Wiesche, Helmut Krcmar

3. Manage multiple platform-ecosystems -- Christopher Jud, Georg Herzwurm

4. Survival of the smartest: Digitalization of mechanical engineering companies by creating a software ecosystem -- Industry Keynote by Benjamin Müller, ADAMOS GmbH

5. Building your IoT ecosystem: Proposing the Hybrid Intelligence Accelerator -- Dominik Dellermann, Nikolaus Lipusch, Philipp Ebel, Jan Marco Leimeister

6. The European Standard on eInvoicing EN16931 - Applications and Services to implement Directive 2014/55/EU on electronic invoicing -- Industry Keynote by Seeburger AG

7. Platform Business in Application Markets: Data Analytics of Mobile App Usage and Descriptions -- Lauri Frank

8. Fake it till you make it: how to bootstrap an ecosystem before your company is ready -- Alexander Eck, Benjamin Spottke

9. Strategy definition in large enterprise software ecosystems -- Ralf Meyer

BUY IT NOW

Buy on Amazon

Digitalization of M&A processes: let´s talk about the data

Digitalization of M&A is about data and data analytics, but also about confidentiality, authorizations and access rights.

• Establishing a clearly defined, phased, end-to-end M&A process with clearly defined tasks and roles in the different phases (seems obvious, but is not yet implemented, esp. in small and medium countries);

• establishing a higher degree of automation of tasks (like automated analysis of contracts which needs all contracts to machine-readable), an important prerequisite is to have digital data as much as possible;

• have one large data set along the end-to-end M&A process (to leverage big data analytics) and clear rules which data are safe to be accessed from the following phase.

So what can you achieve if all these prerequisites are fulfilled, here is my vision:

• combine structured and unstructured data for unimagined insights : you have financial data, but are they solid and trustable? do the revenue numbers projected reflect the existing contracts with customers? In due diligene, by combining structured information (revenue forecast) with unstructured information (text in contracts, information about pipelines in the data room) you can easily compare both to establish additional trust or to ask tough questions.

• leverage data across phases of the M&A process: there are restrictions which data from due diligence can be used in later phases. But the data that you can use from target screening and due diligence can be combined and compared with data. Current data you are looking at could be augmented with historical data automatically.

• actionable insights across M&A projects: the data from all phases and all M&A projects can be used to determine actions in a specific situation. Based on machine learning, an automated assistant could propose what to do, what has been done in other projects in similar situations, could propose who to talk to to leverage the lessons learned from other projects.

So the call to action is: Unite your data on and end-to-end platform to build the foundation to leverage the data for better insights, better execution and more success in M&A processes.