I wonder if Neil knows just how loaded his question: "What's the reporting issue in your view?" really is. From my perspective. Those who read AccountingWEB may know I've acquired the reputation as the semi-resident Spreadsheet Rottweiller. Those that got John Stokdyk's email this week certainly know that!
I won't rehearse the arguments here except to say when a finance house overpays £135 million on a mortgage book because of spreadsheet error, then I rest my case - again.
Most software vendors have consistently let down their customers by failing to provide a proper reporting solution. They stop at recording the transaction. They're not lazy but reporting is difficult to code. But you already know that from the amount of time you waste building spreadsheets you pray are error free (Howlett - shut up - you promised not to do it and you're off.)
I believe Sage has missed huge opportunities to make a difference in its acquisition sprees. I also believe the choices available to OMB/SME businesses are abysmal. Hence the spreadsheet rules by default. While professionals are forced to use specialist, EXPENSIVE products like IRIS, Viztopia and the rest.
I make no secret of the fact that I believe the SaaS route offers real possibilities to change that dynamic by offering a genuine win-win-win. You'll be hearing more about this from a live customer - soon.
'Nuff said - feel free to discuss.



1.It's not that I don't like spreadsheets - in the right hands they're useful. But it isn't a reporting tool - it's a GP toolbox.
2.It is the lack of understanding around the programmatic nature of the tool that is so worrying
3.Excel 12 - OK - so...errrr...I thought that was what ODBC was supposed to do but let's see:
a. I've got to map to the database - hmmm...no work reduction there
b. I've gotta run program checks etc etc
c. I'm still screwed
Excel 12 doesn't fundamentally change a thing then, right? It's a desktop toolkit trying to be an Internet app - not the same thing?
A solution might be something akin to wikiCalc which spits native XML coupled to XML spat out through SaaS products. These new offerings should be able to speak directly to one another and not have to go through a transalation process. OK, someone's got to programmatically deal with XML semantics (a+b above) but sooner or later that has to happen anyway.
The difference is that if someone takes this by the scruff of the neck then you could end up with a properly transportable schema rather than having to reinvent the wheel, every time there is a change or every time you move form one product to another.
BASDA and others have looked at this scenario and said 'nah' too hard but hey - could be for industry specific apps. We've already got things like BEPL XBRL and so on flaoting around so people know it's an issue.
But the other problem is that MSFT itself isn't sure that Excel over the wire is desirable. This is because you wouldn't use Excel to do analytics over the wire. It doesn't make sense in MSFTs world. I can see that.
I can also envisage buying XML calculation or presentation components that fit into the spreadsheet mould but which again are transportable so you only buy that functionality you need for as long as you need it in a particular analytical scenario and can carry it around with you from product to product.
Finally, what you don't see is that in taking the position it is on the OS stuff, MSFT is at risk of fracturing its franchise. That's a much more serious issue but it has direct relevance.
I've raised these points with MSFT at a pretty senior level. I'm waiting to see how they approach it.
In the meantime, you're stuck with a difficult and error prone series of processes like: enter in Sage>run Sage native reports>create Sage specific reports>spit out Sage CSV>import to Excel>use some format>present>review.
Incredibly cumbersome.
Posted by: dahowlett | December 15, 2005 at 11:19 AM
Ok, so we know you don't like spreadsheets. Neither do I. However Microsoft's .NET roadmap has Excel as the premier reporting tool and with two way capability as well. Updates directly to the database from an Excel spreadsheet - the stuff of nightmares.
So having aired the issue, what out there represents the seed of the solution, in your view? What would you like to see?
Posted by: Neil Wilson | December 15, 2005 at 10:23 AM