Comments on: False-positive alerts, non-collaborative BI, inaccurate metrics, and what to do about them

By: Confluence: Analysis (Business Intelligence)

Confluence: Analysis (Business Intelligence) — Tue, 25 Oct 2011 01:44:00 +0000

Monitoring…

Goals P1 Collect status and alerts from multiple source systems (tickers, data quality, automation,etc.) in one place and know whether a part of the system is broken sooner. Institute a better way to communicate such issues,……

By: Curt Monash

Curt Monash — Tue, 27 Jul 2010 01:15:03 +0000

John,

I’m thinking of something much more granular than that. Chorus can be restricted to the model Wayne was suggesting — let your specialists do a better job of considering alternate possibilities. I want line managers to be allowed to think for themselves as well.

By: John M. Wildenthal

John M. Wildenthal — Mon, 26 Jul 2010 20:38:27 +0000

The plurality of definitions makes me think of Chorus’ support for multiple marts. Is this sort of functionality part of what Greenplum is targeting? Each group getting to define its metrics differently in its own virtual mart and still access the official definition as well?

By: Curt Monash

Curt Monash — Mon, 26 Jul 2010 14:17:46 +0000

Wayne,

But it’s not necessarily as simple as a threshold. A compound expression/condition/test may be what’s needed to avert false positives.

As for preventing people from ever discussing alternate forms of metrics with each other — that’s way too Big Brotherish for my tastes …

By: Wayne Eckerson

Wayne Eckerson — Mon, 26 Jul 2010 14:05:07 +0000

The best way to control false positives is to allow end-users to set the alert thresholds themselves. That’s a better adaptive system than any artificial intelligence-based system can deliver.

In terms of metrics, you need standard metrics so everyone knows what’s going on (e.g. customer profitability) and you don’t have a tower of Babel. But around the metrics (and even within them), power users should be able to explore the business activity behind the metrics to see what new information and insights they can glean.

So metrics are for casual users and running the business; explorative analytics is for power users to seek insights or clarification around the metrics. These are wholly compatible.

One thing you don’t want to do is create multiple versions of metrics for enterprise consumption…. chaos.

By: Curt Monash

Curt Monash — Mon, 26 Jul 2010 08:30:57 +0000

Justin,

I’d say the server side model is probably the BI tool knows how to do everything itself, but can also delegate to DBMS and/or ETL when that makes sense. This could mean a whole new level of cooperation between BI and DBMS technology.

Naturally, they’d be more prone to do this with DBMS vendors that:

A. They own
B. Have high market ahare

all else being equal – not that all else would be equal …

By: Justin Hyde

Justin Hyde — Mon, 26 Jul 2010 07:52:54 +0000

Good article. I’d suggest that the metrics must be dimensional and might be thought of as services, i.e. Can be subscribed to to create derived metrics. This metric engine / designer would require that the 3 bi tools: etl, query, report, are merged into a single tool as the usage of the metric might dictate that it needed to be precalculated during the equivalent of the etl run.