Garment Factory ERP — How Our Small CMT Factory Tracks 100,000+ Pieces a Month Without SAP

I'm a medical doctor who owns a garment factory. I built my own garment factory ERP because nothing on the market worked for us. This is an honest account of what broke, what we tried, what we built, and what the numbers look like now — 115,370+ pieces tracked and counting.

This is a real factory. 42 sewing operators, 5 machine types, piece-rate pay, QR bundle tracking. This is the account of what broke, what we tried, and what the numbers look like now — 115,370+ pieces tracked and counting.

The Day I Knew Excel Was Over

It was a Thursday evening — payday week. My supervisor was hunched over a laptop, surrounded by three different registers, a calculator, and WhatsApp messages from five operators who all claimed their piece counts were wrong. She'd been at it for over three hours. The salary run for 37 sewing operators was still not done.

I walked over and asked her what the problem was. She showed me: one operator's bundle tally sheet said 1,840 pieces. The Excel register said 1,720. The operator herself was insisting she'd done "at least 1,900." No one was lying. Everyone was working from a different count, recorded at different times, under different conditions, by different people.

We paid based on the register figure — 1,720 — and that operator didn't speak to her supervisor for two weeks. That month, we had four disputes like this. Each one took time, damaged trust, and ultimately resolved with someone being paid less than they believed they'd earned.

I'd been running the factory on Excel and handwritten registers for two years by then. We were producing between 95,000 and 100,000 pieces a month. At that volume, manual tracking wasn't just inconvenient — it was actively costing us money in lost pieces, disputed payments, and supervisory time that should have been spent on the floor.

That Thursday evening, I knew we needed a proper small garment factory ERP. I just didn't know yet that I'd end up building it myself.

Why SAP and WFX Were Never an Option

I'm not someone who dismisses software tools without investigating them. I spent about six weeks looking at what was available for garment factory management. I looked at SAP's SMB products, WFX, Stitchflow, and several other platforms marketed at garment manufacturers.

The honest conclusion: none of them were designed for a factory like ours.

SAP, to be blunt, was absurd. It would have required a consultant to implement, a dedicated IT person to maintain, and a year of disruption to roll out. For 37 sewing operators in a CMT factory our size. The ROI was negative before we even signed the contract.

WFX was closer to the right direction — it's built for garment manufacturers — but its pricing assumed a larger operation with full-package capabilities. More than that, when I dug into the feature set, the piece-rate payment module worked the way software people imagine piece-rate works, not the way it actually works on a factory floor with five machine types, colour-based work ownership, and operators moving between operations.

This is a problem with garment factory software for small factories in general: it's often designed by people who have toured garment factories, not by people who have run one.

For context: in India, 99.6% of garment and textile MSMEs are micro-enterprises with fewer than 10 workers. Even factories with 20–50 sewing operators are considered mid-tier in the Indian context. The typical CMT unit produces 300–600 garments per day depending on style complexity. We sit in the mid-tier by regional standards. Yet every enterprise software vendor we spoke to treated us either as too small to bother with, or assumed we had a full procurement and design function we simply don't have.

What We Actually Needed on the Floor (Not What Vendors Said We Needed)

After the failed evaluation, I sat down with my supervisors and wrote a list. Not a feature wishlist — a list of the exact problems that were making our lives difficult every single week.

It came down to four things:

First: Know exactly where every bundle is, at all times. When a buyer calls to ask about their order, I want to be able to answer in 30 seconds without walking the floor. When a bundle goes missing between cutting and delivery, I want to know which station it was last scanned at and who had it.

Second: Calculate piece-rate payment without any manual steps. Every time a piece is completed, that count should go directly into a running total. At salary time, the number should be a database figure, not a reconstructed estimate from three different registers.

Third: See which line is falling behind, in real time. Not at end of day. Not in a morning report. Right now, so I can act on it while there's still time to act. If 200 bundles are piling up at the overlock station, I need to know that at 10 AM, not at 5 PM.

Fourth: Have an audit trail for every piece. Which operator sewed which bundle, at what operation, at what time. When quality issues come up — and they always do — I want to trace the problem to the source, not point fingers at whoever touched the garment last.

Those were the four real problems. Nothing about procurement. Nothing about BOM management. Nothing about supplier relationships. Pure CMT floor problems that an affordable garment ERP should solve — and that generic enterprise software completely ignores.

Building It: The First Version Was Embarrassing

I want to be honest about the first version, because I think factory owners considering building their own software need to know that the first version will be bad. And that's okay.

My background is medicine, not software development. I learned to code during the months I spent trying to solve this problem. The first version was a web app that operators could open on their phones. It had a QR code scanner, a simple form, and a database behind it. Operators would scan a bundle, tap their name, tap the operation, and hit Submit. That was it.

It broke constantly. The QR scanner failed in the factory's lighting conditions more often than not. The form had too many steps. Operators would scan, get confused, scan again, and we'd end up with duplicate entries. I spent three months fixing one problem at a time.

What I was building — though I didn't know the term at the time — was a small garment factory ERP from scratch. It was exactly what we needed and nothing we didn't. No procurement module. No BOM management. No supplier database. Just: this operator, this bundle, this operation, at this time. Recorded. Counted. Totalled.

The QR code system went through seven versions before it reached the 95-99% scan accuracy it has today. I added a small hardware device — a Raspberry Pi connected to our factory network — that acts as a bridge between the operators' phones and the cloud database. It also powers the live supervisor dashboard that updates every few seconds. The same device sends WhatsApp reports to my phone at 6 PM every evening: how many pieces completed today, which operators are below target, which bundles are still in the pipeline.

None of this was built by a software company. It was built by a factory owner who needed it badly enough to learn how to build it. That's both the advantage and the limitation — it's exactly right for our operation, but it took two years to get there.

What 100,000 Pieces a Month Looks Like Now

Today, our small garment factory ERP tracks every bundle from the moment it leaves the cutting table to the moment it's packed for dispatch. Here's what a typical production day looks like now.

In the morning, the cutting room supervisor enters a new cutting sheet into the system: lot number, style, sizes, colours, bundle count. The system generates a QR code for each bundle — a unique identifier that encodes the lot, style, colour, size, and bundle number. Labels are printed and attached to each bundle before it leaves the cutting room.

When a bundle reaches a sewing operator, they scan the QR code on their phone. The system knows which operator they are (they're logged in), records the time, and assigns the correct piece-rate for that operation automatically. When they finish and scan out, that's a completed piece count — recorded, timestamped, attributed. No forms. No manual entry. Three seconds of work.

On my dashboard, I see every bundle in the factory in real time. I can see which bundles are at which stations, how long they've been there, and which operations are creating backlogs. If a bundle hasn't moved in 4 hours, it appears as a flag. I act on flags before they become delays.

At the end of the month, payment calculation is automatic. The system has a complete record of every piece every operator completed, timestamped and categorized by operation and machine type. Piece-rate is calculated, bonuses are applied, advances are deducted. The payment register is ready in under 30 minutes. Operators can see their own running totals through the same app they use to scan — so there are no surprises at payday.

Last month, we tracked 115,370 pieces through this system. Forty-two operators across five machine types — overlock, single needle, double needle, flatlock, and kansai. Three active lots running simultaneously. Not a single piece was unaccounted for at month end.

The Numbers Before and After

I want to give you real numbers, because I was skeptical of case studies that didn't. Here is an honest before/after comparison based on our actual operation:

The piece-count disputes are the number I'm most proud of. We went from 3-4 arguments every payday — arguments that damaged trust, demoralized operators, and took hours to resolve — to almost none. The reason is simple: when an operator scans a bundle, both they and the system record the same number at the same moment. There is no ambiguity. There is no "I think I did more." There is a timestamp and a count, and everyone can see it.

The invisible losses deserve attention too. Before the system, we estimated 400-800 pieces per month were simply untracked — bundles that moved between stations without anyone writing them down, pieces completed in the last 30 minutes of a shift that didn't make it into the tally, bundles set aside for re-work that disappeared from the count entirely. At our piece rates, 600 lost pieces per month is a meaningful number. Those losses are now near zero.

A Forrester study found that manufacturing ERP deployments generate an average 106% ROI over three years with a 17-month payback period. That assumes a successful implementation. ERP failure rates in discrete manufacturing run at 73%. The difference between success and failure is almost always the same: whether the software was actually designed for what you do, or whether you spent six months trying to make a generic system fit a CMT workflow. Our numbers above aren't projections. They're what happened when the fit was right.

What Other Small CMT Factories Can Take From This

For context on scale: in India, 99.6% of garment and textile MSMEs are micro-enterprises with fewer than 10 workers. Factories with 20–50 sewing operators are considered mid-tier. The typical Indian CMT unit produces 300–600 garments per day. Our factory sits in that band. We are not an outlier — we are the majority of the industry, and almost none of the available software was built for us.

I'm aware that most factory owners reading this don't have the background or the time to build software from scratch. I spent two years on it, and I had a specific advantage: I'm unusually stubborn about fixing systems that are broken, a trait I picked up in medical training.

But the things I learned from building our own small garment factory ERP apply to anyone evaluating garment factory management software for a CMT operation:

Start with the floor, not the office. The software that matters is the software your operators use 400 times a day. If the scan process takes more than 5 seconds, operators will find workarounds. If the interface is confusing, supervisors will go back to paper. Test on the floor before you commit to anything.

Piece-rate payment is the single most important feature. Everything else — WIP dashboards, bundle tracking, audit trails — ultimately feeds into one thing: did I pay this operator the right amount for the work they did? If your garment factory tracking without SAP doesn't solve payment disputes, it doesn't solve the core problem.

You don't need to track 100 things to transform your operation. Garment factory software for small factories doesn't need to be comprehensive. It needs to be accurate about the three things that matter: where is each bundle, how many pieces did each operator complete, and which stations are falling behind. Those three things, tracked reliably, will change how your factory runs.

The Raspberry Pi and the WhatsApp reports were not the plan — they were the solution to a real problem. I get asked about the hardware setup a lot. The honest answer is: I added a small networked device to the factory because operators had better phone connectivity when their data went through a local server rather than directly to the cloud. The WhatsApp reports came about because I wasn't always in the factory and I needed to see the day's production from wherever I was. Every piece of the system exists because it solved a specific problem, not because it looked impressive in a brochure.

One last data point worth knowing: SaaS garment ERP adoption is growing at 29% annually globally since 2020. But 68% of Bangladesh RMG manufacturers who claim to have "started digital transformation" have done nothing more than install accounting software or move from paper to Excel — the Industry 4.0 maturity score across Bangladesh textile factories is 1.91 out of 5. The gap between adoption rhetoric and floor-level reality is the market that Scan ERP was built for. If you're reading this, you probably already sense that gap in your own operation.

Skepticism from operators is normal and it passes. When I first introduced QR scanning, three operators refused to use it. They'd been in the garment industry for 15 years. They'd seen software come and go. They waited to see whether the others would be cheated by the system. When the first payday came and the counts were exactly right — actually higher than the manual tallies, because the system caught pieces that would have been missed — those three operators were scanning by the following week.

The ROI question is the wrong question. Factory owners keep asking "what's the ROI on garment factory ERP?" The better question is: what is the cost of not having it? In our case, that cost was 400-800 untracked pieces per month, 3-4 salary disputes per payday cycle, 3-4 hours of supervisory time every payday, and the chronic low-level mistrust between operators and management that comes from a system nobody completely believes. Those costs are real. They're just invisible, because they're baked into how the factory has always run.

Today we track 115,370+ pieces per month through Scan ERP. Forty-two operators. Five machine types. Three simultaneous lots. The system runs on the factory's existing WiFi, on operators' own phones, through a QR code that takes three seconds to scan. The supervisor dashboard is open on a tablet mounted on the floor. My 6 PM WhatsApp report takes 30 seconds to read.

This is what an affordable garment ERP actually looks like when it's built for CMT factories, not against them.

If you run a small CMT factory and think you can't afford this — you can. The question is whether you can afford not to.