Distribution Management System

That was the starting point when I joined Apparel One and was assigned, about a month in, to rebuild the Cutting Distribution Management System (CDMS), one piece of a company-wide initiative to standardize and digitize production end to end, run jointly by the Operational Engineering and ICT teams.

A rough blueprint already existed, years old and never fully implemented, so we started over to get the precision the business actually needed. CDMS sat at the center of the data flow: fabric tracked from the moment it entered the warehouse, through cutting and pattern-making, down to individual pattern pieces, with direct integration into the auto-cutting machines themselves to capture output data in real time. That data then fed into distribution, sewing, packing, and QC, while other departments, finance, order management, export-import, pulled from CDMS in turn.

None of it could be standardized blindly, either. Each of the four branches had built its own habits over the years, so the same process on paper often meant something different on the factory floor.

That gap, between what the SOP said and what people described, was where the real standardization problem lived: each branch had grown its process around its own buyers, its own machines, its own habits, not because anyone wrote it that way, but because nobody had needed it to match before.

I worked alongside a PM from the Operational Engineering team throughout this. He owned the business side, the buyer requirements, the process logic, and I translated that into system terms: what each option meant technically, what it would cost to build, and what trade-offs it created downstream. When a branch's process couldn't be standardized without breaking something else, we escalated it back to the relevant department to work through directly, with our team facilitating rather than dictating.

For rollout, we piloted at the central factory first, the branch with the most system-ready team and the clearest picture of what the target process should look like. Once that branch could run on CDMS end to end, we moved to the next, one department at a time, with the old and new systems running in parallel so production never had to stop for the transition.

Adoption was its own problem to solve. I picked one PIC per branch, someone comfortable with systems rather than intimidated by them, and worked alongside them for at least a month until they could run the new process on their own. From there, that PIC became the one training their own team, operators first, then admins, staff, and supervisors, because peer-to-peer training landed better on the floor than anything coming from an outside system analyst.

Standardization here was never all-or-nothing, either. Some differences turned out to be real, tied to buyers or machines, not just inconsistent habits, so the system was built to hold a shared core process with room for a few deliberate exceptions rather than forcing everything flat.

Instead of a single company-wide switch date, the cutoff was tied to PO and PCD (Production Completion Date): every PO with a PCD on or after a set date had to be entered into CDMS, everything before it stayed on the old process. That kept the transition traceable PO by PO instead of guessing where the line between old and new data actually was.

When an issue surfaced at one factory, however minor, it got raised back to all four branches together, not patched quietly and forgotten. If a bug kept resurfacing, the rule was to trace it to the root cause instead of patching the symptom again.

BRDs went to supervisors and above, framed to keep scope legible and contained rather than drifting wider with every meeting. FSDs stayed internal, the technical team's build reference. SOPs were less about referencing procedure and more about speaking the same language as the people on the floor, since that was rarely the language a requirements document used. UAT checklists structured testing, and manual books were written for the end users who'd actually run the system day to day, not for anyone reading it as a technical spec.

The harder gap was conversational, not written. People on the floor described their process the way they lived it: field language, exceptions, workarounds, a flow that rarely matched how a system would need to structure it. Early on, that was difficult for me to follow. What worked was showing up to discussions with a Figma prototype instead of a requirements doc, something they could click through and react to, rather than a specification they'd have to imagine. Seeing it made the gap between "how we work" and "how the system will work" concrete enough to actually discuss.

Reporting upward ran the same way it was built: split by domain. The OE PM presented the business standardization side, I covered how the system would handle it, and management heard both halves from the people who actually owned them, not filtered through a single voice trying to represent both.

All of this ran on a monthly cross-factory sync, with anything urgent pulled into an ad hoc meeting rather than waiting for the next cycle.

The clearest change was in visibility. Production that used to be tracked manually, department by department, became something that could actually be monitored end to end: where a bottleneck was forming, which factory it was in, and what to do about it, all visible instead of pieced together after the fact. Manual tracking didn't disappear entirely, but it stopped being the primary way anyone understood what was happening on the floor.

CDMS is still running today, across all four branches, with new phases continuing to build on it after I moved on.