Every workshop that runs more than one system eventually hits the same wall: the ERP shows one stock number, the shop floor log shows another, and someone has to manually reconcile them every week — or worse, an order gets processed twice because two systems don't agree on its status. The usual reaction is to call this "an integration problem" and hope a developer can just "connect" the two systems. But integration is not one thing. It is five different things, and until you know which one is actually missing, nobody can fix the real bottleneck — they will just patch the symptom you happened to notice.
Integration has five different objects
In business informatics, this idea is formalized as the five integration objects (Integrationsgegenstände) — the different things that can actually be linked between two systems.
- Data integration means the same information is shared or kept consistent across systems, so a customer record or a stock level looks the same everywhere.
- Function integration means systems share business functions or services, instead of each rebuilding the same logic.
- Process integration means an entire business process — order to delivery, for example — runs across systems without a human having to bridge the gap by hand.
- Method integration means the same analytical or planning method (a costing method, a scheduling logic) is used consistently wherever a decision depends on it.
- Program integration means the actual software or code is linked at a technical level, not just the outputs it produces.
These five are independent of each other. A workshop can have excellent data integration — the same part numbers and stock figures everywhere — and still have zero process integration, because someone still has to open two screens and re-type a number to move an order forward.
Horizontal, vertical, and how far it reaches
Integration can also be described by direction and by reach.
- Horizontal integration links systems that sit at the same level — for instance, connecting the shop floor scheduling system to the purchasing system.
- Vertical integration links systems across levels — connecting daily production data up to management reporting.
Separately, the reach of integration (Integrationsreichweite) can be as narrow as one department, or as wide as crossing company boundaries entirely — for example, an EDI connection that exchanges orders or invoices directly with a supplier's or customer's system. A workshop might have solid integration inside its own four walls and none at all once data has to leave the building.
Naming which one is broken
This framework matters because most "our systems don't talk to each other" complaints are really a mix of successes and gaps that nobody has separated out. The data might already be shared correctly — that part of the integration works — but the process still requires someone to manually re-enter a number into a second screen, because process integration was never built. Or the reverse: the process looks automated on paper, but underneath, two systems are quietly drifting on the same data field, because nobody actually built data integration — they just built a workaround.
Treating "integration" as one single problem, instead of naming exactly which of the five is broken, is a common reason integration projects spend money without fixing the actual bottleneck.
Practical takeaway: before you ask anyone — a developer, a software vendor, or a consultant — to "integrate" two systems in your workshop, spend fifteen minutes naming which of the five is actually missing.
- Is the data inconsistent, or is data fine but a process step still requires manual re-entry?
- Is a function duplicated in two places, or is a planning method applied differently by two teams?
That fifteen-minute exercise usually points straight at the one fix that matters, instead of a project scoped around the word "integration" in general.
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 →