What an MES actually does in a garment factory
MES stands for manufacturing execution system. Strip away the acronym and it is a simple idea with three layers stacked on top of each other:
- Data collection. Something on the floor records each unit of work as it is done — not at the end of the shift, not from a supervisor's notebook, but at the moment and the place the work happens.
- Execution visibility. Because the data arrives as work happens, someone can look at a screen mid-shift and see where work is piling up, which operation is starving, and which bundle has not moved since morning.
- Traceability. Because every record carries who, what, where and when, you can walk backwards from a finished garment to the operator, the operation, the bundle and the lot it came from.
That is the whole concept. Everything a vendor adds on top — scheduling engines, maintenance modules, document control — sits on this foundation, and none of it works if the foundation is missing.
MES versus ERP, stated plainly
An ERP plans and records the business. It holds the order, the costing, the fabric value, the payroll totals, the dispatch documents. It thinks in orders and money, and it is usually correct at the end of the day.
An MES runs the floor. It thinks in bundles, operations and operators, and it is useful in the middle of the shift. An ERP can tell you that a lot of 5,000 pieces was cut on Monday and dispatched on Friday. Only an execution layer can tell you at 11:00 on Wednesday that sleeve attach has 400 pieces waiting while collar attach has none, so the line is about to stall.
The two are not competitors. They answer different questions at different time scales. If you want the longer treatment of where the boundary sits, we wrote a dedicated explainer: ERP vs MES in a garment factory.
The MES functions a CMT factory actually needs
The textbook definition of MES lists eleven functions. A CMT contract factory — cut, make, trim, buyer-supplied orders, no design, no retail — does not need all eleven, and pretending otherwise is how factories end up buying software they never switch on. These are the ones that earn their place on a sewing floor.
1. Data collection at the operation
The foundation. Every bundle carries a QR code that encodes lot, article, colour, size, component and quantity. An operator scans it at the operation they are about to do. That scan records the operator, the machine, the operation and the timestamp. No paper ticket, no notebook, no end-of-shift transcription. Everything else on this list is derived from these records — which is why a factory that gets only this one function right still gets most of the value.
2. Product tracking and genealogy
Bundle-level tracking, not lot-level. Because the QR carries the component as well as the lot and size, the system knows that the fronts for a given lot-colour-size are at one operation while the sleeves for the same garment are three operations behind. That is the difference between knowing a lot is "in sewing" and knowing exactly which part of it will hold up assembly. See how the bundle system works for the mechanics.
3. Execution visibility and WIP
Because scans arrive continuously, work-in-progress is a live figure rather than a monthly count. Supervisors can see which operations are accumulating and which are starving. Items that have not moved beyond a threshold get flagged: supervisor views highlight work stalled beyond six hours, so a bundle that fell behind a machine at 09:00 does not surface at 18:00 as a mystery. Stuck-operation sweeps run every two minutes with a five-minute Cloud Function backstop, so the flagging does not depend on someone remembering to refresh a report. More on the practice: WIP tracking in a garment factory.
4. Dependency gating between operations
Garments are assembled from components, and some operations cannot start until their predecessors are done. The system holds an operation until the predecessor components for that garment are complete, so an operator is not handed work that physically cannot proceed. This is a modest, rule-based form of shop-floor control — it is not a scheduling engine, and we are careful about that distinction in the table below.
5. Performance analysis
Because every scan carries an operator, an operation and a timestamp, output per operator and per operation falls out of the data without anyone filling in a form. You can see which operations are slow, which operators are fast on which operations, and how a line's throughput changed across a week. WhatsApp bottleneck summaries go out at 11:00 and 15:00 so a supervisor gets the picture without opening a dashboard.
6. Labour management and piece-rate pay
On a piece-rate floor, labour management and data collection are the same act. The scan that records the work also records the pay. Pieces completed multiplied by the operation rate gives the operator's earning, calculated as the work happens instead of reconstructed at month-end from paper tickets. Repair bundles pay 1.5× the operation rate, so rework is compensated rather than argued about. Attendance comes from ZKTeco biometric devices over the ADMS protocol and sits alongside the same records.
7. Quality data collection
Defects are typed at the point they are found rather than summarised later: stain, tear or hole, size issue, stitching defect. Damage reports carry photo evidence and a severity level. Finished goods are graded A or B on SAC receipts, with the B-grade reason recorded by defect type and atomic receipt numbering in the form SAC-BSYEAR-NNNN. Because the defect is attached to a bundle, and the bundle has a scan history, a recurring defect type can be traced to the operations it passed through. Longer read: garment QC software on a CMT floor.
8. Dispatch and downstream record
The execution record does not stop at the last sewing operation. Challans carry printable picking lists, and a lot pipeline ledger tracks each lot through CUT → RECEIVED → DISPATCHED so the quantity that left the building can be reconciled against the quantity that was cut.
What Scan ERP covers, and what it does not
Scan ERP is not a full MES in the textbook sense, and we would rather you learn that here than three weeks into an evaluation. A classical MES specification lists eleven functions. Scan ERP covers some of them well, covers one partially, and does not attempt four of them at all. Here is the whole list.
| Classical MES function | Scan ERP | What that means on your floor |
|---|---|---|
| Data collection and acquisition | Yes | QR scan at every operation, recording operator, machine, operation and timestamp. |
| Product tracking and genealogy | Yes | Bundle-level history: lot, article, colour, size, component, quantity, and every operation it passed. |
| Performance analysis | Yes | Output and timings per operator and per operation, derived from scans; bottleneck summaries at 11:00 and 15:00. |
| Labour management | Yes | Piece-rate pay computed from scans; biometric attendance via ZKTeco ADMS; repair bundles at 1.5× the operation rate. |
| Quality management | Data collection only | Defect typing, photo evidence and severity, B-grade by defect type on SAC receipts. It records quality events; it does not run SPC charts or a quality workflow engine. |
| Process management | Partial | Dependency gating holds an operation until predecessor components are complete, and stuck work is swept every two minutes. That is rule-based control, not a process engine. |
| Operations scheduling / APS | No | There is no finite-capacity scheduler. Scan ERP does not compute an optimal line plan or sequence orders against machine capacity. Your planner still plans. |
| Dispatching production units | No | Work is not automatically pushed to operators by an algorithm. Supervisors and operators decide what gets picked up; the system records the result. |
| Maintenance management | No | Not a CMMS. No machine service schedules, no breakdown tickets, no spare-parts register. |
| Document control | No | No tech pack, SOP or drawing repository, and no revision control over factory documents. |
| Resource allocation and status | No | No capacity model of machines and tools reserved against a plan. Machine identity is recorded on scans, but it is not allocated by the system. |
Why bundle-level data collection is the foundation
Most of what looks like sophistication in MES software is, underneath, a consequence of collecting the right record at the right granularity. Get the granularity wrong and no amount of dashboard design rescues it.
A Scan ERP bundle QR carries six things: lot, article, colour, size, component and quantity. That is deliberately more than an identifier. Because the component is in the code, the system knows a bundle of sleeves from a bundle of fronts belonging to the same garment. Because the colour and size are in the code, it knows which bundles must converge before assembly can begin.
Each scan then adds four more: operator, machine, operation, timestamp. One physical act — the operator scanning the bundle they are about to work on — produces a record with ten dimensions on it. From that single stream, without any additional data entry anywhere in the factory:
- WIP is the set of bundles whose last scan is not the final operation — a live figure, not a count.
- Per-operator output is the scans grouped by operator; per-operation timing is the gap between consecutive scans on the same bundle.
- Piece-rate pay is pieces multiplied by the operation rate, so the payroll is a by-product of work that was already happening rather than a separate month-end exercise.
- Traceability for a buyer audit is the scan history of the bundle a garment came from, already stored, requiring no compliance team to assemble.
- Bottleneck detection is the operation with the largest queue of bundles whose last scan is its predecessor.
This is the argument for why an execution layer is cheap to run once it exists: nobody is doing data entry. The operator is doing what they were already going to do — picking up a bundle and sewing it — and the record is a side effect. Sewing floor management goes into how supervisors use that stream day to day.
One practical note on infrastructure: factory WiFi is imperfect everywhere. A Raspberry Pi on the factory LAN holds a cache so that brief WiFi blips do not stall the floor. Scan ERP is a connected system and we do not market it as offline-first — but a short drop should not become a stoppage, and the LAN cache is there for exactly that.
MES vs a spreadsheet: what changes on the floor
Nearly every factory that has not bought execution software is running one in Excel, plus a supervisor's memory. The honest comparison is not "software good, spreadsheet bad" — it is about which specific things change.
| On the floor | Spreadsheet + paper tickets | Execution layer with bundle scans |
|---|---|---|
| Finding a bundle | Supervisor walks the line and asks | Search the bundle; its last scan says the operator and operation |
| WIP figure | Counted when someone has time; stale by the time it is typed | Derived from scans; changes as work is done |
| Knowing a line is about to stall | Noticed when it has already stalled | Queue depth per operation, plus stalled-beyond-six-hours flags and 11:00 / 15:00 summaries |
| Operator pay | Paper tickets collected, transcribed, disputed, reconciled at month-end | Calculated per scan as the work is done; month-end is a review, not a reconstruction |
| Rework | Often untracked and unpaid, which is why operators resist it | Repair bundles recorded and paid at 1.5× the operation rate |
| Defects | A tally on a sheet, detached from the garment | Typed defect with photo and severity, attached to a bundle with a full scan history |
| Buyer traceability question | Days of manual assembly, if it can be answered at all | Already in the bundle's record |
| Component convergence | Discovered when sleeves arrive and fronts have not | Dependency gating holds the operation until predecessor components are complete |
| Dispatch reconciliation | Cut quantity and dispatch quantity compared, with a gap nobody can explain | Lot pipeline ledger: CUT → RECEIVED → DISPATCHED, with challans and printable picking lists |
Notice what does not change in that table. The spreadsheet's planning work — deciding which order runs next week, how to balance the line, when to service machines — is still planning work afterwards. An execution layer does not take it over, and any vendor implying otherwise is selling you a scheduling product under an MES label.
What it costs
Execution software sold to apparel manufacturers is usually quoted as an implementation project plus an annual licence, with the figure depending on modules and factory size. Scan ERP is priced on usage instead, because a CMT factory's ability to pay scales with what it produces:
- $1.50 per machine per month, or
- $0.005 per finished piece
- whichever bills lower, starting at $45 per month
There is no per-user fee, so putting the app in front of more operators does not raise the bill — which matters, because an execution layer only works if every operator is scanning. Full details and worked examples for different factory sizes are on the pricing page, and the complete function list is on features.
Who built this
Scan ERP was built by Santosh Rijal for Trishakti Apparel, his own 500+ machine CMT factory in Nepal, and it runs there every working day. Over 50,000,000 piece-operations have been tracked through it. That is the reason this page has a table of what the software does not do: everything on the "no" side is something we decided not to build, not something we forgot to mention. A factory owner reading a vendor page wants to know where the edges are, and the fastest way to earn that reader's trust is to draw them yourself.
If you are comparing named platforms rather than categories, the comparison hub lays out the head-to-heads.