In a previous blog, I asked the rhetorical question, ‘Why?’ when I saw a fragile development and bespoke customisation in client databases after we inherited them from other partners. Since then I have gained some perspective as to why this happens and how to avoid it.
It is the goal of every NAV consultant to maintain client satisfaction. This is often construed as gaining an immediately positive reaction from the client in front of you. It is easy to say ‘Yes’ to a client request, but this is not always the best solution and can, in the long term, lead to significant client dissatisfaction.
Clients are experts in their business and know how they need their processes to work. This can lead to situations where, upon seeing that NAV differs from a required process, clients request modifications to make NAV fit exactly to what they expect. It is the responsibility of the NAV consultant to ask ‘Why?’, albeit in a non-confrontational way. For the most part, clients are not software designers and should not be responsible for translating proven business processes into NAV functionality.
As consultants we need to maintain the big picture to prevent structural instabilities in client data and functionality. And a crucial step is to ask, ‘Why?’.
The NAV consultant needs to work with the client. The consultant should use their own expertise in NAV to identify a solution that is stable—relying on standard NAV functionality and strong development principles; and a solution that is appropriate for the business, using the expertise of the client.
When designing custom functionality, ‘Yes’ is always the easiest answer but rarely the right one. It leads to databases that work exactly as the client expects for one situation but potentially not for any other, often with negative ramifications. As consultants, we need to maintain the big picture to prevent structural instabilities in client data and functionality. And a crucial step is to ask, ‘Why?”.
