When does a company need to migrate or change their data landscape? What could be a benefit of doing this?
When it comes to mergers and acquisitions, they are driven by an agenda of growth. You’re often trying to merge departments to thereby increase efficiency and decrease costs. From the data migration perspective, it’s crucial to ensure that the data landscapes are united in such a way where all the data and KPIs follow the same logic.
What might common pitfalls be in a merger & acquisition migration project?
When you merge data landscapes, it’s often extremely complicated. It’s crucial that you, early on in the process, understand what impact the merger is going to have throughout your entire data landscape. This is why it’s entirely necessary to establish a thorough overview of your landscape, including all its integrations, before tackling this type of migration.
It’s also quite common that the companies in question have different ways of measuring, using and calculating data. This presents a further challenge as it is entirely essential that the final landscape adheres to only one type of logic.
Other challenges related to M&As include cultural and language differences. Often, documentation and software will be presented in a local language – creating challenges when it comes to understanding KPIs and the overall data landscape. Cultural differences can be an obstacle when it comes to decision-making styles, leadership, ability to change, how people work together and beliefs regarding personal success and teamwork. In a case like this had facts, such as data lineage, can be the one truth about the company´s real status.
This is where the NodeGraph solution really shines. From an early stage, before the merger has even taken place, you are able to evaluate and validate the figures that are presented to you – enabling you to properly determine where the KPIs actually come from, how they are connected, how they are calculated and how they are interpreted.
How complex and time-consuming can it be to migrate data during a merger or acquisition? Is it possible to correctly estimate the cost and time needed? What hidden costs are usually overlooked?
This entirely depends on the size and complexity of the data landscapes in question. Another important thing to consider is the innate compatibility of the landscapes. Are the companies using similar systems from the get-go or will further migrations have to take place to achieve the final result (ex. BI or ERP migrations). A good place to start is by mapping the landscapes, in order to fully understand what it is you are dealing with.
It’s also quite common that an organization has built in-house add-on systems, ex. time reporting, budget forecasting system, etc. These types of systems can be difficult to identify in advance and often come as a surprise when you are already midway through the project.
It is also important to look at the long-term effect of a project. Data quality, data cleaning, mapping and documentation are key factors for an efficient project. If that is not properly done from the beginning, further problems and costs will occur later.
How often do you discover bad or outdated data, undocumented data relations or other “surprises” in the process? How can you identify them as early as possible?
Extremely often – especially when you are dealing with two or more separate landscapes. Usually, when you choose to embark on any type of migration project, you will use that opportunity to clean your data.
The largest challenge here is to ensure that everything flows smoothly throughout your entire landscape. As you begin to merge your landscapes, you will need to first map the individual data environments 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 combined landscape. Ultimately, there is a lot of impact analysis that needs to take place before anything can be migrated.
The problem is unless you have a tool like NodeGraph, you have to manually map these landscapes and their dependencies. This becomes very time-consuming and you also don’t get a comprehensive overview of the entire solution. However, by applying a tool like NodeGraph, you can instantly see where all the dependencies exist in a way that would be impossible as a result of manually entering each data element.
All in all, migrating data during a merger or acquisition project is a big investment. How profitable can it be and how soon can you expect to get a return on your investment?
My feeling is that IT projects generally tend to become larger than initially predicted. And I think this applies here as well. Subsequent needs for further investment often stem from bad project management and incorrect prioritization.
In general, however, this is an impossible question to answer. But instead of trying to apply a specific number, you can look at it in terms of the number of resources you were allocating to different BI tools and teams different data landscapes prior to the migration. This acts as one parameter. But another important thing to consider as well as the quality of your solution(s). By uniting all the data in one landscape, you can ensure that you are basing your business decisions on the correct KPI (rather than having two or three separate versions to choose from).
Ultimately, I would say the ROI is split between directs savings, less software and manpower costs, and (perhaps most importantly) indirect savings, the quality of your data solution.
What can you do to improve the project’s ROI?
When it comes to migrating data during a merger or acquisition, and specifically the BI perspective on this, it’s entirely necessary to start off by understanding and mapping the individual landscapes that are to be merged. How do they work individually and what are the potential challenges involved in ensuring that they will work together? Can the integrations in each of the landscapes remain the same throughout the migration process or will the new environment require additional middle grounds (ex. a data warehouses or data lakes) that will prepare the data in the correct way?
Ultimately, I think the key to maximizing ROI and success lies in automating the mapping of your current data landscapes as well as employing a documentation process that is automated and up to date.
Who usually leads a project like this? What roles are needed in the project team?
The CEO or CFO are involved in the early stages before the merger or acquisition has been decided upon and focus on investigating company figures and the true value of the business opportunity. After the merger has been finalized, you would typically need two CIOs whose primary focus is collaboration. It’s also important that the project is supported by top management because you need to have full transparency into a system when merging and migrating. This is furthermore important in order to facilitate collaboration.
Basically, there are a lot of people that need to be involved in a project this massive. And one of the biggest problems that arise when a lot of people are involved is, of course, human error. That’s why it is very important that the companies in question choose to be data-driven and employ data tools and automation wherever possible.
What are the top challenges that businesses typically face when merging data landscapes?
Getting people to collaborate and unite as one is probably the hardest part. Furthermore, companies are often lacking a proper and sturdy data governance framework, making overall data quality and documentation crucial challenges.
How does NodeGraph help to deal with these challenges? How does the NodeGraph data intelligence platform work? What does it do?
Primarily, NodeGraph allows you to automatically map and create automated documentation of the data landscapes in question. This will ensure that you are always up to date and will set the foundation on which to start building your combined data governance framework.
It’s also worth considering the data that led to the merger/acquisition in the first place – and whether this data was actually trustworthy.
Basically, prior to a merger/acquisition, there is a lot of knowledge and data exchange that goes on between the companies in question, related to things like revenue, overhead, employees, etc. But how can you know that these numbers are correct? And that they are being sourced from the correct place?
If you use NodeGraph in this scenario, you can automatically see an overview of the data landscape in question and are able to validate the data that you have received.
Are there any alternative tools or strategies?
One alternative strategy involved using your BI tool and collecting the numbers from there. That work will be manual and very time-consuming. If the merger/acquisition is international, this method might also see companies encounter language barriers in the form of country-specific systems, explanations and documentation.
For some, mergers are a one-off, for some, it happens quite often – how can NodeGraph be a long-term solution in both cases?
NodeGraph will help you with a lot of issues associated with your merger – from the initial KPI run-through, evaluating how figures are calculated and where data actually comes from, to the actual merger, providing an entire data landscape map with full end-to-end data lineage visualization. Additionally, you are able to automatically document your data landscapes, ensuring that everything is always currently and properly reported. All in all, NodeGraph enables you to have full control of your complete data landscape.
When it comes to more long-term wins, one of these is reflected in your data governance framework. With the knowledge that your data is always accurate and the ability to track your data throughout your landscape, you are able to build a solid foundation for high-quality governance.