If you’re implementing Oracle Cloud ERP, data can be a serious pain point unless the right people, process, and technology are in place to extract, transform, cleanse, enrich, and load the data. The following checklist leverages Premier's experience implementing dozens of Oracle projects that can help your organization prepare it's upcoming Oracle Cloud ERP implementation.

‍Assess the Landscape

Start planning the data effort by assessing what you have today and where you are going tomorrow. While frequently glossed over, spending time assessing the landscape provides three prime benefits to the program. The first benefit is that it gets the business thinking about the possibilities of what can be achieved within their data, by outlining what data they have today and what data they would like to have in the future. Secondly, this exercise gets the organization engaged on the importance of data and instills an ongoing master data management and data governance mindset. The third benefit is that it enables the team to start to seamlessly address the major issues that programs encounter when assessment is glossed over.

  • Create legacy and future state data diagrams that capture data sources, business owners, functions, and high-level data lineages.
  • Outline datasets that don’t exist today that would be beneficial to have in Oracle Cloud.
  • Ensure the future state landscape aligns with data governance vision and roadmap.
  • Reconcile legacy and future state data landscapes to ensure there are no major unexpected gaps.
  • Capture the type, volume, and load method for the different types of attachment/document data that will be required to reside in Oracle.
  • Perform initial evaluation of what can be left behind/archived by data area and legacy source.
  • Perform initial evaluation of what needs to be brought into the new Oracle based landscape and reason for its inclusion.
  • Profile the legacy data landscape to identify values, gaps, duplicates, high level data quality issues.
  • Interview business and technical owners to uncover additional issues and unauthorized data sources.

Create the Communication Process

Communication is a critical component of every implementation. Breaking down the silos enables every team member to understand what the issues are, the impact of specification changes, and data readiness. (Read about the impact of siloed communication.)

  • Create migration readiness scorecard/status reporting templates that outline both overall and module specific data readiness.
  • Create data quality strategy that captures each data issue, criticality, owner, number of issues, clean up rate, and mechanism for cleanup.
  • Establish data quality meeting cadence.
  • Establish a cadenced meeting with Oracle Support to discuss critical Service Requests (SRs) and ensure any Oracle-related roadblocks will be resolved in a timely manner.
  • Define detailed specification approval, change approval process, and management procedures.
  • Collect the data mapping templates that will be used to document the conversion rules from legacy to target values.
  • Define high-level data requirements of what should be loaded for each Pod. We recommend getting as much data loaded as early as possible, even if bare bones at first.
  • Define status communication and issue escalation processes.
  • Define process for managing RAID log.
  • Define data/business continuity process to handle vacation, sick time, competing priorities, etc.
  • Host meeting that outlines the process, team roles, expectations, and schedule.

Capture the Detailed Requirements

Everyone realizes the importance of up-to-date and comprehensive documentation, but many hate maintaining it. Documentation can make or break a project. It heads off unnecessary rehash meetings and brings clarity to what should occur versus what is occurring.

  • Document detailed legacy to Oracle Cloud data mapping specifications for each conversion and incorporate additional cleansing and enrichment areas into data quality strategy.
  • Incorporate when Oracle’s quarterly patches will occur in each POD into the project schedule to ensure any updates to FBDI/HDL templates are identified and are reflected in the mapping specs, conversion programs, etc.
  • Be cautious when scheduling test cycles or go-live around quarterly patches.
  • Document system retirement/legacy data archival plan and historical data reporting requirements.

Build the Quality, Transformation and Validation Processes

With the initial version of the requirements in hand, it's time for the team to build the components that that will perform the transformation, automate cleansing, create quality analysis reporting, and validate and reconcile converted data. To reduce risk on these components, it's helpful to have a centralized team and dedicated data repository that all data and features can access.

  • Create data analysis reporting process that assists with the resolution of data quality issues.
  • Build data conversion programs that will put the data into the Oracle Cloud specific format (FBDI, ADFdi, HDL, etc).
  • If necessary, review Oracle documentation or submit service requests for any unexpected findings when working with Oracle delivered formats or load programs.
  • Incorporate validation of the conversion against Oracle configuration from within the transformation programs.
  • Enable pre-validation reporting process that captures and tracks issues outside of the Oracle load programs.
  • Define data reconciliation and data validation requirements and corresponding reports.
  • Build query-based reporting that extracts raw migrated data out of Oracle Cloud to streamline validation and reconciliation process.
  • Verify data quality issues are getting incorporated into the data quality strategy.
  • Confirm any delta or catch-up data requirements are accommodated within the transformation programs.

Execute the Transformation and Quality Strategy

While often treated separately, data quality and the transformation execution really go hand-in-hand. The transformation can't occur if the data quality is bad and additional quality issues are identified during the transformation.

  • Ensure that communication plans are being carried out.
  • Capture all data related activities to create your conversion runbook/cutover plan while processes are being built/executed.
  • Create and obtain approval on each Oracle load file.
  • Run converted data through the Oracle load process.

Validate and Reconcile the Data

In addition to validating Oracle functionality and workflows, the business needs to spend a portion of time validating and reconciling the converted data to make sure that it is both technically correct and fit for purpose. The extra attention validating the data and confirming solution functionality could mean difference between successful go-live, implementation failure, or costly operational issues down the road.

  • Execute data validation and reconciliation process.
  • Execute specification change approval process per validation/testing results.
  • Obtain sign-off on each converted data set.

Retire the Legacy Data Sources

Depending on the industry/regulatory requirements system retirement could be of vital importance. Because it is last on this checklist, doesn't mean system retirement should be an afterthought or should be addressed at the end. Building on the high-level requirements captured during the assessment. The retirement plan should be fleshed out and implemented during throughout the course of the project.

  • Create the necessary system retirement processes and reports.
  • Execute the system retirement plan.

Following this checklist can minimize your chance of failure or rescue your at-risk Oracle ERP Cloud implementation. While this list seems daunting, rest assured that what you get out of your Oracle implementation will mirror what you put into it. Time, effort, resources, and – most of all – quality data will enable your strategic investment in Oracle Cloud to live up to its promises.