Planners and operators need different things from the same system. We build software that ties planning to the floor and automates the repetitive steps, so your team can scale without adding admin:
Six jobs. A scheduler that does the first three and not the last three produces a plan the floor ignores.
Machines, tooling, skilled operators and shifts. Most ERP planning assumes unlimited capacity, which is why the whiteboard survives next to it.
Grouping jobs by colour, material, tooling or temperature to avoid a setup. It is often the biggest gain on the floor, and why an experienced scheduler beats the system.
A job scheduled without the stock behind it moves the problem to the floor. Availability is part of the decision, not a check done afterwards.
Sales gets a date at the time of the quote, calculated from what is already committed. This is usually the feature that justifies the project.
Start, finish, good quantity, scrap and downtime reason captured at the machine. Without it the schedule drifts from reality within a shift.
When a machine is down at 6am, the schedule resequences what is left and shows what moves. Nobody rebuilds the week by hand.
On most sites each system works well enough on its own. The orders go missing in the gaps between them.
Raw materials and finished goods with a location, so a picker is not walking the racks looking for a pallet.
Servicing driven by hours run rather than the calendar, so a breakdown does not take the line out mid-order.
MES, quality, planning and the ERP joined up, so an order is entered once and every system reads the same record.
Job cost, stock and invoicing in one record, so the price you quoted and the cost you carried can be compared.
Most Australian manufacturers are not short of software. They are running an ERP like Pronto, Ostendo, SAP Business One or MYOB Advanced, a separate scheduling spreadsheet, an MES or SCADA layer on the plant, and Xero for the books, and none of it agrees. CodeFish builds the layer that joins them: reading job data out of the ERP, pushing actuals back, and putting one live view of the schedule in front of the people who need it. We do not replace the ERP you have spent years configuring. We make it answer the questions it was never built to answer, like what a job actually cost once rework and overtime are counted.
Connecting MES, quality and planning systems to the ERP is covered on our systems integration page.
Every one of them starts with a Rapid Insight Workshop: a paid session that maps your operation and hands back a prioritised roadmap. What you do next depends on what it finds.
We stay embedded and work through the roadmap with you month after month, from planning through to the shop floor. One monthly fee, measured against results we agree at the start. From $15K a month, six-month minimum term.
One build, scoped in writing before anything starts, then quoted at a fixed price against that scope. A one-year warranty, and the code and the IP are yours. Typically $100K and up.
Prove a scheduling or job-tracking tool on one line. Fixed price, $25K to $50K, and working software in four to eight weeks — enough to test it with real users before you spend more.
With a Rapid Insight Workshop. It maps the operational picture from planning through to the floor: which systems you run, where production data is being re-entered by hand, what the friction costs you, and which fix returns the most. You get a prioritised roadmap back before committing to a build. From there you either test one idea first (Ignite), build one thing at a fixed price and own it outright (Amplify), or keep us on to work through the roadmap with you month after month (Apex). We will tell you honestly which one fits.
Yes, and connecting them is usually the core of the work. Planning sits in the ERP, execution sits in the MES or on paper, and the gap between them is where schedules drift and jobs get counted twice. We integrate them so planning and the floor run off one picture instead of reconciling two.
That is what we design for. Interfaces need to be fit for purpose in industrial environments: readable at a distance, usable in gloves, and tolerant of dust, glare and interruption. Operators get tools scoped to their role and shift rather than a full system they have to navigate around.
Usually, and it is often where the fastest return sits. Scheduling, job sheets, batch records, quality checks and compliance paperwork are rules-based work being done by hand at scale. We automate the workflow where the rules are clear so your people handle exceptions and judgement calls instead of transcription.
Yes. We work in stages rather than big-bang replacements. The existing system stays in place until the replacement is proven, changes run through testing, and we cut over incrementally so the line keeps moving and you keep control of spend and risk.
Clear visibility into system state is a safety property, not just a productivity one. When operators can see what a machine is doing, what state a job is in, and what has changed on their shift, the guesswork that causes incidents goes away. Checks and permits captured in the workflow also leave a record that stands up to audit.
Yes, and it is most of the work. We read from and write to whatever you already run, through the API where there is one and a supported export path where there is not. The aim is that your ERP stays the system of record and stops being the place data goes to die.
That is the common case, and it is usually the highest-value thing to replace first. A spreadsheet holds the schedule fine until two people edit it, the shop floor works from a printout, and nobody can see the effect of a late delivery. We rebuild that as a live schedule everyone reads from, keeping the logic your planner already trusts.
Yes, and it is the safer way to begin. Pick the line or work centre where late jobs hurt most, connect it to the job data already in your ERP, and run it there while the rest of the plant carries on as normal. Your operators and production supervisor test it on real shifts, so problems surface on one line rather than everywhere at once. Once that line shows what can ship this week and why a job is running late, rolling out to the next line reuses the same connections and screens. You never have to stop production to get started.
Make logging a stop take one or two taps at the machine, not a form at the end of the shift. Where the PLC or SCADA layer already knows a machine has stopped, the stop is recorded automatically and the operator only picks a reason from a short list your team agrees on. Where there is no machine signal, a tablet at the work centre does the same job with large buttons that work in gloves. The production manager then sees stop reasons by line and shift the same day, instead of a clipboard tally that arrives on Friday.
It depends on how much of a full MES you would actually use, and that is the question to answer first. Many plants pay per-user or per-site licence fees for a suite where they use scheduling, job tracking and downtime, and leave the rest switched off. A build covers just those jobs, connected to the ERP you already run, and you own the code with no per-seat fee as you add operators. Where a packaged MES genuinely fits, we will say so. Our MES page covers the trade-off in more detail.
They will if the screen saves them time on their own shift. Operators ignore screens that ask for data only the office wants and give nothing back. We put the next job, the drawing or work instruction, and the quantity still to make on the same screen they log against, so using it is quicker than walking to the supervisor's desk. Leading hands and operators try early versions on the floor before rollout, and anything they skip or work around gets changed. If a field is not used by anyone downstream, it comes off the screen.