7 problems with automated PDF reports

If you want several automated PDF reports, there are a few software solutions, such as those provided by Tableau as well as some generally expensive Business Intelligence systems. The alternative is to find a services provider that can automate the reports either by using a software platform or by programming report production in some way.

Manual report production is time-consuming and risky

Even if you are tasked with as few as, say, 10 reports of 10 pages containing a selection of charts, figures and infographics, manual production of these reports is likely to be slow, error-prone and inflexible to minor changes.

This article looks at the 7 most common problems that arise when you have tens, hundreds or thousands of reports that you need to generate in an identical format for different users of your data.

1. Buying a software solution vs buying services

Automated reports are usually generated by specialist software packages or by programmers that can generate the required output – or, a combination of the two. There are some very good software tools that allow you to automate reports yourselves. The problem is that they can be difficult to learn and/or expensive. They tend to be simple on the surface and look good in a demonstration, but can be cumbersome or frustrating for implementing the detailed requirements that you may need. Generally, buying a software solution for one or two projects will not be a good route. Hiring a specialist automated reporting vendor will tend to be a better route.

2. Making changes

Automated processes work best when there are minimal changes during a project. Changes are sometimes necessary, but if the recipient(s) of the reports see the process as something that needs to be refined over time, costs, whether internal or external, for the automated reporting are likely to go way over budget. The more thinking and agreement on requirements that can be carried out in advance, the more smoothly a project will go. Last minute changes really are not recommended when hundreds or thousands of reports are to be produced.

3. Dealing with different versions

Different versions of reports, however minor or subtle, are often inevitable. Being clear in advance as to what refinements are needed for different types or versions of a report is important. Programmers can perform more efficiently if they know in advance what tweaks and fixes are needed. Adding different versions after a project has been programmed will always be more expensive.

4. Neglecting testing

An important of the process is testing any automated reports. Testing is not a quick process. It means that test data must be produced which is capable of testing all the variants of the report. In many cases, these variants can multiply quickly making testing a significant task. Without proper testing, there is a real risk that a small number of (or all!) reports will contain an error. It means that where there are late specification changes, there is a dilemma. What do you do? Is it such a small change that you only need to check the effect of the minor change? Or, could the change impact something else which would mean re-doing a full test? It’s a common problem and best avoided by having no late changes.

5. Calculating the results

Where calculating results is part of the process, it is important to have the right tools to hand. There are many tools on the market that can calculate results – from Excel to sophisticated number crunching tools like our MRDCL software. If the calculations are simple, there isn’t a problem, but we worked with a client who was running data calculations in Access themselves, which took over 24 hours to run. In our software, which is geared to heavy number crunching, the run took about one minute. Clearly, this caused a bottleneck when data corrections or additional data was provided.

6. Neglecting the detail

Reports can become complex. Something that is conceptually quite simple can be difficult for many software packages and, indeed, for some report production specialist companies. Here’s an example. Let’s say you need to automate 1000 reports in an employee study. It’s likely that you would want to suppress data from small bases of, say, 10 or less, so that employees cannot be identified. This sounds simple, but unless you have the tools to automate this, it will prove a problem. Similarly, pulling in data from the previous year for comparison should be easy, but what if the data is in a different format from year to year. Can the system cope? These types of details will be important to the success of a project.

7. Poor scheduling

Typically, an automated reporting process goes through several stages that are likely to go across different teams of people or companies. Data is often collected, collated, analysed and reported by different teams with the report recipients needing to provide input into how the reports appear. This means that scheduling when everything happens and what deadlines need to be met is key to the success of a project. It sounds obvious, but automated reporting tasks which are always in crisis are likely to fail at some stage. There needs to be time to make changes, test and agree data and reporting formats. Poor (or no) scheduling is a common cause of a project being problematic.

How we can help?

We are experienced in avoiding all the above problems associated automated reporting and can help you to make sure your project stays on course. Contact, our expert in such tasks, lauren.stone@mrdcsoftware.com, for free advice and help with your project.