Understanding the problem is a vital component for making informed decisions about a software solution and its role in a company’s operations. Too often, clients are looking for a solution for a problem that they themselves might not understand. Even within an organization, people come from different backgrounds and different experiences, many of which are shaped by systems and applications they have used in the past.

In the distant past, I was involved in a project where we developed an interface between Microsoft Dynamics NAV and a third party application designed to handle shipping and logistics requirements for dispatching stock.

The requirements were fairly straightforward – an XML based interface passing information into a separate system about the items being picked, the number of pallets and the delivery details. The intention was that this interface would improve the speed and accuracy with which picks could be organized to optimize warehouse space and maximize the usefulness of warehouse staff.

My first meeting for this project involved a representative from the third party system; we discussed the specification, toured the warehouse, talked to the users, and planned out our approach. Unfortunately, we never got the opportunity to talk about the actual problem that the users were experiencing. Simply presented with the solution I went away and developed the interface as instructed; we tested it and got the users to sign off; and we deployed on time and on budget.

The results weren’t as expected. There was virtually no difference in the time it took for the information to flow from NAV, to the shipping system to arrange pickups from various delivery companies. In hindsight there were two major obstacles:

  • The users were not familiar with the shipping system, and the support they received from their partner was poor.
  • The users, who were entering the original orders, did not understand that mistakes they made at the sales order entry level cascaded down and affected the warehouse staff. The warehouse staff had to manually review the data and confirm or verify the delivery details.
    In hindsight, we should have had an opportunity to discover for ourselves the issues that were being experienced in the warehouse, and we shouldn’t have been so focused on the solution that we missed existing problems.

If we had been able to identify the real problem we would have bypassed the separate shipping system altogether and trained the sales team in the importance of accurately recording shipping details and arranging the delivery information prior to releasing their picks to the warehouse. Such a solution would have been much more in line with the problems that the client was experiencing rather than the Band-Aid fix that was applied.

At Fenwick, we are experts in Dynamics NAV – we understand the system and its strengths and weaknesses. Our clients are experts in their own fields and in the challenges that face their businesses. Our job is to become as familiar with our clients’ processes as we are with the application – it is only when we are able to gain a complete understanding of both that we can design a solution to ensure that the weaknesses are covered, and the strengths are accentuated.