17 Feb ERP Fail – the Software Demo
No failed ERP implementation was ever preceded by a bad demo.
There is a great software joke that goes something like this. Man arrives at the Pearly Gates and is met by St. Peter who tells him that he has lived a shaky life but not without redeeming qualities. As a matter of fact, the decision to send him to the good place or to the bad place is basically a coin flip.
St. Peter looks up and asks if there is any input regarding where he should be sent. Thinking for a moment the man asks if he could take a peek in both the good place and the bad place to help him decide. Being a slow day, St. Peter decides to oblige.
First the good place: angels sitting on clouds playing harps. Very peaceful. In the bad place folks are mostly dingy, dirty and sweating because of the high heat and humidity but are generally sitting around playing poker and smoking cheap cigars while drinking non premium whiskey.
All in all, the man reasons that being hot and sweating is not that bad and that playing poker for eternity is a lot more fun than playing a harp.
So St. Peter finishes up the paperwork and ushers the man to the bad place where he is promptly strung up upside down and stuck with pitch forks. Screaming in agony he wants to know what happened to the poker and cigars!
St. Peter scratches his head and mumbles something about that just being the demo…
Lets all agree that no one ever purchased an ERP system based on a bad demo, that no failed ERP implementation ever had a failed demo. So why the vast disconnect between the fabulous demonstration and the reality of the implementation. Several factors:
- The folks responsible for creating software demonstrations are often the highest paid and smartest people in the company. For sure they are the most charismatic.
- Demonstration experts typically have a lot of time to prepare.
- The demonstration often sells to the emotional side of the brain not the practical.
- Demonstrations stay away from “trouble areas”.
- A lot of software is designed to demo “easily”.
I was competing in a software deal for a company that manufactured beautiful custom saddles. Each custom saddle allowed you to choose custom features and options to perfectly match your body, riding style and taste. The multiple ways that you could design your saddle made it impossible to start with stock or standard saddles and each had to be made individually from scratch. The definition of a “configure to order” manufacturing opportunity.
The relatively small number of feature and options made the customer and his manufacturing process a perfect fit for a software product I was presenting. Not only did it have an elegant product configurator but the software produced a bill of material and a routing from a completed configuration. A perfect solution and almost impossible to find outside of a million dollar “Tier 1” product.
Knowing I could not possibly lose this client I prepared a presentation complete with pictures of various features and options that stepped a potential customer through the process of designing a customized saddle and automatically creating all of the work steps and costing information for the manufacture of the saddle. Obviously the business logic required to do this was complex and sophisticated.
Predictably the client was impressed.
Days before the deal was signed my prospect sent me a note that a friend of a friend had recommended a competing product because of its amazing “look and feel” and ability to easily format screens to the customer’s desires.
Oh oh…anybody know where this is going?
I had detailed knowledge of the competing product and was not concerned because I knew that they did not have a product configurator, a very complex piece of code, never mind a sophisticated configuration tool that created manufacturing bills and routings.
Of course you know how this ends. The other vendor “mocked” up a couple of screens that looked like a product configurator and because the screens were so easy to customize and attractive they won the deal.
The big lie in the demo process of course was that while it is easy to create screens it is not easy to write complex business functionality to support those screens at the drop of a hat.
Six months later the actual feedback I got was that the “blood was knee deep” in the business because of the cost overruns in trying to develop code that did not actually exist during the demo.
Interesting side note: after I lost the business I was poking around on my competitor’s web site out of frustration and there on the front page in a big yellow starburst was the message that “Dewey, Cheetum and Howe is proud to announce it Product Configurator”.
A hallmark of the ERP demo is that it will try and appeal to the “sizzle” potential of the implementation rather than the “meat and potatoes”.
My rule of thumb: if you are watching an ERP demo and you are presented with something “graphical”, chances are you will never see that functionality implemented or best case scenario in Phase 53 of the project.
In the sales and marketing pitches for ERP software users are typically presented as being empowered with rich content. They are always, young, smiling, lean and in great shape and wearing the latest in fashionable eyewear.
Typically, they are in a group of three racially diverse co-workers and they are marveling at a mobile device filled with powerful and rich data.
Believe me that does not happen in the real world.
A more typical example is the company in the third year of their implementation that is delighted when checks print accurately. Having gone through multiple failed go-live events, two big national partners and several million dollars, everyone is exhausted: financially, emotionally and mentally.
Prior posts in this series:
If you are in the process of selecting a new ERP solution or in the midst of a challenged or failing ERP implementation give us a call.