Most manufacturing workshops start with Excel. Then someone adds a second spreadsheet for inventory, a shared folder for order confirmations, and a third file for supplier contacts. It works for a while. Then the workshop grows — more orders, more people touching the same numbers — and the same file system that used to feel simple starts producing wrong numbers, slow answers, and mistakes nobody can trace back to their source. This is not bad luck. It is a structural limit of file-based data management, and it has a name in database theory: the four classic disadvantages of a plain file system compared to a real database management system (DBMS).
1. The same fact lives in five places, and they disagree
When a customer's address or a part number is stored in one file, updating it is simple. When it is copied into a sales spreadsheet, a production sheet, and an invoice template because three different people needed it, updating it means finding and fixing it everywhere at once — and someone always forgets one copy. This is data redundancy and inconsistency (Redundanz und Inkonsistenz): the same information duplicated across files, drifting apart over time until nobody knows which version is correct.
2. Every new question needs a new program
A spreadsheet answers the questions it was built for. The moment someone asks something it wasn't designed to answer — "which orders shipped late last month, grouped by customer" — there is no general way to ask it. Someone has to open the raw files and manually write new logic against their specific structure. This is the problem of erschwerter Datenzugriff, difficult data access: without a query layer, every new question is a small development project instead of a question.
3. Data that belongs together lives apart
Orders, inventory, and production data usually end up in separate files, often in incompatible formats, maintained by different people. Even though a late shipment, a stock shortage, and a production delay are really the same underlying event, the data describing them is isolated in different places, so nobody can easily connect them. This is data isolation (Datenisolation) — and it is why so many workshops answer simple cross-department questions by asking three people and comparing notes, rather than by looking anything up.
4. Rules exist only where someone remembers to enforce them
A rule like "stock cannot go negative" or "an order must reference a real customer" is only as reliable as every single program and person that touches the files. In a plain file system, that rule has to be re-implemented everywhere it matters, and it is easy to violate silently — a typo, a skipped check, a new spreadsheet that forgot the rule entirely. This is the integrity problem: without a central point enforcing constraints, bad data gets in quietly and is discovered only when it causes a visible failure.
None of this is solved by "being more careful" or hiring someone to keep the spreadsheets tidier — it is solved by moving the data into a system built to prevent these four problems structurally: a shared, centrally-managed database with one query layer and enforced rules, which is exactly what a DBMS is designed to do. If your workshop's numbers already disagree depending on which file someone opens, that is not a discipline problem. It is a sign the data has outgrown the file system it is living in.
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 →