Monthly Archives: October 2025

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!

EOQ Part II: The Quantity You Need the Computer To Calculate, Though You Can’t Depend On It Until You’ve Calculated and Verified it First!

In our last article, I noted how I was reminded that most of today’s so called Supply Chain and Procurement experts could not pass a basic EOQ exam question, and that the reason for that was lack of real supply chain (cost) knowledge, math, and the intricacies of inventory carrying cost that are swept under the rug in the classic EOQ formula, which, sometimes, is not at all accurate.

I say reminded because this was something I explored in depth about 17 years ago when Charles Dominick, the founder of Next Level Purchasing (now a part of Certitrek) and co-author of The Procurement Game Plan approached me about the severe inadequacy of the EOQ formula (and how it often leads to Procurement Managers ordering too little, or too much, and never truly understanding the true cost of inventory or the levers available) and asked if I could help him come up with a better equation that he could teach to his students in his (advanced) Procurement courses.

The answer was yes, we did, but then he decided that he didn’t want to use it at the time because getting it close to right was a bit more involved than he thought and, well, math. It was a bit beyond what an average student could be expected to do in a spreadsheet. That’s because an extended EOQ equation has to take into account, at a minimum:

  • actual warehouse space utilization of an item (screws don’t take up much space, but control system boxes do), and
  • the cost of capital

Moreover, while I fully agree with Mr. Mr. Koray Köse that you shouldn’t re-invent the wheel, there’s nothing wrong with strengthening the rubber, improving the tread, and reinforcing the rims — which is where we started out. We started with the classic equation and just extended it to take into account the above.

We started by determining the actual inventory cost of a single unit of an item and the cost of capital tied up in that unit since the most inaccurate part of the classic equation is the average across-the-board CCP. This gave us this equation:

  • EOQV1 = √ ( (2 * ACPO * AUU) / ((AWC * UV / UWV) + (UC*WACC)) )

where

  • ACPO = Acquisition Cost Per Order
  • AUU = Annual Usage in Units
  • UC = Unit Cost

as before, and

  • AWC = Annual Warehouse Cost (which is the FULL operating cost, including staff)
  • UV = Unit Volume
  • UWV = Usable Warehouse Volume (i.e. just because your warehouse is 100*100*10 or 100,000 cubic ft, doesn’t mean you can use it all; it will depend on your layout, since you can’t store in the aisles and the shelves themselves take up some space; in reality, less than 50% will be usable)
  • WACC = Weighted Average Cost of Capital

To gauge how good this equation is, let’s recalculate our Spacely Sprockets example.

As before, we’ll assume:

  • ACPO = 3,400
  • AUU = 5,068
  • UC = 1300, 1250, 1200, or 1175, depending on volume

And we’ll assume the following costs and dimensions (which are reasonable given the Finance CCP):

  • AWC = 4,000,000
  • UV = 1 cu ft (they are gears for industrial moon mining equipment)
  • UWV = 40,000 cu ft
  • WACC = 0.10 (10% cost of capital)This gives us:
    • EOQV1 = √ ( 34,462,400 / (100 + 0.1*UC) )

    and we calculate for each price break:

    • 1300: √ ( 34,462,400 / (100 + 130.0) ) = √ (149837) = 387
    • 1250: √ ( 34,462,400 / (100 + 125.0) ) = √ (153166) = 391
    • 1200: √ ( 34,462,400 / (100 + 120.0) ) = √ (156647) = 396
    • 1175: √ ( 34,462,400 / (100 + 117.5) ) = √ (158448) = 398

    which is a bit closer to the EOQ, but not by much, but helps us understand that when it comes to EOQ, the primary factor to consider is often going to be the cost of capital, because, whether you use all of your warehouse space or not, your warehouse costs are relatively fixed for a year, which means your inventory costs per unit are relatively fixed as well (whether it’s in for a few days or a few months), and when you’re buying, you’re ultimately trying to balance the WACC with the fixed inventory allocation (which is typically just averaged to get the total inventory cost that is used to compute the average carrying cost percentage that goes into the standard equation).

    Moreover, the cost of capital is dependent on how long the item is in inventory! This says the equation needs to be modified to take this into account:

    • EOQV2 = √ ( (2 * ACPO * AUU) / ((AWC * UV / UWV) + (UC*WACC*EDIR)) )

    where

    • EDIR = Expected Days in Inventory Ratio (the WACC is annual, if the item is only expected to be in inventory for half a year, the ration is 0.5)

    Moreover, this also allows us to build in some consideration for price breaks! Since each price break dictates a maximum number of orders per year based upon the AUU, we can simply define

    • EDIR = (MBQ)/(2*AUU)

    where

    • MBQ = minimum break quantity

    This slight revision gives us:

    • 0400@1300: √ ( 34,462,400 / (100 + (130.0 * 0.04) ) ) = √ (34,462,400 / 105.2) = √ (327589) = 572
    • 1000@1250: √ ( 34,462,400 / (100 + (125.0 * 0.10) ) ) = √ (34,462,400 / 112.5) = √ (306332) = 553
    • 2000@1200: √ ( 34,462,400 / (100 + (120.0 * 0.20) ) ) = √ (34,462,400 / 124.0) = √ (277923) = 527
    • 5000@1175: √ ( 34,462,400 / (100 + (117.5 * 0.50) ) ) = √ (34,462,400 / 158.8) = √ (217018) = 466

    Which is closer, but certainly no cigar! The fact of the matter is that the rule of thumb of (2 * ACPO * AUU) that was developed to make the formula easy to understand and calculate while still providing a curve that is relatively cost-insensitive near the optimal quantity, is not perfect. While it will often get you close, it could still be a ways off that becomes significant when costs get into the millions. If there are no price breaks that can cause significant swings, we can see it works pretty well, but when there are, it doesn’t do as well. So we need to address this too!

    Without rewriting the equation entirely, this isn’t as easy to do as our fixes so far because the equation was designed to give a good curve that balanced inventory costs with acquisition costs without requiring deep, precise modelling. Still, when we have volume breaks, we can note that our order costs will be higher at lower volumes (which means more orders) and lower at higher volumes (which means less orders) and replace that 2 with a parameter that is defined on the volume breaks.

    More specifically, we will use:

    • EOQV3 = √ ( (C * ACPO * AUU) / ((AWC * UV / UWV) + (UC*WACC*EDIR)) )

    where

    • C = 2 x AVV/XBQ
    • XBQ = maximum break quantity (= maximum order quantity for final tier)

    This final slight revision gives us:

    • 0400@1300/c=10.0: √ (172,312,400 / (100 + (130.0 * 0.04) ) ) = √ (172,312,400 / 105.2) = √ (1637950) = 1279
    • 1000@1250/c=5.00: √ ( 86,156,400 / (100 + (125.0 * 0.10) ) ) = √ ( 86,156,400 / 112.5) = √ ( 765831) = 875
    • 2000@1200/c=2.00: √ ( 34,462,400 / (100 + (120.0 * 0.20) ) ) = √ ( 34,462,400 / 124.0) = √ ( 277923) = 527
    • 5000@1175/c=2.00: √ ( 34,462,400 / (100 + (117.5 * 0.50) ) ) = √ ( 34,462,400 / 158.8) = √ ( 217018) = 466

    Which, will still not perfect, gives us an even stronger indication that the EOQ is at the first price break, because at the 0 break, we’d have to order more than we are allowed to hit our EOQ based on our high orders, but at the first price break, our EOQ is slightly less, which means we round up and use that breakpoint, which we found out in Part I is optimal.

    So, does this mean you should scrap the classic, simple formula of

    • EOQ = √ ( (2 x ACPO x AUU) / (UC x CCP) )

    and replace it with:

    • EOQV3 = √ ( (C * ACPO * AUU) / ((AWC * UV / UWV) + (UC*WACC*EDIR)) )

    The answer is no. Even though this formula works well if there are no price breaks, the point of this exercise was not to develop a better EOQ formula, but to demonstrate that classic EOQ (still used in many inventory and classic MRP/ERP systems) is broken.

    Moreover, there is no one EOQ formula because EOQ is 100% dependent on inventory levels and costs when you order, shipping times and costs when you order, and supplier and carrier breaks. It changes all the time.

    That’s why, if you want to get it right, you need a modern optimization-backed SCP system to help you dynamically calculate it in real time so you put your orders in (against your contracts) at the right time to balance cost and risk.

    What does that system look like? We addressed some of it in our prior posts on optimization here on Sourcing Innovation and will likely address it again in the future, but for now, follow @Koray Kose for insights on what a modern supply chain solution should address from a business viewpoint and @Jennifer Rouse for what it should do from a systems viewpoint.

EOQ Part I: The Quantity You Can’t Depend On The Computer to Calculate!

I was reminded of this while reading Mr. Koray Köse’s great piece on how our supply chains are literally drowning in wannabes who mistake theory for expertise where he accurately and astutely noted that most of today’s so called “experts” could not pass his Economic Order Quantity (EOQ) exam question. And I totally agree. Because

1) Math (where competency in many Western nations decreases every year and where the US is literally becoming math stupid, as reflected in the latest OECD ranking which puts it 25 out of 31 “developed” countries that were globally measured with countries like Croatia coming in ahead of it).

2) No real understanding of supply chain or total supply chain cost!

3) Even less understanding that your EOQ (Economic Order Quantity) is not your suppliers EPQ (Economic Production Quantity) and for high cost/complex products, this can sometimes (but not always) be much more important (and impactful) than the classic EOQ formula would dictate.

Mr. Köse illustrates this deftly when he shared one of the questions he uses to gauge whether or not his MBA students truly understand EOQ. The core variant of the problem he shared with us was this:

  1. The purchasing manager for Spacely Sprockets orders mechanical gears from an industrial supplies distributor, Cogswell Cogs.
  2. Spacely Sprockets uses 5,000 gears per year.
  3. Annual inventory carrying costs are 20% and order costs are 3,400 per order.
  4. The following order discount price schedule is provided by Cogswell.
    • 0,200-0,999 $1300 / unit
    • 1,000-2,999 $1250 / unit
    • 3,000-4,999 $1200 / unit
    • 5,000+      $1175 / unit
    
    
  5. Determine the optimal order quantity, total cost, and actual per unit cost (once order costs and inventory carrying costs are taken into account).

Now, if you were a prepared student, you might have memorized the classic EOQ formula:

  • EOQ = √ ( (2 x ACPO x AUU) / (UC x CCP) )

where

  • ACPO = Acquisition Cost Per Order = 3,400
  • AUU = Annual Usage in Units = 5,000
  • UC = Unit Cost
  • CCP = Carrying Cost Percentage = 0.20

and this leaves you with

  • EOQ = √ ( 34,000,000 / (0.2 * UC) )

and you can work this out at each price break:

  • 1,300: √ ( 34,000,000 / 260 ) = √ (130,769) = 362
  • 1,250: √ ( 34,000,000 / 250 ) = √ (136,000) = 369
  • 1,200: √ ( 34,000,000 / 240 ) = √ (141,666) = 376
  • 1,175: √ ( 34,000,000 / 235 ) = √ (144,680) = 380

which indicates the first price bracket is the correct one for you, and you should be making 13.8, rounded to 14, orders every 26 days (and net a total volume of 5,068 units over the year) and, on average, you will carry each unit of inventory for 13 days.

  • unit cost: 5,068 * 1,300 = 6,588,400
  • inventory carrying cost: 13/365 * 0.2 * 6,588,400 = 46,931
  • order cost: 3,400 * 14 = 47,600
  • total cost: 6,682,931
  • unit cost: 1,319

But this is NOT an EPQ for the supplier, which means that you might be paying more than you need to. To figure that out, you have to analyze the costs at each breakpoint that is reasonable for you.

These are:

  • 362, your computed EOQ, with 14 orders per year
  • 1014, the first discount tier, at 5 orders per year every 73 days, with 36.5 days of inventory on average
  • 5,068, at the third discount tier, at 1 order per year every 365 days, with 183 days of inventory on average
  • … because you can’t hit the 2nd tier more than once

First run the calculation at 5,068, because your greedy executives only understand unit discounts:

  • unit cost: 5,068 * 1,175 = 5,954,900
  • inventory carrying cost: 183/365 * 0.2 * 5,954,900 = 595,490
  • order cost: 3,400 * 1 = 3,400
  • total cost: 6,553,790
  • unit cost: 1,293

You quickly see that you clearly want the discounts even if your inventory costs shoot up because 633.5K in savings is greater than 595.5K in expected inventory carrying costs.

But you’re not done yet. Now you have to run the calculation at 1,014 units an order over 5 orders, because it’s also a valid option and captures the suppliers first EPQ point:

  • unit cost: 5,068 * 1,250 = 6,335,000
  • inventory carrying cost: 36.5/365 * 0.2 * 6,335,000 = 126,700
  • order cost: 3,400 * 5 = 17,000
  • total cost: 6,478,700
  • unit cost: 1,278

which is your actual EOQ because it not only takes advantage of the supplier’s EPQ level but does so at the breakpoint that is closest to that given by your traditional EOQ calculation!

Now we’ve now clearly demonstrated why most of today’s so called experts couldn’t calculate EOQ with a computer because it’s not always the classic EOQ formula (or whatever pseudo-random formula happens to be in the forecasting system they try to use), or the supplier’s optimal EPQ level (if that leads to a significantly high storage cost for you — JIT is a core tenet of lean for a reason, inventory is costly, and while you need a safety stock, too much not only presents too much obsolescence risk but shoots your carrying costs way up), but usually somewhere in between (where the optimal curves intersect closest to their respective minima). Good luck doing that if you can’t do math, don’t know supply chain, and think Chat-GPT holds the answer to everything.

What we didn’t demonstrate is why, in reality, you often need a computer to calculate it (and that comes down to the inventory carrying costs which are often much more involved than Finance believes) and your associated supply chain costs. The reality is that you might have to re-write your formulas, which really will require a computer to constantly calculate and recalculate your true inventory carrying costs, but the reality is that you will only be able do this AFTER you understand what the proper order volumes should be (because you need to check that you worked out the formulas and calculations right for your supply chain)! We might tackle this in another article, because the only way to get costs way down is to help Finance and Operations understand the true costs and how to tackle them (because if you’re still running on an average ICC of 20%, or even worse, 25% to 30%, someone, somewhere, is performing pretty poorly in their profession).

KPIs To Ask For By ProcureTech Module: Part III

In our last series on Why Your Tech Selection Should be KPI, and not Bell-and-Whistle, Focussed if you are not technical, we reviewed Tanya Wade’s 21 KPIs that are a great start if you’re looking to put some KPIs in place to properly program and percolate procurement. Not all of these were (the most) appropriate for all modules, but if you don’t know your tech, they were a great start.

In this mini-series, we’re partitioning the performance indicators by ProcureTech module as well as indicating a few more you should be asking for. We’ve covered the core Source-to-Contract modules, and today we are concluding with the Procure to Pay Modules of e-Procurement and Invoice to Pay (Accounts Payable).

e-Procurement

Tanya Wade’s Performance KPIs

  • Supplier Performance:Supplier Lead Time
  • Compliance & Risk:PO Compliance
  • Operational Efficiency:Procurement Cycle Time
  • Operational Efficiency:Automation Rate
  • Spend Analysis:Tail Spend

For details on these, see our prior series.

Key Module KPIs

  • Compliance & Risk:Maverick Spend Reduction – maverick spend is out of control in most organizations without good (e-)Procurement systems; it is important to know what is the average improvement from implementing the provider’s system (no matter what metrics the vendor throws at you, if this isn’t substantially increasing, the system is NOT being adopted)
  • Compliance & Risk:Preferred Supplier Spend (Improvement) – how much of the off-contract spend is with preferred suppliers, and by what percentage is preferred supplier spend expected to increase
  • Compliance & Risk:Avg Improvement/Time-to-Value in Discount/Rebate Acknowledgement – many traditional savings in office suppliers / MRO are offered in the form of rebates if a volume is hit (because the provider knows it won’t be because all organizations without good e-Procurement/Contract Management have high levels of maverick spend and they know they can often substitute SKUS due to “temporary stockout” and the buyer won’t notice and this will help ensure that the volume is not hit)
  • Operational Efficiency:Automated Inventory Re-Order % – for regular inventory/MRO restocks or predictable volumes based on the manufacturing plan, the e-Procurement system should be able to submit the POs automatically
  • Operational Efficiency:Repeat Order Cycle Time Reduction – for standard orders such as employee onboarding kits, monthly storeroom re-orders where the amounts need to be human verified/input, etc., on average, how much faster can these be placed vs. pre-module implementation
  • Operational Efficiency:Quick-RFP / RFQ % Reduction – by what percentage does the e-Procurement system, with its integrated catalog and quote management functionality, reduce the percentage of quick RFP/RFQs that the organization needs to issue for non-strategic purchases
  • Operational Efficiency:% (Increase) Spend on PO – by what percentage is on-PO spend increased

e-Procurement is all about getting Spend Under Management, ensuring contracts and included pricing are adhered to, and using preferred suppliers (and products) as much as possible (to help with standardization). This requires making it easy for requisitioners/buyers to find what they need, buyers to issue POs, and on-contract/preferred supplier spend to be easily tracked. Metrics should be in place to make sure all of this happens.

Invoice-to-Pay / Accounts Payable

Tanya Wade’s Performance KPIs

  • Operational Efficiency:Procurement Cycle Time
  • Operational Efficiency:Automation Rate

For details on these, see our prior series.

Key Module KPIs

  • Operational Efficiency:Invoice Cycle Time Reduction – by how much, on average, do clients see invoice cycle time reductions
  • Operational Efficiency:Straight Through Processing Percentage – what percentage of invoices are able to be processed straight through (with m-way match) without human interverntion
  • Operational Efficiency:Average Dispute Resolution Time (Improvement) – what is the average dispute resolution time in the platform and what is the improvement over the average time reduction versus pre-system implementation
  • Operational Efficiency:Early Payment Discount Opportunity Improvement – percentage-wise, how many more invoices eligible for early payment discounts can now be paid early (that couldn’t before due to processing delays), allowing organizations to improve their working capital management

Invoice to Pay is all about invoice processing automation and minimizing the amount of time that a human needs to manually review invoices for completeness and correctness and (automated) payment according to pre-defined terms. Make sure the metrics you choose reflect this.

We don’t claim this is a complete list, or every KPI that you can, and possibly should, ask for, just that if you are non-technical, and can’t judge a solution on its technical merits, if you can at least get these KPIs and force the vendor to prove them to you, then you will at least get a solution that is bound to provide you with some improvement and that, because of the real improvement potential, may actually be used.

The best solution is to hire an independent third party who is an expert in ProcureTech and who has no stake in any provider or implementer and is solely interested in doing Project Assurance for you, but if you can’t get that, at least get something which has a history of delivering measurable value to similar organizations.