Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 4 of 5

Business validation by data owners

10 min

Reconciliation shows that numbers tie out. Business validation shows that the data is right and usable in the eyes of the people accountable for it. It is the step where a data owner says "this is our data and we can run the business on it". Because owners are busy and validation windows are short, especially on go-live weekend, validation has to be designed as carefully as the load itself.

Designing a validation pack

For each object, prepare a validation pack for its owner: what to check, how many records, which apps or reports to use, the comparison data side by side, and how to record the result. Owners should never receive raw tables. They should receive a short checklist and comparison reports with the same layout for source and target.

Pack elementWave 2 example: customers (owner Maria)
ScopeBusiness partners in the customer role, sales area 1910 / 10 / 00
Inspection set50 largest fleet customers in full, every merged duplicate, a random sample of 300
Usability testsCreate, deliver and bill a test order for a migrated customer; post a payment against a migrated open item
Where to lookBusiness partner display, customer line items, the sales order apps; legacy ERP comparison report with the same fields
How to recordPass or finding per record; findings logged as migration defects with object and mock
Time neededSix hours in mocks; two hours on go-live weekend for the reduced set

The elements of a validation pack, with the Wave 2 customer pack.

Inspection and usability

Validation has two halves. Inspection asks whether records are right: owners compare attributes with the source and with what they know. Usability asks whether the data works: key users run real transactions on migrated records, because a record can look right and still fail in a process because of a field nobody inspected, such as missing shipping data or a wrong dunning procedure.

Full inspection by reportOwners review exception reports over all records for key attributes; good assurance for modest effort
Usability on critical recordsRun real transactions on top customers' orders and open items; highest assurance, highest effort
Spot checks without a planOwners look at whatever they happen to open; little effort, little assurance
Unplanned record-by-record reviewOwners page through thousands of records; tiring, and assurance drops as attention fades
Validation techniques by effort and assurance. A good pack uses the top row, plus a planned sample, and avoids the bottom row.
The Sign-Off Table · thesignofftable.com/academy/sap-dmg-302

Validating derived and dependent data

Some of the most valuable checks are on data the migration derived rather than copied: credit limits assigned during migration, payment blocks from cleansing rules, price conditions linked to the right customer and product, or the core part flag on products. Owners should check that derived values follow the approved rules and that dependent objects point at the right parents, for example that open orders for Flotillas Monterrey carry the surviving business partner number after the duplicate merge.

  1. Before the mockPacks agreed with owners; comparison reports tested; time slots in the plan
  2. After load and reconciliationOwners receive packs only when reconciliation is clean or explained
  3. InspectAttributes checked against source and knowledge
  4. UseTransactions run on migrated records in the test system
  5. RecordResults per record; findings logged as defects
  6. DecideOwner states the validation result for the object
The validation cycle in each mock. Reconciliation comes first, so owners do not waste time on data that is incomplete.
The Sign-Off Table · thesignofftable.com/academy/sap-dmg-302

Go-live weekend validation

The final load leaves little time. Agree a reduced set per object in advance, rehearse it in the dress rehearsal with real timing, and keep owners on call in their slots. Typically the reduced set covers the high-value records in full, a smaller random sample and a few safe usability checks. Everything validated on the weekend must be something the owner has already done in a mock.

What would you do?

In Wave 2 Mock 3, Dan's validation of open payables finds all inspected supplier items correct, but no one has posted a payment run against migrated items. Usability tests were dropped because "inspection was clean". The final load is in three weeks. What should Priya do?

Key points
  • Give each owner a validation pack: scope, records, usability tests, where to look, how to record, time needed.
  • Validate both inspection (is it right?) and usability (does it work?).
  • Check derived values and dependent references, such as merged business partners on open orders.
  • Rehearse the reduced go-live validation set with real timing in the dress rehearsal.

Check your understanding · not graded

Lesson check

  1. 1. When should owners receive their validation packs in a mock?

  2. 2. Which validation half runs real transactions on migrated records?

  3. 3. Why check open orders after a duplicate customer merge?

  4. 4. What usability checks run in production after the final load?