Lesson 5 of 5
Testing capacity results
10 min
Listen to this lesson
Capacity planning produces numbers and dates, not documents, so it is easy to "test" by looking at a chart and nodding. Good capacity tests calculate the expected load before running the tool, then compare. They also prove the behaviors that change daily work: overload detection, finite dispatching, firming after dispatch, and the load reduction from confirmations and TECO.
- PrepareKnown capacity on ASSY-10 (for example 25.5 h/day) and a known set of test orders in CMQ
- ExpectCalculate load per day by hand from standard values and quantities
- EvaluateManage Work Center Capacity: record load, first overload and pegged orders
- LevelDispatch with an agreed planning strategy; record new dates and statuses
- Re-evaluateLoad after leveling compared with expectation; screenshots plus order data
Test cases
| Case | What to prove | Evidence |
|---|---|---|
| Available capacity | Shifts, breaks, utilization and individual capacities give the expected hours per day | Capacity header and the app's available capacity for a sample week |
| Requirements | An order's load equals setup + quantity × time per piece | Hand calculation vs pegged requirement |
| Overload detection | A planned overload shows in the overload band at the agreed threshold | Overview: max load, first overload date |
| Finite dispatch | Dispatch moves operations into free capacity in the planning direction | Order dates before/after; status DSPT; load after |
| Firming | MRP does not move dispatched planned orders | Planned order before/after an MRP run |
| Load reduction | Confirmation and TECO reduce or remove requirements | Load before and after the confirmation and TECO |
| Deallocate | Deallocating returns the operation to not dispatched | Status and load after deallocation |
A capacity regression set.
Capacity results depend on time, which makes them fragile in test systems. Load is calculated against today's date, so a test that passed in March may show everything as backlog in April. Write test data with relative dates (start next Monday), and record the system date with each result. If the test client is refreshed or mocks are rerun, recreate orders rather than reuse old ones.
Include authorizations in the test. Dispatching firms orders and changes dates that production and sales rely on, so not every user should be able to do it. Test that a planner for Detroit can dispatch on Detroit work centers, and that a user without the planner role cannot. That is a negative test, and it belongs in the same pack as the functional ones.
- Mock 1Master data checkCapacity headers and standard values compared with ECC for critical work centers
- Mock 2Functional testsEvaluation and leveling cases run in CMQ with Fiori apps
- Dress rehearsalPlanner walkthroughPlanners level a real week of converted orders
- Go-live weekProduction checkLoad on ASSY-10 compared with the plan agreed before cutover
In a conversion, two extra risks apply. First, planners who used the classic planning tables in ECC must be trained and tested on the Fiori apps, because the classic tables are not the target. Second, open orders converted from ECC carry their capacity requirements over; the first evaluation in S/4HANA should match the last one in ECC for the same horizon, or something was lost or duplicated.
What would you do?
A capacity test passed last month. Today the same test shows every order as backlog. Nothing was changed in configuration. What is the most likely explanation?
| Defect seen in Contoso's capacity tests | Root cause | Fixed by |
|---|---|---|
| Every operation on TEST-10 shows as overload | Capacity category not marked relevant for finite scheduling | Work center capacity settings |
| Dispatch places work on a Saturday | Interval with a weekend shift left over from an ECC peak season | Remove the interval; retest |
| Load twice as high as the hand calculation | Standard values in minutes read as hours by a converted formula | Formula and standard value key corrected |
| Planner cannot dispatch on WIND-10 | Role restricted to MRP controller 101 only | Role extended to WIND-10 for the component planner (102) |
Capacity defects from Contoso's test cycles: almost all are master data or role findings.
- Calculate expected capacity and load by hand before running the tools.
- Test overload detection, finite dispatch, firming, deallocation and load reduction.
- Use relative dates and record the system date; capacity results depend on time.
- In a conversion, compare ECC and S/4HANA load for the same horizon and retrain planners.
Check your understanding · not graded
Lesson check
1. Why calculate the expected load by hand before testing?
2. Which evidence proves firming after dispatch?
3. How should test data be dated for capacity tests?
4. The app shows load exactly twice the hand calculation for every order on one work center. Where should the tester look first?