The version name says all; 2009. It has been a year since the release of Microsoft Dynamics NAV, making it time for a thorough evaluation.
At this moment I have two customers ready to go live on January 1. One with Dynamics NAV CRM and one with NAV Financials and an add-on. For this add-on, we used the Transformation Tool to upgrade the forms to pages.
So what have we learned? I have broken this evaluation into five sections or components, and evaluate each one separately. Each component comes at the evaluation from the End User perspective, the Consultant perspective and the Developer perspective.
Because of its length, this evaluation is being presented in three parts. In this Part 1, I assess the new Role Tailored Interface.
My company uses the new Role Tailored Interface in the role of an end user, for invoicing and banking.
The new interface is definitely the most eye-catching change in this version of Dynamics NAV, but is it an improvement? And what about implementing and developing with this compared to the classic interface?
From the end-user perspective, I must say I am very impressed. End users find the interface very easy to use and it seems very intuitive.
One group of end users is migrating from a Unix environment with a 25x40 line screen, unbelievably easy to use but graphically from the stone age. They can find their way in the RTC client within minutes. The action buttons are easier to use than the old menu buttons and filtering is much more intuitive.
The fact boxes are a big improvement to end users, making detailed information easier to locate as well as the fast tabs. The success of the fast tabs is not in the vertical vs. horizontal character, but in the promoted information. Users can see information on a tab without expanding it.
From an integration perspective the client add-ins are a big improvement. We have used it to interface with Bing Maps. We used the examples from the NAV Team and expanded it with complete route visualization.
Once users are more used to the interface, they start personalizing it. The two most popular personalizations are changing the columns and changing the menus on the role center. The first was also possible in the classic client, the latter is new.
A complaint from the end user is the lack of color and/or indication possibilities. People who work with a generated workflow that they have to manage by exception have an especially big need for this.
From the consultant's perspective the new interface means less and more work. In the classic environment, end users had many more difficulties finding their way. Menu items where hard to find and often in odd places between menu items that were not used but easily clicked on by mistake. So explaining it is a lot easier--a consultant no longer has to ‘defend' the way the interface works.
More work is generated from the possibility to create the profile personalization layer. This is also part of the success of the end users' acceptance. The consultant needs to interview the end user and place actions, menu items and fact boxes in the right place.
This gray area brings us to the developers' perspective. This job has become more comprehensive than before. This is not because developing in 2009 is more complex, but because of the lack of integration between the Role Tailored Interface and the development environment. The development environment is still in the classic client.
To ‘develop' in the new interface, the developer needs to be able to translate in his mind how it's going to look when it's executed on the new client. Fortunately, this job is made much easier with the new client adopting the changes almost immediately. A change in the interface or business logic no longer requires a restart.
My experience is that the ‘run' function in the development environment is hardly used. It is enough to have the Role Tailored client open and simply restart the page. The run function also often executed the object in the wrong mode--for example, where edit is required it shows view mode.
Also developing in a Role Tailored environment means a better need to understand the end user and the business process. As a developer, you can no longer just group functions by functionality. There needs to be more interaction if a function is important enough to be on the Action pane, in which category, big or small. Should a field be promoted or additional? What fact boxes can I use with a page? Does it makes sense?
Developing in an ERP system always was a challenge for techies without knowledge of businesses, and that has not changed. On the contrary, it has become even more important.
A special consideration must be made for developing the role center. Designing a role center requires special skills in understanding a business workflow. From a technical perspective, we have found out that it is best practice to have only one cue table for all role centers in the company. This makes it easier to copy and paste cues from one center to another. The ‘my' pages are very popular. Microsoft delivers my customers, vendors and items with the package, but so far we have created my contacts, my to-do's and my routes.
What makes it extremely difficult for a developer is the debugging process. The new interface does not know a debugging tool, so whenever a bug is reported in the new client, it first has to be recreated in the classic environment. Only then, is the developer able to debug.
This article is also reviewed and posted on MS Dynamics World. Thank you for this.
Please also read part 2 and part 3.
Thank you Guido.
But, a way to debug does not make a real debugger...
Anyway, it is better than nothing.
There is a way to debug. blogs.msdn.com/.../debugging-in-nav-2009.aspx . It works quite well.
Thanx for sharing this, Marq. Valuable info.