The homegrown MRP system that runs your factory

It started as a bill of materials database. Then it became the factory.

A typical business running one of these has 30 to 120 staff on one site, makes to order in batches, carries somewhere between 500 and 5,000 live part numbers, keeps 50 to 200 works orders open at once, and has a buyer placing 200 to 600 purchase order lines a month. It does the same job whether it was started in 2005 or built in 2018.

Day to day it explodes a sales order into the parts and operations needed to make it, raises the works orders with the right drawing revision, tells the buyer what to order and when, prints the job cards and the route cards, books stock in and out, and produces the despatch note with the certificate of conformity behind it.

It is rarely alone. In many of these factories the accounts, and sometimes stock and purchasing, run in Sage 200 or a similar bought package, and the homegrown MRP sits beside it for the BOMs, the works orders and the route cards. Which of the two holds the stock figure everyone trusts differs from building to building.

The rules it holds are the ones no package would know:

• A BOM revision applies from a given works order number, and old stock is used up first unless the customer's drawing says otherwise.
• Each operation carries a scrap allowance, set years ago from what happened on the machine.
• Three customers use their own part numbers, and the system translates both ways.
• A works order cannot close until inspection has signed it, except for the product family that is inspected at despatch.
• The supplier lead times in the system are the buyer's memory, corrected by hand every time a delivery is late.

Started somewhere between 2003 and 2012 as a Microsoft Access database, written by the production manager who was good with computers or by a contractor brought in for a few months, to hold the BOMs. Works orders followed, then stock, purchasing and despatch. The data may have moved to SQL Server along the way or may still be an Access file on the office server, with a Visual Basic 6 helper program for the labels or the barcode wand, Crystal Reports for the job cards and the route cards, and a month-end export to Sage. The front end is copied to each PC in the office, and the back end lives on the server that came with the building.

The person who built it has other jobs to do, or has retired, and the last change was made with everyone out while the file compacted. Nobody has tried restoring the backup. It cannot be seen from the shop floor, so the time booking is on paper and the job status is a walk round the factory.

The same system built between 2016 and 2022, usually by a freelancer the accountant recommended or by a small agency, as a web system in PHP or .NET Core, or put together on Zoho Creator by the production manager who followed the one with the Access database. It opens in a browser, the stores have a tablet for goods-in, the MD has a dashboard with the shortages on it, and the biggest customer can log in to see where their order is. From the office it looked like the ERP question had been answered.

What stops it is the stock. The Sage link was written for the version the accounts ran then, and when the accounts moved up a version the two stock figures began to drift, so the stores keep a count sheet again. A fix to the purchasing screen broke the export outright and was taken back out. The freelancer has a full-time job now, and nothing underneath has been updated since it went live.

Since 2023 a few production managers have tried again with an AI app builder, got BOMs on screen quickly, and stalled at stock allocation, where the rules stop being simple. Either way it runs every day and cannot be changed with confidence, which leaves it as stuck as the Access file it followed.

A factory that knows what to make, what to buy and what it has, from one screen.

It is the reason the business never bought an ERP package. A package would need configuring to fit how the factory works; this system already fits, because it was written from how the factory works. A sales order becomes purchase requirements in seconds, and the buyer sees the shortages for next week before Monday.

Every works order goes out with the right revision of the drawing, which is why the returns are as rare as they are. Stock counts reconcile, because the system has booked every issue since 2005. When a customer asks for the certificate of conformity from a batch shipped three years ago, the stores find it in a minute. And at month end the figures go to Sage in one export, so the accounts and the factory agree.

Systems like this hold the factory together. What they stop doing is growing with it.

The Access ceiling. An Access file has a size limit and a limited appetite for several users at once. Somewhere past ten people the system slows, then it corrupts, and the office learns the phrase "everyone out while we compact it". The nightly backup is a copy of the file, and nobody has tried restoring it.

Only one person can change it. The person who built it is the production manager with other jobs to do, has retired, or is the freelancer who now answers in weeks. Whichever generation it is, changes queue behind production. The workaround for the workaround is a spreadsheet next to the system, and there are now several.

It cannot see the shop floor. Time booking is on paper or in a separate spreadsheet, job status is a walk round the factory, and the customer asking where their order is gets a phone call back that afternoon. The newer version has a dashboard, and the dashboard is fed from the same paper. The auditor asking for traceability gets three sources that mostly agree.

The platform is aging under it. Windows 10 support ended in October 2025, and the PCs by the machines are still on it. If the data moved to SQL Server 2016, its updates ended in July 2026. Neither stops the system today. Both make the Cyber Essentials renewal and the customer supplier audit harder each year.

The same BOMs and works orders, on the shop floor and in the stores, live.

Each of these builds on something the system already does well.

Works orders on the machine. The job card on a tablet by the machine, with the drawing revision and the operations, and a tick per operation as it is done. The office sees where every job is without leaving the desk.

Time booked where the work happens. The operator books on and off the job at the machine, and the actual time goes against the estimate. The scrap allowances stop being folklore and start being measured.

Stock that is right. Barcodes at goods-in, at issue and at despatch, writing to the same stock records. The stores stop counting to find out and start counting to confirm.

Purchasing from real lead times. Every delivery updates the supplier's lead time, so the buyer's memory is in the system and survives the buyer's holiday.

Traceability the auditor can follow. Batch, certificate, operator, machine and inspection on one record, reachable from the despatch note. The three sources become one.

Off the Access file. The data comes off the Access file onto a supported database, on a supported server, with backups that have been restored on purpose. Several users at once stops being a risk. The Access screens keep working against the new database until each one is replaced.

The old system is not switched off for any of this. Each piece is added beside it.

In the acknowledgements the buyer retypes, and in the questions about late parts that no report in the system answers.

The BOMs and the planning stay with the people who know the factory. AI works on the records and paperwork around them:

Supplier acknowledgements, read onto the order. The acknowledgement arrives as a PDF with a new date on two lines and a price change on a third, and the buyer types the changes in. AI reads it, drafts the update and shows the buyer what moved. At 200 to 600 order lines a month, with an acknowledgement on most orders at a few minutes each, that is typically one to two hours a week back for the buyer.

Which jobs is this late delivery holding up? The shortages report lists parts, not which works orders wait on which late purchase order, so the buyer works the chain out by hand before the production meeting. Asked in plain words, AI answers from the allocations and due dates, and lists the orders behind the answer so the buyer can check them. With 50 to 200 works orders open, most of an hour of preparation typically becomes a few minutes of checking.

Stock bookings that do not fit. An issue ten times the BOM quantity, a receipt against a superseded revision. AI flags them the day they are booked, so the stores correct a short list each morning in place of a day or two hunting before the stocktake.

Not worth doing: replacing the BOM editor with a chat window. Engineers want a grid, and a model that guesses at a BOM line is a scrap batch waiting to happen.

A draft purchase order change needs somewhere safe to land, and an Access file that corrupts under load is not that place, so AI follows the move off the file. The assessment maps where it would pay back on the system as it stands.

The first move is the one that removes the risk of losing everything.

1. Split and stabilise. The data comes off the Access file onto a supported database and the Access screens are pointed at it. Corruption stops, several users at once becomes normal, and there is a real backup. This goes first because a modernisation that starts on a file that could corrupt tomorrow is built on sand.
2. Shop-floor time booking. The first new piece is the one the office has never had: a screen on a tablet at each machine, booking time against the works order in the same database. Small, and live in weeks.
3. Stores and goods-in. Barcoded receipts, issues and despatch, writing to the stock records the Access screens still read.
4. The office screens, one at a time. Works orders, purchasing, then the BOM editor, each opened in a browser and run beside its Access form until the office chooses the new one.
5. Retire Access when nothing still opens it. The BOM editor is usually the last thing to go, because the engineers trust it.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For an MRP system that means a few days with the office, the stores and the database, finding the rules and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work, what drives the price and the payment terms each have a page, and so does each technology the system is built on: Microsoft Access, Visual Basic 6, SQL Server, Crystal Reports and Sage integrations, and for the newer generation old PHP and .NET Core.