Data: Would You Build a Bridge Without a Plan?


Written by:

Data flows through companies like blood through a body. It’s created by the transaction systems that capture sales, receive goods, watch processes, and process checks. It’s aggregated and passed on, moving through various processes before being presented to management and investors as The Truth.

Yet few companies can actually tell you how data gets from point A to point B, much less what happens to it along the way. Fewer still can tell you where data originates and what the definition of that data was when it was first put into the transaction systems. Of the ones that can do this, even fewer can do it across the entire enterprise.

What we are talking about here is “data architecture.” It means having definitions of the data you capture, the rules governing how it is aggregated, and maps showing where it resides. Not having a data architecture leads to confusion, added labor to combine, unlike data, nonspecific output, and generally added costs and time to get things done while the pieces are put together manually each time you need to answer a question. Having one means that SarBox and audits are straightforward, systems development is easier and cheaper, and you need many fewer accountants.

When I walk into a company, some of the things I look for that tell me right away about the state of its data include:

• Do all of the people charged with putting data into a system agree on the definition of that data? Take, for example, an inventory system where the salesperson will enter the amount sold; the supplies manager, the amount forecasted; and the fulfillment manager, the amount delivered.
• Do systems with similar functions replicate the way they identify and track key data, e.g., customer IDs?
• Can you create a “single view of the customer”? Do you know the total risk your company is exposed to, against any single counterparty, across all businesses in the company?
• Are there teams of accountants charged with creating end-of-period reports for lower-level businesses?
• How long does it take to close the books at the end of a quarter?
• Have you acquired a company and been told it would take 18 months to migrate a system, and after that was done been told it would take two more years to migrate the data?

Teams of accountants at departmental intersections and consolidation systems such as Hyperion and Cognos are bandaids covering up the underlying problem, i.e., you neglected to design the plan before building it and no one went back to do the work afterwards. More problematically, since you didn’t take the time to get the input right, your data is of questionable quality and your results are suspicious.

Establishing an Enterprise Data Architecture (EDA) retrospectively is as much a social engineering effort as a technical one. You will need to start at the top and get all business heads to agree what they are measuring and how it is defined, e.g., like Return on Capital, Sales, and COGS. Don’t laugh — you will likely find out that there is not agreement on how your key performance measures are defined and captured.

Once the business heads agree on their ultimate measures, the process becomes mostly mechanical, albeit tedious:

• Agree the data elements for each measure.
• Map where they come from. Rectify redundancies and conflicts, e.g., two systems with part numbers.
• Define with Audit’s approval the business rules by which data elements are rolled up to performance measures.
• Develop the technical architecture databases and systems that serve as the plumbing to move all this stuff around.

One nice outcome is that once you have done all the architecture work, business intelligence and reporting become very much easier. With an EDA, you can eschew complex systems like Hyperion and do most reporting in Excel. Instead of waiting for the analysts to pull and rationalize data, you can plug your spreadsheets right into the data engines and play “what if” as long as you like, with rapid feedback.

Data warehouses are a technology often used in the development of EDA and consolidated views. They make the job a bit easier because they require you to pour all the data into one place in order to work with it. The reality is that this is not always needed, whereas you will need to do the definitional work regardless of what technology you use to implement. It is quite possible to start with a small area and work through it before going on to the next one. It’s all about how long you are willing to tolerate the project for and the urgency of change.

Leave a Reply

Your email address will not be published. Required fields are marked *