One of the most powerful arguments for looking at Dynamics NAV is the ease with which the software can be customised. This has important benefits for organisations implementing Dynamics NAV, both during initial implementation and in the future, the system can always be tailored to fit your process.
Both the product and the Dynamics NAV support channel were designed to support customisation. The drawbacks associated with bespoke software do not apply to Dynamics NAV; there is no version or partner lock in. This means that with Dynamics NAV you can achieve a 100% fit to your business, now and in the future, giving you confidence in product selection.
No matter how detailed your evaluation process, it is unlikely you will have investigated every function and some fit is taken on trust and assumption. Generally this means there are acceptable differences where the new system works in a different way to the old but the same result is achieved. Occasionally it can be more problematic where the standard function does not meet your process or where there is no standard function for a key process. Fortunately the flexibility of Dynamics NAV and the access to source code mean we can ensure the product is an excellent fit, from tweaking existing functions to creating new areas of functionality.
System lifecycles typically go from great fit on day one of the implementation handover, then, as your organisation grows and processes change, the system fit becomes less good. During the life of any system which is difficult or impossible to modify, a gap opens and widens over its life between what the business needs and what the software can deliver. This gap is filled by using a combination of spreadsheets and word processor documents until the day that this becomes so frustrating you decide to replace your system.
Because Dynamics NAV is relatively easy to customise, it can be continually ‘tweaked’ so that the Application gap is kept to a minimum or even eliminated.
During the evaluation of new software the issue of ‘standard’ versus ‘developed’ will inevitably be raised. In the UK most companies are apprehensive about developing software. This paper investigates why development is viewed as a dirty word and presents the case for changing minds; the right development is essential to make your software investment really work for you.
Why do we like our software to be “Standard”?
The assumption is that standard software will be easy to implement and maintain, should be fairly safe to make, especially where the decision to change process rather than software has been made. If we all worked in the same way, implementation would be straight-forward matter of installation, data conversion and training, in short, life would be a breeze!
The dangerous assumption is that there is one standard. No two companies work in exactly the same way, if they did there would be no competitive edge. There is also no ‘standard’ across software packages and so to map data from one to another may not be simple, especially where you are looking to bring about process and reporting improvements as part of the implementation (improving the ‘standard’). Therefore, if you are looking at a scope beyond basic accounts, your ‘standards’ will be unique to you.
When it comes to accepting a development approach the good news is we all know what we’re getting. With standard there are too many assumptions and a tendency not to properly analyse requirements or functionality followed by conflict when the system’s ‘standard’ is not what was expected.
Standardising processes is a great thing, especially when looking to optimise ERP investment. This is about standardising within your organisation, not the world. Opting for ‘standard’ software that does not offer the flexibility to mould to your processes is often disastrous and will quickly lead to the necessity for work arounds; thus negating a key driver for changing systems in the first place.
Any ‘tweaks’ or modifications need to be evaluated on the basis of Return on Investment, just as much as the initial implementation. Ease of customisation does not mean that every implementation should be approached on the basis that the Dynamics NAV software will be modified in any way. At TVision we believe that there should be a clear business case for any change; Our “standard is best” mantra is over-ruled only where change is justified to ensure the software supports your business.
Dynamics NAV resides in its own development environment which is delivered as part of the package and loaded onto your server. This development environment is exactly the same as Microsoft developers use to create the standard product. Access is controlled by licence type; all clients have the licence to access basic customisation tools (table designer is additional cost) and can elect to purchase full Solution Developer licence, giving the same access as a Dynamics Partner.
If you do plan to make changes, no matter how small, it is essential to agree development protocol to ensure that support is not compromised.
Basic Customisation Tools: Table and Form Customisation
The data in NAV is held in numbered fields in numbered tables, meaning each object (i.e. field) has its own unique identifying number. Each field has its own properties such as type, character length, caption etc. Changes to Tables can include modifying field properties and creating new fields to capture data specific to your process. You can also create new tables. Compilation tools check the integrity of any changes, rejecting those that will not comply. As NAV is a relational database, the compilation will also ensure that changes are reflected throughout the system; for example, an additional field added to the Customer table would be automatically available as filter criteria in the Aged Debt report.
Forms display the data and because they are separate from the data, you can have many forms all accessing the same tables. This means you can have variations of forms depending on the user’s role (linked to their permissions). Simple form changes include hiding fields that are not used, a very basic, easy change which has an enormous impact on training as there is no need to waste time instructing users on what not to do!
Beyond simple Form, Page and Table customisations, Dynamics NAV can be customised by the development of application code which takes the data entered and makes it represent the processes in your business that make you unique and which make you profitable.
Application builder has restrictions on the code that can be accessed; for example, you would not be able to modify posting routines; however you can develop processes that then link into the existing posting routines. These restrictions are sensible precautions to ensure integrity of the database is maintained.
As Application Builder but with access to all code units. Unless you have a dedicated resource who will be working extensively with the solution, it is not usually cost effective or advisable for clients to take this route.
Changing any part of the software is a double-edged sword as it requires great discipline from both parties.
Two points need to be borne in mind. Firstly, any change, no matter how apparently trivial should be judged on the basis of the Return it will bring on the cost of making the change. Moving a field on a form looks simple enough but it will need to be tracked through whatever Version Control system your Dynamics NAV partner has in place. It needs to be tested by all the users and against all of the processes that the software needs to fit. And it then needs to be maintained through Upgrades as they are implemented. So where possible, keep all changes to a minimum. Also, remember that if you add areas where you want additional data recorded, the person doing the input must have a direct interest in the information being gathered. If they don’t then there is the danger that they will put in the easiest thing they can think of rather than what’s correct and that glorious report or graph that you think you’re going to get will be based on bad data.
Secondly, there is a natural tendency for Dynamics NAV Consultants to believe that the answer to any process difficulty is in customising the software where the underlying issue may lie elsewhere and may require extensive analysis in order to deliver a solution. Thus, development of the customisation starts too quickly and leads to an excessive number of round trips, costs and time spent before the ultimate solution is delivered.
Dynamics NAV competitors like to promote the myths that NAV needs customisation to be a good fit and that this customisation will make upgrading costly. Neither is true.
For most implementations, NAV does not need customisation as it is a functionally rich solution. Minor modifications such as hiding unused fields are simple cosmetic changes that make good fit great.
Customisations are separated from standard objects by the unique numbering allocated to them. When upgrades are released these affect the standard objects, they do not over-write customisations. There may be work to map customisations, you may decide that new functionality provided by the upgrade makes your customisation redundant; the upgrade tools provided help you evaluate the best course for your business. Unless a system is a standalone, standard off the shelf package it will incur cost at upgrade, for Dynamics NAV this is managed and affordable.
Microsoft Dynamics solutions are sold and supported through the Partner Channel. Usually the partner is selected at the same time as the product. Occasionally situations change and you may decide that you want to move your support. Your new partner will be able to access any customisations to your system. Partners are encouraged to develop to agreed protocols and provide documentation (paper or electronic); where good practice has been followed taking over support for these customisations is straightforward.
Simple, work with an experienced Dynamics NAV partner, such as TVision Technology, who use a proven implementation methodology and keep expectations realistic. Don’t be frightened of developing. Although no system can do your work for you, when well implemented, Dynamics NAV will make your work easier with no need to fall back on “work-arounds”.Back to top Back to All Knowledge