Every record you retire before the migration is one you never have to migrate or reconcile. Step 2 of 6: decide what is worth taking across, and clean it at source. Missing fields. Old records nobody has used in years. The same vendor set up more than once with slightly different punctuation. None of it looks dramatic in the source system, and all of it can complicate and derail an SAP migration. The cutover weekend is the worst possible moment to meet it for the first time. Step 1 profiled the system and worked out what is actually in it. This step decides what is worth taking across, using vendor master data as the worked example, and shows how the corrections go back into SAP. This post covers why cleansing belongs at source, the three questions the flow asks in order, and how the same flow feeds the progress dashboard and the write-back. Step 2 of 6: retire, dedupe and check vendor master data in one flow, then write the fixes back to SAP. Also available on YouTube. Why cleansing belongs at sourceCleansing is step 2 of the six data-workstream phases in an ECC to S/4HANA move, and it pays for itself twice. Every record you drop here is a record you never need to migrate, and never need to reconcile afterwards. The later phases get lighter with every vendor, customer or material you retire in advance. It also matters where you do it. Clean the data in flight, between extract and load, and your source and target no longer match, so the reconciliation in step 5 has to explain every difference you introduced on the way. Clean it in the source system before anything moves, and source and target should agree. That is the whole argument for doing this early, and doing it in ECC. One flow, three questions, narrowing as it goesThe worked example is the vendor master, in one documented DVW Flow Tool flow that reads left to right. It asks three questions in a deliberate order. Is this vendor still used? Is it the same as another one? And only for the vendors you are keeping, will it actually load? Each question shrinks the list the next one has to work on. 1. Is this vendor still used?LFA1, the vendor master, gives every vendor and the date it was created. That is one half of the retirement test. The other half is whether anybody has actually bought anything from them, which comes from looking across purchase requisitions and purchase orders for the date each vendor was last used for anything. A vendor created years ago with no purchasing activity since is a candidate for retirement, and the flow says so. 2. Is it the same as another vendor?Duplicates rarely match exactly. The flow normalizes the names, drops punctuation and legal forms, and then suggests possible matches. The matching logic is yours to change, so the rules reflect how your organization names its suppliers rather than a generic algorithm. Together, the first two questions produce a proposal list of old, unused or duplicate records for the business owners to decide on. The flow does not decide for them. It puts the evidence in front of the people who own the data. 3. Will it actually load?Everything past this point runs only on the vendors you are keeping. The address, bank and company code checks are driven by that list, because there is no point querying SAP for detail on a vendor already marked for retirement. The question is whether each vendor will become a business partner in S/4HANA. The rules are not uniform. A region, for example, is mandatory only for certain country codes, not all of them. Those checks live in the flow, where they can be changed and recorded so they match the way you use your own SAP system. Two outputs come out for each vendor. The single worst problem, so the counts are clean and the dashboard can prioritize. And the full list of problems, so whoever has to fix the record sees everything at once rather than fixing one field and having it rejected on the next check. Track the progress without extra adminProject management need status updates, and data owners need to prioritize corrections. The same flow that assesses the data also writes the output for the progress dashboard, so nobody compiles a status report by hand. The data owners review it, decide what to archive and what to clean, and make the adjustments. Put the fixes back into SAPThere are two routes. SAP's own mass change tools, such as XK99, work for many corrections. Or a second flow can update SAP directly. That flow writes the worklist and shows what SAP already holds for each vendor. The data owner fills the gaps and puts a Y in the apply column. That column is the control, so updates can be batched as they come through rather than applied all at once. The flow reads the input sheet and writes the changes back to SAP through the DVW BAPI Write tool. Each vendor is updated in turn, and the confirmation is read back from SAP, so any failed update can be reviewed and investigated rather than discovered later. Run it againLike the profiling flow in step 1, this one is repeatable. Each run shows the further improvement in data quality, reflected in the dashboard run by run, until the vendor master you are taking across is one you trust. That is the cleansing phase: assess what should be moved, clean it in the source system ahead of time, and close the gap to de-risk the migration. For the wider picture see the SAP data migration solution page. In this series
Next in the series is mapping, where the old values are translated into the new structure, ready for the target. Run the retirement test on your own vendor masterRead and write SAP data from any analytics or data platform. Free 30-day trial, full functionality, no commitment. Trusted by 500+ enterprises. Comments are closed.
|