Writing NetSuite Requirements and UAT Scripts That Hold Up After Go-Live
Most ERP projects fail at the requirements stage. An ERP system is simply your processes mapped unto software. If your processes are not clearly defined then system gaps will show up during UAT or post go live. I have written requirements and run UAT on NetSuite implementations and on a Dynamics 365 migration, in media, FMCG and other sectors. These are the habits that help.
Start from the process, not the screen
Map the key finance processes first: order to cash, procure to pay and record to report. Capture the current process, the intended process and the people who own each step. Requirements that come from a process map describe outcomes, not just fields.
Write requirements that can fail a test
One requirement, one outcome, written so multiple people would agree whether it was met.
An owner, a priority and an acceptance criterion for each.
A reference back to the process step it supports.
Keep a traceability matrix
A simple table linking each requirement to its configuration and to the test case that proves it, makes scope discussions easier to make. When someone asks why something was built, or whether something was tested, the answer is only a lookup away.
UAT scripts with expected results
A good UAT script names the user role, the starting data, the steps and the expected result, for finance, the expected general ledge impact should be included. Include the awkward cases: credit notes, intercompany, foreign currency and period-end.
Use recordings as evidence
Recorded walk-throughs of users completing the scripts let you compare what was done with what was agreed, without everyone being present. They also help with training and with settling disagreements about what was demonstrated.
Test the data migration separately
Migrated balances and master data deserve their own acceptance tests: reconcile opening balances, open items and key reports to the source system, and have finance sign them off.
Define sign-off before you start
Agree what ‘done’ means. For example: no open critical defects, all high-priority scripts passed, migration reconciled and key users trained. Written criteria turn a negotiation into a checklist.
This is the work behind my systems and technical requirements gathering service.