A non-conformance is an issue with a defined lifecycle, an owner, a due date and a required verification step, which is exactly what Redmine's tracker model is. RedminePRO runs it managed, with flat pricing that lets you give the whole plant access rather than rationing seats.
Most quality processes end up in a spreadsheet not because a spreadsheet is good at them but because the software available was built for software teams. Redmine is unusual here: because trackers, fields, statuses and workflows are all definable, a corrective-action process can be modeled directly rather than approximated.
A tracker per object type. Non-conformance and Corrective Action as separate trackers, each with its own field set and its own workflow. Keeping them separate rather than a single “issue” with a type field is what lets them have genuinely different required fields and different approval gates.
Custom fields carry the quality data. Defect code, batch or lot number, part number, quantity affected, disposition, customer impact, root-cause category. Fields can be required at a specific status — so a non-conformance cannot reach Root Cause Identified without a root-cause category on it.
The workflow is the gate. Detected, Contained, Under Investigation, Corrective Action Assigned, Verification Pending, Closed. Which role can make each transition is an explicit grid, so a line supervisor can raise and contain while only the quality role can close after verification. That is the control, and it is configuration rather than discipline.
Relations connect the corrective action to the finding. A Corrective Action follows the Non-conformance that triggered it, and a verification task follows the corrective action, with dates shifting automatically when a predecessor slips. Categories map to the physical plant — lines, cells, stations or product families, each with a default assignee, so a non-conformance lands with the right owner without anyone routing it.
Manufacturing organizations rarely have one location, and the usual failure is either one shared project that becomes unnavigable or separate systems per site that cannot be compared. Redmine's project hierarchy handles this directly: a parent project per program with a subproject per site keeps each plant's work separate for day-to-day use while rolling up for anyone who needs the whole picture. Roles are assigned per project, and versions can be shared across a project hierarchy, so a program milestone that applies to three plants exists once and every site tracks against the same target. Cross-site reporting is a saved query, grouped by site, made public. Unlimited projects on every plan means the structure can match the organization instead of being compressed to fit a project quota — a real constraint on several competing hosts.
Supplier quality issues involve people who do not work for you and should not see everything. Redmine handles this with a restricted role scoped to a single project: a supplier gets access to one project, with a role that can view and comment on the issues concerning them and nothing else. Private notes let your team discuss commercial context on the same issue without the supplier seeing it. For suppliers who will not log into anything, the Helpdesk feature on the Business plan turns inbound email into issues in the right project. Flat pricing matters more here than it looks: on per-seat pricing every supplier contact is a recurring cost, which is why organizations end up running supplier coordination over email attachments. On RedminePRO, $169/mo on Business covers 250 users — adding twelve supplier contacts changes nothing. Pricing.
A tooling program, a plant qualification or a product transfer runs for quarters or years, and the tracker has to hold dependencies that stretch across them. Issues carry start and due dates, and precedes/follows relations shift dependent dates automatically when something upstream moves — the single most useful behavior in long-horizon planning, because the alternative is a plan that is quietly wrong within a month. The Gantt and portfolio planning on the Business plan renders the whole program, and statistics and analytics on the same tier covers the reporting layer above it.
This is the constraint that decides most manufacturing rollouts: Redmine's default interface is dense, and a line supervisor handed the full issue list will not use it. The lever is that almost all of that density is configurable, and RedminePRO gives you full administrator access on every plan to configure it. Modules you do not need — repository, forums, news, documents — switch off per project, and the tabs disappear with them. Trackers show only the fields you define. Saved queries, made public, become the entry point: “Open non-conformances on my line”, “Corrective actions due this week”. Most people never touch the general issue list. Budget the configuration time: a Redmine rolled out with defaults gets abandoned; one rolled out with three saved queries and four fields per tracker gets used. If you would rather not do that yourself, guided onboarding is included on the Enterprise tier.
If you are moving off a spreadsheet system or another tracker, the free assessment tells you in writing what carries across and what needs a mapping decision; the migration itself is a one-time professional-services fee quoted after it. Once you are live, Redmine upgrades, OS and stack patching, encrypted backups with point-in-time recovery and disaster recovery are ours, which matters in an organization where nobody is going to be assigned to babysit a Ruby application. What managed covers.