The Best SaaS Reporting Tool is No SaaS Reporting Tool
Almost every one of my clients depends on some kind of SaaS solution for some part of their operation.
Whether it’s payroll, accounting or electronic records, the data is controlled by their vendor of choice.
This is all well and good for basic processing. But too often, it doesn’t work well when it comes time to actually understand the data or (even more so) combine the data with data from other systems.
Why? Because if my clients weren’t careful when they chose a solution, they’re probably now reliant on the SaaS reporting tool provided by the application if they need to create any custom queries or reports. Or worse, they have to rely on the reports the vendor provides.
And this leads to problems.
Recently, I’ve had to get data out of Ultimate Software’s payroll, time and attendance software solutions.
I have nothing against these solutions. My client seems generally happy with them.
Indeed, from a reporting perspective, they’re better than many other solutions I’ve worked with. At least the reporting tools are functional and we can (with some help from support) find the data we need. I’ve been in other situations where the tools provided just didn’t work or just didn’t exist.
Still, these solutions are far from ideal for the following reasons:
1. Every reporting tool has a learning curve
I work with data for a living. And while my focus is currently backend data and data architecture, my team and I have worked with a wide variety of reporting tools, such as Crystal Reports, SSRS, Business Objects, Oracle Discoverer, Oracle Business Intelligence, and Qlik (not to mention the green screen tools on the AS400)… just to name a few.
As a result of this experience, learning new reporting tools isn’t all that hard. It’s what I do. But even so, I have way more fluency in tools that I’ve used over and over again when compared to tools I’ve worked with only a few times.
So imagine what it’s like for folks who don’t have this background to draw from!
In this particular case, Ultimate provides Cognos for reporting writing. Cognos is a major BI tool, no doubt about that. However, only one person in my client’s entire organization has any knowledge of how it works. Making matters worse, Ultimate provides DIFFERENT versions of Cognos for its different applications — and this person’s fluency was limited to one version. So, when I needed data from that other application, I was on my own.
Every customer I have wants to standardize on as few tools as possible. When you have to use the tool that each vendor has chosen, standardization becomes that much harder.
2. You never get all the data
I’m all for developing abstraction layers because most report developers aren’t SQL developers. Even most solid data analysts aren’t SQL developers.
But when you ARE a SQL person, it’s incredibly frustrating to dig around with models that only give you what someone else thought would be useful. You can never get all the data you really want. Or you wind up having to create several reports so that you could combine things the way you want.
If you had all your data, even in its raw form, you would just need a good SQL person (even if only for one project) to get what you need.
3. Your data ends up in different silos
Let’s say in the Ultimate case that we have a payroll report we like. What if we want to combine that data with time and attendance data? As these are two different products, we can’t do it. Instead, we have to create separate reports and dump the output into Excel to combine.
And similarly, if we want to reconcile payroll detail with our Microsoft GP ledger, we also have no choice but to push into Excel — and off to the races we go. (Or, as we did, take all our data into a central SQL Server repository and work from there.)
As you can probably gather, this is why I spend a lot of my time dumping reports into Excel and pushing them into SQL Server.
Ultimately, that’s not the answer.
Rather, it would be great if customers demanded full access to their data when they first sign on with the vendor. This could be access to a full set that’s hosted by the software company or (even better) a full set that can be restored into a database the customer controls.
The point is, this should be a major discussion point before the software contract agreement is ever signed.
Has your company ever signed up for a SaaS and realized — too late — that the data wasn’t easily available?