Business Intelligent LIMS Reporting

Embedded within every LIMS project is a set of deliverables that usually seem mundane.  These are the business reports.  In my experience, these “mundane” reports end up being one of the largest drain on resources and can lead to the overall impression of the new LIMS system by the end users.

In my experience, business reports have usually taken one of the following development approaches:

• Rebuild – Rebuild what the business already has in the current LIMS system without asking any questions.
• Standards – Deliver a set of “standard” reports based on an evaluation of the current reports to see which are actually being used by the business and where multiple reports could be combined.
• Business Process Gaps – Identify requirements in the Business Process that cannot be met by a function in the system and deliver a report that fills this requirement.
• Iterative Development – Schedule a working session with representatives from the business and collaborate on the reporting requirements.  Continually refine these requirements through iterative development and test cycles with the end users until the budget is exhausted, or until the Business loses patience and “accepts” the reports.
• End User’s Problem – Deliver “starter” reports designed to show the general LIMS data model and allow for the end users to further customize these reports to fulfill their own purposes.

I believe that each of these approaches can be a valid path based on the approach to implementing the LIMS system.  The scale of the deployment will heavily impact the success of the chosen approach as the number of end users to satisfy will often determine the amount of compromise that is required.

However, possibly the paradigm of LIMS report delivery should actually be challenged. Regardless of the approach used above, they all share the same common fault.  All of these approaches rely on the business use of the LIMS system to remain static, and for data model translations between the business data and the LIMS data schema to remain unchanged.  These approaches make it more and more difficult for value added changes to the LIMS application to be implemented over time as the system becomes locked-in to the data organization expected by the reports.

I believe that a Business Intelligence (BI) approach to the LIMS data would solve this issue. Possibly not every report required by the business users would be able to be replaced by a BI report, however I believe the vast majority could be delivered through the selection of the right tool.  Additionally with a complete data model mapping provided to power business users, the requirement to retain staff for the sole purpose of maintaining business reports could be eliminated.  An appropriate investment into Business Intelligence with the deployment of a new LIMS system could drastically increase the ROI of the project over the long term investment.

This investment, however will not be small.  The challenge with a BI project is to convince the stakeholders that a significant scale BI project will eliminate the slow funding of future static report creation and maintenance. Experienced stakeholders will recognize the value in this approach immediately as they are haunted by the operational cost of LIMS reporting in prior projects.  Others however will need to be convinced of this need due to the intelligent reporting available in many consumer systems available in common web portals.

Over the next series of posts, I’m going to explore a few of the cross platform BI tools that are available on the market and discuss the positives and drawbacks for use with a LIMS deployment.