Continuous improvement in the age of AI
A global logistics company we work with kept running into the same situation. A frontline team in the Netherlands hits a problem. They do what good teams do: dig into the cause, try a few things, and eventually land on something that works.
Two years earlier, a site in Singapore had solved the same problem. The fix worked there, and the knowledge of it sat in someone’s head or in a spreadsheet on a regional drive. Nobody in the Netherlands had any way of knowing that, so they started from zero.
Both teams were doing their jobs well. That is what makes the story uncomfortable, because no amount of extra effort or better training would have fixed it. The answer existed. It just could not be found.
If you run operations across more than one site, you probably have a version of this story. This article looks at why it keeps happening, what we built to stop it for a global logistics client, and where AI genuinely helps once the foundations are in place.
Where good ideas go to disappear
Continuous improvement programmes are usually good at producing wins. Teams spot waste, test a change, and measure the result. The trouble starts one step later, when the win has to travel.
Three leaks show up again and again.
The first is capture. Writing up an improvement properly takes time that nobody has on a busy shift, so the record gets a title, two lines and a photo, or nothing at all. The real detail—what was tried, what failed, and why the final version worked—stays with the people who did the work.
The second is retrieval. Suppose the record does exist. It lives in a regional spreadsheet, a slide deck from a review meeting, or a shared folder with a naming convention that made sense to one person in 2022. Someone facing the same problem in another country has no reason to open any of them.
The third is language. A site-level win documented in French or Mandarin is invisible to a supervisor who reads Dutch. In a global business, the language barrier quietly divides the organisation into parts that cannot learn from each other.
The result is that improvement knowledge behaves like tribal knowledge. It belongs to whoever was in the room, moves at the speed of conversation, and often walks out of the door when those people move on. This is where knowledge management becomes important—not simply storing information, but making valuable organisational knowledge easy to capture, find, understand, and reuse. Our view is blunt: a shared folder nobody can search is the same as having no folder at all.
Search by symptom, because that is how problems arrive
Here is a detail that changes how you design the whole thing. Nobody walks up to a supervisor with a root cause. They walk up with a symptom.
The scanner keeps dropping its connection. Cartons are arriving crushed on the same lane every week. A changeover that should take twenty minutes is taking an hour. These are illustrations, but they sound like the way people really talk about problems on a floor.
Now think about how the original team filed their fix. They filed it under the cause, because by the time they wrote it up, they knew the cause. The person searching next year does not know the cause, which is the reason they are searching. A library organised by cause is invisible to the people who need it most.
Flipping that around was the core design decision in the platform we built. Instead of asking users to guess the right category, it asks them to describe what they are seeing, and it surfaces the closest matching solutions from the global library. The person with the problem does the easy part, and the platform does the hard part.
What we built for a global logistics client
The client had years of genuine improvement wins scattered across regions. The brief was to make them findable, fast, for people who work in different languages, on different devices, in different business units. Six capabilities did most of the work.
- A centralised improvement library. One searchable place to register and retrieve improvement records, so every solution is documented once and stays put. Connecting improvement records, dashboards, permissions, and business systems also requires reliable automation and integration.
- Symptom-based search. Teams describe the problem in their own words and the platform returns the closest existing solutions.
- Support for 16 languages. French, Dutch and Mandarin are among them. A record written in Singapore can be read in Amsterdam without a translation project.
- Single sign-on across computers, tablets and mobile. The answer has to be within reach of the person standing next to the problem, and logging in cannot be a hurdle.
- Interactive KPI dashboards. Managers see submission rates, projected savings and improvement activity in real time, which turns a cultural initiative into something measurable.
- Role-based permissions with audit trails. The right people see the right records, and there is a clear history of who added or changed what.
None of these is exotic on its own. The value came from putting them together in a way that matched how frontline teams actually work, and from choosing findability over completeness at every decision point.
What changed
Once existing solutions became discoverable, duplicated effort across business divisions dropped noticeably. Teams stopped reinventing fixes that already existed elsewhere in the company, and hours that would have gone into repeat problem-solving went into new problems.
Managers gained something they had never had before, which was a live view of how much improvement activity was happening and what it was worth. A programme that once ran on goodwill and anecdotes now had numbers attached.
Participation improved as well. When submitting an idea takes less effort and the person can see that others will actually find and use it, people submit more. The client’s teams now build on each other’s work instead of starting from scratch, and improvement practices are far more consistent across the organisation.
Where AI actually earns its place
The platform above is built on structured records and symptom-led search. AI makes several parts of it better, particularly when combined with AI-powered data and intelligence solutions.
Retrieval that understands meaning. Keyword search only works when the person searching and the original author happen to use the same words. AI-powered retrieval changes that by understanding the meaning behind a query rather than relying only on exact matches. For example, it can connect “cartons crushed at the bottom of the stack” with a record titled “load stability on mixed pallets,” even though the wording is completely different. For a symptom-led knowledge library, that makes finding relevant solutions much faster and more practical.
Translation and summarising. A long record can be reduced to a few lines in the reader’s own language, with the full detail one click away. A supervisor decides whether a fix is worth pursuing in thirty seconds instead of ten minutes.
Easier capture. Much of the raw material for a good record already exists in shift notes, chat threads and photos. AI can draft a structured entry from it, so the person writing it up reviews and corrects instead of facing a blank form. Since capture was the first leak, this matters more than it might seem.
There is also a warning attached, and it is the reason we start with the library rather than the model. AI pointed at unstructured tribal knowledge produces confident nonsense. It needs consistent records to work from: what the symptom was, what the cause turned out to be, what was changed, where, and what happened afterwards. Without that, an assistant will happily produce an authoritative answer that mixes two unrelated fixes.
Two boundaries are worth keeping in place. First, the assistant reduces reading load and leaves the judgement to people, because whether a fix from Singapore suits a site in the Netherlands is a decision for the team that knows both sites. Second, permissions and audit trails have to sit underneath any AI layer, so what it can surface is controlled and every answer can be traced back to a source record.
That is our broader belief in one paragraph. The AI era leaves the requirements of enterprise systems where they were, and it raises the price of getting the foundation wrong, because an assistant now repeats every gap in your data at scale.
How to start without a big programme
You do not need a global platform to test the idea. A small start will tell you a lot.
- Pick one problem type at one or two sites. Choose something that recurs, such as equipment stoppages or damaged goods, so you can see a quick payoff.
- Make the symptom the first field. Whatever template you use for improvement records, ask “what did people see?” before “what was the cause?” This single change makes the records searchable by the people who will need them.
- Count failed searches. Ask teams to note when they looked for an existing fix and could not find one. That number is the size of your problem, and it is a much easier case to make to leadership than a general appeal for better knowledge sharing.
- Decide your language policy early. If your sites work in several languages, settle how records will be written and read before you have a thousand of them.
- Give the library an owner. A shared space with no owner decays. Someone needs the job of keeping it tidy and encouraging use.
The unglamorous half of every AI project
Plenty of companies we talk to want an AI assistant that understands how their operation works. The knowledge it would need is probably spread across three regions, two spreadsheets and the memories of a few veteran supervisors. Turning fragmented operational knowledge into a usable enterprise platform often requires thoughtful application development and modernization.
Getting it out of those places is the unglamorous first half of the project. In our experience it is also the half that decides whether the second half works.
If your teams keep solving the same problems in different time zones, we are happy to talk it through. Write to us at info@shvintech.com or visit www.shvintech.com.