In the first post of this series I introduced you to three personas used to develop our business intelligence strategy. Based on these personas and our roadmap, our early stage business intelligence solution employed a traditional reporting framework. We created a tool that would allow access to every field in the application, including user defined fields. We also wanted it to be completely self-service, meaning easy to use, harmless, and data-complete.
Harmless? Yes, harmless. The data must be read-only. I think the desire to merge reporting and editing has been largely driven by spreadsheet type interfaces. It makes sense in some situations, but not in an environment where casual users have access. In a self-service mode the users’ data security profile must automatically apply to any report they create. If it doesn’t, then either one of two things happen:
1.) Your security is compromised because users can run a report to view information they shouldn’t have access to,
2.) Or some other entity must create reports on behalf of the users in order to restrict access, negating the value of self-service.
The requirements – easy to use, harmless, data complete – ended up being tougher to find than we expected. It turns out that most commercial products do a pretty poor job at all three. The sophistication and power has turned them into complex tools that require training, and often lots of it to become proficient. Don’t believe me? Check out the number of classes and books available. As for harmless, most of the commercial solutions have rich security capabilities, but none worked elegantly in a SaaS environment. Their security models were built on the assumption that we know all of our customers’ roles and permissions. With a known data model any reporting tool works well. But what about a constantly evolving one that is partially controlled by the end-users? I couldn’t find a third party application that could handle it without manual intervention.
In our software we give our customers and partners the keys to the kingdom, if you will. Bucking the conventional wisdom of the time, we opted to build our own reporting tool. We were willing to sacrifice some of the power of the commercial tools for a few reasons:
* A general-purpose reporting tool made little sense in a specific-purpose application.
* Most users stick to the basic functionality, and opt for simplicity over power.
* A seamless experience from the application to reporting better serves our users.
* Finally, we knew we could and would build what our users needed.
That brings us back to personas. Today, I’d like to introduce you to a new set of personas:
Excelsior – “I Just Want to Use This Spreadsheet” – This persona has built up a process for getting data into Excel, beating the data into graphical and/or tabular submission, and interpreting those results. She has learned the ins and outs of Excel and wants to emulate her current process.
Horus – “I Need the Big Picture.” – This persona doesn’t like to get caught up in the weeds. He needs to be able to roll up organizational entities such as business units, cost centers, and sites for that big picture understanding and to see overarching patterns.
Hipster – “How Have We Changed?” – This persona is also big picture, but sliced across time. She is focused on changes and more specifically, improvement of key areas. She is on the lookout for indicators that portend good or bad for the organization.
These three personas have benefited from our business intelligence functionality’s second evolution. We turned to functionality targeted toward what the “Excel crowd” – people who are savvy about data and have strong opinions about how to see it. With an initial foundation built on readily available data, we simply needed to add some more processing capabilities to further manipulate that data in different forms.
In my next post, I’ll talk more about how we expanded our traditional reporting platform to address the needs of “Excel crowd”, as well as introduce the third trio of personas.