SAP Hypercare Checklist and Exit Criteria

Decision context

Hypercare has a defined start and no natural end. Without written exit criteria it becomes an expensive support model nobody can cancel, because the argument for stopping is always weaker than the fear of stopping.

Two things decide whether hypercare works: the severity definitions and the daily rhythm. Severity has to be defined by business impact, agreed before go-live, and applied by one triage owner rather than by whoever raised the ticket.

What Adranum contributes here is narrow. When a hypercare defect turns into a change, the change carries its impact analysis, its selected tests, and its results bound to the package, so an urgent fix does not become an unrecorded production change.

Severity definitions to agree before go-live

Define these by business consequence, not by technical symptom, and agree them with the business before the window. Four levels is enough.

• Critical. A core business process cannot run and there is no workaround: goods receipts cannot post, invoicing is blocked, payroll cannot run, statutory reporting is stopped. Immediate response, continuous work until resolved or a workaround exists.
• High. A core process runs with a costly workaround, or a non-core process is stopped. Response within hours, resolution within the working day.
• Medium. A process is degraded, slower, or partially incorrect, with an acceptable workaround. Resolution within the hypercare period.
• Low. Cosmetic, convenience, or enhancement requests. These are not hypercare defects and belong in the normal backlog immediately, or hypercare volume stops meaning anything.

The daily rhythm

Hypercare is run on a cadence, not on demand. The cadence is what turns a queue of tickets into a set of decisions.

• Morning technical check before business hours: background jobs, interface queues, failed IDocs and messages, short dumps, update errors, lock entries, spool and output errors, database growth and free space.
• Daily triage with one triage owner who sets severity, assigns, and closes. Severity set by anyone is severity set by no one.
• Daily stand-up per business stream with the process owner present rather than a delegate, because severity is a business judgement.
• Daily report to the sponsor: new, resolved, open by severity, aged items, and trend. The trend is the number the exit decision depends on.
• Weekly review of aged and recurring items to find the underlying cause rather than repeating the same fix.

Exit criteria to write before hypercare starts

Write these into the go-live decision pack. Agreeing them under pressure, after go-live, rarely produces criteria that can ever be met.

• No open critical defects, and no high defects older than an agreed age.
• New defect arrival rate below an agreed threshold for a stated number of consecutive days.
• At least one complete period-end close executed in production and reconciled.
• All interfaces at steady state with error rates back to an agreed baseline.
• Every remaining open item transferred to normal support with an owner, a severity, and a target date.
• Knowledge transfer complete: run book, known issues, and workarounds handed to the support team and acknowledged by them.
• Business process owners formally sign that their process is operating.

What the workflow must cover

• Triage ownership. One accountable triage owner sets severity, so the queue reflects business impact rather than the urgency of whoever reported it.
• Change discipline under pressure. An urgent hypercare fix still carries impact analysis, selected tests, and results bound to the exact package that was shipped.
• Trend over volume. The arrival rate and the age profile decide when hypercare ends, not the raw count of tickets closed.
• Documented handover. Open items transfer to normal support with owner, severity, and target date rather than closing when the hypercare period expires.

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. Agree severity definitions and exit criteria before go-live.
2. Staff the rota with a named triage owner per day and an escalation path.
3. Run the daily technical check, triage, stand-up, and sponsor report.
4. Review aged and recurring items weekly for underlying cause.
5. Exit against the written criteria and hand over every remaining item.

Evidence to require

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

• Severity definitions agreed pre go-live
• Daily technical check results
• Triage decisions and owners
• Defect arrival and closure trend
• Period-end close reconciliation
• Interface error baseline
• Handover list to normal support
• Business process owner sign-off

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.

• Hypercare cannot compensate for testing that did not happen. It surfaces the gap at the most expensive moment.
• Severity is a business judgement, and no tool assigns it.
• Exit criteria set after go-live are negotiated under pressure and rarely hold.

Buyer checklist

• Were severity definitions agreed before go-live?
• Is there one triage owner per day?
• Is the defect arrival rate falling or flat?
• Has a full period-end close been executed and reconciled in production?
• Does every open item have an owner and a target date at exit?