Ein Kompetenzkatalog ist das gemeinsame Vokabular, mit dem ein Unternehmen beschreibt, was seine Mitarbeitenden können. Richtig aufgebaut wird er zum Rückgrat von Rollendefinitionen, Kompetenzmatrizen, Entwicklungsplänen und interner Mobilität – den zentralen Bausteinen jeder Skill Management Software. Schlecht aufgebaut, zu allgemein, zu kleinteilig oder voller Aufgaben und Persönlichkeitsmerkmale statt Kompetenzen, vertraut ihm niemand, und deshalb nutzt ihn auch niemand.
Dieser Leitfaden führt Sie Schritt für Schritt durch den Aufbau eines Kompetenzkatalogs und erklärt zwei Konzepte, die darüber entscheiden, ob Ihr Katalog auch beim Wachsen nützlich bleibt: Kompetenztaxonomie und Kompetenzontologie.
Was ist ein Kompetenzkatalog?
Ein Kompetenzkatalog ist die zentrale, strukturierte Liste aller Kompetenzen, die ein Unternehmen erfasst: jede Kompetenz, die Mitarbeitende haben oder benötigen, einmal definiert, einheitlich benannt und so organisiert, dass sie über Rollenprofile, Kompetenzmatrizen, Entwicklungspläne und interne Mobilität hinweg wiederverwendet werden kann. Statt dass jedes Team eigene Bezeichnungen für dieselbe Kompetenz erfindet, gibt der Katalog dem Unternehmen eine gemeinsame Sprache dafür, was Menschen können.
Ein Kompetenzkatalog ist nicht dasselbe wie eine Skill-Matrix, die den Katalog auf ein bestimmtes Team oder eine bestimmte Rolle anwendet, um Kompetenzstufen zu erfassen. Der Katalog ist das Wörterbuch; die Matrix ist ein damit geschriebener Satz.
Was ist eine Kompetenztaxonomie?
Mit Kompetenztaxonomie ist das Klassifikationssystem, das die Kompetenzen in Ihrem Katalog in Kategorien und Ebenen einordnet, so wie eine biologische Taxonomie Arten in Gattung und Familie einteilt. Sie beantwortet die Frage: Wo gehört diese Kompetenz hin?
In der Praxis besteht eine Kompetenztaxonomie aus:
- Kategorien: Gruppierungen wie „Daten & Analyse", „Kommunikation" oder „Projektmanagement", die die Struktur oder Branche Ihres Unternehmens widerspiegeln.
- Kompetenztypen: Hard Skills, Soft Skills und Sprachen sind die gängigsten, Sie können aber auch eigene Typen definieren.
- Hierarchie: übergeordnete und untergeordnete Kompetenzen, zum Beispiel „JavaScript-Frameworks" als übergeordneter Begriff von „Vue.js" und „React".
Eine gute Taxonomie ist es, die einen Katalog mit Hunderten von Kompetenzen noch überschaubar macht: Mitarbeitende, die nach einer Kompetenz suchen, finden sie in einer sinnvollen Kategorie, und Admins erkennen doppelte oder fehlende Kompetenzen auf einen Blick.
Was ist eine Kompetenzontologie?
Mit Kompetenzontologie geht einen Schritt weiter als eine Taxonomie. Während eine Taxonomie Kompetenzen in einen Kategorienbaum einordnet, bildet eine Ontologie die Beziehungen zwischen Kompetenzen ab, unabhängig davon, in welcher Kategorie sie stehen. Sie beantwortet eine andere Frage: Wie hängt diese Kompetenz mit jener zusammen, statt nur, wo sie hingehört?
Typische Beziehungsarten in einer Kompetenzontologie sind:
- Spezialisierung / Verallgemeinerung: „Vue.js" ist eine Spezialisierung von „JavaScript-Frameworks".
- Enthält / ist Teil von: „Vue.js" enthält „Vue Router" als Komponente.
- Voraussetzung: Eine Kompetenz muss erlernt sein, bevor eine andere wirksam genutzt werden kann.
- Ähnlichkeit / Transfer: wie stark sich Kenntnisse in einer Kompetenz auf eine andere übertragen lassen, zum Beispiel hat „Vue.js" eine hohe Ähnlichkeit mit „React" und „Angular", weil sich die zugrunde liegenden Konzepte überschneiden.
Das ermöglicht es einer Plattform, über Kompetenzen nachzudenken statt sie nur aufzulisten: sie empfiehlt, was als Nächstes zu lernen ist, ordnet jemanden einem Projekt zu, selbst wenn die genaue Kompetenz nicht gelistet ist, aber eine eng verwandte, oder erkennt, dass zwei „doppelte" Kompetenzen im Katalog eigentlich dasselbe sind, nur anders geschrieben.
Taxonomie vs. Ontologie, in einem Satz
A taxonomy sorts skills into a hierarchy of categories. An ontology connects skills to each other through typed relationships, whether they sit in the same category. A taxonomy is usually part of an ontology, but an ontology carries more information than a taxonomy alone.
Wie Sie einen Kompetenzkatalog aufbauen
1. Legen Sie fest, was als Kompetenz zählt
Bevor Sie den ersten Eintrag anlegen, legen Sie fest, was in den Katalog gehört. Eine Kompetenz beschreibt, was eine Person kann, nicht eine Aufgabe, ein Zertifikat, ein Persönlichkeitsmerkmal oder eine Arbeitsbedingung.
- „Videobearbeitung" ist eine Kompetenz.
- „Das wöchentliche Rückblick-Video schneiden" ist eine Aufgabe, keine Kompetenz; sie gehört in die Aufgabenliste einer Rolle, nicht in den Kompetenzkatalog.
Ein einfacher Test: Können Sie sagen „sie ist Expertin für [X]"? Wenn ja, ist X wahrscheinlich eine Kompetenz. Klingt der Satz seltsam, haben Sie es eher mit einer Aufgabe, einem Ergebnis oder einem Merkmal zu tun.
Es hilft außerdem, Fertigkeit von den benachbarten Begriffen abzugrenzen, die oft verwechselt werden: Fähigkeit, Kompetenz und Qualifikation bedeuten jeweils etwas leicht anderes, und genau dort beginnt bei den meisten Katalogen die Unschärfe. Den Unterschied erklären wir ausführlich in Was ist der Unterschied zwischen Fähigkeiten und Fertigkeiten?
2. Beginnen Sie mit Rollen, nicht mit einer leeren Liste
Zu versuchen, „jede Kompetenz im Unternehmen" von Grund auf zusammenzutragen, führt zu einer aufgeblähten, unübersichtlichen Liste. Beginnen Sie stattdessen mit den Rollen, die in Ihrer Organisation bereits existieren, und leiten Sie deren Kompetenzen aus den zugehörigen Stellenbeschreibungen ab. So bleibt der Katalog von Anfang an auf das beschränkt, was Ihr Unternehmen wirklich braucht, und jede Kompetenz hat von Tag eins an einen klaren Platz. Siehe So erstellen Sie eine Rolle im Kompetenzkatalog für die praktischen Schritte.
Our advice for anyone starting today: pick the roughly 10 to 20 skills that are actually relevant to the work at hand rather than trying to cover everything up front, then let real gaps in visibility tell you where to expand next.
3. Finden Sie die richtige Granularität
Zu allgemein („Marketing") und der Katalog sagt nichts Brauchbares aus. Zu kleinteilig („Instagram-Reels-Untertitel in Canva erstellen") und er wird unhandlich und abschreckend zum Ausfüllen.
Ein verlässlicher Maßstab: die Granularität, die in Lebensläufen und Stellenanzeigen bereits üblich ist. Beide Formate haben sich über Jahrzehnte auf einen Detailgrad eingespielt, der genau genug ist, um aussagekräftig zu sein, und kompakt genug, um lesbar zu bleiben. Fragen Sie sich also vor jeder neuen Kompetenz: Könnte das in genau dieser Form in einem Lebenslauf oder in einer unserer Stellenanzeigen stehen? Wenn ja, ist die Granularität richtig.
A second, complementary test: stop splitting a skill further once you can no longer point to a specific training for it. “Programming languages” is too broad to act on; “C++” is specific enough that you can find or commission a course for exactly that. Once you’re below the level where a dedicated training could plausibly exist, you’ve gone one level too deep.
4. Nutzen Sie das Vokabular, das Ihre Organisation bereits versteht
Eine gemeinsame Sprache für Kompetenzen entsteht nicht erst mit dem Katalog, sie existiert meist schon informell, überall dort, wo Entscheidungen zur Projektbesetzung getroffen werden. Wenn Ihre Teams bereits Kompetenzmatrizen ausfüllen, um Projekte zu besetzen, sind diese Begriffe bereits Teil des Arbeitsvokabulars Ihres Unternehmens, von allen verstanden und verwendet. Behalten Sie sie bei.
Falls dieses gemeinsame Vokabular noch nicht existiert, erfinden Sie keines von Grund auf: Übernehmen Sie Kompetenzbezeichnungen aus vorhandenen Lebensläufen und aus Ihren internen oder externen Stellenanzeigen. Beide sind bereits in einer Sprache verfasst, die Kandidaten und Mitarbeitende wiedererkennen.
5. Ordnen Sie Kompetenzen in einer Taxonomie
Sobald Sie eine funktionierende Liste von Kompetenzen haben, gruppieren Sie diese in Kategorien, die die Struktur oder Branche Ihres Unternehmens widerspiegeln, und versehen Sie jede mit einem Typ (Hard Skill, Soft Skill, Sprache oder ein eigener Typ Ihrer Wahl). Das macht aus einer flachen Liste eine Taxonomie, in der man wirklich stöbern kann.
6. Fügen Sie eine Ontologie-Ebene hinzu
Sobald die Taxonomie steht, verknüpfen Sie verwandte Kompetenzen miteinander: markieren Sie Spezialisierungen, Voraussetzungen und Kompetenzen mit starkem Transfer untereinander. Diese Ebene macht aus einer statischen Liste etwas, das intelligenteres Matching und personalisierte „Was lerne ich als Nächstes"-Empfehlungen unterstützen kann, und hier sparen KI-gestützte Werkzeuge meist den größten manuellen Aufwand, da Beziehungen zwischen Hunderten von Kompetenzen mühsam von Hand zu erfassen sind.
This isn’t just useful for recommendations, it also changes behavior at the exact moment duplicates get created. When catalog search only matches exact text, people whose wording doesn’t line up exactly tend to add a near-identical skill under different phrasing instead of finding the one that already exists. Once search also surfaces related skills through the ontology, not just exact matches, people recognize “that’s basically it” and reuse the existing entry instead, which cuts down on duplicates substantially.
7. Legen Sie die Governance fest: Wer darf Kompetenzen anlegen, und wer genehmigt sie?
A decision to be made at the beginning: Will employees be allowed to add a skill that doesn’t exist yet, and should new skills sit in a review queue before moving into the public catalog? Turning on review keeps the public catalog clean at the cost of a bit of friction. Leaving it off lets the catalog grow faster but needs more cleanup later.
We have set up the following process with several customers to ensure a consistent and clear skill catalog over time:
- Creation. A user creates a new skill. It’s private by default, visible only within their own team.
- Adoption signal. Other, independent teams start selecting and reusing that same skill on their own.
- Threshold reached. Once enough independent teams have picked it up, that cross-team reuse is treated as a signal that the skill is relevant beyond one team.
- Routing. The skill is automatically moved out of private status and routed to a review queue.
- Review. A subject-matter reviewer, not HR, evaluates it. HR can govern the process, but usually can’t judge whether a technical skill is correctly named, categorized, or actually relevant. That judgment needs someone who knows the domain.
- Decision. The reviewer approves it into the public catalog, merges it with an existing near-duplicate, or rejects it.
A lesson learned from several rollouts: define the catalog’s structure and actually enforce that reviewer role from day one. Skipping it early caused most of the recurring friction later.
8. Halten Sie den Katalog lebendig
Ein Kompetenzkatalog ist nie „fertig". Neue Werkzeuge, Rollen und Arbeitsweisen bringen ständig neues Vokabular. Prüfen Sie ihn regelmäßig, um Duplikate zusammenzuführen, ungenutzte Kompetenzen zu entfernen und Synonyme zu ergänzen, damit zwei Schreibweisen derselben Kompetenz nicht als zwei verschiedene Einträge enden.
What matters most is clear responsibility and dedicated time, not everyone’s occasional attention. Someone needs to own the catalog, with time set aside to actually review it, the same way DB Systel’s catalog stewards do. Search only stays trustworthy if a query reliably turns up one entry instead of several near-identical ones.
The administrative work behind that, however, can be mostly automated. Teammeter’s Skill-Katalog uses AI to surface near-duplicates and inconsistent naming, categorize new skills, generate relationships between them, and translate skill names for multilingual teams. That leaves the catalog administrators to focus on judgment calls on whether the catalog actually represents the common language in the organization.
Häufig gefragt
The skill catalog is the actual list of skills your organization tracks. The skill taxonomy is the classification system, categories, types, and hierarchy, that organizes that list so it stays navigable as it grows.
A taxonomy organizes skills into a hierarchy of categories. An ontology adds typed relationships between skills, specializations, prerequisites, and transfer between related skills, regardless of category. Most mature skill catalogs use a taxonomy for organization and an ontology for reasoning about relationships.
No. Tasks describe what someone does (“edit a video”); skills describe what someone can do (“video editing”). Keeping tasks in a separate field, tied to a role, keeps the skill catalog reusable across roles instead of duplicating skill names as tasks everywhere they’re needed.
Granular enough to be meaningful, broad enough to stay manageable. A practical benchmark is the level of detail already used in CVs and job postings: if a skill could realistically appear in one of those, in that exact form, the granularity is about right. Another good test: stop splitting once you can no longer find a specific training for the result.
Yes, and you should. If a skill matrix is already filled in and actively used to staff projects, its vocabulary is already part of the company’s shared language. Carrying those terms into the catalog is easier, and more accurate, than inventing new ones.
Usually HR or People Ops owns the governance (categories, review process, standards), while managers, employees, and subject-matter reviewers contribute and vet the actual skill content, since HR can rarely judge whether a technical skill is correctly named or categorized. A catalog that only HR touches tends to drift away from how work actually gets described on the ground.
AI is genuinely useful for the repetitive parts: suggesting skills from a role name, sorting new skills into the right category, generating relationships between skills, and translating skill names for multilingual teams. It’s less reliable for the upfront decisions, what counts as a skill, and at what granularity, which still benefit from a short human review pass.