LEANPRO / PRACTICAL WORKBENCH / 02
Finance readiness.
Prove the business can operate through the systems change.
Finance leads, project managers and operational owners preparing an ERP change, separation or first operating cycle.
A critical-journey register, evidence gaps, dependency owners and a first-cycle support plan.
00 / SET THE BOUNDARY
Your working brief.
Start with a real decision and a defined scope. Work through the six sections with the people who operate the process and the people accountable for accepting change.
Prepare a first draft, then challenge it in a working session. Put references to evidence in the registers, assign accountable reviewers, and turn the gaps into actions. Review the generated decision brief before sharing it. The tool organises evidence; it does not certify readiness or make a decision for you.
Your entries stay in this tab unless you choose to save in this browser or download a copy. Nothing entered here is submitted to Leanpro. Avoid unnecessary personal, sensitive or confidential details. A downloaded HTML copy includes your entries and the complete tool, so you can reopen it offline.
01 / WORKING SESSION
Define the operating day.
Which transactions must work, for which entities, on which date?
Work through it
- Identify the operating date and the first transaction cycles after it. Separate the immediate operating model from the later target model.
- Walk one real journey from trigger to reconciliation. Include manual steps and failure routes, not just the system transaction.
Challenge the assumption
- Who loses money, service or control if this fails?
- What can safely wait, and who has accepted that boundary?
Worked example — illustrative, not a client case
An illustrative UK distributor must invoice from a newly separated entity on Monday. Its first payroll is three weeks later, but employee data and payment approvals still need an earlier preparation date. These are different deadlines.
Use the starter rows or add your own. Evidence references can identify your internal records without copying confidential content into this file.
| Journey / entity | Day One outcome | Volume / deadline | Failure consequence | Accountable owner | × |
|---|---|---|---|---|---|
| Invoice and collect | |||||
| Purchase and pay | |||||
| Close and report |
OUTPUT STANDARDA bounded list of operating journeys with dates, owners and an explicit out-of-scope decision.
Watch for: Using the configuration workstream list as the business scope.
Record the review, not just the activity.
“Accepted” requires a named reviewer, date and evidence. “Not applicable” needs the same accountability and a rationale. This is a working record, not independent assurance.
02 / WORKING SESSION
Test the business journey.
What evidence demonstrates a critical journey works end to end?
Work through it
- For each journey, specify a normal case and an exception using representative data and access roles.
- Record the expected result before the test, then link the actual result and the person who accepts it. Retest after material changes.
Challenge the assumption
- Can the real operator complete it without project-team rescue?
- Does the accounting or reporting output reconcile to the source?
Worked example — illustrative, not a client case
An invoice test is not complete when an invoice posts. The illustrative evidence also shows correct tax treatment as agreed by finance, customer delivery, ledger posting, cash allocation and an authorised correction. Finance confirms the control requirements.
Use the starter rows or add your own. Evidence references can identify your internal records without copying confidential content into this file.
| Journey / test ID | Expected result | Actual result / evidence | Exception / workaround | Acceptance owner | × |
|---|---|---|---|---|---|
| Invoice correction / credit | |||||
| Payment rejection | |||||
| Reporting reconciliation |
OUTPUT STANDARDTraceable test evidence, recorded exceptions and business acceptance for critical journeys.
Watch for: Treating a successful supplier demonstration as operational acceptance.
Record the review, not just the activity.
“Accepted” requires a named reviewer, date and evidence. “Not applicable” needs the same accountability and a rationale. This is a working record, not independent assurance.
03 / WORKING SESSION
Connect external dependencies.
Which inputs outside the build team can stop the operating move?
Work through it
- Name the provider and receiver of each input. Give it an acceptance condition, not just a delivery date.
- Work back from the transaction deadline and allow time for validation. Escalate decisions that have no accountable approver.
Challenge the assumption
- What exactly does this input unblock?
- What is the fallback if it arrives late or is rejected?
Worked example — illustrative, not a client case
A bank file layout can be delivered on time but unusable. The dependency closes only after the receiving bank or agreed test route accepts the file and finance confirms the response can be reconciled.
Use the starter rows or add your own. Evidence references can identify your internal records without copying confidential content into this file.
| Required input | Provider → receiver | Acceptance condition | Needed by | Fallback / decision | × |
|---|---|---|---|---|---|
| Banking and signatories | |||||
| Customer / supplier master data | |||||
| Access and approval roles |
OUTPUT STANDARDInputs with an accepted receiver, a meaningful completion test and an escalation route.
Watch for: Marking an input complete because an email or file was sent.
Record the review, not just the activity.
“Accepted” requires a named reviewer, date and evidence. “Not applicable” needs the same accountability and a rationale. This is a working record, not independent assurance.
04 / WORKING SESSION
Accept balances and control totals.
Can finance explain the migrated position and unresolved differences?
Work through it
- Agree reconciliation levels by entity, currency, ledger and material account before loading. Have finance define tolerances.
- Record the source total, loaded total, difference and disposition. Separate corrections from accepted differences; keep approval evidence.
Challenge the assumption
- Can opening positions be traced to an agreed source?
- Who owns exceptions after the project team leaves?
Worked example — illustrative, not a client case
An illustrative opening-balance difference is within an agreed threshold but affects a control account. Finance investigates it separately rather than allowing the overall net difference to conceal the issue.
Use the starter rows or add your own. Evidence references can identify your internal records without copying confidential content into this file.
| Reconciliation item | Source / loaded reference | Difference / tolerance | Correction or accepted exception | Approver / evidence | × |
|---|---|---|---|---|---|
| Opening balances | |||||
| Open receivables / payables | |||||
| Bank and control accounts |
OUTPUT STANDARDA signed reconciliation approach and a visible disposition for material differences.
Watch for: Assuming a balanced trial balance proves every account or open item is correct.
Record the review, not just the activity.
“Accepted” requires a named reviewer, date and evidence. “Not applicable” needs the same accountability and a rationale. This is a working record, not independent assurance.
05 / WORKING SESSION
Rehearse the transition.
Can the team execute, stop or recover the move?
Work through it
- Sequence activities around business deadlines, prerequisite evidence and explicit decision points. Assign one owner per step.
- Rehearse timings, communications and recovery with the people who will execute them. Record the last viable point for each recovery option.
Challenge the assumption
- Who can stop the transition, and on what evidence?
- What business consequence follows if recovery takes longer than planned?
Worked example — illustrative, not a client case
A rehearsal shows that the final load overruns the invoicing window. The team changes the sequence and tests an agreed interim invoicing process instead of leaving the conflict to cutover night.
Use the starter rows or add your own. Evidence references can identify your internal records without copying confidential content into this file.
| Activity / decision | Prerequisite | Owner / deputy | Timing / stop point | Completion evidence | × |
|---|---|---|---|---|---|
| Final reconciliation | |||||
| Release decision | |||||
| Business acceptance |
OUTPUT STANDARDA rehearsed sequence with named decision authority and realistic recovery conditions.
Watch for: A long task list with no authority to pause or a fallback nobody has tested.
Record the review, not just the activity.
“Accepted” requires a named reviewer, date and evidence. “Not applicable” needs the same accountability and a rationale. This is a working record, not independent assurance.
06 / WORKING SESSION
Own the first operating cycles.
Who carries the operation after the technical switch?
Work through it
- Plan support around invoicing, payment, reporting and close cycles, not an arbitrary number of days.
- Define incident severity, response ownership, workarounds and handover evidence. Agree what must be true before project support exits.
Challenge the assumption
- Who can authorise an urgent workaround?
- What changes when the first month-end reveals a new issue?
Worked example — illustrative, not a client case
An illustrative team completes the first payment run during hypercare, but its first month-end is still unproven. Support reduces only where the remaining close-cycle risks and coverage are explicitly owned.
Use the starter rows or add your own. Evidence references can identify your internal records without copying confidential content into this file.
| First-cycle milestone | Operational owner | Support route / cover | Exit evidence | Residual action | × |
|---|---|---|---|---|---|
| First invoicing run | |||||
| First payment run | |||||
| First month-end close |
OUTPUT STANDARDA support plan spanning the actual first cycles with accepted residual ownership.
Watch for: Equating a quiet first week with a stable finance operation.
Record the review, not just the activity.
“Accepted” requires a named reviewer, date and evidence. “Not applicable” needs the same accountability and a rationale. This is a working record, not independent assurance.
07 / INTERACTIVE WORKBENCH
Critical operating conditions.
Record the conditions that must hold for the operating day. A condition is not closed until a named owner has recorded evidence. This register does not approve go-live.
Use the action log below for each commitment. Choose “Blocker” only where an accountable decision has made it a blocking condition. Record closure evidence and an owner before marking it complete. The decision brief highlights open blockers and overdue commitments alongside the section reviews.
08 / TURN GAPS INTO COMMITMENTS
An action needs an owner.
Describe an observable closure outcome. Record the owner and due date, and add an evidence reference when closing it. A completed action without owner and evidence remains unresolved in the decision brief.
| Action / closure outcome | Accountable owner | Due date | Priority | Status | Closure evidence | × |
|---|
09 / BRING THIS TO THE DECISION
Your decision brief.
These counts describe your records, not a readiness score. An accepted section can still contain conditions; review the evidence and the action log before any decision.