Category Archives: Best Practices

Sourcing the Day After Tomorrow Part XII

In Part I we recapped Sourcing today, in Part II we did a deep dive into the key requirements of the review step as it is today, and then in Part III we did a deeper dive where we explained that while some steps were critical for a sourcing professional to undertake, others, while necessary, were a complete waste of skilled talent time as the majority of the tasks could be automated. Then in Part IV we began our deep dive into the needs assessment phase which we completed in Part V. This was followed by a deep dive into strategy selection in Parts VI and Part VII, the communication step in Parts VIII and IX, and the the analysis step in Parts X and XI. And upon review of these steps, we’re still at the point where some tasks have to be done by humans whereas others can be mostly automated. We’re becoming fairly confident that this is true across the entire sourcing cycle, but we can’t be completely sure until we complete our analysis, so that is what we are going to do this week.

In the next step, the negotiations step, we have the following primary sub-steps:

  • Format Selection (online, offline, hybrid)
  • Fact Prep
  • BATNA fallback
  • Audit Trails

In the format selection step, the senior buy decides the primary format in which the negotiations will take place. If it’s a low dollar or non-strategic buy, the buyer might conclude that the negotiations can take place entirely on line through offers and counter-offers, through a system that can ensure offers and counter-offers cannot be altered If it’s a high dollar strategic buy, the buyer might decide that all negotiations and communications of any kind must take place in person behind sealed doors. And if’s somewhat important but only mid-price, the buyer might decide that initial communications, offers, and counter-offers can take place on-line through a secure platform with unalterable audit trails and when both parties at least have a solid understanding of the other side, final negotiations will take place in person.

In the fact preparation phase, the buyer undergoes the collection of all information that could be relevant in the negotiation. Market costs, should cost models, supply and demand trends, customer needs, supply alternatives, and so on. This will consist of the relevant information collected in previous steps from the market, the supplier, and the organization’s systems. It will be synthesized into a cohesive set of documents, tables, and facts that can be used in negotiations to the benefit of the buyer so that, at the ver least, the buyer enters negotiations with knowledge.

In the BATNA phase, which stands for Best Alternative To Negotiated Outcome, the buyer determines what the backup plan is if the negotiation does not conclude successfully and lead to an agreement which is captured in a contract (which, even though listed as a separate phase, is a simultaneous phase that occurs during the lsat step of negotiations). Will the buyer take up negotiations with another supplier, temporarily buy on the spot market, or try to extend the current contract? If it’s a spot buy, will it be through a one-time auction or through a catalog from a non-preferred / non-contract vendor? If negotiations fail, especially if time-lines are tight, the buyer needs to be able to put a back-up plan into place quickly. Plus, if the buyer has a back-up, that limits the pressure that the supplier can put on the buyer.

Finally, the audit trail is not so much as a phase as the collection of the output of each step of the back and forth negotiation (which could take anywhere from 1 to n steps, for n quite large) that occurs between both parties. This step tracks who made an offer, who made a counter offer, who commented on the offer or counter-offer, what information was revealed by a party (or counter party), and does so in a secure, unalterable, queryable fashion that can be reported on at any time.

Except for the auditing, which you expect systems can automate, this sounds largely human driven as we choose the negotiation format, we need to get our facts in order, and we need to determine the best alternative to negotiation agreement, but, as we’ve discussed during previous steps, sometimes what sounds human driven isn’t. Sometimes it’s just human verification. But this is a subject we will explore in Part XIII!

Dear Big Co. Here’s Why Your Contracts Suck …

… and why no one wants to sign them, yet alone even read them!

And since all contracts should be written in plain English (or, if between two parties whose native language is Elbonian, in plain Elbonian, for e.g.), at a senior high school reading comprehension level, we are going to write this post in plain English too.

They are too long. No one wants to read 100 pages of your lawyer’s hyperbole rhetoric that is, in common terms, the literary equivalent of a steaming pile of cow dung.

You read that right. No one wants to read 100 pages of your lawyer’s hyperbole rhetoric that is, in common terms, the literary equivalent of a steaming pile of cow dung.

Furthermore, at least 90 pages of this is guaranteed to be completely unnecessary (and you should feel ashamed at the money you wasted paying your high powered corporate lawyer to write it in the first place).

Let’s go back to the purpose of a contract.

To clearly specify

  • the obligations between two parties,
  • the benefits to both parties from meeting their respective obligations, and
  • the recourse available to one party if the party defaults on the obligations of the contract.

In plain English, even English written by the bard himself, how many pages does that take? Even in the most sophisticated of transactions with a list of obligations by both parties, probably not more than a few pages. (Now, if you are contracting for the construction of an office building, you might need hundreds of pages of addendums on architectural, structural, municipal, etc. requirements, but that’s not the heart of the contract. This can be clearly captured in a sentence that states party X agrees to build the structure required by party Y, as clearly detailed in appendices A through T that detail obligations 1 through 20 respectively, do so for a fixed fee of Y M, and delivery by due date, with penalties accruing at the rate of Z00 K per month. Simple, eh?)

After you’ve specified the mutual obligations, there are only three other requirements for a contract:

  1. Requirements of your Insurance Company
    If your insurance requires limitations of liability, certifications, etc. to explicitly be included for it to remain in effect, you include these requirements, and only these requirements, and only to the extent required.
  2. Requirements of the jurisdiction in which you are operating your business
    If you are doing business in the US, and you are buying technology that could possibly fall under ITAR (for example) if certain requirements are not adhered to, then it must be contractually clear that the products will be designed to adhere to those requirements. (Encryption will not exceed a certain level, etc.) Furthermore, if there are regulations against human trafficking in the supply chain, taking measures to insure denied parties do not receive financial payments, etc. that must be adhered to, then these are included as well.
  3. Requirements of any jurisdictions in which you are subject to as part of the transaction
    If the jurisdiction of the other party can imposed requirements on you, or if you plan to sell the products or services bought in a third jurisdiction, you need to include any requirements imposed by those jurisdictions.

However, this does not mean you include pages and pages of detailed requirements and regulations, that are well defined in the appropriate laws and statutes and regulations you are bound to, merely that you reference those regulations and require the other party to adhere to them. This usually requires only a few sentences per regulation, max. Not paragraphs and definitely NOT pages.

That’s it. Nothing else. And I cannot emphasize enough that you don’t include something else just because your lawyer decides there is a minute 1 in 1,000,000 risk that something could go wrong and someone with a better funded legal team could possibly find an innovative way to wiggle out of a contract that didn’t cover the obscure case of a worker tripping and skimming his knee because he stepped on a snail on the way to your worksite. Over funded legal teams under the control of people with more money than brains can always come up with harebrained arguments and ridiculous legal challenges — but how often does it really happen? Especially between two parties who were open and honest in negotiations and go into the contract fully intending to fulfill it? And is it really worth spending tens of thousands (or more) of legal time on an average contract which is usually a small fraction of organizational spend? (If an organization has 10,000 contracts and it’s revenue is less than 10 Billion, the average contract value would appear to be one million, but give that there will be a few large contracts with key suppliers that leverage volume, you’ll have a few dozen contracts in the tens or hundreds of millions and an “average” contract in the tens or hundreds of thousands.)

Remember, your lawyer’s job isn’t to tell you what to do. Your lawyer’s job is to listen to what you want to do, advise you of the risks, and then do whatever you tell him to do, which definitely includes writing short, easy to understand, contracts that people will actually sign. At the end of the day, you need to do your business. Contracts should enable that, not get in the way.

Sourcing the Day After Tomorrow Part XI

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, and the communication phase. Now we are in the analysis step. At first glance, it looks like this is more strategic and human-driven than prime for tactical automation, but we have been fooled before (and won’t get fooled again).

We are discussing the analysis step, which has the following sub-steps that have to be completed every time (and not just sometimes):

  • Market Pricing Data
  • Historical and Projected Spend
  • Cross-Category Materials Spend
  • TCO / TLC (Total Cost of Ownership, Total Lifecycle Costs)

Let’s start with market pricing data. While humans need to review and verify the data for accuracy and completeness, they don’t need to manually collect it. Consumer pricing can easily be collected from crawlers and punch-outs, many BPOs/GPOs have APIs and data feeds or at least easily parsed CSV files, and pricing from government contracts can usually be downloaded from government sites and automatically parsed. As a result, most of the market pricing data collection effort is easily automated.

When it comes to historical and projected spend, this can be easily be pulled from a good spend analysis system once all the data has been cleansed, categorized and enriched. A few rules get the relevant spend, the related spend, and the application of a few algorithms can easily automate the calculation of projected spend under standard assumptions.

When it comes to cross-category materials spend, if the organization’s ERP contains bill of materials (and approximate usage of a raw material in the production of a product or service), and if the spend analysis system is configured to support this level of detail, then the cross-category materials spend can be pulled out of the spend analysis system in an automated fashion and matched to the current and projected spend. All a human needs to do is review and verify the data.

Finally, in the TCO/TLC phase, most of the relevant costs factors can be automatically identified by a modern spend analysis system that can match invoices to goods and services and identify the associated costs as well as through a contract analytics systems that can analyze past contracts and pull out the “hidden” costs that the supplier passes on to the buyer (in margins or lump-sum fees). Plus, semantic analysis of product descriptions can allow other direct and indirect costs to be identified, and all of these factors can be compiled to create a should-cost model, with certain costs (such as transportation, import/export fees, taxes, etc.) automatically pulled from market data and other costs estimated using prior costs and estimated costs on related categories. A human has to do the final analysis and sanity check, but so much of the tactical drudge work of analysis can be automated these days that it’s almost cognitive.

In other words, the more we explore the sourcing process, the more we find out how truly tactical the majority of it is. But we’re not done, so in our next four parts we will explore the last two phases of negotiation and contract.

Sourcing the Day After Tomorrow Part X

In Part I we recapped Sourcing today, in Part II we did a deep dive into the key requirements of the review step as it is today, and then in Part III we did a deeper dive where we explained that while some steps were critical for a sourcing professional to undertake, others, while necessary, were a complete waste of skilled talent time as the majority of the tasks could be automated. Then in Part IV we began our deep dive into the needs assessment phase which we completed in Part V. This was followed by a deep dive into strategy selection in Parts VI and Part VII and the communication step in Parts VIII and IX. And upon review of these steps, we’re still at the point where some tasks have to be done by humans whereas others can be mostly automated. We’re starting to suspect this is true across the entire sourcing cycle, but we can’t be sure until we complete our analysis, can we?

In the next step, the analysis step, we have the following key sub-steps that have to be completed every time (not just sometimes):

  • Market Pricing Data
  • Historical and Projected Spend
  • Cross-Category Materials Spend
  • TCO / TLC (Total Cost of Ownership, Total Lifecycle Costs)

In the market pricing step, you collect as much information as you can about pricing for the goods or services you are looking to acquire to be as informed before negotiations as you can be. This could require collecting consumer pricing from retailers, pricing available from GPOs/BPOs, pricing from government contracts (that are public data), import / export manifests (to determine volumes and supply/market dynamics), and pricing from similar product/services on past contracts. It could also involve collecting competitive intelligence through analyst reports, buying collectives, and other avenues.

In the historical and projected spend phase, the organization does deep analysis of historical spend and volumes across the product and services lines, similar product and services lines, and market dynamics. It then pieces all of this together to form projected trends that look at current trends modified with projected demand shifts within company product and services lines and expected uptakes or product line abandonments based on current market dynamics. It collects as many pieces of data that are readily available to try and determine if market shifts are seasonal, responsive to price changes, reactive to new product introductions, or undetermined factors.

In the cross-category “materials” spend phase, the organization makes an effort to identify the the primary components of the spend and how they should influence the spend dynamics of the product or service being acquired. For example, if it’s a metal product where steel is a primary component, they will attempt to identify how the pricing is shifting in other categories where steel is a primary component and compare that to market price shifts. If it’s a service, they will look if the primary costs are related just to talent, to organizational support, or even expenses (such as excessive travel requirements) and compare that to market costs across different divisions of the company. (E.g. extra
IT support is IT support whether contracted by Procurement or IT)

Finally, in the TCO phase, the organization will work hard to identify all the other direct and consequential indirect costs associated with the acquisition. Taxes (and whether or not they are reclaimable and the costs of reclamation if they are), import/export duties, intermittent storage fees, transportation fees, typical loss fees (due to spoilage, waste from mandatory tests, etc.), etc. will be identified and factored in as direct costs. In addition, potential indirect costs such as additional testing, expected loss during local transport, alteration costs for implementation, loss of co-marketing support, etc. will be factored in.

This sounds largely human driven, but, as we’ve discussed during previous steps, sometimes what sounds human driven isn’t. But this is a subject we will explore in Part XI!

Sourcing the Day After Tomorrow Part IX

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, and the strategy selection phase and are in the communication (identification) step. At first glance, it looks like this is an entirely strategic human-driven step with little option for tactical automation, but is this the case?

As per our last post, the communication step of the typical sourcing process, we have the following key sub-steps that typically have to be completed:

  • Standard Protocols
  • Supplier e-Communication Capability
  • Level of Detail Required
  • Response timeframes

Let’s start with the standard protocols. At some point a human has to establish the standard (organizational) protocols, but how much do they change from event to event for a product or service or category or across products and services within a category (or across similar categories)? Not much. There’s no reason that once an event is created a system can’t find the closest event or category that’s ever been done, extract the communications protocol that was used, present it to the buyer, allow the buyer to accept all, or part, and if only parts are accepted, find and recommend the next best parts, and then allow the user to edit the closest parts to make it all fit. A great platform will make it extremely quick and easy to create a standard communication protocol and framework, and even quicker to set up automation using templates, timers, alerts, and other capabilities of modern Source-to-Pay platforms.

When it comes to supplier e-Communication capability, once the buyer has an e-mail, the platform can send out the surveys to those suppliers that are new and, more importantly, suck in profiles from other events from suppliers that have recently responded. And if the response is over a year old, automatically resend it to the supplier for verification. There’s no reason a human has to do very much at all. This is a step primed for platform automation.

The level of detail required step, like the standard protocol step, is another step where a human has to make an initial decision at the organization, category, or product level, but once that decision is made, and captured, there’s no reason a human ever has to make that decision again (unless an event happens that indicates the decision no longer fits). The system should be able to extract the right guidelines and templates to help the humans through the proper supplier communication protocols and responses and allow the buyers to focus on the strategy, not the minutia.

Finally, with respect to response timeframes, the system can query organizational guidelines, decisions from previous events, and typical average response times and present the buyer with suggested response timeframes. It also enables the buyer to alter any suggestions quickly and easily so that the buyer can produce all the internal guidelines and disseminate them in a quick and easy fashion and spend more time on the preceding strategy step and the following analysis step.

In other words, we again see that, without proper system support, a buyer will waste much of their time on tactical processes, non-strategic data collection, and making the same tactical decisions over and over again and Sourcing really has to change.