No one ever over estimates the amount of data work required to integrate a new acquisition.
Its one thing when an entire company is being purchased, but today as companies optimize their product lines it is often a single division or even a business that’s being sold and in those cases getting the business off of the former owners ERP is part of the value proposition for selling. Typically there are penalties associated with not moving off of the former owners ERP by a given date. Time is always of the essence.
The team who did the deal invariably assumes that the data will just merge right into the current SAP environment. This is especially the case if the division of the selling company is already running SAP. How hard can it be to move a business from one SAP system to another?
As with everything, it depends.
It depends on how much customization either of the companies employed. If they are both on the same version standard SAP, with little customization, then of course it is easier and if one of the two rebuilt all the supply chain processes.
However, even in the best of cases:
· The definition of the Customer will often be slightly different making harmonizing the customer data difficult. (are you selling the doctor or the office? Is your customer defined as a delivery point first as is common with route sales or defined at the legal entity level as in most b2b businesses)
Try combining customer databases if one entity used customer sales organization to to define a given level of a customer that the other organization used at the global customer level? Both could be perfectly rational ways to manage customers, but they are different. If you assume they are not, you will waste time and money and risk integration success if you do not understand the deltas quickly.
· How much customization of material types took place? Are you even using the same materials types for indirect items? What about units of measure?
· Is the data owned by people moving to the new organization or will you have a brain drain?
Yes of course there are some great ETL tools that manage the technical conversion and integration of the master data as well as the transactional data. But they only work when the BUSINESS RULES are fully understood by those programing the tools.
It is not about just profiling the data and slamming it into the new system. You need to understand it first and no one person at the acquired company will understand it all.
Now go back to the earlier blog where we discussed the data diamond.
If you get the reference and master data right and you understand it at a very granular element-by-element level and you make it transparent to everyone in a controlled and standardized way then at least you will clearly know where are the detail devils.
Actually it s not so hard. The trick is to get everyone speaking the same language and documenting in the same way and to the same level of completeness.
Only by communicating in a controlled and standardized format with everyone can tracking the knowledge gaps be accomplished.
That’s where RuleBase 5.0 comes in. RB5 displays the complete business rule including all the technical metadata, allowed values with their preferred use, the enterprise rule along with all regional and business variations plus the quality control methods. RB5 also communicates the business rules owner and data accuracy owner for every element and much more, all in a standardized easy to digest format for the power users or business users. There is also a section to document the mapping rules where bolt-on management is critical to success. QueryBase governs the active and passive controls. Queries are not run from here of course, but the information regarding the governance of the upfront and monitoring controls (active and passive controls) are set in QueryBase.
Imagine if your rules and the acquired business’ rules could be preorganized BEFORE the closing of the deal and five minutes after closing the integration team had access to the business rules of both sides in a standardized presentation on their intranet? What if you knew how they set their controls (active/process control and passive/monitoring controls) of their data according to the open source ASUG Taxonomy?
If you did then on day one your team could begin the integration process without months of digging while under the intense integration stopwatch.
The process looks like this:
· Evaluate and implement a rules management system in a common format for each company independently – 2 weeks for RB5
o All existing rules that are documented anyplace in a structured way are now in RB5
o If you are doing this in excel, how are you maintaining the control and visibility for everyone that needs to see and touch it at exactly the proper time
· Gaps of what is not known can be evaluated and even baked into the deal if the gaps are large.
o Your business rule knowledge gap analysis, once based on a common format, is fast and quantitative
· Rule enrichment can take place directed by the needs of the acquiring company, without revealing details before they must be.
You can configure your rules repository to lay out the rules side by side, domain by domain, data element by data element so that everything is transparent at the right time for the right people. Integration success is predicated on the right people looking at the same rule the same way.
It takes less than two weeks to get a company’s rules on a secure server in RuleBase 5.0 if they are already in hand. Then its clear what you really know and where you have gaps.
Post-closing, the mind-share of critical employees not coming to the new organization decreases rapidly. Once their head is somewhere else, how will you ever unravel the rationale behind their SAP Master Data settings?
Will you have the time to set this up easily and securely in advance of your next acquisition’s closure? This degree of detail is an impossible priority in the heat of an acquisition “white room”.
Regardless of how you build your rules repository it must be able to separate the rules before closure and then to combine them quickly afterwards. The definitions for all rule attributes must be the same. This will mean somebody has to learn some new definitions so the definitions of the rule attributes must be in their face. Otherwise, misunderstandings will occur.
As RB5 is based on SharePoint 2010, once the ink is on the paper, connecting the data is trivial. This is essentially the same model you would use if you had multiple SAP instances in your current company. All rule attribute definitions are in “your face” and managed at the site level so modifications can be pushed to all.
Successful integration of an acquisition is information dependent. Its dependent not only on knowing what it needs to look like in the new system, but one must have a granular understanding of where its coming from and why it was structured the way it was.
The message is to start at the bottom of the data diamond and work up in a structured way and to make what you learn transparent all along the way.
We can help with that and RuleBase 5.0, our cloud based business rules accelerator can accelerate it.
Visit us at www.DataIntent.com
Richard A. King