Part One of Three

For several weeks we have been taking a deeper look at what we believe is the right approach to a new business management software implementation. In the coming weeks, we will be focusing more closely on how the expertise of a Value Added Reseller (VAR) can be beneficial; and improve the likelihood of a successful outcome.

Before we jump in, we would like to suggest that you change the definition of what you’re looking for.  Rather than looking for ‘software’ we’d like to call it looking for a ‘solution’.

You have a series of problems, opportunities and objectives – no product will, by itself, solve these on its own.  You need a ‘solution’, not a particular ‘software product’.

Bottom line note…

1.    Everyone involved needs to recognize that your business goals and objectives must drive your business system selection.

The key to buying software, in our opinion, is something other than the tired methods used for years.  We call our system the “Economic Business Impact Assessment”.  This assessment is designed to uncover both the business objectives and the business drivers that are the key elements in causing your business to succeed; and then using this information to define your processes.  It is critical that each partner (both management in your organization and any VAR you hire) understands these elements and the monetary benefit derived from reaching them.  If the VAR doesn’t understand your business system drivers, it is unlikely that he will be able to help you meet them.  We believe that our ability to uncover both the objectives and the drivers enables us to help our clients succeed in their business system implementations.

We met with one of our distribution clients recently to discuss an upgrade to their system.  They were concerned about all the modifications that had been made over the course of their use of the software.  They really wanted to use stock software.  We discussed the issues of stock software.  As we discussed the question, I came to the realization that they were in the business of saying, “Yes”.  They were a custom delivery business, matching their services to the needs of their customers.  Yes, they distributed products like their competitors, but rather than making everyone conform to a rigid system of processes, they were willing to adapt to the customer’s needs.  Their modifications allowed them to continue to say “Yes” to each customer’s request and still make a profit.  This was their value proposition, one of their key drivers.

Your VAR must recognize your business objectives and drivers, or your business management system will fail.   Generally, the VAR you feel can do that will represent the right software solution for your company.  How can I say that?  Well, if you are comfortable with the VAR, it is generally because they spoke your language.  You didn’t have to define, explain and facilitate understanding of the general principles you use in your business.  Of course, you still had to share a great deal of your company’s information, but they “got it” when you told them.  If the software they sell does not fit, they should tell you so. We have “saved” implementations where the customer had gone through three or four other VARs and still was not happy with the results. To reiterate, the VAR is an important part of the solution.

Does it seem unlikely that a company will turn down your business if you want to buy from them?  As I said, I have.  Failed implementations are both financially and personally draining; two results that rational people don’t want.  With an IT project, product delivery is not the same as delivering a car.  Much of the “product” is a result of the training and implementation provided by the VAR.  There is typically great personal investment in product delivery.  A failed implementation can be viewed as a personal failure.  Failed implementations frequently result in significant loss of billable hours or uncollected invoices.  In addition, the reputation of the VAR can be damaged; causing long-term loss of business.  It is better for me to decline a project that I believe has limited, or no chance of success, because of a poor software fit or lack of direct or indirect experience in a field.  Or, if the prospect is unwilling to provide needed data or insists on doing things in a way that doesn’t mesh with our proven business methods.

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