Ask Slashdot: Is Reporting Still Relevant? 179
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?
Unfortunately (Score:5, Insightful)
Re:Unfortunately (Score:5, Insightful)
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 (Score:5, Informative)
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 (Score:5, Insightful)
Not to mention, once it's in your inbox, you are no longer at the mercy of their downtime.
Re: (Score:2)
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.
You sound like this PM I work with. What's the point of using an issue tracking system if 20 people send you daily email reports? WHy don't you just take the 30 seconds and run the report on the issue tracker instead of having to read 20 different emails? It saves the entire team time, and not just you.
Re: (Score:2)
Hmm I may have misinterpreted what you mean, if you were talking about having a report automatically generated for you. But if you expect all of your direct reports to write you a report when you could just as easily generate a report yourself... well that's just a waste.
Re: Unfortunately (Score:4, Insightful)
Re: (Score:3)
Because managing a mailing list for each individual report is bullshit work, a waste of time that can and should be avoided. The managers in question can either set up and manage their own mailing lists, or log into a dashboard that remembers their custom view settings. They can even have the dashboard mail a copy once a week, but they have to check the boxes themselves. It's pull versus push reports.
The first option is never ever going to happen, no manager can be bothered to maintain mailing lists. The se
Re: (Score:2, Insightful)
Not your decision to make. The rest of your post depends from this.
Re: (Score:3)
Actually, it is in fact my decision to make, both because of seniority, because I know the systems best, and because we finally (FINALLY!) have a collection of managers that aren't completely clueless.
If you are not allowed to influence your own tasks, I suggest you find better employment.
Re: (Score:2)
I've been doing monitoring and reporting for the last 7 years, I know all of this from experience. Report mailing lists turn into uncontrollable messes quick
Are you serious? With modern software, managing a mailing list is brain dead simple. Anyone can add or remove themselves by clicking on a webpage. Have you ever used Yahoo Groups? Why is it that the people with the worst prima donna attitudes are always the most incompetent?
Re: (Score:2)
Didn't I just specifically mention that the only reasonable way to have mailing lists is for people to subscribe and unsubscribe themselves?
Unfortunately, if you've ever worked closely with anyone in management at a larger company, you would know that even this "ideal" solution is doomed to fail. Managers in general cannot be bothered to "do all that technical stuff" and will always ask some underling to do it for them.
They only understand powerpoint presentations made specifically to their individual needs
Re: (Score:2)
If only we had a way to.. automate repetitive tasks? Why, what a world we'd live in!
Re: (Score:3)
Re: (Score:3)
If my manager doesn't let me manage him from below, I'm going to skip straight past him and manage his manager instead. She'll manage him for me.
Re: (Score:2)
<sarcasm>Wow, I'm sure that attitude will land you a few good jobs. </sarcasm>
Learn to live with it: if your job description says "do X", then you're expected to do jsut that, regardless of what you expected your manager to let you do.
Re: (Score:2)
Actually I find that approach results in a very happy manager.
I don't really mention it at job interviews, instead I mention all of the things that it enables - the level of autonomy it gives me allows all sorts of fun, interesting and valuable work to get completed.
Re: (Score:2)
The geek with a 2x4 foot chip on his shoulder. (Score:5, Insightful)
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.
Re: (Score:3, Funny)
Re: (Score:2)
Not his job. It's ours.
Re: (Score:2)
In theory. In practice, it's more often a manager's job to validate their existence to other mangers via shiny charts with no referent to actual facts, until such time as the project falls apart, at which point they blame the workers and use their social connections (groomed via all those shiny charts) to obtain another meaningless management position.
No Worky (Score:5, Insightful)
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: (Score:2)
Re:No Worky (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
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.
So, I get where you're coming from and I tend to be of the same mind, I have found that sometimes it really does make sense to actually archive PDF copies of stuff outside of the system that generated them. This is usually best when that report actually gets, well, reported somewhere often due to legal reasons.
Imagine you have a system that generates tax returns from a database full of financial transactions.
Option 1 - a system that always contains an up-to-date set of rules for generating a tax return for
Re: (Score:2)
Precisely. If the OP could install the stack, he/she should also be able to automate report generation and delivery of the report, so that it can rot away a piece of disk space waiting until it is needed.
Re: (Score:3, Insightful)
Re: (Score:2)
Hmmm ... (Score:5, Insightful)
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".
Hmmm ... (Score:2)
Nailed it.
Submitter is trying to solve a different problem than what management needs.
Re: (Score:2)
Re: (Score:2)
Because a dashboard is a transient thing, which is a snapshot in time and which you can't look back for historical records.
I don't know which reporting environment you're doing your stuff in, but maybe you should change it.
What I'm using can save snapshots, provide historical analyses, even match current data against snapshots and provide changes with drilldowns.
Or maybe we have different definitions of "dashboard".
Re: (Score:3, Insightful)
That's not a dashboard, that's a reporting system that joins dashboarding and reporting. Dashboards are current transient data. Anytime you go back in time, that's a report. You just supported the OP's claim.
Re: (Score:2)
I guess it's a naming convention which has different meanings.
A quick look here (http://en.wikipedia.org/wiki/Dashboard_(management_information_systems)) brings this definition up:
"an easy to read, often single page, real-time user interface, showing a graphical presentation of the current status (snapshot) and historical trends of an organization’s key performance indicators to enable instantaneous and informed decisions to be made at a glance."
OBIEE (yeah, I know, Oracle, sucks, bleah, bad) refers to "dashboards" which contain live reports, but you can set filters for those reports in such a way that they don't modify every time you refresh the dashboard.
Anyway, nitpicking.
Re: (Score:2)
The connotation of "Dashboard" is that it may give you a trendline, but not necessarily be able to pull up trendlines for arbitrary time intervals.
There are of course dashboards that do so, but it is reasonable to argue that those are really dashboard/reporting hybrids.
It sounds like TFA is referring to a dashboard that is fully featured in that department. Few are, even these days.
In any case, if the product doesn't make autodefinition of intervals and side-by-side comparisons as easy for managers as pull
Re: (Score:2)
Agreed with everything you said.
I guess I was focusing more on the idea of online reporting versus document-based reporting. A PDF export is something that's static and quickly slips into obsolescence, also it's an uncontrolled document which might or might not be relevant a day, a week or a month from now. I had plenty discussions with people who used to export reports to PDF and challenge the online reporting after a couple months when, due to inherent changes in the DB data, the online report would no lo
Re:Hmmm ... (Score:4, Insightful)
You are just extending the same mind set. Why is what _you_ want more important than what someone else wants. Every position in my company uses data slightly differently. Admins want to know what is having problems and trouble shooting the right things, Finance needs reports to know whether they need to give rebates, marketing needs data to generate slides showing trends in performance, developers want to know if their latest patch is working (sometimes), etc... Sure, the admins and developers are probably more concerned with a dashboard like view which is constantly updating. The rest of the people want, and need, a static weekly report without having to go do something to get it.
When those automatic weekly reports get removed and replaced with manual steps, people tend to jump right to the "those people are just lazy" crap.
Re: (Score:2)
It's laziness because you add dozens, sometimes hundreds of man-hours a month which your company bills to people just because you don't feel like spending 5 minutes a week clicking on a fucking link.
Re: (Score:3)
That 5 minutes of work never existed before an IT guy made a change. The IT guy made the change without considering and/or caring that it added extra work to people. That is the IT guy being inconsiderate and forcing people to do more work, not people being lazy.
Re: (Score:2)
Absolute Bullshit. You added 5 minutes a week, every week, to the director, finance team, law team, marketing team, sales team, etc.. etc... And what did you gain in the process? The one IT guy can claim "I have an awesome dashboard" on Slashdot, because the rest of the IT team was fine with the old system.
Stop trying to exemplify your nonexistent business logic.
Re: (Score:2)
Yes, as a matter of fact I did, it was part of the new implementation BRD.
Let me know if you have other questions.
Re: (Score:2)
If it takes a person more than a month to create a report, you're doing it wrong. Seriously wrong. We could create reports much faster than that when we were writing them in COBOL and hitting discrete files on disk and tying them together ourselves. I understand some newfangled systems can do better than hand-coding COBOL and can use these novel relational databases.
Re: (Score:2)
I usually don't respond to ACs but you weren't trolling so there goes:
The complexity involved when handling reporting for a large(r) organization prohibits full automation. There will be groups which need different inputs and the same type of outputs, the simplest example being regions (EMEA, APAC, AMER and their subdivisions). Add hierarchy-based groups on top of that and everything turns into a nightmare to manage and automate. The most optimized solution would be to build a single report with input varia
Re: (Score:2, Insightful)
This.
You cannot verify previous numbers from an instantaneous dashboard. If the June numbers indicate a change should be made, and someone in August wants to investigate that decision, it's entirely possible they cannot recreate the data used to justify the initial decision.
I watched exactly this issue become a problem for a company last month. Their client tried to reproduce numbers they were given in a report using their dashboard. They dashboard data didn't match the report, and there was much conster
Re:Hmmm ... (Score:5, Insightful)
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 ... (Score:5, Insightful)
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.
Re: (Score:3)
Reports don't take additional time to generate every time you look at them.
Reports don't require a constant on-line internet connection
Reports still work when the dashboard server, database server, internet, electrical grid, etc. are all down.
I am a manager. I created a dashboard for our product that our operations people use. But when I go to management meetings, I need to present static data to the upper management. They don't want to sit and watch me enter date ranges and wait for data to come ba
Re: (Score:2)
The business is their client. If they were freelancing and pulled the same attitude, they would immediately be looking for another client to replace the one who just walked.
Re: (Score:2)
However, of course the effort doesn't always succeed.
Also, sometimes it's just easier to give people what they want than it is to convince them that they don't really want it. Sometimes you have to ask whether "being right" matters, or if it's harmless and easy to comply with a silly request.
Re: (Score:2)
I do think I know more about technology than management does. Management knows more than I do about how to run a business. Neither one of us has the entire picture. We have to inform each other as well as we can, so that our business decisions reflect good judgment across all of our areas of expertise.
Sometimes we have to explain things to each other, and sometimes those explanations need to go into depth. Some of my best moments in business have been when someone went to the whiteboard and effectively
Re: (Score:3)
This is absolutely true, but there is another factor (as noted by other posters) -- the effort required to read them.
It's the same as mailing lists vs. forums. The mailing list is fully integrated into my daily activities -- I am already reading my mail. I don't have to log into a forum, perhaps type a password, select the appropriate search (or use multiple dialogs to select the i
Dashboards are not Reports (Score:4, Informative)
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.
Re: (Score:2)
Obviously! (Score:5, Insightful)
'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.
Re: (Score:2)
Re: (Score:2)
Reports have their uses (Score:2)
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.
Re: (Score:2)
Reports can be neatly arranged into a web-based dashboard. Big bada-boom! :)
Re: (Score:2)
That's bad implementation right there. In my company, there's single sign on. Other companies could implement it too but hey... lazy management. Oops :)
Multipass --> Singlepass!
I am a report writer (Score:4, Insightful)
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).
Re: (Score:2)
I used to be in a laaaarge international bank as an analyst/reporter/model developer and I can concur with a lot of this.
Usually we had all the data/reports but then had to redo them to change format or whatever.
I've been flung "your cash-flow analysis is wrong" since it didn't match up with marketing expectations.
I remember we build one score card using dummy variables instead of weights of evidence like the rest in the company, and only because of that we got more questions about this scorecard than the o
Re: (Score:2)
My brother, uncle and boss is actually colour blind, and I always make sure to not put colours they have issues with where they could be confused.
It's not what I was talking about.
If I make a mistake in this area and a manager comes to me with that I will change the format immediately and without a word.
Reports still serve a purpose (Score:4, Insightful)
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.
Reports are often better than dashboards (Score:4, Informative)
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... (Score:5, Insightful)
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
Finance needs it (Score:2)
When I'd prefer e-mailed pdf (Score:3)
OpenID (Score:2)
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 [openid.net].
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
Re: (Score:2)
So, if I as a manager want historical data that isn't available right now, I have to submit a request to the dashboard provider to get that information? In what way is that better than digging into my archives and pulling out a report that was created back then?
ah... (Score:2)
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
Re: (Score:2)
You should have an export feature. If not, that's another problem.
And if your report logic is properly separating logic from presentation, you can probably make an export feature by simply spitting out the report data as a big blob of JSON.
Dashboards are a subset of reports (Score:2)
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
Reports are static (Score:2)
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 o
You need both (Score:2)
Of course reports are relevant (Score:2)
Reports can be saved. You can't save your current view of a dashboard.
Re: (Score:2)
Nice theory, but you're assuming the dashboard is only as big as the screen. That's a very poor assumption, especially if the user is on a 720p display. As to printing out the web page, I've had no end of problems printing out dynamically-generated pages over the years.
Always (Score:2)
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 n
Re: (Score:2)
If your database is corrupted, and somebody needs the dashboard data before the database is recreated or whatever, that's a problem.
Re: (Score:2)
I'm thinking more subtle corruptions than "nothing works." Silently putting in Mar.1 instead of Feb.29 on a leap year because of some bad math and nobody noticed until November when the accountant starts reviewing for your end of year. If you just look at the dashboard, it will only reflect what's in the database. On the other hand if you go back and pull the Feb.29 and Mar.1 reports, you (may) be able to distinguish the data from each day in order to manually correct the records.
Reports should only exist to solve problems (Score:2)
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 pr
Re: (Score:2)
Reports should only exist to solve problems.
Wrong. Submitter was talking about monitoring, not debugging. The subjects of his reports are operations; the idea is to look for opportunities to improve things, get an early heads-up that something isn't running as well as it used to, is getting close to capacity, etc. In other words - avoid problems, don't solve them.
Let me get this straight (Score:2)
Management versus development toys (Score:2)
Re: (Score:2)
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?
Yep, we're all iPhones now. So let's just stick our heads in the microwave -- and we'll even run 3x faster.
I'm just pulling this out of thin air. (Score:2)
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.).
I will defend reports to some extent. (Score:2)
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.
Is Slashdot still relevant ? (Score:2)
Why is this even a question? (Score:2)
Report based on decisions (Score:2)
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 thi
Of course... (Score:2)
Re: (Score:3)
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.
Re:static versus dynamic, access & post proces (Score:4, Informative)
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.
Re: (Score:2, Funny)
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.
Re: (Score:3)
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?"
Re: (Score:2)
That's true.... I wouldn't worry about it, however... it's just an aesthetic issue :)
Re: (Score:2)
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.
Re: (Score:2)
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,
Re: (Score:2)