Where is Dynamics NAV is headed ?

Alex_Chow

Captain DX4 wrote:

However, the core functionality that we've all come to know and love hasn't been eradicated,

Try and find Navigate on the 4.0 menu. Back in 1998, navigate was the main selling point of Navision.

Captain_DX4

deadlizard wrote:

Try and find Navigate on the 4.0 menu. Back in 1998, navigate was the main selling point of Navision.

True, but I can't find ANYTHING on the new menus! *lol*

johnson_alonso

I don't actually care about where is dynamics NAV is headed. what the h*ll happened. The important one is how to make dynamics NAV sales increase in all the world and especially in Indonesia, not action talk only must be avoided. new ERP concepts must be developed and it must be available in the new navision. Sometimes, there are many changes but no body does something that can be a reason to support the changes. In the customers side for example, how can someone knows their real requirements and benefit calculation ?

rgds,
Johnson Alonso

"live to work"

Shenpen

Captain DX4:

true enough, but the problem is that adding semi-serious new functionality is more harmful than not adding it at all, because partners don't have the resources to thoroughly test all new functionality from all possible viewpoint and find bugs, design flaws and missing integration points before offering it to a customer. Now, actuall, after 3 years of experience and troubles I had to realize that I must take the time for this no matter what, but most new partners I meet just think the way "If a granule's name is X and it promises to cover functionalities of type X then if customer has requirements called X it must fit, because Microsoft promises it to fit X and most of their products like Office or Exchange is a succes so we can believe it, can't we?"
Often I called in to help in the projects of other partners where the licence has already been sold and therefore they are trying to customize completely not-fitting functionality, such as Capacity Requirements Planning for a construction company, instead of developing from scratch or buying an add-on.

So the golden rule should be to don't misguide partners by offering anything that they might think will fit when it actually won't.

It even goes back to basics as the general user interface.

I mean when NF2.6 was a strictly financial product offered strictly for accountants and nobody else, these user interface standards such as Excel-like journals, complex documents and flowfields summing up ledgers was a perfect fit. It fits very well how accountants think and work.

The first, and most basic error was to introduce Manufacturing, WMS, Service etc. with the same interface standards as Financials, because warehouse workers, shop floor workers, service technicians etc. are NOT accountants. They need lot less flexible, a lot more strict, and and lot simpler UI. So for example, while General Journals fit accountants perfectly, taking that idea and offering Output Journals to shop floor workers is a completely ridicuous idea. Shop floor workers would instead need a big card-like form with 16pts font size and very simple fields, and no more than 5 fields, or, preferably, printing bar code to Job Cards for each operations, and record time automatically between scanning each operations bar code etc. etc.

Of course WE can do that, that's not a problem. The problem is that in my first year of consultancy I blindly believed Output Journals will fit just because Microsoft offers that functionality and Microsoft is always right.

And new partners I often meet also make the same errors.

So this is the problem that needs solving - don't offer confusing functionality, that people might think it will fit but it won't.

This is what MSFT needs to do: to offer a product that makes it very clear what it will fit and what not.

Shenpen

Some more on planning Navision's future, especially licencing:

MSFT needs to decide that Nav is a finished ERP product in itself, or just a bunch of building blocks for building ERP's? Or in other words, does pure vanilla Nav offer a reasonable ROI or add-ons just offer additional value for something that's cool enough by itself, or is it just a platform for add-ons and NOT meant to be implemented by itself?

My personal opinion is the later - for example, for a waste recycling company, adding the Enwis add-on to Navision costs about the same in licence terms as Navision itself and provides about 20 times as much value. So for a waste recycling company, for X amount of money, you got an amazing all-over solution covering completely everything, but for X/2, you got a basic accounting, invoicing, and inventory (because no other granules are suitable for that business) - almost nothing. So Navision price/value ration is MUCH lower than the price/value ratio of the add-ons - and this can only be justified by stating that Navision not just offers a bunch of functionality, but also a very productive development platform for the add-on. By this logic, Navision is not a finished product, but an add-on platform - partners get development tools for nominally for free, but actually when customers buy user licences for those users who only use an add-on and nothing in the standard, then actually that's where the price for the free development tools is paid.

So, a decision needs to be made. If MSFT decides Navision is a finished, full ERP product, then it should move towards user based pricing. However, it would kill the add-on culture and THAT in turn would kill the Navision market so I hope they don't do that.

If MSFT accept that Navision is but a platform, then the price of the standard functionality should be higher, but the price of users should be lower - MSFT should understand that the current licencing conditions for those companies, who use 10 users for accounting in standard Navision and 90 users who only use an add-on and nothing in the standard is unsuitable.

Captain_DX4

Shenpen wrote:

true enough, but the problem is that adding semi-serious new functionality is more harmful than not adding it at all, because partners don't have the resources to thoroughly test all new functionality from all possible viewpoint and find bugs, design flaws and missing integration points before offering it to a customer.

I think you're hitting the nail on the head, but you're using a saw instead of a hammer to pound it in. *hehe*

I agree there are plenty of Partners out there that are not conscientious to what they are selling to their customers, for a variety of reasons. Just because Microsoft offers a functionality that isn't clearly understood does not make Microsoft or the Navision application the "bad guy" in the scenario.

With the exception of Partners that would sell their grandmother's dentures (shady dealers that do not seem to care one bit about what's "best" for the customer), I see the biggest problem with new functionality in Navision is a matter of training. I feel it is the responsibility of the Navision Reseller to get adequate training on new features before offering to clients.

I work with an implementer who has a good history in accounting, and then has a decent history with Navision. She is very good at recognizing and reacting to the accounting principles in sales and support. And when a client asks about new features in Navision that are unfamiliar to her, she must spend the time looking over the details on Partnersource, downloading all the training material that she can, and testing a solution thoroughly before she can make recommendations to our clients.

For myself, I used to be a Navision user. I learned Navision as a client before delving into the development side of things. In this regard, I find that learning and understanding the functionality as it needs to be presented to clients comes more naturally for me.

Though time-consuming, self-training is absolutely necessary. I disagree with you about functionality added to Navision not being clear enough. I would be happy to see any examples you might provide that prove Microsoft was lax in giving adequate details about new functionality. The training and documentation has always been available that I've seen.

I find that users of products like Word, Excel, or Outlook are not a fair comparison. In those types of applications, the base function is constant. In Word, you always expect to be able to open the application and begin typing a document. The main difference in the added functionality for these other applications is they are intuitive enough because the base application is a very simple task. Plus, you can see exactly what occurs when you attempt a new function in Word, and always have the option to Undo. With Navision, new functionality does take some training and advanced planning to get them to work properly. Navision functionality is sometimes intuitive, but mostly is not.

Now, I will agree with your assessment that the growth of the product doesn't always seem clear, and that sometimes we get functionality that we'd rather not have seen. And yes, sometimes Microsoft gets ambitious to offer functionality that might be better left to third-party vendors to produce add-ons. In those instances, specialty designs from a third-party vendor who can offer sales and training support would make our jobs easier as Navision Partners.

Captain_DX4

Shenpen wrote:

*snip*

If MSFT accept that Navision is but a platform, then the price of the standard functionality should be higher, but the price of users should be lower - MSFT should understand that the current licencing conditions for those companies, who use 10 users for accounting in standard Navision and 90 users who only use an add-on and nothing in the standard is unsuitable.

This does seem like the best standard they could adopt. Unfortunately, Microsoft could also argue that without the base platform, the add-on is irrelevant and therefore worth more in terms of licensing. After all, they must support the base platform. *hehe* Silly for them to think they can justify this, I know, but this seems to be how Microsoft positions itself.

Alex_Chow

I agree with Shenpen in that Microsoft releases a lot of new feature and functionality that are unnecessary. However, from MSFT's standpoint, they need the product to have more features so they can say that offer more bang for the buck with Navision.

They probably also consider using Navision to push some of the other Microsoft server products to boost their sales.

At this point, I really believe the salespeople are managing the development of Navision instead of people who actually uses it.

Shenpen

"I would be happy to see any examples you might provide that prove Microsoft was lax in giving adequate details about new functionality. The training and documentation has always been available that I've seen. "

Available documentation is a general, theoretical study rather than a practical documentation on what business need can be solved with what functionality.

For example, it is not written anywhere how to scale the warehousing functionalities - when do you need just Locations, when do you need Bins, when do you also need Pick/Put-Away, and when do you need the full WMS.

So actually I ended up writing in-house manuals for this, something like:

"Use Locations only to represent sites, and not rooms, because if you use it to represent rooms, Req. or Planning Worksheets can bite you hard, as demand will not meet supply.

Rooms can be represented with Bins if no shelf-level warehousing is needed, in that case no additional warehousing granules are needed.

If Bins represent shelves then Invt. Pick is also needed, because in that case Sales etc. Lines need to be in a 1:N relationship to the Bins where the goods are. Invt. Put-Away is usually unnecessary however, because no one ever receives goods directly to shelves, and if you don't use it, you can Undo Receipts.

Additional warehousing granules are needed when clients want bulk shipment: picking more than one orders, usually everything that goes to one truck. In that case, a Posted Warehouse Shipment can also double as a Freight Route Document for the truck..."

... and so on, and so on...

But it would MSFT's job to write these manuals, not mine! I had to learn these by trial and error and a lot of trouble because no one wrote a manual from a such practical viewpoint. Manuals just list features and how to use them, but not list limitations (lack of Undo Receipt with warehouse documents had bitten me HARD in the past) and do not tell the typical business cases. So we have to reinvent the documentation. That's bad.

kine

I see one big problem in writing this kind of manuals: there is no some general company or situation. Each case has own solution and nobody is able to describe all cases and combinations. For example I know solution using locations as something other than physical location where the item is stored and using bins as something other than part of location. And this solution is very good for the purpose... It is very dangerous to say: this use if... because there are many cases when you need that and many when not. Each company needs own solution. Of course, if you sell some specialized Add-on which solve the problems completely, you can create such a manual. But for general solution like whole Navision ... #-o

Luc_VanDyck

davmac1 wrote:

Convergence will have its first European meeting in Munich in November. All the main Navision people will be there - so it will be worth going to if you could not make it to the USA meeting.

Check out this site: Microsoft Convergence 2006 EMEA

Shenpen

Kine,

you would be right if Navision implementations would be the similar to how the big boys (SAP, JDE etc.) do it: several hundred days, with a "research" approach, customers accepting that there is no fixed price, licence only configured after a month or so of analysis and design and heavy, heavy testing to find out the limitations etc.

But in reality Nav. implementations are bought by companies who want something one step upwards from the simple accounting/operations software they currently have that did not even need any implementation project.

Therefore, ususally on the second or third sales meeting a licence needs to be configured, days counted and a fixed price proposal be made or else it won't be bought.

Therefore we need to be able to design the whole system at least on a conceptual level based only very little information gathered on sales demos, which means one does need to know limitations very well and be able to quickly model all possible scenarios in one's head and build a mental model of the solution to be implemented to be able to make a proposal.

To be able to achieve this, one not only needs to think like a chess player, but have predefined mental models, template scenarios ready that can be a basic model for the solution to be implemented and then just offer a few dozen days of custom development and hope to get away with it.

kine

Yes, I agree with you. I just want to say that it is too hard to describe something like that. It can take 6 or more years of experiences with Navision to be able to do this mental model. May be the RIM will helps you in some way to prepare templates for some groups of companies...

modric

Seemingly the idea expressed hereabove that Navision development is salespeople driven explains the topic fully...

One more example - once you have ordered a license for a client, there is no way back in case it contains excess granules AND partner is due to pay for it at full extent. At the same time there is no such a thing as trial licence or so with which I could check if everything is OK for my assumed functionality. Of course, there exists a long list of what access rights each granule contains, but it`s at table/form/report level and it takes days to build the mentioned mental model.

Although I am not a newbie in Navision, sometimes its really difficult to figure out if client really needs some granules and how lack of them will affect the functionality - I`ve had a couple of cases, when it turned out I need some more granules, and the crossreference of them wasn`t straightforward and easy assumable at all.

I`ve heard at rumour level that Axapta has some method of "switching on/off" the licensed parts for testing purposes - if MS is going to melt together all current Dynamics product line in foreseeable future, let`s hope this one common Dynamics ERP will contain the best parts of it components

ara3n

wow these are realy heated topic, and great examples, problems, senerios. I hope MS is reading this and listening.