Two checklists you can use without us.
The five questions we start every assessment with, and the nine things business users actually report after an upgrade. Take them and use them with your own team — they work just as well without a Rufouss engagement behind them.
Five questions worth asking before go-live.
These are the five we start every assessment with. They are just as useful without us, so please take them and use them with your own team.
Gathering the answers usually takes a programme a little time — that is completely normal, and it is often the most useful conversation a team has all quarter.
Two to three weeks · fixed fee
fully remote · no obligation to continue
“It worked before the upgrade.”
These are the things business users actually report in the weeks after an upgrade or a conversion. Underneath each one is a familiar cause — and a check that would have found it first.
“The system feels slower since the upgrade.”
Usually Custom programs written against the old data model now read through compatibility views instead of the tables they were built for. Nothing is broken, so nothing is flagged — it is simply doing more work than it used to.
We check Which custom objects still read legacy tables directly, and whether any test measures the same transaction before and after so the change is visible as a number rather than a feeling.
“Users are hitting dumps in transactions that were fine last month.”
Usually Custom code nobody mapped. A month-end program fails at month end, not before, because it was never in test scope — nobody knew it still ran.
We check Production execution logs against test coverage. Code that no longer runs needs no test. Code that runs without one is the exposure.
“Invoices didn’t print on go-live morning.”
Usually Output management moved to BRF+. It is the single most predictable go-live failure there is, and it is almost never fully covered because output determination has more combinations than anyone expects.
We check Output coverage across every document type and every channel — print, email, EDI — not just the two the team demonstrated.
“The report runs, but Finance says the number is wrong.”
Usually The Universal Journal replaced the old FI tables. A custom report still totals correctly against its own logic — it just no longer agrees with the system of record. This is the worst class of defect there is, because nothing fails.
We check Reconciliation coverage between legacy tables and ACDOCA for every custom financial report in scope.
“Long text is getting cut off, and some interface files are rejecting.”
Usually Material number extended to 40 characters. Anything that concatenates or truncates it quietly loses data, and QA rarely uses material numbers long enough to expose it.
We check Every custom object and interface that touches material number — traced, and covered with data that is actually long enough to break it.
“Purchase orders are failing on vendors that were fine in test.”
Usually Business Partner conversion. The conversion itself was tested and signed off; the downstream procure-to-pay scenarios that depend on the converted records were not re-run afterwards.
We check Whether end-to-end process scenarios were re-tested after conversion, or only the conversion.
“A trading partner rang to say our messages are rejecting.”
Usually Interfaces and EDI were tested with sample messages rather than real ones. The variants that only appear in live traffic were never sent.
We check Replay coverage against real message volume — per partner, per message type.
“Stock figures in our own reports don’t match the system.”
Usually The simplified inventory data model. Custom inventory reports reading the old aggregate tables drift quietly out of agreement, and the drift is only noticed once someone reconciles by hand.
We check Which custom objects read the old tables, and whether any test proves the new answer matches the old one.
“Testing passed, but the scenarios don’t look like how we actually work.”
Usually Test data that cannot support the test. Testers could not construct the real scenario, so they tested the variant the data permitted and recorded a pass. Everyone acted in good faith.
We check Whether representative, masked, reconciled data exists for each in-scope scenario — and how old it is.
None of this is obscure — every experienced SAP team knows these areas. They still cause trouble, simply because a programme under deadline has more to track than any one team can hold. A second pair of eyes on this list is usually all it takes.
Used one of these and found something you did not expect?
There is no charge for a conversation, and no obligation to continue. Tell us what you found and we will tell you what we would look at next.