"What a nonsense and waste of time and money, all that modeling"

[RonvdP]

What a nonsense and waste of time and money all that modeling", that's what a user said.
We have a Kimball modeled data warehouse. But now and then the user asks us not to model information, just to earn time and money.

For instance they have to make a report on information, which is delivered in a dataset by a department. That dataset consists of all the information needed. Records can be read one by one to produce the report. So the user says: put it in a datamart in the data warehouse, and with our reporting tool we will read the table and produce the report. And ... if you want to keep track of the history, just put a month-key in the datamart. We are only interested in getting the information of the dataset in a report, that's all.

Of course the user should not interfere with the technical solution.
But what should be reasons to follow or NOT follow the technical solution the user suggests??

 

[Craig0201]

Of course the user should not interfere with the technical solution.
But what should be reasons to follow or NOT follow the technical solution the user suggests?? "

I think that summarises your problem nicely. You're doing things that you believe are right but have no rationale for doing so. And you don't appear to be adding much value.

"We have a Kimball modeled data warehouse."

As a user, I don't care how nicely modelled it is. I want the information to run my business.

"So the user says: put it in a datamart in the data warehouse, and with our reporting tool we will read the table and produce the report. And ... if you want to keep track of the history, just put a month-key in the datamart. We are only interested in getting the information of the dataset in a report, that's all. "

The user is right. They just want the information.

So the questions I have for you is:

Why aren't you producing the reporting? That's what the business value is, not the nice models.

 

[blom0344]

I think it is vital to establish the type of support this user may or not may expect. The basic problem with one-off solutions is that over time they are taken for granted and treated like the generic solution. And then you may find yourselve in a world of hurt if you need to find out specs etc. Make sure you get them responsible for their own private part and let them know what to expect in terms of support/updates etc.

Ties Blom

 

[MDXer]

Of course the user should not interfere with the technical solution.
But what should be reasons to follow or NOT follow the technical solution the user suggests??

Correct a user should not dictate the technical solution, but if the technical solutions fails to meet the needs of the business then the solution isn't much of a solution. A DW is an organic object that needs to grow and evolve with the business and it's users. My question is why ask here if as reasons to not follow, you should be asking business and your users what is lacking in the current system.

Like everything else in the DW world the reason for making changes to a DW vs and OLTP system are quite different.

I agree with Ties you should be creating the needed reports.

 

[JBroadwater]

Reasons to follow or not follow the users suggested solution:

To follow: the user knows how to generate her own reports and knows the pitfalls of putting unscrubbed, nonconformed data/tables in her datamart, and all other users are similarly knowledgeable.

To not follow: you know more than the user does. For example, you know that if the user joins this new table to one of your other data mart tables, the user may accidentally filter out some rows or may accidentally repeat rows, rendering sum() results incorrect. For example, you know the user may create a report grouped by a column in the new table, where the column has values incompatible with a corresponding dimension in your other model (and therefore the user cannot reconcile her new report with other similar reports). For example, you know that if you frequently add tables to the data mart you will eventually have so many tables that users will have trouble finding what they need.