Every week another vendor is going bankrupt or calling it quits. Every week another vendor is getting acquired. Most of the startups, even the over-funded ones, are not going to make it. Even assuming you know what functionality you need, it’s very hard to select a vendor that is not only good for you but likely to be around for the length of the initial engagement, which is probably 3 to 5 years (mid-sized to large) because, any shorter, and you’re spending more time on vendor evaluation, selection, implementation, and integration than actually using the vendor’s product! (And even if you can get a year-to-year contract, you know you still want the solution to last for at least three years to get a return on the time you spent investigating, selecting, and implementing the solution … which might only hit majority adoption at the end of the first year!)
So how do you select a vendor that is not just “good” but “safe”?
Well, let’s go back to our process for vendor assessment and selection.
Stage 0: Find a reasonable candidate pool based on your needs based on quick high level assessments.
Stage 1: RFI Creation
This is where you focus on weeding out vendors that
- don’t have technology that might actually solve your problems (without getting into deep details and demos)
- don’t have the necessary (cyber) security and privacy protections (especially if you are processing payments or private data and have to comply with industry and governmental regulations)
- are just too risky from a viability perspective for you to deal with
- don’t give you a back-up plan if something goes wrong
If it’s a point-based best-of-breed solution designed to solve one problem that could be replaced with another solution through the API, you can probably take a bit of a risk. But if it’s a foundational sourcing execution or procure-to-pay platform that is going to power your sourcing events and category management or your procure-to-pay process, this is not a vendor you can afford to have shutdown or get acquired by a buyer who doesn’t want to support it (because they’re buying for the customer base or dev team).
So how do you figure this out? It’s not perfect, but as we pointed out before, you calculate the relative corporate debt. If it’s too high, the vendor is not financially viable, even if it is “well funded” because most investors, even PE, won’t wait more than 5 years for their return — which is hard to get in tight economies when they invested at a multiple that’s (way) too high — and typically any multiple above 5X to 7X IS if you want a return in 5 years. (That’s why you always need to ask who’s funding your ProcureTech Vendor. If it’s customers, you’re safe. If it’s PE, you have to investigate deeply. A few firms are willing to wait [more than 5 years] for their return if the long-term is very profitable. But a lot of firms are of the “strip-and-flip” mentality, and that’s not good for anyone. And those in between start losing patience around the 3-year mark if they don’t see the sales growth they want, even if their growth expectations are ridiculous!) Collect the key financials and run the equation.
As for security (and privacy), you ask for their SOC 1/2 and certifications and any other certifications that are mandatory or designated as essential by your risk management department. If they don’t have the minimum, you drop them (unless they are in process).
As for functionality, you ask them to describe (at a high level) how they support your key core requirements. The in-depth descriptions and demos come during the RFP process later. The key to selecting a “safe” vendor and not being pressured to select a possibly “unsafe” one because you didn’t do all the right checks until after you fully verified the tech (and you can’t start the process again) is to do the majority of key non-tech validations up front, not at the end.
Moreover, by doing this analysis up front, you ensure that you aren’t wasting time analyzing vendors you can’t risk from a business perspective! Capability assessments take time. If you wait until the end to look at viability, you’re wasting a lot of time whereas the RCD calculation, certification verification, and verifying key requirements of other stakeholders often takes a fraction of the time as the in-depth tech assessment.
As for the back-up plan, here’s all you need to ask up-front:
Can I export 100% of my data, in a standard format, anytime I want it?
Not 90%. Not 95%. Not 99%. 100%!
Not submit a request and ask them to export a database or wait for a weekly backup process to backup and shoot you a copy. Request on the fly, it zips up (possibly into a multi-part archive) on the fly, and you can download on the fly.
If you can always get all your data, then, even if you mess up on the risk or viability assessment or something unforeseen by both parties happens, you have the most critical thing — your data — and you can always go with the next best solution! (And then make sure the clause is in the contract because it’s the most important clause in the contract.)
Now, this isn’t a complete list of requirements, as it will depend upon the industry and geography you are in and what type of solution you are selecting, but it’s a good start!