Every workshop that installs an ERP system eventually asks for "just one small change." Add a field to the goods-receipt screen. Change how a discount is calculated. Make the system talk the way the shop floor already talks. The request sounds small. Whether it stays small depends entirely on which part of the ERP you are asking to change — and almost nobody making the request knows that different parts carry completely different risk.
Standard software is generic on purpose
In business informatics, standard software (Standardsoftware) is defined as software that can be used across different companies without substantial changes. That is the entire reason to buy standard ERP instead of writing your own: the vendor spreads development cost across hundreds of customers, and you get a working system in weeks instead of years. But being usable by hundreds of different companies means the software has to be generic. It cannot already know how your workshop calculates a rush-order surcharge, or how it numbers work orders.
Five layers, five different levels of risk
The Kern-Schalen-Modell (core-shell model) describes this generic-to-specific structure as layers wrapped around one another:
- Technical core — the database engine and base platform, identical for every customer.
- Business core (BWL-Kern) — generic accounting and business logic that applies to almost any company.
- Industry-type layer — distinguishes something as basic as discrete manufacturing from process manufacturing.
- Industry layer — automotive logic looks nothing like furniture-making logic.
- Company-individual layer — the specific rules of your workshop, and nobody else's.
The pattern that matters: the further out from the core you go, the more customization a company needs — and the more fragile and expensive that customization becomes to keep alive across every future version upgrade of the ERP.
Not every kind of change carries the same risk
Vendors call the process of adapting standard software to a company "Adaption," and it comes in three forms:
- Customizing — configuring the system within parameters the vendor already built and supports, switching options on and off, filling in settings tables.
- Modifikation — changing the underlying source code of the core itself.
- Erweiterung — bolting on separate add-ons alongside the core system.
Customizing done purely through configuration, without touching source code, is called Parametrisierung (parametrization) — and it is the safe zone, because it keeps the system Releasefähig: fully compatible with the vendor's next release. Modifikation of the core is the risky zone. It might solve today's problem, but the next ERP upgrade can silently break it, and nobody notices until production stops.
Where the outermost layer actually gets built
This is exactly why the outermost, company-individual layer is usually built as a separate extension sitting on top of a standard ERP, rather than as a change to the ERP's own source. Independent ERP consultancies, for instance, build that company-specific layer on top of clients' standard ERPs — systems like Infor or ABAS — precisely because the layers underneath cannot and should not be touched.
Before you approve the next "small customization" request in your ERP, ask one question first: which layer does this actually touch? If the answer is a configuration option the vendor already supports, say yes without worrying. If the answer is a change to the core logic itself, treat it as a separate, budgeted decision — because you are not paying for that change once, you are paying to redo it at every future upgrade.
Nguyễn Hải Minh
I build custom software and data solutions for manufacturing ERP systems, including INFOR, for clients in Germany. As a Staatlich geprüfter IT-Techniker (Fachrichtung Informatik) and Informationselektroniker, I combine deep technical skill with business-systems thinking to help manufacturers automate operations and optimize cross-border import and export.
More about the author →