Comment Re:First (Score 1) 27
It's not about the size of the boat, but the motion in the ocean!
It's not about the size of the boat, but the motion in the ocean!
They meant this dude: http://en.wikipedia.org/wiki/P...
Compared to "it doesn't work at all under Linux"...
Please don't open that particular can of worms
The reasons why some people go through this effort of manually putting together reports is unreasonable management demands.
They want powerpoint slides in that specific format, using those specific fonts, having that specific logo in that specific place, using data sources which are not connected to each other, and God forbid if you put that graph 2 millimeters to the right. It would be the end of the world.
I can create reports really quickly, but they don't satisfy specific constraints, so results need to be exported and babysat to appease the powers that be. Formatting it accordingly is a PITA and no automated reporting can do the job.
Not to mention data sources which are not integrated for plenty of reasons:
- someone doesn't want to grant access to their data source for automation ("only PDF outputs, no DB access!")
- someone felt like using a DB was "too difficult" so they have spreadsheets for their data
- someone has an ancient, non-standard spaghetti code script set up and don't feel like leaving the 80s.
Sprinkle all that with political games that happen between teams and groups and you're proper fucked.
Geez, mate.
OK, the shade of PINK. The shade of GREY. The width of a line. The size of this font.
Better now?
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 longer exactly match the PDF export they had.
Yes, as a matter of fact I did, it was part of the new implementation BRD.
Let me know if you have other questions.
Oh yeah, add 5 minutes of work for a director (50 dollars lost) and remove 100 employees' man hours (1000 dollars gained), I see how that doesn't make any sense...
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 variables, where each group would use to enter their own shit and the report would crap out the pies and barcharts and whatnot, you know, the stuff everybody loves.
Without user-facing input variables (e.g. pick yer timeframe, choose thy region(s)) I would need to manage not 500+, but 5000+ reports. Kind of a bit too much for ONE FUCKING MAN.
Yes I have a powerful scheduling solution, with agents, configurable outputs and so forth, but those only go so far. Yes, I can even automate most of those variables (e.g. group A has variables x, y, z etc) but then a shitload of people would crash on my head asking for "a small change" which turns automation into manual workload and we're back to square one.
I taught them to go to $this_url and select $these_values and bookmark their selection, said "NO" to "can't you send it to me every week?" and done deal. If they cease visiting the reports after running them twice, that's not my problem, it's theirs.
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!
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.
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.
Reports can be neatly arranged into a web-based dashboard. Big bada-boom!
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?
Um... great question.
NOT.
If the dashboard isn't available, your environment sucks donkey ass.
If someone doesn't have access to the dashboard, then they either shouldn't have access in the first place or they need to be granted that access.
"Why would you want reports when you have a dashboard?"
Because a dashboard is a transient thing, which is a snapshot in time and which you can't look back for historical records.
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".
An authority is a person who can tell you more about something than you really care to know.