Case study · ERP · Quality assurance
Building an ISO-certified quality process into an ERP that couldn’t hold it
The client’s quality lab was certified under ISO and ICONTEC, and every test it ran had a compliance threshold it either met or didn’t. The ERP’s standard quality module covered most of that process. Not the part that had to be exact.
- ISOAnd ICONTEC certification behind every threshold
- AS-ISProcess mapped before a line of code was written
- ADVPLPatches developed and compiled into the ERP
- 4Years at TOTVS
Context
I spent four years at TOTVS, Latin America’s largest ERP provider — the last three as ERP Consultant, leading end-to-end implementations across manufacturing, supply chain, procurement and cost management for clients in Colombia and Ecuador.
One of those clients manufactures tubing for a wide range of fluids and runs its own quality assurance laboratory. That lab is certified under ISO and under ICONTEC, the Colombian quality assurance standard, and every test it runs has to comply with those norms exactly. There is no partial credit in quality certification. Either a result complies, or it doesn’t.
My job was to bring their testing procedures into Protheus, the ERP, using its native quality assurance module.
The constraint
When I mapped what the client needed against what the module did out of the box, the gap was real. Their testing corpus — the full set of tests they ran on manufactured products, each with its own compliance threshold — did not fit cleanly into the standard configuration. Parameterization ran out before the process was covered, and the part it left uncovered was the part a certification audit actually looks at.
What I did
- Documented the AS-IS process in detail — working directly from what the lab technicians described and from their own process handbooks. The standard implementation playbook doesn’t ask for this, but at this level of precision I couldn’t afford to guess at a single threshold.
- Matched the AS-IS against the module’s defined process to see exactly where the system’s coverage ended — separating what I could configure around from what I would have to build.
- Designed the TO-BE state and had it approved before writing anything, so the target was the client’s certified process rather than my reading of it.
- Built the missing piece in ADVPL — Protheus’s own programming language — developing and compiling patches directly into the system so it could reproduce the results the certified lab was already producing.
- Tested each patch against the real compliance thresholds until the system’s output matched what the certification demanded.
When the outcome is binary — comply or don’t — you don’t stop at what the tool gives you by default. You map the real process first, find exactly where the gap is, and then you build the missing piece yourself, even if that means picking up a language or a layer of the system you hadn’t touched before.
Results
- A quality module that ran the client’s actual certified process inside their ERP, not an approximation of it.
- Held to the same standard the lab was already accountable to — ISO and ICONTEC compliance, audited, with no room for a partial match.
What I’d do differently
- I’d have built the AS-IS map with the lab, not just from it. I interviewed the technicians and read their handbooks, then wrote the map myself. Writing it alongside them would have caught the same edge cases sooner and left them with a document they owned.
- I’d have asked what happens when the norm changes. I built to the thresholds in force at the time. Standards get revised, and I didn’t leave behind a documented path for updating the patches without me.
- I’d push back earlier on “the module can do it.” I spent time trying to configure my way to a fit before accepting that the gap needed code. Mapping the process first would have told me that in week one instead of week three.
Stack
ADVPL · TOTVS Protheus (quality assurance module) · Process mapping (AS-IS / TO-BE) · ISO · ICONTEC · Requirements documentation