Design for Information

4 08 2009

All to often reports are designed to provide data, not information.  There are charts and tables with little intrepretation, or description.  While I am not great fan of PowerPoint, it can often make up for Enterprise BI limitations.  We can call out certain areas within the charts and graphs, as well as add the commentary to help us communicate our point.

A safe assumption is that the person reading the report will not have the same understanding of the material as the report designer, or analyst.  It is then our job to make sure that the report communicates the point clearly.  The last thing you want is to hear “what are you trying to show me?”

Below is a good example of presenting data, while not telling us much.  Here we see that he/she has a few fans that are frequent contributors, and that tweet volume picks up around the lunch hour.  There is not much variation for the days of the week, with a little drop off for the weekend.  August is also the most popular month.

twitter2008-1

What would be helpful to know is why this data is important to us.  What perhaps would be the most important is to know the subject material, so we could do things like tweet just before lunch as that seems to be the most popular time to inspire reaction.  Or that August tweets were up due to an embarassing grammatical error.

As we are designing reports, make sure that the information has a purpose.  Most specifically, know the audience and know the potential actions the information is going to inspire.





Data Warehouse Design

24 06 2009

One of the main problems with Data Warehouses is that they are designed to answer any question.  The problem is that they usually fail to answer the one someone is asking.  DWs are usually good for referencial information – meaning I can answer questions like “how many customers do we have that have spent over $100,000” or “which customers bought the blue widget.”

There are a number of points of failure that hamper DW projects:

  • They are usually complex and very costly
  • The business changes (regions, product lines, sales heirarchies, etc) in the middle of the process
  • The end use is not well defined
  • Lack of analytical skill and knowledge of data structure in the business users to get the right data
  • The end result is too complex for the users to understand where to go to get the right information
  • No one tells the organization “thou shalt” use the data warehouse – so people get data from all different sources making a common version of the truth difficult to get to
  • There are often no rules of engagement for how to use the environment, or data in general

If organizations only use 6-10% of the data they collect, how do you design the DW for greater adoption?

For starters, understand the common business questions and the potential levers that can be pulled. For example, one of the areas that always surprises me is the lack of information around the success of marketing campaigns. Marketing campaigns and price are really the only levers we can pull in the short term to increase revenues. What we often fall back to is the sales whip – where we put more pressure on the sales team to perform. This is a strategy of hope (which is not a recognized as a successful strategy practice). We apply the pressure without providing much in the terms of support.

Instead let’s say we are ending the 3rd quarter and our numbers are a little behind and the pipeline is not as strong as we would like.  We know we have some time, but the programs have to be very tactical to find low hanging fruit. Instead of reviewing the potential marketing programs or trying something new, we cross our fingers and yell at the sales team. We could cull the DW to find large groups of customers who had not bought specific groups of products and offer incentives for them to buy.  We could identify the groups/verticals of customers with the shortest sales cycle and build a promotion and program for them as well.

Yet why do we not do this…we typically lack the information in a format we can use in a timely manner.

So if we design the data warehouse (or perhaps data marts) around specific business levers we stand a better chance of answering the one question we need. We just might trigger some very interesting questions about our business.