Axapta from a Navision users point of view.

Hi all,

this is not a new topic, but one that we never really have a resolution to, and probably we are not likely to see an answer to, but I would like to discuss it again.

I am working with a company that were ready to implement Navision, the driving reason is that they want to use LS Retail as the front end for their operations, and they have experience with NAV, and know that it is a good solution for them. The issue is sizing and performance. This is something we here all the time, i.e. NAV maxes out at 3 concurrent users, and Axapta runs 27,000 conncurrent users posting sales invoices on a single CPU server with one hard drive. OK I am exagerating, but sometimes the “facts” out there are little more than numbers made up on the spot.

So I would like to hear from people with experinece with BOTH products, and lets try to get some rational ideas together to decided where the real cut off is.

In a retail operation, the decidion for NAV Axapta is not likely to be the number of stores (assuming offline stores), but infact the number of concurrent users in the back office, and of course the number of transactions posted to the financial database. Also of course we need to factor in the sales value of items, since an ERP systme really doesn’t care about the price you sell an item for, nor (too much) about how many of an item you sell, its the number of transactions per day that matter.

I think its fair to assume that in a reatail environment, there is not a great need for a high level of customization in the back office, since the biggest requirement will be reporting, not data entry. But also I would like opinions on developement, i.e. is it true that typically development in Axapta is abotu 3 times that of NAV, or is it just that “typical” Axapta customers have more money to spend, and thus do more customizations.

Also I know that this topic leads to a lot of opinions, but really I would appreciate that we keep this concentrated on real world expereince, and please compare what you know abotu Axapta to what you know about Nav, not what you read in the marketing litureature somewhere.

Thanks.

PS in this case I am using retail as an example, but please lets look at ALL applications where either Axapta or Navision could suit the client, and a choice needs to be made.

PPS if your company was once oriented to one of the products and is now biassing towards the other, then your comments would be most appreciated, even if the reason was related to revenue and profitiability, we still want to hear it.

I wonder why this topic is so quiet?

I can give you some functional comparisons, and probably some unsubstatiated differences, from a functional consultants perspective, but the question seemed more technical or for customers, so I did not want to muddy any waters! Just let me know.

No please any and all comments will be welcomed.

We went live with LS Retail 4. sp3 for a client with really high volume of transaction. 80 Location (Stores) 20 K of item sales on average per store per week. Navision couldn’t handle the details and we had to combine the items as they were imported into HQ. One Sale entry per Item per week per store. It comes down to 1000 entries per store per week compressed. We went live with a 50 Gig db. We have been doing a lot of performance tunning and so far it’s going. Big issues that we have seen is performance. They have 150 K items and replenishment (MRP) was running for ever. So spent a lot of time tunning MRP. Post the Sales was taking for ever. Spent more time on tunning. They create a lot of transfer order and HQ warehouse has to replenish all the stores. Locking is a big issue. The client runs an unusual retail system. They run stores on cruise ships. So replenishment with moving targets. Plus they reconcile with every ship at end of every week (voyage). Right now all the modification are done at for HQ so very little needs to be done once we implement navision at the Stores. It has been a one year implementation. I don’t know how long it would have been on Axapta. Another example. LS Retail was implemented for a client for one store and HQ. We implemented it in 4 months and everything went great. Client has stores all around US, they deceided to go with Axapta. :frowning: The project went over budget, and they are still not live. Navision is still running for one store. There is nothing preventing them to install Navision clients at other store and start replication. I wouldn’t call the Axapta failure totally Axapta fault, the client isn’t managed well. Another example, We implemented LS retail for a client with 80 Stores. Low transation volume, but Serialized inventory. 50 gig in first year. Very complex POS rules. (they were selling phones), which had to be activated etc, (It takes about 20 min) to sell the phone. Major issue was replication, (they scanned customer driver license and we stored it in customer picture blob), LS retail would take 5 time longer to replicate. I would say most of retail implementation are challenging compared to standard GL, AR,AP, Manufacturing. It is a lot harder to support as well. For example client calls and says, replication stopped working. And you have to spend hours finding why it has stopped.

I worked with Rashed on a few of these projects . I would say that LS Retail replication allows NAV to scale to levels that I think you usually only see in Axapta.

LS Retail replication on NAV is difficult to support and implement, but from what I have gathered, is still more likely to result in a successful go-live than any Axapta implementation.

I wonder why so many AX implementations fail? Is it just that the projects are require better managment? Are there fewer skilled implementer out there? Is the product crap [;)] ?

Adam woud you please tell us about some of the functional differences?

Thanks Rashed and Girish,

This helps me a lot. basically the client wants to go with NAV, but need to o due dilligence to see if this is the right way to go. They will have around 250 backend NAV/AX users, and will start with 200 stores, but expect that to grow very rapidly.

So it also comes back to Girish’s question, are there more AX failures by % than NAV, and IF so then is this just because NAV now has so much more history, and so many more good experienced consultants? Or is it all just hype?

Disclaimer first. For anyone who knows me or who I work for these are personal opinions based upon my last 8 years in the Dynamics channel, they do not reflect my current employer. Also some parts of what I say maybe outdated, or I may repeat something I have “heard” rather than have experience of, my apologies, I am not perfect, I will try and put down as much as I can, but feel free to correct me [:D]

Background second [:D] I am Navision centric, have been for 8 years now. I am now a certified AX Solutions Professional, (They moved the goalposts on the NAV one so I have now dropped out of this but still have lots of exams!) but do not be fooled into thinking that as I have passed some exams I know the product in-depth, this can only come with experience, and I have 9 months of it with AX. I am a functional consultant, I deal with trade and logisitics and manufacturing. Coming from the NAV world it will not surprise you to hear I have also done Finance as well as some basic development (report writing, data migration with dataports, development I should not have been doing etc) and I also worked first line support in the last company, so I have experience of that side as well.

Starting with the sales side there is a 5% difference in the license fee between the two products as a guide, there are of course different ways to sell them, but that is my understanding, so even on a large budget the software element difference is small. You also get more for your money with AX, but I will come to that in the functional differences. The user count, whilst always argued, I honestly do not find that relevant. Whilst there will be exceptions I am aware of NAV sites of 200+ users and AX sites of less than 5. Historically the difference in the products was always defined glibly by users, “if it is 100+ you have to go AX” etc. What should be considered at greater depth is the size and scalability of the database, in todays market business can transact 1000’s of entries an hour/day and it is the capability of these solutions to handle this requirement that is key.

I have no experience on the retail side so I can give no comparison between the two, you will need to read the previous postings for some information there.

Having worked in the NAV side and now the AX side the difference I see in the projects is simply size, it takes more man days per compariable project to implement an AX site than a NAV site. This is using the Sure Step implementation methodology of Microsoft, although even they have a fast track, which frankly AX cannot be used with in my opinion. To answer they questions of girish.joshi why do so many AX implementations fail, well first where is this source of information, do we have any figures comparing to NAV? I would guess not, it is very difficult to judge what is a failure and then where the balme lies. My experience in the NAV world has seen many implementations start and conclude, at the smaller end, without the customer having a project manager. This would not be the case with AX, the projects are bigger because more decisions are required, and I would say an AX implementation is far more likely to fail without one than a NAV project, but please customers, give yourself a chance and have a project manager, and if you are feeling generous even give them the time to do the task. So are there fewer skilled staff on AX than NAV, again difficult to comment worldwide, it depends where the need is, what I will say is in the UK there is a shortage of skilled staff across the entire Dynamics suite. This is being addresses, in part by Microsoft, but mainly by the partners who badly need the resource. I am aware of consultants being trained up from other software; Sage, SAP, Baan, etc, but this is a common aspect of the business we are in. I would though say the shortage is comparable on both sides and I do not see this as a factor of differentiation between the two. As for is the product crap, my simple answer is no.

Okay, the functional stuff, try to remember I am NOT an expert, so all errors are my own! AX5 is due out later this year, so for this I am comparing AX4 to NAV4.

User Interface

The menu suites are the same to look at, slightly different to modify.
I struggle with AX navigation, it seems a little clunky, however this could simply be personal experience bias.
The AX screens are too large for standard resolutions at times, although you can hide the at the click of an arrow rather than through view. You can also open a new workspace, a new separate version of what you are running. Ultimately I find AX asthetically more messy than NAV, but it is a personal choice.
The filtering in NAV is more slice and dice, it is quicker if you know what you are doing, but AX has the ability for you to save these filters and then you pick them again from the same screen.
The designing and setup of the forms is per user and involves all fields in AX, not just the line sections for movement, it requires more development in NAV and it affects the form, not just the user.
You can create a template in most places in AX, once activated you are prompted each time. NAV templates are a later invention, which take a lot more setup, arguably making them more flexible, but different. Not sure if the master templates came into NAV at 5 or 4.
Function keys and lookups/drill downs work differently, which is a little annoying, but hey who uses both?

One thing I will say is the products are becoming more and more alike from a user perspective.

Overall

AX has a series of layers where the objects are placed enabling different objects to be placed in different layers, with the lowest layer being the object taken. This is different from the object handling in NAV.
I have a vague memory telling me that AX has an advantage in a global role out, different language sets can be used within the same database, or different localisations can, or something, which gave it an advantage over NAV in this area.

I will put some details in the following areas later [:D]

Financial
Inventory
Production

Thank you, Adam! Very helpful. I’m looking forward to your next post on this…

Thanks Adam, that really is a very good unbiased review. Keep it coming.

[Y]

Thanks. I liked

Can you tell us more, Adam?

Bravo!

I’ve always wondered why AX took so long to implement and why it took so many man hours. Keep em coming Adam, perhaps you should start a blog post about this?

Strangely Alex David set me up with a blog a while ago, all I needed was a subject which never came, perhaps this is it - my experiences on the AX conversion from NAV route [:D] Only my technical ability now to let me down!

I will get around to this, it is just the time. I promise by the end of this week (Sunday [:D]) to have posted more - honestly!

That would be great. BTW carefull of such promises, I had planned to do the next installment of my 10 diggers digging a ditch blog on Sunday, but then the Sun came out and just ruined that idea [:D]

Okay my attempt at finance is done [:D] Inventory comparisons coming in 2009!

It is now in a blog which you can find here:

http://dynamicsuser.net/blogs/adamroue/archive/2008/03/14/the-differences-between-nav-and-ax-microsoft-dynamics-part-ii-finance.aspx