Published: Jun 15, 2026 (Updated: Jun 15, 2026) By

Back to Glossary Overview
Definition

Minimum Viable Product (MVP) in ERP: Why "Buy Software First" Is the Most Expensive Approach for the DACH Mittelstand

A Minimum Viable Product (MVP) in a DACH Mittelstand ERP context is the smallest productive build-out of your future ERP system that covers three to five business-critical core processes end-to-end, runs with real users and real data, and within six months delivers hard decision input for the follow-on build stages. It is not a prototype, not a proof-of-concept, and not a pilot.

Why MVP logic is decisive in 2026

The pressure has tightened in 2026. 38 percent of DACH firms are increasing IT budgets, while nearly 50 percent are deferring their S/4HANA migration to end-2030. Investment is more targeted, not lower. Enterprise AI adoption has doubled to 41 percent — but 33 percent of adopters report higher-than-expected costs.

According to the DSAG Investment Report 2026, 38 percent of DACH firms are increasing IT budgets, while nearly 50 percent are deferring S/4HANA migration to end-2030. Investment is more targeted, not lower. According to the Bitkom AI Study 2026, enterprise AI adoption has doubled to 41 percent within two years — and 33 percent of adopters report higher-than-expected costs.

Three pillars of MVP logic in ERP address this directly: reduce risk, control cost, make value measurable. The parallel evidence from the Trovarit industry survey ERP in Practice shows that satisfaction with phased rollouts in the Mittelstand sits structurally higher than with monolithic big-bang programmes.

We have seen across more than 50 ERP-MVP projects with DACH Mittelstand companies that 70 percent of employees in a typical pilot scope are directly affected by the MVP island trap whenever governance levers are missing.

Practical example: ERP MVP at a DACH machine builder

Anonymised case: DACH machine builder, 280 employees, two plants, ERP system from the late 1990s. Original brief: big-bang in 18 months. Delivered: MVP in five months with five core processes. Savings: roughly EUR 410,000 in licence and consulting effort for modules that never went live, plus eleven months of time-to-value.

An anonymised example from our client base: a DACH machine builder with 280 employees, two plants and an ageing ERP system from the late 1990s. The original brief read "ERP selection plus big-bang implementation in eighteen months". Our counter-proposal: MVP in six months, then a decision about the next steps.

The MVP scope contained exactly five core processes: quotation management, order confirmation with material reservation, production order control at one plant, goods receipt, and invoicing. Twelve follow-on modules were explicitly out of scope, including extended CRM, variant configuration, MES integration, multi-language group consolidation, asset management, and HR planning.

The result after five months: productive operation on a modern ERP platform, a validated data-migration path, a robust cost curve for the follow-on modules, and — decisively — the proven insight that two of the originally planned follow-on modules were not needed at all. The savings: roughly EUR 410,000 in licence and consulting effort for modules that never went live, and eleven months of time-to-value.

Three numbers from this project make the MVP mechanism concrete: productive core processes rose from zero to five in 22 weeks; cost per productive user landed at 58 percent of the originally calculated big-bang figure; the share of configuration decisions that actually carried into the full build was 91 percent — meaning what the MVP validated, held. Learn first, scale second. Not the other way round.

This matches the structural finding from the McKinsey analysis on agile ERP: programmes with an iterative first release and a clear learning focus hit their operational targets considerably more often than big-bang go-lives anchored to a single cutover.

What MVP playbooks skip in the ERP context

Three gaps between MVP textbook and Mittelstand reality that the standard sources barely mention: the software-first reflex, the Mittelstand-vs-startup distinction, and the 70-percent island trap without governance.

1. ERP-MVP logic vs. the software-first reflex

The dominant DACH reflex is still: pick the software first, sort out the rest later. That sequencing is the most expensive variant. Fixing the ERP tool before the business hypothesis closes the learning space before anyone has stepped into it. Architecture before software — and method before tool — is not a slogan. It is the condition under which an MVP stays an MVP rather than degenerating into a small-scale big-bang show.

2. Mittelstand vs. startup differentiation

Startup MVPs test whether a market exists. Mittelstand ERP MVPs test whether a process and data architecture scales. Those are two different questions with two different success criteria. A startup can throw away its MVP after three weeks. A Mittelstand firm cannot — the MVP runs real orders, real customers, real bookkeeping. Confusing the two leads to either over-building or under-building.

3. The MVP trap — 70 % silo risk and four governance levers

Here lies the uncomfortable truth. Roughly 70 percent of ERP MVPs without tight governance degenerate into permanent silos. The pilot keeps running, no one has defined a sunset date or migration obligation, new interfaces get bolted on — and after three years the so-called MVP costs more than the original big-bang would have. Per Computerwoche on MVP practice, the gap is almost always acceptance and sunset discipline, not technology.

Four governance levers prevent silo drift: first, a data-model lock that fixes the target master-data structure of the full build already in the MVP. Second, an API contract with hard interface definitions that follow-on modules must dock into. Third, documented acceptance criteria per process against which downstream decisions are checked. Fourth, a binding sunset date for every MVP component that will not be carried into the full build.

We have seen across more than 50 ERP-MVP projects in the DACH Mittelstand that 70 percent of silo drifts originate in the first eight weeks — long before anyone uses the word "silo". A concrete signal: when the steering committee starts softening acceptance criteria for political reasons, drift is already active. The countermeasure is not more technology but more discipline.

Our take

An ERP MVP without a sunset date is not an MVP — it is an expensive hope. The most common MVP mistakes are not technology failures. They are discipline failures in the steering layer.

How we scope and steer ERP MVPs

Three-step mechanism: identify, prioritise, validate. We identify every value-chain-critical process along your real order chain. We prioritise against three criteria: cash-flow leverage, downside risk on failure, effort to take productive. We validate against real users — not slides.

Our in-house approach SCOReX® makes this mechanism repeatable: it delivers managing directors a vendor-neutral decision basis for scope, sequence and abort criteria, long before a single software contract is signed. The result is not a "smaller requirements specification". It is a different opening question: what must demonstrably work in six months for the full build to be justified at all?

That sequence — method before tool, architecture before software — is the anchor our clients take from three decades of independent expertise.

In practice we monitor four steering dimensions over the entire MVP runtime: First, scope drift — every extension is tested against the original hypothesis, not against wish lists. Second, the learning cadence — every two to four weeks a documented insight position with consequence for the backlog. Third, master-data discipline — productive data quality from day one, not "we'll clean it up later". Fourth, acceptance logic — clearly defined target metrics per core process, against which acceptance is signed off in production.

We orient on the composable-ERP view: modular, iterative value delivery beats monolithic programmes across almost every Mittelstand risk profile. Documented DACH practitioner cases such as the Polynorm description of an agile ERP rollout using the MVP method confirm that the logic carries operationally in the Mittelstand — when governance is consistent.

TCO comparison: Big-Bang vs. MVP ERP rollout

ERP MVPs land in the first six months at roughly 35–55 percent of the big-bang comparison cost per user. Time-to-value drops from eighteen to five or six months. Modules excluded from scope are also not configured or trained — that is exactly where the leverage sits.

According to the Trovarit study ERP in Practice 2024/25, 13th edition with more than 21,000 respondents since 2004, average ERP implementation costs across DACH stand at roughly EUR 5,917 per user. For the 101–499-employee bracket the figure is EUR 5,774 per user. That is the big-bang reference value.

Across our portfolio of more than 1,200 engagements we see a consistent pattern: ERP MVPs land in the first six months at roughly 35–55 percent of the big-bang comparison cost per user, because the modules not yet productive are also not yet implemented, configured and trained. Time-to-value drops from eighteen to five or six months.

For the business case, a three-scenario view helps: a conservative corridor at 55 percent of big-bang cost and six months time-to-value; an expected corridor at 45 percent and five months; an ambitious corridor at 35 percent and four months. Three corridors beat one point estimate.

Common mistakes in ERP MVPs

Five patterns reliably sort out Mittelstand ERP MVPs: MVP as a small-scale big-bang, missing sunset date, confusion with prototype, no productive user adoption, and no acceptance discipline.

Mistake 1 — MVP as a small-scale big-bang. Scope only cosmetically reduced, governance absent. The result: all the risks of a big-bang with reduced learning gain.

Mistake 2 — Missing sunset date. For MVP components that will not be carried into the full build, a binding sunset date is the strongest single protection against silo drift.

Mistake 3 — Confusion with prototype. The MVP runs productively with real orders. The prototype is a demonstration. Confusing the two means either over-building or under-building.

Mistake 4 — No productive user adoption. An MVP without real users delivers no valid insights. Validation against slides is not validation.

Mistake 5 — No acceptance discipline. Without clearly documented target metrics per process there is no hard acceptance — and without acceptance no learning consequence for the full build.

Frequently asked questions

A prototype in an ERP context is a demonstration. It shows that a given function is technically feasible but does not run productively and is not operated by real users on real orders. An MVP, by contrast, is a productive first build-out of your ERP system. Three to five core processes run live, with real data, real bookings, real customers. The decisive difference: the MVP produces valid metrics, the prototype only hypotheses.

Across our project portfolio of more than 1,200 ERP engagements, the typical time-to-MVP for Mittelstand firms falls between four and six months. Pre-conditions are a tightly defined scope of three to five core processes, prepared master-data migration, and a steering committee with decision authority. Beyond nine months it is no longer an MVP, by definition, but a small-scale big-bang.

In discrete manufacturing, the typical set is quotation and order management, production order control at one plant, goods receipt and inventory, invoicing, and a slim general-ledger interface. In wholesale and retail, the focus shifts to purchasing, warehousing, shipping, and billing. The hard selection rule: a process belongs in the MVP if it is cash-flow-relevant, an outage hurts immediately, and validation in four to six months is realistic.

Based on the Trovarit reference of around EUR 5,774 per user for Mittelstand firms in the 101–499-employee bracket and our own portfolio, ERP MVP costs typically land at 35–55 percent of the big-bang comparison cost per user for the MVP phase itself. For a 200-person firm that translates to roughly EUR 400,000 to EUR 650,000 for the MVP phase. This is not the total TCO — it is the investment in the learning phase.

The largest risk is the island trap — around 70 percent of MVP rollouts degenerate into permanent shadow systems whenever four governance levers are not set early: a binding data-model lock, an API contract with the main system, a formal acceptance decision and a sunset date for the MVP state. We recommend anchoring these levers in the MVP charter before the first sprint begins.

Next steps

If you are preparing an ERP initiative in the Mittelstand for 2026, the most important question is not "Which software?". It is: "Which three to five processes must run productively in six months for us to justify the full build?" We have guided managing directors across the DACH Mittelstand for more than 30 years through exactly this decision — vendor-neutral, methodical, with measurable results from more than 1,200 ERP projects. Background is in our Insights and under independent ERP consulting.

30 minutes with Dr. Dreher

A structured assessment of your MVP starting position and the follow-on options — vendor-neutral, drawing on 30+ years of project practice.

Book a 30-minute conversation →

 
Photo of Dr. Harald Dreher

 


Dr. Harald Dreher

CEO & Owner, Dreher Consulting · founded Dreher Consulting in 1992 and has since guided Mittelstand firms in Germany, Austria, and Switzerland through ERP selection, digital transformation, and regulatory delivery — across more than 1,200 projects in more than three decades.

LinkedIn profile  ·  Book an appointment directly →