Just like RFPs and contracts are integral to procurement, so are catalogs – they help one choose the right product or service to fulfil enterprise
All we want is more - but we’re not sure what for
For this blog contributor, the last couple of weeks have been crazy, not because of the travel with extended long weekends, but because of the apparent need for companies to adhere a little too strictly to their policy rule book.
A good number of the prospective customers I have met recently have had their own set of reasons, issues and business challenges that, ‘as per policy,’ has forced them into an interminable vendor selection loop, ironically for a cloud-based application that will be used for…vendor selection.
Almost all of these companies provided us with scripts, scenarios and long-form documents outlining each procurement function for us to simulate in front of a user group; the goal being to excite them with the possibilities of changing how they work for the better.
This is fine, by us. We can certainly cope with any scenario.
But there a bit of a problem. The members of these user groups had been asked, individually, to provide high-level wish lists of functions they believed would make their work more efficient. These lists were then collated and shared as the requirements list. The “need to haves”.
As Solutions Design Consultants, we went well prepared, of course, and set about thoroughly showing off each scenario and use case prescribed in their scripts.
Only for some wise soul to speak up with: “It seems your software can handle really complex stuff; but we are not there yet. We currently do only 10% of what you have shown.”
As I said this has recently been a recurring theme in many of the meetings I attended.
There was the moment of truth, and clarity for us.
Why the long scripts, the complex scenarios, this blue-sky stuff that you don’t even do today?
This seems to be paradox in many companies today. A lot of time is spent imagining how thing could be in an ideal world, and much effort is put to drafting complex requirements that would put the most sophisticated and mature supply chain organizations to shame.
But the reality is buyers would better serve themselves by being more pragmatic in identifying what they need to do today, right now, and maybe a bit tomorrow.
Instead of approaching a selection with a long list of features and possibilities for that ideal world, they might look more closely at the rather less exciting set of their needs today and seek out vendors who can better blend into their culture, be flexible and work with them to help them grow along a learning curve.
After all, the purpose of a procurement software solution is to make things easier and simpler for the users to procure goods and services. Starting from the most complex possible set of requirements is probably not going to help choose a system that’s going to work for you. But it does seem to be a popular approach.
Giving technologies human names can be problematic. Especially for those people whose names have been appropriated by the device manufacturers.
In an earlier post, we established the importance of simplified and satisfying enterprise technology experiences as being the primary drivers of us