Many software suppliers are more focused on the sale than the solution when working with customers.
Twenty-something years ago, software demos gave potential customers a good idea of the system they were buying.
Today, as software functionality continues to expand and teams of consultants scramble for profit (read our blog on Tesla for more on that), it’s difficult for manufacturers to know what they are purchasing. The skill in MES sales has grown faster than the market’s ability to discern fact and fiction. The rules in the software market have gotten skewed, and without rules, how do we play (or purchase a system)?
Gentlemen’s Rules in Cycling
I was an avid cyclist. After competing for 18 years on the cycling circuit in the US, I’m content now to watch the Tour de France in a comfortable armchair.
The Grand Tour is an amazing spectacle. If you live in France, the month of July is dedicated to the sporting event. It is called one of the most grueling sporting events in the world. For 21 days straight, almost 200 cyclists (usually 22 teams of 9 riders) compete in road stages that make Death Valley seem leisurely.
In cycling, there’s always been an unwritten gentlemen’s code of conduct. If you are a rider, a competitive one, you know it. And you live by it...
Cycling is, at its heart, a team sport. Inevitably, the entire group (the peloton) doesn’t ride together – the group will split as the race speeds up or the hills get steep. In these situations, the gentlemen’s code ensures:
- you never attack the leader if he or she is down;
- you work together and everyone takes a turn, and;
- if you’re not able to work with the group, you may sit on the back (where there’s less wind and it takes less effort) but you won’t participate in the sprint or receive points on the day.
The code subtly manages the race. You don’t win if you can’t do the work. Unfortunately, it doesn’t seem like the software industry has a similar rule…
As a customer, you want to get the best product for your business. The purpose of the demo(s), the Request for Proposals (RFPs), and the other stages of the software purchase process is to determine how well the system will serve your manufacturing needs. The process should let you “try out the team,” who will be providing your new system, ensuring only a company that can do the work will earn the job.
But, that’s not how it works today. Many suppliers use resellers so they never work with an end user. Other suppliers are so big, there are layers and layers of bureaucracy between you and the people who really know the software. Most customers only meet the sales team, and are introduced to a few people on the installation project leads - a team focused on sales and collecting commission or service charges, and not meeting the goals of the implementation.
How are those implementations working out? How many companies suffered with a poor software installation when the salesperson (who was well-liked liked) made promises the solution couldn’t keep?
Implementing a Code of Conduct for Software Sales
Let’s go back to my gentlemen’s code theory. If the sales team tells is focused on closing the sale, are they really worried about what your needs will be in the future? When you have an issue, are they there to help you, or are they counting on your service charges each time a problem comes up? Are the sales or implementation team best positioned to answer your questions? You never even meet the real software experts (if there are some). In fact, it’s not in the interest of some companies to review every option or potential problem before an implementation, because their sales model is based on the additional service charges they’ll be getting from you.
I’m not suggesting you find a better salesperson. It certainly helps the process, but I think you need to look deeper. With the increase in consultants, and the constant attrition in the marketplace as smaller companies are eaten by the monolithic software enterprises, the “team” concept in software sales has disappeared. As software companies absorb functionality from other systems, finding someone, anyone, who understands the software enough to provide adequate, or useful, support, is almost impossible. This leads to higher cost, additional complexity, and a software product that never works the way it was sold.
A gentlemen’s code of conduct would help eliminate many of these problems. Consider this:
- The software supplier should walk a customer through the entire implementation process (eliminating those “surprise” service charges that creep into many projects).
- No system should be installed without an upgrade path. Systems shouldn’t fade into obsolescence. (Read more about it here. It’s critical.)
- The software supplier should offer a guarantee and benchmarks for the system and implementation. They should take some risk in the project, and not expect the customer to carry the burden.
- No product should require a manufacturer to completely change their processes and work instructions. Too often the shop floor ends up serving the software, rather than the software supporting production.
I’m sure every person who has ever worked with a software supplier could add to this list, but it’s a start, and we need to start somewhere.
Will Your Supplier Go the Distance?
We should all work for our customers like members of a cycling team.
This year’s Tour has been one for the books. Last week’s stage to Mont Ventoux reminded me of a software installation gone awry. With winds topping 60 to 100 kms/hr, race officials cancelled the last 6 kilometers of the race. None of the teams complained, even though the decision hindered the advantage of the top climbers. Unfortunately, many people had camped on the side of the road for those final 6 kilometers, and as word spread, those people waiting at the top started to make their way down the mountain. The crowded roads caused the leader to crash badly.
If something like this happened during an MES implementation, many suppliers would sigh and extend the schedule, halt production on the shop floor while they fixed the problem, or call procurement with more service charges. Installation is a tricky process and things go wrong. Is your software vendor willing to change the requirements or project plan when problems happen? How painful will the service charges be? How will they work with you?
If you have a problem, will your team (if you even have one) do what the leader did on Mont Ventoux? With a wrecked bike and watching other groups pass him as he waited for a team car, he began to run. Running in the Tour de France? In 25 years, I’d never seen it. He did what it took to keep the winning jersey with Team Sky. And he delivered.
That’s the difference between working with a team focused on your goals and with people who really care about your success and the product they offer, and working with just another software reseller.