SAP CR&B Data Migration - Reconciliation Strategy

Disclaimer: this blog is written with the sole intent of knowledge sharing based on my own personal experiences across various IS-U Data Migration projects. Please feel free to provide feedback/comments based on your project experiences that will enhance this write-up for the entire community within the SAP Utilities space.

Assumption: for the purposes of this blog write-up and the illustrated diagram, it is assumed there is one primary data source (system of record) that will be migrated over to the SAP CR&B system. Since all Client projects are unique with their source legacy system(s) and business processes, if there were more than one legacy source databases that are being migrated, then all such source data should be reconciled across the E-T-L framework as well.

As with any SAP Implementation, SAP CR&B Data Migration Reconciliation is an absolute critical factor for a successful Go-Live. Usually, this is documented in detail as part of the CR&B Data Migration Strategy. In this blog, I have primarily focused on summarizing the much needed three different reconciliation levels in the CR&B Data Reconciliation Strategy. It is summarized at a very high-level to provide a brief overview of the CR&B Data Reconciliation approach. Essentially, a Data Reconciliation Strategy should aim at achieving both, Quantitative and Qualitative data reconciliation.

Needless to mention, that I have successfully utilized this strategy/approach across various IS-U projects (Electric, Gas and Water Utilities) within the USA. In fact, I would recommend that the Data Reconciliation Tasks should be incorporated in the Data Migration Project Plan early on with the Mock (Trial) Data Conversions and Integration Test Cycles.

Very simply put, we should reconcile entire data set end to end for the E-T-L umbrella, that is, from Extracts to Transform to Loads. See below diagram illustrating the three levels of Data Reconciliation needed for a CR&B Data Migration across the E-T-L streams.

1. First and foremost, ensure that  Object Totals - Record Counts and Dollar Grand Totals are reconciled starting with the first Mock (Trial) Data Conversion or perhaps even earlier starting with the Unit Test / String Test phase. Getting these reconciled and matched up early on in the Realization phase, flushes away many of the technical programmatic, field mapping errors as such. Thus, this level can be categorized as a purely quantitative reconciliation per Migration Object.
   1. For the Extract and Transform streams, the record counts and totals can be incorporated in the conversion programs itself to obtain a level of accuracy.
   2. For the Loads as such, ISMW provides the load statistics for each load run and these can be captured from EMIGALL Statistics.
   3. Statistics from (a) and (b) can be summarized for Management Reporting purposes or as needed.

    

2. Second level, gets us deeper into validating the data quality from a business perspective. As part of the Reconciliation Strategy, teams should compile a list of business reconciliation checks that would also alleviate data quality concerns for the business users. These queries/checks should be executed for each of the Integration Test Cycles and perhaps most of the Mock (Trial) Data Conversion Loads.
   This level of reconciliation focuses on comparing numbers/reports from Legacy Extracts to the converted data in SAP CR&B system. Some good examples would be, comparing and reconciling installations/premises categorized by Residential and Commercial and/or Division (if there are more than one Division that is); reconciling counts of installation by rate category, number of customers on Budget Billing; Number of vacancy disconnects vs. number of technical disconnects vs. number of disconnect due to non-payment; number of business customers vs. individual customers; customers on owner allocation, etc. These are just a few examples. A comprehensive list will vary by each project and can be put together based on the functional/business teams’ inputs. These checks, should however, be in addition to a good Data Validation Plan that gets incorporated into the Integration Test Cycles. Typically, the data validation plan should be outlined in a complete Data Migration Strategy as well as the Project Test Strategy.
3. Finally, the last level of Reconciliation focuses on the FICA Reconciliation. This takes the $$ totals reconciled at Level one (described above) a step further into a more detailed level, whereby reconciling at the Contract Account level and by Main and Subs Transactions. Usually, the FICA Main and Sub transactions are mapped to different types of legacy balances/charges/fees. Some examples would be, Current Open Balance for the customer, Past-Due Balance, Deferred Balance, Miscellaneous fees, Written-Off amount, etc. Therefore, reconciling by Main and Sub Transactions provides and suffices for a complete FICA reconciliation for the converted data.
   The FICA reconciliation for the converted data is also done from an end-to-end E-T-L to ensure the dollars are reconciled completely. Even if there were errors along the E-T-L path, these can be accounted for and reconciled at various check-points. The results can be summarized for Project Management Reporting purposes as well as for the Internal/External auditors, as the case may be.

Hopefully, the above write-up provides a good overview and summary to give a kick-start to document and implement a detailed CR&B Data Reconciliation Approach. The detailed strategy should document specifications of every check-point where data needs to be reconciled in the E-T-L Data Migration Flow; as well as the list the Migration Objects and the business data elements being reconciled.