“We need traceability.” I hear this sentence regularly in projects. But what is meant by it often differs considerably. Is it about proof for a certification body? About tracing requirements all the way to the test? About change traceability across the entire product lifecycle? Or simply about knowing which version of a document belongs to which product state?
All of that is traceability, but it is not the same thing.
Traceability is not all the same
Not every product and not every company needs every kind of traceability. A ventilator for hospital use has to meet very strict traceability requirements: human lives depend on it, and regulators check it closely. A cordless drill from the hardware store is subject to different requirements.
That sounds obvious. In practice, though, it rarely turns into a structured requirements analysis. Instead, teams often aim for either too much traceability, with the corresponding effort and modest benefit, or too little, which becomes a problem at the latest when a change or certification comes up.
The Traceability Navigator
So I developed a “Traceability Navigator”: an overview along the product lifecycle that shows the various intersections where traceability can be relevant.
The navigator works as a structuring aid: you go through the different points and decide for each one what the right and necessary traceability is for your own product. The result is not a generic “we do everything,” but a tailored traceability concept.
From concept to implementation
Once it is clear which traceability is needed, the next question follows: how do we map it in the PLM toolchain?
The trick, of course, is finding suitable solution approaches. In most companies, PLM architectures have grown over the years. The information that is meant to be traceable is spread across many tools: PLM, ALM, ERP, document management. And it is often not available in the data quality that unambiguous traceability requires.
For every point in the navigator, a suitable solution approach can be described: which tool contributes what, where we need interfaces, where data quality has to be improved. The navigator serves as a shared basis for discussion between the business side and IT.
Traceability requirements are product-specific. A generic “we need traceability” leads either to over-engineering or to blind spots. The navigator helps identify the right requirements and then translate them in a structured way into the existing tool landscape.
If you would like to learn more about the Traceability Navigator or have specific questions about implementation, feel free to get in touch.