So you are planning to become a Navision consultant. You are going to show people how to use Navision, how to run their business, and more importantly how to make their business run better.
Of course you already know that NAV application from start to end. You can post any Sales Order, and know exactly how it will affect the G/L. You know exactly which tables will be hit and what the entries will be. You understand Business Process Re-engineering. You are able to perform an ROI on any request that a client gives you. You have studied the clients business model, sought out its weaknesses and strengths, found where those strengths best work with which Navision functionality, and how to best utilize Navision to circumvent the weaknesses. You will be able to guide the client not how to mould Navision to fit their business, but how to best tune their business process, and tune Navision to an ideal balance.
But still we have not gotten to that most powerful tool that you have in your Navision Tool box. That tool is of course.
The word NO! Ne! Nein! Non! Nej! Nyet! Nie! Nem!
There is nothing else that will make the implementation more success full, nor give you a happier client than the proper use of the word no.
Generally one of the golden rules of sales is "The Customer Is Always Right". Well in the ERP world, that just isn't true. Of course as Dynamics NAV Consultant, you arrive on the scene after the sales process. So you have some work to do. When you get assigned to a Navision project, the first thing you must do, is go through all the paperwork, and review all the promises that the sales person made, and then get out a big NO from your tool box, and start using it.
All too often, one or two yes's sneak through the early project phases, and yes's are like rabbits, they bread like crazy. At first it all sounds great and happy, but a month or two down the line when you are trying to work around all these promises, you will realize that it would have been better to have been up front at the beginning. You will read some humorous statements like "We want to use pop-up to speed up data entry and make it more accurate". As a consultant you know that pop-ups make data entry much slower, and reduce accuracy, so say NO now, don't wait till the customer is live six months and then finds all the data errors.
Clients respect honesty.
This seems to have been lost somewhere, but if a customer makes a suggestion, that is just wrong, then … Just … Say … NO … ! it won't hurt you. When you tell the client why their suggestion is wrong they may react with disbelief, but give it time and that disbelief will grow to respect. It is very important to understand that your client most likely does not know Navision very well. That is why they engaged your services. They need you to tell them the best way to use the system. And sometimes that means just saying "No that just is not the right way to do this". Suggest to them the proper way.
I don't know.
Also don't be scared to say "I don't know", just make sure to follow-up with a "I will discuss it with the team back at the office and get back to you on ..." Just be sure that there is a team back at the office, and at your weekly team meeting don't forget to throw the issue around for ideas.
Anyway I just wanted to have this little rant, because I believe that if you are not capable of saying "NO" sometimes, then you are absolutely not capable of working with Navision, and you should leave and go to a different industry.
You're right. By the way; your post is missing the word Nee for the Dutch NAV-people. ;-)
Just couldn't agree more!
My Nav-EP project took 6 months longer than planned because no consultants were involved in the sales process. A few early No statements would have saved everyone a lot of trouble.
But don't fool anyone to say that it should be easy just to say no! Especially new consultants/programmers who know that "everything is possible" will sometimes be carried away by a requirement from a customer which they think could be "fun" to develop. Even if they know that there could be better solutions...
Very good post.
Another thing to keep in mind is the 5 Whys.
Just because a modification has been requested. Doesn't necessary mean that's what they were trying to achieve. You have to get to the route cause by asking questions.
Like Erik said everything is possible but don't just do because you were asked.
Don't forget "Just Say No".
That's why Development needs to be involved much earlier in the sales cycle than less modifiable ERP packages.
I always joke that it is my job to say: "Sales told the customer we could do what?!"
Respect for the Hungarian version of "No" -> "Nem". :)
Vietnamese version of the word "No" is "Khong" ;)
Very good article, something that shadowing a good senior consultant during PIT phases will certainly teach you.
"Hold on, Stop, let's take a step back, what are you really trying to achieve.
"Why are you doing it that way?"
It is not for NAV only.
This "tool" must be used in all other projects such as CRM, AX, GP.
Thanks everyone for the very positive feedback.
And yes its not just for the NAV world, t applys to most forms of consulting. Don't just do word for word what the customer wants. Ask them WHY they want it, work out if its the best option for them, show them alternatives, and in the end give them a simple solution that solves their need economically.
I am so glad to see that so many people out there agree with this aproach.
You are truly speaking for the many consultants out there that find themselves on the bad end of a sales pitch.
Many things are possible with Dynamics NAV, however there are many things that should never be done with an ERP system.
It is better to have not made a sale at all than to have made a sale that looses you money trying to impliment a bad solution...and NO, dispite what some may think, constantly selling at a loss can never be overcome by high volume.
Where I come from they would typically say "those people have more dollars than cents (sense)"
If we see a movie called yes man then we must not use NO at all ;-)
I am somewhat agreed on it as the problem that i have face is sometime customer wants everything automated :-)
Thanks for that :)
I like this article. Very honest and truthfully.
One day, a man come to doctors and said: "Doc, what is the best unhurt way to amputate my leg?"
Doctor A: "Use a knife and anti-pain drug"
Doctor B: "We could do a surgeon for you. Give it to us, and let me do it"
Doctor C: "What's wrong with you? Why do you want to do that?"
Patient: "My leg is very itchy and I could not stand of it."
Doctor C: "Then I will prepare a prescription for you and go to the drugstore then"
So, which Doctor would you listen to?
So, you must to KNOW WHY, and WHAT is the PURPOSE/OBJECTIVE, and lastly of course, you MUST KNOW the Product Knowledge of standard usage (get the Training material, Online Help, etc).
If the standard could not achieve that, try work-around, and if it is very critical and worth (not just for a nice-to-have feature for a lazy user), then the mod is the last resort.