Data warehouse technology is rarely associated with the glamorous world of mergers and acquisitions, usually the domain of sharp-suited investment bankers, late night board meetings, top lawyers and sometimes bizarre behaviour (see Barbarians at the Gate). But once the deal is signed, the party is over and the bankers and lawyers get their modest fees, what happens next? You can be sure that there is a hard-pressed person, possibly the CFO, who is put in charge of delivering all the vast synergy benefits that were promised by the chief executives to their shareholders. Do not envy this person. According to Deloitte: “Between 50-70% of mergers fail to deliver shareholder value after the deal.” Moreover, to emphasize just how important quick results are, according to Accenture: “For an acquirer expecting to reap $500 million in yearly cost savings from an M&A transaction, a one-month delay reduces the net present value of the deal by more than $150 million (assuming a 10 percent cost of capital). A seven-month delay costs nearly $1 billion in lost value, or approximately $3.5 million per day.”

Given this type of background, it is perhaps understandable that the first thought from the woefully underpaid consultants from the big systems integrators is not “let’s build a data warehouse then”. Yet understanding the cross-enterprise picture is immediately critical realizing benefits. For example, when HBOS merged, one of the key areas for quick savings was identified as procurement. Yet to just pick one of the existing procurement systems, switch off the other and convert all the data from one to the other was estimated at taking well over a year. Instead, what they did was to implement a packaged data warehouse, map the two sets of data from each bank, and in this way get a single view of the procurement spend across torganizationion without having to convert all the data in the underlying systems. This was achieved in just three months, giving an immediate view of post-merger procurement that allowed huge business savings to achieved. For more on this award-winning project click here.

In this way HBOS cleverly avoided a common trap, neatly summed up by McKinsey: “To succeed, a merger requires the smooth integration of IT systems and services, but the task often plunges the CFO responsible for ensuring the savings into uncharted territory. Confronted by an immediate technical challenge, companies typically choose one of two questionable routes. Some, fearing costs and complexity, never fully integrate their acquisition’s systems and thus gain few synergies. Others focus on the promise of synergy gains and improved performance but, in their haste, simply choose one system over another, often alienating both customers and employees.”

Other companies that have successfully used a data warehouse in this fashion are Shell, Intelsat, Unilever and Cadbury Schweppes. What is critical in such cases is the need for the warehouse to be able rapidly deployed, so that the business can see quick results. For those toiling away on an unrewarding data warehouse project, remember that next time your company buys another, a data warehouse could be a key part of the solution. Just ask HBOS.

There is an excellent article today by Ventana analyst Dave Waddington on how to tell if you have a master data management problem in your company. He sets out no fewer than 17 symptoms that would indicate that your master data is not fully under control. The beauty of this article is that it takes a business viewpoint and lists a series of different issues that will resonate with business executives; so many articles on MDM are written by people who have a pure technology problem, but Dave is that rare breed: someone is an expert in technology who worked for many years at Unilever, so has excellent business grasp. Dave also happens to have an unusually sharp mind.

His checklist is an excellent way of engaging with business people to try and put across the concepts of master data management in language that they will understand, rather than discussing hubs and metadata repositories. There has been much written on how difficult it is to justify master data initiatives, and yet if you run through this list of potential issues it should be possible to at least estimate a dollar cost associated with these problems, which is the first step to justifying a project that the business will support. The sorts of issues listed e.g.

“You struggle to determine total product sales to global customers”

is exactly the kind of problem that I recall the business struggling with when I worked at Shell. Shell sold products to Ford motor company, which of course in reality trades under multiple subsidiaries, and moreover different IT systems have different codes to describe “Ford”. This is not just an abstract issue: an account can be lost if the customer does not feel that you are able to deal with them consistently on a global basis, yet doing so is a major challenge for most companies. Working out the loss of revenue if a major global account defected to a rival should rapidly justify an MDM initiative.