Category Archives: Technology

The MOST Important Clause in Your (Procure) Tech (SaaS) Contract (Part III)

In Part I we told you that

  • while you might think there is no single most important clause as there are a lot of important clauses, especially if you ask around,
  • liability or penalty clauses are quite important, or that
  • termination matters

the reality is that

  • there is a most important clause, and it’s not what you think,
  • liability is worthless if collecting costs more than you get, and
  • you can’t terminate if you don’t have another choice!

We also told you that, after signing the contract, there is a good chance you will be screwed to some extent, whether or not the provider intends it. Between:

  • psychopathic salespeople who will promise anything to sign the deal (and off to their next job before the reckoning comes),
  • investor owners that are going to limit/cut support when unreachable sales targets are not hit, forcing the C-Suite to pick and choose who to screw over,
  • the fact that your vendor will likely be acquired (because if it’s not, it’s likely to go out of business since there are almost 10 times the number of vendors we need in ProcureTech), and
  • the fact that a struggling vendor with the best of intentions will take on too much and be forced to leave some customers high and dry

the chances are, like it or NOT, that you are going to be screwed. (And possibly doomed and entombed by the proprietary software using proprietary data formats that you probably shouldn’t have bought.)

This means there is one clause that overrules them all:

IT’S MY DATA … AND I CAN, AND WILL, GET IT ANYTIME I WANT IT!

Then we made it clear in Part II that while you might think it’s your data, you’ll think again when something happens 6 to 18 months down the road and you need to get it out. Chances are that, unless the developers give you a full database dump (in an underlying schema you have no documentation for, using encryption you have to acquire third party software for), you will be limited to exporting a few reports, and small transaction or record sets at a time. (Unless, of course, you include a clause mandating this, test it after all of your data has been imported and you have run a few events/processed a few thousand transactions to augment it, and penalty and termination clauses with damages and real teeth if this critical requirement is violated.)

But what we didn’t make clear is:

YOUR DATA IS MORE THAN JUST YOUR DATA

It’s also your configuration!

–> Who is using the software and what access rights they have.

–> What processes and workflows they are using.

–> And, most importantly, how those processes are configured!

Now, we’ll be brutally honest here and say that while you can’t expect to be able to import these settings into the next app you get for the same purpose, because every app is slightly different with slightly different configuration capabilities, workflow, etc.

It is very likely this is the only documentation you have of:

  • who is allowed to use the software and what they are permitted to do
  • what processes and workflows you are following
  • what approval processes you are using and who is actually approving
  • and so on.

In other words, it is very likely that the ONLY documentation you have on your processes and practices is in the tools you are using, and, more specifically, in the configurations. Thus it’s absolutely essential you be able to export those as well. Even though you will have to manually recreate them when you switch platforms, it is still better to have documentation on what you were doing, and who was doing it, than none at all. Plus, you can then analyze your processes and find opportunities for improvement with these records!

So make sure that when you select an app you can get your data, and we mean all of your data, at any time before you sign on the bottom line. That way, no matter what happens, you’ll never really be screwed.

The MOST Important Clause in Your (Procure) Tech (SaaS) Contract (Part II)

In Part I we told you that

  • while you might think there is no single most important clause as there are a lot of important clauses, especially if you ask around,
  • liability or penalty clauses are quite important, or that
  • termination matters

the reality is that

  • there is a most important clause, and it’s not what you think,
  • liability is worthless if collecting costs more than you get, and
  • you can’t terminate if you don’t have another choice!

But this isn’t the worst of it! The worst of it is that, after signing the contract, there is a good chance you will be screwed to some extent, whether or not the provider intends it. Between:

  • psychopathic salespeople who will promise anything to sign the deal (and off to their next job before the reckoning comes),
  • investor owners that are going to limit/cut support when unreachable sales targets are not hit, forcing the C-Suite to pick and choose who to screw over,
  • the fact that your vendor will likely be acquired (because if it’s not, it’s likely to go out of business), and
  • a struggling vendor with the best of intentions will take on too much and be forced to leave some customers high and dry

the chances are that you are going to be screwed.

This means there is one clause that overrules them all:

IT’S MY DATA … AND I CAN, AND WILL, GET IT ANYTIME I WANT IT!

You might think it’s your data, and you might think you can get it anytime you want it as there will be clauses around data protection, privacy, security, etc. as well as acknowledgements that you own your data, it will be kept separate from competitors, and the provider will not use it except to serve you, which may include using limited anonymized portions of it in community data.

And you might think you can get your data anytime you want it because they will guarantee up time, allow you to export transactions and reports, and so on.

But ask yourself this. Of the hundreds (and possibly beyond a thousand) of SaaS applications your organization currently uses, and has used throughout your career there, how many could you, self-serve, do a complete export of all of your data on-demand? And by all of your data, I mean all of your data. Not just reports or summaries or core record subsets. When sourcing, all suppliers and all related 360-data — all risk scores, compliance certificates, performance KPIs, related transactions, related bids, related events, product catalogues, tooling data, etc. In Procurement, all documents related to a transaction — not just the invoice but the purchase order, acknowledgement, goods receipt, credit note, etc.

When we say all of your data, we mean ALL of your data. Chances are, you can’t get it self-serve from your SaaS Application. You might not even be able to get all of your data with help from the the provider’s services personnel. For some applications, the only chance is if the developer does a, relatively undocumented, database export. And good luck with that!

This means three things.

  1. If the provider says that have no way for you to get all of your data at any time, you should not consider them.
  2. You must have a clause that:
    • allows you to export all of your data self-serve at any time (although it’s reasonable for the provider to charge a fee if we’re talking many GBs or TBs and you decide to export all of it on a regular basis, but you should be able to do this, depending on the data velocity and volume, at least once a quarter, month, or week, for free) in a standardized format; in addition, you must also include a modified
    • penalty clause with a significant penalty if you cannot do so by whatever date the baseline implementation is supposed to be completed; a (modified)
    • termination clause if the provider is unable to correct this by a certain time, and a (modified)
    • liability clause for the damages incurred as you will have to find another solution and will have lost time and money on implementing the providers solution.
  3. You must test the ability as soon as the initial import of all of your data is complete, and again in a few weeks once you create a whole lot of new data in the system (updated profiles, end-to-end sourcing events, thousands of new transactions with associated documents, etc.). We realize this will take a lot of time, but much less than trying to figure out what to do six to eighteen months down the road when the vendor fails (you) and you’re left high and dry.

That way, if the provider

  • fails to complete the implementation and required integrations in a reasonable time (and you’re unable to adopt the system),
  • sells you something they don’t have and may not have within the timeframe of the initial agreement,
  • gets acquired by a larger vendor with no intent to support the solution longer than they feel it will take for their forced migration to a higher-priced solution you don’t want, or
  • serves you a notice that it is winding down operations

you can keep going. As long as you can export all of your data in a standard, documented, format, you know that there are a dozen (if not dozens of) providers who will happily convert it to to their format (for free) for your business. Just be sure they will also agree to the same IT’S MY DATA … AND I CAN, AND WILL, GET IT ANYTIME I WANT IT! before selecting them!

The reality of the situation is that there is no unique capability in business data processing that can’t be, and isn’t, more-or-less replicated by dozens of other solutions. Sure they have different UIs, add or subtract process steps, and use different data storage formats, but universal business processes are universal, there are dozens of ways to do them, and get around the software patents supposedly protecting them (which should be banned in the US, as they are in the EU). The next solution might not be as custom fit as the one you are forced to abandon, but it will work (as long as you have unhindered access to 100% of your data). That’s the point.

As long as you can always get your data, you’re never completely screwed. (And once you’ve switched, if the losses are still significant, then, if the C-Suite wants to pursue, you can let the lawyers have their day. You won’t be held ransom by a vendor holding your data hostage.)

The MOST Important Clause in Your (Procure) Tech (SaaS) Contract (Part I)

While you might think there is no one most important clause as there are a lot of important clauses, especially if you ask around.

  • In Procurement, you will want implementation in the promised timeframe
  • Finance will want holdbacks and penalties if functionality is not delivered or timeframes are not met
  • Risk Management will want clauses around cyber-security and privacy
  • Legal will be very concerned about governing venue, liability, and standard termination clauses,
  • etc.

And those are all important, but the reality is:

  • regardless of what’s in the contract, the solution will be implemented when it gets implemented, and delays will be blamed on your IT team, partners, etc. especially if it is their fault
  • you have to prove it was the vendors fault to get any penalties enforced, and that will be very hard indeed
  • good clauses alone are not enough if a cyber-breach or data-breach happens, your customers will still be coming after you
  • the legal venue usually isn’t that important, the only time liability typically comes into play is if customer data is fraudulently accessed as a result of the provider’s failure in security or there is a massive prolonged system failure, and, no matter how bad the performance, the contract won’t be terminated unless there is outright fraud because the organization still needs a system
  • etc.

which means that, while important, unless there was outright fraudulent representation (or serious negligent misrepresentation) in the signing of the contract, none of these clauses really matter as they aren’t protecting you nearly as much as you think they are since any damages you would be awarded in court would be limited to fees paid, which could be dwarfed by the legal fees and mounting losses while you waited months or years for the situation to be resolved!

Moreover, when you consider that the average company is not a Fortune 500, and no longer has (multi-)million budgets for SaaS, that means that most of your purchases are going to be in the (low) six figure range. This means that the vendor knows that the cost of any legal action that would arise plus the losses that would be incurred by the organization that takes action will dwarf the fees paid, and that means that the likelihood of any action coming the vendor’s way is minimal. (Plus, after all of the glowing recommendations you gave the vendor to the C-Suite upon selection, to their customers in the all-expenses paid customer event at the fancy resort destination that was offered to you as a big new name customer, and to new potential customers in reference calls when you were still enthralled by the shiny screen, they know you won’t want to come forward and admit how wrong you were.)

This means that a good portion of you will be screwed to some extent. Let’s consider the reality.

  • Once FinTech, and then ProcureTech, became hot, you had all of the top performing sales people from across enterprise tech move in — and not all of them are altruistic; in fact, some of them are as psychopathic as they come and will promise anything to get the deal signed, even if they know the vendor organization CAN NOT deliver
  • Many providers have been capitalized at multiples of 7, 10, 15, or more by VC and PE firms looking for the next unicorn and are under pressure to reach ridiculous, and wholly unrealistic, sales targets and will effectively over promise to get sales and then underdeliver when the investors don’t allow them to hire enough support personnel due to not hitting sales targets
  • There are over 700 providers in a space that offers less than 10 core modules. That’s almost 10 times the number of providers that are needed. Most will not make/retain profitability and, thus, most will not survive. Some will go under, others will be acquired in fire sales or discount sell offs by investors who cut their losses before they lose it all. Even if your vendor gets acquired, chances are the acquirer will gut it and support levels will significantly decrease (and new development come to a standstill).
  • If the vendor needs the sale to get the bank loan, keep their jobs, make payroll, even the best providers will assume they can figure it out later with money in the bank, but this won’t always happen, especially if they are behind on promises to other customers.

In other words, even if the sales person and the provider had no will intent, you are still likely to get screwed.

This means that the most important clause in the contract is …

Technology Has Improved, But It’s Still Not Solving Fundamental Problems!

In a recent Procurement Insights posts, THE REVELATOR tells us that a 2007 challenge is finally being addressed in 2025, and he’s right in that it’s being addressed, but parts of the problem are still not being solved. But before we can dive in too deep, let’s review the four points from his 2007 post on the Change Management Myth.

The core of his eighteen year old post was the statement that many failures stem not from resistance to change itself but from deeper systemic issues in how technology is deployed, which is often the case because, when the system selected is the one with backing from the core team, there is obviously some desire to change, but something is preventing that change from happening. Based on interviews and discussion with third parties, including one with a professional who had over a decade of public sector Procurement system implementations at the time (remembering that the first procurement system only went live twelve years before his post eighteen years ago), he identified four key reasons why automated procurement systems fell short and resulted in poor adoption and outcomes.

These four reasons were:

  • lack of technical savvy and cultural understanding
  • procurement module was an ERP afterthought
  • lack of process mapping/improvement before automation
  • discrepancy between promises and delivery

While technology has improved greatly, as far as I’m concerned, two of these still aren’t being solved because the technology that is addressing the issues are not solving the fundamental problems. In THE REVELATOR‘s post, he points to an AI-powered “digital team member”* agent solution (and one custom built for the SAP ecosystem) as an example of a technology that addresses the four problems (but we will not name it as we don’t want to be negative on a particular technology that does offer some value to customers in Ariba jail). Our goal of this article to address the statements he is making and the fundamental requirements to solve the problems that still plague our space).

According to THE REVELATOR, each of the problems are addressed for the given reasons:

  • lack of technical savvy and cultural understanding because these platforms minimize the need for advanced skills with conversational interfaces and email integrations that don’t require extensive training and that “implicitly teach the why” by delivering immediate value
  • procurement module was an ERP afterthought because this technology is purpose built for procurement, enhancing the across-the-board experience by implementing and supporting “best practice” out of the box
  • lack of process mapping/improvement before automation because it inherently improves processes by AI-triage, prioritization, and workflow embedding while analyzing data in seconds, eliminating manual entry, and supporting iterative testing
  • discrepancy between promises and delivery because seamless integration allows for instant impact, results, and measurable ROI

And each of these approaches is an approach that addresses the problem. However, it does not solve two of them, and that can lead to even worse errors being made then before. Namely, it doesn’t do anything for:

  • lack of technical savvy and cultural understanding because guiding a person through a process, which is the one statistically estimated (i.e. guessed) to be the correct one, does nothing to address their lack of technical savvy or Procurement understanding, and, in fact, if it makes the process too easy or, on the easy test cases, gets the process too right, it leads the user into a false sense of security, just like vibe coding (which results in over half of the code being produced having serious security issues) or vibe physics (which sometimes results in delusions and sometimes even early stage “ChatGPT” psychosis), except in this case the user will happily authorize a million dollar purchase for the wrong product if the system doesn’t detect it’s the wrong product
  • lack of process mapping/improvement before automation is not solved by slowly “learning” processes post implementation, and letting the system guide you on “corrections” because probabilities are not certainties, and if you don’t do pre-implementation process and data mapping, and understand the state of your data (and, if necessary, cleanse and enrich it), the system could make very wrong decisions (because it can only compute on the data it has, and if that data is bad, the recommendations will be very bad)

Not only does too much AI not solve the problem, but it actually exacerbates it. While we do want Augmented Intelligence, we want carefully designed, selected, evaluated, and implemented Augmented Intelligence where we can have very high confidence in everything it does because we pre-verified it, understand its limits, validated its data, and never apply it inappropriately. Plus, we want it to support our thinking and analysis, not have us support it when we have no clue where it’s coming from.

At the end of the day, we want better educated and trained personnel, because then they will know what tool to use where, how reliable the answer will be, and when a process can be fully automated vs. when you need manual checks. And then we want to give them the technology that makes them up to 10 times as efficient at their job by automating all of the tactical data collection, processing, analysis, and summarization so they can review everything they need to make the right decisions, select the right options in the system, and then have the system automate the tactical processes that come after. That’s not being guided by AI, that’s guiding the AI. That’s not just a semantic difference, it’s a significant process difference that can have a significant impact on Procurement efficiency and effectiveness.

* Let us remind you that AI Employees Aren’t Real!