Monthly Archives: October 2014

Process vs. Technical Questions

Overview
If you’re an IT or Finance person working in a company that uses Dynamics NAV. First, congratulations! There’s no other ERP product for the mid-market that has the growth (and growth potential) as Dynamics NAV.

Having said that, often times you will be fielded with questions about NAV and it will be difficult to respond. This is especially true when you’re supposed to be the “expert” of the software within your organization. Of course if you really get in trouble, you have your Dynamics NAV partner to back you up so you’re never really alone.

However, in order for your NAV partner to make you look good in front of your peers, you have to phrase your question in a way to get a “on the point” response. Don’t assume your NAV partner to know what you’re thinking, because trust me, being in this business since 1999, I still don’t know what you’re thinking. I did, however, developer a better sense of asking the right questions, but that’s probably a topic for a separate blog post.

When fielding questions, there are generally 2 different types of questions. One is technical question and the other one is Process.

What is Process and What is Technical?
I’m glad you asked that question. Here’s my definition of both

Process Question: A question that’s related to the daily/weekly/monthly workflow of a particular operation. For example, reconciling inventory to G/L at month end. (Non-linear)

Technical Question: A question that’s indirectly related to the daily/weekly/monthly workflow of a particular operation. For example, an error message when you’re trying to post. (Linear)

Troubleshooting the Process
Which of these questions is more straight forward? Of course the technical questions. It follows a linear path. These types of problems can usually be resolved using a debugger.

As the Dynamics NAV go-to person in your company, I bet most of your time is trying to figure out the process questions. The Non-linear questions that can have multiple paths.

It’s important to identify what is process and what’s technical question. If it’s a process question, you should get the experts or the person responsible for that piece of information involved. As much as you like to help out the process by request or making little modifications that solves their process question, it’s not the right way to go about it.

For example, over receiving. Some times the warehouse will complain that you cannot over receive. As an IT guy, yes it’s easy to bypass the check process and just modify the quantity.

However, by doing this, you’ve cascaded the problem and implemented a flawed process that people will get used to.

In this example, why is it flawed? Among the various reasons, one of the biggest problem is because when the vendor send you extra items, who’s responsible for it? Do you have to pay for it? Should the vendor give it to you for free? What if the buyer did not want to receive the additional items because it messes with their budgeting? You get the point.

Changing the Process
That’s not to say that processes cannot be changed. It’s really about how you go about changing the process.

The first step is to get with the people responsible for the process. For some reason there are some internal IT and finance people that simply will not do this. They want to assume they know what they’re doing or they do not want to ask the people responsible questions. This is absolutely a MUST!!

In our example, the purchaser should be involved and the warehouse manager should be involved. Sit with them and describe this problem and ask the all important question: “how do you want to resolve this?”. It’s up to them to define a process that satisfy the buyer and their vendors, the warehouse and the receiving process. Once that process is agreed upon, then it becomes a technical question.

Conclusion
As the NAV guru in your company, you’re most likely swamped.

We want resolve problems and issues to “get them off our plate” as soon as possible that sometimes, we mistakenly treat process questions as technical questions. I know because I’m guilty of that as well. This is not the right way to go about doing implementations and certainly not the way you should go about addressing the needs for your company.

Because ususally when IT gets involved in process questions, developers tend to find the shortest way to resolve the problem, not the right way. As always, finding the shorest way will always require exceptions in processes. Exceptions are fine until there are exceptions to exceptions. Then exception to exceptions to exceptions. This is a sure fire way to complicate your business process and have each department not taking responsibility and point fingers at each other.