Timely access - part 2 of 4

So what is timeliness? Again this a purposely vague term. I suppose that "knowing something when you need to know it" is timely; and the sooner you know something the more options you have to react to the information. But in reality this depends on the nature of the information - looking at last month's sales is less time critical than making an assessment that more agents need to be brought on-line in a call centre to cope with a sudden surge in calls

The lag between an event and it being first reported in a BI system (either through conventional reports or a BI dashboard) is the sum of many discrete time intervals: the time to capture the event, the propagation time to the data warehouse, the time to validate and load the data, the time to aggregate it, and the time for the report to run. But BI users tend to have a notion the lag is just the period between firing a query off in the query tool and the results appearing; of course for historical reporting (and a large amount of BI is just that) this idea is not far from the truth.

So we now have two kinds of timeliness: whether the information is available in the BI system within an acceptable delay from an event occurring, and whether actionable information can be delivered from the system to the user quickly enough to satisfy the user.