Because I'm going to forget the points I'm thinking this morning remind me to talk about this stuff when we speak in a month or so time:

\1 Don't just copy their tables and expect them to navigate the front-end, store data in a way that relates to how they work with the data (if it says "Risks" in their UI, then they expect to see a 'table' called Risks in their reporting) and it's often much better to de-normalise lots of inputs into the one way that reflects how they think about the data.

\2 Don't try and understand their data or to apply any surprises to the data. It must be predictable. Most people don't comprehend stats properly and if you aggregate or do anything that they cannot compare to their raw data and immediately comprehend then they reject the chart/report. It's been more successful and easier to chart dumb data in a predictable way than it is to try and understand the data and chart it in an intelligent way. Leave domain specific problems unless that domain is lucrative enough and you know it well enough (risk management fits in here).

\3 Storage of data is interesting. Storing snapshots gives trends and trends are valuable, on the other hand storing snapshots is expensive (multiple copies of data) and so a delta is preferred, but deltas are expensive. Alternatively, for low maturity and 'free' accounts your could just do 'Now' data and nothing else as it has the lowest storage and processing requirements.

\4 Most business data is still in Excel within the SME world. Tech startups aside (where most stuff is in databases and Google Docs), just cleaning up the Excel so that it's usable is fun on it's own.

\5 Whilst everyone knows you can't chart TEXT fields, good reporting leads to the asking of more questions as one question begets another. Eventually this leads to root cause analysis and drilling down to the few exceptions. When they finally get down to knowing the n items that are the cause they really do want to see that full data in the one place (the reports). Unfortunately this means cleaning text as you wouldn't believe the weird and wonderful ways that people find to enter text (if it can be written in PowerPoint, pasted into Word and copied into whatever datastore that they are using - it will be).

\6 Relationships between data. The more these can be understood the better. Most places aren't good at this, tools which can analyse even just the names of fields and suggest possible relationships are good things. Using these relationships to build filters and drill-downs is really cool stuff that sells it easy.

\7 Tufte. Go read everything and excel at producing the cleanest and easiest to read diagrams and charts. Everyone wants their presentation to look cool, everyone wants to look at a sexy dashboard and understand the problem... the whole world is tired of Excel charting, but Google charting is also ugly... make the charts pretty as this the bit the user sees most of the time and is what they will most readily pay for.

Those are more talking points... an immediate brain dump. I'll try and give you a more structured brain dump in a month or so.

There are only a few key problems:

1) Aggregating multiple stores of data to create the high level reports.

2) Relationships between data.

3) Deciding on how to store stuff so you can trend.

4) Making it look good.