SAP ATC Check Variant: Scoping a Useful Run

Decision context

An ATC run that returns forty thousand findings changes nothing. The team looks at it once, agrees it is unmanageable, and goes back to work. Everything about configuring ATC well is about producing a result somebody will act on this week.

Three levers control that: the check variant decides which checks run, the object set decides what they run against, and the priority and baseline settings decide what is presented as requiring action now.

The other decision is where the checks run. Remote ATC lets a central system on a current ABAP release check an older managed system over an RFC connection, which is how S/4HANA readiness checks are run against a system that has not been upgraded.

Choose the variant for the purpose

A single variant cannot serve both a conversion analysis and a daily development gate. They ask different questions and tolerate different volumes of finding.

SAP delivers variants for S/4HANA readiness analysis, including one intended for remote checks against a managed system. The delivered names and their contents vary by release and by the version of the simplification content in the checking system, so confirm what is delivered in your own system rather than adopting a name from an article.

• Conversion readiness. Simplification and S/4HANA-specific checks, run remotely from a central system against the production-equivalent source. The output is a remediation scope, not a code review.
• Development quality gate. Syntax, performance, security, and internal standard checks, run at transport release or in the editor. This variant has to be small enough that a developer runs it without resentment.
• Security-focused. Run separately and reviewed by a different audience, because mixing security findings into a general quality report is how they get triaged as style issues.
• Performance-focused, run against the objects that actually run hot rather than against everything, since the finding density is high and the relevance is not uniform.
• Keep the variants few and named for their purpose. A landscape with fifteen variants has no variant anybody trusts.

Scope the object set

The object set is the second lever and the more effective one. Most of the difference between a useful and a useless run is what it was run against.

• By package or software component, for a scoped analysis of one area rather than the whole custom namespace.
• By transport, so a run covers exactly the change under review. This is the object set that makes ATC usable as a gate.
• By last-used data where you have it. Custom code that has not executed in a year is a candidate for retirement rather than remediation, and remediating it is the most expensive way to discover that.
• Exclude generated objects, obsolete namespaces, and anything already scheduled for decommissioning, and record the exclusion so the number is honest.
• Run against a copy of production content rather than development, when the question is what production actually contains.

Priorities, exemptions and the baseline

These three features are what turn a finding list into a work list. Used without a policy they turn it into a way of suppressing everything.

• Priority 1 findings are the ones that block. Decide as a team what priority 1 means for you and hold to it, because a priority that never blocks anything stops being read.
• Exemptions need a requester, an approver, a reason, and an expiry date. An exemption with no expiry is a permanent silence, and a codebase accumulates them faster than it accumulates findings.
• A baseline suppresses the findings that existed at a point in time so that only new findings block. This is the single most effective way to introduce ATC into a large legacy codebase without stopping delivery.
• The baseline is a debt, not a resolution. Record what it contains, review it periodically, and reduce it against a plan rather than letting it become invisible.
• Report new findings per release separately from the baseline total. The trend in new findings is the number that tells you whether quality is improving.

What the workflow must cover

• Purpose-scoped runs. Bind a check variant and an object set to a stated purpose, so the output is a work list rather than an inventory.
• Usage-aware remediation. Combine findings with usage evidence so unused custom code can be retired rather than remediated.
• Exemption lifecycle. Require an owner, a reason, and an expiry on every exemption, and surface exemptions approaching expiry.
• New-finding trend. Separate baseline debt from new findings so the trend that matters is visible per release.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. State the purpose of the run before choosing the variant.
2. Scope the object set by package, transport, or usage rather than by the whole namespace.
3. Run remotely from a current checking system when analysing an older source.
4. Set a baseline for legacy findings and enforce priority 1 on new ones.
5. Review exemptions and baseline content on a fixed cadence.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Variant contents and purpose
• Object set definition and exclusions
• Checking system and content version
• Finding counts by priority
• Baseline contents and date
• Exemptions with owner and expiry
• New findings per release
• Usage evidence per object

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• ATC findings are static analysis. Dynamic calls, generated code, and runtime configuration are not fully covered.
• Delivered variant names and contents vary by release and by the simplification content version in the checking system.
• A finding count is not a remediation estimate. Effort depends on the objects, not on the number of messages.

Buyer checklist

• What is this run for, and does the variant match that purpose?
• What was the object set, and what was excluded?
• Which findings are new since the baseline?
• How many exemptions have no expiry date?
• Is unused custom code being remediated instead of retired?