An opinion on the use of Dimensions

seckpin

I am with the end user environment now, but i was with a solution centre before and do have different opinion from our current vendor on how certain things should work in NAV.

Our vendor loves to use Dimensions as solutions to our company's requirements for information. Having bad experience with dimensions (e.g. slow performance issue, difficulties in analysis), i am very concerned about this approach.

I believe that the original purpose of Dimensions was to provide added information to G/L so that it is not needed to create multiple G/L Accounts and to facilitate analysis. The more Dimensions we set up, the more the users need to key in when entering a transaction, and the more processing it requires on the system, especially when we are using SQL db and may run into tables locking issue.

It seems that the vendor is using dimensions as an alternative to adding table fields and reports writing. To date, we have at least 17 dimensions set up in the system, with a few having "ever-increasing dimension values". For instance, they set up "Customer No" as a dimension (which will auto create the same code when a new customer is created), and also "User" as a dimension (to capture user code on transactions but have to be entered manually).

In my opinion, Dimensions should only be used for those with a "finite" number of values, i.e. information that we don't really change all the time, such as sales region. It should also not be used for information that we do not want to analyse at G/L level, e.g. if it is just some extra information to be captured, say, at Inventory module but will not be analysed in G/L.

I know that there are a lot of implementers out there who think of Dimensions in NAV as a solve-in-all super feature, but i found that they are only seeing it from the point of view of "giving the customers a solution for their requirements", and do not think of other issues down the stream such as operational efficiency and system performances.

Any take on this?

kine

Yes, for me the "dimension" is some "slow-changing" set of values (nearly fixed count). But all depends on how the reporting is done. If you want to use "generic" reporting environment, which is same regardless what you are analyzing, dimensions are good way, but with CONS (performance, data entering overhead etc.). If special reports for each analysis is ok for you, why to use dimensions? In this case, adding some field to the entries etc. is much quicker and with better use. But as I wrote, all depends on the specific situation...

Slawek_Guzek

Hi,

Using dimensions and minimizing number of added fields in the database is not bad approach. It makes things more conforming to standard, you can then use published patches without having them merged first.

Problem with dimensions and performance might be due to database problems itself, do not necessairly blame the number of dimensions. Difficulties with entering transaction data might be solved (at least partially) by using default dimensions.

Dimensions has one big advantage - they give you historic values on historical transactions. I mean once set during transaction they stay in the database as they was set, without adding extra field on ledgers, and modyfying posting routines.

On the other hand neither extremum is good. Assinging Customer No as a dimension makes little sense to me. This information is nearly everywhere, including G/L Entry. It might be justified if your vendor has some 3rd party reporting solutions, or if they want to have all information in one place. Once you start writting reports intensively using dimensions it is better to have them all in one place.

The best usage for dimension are 'slowly-changind' values IMHO, which don't necessarirly mean fixed or nearly-fixed in terms of dimension values count. Every situation when the transaction might change it's dimension is a good candidate.

For example. A Department in Company. You may work for X department for some time and all your transactions 'belongs' to X, then you move to Y, and since then all your transaction are marked by (proper) dimensions as Y-belonging. You will be able to retrieve correct department transactions information only by using dimensions, because your USERID code don't tell you anything about the past, without developing a history of USERID first.

Regards,
Slawek

David_Singleton

seckpin wrote:

...
In my opinion, Dimensions should only be used for those with a "finite" number of values, i.e. information that we don't really change all the time, such as sales region. It should also not be used for information that we do not want to analyse at G/L level, e.g. if it is just some extra information to be captured, say, at Inventory module but will not be analysed in G/L.
...
Any take on this?

=D> I agree with your opinion.

Dimensions are probably the most disastrous feature ever added to Navision, they need to be used with extreme caution. Generally when I see more than 4 or 5 dimensions, its because the original partner was too lazy to do the job properly.

The exception to this is in very small implementations, where the transaction volume will never be large, and thus the performance will not become an issue. But over and over again I see massive performance issues related to the miss use or over use of dimensions.

Does "..The Dimension table is blocked by ...." ring a bell anyone.

DenSter

David Singleton wrote:

Generally when I see more than 4 or 5 dimensions, its because the original partner was too lazy to do the job properly.

OR: partners that don't realize, or are in denial about, how big an impact too many dimensions can have.

Either way, not an ideal situation to be in.

Savatage

we use two dimensions and i wish we never did. but thank G*d only two (17 ouch)

Ledger entry dims are now 41,192,883 records
Posted Doc Dimentions are now 14,860,675 records
etc.
We don't even use them but to delete them seems to be a long long process at this point.
Just clearing these two tables I'm afraid error messages will pop up all over.

So we just live with it

themave

as and end user, I like dimensions, as a programmer I would rather change the code and add fields and tables, As a user, the fewer changes to the navision the better. Just try applying a service pack to a modified database, our last estimate was for $10,000 to apply service pack 3 to our 4.0 database.

if you have a problem with posting times, setting the proper keys can solve a lot of the problems, and paying to have that coded is way cheaper than paying to code in new fields, and then paying again everytime an update needs to be applied.

use standard navision as much as possible. resest the developers call to custom program everything. When I browse these forums, and users ask basic questions nearly always the first response is a program change, when nearly always a cleaver setup of standard navision could accomplish the same thing, for a lot less money and way fewer headaches down the road.

But the key here is the proper use of Navision, it does sound like they are carrying dimension too far, why would you use dimensions for customer numbers, when there is a built in navision number series routine specifically for that.

seckpin

Thanks for sharing your point of view, everyone! It provides a different perspective on things for me to ponder on...

themave wrote:

if you have a problem with posting times, setting the proper keys can solve a lot of the problems, and paying to have that coded is way cheaper than paying to code in new fields, and then paying again everytime an update needs to be applied.

Slawek Guzek wrote:

Problem with dimensions and performance might be due to database problems itself, do not necessairly blame the number of dimensions. Difficulties with entering transaction data might be solved (at least partially) by using default dimensions.

Frankly, i do not think adding keys will solve the problems. Excessive use of Dimensions for companies with high volume of transactions means that the posting of every process in every functional area will have to access the same tables (e.g. Ledger Entry Dimension, Posted Document Dimension, Analysis View Entry. etc.). And if the company uses Analysis By Dimensions, updating or even openining the Analysis View can take forever.

I think the so-called database problems, specifically for SQL db, are inherent in NAV, as it was built mainly for the native db and does not work well with SQL (i am referring to version 4 and before; not sure about the new version). I know that theoretically doing proper tuning on SQL db can supposedly solve this problem, but in reaility it's a different case -- but then, this is a different topic altogether.

Just being a devil's advocate here, the same statement can be said about the database actually -- do not necessarily blame the database for the performance. Sometimes, the problems actually lies in the application itself, or rather, how the application is implemented and used, and how it is designed to work with the database.

themave wrote:

But the key here is the proper use of Navision, it does sound like they are carrying dimension too far, why would you use dimensions for customer numbers, when there is a built in navision number series routine specifically for that.

We are still using the default Customer Number with number series. What they did was that they created a mandatory Dimension of Customer Number that will be auto-populated with the same numbers and set to "Same Code". I think they want the Customer Number information to be available everywhere to ease reporting and analysis.

Slawek Guzek wrote:

Using dimensions and minimizing number of added fields in the database is not bad approach. It makes things more conforming to standard, you can then use published patches without having them merged first.

themave wrote:

use standard navision as much as possible.

I do agree to conform to standard NAV as much as possible to ease furture upgragdes and fixes. However, keeping to this principle does have its side effect sometimes (e.g. doing workaround that require more steps for the users, use a lot of Dimensions impact performance, etc.). After all, standard NAV is built with the basic functionalities of a typicial trading company, but the business process of different companies and industries can be very unique. The cost of upgrades/fixes is one thing, but the invisibe cost of operational efficiency sometimes may be even more.

And just like what everyone here agreed, there need to be a balance to everything. Too much of either approach can be disasterous, if not now but in the long run.

idiot

Dimension is a pathetic attempt to mimic business intelligence ability, which is how it is being marketed & implemented by most partners.
Then there are checks like "Select a Dimension value..." where the system is able to be so specific about the error but unable to automatic update & require user to update manually.
I have removed Dimensions implemented by other consultants for some of my clients & improved by creating fields instead... Now the system works faster, database size growth rate is slower, filtering could be done directly...Everyone is happier.

Slawek_Guzek

seckpin wrote:

Too much of either approach can be disasterous, if not now but in the long run.

It is not a rocket science, but I fully agree it is the best approach - to find a proper balance, which of cource will be different in each environment.

idiot wrote:

Then there are checks like "Select a Dimension value..." where the system is able to be so specific about the error but unable to automatic update & require user to update manually.
I have removed Dimensions implemented by other consultants for some of my clients & improved by creating fields instead... Now the system works faster, database size growth rate is slower, filtering could be done directly...Everyone is happier.

You are happy... But is your client really happy to pay you for extra xxx hours or days for merging patches ant testing the merge instead of just importing objects ?

My general feeling is that sometimes, too often unfortunately, consultants/developers are doing customizations just because they can.

Regards,
Slawek

DenSter

Slawek Guzek wrote:

instead of just importing objects ?

When was the last time you were able to "just import" new sets of objects? There's always merging involved, and unless we're talking about an upgrade, this is usually a relatively small task.

Dimensions is a nightmare, I don't think it is such a bad idea to get rid of them.

Slawek_Guzek

DenSter wrote:

Slawek Guzek wrote:

instead of just importing objects ?

When was the last time you were able to "just import" new sets of objects? There's always merging involved, and unless we're talking about an upgrade, this is usually a relatively small task.

That was quite a while ago, but mostly because (most) consultants make customisations just because they can. Because they think (I suspect) that it is more 'professional' to make customization instead of configuring the product? Because customisation is better paid than reconfiguration and binds customer more tightly to the NSC ? Because they just don't know how to do the task in standard just by reconfiguring it? Because they don't know the word No, and putting into the database whatever stuff the customer just thinks about ?

Whatever. Putting too many customizations results in releasing the customer staff from thinking. And this always ends up with bad results.

DenSter wrote:

Dimensions is a nightmare, I don't think it is such a bad idea to get rid of them.

Dimensions are not a nightmare. Badly used or configured dimensions can be a nightmare.

Regards,
Slawek

David_Singleton

DenSter wrote:

Dimensions is a nightmare

I agree with Slawek, that sentence is just completely wrong!!!

It should be either

Dimensions ARE a nightmare or Dimensions FUNCTIONALITY is a nightmare

DenSter

funny David

Actually Dimensions is a pain in my butt every time I have to debug anything, every single time going through that fricking dimension logic.....

I don't care what you call it Slawek, but the way that dimensions are implemented in NAV just sucks, it is a bad design for some well intended functionality. I agree that the way you configre it matters a lot, but still, in the end it is not a pretty piece of functionality.

seckpin

Slawek Guzek wrote:

Because they think (I suspect) that it is more 'professional' to make customization instead of configuring the product? Because customisation is better paid than reconfiguration and binds customer more tightly to the NSC ? Because they just don't know how to do the task in standard just by reconfiguring it? Because they don't know the word No, and putting into the database whatever stuff the customer just thinks about ?

I do not think by just configuring standard NAV will fulfill the needs of most companies, unless you are talking about small implementations that only use G/L and not other modules. Of course, this approach works if the users are willing to perform more processes in the system, which translate to actually making their work more tedious than before.

As i mentioned earlier, every business process is too unique to have a one-size-fits-all kind of system. We do have consultants who do not like customizations and always go for the standard; throw in the management who is very cost-concious, all we get in the end is a system that is implemented based on workarounds, workarounds, workarounds.

Most of the times, users complain about making the business works for the system instead of making a system that works for the business, which is what implementing an ERP supposedly to be about (but i realized over the years that this seems to be a myth). It is a pity that people see the cost in terms of how much they are billed, instead of the hidden/invisible costs of operational inefficiency, staff turnover (yes, people leave because they can't stand a "stupid system"), customer satisfaction (because it takes longer time to answer customer's queries)...

But then, i digress... this is supposed to be about Dimensions, right? :P

Slawek_Guzek

I do not think by just configuring standard NAV will fulfill the needs of most companies, unless..

You're absolutely right, it will not fulfill all user needs in all cases. But I'm talking here about many situations, too many in my opinion, where some additional, sometimes small, sometimes bigger customizations are made to the code just without any serious justification.

Most of the times, users complain about making the business works for the system instead of making a system that works for the business...

Deploing ERP system in the organization can and should be used to 'straighten' some business processes. I believe that there are always elements of business process where ERP system should be aligned to the company processing rules, and there are elements of business process where company rules can and should be aligned to the way ERP system is working.

If you computerize or automate a mess, you will get nothing more than computerized/automated mess.

It is a pity that people see the cost in terms of how much they are billed, instead of the hidden/invisible costs of operational inefficiency, staff turnover (yes, people leave because they can't stand a "stupid system")

Yes indeed, I've met many times users claiming the system (NAV) is stupid. Most of them, after explanation how it works and, which in my opinion is quite important, why it works like that they changed their opinions. Usually after some time and getting used to new methods of doing the things in NAV they were quite happy.

...this is supposed to be about Dimensions, right? :P

Right...
My opinion is slightly different than DenSter, David and others, but they are much more experienced than me, so who knows, perhaps some time I will reach very the same conclusions

DenSter

Slawek Guzek wrote:

My opinion is slightly different than DenSter, David and others, but they are much more experienced than me, so who knows, perhaps some time I will reach very the same conclusions

But a very valid opinion it is Slawek, and we are all better for reading about it. You are raising a very good point about overdoing it on the customizations, which we could talk about in a separate topic.

Alex_Chow

Dimensions is a good demo tool. It looks great when you break out your dimensions to "slice and dice" the data anyway you want. Most prospects and end users that sees this usually have their jaws drop. Using NAV's SIFT technology, not only can you slice and dice, you get those data in real time! Who doesn't want that?

The idea of dimension is great. I think everyone that's contributing here agrees. However, it's the implementation of dimensions that is terrible in NAV.

Here are some problems I've encountered with Dimensions:
1. The end users does not understand management's intent for dimensions
2. Extra maintainence needed to setup master data and/or enter orders and journals
3. Adjusting improper entries posting with wrong dimensnions.
4. Extra hardware requirements and database space requirements
5. Bugs related to dimensions
6. The vague error messages that arise if the stars does not align
There are probably more..

If you think NAV developers are expensive, do you think it's cheaper to hire SQL optimization consultants when your DB grows to 2 TerraByte because of dimensions? Or to have to migrate and buy the latest and greatest hardware to support such a large DB?

I do agree dimensions has its usefulness. However, the maximum number of dimensions I will implement is 2, maybe 3, tops.

DenSter

I agree 100% =D> that is probably the most eloquent I've ever seen that explained, thanks.

David_Singleton

Alex Chow wrote:

...
There are probably more..
...

There sure are, but this is a good start, and very good explanation.

Slawek_Guzek

Alex Chow wrote:

...The idea of dimension is great. I think everyone that's contributing here agrees. However, it's the implementation of dimensions that is terrible in NAV.

Here are some problems I've encountered with Dimensions:
1. The end users does not understand management's intent for dimensions
2. Extra maintainence needed to setup master data and/or enter orders and journals
3. Adjusting improper entries posting with wrong dimensnions.
4. Extra hardware requirements and database space requirements
5. Bugs related to dimensions
6. The vague error messages that arise if the stars does not align
There are probably more..

1,2 and 4 are not implementation issues.

1. This is lack of user training. No matter how you implement dimensions the user will not be happy having to enter them without knowing the purpose. It will seem to him just another unecessary thing to do. As I said and you definitely know it default dimensions and dimensions priorities are some kind of relief to that problem

2. This is a business requirement driven stuff and has nothing to do with the implementation. If busines requires to know some information user HAVE TO enter it. No matter where and how, as a dimension, or as an extra field on the record.

4. Dimension record is relatively small (T355 Ledger Entry Dimension - max 68 butes, 32 bytes/rec on average assuming 8 chars in document no, dim code and dim val code, T359 Posted Document Dimension max 76 bytes, 40 bytes/rec on average assuming 8 chars in document no, dim code and dim val code), comparing to the record it is connected to, unless some 'intelligent other way' developer add extra fields. Dimensions don't have any SIFTs behind. So please don't tell us that the database will grow to 2 TB just because of dimensions....

If you think NAV developers are expensive, do you think it's cheaper to hire SQL optimization consultants when your DB grows to 2 TerraByte because of dimensions? Or to have to migrate and buy the latest and greatest hardware to support such a large DB?

Do you hire SQL admin just to optimize *Dimension* tables ? Do you think you can live without senior level SQL admin having 2TB databse in house ? Do you really think that cutting off dimensions an storing the data on the rows will save you such a big volume of data that you will be able to live without SQL admin or not to upgrade to the latest and really powerfull SQL server ? How much MORE will cost you SQL admin just because of big dimension table ?

Regards,
Slawek.

David_Singleton

Slawek, I am sure that Alex was exagerating when he said 2 Terra, but what he siad was 100% on the mark.

Its very easy to see 20-50GIG of data just for dimensions. But the absolute size of the dimension tables is not the issue. The issue is the overall impact that dimensions have on performance in large systems. Believe me when you have 100 users entering sales orders, the BIGGEST issue you are going ot to have is the blocking caused by dimensions, and to make things worse, even if your company does not use dimensions you will still have the same blocking issues.

For this reason you need to tune your system, AND spend more on hardware, AND spend more on consulting to make it work.

I am going to reitterate what Alex said:

Alex Chow wrote:

The idea of dimension is great. I think everyone that's contributing here agrees. However, it's the implementation of dimensions that is terrible in NAV.

PS I am curious, how big are the typical Navision implementations you work on? No of Users and DB size? Because in some smaller implementations dimensions can be usable.

Slawek_Guzek

Its very easy to see 20-50GIG of data just for dimensions. But the absolute size of the dimension tables is not the issue.

I know that very well. But it wasn't me who start talking about database size due to dimensions....

David Singleton wrote:

PS I am curious, how big are the typical Navision implementations you work on? No of Users and DB size? Because in some smaller implementations dimensions can be usable.

The biggest one was 130GB (at the time I left the company), up to 7.5k orders per day, ~100 users entering orders +web shop users, 1.2 items/order on the average. Batch order posting. 4 dimensions btw

The second big one around 70Gig. All the others were not so big.

I have another end example as well. 1GB database, 17 dimensions, and posting of single line was taking around 60secs..

Regards,
Slawek.

Alex_Chow

Thanks David. You post explains exactly what I was going to say.

The idea of dimension is good, but implementation is bad.

Yes, proper use of dimension is important and training is important as well. However, it's hard to expect data entry users to understand how to classify data when an order is posted. In addition, turnover rate for data entry users are usually quite high, you must take into account how much they can learn when a new batch of faces coming in when NAV is already up and running. It requires a lot more due dilligence on their internal managers than anything else. To compound the problem, if the manager leaves, the use of dimensions will most likely lost in transition.

Especially if the new users does not read the manuals you write for them or the company wants to train their employees inhouse. Not to mention deadlock problems...

Setting more than 2 (or 3) dimensions will net more problems than it achieves. IMHO.

David_Singleton

Alex Chow wrote:

...
Setting more than 2 (or 3) dimensions will net more problems than it achieves. IMHO.

Exactly my opinion.

Before Dimensions we had Project and Department and that was generally enough. Occasionally a client needed a third, and in that case I would generally add 2 to give a total of 4 so they had one spare. That code took half a day. Upgrading it was simple.

Now we have 2 globals, 8 shortcuts 4 in analysis views and infinite in total. but why?

In my opinion (and no its not humble ) if a company needs more than 4 dimensions then they should be looking at a proper BI solution and they should NOT be doing it in NAV. Building JOINS on SQL tables is simple, so go and do it all out there. Doing it in NAV is going to increase your costs.

IMHO (note the H this time) What they should have done is extended Deparments and projects from 2 to 4, and made that the limit.

Alex_Chow

David Singleton wrote:

In my opinion (and no its not humble ) if a company needs more than 4 dimensions then they should be looking at a proper BI solution and they should NOT be doing it in NAV. Building JOINS on SQL tables is simple, so go and do it all out there. Doing it in NAV is going to increase your costs.

=D> That pretty much sums it up in regards to requirements where you need more than 3 dimensions.

Creating and managing cubes is a lot easier than dimensions.

Slawek_Guzek

Alex Chow wrote:

However, it's hard to expect data entry users to understand how to classify data when an order is posted. In addition, turnover rate for data entry users are usually quite high, you must take into account how much they can learn when a new batch of faces coming in when NAV is already up and running. It requires a lot more due dilligence on their internal managers than anything else. To compound the problem, if the manager leaves, the use of dimensions will most likely lost in transition.

Especially if the new users does not read the manuals you write for them or the company wants to train their employees inhouse. Not to mention deadlock problems...

Alex, that IS true. But all the above are NOT implementation related problems. Removing or minimizing number of dimensions used does not solve problems like mentioned above.

What WE can do is to implement solutions like Jorg's solution with GUID as clustered indexes to minimize blocking or optimise table indexes, or tune the hardware and OS environment. Dimensions ARE flexible, they allow user to add just one more dimension anytime on its own, without writting sinle line of code, redesigning tables, etc. This is VERY BIG advantage to any customisation based solution, but has its side effects, and may lead and often leads to performance problems.

What we SHOULD do is IMHO not to tell "Don't use more than 2,3.. x dimensions because they are BAD, or BADLY IMPLEMENTED". Instead we SHOULD teach the users not only how to use dimensionsm, buty also what are the side effects. We also shoud teach users how to minimize usage of the dimensions in terms of reorganizing the structure. Suun after I started my trip with NAV I easilly agreed to create 4 separate dimensions (three with TWO values only, and one 'normal' with couple of dozens values), because I was not aware (as a junior consultant) of the consequences, and I wasn't able to convince the head of accountants to a bit more complex dimension structure, which I felt will be better but wasn't able to clearly explain why. The database soon became slow, but I don't blame dimensions (now) but myself, because the true reason was my ignorance at that time.

Regards,
Slawek

Slawek_Guzek

David Singleton wrote:

In my opinion (and no its not humble ) if a company needs more than 4 dimensions then they should be looking at a proper BI solution and they should NOT be doing it in NAV. Building JOINS on SQL tables is simple, so go and do it all out there. Doing it in NAV is going to increase your costs.

BEFORE any BI solution is implemented the data have to be entered and stored somewhere, right ?

Slawek_Guzek

Alex Chow wrote:

=D> That pretty much sums it up in regards to requirements where you need more than 3 dimensions.

Creating and managing cubes is a lot easier than dimensions.

I just wonder from what data you're going to build and manage your cubes....

BI solution is all about analyzing EXISTING data, right ? So FIRST you need to gather the data, and store them. Or I'm missing something somewhere and you are both happy to analyze /dev/rnd output....

First you start talking about bad implementation and blocking issues, now about data analysing in NAV or 3rd party solutions, which in my humble opinon is not related at all....

Alex_Chow

You do have valid points. It all boils down to the implementor that will be doing the implementing and support. If the implementor feels comfortable setting up 10 dimensions and can keep the customer happy with it, more power to the implementor.

For me, I dislike dimensions, from your postings, you seem to be a fan. I hate Vista, but some people loves it. We can argue about this issue until the cows come home.

The original post asks for an opinion and I think both sides has been expressed.

davmac1

I have always thought that dimensions were an unnecessary complication. Adding a couple of extra fields as was suggested would have been the better way to go.
Dimensions are also treated as part of the accounting process which for many companies it is not.