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
Do you know what problems they were solving with those reports, or did you just assume that a dashboard would solve them?
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)
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
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.
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?"
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.
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.
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
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.
Sorry, missed the reporting bit - sounded plausible.
Slashdot: stuff for news, nerds that matter, matter for news, stuff that nerd
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.
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.
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.
As I mentioned in a reply before: we did supply our internal clients - management - and our external clients with what they wanted. That's our job and I'm well aware of it. The question was asked to see what's the status of reporting and if it is loosing grounds to dashboards, and how the IT community feels about it. From the comments it seems that the question was well worth asking.
Why would I buy a /. id?
It is me, none else but me. And who would you be?
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.