Business Intelligence, 1923 style ...

Continuing on the theme from the last post - a press release from C3 Business Solutions (a Melbourne-based BI consultancy) that includes some statements from me has been in the "wild" for some time now. Thought it was worth reposting here:

http://www.abhishek-tiwari.com/2009/10/is-business-intelligence-too-sexy.html

The vendors do a great job of making everything they do seem exciting and new - that's their job, they have to sell software and that's a good way to do it I think. It plays into the general IT culture. However, there is a real danger we will ignore the lessons of the past if we focus uncritically on the new. I was reminded of this recently when I an amazing article - it was written in 1923 (before the great crash). It was published in the Harvard Business Review and it described the creation of a statistics department (providing information for management) at Eastman Kodak. Abstracting a little (the article referred to draftspeople - report designers, and statisticians - data managers), and substitute the name 'statistics department' for 'business intelligence competency centre' and the advice given could apply to a large company today. It really is a stunning article. Here is a quick summary of a selection of the main points in the paper. They might not all work in your organisation, but they represent some excellent ideas for organisation your BI efforts.

• The head of the BI department must report directly to the CEO. Not to Finance, Marketing or Information Technology. They need to have a direct line to the executive decision making processes; this is the only effective way for them to be able to develop processes and systems that will support the strategy of the organisation.
• If there are already BI groups in the organisation, perhaps groups located out in the business units (creating what today we would call data marts), don’t fight against them, and don’t replicate their efforts. They already will have a good understanding of their functional area and a good relationship with their clients. Allow the central team to (slowly) develop standards, and processes that those groups use. The central team can provide quality control, and also help to minimise areas of overlap and inconsistency. The central team can source data from those groups to allow for more “enterprise” views to be created.
• The BI team should be organised along the same functional lines as the business. This will allow members of to develop a deeper understanding of ‘their’ area of the business and to develop relationships with the people in that area.
• Have equal numbers of people in the BI team devoted to the design of processes of systems to source, transform and store data, and to design the reporting systems that users will actually interact with.

As you read the, remember the paper was written in 1923! The important lesson, I think, is to remember people have been attempting to provide managers with information they need for a long time. Quite a lot is understood about how and how not to develop BI systems them – yet I see a lot of the same mistakes being made. Teams that develop and implement systems that are successful, more often than not, include some people with experience. We should try hard to learn from the past – experience really does make a difference.

POD

Do we really build systems to improve decision making?

Just wrapping my mind around a new direction for a research project. Some of you know, I've been around the traps in the last little bit doing my schtick on interfaces. Of course everybody says the interface is important but I don't think we do a lot about it.Main message of my talk is that we don't devote enough effort or resources to the design of the interface. We just use the "orthodox" tables and charts provided by the vendors in our data displays (and the same for the navigation between views of data) - and many of them are not very good.

We just did a study where we can two different groups of people the same data - but one group got the data in "orthodox" BI charts, complete with 3D effects or gradient shading, not over the top but typical of BI systems today - and the other group an equivalent set of charts - very plain in their design (think the design principles of Tufte or Few). As we hypothesised, when asked questions about the data that required accurate analysis - the group that got the plain charts did much better than the group that got the sexier charts. Neat to see that this study and article that Trevor Clarke wrote for Computerworld after a chat with me has stirred up some debate.

Most BI systems provide users with a slicer dicer style interface in the hope that they will explore the information our systems give them access to - finding the "number" that solves their problem - just like in the demo's the vendors give. Sadly for that dream, in another study, we showed that a lot of people can't use pivot tables.

I think we have a problem. A serious one. Nigel Pendse thinks (based on his global survey) that the mean usage rate of a BI system is around 7 to 8%. That seems a little low to me - but its been a while since we collected that kind of data, and with web technologies (esp. in the last couple of years) meaning that more people have access to BI systems, the proportion using them might have fallen - so while 7-8% seems low, his data collection is good, I've got to think that he must be close to right. Even if he's not, the best take up rates we have seen in our case study work aren't very good.

In my presentations and writing I've been arguing that one main reason for this low usage rate is the interface we provide. I think that most BI systems have very similar interfaces (with few exceptions, the character of the main offerings from the BI vendors is identical). Those interfaces suit a few people, but not many. We need a major re-focus on the role and place of the interface if we are going to get better rates of usage of BI systems.

Now, there are a couple of underlying assumptions to those assertions. The first is that its desirable for lots of people to have access to a BI system, and to use that in their daily work. That may not be true. There have been studies that show that using decision support systems actually decreases decision performance - so the people using BI systems might actually be doing their organisations and themselves harm. I'm happy for the moment to believe in the value of BI systems, and leave the research on that one to other people.

The second assumption that I have been thinking about - is that people use BI system to help make decisions. What if that's not true? What if people use these systems for some other purpose. It could be (as would be predicted by cognitive artefacts like the confirmation bias) that our systems are to build a case to convince ourselves and others that a decision already made is correct?

If that's the case, no wonder we are putting 3d funnel charts in our systems - in response to user demand. The aim of the display of data would be to impress people, show them how clever we are, how the data supports our strategy (better obscure the data a bit just in-case it doesn't). Im exaggerating the case a little (of course), but it is interesting to think about - and not to hard I think to design a research instrument that can be used to go out and find out what BI systems are actually being used for: decision making or decision justification?

POD

:-( back to marking exam papers.

Timo Elliott's demonstration dashboard

Neat little demo put together by Timo Elliott (@timoelliott) from Business Objects using their Xcelcius product as a - think I'm inventing words here - mashupable object. He plonked the dashboard he made, on his blog with a number of controls that allow you - YouTube style - to share via email, twitter or cut and past as an object in html. This kind of functionality will get even easier when HTML 5 gains traction, but as Timo shows its do-able right now. Doesn't matter that it's a dashboard, the idea could work with any report or report part. I really like the ability to click to expand to full-screen view - just link clicking on a web page section in iPhone's Safari, a visual drill-down (or up).

So with a click on Timo's blog and a paste, here is Timo's demo Dashboard (his blog has some context that's fun to read too). To start with our blogger hosted blog isn't coping with the width of the element so well, but Timo kindly set a new code block that does fit - Thanks Timo.

An experiment on Twitter

For a long time a few of us, and not just at Monash, have wondered how a real time text feed - perhaps in RSS format - might be applied to BI systems. Now that social networking sites like Facebook/Twitter/Friendfeed exist and are becoming widely used the idea has a bit more traction with people we talk too - nothing like concrete experience to help people understand what you are talking about.

I've just set up a Twitter account that I'm going to use to develop a prototype system to demonstrate how a "feed" of text updates might be useful in a BI context. This feed (@monashbiindex) will contain updates and observations on data collected as part of out BI Index project.

Right now, all it will report on is a single number - the number of on-line job ads placed in Australia for positions related to business intelligence and data warehousing. I've been collecting this number (off and on) since 2005. It's quite interesting, there are weekly wobbles (up on Thursday and Friday) and significant seasonal variations too (up before and after the end of the financial year - way down in January). The analysis we are doing will soon expand (just like any dimensional data set) to include more detail like locations, industry sectors, job categories and the like. Later we might extend it to other countries but right now we'll stick to Australia.

So, I've got a nice little automated app, that will at 9:00 Am each morning go to seek.com.au, do a search and grab from the resulting page the total number of jobs. It records that number in a database - along with the data and time. Then a 'reporting' app fires up and does a simple day by day comparison of the number to the previous days and posts a tweet. Much better than the Excel macro's I've been messing with since 2005! Once I'm happy with how that's working, I'll extend the range of topics tweeted on to include a wider range of temporal tweets (end of week, end of month, end of season summaries), link the tweet to reports (no 3D donut charts I promise) and start to build agent style data monitors that look for exceptions, to demonstrate how a twitter style feed might be used for reporting the results of data mining algorithms.

POD

P.S. Oh, later the "Index" will include more measures of health than job ads. We are planning a regular survey of the "industry" and also a stock market index - something again I started a long time ago.

P.P.S The BI Job index is based on the number of jobs that match the search terms "Business Intelligence" or "Data Warehous" that are listed on www.seek.com.au. The index is expressed on points based on a ratio of the number of jobs to the number on the day the index started 23/10/2005. On that day there were 349 jobs - 100 index points.

Light at the end of the tunnel

Rob and I and co. bloggers have been more than a little quiet as - despite our best intentions - we got run over by our teaching work load in semester 1. Semester 1 is about to end so we'll get back to some BI blogging very soon.

Worth mentioning that we'll also be starting a BI podcast (not the same as the ones we have for our units). This will feature interviews with BI "thinkers" from Melbourne and around the world, as well as the occasional talk from members of the Centre. We will start with a couple of talks from me - the first will be a "briefing" on the decision support industry I gave to Prof. Arnott's FIT5094 class a fortnight ago, and my closing keynote at the Mastering Business Objects conference in Sydney last week. We hope to have a new posting in the podcast stream every two weeks. If you have any ideas about people you'd like to interview, or topics you'd like us to cover, please let us know.

POD

Cranky Geek - John Dvorak - takes huge swipe at spreadsheets, BI and accountants.

Lots of other things I want to and should post at the moment, but I couldn't let this slip. An article by John Dvorak that is kicking up quite a storm. Love John Dvorak. Always worth reading and listening. He's often wrong (and very wrong), but always there is something to what he says. Anyway, he is an article about the 30th anniversary of the spreadsheet.

He's nuts of course (in a good way, and that's what I like about him), but he makes a point. We have all this wonderful what-if analysis, information at our figure-tips, enterprise Bi all over the place - so how come we aren't making better decisions? Of course, the spreadsheet isn't to blame but its a fun read.

The 30th Anniversary of the (No Good) Spreadsheet App

POD

Scoble on BI Panorama/Google style

Thought it was worth drawing your attention to a recent video post by Robert Scoble.

The story of 2009? Enterprise disruption?

It's not particularly critical - really just a PR puff piece - it covers the tool's Panorama have been creating in partnership with Google. Panorama are a company to watch, Novaview - their core offering - is excellent, and they are the company that sold Microsoft the technology that became Analysis Services.

However, I'm underwhelmed by the tools they have created with Google so far, but its a start I guess, into a potentially interesting shift of BI services in the 'cloud'.

Have a watch, I'd be interested in your thoughts. I'll post a little later on why I think this in general is a big deal, but this particular tool isn't.

POD