Knowledge Management: Organizational Competency, Models, and Examples

By Kevin Kim · Updated Oct 13, 2026

Knowledge management is the organizational capability to create, share, retain and apply what people know, so results don't depend on any one person's memory. It covers explicit knowledge (documents, data, procedures) and tacit knowledge (skills, judgment, intuition). It succeeds or fails on habits, roles and trust long before it depends on tools.

Tacit and Explicit Knowledge: The Distinction Everything Else Rests On

Most companies think of knowledge as the stuff stored in documents. That's the easy half. The harder half lives in people's heads and hands.

Ikujiro Nonaka's 1991 Harvard Business Review article, The Knowledge-Creating Company, opens with a blunt claim: in an economy where the only certainty is uncertainty, the one sure source of lasting competitive advantage is knowledge. The same article separates two kinds of it. Explicit knowledge is the kind you can put into documents and data. Tacit knowledge, by contrast, is "highly personal" and "hard to formalize", and it is deeply rooted in action and in a specific context such as a craft, a technology or a team. Nonaka borrows the philosopher Michael Polanyi's phrase for it: "We can know more than we can tell."

The article's example is still the clearest one. In 1985, Matsushita's developers couldn't get a new home bread-making machine to knead dough properly, even after comparing X-rays of machine-kneaded and baker-kneaded dough. Software developer Ikuko Tanaka trained with the head baker at the Osaka International Hotel, noticed his distinctive way of stretching the dough, and worked with engineers to turn that into product specifications, including special ribs inside the machine. Nobody could have found the answer in a manual, because no manual existed. It had to be watched, practiced and then put into words.

Here's how the two types compare in a normal company.

Key Facts

• Origin of the tacit/explicit framing in management: Nonaka's 1991 HBR piece is described by the magazine's own editors as having helped popularize the notion of "tacit" knowledge in management thinking.
• Three parts of the model: Nonaka, Toyama and Konno's 2000 paper proposes that knowledge creation consists of the SECI process, ba (the shared context) and knowledge assets.
• A formal standard exists: ISO 30401 sets requirements and provides guidelines for establishing, implementing, maintaining, reviewing and improving a management system for knowledge management. It was first published in 2018.

Why Knowledge Management Is a Capability, Not a Project

A project ends. A capability is something the organization can do repeatedly, under pressure, with different people. That's the useful way to think about knowledge management, and it's why it sits alongside organizational capability building rather than in the IT budget.

Three things have to be true for it to count as a capability:

1. It's repeatable. A new hire, a new region or a new product gets the benefit of earlier lessons without someone reinventing them.
2. It's owned. Someone is accountable for each critical body of knowledge, with a name beside it.
3. It's practiced. People use the knowledge, correct it and add to it as part of normal work, not as an annual cleanup.

If a company can't do those three things, buying a bigger repository won't change the outcome. It will just hold more unread documents.

The SECI Model: Four Ways Knowledge Moves

Nonaka and Takeuchi's SECI model describes knowledge creation as a spiral between tacit and explicit forms. In the 1991 article, the four patterns appear as socialization, articulation, combination and internalization. Later work calls the second one externalisation, which gives the model its name: Socialization, Externalization, Combination, Internalization.

In Nonaka's Matsushita story, Tanaka moves through all four: she learns the baker's craft by working with him, puts what she learned into explicit specifications, her team standardizes it into a manual and a product, and the experience of building the machine enriches their own tacit knowledge. Then the spiral starts again at a higher level.

Two points matter for managers. First, the article is clear that socialization on its own is limited: because the knowledge never becomes explicit, it cannot easily be leveraged by the organization as a whole. Second, the same goes for combination alone, which merely reshuffles what's already written down. The value comes from the exchange between the two forms. That's also why this capability feeds directly into innovation management.

Ba: The Place Where Knowledge Gets Made

SECI says how knowledge converts. Ba says where. Nonaka and Konno's 1998 paper defines ba as "a shared space for emerging relationships", and adds that it can be physical, virtual or mental. Their argument is that knowledge is tied to its context, so you can't just move it around like freight.

The 2000 paper by Nonaka, Toyama and Konno sorts ba into four types by two questions: is the interaction individual or collective, and is it face to face or virtual? Each type mainly offers a context for one SECI mode.

The practical takeaway: most organizations over-invest in systemising ba (the repository) and under-invest in originating and dialoguing ba (the human contact). The same paper gives middle managers a central role, calling them "knowledge producers" who energize ba, while top management is responsible for articulating the knowledge vision. If your managers are too overloaded to host a decent retrospective, you've found the bottleneck.

Knowledge Management Models Compared

SECI isn't the only lens. Pick the one that fits the question you're actually asking.

Communities of practice

Etienne and Beverly Wenger-Trayner define communities of practice as groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly. They name three crucial characteristics: a shared domain, a community that interacts and helps each other, and a practice, meaning a shared repertoire of experiences, stories, tools and ways of addressing recurring problems. The same source is clear that having the same job title doesn't make a community of practice unless members interact and learn together. That's a useful warning when someone proposes to "create a community" by adding people to a mailing list.

ISO 30401

ISO 30401 is the management system standard for knowledge management. Its published scope covers establishing, implementing, maintaining, reviewing and improving an effective management system for knowledge management in organizations. A practitioner paper on integrating it with quality systems notes that the standard prescribes activities for knowledge development, including acquisition, application, retention and handling of obsolete knowledge, plus activities for conveyance and transformation such as human interaction, representation, combination and internalization. The authors point out that those last ones are directly inspired by SECI. You don't need certification to borrow its logic: policy, roles, objectives, review. The standard also fits naturally with process optimization, since knowledge activities are most reliable when they're built into the processes people already follow.

How to Build the Capability, Step by Step

1. Name the knowledge that matters. Start from business risk, not from a library. Which skills would hurt most to lose? Which decisions get repeated badly? Pick 5 to 10 critical knowledge areas, such as "pricing exceptions" or "plant changeover."
2. Map where it lives. For each area, note whether it's mostly explicit, mostly tacit or mixed, who holds it, how many people hold it, and where it's written down (if anywhere). A single holder with nothing written down is your highest risk.
3. Assign an owner for each area. The owner isn't the best expert. It's the person accountable for making sure the knowledge is current, findable and passed on.
4. Create originating ba. Set up pairing, shadowing and rotation so tacit knowledge moves person to person. This is where coaching and mentoring do real work.
5. Create dialoguing ba. Run after-action reviews, decision retrospectives and expert interviews to turn experience into words. Ask "what did you notice that told you to do that?" rather than "can you document this?"
6. Capture it in a usable form. Write short, specific pages: the decision, the signals, the exceptions. Good technical documentation is plain, current and tied to a task.
7. Combine and curate. Merge duplicates, retire stale pages, and give each page an owner and a review date. A smaller, trusted library beats a large, doubted one. Digital fluency across the team helps people search, tag and contribute without hand-holding.
8. Close the loop with practice. Build the knowledge into onboarding, drills and everyday workflows so people internalize it. This is the organizational side of continuous learning.
9. Start communities where practice is shared. Where practitioners in different teams do similar work, give them a recurring slot and a real problem to solve together.
10. Measure and review. Track a few signals: time for a new hire to reach full productivity, repeat incidents, share of critical areas with a named owner, and how often key pages are used and updated. Review quarterly.

A Ready-to-Copy Knowledge Management Plan

Use one row per critical knowledge area. Fill it in with the people who hold the knowledge, not just their managers.

Questions to answer before you finalize it:

• If the top holder left tomorrow, what would break first?
• Which area has only one holder and nothing written down?
• Where does the knowledge need to be used, and is it available there?
• How will we know in six months that it's working?

A simple maturity check

This five-level scale is a practical self-assessment, not a published standard. Rate each critical knowledge area, then look for the pattern.

Most teams that try this find a mix: perhaps level 3 for finance procedures and level 1 for sales judgment. That's normal, and it tells you where to start.

Examples by Business Function

These are illustrative scenarios, not case studies.

Sales

The best rep's discovery calls close at a higher rate, and nobody knows why. Originating ba: junior reps sit in on calls. Dialoguing ba: the rep and a manager listen to three recordings and list the questions that shifted the conversation. Combination: those questions become part of the call guide, alongside existing qualification criteria. Internalization comes from using the guide and adding to it.

Customer support

Tier-two agents solve odd tickets by instinct. A weekly "hard ticket" session captures the reasoning behind five tricky resolutions. The write-ups go into short troubleshooting pages with the symptoms, the check and the fix. Agents who use them regularly stop needing them, which is the point.

Engineering

After an outage, a blameless review asks what the on-call engineer saw that others might have missed. The answers become a runbook entry and a monitoring change. Without the dialogue step, the runbook would only say what to do, not how to recognize the situation.

HR and onboarding

New managers struggle with the same three conversations. A community of practice for first-time managers meets monthly, and experienced managers bring real cases. A short guide emerges, and it links to broader skills such as skills-based talent strategy where relevant.

Operations and manufacturing

A senior technician can hear when a machine is about to fail. Pairing a junior technician on rounds transfers some of the skill. Recording what the senior technician checks and listens for gives the plant a starting checklist, which the team refines over time.

Finance

Month-end close depends on a controller's memory of exceptions. Documenting the exceptions, who approves them and why, converts a fragile habit into a reviewed procedure.

Do's and Don'ts

Limits of the Models

SECI is a descriptive framework drawn from case studies of companies, and it isn't a measured prediction tool. The four modes overlap in real life; people rarely move cleanly from one to the next. Treat the model as a checklist of questions: have we given this knowledge a place to be shared, a way to be put into words, a form people can find, and a chance to be practiced? And remember that some knowledge resists capture. The goal isn't to extract everything from people's heads. It's to make sure the right things are shared before they're needed.