Most advice on AI adoption assumes you already have a pilot running. If you have no pilot and no shortlist, the first problem isn't technology: there are too many places to start, and no obvious way to choose between them.
Most conversations about AI adoption assume you're already somewhere on the journey. There's a pilot running, or a use case shortlisted, or at least a team who's been told to “look into it.” The advice out there is mostly written for that audience.
Far more organisations are somewhere earlier than that. No pilot. No shortlist. Just a growing sense that everyone else seems to be doing something with AI, and a vague discomfort about being the one still doing nothing. If that's where you are, the honest first problem isn't technology. It's that there are too many places to start, and no obvious way to choose between them.
At Notium, we score the organisation and the estate separately before recommending anything, and the verdict is allowed to be no. That's usually what breaks the paralysis: a ranked answer instead of another opinion in the room.
The real barrier is decision paralysis, not capability
Ask five people in the same organisation where AI should be applied first and you'll usually get five different answers. Finance wants it in forecasting. Operations wants it in scheduling. IT wants a platform decision made before anyone commits to a use case. Someone senior read an article about agents and wants to know why you're not already doing that.
None of these answers are wrong. That's exactly the problem. With no shortage of plausible starting points and no clear way to rank them, the natural response is to wait. Commission a strategy document. Run a vendor evaluation. Wait for the platform decision to settle before picking a use case, or wait for a use case before picking a platform. Eighteen months later, nothing has shipped, and the discomfort of being behind has only grown.
The organisations that actually get moving usually do something less impressive-sounding: they stop trying to choose the right starting point and just choose a starting point that's genuinely small and genuinely bounded.
Pick a problem you can point to, not a technology you want to try
A common mistake is starting with the technology rather than the problem. Someone decides the organisation should “do something with generative AI,” and only then goes looking for a use case to justify it. This tends to produce demos that are interesting and projects that go nowhere, because nobody was actually short of the thing being built.
The more reliable starting point is the other direction. Find a task that's genuinely annoying right now: something repetitive, something that eats an afternoon every week, something a specific person complains about regularly. It doesn't need to be strategically significant. It needs to be real and bounded, with a person who will notice and care if it gets easier.
This matters more than it sounds like it should. A use case invented to justify a technology has no natural champion. A use case that solves someone's actual weekly headache already has one, and that person becomes your best evidence when it's time to decide whether to expand.
In our own work, we insist on this even when a client arrives with a bigger idea already in mind. We'll ask what's actually eating someone's week right now, in a part of the business we can genuinely stand behind, before agreeing to build anything. It occasionally means saying the exciting idea should wait and the boring one should go first, which is a harder conversation to have but a much easier one to win.
Don't buy the platform before you've proved the problem
There's a strong pull, especially once budget gets involved, to make the first move a platform decision: pick the AI vendor, sign the contract, then figure out what to do with it. It feels like progress, because it's a decision with a purchase order attached.
It's usually the wrong order. A platform chosen before you understand your first real use case tends to get chosen for the wrong reasons: whoever presented best, whoever a competitor uses, whoever promised the broadest feature list. Once it's bought, there's pressure to make it look like the right choice, which quietly biases the use case selection that follows.
It's a more useful sequence to run a small, contained experiment on whatever's readily available, even something as unglamorous as an existing tool you already have access to, and let that experience tell you what actually matters in a platform. You'll know far more about what you need after one real attempt than any vendor comparison will tell you in advance.
Give it an owner before you give it a deadline
A pilot with no clear owner tends to survive exactly as long as the person who happened to build it stays interested. It gets demoed once, gets a round of applause, and then quietly stops being anyone's responsibility the moment that person moves on to the next thing.
Before the first experiment even starts, it's worth naming one person who's accountable for it: not necessarily the most technical person in the room, but someone who cares whether it actually gets used, and who has enough standing to make sure it isn't forgotten in three months. That ownership question is unglamorous compared to picking a use case, but it's usually the difference between something that becomes a habit and something that becomes an anecdote.
We build this sequencing into how we approach it at Notium: the platform conversation waits until the estate and the use case are both understood, not before. Where a client already has entitlements sitting unused, we say so and start there. Where they don't, we'd rather run the first real attempt on something modest than let a platform decision get made on a demo alone.
Let the first result set the pace, not a roadmap
There's a temptation, once you've picked a starting point, to plan the next eighteen months around it before you've learned anything from it. A three-phase rollout gets sketched out, a budget gets requested for the whole thing, and momentum builds around a plan that's still entirely theoretical.
It's a steadier approach to treat the first attempt as genuinely informative rather than a formality on the way to the real plan. Did it save the time it was supposed to? Did people actually trust the output, or did they quietly double-check it every time? What would need to be true for this to expand to a second team or a second process? The answers to those questions are worth far more than a roadmap written before any of them were known, and they'll tell you honestly whether you're ready to go further or whether the first attempt needs another round before it does.
What starting from zero actually looks like
None of this requires a strategy document, a platform decision, or a large budget. It requires picking one real, bounded problem that somebody genuinely wants solved, trying something small against it with a named owner watching, and letting what you learn decide the next step rather than deciding it in advance.
That's a much less impressive story to tell in a board update than “we're rolling out an enterprise AI strategy.” It's also considerably more likely to still be running, and still be trusted, a year from now. The organisations furthest ahead a year from now won't necessarily be the ones with the boldest plan today. They'll be the ones who started smaller than felt comfortable, and actually started.
Notium works with SAP customers at every stage of this, including organisations taking their first real step into AI. If you're not sure where to start, that's a normal place to be, and a conversation worth having before the decision, not after.
