A customer asks why an order shipped three days late last month. Your ERP can answer that for one order, on one screen, in seconds — it was built to run that exact order in the first place: check which warehouse can fulfill it, calculate pick time and shipping time, apply working-day and cut-off corrections, and move on to the next order. Ask the same database the same question for every customer, every warehouse, over the last quarter, and it starts to struggle. That is not a hardware problem. It is a modeling problem: you are asking a system built to handle one transaction at a time to answer a question about all of them at once.
Two jobs, two models
This is the split behind OLTP (online transaction processing) versus a model built for analysis. On a real delivery-time module built on the Infor ERP system, the operational side handles the live process:
- Check which warehouse or warehouses can fulfill an order
- Calculate pick time and shipping time per warehouse
- Apply working-day and cut-off corrections so the promised delivery date is realistic
That model is optimized to write and read one order correctly, fast, right now. It was never built to be summed, sliced, and compared across thousands of orders — and it shouldn't be forced to.
Rebuilding the same data as a star
For reporting on top of that operational process, the same data gets modeled differently: as a star schema (Sternschema), the structure behind the Kimball approach to analytical modeling. At the center sits one fact table, for example FAKT_Lieferung, holding the measures worth analyzing:
- Planned delivery time (Lieferzeit_geplant)
- Actual delivery time (Lieferzeit_ist)
- The deviation between them (Abweichung)
- An on-time flag (OnTime)
Around it sit dimension tables that describe the context of each delivery:
- Dim_Zeit — when the order happened
- Dim_Kunde — which customer it belongs to
- Dim_Lager — which warehouse fulfilled it
- Dim_Artikel — which product was shipped
That shape is what makes OLAP-style questions possible afterward: slice total late deliveries by customer, dice them by warehouse and time period, then drill down from "late deliveries this quarter" all the way to the specific warehouse-customer combination causing it. None of that is a query the operational Infor tables were designed to answer efficiently.
Getting the data there
The star schema does not fill itself. An ETL (extract-transform-load) step has to move data out of the operational system and into the analytical model, typically through change-data-capture — for example Debezium reading changes off the operational database and feeding them through a message pipeline before they land in FAKT_Lieferung and its dimensions. That pipeline runs separately from, and after, the operational transaction itself.
The practical takeaway for a workshop running its own ERP: if reports on delivery times, order backlogs, or machine utilization feel slow or awkward to build, the fix is rarely a faster server or one more index on the live tables. Usually no one has built the second model yet — the one whose only job is to answer questions after the fact, kept separate from the one whose job is to run today's orders.
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 →