Six years ago as a young researcher, I was drawn to the prospects of report automation when I was given a Power Point template and told to make 12 versions of it for 12 different countries.
I watched YouTube videos about Macros, figured out how to use VLOOKUP, and discovered an underground network of Excel geeks. After about a day and a half, I was a little nervous because I had spent several hours not really making any progress populating the reports, but I knew (hoped) the investment would be worth it.
All in all, what I developed wasn’t perfect. But it was very convenient. I would open up an Excel file, run a macro, and the output would be something I could copy into Power Point, so that each report only took about 15 minutes.
It turned out, a lot of people were trying to solve the report automation problem. Researchers spent a lot of time copying numbers from one document into another; and report automation was supposed to allow researchers to focus on more profitable tasks. There were special committees aimed at finding the newest report automation program; groups of researchers who would trial the programs; and a general sense of optimism. We could taste it!
Fast forward to today, and we’re no closer to cracking the report automation problem than we were six years ago. And, more frustratingly, the solution is constantly been just out of reach. No matter how many blogs I read or programs I test, no report automation tool really gets it right.
So, why the nuclear power reference?
It’s an old joke in the nuclear power world that cold fusion as a viable energy source has always been and will always be 30 years away.
To save you the time of checking my profile, I’ll tell you now that I’m not a nuclear engineer. But the issue with viable nuclear energy seems to be that advancements generate new,complex questions — often more complex than the questions answered.
And it seems to be a similar case for report automation:
Much in the way that viable nuclear fusion is perpetually 30 years away, viable report automation has been just out of reach for the past six years, at least.
Report Automation is not Solving a Mechanical Problem
From my experience, report automation programs usually end up creating more work than they save. Changing a little aspect of a graph that was created with a program is like playing Russian roulette with my report… I double click and have no idea whether or not Power Point is going to crash.
But really, I believe we have misinterpreted the problem that report automation is aimed at solving.
Although we call the final product a “report,” it’s really a narrative. Personally, I don’t know whether an array of data ought to be displayed as a bar chart or a pie chart or whatever until I’ve had a chance to see both. I need to play around with it and see how different displays complement the overall story the data is telling. Maybe the data doesn’t belong in the report at all? Maybe I need to combine an array of data with some other data point. Maybe I need to add in some desk research to support the data.
While I don’t think I’m an artist, there is a certain level of creativity that goes into developing a report. A creativity that is stifled with a report automation programs.
Ultimately, the “custom” in custom research will continue to preempt effective use automation programs. Sure, automation will be useful in some cases like in the story I described above; but I get the sense that solutions like these are ad hoc and difficult to apply generally.
Other (Specify) 