“We’re talking about two different things.”
I have often heard that sentence in meetings, and said it often enough myself. Usually it was wrong. We were talking about the same thing. We simply used different names, and it took twenty minutes for someone to notice.
I studied industrial engineering because I was interested in the point where business administration and mechanical engineering meet. Later, I trained as a business mediator. Both times, it was about the same point: where people approaching things from different sides have to talk to one another.
One component, four names
Take the impeller in a pump.
The maintenance department calls it “Laufrad”. Purchasing writes “Impeller” on the order because the manufacturer supplies its information in English. In the drawing it is “Pos. 14”. And the colleague who built Line 3 in 2009 called it “Schaufelrad”, a term half the workshop still uses today.
Four names, one thing. As long as the people involved know one another, it works.
It stops working when the colleague retires. When a second location is added. When an external specialist has to handle a complaint. Or when someone tries to search for the information rather than asking another person.
What was taken for granted then becomes a search problem; the search problem becomes a follow-up question; and the follow-up question becomes work for two people.
Four questions mistaken for one
Anyone trying to sort this out will quickly find tools and consulting services on offer. What is rarely mentioned is that there are four different questions, and none answers the others.
1. What should it be called? One of the four names above has to be the standard. Not because the others are wrong, but because otherwise there is no agreed reference. The other names remain as synonyms so that they can still be found.
The component does not tell you which of the four names to choose. There is nothing about the impeller itself that dictates “Laufrad” rather than “Schaufelrad”. There is no correct answer merely waiting to be discovered. There is an answer someone has to decide on.
2. Where does it belong? The impeller is inside a pump, the pump is on Line 3, and Line 3 belongs to the North Plant. Someone asking about the line usually also wants to know what is associated with its components.
3. What kind of document is this? An approval is different from an inspection report, and both are different from a work instruction. Someone looking for the current version is looking for a particular kind of document, not just any document.
4. What is related to what? The ERP system may record that this impeller is in this pump from this manufacturer. The CRM system may record that it relates to a particular complaint from 2023. That both records concern the same thing is recorded nowhere.
Four questions, four answers. In practice, they are often lumped together. Then a business buys a tool that solves one of them and wonders why the problem remains.
Why build this if AI understands everything?
This is the question I hear most often now that everyone is talking about AI. It is a fair question, and it has a short answer.
A language model knows about the world. It does not know your business.
It knows what “Laufrad” and “Impeller” mean, and that they may refer to the same thing. It does not know that “Plant 7” means the filling operation at your site and the paint shop at the neighbouring site. That information does not appear in any training dataset because it does not appear in any public text. It was decided within your company, usually verbally, often years ago.
This is not a gap a larger AI model can close. It is the part the company itself has to contribute.
The uncomfortable part
All four questions above have something in common that people do not like to discuss: they require ongoing maintenance.
A term is created, a synonym added, an association corrected when something changes. No tool does this on its own, and no AI builds it for you. It can make suggestions, and NXTGN AI CORE does: when two terms repeatedly occur together in the collection, the system notices, and a suggestion goes to someone who can approve or reject it.
But a person remains in the process. A suggestion based on the collection is an observation. Only approval turns it into an agreed definition for which someone takes responsibility.
Why this is not just routine work
At this point, delegation seems natural. Someone in technical documentation gets the task because it looks like documentation work. Sometimes that works well. Often it does not, and the reason is not a lack of care.
When two departments use different names for the same thing, it is rarely accidental. Sometimes there is a technical reason. Sometimes there is an old dispute that has nothing to do with technology. Whoever decides which name applies also decides which side has to give up its preferred word. That is a leadership responsibility. Delegate it downwards, and you get back a list nobody follows.
I recognise the pattern from my work as a business mediator. Two sides argue about an issue while actually referring to something that happened behind it. You can spend a long time clarifying the issue. It is resolved only when both sides use the same word and know why that word was chosen.
My conclusion
A shared language is not a by-product of digitisation. It is a prerequisite for digitisation to deliver anything at all.
You cannot buy it or simply roll it out. You can agree it and maintain it, and both require attention from people with the authority to make decisions.
The effort is manageable. The question is who takes it on.
As long as the answer is “someone in the team”, there will still be four names for one thing, and the search will find none of them.