Slashdot Mirror
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?
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?
Just as there are courts where faxes are permitted, but emails are not, reports will still linger around, strutting proud its cloak of obsolescence.
"Love heals scars love left." -- Henry Rollins
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).
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".
Lost at C:>. Found at C.
In case anyone is looking for it:
https://github.com/WedjaaOpen/ElasticJasper
Reporting is still relevant because of management: they hold the knife, they dictate what your output is.
Do you know what problems they were solving with those reports, or did you just assume that a dashboard would solve them?
Dashboards & online reports are great when you have access to them. But what if the dashboard isn't available, or you need to provide the data to someone who doesn't have access to the dashboard? Reports are also static - this was the data as of the time the report was generated whereas a dashboard might reflect modifications made after the report was generated. The data used by the dashboard might also have a shorter purge interval than the reports are used for. Finally, depending upon the format of the reports, they may be used for post-processing.
IT people wants the information on realtime.
Managers want them archived, untoched and easy viewing so they can review it in case problems appear.
Is Slashdot?
Answer is a resounding, ugggggh.
I helped install an MRP system at a defense contractor back in the 1980's. The Director wanted his "Tapes". Which were 2 boxes of greenbar paper with the allocation report from midnight on it. And it was obsolete 60 minutes after the morning shift started. Consider training the people who need reports on how useful dashboards are for identifying trouble spots.
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. ... 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.
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.
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.
I've worked in multiple multinational situations. In my experience Western Europeans and Indians have a culture that utterly resists things being fluid. I've had zero problem using dashboards in American and British and Eastern European (Poland, Ukraine, Estonia) divisions. Once you get the folks to understand the data is live and give them the ability to use time hacks its been to great success and have allowed analysts to do much deeper dives into the data. It has been a great success. But cultural differences in those other two geographic regions make it so i have to use set in stone policies and decrease efficiencies. It has to be a 100% repeatable process with a set outcome. If your saying well a dashboard is that, i agree. But the fact that you can alter the dates and get any dataset you want on demand is what doesn't work well. So i literally use dashboards in England/US/Poland and static generated ssrs reports for India, France, Germany and Belgium.
My experience was that the bosses were generally older people who liked printed reports best, and emailed pdfs a very bad second. OTOH when it's your turn, you would insist on dashboards while you staff would be wondering why you do not prefer the latest and greatest way to represent data.
Dashboards & online reports are great when you have access to them. But what if the dashboard isn't available, or you need to provide the data to someone who doesn't have access to the dashboard?
Open the dashboard in a web browser, take a screenshot, export it to JPEG, and send it as an e-mail attachment.
Many things are impractical to do with a dashboard.
Reports also represent data at a specific point in time. Monthly, quarterly, yearly finance reports are mandated by Accounting Standards I believe. Your taxes statements are essentially reports.
Sometimes you need to be able to fix data a specific point in time in order to consider it and take action on it.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
As per title...
I am a report writer and dashboard manager. I'm also the main developer of analyses and dashboards (Business Intelligence) for a sizable LoB within my company.
Based on my experience, management is lazy. As in "fucking lazy". They want to sit on their asses, get the reports in their Inbox and never look at them.
I currently manage over 350 items in our main Business Intelligence analytics instance and about 100 more in a secondary instance. There are other environments which we're currently merging, and those contain a few hundred more items (analyses, dashboards, etc). Management asked for most of them. They looked at them once, maybe twice. They only look at about 15-20 of them on a regular basis and that's only because they're forced to do so in order to prepare for mandatory monthly operation reviews.
As for acting based on the data in there, that almost never happens. Some analyses, KPIs and scorecards have been "in the red" for months, years even with no reaction from management. Ironically, requestors come and ask me to build analyses which they already had requested and were published for them months ago, tha means "asking for stuff they already have".
We have a saying in my country: "fish starts rotting from the head". So if you ask yourself what's wrong with them, look at their managers, and their managers' managers and you'll find out. I'm yet to find one single person who gives a shit about data in a report rather than the shade of green the bars are colored.
Amazingly, I still like what I'm doing, but I'm not doing it for them, rather I'm doing it for myself because it keeps me in touch with new technology and allows me to gain a shitload of experience by pushing the environment's capabilities and limits to the maximum. But if you're not really into reporting, just run as far away from it as possible, because it's very likely things won't get better. Soon enough, you'll be asked to provide powerpoint slides. Mark my words! I've been there (but haven't done that).
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
Your dashboard should be keeping some sort of log, even if it is a temp file somewhere. Use the logs to create the reports you need. If your dashboard does not have logs, then you probably should find something different.
Nailed it.
Submitter is trying to solve a different problem than what management needs.
Don't call it a "dashboard" because they think that just because its packaged differently and called something else it must not therefore be what they want. Call it "Realtime Reporting" and be done with it. Its not, strictly speaking, realitime, but that matters very little; its not strictly speaking a dashboard either.
Granted, it may be primarily of a bureaucratic bent that many geeks - professional or otherwise - may not be terribly keen on, nor interested in, however reports - especially those of the "mailed-daily-to-your-inbox" variety fulfill a number of functions within a business ecosystem.
Reports of the "traditional" variety provide an accountability chain and historical record that a dashboard cannot. They can be accessed locally, outside of any other application or access requirements - including email - meaning a connection to said dashboard is not required when someone must review those reports for whatever reason.
Reports can be printed off readily, and due to their very nature, are often formatted to present data to the viewer in such a way that they retain their usefulness after being printed to hardcopy, whereas a screen-cap and printout of a dashboard is quite often one of the least efficient ways to consume the type of data these more traditional reports display.
Last but certainly not least, they make it possible for data to be shared easily with other interested parties, on demand, at any time, without having to carve out user accounts or VPN tunnels to internal networks or mission-critical systems, with no requirement greater than being able to read whatever format the report is stored in - again, unlike dashboards, no few of which also require Java or some other extension to be installed on the user's computer, often necessitating IT support for non-Administrative end-users, which is itself a special and often painful consideration when this data needs to be provided to customers or vendors with their own IT processes, procedures and issues to deal with.
Dashboards have their uses and purposes, especially for live, changing data, things that need to be regularly and closely monitored, or even things that just need occasional monitoring, however for many other purposes, such as those involving accounting or other applications where historical data is of a concern, they fall dramatically short of being able to adequately - much less completely - supplant reports as they have traditionally been used.
"Inveniemus Viam Aut Faciemus" 'We will find a way... Or we will make one!' --Hannibal of Carthage
I'm in no way a dashboard hater, but reports are great because:
* I can see them everywhere I can access my email. This is not always the case when a dashboard runs off an internal server.
* Getting an email in the morning is a reminder to check the data. If I have to remember to go to a dashboard I'll forget if I'm busy and could miss something important.
* Reports in my email are easily searchable without fiddling with date ranges in a console - assuming adequate history even exists since the latest time someone thought it would be a great idea to rebuild the dashboard.
Dashboards are great for sharing a realtime view but they aren't a replacement for reports. If you think they are, you probably seriously misunderstand your users.
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
Rejecting reports, because of a dashboard is like saying, "We don't need trade journals, because we have Twitter"!
Where reporting is really needed is with finance. So all those lovely metrics you collect should at some level get tied to financials. That site traffic has expenses associated with it - labor, acquisition, and hard costs like data pipes. Downtime has costs associated with it. At the end of the day, I'd venture that nearly every company just uses Excel to crunch those kinds numbers. (Perhaps they get stored in a database, in which case the staff accountant who generates the reports likely exports them to Excel, makes a few modifications or fixups, and then emails them on.) So yes, in order to intelligently run your company you need to meld together all kinds of different numbers and that's where reporting typically comes into play. Also, the higher up the food chain you go in any company, typically the older the employees are. The folks higher up typically have very little time to twiddle around with a web interface. In fact, they probably just use Outlook all day long and just send email around. So, if the report comes in via email, there's a reasonable chance they'll look at it. Not every day, but at least occasionally.
----- obSig
Stop producing reports for sometime and see what happens. If nobody complains, stop wasting your time on the reports and do something productive. That's what I did and it worked out well.
The purpose of a report is to tell a story. The story of business that is. If you started an initiative that is supposed to benefit your organization in some shape or form, you better be ready to explain how that initiative succeeded or failed. Everything else is just semantics that can be safely avoided. For example, if you thought that doing X will bring more money, you have to show how X affected your revenues and, possibly, profits. If people really want to see more data and more reports, make sure that they can login into your data warehouse and have enough knowledge to generate a report they desire.
Other rules for my team. First of all, make it an interesting infograph. Secondly, ensure that the graphics can fit into an e-mail nicely; mind mobile devices as well. Finally, display the report in all prominent areas of workspaces, so you people spend less time reviewing data in meetings and ask more questions that matter.
Dashboards & online reports are great when you have access to them. But what if the dashboard isn't available, or you need to provide the data to someone who doesn't have access to the dashboard?
Open the dashboard in a web browser, take a screenshot, export it to JPEG, and send it as an e-mail attachment.
A screenshot of a report is a poor substitute for an Excel or PDF report where you can copy and paste the data.
This is basically the kind of system I run. A different application, but I have the same problem.
The problem is you. You're describing it wrong. The Dashboard is the report. It's just a new kind of report.
Explain that emailed PDFs, spreadsheets on network drives, etc... are bad. If they give you a report to write and you do... it gets emailed to them and then they base decisions off that report. Now, a week later someone points out a flaw in the reporting. You had a bad join! Oh no! So you fix it. The data is instantly fixed in the "Dashboard" but the report they have in their email or network drive will be forever wrong.
Reports arent wrong, they're just better now.
If they need the raw data for a presentation or something, that's different. You should have an export feature. If not, that's another problem.
Reports are definitely relevant here. I'm at a small nonprofit in the US (Posting anon because on /. during working hours :P) and management highly prefers PDFs. Web dashboards don't scale well with the bureaucratic dance once you're responsible for more than one with delays signing in vs/delays loading a document/opening a paper folder. When you can set up a collection of PDF reports (regardless of the contents) its much easier to deal with it on the fly (and pull the records of what it said before, later).
While there is some overlap between reporting and dashboarding, there are some things for which reporting is more appropriate. Your examples are all trends and realtime stuff where dashboarding seems more appropriate. But data mining is where reporting comes in.
For example, suppose there was recall on particular lot number of something. You may want to determine everyone who used that particular lot. This is not something you want on a dashboard. This is something you want to see on screen, export into a spreadsheet, archive, and print. You may want to see which client was most impacted, or how many it was used. Maybe you know the % failure in the lot and you want to estimate the number of people in Nigeria affected as compared to the number of people in Egypt. This reporting or querying, but not dashboarding.
When the manager looks at an old PDF report a year from now, he knows that the numbers will be exactly the same as the last time he looked at it.
When he runs a new report for that time period, he has no such assurance that the numbers will be the same or even there at all. "Oh, we reclassified some of the expense categories last month, so the numbers are a little different" or "Oh yeah, when we migrated from the old database 6 months ago, and it was too hard to import some of the older data, so we left it out" or "Oh yeah, we decided that we only need to keep 9 months of historical data" or "Oh really? The numbers are different now? Maybe that's a bug, file a bug report and we'll bring it up with the vendor".
A screenshot of a report is a poor substitute for an Excel or PDF report where you can copy and paste the data.
This is where picatext or other OCR software comes in handy.
Also... in principle, you could make or use screenshot software which also captures the text from the window shown.
Reports are good at details. They are formatted to be printed. They can be custom designed by the user to answer specific questions. Dashboards should involve more interaction at higher levels. A good dashboard can be linked to reports if required.
Well, there's spam egg sausage and spam, that's not got much spam in it.
A screenshot of a report is a poor substitute for an Excel or PDF report where you can copy and paste the data.
This is where picatext or other OCR software comes in handy.
Also... in principle, you could make or use screenshot software which also captures the text from the window shown.
I can't think of a worse use for OCR software than for reporting. "Hey, why are all of the category zero items showing up under category O? And why were all of the accent marks turned into apostrophes?"
Or you could fucking AUTOMATICALLY generate a nice fucking PDF out of the fucking data once a fucking reporting cycle and be fucking done with it, so no-one has to copy or paste anything and you don't have to give random fucks access to your dash.
A screenshot of a report is a poor substitute for an Excel or PDF report where you can copy and paste the data.
This is where picatext or other OCR software comes in handy.
Also... in principle, you could make or use screenshot software which also captures the text from the window shown.
Neither of which your CEO, President, VP(s), Sr. VPs, or Directors want to do or learn, nor should they have to. That's what underlings are for, and they don't want their secretaries doing it either (should they have one). Their time is too valuable to the corporation for that, and yes, they will all pull data from that report to make another report.
Even the manager above you wants a report they can easily edit, merge, and send up the chain; it makes reporting on multiple projects a lot easier to do.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
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.
If so, you need reports.
That, or submitter is lazy and doesn't feel like sending reports. Why not provide both? If it's not a relatively small effort to do so, then either A. your systems are designed terribly or B. you don't know what you're doing (which may have caused A).
Hey you forgot to close that small crack in your blindfolds, be more careful next time my friend, or you may actually end up understanding what people are talking about.
Reports can be saved. You can't save your current view of a dashboard.
I do not fail; I succeed at finding out what does not work.
Reports will always be needed. A dashboard has a sense of impermanence, and rightly so -- if the backend database gets corrupted, then your dashboard isn't going to show the same thing today that it showed yesterday, even for the exact same filter options.
Add to that the ability to do things like highlight lines/items as you go through and all the other tricks humans have built up over the past few thousand years for dealing with paper, many of which are only kind of functional in even the best e-readers never mind some random dashboard and yes, reports are definitely needed.
That said, there is definitely still an overabundance of reporting when not needed. Run a whole report to look up the current price of a single item? Yeah that happens and then is immediately discarded once the information is obtained. That type of "reporting" is definitely a complete waste of time and paper but that's more an issue of stupid people not using the tools available to them than the tools being wrong or bad.
Basically any time you have some piece of data that the accountant might need come end of year, a report is going to be necessary.
A good halfway point seems to be PDFs (or similar.) They're dissociated from the underlying database unlike a dashboard (that is, the data will never change -- or if it does, chances are the entire PDF is corrupt) while at the same time still remaining electronic and not wasting a bunch of paper. It doesn't help the highlighting aspect for reports that someone actually reviews, but for many end-of-day and similar reports that "must" exist but only get looked at when there's a problem, PDF works wonders.
Screenshot, export to jpeg, attach to email?
Hmm, is that Alt PrtSc, CtrlPrtSc (what's the focus at the time?) or is it command-shift-4 or option-control-17 or what?
Oh, you mean that I can't read your dashboard when I'm on a plane to a meeting because there's not universal wideband internet connectivity? Bummer. Had you done that report as a pdf attachment that wound up on my phone/laptop last night, so I can see it on the plane and cut and paste into the presentation I have to give 3 hours after I land, I'd be happy. But no, you wanted a "up to the second, real time dashboard", so I'm going to have to futz around with my laptop on my lap while sitting on the effing rental car shuttle bus trying to do 2 factor authentication with the VPN to your precious real time website, and then sit out in the parking lot trying ot put the report together. Oh, and all those nifty graphics, and the 100s of kbytes of java or javascript or whatever cruft you put into that fancy client side processing are a royal pain in the rear when you're competing with the other 30 people using tethering into a underprovisioned 3G cell tower (Yay, I'm getting 2kByte/second right now) Sure, I could have stayed up late last night and run your effin dashboard, done the screen cap, saved into my ppt. But ya know.. I like to sleep at nights when I have to get up at 330AM to get to the airport by 7AM. That 5 minutes to log in thru the VPN, get your dashboard, etc. (more like 10 or 15 minutes) is cutting into a precious commodity. My wife is pissed enough that I'm not going to be home for the next 2 days, and that 15 minutes you cost me could have been replaced by a much more enjoyable activity. Thanks.
When I get back, your supervisor and I are going to have a chat, and *your opinions* about what *I need* to do my job may wind up to be career limiting.
You demand your customers remember to pull data from some repository that changes with every new IT fad.
Your customers want data pushed to them without their effort in a form that will be format-stable and readable longer than the next IT fad.
The failure to understand the difference is yours.
Reports should only exist to solve problems. And, when the problems go away so should the reports.
Why are reports typically created? Usually in my experience it's because you need to get a handle on the performance of something. Or you have identified a problem that you need so solve.
If you want to get a handle on the performance of something then you should run the report as long as it takes to get a handle on it. If it's not a problem, then stop the reporting.
If you have identified a problem, then by all means create a report to measure the problem and set a criteria for what you would consider to be "bad" and "good". Once you get the problem in hand and move your measure from bad to good and can keep it at good the problem will likely be gone. At which point your report is really doing no good anymore. If you're concerned about the problem coming up again set up some sort of threshold alert to warn you and stash that report away in your archives.
If a report outlives the problem it was intended to help solve institutional momentum will keep that report going forever. No one will remember why metric X was generated or why it was considered "bad" back in 2007 when that value got too high. The underlying technology or processes may have changed completely in the meantime and metric X may be meaningless, but someone who is ill informed will keep looking at it and trying to drive meaningless work off of it. The healthiest thing a company can do is to define a lifetime for their reports and re-evaluate whether those reports should continue at the end of the lifetime. If you do determine it should keep continuing define a new lifetime and re-evaluate it at the end of that lifetime again.
If I am resposible for watching reports for multiple sites (I don't want to learn 10 different url/username/password combos for 10 different dashboards + learn to use each one of them)
That's more of an argument for the dashboard provider being an OpenID relying party than for e-mailed reports, so that it can accept logins from Google, AOL, Yahoo, Ubuntu SSO, Myspace, LiveJournal, WordPress, or what have you.
If I need to forward the report to someone else [or] need someone else to temporarily take over watching the reports
Then add the recipient's OpenID identifier as an additional viewer of your dashboard.
If I need to see backwards in history and the dashboard doesn't provide that (as already mentioned above)?
Then request that from your dashboard provider.
If the dashboard is continuously "improving", i.e. they keep hiding the things I want to see every two weeks.
Then report that as a bug to your dashboard provider. The same thing would happen when the format of a static report changes and it leaves out a section on which you have been relying.
I want to make sure I understand this correctly. When Sony or EA or Microsoft require a constant on internet connection in order to play your game, that is bad, but when your IT department requires a constant on internet connection to view historical data, that is good?
If you are not allowed to question your government then the government has answered your question.
So when management reads their trade journals and wants us to use this fancy, trendy new toy that doesn't really meet the needs of the employees, then we get all bent out of shape. But when development wants to use this fancy, trendy new toy that doesn't really meet the needs of management, we get all bent out of shape?
If you are not allowed to question your government then the government has answered your question.
Maybe you want to share information with people for whom you don't want to set up a dashboard for and train them in (e.g. potential investors, advertisers, loan officers, managers who don't need to be monkeying with stuff, etc.).
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Management types judge their self-worth by the number and types of reports they get. It makes them feel important.
Having said that, I will offer this in their defence: They can go to one place, i.e., their email, and get everything; reports, discussion about the reports, and the ability to begin discussions about the reports. With various dashboards from various systems and vendors, they have to go to multiple places to get the data they want, and have difficulty sharing it and discussing it with others.
Proverbs 21:19
Just stop doing a report and see if anyone notices. Usually, they do not, and I just quit doing it. I think 99% of all reports and other status-related things are ignored.
Both reports and dashboards have their place, and I won't repeat what others have already said about the differences between the two and the merits of each. No, I have a different rant about web-based publication, including dashboards: it's the arrogance of "You're not worth the time it would take me to send you something, so you'll have to put in the time to come get it from me". The developers posting on the ElasticSearch mailing list obviously suffer from it, and it's rampant throughout every industry where one entity holds information that multiple other entities depend on. For example, take the health insurance business...
In the old days (pre-WWW) when an insurance company needed to inform health care providers about a change in its billing policies it would mail letters to them, publish the changes in a monthly newsletter, and include a "check stuffer" with every remittance it sent out to make *sure* word got to them. Providers who did business with that company had only to open the mail to get the news, and there was little question about whether they were getting the message. Might a provider's clerical staff have to sift through a lot of that stuff? Sure! But they had to open the mail anyway, and while it was a bit tedious to read everything, all the news they needed was right there in their hands and couldn't be missed.
Then the WWW came along, and now those insurance companies gleefully tell providers that everything is on-line for their convenience. Well that's nice, except that there are something like 1,500 health insurance companies in the US and God knows how many third party administrators who manage millions of groups. Is a health care provider's billing staff really supposed to log in to thousands of websites every day and click through five or six layers of menus to see what the latest updates and changes are? Well, they'd better! If they don't then the insurance companies reject their claims for having been billed incorrectly, and the provider has no right to appeal because "we published that information on our website months ago, and it's your responsibility to keep up with our policy changes". What used to be one entity putting the effort into pushing information to thousands before they needed it has turned into thousands of entities having to guess at whether/when they should put effort into retrieving information from that one entity, in many cases deciding that they'd better do it daily. While that may save the insurance company lots of money it *adds* to the health care provider's administrative costs, turning into a colossal waste when multiplied across all the providers out there!
While it may greatly reduce the expenses of the information-holder web-based publication does so by distributing those costs across all of the information-seekers, which may cost that community more in the long run than the information-holder saves. Regardless of how the costs are spread around, from a customer service perspective web-based publication fundamentally represents the owner of information telling the receivers of that information that they're beneath notice, and not worth the expenditures necessary to *ensure* that they get the information they need.
I want reports because I am the customer, not you. Stop telling me I don't need something.
I think it's pretty clear at this point that news reporting is not relevant.
Sorry, missed the reporting bit - sounded plausible.
Slashdot: stuff for news, nerds that matter, matter for news, stuff that nerd
Open the dashboard in a web browser, take a screenshot, export it to JPEG, and send it as an e-mail attachment.
Please hold while I laugh myself sick.
It doesn't matter if they never read them; they are paying you to maintain them.
And yeah elastic search sucks for doing reports, that's why RDBMS has been very successful. So if RDBMS isn't cool enough for you, take your elastic search data and drop it into Hadoop and run your analytics off that.
But honestly it sounds like you're at a cool startup, but really don't have any actual business experience.
Did you actually buy your /. id?
But if the management wants their reports, you let them keep them, and you keep that in mind when you change technologies.
If your clients want reports, you don't have to do that, but they don't have to keep you as a vendor either.
This post embodies the idea that sufficient incompetence is indistinguishable from malice, regardless of whether or not it was a joke. I felt upset with you as I read this. So, if you are trolling -- and I hope you are -- well done, troll. Well done.
Otherwise, please leave Slashdot and any software development or IT related industry.
Obviously folks are trying to fit a large square peg into a small round hole.
The best of both worlds: In Splunk, all you have to do is create your report, click "Save As" and select "Report", select a schedule, a group to email it to and "Save." Not so hard. You could continue and then "Save As" a Dashboard Panel and slap it into either a new or existing Dashboard.
It's simple. Your clients are asking for emailed reports. Therefore, emailed reports are still relevant. If you think there's a better alternative by all means, show them. If they still prefer the reports then the reports are still relevant. Q.E.D. Geez, why is this even a question?
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
You don't give management all of the information they need as it creates a reporting burden for no reason. They don't know how difficult the reports are to use and they won't use a dashboard because that means they have to think about the dashboard instead of the decisions they are trying to make.
If you have management that wants reports, you ask them what they need to decide on and then you ensure that they will get *that* information without all the fluff. It doesn't matter whether or not anyone here thinks if dashboards vs reports are relevant, is it relevant to the user of the data? Unlike sales dashboards where management knows what they are looking for, they have now idea what technology articles they need, so until that day arrives, reports based on what decisions they have to make, are.
And that is what you have to say.
My ism, it's full of beliefs.
IMO, writing reports is a manager's own damn job. If you can't write simple SQL to report on your direct's performance, why should you believe the report they wrote is accurate?
so that lazy and clueless managers can micromanage without any intellectual effort, or even needing any experience or knowledge of the actual business needs or processes - just wait until the realtime gauge or graph flashes red and you know it's time to whip the peons into shape.
Helped develop the original reports and assisted in the translation to Dashboards. Watched managers overreact when they didn't understand threshold settings and the years of requests to build into the display the Management Logic to show when there was a problem.
Not sure what we need managers for other than someone to pay extra and yell at. The parameters of performance are coded in. A trained ape could do it easily, except a trained ape would tear someone apart if they had to put up with the abuse.
TPS reports are vital. And don't forget the new cover sheet.
Neither of which your CEO, President, VP(s), Sr. VPs, or Directors want to do or learn, nor should they have to.
I'm not sure what you're talking about. I am in network operations. The CEO/President/VPs/etc, don't ask for such reports from logging/monitoring systems.
I am not sure what they would want to do with the data anyways..... the kind of information that can be gathered by monitoring is mostly only actionable by IT management.
It's not like they're going to turn to page 36 of some report, and start asking us what's the deal about latency increasing from 5 milliseconds to 10 milliseconds.
And then you've got a shitty looking report that looks just like your desktop. Complete with that one risque tab you opened to search for "girls of burning man," and a small fragment of an IM from a coworker that reads "...who the fuck knows with those guys? bunch of morons!"
Yeah, screenshotting is clearly a better solution for sharing the report with a wider audience.
That's true.... I wouldn't worry about it, however... it's just an aesthetic issue :)
Are they ok with automatically generated and mailed reports, or do they expect you to manually predigest the information and draw conclusions for them (with pretty colors and maybe a cute animal picture at the bottom)? The first is a perfectly acceptable and legitimate request, the second, while extremely common, is not.
Neither of which your CEO, President, VP(s), Sr. VPs, or Directors want to do or learn, nor should they have to. That's what underlings are for, and they don't want their secretaries doing it either (should they have one). Their time is too costly to the corporation for that, and yes, they will all pull data from that report to make another report.
Even the manager above you wants a report they can easily revise history, put political spin on facts, merge, and send up the chain; it makes reporting on multiple projects a lot easier to do.
/quote>
FTFY
A good report is decission tool wich contain data just like a dashboard, but it has also added value by conclusions made by the reporter.
Putting data in the proper context with background info is not easy to do with a dashboard. If one manipulates a dashboard on purpose to tell the story behind the graphics, one is already creating a report.
While driving a car, one needs to know the speed: Dashboard.
Fuel expenses: Report. First 3 days of the month you were driving in the alps, which consumes more fuel then intercity traffic. Without AI, you need a reporter to make this kind of remarks.
Even the manager above you wants a report they can easily edit, merge, and send up the chain; it makes reporting on multiple projects a lot easier to do.
Just open the region selection tool, draw a rectangle around the parts of the data you want, Control + X, and then Control +V the picture into your report... . easy as pie ^_^
Or print it out, and they can grab scissors and cut out the data and paste it onto their report.
There are a lot of legit ways to handle this one.
It's not like they're going to turn to page 36 of some report, and start asking us what's the deal about latency increasing from 5 milliseconds to 10 milliseconds.
The CEO may not, but you're boss's boss might; or your boss might condense that 100 page report to 50 pages for his boss who might make it 5 pages for their boss, which might become an excerpt in the report that the CEO does read.
And that 5 ms jump to 10 ms might very well make it into a report to the CEO if it caused a major issue for the organization, especially an organization that is solely centered around providing IT services to other organizations.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Even the manager above you wants a report they can easily edit, merge, and send up the chain; it makes reporting on multiple projects a lot easier to do.
Just open the region selection tool, draw a rectangle around the parts of the data you want, Control + X, and then Control +V the picture into your report... . easy as pie ^_^
Or print it out, and they can grab scissors and cut out the data and paste it onto their report.
There are a lot of legit ways to handle this one.
While those may work, they are neither desirable nor sufficient for the kinds of reports that management uses.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
The CEO may not, but you're boss's boss might; or your boss might condense that 100 page report to 50 pages for his boss who might make it 5 pages for their boss
My direct boss is at the top and doesn't have any bosses, and while there is information about IT disseminated, I believe it is mostly all financial in nature, or related to the performance of individual workers and the performance of networks with regards to uptime and usage. There are no "Reports" gathered directly from any IT central logging systems, which are mostly applicable for troubleshooting issues anyways --- summary information from a central logging system, simply has nothing to do with running IT or the company, other than maintaining the logging system itself.
In other words... it's probably a report nobody needs anyways.
But if you do, your department should probably be writing custom scripts to gather and report on the data, just as they apparently have.