From fixing the error to fixing the cause

In the production flow for banking notes (high-volume, highly repetitive financial documents), I started noticing that certain formatting errors weren't isolated incidents. They kept showing up, in different documents, different languages, sometimes different team members. They got fixed case by case in QA, but reappeared the following month in a different document.

Fixing the symptom every time it appeared was eating review time that should have gone into real quality control, not repeating the same correction.

As part of the DTP team, working alongside my Team Lead and the project's PM, I set out to stop treating these errors as one-off incidents and instead identify their root cause, drawing on a specific Root Cause Analysis certification to apply a structured method instead of intuition.

From one-off fix to pattern. The first step was simply keeping a log: every time a formatting error repeated, I noted what type of document it appeared in, at what stage of the workflow, and what triggered it. After a few weeks, the log stopped looking like a list of loose incidents and started looking like a pattern.

Applying a method, not just intuition. With the Root Cause Analysis certification as a framework, I used a 5-whys approach adapted to the DTP workflow. Instead of stopping at "the style wasn't applied correctly," I kept asking until I reached the structural cause, for example whether the real problem was in how the translated content arrived, in an outdated template, or in a workflow step with no clear owner.

Distinguishing root cause from apparent cause. Often the obvious cause (a one-off oversight) wasn't the real one. The method helped separate what looked like the cause from what was actually generating it, which was a step in the process, not a person.

Proposing the change, not just flagging the problem. Identifying the root cause isn't enough if it doesn't translate into a concrete change. I brought the finding to my Team Lead and the PM with a specific proposal to adjust the workflow, instead of just reporting that this kept happening.

• Log before drawing conclusions. I resisted the temptation to diagnose the cause from the first case; the pattern only became visible after several cases were logged over time.
• Look for the structural cause, not the responsible person. The analysis always focused on the process, where the workflow was failing, never on who made the one-off mistake.
• Close the loop with an actionable proposal. A root cause analysis that ends in a diagnosis with no recommended change doesn't change anything in practice.

A concrete adjustment to the production workflow, identified from the logged pattern and validated with the root cause analysis method, presented to the team as a process improvement proposal rather than a fix for an individual case.

The recurring error stopped reappearing at the same frequency, because its origin was addressed instead of its most recent symptom.

An error that keeps repeating isn't an error anymore, it's information about the process.

That way of looking at problems, asking why this keeps happening instead of just fixing it again, is something I now apply as a first step for any recurring problem, not just in DTP.