hypercare

SAP Post-Go-Live Hypercare Management

This skill enforces a structured, measurable hypercare period — preventing premature exit from hypercare, untracked P1 downgrades, and BAU handover before the system has actually stabilized.

---

Iron Laws

1. NEVER EXIT HYPERCARE WITHOUT MEETING ALL STABILIZATION CRITERIA. A stabilization criterion is a hard gate, not a guideline. "Things are mostly quiet" is not a criterion. Zero P1s for the defined period is a criterion.
2. NEVER DOWNGRADE A P1 WITHOUT EXPLICIT BUSINESS OWNER SIGN-OFF. A Basis consultant cannot unilaterally decide a P1 is "actually a P2." The business owner whose process is affected makes that call — and signs it.
3. ALWAYS TRACK RESOLUTION TIME AGAINST SLA. Every issue must have a logged open time and a logged close time. SLA compliance is reported daily, not estimated weekly.
4. EVERY ISSUE MUST HAVE A DOCUMENTED ROOT CAUSE, NOT JUST A FIX. Applying a fix without root cause analysis means the same issue recurs. Root cause is mandatory before an issue ticket is closed.
5. ALWAYS COMPLETE LESSONS LEARNED BEFORE HYPERCARE EXIT. Lessons learned are not optional retrospective documentation. They are the mechanism by which the BAU team inherits institutional knowledge. Skipping them means the next incident is guaranteed.
6. HYPERCARE SHIFTS MUST BE EXPLICITLY ROSTERED. "The team will be available" is not a shift plan. Named individuals, contact numbers, shift start/end times, and escalation paths must be documented before go-live day one.

---

Rationalization Table

Agent Will Try To...	Why It Seems Reasonable	Why It Fails	Counter
Declare hypercare exit because "it's been quiet"	"No major issues in the last week — the system is stable"	Quiet periods during hypercare can reflect low user adoption, incomplete business processes (month-end not yet run), or issues being worked around rather than resolved. Stabilization criteria exist precisely to prevent this misreading.	Iron Law 1: Stabilization criteria are checked line-by-line, not assessed by feel.
Downgrade a P1 to avoid SLA breach	"It's really more of a P2 — there is a workaround"	If the original classification was correct, downgrading under SLA pressure conceals a performance failure. The workaround may be consuming significant business effort not visible to IT.	Iron Law 2: Priority changes require business owner sign-off. Document the workaround effort cost.
Close an issue ticket without root cause	"The user confirmed the issue is fixed"	Without root cause, the fix is symptomatic. The same issue will recur in a different context (different user, month-end load, different plant).	Iron Law 4: Root cause field is mandatory for ticket closure. "Unknown" is not acceptable — it means investigation is incomplete.
Skip daily standup when issues are low	"It's a quiet day, we don't need the call"	The standup is not just issue review — it surfaces emerging patterns, batch job failures, and performance degradation before they escalate to P1. Skipping it creates blind spots.	Checklist Step 4: Daily standup is non-negotiable during hypercare, regardless of current issue volume.
Hand over to BAU before stabilization criteria are met	"The BAU team is capable, they can handle it from here"	BAU teams do not have project context, escalation relationships, or vendor access that the project team has. Premature handover without these transfers creates a support vacuum.	Iron Law 1 + Checklist Step 7: Knowledge transfer is a structured activity with completion evidence, not an assumption.
Treat all issues as equally urgent	"Every user complaint is a priority"	Without triage, P1 (system down) competes with P4 (cosmetic issue) for the same resource. SLA discipline collapses. Business-critical processes go unaddressed while cosmetic issues are fixed.	Checklist Step 3: Priority classification happens at first contact, using the defined P1-P4 matrix.