AMS and continuity

How to Use AMS Incident Patterns to Improve the SAP Data Model Instead of Just Reducing Ticket Volume

By Dzmitryi Kharlanau · Published · 23 min read

The AMS dashboard shows progress.

Contents

Reviewed: 14 July 2026

The AMS dashboard shows progress.

Supplier-related incidents have fallen from 180 per month to 95.

Average resolution time has improved. More tickets are resolved on first contact. Knowledge articles cover the most common validation messages. Automated routing sends incidents to the correct support teams.

The service organisation is performing better.

But behind the lower ticket count, the same model weaknesses remain:

The visible ticket volume is lower.

The model has not necessarily improved.

This is the limitation of treating AMS incidents only as service-management demand.

An incident is also an observation of where the approved model, operational process, source data and implemented system fail to meet each other.

A single incident may be noise.

A recurring pattern is evidence.

The purpose of incident-pattern analysis should not be limited to reducing support demand. It should reveal where the SAP data model is incomplete, ambiguous, misapplied or no longer aligned with operational reality.

This does not mean turning every incident into a design issue.

Most incidents remain operational:

The value appears when AMS can distinguish these cases from incidents that expose a structural model problem.

---

The support queue is an operational sensor

An SAP programme sees the model primarily through:

AMS sees the model differently.

It sees what happens when thousands of users, records, integrations and local processes apply that design every day.

AMS incidents reveal:

This evidence is especially valuable because it appears after the controlled conditions of programme testing have ended.

The objective is not to treat the support queue as automatically authoritative.

Users can misunderstand the process. Local workarounds can be poor practice. Repeated incidents can come from training or access problems rather than model design.

The queue is a sensor, not the model owner.

It tells the organisation where to investigate.

---

Ticket reduction can hide model deterioration

A lower incident count can result from genuine improvement.

It can also result from several less desirable changes.

Users stop reporting the problem

They learn a workaround.

AMS resolves the issue before creating an incident

The operational effort remains but disappears from formal metrics.

The validation is weakened

Records no longer fail, but data quality declines.

A default suppresses the error

Completeness improves while meaning becomes less trustworthy.

The process moves into a spreadsheet

SAP generates fewer incidents because the real lifecycle now happens outside SAP.

Several incidents are grouped into one recurring request

Ticket volume falls while structural demand remains.

Therefore, a good AMS review should ask two separate questions:

  1. Are fewer users experiencing operational disruption?
  2. Has the underlying model become more coherent?

The first is a service metric.

The second is a governance outcome.

They may move in different directions.

---

Problem management is necessary but not sufficient

Problem management already provides a useful discipline for moving beyond individual incidents.

Atlassian describes problem management as identifying and managing the underlying causes of incidents, linking incidents to problems, supporting root-cause analysis and tracking longer-term corrective actions. It also stresses that service restoration may close an incident while the underlying problem remains.

ServiceNow similarly presents problem management as a way to analyse service patterns, connect incidents, identify root causes, manage workarounds and prevent recurrence through remediation plans.

That is the correct operational foundation.

For master-data and model-related incidents, one additional question is needed:

Does the recurring problem indicate that the effective data model should be clarified, corrected or extended?

A root cause such as:

Validation rule does not include the new supplier category

can represent several different model situations:

Problem management identifies and coordinates the investigation.

Model governance determines what should become true.

---

Start with patterns, not ticket counts

A monthly report may show:

Supplier incidents: 95
Customer incidents: 64
Product incidents: 48

This is useful for workload planning.

It is weak evidence for model improvement.

A stronger analysis groups incidents by their relationship to model objects and decisions.

For example:

Supplier Risk applicability:
27 incidents

Tax exemption evidence:
19 incidents

Customer Group granularity:
16 incidents

Unmapped local Legal Form:
14 incidents

Expired migration default:
11 incidents

Supplier Review Status absent:
8 incidents

The second view reveals recurring model themes.

The incidents may have different:

They still point to the same model question.

---

Error-message clustering is not enough

A single model problem may produce several technical symptoms.

Suppose Customer Group is modelled incorrectly as a central attribute even though the operational meaning is sales-area-specific.

The resulting incidents may include:

Grouping by error message creates six problem groups.

Grouping by canonical model object reveals one shared issue:

ATTR-CUSTOMER-GROUP
Granularity: unresolved between central and sales-area context

The reverse also occurs.

One message such as:

Supplier Risk is required

may point to:

Pattern analysis must therefore use more than text similarity.

It should consider:

---

Normalise incident evidence

Incident descriptions are usually written for support.

They are not structured model evidence.

Before analysing patterns, normalise each relevant incident into a small set of fields.

Incident:
INC-4821

Affected object:
ATTR-SUPPLIER-RISK

Rule:
RULE-SUPPLIER-RISK-ACTIVATION

Context:
Country = PT
Supplier category = regulated
Lifecycle = activation

Observed condition:
Risk missing
Review status pending

Operational resolution:
Manual review completed

Model interpretation:
Possible missing review lifecycle

The normalisation does not replace the original ticket.

It creates a comparable evidence layer.

Important fields include:

Without this structure, incident analysis remains dependent on keywords and analyst memory.

---

Separate recurring symptoms from recurring causes

A recurring symptom is:

Supplier activation blocked.

Possible recurring causes include:

A recurring cause may also create different symptoms.

For example, missing strategic-status evidence may lead to:

The analysis should preserve both levels.

Pattern:
Supplier activation failures

Sub-patterns:
- risk missing;
- applicability unknown;
- exemption invalid;
- configuration mismatch.

Shared contributing factor:
strategic-status context is unreliable.

This prevents the organisation from solving only the most visible error message.

---

Use five pattern classes

Most model-relevant AMS incident patterns fall into five broad classes.

1. Definition pattern

Users and systems interpret the same term differently.

Examples:

Typical evidence:

Potential model response:

---

2. Applicability pattern

The rule is valid, but teams disagree about where or when it applies.

Examples:

Typical evidence:

Potential model response:

---

3. Source-evidence pattern

The model requires information that operational sources cannot supply reliably.

Examples:

Typical evidence:

Potential model response:

---

4. Lifecycle pattern

Operational work requires intermediate states missing from the model.

Examples:

Typical evidence:

Potential model response:

---

5. Ownership pattern

Incidents circulate because nobody has clear authority.

Examples:

Typical evidence:

Potential model response:

These classes are broad enough to remain stable across projects while still leading to distinct model actions.

---

Do not promote a pattern based on frequency alone

A pattern affecting three critical suppliers may matter more than one affecting thousands of inactive records.

Use several signals.

Frequency

How often does it occur?

Population

How many records are affected?

Recurrence

Does it return after correction?

Spread

Does it affect several countries, systems or processes?

Materiality

Does it affect compliance, payments, operations or cutover-critical objects?

Semantic divergence

Does the workaround change the meaning of stored data?

Operational effort

How much manual work is required?

Detectability

Does the issue produce visible failure, or can bad data pass silently?

Reversibility

Can the condition be corrected easily after propagation?

A low-frequency unexpected pass may deserve immediate model review.

A high-frequency formatting error may remain an implementation problem.

---

Analyse resolutions, not only incidents

The resolution history often contains stronger model evidence than the incident description.

Suppose 40 incidents were resolved through:

The pattern is not merely “missing field.”

It shows that the current model cannot be satisfied operationally without altering behaviour.

Resolution analysis can reveal:

A support organisation that reviews only open-ticket categories misses this evidence.

---

Workarounds are model hypotheses

Every workaround makes an implicit claim.

Example:

Workaround:
Enter STANDARD when final risk is unavailable.

Implicit hypothesis:

A supplier without assessment can be treated operationally as standard risk.

Another:

Workaround:
Maintain exemption in a spreadsheet.

Implicit hypothesis:

Exemption is a separate governed state requiring evidence and validity.

Another:

Workaround:
Allow blank field until activation.

Implicit hypothesis:

The field is required at activation, not creation.

These hypotheses may be valid or invalid.

Incident-pattern analysis should surface them explicitly.

Do not wait until the workaround has become permanent.

---

Build an incident-to-model review cadence

A useful cadence does not require a large governance board.

Weekly operational review

Focus on:

Participants:

Monthly pattern review

Focus on:

Output:

Quarterly model-health review

Focus on:

The quarterly review should not read individual incidents.

It should assess whether the model is learning from operations.

---

A pattern record should remain stable

Incidents open and close.

The pattern should persist across them.

id: PATTERN-SUPPLIER-RISK-REVIEW-001

status: model_decision_required

affected_objects:
  - ATTR-SUPPLIER-RISK
  - RULE-SUPPLIER-RISK-ACTIVATION

evidence:
  incidents:
    - INC-4821
    - INC-4930
    - INC-5014
  service_requests:
    - REQ-2088
  datasets:
    - ERP_B_SUPPLIER_PROFILE_2026_07

pattern:
  symptom: supplier activation blocked
  recurring_resolution: manual risk review
  hidden_state: assessment_pending

scope:
  source_systems:
    - ERP_B
  supplier_categories:
    - STRATEGIC
  lifecycle:
    - ACTIVATION

assessment:
  classification: lifecycle_model_gap
  confidence: high

decision_required: >
  Determine whether Supplier Review Status should become
  a governed concept separate from final Supplier Risk.

This is a conceptual product direction, not a claim about the current Martenweave schema.

The stable pattern ID allows the organisation to measure whether the eventual model change works.

---

Compare before and after the model change

A model change should have a measurable operational hypothesis.

Example:

Introducing Supplier Review Status will reduce activation incidents caused by pending assessment without weakening the final Supplier Risk control.

Baseline:

Monthly incidents:
27

Manual defaults:
18

Average resolution:
2.8 days

Records with ambiguous STANDARD:
1,800

After implementation:

Monthly incidents:
6

Manual defaults:
0

Average review initiation:
3 hours

Ambiguous STANDARD:
0 new records

This demonstrates more than ticket reduction.

It shows that:

---

Measure displacement

After a model change, incident counts may fall because demand moved elsewhere.

For example:

Therefore, compare:

A successful model improvement reduces the underlying operational friction, not only one queue.

---

Track recurrence by model object

Traditional AMS reporting often groups by:

Add a model-object view.

For each critical object, show:

Example:

Model objectIncidentsActive patternsWorkaroundsOpen decisions
Supplier Risk42211
Customer Group31121
Tax Identifier28312
Payment Terms14100

This turns AMS demand into a model-maintenance portfolio.

---

Distinguish a weak process from a weak model

Repeated incidents do not automatically justify model change.

Consider mandatory Tax Identifier.

Users repeatedly fail to provide it.

Possible explanations include:

Weak process

The field is valid and required, but users lack training or evidence at the correct point.

Response:

Weak source

The field exists but does not arrive reliably.

Response:

Weak implementation

Validation fires too early or for the wrong population.

Response:

Weak model

The rule does not represent legitimate exemptions or lifecycle.

Response:

The investigation should preserve these alternatives.

Changing the model to reduce incidents is dangerous when the incidents are caused by weak execution.

---

Do not optimise the model for zero incidents

A good control may intentionally create incidents or review work.

For example:

The objective is not zero exceptions or zero support demand.

The objective is that expected controls produce:

A model can be correct while still generating legitimate review cases.

The pattern review should distinguish:

Expected control demand
Unexpected operational friction
Structural model weakness

Removing a valid control to improve ticket metrics damages governance.

---

Unexpected passes are the highest-value signals

Support queues primarily capture visible failure.

The more dangerous model problems may not create incidents:

Find these through:

Incident-pattern analysis should therefore combine reported tickets with silent evidence.

Otherwise, the organisation optimises only what users can see.

---

Link operational patterns to dataset evidence

A pattern is stronger when it can be measured against actual data.

Suppose incidents suggest that Customer Group is often wrong for multi-sales-area customers.

Dataset analysis can test:

The result may show:

Incidents:
16

Affected observed records:
9,480

Multi-sales-area customers:
3,120

Repeated central value:
2,870

Approved organisational mapping:
Not defined

The incident count understated the scale.

AMS evidence identified the question.

Dataset analysis revealed the population.

---

Use trace and impact before proposing change

A recurring incident pattern may point to one attribute, but the change can affect:

Before proposing a model change, trace the object.

For Customer Group:

Business attribute
→ source CRM Segment
→ country mapping
→ SAP sales-area endpoint
→ pricing process
→ reporting
→ downstream interface
→ local override spreadsheet

This prevents the organisation from fixing the visible incident while creating another inconsistency.

---

Model changes should explain which incidents they resolve

A PatchProposal should reference its operational evidence.

Example:

Proposal:
Separate Supplier Review Status from Supplier Risk.

Supported by:
- 27 recurring activation incidents;
- 18 manual defaults;
- one expired workaround;
- 1,800 ambiguous records;
- two downstream interface conversions.

The proposal should also state what it will not fix.

For example:

This proposal will not correct missing source risk evidence. Source remediation remains a separate action.

This prevents one model change from becoming a vague promise to solve every operational problem.

---

The role of SAP MDG

SAP describes SAP Master Data Governance as a central layer for governed master data, with one governed model across business entities, preserved semantics and relationships, ownership of attributes, collaborative workflow routing, validated values, business-rule monitoring and auditable changes.

Those capabilities are appropriate for implementing approved operational improvements such as:

They do not independently establish that repeated incidents justify changing the model.

The incident evidence, business authority and model-impact assessment remain necessary.

---

The role of problem-management platforms

Jira Service Management, ServiceNow and similar tools can:

Atlassian explicitly warns that a heavy, isolated problem-management process can become a dumping ground where problems remain disconnected from the teams capable of addressing them.

ServiceNow describes dashboards and analytics for identifying abnormal trends, coordinating root-cause analysis and reducing repeated incidents.

The model-governance process should use these capabilities rather than duplicate them.

Its narrower task is:

Connect the operational pattern to the canonical model object and decide whether model truth should change.

---

Where Martenweave fits

Martenweave currently positions itself as a backend-first model-governance and evidence layer for SAP migration, MDM, data governance and AMS. It connects datasets, tickets, validation reports, decisions and SAP context to canonical model files, deterministic validation, gap reporting, lineage, impact analysis and reviewable proposals.

Its principles are relevant to incident-driven improvement:

The operating chain could be:

AMS incidents and problems
→ normalised observations
→ recurring pattern
→ affected model objects
→ dataset evidence
→ impact analysis
→ PatchProposal
→ human approval
→ implementation
→ recurrence measurement

Martenweave should not replace incident or problem management.

It should preserve the model-learning loop those systems usually do not own.

---

A focused product slice

A useful first implementation would not need sophisticated machine learning.

It could support:

Incident evidence references

Register external incidents, requests, problems and knowledge records.

Model-object linking

Associate evidence with:

Pattern grouping

Group by:

Recurrence report

Show:

Promotion to finding

Convert a recurring pattern into a reviewable model finding.

Proposal generation

Draft a PatchProposal using:

Outcome tracking

Compare recurrence before and after the approved change.

This is enough to demonstrate operational model learning.

---

Deterministic controls

Martenweave could validate that:

The validator should not decide that ten incidents automatically require a model change.

It should ensure that the decision is supported and traceable.

---

What AI may safely contribute

AI can help with:

AI should not conclude:

A safer AI output is:

Observed pattern:
Twenty-seven incidents concern Supplier Risk during activation.

Common resolution:
Manual review followed by temporary STANDARD entry.

Possible model implication:
The operational process uses an assessment-pending state
that is not represented separately from final risk.

Evidence still required:
- owner confirmation;
- affected dataset population;
- downstream use of STANDARD;
- current source-remediation status.

This assists investigation without inventing authority.

---

A worked example: Customer Group

Operational evidence

Over four months:

Initial support interpretation

Users maintain Customer Group incorrectly.

Pattern analysis

Most incidents involve customers with multiple sales areas.

The central CRM provides one Segment value.

SAP stores Customer Group by sales area.

Local teams maintain overrides in a CSV.

Model finding

The approved mapping implies central equivalence but does not define organisational derivation.

Decision

Customer Group remains sales-area-specific.

CRM Segment is not automatically equivalent.

A governed enrichment process is required until an authoritative organisational source exists.

Implementation

Outcome

Ticket volume falls, but the more important result is that the model now represents the correct granularity.

---

A worked example: Supplier Risk

Operational evidence

Pattern

The process requires an intermediate review state.

Model change

Create Supplier Review Status separate from final Supplier Risk.

Implementation

Outcome measures

The result cannot be assessed through incident count alone.

---

A worked example: Tax Identifier exemptions

Operational evidence

Country support repeatedly requests validation bypasses.

First hypothesis

Local users are avoiding mandatory data.

Pattern analysis

Most cases involve non-resident supplier organisations with exemption evidence.

The approved model lacks an explicit exemption structure.

Model response

Create contextual exemption attributes or relationships containing:

Operational result

Fewer bypass requests.

Governance result

Exemptions become identifiable, time-bound and auditable.

The second result is more important.

---

A worked example: no model change required

Operational evidence

Twenty incidents report that supplier persons fail an organisation-only validation.

Investigation

The canonical rule already applies only to organisations.

Classification

Configuration defect.

Response

Correct SAP configuration and regression tests.

Model outcome

No canonical semantic change.

Operational outcome

Incidents cease.

Incident patterns improve the system without changing the model when the model is already correct.

This distinction protects the registry from unnecessary churn.

---

A decision matrix

Pattern evidenceModel clear?Implementation aligned?Likely response
Repeated incident, known correct ruleYesNoFix implementation
Repeated incident, missing source evidenceYesYesSource or process remediation
Repeated exception, context undefinedNoUnclearModel decision
Placeholder used as workflow stateNoOperational workaroundSplit concepts
Users misunderstand valid processYesYesTraining and service improvement
Unexpected pass caused by defaultYesNoRemove default and remediate
Same local concept in several countriesPartialMixedEvaluate global promotion
Owner reassignment dominates resolution timePartialN/AOwnership model change

The matrix is not an automated decision engine.

It disciplines the initial interpretation.

---

Measures for an incident-informed model

A useful scorecard can include:

Model-linked incident coverage

What proportion of relevant incidents reference a canonical object?

Recurring-pattern rate

How many incidents belong to an existing pattern?

Unresolved model patterns

Which recurring patterns still lack a decision?

Workaround dependence

How many patterns rely on defaults, spreadsheets or bypasses?

Time from evidence to decision

How long after a pattern becomes clear does the owner decide?

Recurrence after change

Did incidents return after model or implementation correction?

Unexpected-pass detection

How many silent-control failures were found outside user reports?

Semantic debt reduction

How many overloaded values, shadow states or ambiguous mappings were removed?

Ownership delay

How much resolution time is spent finding authority?

These measures show whether AMS is improving the model rather than merely becoming faster at handling its weaknesses.

---

Do not punish teams for surfacing patterns

If recurring incidents are treated as evidence of poor AMS performance, teams will suppress or recategorise them.

A learning-oriented process should distinguish:

The team that identifies a shadow lifecycle or invalid default has improved governance, even if the short-term defect count increases.

The purpose of the analysis is not to assign blame.

It is to make operational evidence usable.

---

The final operating loop

A mature AMS organisation should be able to run this loop continuously:

1. Restore service.
2. Preserve the incident evidence.
3. Link the issue to canonical model context.
4. Group recurring patterns.
5. Distinguish implementation, process, source and model causes.
6. Measure the affected population.
7. Route the question to the correct owner.
8. Propose the smallest valid change.
9. Validate and review impact.
10. Implement through existing SAP and ITSM processes.
11. Measure recurrence and semantic improvement.

The loop does not require a new enterprise platform.

It requires a stable model layer between operational evidence and approved change.

---

Final perspective

AMS is usually measured by:

These metrics matter.

They do not measure whether the underlying data model is becoming healthier.

An organisation can build an efficient support service around an increasingly fragmented model.

It can resolve:

The tickets close.

The model debt grows.

Problem-management practices already encourage organisations to connect incidents, investigate contributing causes and prevent recurrence rather than stopping at service restoration.

SAP MDG provides the operational governance capabilities needed to enforce approved models, ownership, workflows, validated values and business rules.

Martenweave’s opportunity sits between them:

Turn recurring operational evidence into traceable, validated and human-approved improvements to the canonical data model.

The practical test is not only:

Did the number of incidents fall?

It is:

Can the organisation explain which model weakness caused the incidents, which approved change addressed it, which population and implementations were affected, and whether the same semantic problem disappeared afterward?

When it can, AMS becomes part of continuous data-model governance.

When it cannot, support becomes increasingly efficient at compensating for a model that never learns.

About the authors

Martenweave is maintained by Dzmitryi Kharlanau.

Martenweave is a backend-first model-governance and evidence layer for SAP migration, MDM, data governance and AMS teams.

It connects:

It does not replace SAP MDG, ServiceNow, Jira Service Management, problem management or AMS delivery.

Its role is to ensure that operational learning becomes durable model knowledge rather than another closed ticket.

Sources and notes

This article was reviewed on 14 July 2026.

SAP currently describes SAP Master Data Governance as a central governance layer that unifies master data, policy and metadata; preserves semantics and relationships through one governed model; assigns ownership of attributes; enforces validated values; supports collaborative workflow routing; monitors business rules; and preserves an audit trail of changes.

Atlassian describes problem management as identifying and managing the causes of incidents, analysing contributing factors, connecting incidents to problems and tracking long-term corrective actions. It distinguishes service restoration from elimination of the underlying problem and warns against heavy, isolated problem backlogs disconnected from teams that can act.

ServiceNow’s current Problem Management description includes identifying abnormal trends, linking incidents and problems, exposing known errors and workarounds, coordinating root-cause analysis and building remediation plans to reduce recurring incidents.

Martenweave Core currently describes itself as a backend-first model-governance and evidence layer that turns datasets, tickets, validation reports, decisions and SAP context into canonical files, deterministic validation, gap reports, lineage, impact analysis and human-reviewed proposals.

Its current principles define canonical Markdown and YAML files as the source of truth, generated indexes as rebuildable, deterministic validation as the first gate and AI output as reviewable PatchProposal objects rather than silent model mutation.

Its documented pipeline connects evidence, proposals, validation, dataset gaps, impact analysis, human review and GitHub issues or pull requests, while explicitly avoiding the role of a generic workflow engine or direct SAP write-back platform.

Martenweave is independent and is not affiliated with or endorsed by SAP, Atlassian, ServiceNow or other vendors named in this article. Product names and trademarks belong to their respective owners.

Primary sources

Related articles