In Part I, after noting that I’ve been hearing and seeing the following too often lately:
- smaller vendors struggling to close/losing deals because the bigger/splashier vendors have more “Bells and Whistles”
- vendors getting lots of (and possibly too much) funding focusing heavy on bells and whistles
I said that we were going to dive into some of the most common bells and whistles and why, in the best case, they’re a complete waste of money and, in the worst case, the thorn prick will end up being so painful that your team will simply stop using the software. (And often do so before the subscription is half, or even a third, up, which leaves you in an expensive subscription jail you cannot stop paying for even though no one is using it.)
But before we continue with the modules, here are two of the most common bells and whistles across all Source-to-Pay platforms that deliver absolutely no value whatsoever.
Flashy UX
A lot of startups over-focus on the UI and UX, believing that the big problem with today’s platforms is that they are too unfriendly and too hard to use (which is often the case with older generation suites, but not the case with the majority of newer, mid-market, suites and best-of breeds) and that everything can be made simple with an AI-driven workflow that makes all of Sourcing and Procurement easy-peasy (which it is if you are buying pens and paper for the stockroom, but that’s about all that’s easy peasy).
They then get professional speakers and presenters to train their salespeople on these very flashy, impressive looking, platforms to give awe-inspiring demos on the pen and paper buying process (with the promise that everything is just as easy) that management and buyers eat up, even though the buyers aren’t allowed to play with it first (and see what happens if they try to source custom built FPGAs for their control systems or specialized implementation and integration services for their new supply chain planning software that needs to connect to the ERP, the direct sourcing module, and the CRM — which is where their over-simplified flashy UX will fall apart completely as there will be no deep functionality behind it).
The reality is that it is not flash, fancy UI, or even AI-driven automation, that matters in enterprise software. What matters is the effort required to do daily tasks of moderate plus complexity, and that is often best accomplished by sophisticated workflows that are pre-configured for different scenarios and very simple, step-wise, input screens (with the current step and complete workflow highlighted) that allow a person to see where they are, why they are there, what they need to enter, and what comes next. It’s often the case that the screens aren’t minimal, aren’t colourful, and aren’t flashy. (There’s a reason that green screens lasted so long and that’s because, well designed, they made work efficient — remember, it’s not personal entertainment software, it’s business software your team might need to use 10 times a day and if the flashy software requires 30 screens because they are all too minimalistic [when it should require 10], or doesn’t support the process at all, it doesn’t matter how good it looks or how easy it is to use.) The best software is designed to ensure that all of the common repetitive tasks, no matter how variable they can be, can be accomplished as quickly as possible with as little human input as possible, and you can’t always make that minimal, flashy, or appealing to the inner artist.
Adaptive AI-Driven Automation
A lot of (over-funded) startups on the Gen-AI Hype Train (who have been Blinded By The Hype) believe that they can use the latest and greatest version of Gen-AI (which, FYI, has a 48% failure rate if we’re talking the latest ChatGPT version as of the time of this being posted) to automatically adapt to all input requests and automate every sourcing and/or procurement process they claim to cover. They can’t. And they never will be able to because hallucinations are a core function of LLM technology (regardless of which LLM you use).
As a result, while it will work great for most of the standard requests and processes and get them mostly, if not entirely right, anytime anything sophisticated or exceptional comes along, it will break down completely. If you’re lucky, it won’t know what to do, won’t do anything, and force human intervention — forcing you to design and build a full process by hand through it’s painful conversational interface that will require you to repeat yourself multiple times and specify the same request in six different, increasingly precise, manners until it builds the process you need. If you’re not lucky, it will assume your request to order 1000 Ford brake shoes (for your fleet of vans) is actually a request to order 1000 Nike Jams (breaking shoes) because your last order from James Ford (a sales manager who likes to abuse his P-Card and gets away with it because he signs the largest contracts and the boss looks the other way) was for Nike Jams, and the system automatically orders 1000 pairs of Nike Jams, shipped to Fords office. Moreover, you don’t notice, because it says order placed, delivery in 5 days, and you don’t bother to verify because you’re in a hurry (and it worked okay on the last 9 order requests you made).
If, in comparison, you had an e-Procurement system that you could setup with standard re-orders off of contracts, you could type re-order brake shoes in the universal search bar and it would brings up the standard order pre-filled with units, supplier, and standard delivery date and you could simply hit submit to get the standard re-order with 100% certainty, or change the supplier, delivery location, delivery time, and/or units to make a simple change. No ambiguity, and no chance of error. It’s 3 words and 2 clicks, and you’re not waiting 15 seconds for it to parse your request and 15 seconds to do who-knows-what and give you a verification.
In other words, bells and whistles look and sound cool, until you realize that the ringing can be deafening to the point it gives you such a headache that you can’t get your work done.
Moreover, after 25 years in the space and 19 as an (independent) analyst, I can tell you that this correlation almost always holds true:
The more bells and whistles a product has, the less actual functionality or support for complex or exceptional situations or process is actually embedded in the tool, and the less useful it ultimately is over time.
The tool will ultimately end up as yet another piece of shelfware (that you are locked into for another year or three if it’s SaaS, and more if it’s not), and that’s why the average mid-sized and larger enterprise has somewhere between 300 and 1000 SaaS applications! (Because most aren’t used!)
Seek deep solutions that solve your problems and allow your team to become more efficient over time, not razzle-and-dazzle solution based on the wisdom of P.T. Barnum: “the people like to be humbugged“.
To make it clear how useless bells and whistles are, we will continue this series and address major areas of Source-to-Pay starting in Part III.