Planner acceptance and sign-off

Transactional systems are accepted by business users running scenarios. Planning systems are accepted by planners trusting the numbers enough to act on them. That trust is the real exit criterion, and it has to be built with evidence: parallel runs within tolerance, explained differences, planners who can do their weekly tasks without help, and a fallback they will not need.

Planner acceptance testing

Planner acceptance testing (PAT) is user acceptance testing for planning. Contoso ran it during the second parallel cycle, with planners doing their real monthly tasks in IBP and embedded PP/DS while APO still drove production. Each task had a script, but the success criterion was the planner's decision, not the clicks.

Exit criteria for go-live

• Two signed parallel cycles per stage, all comparisons within tolerance or classified.
• No open defect of severity 1 or 2 in planning, integration or PP/DS; severity 3 with workarounds known to planners.
• PAT complete: every task accepted by its planner.
• Integration proven: release counts and totals reconcile in two cycles; MRP plans from IBP demand in the test system without duplicates.
• Cutover rehearsed: dress rehearsal completed in the planned window, fallback tested.
• Operations ready: job schedule, monitoring of CI-DS tasks and PP/DS alerts, support roles named.

Hypercare and the first months

After go-live, the first two monthly cycles are hypercare: Priya's team runs the same comparisons against the frozen APO snapshot where it still makes sense, and the support team watches CI-DS task logs, PIR reconciliation and PP/DS alerts daily. Contoso tracks four measures: forecast accuracy (weighted MAPE) against the APO baseline, the share of planner overrides, PP/DS schedule adherence on ASSY-10, and the number of manual PIR corrections. A rising override share is often the first sign that planners do not trust the system.

Step by step: running a PAT session

1. Before the session, Wei's team checks that the second-cycle snapshot is loaded and the comparison report from cycle 1 is closed.
2. The planner opens the task script: the decision, the data, the criterion. No click-by-click instructions; the planner works as on a normal day.
3. Priya's tester observes and logs time taken, help requested and any workaround used.
4. The planner records the decision in IBP (for example a locked consensus or a promoted scenario) and states whether the criterion is met.
5. Misses are logged in SAP Cloud ALM as a training need or a defect, with the planner's words, not the tester's interpretation.
6. At the end of the cycle, the planner signs the task list; open items carry a planned retest date.

Observation data is useful evidence. When the Detroit scheduler needed 70 minutes for a weekly sequencing task that took 25 minutes in APO, the cause was not the system but a missing Fiori tile on her launchpad; she had been navigating through three apps. The fix was a role change, and the retest took 22 minutes.

After APO: the planning regression set

IBP is a cloud product with several releases a year, and S/4HANA receives feature packs and upgrades. Once APO is gone, the decision-based PAT tasks and the integration checks become Contoso's planning regression set. Before each IBP release reaches the production tenant, Priya's team reruns the forecast job on the controlled data set, a supply heuristic run with expected capacity loads, the release reconciliation and two PAT tasks with planners. Tolerances stay the same; the comparison point is now the previous IBP release instead of APO.