ERP Is Not Just Software

It Is the Nervous System of a Real Business

What a German hidden champion, an SAP S/4HANA greenfield project, and an unusual project setup reveal about transformation without theatre.

Note: This article is a personal reflection from the environment of an SAP S/4HANA greenfield project in the German mid-market. It is not an official project statement and does not speak on behalf of any company or project partner involved.

What interests me here is the pattern behind the story: What makes ERP transformation in the mid-market truly sustainable?

Free-link for non-members

-> If you like this kind of work => imagine to become a member

There are companies almost nobody knows by name.

And yet, almost everyone has encountered their products.

At airports. In production halls. In critical infrastructure. In tunnels. On machines. Inside control cabinets. Or at night in Paris, when the Eiffel Tower begins to sparkle.

Pfannenberg is such a company.

A family-owned company from Hamburg. Technically specialized. Internationally active. Not necessarily loud in the public arena, but visible through the impact of its products.

A good example of what is often called a German hidden champion.

And this is exactly why I found the SAP S/4HANA greenfield project there so interesting.

Not only because it was an ERP project. Not only because it involved S/4HANA. Not only because the go-live was successfully reached.

But because this project made something visible that often remains hidden behind success stories.

Success does not emerge only from systems, methods, or logos.

It emerges from a field of experienced people who know how to bring business, processes, and SAP together in a meaningful way.

The Hidden Champion as a Reality Test

The term hidden champion can sound like a nice label.

In reality, it is usually much more concrete.

Companies like this are not successful because they talk loudly about transformation. They are successful because, over many years or even decades, they have learned to solve very specific problems very reliably.

They know their products. They know their markets. They know their customers. They know the critical details on which real processes depend.

And this is exactly why ERP projects in such companies are demanding.

Because the task is not to place an abstract target architecture on top of an organization.

The task is to translate a real, grown, internationally active business into a new system in such a way that it does not merely look more modern afterwards, but actually works better.

In companies like this, ERP is not just software.

ERP is the nervous system of a real business.

• Production.
• Logistics.
• Sales.
• Service.
• Finance.

-> Master data. -> Variants.

=> Delivery capability. ==> International rollouts. ===> Operational control.

Everything is connected.

And when you work on such a nervous system, it is not enough to understand technology.

You have to understand what is really happening in the business.

Greenfield Is Not a Blank Sheet of Paper

SAP S/4HANA greenfield sounds, at first glance, like a fresh start.

A new system. New processes. New structures. New possibilities.

But in practice, greenfield is rarely a truly blank sheet of paper.

Especially not in the mid-market.

Even if the system is built from scratch, the company itself does not come from nowhere.

It brings history. Experience. Special cases. Customer relationships. Product logic. Sales channels. Supply chains. Grown responsibilities. Old decisions that once had good reasons.

A greenfield project is therefore not simply about deleting the past.

It is more about asking:

What must be preserved because it belongs to the business? What must be changed because it slows the business down? What must be rethought because the old logic no longer carries the future?

This is where the real work begins.

Not in the word greenfield.

But in the act of translation.

Between past and future. Between business departments and IT. Between proven process knowledge and new system logic. Between global ambition and concrete operational reality.

Architecture as Responsibility

Another interesting aspect of the project was the attitude toward the system decision itself.

In many transformation discussions today, it can feel as if the direction has already been decided in advance.

Cloud first. Standard first. Best practice first.

This can be right. In many cases, it is absolutely reasonable.

But it should not become a substitute for thinking.

Especially in the mid-market, the decisive question must remain:

What architecture truly fits the business?

Not the slide deck. Not the trend. Not the general transformation narrative.

But the company.

Its ability to steer. Its process reality. Its international structure. Its products. Its customers. Its ability not only to introduce change, but to operate it over time.

When a company consciously deals with its ERP future and does not simply follow a generic cloud narrative, this is not necessarily backward-looking.

It can be an expression of responsibility.

Architecture decisions are not fashion decisions.

They determine how much control, flexibility, standardization, scalability, and dependency a company will actually live with in the coming years.

The Underestimated Project Setup

What I found remarkable was not only the system side.

It was also the setup.

Experienced solo consultants. Small specialized consulting units. A larger implementation partner. Business departments with real process responsibility. And a customer who consciously steered the project directly.

On paper, such a setup does not automatically sound simple.

Different contractual models. Different companies. Different roles. Different perspectives.

But precisely there, one of its strengths became visible.

The connection did not primarily come from an org chart.

It came from experience.

Many of the people involved knew each other from previous projects, former company constellations, or shared SAP years. People knew who could do what. They knew working styles. They could assess competence. They knew where trust was justified.

This is not a soft factor.

It is project infrastructure.

In complex ERP projects, trust is not merely nice to have.

It is productive.

It reduces friction. It accelerates clarification. It enables direct communication. It helps keep conflicts factual. It prevents every issue from first having to pass through roles, hierarchies, or political defense mechanisms.

Of course, trust does not replace structure.

But structure without trust often only produces controlled slowness.

Experience Is Not a Nostalgia Argument

In transformation projects, experience is sometimes underestimated.

Maybe because it shines less than new methods. Maybe because it is harder to market. Maybe because experience does not always fit neatly into modern project slides.

But experience does not mean: “We have always done it this way.”

Good experience means something else.

It means recognizing patterns.

Knowing when a seemingly small detail will become expensive later. Sensing when a process has not yet been truly understood. Recognizing whether a customizing topic is really a customizing topic — or actually an unresolved business process. Distinguishing whether a problem is technical, organizational, or communicative. Knowing when to discuss — and when to decide.

This kind of experience is often decisive in ERP projects.

Because SAP is rarely just SAP.

SAP is the place where the organization becomes visible.

What is unclear in the company does not automatically become clear in the system.

It becomes more visible.

Sometimes sharper. Sometimes uncomfortable. Sometimes productive.

But always real.

Customer-Led Transformation

Another aspect that stands out to me: The customer consciously led the project.

That may sound obvious.

But it is not.

Many companies delegate ERP transformation largely to implementation partners, methodology models, or program structures. That can work. But it carries a risk.

The project may be well managed, but not truly owned by the company.

In a customer-led setup, responsibility remains where it belongs:

With the company itself.

The implementation partner contributes methodology, system knowledge, and delivery power. Specialized consultants contribute depth, experience, and clarification. The business departments contribute process reality. But the customer must decide what is right for its own business.

That is more demanding.

But it is also more honest.

Because in the end, it is not the implementation partner who has to live with the system.

The company does.

Every day.

ERP Transformation Is Translation Work

Perhaps this is the central point.

ERP transformation is translation work.

Not only from old system to new system. Not only from ECC to S/4HANA. Not only from process documentation to customizing.

But from business into system logic.

From experience into structure. From operational reality into manageable processes. From implicit knowledge into transparent workflows. From local solutions into scalable models. From past into future.

This does not happen through tools alone.

And it does not happen through methods alone.

It happens through people who can read both sides:

the business and the system.

The language of the business and the language of SAP. The operational necessity and the technical consequence. The historical cause and the future architecture.

That is where value is created.

Not in the beautiful transformation term.

But in the ability to understand the reality of a company so well that it can be represented in a new system in a sustainable way.

What Success Stories Often Do Not Tell

Success stories usually tell the result.

Go-live achieved. Project successfully completed. New system introduced. Partners delivered. Customer satisfied.

That is understandable.

But it often leaves out the most interesting part.

The many small decisions. The difficult translations. The experience in the room. The old connections. The trust between people.

The moments when someone says:

“This looks small, but it will matter later.” Or:

“This is not an SAP problem; this is a process problem.” Or:

“Here we need to decide, not continue modeling.”

That is often where the true quality of a project lies.

Not only in the official narrative.

But in the field behind it.

The Mid-Market Does Not Need Transformation Theatre

The German mid-market needs transformation.

But it does not always need transformation theatre.

It does not need maximum staging. It does not need overloaded programs. It does not need method labels as a substitute for thinking. It does not need cloud debates as belief systems. It does not need slide architectures that look stronger than operational reality.

It needs sustainable decisions.

Experienced people. Direct communication. Clear responsibility. Clean translation between business and system. And the ability not only to manage complexity, but to understand it.

That may be less spectacular.

But it works.

And sometimes the quality of a project shows precisely in the fact that it does not arrive loudly.

It simply goes live.

Closing Thought

For me, this project was more than a technical SAP success story.

It was an example of how mid-market transformation can work when several things come together:

a company with real global substance, a conscious architecture decision, a customer-led setup, experienced project participants, and a shared understanding that ERP is not just software.

ERP is the nervous system of a real business.

And whoever works on it is not merely working on tables, transactions, or processes.

They are working on the steering capability of a company.

That is why it is worth looking more closely at ERP projects.

Not only at systems. Not only at methods. Not only at logos.

But at the field of experienced people

that makes the difference.

Final note: This article does not describe an official success story. It is a personal observation about patterns of successful ERP transformation. Names, examples, and public references serve as a starting point for a broader reflection: ERP projects succeed not only through systems, methods, or logos — but through experienced people, clear responsibility, and the ability to truly connect business and system.