- Which station each part is at and how long it has been stopped
- Several open incidents per part, with the latest always in view
- Full history and an activity log of every change
- Several people working on the same screen at once, with no reloading
- Every movement signed by whoever made it
- Import and export to spreadsheets for the rest of the office
The problem
A part’s status lived in a spreadsheet and in the head of whoever had moved it last. To find out whether something was waiting on inspection, on paperwork or on an incident, you had to ask — and the answer depended on who was on shift.
What was built
A board covering the whole route, from incoming inspection to the despatch bay, with parts as cards you drag from one station to the next. The data is shared: what one person moves, everyone else sees instantly, without reloading the page.
The route guides but does not forbid. The arrows mark the usual path and a part can go to any station, because in a real plant the odd cases exist, and a tool that blocks them stops being used.
How you get in
Each person makes up their own PIN the first time they open the application. Nobody else sees it: not the supervisor, not the database, which only stores an encrypted hash. In exchange for a short PIN, every failed attempt leaves a line in the activity log, so if somebody is trying PINs it shows.
If somebody forgets theirs, there is nothing to look up: a supervisor blanks it and that person makes up a new one next time they sign in. Adding people, removing them and resetting PINs are all done from the application itself, and all of them require the PIN of whoever is doing it, checked inside the database.
How it is maintained
Adding a station to the route means touching one file. Adding a new field to parts means three, always the same three, documented one by one in the project manual. It is built so that whoever comes next can change it.
Measurable results: awaiting the client’s authorisation to publish them.