Part Two of Three

choosing-VAR-for-business-management-system-implementationIn part one of this series, we discussed the importance of letting your business goals and objectives drive your business management software selection. If you followed our process to this point, you have a great tool with which to measure each VAR.  You know what you want and you know why you want it (remember, these are business objectives, not product features).  If the VAR doesn’t employ the same questioning process you have used, then it is likely that the VAR is expecting his software product to be the solution to your problems without understanding your objectives.  Your chance of success with this VAR is low.

If you haven’t taken the time to follow our process of business objective discovery, then look for the VAR to do it.  The VAR may do some of the discovery as a part of the sales process, but will most likely charge for a full discovery engagement.  (We will discuss this more in another blog). If the VAR does only limited or no discovery work, then your chances for success are limited.  Find another VAR who will.

Bottom line notes…

1.    Don’t dictate how the VAR conducts business; rather watch to see if he does it the way you require.

Mahan Khalsa, author of Business Think, says that how we sell, is a free demonstration of how we implement.  There are several lessons to draw from this.  One, don’t tell the VAR how to conduct his business with you.  Let him show and tell you how he does business.  You will learn more about the VAR’s implementation methods this way.  In other words, let the VAR do his discovery or not; let the VAR guide the “demo” – don’t write your own script.  You will find valuable decision-making material about the VAR in this process.

2.    Can the VAR communicate clearly with you?

Two, listen to the VAR’s language.  Are the people on his team speaking “Business” or “Computerese”?  Remember, this is about solving your business problems and meeting your business objectives, not about computers and software.  Of course, there will be technical discussions, but these technical discussions should not be the bulk of the talk.  These discussions will be more detailed with your IT staff, but they should be at the lowest common denominator for the audiences; so that the discussion creates understanding, not confusion.

3.    You and your VAR should be on the same page, naturally.

Finally, evaluate the conclusions the VAR draws; as well as his ability to relate them to you and your business.  Are the conclusions natural extensions of those you have come to on your own?  Do the methods and tools used during the selling process lead to greater clarity as you work through the process?  Do the members of the VAR team relate well to your team?  The VAR should be evaluating you while you are evaluating him.  His conclusions will affect the price and the likelihood of success.  Does the VAR express both the areas of risk as well as the project results?  If you don’t hear anything about risk, the VAR is either ignoring it or wants you to believe there is none.  We are all risk-averse to some degree but every project has risk.  Don’t be fooled into thinking there is none.  Why else do 68% of IT projects fail?  You can’t fail if there is no risk.

Why is the VAR important?  The VAR will have implemented many business management systems over the course of many years.  This experience will enable valuable time savings, enabling you to experience payback on your investment sooner than if you do it yourself.

Choosing the right VAR for your Business System Implementation Part 3…

For comprehensive access to all of the tips listed here on our blog regarding how to choose an ERP system, please click below to receive our ERP Project Success whitepaper, compliments of BASM!