To infinity and beyond isn’t just the goal of Buzz Lightyear, it’s also an accurate description of how often tech buyers make this critical mistake. And what is this critical mistake?

Not negotiating an easy, full, self-serve, cost-free, 100% DATA OUT clause in the contract — and forcing the supplier to prove it works one third (or one half) of the way into the agreement.

Sure, buyers always ask “can we get our data out if we choose not to renew” and sure suppliers always say “of course you can get a full data dump“, but the supplier rep is always going to say yes after the developers say it’s possible (but that doesn’t mean it’s encoded in the product, and more often than not with older platforms it requires the tech team to do the data dump — which might be more difficult and take a lot longer than they expect because they are using a shared database, have data and files split across multiple databases / servers, or they can only extract data a few files / tables at a time — and it might even come at a huge cost for their time), even if it’s really not. (It’s not just whether or not the development team can extract the data, it’s whether or not they can do so in some sort of standard format that would allow you to at least load it into a standard database or file storage system.)

The most important thing to remember is that even if a solution is the perfect fit for you now, it does not mean it will be the perfect fir for you next year, and by the time renewal comes up, due to changing organizational needs, changing provider directions, or a combination of the two, it may no longer be appropriate at all. Should this happen, you need to be able to migrate to a new solution quickly and easily, and this will require being able to extract all of your data from the current platform, self-serve, in a standard format that you can then push into a new platform as soon as that new platform is identified.

The only way to ensure this is to insist on a clause in the contract along the lines of the following:

The platform will contain a self-serve feature that will allow a buyer administrator to export any and/or all data in _____-format (e.g. XML, flat-file) in accordance with standard _____ (e.g. cXML, SQL) in a format that will allow the data to be immediately loaded into _____ (e.g. SAP, mySQL) application by executing a single load control-file/script. Attachments, if not stored in the database, should be capable of being downloaded in a (multi-)part ZIP file, with names and relative directory paths matching any indexes in the database directory files. If still in development, this capability must be fully implemented before one third [or one half] of the subscription term has expired.

Furthermore, on or before YYYY-MMM-DD, the supplier will walk the buyer administrator through a test of the export process wherein the buyer will self-serve export all of the data and then load it into a test instance of the indicated backup system. Should the test fail, the supplier will be subject to a monthly subscription penalty of X% a month until the functionality is complete and the test succeeds. Should the functionality not be finished by the time two thirds [three quarters] of the subscription term has expired, the supplier will be subject to a monthly subscription penalty of 2X% a month (as the buyer will have to invest in manual effort to recreate critical data in backup systems).

Any supplier that objects to the first part of the clause is likely NOT one that you want to be considering as most modern platforms support full data import and export through APIs and are built on the principles of data sharing. Furthermore, if the platform still doesn’t support export in a standard format, but claims they are working on it, you should expect most of the capability within a year if the platform really is serious about joining the modern data sharing club (and, thus, should not balk too much at the second part of the clause if they truly are serious as it should only take a few months to figure out a good export module for even a large schema).

Depending on how much data you produce, and how much manual effort it would be to manually recreate a copy of the data you can’t extract, X=20% would not be unreasonable in our view.

Finally, note that this requirement not only protects you in the situation where the platform isn’t right for you, but also increases the chance the platform will be right for you, as a platform that supports open data integration can usually be augmented with ease if you need additional functionality in the future, but don’t necessarily need a whole new platform as the current platform still does what it was purchased to do just fine.

For every win you hear about (usually in the form of some ridiculous “we saved X Million thanks to Big S2P Suite Installation“, but that’s a rant for another day), there’s always someone muttering under their breath how their Source-to-Pay module or suite was a partial to complete failure. The reality is that any tech solution, no matter how good it may be for someone else, can be a dud for you if you aren’t careful about selecting the right type of solution from the right vendor.

That’s one of the reasons we are doing a large (initially 33 part) series on Source-to-Pay right now, so that you get an understanding of what each core module should do, and could do, can figure out what modules you need now, and identify the core features that are a must have. This isn’t the full picture, and we can’t provide the rest of it in just a single post (and have written dozens on the subject in the past), but we can outline five mistakes that, if avoided, greatly increase your chances of (great) success.

Lack of understanding of the real value proposition from tech

This is probably the biggest, and the main reason we indicated that, once you have a solution in place that captures all of your spend data (i.e. e-Procurement baseline), you should do a spend and opportunity analysis to understand where the real cost control opportunities are. (Notice we are saying cost control, not savings, as you don’t get savings until you have processes and technology in place to actually capture the savings you identify. Otherwise, you identify the possibility, but don’t actually capture them. But don’t get us wrong, your costs will go down, sometimes significantly, but properly selected and implemented source-to-pay technology should deliver two rounds of cost reductions — an initial round when you start capturing all of the opportunities you previously identified, and then a second round when you are able to start using it to identify new cost reduction opportunities.)

The key here is to understand, for a given solution, how much cost reduction you can reasonably hope to capture in years one, two, and three (given that you will likely have to sign at least a 3 year subscription agreement to get a decent subscription rate), and what the total cost of ownership is going to be over those three years. (It will be more than just subscription cost, there will be implementation and integration costs, training costs, and internal costs when your IT team is working with theirs to make it work.) If the total cost reduction that can be reasonably (read: conservatively) expected for the first three years is not at least five times the total cost of ownership (with at least a 20% buffer), chances are that either the value proposition is NOT there (or you don’t really understand what it is yet and should either research further, find a different vendor, or, most likely, move on to another module).

Not knowing your true numbers — for spend, suppliers, contracts, orders, invoices, etc.

This is kind of intertwined with our first mistake, but needs to be called out on its own. When doing the potential ROI analysis, you can’t make rough assumptions on how much spend by supplier/category (you’ll always be off, and sometimes considerably), how many suppliers (which will be way, way more than you think), how many contracts (which will always be too low, and you probably won’t be able to quickly find a significant number of those contracts if you don’t have a SaaS contract management solution), how many orders (and you’ll be low here as well), or how many invoices (which will be way more than orders as some suppliers will partial ship and partial invoice, may invoices will come in without POs, etc.). Get your numbers, then do your analysis.

Overvaluing the tech (and AI)

This is the biggest mistake you can make, and goes hand-in-hand with not doing the homework required to work out the real value proposition from the tech. Whenever you hear “we saved X Million with Big S2P Suite Installation” you should immediately ask all of the following questions in order:

• how much of that was truly do to tech vs. actually instituting a process that the tech enforced (i.e. the implementation of a new supplier management platform also instituted a process that ensured all suppliers were properly qualified before being onboarded, which minimized future event time and, more importantly, prevented orders to unreliable, poor quality, and even fake suppliers and considerably reduced organizational loss due to bad suppliers — most of those savings were due to the process, not the platform; the platform would be correlated with the development processes it was then used to manage after the suppliers were onboarded)
• of what was actually tech, how much of that was due to baseline capabilities, and how much due to advanced capabilities (that are semi-unique to that supplier’s tech and not widely/otherwise available); for example, if the tech in question was e-Sourcing, and the vendor was one of the few that offered decision optimization, how much of that was achieved just with the baseline RFX/Auction capability (i.e. best bids and standard award methodologies, lowest bid by supplier, lowest total bid by category, etc.) and how much additional savings was from decision optimization once ALL constraints were taken into account.
• how much more the organization paid for that advanced capability and how often it was actually used / required to get savings [if it was only used 10% of the time, and only identified considerable savings half the time it was used, is it really worth it? or should the organization just do a one-off services project when those categories come up]
• how much the savings actually relied on ML/AI, vs. just providing a fancy NL interface (when the same result could be accomplished through submenus or a few filter definitions / selections);
• and if any savings can actually be tied to ML/AI (vs. good process and more predictable technology), what the risks of failure are here!! [i.e. if the savings were due to reduced stock-outs as a result of the “AI” doing auto-replenishment orders as needed to adjust to demand fluctuations, what happens if there is a temporary, extreme, demand spike due to a near end-of-life sale, will the algorithm assume that is a sign of demand resurgence and fall prey to the bullwhip effect, sticking the organization with tens of thousands of units it will never sell without a fire sale?

Basically, at the end of the day, more often than not, when a customer says “we saved X Million with Supplier’s Spectacular Solution“, you would gain at least 80%, if not 90%, of those savings by implementing any any other solution with the same baseline capabilities that enforced the same processes be followed. (And this is the best argument ever NOT to overpay. Paying 5X to 10X for an incremental 10% is usually NOT worth it unless your organization is a F500/G3000 with over 1 Billion in annual spend. Again, it’s all about that ROI calculation.)

Misunderstanding the SaaS provider’s viewpoint

Not the salesperson’s viewpoint (which is to sell, sell, sell and match you with the solution they think is the best fit so you will be enticed to buy), but the SaaS provider’s viewpoint. Regardless of what terminology the SaaS solution provider is using:

• what are they actually selling now
• what are they currently working on that you can expect to be completed before an annual roadmap revisit
• where are they going with the tech (i.e. they are AP/Payments — are they doubling down and adding support for global payments and clearance in more countries, or are they just sticking to the basics [and only good for post-audit countries] and working on expanding into broader P2P or the new intake-to-pay/procure/process trend)
• what is their support and training philosophy — all in-house, hybrid in-house and third-party (and you can/can’t choose), or all third party
• what is their target market — preferred customer size, preferred industries, etc.
• what is their philosophy on working with customers — do they take input? hold working groups? or do they just develop the features they believe are most likely to fill gaps or increase efficiency with little to no input to keep development rapid and costs down?

At the end of the day, if you don’t understand this for each provider you are considering, you won’t know if they will be the provider for you.

Failing to find the right relationship

This happens more often than not, partly due to not understanding the most appropriate tech requirements for your organization at the present time, and partly due to not really understanding both the culture of the provider and it’s viewpoint. True value materializes when you find the right tech from the right provider that will not only work with you to ensure you get that ROI, but has a vision that is congruent with where you want your organization to go.

Are these all the mistakes you can make or all the mistakes we’ve seen? Of course not, but these are some of the biggest, and if you avoid these, your chances of success shoot up considerably.