What Is Knowledge Management? Systems, Methods and How to Choose One

Ask four people in the same organisation what knowledge management means and you will often get four different answers. A search platform, to an IT director. The help centre, to a customer support lead. Culture and behaviour change, to a management consultant. To a librarian, archivist, or information manager it means description and retrieval, and the work of making sure that something written down once can be found again later by someone who had nothing to do with writing it.

Those answers are not equally right, and the difference is not academic. It decides which team owns the work, what the project is measured on, and what the organisation eventually buys.

This guide covers what the discipline includes, how it differs from information, document, and records management, what a knowledge management system does, which methods organisations genuinely use, which standards apply, and how to evaluate a system if you get that far.

What does knowledge management actually cover?

The discipline works on two kinds of material. Explicit knowledge has already been written down: reports, procedures, completed research, catalogue records, past project documentation. Tacit knowledge has not, and often cannot easily be, because it lives in the judgment of experienced staff. Knowing which supplier is reliable, or which past project a new problem resembles, is tacit knowledge. Between the two sits implicit knowledge, the practical know-how that could be recorded but never has been because nobody thought to ask. The distinction sounds theoretical until somebody retires, and it is worked through in detail in our guide to how tacit and explicit knowledge behave inside a law firm.

Every organisation manages knowledge somehow. What separates them is whether it happens by design or by accident, and whether the institutional knowledge built up over years survives a reorganisation, a merger, or a single resignation. That is the whole argument for treating this as a discipline rather than as a habit.

Any serious effort has three parts: the people who hold and use the knowledge, the processes that keep it captured and current, and the systems that store and surface it. Organisations buy the third part. The first decides whether the purchase was worth it.

How does knowledge management differ from information, document, and records management?

These terms overlap in practice, which is why they get used interchangeably. The same document can sit under more than one of them at the same time, and vendors tend to describe their software using whichever term is selling that year. The distinctions are still real, and they are worth holding onto, because each discipline answers a different question.

The sharpest line in that table is between records management and knowledge management, and it is a line of purpose rather than of content. A record exists because an obligation requires it: a regulation, a contract, a legal duty, or an internal policy reflecting one. ISO 15489-1:2016, the international standard for records management concepts and principles, frames the discipline around the creation, capture, and management of records rather than around their reuse.

Knowledge management starts from the other end: something is worth keeping because somebody will need it again. No rule obliges an organisation to keep a good internal briefing on a market it exited, and it may be the most valuable document in the building on the day it goes back.

A completed project report can be a record under a seven-year retention schedule and a knowledge asset with no expiry date at all. The two frameworks do not compete. They answer different questions about the same file.

This is not a semantic exercise, because framing decides ownership. Scope a project as records management and it lands with compliance or information governance and gets measured on retention accuracy, which it can pass while nobody ever reads anything again. Scope the same project as knowledge management and it lands with a library, information, or knowledge team, gets measured on reuse, and fails quietly if the description work is skipped.

An integrated library system sits slightly apart from all of them. It manages a described collection of resources, and it is the discipline where controlled description is most mature. That is why this work so often ends up with people from a library or archive background. Where knowledge sits in collections, creating contextual descriptions are usually requires both information mangement expertise and an in-depth knowledge of what the organization does. It is time-consuming, which is why most organizations have a glut of unstructured knowledge assets that are difficult for an organization to take advantage of.

What does a knowledge management system actually do?

A knowledge management system is the software expression of the discipline, not the discipline itself. An organisation can practise knowledge management with no dedicated system at all, and it can own an expensive KM system while practising very little. Being clear about that before a procurement conversation prevents a good deal of disappointment afterward.

Setting product names aside, a system in this category has six jobs.

Capture and contribution: Knowledge gets in by one of three routes: staff submit it, it is ingested in bulk from systems that already hold it, or it is created in place. Which route matters less than whether contributing is easy enough that busy people bother. Where it feels like an administrative chore, the repository stays empty and the post-mortem blames the software.

Description: This is the part buyers underestimate most often and the part that decides whether anything else works. Content has to be described consistently enough to be retrieved by someone who does not already know it exists. That means metadata, a taxonomy or classification scheme reflecting how the organisation actually thinks about its work, a thesaurus connecting the different words people use for the same concept, and authority control keeping names of people, organisations, and subjects consistent as records accumulate over years. Our guide to metadata management software covers how controlled vocabularies and taxonomy management work in practice. Without this layer, capture produces a store nobody can retrieve from, which is the commonest way one of these projects fails without anyone noticing.

Retrieval: Search across the repository is the baseline. Reaching content held elsewhere is where approaches diverge, and it is worth asking exactly how a given system does it. Enterprise search indexes external sources directly. Federated search queries them in real time through protocols such as Z39.50 and returns results from each. A third approach relies on shared taxonomies and metadata so that material in a document management system or intranet is described consistently enough to surface alongside everything else. Ask about unified search across connected information sources specifically and pin down its exact reach. Retrieval quality is a function of description quality, and a better search tool rarely fixes a findability problem on its own.

Access control: Configured roles and permissions determine who sees what. In regulated organisations and professional firms this is a functional requirement rather than an IT detail to settle later, because retrofitting a permissions model across a populated repository is slow and thankless work.

Review and currency: Content has to be checked, kept current, and retired when it stops being accurate. Out-of-date knowledge that is still findable is worse than knowledge that was never captured at all, because somebody will act on it in good faith.

Reporting: What is being found, what is being used, and what has never been opened once. The last is the most instructive of the three and the one worth confirming a system can actually produce before you sign anything.

A note on artificial intelligence: AI-assisted retrieval and summarisation are standard in this category now, and they change the description question rather than removing it. A summary is only as dependable as the material behind it, and an assistant that cannot tell an approved current procedure from a superseded draft it may present both as equally authoritative, potentially misleading users. We set out what that means for special libraries and archives in our discussion of knowledge management and artificial intelligence. For a buyer, AI features raise the value of the description layer rather than lowering it.

Which knowledge management methods do organisations actually use?

There is no standard sequence here, and anyone presenting one is describing a preference. What organisations do in practice is pick two or three approaches against a specific problem. The choice comes down to one question: is the knowledge in question easier to write down, or easier to pass from one person to another? Documentation suits the first. Conversation, mentoring, and shadowing suit the second. Treating everything as a documentation problem is the most common misstep. All five approaches below are attempts to produce the same behaviour, knowledge sharing, and that behaviour responds to incentives and management attention rather than to tooling.

Communities of practice group people around a shared area of expertise rather than around a reporting line. APQC, the research body that has studied this longest, treats them as a core approach. The test of one is whether it has a genuine shared problem and somebody with time to keep it alive. Assembled from an org chart, it becomes calendar clutter.

Lessons learned and after-action reviews capture what a project taught while the detail is still recoverable. Timing decides everything here. A review held within days of the event produces something usable; one held after the team has dispersed produces paperwork.

Expertise location makes it possible to find the person who already knows, which is frequently faster than finding the document. It earns its keep in organisations large enough that people genuinely do not know each other, and in a team of thirty it solves a problem nobody has.

Knowledge retention and transfer address the departure problem: succession, handovers, and retirements. A departure is the moment the cost of unmanaged knowledge becomes visible to people who were not previously interested in it, which is why departures so reliably prompt a wider programme. Start months before somebody leaves, not during their notice period.

A knowledge audit establishes what the organisation already holds, where it sits, and who depends on it. It is unglamorous and almost always the right first move, because nothing else reliably distinguishes a missing-content problem from a findability one.

On the SECI model. Ikujiro Nonaka and Hirotaka Takeuchi’s model of knowledge conversion, made up of socialization, externalization, combination, and internalization, is where much of this vocabulary originated, and it is worth knowing for that reason alone. It is a conceptual model of knowledge creation rather than an operating procedure, and treating it as a workflow is a dependable way to produce a programme that reads well and changes nothing.

Are there standards for knowledge management?

Yes, and more than most buyers expect. The one written specifically for the discipline is rarely mentioned in vendor material at all.

The point most software marketing gets wrong about ISO 30401 is what it means by the word system. It uses the term in the management-system sense: policy, roles, planning, evaluation, improvement. It is not a specification for software. No vendor can sell you an ISO 30401 knowledge management system, because the standard describes what an organisation does rather than what a product contains. Read that way it is useful even if you never intend to certify, and the revision now in development is worth tracking if you are building a programme around it.

The ISO 9001 clause matters more immediately. If your organisation is already certified, knowledge management is not a new initiative needing justification from nothing; it is an existing obligation you are probably meeting informally. That is often the strongest funding argument available, and it sits in a document the quality team already owns. Note that a sixth edition is scheduled for publication on 16 September 2026, so check the clause wording against whichever edition is in force when you write the case.

The description standards in the final row sit underneath the rest rather than alongside it, which is why native support for the ones you already use is a procurement question rather than a theoretical one.

Where knowledge management sits in different organisations

The function has no fixed home. Where it lands, and what it is asked to do, changes the work considerably.

Special libraries and corporate information centres: This is often where the function already lives, because the skills it needs are the skills these teams have. The knowledge is a mix of purchased research, subscriptions, internal reports, and staff expertise, across settings from corporate and special libraries to law, medical, news, and research information centres. Whether the team is called a library, an information service, or a knowledge centre, the recurring problem is mandate rather than capability: a group treated as a cost centre is asked to run the function for the whole organisation with no authority to require anyone to contribute.

Law firms and in-house legal teams: Here the knowledge is precedents, drafted clauses, matter history, and knowing which partner has handled something similar before. The discipline has its own established vocabulary and its own software category, and we cover it separately in our guide to legal knowledge management.

Research and technical organisations: Consultancies, laboratories, and engineering and scientific bodies hold project history, test data, technical reports, and published research, spread across several systems organised by discipline rather than by the people searching them. Engineering, scientific and technical organisations tend to share a characteristic failure: each specialism can find its own material and nobody can find anybody else’s.

Lucideon, a materials science consultancy working across healthcare, aerospace, nuclear, energy, and construction, had that shape of problem: international teams searching the World Ceramics Abstracts database, the library collections, and proprietary research papers as three separate exercises. Working with Soutron, it built a branded portal, the Lucideon Online Information Service, bringing those sources together with self-service requesting and usage reporting. The full Lucideon case study sets out how.

“Soutron has been a brilliant massive step forward for us and is now central to everything we do in the library.”

     — Lucideon

Corporate archives and heritage organisations: These hold institutional memory formally, and their description practice is frequently the strongest anywhere in the organisation. The question is not whether the material is well described. It is whether the archive is connected to the people who need it this quarter rather than only to researchers in fifty years.

Government and public bodies: Here the work usually arrives attached to a transparency, accountability, or continuity requirement rather than a productivity argument, which changes who sponsors it and what it is measured on.

How to choose a knowledge management system

Before comparing systems, establish what the organisation needs to find and reuse, and who needs it. A knowledge audit, or a scoped pilot on one real and irritating problem, will tell you more than any vendor demonstration, because a demonstration shows what a product does well rather than what your organisation does badly. Buy first and define requirements afterwards and you get an expensive system configured around a process nobody agreed to, followed by a view that the system was the problem.

These are the questions worth taking into an evaluation, and what a weak answer sounds like.

Mistakes worth avoiding

Buying a tool before agreeing on the problem:: The most expensive mistake and the easiest to detect. If nobody can say in one sentence what will be findable afterwards that is not findable now, the requirements are not ready.

Building a taxonomy in isolation: A classification scheme designed by two people in a room reflects how those two people think. Where it does not match how users understand the work, they fall back on free-text search and the taxonomy becomes decoration. Test it with the people who will search it before it is loaded.

Treating it as a project rather than a service: Projects close, and when they do, capture stops, review stops, and the repository decays at whatever rate the organisation changes. Somebody has to own it afterwards, with time actually allocated.

Measuring contribution instead of reuse: Ten thousand documents and no retrieval is a storage cost, not a knowledge asset. Count what gets found and used rather than what gets uploaded.

Where Soutron fits

Soutron builds information management systems for organisations whose knowledge sits inside collections, archives, records, and specialist libraries, with 50+ years behind that work. The connection to everything above is the description layer. The Soutron Information Management System is built around capture and tagging of organisational content, a multi-lingual thesaurus and authority control that keep description consistent as material accumulates, relational data structures, and configurable branded portals so that different audiences reach the same collection through an interface suited to them. It supports RDA, ISAD(G), ISAAR, and Dublin Core, along with legacy AACR2 records, integrates with SharePoint and iManage, and exchanges data through XML, MARC21, CSV, and provides a full API for integration with other systems. Access is governed by configured roles and permissions.

Where retrieval needs to reach past the repository itself, Soutron Discovery provides unified search across connected information sources, including library materials, subscriptions, and proprietary databases.

That suits organisations whose knowledge problem is fundamentally one of description and access across mixed collections. It is a weaker fit where the main requirement is a customer-facing help centre, and it is worth saying so plainly rather than discovering it during an implementation.

Frequently asked questions

What are the five stages of knowledge management?

There is no agreed set. Competing models circulate with five stages, five C’s, five pillars and seven types, most originating with individual consultancies rather than with a standards body or professional association, and they disagree with one another. The components that recur across them are people, process, content, technology and governance. For a structure with actual standing behind it, ISO 30401:2018 sets out requirements for a knowledge management system.

Is knowledge management the same as a knowledge base?

No, and the two are usually bought by different departments for different reasons. A knowledge base publishes approved answers outward, most often to customers, and support teams own it. Knowledge management serves internal specialists, includes material nobody has written down yet, and tends to sit with a library, information, or knowledge function. Conflating them is how organisations end up with help-centre software and an unsolved internal findability problem.

How does a knowledge management system work?

Content is contributed by staff or ingested from systems that already hold it, described with metadata against a controlled vocabulary, made retrievable through search across the repository and connected sources, governed by configured roles and permissions, and reviewed on a cycle so it stays accurate. None of that sequence is automatic. Each step needs somebody accountable for it, which is why two systems with near-identical feature lists can produce very different results.

What is knowledge transfer, and how is it different from knowledge management?

Knowledge transfer is the movement of knowledge from one person or team to another, typically around a departure, a handover, or the close of a project. It is one activity within knowledge management rather than a synonym for it. The difference that matters operationally is direction: transfer moves knowledge to a known recipient, while knowledge management makes it available to people you cannot identify in advance.

Do you need a knowledge management system to practise knowledge management?

No. Many organisations start with practices rather than software: a lessons-learned routine after each project, a maintained directory of who knows what, a habit of reviewing key documents. A system becomes necessary when the volume of content, the number of contributors, or the need for consistent description and controlled access exceeds what shared drives and spreadsheets can hold reliably.

Is personal knowledge management the same thing?

No. Personal knowledge management is the practice of organising your own notes, reading, and reference material for your own recall and thinking. It shares vocabulary with organisational knowledge management but not its purpose. Organisational knowledge management exists so that knowledge is usable by people other than whoever created it.

The part that actually decides it

Plenty about this work is genuinely difficult, culture and incentives and executive sponsorship among it, but storage is not the constraint. For organisations whose knowledge sits in collections, the constraint is description and reuse: deciding what needs to be findable, describing it consistently enough that somebody who did not create it can retrieve it, and keeping it current enough to be trusted when they do.

Organisations that get value from this work tend to move in the same order: establish what they hold, agree what needs to be findable and by whom, and only then decide what to buy. Where to start differs, though. An organisation with an existing library, archive, or information team has a description capability to build on. One without has to acquire it somewhere, and that is a resourcing decision rather than a software decision.

If you are working out what that would look like across your own collections, we are happy to talk it through.