This is really good. Simple perhaps, but I'm guessing it's just early.
When I'm done with my MSc project you guys should take a look. It loads in near real-time (within seconds of a change) SharePoint data into a SQL database in a form that allows for the differently structured data to be reported on. It's only a few weeks away from being written up but I'm going to be putting the code out there for anyone to use once it's done.
Anyhow an issue that you're going to have is data storage.
Ignoring the fact that enterprises will be very reticent to letting you have data, SMEs in Europe are going to be very reticent to let that data leave the legal boundary of Europe. There are lots of good laws in Europe that protects data so long as it's kept in Europe.
You should look at putting in place something that allows you to offer Europe only hosting of the data to counter that, a silo for a major legal domain.
That's the big problem I see, but in your favour not all companies will think of it (though enough will).
Another question I would have is: Storage is cheap but ongoing cloud storage is still expensive (relative to buying a couple of hard drives and a cheap machine vs you holding the data for a couple of years). Have you not thought of just offering the charting as a product companies can install locally? This also solves the legal boundary problem of data protection.
Also you should think of adding KPI charts that can be embedded into Word and PowerPoint docs. Little smart widget things that go and get the chart data from you as it changes.
We will definitely add the ability to embed charts. It is all done in javascript which means it can be viewed pretty much everywhere.
We are looking into a Firewall version much like Github has for big businesses, but we really want to build the product with the small and medium business in mind.
Definitely stay tuned as we iterate. There is a lot more to come!
Cool. If you want any pointers let me know. I've basically built this twice before for medium and large enterprises. Unfortunately the company I worked for didn't appreciate fully the general applicability of the product (they thought it only solved project management problems, only 1 of our customers fully understood it solved nearly all of their "first 80%" reporting needs), but it did allow data to be fetched from multiple backends (Excel, MySQL, SQL Server, Oracle, etc) and to be fed into one database that added snapshots over time (configurable granularity from 1 day up to anything).
To companies that had trouble getting their data together the sale was always easy as they appreciated the problem. But most didn't appreciate that problem so it's hard to sell on that basis.
The real value and the whizz-bang that sold it to most companies was how I presented the charts. I used SharePoint to create chart blocks, and these could be connected to other charts via a very simple connection framework.
Example: Drag one chart onto the page, configure it to look at some data. Drag another chart onto the page and configure it to look at some other data. Drag a filter onto the page and connect Chart A to Chart B via the filter and specify that Chart B's data is restricted to the selected series in Chart A.
What you then get is a multi-level drill-down and sets of building blocks that allow you to build any dashboard you want and to have pages that show really rich related charts.
Unfortunately the company I worked for only ever considered this as a project management solution even though it worked for all structured data from any source.
My latest toy (in my spare time) is how to do the same thing for semi-structured data and data that may be structured but not consistently. This is just because what I saw as constraints to reporting within larger companies wasn't the lack of data, but the lack of common edges that could power reporting.
Anyhow, I'll open source my work on SharePoint in a month or so, feel free to use whatever you need. It shows how to fetch data from multiple SharePoint systems in an eventual consistent way. And it also allows for storing data from multiple tables in the same few tables whatever the structure whilst being extremely efficient at aggregated reporting queries.
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.
When I'm done with my MSc project you guys should take a look. It loads in near real-time (within seconds of a change) SharePoint data into a SQL database in a form that allows for the differently structured data to be reported on. It's only a few weeks away from being written up but I'm going to be putting the code out there for anyone to use once it's done.
Anyhow an issue that you're going to have is data storage.
Ignoring the fact that enterprises will be very reticent to letting you have data, SMEs in Europe are going to be very reticent to let that data leave the legal boundary of Europe. There are lots of good laws in Europe that protects data so long as it's kept in Europe.
You should look at putting in place something that allows you to offer Europe only hosting of the data to counter that, a silo for a major legal domain.
That's the big problem I see, but in your favour not all companies will think of it (though enough will).
Another question I would have is: Storage is cheap but ongoing cloud storage is still expensive (relative to buying a couple of hard drives and a cheap machine vs you holding the data for a couple of years). Have you not thought of just offering the charting as a product companies can install locally? This also solves the legal boundary problem of data protection.
Also you should think of adding KPI charts that can be embedded into Word and PowerPoint docs. Little smart widget things that go and get the chart data from you as it changes.