Digitalization in the SME sector: it’s far from over

by admincf | Jul 9, 2025 | Insight, Newsroom

Digitalization - just buy!

The digitalization of German SMEs cannot happen organically. This pithy statement was made at a conference a few months ago. In principle, this would mean building up the necessary skills internally and developing the organization towards digitalization on the proverbial greenfield site.

Theoretically, this is certainly possible. You start by hiring two or three really good people. But here lies the first major hurdle: Where do you find them? Which top talents would choose to join an organization that still has to be trained and educated? Even if you overcome all these hurdles, it will be a very long road.

What alternatives are there? If the organic route doesn't work - or would simply take too long - the anorganic solution remains. This was exactly the approach promoted at the conference. So we simply buy the digital expertise - a kind of white knight who turns everything around. Search, buy, done.

So that would be the solution for the digitalization of German SMEs. Of course, this approach can also be applied to generative artificial intelligence - as well as to many other more or less necessary transformations.

That's right: the digitalization of an organization is a genuine transformation. The organization should then be (more) digital, think (more) digitally, and act (more) digitally. This is far more than just a few new processes. It is about new perspectives, new ways of thinking, different logic, and different beliefs.

Signing done - and now?

Is the acquisition complete then? Does the desired change happen all by itself? That would be easy. This is probably why it is so often attempted - not only for digitalization but also for many other acquisition targets. Once the ink is dry, the contract is filed away and archived. And that's it. Too good to be true.

Let's take our German medium-sized company as an example, which by the way manufactures drills for special applications. They are really good at it. Now they have bought a digital company that programs very cool apps. If not much else happens after the signing - or even after the closing - apart from a short speech and a few new pens with new logos, not much will change.

Then everything stays the same. One part of the organization will continue to produce excellent specialty drills, and the other will remain the hip digital team. No exchange, no cooperation, no change. After all, as long as both can simply carry on as before, at least nothing will break.

It could be worse...

Yes, unfortunately. For example, if the buyer - the one with the drills - tries to impose its processes on the digital team. If suddenly the same purchasing conditions apply to everyone: Who needs special hardware or digital flipcharts? Standard notebooks and old flipchart pads will do - there are still enough of them in the warehouse anyway. Or if the same core working hours (08:30-16:00) and attendance requirements suddenly apply to everyone. Who needs regular video conferences with Silicon Valley or China? It goes without saying that the digital team will suffer in this scenario.

So it takes more than just a well-intentioned post-acquisition approach. A rethink is needed - both for the team with the drills and for the hip digitals. They need to understand each other and learn from each other.

Going back in time - Industry 4.0

Why is digitalization such a comprehensive change? Many years ago, we supported an automotive supplier during a major restructuring process. Towards the end of all the organizational restructuring measures, the desire arose to introduce a Manufacturing Execution System (shortly MES) in production to move towards Industry 4.0. However, after such a far-reaching change, an organization first needs time to consolidate. The new setup has to settle and become part of the routine. The timing was therefore rather unfavorable.

Industry 4.0 means that information is exchanged in real time between customers, in-house production, and suppliers along the entire value chain. To achieve this, the company's organization must be data-driven and digital. Although installing hardware and software in production is very cash-intensive, it is a comparatively minor technical requirement.

In this organization, digital was almost a foreign word at that time. Everyday management life was characterized by heavy signature folders transported back and forth between several locations. Travel expense reports were still prepared by hand on specially made envelopes into which the receipts were inserted.

This was the real transformational step: turning an organization that works with physical receipts and documents into one that thinks and acts digitally and data-driven. Otherwise, for example, a change to the delivery schedule would come from the customer in real time, which would first be printed out on site and then distributed internally. Only then could production, logistics, and purchasing react - and HR might still not know that more staff would be needed in production next week.

Digitalization cannot be imposed top-down

What makes digitalization so different from other change programs? Why can't you simply set the goal, chart the path, and give the go-ahead? The digital mindset is not yet in place. The organization is still blind in this area. So no digital solution can be specified. Often, the problem for which this digital solution is needed is not even clearly identified. For this, the organization must first be upgraded - or rather transformed.

Top-down specifications do not work. How does it work then? This transformation can only succeed from within. The organization must be introduced to “digital” step by step - for some, these steps are bigger; for others, smaller. People need to practice and make experiences so that the digital mindset can develop.

The employees in the digital team help to make these experiences possible and to convey the new way of thinking. In this way, some learn to think more digitally, and others learn to act like a manufacturer of special drills. The result is an organization that thinks and acts digitally, identifies problems, develops digital solutions, and is able to implement them.

Post-merger integration – The catalyst

Digitalization cannot simply be prescribed, planned, and controlled top-down. However, there are many things that can be done to make it a success. Above all, the right framework for the transformation is needed, along with organized shared experiences and initiatives.

Classic post-merger integration with its mission of growing together by coming together is ideal for this. Collaborating on manageable tasks - and there are many after an acquisition - creates a shared sense of achievement. Old organizational boundaries are overcome, people interact, and they learn from each other.

A clearly formulated vision is needed for this particular acquisition. A vision that describes digitalization, beyond a specific new product or solution - because it is about much more than that. This vision inspires the first pioneers in both organizations to seek contact, work together, and overcome resistance. It provides orientation on the path to transformation.

The acquisition of the digital team is the turbo on the road to digitalization. However, there is no shortcut for the essential steps - the transformation of the organization. Post-merger integration is the catalyst that keeps the process going.

Achieving acquisition targets with agile principles

by admincf | Jun 10, 2025 | Insight, Newsroom

The agile nightmare of Paul M.

Paul was convinced: this time everything will be different. No rigid Gant charts, no endless Excel spreadsheets, no yesterday's waterfall logic. His PMI project - a medium-sized but politically sensitive merger - would be agile. With daily stand-ups, backlog grooming and, of course, reprioritization “on the fly”. Paul was reading Scrum for Dummies when the first topic came up.

The integration of the sales team, actually a “top priority”, was postponed - “because finance is shouting louder right now”. Two weeks later, HR postponed the onboarding process “because the target system is not yet connected”. And when Paul realized in Sprint 3 that neither team knew what the other was working on, he decided to turn the retrospective into a crisis meeting.

The only thing that moved regularly was the priority list. Instead, the timeline remained constant: late. Paul smiled bravely through the daily chaos, clinging to agile manifestos - and secretly wished for nothing more than an honest, old-fashioned project plan. With milestones, deadlines and please, please: clarity about who has to do what and when.

Agile is good. But maybe not here? Not right now? Not like this?

Agile project principles - beyond post-is and stand-ups

Agile project principles and, in particular, frameworks such as Scrum are not just tools or methods. They are thought models. Their foundations include the three pillars of continuous improvement: transparency, review and adaptation; the Agile Manifesto, the twelve agile principles and the five Scrum values: commitment, focus, openness, respect and courage.

These principles and values form a flexible framework for how (software development) projects can be implemented. Two central ideas underpin them. An iterative-incremental approach in order to be able to better absorb changes and external influences, and a focus on customer value to deliver results with the highest added value.

The agile framework includes the roles of Product Owner and Scrum Master, the artifacts Product Backlog and Sprint Backlog as well as the events Sprint, Daily Scrum, Sprint Review and Sprint Retrospective. However, the concepts that originally came from software development should not simply be adopted unchanged. They need to be translated into the context of mergers & acquisitions and post-merger integration.

Integration backlog - what really counts

What is to be achieved? In software development, this central question is usually answered in terms of customer value. But who is actually the customer in a post-merger integration?

In a project as complex as a post-merger integration, there are not only many, but also very different customer groups. To avoid confusion, it is better to speak of stakeholders. These include the usual suspects: Owners, employees of both companies (including management or board members), (regulatory) authorities such as tax offices, suppliers, financiers and, last but not least, the companies' “real” customers.

There are indeed many of them, which explains why post-merger integration is considered so complex. Different stakeholders have different needs that need to be taken into account. Accordingly, the integration backlog quickly fills up with a wide range of housekeeping objectives as well as deal-specific value creation objectives.

The integration backlog does not contain the individual action steps. Instead, it lists the objectives that are to be achieved. Goals that can be clearly derived from the needs of the stakeholders. If these needs are prioritized, the entries in the integration backlog can also be prioritized accordingly.

This prioritization is usually based on predefined milestones, such as reporting obligations, trade fair appearances or the goals from the deal story. And: this prioritization is not universally valid, but always situation- and acquisition-specific.

The integration backlog already contains a large number of “must-dos” on day one. The good news is that they do not all have to be completed immediately. In many cases, a phased approach of First 10 Days, First 30 Days, First 100 Days, Beyond 100 Days has proven effective for quick clustering and implementation focus.

The integration backlog is not a static document. This aligns with one of the basic principles of agile project work. Items can be added, removed or reprioritized during the course of the project. The original weighting can also change over time. The advantage of this thinking model for complex post-merger integration is that you can start quickly and go straight into implementation, without having to plan everything down to the smallest detail beforehand.

Integration Sprint - Or is it a marathon?

Classic post-merger integration is more like a marathon than a short-distance run. It is not uncommon for 18 months or more to pass before an integration is fully completed. Perhaps post-merger integration should even be compared to an ultramarathon, with distances of 100 kilometers and more.

The idea of achieving results and celebrating small successes at short intervals is just one of the considerations behind the integration sprint concept - but it is a particularly central one with regard to the principle of “growing together by coming together”. This is because the first fruits of the joint work become visible after a short time, rather than after many months. In this way, people and organizations grow together step by step.

An integration sprint usually lasts two to four weeks. The exact duration is determined in advance. And this is precisely where another advantage of the approach becomes apparent. This manageable period is much easier and more reliable to plan. In contrast, planning across six, nine, or even twelve months is far more time-consuming and significantly less precise . The use of available resources - especially internal resources - can also be better estimated and managed more efficiently within this short time frame.

In this way, joint activities can be implemented more quickly. The high level of short-term planning certainty means that there are fewer deviations from the plan, which in turn increases satisfaction within the integration team. And once again, the team grows closer together.

During an integration sprint, the team members can concentrate fully on the issues at hand and deliver concrete results. Requirements and priorities remain constant during this phase. And thanks to the brevity of the sprint, new prioritizations can wait until the next sprint without disrupting ongoing work.

The central elements of an integration sprint are the integration review and the integration retrospective at the end of the respective sprint as well as the integration daily, which, as the name suggests, takes place every day.

Integration review - more than just ticking boxes

Transparency and feedback are key principles of agile projects. They are systematically embedded in the integration review. At the end of each sprint, the team members report on what they have achieved. The PMI owner and the stakeholders provide feedback on the results presented.

In this way, the “customers” of the integration are regularly involved and remain informed about current issues and progress. The integration team receives valuable information on whether the integration is progressing in the right direction, whether the results achieved meet the expectations of the stakeholders and whether integration may have gone too far or not far enough.

The high frequency of the integration reviews ensures that all participants stay actively engaged in the integration process. The substantive evaluation of the results prevents pure task tracking - a typical pitfall of classic large-scale projects, where the focus is merely on completing tasks without questioning the content of the results. New or additional requirements are also identified in the integration review and added directly to the integration backlog if necessary.

Integration Retrospective - Internal Only

In addition to the “external” format of the Integration Review, the Integration Retrospective is an “internal” event. It is aimed exclusively at the integration team and also takes place at the end of each sprint. Put simply, two central questions are reflected upon. What went well in the current sprint? And what should be improved in the next one?

This is not about the work results but about collaboration within the team. The focus is on how we deal with each other, communication and cooperation within the integration team. Another important dimension of the retrospective is the interaction with stakeholders and other people outside the team. Did the integration team have sufficient opportunity to focus on the relevant topics or was it too distracted by outside influences?

This is where the Integration Master and the PMI Owner come into play. They are responsible for creating the necessary framework so that the team can work effectively.

The Integration Retrospective not only serves to improve the operational aspects of project work, it also promotes cultural understanding between the organizations involved. Open discussions about collaboration naturally bring cultural differences to the surface. By regularly discussing these differences and jointly considering how to deal with them, cultural integration emerges as a by-product.

Integration Daily - Every day!

That brings us to the central element Integration Daily. As the name suggests, it takes place every day. It is a short coordination meeting of the members of the integration team. The goal is to create transparency. Everyone knows what the others are currently working on. Dependencies are uncovered and clarified, obstacles are identified and necessary support can be requested.

Especially in the early phase of integration, in preparation for Day One and in the first few days afterwards, it is highly recommended that the Integration Daily is held daily. Unplanned or unforeseen challenges always arise in this phase, so this brief coordination brings a noticeable gain in effectiveness.

As the project progresses, the frequency of the Integration Daily can be adjusted, for example to two or three times a week or, if there is less need for coordination, to an Integration Weekly. Especially after the first 100 days, when the team members are no longer predominantly involved in the integration work, the rhythm of the daily meeting should be adapted to the respective course of the project.

PMI Owner - One for all

Every integration needs someone who understands its value and takes responsibility for its success. This is the role of the PMI Owner. Managing directors or board members with operational responsibility are often appointed to this role as project managers for post-merger integration. While this is possible, in practice, the limits of this approach quickly become apparent.

In the agile world, the product owner - in our case the PMI Owner - is the person who keeps an eye on the business perspective of the project. In the context of post-merger integration, this means aligning integration efforts with the corporate strategy and acquisition goals, and vice versa. The PMI Owner thus establishes the link between the integration activities and the overarching strategic vision of the acquisition.

Accordingly, the PMI Owner is also responsible for prioritizing the integration backlog and defining the sprint goals. These are based on strategic requirements, acquisition targets and external milestones, such as reporting obligations or regulatory deadlines.

During a sprint, the PMI Owner is available to the integration team as a sparring partner to quickly clarify open questions. This has the advantage that the team does not have to wait for feedback from steering committees or other escalation rounds. This keeps the sprint focused and efficient.

However, this requires the PMI Owner to be constantly available for the integration team. And this is precisely where a conflict of objectives arises: the managing directors with operational responsibility are always heavily involved in day-to-day business, making it unrealistic for them to be constantly available. This is why the idea of using these managers as PMI Owners often falls short in practice.

Integration Master - the real PMI experts

Alongside the PMI Owner, who maintains the link to the corporate strategy and the acquisition targets, the Integration Master(s) serve as the central experts for post-merger integration. They know exactly what it takes to ensure a successful integration and are familiar with the typical housekeeping issues that need to be addressed.

Integration Masters are facilitators, transformation agents, moderators - and sometimes also mediators. They network the various workstreams, remove blockages within the teams and ensure smooth collaboration across team boundaries. While the PMI Owner primarily focuses on the “outside world” beyond the integration team, the Integration Masters are operate within the team, acting as a driving force and providing hands-on operational support.

Last but not least, they play a central role in cultural integration. Their experience from numerous post-merger integration projects and other transformations makes them key figures when it comes to bringing different corporate cultures together.

Agile in post-merger integration?

Yes - but only if it makes sense. Not because it's currently “hip”. Agile is not a panacea. However, the sprint principle helps to maintain focus and use the available resources effectively, especially in projects of the caliber of an ultramarathon, as post-merger integration often is.

If the values of the Agile Manifesto are applied to post-merger integration, the following picture emerges.

Individuals and their interaction take precedence over processes and tools. This is precisely what encourages people from both organizations to grow together. Former boundaries are overcome - a new, joint organization begins to shape.

A functioning organization is more important than extensive process documentation. The focus is on genuine collaboration and functionality within a (new) organization, not on appearances and shadow processes.

Alignment with the corporate strategy and the acquisition targets takes precedence over merely creating project plans. Integration is not carried out as an end in itself ; it is a critical driver for achieving the acquisition goals.

Responding to changes is more important than rigidly following a plan. The ultimate goal is a resilient and sustainable new organization that not only achieves the initial targets but continues to evolve.

The formal agile elements - from clear objectives in the sprint and the Integration Daily to the Integration Review and Integration Retrospective - create a structured framework that also leaves room for focus and adaptability. PMI Owners and Integration Masters ensure that this framework is adhered to and remains effective.

The Role of IT in Buy & Build Projects

by admincf | May 2, 2025 | Insight, Newsroom

Fairy tale hour with system jam

The hare sprints — but the hedgehog is already at the finish line. The hare is not only completely out of breath but also beside himself with anger. “I don't mind,” says the hedgehog, “I'm already here.” So the whole game is repeated seventy-three times. But on the seventy-fourth attempt, the hare doesn’t make it to the finish line.

We know the story — it may sound like a fairy tale, but it’s still true, at least according to the Brothers Grimm. There are only a few buy & build cases in which 74 add-ons are actually integrated. But what if IT isn’t the hare this time, but instead takes on the role of the hedgehog?

IT in Buy & Build: The Underestimated Bottleneck

In most cases, IT is not involved from the outset when the target company is turned upside down during the due diligence process — even though IT plays a significant role in value creation, especially in the financial services sector.

How often is IT excluded from management presentations because they ask critical questions? Because they inquire about the budget for IT integration? Because their bulletproof migration plans might delay the entire deal?

Then comes Day One — and there is no plan for IT integration, no budget for the necessary data migration, and no additional capacity to handle the required effort. “That can wait. It's not that urgent.”

A few months later, disillusionment sets in. The acquisition goals have not been achieved. The anticipated cross-selling has failed to materialize. Access to products and customer data remains cumbersome and time-consuming.

Why is that? When interfaces are poorly defined — or not defined at all — the data doesn’t match along the process. Information must be entered twice, three times — or seventy-four times. This becomes a breeding ground for shadow IT.

This isn't just inefficient due to excessive duplication and reduced quality. It also leads to ineffectiveness, missed opportunities for innovation, and delayed product launches. In short: a loss of added value. Welcome to the fairy tale forest of lost integration opportunities.

What IT Could Do If You Let It

Let’s start with a classic no-brainer: data harmonization can begin before closing. No data needs to be exchanged — which is usually prohibited by regulation anyway — but it is possible to align on formats and requirements for the data sets and prepare existing information accordingly.

Starting early not only means being ready sooner, but also results in less duplication of work later on. From the moment of alignment, new data can be entered “correctly” from the start. This immediately frees up capacity for activities that create real value — for example, additional cross-selling activities.

The voice of IT is often critical. That’s true. And the word “unfortunately” is deliberately omitted here. IT is responsible for digitally supporting and automating complex processes — as quickly, smoothly, and error-free as possible.

To achieve this, IT must inevitably pay attention to detail. IT needs a special eye for exceptional situations — even if they rarely occur. But sooner or later they will, usually without warning.

This critical mindset should not be demonized. IT — in the role of advocate diaboli — identifies stumbling blocks. And if you let them, they will develop solutions to remove those obstacles in good time.

An IT department constantly in firefighter mode is busy fixing problems that have arisen and cleaning up afterwards. What’s often missing then is the time to calmly develop viable solutions to complex challenges.

Creative hacks can’t be forced — and certainly not rushed. Sometimes it’s enough to give IT an extra week and the freedom to devise a thoughtful, sustainable solution. In the end, this usually saves both time and money.

If employees are already electronically connected on Day One, this significantly enhances collaboration. Anyone can find and contact anyone — across locations and company boundaries — thanks to email and video conferencing.

The prerequisite, however, is that contact details are easy to find. If you have to hunt for email addresses in the target company, you might not get invited to the meeting at all.

Mutual access to intranets also supports cultural integration. It offers insights into the “others”, allows differences to be perceived and shared values to be discovered.

IT can build bridges between old and new. Much is possible — if you involve them early and give them the necessary freedom they need. So far, this applies to any integration.

Buy & Build Needs Built-to-Buy

Buy & Build can only reach its full potential on a sustainable platform. This requires a powerful organization with efficient, stable processes — which, in turn, depend on a solid IT foundation: a modular, scalable IT application landscape.

This calls for preparation — and, above all, the early integration of IT into the strategic planning of the Buy & Build strategy. If IT is not built-to-buy, this foundation on which everything else depends is missing. Even the most creative platform architect cannot build a resilient structure in this case — only a fragile conglomerate that will eventually collapse.

If the goal goes beyond “more of the same”, scalable processes alone are no longer sufficient. That’s why it’s critical to consider modularity from the very beginning. How can AI agents take over core processes if the underlying data isn’t consistent? For example, if boreholes are measured in centimetres in one company and in inches in another?

IT that is deeply embedded in business processes and has a strong understanding of the business, can unlock additional synergies — not just to boost efficiency, but also to enable growth and innovation.

A built-to-buy IT department knows its application landscape inside out — and also has control over modifications and extensions. If the hedgehog hadn’t known the map, how could it have reached the finish line before the hare?

The Hedgehog Is Not a Know-It-All. He Just Started Earlier

IT is not slow — it is thorough. Who wants an invoice showing the wrong VAT rate or a customer receiving the wrong delivery just because both recipients happen to be named Meyer?

One possible solution for the role of IT in Buy & Build projects lies — quite fabulously — in Buxtehude. The fairy tale “Dat Wettlopen twischen den Hasen un den Swinegel up de lütje Heide bi Buxtehude” (Brothers Grimm, 1843) offers the idea: How can the hedgehog always be at the finish line?

Quite simply: it is in both places at the same time. One part of IT ensures the stable operation of existing systems (“run the platform”), while another part actively develops the platform and is involved in M&A transactions from the very beginning (“build & integrate the platform”).

Regular exchanges between these two teams are essential. Only then can they learn from one another and continuously improve the platform. “...and they both went home happy with each other: and if they didn’t die...”

In Buy & Build Projekten entscheidet nicht die Geschwindigkeit des ersten Zukaufs – sondern die Konsistenz des vierten. Wer bis dahin keine belastbare Plattform aufgebaut hat, rennt zwar mit hoher Geschwindigkeit – aber eben im Kreis. Und bricht irgendwann erschöpft zusammen.

And IT?
They were already there —
if you ask them in time.