Lesson 4 of 5
Test close
10 min
Listen to this lesson
The first close in a new system should never be the first time the close runs. A mock close in a test system, with realistic data and the real owners, finds the missing authorizations, the wrong variants, the jobs that run too long and the dependencies nobody wrote down. It also gives the close its first real durations, which the critical path needs.
Planning the mock close
| Decision | Contoso choice | Why |
|---|---|---|
| System and data | CMQ, client 100, refreshed from the last mock conversion | Production-like volumes and history |
| Period | A full month of transactions replayed: May | Closes need a full period of activity to be realistic |
| Scope | Company codes 1710 and 1810; plants 1710, 1720, 1810 | Covers intercompany and both US plants |
| People | The real task owners, not the project team | Tests roles, authorizations and know-how |
| Calendar | Same working days and hours as a real close | Durations are only meaningful in real conditions |
| Evidence | Task list status, logs, reconciliations, issue log | Feeds the sign-off and the next improvement cycle |
Contoso's mock close plan.
Two details matter more than they seem. First, the people: if consultants run the mock close, it proves the configuration, not the organization. Ana should post the last invoices, the cost accountant should run settlement, Dan's G/L team should run valuation. Second, the calendar: a mock close squeezed into one afternoon cannot reveal that the overhead run takes three hours on real volumes or that the reviewer for intercompany is only available in the morning.
- Week -2PrepareRefresh CMQ; replay May transactions; generate the task list; confirm owners and access
- Day 0Cut-offLogistics cut-off at 18:00; materials period moved
- Day 1Subledgers and accrualsAP backlog, billing, depreciation, accruals, GR/IR analysis
- Day 2ControllingAllocations, overhead, WIP, variances, settlement
- Day 3Valuation and reconciliationFX valuation, regrouping, intercompany reconciliation
- Day 4Statements and reviewTrial balance, statements, reviews, sign-off rehearsal
- Day +2RetrospectiveDurations, issues, critical path, improvements
Recording issues and durations
Record two things for every task: the actual start and end time, and every issue, however small. Issues fall into a few types: authorization (Ana cannot run the invoice report), configuration (a variant points to the wrong company code), data (a material without a price blocks a run), dependency (a task started before its input was complete), performance (a job ran much longer than planned), and knowledge (the owner did not know the step). The type tells you who fixes it, and the pattern across types tells you how ready the organization is.
| Task | Planned (h) | Actual (h) | Issue | Type | Owner |
|---|---|---|---|---|---|
| B: last supplier invoices | 6 | 9 | 120 invoices blocked for price; tolerance too tight | Configuration | Ana / P2P lead |
| G: allocations | 3 | 3 | None | - | Cost accountant |
| H: overhead, WIP, variances | 4 | 6.5 | Overhead job for plant 1720 ran long | Performance | Sam |
| L: intercompany reconciliation | 4 | 5 | Reviewer in 1810 lacked display role | Authorization | Security lead |
| M: statements | 6 | 6 | None | - | Dan |
Extract from mock close 1 issue and duration log.
- PlanTasks, owners, durations, predecessors
- RunReal owners, real calendar, test system
- MeasureActual durations, issues by type
- RecalculateCritical path with actual durations
- ImproveFixes and changes before the next cycle
After mock close 1, recalculate the critical path with actual durations. At Contoso, AP invoice posting took nine hours instead of six and the overhead job took 6.5 hours instead of four; the critical path grew from 28 to 33.5 hours. Both issues sat on the path, which made them the first two fixes. The authorization issue on intercompany was off the path and cheap to fix, so it was fixed too, but it was not what made the close long.
The retrospective
Hold a short retrospective within two days of each mock close, while memories are fresh. Walk the task list in order and look at three things: which tasks ran late and why, which issues recurred from the previous cycle, and whether any dependency was discovered that was not in the template. Each finding becomes an action with an owner and a date before the next cycle: a template change, a role fix, a variant correction, a job scheduling change or a training session. Priya logs the actions in SAP Cloud ALM next to the defects so the next mock close starts from a known list. A retrospective that produces no template changes is usually a sign that the questions were too polite.
What would you do?
In mock close 1, the overhead job for plant 1720 runs 2.5 hours longer than planned. Luis asks whether to accept it, because "it is only a test system." What should the close lead do?
- Run a mock close in a test system with production-like data, the real owners and the real calendar.
- Record actual start and end times and every issue, typed as authorization, configuration, data, dependency, performance or knowledge.
- Recalculate the critical path with actual durations; fix on-path issues first.
- Include reconciliations as tasks with owners and evidence.
Check your understanding · not graded
Lesson check
1. Who should execute tasks in a mock close?
2. Mock close 1 shows AP invoices took 9 hours instead of 6, on the critical path. What happens to the close?
3. A reviewer in 1810 lacked a display role. Which issue type is that?
4. Why should the retrospective happen within two days of the mock close?