Summary: The information engineer and the businessman need to have common agreement on the purpose of the enterprise data warehouse. Once it’s understood, IT must make it happen. The enterprise data warehouse should be able to perform profitability analysis.
On the part of the information engineer, it reveals an insufficiently specific appreciation of the pragmatic goals and functional mechanics of the business that the engineer serves. Of course, the goal of the EDW is to help the business make better-informed decisions. That should be a given. But are all decisions equal? Furthermore, as engineers in the service of the business, let’s camp out a bit on the businessman’s statement of purpose, i.e., “To make more money.” What should we as practitioners do with that? Given the stress and complexity of implementing an EDW, it is tempting to brush off the point – after all, everything about a business is (or should be) ultimately geared toward earning a profit. But if we tune out this point as excess noise owing simply to its comprehensive and ubiquitous nature, we miss the tremendous bottom-line value we can deliver by pondering the point and taking appropriate action. Perhaps this assertion is not excess noise, but in fact a governing design principle, and arguably the most important design principle for the EDW itself; that is to say, the ability to perform profitability analysis needs to be comprehensively, ubiquitously and schematically embedded in the EDW. In other words, the right response for information engineers is not, “So what?” but, “How can I make that happen?”
To make it happen, let’s start by addressing the following: what do we have already, and what are we missing to get the job done? Those of us with some experience around various enterprise resource planning (ERP) systems know that these systems do a good job of linking together financial transactions (accounting records) with their associated operational transactions (purchase orders, deliveries, inventory movements, invoices, etc.) such that there is a join path back to the data points we need to determine the actual cost of acquiring a product from a supplier. The ERP may even do a good job capturing manufacturing and inventory holding costs. Furthermore, the ERP may drop these valuable bits of financial data right onto the operational transactions themselves, greatly simplifying our ability to do ubiquitous gross margin reporting within the EDW. We can build line-item fact tables right off our order, shipping and invoice records with the two perfectly additive measures we need (revenue and cost) handed to us directly out of the ERP with little to no transformation required.
The solution should not merely capture those numbers, but should also expose the drivers behind them. It’s not really sufficient or defensible to show that Customer A is a sugar daddy while Customer B is dead weight without providing the data that supports those conclusions.
If the problems or the promise of a solution described herein resonate, stay tuned! This series will continue in DM Direct on June 8, June 15 and June 22. Go to www.dmreview.com/newsletter if you are not already a subscriber.