Making sure problems are identified, analysed for cause and impact, tracked to closure, and mined for trends — with a controlled problem record at the centre.
ASPICE SUP.9 Problem Resolution Management ensures that problems are identified, recorded, classified, analysed for cause and impact, resolved with the right urgency, tracked to closure, and analysed for trends — with affected parties alerted and the status of every problem known.
SUP.9 is the defect/problem loop. The standard cares less about the bug tracker you use and more about whether every problem has a cause, an impact, a status, and a closure — traceably.
Purpose (per the ASPICE PAM): ensure that problems are identified, analyzed, managed and controlled to resolution.
The process is achieved when these outcomes hold:
Define classification, workflow, roles.
Uniquely identify and record each problem.
Root cause and impact on work products (config items).
Where a problem needs immediate action.
Notify affected parties.
Trigger the fix (often a change request, SUP.10).
Manage status through to closed.
Detect systemic issues.
The output work products SUP.9 asks for (named per the standard):
This is where the standard meets reality. Each work product and outcome has a concrete home — an issue type, work-item type, or model element — in the tools you already run. Types are configurable, so treat this as the typical ASPICE setup:
| Work product / outcome | Jira | Polarion | Codebeamer | DOORS Next | Enterprise Architect | Confluence |
|---|---|---|---|---|---|---|
| WP: problem management strategy | workflow + priority scheme (documented) | problem-mgmt plan LiveDoc | plan item | — | — | problem-mgmt page |
| WP: problem record | 'Bug' / 'Problem' issue type | Defect / Problem work item | Bug / Problem tracker item | — | — | problem log (only if no tracker) |
| Outcome: classification, cause & impact | severity/priority + root-cause fields + links | classification + cause fields | classification fields | — | — | RCA page |
| Outcome: impact on work products | 'affects/relates' links to config items | Linked Work Items (impacted) | impact links | link module | — | — |
| WP: trend / status report | JQL dashboard / control chart | LiveReport | report / chart | — | — | trend page |
The trap isn't the tools — it's that the links between them are maintained by hand and decay the moment a requirement changes. (See best ASPICE tools.)
Here is the part almost everyone misses. SUP.9 can never reach a mature capability level (CL2+) on its own — it can only be as mature as the configuration-management data model underneath it. SUP.8 Configuration Management is the secret enabling layer: the shared data model of items, versions, baselines and links that is the basis on which every other process group becomes provable. Scatter that data model across a Jira project, a Polarion space, a DOORS module, an EA model and a Confluence tree, and the model is fragmented by construction — the traceability that SUP.9 depends on decays the moment anything changes, and no amount of process ceremony fixes it.
What actually unlocks maturity is a headless ALM — an API-first, tool-agnostic configuration-management data model that is the single source of truth for every work product and every link, readable and writable by both humans and agents — plus an agent/human workflow definition, coordination and traceability platform on top of it, so every change is planned, assigned (to a human or an agent), executed and traced against that one model. That is the layer that lets SUP.9 be mature instead of theatrical.
ASPICE deliberately gives you no blueprint. So we wrote one. This SUP.9 guide is part of The Blueprint — our free, open template QMS for ASPICE: every VDA-scope process area, its outcomes and work products, mapped to concrete artifacts in your tools and grounded in one configuration-management data model. Take it, use it, no cost.
Agents triage and classify incoming problems, propose cause and impact by tracing to the affected configuration items, and surface trends — keeping the problem record complete instead of a one-line bug. And we offer to implement The Blueprint for you: our agentic solutions (Vera generates SUP.9's work products and traceability as a byproduct of the build, each with a confidence score and audit trail) running on a partner headless ALM — the API-first configuration-management data model that makes the whole thing provable.
SUP.9 Problem Resolution Management ensures problems are identified, classified, analysed for cause and impact, tracked to closure and mined for trends, with affected parties alerted and status always known.
A problem management plan/strategy, problem records (with unique id, classification, cause, impact and status), and problem trend/status reports.
A problem (SUP.9) is often resolved by raising a change request (SUP.10). SUP.9 manages the problem to closure; SUP.10 manages the change that fixes it, with impact assessment and approval.
As a Bug/Problem issue type with severity/priority and root-cause fields, 'affects' links to the impacted configuration items, a workflow to closure, and a dashboard for trend analysis.
Grounded in the standard, honest about the theater: All VDA-scope process areas · SUP.10 Change Requests · SUP.1 Quality Assurance · SUP.8 CM