In this series we are doing a deep dive into the sourcing process today, and, in particular discussing what is involved, what is typically done (manually), and whether or not it should be that way. We have already completed our initial discussion of the initial project request review phase, the follow up needs assessment, the strategy selection phase, the communication phase, the analysis phase, and the negotiations phase. Now we are in the final contracting phase. At first glance, it looks like this is the second most strategic and human-driven phase there is, second only to negotiation, as it is humans (and lawyers in particular) who typically define standard terms and conditions, humans who identify risk and mitigation strategies, humans who define obligations, and humans who analyze the contract for compliance to goals. But is this the case?
So in this final step, the contract step, we have these final sub-steps:
- Standard Terms and Conditions
- Modification & Risk Mitigation to Supplier & Country
- Key Metadata definition and obligation specification
- Contract Analytics
If all of the standard terms and conditions are in existing contracts and the contract clause / template repository, there’s no reason that a system cannot automatically scan the contracts and repositories, identify the standard organizational terms in every contract, identify the standard terms for the category, and identify any terms, often not included, that would be relevant to the category. Probabilities can be applied and contract terms organized by weight. The buyer can then just bulk select or bulk reject the relevant clauses.
In the modification and risk mitigation step, a contract analytics engine can be applied to determine how well a particular clause addresses a certain risk of relevance to the organization based on context models and differentials. It can then compare that clause to the clauses that best address the risk and identify the necessary modifications, and do so specifically from a supplier or geographic context.
In the key metadata definition and obligation specification step, the goal is to identify the right metadata that needs to be tracked against the contract. This will be dependent on the terms and conditions, the goals, the obligations, and other key information that will be specific to the contract. However, contract analytics can identify, or at least suggest, much of this as well automatically based upon similar contracts, similar terms, similar goals, and similar obligations. This can greatly reduce the effort required by a buyer.
In the final step, the contract analytics step, the identification of risks, variances from a norm, and non-standard clauses can often be better identified by a contracts analytics engine that can cross-compare potentially risky clauses and variant clauses across hundreds, if not thousands, of contracts and identify deviations from the norm. A user just has to decide whether the variance is enough to be of interest to them, and properly setting a threshold can eliminate the majority of those variances that are not.
In other words, at the end of the day, contract analytics identifies the majority of standard terms and conditions that are of interest, the majority of standard clauses that will need modifications to address supplier and country risk, the relevant metadata and obligations associated with the contract, and any clauses that can be considered variant enough to warrant special consideration.
The majority of the work can be automated with a good contract analytics engine — the role of the buyer is to apply their intelligence to determine how accurate and effective it is. As the buyer trains the engine, it will become more and more accurate over time and the strategic work will be reduced to hours, sometimes minutes for simple contracts, compared to days or weeks.
In other words, the more we explore the sourcing process, the more we find out how truly tactical, or at least automatable, the majority of it is.