IWMS expert and Lucernex President, Joe Valeri (see Joe’s management summary here), discusses reporting options in IWMS Location Performance Management Applications.
It always amazes me how little importance some software buyers place on reporting options. The fact is, while some IWMS applications have great industry specific functionality or better project management or CAFM or lease administration; the ultimate reason to establish a single source of location data it to enable effective decision-making. And effective decision-making can only come through thoughtful review of summarized data (i.e. reporting). While dashboards can help drive some decision making as can specific analysis functionality, reports are still the most widely used deliverable of any IWMS system.
Also interesting is how many business users seems so willing to forfeit their right to quickly create queries and reports on their own, instead giving over this function to IT personnel specifically hired (at high salaries) as report writers. I believe the reasons for this are simply a history of “enterprise” report writers in large firms and a lack of knowledge of the reporting options available in IWMS applications.
IWMS applications vary widely in their reporting capabilities and many have only one option that adds a substantial cost to the annual total cost of ownership (TCO).
With this in mind I will discuss the different types of reporting and what prospective IWMS users should look for in their IWMS applications.
In general there are three types of reporting, dashboard objects which are really mini interactive reports, ad-hoc reports and enterprise reports. Now a reporting expert will probably call this a gross generalization but for business end users this is really what should matter to you.
Dashboard Objects
Unlike other forms of reporting, IWMS software reviewers do typically place a sufficient amount of importance on dashboards. Though many folks don’t consider Dashboard Objects reports, in truth they are small interactive reports with 5 or 6 columns typically with one grouping variables and a way to re-filter the report using options on that grouping variable. For example, a dashboard object may contain a list of lease options coming due in the next 30 days allow the user to click on a field to drill down to the specifics on the actions needed to execute the option. The object might even have a drop down box allowing the user to change the number of days into the future to show these lease options.
You will find some form of dashboard in every IWMS application with varying degrees of functionality. The difference in vendors comes in:
- The number of pre-built objects available
- The functional areas covered by those pre-built objects
- The expertise of the IWMS vendor to create meaningful pre-built objects
- Drill down capability on each object – note, systems that use an external providers dashboard will not have the same degree of drill down capability into the core application as a provider who has built their own dashboard into their own code. See Single vs. Multi-platform IWMS and why you should care
- Security control over those objects
- The ability of the client to create their own dashboard objects
- The complexity of the process to create a new object (by the end user or an IT user)
- The performance or response time of the dashboard – keep in mind when you launch a dashboard you are actually tasking the system to generate a bunch of reports across a large database. Poorly architected systems may take a long time to “paint” the screen.
- The ability to re-sort tabular dashboard objects with one click and no screen or object refresh – this one items will tell you a great deal about the quality of the system architecture. If a re-sort requires a page or an object refresh there is a performance issue being hidden
Once implementation of an IWMS application is completed, experience tells us that most users will spend most of their time on the dashboard. It is the first thing you see and, in a well architected and designed system, brings each users required tasks and issues to the forefront so that work can be done in priority order with ease. Make sure to consider this use case when selecting an IWMS application.
Ad-hoc reporting
The next most used reporting feature is ad-hoc reporting. The funny thing is many IWMS applications do not actually have a true business user capable ad-hoc reporting tool. Instead, most IWMS applications take the easy road and partner with a third-party reporting company and rely completely on canned reports or on complex ad-hoc reporting tools that require an IT report writer to create reports. This means business users are beholden to IT (and the often long waiting periods after request) to get even the simplest report created. It also requires the purchaser of the IWMS to lay out an additional $25,000 to $75,000 up-front plus annual maintenance for the right to report against their IWMS database.
Ad-hoc reporting should be just that, ad-hoc; meaning any business user should be able to, upon coming up with an idea for a report, create a report within a few minutes and get a result. And they should be able to do it without understanding what an outer-join is or a foreign key relationship. There will always be some reports that are too complex and require a professional report writer, but this should be the exception, not the norm.
When getting a demo of an IWMS ask the vendor to build a simple report right in front of you to find out if there is a true ad-hoc report capability and if its truly business user friendly. Can the report be saved and kept private or shared with others? Can the report be scheduled and automatically sent out? Also ask if those reports can be emailed to a distribution list or printed, or saved as PDF, or dumped into Excel. Business users should control reporting not IT so ASK!
Enterprise Reporting
As mentioned above, there will always be some reports that are too complex for any ad-hoc tool or that require data from multiple systems including the IWMS application and other databases within the client network. Ad-hoc reporting tools also cannot typically produce detailed and often very user specific formatting requests. In these cases Enterprise reporting is required.
There is a huge divergence in IWMS vendors on Enterprise reporting that breaks down into two camps.
Mandated Third-party reporting software
Many IWMS applications, particularly those created from a bunch of different applications gotten through multiple acquisitions of other software firms. Using a mandated third party applications is required in this case as the vendor needs it to knit together all the different databases that are a typical by-product of the multi-platform IWMS application.
The benefit of this option is the vendor has likely pre-configured the data into manner making it easier to report on. This will make implementation of the reporting tool simpler and thus reduce some professional services cost at implementation (that might have been spent on organizing the data for reporting). There still will be a PS cost in creating the clients specific reports since it is unlikely the client has an IT resource that knows the required third party tool.
The biggest problem with this option is the purchaser is required to pay a rather large fee up front and then annually to use this third party reporting tool. A tool that they likely don’ t have hardware or IT resources to support. This means a very high TCO when you analyze the cost of the licenses, maintenance, hardware and IT staffing.
Even if a company has already invested in an Enterprise reporting tool, many IWMS vendors offer one option for third-party reporting and if you are not already using that third-party product you have no choice but to bring in yet another reporting solution.
Vendor Agnostic Third-party reporting
In short, what this means is the IWMS vendor allows for reporting by most if not all third party reporting solutions. There are two common methods used for this type of reporting, data marts and web services.
Data marts There is a base standard most third-party enterprise reporting vendors use for how they access data called ODBC or JDBC. What this means is any data provided in a manner that can be accessed using ODBC or JDBC can be reported on.
So, some IWMS vendors will provide new clients with a data mart, which is a small database designed specifically for reporting against. The vendor should then also provide a pre-built process for updating that data-mart on some short time period (often nightly). This then allows the client organization to leverage their existing enterprise reporting investment to create Enterprise reports against their IWMS system. They don’t have to buy any additional software licenses nor hire more IT staff to write reports using a new reporting tool.
Clients do have to provide a database instance to store the data mart in-house and enough bandwidth at off-peak hours to update it. There will likely be some up-front cost in making sure the data mart has all data clients may add during an implementation and in making sure the data exchange for updating the data mart works in a secure fashion though any cost here will be far less than the cost of buying a new third-party reporting tool.
Web services
Another method more advanced IWMS vendors may provide is web-services access to data for reporting. What this means is the vendor has pre-built little programs that are created for the sole purpose of securely passing data out of the system to a requesting system. The big advantages here are that this method is self updating and does not require much upfront PS work to get it going. It also
The downside is that many customers simply don’t have the IT know how to do it.
Using this means the customer IT staff would create a report using what ever third party tool they already have and then write web services (if the third party tool does not already have them) to ask for the data the report requires. The request is sent to the IWMS vendor application, which has web services to receive the request and respond with the data required for the report.
I could go on all day about reporting but as this is my longest blog ever I applaud anyone who got this far and thank you for getting here!
Shameless Plug
Lx IWMS offers business user friendly ad-hoc reporting and Enterprise reporting through a delivered data mart and web services allowing clients to leverage their existing Enterprise reporting investments without any additional software cost. Lx IWMS also provides a user definable set of dashboards including dozens of pre-configured user specific dashboard objects. And, in late 2010, we will add the option of an optional Enterprise reporting tool called BIRT; an open source (aka FREE) reporting application that will allow clients without existing enterprise reporting to build and utilize advanced Enterprise reports with NO additional software cost.
Previous IWMS related Blogs
What is IWMS anyway?
IWMS? It’s Location! Location! Location!
The Power of Location Management
IWMS – Why so expensive?
IWMS in the “Cloud”
How Capital Project Management fits in an IWMS

[...] This post was mentioned on Twitter by Joe Valeri, Joe Valeri. Joe Valeri said: New Lx Blog Post: Reporting options in IWMS applications http://www.lucernex.com/files/index.php/blog/iwms-reporting-options/ [...]
[...] Posted on 12 July 2010 Tags: Ad-hoc Reporting, Dashboards, IWMS, Reporting IWMS expert and Lucernex President, Joe Valeri (see Joe’s management summary here), discusses reporting options in IWMS Location Performance Management Applications. The original post appeared on Lucernex Blog. [...]