Knowledge management in the enterprise is a term so worn out that most managing directors mentally push back their chair at the mere mention of it. For good reason: over the past 20 years they have lived through at least three knowledge-management projects that began with software investments and ended with disbanded staff units.
The diagnosis is straightforward. The projects do not fail for lack of tools. They fail because of three mistakes I have seen repeatedly over 28 years.
Knowledge management in the enterprise — the three most common mistakes
Mistake one: knowledge management is confused with a knowledge database. A knowledge database is a tool. Knowledge management is an organisational discipline. Anyone who introduces wiki software and calls it knowledge management has traded a tool problem for an organisational problem. After six months the wiki is half full of outdated content, no one is responsible for the maintenance effort, and management wonders why nobody uses the wiki.
Mistake two: knowledge management is anchored in a staff unit. Staff units have no operational mandate. They can develop methods and proposals, but they cannot oblige anyone to do concrete knowledge work. After 18 months the staff unit is disbanded and the project is deemed a failure. That is the predictable result of wrong anchoring, not the staff unit’s fault. It is the predictable result of a wrong organisational placement.
Mistake three: knowledge management is set up without methodological competence. Structured information maintenance is a craft. Topic modelling, metadata assignment, versioning, reuse — all of these are learnable methods, but they are not trivial. Anyone who does not master these methods builds either a chaotic wiki or an over-complex taxonomy monster. Neither works.
What knowledge management in the enterprise really is
Knowledge management is the organisational practice by which a company ensures that relevant knowledge is created, maintained, found, and used in a structured way. Three aspects are contained in this definition:
Creation. Knowledge does not arise spontaneously in a database. It is created in work processes — in design, on a service call, in a sales conversation, in handling complaints. The question is whether it is captured for reuse or stays in one person’s head. Anyone doing knowledge management organises the capturing.
Maintenance. Captured knowledge goes out of date over time. A service manual from 2018 is no longer usable in 2026 if the machine has received three updates since. Anyone doing knowledge management organises continuous updating, with responsibilities, versioning, and review cycles.
Use. Knowledge that nobody finds is dead knowledge. Search functions, taxonomies, and recommendation systems are the technical side. The organisational side is the question of whether staff actually find what they need on the first search, and whether they give up after three unsuccessful attempts or keep searching.
Where knowledge management in the enterprise should be anchored
My recommendation from consulting practice: anchor knowledge management in technical documentation. Not in IT, not in HR, not in a separate staff unit.
The reasoning: technical documentation already masters the methods that knowledge management structurally needs. Modular content structuring, metadata maintenance, terminology work, versioning, reuse across several documents — in other departments these are foreign words. In technical documentation they are everyday business. I describe the professional background to this in Technical Documentation as a Superbrain.
This anchoring is anything but trivial: technical documentation has to be given the mandate, explicitly by management. Without a clear assignment of responsibility, technical documentation faces exactly the same problem as a staff unit: methodological competence without leverage. With a mandate, it has both.
What knowledge management in the enterprise delivers in concrete terms
From three real projects I have accompanied, one concrete lever each:
Project 1. Mechanical engineering, 180 employees. Service knowledge was spread across three people who were all due to retire within the next three years. Structured capture in a CCMS-based knowledge management: 14 months of effort, 3 additional positions, in return a centrally maintainable body of service knowledge that still works after the staff turnover. ROI calculated over the staff-turnover period: positive, because the alternative — external providers for service training — would have been more expensive.
Project 2. Industrial service provider, 60 employees. Handling a complaint took 4 days on average. Main cause: searching for the right service documentation and past similar cases. Building a complaints knowledge base within technical documentation: average handling time after 6 months 1.5 days. Effect: less waiting time for customers, fewer escalations, measurably fewer follow-up complaints.
Project 3. Plant manufacturer, 600 employees. Onboarding new design engineers took 9 months until they worked independently. Structured onboarding paths based on existing design guidelines that were being maintained in technical documentation anyway. Onboarding time after 18 months: 5 months. A direct effect on staff costs and on the time to the first productive design contribution.
Three different industries, three different levers. What they have in common: all three set up knowledge management anchored in technical documentation, and bought no new system.
Where knowledge management in the enterprise hits its limits
Four limitations I address openly:
Build-up time. Building knowledge management takes at least 12 months before measurable effects become visible. Anyone expecting quick wins will be disappointed.
Staffing needs. Structured knowledge work needs staff. The rule of thumb from my projects: 1 additional person per 50 to 100 employees. Without this staffing increase, the project fails regardless of the tool.
Management commitment. Knowledge management touches areas that people are reluctant to touch. Who has which knowledge? Who maintains it? Who is responsible for the gap? These questions need answers from the top, otherwise they go unanswered.
Cultural work. Staff who see their knowledge as a personal asset only pass it on in a structured way when the culture values that. Anyone who only makes demands, without anchoring appreciation organisationally (bonus, recognition, career path), gets compliance without substance.
What you can do in concrete terms
If you want to build knowledge management in the enterprise, the first three steps are manageable:
- Take inventory: where does knowledge sit today (heads, folders, wikis, ERP, CRM)? How is it used? Where do waiting times and duplicated work arise?
- Check the methodological base: how is technical documentation set up? Modular or document-centred? CCMS or Word? Adequately staffed?
- Clarify the mandate: who in management carries the knowledge-management initiative? What powers does the operational responsibility receive?
Only after that comes the tool question. Anyone who works in this order builds a knowledge management that still works after 18 months. Anyone who starts with the tool question probably builds the next wiki that nobody maintains.
Knowledge management that still works after 18 months
Most knowledge-management initiatives fail not because of the software but because of the organisational anchoring and the methodological base. Schübeler Consulting helps you set this order up correctly: inventory, mandate clarification, implementation with staffing plan.
Book your initial consultation online →
Prefer to write? info@schuebeler-consulting.de
— Johann Jörgen Schübeler, Schübeler Consulting