ERP
WARDROBE PLM
Enterprise PLM/ERP platform for apparel manufacturing, unifying 19 modules — merchandising, planning, Cut2Pack, HRIS, payroll, accounts, inventory, supply chain, QA, knitting, wet process, and more — into one integrated system with role-based access.
- Scale
- Wardrobe PLM is an enterprise ERP with built-in product lifecycle management for a vertically integrated Bangladesh apparel group.
- Client
- Texeurop (BD) Ltd.
- Delivered
- February 2018
- Category
- ERP
Problem
What was unclear or broken
Six business units ran on email, Excel and disconnected tools. Tech packs, BOMs and costing lived nowhere merchandising, the sample room and accounts shared, so bulk production started on stale data and margin loss only surfaced at month end — too late to correct a losing order.
Constraint
What I was working against
Two legal entities plus shared services serving both, and every existing tool assumed one flat role list — so admins either over-shared data or minted a new role per factory. The real org chart was ragged (some units nest five levels deep, Garments goes straight to sections), and had to be modeled correctly before any schema was fixed, with management's sign-off on legal-entity and profit-center boundaries needed first.
Decision
The call I made
I chose one generic org_units tree with a closure table over hard-coded per-level tables (companies/wings/divisions/departments). It cost extra weeks up front and was harder for new developers to read — the trade-off I had to defend to the team — but it meant the ragged real structure (Press and AOP as separate profit centers, shared services spanning two entities) needed no later migration.
System Sketch
Outcome
What shipped
Shipped: a shared authorization and scope-cache core, approval engine and numbering service used by every domain module (PLM, merchandising, textile, garments, stores, HR, payroll, accounts) across both legal entities, released behind a named scope-test suite as the gate. Every module now reads one style record instead of five separate copies, and access is enforced by scope rather than by one-off roles. Before/after timing and accuracy metrics are being tracked module by module as remaining factories go live.
Retrospective
What I'd change
I'd freeze the shared columns — entity, business unit, org unit, location, data class, owner — on every table before any module was built; adding them after modules existed was the costliest rework on the project. I'd also pick the production database before designing the schema: starting in PostgreSQL syntax and porting to MySQL cost a translation pass that was avoidable.
Wardrobe PLM — Apparel Manufacturing ERP
Overview
Led the design and development of Wardrobe PLM, a comprehensive Product Lifecycle Management and ERP platform built for the apparel manufacturing industry. The system unifies the entire operation — from order inception to shipment — into a single integrated environment, replacing the spreadsheets, email threads and standalone tools that typically fragment merchandising, production, finance and HR in a vertically integrated garment group.
The platform is organized as 19 interconnected modules sharing one data layer, so a style, a purchase order, a production lot or an employee record is entered once and read the same way everywhere it's needed — in costing, in the production floor, in payroll, in the executive dashboard. That shared layer is what lets new modules be added, and existing ones changed, without the data drifting out of sync the way it does when each department keeps its own copy.
Modules
19 modules, each independent but built on the shared data layer, spanning the full order-to-shipment cycle:
| Group | Modules |
| Merchandising & planning | Merchandise, Planner, Design & Development |
| Production | Cut2Pack, Knitting, Wet Process, Print & Embroidery |
| Commercial & supply | Commercial, Supply Chain Management, Inventory |
| Quality | Quality Assurance, IPE |
| Finance & people | Accounts, HRIS, Payroll |
| Operations & platform | Vehicle Management, Information Technology, System Management |
Each module operates independently — its own screens, its own team — while sharing a common data layer, so production, inventory, costing and HR data stay consistent across the business instead of each module keeping its own copy.
Engineering focus areas
- Normalised database schema for high transaction volume. Modeled for the write load of 19 concurrent modules — production bookings, stock movements, attendance, payroll runs — without duplicating the same fact in multiple tables, so a correction in one place is correct everywhere.
- Query and indexing optimisation for reporting on large datasets. Production, costing and HR reports run across months of transactional history; indexes and query design were built around the report shapes managers actually use, not just the transactional writes.
- Granular role-based access control mapped to organisational hierarchy. Permissions follow the real org chart — company, business unit, factory, department — so access narrows automatically by where someone sits, instead of every role needing to be hand-built per site.
Modular architecture for safe extension. New modules attach to the shared data layer through defined contracts, so a module can be added — or changed — without touching the modules already in production.
