Robotic Process Automation (RPA); for some, it spells a technological coming of age that’s set to make work easier for all humankind.
Set Your Procurement Process to “Automatic”
How many settings does a washing machine need?
Or come to that, a camera?
It would seem to be the case that the more settings there are, the higher the price. Of course, this is right and proper, isn’t it? If you’re emptying your pockets (or even your bank account) to get the latest and greatest device, whatever it is, you want to be sure it can do absolutely everything.
So it can handle your bed linen as well as your silk shirts (the washing machine, that is, not the camera), or it offers you ultra-close-ups and natural skin tones (not the washing machine).
So far, so satisfying. That’s great, it can do ALL this. But for ease, just set it to automatic, eh? In my household, we used to have a washing machine with a dial labelled A to J. We used E. “E for Everything”, as it became known.
Would we pay as much though for a device, whatever it is, that had just one button? Perhaps a big friendly one that had “Wash” written on it? Or “Photo”? Almost certainly not. Complexity sells.
As a bit of an electronic music enthusiast I recall the launch of the truly ground-breaking Yamaha DX-7. Even typing the name make my hands sweat ever so slightly. The staggering sounds that it could produce straight out of the box made it the most desirable machine of its kind. But, and it was a big but, it had no knobs! Synthesisers had knob. And sometimes cables. Knobs and cables, patch panels, dip switches…oh the complexity! And then along came the DX-7 with its true-to-life tubular bells but not a knob in sight. Instead an array of identical green rectangles covering barely depressible micro switches were used to select sound or, indeed, program the beast. Slightly disappointing for those who liked to appear on stage surround by what looked like a 1920s telephone exchange. Until, one realised, the DX-7 was almost entirely impossible to program. So-call FM synthesis made for staggeringly rich and sonorous performances but required phenomenal dedication and hours of diligent tweaking to create anything better than the factory pre-sets.
So nobody ever programmed a DX-7. It was universally used as a factory pre-set keyboard. Musicians with the talent to get the best out of playing the DX-7 rarely had the same internal wiring that allowed them to comprehend nine-operator frequency modulation algorithms.
But then again nobody would have bought one if it couldn’t be programmed.
This is the technologist’s Catch-22. You have to have complexity to be taken seriously but your product must be the easiest thing to use. In fact the more complex it is, the more you can charge for it, but the easier you have to make it to use.
There is a corollary to that catch. Don’t make it too easy to use because the psychology of technology equates easy-to-use with simple and limited. People like lots of knobs. So much so we even have a term for it in everyday language. We call them “bells and whistles”.
Procurement software, like all software, is no different. It has to be full of features and functions, bells and whistles, to enable the most complex and specific use-cases and yet it has to be intuitive and usable and simple.
In a recent conversation with a competitor I was asked if the SMART by GEP procurement software had a particular feature, one that is regularly specified as a requirement by our prospective customers. When I replied that indeed SMART by GEP did have that feature, my counterpart replied, “yeah, ours too. Don’t know why, though, I’ve never known anyone use it!” But we both knew if it wasn’t there our two products would be marked down.
So where will this arms race of whistles and bells take us? To products that are so over-engineered they are impossible to use. Well, perhaps, in some cases.
The camera manufacturers got wise to this some years ago and whilst there is plenty of programmability available if we want it, the “auto” settings are now so intelligent that the camera behaves as if it were in the hands of a professional.
What procurement software developers need to do is to understand that their customers need complexity in their sourcing programmes not in the tools they use. Being able to conduct an in-depth selection process, leading to multiple rounds of negotiation and ultimately to a contract execution is a complex enough process as it is. Making the tools used to automate that process as tricky as programming a DX-7 does little to enhance the efficiency of the procurement professional.
The complexity should come from how you deploy the tools rather than how you program them. You should not have to care about too many settings and switches and knobs and cables, you just want to sit down a play the tune.
That’s not so say that there should ever be and “E for Everything” sourcing option but more intuitive and usable tools will let you concentrate on the composition and let the tech look after the rest.
For more interesting thinking on procurement, visit the GEP Knowledge Bank.
How many of us, a decade back, would have imagined that there would come a day when machines, much like a Beethoven or Mozart, would write original