TM1 Forum

Hi Experts!

Just wanting to hear opinions on this one.
I have a client which is new to TM1. No one from them has used it before. What they've been using for years now is QlikView. I am the only one who knows the tool. Now we're currently designing the cubes for a particular model.

I am kind of shocked in a way because they're asking for cubes to contain an average of 25 dimensions each. Which I'm not used to. In my past clients, as I recall the most number I developed is below 15 dimensions for just one or two cubes only.

But in this client, they're asking me to contain different dimensions found in their sources.
I know that I have a choice. One is to explain that this is not a typical practice to contain cubes with ave 25 dims each. Another is to propose a creation of cubes with same measures but with with different dimensions, that's if they'll understand what I mean and what I'm trying to avoid.

But currently, it seems that, they want what they want. Where in fact TM1 is not of mainstream reporting tool.

It's just that, maybe, I should have a more powerful voice on explaining the normal practice up to what is least accepted.


Thanks.

Bunch

Generally companies hire consultants because they think the consultant knows a thing or two about the product and should have some pretty strong opinions about how to put it together.

I realise not every workplace is like that and it depends on who you're working with and the culture of the organisation (and country), but if the project manager has got even an ounce of sense they'll listen to your reasoning. Then if they do ultimately tell you to do it their way anyway, then you can't really be blamed. Some people just plain won't listen to sense.

But if you're not going to pipe up when you know a design is bad, then it's your fault when it runs like a dog and people can't make head or tail of it when they're trying to use it.

So yes, you should absolutely be telling them if you feel that the design is not right for TM1. And also have a high level design ready for what you think is the correct way of doing it, so that when they say "ok, so would should we do then?" you've got something prepared.

Thanks Martin. Appreciated.

bunchukokoy wrote: I am kind of shocked in a way because they're asking for cubes to contain an average of 25 dimensions each. Which I'm not used to. In my past clients, as I recall the most number I developed is below 15 dimensions for just one or two cubes only.

But in this client, they're asking me to contain different dimensions found in their sources.
I know that I have a choice. One is to explain that this is not a typical practice to contain cubes with ave 25 dims each. Another is to propose a creation of cubes with same measures but with with different dimensions, that's if they'll understand what I mean and what I'm trying to avoid.

But currently, it seems that, they want what they want. Where in fact TM1 is not of mainstream reporting tool.

It's just that, maybe, I should have a more powerful voice on explaining the normal practice up to what is least accepted.

Who exactly is saying that cubes should have 25 dimensions and where and why? Is this listed in a technical specification document for the project? If so why was the design specified? What are the actual user requirements? As in forget about technical specifications and cubes and concentrate on user requirements:
- what should the reports look like?
- how should the reports be able to be filtered and aggregated?
- what kind of ad hoc analysis needs or might conceivably need to to be done?

This is what should inform the technical design. The best design might be to have a lot less dimensions and more attributes, it might be to have a tiered cube design with "optimized" cubes with less dimensions for most summarized level reporting and "exploration" cubes to drill in to with more dimensions and/or more data granularity for analysis where sub-second query performance is not so important. The best design might be to have one size fits all cubes with 25+ dimensions but it is probably unlikely.

The key is to go back to user requirements and build a quick PoC cube and test this with end users, or if you have to with the Project Manager if direct access to business users is not available. If the users are used to Qlickview then their perception of what they "need" will be shaped by the tool that they know. Qlickview uses columnar processing and doesn't have a concept of multi-dimensionality or hierarchies like TM1 does. What in a TM1 cube might be an alternate hierarchy, attribute or additional measure will all be handled in Qlickview as additional columns.

That said if a large amount of "slice and dice" ad hoc analysis is needed then lots of "attribute based" dimensions may be the only way to go (especially if Cognos BI is the report delivery UI) as TM1 can't do ad hoc calculations with attributes anywhere near as easily as can be done with SQL in an RDBMS. But even still I would push to see whether this is really needed all the time versus a streamlined cube for 95% of all reporting plus a more detailed cube to dive into for analysis purposes.

Maybe it is just a case of interpreting or translating the requirements into "TM1 speak" and what is specified as a dimension is really a hierarchy for example once the requirement is properly understood. One thing is for sure and that is to get to the bottom of what the end user requires. If a poor understanding of the tool leads to a poor design and then poor usability and poor performance then it is the tool that ultimately gets a large proportion of the blame and that is always a shame and the reason for many project failures. So yes it is your job to speak up and have an opinion not to just implement whatever is asked without some intelligent questioning. If the customer doesn't understand the tool they have been sold then someone has to educate them and the time to do it is BEFORE a poorly thought-out design is in place not afterwards.