Software for manufacturing
The plant runs a process. The ERP describes a different one. Everyone knows this, everyone works around it, and the gap between the two is where the stock figure goes wrong.
Every sector page here leads with the modelling problem that sector actually has — the exception that breaks the schema, the number two systems disagree about. If it could be rewritten for another industry by swapping six nouns, it would not be on this site.
The exception is the process
A manufacturing system fails when it cannot express the exception. The rush order that skips the queue because the customer matters. The batch that goes out at ninety-eight percent because the buyer accepted it on a phone call. The job that went to a sub-contractor because the machine was down, and came back with a different weight than it left with.
These are not deviations to be stamped out. They are the business responding to reality, and a system that treats them as errors gets bypassed — which means the data stops describing what happened. Once that is true, every report built on it is fiction, and nobody trusts the numbers enough to act on them.
So the first thing we do is find the exceptions and model them explicitly, with the approval that authorises each one. An exception that is recorded is data. An exception that is worked around is a hole in your books.
Job work and sub-contracting
Job-work tracking is where Indian manufacturing software most often breaks down. Material leaves your premises but not your books, comes back transformed, and the reconciliation has to account for process loss, rejections and the occasional short return — while remaining defensible for GST purposes.
Modelling this properly means treating the sub-contractor as a location in your inventory rather than as a customer and a supplier in sequence. Get that wrong at the schema level and every job-work report afterwards needs a manual adjustment, forever.
Shop-floor reality
Data entered at the end of the shift from a notebook is not shop-floor data — it is a recollection. If you want production data that is worth reporting on, capture has to happen where the work happens, which usually means a rugged tablet or a scanner and an interface designed for someone wearing gloves.
That interface has different rules from an office screen. Large targets, minimal typing, tolerant of a dropped connection, and honest about sync state — a worker needs to know whether what they just recorded has actually reached the system, because on a factory network it often has not yet.
The six things that decide a manufacturing project
These are where the schedule goes, and where a generic implementation quietly fails.
Production planning
Schedules that survive a machine breakdown and a rush order in the same week, with the re-planning visible rather than done by phone.
Job-work reconciliation
Material out, material back, process loss and rejections — modelled as inventory movement, not as sales and purchase.
Quality records
In-process and final inspection captured with the batch, retained for the period your customers and auditors require.
Traceability
Batch and lot genealogy in both directions, so a recall question is answered in minutes rather than in a week of paperwork.
Shop-floor capture
Interfaces built for gloves, poor lighting and unreliable wifi, with sync state a worker can actually see.
Costing that reconciles
Actual against standard cost per job, with variances attributable to material, labour or process rather than to a single unexplained number.
Systems for manufacturing
Not a product list — these are the shapes of system this sector keeps needing, built to fit rather than configured to approximate.
- Production planning and scheduling with visible re-planning
- Job-work and sub-contracting with GST-defensible reconciliation
- Quality management — in-process checks, non-conformance, corrective action
- Batch and lot traceability, forward and backward
- Shop-floor data capture on rugged tablets and scanners
- Maintenance scheduling tied to machine hours rather than to a calendar
- Costing and variance analysis that ties back to the general ledger
Manufacturing, answered
The questions that come up on a first call in this sector specifically.
Should we buy an MES or build one?
Buy the parts that are genuinely standard — inventory, purchasing, accounting — and build only where your process is a competitive difference rather than an inconvenience. In practice that usually means a standard ERP core with custom modules for production and quality, because those are the two areas where plants differ most from one another. Building the whole stack from scratch is rarely justified; so is forcing a genuinely unusual production process into a package that cannot express it.
Can the system work when the factory network drops?
It has to, and this is a design decision made at the start rather than added later. Shop-floor capture is built local-first: the entry is stored on the device, the worker sees clearly whether it has synced, and the sync resolves conflicts by an explicit rule rather than by whichever record arrived last. Retro-fitting offline behaviour into a system that assumed connectivity is close to a rewrite of the data layer, so it is worth deciding early.
How do you handle job work and GST compliance?
By modelling the sub-contractor as a location within your inventory rather than as a customer followed by a supplier. Material moves to that location under a delivery challan, is transformed there, and returns with process loss and rejections accounted for against the original quantity. That structure produces the job-work returns and the reconciliation your auditor asks for as a natural output rather than as a separate report someone assembles by hand each quarter.
Can you integrate with our existing machines?
It depends entirely on what the machines expose. Modern equipment with OPC UA or Modbus is straightforward. Older machines with a serial port and a proprietary protocol are possible but need investigation, and some machines expose nothing at all — in which case the honest answer is a scanner and a well-designed manual entry step rather than an integration that does not exist. We find out which category each machine is in during discovery, because the answer changes the scope significantly.
What this sector usually needs from us
- RunERP SolutionsImplementation, plus the custom modules the implementation always turns out to need in month four.Read more
- BuildCustom Software DevelopmentCustom platforms, marketplaces and SaaS. We write the parts that are specific to your business and buy the parts that aren’t.Read more
- GrowAI & AutomationLanguage models pointed at the two or three tasks where they actually beat a rule — and kept away from the ones where they don’t.Read more
- RunMaintenance & SupportTaking over a system someone else wrote — including the archaeology needed before anyone can safely change it.Read more
Working in manufacturing?
Tell us what your team works around every week. That is usually where the real project is, and it is a better opening than a requirements document.