Other skills to keep on with navision

lakshmivalluru

Hi,

What are the first five skills we need, to be a good navision developer other than C/AL programming? I mean like XML, SQL Server, etc. (You can leave counting Excel, MS word.)

ara3n

Knowing Navision from End user perspective. From a consulting perspective. This is the most important thing for a developer. Knowing how a modification will effect the overall system, and come up with solutions that are least intrusive.

Shenpen

1. Understanding the ERP concept.
2. Understanding general business procedures.
3. Understanding how standard Navision works.
4. Understanding what's going on behind the scenes (standard Navision code object configuration)
5. Understanding why it is going on behind the scenes this way (Navision best, or maybe not exactly best, but still generally accepted practices).

Programming skills, XML, SQL is not so important. Navision programming is very hard for Visual Studio junkies - a Navision programmer is not really a programmer, but a business consultant who expresses business rules "just by chance" in software code & object configuration.

lakshmivalluru

I have been in both end of navision world, worked for NSC and also for end user. All the points Shenpen pointed are ok. But surely we need to know SQL Server if we have to write queries on SQL tables for the clients,
for SQL server installation, and XML messages for web interface...

What do you think an NSC should see in a Navision Developer? I heard and faced personally some comapines does nothing to improve individual skills to make the develper more worth. For example if there is a developer who has already done a Navision implimentation on SQL server, they choose the same developer for the next implementation. Does not give another developer a chance.

Do you think with this new Dynamics we need to know abt Sharepoint, .net?

kine

Prepare yourselfs for all Microsoft technologies. Each technology you know is pro for you... (Biztalk, C# etc., SQL, .NET, XML, SharePoint, Office...)

johnson_alonso

I think the core of all is hat you must have a good product knowledge, it's a standard thing that all marketing peaople must know, and the product knowledge I mean here could be as same as what people here has posted in this topics, beside that you must have communication and presentation skills too. If you want to understand about ERP concepts you can browse this webs: http://www.apics.org.

Rgds,
Johnson

"there is a time for everything - Ecclesiastes"

DenSter

Shenpen wrote:

<snip>Programming skills, XML, SQL is not so important. Navision programming is very hard for Visual Studio junkies - a Navision programmer is not really a programmer, but a business consultant who expresses business rules "just by chance" in software code & object configuration.</snip>

Excuse me??? Pogramming skills not important?? That goes against everything that you are always complaining about in here! You HAVE to have good programming skills to do it the right way. You HAVE to know about XML because that's is THE way to communicate nowadays. You HAVE to know SQL Server, maybe not as much as a Visual Studio developer, but it is an absolute MUST to have a good SQL Server knowledge, especially going to the future.

For most of us Navision developers there is absolutely nothing 'just by chance' about the work we do. I think that is a very wrong generalization. Navision programming is not hard for VS developers either, as long as someone takes the time to explain the basics.

DenSter

Now I believe the initial question was about "other skills", so I'm going to skip the obvious ones related to Navision itself.

- General SQL Server knowledge, and how Navision behaves on it. T-SQL is not so important at this point, but you never know in the future. I would not spend any time learning it yet though
- XML. You must have a good working knowledge about XML. Buy a "XML for dummies" book and study what a well formed XML document is. While you're at it, also learn about XML webservices, that may come in handy too.
- Windows security. This may not be so important now, but we should all invest some time into learning about it, it is becoming important enough for MS to organize conventions around this subject alone.
- Windows networking, like AD, user profiles and things like that. I am constantly running into issues with security and user permissions, and every time it happens I wish I knew more about it. I'm not saying we should all become MCSE's, but we should know something about it.
- Office (Word, Excel, and maybe Outlook) and the object model
- Sharepoint, but only if you have prospects in that area.

For now it is not terribly important to learn any .NET language or Visual Studio, but it can never hurt if you have prospects in the application integration area. And who knows going into the future...

Shenpen

DenSter,

90% of Navision development goes into the "loop through a record set, do something with the values and throw them into another table" basket. Any 16 years old with a B degree in VisualBasic could write that - the hard part is knowing 1) the concepts (such as whenever we do something with inventory quantity, we need to take care of inventory value as well 2) knowing how the standard system works 3) the little magic tricks of object configuration, such as the AutoSplitKey property.

XML or SQL might occasionally be useful, but they are a whole order of magitude easier to grasp when necessary, than f.e. grasping how Inventory Adjustment *should* work and what *should* it do from practical viewpoint, not from the theoretical viewpoint of the manuals - after all, XML and SQL is properly documented while the later one is not, you have to figure it out yourself by trial and error.

I have met with "traditional" programmers who were very well experienced in OO programming and mathemathics and the usual Computer Science stuff, and they were a lot less effective than those business consultants who overcame their inital fear of hacking code, because they approached Navision from a syntethic, holistic, integrated, system-oriented viewpoint, which is a LOT different from the "concentrate on one subproblem" view of traditional, analytical, engineering-oriented programmers.

Why not just by chance? The typical development need I often meet on projects is like "write a report that back-calculates FIFO to prove to tax inspectors where our current inventory value came from" or "find out why Inventory Adjustment returns a division by zero" or "repair the stupid hardcoded Variant Code numbering series in Landsteinar" . Every such line of code is almost directly translateable to a verbal business rule. If a business would operate on paper and pen instead of computers, I would describe these functions as a verbal rule for manual work in quite similar way than I describe them in code. A few years ago business consultants described procedures in pseudocode - and C/AL is actually quite close to being a pseudocode that's executable "by chance". It's not a big difference to design in pseudocode or to design in C/AL.

You might be right if you are mostly concentrating on big-time add-ons like Landsteinar or Enwis, where consulting and development roles are usually separated, and not the usual on-the-fly customization - or if you are integrating Navision into a big enterprise architecture, instead of the "make one software do everything" approach which my clients insist on.

And what does it do with the problems I usually complain about? I have no problem with Navision development - the problem I usually complain about is that we are always forced to perform development that is not adding value but making Navision do the most basic, expected things right.

kine

There are tho models of consultant - developer.

a) Developer is "consultant creating C/AL code", which has large knowledge of the application and processes, but the code and "how to do that" can be very limited and in many cases need help from more sklilled developer (for example on MIBUSO... :-), is able to answer questions about "When I posted this, on which accounts I will see the VAT?"

b) Developer is "professional programmer" - he need some skilled consultant which is able to say "what must be done" - developer himself will create the "how it will be done". He/she do not need help with technical issues but need help with processes and consequences in the system from user point of view. (and is able to answer question of people from group A, and is posting question about processes etc. - if has no time to dive into code and search for the answer within code)

And which is better?

For fast developing some simple tasks A is enough. For developing more complicated modules like connecting two systems, performance troubleshooting, debugging modules, using 3rd party applications or other MS applications etc. you need someone from group B.

Conclusion:

You need both groups to have flexible team...

Shenpen

Kine,

A) is happening only if the given consultant has a mediocre intelligence or dedication. This is one of the hardest jobs around, it needs the really exceptional people, both in skill and in "fanatism". To be able to charge $500 for a day, the work performed in that day needs to be really exceptional or the project will slide into a endless debate with the customer. I mean there are operations/accounting systems where the whole licence fee for 10 users are about $5000, so to charge $1500 for a new report the legacy system had built-in is a kind of out of question, so one needs to learn to work real fast, I think there is no other way around.

As for the complicated tasks... I mostly agree. However, I think one should only concentrate on such big-time developments after the basic things are fixed and working properly... I often see "sales-driven development" where a lot of bells and whistles and chrome are added while the user still almost needs a degree in CS to key in a simple Item...

kine

I see one difference between these groups (from my experiences):

group A is able to create solution on bases "we need to do this and this now, let's go and do it..." (quick development, without thinking about future, hard modifications in future, sometime very hard upgrade)

group B is able to create solution on base "ok, we need to do this and this now, but in the future may be this and this will be needed, let's go and do it in a way which will support the additional request in the future" (longer development on beginning, quick modifications in future, easy upgrade etc.)

But still: in my opinion you need both - A and B - each for another sort of work. (for example A is very good for support, B is good for implementation)

Shenpen

The first is called customization, the second is called add-on development. The first is done if you want to minimize costs - because the customer forces you to do it for free - the second is done if you want to maximize flexibility, because expect to earn future revenue with it. So I think it's the goal what's different, not the skill.

kine

But for different goals you need different skills... :-)

And in most cases it is not easy to differ between "customization" and "add-on development". Each customization can be developed as add-on and add-on need customizations... as I say, you still need A and B if you want to have good team... and it means that you need the skills in generally 8)

But it doesn't mean that I don't agree with you...

Each additional skill is big plus for your company...

davmac1

I have an MBA and subscribe to Fortune, Business Week, and WSJ Online.
To really understand what people need, you need to understand business, processes, and a suitable array of tools for proving what people need.
Currently I know Navision, other legacy apps, SQL Server, Access, and Excel (at various levels) and use all of it regularly.
It seems the level of technical expertise required keeps going up and up - where does it end?
Looks like we need to learn Sharepoint at least at a middle level of expertise and start ramping up on Visual Studio C#.
Back in the 80's, the experts were touting a move to 4GLs to make programming simpler and faster. GUI and ever more complicated applications seem to have derailed that concept.

lakshmivalluru

The problem is most of the developers are left to fight there own battle to improve their technical knowledge. the more knowledge = more salary + more projects. Less knowledge = more expectation + more working hours + small projects.

Most of the time companies accept pojects and promise to deliver within next unrealistic days, for which they pick already experienced developers. So experienced developers get more experienced and other developers long for an oppurtunity.

Developers should be given a break now and then to come out of their busy work, spend sometime to get other skills (i mean not using personal time). I get up at 6:00, goto work by 8:30, come back home at 5:30, look after family dinneir, washing,etc. And by the time i put my feet up its 10:00.so where do we ( probably there might be developers like me) time to do that extra bit of time to imrpve skills.

Office is the best place to work and learn.

kine

I get up at 6:00, at 6:30 (or 6:45) I am in office, back home at 17:30 (something takes the shopping on my way home)...

The time in my work I spend with

a) working
b) learning
c) answering MIBUSO... :-) (learning)

Because time for the development is calculated for average programmer, I have some extra time I can use for learning some new things etc. But as you can see, it means that I am longer than 8:30 hours in my work... :-(

kriki

kine wrote:

c) answering MIBUSO... :-) (learning)

Definitly true. At a certain point I noticed I didn't learn anything anymore, so I started reading (and answering) on MIBUSO and by reading all posts, I have learned a lot of new things.


One remark about the "group B (professional programmers). They are more costly per hour. But not necessary for programming something. This because they spend LESS time then a group A-programmer and in general it is less buggy (so a functional has to test less) and less difficult to change it later.

johnson_alonso

Dear All,

lakshmivalluru wrote:

the more knowledge = more salary + more projects. Less knowledge = more expectation + more working hours + small projects.

I definetely disagree especially your words : more knowledge = more ....+ more projects. There are no one less knowledge in this world either he/she is a navision consultant (technical/developer or Business)

There is no assurance that the projects will come more and more if you have more knowledge. Also your words : "less knowledge = more ..+ ...,
don't judge everyone that involve in navision has less knowledge. There will never less knowledge either for developer or business analyst. e.g .which one of these two engineer are more clever, a nuclear engineer or a mechanical engineer ?

This quote about ERP implementation will describe more clearly about ERP system, either Navision, BAAN, Oracle or SAP although only SAP mentioned and then we are all here must focus more an more to know Navision deeply:

This article presents an interview with Don Schmickrath who was a
Director of Worldwide Distribution - responsible for all Distribution
organizations supporting Hewlett Packard computer products, including The Hewlett-Packard North American Distribution Organization (HP NADO) - the organization responsible for order management, credit and collections, customer support and distribution of computer products in North America. He describes the "6000 Rule" for successfully implementing systems software like an Enterprise Resource Planning (ERP) SAP package.

"THE 6000 RULE"
"The "6" means "6 months": implementation projects should be divided
into rapid incremental projects no more than six months in duration, each.
Team should start planning next phase during current phase. Well, the Six
Thousand Rule is something I've developed over time. The first part is
the six month project. I think it's really critical, once again, that you
split a project into small pieces, and get things done, get the results, get
the benefits from it, and see what you're doing. So these projects that are
mammoth projects that people get done in what we call "big bang" are
rare.

[Note from Ahmad Syamil: FoxMeyer, the fifth largest drug distributor
in the U.S., literally went out of business/bankrupt after spending more than $100 million on a failed ERP SAP R/3 implementation. FoxMeyer blamed SAP and Andersen Consulting who oversold SAP R/3].
other :
In the same interview with Schmickrath, the 6000 rule is contrasted to
the "Big Bang" approach to package implementation. A big bang project would be a multi-year project implementing a major software implementation simultaneously across much or all of a large organization. Schmickrath states the big bang projects are very risky and usually unsuccessful."
Source: Management Information System (MIS) lecture note from Stanford
University.

I wish those mentioned words are also skills needed to keep on Navision.


Rgds,
Johnson


"The Lord Jesus is my Shepherd, I shan't be in want"

lakshmivalluru

Hi Johnson,

I thought this is a general chat area. There is no need to be very serious of my"more" word. Obviously knowledge cannot be measured. but knowldge per area can be. if u know manufacting module and i don't thats the difference i am pointing out when i said "more" knowledge.

I am sure there are users who will agree and disagree with me. It all depends on how you(anyone) read my text.

themave

As and end user only, here is what I would like my solution center to know.

1. How Navision works in detail. If you make a change here what else is it going to effect ? So, when I ask for a change you can tell me what else will need to be changed also to really make it effective. For instance, I say we would like to add a field to the sales header so we can track what type of customer we are selling to.

When we started in Navision, if I asked this, here is what I would get, Ok we added the field "Type" to the sales header, you can enter what ever you want in it. So we would start using it and a month later we would say ok now we want to run a report on all that data. And we would hear, you mean you want the information carried over into the posted sales header too, that will be another programming change.

What should have happened when a naive new user asked for something the programmer should have said, ok, what are you trying to accomplish and how do you think you might want to use this information in the future.

Now that I know Navision pretty well, I find myself on this forum and a new user ask how to do something and most of the responses are suggestions on how to make a programming change. I try to suggest how to do the exact same thing using existing Navision functionality. Which seems to be the last thing a Navision solution center wants to suggest.

2. Understand some basic business principles. And under stand how a company that is not a Navision solution center actually works.
It amazes me how a programmer will write something, and it is clear he has no idea how it will be used. The layout of the fields is terrible. It may have required input fields spread across several tabs, it will have the user have to key his way through a dozen fields he doesn't need to enter data in.

Take the standard Navision sales order screen, it has to be the worst designed input screen ever created, I would be willing to bet there is not a single end user that hasn’t had to change it.

David_Cox

The post was about other skills, required to go forward and the thread has gone off track to "who does what".

With all the fast changes going on at the moment, I am also looking to expand my skill set.

I have worked just on the core Navision product for 9 years, the demand was there for this, knowing the product intimately I was in high demand, now with the growth of developers, the skill requirements are changing, and Navision skills alone will not carry you in the market place.

So like Lakshmi I would like to know where we should put our learning effort?

I read that navision has it's own .NET, or should we be looking at the standard MS.NET platforms.
Sharepoint is a product that gets a lot of attention, so should we start there.
Then the backend MS SQL, as a developer I left the backend to the implementation guys, but will Navision be normalized, brought in line with the standard SQL, over the next few years, to use stored proceedures etc:?

I spoke to a recruiter the other day he said "9 years solid Navision is good, but I am getting Guys with 5 years Navision, .NET, Sharepoint, Web Design etc: and this is more inline with requirements and marketable, you need to expand your skills".

So Like Lakshmi where do you start?

DenSter

David Cox wrote:

<snip>5 years Navision, .NET, Sharepoint, Web Design etc: and this is more inline with requirements and marketable, you need to expand your skills"</snip>

That only sounds good to a recruiter, anyone that actually works in the Navision world knows that you shold be set with just Navision skills for years and years to come. You only need Sharepoint skills if that is needed for a particular customer, or if you are in presales. It doesn't really mean much anyway, because the Navision - Sharepoint integration is a very limited one, so the part of Sharepoint that you'd need to know is not that big.

But I digress . Going forward you shold get more knowledgeable about SQL Server, but specifically for Navision. Read the material in the SQL Server toolkit (on the tools CD) and get familiar with how Navisin deals with SQL Server indexes, and how SIFT indexes are handled, how to increase performance. This is an area that you will find lots of work as a technical resource.

Then there is SQL Server reporting services that is becoming more important on 2005. I suspect more advanced BI will become a hot topic in the Navision world too now that it connects to SQL 2005 and BI becomes easier in Navision.

Don't put too much time into .NET development, that's not in scope for Navision for a long time. You should, however, know what .NET is, so buy a book called "Introducing .NET" by MSPress, or something similar. There is so much hype going around by people who just don't know what .NET means it's not funny.

nsrao2k

Am not a developer of Navision, still the crux of the converzation is to make oneself worthwhile in what we are doing. They follow the basic rules of any profession to be a professional

1) Keep Learning
2) Keep Experimenting
3) Keep Track of recent developments in Area of one profession
4) Professional Area is a Vast knowledge to learn - Common Sense helps most often.
5) Keep in Mind - we cannot learn everything - so leave some scope out

The most basic rule that differentiates from a successful professional and others is

Plan, Organize, Learn, Experiment, Implememt, Communicate and Challenge Onself.

The rest will follow...

Shenpen

It think it all breaks down on how big your team is. If you got a huge team, 10 people or more, then basically anything you are interested in might be useful.

If you have a team of 2-3 people, it's better to leave too technical tasks - like fine tuning SQL server or developing visual controls for Navision in .NET - to external consultants, and focus on other things.

The basic thing is that customers for some obscure reason always assume the following things:

- you generally know accounting and all accounting laws applicable to your country and even generally accepted accounting practices (kinda "what reports tax inspectors usually ask for" stuff)

- you know the typical business processes related to their industry, and in an analysis phase they will assume that they don't have to mention processes that "everybody is doing this way", because they assume you already know it.

- you know Navision as deep as if you have written it by yourself, both functionality, best practices, limitations, bugs, coding and whatever. If keep saying "OK, I'll find it out by our next appointment." after a while the customer will ask to send a "real expert who knows what he is doing" instead of you, and if you don't have one, there is trouble.

Believe me, these three are more than enough for one man. And actually the first two is the really important. I mistakenly believed for a long time that the third one is the really important - to know what's going on and how to change it fast. But actually... an implementation project is always a social game, a kind of a power game... if you play the "smart techie" , the "lighting-fast hacker" role, customers in their mind will put you into a kind of a lowly servant, waiter, car mechanist role - someone who is good with a duct tape and nothing more, which means you have no say in how things should bed designed - they will say what to do, and you can only do it.

So, it is also important to become someone like a customer can accept as an equal partner, not as someone who is just a techie. It means business, accounting and industrial knowledge. Whenever a customer wants some change in Navision, you have to be able to prove that their requirement is special and against the generally accepted practices and therefore an extra charge for developing it is rightful. You need to gain some kind of air of authority or respectability, and its not, very important, not possible just by becoming a Navision uber-expert.

This is very hard, because it needs totally different skills. For example, I rather hack overtime to satisfy requirements than to confront customers in a hard negotiation, a kind of a showdown. I am that type who likes to avoid conflicts. But I need to change it in myself, because my approach only leads to more and more requests, and this is going on for infinity - so I need to learn how to manage dissappointment: I need to learn how to gently, but firmly guide customers through the unavoidable phase of disappointment: when they ultimately realize that ERP does NOT mean that everything happens by itself and everything is automatic and error-proof. Maybe the old-timer consulting approach - wearing ties, speaking bullsh*t terms and keeping a distance, and definitely NOT trying to be every user's best friend like I am doing it today - would also help in gaining this kind of authority. I dunno, I actually never tried that, never had the stomach for that...

Compared to these things, something like SQL server tuning is easy and one can leave that to externals if being short on consulting resources.

ara3n

Shenpen
That was a very interesting view point, and thinking about for moment, I feel that I've been trying the same thing you've described. I work with consultants and on most projects, the clients view him as a equal and business partner, and me as tool.
I've been learning the business and accounting and industrial knowledge. But it's tough to master the power game and gain respect.
Where do you start? and every client is different, and you have start all over again.

Alex_Chow

Applause for Shenpen! =D> =D> =D>

He truly understands the nature of this business. Rather the true nature of all service related businesses.

Shenpen

Ara3n,

I dunno where to start. I'm just trying.

Shenpen

Another thing:

What skills to forget when starting to work with Navision:

- Hungarian Notation. Please, please... everybody can guess what type TotalAmount, SalesQty, or ErrorText is, no need to make code ugly by prefixing it with ldecTotalAmount.

- your native language, unless it is English. I just freak out when I have to maintain code with variables like ServiceVerkaufrechnungskopf.

What skills to don't learn (what practices are wrong in standard Navision and therefore should not be copied) :

- "Subject -> action" style GUI design. In standard Navision, you usually have to find the subject of an action first and choose the action later. For example, to release an order, find the order and click release. This is as bad as it can get - everybody has to navigate through lot of meaningless functionality, and it's impossible to design a decent workflow, and it's also bad for upgradeability. Do it the opposite way, "action -> subject", meaning f.e. there is a processing-only report in the main menu, where you can choose a subject (order etc.) or filter for them.

- Functions changing global variables. Parameters by reference. These violate the most basic programming best practices. The standard does it a lot, which shouldn't be learned.

girish.joshi

Wow, Shenpen. The "power game" post was one of the best posts I've ever read about what goes on this industry -- certainly from a developer's perspective.

I couldn't agree more. One thing I have noticed is the bulls**t you refer to about wearing suits and such actually works.

So that's my other skill: If you want to work with Navision as a consultant/developer learn how to tie a tie well. You'd be suprised at how effective that is in solving your problems.