I like to keep an eye on the job market.
Not because I'm constantly looking for my next move.
I just think it's useful to know what companies are looking for.
What skills are becoming more valuable?
How are roles changing?
What would somebody expect from me if I walked into a similar role somewhere else tomorrow?
What could I expect of a new hire into my team?
Recently, I'm noticing something.
AI is everywhere.
AI transformation.
Digital procurement.
Automation.
Advanced analytics.
AI-enabled sourcing.
Increasingly, particularly in more senior procurement and supply chain roles, companies don't just seem interested in whether you've used AI.
They want experience implementing it.
Sometimes they want experience leading the transformation.
And that got me thinking.
What exactly counts as AI experience?
Because those are very different things.
I've been using AI for some time.
I experiment with it.
I use it to challenge my thinking.
I've looked at ways it might improve workflows.
I've tried things that have worked.
I've tried things that haven't.
I've also been heavily involved in the internal leadership side of technology transformation.
Understanding the business problem.
Helping shape what we need.
Working through processes, people and change.
But typically, there has been an external partner providing much of the technical capability.
So have I been involved in transformation?
Yes.
Have I personally led an end-to-end AI transformation, from strategy through technology to implementation and adoption?
No.
But I'm pretty sure I will at some point.
And perhaps that's the interesting part.
Because I'm not starting from zero.
I've led change.
I've worked through technology implementations.
I've worked with external partners providing the technical expertise.
I've dealt with processes, stakeholders, adoption and all the complications that come with changing how an organisation works.
What I'm building now is another layer of capability.
AI.
And I suspect I'm not alone in that.
I think we need to separate a few things.
Using AI is one thing.
You understand what the tools can do and use them effectively in your work.
Implementing AI is another.
You identify a real problem, change a workflow, introduce the technology, test it, deal with the data, governance and users, and hopefully make something better.
Then there is leading AI transformation.
That's something bigger again.
Strategy.
Technology.
Data.
Governance.
Risk.
Investment.
Processes.
People.
Adoption.
Operating models.
Change.
Potentially across an entire function or organisation.
But perhaps there's another side to this.
Implementing new things isn't new.
AI is new technology, but transformation isn't a new discipline.
Many experienced supply chain professionals have already spent years implementing systems, changing processes, working with technology partners, managing stakeholders and trying to get people to adopt new ways of working.
Once an AI idea becomes something an organisation actually wants to implement, much of that familiar machinery appears again.
Project teams.
PMOs.
Budgets.
Risks.
Governance.
Testing.
Training.
Change.
Adoption.
Benefits.
The technology may be different.
But some of the leadership required to implement it isn't.
Maybe that's another reason we should be careful about what we mean by “AI transformation experience.”
It doesn't mean a supply chain leader needs to become an AI engineer, a data scientist and a transformation specialist overnight.
But they probably do need to understand enough about AI to combine it with the experience they already have.
Perhaps our role is to understand the problem.
Define the outcome.
Challenge the solution.
Understand enough about the technology to ask good questions.
And bring the organisation with us.
That's leadership too.
And that's why I think the language around AI experience matters.
I don't think the answer is that every procurement or supply chain professional suddenly needs to become an AI expert.
I certainly don't intend to become a machine learning engineer.
But I do think we have some responsibility for our own relevance.
Because our profession is changing.
You can see it in job descriptions.
You can see it in procurement technology.
You can hear it in conversations at industry events.
And you can see it in the amount of time organisations are spending trying to understand where AI might actually add value.
Nobody really knows exactly where all of this lands.
I certainly don't.
But the direction is becoming increasingly difficult to ignore.
And waiting until somebody tells us exactly how our jobs will change feels like a risky strategy.
A recent conversation really brought this home for me.
I was at an industry event and met somebody working in procurement who showed me something he'd been developing internally.
It was an AI environment built around the work his function actually did.
Not a glossy demonstration of what AI might theoretically do one day.
Something useful.
Something real.
And it was impressive.
But the thing I found most interesting wasn't actually the technology.
It was the person showing it to me.
He understood procurement.
He understood the processes.
He understood the problems.
And he'd spent enough time exploring the technology to start connecting the two.
I remember coming away from that conversation thinking:
I need to try more of this myself.
Not:
We need a massive AI transformation programme.
Not:
We need to spend thousands on consultants.
Just:
What could I try?
Because those of us already working inside supply chain have an enormous advantage.
We know the work.
We know which processes frustrate people.
We know which reports take far too long to produce.
We know where planners spend hours manipulating information.
We know which sourcing activities are repetitive.
We know where decisions get stuck.
We know which information is difficult to find.
We know where the spreadsheets live.
And, perhaps most importantly, we know which problems are actually worth solving.
An AI specialist can bring technical expertise that I don't have.
A consultant might eventually help turn an idea into something far more sophisticated than I could build myself.
There may come a point where you need proper architecture, integration, security, governance, data engineering and change capability.
But you don't necessarily need all of that to ask the first question:
Could AI help me do this better?
So I've decided to do something very simple.
I'm giving AI an hour a week.
Not an hour reading about it.
Not an hour watching somebody else demonstrate it.
An hour trying things.
Taking something from the work I understand and asking whether AI could help me do it differently.
And I've given my team the same objective.
One hour a week.
Explore.
Experiment.
Try something.
Share what you learn.
I'm not expecting somebody to come back next Friday having transformed Procurement or Supply Chain.
That's not the point.
I want us to build curiosity.
To understand what these tools can do.
To discover what they can't do.
And gradually build our own experience.
Take something you actually do.
A supplier analysis.
A sourcing exercise.
A forecast review.
A repetitive report.
Preparation for a negotiation.
A pile of information you need to make sense of.
A process that takes too long.
And ask a simple question:
Could AI help me do this better?
Sometimes the answer will be yes.
Sometimes it will be no.
Sometimes it will produce something that looks brilliant until you realise it's wrong.
Good.
That's learning too.
There is an important caveat here.
Experimenting doesn't mean ignoring the rules.
If you're using company information, commercially sensitive data, supplier information, customer information or anything confidential, use only AI tools and environments your organisation has approved for that information.
And follow your organisation's policies.
If you're not sure whether you're allowed to put something into a particular AI tool, don't.
Use dummy data.
Create a fictional example.
Ask the right people.
Because understanding how to use AI responsibly is part of the experience too.
In fact, perhaps that's one of the first lessons in moving from simply using AI towards actually implementing it.
The clever idea isn't enough.
It has to work in the real world.
And I don't think every experiment needs to become a project.
We sometimes have a habit in business of turning an interesting idea into a programme remarkably quickly.
Business case.
Project team.
Consultants.
Steering committee.
Implementation plan.
Before we've really established whether the idea is useful.
Maybe AI gives us an opportunity to start differently.
Problem.
Experiment.
Evidence.
Then scale.
If something works, brilliant.
Now ask what it would take to implement it properly.
Perhaps that's where specialist support becomes valuable.
Perhaps that's where investment becomes necessary.
Perhaps that's where something small starts becoming transformation.
But first:
Does it actually solve a problem?
Because experience accumulates.
One hour doesn't make you an AI expert.
One experiment certainly doesn't make you an AI transformation leader.
But one experiment might teach you something.
Then you try another.
One of those experiments might become a workflow.
A workflow might become an improvement.
An improvement might become something your team uses.
Then you encounter governance.
Adoption.
Bad data.
Resistance.
Security.
Integration.
Measurement.
All the slightly less exciting things that sit between a clever demonstration and something that genuinely works.
And suddenly you're not just reading about AI anymore.
You're building experience.
And somebody else in your profession is doing exactly that.
They're experimenting.
They're discovering where AI works.
They're discovering where it doesn't.
They're learning which questions to ask.
They're making mistakes.
They're figuring out how the technology fits around the work they already understand.
That doesn't mean they'll replace you.
It doesn't mean everybody needs to race to become an AI specialist.
And it certainly doesn't mean twenty years of supply-chain experience suddenly becomes irrelevant.
Quite the opposite.
Domain knowledge might be one of the most valuable things we bring to AI.
Because the technology doesn't automatically know which problem matters.
We do.
But domain knowledge becomes even more powerful when we're curious enough to understand the tools now available to us.
I don't know exactly what procurement or supply chain will look like five years from now.
Nobody does.
But I'm increasingly convinced that waiting to find out isn't the answer.
So I'm giving myself an hour.
I'm giving my team an hour.
We're going to experiment.
Some things will work.
Some won't.
We'll do it responsibly.
We'll start with problems we understand.
And we'll see where it takes us.
Because somewhere else, another procurement or supply chain professional is doing exactly the same thing.
And a year from now, neither of us will just be able to talk about AI.
We'll be able to talk about what we tried.
What worked.
What didn't.
What we changed.
What we implemented.
And what we learned.
That's experience.
Theme
Capability
Signal
You don't need to become an AI expert. But you do need to start building experience.
Reflection
AI capability isn't one thing.
Using AI, implementing AI and leading AI transformation require different levels of knowledge, responsibility and experience.
But AI doesn't make everything we already know about transformation obsolete.
Implementing systems, managing projects, working with partners, changing processes, navigating governance and bringing people with us are not new challenges.
The technology is new.
Much of the leadership isn't.
Our value starts with understanding the work.
The problems.
The decisions.
The processes.
The people.
Then understanding enough about the technology to see where it might genuinely help.
Start small.
Experiment responsibly.
Learn where AI works and where it doesn't.
Then decide whether something deserves to scale.
Because experience rarely arrives before you start.
Question
What could you learn if you gave AI one hour of your working week?
The Demand Signal
Lessons from the front line of supply chain.
The Demand Signal
Lessons from the front line of supply chain.
