Let’s think about AI from first principles.
Imagine the early days of the automobile industry. Cars were made by hand. Skilled individuals used tools (screwdrivers? wrenches? hammers?). The quality of the cars was variable. It was difficult to produce in high volumes.
Then, Henry Ford applied principles developed in other industries (like meat packing) to automobile manufacturing. He standardized components, broke down the process into steps, and set up a production line in which workers (specializing in individual stages) sequentially performed all of the tasks necessary to make a car. Production engineers studied the line constantly, using the data they gathered from time-and-motion studies to tweak the work at every point to make output more efficient on the margin.
“By 1914, Ford was producing more cars than all other automakers combined, with a Model T rolling off the line every three minutes.”
Automation of the Ford line brought prices down, making cars more affordable. He also took care of his workers, raising wages and implementing work rules that improved their lives and enabled them to afford the cars they manufactured. The impact this industrialization had on the broader face of America was even more significant. Other industries adopted his production techniques and his labor policies. Urban geography changed as automobile adoption became widespread with the rise of the suburbs; Ford had compressed distance. Other countries followed suit.
Car companies started to outsource some of their production lines, such as the assembly of parts (or, in some cases, whole cars), sometimes sending work outside of the country.
Fast forward to today and many automobile manufacturing plants employ robots instead of humans. The robots work tirelessly. They are less expensive. They are more reliable. They use more specialized tools. They are custom-designed; a robot on the automotive line is different from a robot in a shoe factory.
The modern company is full of so-called knowledge workers who work with data, using their judgment to make decisions. They have specific expertise in one or more functional areas, including procurement. Often, they must collaborate with other knowledge workers within the firm who have access to different data and look at it through the lens of different knowledge.
To quote Daniel Kahneman, Olivier Saboy, and Cass R. Sunstein from their book Noise, “Judgment can therefore be described as measurement in which the instrument is a human mind. Implicit in the notion of measurement is the goal of accuracy – to approach truth and minimize error.”
There is a parallel here to the evolution of manufacturing.
In the beginning, there was pen and paper. Procurement staff did everything manually. At the RFP end of the spectrum (EdgeworthBox’s area of focus), this meant coordinating internal stakeholder committees, developing requirements, writing bid solicitation documents, and mailing potential suppliers. It involved tracking everything in spreadsheets kept up by hand. Suppliers wrote out their responses and buyers evaluated them.
The advent of email and spreadsheet software made this easier to track and coordinate. Instead of corresponding with suppliers using letters, buyers could do so with electronic forms of communication. Spreadsheets helped procurement staff plan and organize reverse auction RFPs and RFQs. Theoretically at least, it was easier to manage and retain data for subsequent use.
In practice, the judgment of the staff derived from their experiences. Procurement events were noisy and biased in that there was tremendous variability around the outcomes. Even for one-off decisions, the outcome could be very different depending on who was running the process. Purchases of goods and services did not always obtain the best value-for-money in terms of the problem-solution fit the firm sought or obtaining the right price from the right supplier. Procurement judgment was prone to missing the truth.
ERP solutions and other sourcing software tools emerged over the past thirty years. These sought to take the knowledge worker’s process (for various functions) and to translate them into code, replacing the use of email and spreadsheets. The underlying (unstated) assumption behind these systems is that all companies execute these functions using the same process. Developers held this assumption even more firmly when building software for use in a specific industry, say manufacturing. All manufacturing companies were deemed to use roughly the same accounting, for example. And they were thought to approach RFPs the same way.
It makes sense to do so from the developer’s perspective. There are fixed costs to writing code. To the extent that you can sell the same code to more people, you amortize these over a larger base, improving your profitability. However, you avoid contextualizing the solution for each company.
You can have any color suit you like, sir, as long as it’s grey.
This lack of contextualization is a problem. Consider system A. It was originally written for manufacturers to help them execute RFPs. The vendor obtained tremendous success and sold themselves to a large ERP company. The ERP company then integrated the acquired solution into their offering as their procurement module, something its customers could elect to bolt on as an option. The ERP company wants to have a comprehensive suite of solutions so that they become the single source of back-office truth for their customers. Software is about scale, after all.
What happens if your company is a medical products company that is using system A. You have to jam your square peg into their round hole. What’s even more difficult is that the ERP system sells expensive seat licenses. Your CFO wants to control how many people get these, so it’s typically only people from the procurement department who warrant access. The other stakeholders are left on the outside.
In the end, many people end up using email and spreadsheets to overcome the limitations of the ERP module. Combine this reduced business-software fit between system A and the user firm’s context with the fact that the data in the system is restricted in terms of who can access it (and who practically does look at it), judgment gets noisy and biased.
Companies don’t buy the right products. They don’t find the right suppliers. They don’t pay the right prices.
Companies don’t get value-for-money.
AI takes two forms: tools and agents.
An example of an AI tool is chatbot, like ChatGPT. People use ChatGPT to write the emails that they send to suppliers or to other internal stakeholders. They may ask ChatGPT to write the Statement of Work. In this case, the machine is predicting a series (sometimes a long one) of next words. We use judgment to predict. The machine has some judgment that it has distilled from its training on vast amounts of general data. The user provides some context (in what is called the context window) and the machine does the rest. For some tasks, it’s probably fine. For other tasks that require more specific knowledge and greater experience in making decisions, it may not be the best solution.
We can think of AI agents like the robots on the manufacturing line. We give them access to tools, some of which may be AI tools like chatbots and others may be more general like access to Internet search or a calculator for performing mathematical operations.
I suspect that many of the early AI tools and AI agents were nothing more than wrappers for the legacy systems and ERP modules they were meant to augment. The predictions were just as biased and as noisy. If anything, the process became opaquer.
Over time, the agents will be more effective and more transparent. They will use chain-of-thought reasoning to emulate the judgment of their human overseers, showing their work. They will have access to a broader array of tools.
Their judgment will improve.
Most importantly, though, the agents will be customizable for the specific context of each user firm and each user case. This will be made much easier for agents using software tools that have built-in flexibility and collaboration around structured data. The flexibility makes it easier to integrate idiosyncratic conditions; no more trying to fit in questions about penetration testing in an RFP template designed for buying diesel generators. Collaboration is key because the agents will become members of the team; the more information and context they can obtain from the team, the better the outcome will be. Structured data, say from prior RFPs and responses received, will be vital for developing the agents’ judgment.
This kind of thoughtful approach will be far superior to just creating an agent backed only by a general large language model, or one reliant only a limited set of tools.
The efficiency gains of a robotic manufacturing line compared to manual assembly are staggering. The gains from agents will be just as impressive.
Please reach out to us. We love talking about the future of procurement and AI, in particular.
