Case Study #2

Toward a single source of truth

Enterprise PLM implementation across 45 stakeholders, from fragmented spreadsheets to a single source of truth.

Toward a single source of truth

No data, no decision

At Drykorn, product development ran on spreadsheets, a legacy ERP, and trust. Trust that the numbers were current. Trust that the handoff was clean. It rarely was. The same problem looked different depending on where you sat.

Quote mosaic

The cost of fragmentation

Product Developers copied spreadsheet columns into a legacy ERP by hand. Sales data came from SQL queries that were sometimes days old. A mistake in a PM-to-PD handoff wouldn't surface until weeks later, in production, or worse, at market. The source of truth didn't exist. Everyone was working from their own version of the same product.

Diagram showing service blueprint of the PLM implementation, with touchpoints across departments and external consultants

45 stakeholders, one system

The PLM implementation touched every function: C-level, design, purchasing, production, sales. As one of three Key Users in a team of 12, the work spanned requirement gathering, workflow design, training, and change management across all of them. The challenge wasn't the software. It was getting 45 people who had never shared a single source of truth to trust one.

Roadmap diagram showing phases of the PLM implementation, from requirement gathering through to training and change management

Making 45 people trust something new

Rollout happened in phases. The core functions: design, purchasing, production, sales went first. Business intelligence and supply chain followed as the system proved itself. The training model was deliberate. Super Users were trained first so they could train their own teams. That meant the knowledge transferred with context, not just instructions. Weekly alignment meetings kept everyone moving at the same pace. At the strategic level, product demos with C-level and key stakeholders kept the vision visible and decisions moving. At the operational level, workshops gathered the domain-specific requirements that made the system actually usable. Separate sessions for menswear and womenswear captured the attributes each category needed for PIM integration.

Project metrics showing 100% of products in the system within six months of rollout, and 0% errors in handoffs between PM and PD after one year

The decision that made everything else work

Product color codes had shifted every season, the same code referencing a different color the following year. Clean data was impossible without fixing the foundation first. After several sessions and an open discussion with C-level and all stakeholders, one rule was established: four digit codes only, one fixed reference per color, permanently. A full department pushed back. The data made the argument.

Before and after showing the same code pointing to different references across seasons versus the fixed one-to-one relationship

Where design thinking came from

Three years of requirement gathering, workflow design, and change management across an entire organisation kept pointing to the same instinct: the process itself could be better. Not just the software, not just the data, but the way work flowed between people, the points where things broke down, the moments where a clearer structure would have saved hours of friction. That instinct is design thinking. Recognising it led directly to a transition into design, not as a change of direction, but as finding the discipline for something already there: designing the systems that connect people, process, and outcome.