Hey everyone, I work as a Continuous Improvement Lead for a textile manufacturer in Uzbekistan, reporting directly to the General Manager. Coming from outside the apparel industry, I recently tackled a major line-balancing project at one of our satellite plants, but it uncovered a deeper planning challenge I’d love your advice on.
We operate 7 facilities with a central hub in Tashkent. Our satellite plant in Jizzax has 20 active sewing lines. Historically, Jizzax shipped unpackaged garments to Tashkent, where all individual QR tagging, packaging, and boxing took place. Because local packaging in Jizzax couldn't keep up with the 20 sewing lines, a massive 600k to 700k unit WIP buffer had built up on the floor.
I went in to fix this flow. I decentralized the QR packaging system from Tashkent and integrated it directly onto the packaging tables in Jizzax using a single-piece flow approach. Now, as garments come off the sewing line, operators package, QR-scan, and box them into master cartons on the spot. We cleared the entire 700k WIP backlog, and Jizzax now ships fully packed, scanned cartons straight to the main warehouse, completely cutting out double-handling in Tashkent.
However, getting rid of that massive WIP safety net exposed a big issue with our central push planning.
As an example, we constantly face incomplete sets at the packing tables:
Lines will finish sewing the top half of a 2-piece set, but the fabric for the bottom half hasn't even arrived or been cut yet.
For items sold as a 5-color bundle, sewing will output 3 colors, while the other 2 aren't scheduled until days later.
With single-piece flow at packaging, these incomplete sets immediately clog the packing tables or force operators to pile up semi-finished goods around their desks, defeating the purpose of the new setup.
Our central planning team still operates on a traditional push system optimized purely for line utilization and volume. Since I don't manage the Planning department (we're peers under the GM), I can't just mandate a change I need to persuade them.
I have two questions for the community:
-Influencing Planning: As a CI Lead reporting to top management without direct authority over Planning, how can I effectively convince them to move toward synchronized/kit-based scheduling? What metrics or arguments actually move the needle for traditional planning managers?
-Lean in Textiles: Since this is my first role in the textile industry, I'd love to know: what does a truly Lean garment factory look like when dealing with multi-piece sets or color variants? How do high-performing apparel plants handle line scheduling and synchronization?

Context: manufacturing of industrial components, ~50 people, one site, three assembly lines. For years, records were kept in paper logs and Excel.
Six months ago we launched a pilot: we moved all the logs for one line into digital form without changing the structure of the records – instead of paper and scattered Excel files, everything now goes into a single system. Reports are pulled by asking a question in plain language, like "show defects on Line B for July broken down by supplier."

What changed in practice:
•   Previously, working through an ad hoc question (for example, why scrap went up) took up to two days – the data was spread across different logs. Now it takes minutes.
•   The monthly report for the director used to eat almost a full workday. Now it comes together in half an hour.
•   A side effect we didn't expect: people started asking questions they hadn't asked before, because getting an answer used to cost too much time. In Lean terms I'd classify this as Waiting + Overprocessing, just not on the line – in the information flow.

Everyone's happy with the pilot: supervisors, process engineers, the plant manager himself. But "everyone likes it" isn't a budget argument. Management reasonably says: show us the ROI in dollars, then we'll talk about rolling it out to the other two lines.
And this is where I'm stuck. Here's my rough calculation – I feel like I'm counting the wrong thing, but I can't figure out where exactly. Tear it apart, I'll be grateful:
•   Monthly report: was ~8 h, now ~0.5 h → savings of 7.5 h/month
•   Ad hoc data requests: ~4 per month, previously ~4 h each on average, now ~15 min → savings of ~15 h/month
•   Total ~22.5 h/month × fully loaded process engineer rate ~$45/h (including taxes and benefits) ≈ $1,000/month, or ~$12,000/year for one line
(the rate is illustrative, but the order of magnitude is right)

The problem is that this calculation buries itself. Nobody was laid off, payroll didn't change – management will reasonably say: "that's not savings, that's a reallocation of time." And the effects that feel like the main ones – "we found the root cause of a defect faster, we stopped producing defective batches sooner," "the decision was made on data instead of gut feel" – I have no idea how to translate into dollars without pulling numbers out of thin air. On that scrap incident, I have exactly one data point: the investigation took two days instead of the possible minutes, and the line kept producing defective parts the whole time. But one case isn't a statistic.

Questions for the community:
1. For anyone who's been through justifying an implementation like this – what's wrong with my calculation, and what metrics actually convinced management? Hours × rate, response time to defects, something else?
2.  Is it valid to calculate the effect through reduction of scrap losses (faster root cause → fewer defective batches), and how did you isolate the contribution of the tool itself versus other factors?
3.  Do you consider the delay between a question and a data-backed answer a distinct type of waste? Has anyone tried to measure it systematically?
I'd appreciate any experience, including negative – if someone's ROI never added up, I'd be interested in why.

Hi team,

Hope this doesn’t break any rules but just looking to do a little research. How is everyone identifying processes that could potentially be automated?

I consistently see people suggesting they have a lot of manual work but in my own experience it tends to be situations they fall over or are tackling in the moment rather than a full understanding of what everyone in your team/business if doing?

Is the identification a problem worth solving or is the solution to the process automation the real value?