Ask Slashdot: Is Reporting Still Relevant?

New submitter MrWHO (68268) writes A while ago we switched for monitoring our systems to the ELK (ElasticSearch, LogStash and Kibana) stack. Our management wanted to keep the reports they got — and possibly never read — flowing in at the beginning of every week with statistics like sites traffic, servers downtime, security alerts and the works. As we migrated some of our clients to the same stack they kept all asking for the same thing: reporting. There was no way for us to create and schedule reports from ElasticSearch — searches for ElasticSearch and Jasper Reports returned nothing apart from people asking how to do it — so we created our own Jasper Reports plugin to create reports from ElasticSearch data, which we released on GitHub a while ago, and we promptly moved along.

None of our clients were easily convinced that a dashboard — Kibana — was a substitute for mail delivered PDFs, even if all the information was there, with custom created panels and selectable date ranges. On the other hand, on the ElasticSearch mailing list when questions were asked about "how do I do reports?" the answer was, and I sum it up here, "Why would you want reports when you have a dashboard?" Are reports still relevant — the PDF, templated, straight in to your mail kind — or the subset of my clients — we operate mainly in Italy — is a skewed sample of what's the actual reality of access to summary data? Are dashboards — management targeted ones — the current accepted solution or — in your experience — reports are still a hot item for management?

Comments

Unfortunately

[Baby Duck]

Just as there are courts where faxes are permitted, but emails are not, reports will still linger around, strutting proud its cloak of obsolescence.

Re:Unfortunately

[knightghost]

Neither law nor easily used technology has caught up with the "digital signature" in an open environment. Yes, I know PGP, but using it isn't automated widely.

For dashboards, email is far easier than the PITA of logging into yet-another-system and navigating who-knows-where-and-changes-often. Seriously... automate! Quit relying on people to do things manually.

Re:Unfortunately

[ShanghaiBill]

reports will still linger around, strutting proud its cloak of obsolescence.

Reports are not obsolete. As a manager, my "to do" checklist is long enough. Logging in to a dashboard is something that takes time, and more importantly, is something I need to add to my checklist so I remember to do it. A report, on the other hand, is sitting patiently in my email inbox, until I open it with a single click as I process the rest of my email. If you work for me, it is your job to keep me informed. It is not my job to pull information out of you.

Re:Unfortunately

[Anonymous Coward]

Not to mention, once it's in your inbox, you are no longer at the mercy of their downtime.

No Worky

[Anonymous Coward]

People who have to read reports don't want to have to run them. They want them already done in PDF format so they just have to open and read them. The process of creating/searching/saving search in a dashboard is more work than people want to do (especially since they barely read the PDF's).

Re:No Worky

[Qzukk]

While laziness and not wanting to wait 5 extra seconds for number crunching are certainly a factor, I've got customers who are paranoid that we might pull one over on them and retroactively change the data so when they go back to last quarter's numbers they won't be the same.

I set up a cronjob to wget the dashboard weekly, feed it to html2pdf, and email the result to the stakeholders.

Hmmm ...

[gstoddart]

"Why would you want reports when you have a dashboard?"

Because a dashboard is a transient thing, which is a snapshot in time and which you can't look back for historical records.

Corporations want things they can file and hold onto, and a PDF can do that much better than a dashboard. You can submit a report to an external entity ... a snapshot of your dashboard? Give me a break.

This is stupid, because it sounds like "why would you need your paystub when you can look at your bank balance". They're different things, and you can glean more information from looking at a series of reports, than an instantaneous dashboard.

If you think a dashboard does the same thing, then maybe your understanding of what they get used for is lacking?

There is a reason why management is asking for it. And your inability/unwillingness to deliver it means that you're either acting thick, or thinking that you are the most important aspect of your business.

God, it's like IT in the 90s all over again ... we don't care what you want, this is what we're giving you because we think it's cool.

This whole article reads like "we in IT are too uninterested in giving management what they want, so I need someone to help me phrase it better".

Re:Hmmm ...

[kurisuto]

There is a reason why management is asking for it.

The reason might be one of these two:

1. Management knows what they're talking about: there's some valid business reason why the information needs to be in the requested form; and the tech guy just isn't aware of that reason.

2. Management thinks they know what they want, but their request reflects an incomplete understanding as to what technical solutions are possible, and which one would really best serve the business.

I encounter both situations regularly. Sometimes I investigate and find out that management really does have good reasons. Sometimes I conclude that I'm dealing with case #2 above. It's not that I think management is stupid; it's just that their expertise is in a different area from mine. I often try to educate, depending on how important I think the issue is. Fairly often, my effort succeeds: managers generally want to do right for the business; they understand that the tech guy knows things and is worth listening to; and sometimes they agree that my proposal is better.

However, of course the effort doesn't always succeed. Unless you're writing software on your own without having to please clients or management (e.g. as a hobby, or in an academic setting), it's just a part of life as a paid tech guy that you sometimes have to implement decisions which were made without the benefit of as much tech expertise as you have yourself.

Re:Hmmm ...

[petes_PoV]

There are more reasons.

Reports are consistent: they report the same data, in the same format thus making for easy comparisons
Reports are easily filed. Why would a manager want to waste their time learning how to retrieve past data and then learn how to compare it with stuff form other dates/times when they can simply print it and highlight what they want. Paper and disk space are cheap - their time is not.
Reports are portable. You can take them away with you, you can show them to other people.
Reports are secure. You can print them and be sure that whoever you show them to cannot access anything else. ANYTHING
Reports can be easily incorporated into a manager's "product" (presentations, summaries, proposals and archives) without them having to learn any new methods. Again: it's a trade-off between cheap IT resources and their expensive time.

And probably most important of all: reports are familiar. Never forget that IT is providing a service to the business. It's not the place of IT to dictate to the business how they do their work - it should always be the other way round.

Dashboards are not Reports

[IcyWolfy]

Most everywhere I work, reporting is still the top most requirement. Even more so at publically traded companies.

I've had former colleguges make a good living working in the dedicated report-generation area. (Developing reporting tools, creating reports using existing client tools, etc)

But, the use is primarily that of communication, and more so, consistency, of the data generated so that you can see the trends as they happen; and easily share them in email; slides; presentations; and -- more reports to Regulatory agencies.

Dashboards are nice, but they aren't reports.
Reports are normally more complex data manipulation and correlation that are composites and manipulations of the data that dashboards provide.
There are also many one-offs that are needed to be drawn up, for specific documents, endeavours, and studies.
All of which require good reporting tools.
And these reporting tools are lacking in most developers systems.
But, thankfully, many developers can expose all the raw data streams, processed into something usable; to which, they take all these numbers, plug them into a proper reporting / modelling toolset, and generate the reports required using the proper tool.

Many places don't have a proper reporting/analysis tool; and expect the software to deliver that. This is a failure of either knownig the tools exist, or unwillingness to accept the costs involved in the additional licenses. (and thus leading to just importing the data into Excel, and massaging it there)

Application
1. generates Metrics
2. exports Data
3. imported into Reporting Application
4. worked by Analysts
5. automatically Generate Reports as new data is imported.

Steps 1 and 2 often exist.
Many places want the Application to do steps 2-5, which is fundamentally not the domain.
And thus led to the development of dashboards and other simple visualizations, which are not proper reports.
Introducing companies to dedicated modelling and reporting tools (Quantrix is one used a lot) tend to get them to realize how much better things could be. ... which then usually leads them to complain that their applications don't export data in clean, discrete, normalized data sets to which other tools can ingest.

Obviously!

[fuzzyfuzzyfungus]

It all comes down to movie psychology: A 'dashboard' is basically just a boring web based equivalent to the rows of screens and blinking lights and things that the jumpsuited minions hunch over, monitoring feverishly. A 'report' is the thing (piece of paper, datapad, etc. depending on era) that an obsequious yoeman hands to The Leader while he stands in a super-decisive Master and Commander pose in a suitably dramatic part of the set. The Leader then glances at the report and, thanks to the powers of decisive leadership, immediately gleans the relevant information and issues an order to rally his underlings.

'Dashboard' (while more useful) is basically a giant blinking signal that you are a peon, a cog in the machine. 'Report' is the executive summary with all the tedious detail drained out so that you can focus on being a big picture thinker and indispensable idea guy. It's like the difference between the giant bundle of keys that the janitor has (which can get you anywhere in the building; but show you to be a blue collar lackey) and the single RFID card that opens the suites on the top floor.

The middle manager's job is...

[netsavior]

The middle manager's job is to prove to his boss that all of his employees are actually doing something. The Emailed pdf serves as a daily reminder that "we are doing stuff."

Emailed PDF: "Just a quick reminder from the server that your employees are busy working hard, feel free to not read this."
vs
Dashboard: "Do my employees even do anything?? I guess I will go look that up."

strip everything down to "why do I still get a paycheck" and you will get to the answer, you never want to allow the big boss to think "do they even do anything?" Email is a preemptive strike against your boss's boss having to seek out that answer

The geek with a 2x4 foot chip on his shoulder.

[westlake]

Reports validate a manager's existence in an organization and shiny charts make them feel warm and fuzzy inside.

It's a manager's job to manage. It's IT's job to present the information he needs to manage things well in a form with which he is comfortable.