Investing in a new software or technology platform is always a big decision. And, if the implementation isn't done right, it can do more harm than good. Read this post to learn how you can effectively implement new procurement technology or software, while saving on time, money and efforts.
July 20, 2016
One Size can fit all, as long as it can change shape.
The previous post to this blog revealed a challenging trend in solutions selection – the prioritizing of “feature count” over utility and suitability.
In a way it’s a pattern we’re familiar with as consumers. When we shop for something – be it a new mobile phone, a washing machine or a new mattress for the bed, we place high value on the plethora of “features and functions” and focus less on suitability for the task in hand.
Memory foam, pocket-spring count and breathable fabrics are all well and good, but if you don’t get a good night’s sleep then you should have chosen a different mattress.
The problem in B2B technology is, however, that the smallest feature could be the overriding reason why a piece of software works for one company, or not.
Thus, the combination of the desire for an increased number of functions (whether they are used or not) and the significant impact the right function might have, leads to the general over-engineering of business software in an attempt to please all of the people all of the time.
Indeed, it is true that nobody uses more than 10% of the features of any major software system.
That is, no individual user uses more than 10% of the features of any major software system. But although my 10% might overlap with yours, it is unlikely to be identical. So, taking that to its logical conclusion, amongst all the users of a business software system, it is likely that every feature will eventually be used by someone.
But is that a justification for continued feature-stuffing? Perhaps not.
Here’s one opinion: Procurement software exists for a purpose. As a tool, or rather a toolset to enable procurement professionals, purchasers, strategists and finance folk to more effectively deliver value to the business, be that in terms of savings, cash flow, efficiency or whatever. It doesn’t exist to deliver technical superiority in some kind of battle-of-the-systems competition between software developers.
And this is an interesting notion. Too much emphasis is placed by vendors, and indeed buyers alike, on feature-parity and whose software has which widgets and whether the system allows procurement pros to conduct “Reverse Japanese Auctions with Bonus/Malus in Icelandic with final-minute automatic extensions and second-to-lowest safety-net auto re-bidding.”
The technical capabilities are all well and good but they can lead us to lose sight of what the software is for. Procurement is not like manufacturing. In manufacturing there is usually only one way to assemble the finished product from the components or raw materials and any change in the process is likely to be costly and disruptive.
In procurement, there are many ways to arrive at the best deal whilst negotiating, many ways to arrive at the most mutually beneficial contract wording and many ways to structure the process of req to cheque workflow.
In effect you can arrive at your ideal combination of supplier, terms and pricing via RFP, auction or even old-school meeting and negotiation. The result should not be determined by the mechanism you choose to get there. You don’t need any particular software feature to get the result you need.
To suggest that a single feature can be some kind of panacea for all procurement’s ills is to put too much faith in the software itself.
Too often the rationale for scoring software with a thumbs-up or thumbs-down is its capacity to deliver against one highly-specific use case. But this is a red herring. Procurement software needs to be configurable around how you can get the best out of your supplier relationships, and needs to be able to be reconfigured as circumstances change. Highly-specific requirements are all well and good, but experience teaches us that they have a tendency to change, or even become unfashionable.
Smart developers today have to consider the business they are developing for first, and then think about feature and functions in light of what the business needs.
There’s an old urban myth that, during the Apollo program, NASA developed – at considerable cost - a ball-point pen so advanced it could write in zero gravity. The Soviets, it is said, used pencils.
Whether true or not, it goes to show that tech that’s stuffed with whistles and bells isn’t necessarily the only possible answer.
Of course, there’s a minimum acceptable functionality, and in procurement software the bar is quite high – software like SMART by GEP does do an extraordinary amount, including all the variations alluded to earlier. But the point is this:
Just like when shopping for a mattress, you shouldn’t choose your software on the number of features it has alone, but on the difference it can make to your level of comfort. There are many ways to spend a night, the trick is to spend it well and not end up so distracted by features that you never get any rest!
Image credit: pixabay