Reporting on your project throughout its lifecycle is a very important activity but many companies do not always give it enough importance (in my opinion) during the evaluation phase of a software product. This is a shame because getting accurate and up-to-date information about the project can lead to better decisions and therefore faster and more efficient product development.
Different types of reports can be used at various stages by diverse departments and stakeholders and each individual can use information in different ways. Some will simply analyze data to make more informed decisions while other individuals will transfer information to another system so that it can become part of a bigger whole.
To accommodate these differing requirements, most software applications have a reporting feature which will create user configured reports. This solves many of the user reporting needs and so is usually good enough to pass any software evaluation processes. In the past, I too, used this simplistic way of evaluating the reporting requirements of software I was purchasing. I simply made sure that the software application had a reporting feature, and if it did I moved on without even seeing if the reports that I needed were supported. More importantly I did not research how easy it was to extract the information from the tool to use the Do it all tool Excel. I have now realized that I was wrong.
The fact is, we require very unique reports with very powerful and easy configuration capabilities to generate the reports that we do not know we even need until we need them. When software vendors create a reporting feature/module/product they balance the user complexity of generating and configuring reports with a nice, clean, intuitive UX (User Experience). If they have done a good job, the balancing act between these two goals will result in a reporting capability that will solve 95%-100% of all their client’s needs.
But even under the best scenario, what happens to the user who needs to generate a report that is not supported by the reporting engine? Unfortunately most programs require a very manual process or even a custom developed solution in those cases.
Another challenge related to reporting is that it does not always fit into existing organizations’ workflows. Using the reporting feature on a software application that your department uses on a daily basis will fit into a natural workflow. However, if you are in a different department and only need to access the information via report, you do not want to use another software just to access the report. (This is where enterprise solutions such as PLM/PDM/ERP help but I will leave that for another post.)
Very early in the design of ShipConstructor we knew that no matter how good our Reporting engine was, there was always going to be a report a client needed which would not be supported. However, with our tenet of allowing users accessibility to all their information, we unleashed a whole new way to report on your data. Let me explain what I mean.
ShipConstructor’s reporting solution has two major facets:
- The first is a powerful and user configurable Reports product which gives users access to virtually all information in a project and supports many reporting concepts such as grouping. This reporting product satisfies 95%-100% of all users needs.
- The second is through our Open Architecture which I talked about in my previous post: Knock Knock, the future is calling and it is asking for an Open Architecture.
You might ask, “How is ShipConstructor’s Open Architecture part of the reporting solution?” The answer really revolves around our open Microsoft SQL database and the vast amount of other products which support accessing information from SQL.
You can use applications such as Excel, the most widely used reporting application, to extract live information and have it generate very comprehensive reports for virtually any stakeholder. The benefit of using applications such as Excel is since it is most likely already used in your organization as well as probably how you generate your reports today, the workflow to continue to use Excel with a live link to the ShipConstructor MIM fits very naturally with no disruption to current workflows.
Just last week I created a report for a client who wanted a report to view and manage their Pipe welds. Using Excel I created the report for them. This report can be used by anyone in their organization without requiring the use of ShipConstructor. It is also important to mention that this report has a link to the live project so it will always represent the latest information of the project. There is no need to continually send reports via email because you are empowering the stakeholder with a tool to get the information they need when they need it. If you want the latest report, you open the Excel file, click Refresh and all data and visual data are updated.
Here are some images of the interactive report I created:
These Excel reports can be linked to any project by simply pointing it to a new project and clicking refresh. Yes it is that easy:)
Closing Remarks
The importance of the availability of information in a consumable way has never been more significant than it is today. Good reporting throughout the entire project lifecycle will allow for earlier and better decisions.
Our requirements for reporting will evolve with time. We will require new ways of reporting on our information, more integrated workflows in our daily work as well as getting the information we want before we know that we need it.
Just relying on software reporting engines may solve the majority of our current and future needs but there is a possibility a portion of our needs will not be satisfied.
Having a system which leaves your information open to be accessed and exploited by other tools can get the information you need, when you need it and in the representation you need it in.