A classic principle is that information should only be stored in place place, but if you have a scattered landscape may it be hard to reach this goal.
Let us look at a fictive customer to explain a little bit more about their challenges.
The company have gone though a number of mergers and acquisitions during a decade and they have developed several different systems during the years. Their business model have changes during the years and they have now more product groups, more customer-segments and more customer channels compared to 15 years ago. The result is different systems supporting product groups, customer segments and customer channels and very little master data management.
Product information is scatted between a huge number of systems, depending on the type of product, who its sold to and by whom. The principle state that we should have only one system for product information, but the time and cost to reach this state is not viable from a business perspective.
What we need start with is some archaeology to find out the current state of applications, their data and integrations between systems, as well as describing business processes an a not to detailed level. We also need to keep track of how channels, customer segments and products groups relates to the processes and applications.
Now is it time to analyze the material and to prioritize who to do now, later or never based on business benefits. This last option is especially interesting if a system is not supporting the future business model, but earns money today and can't be closed.
Based on priority can we suggest a transformation plan to start with. This plan needs to be updated regularly due to changes in business and IT, that's for sure. But is good to have a start where we can agree of a reasonable level of changes instead of trying to do everything at once.
This brings us to the governance perspective of the whole thing. We need to have a governance structure in place to succeed with larger changes and this includes information governance. Who is responsible for information models, information quality, which systems should be master for certain attributes and when should changes be done.
Easy as a pie, if you done it before.