Daily Archives: September 22, 2008

Opportunity Analysis: The Challenge is Having Accurate and Usable Spend Information

Today’s guest post is from Bernard Gunther of Lexington Analytics.
He can be reached at bgunther <at> lexingtonanalytics <dot> com.

Sourcing Innovation‘s “Seven Grand Challenges for Supply & Spend Management“, lists the seventh challenge as “Opportunity Analysis”. As a practitioner, I can report that bad procurement data is the biggest obstacle to successful opportunity analysis. By “bad” I mean procurement data that exists when the items are purchased / invoiced is not captured and made available for future analysis. The ongoing data analysis is rarely designed into the procurement process making the analysis hard to do and therefore rarely done.

I find it surprising that half of the large companies I deal with don’t have a formal process for analyzing their AP data. Though they may dump transactions from their AP system into a spreadsheet or a data warehouse, the data is raw and unprocessed and not consistently analyzed or well understood. This is not proper spend analysis, it is flying blind. If the quality of procurement information is so lacking for AP data — the most basic spend data — imagine how bad it is for invoice level data where pricing accuracy can be determined

Accurate and usable procurement information requires source transaction data, ways to enhance that data, and processes to get value from the enhanced source data. The data should be collected and analyzed as part of the regular purchasing process. Data analysis should be designed into the process flows. I will illustrate some of what’s involved to answer the simple question, “Did I pay the right price for an item?”

At a high level, the source data includes:

  1. “Transaction level” information on each purchase that includes: what is purchased, the unit pricing, the amount bought, who bought it, and data to link each transaction to the order, the payment and the contract. The specific data available will vary depending on the commodity. Airline information is different than computers, which is also different than facilities management.
  2. Contract information structured so that each item on every invoice can be priced and stored in a way that links them to transactions.
  3. Payment information which identifies the vendor being paid, who bought the item, which transaction detail links to the payment.

Data Enhancement: Making the raw data meaningful.

  1. Commodity assignment. For an item level cube, the commodity assignment will be more detailed than an AP cube and may be based on the description, the part number, or other attributes of the item.
  2. Pricing context. Each item purchased should link to the contract price, historical pricing, benchmark pricing (internal and external), and other information that puts the unit price paid into context.
  3. Cross item information. Some of the pricing comparisons need to be done across multiple items rather than against a single item. An analysis of the mix of team members on a consulting engagement or a legal matter would be an example.

Data Processing: Converting the meaningful data into actions that save money.

  1. Every month or quarter, the data needs to be collected, enhanced, and analyzed. The analysis should be able to answer such as:
    • Did we pay the contract price?
    • How much of the spending was off-contract?
    • How did the demand shift?
    • How much of the spending was on items that were not intended to be purchased?
    • Which organizations are responsible?
    • How much extra spending did this cause?

    Each company should be able to answer these basic questions in hours, not days or weeks. The data should be in-house and it should not require work from the vendor beyond originally providing the data as part of the invoicing process.

  2. Periodically, the team needs to answer questions like:
    • For a recent price change, what happened to the spending? If we applied the old pricing to the new spending pattern, how much would we have spent? Is this what was expected?
    • Is the mix of items we buy “optimal”? How much could we save by optimizing our demand?
    • How has the market price changed relative to our pricing? Is there enough shift that we should re-bid our spending?
  3. Use the data to generate savings, for example:
    • Request refunds for overcharges
    • Add more items to the contractual pricing terms so we can monitor the pricing moving forward
    • Shift the demand to generate savings
    • Negotiate with the vendor for lower prices

    And, on and on for different ways to leverage the information

This all sounds relatively easy. But it’s not happening today. Let me illustrate from a client example of office supplies. I don’t mean to pick on office supplies vendors, but this is a category with part numbers and contracts so it provides a good starting point for this type of analysis.

The client bought office supplies online through a punch out mechanism from their PO system. The vendor processes the orders, ships the items, and presents invoices for payment. The invoices are approved in the PO system and the vendor is paid per the contract. The contract was written 2 years ago and allowed for fixed (discounted) prices for the top 500 items being bought. When the contract was signed, 250 items were on the list. The new contract offered price reductions on certain items, which the sourcing team projected, would save 12%. Since the contract signing, most prices have been stable, with some exceptions for paper.

As the program was implemented by the client, there were a number of problems with the data:

  • For 20% of the items purchased, the item numbers recorded in the PO system did not match the item numbers in the contract. This was largely a problem of how the PO system recorded the data
  • The client could not state what percentage of the spending was for items with contract prices and what percentage was off-contract. The client needed to ask the vendor for this analysis.
  • The client had agreed to price changes, but did not track those changes and could not calculate the impact of those price changes on overall spending. Again, they had to rely on the vendor to track the pricing and do the analysis.
  • The buyers had shifted their demand, so that of the 250 items in the contract, over 75 were not being bought anymore and of the top 250 items being bought, there was no contractual price for almost 100 of the items. The vendor was waiting for authorization to add 50 new items onto the contract list (with better discounts).

This was all fixable. Fixing it generated incremental savings of 5% and improved the relationship between the client and the supplier. But it didn’t happen until we, the consultants, highlighted the problem and the opportunity.

Generally, we find that procurement data is a mess. And it shouldn’t be. But, this is why it’s a challenge.

Thanks Bernard!