Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Comment Re:Hmmm ... (Score 1) 179

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.

Comment Re:Hmmm ... (Score 1) 179

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.

Comment Re:Hmmm ... (Score 1) 179

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.

Comment Re:Hmmm ... (Score 1) 179

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.

Comment Re:static versus dynamic, access & post proces (Score -1, Flamebait) 179

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.

Comment Re:Hmmm ... (Score 1) 179

"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".

Slashdot Top Deals

An authority is a person who can tell you more about something than you really care to know.

Working...