There is some strong resistance against reporting in process management. Not all of it is unfounded.
Reporting has a special meaning within the agile approach to process management. While there are always some records being kept of processes and their instances, reports are special — these are being sent to someone and they are supposed to be read, right?
But let’s face it. Many employees hate reporting to their superiors or supervisors, exactly because they believe it serves no purpose. Their belief is that many reports are not being read or even opened by their recipients.
However, reports are important, or at least they should be. Not everywhere and always, but there are sound reasons to have them.
Consider this: Any major, well described business process should contain all the related know-how needed to be executed reliably without omissions and missteps. However, the unexpected happens from time to time in any complex process. There will always be singular events, problems, or some important details, that weren’t taken into account in the process design. These will be dealt with, fixed, or at least noted, for sure, and the process will take its course anyway. But shouldn’t they be reported to the process owner as well? For the most part, they should.
Ordinary process records are rather boring. In Procesoid, for example, they are mostly checklists where the completed steps are checked off, possibly with some working notes here and there. And this makes sense, because you probably won’t be digging into these records to get any major intel. They serve a different purpose, which is to record what was finished.
On the other hand, a good report is a form of intel — a piece of intelligence. This is very important, so let me repeat it:
A good report is a form of intel.
What does this mean? It means that it contains an intelligent assessment of the important stuff, that happens in and around a particular process. That is why you should always consider reporting as a vital part of process management — in order to preserve the collected intel.
A good practice may be, for example, reporting on a weekly basis by email. A link to this week’s instance is provided, while also leaving room for a few notes about anything and everything that happened that week.
It may be connected to a production process, customer support, or order management, but regardless of the activity that is being processed, these notes are extremely valuable for the process owner.
We can easily derive other good practices from that:
Automated reporting has its place in agile process management as well, but it tends to be rather overrated, especially with the recent push towards services like IFTTT and Zappier. While it is always nice to aggregate important data into some kind of automated report, real intel has to be gathered by people, at least until we reach an era of universal AI.
As a business consultant, I often work with reports generated by automated systems and rarely, if ever, do they contain comprehensive intel, which would require some very advanced IT skills anyway. Even high-end services like Google Analytics often show me notifications of “important events”, which are totally unimportant. Or they might be unimportant for the recipient and the system won’t know it, of course.
However, it is useful to have automated reporting set up as a way to give you insights, for example on revenues, traffic, new sign-ups or any other number of important metrics and indicators.
I recommend taking the best of both worlds — have some automated reports that feed you key data, while having real people give you real intel. Process management is a powerful tool, but even the best of processes won’t contain everything that is important. It is still up to people to decide what is truly worth shining a light on.