When does a company need to migrate or change the data landscape? What could be the reason/benefit for this?
Changing your ERP system is a relatively normal thing to do, even though it might not occur every year. This move can happen as a result of company growth, moving away from a legacy system towards a newer system or as a result of a merger or acquisition.
The challenge that companies usually face in this scenario stems from the complexity of the many dependencies that exist within the reporting and analytics tools that are, in turn, based on the data in the ERP system. Basically, a change in ERP system will have a multitude of different domino effects throughout your BI landscape. And it’s worth noting that this challenge isn’t necessarily unique to an ERP system change but can also arise when changing CRM system, HR system, etc.
What common pitfalls exist in an ERP system change? And how does this ultimately affect the BI solution?
When you upgrade your ERP system, it’s often extremely complex. It’s crucial that you, early on in the process, understand what impact the change is going to have throughout your entire data landscape. Often, changing your ERP system will also involve reconnecting your BI tool, as well as rethinking and restructuring the infrastructure of your landscape.
For example, as a company grows, they might choose to move over to another ERP system. ERP systems notoriously don’t always lend themselves to reading data in every which way – often requiring an additional license to get the job done and, in some cases, not even being compatible with the BI tool in question.
This is why it’s entirely necessary to establish a thorough overview of your landscape, including all its integrations, before tackling an ERP migration.
How complex and time-consuming can such a project be? Is it possible to correctly estimate the cost and time? What hidden costs are usually overlooked?
I think the largest cost that can be mistakenly overlooked is related to the integrations required to make the new ERP system work with the rest of your BI landscape. As mentioned, you are often required to purchase new licenses to enable data reading between your existing tools and, in some cases, there might even be compatibility issues that can really only be overcome by changing yet another one of your tools.
When it comes to ensuring data quality during an ERP migration, what type of bad or outdated data can you expect? How can you best prepare for and mitigate this?
Anything is possible. Usually, when you choose to upgrade your ERP system, you will use that opportunity to clean your data – which will unavoidably affect your BI system. The largest challenge here is to ensure that everything flows smoothly throughout your entire landscape.
As you change to a new ERP system, you will need to map the previous data environment in order to fully understand what elements will be affected by the migration and what will need to change to match (i.e. properly integrate with) the new system. Ultimately, there is a lot of impact analysis that needs to take place before anything can be migrated.
What tools are worth investing in?
From a BI perspective, I don’t think there are any tools that are going to do the job for you. There are, however, often specific tools to apply to specific ERP systems. For example, you might be able to apply a database viewer to see what tables and fields exist in the ERP system to better understand the environment.
How can NodeGraph help? And how can a user benefit from NodeGraph beyond the migration project?
The strongest benefit of using NodeGraph during your ERP migration is its ability to perform automated impact analysis. This basically means that you can start in your ERP system, select a chosen data element and ask NodeGraph to show you exactly what data is related to that element and what will be affected by a change in that element. All this as a result of one click.
When it comes to personal data, what can you do to ensure that you are following all the relevant regulations?
There are a lot of regulatory structures to consider but one of the most commonly discussed is, of course, GDPR.
With GDPR, you need to know how data moves throughout your data landscape. It’s not enough to know where the data is in your ERP system, but you also have to be able to map how it moves between all your data tools. In this case, using NodeGraph’s Field Tracker is a very simple way of automatically reporting on individual data fields ¬– showing their full data lineage in your landscape, as well as who has accessed them in the past and who has the permission to access them in the future.
What can you do to improve the migration project’s ROI/get a return faster?
When it comes to ERP migrations, and specifically the BI perspective on this, it’s entirely necessary to start off by understanding and mapping the relationship between the ERP system and the BI tool. How do they work together and what are the potential challenges involved in ensuring that they will? Can the integration remain the same throughout the migration process or will the new ERP system require an additional middle ground (ex. a data warehouse or data lake) that will prepare the data for the subsequent tool?
Ultimately, I think the key to maximizing ROI and success lies in automating the mapping of your current data landscape.
Who usually leads a project like this? What roles in the project team do you need?
In this case, considering the size and impact of this kind of migration, a CIO is always involved – perhaps not hands-on but definitely involved. Then you can also expect to have a Project Manager, who is responsible for the actual execution.
What would you say are some of the main challenges that businesses typically face when changing ERP system?
We’re right back at compatibility – do the systems work together and is this new ERP system actually going to work with the current landscape?
On top of this, it’s also important to assess whether the data output is going to look the same as it has before. For example, the change of system might cause your end-reports to look different, effectively changing the way that analysis has to be executed in the business. The challenge here is to get everyone on board with this.
How does NodeGraph help to deal with these challenges? How does the NodeGraph data intelligence platform work? What does it do?
Primarily, NodeGraph is key when it comes to impact analysis. The ability to automatically map your entire data landscape and determine what dependencies exist between your existing ERP system and the rest of your BI tools, on a field-level, is hugely beneficial.
Along with this, a migration of this kind often involves importing historic data. This is when quality checks come into play. With NodeGraph, you can automatically test your data to ensure that everything has been properly migrated. For example, NodeGraph can automatically tell you whether the value for sales in 2018 is, in fact, the same post-migration as it was before.
On top of ensuring quality, these automated tasks will also serve as huge efficiency boosters. Cost-wise, this is fantastic, but I would say, even more importantly, time is really of the essence when it comes to ERP migrations. Because you are working in such a fast-paced industry on a project can take several years, you are always moving towards a variable target. However, by automating many of the processes that are required during this migration, you are able to move the finish line closer – increasing the likelihood that you will be able to predict what the market will look like once you cross it.
Are there any alternative tools or strategies that can be employed when migrating your ERP system?
I think the alternative strategy you are faced with involves being diligent and manually producing detailed and correct documentation of your KPIs in Excel, including recurring updates – which is doable with the right expertise and manpower.
Larger changes in the data landscape happen quite often. How can NodeGraph be a long-term solution that continues to support organizations even past the initial migration?
I think it’s important to note that NodeGraph won’t perform the migration for you – but that it, rather, should be one part of your overall governance structure. Basically, NodeGraph will ease a lot of the pains associated with migration, ensuring that your landscape is always properly and currently documented and that it is aligned with your overall governance guidelines. Here, I think it’s pretty common for companies to have governance under control when it comes to data warehouses, etc. but when it comes to the BI landscape, it’s quite rare to see organization employing a governance tool. Which is strange, really, because there is a lot of logic involved here, too.
Do you have any examples of companies that NodeGraph has assisted in performing successful migrations? What were the key factors to success?
Of course. However, when it comes to ERP systems, this isn’t necessarily a migration that happens very often. I would say we more commonly work with system changes surrounding CRM or E-Commerce platforms– helping to ensure data trust and efficiency throughout the migration.
For example, one of the clients that we work with has stores all over the world. When it comes to implementing new systems in these different stores, you’re up against a wide range of different types of tools and integrations, such as payment solutions, credit card fraud systems, and so on.
If you can’t rely on a proper map of your different data integrations (such as the one the NodeGraph can automatically create for you)– the job becomes extremely resource-heavy.
There you have it, folks.