We’ve written recently about a core problem with Requests for Proposals: poor internal stakeholder coordination.
It creates a number of derivative issues:
- Poor specification of requirements: the organization fails to exploit its internal knowledge and connections
- Lengthy procurement cycles: decision makers struggle to obtain consensus
- Poor visibility into the value chain: without knowledge of or contact with contractors in the chain, managing risk in an opaque supply chain is difficult
When you put it all together with some of the other challenges imposed by the RFP process, the net result is the original sin of procurement: too little competition on price and solution, making it far less likely for the buying enterprise to find the right solution to their problem, offered by the right supplier, at the right price.
This ties into technology. Smaller organizations tend to use email and spreadsheets to manage reverse auctions (if they even execute them at all). Larger organizations are locked into a procurement system, often the sourcing module for the ERP system. In the former case, it can be a paralyzing blizzard of paper. In the latter, the use of the system is often restricted to the procurement department, given its complexity.
In either case, the organization fails to exploit its internal data and to promote collaboration across the various stakeholders involved in the RFP. When buying a good or a service to solve some problem, the entity usually convenes a committee made up of people from various functions: operations, finance, engineering, support, sales, the C-Suite, etc. None of these people are given access to the procurement technology.
How do we get the most out of our internal committee? How do we maximize their productivity?
There can be a jury rig solution for this. For collaboration, we could tack on a corporate messaging system. For data, it could be something as simple as a shared drive. When it comes to evaluation of the proposals, there may be a spreadsheet that goes around soliciting feedback on supplier proposals.
This setup is problematic for at least two reasons.
One, people are inundated with technology solutions already. Standalone messaging tools are like the dog collar of contemporary corporate life, reducing the individual’s control over their time and energy with its constant yank for attention. Email inboxes are polluted enough before adding additional traffic related to procurement projects.
People tell us they want a single contained, dedicated space for their procurement activities, especially when it is not their primary or even secondary function. They want a place where they can log in (when they want to work on the project), see all the relevant data, and be able to communicate with all the relevant people. They go in, do their work, and log out, resuming their primary job.
They want control over their time. They’re more productive and they’re happier when they get to dictate when and how they work on procurement projects.
Two, people want to have access to data and, if possible, tools that can help them make better decisions, faster. The jury- rigged approach where the procurement team act as gatekeepers for the sourcing system is insufficient.
At EdgeworthBox, we have built the dedicated, contained system for procurement. It’s a one-stop shop. People from outside the procurement organization can interact with one another, the procurement project, and the right tools to help them manage the project more efficiently. It takes less time. It makes people more productive. Our user experience is welcoming for everyone, including suppliers. Lowering the frictions suppliers face means more proposals, at least at the margin. More proposals means more competition. Procurement can use EdgeworthBox as the system for interacting with all the stakeholders, pouring the data that they need into the ERP system-of-record when necessary. EdgeworthBox sits as a procurement-enabling layer on top of the existing procurement infrastructure.
Let’s talk.
