Forget the bells and whistles, focus on the features that your procurement team needs to get the job done.
Is it time for an eSourcing solution functionality reality check?
As a rule of thumb, there is a list of 10 questions that every procurement team should ask at all solution provider demos. Some of them you’d probably expect, like questions about integration and the administration of configuration settings. Others you might not have thought of, for instance asking to what degree the company “takes their own medicine” by using the technology themselves.
This list of questions is based on experience in two specific roles: first as a procurement practitioner on a team tasked with selecting and implementing an eSourcing suite; and second, as a consultant at a procurement solution provider where the team was often called to participate in the sales process.
It is safe to assume that most procurement professionals haven’t had the experience of being on the sales side of a bid process in their current role. It is most interesting when your company wins the deal. Obviously, winning is more fun than not winning, but that’s not it. When you go from prospect to partner, you get the opportunity to reflect on the selection process in the context of the priorities and maturity of your newly won customer.
There are three areas of solution functionality that everyone demands, but which at least 90% of companies were not prepared to use.
Companies regularly collect more information from suppliers than they absolutely need because this provides them with options. In theory, the more qualified options procurement has to present to the business, the more value they can create. Optimization automates the process of 1) calculating the cost and 2) ranking the value of different supplier proposals. Here’s the thing – in order to benefit from optimization, you need to know all of the award constraints and be able to enter them in the system.
It is also hugely helpful if you can score/rank the qualitative benefits of each supplier. Without this, procurement will be left with a nice neat ranking of suppliers by price – one that does not align with the business’ view of the category at all. It is much harder to articulate the basis of potential award scenarios with the specificity required for a system to understand them than you might think.
“How many data points can your system handle per project?” It’s a question that any competent provider should be able to answer right away. You can think of this as items * spec fields * bid fields * suppliers. The number balloons quickly in certain kinds of projects, reaching tens of thousands of data points that pose a challenge to import/export, analysis and optimization.
Perfect examples include sourcing events for location-based services (floor washing, grease trap cleaning) and LTL freight (because of the number of lanes and suppliers involved). While data point scale is absolutely essential for certain kinds of projects, they are not usually the norm. Too much focus on this type of detail may lead to the selection of an overly expensive, overly complex system that will be next to unusable in the vast majority of sourcing projects.
One of the primary reasons most companies have for implementing eSourcing is to get their procurement teams away from spreadsheets for bidding and analysis. Given that, it is amazing how many companies will select and implement an eSourcing platform, only to attach a spreadsheet in the bidding section and ask suppliers to input one final number in a single bid field while submitting all of the bid detail in the spreadsheet!
If procurement isn’t skilled in the fine art of cost modeling – and able to create a cost model that reflects the need for standardization across bids as well as the flexibility to allow suppliers to move – you honestly don’t need anything more than the most basic bid field functionality.
Not to violate professional standards and name names, there are plenty of companies out there who chide prospective suppliers for not having expansive functionality even when they are nowhere near ready to use it. There is absolutely no harm in asking about the development roadmap or making sure the technology will grow with procurement as their learning curve progresses.
That said, you’re doing your team and your company a disservice if you are focused on a provider’s ability to get you to the moon, when you’re still getting comfortable leaving your front yard. Instead, define the functionality required by 80% of your company’s sourcing projects and pick the best solution for addressing those.