So you’ve gone live with your new system – congrats! By all means, celebrate the achievement. But don’t lose sight of the fact that when it comes to data quality, you’re just getting started.
Typically, the data migration team moves on to the next release or the next big thing, but the clean data they just loaded won’t stay that way for long. Real people are going to start using that data now, and creating more – without the benefit of the carefully designed business and mapping rules used during the migration. The same data quality drift you saw in your legacy system will start to creep into your new ERP system, and you need to react. All that energy you’ve dedicated to data remediation, standardization and mapping during the course of data migration needs to be captured in your organization’s data governance initiative.
One key mistake organizations often make is standing up their data governance organization in a silo isolated from the data migration team. Over the course of the implementation, it’s the migration team that’s reacting to defects, lessons learned and refining their logic. In parallel, the data governance team is developing data standards and policies. There’s a huge overlap in these activities – or at least, there should be. And too often, there’s not.
There are a few ways to address this:
- Co-location: Quite simply, make governance and migration work together during the implementation. Encourage cross-pollination of ideas and issues. When a mapping changes on a field, migration should inform governance. When a data standard is developed, migration should be checking its own activities against the model.
- Handoff: Just prior to go-live, the migration team should formalize its documentation and mapping rules and share them with the governance team. In many cases, the load methods used by the migration team may be reusable by the governance team. Too often, they’re left to reinvent the wheel.
- Talent swaps: Encourage a revolving door from the migration team to the governance team, and to an extent vice versa. There’s a vast amount of institutional knowledge amassed by the migration team, who need to understand both legacy and new business processes down to the field level. Locking that knowledge away in the migration team deprives the organization of their deep understanding and ability to ensure business-ready data in the live system.
Data quality matters most in ongoing production business processes – so why does the focus so often shift away from it after go-live? Go-live should never be the goalpost for an organization’s data management strategy. A comprehensive and adequately-resourced data governance strategy — enabled and informed by the data migration process — gives organizations a fighting chance to maintain business-ready data in a production system.
About the AuthorFollow on Twitter More Content by Nate LaFerle