Why AI Projects Stall in the Pilot Phase

By Can Kuşaklı · Published October 16, 2026

A company starts an AI project. A vendor is chosen, a pilot is defined, three months of work follow. The pilot succeeds. There is a presentation and management is pleased.

Then nothing happens.

Six months later the solution is either not used at all or sits as a tab nobody opens on a computer in the warehouse. The project is officially a "success" and nobody brings it up again.

This is not the exception, it is the rule. And the cause is usually not the technology, whatever people assume.

Why do AI projects stall in the pilot phase?

Most enterprise AI projects hit the same wall: the people who know AI do not know the ERP, and the people who know the ERP do not know AI.

That sentence may sound too simple. Let us make it concrete.

The AI side - whether a startup, a consultancy or the company's own data science team - knows how to build the model. They know what is possible, which data is useful, how to measure the solution. What they do not know is why that company's order process took the shape it did. Why two product codes exist for the same item, why an approval step cannot be skipped, why the person in the warehouse has no time to look at that screen at six in the morning.

The ERP side knows all of that. They know what lives where in the system, what a field is really used for, why a certain report comes out wrong. What they do not know is what is technically possible today. They often do not even realize the problem in front of them is solvable.

Both sides do their jobs well. The problem is that nobody does the translation in between.

During a pilot this gap stays invisible, because pilots run in controlled environments, with selected data, with an enthusiastic team. The gap appears on the way to production - once the project meets real data, real permission constraints and the real people who are already doing the job somehow.

What is missing is the layer that does that translation. An automation layer is a piece of software that sits on top of your existing business system - whether that is SAP or a Microsoft stack - and runs the repetitive work a person does by hand, with the same permissions and without changing the system itself.

Are you behind, or did nobody write the layer?

Most teams we talk to start the conversation with an apology. "We are a bit behind on this" or "our processes are still very manual."

That diagnosis is wrong, and because it is wrong, it does harm.

You are not behind. The system is yours. The data is yours. The people who know the process are yours. The only thing missing is that nobody has stood in the right position so far to write what can be done with what you already have.

The distinction matters, because "we fell behind" pushes companies toward the wrong fix: big, sweeping, expensive transformation projects. The real diagnosis - "nobody wrote the layer in between" - points to something much smaller and much faster.

What do the processes stuck in that gap look like?

The work Akyalabs does sits exactly in this gap. The processes share these traits:

They run by hand not because they cannot be automated, but because nobody wrote the code. There is no technical barrier. Nobody was simply there to define the job, connect it to the system and put it live.

They live in one person's head. One person really knows the process and it is written down nowhere. When that person goes on leave, the work stops.

Nobody complains. This is the most telling sign. Everyone knows that report is pulled by hand on Monday morning, but nobody has named it a problem. It has become "that is how the work runs."

They may sit on SAP, Netsis, Canias, a local CRM or a Microsoft-based stack. The brand of the system is not decisive - what is decisive is that the process fell into the gap between the system and the person.

Typical examples: matching orders against delivery notes, tracking aged receivables, notifying people of production plan revisions, month-end close checklists, passing candidate details along in hiring. None of it is exotic. Most companies have at least two. For a concrete list, see 5 manual processes still running by hand at SAP/Netsis companies.

What does it take to get past the pilot?

The difference between projects that stall and those that reach production comes down to three things:

First: start at the right size. Pilots tend to be chosen too ambitiously. The projects that reach production often start embarrassingly small. A small job reaches production because it starts working without having to convince anyone. Marka Araçları is an example at that scale: it targets a single repetition, reading the TÜRKPATENT bulletin and running ePats checks one by one. At one office that check was repeated by hand roughly 8,000 times a month.

Second: write the process down. A process has to be defined before it can be automated, and in most projects this is never done. Writing it down looks boring but it is the most valuable part of the project: it is the only step that ends dependence on one person. Its value remains even if the automation never runs.

Third: bring the person doing the job into the process. Whoever prepares the report by hand today is the real expert on that process. When projects leave that person outside, two things happen: exceptions in the process get missed, and that person, understandably, does not take ownership of the solution. When the same person is included, the design is right and the rollout goes smoothly.

None of these three is a technology problem. All three are approach problems - and that is exactly why most stalled projects stall.

A fourth cause of unused pilots is putting the output in the wrong place. At a manufacturing plant, maintenance documents were scattered across folders, files and people. Bakımcı brought them into a single chat assistant: when a technician is unsure, they type the question and get the answer from the plant's own documents. The assistant is reachable from anywhere, so nobody has to walk back to the office to look something up. The solution goes to where the work is already done.

We explain how the layer is built technically in a separate article: How to Automate SAP Reporting Without Replacing SAP.

What does Akyalabs actually do?

We work in three ways, and which one is right depends on the company.

Implementation training. So your team can do this on its own. Instead of buying a tool and hoping, your own people learn to automate your own processes. In the long run this is the healthiest path, because whoever builds the layer also maintains it, and they sit inside the company.

One-to-one collaboration on specific processes. A concrete process is chosen, defined together, built and put live. Scope is kept narrow from the start. The aim is to get the first working thing into production as quickly as possible.

Custom product development partnerships. Only where it makes sense. If the need repeats and standard solutions cannot meet it, we build it together.

What all three share: we do not touch your existing system. We do not change your ERP, upgrade it or replace it.

Where do you start?

The first step you can take on your own is simple: for one week, note which jobs on your team run by hand. Then ask one question for each - does this job include a step that needs a decision?

Every job where the answer is "no" can be automated today.

If a few lines came out of that list, it is worth a conversation. The easiest way to begin is not a proposal but a chat: whichever process runs by hand at your company, let us look at it together.

The automation layer is missing - not the system.