Selecting Target Operating Models- Structural Considerations Part II

Data and Automation
This topic used to be of concern only to the largest acquirers; however, technology adoption has advanced such that even smaller companies often operate on complex IT systems and leverage automated workflows for many business processes.  As such, an understanding of the systems and data architecture of the parties is now both a key aspect of a thorough due diligence process, and a key structural consideration when selecting a TOM for all types of M&A.

It is important to note that many large enterprise resource planning (ERP) systems, such as SAP or Oracle, are highly configurable and thus can be extensively customized by the installers.  It is almost certainly a mistake to assume that because “both of us are on SAP” that your data structures are in any way compatible! Let’s look at an example:

     Target Company's General Ledger Account Numbering Logic is described as AB.CDE.EFGHI And:
     AB=country
     CDE= legal entity
     FGHI= general ledger account number

     Acquirer's General Ledger Account Numbering Logic is described as AB.C.DE.FG.H.IJKL And:
     AB= legal entity
       C= country
     DE= division or business unit
     FG= budgeting cost or profit center
      H= tax treatment for this account, often used for feeds to "bolt-on" tax calculation engines
     IJKL= general ledger account number

Right away we can see that in order to do joint reporting, we are going to need to do some breaking apart and re-mapping of the target’s data, or else forego same and institute a manual process.  (Side note- if we use outsourcing, any such manual process would likely require a new contractual agreement, since the current process for reporting leverages the existing acquirer data structure).

Given the integrated nature of these tools it is common for multiple processes to share a single data field-even across multiple functions or even business units.  Recall that the acquirer had a tax treatment field designed to export data to a tax engine.  Such a field would often be used in the USA to send data to separate tools for sales tax and income tax, and outside of the USA might be used for both value-added tax (VAT) and for local financial statement reporting under that geography's GAAP rules.  The field may also be used to exempt certain accounts from consideration in the budgeting process, i.e. to indicate accounts used only for intercompany transactions.  Bottom line, be sure you have a complete understanding of the data map and the design of all interfaces and workflows before planning to change an existing data structure.

Here I’ve provided the more difficult example, where the target’s existing data needs to be broken into smaller segments.  This is more common since the acquirer is usually larger and more technologically sophisticated than the target; however, the opposite situation could also apply.   In that case the exercise may be simpler, i.e. you can combine data more easily than you can split it out.  In either case, you must take into consideration the time and resources required to consolidate on a combined toolset, and that will have an impact on your selected TOM.
Note also that we’ve only looked at GL account structure in our example thus far.  Imagine the scope that can occur across all of the parties combined data elements and data sets!  This is the reason that data migration is often the “long pole” on the integration critical path, and why an understanding of data and systems architecture is a key consideration in TOM selection.