Category Archives: Best Practices

Exact Purchasing is a Pocket Cube Part 1

Last month we told you that Jason was right when he said that we need exact purchasing, but as we clearly stated then, and stated now, it’s NOT a new matrix. Especially when the original Kraljic matrix didn’t really fix anything in the first place (as it just gave us a methodology to start thinking about Procurement methodically so that we could start on a journey to actually fixing Procurement).

However, any methodology that wants to fix Procurement can’t just try to reinvent the Kraljic Matrix, even if it takes a data, vs process, centric approach. (Although the correct answer will involve both data and process.)

There’s two reasons for this.

First, any answer must take into account people, process, and data. (It’s not tech, tech is just that which implements the process on the right data with the support of people, who at least need to define the process the tech will employ if automation is being deployed.)

Second, any answer must properly take into account the complexity, market risk, and category impact. The only way this can be done is if EACH dimension is analyzed separately — not bundled together in some arbitrary mish-mash of factors that tries to pretend two (or more) dimensions are more-or-less the same.

In traditional Kraljic, you balanced profit vs a risk-complexity mish-mash. It sounded good, except risk and complexity are NOT the same thing. Risk is external (market) risk that you can try to mitigate, but that you have no control over. Category and product complexity is completely under your control — you control the design, the raw material mix, the production process, etc. You can choose to make the product simpler or more complex, use better or worse materials (as long as they meet minimum/maximum industry and government safety and compliance requirements), or less (or more) intensive production processes. Your choice.

In the proposed Busch model, you replace impact with influence and map that against a risk-complexity mish-mash, and then you use this mapping to translate Kraljic’s definition of what a category is into an actual data-backed strategy to purchase it. It’s progress, but not the answer.

The answer, as per our last post, is the pocket cube, where you break out risk and complexity into their own dimensions and deal with the categories accordingly. Especially when there is a mis-match between the risk and complexity ratings.

It’s easy when the risk and complexity match in severity, and Jason is dead on when the risk, complexity, and category impact (not cost, or profit, but criticality) are low and when the risk, complexity, and category impact (again, not cost, or profit, but criticality) are high. In the first case, it’s transaction focussed (but not necessarily continuous real-time transaction monitoring) and in the latter case it’s fundamentally a cost-based architecture, but more complex than Jason presents.

Where it gets tricky is the grey areas when there is a mismatch in two of the categories and, more specifically, when risk and complexity are diametrically opposite. But we’ll get to that in a later post. Starting tomorrow, we’ll take the first two of the four easy categories.

AI has NOT changed the fundamentals of Procurement. It HAS Strengthened Them.

Procurement, one of the last-areas of the back-office to be hit, is still drowning in the AI-Hype machine that is going full-force 24/7/365, as a result of the self-propagating A.S.S.H.O.L.E. that does nothing but excrete derivative nonsense on a continuous basis, piling it so high that it’s hard not be be Blinded By The Hype!

But, as we’ve seen, this new age of Agentic AI is not accelerating us into the Intelligence Age, but instead devolving us into the Neolithic Age (as it’s now been proven that these technologies are eroding [our] critical thinking skills, and only a few critical thinkers seem to realize that AI is dulling our minds).

Plus, it’s not effective. Studies by MIT and McKinsey last year demonstrated that only 5%/6% of early adopters saw a return. That’s a 94% failure rate, which is even worse than the general technology failure rate of 88% that is the highest it’s ever been in two and a half decades of project failure.

All AI has proven is that you can fail much faster than ever before, but still lost just as much money. That’s because the situation in Procurement is the same as in every other back-office function. Results come from the classic formula of:

  1. PEOPLE first
  2. PROCESS second
  3. TECHNOLOGY third

You need good people more than ever. Sure AI can “process” mounds of data at speeds we’ve never seen, but that doesn’t mean it can extract meaningful intelligence, and even if the intelligence is accurate, that it’s actually useful. Remember, these systems not only process data faster, they hallucinate faster than a field full of hippies at a Woodstock revival concert. But since their grammar and paragraph construction is now better than 90% of the population thanks to the social media revolution that has resulted in the average person having an attention span less than a goldfish and an IQ significantly less than our great-great-great Victorian grandparents, the majority of the population is willing to accept anything they pump out as accurate (even when it’s not).

Only top trained people can properly process complex situations, come up with the right solutions, and execute them. They should be using the most advanced tools available to them to process and make sense of the data using modern Augmented Intelligence technologies, but they should NOT be doing what a dumb system, guaranteed to hallucinate on a regular basis, tells them.

Once you have good people, they need to implement good processes that ensure best practice execution not only by them, but by everyone else who is involved in the process, inside and outside the organization (in partners, providers, and clients). Process allows emerging talent (with good education, great cognitive capacity, and an exceptional [dumb AI free] work ethic) to execute at the level of top talent with the guidance the top talent built into the process, and get the experience they need to become the next generation top talent in the organization.

Finally, once you have the right people, who know what to do, and the right processes, that help them get things done, then, and only then, do you identify the right technology to fit into, and accelerate, the processes. Maybe it’s AI, but chances are it’s traditional, domain-specific, (A)RPA that supports the process to automation levels of 95% to 99%. Dependable, fit-for-purpose, technology is always faster, better, and significantly cheaper than general purpose hallucinatory AI that may, or may not, work on any particular problem.

If you want to survive the current chaos, remember these fundamentals.

And if you can’t remember more than one fundamental, just remember PEOPLE first!

(While you can still find, and hire, people who know what they’re doing. Those of us who grew up before tech took over are getting older and greyer. Without us, not only will you not survive today, but you’ll have no one to train your staff for tomorrow. To think that, as a race, we survived The Great Extinction and, more recently, the The Great Decline during the Younger Dryas era only to risk global civilization collapse as a result of The Great Retardation.)

The optimization era is finally beginning!

In a recent article, Koray Köse states that the EU just killed global supply chain optimization.

When, actually, they just ushered in the real optimization era.

If you are a true multi-national, as Koray has said, you have to pick 2 options out of the 3 options available since you can not simultaneously satisfy US CHIPS Act, EU IAA origin/low-carbon requirements, and Chinese local content rules. So you have to decide which 2 options are the most valuable to you (based on costs and revenue opportunity in the market). That’s an expected profit optimization based on predicted sale prices and the localized supply chain optimizations for cost computation.

So you have to run 3 different sets of scenarios against different assumptions and Pareto efficiencies — and as humans we just can’t do that, and today’s AI can’t do that either (despite the over-hyped claim to the contrary). You need optimization to pick/justify your options, and then ongoing optimization to keep costs, and revenue, in line with prediction as global events force you to reroute regionalized and localized supply chains, substitute materials due to shortages, etc.

What was killed was the simple concept of global optimization that was relatively easy to do without optimization (and what passed as optimization for the past 25 years). Up until now, the reality was that, if you had even a few constraints, and the ability to do simple math, you could quickly eliminate the most expensive suppliers and the suppliers that couldn’t meet your constraints, and then, using your constraints, cherry pick the lowest or second-lowest cost supplier/distributor, and come up with a solution that was within 1% to 2% of theoretical optimal, but that was actually more optimal in practice as it was more stable and easier to maintain.

Optimization is only needed when you need to make choices that can’t be made without considering multiple sub-cases, regionalizations, and localizations — and this is exactly what this messed up world has given us!

It becomes even more important if you are a true multi-national with business in, and government commitments in, the US, EU, and China. You have to adhere to all of the rules globally, but you can’t with any one product formulation, so you have to create at least 2 different products where you figure out what 2 of the three combinations are easiest AND cheapest to make, where to make them, and how to supply them to the countries you serve (with there will be one country each mix cannot be imported into). This requires a host of scenarios to be run before a selection to be made, and a host of models to be continually run during production and distribution to ensure everything aligns with changing market conditions.

So while the classic optimization vendors who can’t do anything more than minimally constrained global optimization are now dead, it’s finally opened up the era of real optimization. The question is, what vendors are going to step up to fill the void?

We Need Exact Purchasing … But It’s NOT a New Matrix!

We all know the Kraljic matrix is broken, and that it has been broken for a while. As Jason Busch starts off in his article on how Supply Management Must Become Exact Purchasing, Kraljic was right at the time, but it’s time to come back to where we started. And, more importantly, recognize that the Kraljic Matrix was designed as a starting point for supply management to think critically — and Supply Management was supposed to evolve from there. But it never really did.

Sure we got the Purchasing Chessboard by Kearney to supplement a host of seven step methodologies, procurement game plans, new techniques for managing indirect spend, lean supply management, and a slew of techniques from every niche consultancy to enhance your supply, and category management, strategies, but almost all of these are based on the classic 2 * 2 Kraljic matrix with refinement.

In his post, Jason, who rightfully says that procurement at scale is not one-size-fits-all tells us that answer is Exact Purchasing, or more specifically, The Exact Purchasing Quadrant, where he tries to map cost influence vs contract-and-supply complexity because Kraljic told you what a category is when he mapped profit impact vs. risk / complexity, but he didn’t tell you what to do with it. According to Jason, if you have:

  • low cost influence and low complexity, you transaction capture
  • low cost influence and high complexity, you govern the relationship
  • high cost influence and low complexity, you manage market risk
  • high cost influence and high complexity, you architect the cost

And Jason’s mostly right. Depending on the category in question, you’re generally going to apply one of those approaches.

Jason doesn’t stop there. He tells you that the thread that ties all four of these together is data at the core. And he’s right. Without a data-based (not necessarily database) approach, you’ll never effectively manage, and thus never effectively purchase, a category. Moreover, Jason does a great job at telling you what the core data is, where it resides, and where it could sit in your next generation enterprise Supply Management Solution (SMS). But he falls short when dictates the velocity, because that depends on the criticality. And even worse, the depth of data required depends on the criticality — which can also change the quadrant a category falls in!

For example, while packaging, print & marketing, and NPD are definitely strategic (Kraljic) cost architecture (Busch) categories for some companies (i.e. CPG, Advertising Agencies, and Manufacturers), they are tail-spend for other companies (i.e. Retail Store, Luxury Brands, and a Services Consultancy).

Jason’s improved approach still fails because it suffers from the same fallacy as the original Kraljic matrix — that complexity and risk are a single dimension. They’re not. Complexity is a factor of the product or service that you design and is an internal dimension that you have complete control over. Risk is a factor of the external environment that impacts your ability to create and deliver the product or service and depends on the financial stability of your supplier, the geopolitical situation in which it operates, the trade routes that exist between your supplier and your location, your supplier’s supply chain, and everything else in between — these are all factors you can’t control. Furthermore, it’s not profit impact (Kraljic) [which is short term] or cost influence (Busch) [which depends on spend], but criticality, which is measured in value impact [and what happens if the buy is unprofitable, of poor quality, or unavailable]. A category with zero savings potential can risk a 100M product line if your products can’t be completed without it (and we’ve seen this many times over the last two decades as critical sensors or single-sourced components shut down automotive lines or lack of RAM [from the decennial plant fires] or custom control chips [from trade slow-downs or insufficient production] greatly impacted personal computer / laptop or game system production — costing major brands hundreds of millions of dollars).

The reality is that Supply Management / Exact Purchasing / Get My Stuff (and Git-r-Done) is NOT a 2 * 2 matrix. It’s a(t least a) 2 * 2 * 2 pocket cube (and a 3 * 3 * 3 cube in large Enterprises) that is different for every organization where you take into account:

  1. complexity – low (med) or high
  2. market risk – low (med) or high
  3. criticality – low (med) or high

And as you progress from the lower left of the cube (where all dimensions are low) to the upper right of the cube (where all dimensions are high), you’re simultaneously following a three-dimensional path down a bi-furcating decision tree that takes you from non-critical items where you are simply managing as transactions to highly strategic items that you are cost architecting to the best of your ability, monitoring at least weekly, and alerting the category manager to on every major market event. In the middle, you will deal with your leverage and bottleneck items using well-timed market events to mitigate risk and managed relationships to ensure smooth supply, with the depth, and velocity, of the data correlated to the criticality of the item to your operation.

You do that, and you’ll finally be on the road to Exact Purchasing.

And I’ll leave it to Jason to work out the details of the starting cubic, as he’s so intent on fixing Purchasing (now that he’s semi-retired and can pontificate on the philosophical of purchasing).

(And once Jason does that, I’ll tell you how execution differs between small, medium, and large enterprises because “strategic” doesn’t mean the same thing at different levels, there is no one-size-fits-all platform, and, after a lack of operational readiness [which THE REVELATOR will happily fill you in on], this is likely the second biggest reason new technology acquisition projects fail in our space.)

Building a Good Solution ABSOLUTELY Requires a Good RoadMap

A few weeks ago we tackled the subject of How Does a Vendor Build a GOOD Solution? and outlined seven key steps. SI received some feedback, and most of it revolved around the roadmap and how it should only look three months out!

So we have to address this insanity!

First of all, name ONE great or revolutionary technological invention that was invented with three months effort. You can’t, because there isn’t one.

Now name ONE great piece of software that solves a significant business problem that no other system that came before solved that was invented with three months effort. You can’t, because there isn’t one.

Now name ONE Billion dollar enterprise software platform that went to market with an MVP in 3 months that became a powerhouse that a large swath of businesses are using. You can’t, because there isn’t one.

All you can do in three months is a crap an app that is a piece of crap. Now, you might be able to make a big splash on the app store or in the consumer shareware market, but enterprise software is a complex piece of enterprise technology that requires years of development … and years of planning!

Secondly, remember what a roadmap actually is. It’s a graphical document that shows all of the roads you have available to you, how fast you can travel down them, and where they will take you. It’s not a detailed travel plan!

Similarly, in technology, a roadmap lists out all the things you would like to do, what it might take to get there, and what options could take you there. It is NOT a detailed functional specification or a development plan for the next three to five years (which should be the length of time you should be thinking through). (Also remember that, historically, great inventions came from research labs where the researchers were thinking three, five, and even ten years out and had years to develop groundbreaking developments!)

There are a number of reasons you need to be thinking three years out (even if your plans completely change nine months in), but the most critical reason is this:

If you plan for three months, or go for speed over quality (assuming you can always fix it later) your teams take shortcuts, build crap infrastructure, and add technical debt faster than you can ever eliminate it! (It’s almost as bad as vibe coding your way to an MVP, and then realizing you can never support an enterprise stack on it and have to go back and rebuild it from the bottom up after you’ve wasted months of effort and tens of thousands (or more) on AI credits. (Alex Turnbull gives a good summary in this LinkedIn post.)

When you start thinking about where your enterprise application might need to go, even if you choose not to go in that direction, you understand what processes you will eventually need to support and how you will need to build the foundational data model, workflow and orchestration engine, integration capabilities, internationalization support, and other core foundational features to either build that out or integrate that capability in the future. You’ll have a better idea of what you’ll need in the stack, what you’ll need for the platform, and what the best development environments for your team will be. (Having to change out any of these is very time consuming and expensive should you make a mistake early on.)

For (an easily understood) example, if you think invoice processing sucks (because you only looked at three vendors as you are too clueless to do market research, like many vendors that started during COVID because they all of a sudden realized that the business back-office should be capable of running 100% online, distributed, and remote), what else are you likely going to do after that. (Unless you’re a world leader in invoice processing technology, no one is going to buy just that!) In other words, are you going to support invoice analysis and predictive payment analytics, payment platform integration, contract and PO data extraction and matching, enhanced procurement (platform) support, etc. All of these capabilities will dictate data model, orchestration, and stack requirements.

Again, the point is not to plan out a detailed release schedule, but understand where your customers might ask you to go, where you want to go, where you want to hire a guide (to provide you with the expertise you need), and where you might want to hire a service to take your customers there (because a certain capability is best done by a specialist). This, along with constant monitoring of customer functionality uptake, customer feedback, and user forums will give you the complete picture you need to create the high level development plan for the year and the detailed functional specification for the final release of the next quarter (which might be built incrementally using agile methodology).

To put this in terms non-technical people will understand, you can’t build a twenty-story high-rise on a foundation for a two-story house. By thinking ahead, you’re building a solid foundation, and when you start building, you’re building the frame for the twenty-story high-rise that you can then build out and complete floor-by-floor once you know what the tenants you are signing on want on their floor.

By thinking at a high level years into the future, you are visualizing how you are going to fit into and evolve with the organizational ecosystem you want to sell into, and you are making good architectural decisions as you will be able to build that understanding of what you’ll need to support!

Moreover, as one commenter pointed out, and we noted above, watching how users work with the system is key! That not only helps you understand the depth and configurability of workflow process management required, the breadth of the data models that will be needed, and what systems they will want interfaces to (based on what they use before and after), but how to design a good UX based on now they work and what they are adopting! (It should be noted that designing a good UX, including a good UI, can be harder than the model and controller algorithms — which, if you need advanced analytics, optimization, and higher performance, might take a PhD to get right — because it doesn’t matter how good the application core is if no one uses it!)

Roadmaps are key. That’s how your Chief Software Architect and Chief Technology Officer build great applications. It ensures that once you select a destination, they know the route they have to navigate to get there!