Self-Service Reporting is Hardly Selfish

Submitted on: Thu, 08.07.2014 06:06pm - Gary Owen |

If you want something done right, do it yourself as the old saying goes. When it comes to reporting, this statement is definitely true. Unfortunately, in the world of reporting, doing something right sometimes requires many different skillsets and support to get the job done. Doing it yourself rarely means doing it by yourself.

Let's look at an example of what I mean.   

Nancy's Business Needs
When it comes to reporting, the business folks typically know what they need, and can usually describe it very concisely.

"I need to see all the purchase orders still open and due in the next 3 days."

That's a simple report that meets a specific need. If we are going to make sure our customers get their products on time, we need to know before if we are about to screw up.

Let’s say Nancy is responsible for getting those orders out on time. Without this report she is going to have to go through every single order to make sure none of them meet the criteria, oh, and there are 100s of orders open at any given moment, and the due date isn't on the standard report, so she'll have to pull each order up individually to validate.

So this report takes about 8 hours of labor per week.

Rob's Technical Needs
When this open orders report project comes up on IT's “to do” list, Rob digs into the database and can see three problems right away:

1) The due date is on the header level not the line level, but the open status is on the line level, so he needs to join those two tables together

2) The open status links to another table that actually has multiple different types of "open", so he needs to account for all of those, so that'll be another join and a more complicated WHERE clause.

3) There are actually 4 different date fields, so he needs to ask which one should be used, and he needs to make the filter dynamic based on today's date because this data changes daily. ("I hope they never need to run this as of yesterday...and please don't ask about weekends!")

This report will probably take Rob a week to get put together and tested but first he needs to ask Nancy a bunch of questions about where to get the data...but she isn't answering his emails.

What we see here are two different people speaking two different languages, one from the technical side and one from the business side. Both of them are necessary to build the report.

The problem is that the tools they are working with either don't speak both of their languages, or they don't have enough flexibility. The ERP system speaks the business language but doesn't have the flexibility. The technical users have the flexibility but don't speak the business language of the ERP.

If you want to have self-service reporting, you need a product that spans both languages.

MITS Report does just this by creating what we call a Report Source. The Report Source is a translation layer that lets the technical user speak a technical language, and the business user speak a business language. The result is a tool that provides more clarity, and more flexibility.

Many technical groups are using MITS Report to hide complicated technical logic behind clean business language that allows their users to build their own reports. These reports can be tailored in an easy point and click interface, with a very powerful engine under the covers making sure that the technical rules are never violated.

We've asked a couple of our users to talk about their experiences using MITS Report and I'm excited to bring you their feedback over the next few weeks on this blog. Stay tuned for their insights on how this reporting tool works from both a technical and business user perspective.