How Thorpe Packaging replaced an unsupported ERP with a complete operational system, material planning, shop floor execution, quality management and warehouse control, developed on the Simportal platform and adopted through a staged, evidence led transition.
Sector: Food grade packaging conversion
Operation: Reel based stock, live production that cannot pause
Challenge: An unsupported legacy ERP and growing concern that system records no longer reflected what was happening on the shop floor
Delivered: Materials planning driven by live availability. MES (Manufacturing Execution System): production execution via job number and mistake proofed material IDs. QMS (Quality Management System): goods in inspection, photographic nonconformance capture, batch traceability for food grade compliance. WMS (Warehouse Management System): scanner driven warehouse with live material visibility and proactive line side replenishment, spanning order to cash, with the ledger in Sage.
Reporting: OTIF, a version of OEE suited to the operation, and operator level performance, all drawn from live activity
Go live: 1 July, chosen by Thorpe to align with the start of its financial year, two to three months later than Simportal was ready
Accounts: Integrated with Sage
Result: The legacy ERP retired with no interruption to production and operational data the business can trust
Thorpe Packaging was running on a legacy ERP that remained central to the business but was no longer supported and increasingly difficult to adapt. The age of the ERP was not the real problem. The real problem was that confidence in the information it produced was gradually eroding.
Materials moved through the operation on scanners, but the system demanded strict process adherence through an interface that was difficult to use under production pressure, so steps were sometimes missed. Scheduling had left the system altogether: the running order was built on a table top, with physical job cards laid out by hand into piles. Stock movement requests were typically coordinated by photographing a code and sending it into a WhatsApp chat, so movements after production were not always completed in real time.
Over time, operational control started depending on workarounds rather than systems.
“A table of job cards works, and works well, right up until the person who understands the piles is away.”
The records on screen no longer reliably matched what was happening on the floor, and traceability had become genuinely convoluted: getting from a source reel to a finished reel meant checking the old system, then the paper job card, then the two against each other by hand. Audits depended on manual reconciliation and individual knowledge.
Replacing the ERP outright carried significant risk for a live manufacturing operation. Continuing as they were was becoming increasingly difficult. Thorpe needed a third option.
Purchasing, goods in and stock movements are captured in real time. Production is planned against live material availability rather than piles of job cards on a table. The system knows what is on site, what is committed and what is needed, because it is fed by the operation itself.
Operators record movements, usage and completions at the point they happen, through an interface built for the pace of live production rather than against it. At the machine, no scanner is needed: operators work with the job number and the human friendly identifier on the raw material, six letters, grouped three and three so it is easy to read and key in. Six letters give over 308 million possible codes, and only a small fraction are ever in use. Mistype a code, or use one that has not been issued, and it almost certainly matches nothing, so the system rejects the error rather than booking material to the wrong job. Wrong entries fail safely instead of passing silently.
The MES also produces the finished reel labels. As each reel comes off the slitter it is labelled with its own six letter code, plus the operator, machine and lane that produced it. The record of how a reel came to exist is created at the moment it exists, not written up afterwards.
Traceability runs from goods in to finished reels leaving the site. When a reel arrives damaged, the operator photographs it before it leaves the vehicle, linked to the reel’s six letter identifier, resolving supplier questions before they become disputes. Audits, recalls and food grade compliance draw on data embedded in daily activity, not reconstructed after the event. A single traceability lookup that took more than 20 minutes is now instant. Gathering everything needed for a full audit, once well over an hour against a two hour ceiling, now clears in a fraction of that.
The traceability chain runs: source reel, six letters, then slit finished reel, six letters, then pallet, four letters, then delivery note, then invoice, then Sage.
The part that matters most is what happens at a join. A slit finished reel may carry two or more source reels within its traceability thread, and Simportal holds all of them, so the thread works in both directions: a query on any source reel returns every finished reel containing part of it, and a query on any finished reel returns every source reel that went into it. That is the difference between traceability that satisfies an audit and traceability that survives a recall.
That mistake proofing was recently extended further. If an operator forgets to log a second reel joined into a run, the system calculates the expected finished reel weight from the first reel’s own yield, and flags the run as overweight against what a single reel could have produced, catching the omission automatically rather than relying on the operator to remember.
For example, a finished reel might carry the code AGZ EFW: six letters, grouped three and three, so a chunked code is easier to read and key in without error. It carries the machine, lane, time and operator that produced the reel, and every source reel in its thread. A pallet might carry the code ER QW: four letters, grouped two and two, identifying the pallet that groups finished reels travelling together, and tying them to the delivery note and the invoice.
Every link in that thread is mistake proofed on entry. So the answer to a traceability query is not merely fast. It is the answer the operation actually recorded.
The warehouse runs on scanners. Pallet movements, picking and put away are captured as they happen, so stock records reflect reality rather than yesterday’s paperwork. And the warehouse does not wait to be asked: staff see the live material position for every job running on every machine, and for the jobs coming next, so replenishment happens ahead of need. If material runs critically low, production staff have a call button direct to the warehouse. The principle is simple: machines never stop for want of material. Under the old system, stoppages from material shortages were never measured, though everyone knew they happened. They are measured now. Since go live, there have been none.
Customer orders sit in the same system as production, despatch and invoicing. The delivery note ties the reels and pallets on the vehicle back to the jobs and source material that produced them, the invoice is generated from that same record, and the invoice information is exported into Sage. The commercial flow is not a separate world bolted onto the operational one.
That matters for the same reason the original problem mattered: when the order, the production record, the despatch and the invoice all draw on the same data, there is nowhere for drift to occur. An invoice reflects what was actually made and shipped, not what someone retyped from a docket, and there is no month end exercise reconciling the operational picture against the financial one, because they were never separate.
Capturing activity accurately is the foundation, not the point. Because every movement, completion and delivery is recorded as it happens, Thorpe’s key performance indicators come out of the operation itself rather than being assembled by hand at month end. Three matter most.
OTIF, On Time In Full: whether the business delivered what it promised, when it promised it, drawn from despatch activity, not memory and paperwork.
OEE, a version of Overall Equipment Effectiveness suited to the operation: how much genuine output the plant produces against what it is capable of, and where the losses actually sit.
Operator performance: who is running more than one machine at once, and how closely produced work matches the planned time.
For a director, this changes the character of the decisions being made. Whether to take on another salesperson or buy another machine were once questions answered on judgement and a feel for how busy the factory seemed. They are now answered against measured capacity and measured delivery performance: if there is real headroom on existing equipment, more sales capacity is the sound investment. If the plant is genuinely at its limit, new kit is. The same data answers both.
Peter Jolliffe was also keen to understand how individual operators compare. Because the operator is captured on every reel label as a matter of course, that comparison asks nothing additional of anyone on the floor. It is simply a result of the way work is already booked, not a new reporting burden laid on top.
We started by understanding how materials and production actually moved through the business rather than how the existing ERP assumed they should move.
Instead of proposing a disruptive rip and replace project, we introduced Simportal alongside the legacy ERP and started with materials.
Materials went live almost immediately, and that mattered for more than speed. Once real material was moving through Simportal, production processes could be developed against what was actually happening on the floor rather than a specification written in advance. Each stage made the next easier, and the system that resulted was shaped by the operation rather than imposed on it.
A warehouse already full of material is usually the reason a change like this cannot be made quickly. Thorpe’s was stocked under the old system, and none of it could be set aside while a new one was populated. So the existing stock data was imported, and the warehouse team was given one simple task: scan the old label, apply the new six letter Simportal label. The two identities linked in the course of ordinary work, not a shutdown or a stock take weekend.
Crucially, Simportal ran in parallel with the existing ERP. Management and operators could compare both systems side by side, validate the information being produced and build confidence gradually. Parallel running also produced the stock accuracy figure: because Simportal went live on stock early while the legacy ERP was still running, both systems counted the same stock independently, and the two could be compared. The figure is not a system reporting on itself, it is two systems reconciled against each other.
Only once that confidence was established were scheduling, production completion and wider processes brought fully into Simportal. The transition happened through evidence rather than a leap of faith.
The go live date was Peter’s to choose, and he chose to wait. Simportal was ready two to three months earlier. He held until 1 July, aligning with the start of his financial year: a cleaner cut in the ledger, and more evidence on the table before anything was switched off. The timetable belonged to the customer, not the software.
The MES was built four times. Not revised, rebuilt. We did not understand Peter’s machines as well as we thought: different lanes, works orders, customers, bag and pallet specifications, reel joins, several label types. None of it could have been specified accurately in advance, by us or by Thorpe. It emerged.
What made it survivable was the cycle time. A version of the MES could be built in three or four days, put in front of the people who use it, reviewed over the following week, and rebuilt on the feedback. Four rounds of that is not a failed project. It is a specification being discovered rather than guessed. On a conventional implementation the same discovery arrives as a change request after go live, with a cost attached and a queue to join.
Only once the rules were right did usability become the focus, and that is a separate discipline again. Building something simple to use and genuinely complex underneath takes sustained effort from both sides. Thorpe reviewed every version. That is what it costs, and it is worth being straightforward about it.
The old ERP did not fail because it was badly built. It failed because it was awkward under production pressure and nobody removed the awkwardness. Any platform can decay that way, including this one. So we did not leave at go live: we continue to visit, watch people work and act on what they suggest, removing friction as it is found. There is already a full roadmap of development agreed with Thorpe for the next twelve months, starting in the near term with plastic tax calculations. That is the difference between a system that still reflects the floor in three years and one that quietly stops.
Most importantly, operational control was restored.
The business now works from information embedded within day to day activity rather than information reconstructed after the event. Decisions are made using data that reflects reality, not assumptions.
“The difference wasn’t what Simportal replaced. It was how the transition was managed.”
Control was restored without a single day lost to the transition.
“The transition happened gradually, giving us confidence in the data before switching anything off. We improved control without disrupting production.”
Peter Jolliffe, Director
Many manufacturers believe they face two choices:
Thorpe chose a third option.
Start with the area where control is slipping most. Run in parallel. Prove it with evidence. Transition when the evidence supports it.
Today the whole operation, materials, production, quality and warehouse, runs on a system shaped around how Thorpe actually works.
If operational control is starting to depend on spreadsheets, workarounds or key individuals, let’s start with the operation rather than the software.
A five minute Operational Control Review is enough to identify where control may be slipping and whether a staged approach could help.