Right, so I’m finally taking a lunchtime to write up about the SUGUK Meeting in London last Thursday. The topic was Business Intelligence in SharePoint 2010, and the main presentation was by Ben Robb, with a discussion afterwards. It covered a lot of technologies – there are a lot you can use – but the bit that I think will be interesting is the methodology and management.

Ben started by discussing the why of BI, and the tools available. There are quite a lot – SQL Reporting Services, Excel Services, Business Data Catalog (sorry, Business Connectivity Services now!), KPIs in SharePoint.

The crux of this point was that ultimately, you want to empower business users to report on data they think is relevant. You don’t want to have to employ developers to build these things – they don’t know the data, or what figures are important. It’s a fair point. The sidebar to that is that you do need technical staff to get the data into your ‘cube’ in the first place. In other words, data has to be drawn into a central location and structured there, and then end users can generate the metrics they want from that.

His demo was, frankly, a bit of a stunner. Drilling down through what was clearly a large data-set, sorting and filtering millions of rows to show off PowerPivot (no, I still don’t really get what it is). The Decomposition Tree was very neat. Definite ‘wow’ factor, with a bit of a message of ‘just slap a few web parts on, and it works’.

And that last point was what stuck out for me. Yes, the demo was very impressive. Plenty of charts, filtering, drilling down, publishing to Excel, Bing maps. Slapping web parts on the page looked very simple. But it all relies on you having put your data into an OLAP cube. Don’t know what one of those is? No, me neither (and I was very glad when Chris O’Brien asked what they were – I was assuming everyone else knew!)

When we then started talking about how to draw in that data, the message really became one of “Plan, Plan, Be methodical and Take Your Time”. That rather sits at odds with the demo. Building your data model does need to be done carefully, but it’s not visible, it’s not sexy, and it’s not interesting to management/end users. They just want pretty charts. So you’ve got this tension between the user interface end being “Fast, Easy, POW – Done” and the back end being “Careful, Plan, Gently”. I’m worried that Microsoft’s marketing – and salesmen throughout the industry – will set an expectation which can’t be easily met.

Of course, if you’ve already got a nice OLAP cube to use, that’s not an issue. But the other elephant in the room was that most companies don’t have that. Reporting is an afterthought. At best you get Requests for Tender that say you ‘must be able to produce reports’, but the dialog then goes:

“Report on what?”

“Um, anything we want”

Sometimes reporting isn’t mentioned at all. And when there is reporting, what is the most ubiquitous reporting tool around? Excel Spreadsheets. Every organisation has lots invested in Excel spreadsheets for reporting. And it’s all very well to say “Ah-ha! Excel Services!” – but now tell me how to deal with linked spreadsheets? Or VBA Macros? They always make an appearance, and it’s a phenomenally hard thing to deal with short of ‘right, let’s start again with a different technology’, which is hard to do without a feeling of reinventing the wheel. That’s not to say that I don’t think it should be done – but it’s a tough sell.

All of which then leads round the methodology of this, and the change management – which was a bit outside what could be covered in the meeting. This is where things will get interesting, though – controlling the vision of what can be achieved, and then managing the changes to the existing reporting strategy. Especially as people do like (or maybe just ‘know’) Excel. But that’s for later post – or maybe just someone who knows more.