Many projects have a problem getting reports produced. In one sense, it seems expensive to hire a LIMS, ELN or LES expert who knows the data but who comes with a rather high rate. On the other hand, getting a cheap resource who knows the reporting tool isn’t an easy solution because it’s so incredibly difficult to teach them these massive databases and how they work. Today, I will tell you the solution to this problem.
Use Two Different Resources
The solution to the problem is actually to use two entirely different resources. In fact, and don’t tell my marketing department that I told you this, but they don’t have to be consultants. 😉
Resource A knows the database incredibly well and can do standard queries fairly easily. This person needs to be me (my apologies, but my marketing department wanted me to add that!) or some other person who is a system expert. Even if they don’t know the specific implementation or, sometimes, even the particular product brand, they will be able to figure out how to tie the data together.
And it will likely be horribly ugly.
This is where the reporting expert comes in. This person doesn’t need to know the data but just needs to know the reporting tool and has the ability to “pretty things up.”
The Final Bit
The purpose here is that Resource A, whether a consultant or an employee, tends to be rather expensive. This person can throw together the right query to get the data but probably has little experience with the reporting tool and possibly can’t even match their own socks. But having them get the process started with the right data is the way to go.
Then, to let Resource B, the less expensive resource take over, and let that person fiddle with all the niceties like getting the corporate logo on the report, getting it aligned the right way, and such.
One More Thing
But if you think that Resource A is done, let me just say that they aren’t. Often, when Resource B starts fiddling with the report, there are more changes, sometimes because the report format requires the query to be stated differently than the way it was initially done. However, just put it in Resource A’s queue and let them hit that query for the fix when it pops to the top of their priority list and you’ll have it back in Resource B’s hands lickety-split, in many cases.
The other bit is that someone has to work with Resource B to understand what is needed in the format, even if you’ve produced a requirement document for it. It doesn’t have to be Resource A but that’s one possibility.
What’s the Point
The point is that most customers think that it’s just too expensive to use high-level consultants to get the formatting beautiful and even if you’re not using consultants, your LIMS System Administrator is too busy to mess around with all of that. The other bit is that it’s too hard to teach a reporting tool expert your database, in many cases. Many times, and especially if you just need one report, you don’t need to try. In the situation where you have many and ongoing reporting needs, you can work with the report writer to learn more as the process goes along. One day, they can probably, at the least, create the simple reports and some of the really good ones can learn to create the difficult ones with minimal assistance.
3 Thoughts to “Solving the Reporting Problem”
Reporting is pretty much a developer function. When I say developer, I mean those who create queries, views and write report logic. The layout is generally the least time consuming effort. Many reporting software vendors pitch their products as being usable by non-developers. In my experience I have never seen that to be the case.
Once a report is developed, I find that end users can go into the report and tweak it as needed and copy it and create new report templates from the copy.
Even with all the drag-and-drop tools for reporting, it still remains more of a developer function. None of the tools are that clear or easy to use. In fact, to get data out to report to them, we often write programs to create the right set of data to report off of.
Then, in other cases, the tools use XML, which is more in the programming realm. Tools such as JasperReports (used by LVS LIMS, for example) can be used either with an interface or direct changes to the XML and even the newer companies like iVention are using XML to produce their reports.
The key is on how clear/mature the requirements are. It is important that who specifies how the report output should look like knows a bit about the tool by which it will be developed otherwise, believe me, what can be seen as a simple task can turn a nightmare. A better db model can make it simpler but this is one of the points to keep under control during the project implementation otherwise it can be one of the main reasons to not be on-time/budget.
Comments are closed.