Toward a single source of truth
Enterprise PLM implementation across 45 stakeholders, from fragmented spreadsheets to 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.

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.

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.

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.

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.

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.