Acquisition Data Integration – Part 2: Reporting
Photo by Pietro Jeng on Unsplash
This is the second in a series of posts about acquisition data integration. It is based on a conversation with a friend who is the integration lead for her company’s recent acquisition. The first post recapped my conversation about transactional systems with the in. After the portfolio review, we discussed reporting, which will take on many forms throughout the acquisition integration effort.
On Day One, C-suite executives and other senior leaders integrated management dashboards. Key metrics such as day sales outstanding, revenue forecasts, cash flow projections, sales pipelines, and key employee turnover are common metrics. There will be employee town halls, investor relations calls, media events, and key client meetings they need to conduct. Those leaders will begin asking their teams questions. The need to drill down into information about the combined organization will be a prime imperative.
Preparing for the first financial close will happen what seems like almost immediately. Within 90 days, the first quarterly filings will be due. In addition to financial reporting, most of your regulatory and compliance reporting will also be due within the first few months.
These early reporting efforts are often accomplished with brute force using spreadsheets, simple databases, and user-developed code. Quickly building a stable, reliable reporting platform will drive immediate benefits.
The first step for building the platform is meeting with your business partners to set expectations on what reports will be needed and when. Understanding how the reports will evolve throughout the integration process is also essential. Some changes can be built into the project plans. Others will happen because you learn something new and unexpected about the data or the requirements.
As you are working on your reports and dashboards, be sure to confirm the definitions that each firm uses to define common elements. There are multiple ways to calculate WIP; Cost Value and Percentage of Completion are two examples. Companies often use multiple calculation methods based on the job type. The software platform used to manage WIP can have slight calculation differences as well. As you consolidate data, understanding these differences will impact those reports.
Developing the report requirements also captures most of your functional data conversion requirements. The report designs can be used by IT to build and test conversion programs during the application rationalization process. An example of this is Chart of Accounts mapping. To construct the immediate reports, the finance team will consolidate data. As they work with information, they will refine how they work with the accounting data. This will define much of the financial system integration.
With a detailed understanding of what reports are needed, you can decide what ETL, datastore, and visualization platforms to use for reporting. Quick decisions allow you to move from brute force to a more manageable solution as quickly as possible. Wherever feasible, these should be the same as the standard reporting platforms that will be the enterprise standard for the new, integrated company.
Over the last decade or so, the term ‘data fabric’ emerged to describe a single architecture that unifies all of the services and technologies used by an organization to manage data. This idea of enterprise or master data management is not new. The explosion of IoT, capability focused cloud/SaaS applications, and edge computing drive today’s data management challenges. M&A activities can be a major catalyst for companies that are looking to improve their comprehensive data fabric.
Leveraging integration activities to drive your data fabric platform’s adoption can help IT deliver value well beyond what is expected by the deal.
Please share feedback about this article and suggestions for future topics of discussion in the comments section. Here is a link to a short video on this subject.
