Every workshop manager has lived through this moment. It is close to the end of the shift, everyone on the floor is entering the day's production numbers into the ERP at the same time, and the system that felt perfectly fine all morning suddenly crawls. IT checks the server and finds nothing wrong. The software vendor checks the code and finds nothing wrong. Both are telling the truth, because the slowdown is not really happening in the software at all. It is happening inside a spinning piece of metal, and it happens to any system built on the same physical storage.
Two kinds of memory, and only one of them survives a power cut
Every computer, including the server your ERP runs on, works with two very different kinds of storage:
- Primary memory (RAM) is extremely fast, but it is volatile: switch off the power and everything in it disappears.
- Secondary storage (Sekundärspeicher) — a hard disk or SSD — is much slower to work with, but it is persistent. Every production record, every stock movement, every invoice your ERP saves has to eventually land on secondary storage, or it never really existed once the machine restarts.
That trade-off between speed and persistence is the starting point for everything else.
What actually happens in the moments before your screen updates
When your ERP asks the disk for a piece of data, the total access time (Zugriffszeit) is not one single operation — it is the sum of three separate physical steps:
- Seek time (Suchzeit): the read head has to physically move to the correct track on the disk.
- Rotational latency (Latenzzeit): the disk has to keep spinning until the right sector rotates underneath the head.
- Transfer time (Übertragungszeit): only after both of the above have happened does this begin — the moment the data is actually read and sent back.
None of these three steps is instant. All of them are mechanical.
Blocks, tracks, and why one report can create a queue
Data on a disk is not stored as loose files. It is organized physically into tracks and sectors, and read and written in fixed-size blocks, typically somewhere between 512 bytes and 8 kilobytes. A file in your ERP is really a logical sequence of records mapped onto a physical sequence of these blocks on the disk. Every single read request — one person opening an order, one machine logging a scan, one report totaling the day — has to go through that same seek, rotate, transfer cycle on the same physical disk. Ask for one thing at a time and it feels instant. Ask for forty things from forty workstations inside the same sixty seconds, and every one of those requests is queueing for the same physical read head.
This is not a reason to blame your ERP vendor, and it is not a reason to panic about your hardware either. It is a reason to ask a more precise question the next time your system slows down at the exact same time every day. If the slow window always lines up with shift change, closing time, or month-end reporting, the bottleneck is very likely the physical storage layer handling dozens of near-simultaneous requests, not a flaw in the application logic. That distinction changes what you actually fix: faster storage and better scheduling of heavy reports solve a physical bottleneck; rewriting the software does not.
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 →