How do you recognize that the data model is the problem?
The signals are recognizable once you know what to look for. Orders are duplicated because the system has no concept of suborders, so someone creates two separate orders and tracks the connection in their head. Spreadsheets appear alongside the system: one for the current status of an order, one for the deviations that do not fit in a field, one for the exceptions the planner tracks manually. Reports no longer match the shop floor, because the reality of a production order now has three layers that the system treats as a single line. These are not user problems. They are design problems. The data model describes an order as a flat object: item number, quantity, delivery date. But a production order in practice has subassemblies, semi-finished goods, intermediate steps with their own lead times, dependencies per machine or shift, and revisions that change the schedule without the system recording them. If the model cannot handle that, the organization starts working around it.
Why is the data model in custom production software set up too narrowly?
The cause is almost always the same: the system was built around the production process as it existed at the time. At the start, an order was straightforward. Five years later, ten product lines have been added, the company supplies customers who demand specific configurations, and orders are sometimes changed mid-process. But the data model has not kept pace with that development. Every time a new need arose, someone resolved it with an extra field, a workaround, or a link to a second table. This produces a model that functions technically but no longer makes conceptual sense. The order table now contains fields that are empty for eighty percent of orders, and exceptions are stored in free-text fields that cannot be searched. That is not a software defect. It is the result of incremental adjustments made without redesigning the underlying structure.
When does an AI layer help, and when does it not?
An honest answer: an AI layer helps when the problem lies in processing incoming information, such as documents, emails, or customer orders that you want to read in and match. An AI Worker can handle that flow and connect it to the existing system. But if the problem lies in what the system does with that order afterward, an AI layer solves nothing. If the data model cannot split an order into suborders, does not maintain a revision history, and has no awareness of dependencies between processing steps, you can build an AI layer around it and still face the same problems. The workarounds simply move from a spreadsheet to an API call that still gets no meaningful answer. An AI layer is valuable on top of a model that reflects reality. It is not a fix for a model that no longer does.
What principles help when redesigning the data model for production software?
The good news: you do not have to throw everything away. Redesigning a data model starts with mapping the real entities in your process. What is an order in the reality of your production environment? Is it a single object or a hierarchy? What statuses exist, and do they depend per phase on a different entity? From that description, you build a new model that reflects reality. Three principles that help. First: model the hierarchy as it exists in the operation, not as it was structured in the old system. If an order consists of suborders, make those explicit as a separate entity with a relationship. Second: store mutations as events, not just the end state. An order that changes must have a revision history that you can reconstruct later. Third: keep free-text fields out of the operational model. If something is relevant enough to track, it is relevant enough to have its own field or entity. What has historically been stored as free text indicates which entities are missing from the existing model. Those missing entities are precisely where the redesign must begin.
Is a completely new system needed, or can the existing one be extended?
That depends on how far the current model deviates from what is needed. If the core still holds and the extensions required are limited, you can refactor the existing system: add new tables, restructure relationships, adjust the application layer. That is a technical effort, but achievable without starting from scratch. If the foundation itself is wrong, meaning the central entities are incorrectly named or relationships are structurally absent, then refactoring is a patch that will hit the same wall in two years. In that case, a rebuild is the more honest choice. Not everything has to happen at once: you can start with the core of the data model, the most critical entities and their relationships, and migrate the application layer step by step. What you want to avoid is layering a new model on top of an old one. That leaves you with two models that contradict each other, and the workarounds return in the synchronization layer.