Loading
Industry — Manufacturing
Gujarat's SME manufacturing base runs on people who know their process better than any system does. The useful software here does not try to replace that knowledge. It captures what is already happening on the floor, at the moment it happens, and makes it visible to the people who plan and cost the work.
What we hear
Four problems that come up in almost every conversation in this sector. If none of these sound familiar, the rest of this page probably is not for you.
Problem 01
Production figures reach management through a supervisor's diary, a WhatsApp photo of a whiteboard and a spreadsheet compiled the next morning. By the time a shortfall is visible in a report, the shift that caused it ended two days ago.
Problem 02
Without recorded machine time, actual material issued and real rejection counts per job, a job cost is an average applied backwards. Quoting then carries a margin buffer to cover the uncertainty, which loses work that was actually profitable.
Problem 03
Inspection results live in files that are complete at audit time and useless the rest of the year. Nobody can query which batch, which machine and which operator a recurring defect correlates with, because the data was never structured for the question.
Problem 04
Newer equipment already exposes counters, cycle times and fault codes. Older equipment can be instrumented cheaply. In most plants neither is connected to anything, so downtime is reconstructed from memory rather than measured.
The other side of it
Rugged, low-friction shop-floor screens with large targets and few fields, usable with gloves on and readable under plant lighting. Where the network drops, the app queues locally and syncs when it returns.
Material issues, machine time, labour and rejections posted against a work order as they occur, so the cost of a completed job is assembled rather than estimated.
Inspection results linked to batch, machine, shift and operator, so a recurring defect can be traced to its correlates instead of being argued about.
Once run hours, cycle counts and fault history are recorded, maintenance scheduling can move from fixed intervals to observed condition. Predictive models are worth attempting only after that history exists.
What we build
The order below is the order we usually build in. Each stage produces data the next stage needs, which is why attempting predictive maintenance before you have run-hour history tends to end in a demonstration that nobody uses.
A work order that moves through operations with recorded start, pause, completion and quantity at each. Supervisors see the current state of every line without walking it, and the plan versus actual comparison exists per shift rather than per month.
Raw material, work in progress and finished goods tracked by batch or lot, with issue against work orders and consumption recorded as it happens. Reorder logic driven by actual consumption rates rather than a number somebody set two years ago.
Inspection plans, sampling rules, results and non-conformance handling, all linked to batch, machine, shift and operator. The point is not the certificate. The point is being able to ask which combination of those four correlates with a defect.
A plant-network gateway polling OPC UA or Modbus where the equipment supports it, and edge sensing where it does not. Machine state, cycle counts and fault codes are stored as a time series and rendered as a live floor view plus a shift summary.
Condition-based scheduling first, using run hours, cycle counts and fault history. Statistical modelling once enough failure history exists to learn from. Any model that goes into service is monitored for drift, and its recommendation is a work request for a human to approve, never an automatic instruction to a machine.
Offline-first tablet and handheld applications for the floor, with conflict rules per transaction type, syncing to a production layer that posts summarised movements back to the existing ERP through its API. The ERP keeps purchase, sales and accounts. It does not need to learn about machine cycles.
Transaction level
A single work order, traced through the points where information usually evaporates. Each step names what is captured, which is the difference between a system that can cost a job and one that can only display it.
The work order is released against a product, a quantity and a route of operations. Planned material and planned machine time are attached so that variance has something to be measured against.
Recorded here
Stock is issued against the order by batch, scanned at the store rather than reconciled afterwards. This is the first of the two places where costing usually breaks.
Recorded here
Start, stop and pause events with reason codes, plus counter readings from the machine where available. Downtime becomes a measured interval with a cause rather than a recollection.
Recorded here
Sampling as defined by the inspection plan, with results recorded against the batch and the machine. Non-conformances open with an owner and a due date rather than being noted verbally.
Recorded here
Good quantity, rejected quantity and rework quantity posted against the order. This is the second place costing usually breaks, because rework is frequently absorbed rather than recorded.
Recorded here
Actual material, machine time, labour and rejection cost assembled into a job cost and posted to the ERP. Quoting can then be based on what the work actually costs.
Recorded here
The two steps worth arguing about are material issue and completion. If those two are captured accurately and nothing else is, you already have a job cost. Everything above them adds explanation; those two add the number.
Constraints
Two audiences with opposite needs, which is why one dashboard for both usually satisfies neither.
Where to go next
The services below are the ones this sector draws on most. Case studies are published only with written client permission, and none are published for this sector yet. Ask us in a call and we will tell you plainly what we have and have not done.
Service
Service
Solution
Solution
Solution
Solution
Questions
Usually not. Most ERPs in SME manufacturing are adequate for purchase, sales and accounts, and weak at the shop floor. The common pattern is a production layer that owns work orders, machine events and quality records, and posts summarised material and cost movements back to the ERP through its API or a staged integration. Replacing a working ERP is a large, disruptive project that rarely pays for itself when the actual gap is floor-level visibility.
Only if the system assumes connectivity. Shop-floor apps should be built offline-first: transactions are written locally, queued and synced when coverage returns, with conflict rules defined per transaction type. This is a design decision made at the start, because retrofitting offline behaviour into an online-only application is close to a rewrite.
It depends what the machine already exposes. Newer PLCs and CNCs commonly support OPC UA or Modbus, in which case a small gateway on the plant network can poll counters, states and alarms. Older machines can be instrumented with a proximity or current sensor and an edge device to derive cycle counts and running state. Neither requires touching the machine controller. The first step is an audit of what each asset can report and what each report is worth.
Only if it is faster than what they do now. That means the fewest possible taps per transaction, scanning rather than typing where a barcode or QR exists, screens designed for the physical conditions, and no field that exists only because a manager wanted a statistic. Adoption is also a rollout question: one line or one cell first, with the supervisor involved in the design, before the plant.
After you have enough failure history to learn from, which usually means several months of recorded run hours, faults and interventions on the assets in question. Anyone offering predictive maintenance on day one is selling a threshold alert with a better name. Alerts on run hours and observed condition are genuinely useful in the meantime and are the right first step.
The most useful first conversation is not about scope or budget. It is walking through one process end to end with somebody who does it every day, and finding out where the data stops being trustworthy.
What happens next
