Source-to-Pay+ is Extensive (P23) … Time for More Contract “Management”, but it’s a NAG. Let’s continue with Analytics!

In Part 21 we noted that after Supplier Management came Contract Management because the only way to lock in the opportunity was to get a contract signed on the bottom line. However, like Supplier Management, Contract Management isn’t consistent across vendors because each has a different idea on what Contract Management actually is … and sometimes isn’t. (And most vendors are jumping on the AI bandwagon faster than fleas on the only stray dog in town, but that’s a rant for another day, or week — there’s so much absurdity here.)

However, as noted in our last post, Part 22, most of the definitions, and the implemented capabilities, tend to fall into three categories: Negotiation, Analytics, and Governance. Yesterday we started by breaking down negotiation and today we’ll continue with analytics.

Before we begin, we should point out that contract analytics is not contract spend analytics, which in many platforms is merely a summary of spend under contract, but an analysis of the contractual documents of the organization. We will also remind you that this is not meant to be an exhaustive list of capabilities you may find, or need, but a starting list of capabilities that should be present in any tool you are considering.


Clause, obligation, term, deliverable, etc. identification and extraction
The foundation for contract, not contract spend, analytics is the ability to semantically analyze, parse, and extract key pieces of data and metadata on a contract on which to do contract, and contract pool, analysis. An organization wants to know more than just how much contracts contribute to spend under management, but how they contribute to risk mitigation (by ensuring the supplier is responsible to adhering to key governmental requirements), policy compliance (by ensuring there are clauses for mandated diversity programs or industry certifications), insurance, privacy, and other business factors in addition to providing the contracted product (using only approved parts and/or raw materials) or service (using only certified personnel).

While an advanced Negotiation offering will include some of this semantic capability, it may not support anything beyond basic clause identification and not support the necessary meta-data extraction and enrichment necessary for the analytics the organization wants to perform. Significant up-front research and live confirmation of capability (against organizational paper, not demo documents in a vendor system) may be required to verify this.

Search by clause type, obligation type, payment terms, deliverables, etc.
In addition to being able to parse a contract for key meta-data necessary for contract (pool) analysis, the platform must also support extensive search and filter capability on this meta-data. Knowing that 20% of your contracts do not address privacy in a country where a new privacy regulation has just been approved is good, but being able to quickly identify all of the active contracts is better. When an organization needs to assess readiness for a regulation or a risk or revisit their payment policies, they need to be able to quickly figure out what the precise impacts will be, and this will require advanced contract search and filter capability.

Analytics on document/clause/obligation/payment term/deliverable types
As indicated above, its more than just analytics on spend, but analytics on how many different contract types are used in an organization, how common/prevalent a clause is or isn’t, how often a variation is used, the average number of obligations, the OTD (on-time delivery) of those obligations, standard and variant payment terms, the direct and indirect cost of those payment terms and potential cost avoidance from changes to those terms, typical deliverable categories, and how these metrics change over time from one-period to the next. Also, average contract lifespan, renewal rates, decreases in evergreen renewals over time (as these are typically bad — out of sight, out of mind, out of control), and shifts in contracted supply base, geographies, etc. are as important as the spend the contracts control.

Process / state analytics
An organization also needs to understand its overall process and its state of affairs relative to contracts at any time. It’s not just how many contracts are active, but how many are now expired and how many are in process for signing/renewal. What’s the average time from award identification to signing, for implementation, and for conclusion. And how does it vary by category, geography, and supplier and how does that change over time?

It must also allow for the construction of custom summaries (views, widgets, etc.) of any and all analysis each role and stakeholder wants to see when they sign into the system, and must support full drill-down and filter to individual contracts, clauses, and terms as required.

equal support for buy-side and sell-side
Why should you have one system for analyzing buy-side contracts and another for sell side? It’s just as critical to understand revenue, margin, profit, risk, obligation, etc. on the sell-side contracts as well!


Contract Component based spend / supply / supplier analytics
A great contract analytics solution will not only support best-in-class spend analytics capability, but also allow all of the contract meta data to be defined as cube dimensions and used in formulas, filters, and metrics and allow spend to be sliced and diced by contract dimensions — to find out how much spend is covered by an appropriate risk mitigation clause, and how much is not; how much spend is adequately insured and how much is not; how much is tied to performance and may be recoverable as damages for late delivery/project completion; and so on.

Performance analytics & benchmarks
In addition to process/state analytics, the platform should also support performance analytics with respect to overall contract execution and completion timeframes; performance against obligations, payment terms, agreed upon rates and costs; expected demand and utilization; spend to budget; and so on. It should also support the creation of internal benchmarks by year, category, geography, etc. for judging contract performance (over time), and support the importation of external price / rate benchmarks and standard public contracts for relative analysis of organizational performance to the extent possible.

Duplicate / redundant clause analysis and suggested standardization
If you don’t have a contract negotiation platform and all contracts have been created free-form by the legal team, chances are you have more variations of every “standard” clause than you have standard contracts. (Yes, you read that right. Remember, you have expired contracts too that you should be maintaining for 7 to 10 years to backup any spend that you made for financial purposes, as well as maintaining for the length of time any non-compete, warranty, or liability clauses remain valid — so you can easily have more clause variations than you have active contracts when every lawyer uses their own preferred wording of a clause).

Contract risk analysis based on key contract factors
We know that there are separate solutions for “risk” in our space, but most of those solutions are focussed on supplier/supply-chain risk and compute that risk based upon external factors. However, every contract you sign carries risks — risks defined by whatever the contract didn’t cover (and explicitly transfer liability to the supplier for if they violated a regulation or law) and what it does. Your contracts not only explicitly define the products and services you are buying, and the regulations you are subjected to, but your sell-side contracts also define the associated liabilities you are assuming! And a good CLM should support all of your contracts, not just buy-side, even though chances are the sell-side will be initiated by the supplier (and negotiated in their system) and all your system will store is the final contract (which you also want to be able to analyze as well).

Next up: Governance!

Source-to-Pay+ is Extensive (P22) … Time for Contract “Management”, but it’s a NAG. Let’s start with Negotiation!

In our last post, Part 21, we noted that after Supplier Management came Contract Management because the only way to lock in the opportunity was to get a contract signed on the bottom line. However, like Supplier Management, Contract Management isn’t consistent across vendors because each has a different idea on what Contract Management actually is … and sometimes isn’t. (And most vendors are jumping on the AI bandwagon faster than fleas on the only stray dog in town, but that’s a rant for another day, or week — there’s so much absurdity here.)

However, most of the definitions, and the implemented capabilities, tend to fall into three categories: Negotiation, Analytics, and Governance. So these are the three categories we will tackle, and breakdown at a high level one-by-one, starting with Negotiation.

Negotiation platforms revolve around authoring, negotiation, and signing — and seem to think the need is met when the ink is dry (which it’s not, but we’ll discuss that in our next two instalments). Within this category, they tend to focus strongly on either template libraries, clause libraries, or AI authoring support; collaboration features to allow for team-based creation and multi-party redlining; and/or change management and/or e-signature support.

Note that key capabilities of templating, collaboration, change management, and e-signature are (also) needed for full negotiation support, and the value only shines through when certain capabilities are well thought out, deep, and complete. But not all capabilities are necessary to meet the baseline, so we will separate out our discussion of capabilities into basic and advanced.


A decent Contract Negotiation Management system needs to support contract templates that can be indexed, copied, loaded, and used as the initial draft of a contract once the parameterized fields are filled in, either by automatic pull from a connected e-Sourcing / e-RFX system with the data, or through a wizard that allows a user to quickly complete a draft from the template for the supplier through the definition of a small number of fields and the inclusion of attachments as necessary.

These templates can be static, or automatically assembled from clauses in a library using manual selection based on clause requirements, assembled using hybrid AI that uses a set of clause specifications and meta-data to find the right clauses in the library, or fully drafted using AI and only the demand forecast, final bids and the winning supplier as inputs.

Clause Based Contract Construction / Modification
In addition to supporting templates, the contract negotiation tool should also support clause libraries, preferably with multiple clause versions when the organization needs to work with suppliers in multiple geographies where different regulatory requirements need to be adhered to, and indexes by geography or any other data dimension that may require standard clause variants (such as industry, product/service category, etc.)

Change Tracking
While collaborative authoring, or even authoring support, is not required within the platform if the platform supports Word documents (and the contracting personnel work in Word), it must at least support difference and change tracking and contract redlining from one version to the next.

Negotiation Support
If the tool is a contract negotiation tool, then it must support negotiation. However, the baseline support is simply the ability to export a document to send in an e-mail to a supplier, who returns a document, that is then imported, compared to the previous version, and the changes redlined for review. A better platform allows the contract draft to be shared from within the platform and the supplier to either do their redlining with the platform, or upload their redlined contract to the platform, while maintaining a full audit trail of activity by both parties and a basic chain of document custody. More advanced platforms, will embed AI to make suggestions at each step of the contract.

e-Signature Integration
A contract is not a contract until it’s signed. A core requirement of a Negotiation platform is support for one or more recognized e-Signatures like Adobe or DocuSign. A platform can also support a vendor’s proprietary e-Signature solution if it meets the regulatory requirements and is acceptable to both parties.

equal support for buy-side and sell-side
While the chances are that your organization will be forced to interact with the buyer’s system and process when you are trying to sell, sometimes you might be able to use your system and paper, especially when it’s a new category / atypical purchase for the buyer or they don’t have a good system to manage the process.


Auto contract type / clause identification & extraction for counter-party paper
At a basic level, most contract negotiation platforms only support organizational contract creation, not counter-party paper which is critical if the supplier has the leverage and will only use its own paper, or the organization needs to fast-track a buy for a product or service it doesn’t have a template for and needs to start with counter-party paper.

A key capability here is automatic contract type identification, clause identification, term and obligation identification with associated text-based extraction and auto-indexing using advanced semantic technology.

Auto clause suggestion based on geography, supplier, product/service, regulations, etc
At a basic level, the authoring capability needs to support templates and clauses, but a good negotiation solution will use contract meta data and key indicators to recommend the required clauses, and the preferred version. This doesn’t necessarily mean, or require, anything close to AI as a rule-based expert system designed / tweaked by experts can be the perfect solution for most organizations, but could include machine learning that learns user preferences over time and tailors its suggestion to the user (and not the organizational defaults). Regardless of mechanism, an advanced negotiation platform helps the user author their contract.

Collaborative Authoring
All negotiation platforms must support authoring, but collaborative authoring is not an absolute requirement. However, it’s very useful when a team can collaboratively comment on, and even edit, a draft of a contract before it is locked down and sent to a supplier, especially if specific expertise from a large group of people is needed in various parts of the statement of work, appendices, etc. for complex direct manufacturing contracts or complex project contracts.

Dynamic Templates / Template Generation
Templates are a must, but all classical platforms had, and all basic platforms have, is static, user / vendor constructed templates. A modern ML/AI enabled platform will, based upon the responses to a few questions, category metadata, and chosen supplier, automatically generate a template that takes into account this information, the geography, the industry regulations, and other known factors and automatically generate a starting template using all available clause templates and variations to build a template expected to be as close as possible to what is needed to quickly draft the contract.

Word / Email Integration
The final advanced feature is integration with Microsoft Word to allow contract editing, change tracking, and redlining inside every lawyer’s favourite tool (Microsoft Word). Similarly, it should integrate with the organization’s email platform to allow contracts to be directly sent through email from within the platform, and when the supplier returns them, automatically identify and extract them back into the platform, with versioning and an audit trail generated automatically.

And the best platform should also support every buyer’s favourite tool — Microsoft Excel — for the creation of the pricing schedules, associated timelines, and charts.

This is not all of the features that a Negotiation platform could possess, and not even all of the features that a modern Negotiation platform should possess, but the baseline of what it must posses to support baseline functionality and more advanced functionality for efficiency and effectiveness.

Next Up: Contract Analytics.

Carbon Calculation is Great, But What You’re Really Concerned About is YOUR e-Liability

A few weeks ago, we ranted that Carbon Tracking is Important — But a Calculator or a Credit is Not a Solution! The reasons that credits were not a solution were that most “credits” were iffy at best, and downright fraudulent at the worst. The only solutions to carbon are actual reduction or proven capture. But that’s a diatribe for another rant. A calculator is not a solution either. It’s important to understand YOUR carbon footprint, but simply understanding your footprint is not addressing your footprint. Plus, it’s not just your inbound footprint you need to worry about, it’s your outbound footprint as well. You are NOT responsible for any carbon in your organization associated with products or services that are being sold to another business. You are only responsible for the carbon footprint of products are services that are being sold to a consumer or that you incur in running your operations.

In other words, what you need to be tracking and addressing is your e-Liability, which was well defined in a recent Harvard Business Review article on accounting for climate change. And this is not scope 3 carbon tracking or ESG reporting under the GHG protocol which contains flaws that result in the same emissions reported multiple times throughout the chain by different companies and other emissions being completely ignored. All emissions need to be captured ONCE and allocated as appropriate between the different entities in the supply chain, depending on which business is the last business to acquire the products or services that the emissions are directly correlated with.

Note the concept of direct correlation. All of the GHG produced mining a rare earth mineral is direct GHG associated with that rare earth mineral, and is passed up the supply chain to the buyer who buys that ore to process it, whereas all of the GHG produced by the CEO flying around on his private jet just because he can is indirect GHG that is the liability of the corporation that needs to be accounted for, and offset in someway, but that cannot be passed on to an organization that buys its ore (as it was not GHG absolutely necessary to extract the ore).

The best part of the HBR e-Liability recommendation by Kaplan and Ramanna is that it is based on financial accounting principles which track liability inflows and outflows the same way an accountant or economist would track inflows and outflows. It’s mathematically sound, makes perfect sense, doesn’t double count, and properly used, won’t miss anything either. If you want calculator, get a proper e-Liability calculator.

But remember that understanding your e-Liability is only your first step. The next step is to find ways to actually reduce your GHG footprint by reduction of unnecessary activities, production process improvement (including energy and water efficiency), and product design improvements. (Not BS credits.)

Reporting is Not Analysis — And Neither Are Spreadsheets, Databases, OLAP Solutions, or “Business Intelligence” Solutions

… and one of the best explanations the doctor has ever read on this topic (which he has been writing about for over two decades) was just published over on the Spendata blog on Closing the Analysis Gap. Written by the original old grey beard himself (who arguably built what was the first stand alone spend analysis application back in 2000 and then redefined what spend analysis was not once, but twice, in two subsequent start-ups that built two, entirely new, analytics applications that took a completely different, more in-depth approach), it’s one of the first articles to explain why every current general purpose solution that you’re currently using to try and do analysis actually doesn’t do true analysis and why you need a purpose built analysis solution if you really want to find results, and in our world, do some Spend Rappin’.

We’re not going to repeat the linked article in its entirety, so we’ll pause for you to go read it …


… we said, go to the linked article and read it … we’ll wait …


READ IT! Then come back. Here’s the the linked article again …


Thank you for reading it. Now we’ll continue.

As summarized by the article, we have the following issues:

Tool Issue Resolution Loss of Function
Spreadsheet Data limit; lack of controls/auditability Database No dependency maintenance; no hope of building responsive models
Database performance on transactional data (even with expert optimization) OLAP Database Data changes are offline only & tedious, what-if analysis is non-viable
OLAP Database Interfaces, like SQL, are inadequate BI Application Schema freezes to support existing dashboards; database read only
BI Application Read only data and limited interface functionality Spreadsheets Loss of friendly user interfaces and data controls/auditability

In other words, the cycle of development from stone-age spreadsheets to modern BI tools, which was supposed to take us from simple calculation capability to true mathematical analysis in the space age using the full breadth of mathematical techniques at our disposal (both built-in and through linkages to external libraries), has instead taken us back to the beginning to begin the cycle anew, while trying to devour itself like an Ouroboros.

Source: Wikipedia


Why did this happen? The usual reasons. Partly because some of the developers couldn’t see a resolution to the issues when they were first developing these solutions, or at least a resolution that could be implemented in a reasonable timeframe, partly (and sometimes mostly) because vendors were trying to rush a solution to market (to take your money), and partly (and sometimes largely) because the marketers keep hammering the message that what they have is the only solution you need until all the analysts, authors, and columnists repeat the same message to the point they believe it. (Even though the users keep pounding their heads against the keyboard when given a complex analysis assignment they just can’t do … without handing it off to the development team to write custom code, or cutting corners, or making assumptions, or whatever.) [This could be an entire rant on its own how the rush to MVP and marketing mania sometimes causes more ruin than salvation, but considering volumes still have to be written on the dangers of dunce AI, we’ll have to let this one go.]

The good news is that we now have a solution you can use to do real analysis, and this is much more important than you think. The reality is that if you can’t get to the root cause of why a number is as it is, it’s not analysis. It’s just a report. And I don’t care if you can drill down to the raw transactions that the analysis was derived from, that’s not the root cause, that’s just supporting data.

For example, profit went down because warranty costs increased 5% is not helpful. Why did warranty costs go up? Just being able to trace down to the transactions where you see 60% of that increase is associated with products produced by Substitional Supplier is not enough (and in most modern analysis/BI tools, that’s all you can do). Why? Because that’s not analysis.

Warranty costs increasing 5% is the inevitable result of something that happened. But what happened? If all you have is payables data, you need to dive into the warranty claim records to see what happened. That means you need to pull in the claim records, and then pull out the products and original customer order numbers and look for any commonalities or trends in that data. Maybe after pulling all this data in you see, of the 20 products you are offering (where each would account for 5% of the claims if all things were equal) there are 2 products that account for 50% of the claims. Now you have a root cause of the warranty spend increase, but not yet a root cause of what happened, or how to do anything about it.

To figure that out, you need to pull in the customer order records and the original purchase order records and link the product sent to the customer with a particular purchase order. When you do this, and find out that 80% of those claims relate to products purchased on the last six monthly purchase orders, you know the products that are the problem. You also know that something happened six months or so ago that caused those products to be more defective.

Let’s say both of these products are web-enabled remote switch control boxes that your manufacturing clients use to remotely turn on-and-off various parts of their power and control systems (for lighting, security monitoring, etc.) and you also have access, in the PLM system, to the design, bill of materials (BOM), and tier 2 suppliers and know a change takes 30 to 60 days to take effect. So you query the tier 1 BOM from 6, 7, 8, and 9 months ago and discover that 8 months ago the tier 2 supplier for the logic board changed (and nothing else) for both of these units. Now you are close to the root cause and know it is associated with the switch in component and/or supplier.

At this point you’re not sure if the logic board is defective, the tier 1 supplier is not integrating it properly, or the specs aren’t up to snuff, but as you have figured out this was the only change, you know you are close to the root cause. Now you can dive in deep to figure out the exact issue, and work with the engineering team to see if it can be addressed.

You continue with your analysis of all available data across the systems, and after diving in, you see that, despite the contract requiring that any changes be signed off by the local engineering team only after they do their own independent analysis to verify the product meets the specs and all quality requirements, you see that the engineering, who signed off on the specs, did not sign off on the quality tests which were not submitted. You can then place a hold on all future orders for the product, get on the phone with the tier 1 supplier and insist they expedite 10 units of the logic board air freight for quality testing, and get on the phone with engineering to make sure they independently test the logic boards as soon as they arrive.

Then, when the product, which is designed for 12V power inputs, arrives and the engineers do their stress tests and discover that the logic board, which was spec’ed to be able to handle voltage spikes to 15V (because some clients power backup systems off of battery backups that run off of chained automotive batteries) actually burns out at 14V, you have your root cause. You can then force the tier 1 supplier to go back to the original board from the original supplier, or find a new board from the current supplier that meets the spec … and solve the problem. [And while it’s true you can’t assume that all of the failure increases were the logic board without examining each and every unit of each and every claim, in this situation, statistically, most of the increase in failures will be due to this [as it was the only change].]

In other words, true analysis means being able to drill into raw data, bring in any and all associated data, do analysis and summaries of that data, drill in, bring in related data, and repeat until you find something you can tie to a real world event that led to something that had a material impact on the metrics that are relevant to your business. Anything less is NOT analysis.

Source-to-Pay+ is Extensive (P21) … And We Have a Long Way To Go! Next Up: Contract Management

When we started in Part 1, we noted that even though all core sourcing and procurement technologies have been available for twenty (20) years (although it is debatable just how good the initial versions of many of these applications were) … the majority of organizations still do not have what any modern analyst would consider reasonable support for the full, core, source-to-pay process.

However, now that inflation is back with a vengeance, anticipated savings is leaking faster than a bald spigot, and most organizations are in a cash crunch as a result of down sales during the pandemic (and now due to a lack of core inventory to sell), they need to update their procurement tech stack fast.

But, and this is the kicker, they can’t do it all at once. We went into a lot of the details as to why, but, basically:

  • the applications don’t work without data … and don’t work well without LOTS of data … clean, organized, enriched data … (that you don’t have now and won’t have for a while)
  • the applications don’t deliver without user training …
  • you need value out of the gate to justify the purchase … and good luck getting enough value to justify the license cost of an entire suite!
  • your users need to see results for them to adopt … and use … a solution long term

So, you need to figure out where to start. And after three posts, we figured it out — e-Procurement. We then spent a few posts discussing the need for e-Procurement, the benefits, the barriers to e-Procurement (which were not what you think), and providing you with a large list of vendors. But then we had to step back and figure out what came next again because, depending on the particular situation at hand, there were good arguments for contract management, spend analysis, strategic sourcing, and supplier management. It took quite a bit of analysis, and the answer was spend analysis because, even if all things seemed equal, or one solution looked more attractive than another, spend analysis could identify the (biggest) opportunities and the solution best suited to the most / biggest opportunities, and so spend analysis always made the most sense to adopt after e-Procurement.

After that, it was difficult. But, if all opportunities are equal, or there is no one to do the thorough spend analysis that can help differentiate the savings opportunities that can be enabled by each S2P module, there still has to be a best choice for what’s next. And that was … Supplier Management, which is what we just finished covering after a deep dive into the ten (10) facets of the CORNED QUIP mash that is Supplier Management today. The reason? Just like you needed to get your spend data captured for everything to function (which is what e-Procurement does), no matter what you’re doing, you’re interacting with suppliers, so you need to manage them effectively.

However, now it’s not so difficult as we’re down to two choices as to what comes next: Strategic Sourcing and Contract Management … and the answer is Contract Management.

Why? Don’t you have to find the products and services you need before you contract for them? Technically, yes, but the reality is that you’re already buying products and services, you already have contracts, and chances are you can’t find most of those contracts, don’t know what the obligations and deliverables are for anything that’s not available through the e-Pro catalog, and don’t even know the pricing, permitted price escalations, etc. Not to mention, most organizations without a modern CLM don’t know how many evergreen contracts they have, when they automatically renew if not terminated or renegotiated by that date, when key contracts they need are expiring, and so on. And this doesn’t even take into account the excess manual effort and time the organization is taking to re-negotiate existing or negotiate new contracts. Nor its inability to do a proper analysis of existing payment terms, key risk clauses that are required for a new regulation, and so on.

Contract Management may not identify any big opportunities, but without a good, enforceable, contract that can be easily monitored throughout its lifetime, the reality is that the identified savings will likely never materialize. Thus, Contract Management is key to have in place before you start strategically sourcing, as you want to immediately turn the bids into contract terms before the process disconnect from not having a good CLM solution causes bids to be retracted “because they were only good for 15 days” or some other excuse a supplier will come up with to not honour a bid.

However, like Supplier Management, Contract Management is also a bit of a mixed bag. To be precise, it’s a NAG, but most vendors can’t even get that right, and instead offer solutions that typically fall primarily into one of the three camps:

Contract Negotiation
which supports the authoring and negotiation part of the process
Contract Analytics
which supports the syntactic, semantic and numeric analysis of the contracts
Contract Governance
which supports the ongoing monitoring, management, termination/renewal, and long term archival of the contracts

Tomorrow we will begin our coverage by diving into Negotiation.