Production management system — structural steel fabrication

Every steel job from drawing to truck in one system that knows who may change what.

In build — production status to confirm with the delivery lead

category
Production management
deployment
Cloud-hosted · signs in with the business's own Microsoft directory, so there is no separate user list to maintain
  • 15 — Operational modules covering one continuous chain, from a drawing arriving to a truck leaving
  • 7 — Stages a job passes through — detailing, procurement, subcontract, fabrication, quality records, dispatch readiness, dispatch
  • 17 — Dedicated role-permission test suites, so who may do what is proven per module rather than asserted once

In a fabrication shop, the work is well understood. Where a job has got to is not.

A structural steel fabricator was running production on a spreadsheet. A spreadsheet holds whatever was last typed into it, so the only complete picture of a job is the one you assemble by asking people.

Progress becomes a number in a cell rather than something the system can show, which turns the weekly report into an exercise in reconstruction. Quality records get gathered near the end, at exactly the point where a missing document costs the most. And a spreadsheet does not know who you are — nothing separates an estimator from a coordinator except knowing not to touch a cell.

What was built

  • One record per job, across the whole chain. Detailing, procurement, subcontract work, fabrication progress, quality records and dispatch attach to the job itself rather than to each department’s own list.
  • Progress recorded, not reported. It is entered against the job and carries an audit trail, so the weekly report becomes a query instead of a recollection.
  • Permissions proven per module. Roles are enforced at the interface between the app and its data, with dedicated tests per module — a change that breaks an existing rule fails the build rather than surfacing later as someone quietly doing something they should not.
  • Quality records built during the work. A checklist maintained as the job proceeds, so completeness is visible before dispatch rather than discovered after it.
  • Dispatch against readiness. Truck runs are scheduled for jobs that are actually ready, with eligibility applied by the system rather than judged at the loading dock.

The decision that made it work

The job is the spine, and every stage attaches to it. Modelling the chain rather than the departments is what makes the single question — where has this job got to? — answerable at all.

Roles went in before features, built into the interface between the app and its data rather than layered over it afterwards. That is why permissions can be tested module by module instead of checked once at a login screen.

Sign-in runs on the directory the business already administers, which removed an entire category of account management from the project — no second set of credentials to issue, rotate, or forget to revoke when somebody leaves.

A comparable fit if you are

  • Running production off a whiteboard and a spreadsheet per department, with no single answer to where a job has got to.
  • Reconstructing weekly progress from conversations rather than reading it off the work itself.
  • Assembling quality documentation at the end of a job and finding the gaps at the worst possible moment.
  • Giving everyone the same access because separating it has never seemed worth the effort.

The same spine, a different trade

The chain differs by trade, but the shape holds wherever a job crosses several departments and the only complete picture is the one people assemble by asking each other.

Talk to us