Slow Business Intelligence

I hereby declare the foundation of the Slow Business Intelligence movement. Like the slow food movement of Italy and "langsamkeit" management of Germany, Slow BI advocates the slowing of life.

Many years ago, I read the book Die Entdeckung der Langsamkeit (The Discovery of Slowness) by Sten Nadolny. Essentially a fictional but fact-based novel of the life of 19th century British explorer (and former Governor of Tasmania) John Franklin who died while exploring the Northwest Passage in the Arctic. In the novel, Franklin's slowness triumphed in a Napoleonic naval battle when he shot a French sniper by "waiting, without panic, and carefully noting the angle at which the sniper's shots had been discharged." While those around him panic, he locates the sniper and kills him with a single shot.

I can hear the snorts of derision from my colleagues as they read this but bear with me as I think there may be important lessons in repudiating real-time BI (or more accurately, real-time decision making).

Still reading? OK, here's my logic:

The delivery of numbers quickly to decision makers is an often stated key benefit of BI investments. Words used by advocates often include the like of real-time, zero latency, agile and operational. Largely, this is all correct. It's a good capability for an organisation to invest in as it accelerates the speed it takes to get data and then act. Think about Richard Hackathorn's three types of latency:

• Data latency - the time taken to collect, reconcile and store data
• Analysis latency - the time taken to understand data and make it actionable information
• Action latency - the time taken to react to the information and take action.

So what about the middle step of this sequence? I'm talking about taking time to analyse data and arrive at better decisions. Better, quicker numbers are only worth something if they are used to make better decisions - not just any decision.

In the course of implementing analytic capabilities in several organisations I have often heard counter arguments to publishing numbers automatically out of the BI platform. A common one goes something like the following.

'You can't just give the Board figures automatically. They won't understand the context [i.e. I don't get the chance to 'spin' the message]. They will rush around making knee-jerk decisions either without consulting me, or at best causing me to spend valuable time explaining the figures."

I have often argued successfully that you need to develop trust in the numbers and if you achieve this then to only reason you want to prevent automatic (i.e. real-time) publication is because you see the current ability to spin the numbers as an important source of your power. This is a pretty difficult line to argue explicitly with your CEO. After all, most CEO's themselves like the idea of having better access to the numbers - perhaps for the same 'power' reasons? Generally a capable BI manager is able to 'win the day'.

Another counter argument is

"The numbers are too volatile to report hourly/daily/weekly. This volatility can convey misleading impressions about our business."

I have more sympathy for this and volatility can and does work this way in many businesses. For example a sales operation may on average result in $100 million of new business a week on average. The distribution however may feature sudden rises or falls each day. What is a manager to make of significant changes intra-week in this case?

Well I think there are two conclusions you can make that also support Slow BI:

1. Careful consideration needs to be given to how you present decision makers with such numbers. In this example, if you report a daily number then you may also need to give corresponding information such as whether-or-not the number is outside of the usual range of variance.
2. Analytic modeling can be performed to take into account intrinsic variances and give you the ability to predict what sudden changes will mean for the coming period (in this case the end of the week).

So there are circumstances when the delivery of 'raw' numbers can result in poor decisions. Just churning out the numbers as fast as you can each morning can do harm. The solution is to spend time analysing how the numbers will be used by decision makes under a range of scenarios. This is where Slow BI can make an important contribution: If you want to have realtime BI then you need to spend a lot of time analysing how the information will be used. I think that scenario planning can play a big role in ensuring that the right information is delivered to the right people at the right time and in the right form. I know Gartner talks about this as well.

Take your time analysing your business under all circumstances (this is Slow BI) will deliver you the insight necessary to support the predictive models that will cut through the daily 'fog of operations'. When these are in place, you then have the capability necessary to support successful and Fast BI.

So don't rush, but let's all support Slow BI by slowing down the analysis. We can only then develop the models to support Fast BI.

Comments

[Humi]

The biggest poelbrm I see this making, is the ability to see what percent of web traffic is still on dial-up. Which in the, not so great, great state of Michigan can still be 25% and much much higher depending on where you are targeting. This information is important when you are building sites for clients that have specific target audiences or when you are trying to get a client to change over to a more media rich website after years of hosting a website optimized for dial-up.

[Timothy]

The biggest polbrem I see this making, is the ability to see what percent of web traffic is still on dial-up. Which in the, not so great, great state of Michigan can still be 25% and much much higher depending on where you are targeting. This information is important when you are building sites for clients that have specific target audiences or when you are trying to get a client to change over to a more media rich website after years of hosting a website optimized for dial-up.

[mddwsmuyddu]

hJShTYqekCMJzF Vibram Fingers FuWZVXQMFeEiug

[bpc consultants]

This seems like an obvious factor, but I am always surprised that during initial kick off sessions with new clients it becomes very clear that they do not know what they want their solution to provide them with. More often than not, I find that customers know what they don't want not what they want.

[Thomas Malbaux]

Hi!

Great post and great idea/concept!
To me, this is a name on what "true" BI is :-)

I made a blog post on Cogoobi (french blog dealing with BI and enterprise environment) in order to promote your idea and help spread the word to the world ;-) : http://www.cogoobi.com/blog/2009/07/01/slow-business-intelligence-alias-decisionnel-raisonne

Thanks for your blog,
Thomas Malbaux
Cogoobi : www.cogoobi.com