Best Approach to learn Navision

bijaljambusaria

Hi All...

From the time I have joined this forum, I see lot of people having different views about any topic posted. Now, I would to know what is your view for this...

"When a new person starts learning Navision, what would be the best approach for him to learn so that he is able to design good, acceptable and most importantly "Logical" system in any project"..

I think only reading books and passing certifications is not what is required to build a strong system. There is something more to it...

Waiting for reply from all...

kine

Best is to include this person into project team and let him to assist others in their work. Let senior workers to share their knowledge etc.

bijaljambusaria

What if the senior person himself is not developing the system logically? He will lead that person to a wrong direction

ssingla

If senior person guides junior in wrong direction then only God can help the junior [-o<

bijaljambusaria

All these are okay but I am still not able to find good approach to learn Navision

kine

If there is nobody who can teach the junior, he must learn himself. Yes, there will be mistakes, but these can be eliminated just through experiences (own or by some good senior...)

Joseph_Abou_Nader

kine wrote:

If there is nobody who can teach the junior, he must learn himself. Yes, there will be mistakes, but these can be eliminated just through experiences (own or by some good senior...)

That is how I learned myself...with the help of forums like MIBUSO, and microsoft partnersource...

What I can say...is that practice makes perfect...and mistakes are part of everything...but the most important thing is to learn from the mistakes and improve. There are lots of resources (other than books) that address fresh Dynamics users which might serve as an alternative to a Senior... [-o<

bijaljambusaria

There are lots of resources (other than books) that address fresh Dynamics users which might serve as an alternative to a Senior...

What are these other resources? :-k

Joseph_Abou_Nader

You are posting in one of them... ...

Microsoft Partnersource and the discussion forums are an excellent way to learn and get on hand experience... :idea:

ssingla

You can see the standard database and analyse the way of coding, the variables, functions used. Standard reports helps a lot in developing new reports. Very rarely I have found functions which are not used in Standard Navision , All I need is good design and look where similar functionality exist in Navision to guide the technical person.

Miklos_Hollender

Actually I think it is lifelong learning, therefore there isn't any roadmap.

In the first years, it's mostly taxonomical knowledge - how the standard works and what are the best ways of development. Later on it becomes an art, a Zen of Navision. Really. After 4 years I've thought I'm good but I've just recently watched a real veteran colleague solve a problem and I tipped my hat in deep admiration. The issue started out with a quite complicated sounding requirement and if it was for me, I would have suggested writing it up from scratch, 3-4 tables and forms and 100-200 lines of code. He solved it by mapping the standard Jobs - which I was deeply convinced just sucks and nobody should ever use it - module to the problem in such an amazingly artful way that in the end only a 10-minute change was necessary. I was just stunned. That's more than just swift, skillful Navision hackerdom, that's the true Zen and Art of Navision that can only be learned by much, much experience. So it turned out I still have much to learn.

Anyway, I'm sure the first step is understanding the database, the often used tables and the fields and figuring out the common design practices behind them f.e. how the foreign keys propage through the system f.e. the Document Type - Document No. logic etc. I would suggest starting learning Navision from the database, rather than from the user interface or from the code. Often functionality that is complicated in code is very simple in the database - such as Item Tracking or Reservations. Understanding the database enables you to write quick fixes and workarounds for the problems in the standard system, without having to understand some of the very complicated codeunits. It also enables you to write reports which take up a good amount of every project. Understanding the database also makes you a better application consultant - you can answer a question regarding whether Navision can do something or not by checking whether there is a field that seems to be related to the question (and if yes then investigating further). It also makes you a better developer, because Navision is very well designed from the structural viewpoint and it's a good idea to borrow their way of database design in your developments. The code if sometimes buggy and the user interface is often suffers from usability problems but the database structure is just first-class. And if you design the tables and fields of your own developments well then the code often just "writes itself".

kine

My learning roadmap: 1st day - pile of EDI documentation and one task - make a module for EDI communication. 2nd task was module for Purchase Reminders.

David_Singleton

kine wrote:

My learning roadmap: 1st day - pile of EDI documentation and one task - make a module for EDI communication. 2nd task was module for Purchase Reminders.

I was asked by a client to find an ERP package for them, we found Navision, and my job was complete...

Next task: Can you install it? Oh and we need to localize it to our local Regulations, Oh and can you translate most of it into our local language, Oh, and we do business quite differently, so can we customize stuff, Oh, and we really need to be live in 6 weeks.

And that was before Red Bull!

AH and the first customization required :"30 character is too short for the Names of our Items and Customers" \:D/

Kamil, sounds like not too much has changed.

Joseph_Abou_Nader

kine wrote:

My learning roadmap: 1st day - pile of EDI documentation and one task - make a module for EDI communication. 2nd task was module for Purchase Reminders.

What is your opinion in Microsoft Dynamics implementation tool?? Actually I use it while doing any implementation??

Alex_Chow

bijaljambusaria wrote:

"When a new person starts learning Navision, what would be the best approach for him to learn so that he is able to design good, acceptable and most importantly "Logical" system in any project"..

The best approach to learn Navision is in a classroom environment where the instructor guides you step by step on the syntax and the basic structure of Navision development.

bijaljambusaria wrote:

I think only reading books and passing certifications is not what is required to build a strong system. There is something more to it...

You're right. This applies to all areas in the service industry. A person that passes the CPA exam doesn't automatically make him/her a good CPA. A person that passes the BAR exam, doesn't automatically make him/her a good lawyer.

Certification is only the start, the rest you'll have learn on your own. If you have a one-size-fits-all road map on how to get "there", I'm sure all the CPAs, lawyers, Financial service planners, etc would love to pick your brain!

DenSter

IMHO, the best way to learn NAV is to:
1: shadow a very senior person for 2-3 months, who lets you actually touch the stuff they are working on
2: take the classroom training AFTER this, so that the things you learn about make sense, and you can ask intelligent questions.
3: try to get certified in the functional area as well as the technical area. It is important to be versatile, and to at least have a basic understand of 'the other side'
4: never ever think you know it all, always keep listening to others, they might have something useful to add

couberpu

kine wrote:

If there is nobody who can teach the junior, he must learn himself. Yes, there will be mistakes, but these can be eliminated just through experiences (own or by some good senior...)

Here! Here! :shock: ](*,) =D>

ara3n

couberpu wrote:

kine wrote:

If there is nobody who can teach the junior, he must learn himself. Yes, there will be mistakes, but these can be eliminated just through experiences (own or by some good senior...)

Here! Here! :shock: ](*,) =D>

junior user can always come to Mibuso to ask and learn before making decisions.

DenSter

that also goes for seniors and advisories

Waldo

What I always try to apply in our company is some kind of "coaching" principle.

First, educate them in the stuff they'll need (application, development).
When thrown in to the field, coach them a few months with whatever the have to do. The "coach" should be a senior consultant, which evaluates (by experience) the progress...

kine

Joseph Abou Nader wrote:

kine wrote:

My learning roadmap: 1st day - pile of EDI documentation and one task - make a module for EDI communication. 2nd task was module for Purchase Reminders.

What is your opinion in Microsoft Dynamics implementation tool?? Actually I use it while doing any implementation??

What is that? :-) No, our company has own methodology for implementation created on own longtime experiences.

Joseph_Abou_Nader

kine wrote:

Joseph Abou Nader wrote:

kine wrote:

My learning roadmap: 1st day - pile of EDI documentation and one task - make a module for EDI communication. 2nd task was module for Purchase Reminders.

What is your opinion in Microsoft Dynamics implementation tool?? Actually I use it while doing any implementation??

What is that? :-) No, our company has own methodology for implementation created on own longtime experiences.

It is the methodology followed by Microsoft in order to implement a Microsoft Dynamics product.They have Rapid Implementation Methodology (RIM) for Microsoft Dynamics NAV (formerly Microsoft Navision) which provides powerful tools that help certified Microsoft partners automate implementation tasks.

Check it here http://www.microsoft.com/dynamics/nav/p ... ology.mspx

Captain_DX4

Miklos Hollender wrote:

Actually I think it is lifelong learning, therefore there isn't any roadmap. <snip>

I agree with this sentiment a lot!

In South-Western Ontario (Canada), for the about the last six-months to one year, there is a real need for experienced NAV developers in the marketplace. Unfortunately for all the juniors, companies are looking for people with real experience. For once, getting a few grey hairs is a benefit! *hehe*

My learning started as a NAV customer when the company I was with purchased v2.5 with Advanced Distribution. I didn't even know how to write C in those days. *lol*

One thing that has been tremendous benefit for me over the past years supporting our customers on NAV is my understanding of how the other side feels, being the end-user and not a developer. I feel it has given me a great edge.

Another aspect I've been truly blessed with is working with an implementer who really knows her stuff! She and I are very resolute in how we develop changes for our customers, especially when to say "No" to the customer for customizations that would best be handled with the base product.

However, one final mark of a what will make a good developer, according to my implementer. The developer should be artistic. Never mind knowing how to code and knowing technically how things should be done. Apparently a sense for the artistic (music, drama, any of the art forms) gives an ability to creatively see the sense of a project and connect the code to the process. This can be more benefitial that I ever thought.

So, my thoughts on how to follow the path to become a good NAV developer:

1) Shadow the person doing the job you are going to affect, if you can. Become intimately aware of what you will change.
2) Align yourself with a really outstanding implementer, whenever possible.
3) Take art classes. Take up painting. Join a local drama club. Join a church or local choir. Even sing in the shower. Give yourself a creative outlet to encourage that side of your brain.

The code won't always be perfect, and you will always look onto past projects and think to yourself that you could have done better, but I guess you can only be as good as your life experiences to that point can allow you.

Miklos_Hollender

I have an implementation "methodology" which consists of the following: try no to commit the same error twice - or at least not exactly the same way

couberpu

Miklos Hollender wrote:

I have an implementation "methodology" which consists of the following: try no to commit the same error twice - or at least not exactly the same way

How many times you went to ask the same person, could be a he or she, out until that person say yes? I usually made a lot of "same" mistakes until I fixed it. But I could make it again. I think the key here is not stop trying and make every mistake count.