Warum 800-Skill-Datenbanken sterben - und was die Critical Few stattdessen leisten.

1Die Szene: zwölftausend Skills, eine Vorstandsfrage

Der Termin steht im Kalender als „Workday Skills Cloud Demo - HR-Direktorin, CFO, IT". Der Vertreter zeigt eine Plattform, die aus zweihundert Lebensläufen knapp zwölftausend Skills inferiert hat. Cluster, Adjazenzen, Trendkurven. Auf der Folie blinkt eine Heatmap. Die HR-Direktorin nickt, der CFO rechnet im Kopf die Lizenzgebühr gegen ein dreijähriges Active-Sourcing-Budget. Am Ende der Demo stellt sie die einzige Frage, die in diesem Raum zählt.

„Welche zehn davon tragen unsere Strategie?"

Stille. Der Vertreter referiert auf „Talent-Intelligence-Workflows" und „inferierte Adjazenz-Modelle". Die HR-Direktorin wiederholt die Frage. Der Termin endet höflich. Drei Wochen später unterschreibt das Unternehmen die Lizenz trotzdem - nicht, weil die Antwort kam, sondern weil niemand eine bessere hat.

Die Szene wiederholt sich im DACH-Mittelstand seit etwa zwei Jahren in immer derselben Form. Workday, Cornerstone, Beamery, Eightfold und Gloat verkaufen Skills-Plattformen mit ähnlichem Versprechen. Die Demo ist gut. Die Implementierung kostet sechsstellig. Und die Vorstandsfrage bleibt offen.

Dieser Artikel beschreibt, warum das so ist - mit verifizierten Daten von Josh Bersin, der Sevoir Group und Deloitte. Und er beschreibt, was die Critical-Few-Logik der HIHB-Methode stattdessen leistet: nicht achthundert Skills katalogisieren, sondern fünf bis acht identifizieren, an denen die nächsten 24 Monate tatsächlich hängen.

Bersins Satz ist nicht ironisch gemeint, sondern beschreibend. Das Versprechen ist real. Die Frage ist nur, ob die Plattformen es einlösen.

2Was die Plattformen versprechen

Die Skills-Tech-Landschaft hat sich seit 2020 in vier Lager geteilt. Jedes Lager verspricht, das Skill-Problem zu lösen, und jedes löst es aus einer anderen Richtung.

Lager eins: die ERP-Aggregatoren

Workday, SAP SuccessFactors und Oracle bauen ihre Skills Clouds auf die bestehende HRIS-Datenbasis. Sie inferieren Skills aus Job-Titeln, Performance-Bewertungen und Trainingshistorie. Vorteil: die Daten liegen ohnehin im System. Nachteil: die Daten beschreiben Vergangenheit, nicht strategische Zukunft. Bersin ordnet sie als „die am wenigsten sophisticated"-Schicht ein, die letztlich zu „Skills-Aggregatoren mit APIs" zwischen spezialisierteren Systemen wird.

Lager zwei: die Recruiting-Plattformen

Eightfold, Beamery, Phenom, Seekout und iCims indexieren Milliarden Worker-Profile von außerhalb des Unternehmens. Sie inferieren Skills durch Zeitreihen-Modelle und neuronale Netze. Vorteil: tiefe Daten über Branchen und Job-Familien. Nachteil: die Inferenz arbeitet rückwärts vom Lebenslauf, nicht vorwärts von der Strategie. Wer „AI-Literacy 2027" sucht, findet hier 2024er-Java-Entwickler.

Lager drei: die Talent-Marketplaces

Gloat, Fuel50 und Hitch konzentrieren sich auf interne Bewegung. Sie matchen Mitarbeitende mit Projekten und Gigs, häufig über Skill-Adjazenzen. Vorteil: nutzbar für Internal-Mobility-Programme. Nachteil: das Modell endet an der Unternehmensgrenze, und das Adjazenz-Modell ist Hilfsmittel, nicht Strategie.

Lager vier: die Learning-Plattformen

Cornerstone, Degreed und EdCast lesen Skills aus Lerninhalten. Sie matchen Lernpfade auf Kompetenzlücken. Vorteil: direkter Bezug zu L&D-Budget. Nachteil: ein Skill wird zur Kursliste reduziert, nicht zur strategischen Position im Unternehmen.

Allen vier Lagern gemeinsam ist eine Datenbank-Logik: je mehr Skills erfasst, desto besser. Lightcast, einer der wichtigsten Daten-Lieferanten der Branche, betreibt eine dynamische Skills-Bibliothek mit „tens to hundreds of thousands of skills", wie Bersin dokumentiert. Workday Skills Cloud, Cornerstone und Beamery arbeiten mit Taxonomien, die in der Praxis schnell achthundert oder mehr Einträge pro Funktion umfassen. Das ist kein Bug, das ist das Modell. Die Annahme dahinter: wenn wir nur lange genug taggen, wird aus Datenmenge Strategie-Klarheit.

Dieser Annahme zu folgen kostet im Mittelstand zwischen 80.000 und 400.000 Euro Jahreslizenz, plus Implementierungs-Aufwand zwischen zwölf und vierundzwanzig Monaten. Die Daten dazu liegen in den nächsten Abschnitten.

3Drei Failure-Modes der 800-Skill-Logik

Die Sevoir Group, eine britische Workforce-Beratung, hat 2025 den vermutlich präzisesten öffentlichen Befund zu gescheiterten Skills-Taxonomien publiziert. Daniel Jurow beschreibt im Beitrag „Why Organizations Fail at Skills Intelligence", warum „skills taxonomy projects frequently fail, leaving expensive platforms running on bad data or sitting unused".¹ Die drei häufigsten Failure-Modes lassen sich klar isolieren.

Failure-Mode 1: die Datenpflege bricht zusammen

Eine Skill-Taxonomie ist kein statisches Dokument. Sie ist ein lebendiges System, das Skills aus Stellenbeschreibungen, Projektplänen, Trainingsunterlagen, Onboarding-Decks, Software-Manualen und LinkedIn-Profilen ziehen muss - dazu aus dem Wissen, das in einzelnen Köpfen sitzt und in Job-Titeln eingedampft ist. Die Sevoir Group beschreibt die Realität: „Where does the information about your roles, tasks, workflows, and competencies live exactly? Not one place, is typically the answer."

In Unternehmen mit mehreren Standorten oder laufender M&A-Integration multipliziert sich der Aufwand mit regionalen, kulturellen und funktionalen Nuancen. In der Praxis bedeutet das: nach achtzehn Monaten Pflege hat das HR-Team entweder das Budget aufgebraucht oder die Daten sind so fragmentarisch, dass die Plattform Vorschläge liefert, die niemand mehr ernst nimmt.

Failure-Mode 2: die Detail-Ebene verfehlt das Ziel

„HR teams are happy to purchase generic skills databases so broad that they do not reflect the company's true team model. Department insiders try to write their own but tend to get so granular they're unusable", schreibt Jurow. Die zwei Wege scheitern aus entgegengesetzten Gründen am gleichen Punkt: keiner trifft die Strategie-Ebene.

HR-Listen sind zu breit, weil sie Skills aus Industrie-Taxonomien einkaufen, die nicht zur tatsächlichen Wertschöpfung des Unternehmens passen. Fachbereich-Listen sind zu eng, weil sie Skills auf Tool-Niveau spezifizieren („Bedienen einer bestimmten Designer-Funktion") statt auf Capability-Niveau („gestalterische Entscheidungskompetenz"). Beide Lager treffen die Ebene nicht, auf der die Vorstandsfrage „welche Skills tragen die Strategie" beantwortbar wäre.

Failure-Mode 3: die Adoption findet nicht statt

Selbst wenn Taxonomie und Plattform technisch laufen, kommt das Datenwerk nur dann zur Wirkung, wenn Manager:innen ihre Teams in der Plattform profilieren und Mitarbeitende ihre Profile pflegen. Die Sevoir Group beschreibt das typische Muster: „Managers don't reference the data because it's incomplete, and they don't end up providing assignment and development opportunities based on the insights. Employees stop updating profiles because no one seems to use them."

Das ist kein Adoption-Problem im engeren Sinn, sondern ein Sinnstiftungs-Problem. Eine Skill-Profilierung, die für niemanden eine Entscheidung verändert, wird als administrative Last erlebt - und nach drei Quartalen still abgeschaltet, ohne dass jemand das Projekt offiziell beendet.

Deloitte liefert die quantitative Bestätigung. In der Studie „The skills-based organization: A new operating model for work and the workforce" sagen 85 Prozent der HR-Executives, sie hätten Bemühungen zur Skill-Taxonomie im Gang. Aber nur zehn Prozent halten ihre Klassifikation für effektiv.² Das ist die Lücke, in der die Plattform-Lizenzen abgeschrieben werden.

4Bersins „sober reality"

Im Juli 2023 publizierte Josh Bersin, einer der einflussreichsten Analysten der HR-Tech-Welt, einen Beitrag mit dem Titel „Building A Skills-Based Organization: The Exciting But Sober Reality". Der Text ist kein Anti-Plattform-Pamphlet. Bersin verkauft im Galileo-Ökosystem selbst Tools, die in diese Richtung gehen. Aber er beschreibt mit ungewöhnlicher Klarheit, woran die meisten Skills-Programme scheitern.

Der Kern seines Arguments betrifft die Definition von Skill selbst. Die meisten Plattformen behandeln Skills wie technische Proficiencies - Programmiersprachen, Toolkenntnisse, Methodenwissen. Aber Bersin zitiert seinen ehemaligen IBM-Manager: „Hard skills are soft - it's the soft skills that are hard." Die Skills, die in einem Unternehmen wirklich tragen, sind oft die, die sich am schwersten taggen lassen: Lernagilität, Urteilskraft, Konflikt-Fähigkeit, kulturelle Anschlussfähigkeit.

Er verweist auf eine Harvard-Studie von Boris Groysburg, die zeigte, dass selbst top-bewertete Investment-Banker beim Wechsel des Arbeitgebers häufig ihren Performance-Vorsprung verlieren. Ihre „skills" waren nie nur technische Skills - sie waren das organisationale Wissen, die Beziehungs-Netzwerke, das Verstehen ungeschriebener Regeln. Eine Skills Cloud, die diese Skills auf ihre technische Hülle reduziert, missversteht das Problem.

Bersins zweiter Befund: Unternehmen, die mit Skills-Taxonomien arbeiten, nehmen typischerweise einen von zwei Wegen. Weg eins - das Skills-Taxonomie-Team baut eine flächendeckende Klassifikation und verhandelt sie mit allen Bereichen aus. Dieser Weg „has many points of failure" und dauert oft so lange, dass die ursprünglichen Annahmen veraltet sind, bevor das Modell live geht. Weg zwei - das Unternehmen identifiziert ein konkretes Geschäftsproblem und baut die Taxonomie um dieses Problem herum. Bersin nennt das „falling in love with the problem" und empfiehlt es ausdrücklich.

Die HIHB-Methode arbeitet seit 2018 nach genau dieser Logik. Wir bauen keine flächendeckende Skill-Karte für ein ganzes Unternehmen. Wir identifizieren in einem Workshop fünf bis acht Skills, an denen ein konkretes Strategie-Vorhaben hängt - eine Schlüsselbesetzung, eine Re-Skilling-Initiative, eine Markt-Erweiterung. Das ist nicht weniger ambitioniert. Es ist die einzig praktikable Reihenfolge.

Bersin endet mit einem Satz, der die ganze Branche zusammenfasst: „We have yet to find a company that uses one platform for everything." Die „Single Skills Cloud" - das Hauptverkaufsargument der ERP-Welt - ist nach fünf Jahren Marktreife eine Hypothese geblieben, kein dokumentierter Zustand.

5Was die Critical-Few-Logik stattdessen leistet

Critical Few ist kein Marketing-Begriff. Es ist eine methodische Position, die sich aus 200+ HIHB-Mandaten verdichtet hat und die im HIHB Horizon-Workshop systematisch hergeleitet wird. Die Logik unterscheidet sich von der 800-Skill-Datenbank an drei Stellen.

Erstens: Reduktion vor Erfassung

Die Plattform-Logik beginnt mit Erfassung - so viele Skills wie möglich taggen, dann sortieren. Die Critical-Few-Logik beginnt mit Reduktion: welche Strategie-Ziele liegen in den nächsten 24 Monaten auf dem Tisch, und welche Faähigkeit entscheidet, ob das Unternehmen sie liefert? Die Frage zwingt Vorstand und Bereichsleitung in eine Trade-off-Diskussion, bevor irgendein Tag in einer Datenbank landet. Das ist unangenehm, aber methodisch entscheidend - die Diskussion findet ohnehin statt, die Frage ist nur, ob vor oder nach dem sechsstelligen Lizenz-Invest.

Zweitens: Verhaltensanker statt Skill-Label

Ein Skill in einer Datenbank ist ein String. „Strategische Entscheidungs-Fähigkeit" steht im Eintrag, und die Plattform inferiert anhand vergangener Job-Titel, wer ihn besitzt. Das HIHB-Vorgehen löst denselben Skill in beobachtbares Verhalten auf: Wie verhält sich jemand mit dieser Fähigkeit in einer Trade-off-Situation, in einem Stakeholder-Konflikt, in einer Entscheidung unter Unsicherheit? Der Verhaltensanker ist das, was sich in einem Interview prüfen, in einem 90-Tage-Plan messen und in einer Performance-Review bewerten lässt. Der String ist es nicht. Der nachfolgende Edition-VIII-Artikel zur Verhaltensanker-Methodik vertieft diese Mechanik.

Drittens: Strategie-Kopplung statt Datenbank-Konsistenz

Eine 800-Skill-Datenbank ist auf interne Konsistenz optimiert - jeder Skill hat eine Definition, eine Adjazenz, eine Lerneinheit. Die Critical-Few-Methode ist auf strategische Kopplung optimiert - jeder der fünf bis acht Skills hängt direkt an einem Strategie-Ziel, das Vorstand und Bereichsleitung explizit benannt haben. Wenn das Strategie-Ziel sich verschiebt, verschiebt sich der Skill. Diese Kopplung kann eine Datenbank nicht leisten, weil sie nichts von Strategie weiß. Sie kann nur Skills katalogisieren.

In der HIHB-Praxis sieht das so aus: Ein mittelständischer Maschinenbauer plant für 2027 den Einstieg in das Geschäft mit datengestützten Services. Drei Strategie-Ziele liegen auf dem Tisch - Cloud-Plattform aufbauen, Pricing-Modell für SaaS entwickeln, Vertriebsmannschaft auf Lösungs-Verkauf umstellen. Aus den drei Zielen werden in einem zweitägigen Workshop sieben Critical-Few-Skills isoliert: Solution-Engineering, Pricing-Architektur, Data-Product-Management, Trade-off-Communication, Cloud-Operations, Lösungs-Selling, kulturelle Anschluss-Übersetzung. Keine 800. Keine 80. Sieben. Jeder mit einem Verhaltensanker, jeder mit einer Build/Buy/Hire-Entscheidung, jeder mit einer benannten Tier-1- und Tier-2-Nachbarschaft im eigenen Haus.

Das Ergebnis ist nicht eine Plattform-Datei, sondern eine Strategie-Entscheidung. Sie passt auf eine Seite und überlebt die nächste Vorstandsklausur, weil sie nicht aus einem Modell stammt, sondern aus einer Diskussion mit denen, die die Strategie verantworten.

Die Critical-Few-Logik ist methodisch verwandt mit der 5C-Methode des HIHB-Pre-Recruitings, die HIHB seit 2018 in über 200 Mandaten anwendet. In beiden Fällen geht es um die methodische Reduktion auf das, was die Entscheidung wirklich trägt - bei 5C die Schlüsselbesetzung, bei Critical Few die Skill-Strategie. Beide Verfahren sind die Antwort auf dieselbe Beobachtung: wer am Anfang vollständig sein will, ist am Ende nicht entscheidungsfähig.

6Entscheidung im Mittelstand: kaufen oder designen?

Für CHROs und Geschäftsführungen im Mittelstand stellt sich die Frage in der Praxis selten als „Plattform oder nicht". Sie stellt sich als Reihenfolge-Frage: Welcher Schritt kommt zuerst, und welcher folgt - wenn überhaupt?

Drei Szenarien zeigen, wie die Reihenfolge typischerweise auseinanderläuft.

Szenario eins: erst Plattform, dann Frage

Ein 600-Mitarbeitende-Unternehmen unterschreibt nach einer überzeugenden Demo eine Skills-Cloud-Lizenz. Implementierung dauert vierzehn Monate. Nach Abschluss liegen 4.200 Skills im System. Die Vorstandsfrage „welche tragen unsere Strategie" wird nicht beantwortet, weil die Plattform sie nicht stellt. Nach weiteren zwölf Monaten wird das HR-Team die Plattform „nicht aktiv pflegen" - höflicher Code für Adoption-Tod. Das Budget ist abgeschrieben, die Lizenz läuft.

Dies ist nach der Sevoir-Group-Beobachtung das häufigste Muster. „Skills taxonomy projects frequently fail, leaving expensive platforms running on bad data or sitting unused."

Szenario zwei: erst Frage, dann gegebenenfalls Plattform

Dasselbe Unternehmen führt vor dem Plattform-Entscheid einen Horizon-Workshop durch. In zwei Tagen werden sechs Critical-Few-Skills isoliert, mit Verhaltensankern beschrieben, gegen die nächsten 24 Monate Strategie gekoppelt. Die HR-Direktorin geht in das nächste Plattform-Gespräch mit einer klaren Frage: „Was kann Ihre Plattform für diese sechs Skills leisten - mit welcher Datenbasis, welcher Inferenz-Logik, welcher Pflegelast?" Das Gespräch wird nicht von der Plattform geführt, sondern vom Unternehmen. Häufiges Ergebnis: die Plattform wird kleiner gekauft als angeboten, oder gar nicht.

Szenario drei: Critical Few statt Plattform

Für viele mittelständische Unternehmen ist eine Skills-Cloud schlicht überdimensioniert. Sechs Critical-Few-Skills mit Verhaltensankern, Nachbarschafts-Karte und Build/Buy/Hire-Entscheidung leisten genug, um die Strategie der nächsten 24 Monate methodisch zu unterlegen. Eine sechsstellige Lizenz löst kein Problem, das ohne sie nicht lösbar wäre - sie addiert nur Komplexität und Pflegelast. Die Plattform-Entscheidung verschiebt sich um zwei oder drei Jahre nach hinten, mit klarerem Bild, was sie eigentlich leisten soll.

Die Reihenfolge ist die eigentliche Pointe. Wer die Strategie-Frage vor der Plattform-Frage beantwortet, kauft anders. Wer die Plattform vor der Strategie kauft, hat die Strategie-Frage am Ende immer noch offen.

Diese Logik ist nicht plattform-feindlich. Sie ist nur unbestechlich gegenüber der Annahme, dass Datenbankgröße strategische Klarheit ersetzt. Die grundlegende Skepsis gegenüber Plattform-Verheissungen im Recruiting hat sich in den letzten drei Jahren auch in der Skill-Welt etabliert - die Argumentations-Linien decken sich weitgehend mit dem HIHB-versus-AI-Recruiting-Vergleich und der Beobachtung, dass skill-based hiring ohne strategische Verankerung dieselben Failure-Modes produziert wie eine 800-Skill-Datenbank. Wir lesen die Bewegung als methodische Reifung, nicht als Anti-Tech-Reflex.

7Was als Nächstes zu tun ist

Wenn auf Ihrem Tisch gerade ein Skills-Cloud-Angebot liegt - Workday, Cornerstone, Beamery, Eightfold, Gloat oder Lightcast - lohnen sich drei Schritte, bevor die Unterschrift unter die Lizenz geht.

Schritt 1: die Vorstandsfrage explizit machen

Setzen Sie eine Stunde mit der Geschäftsführung an und fragen Sie schriftlich: „Welche fünf bis acht Faähigkeiten tragen unsere Strategie in den nächsten 24 Monaten?" Die Antwort wird unscharf sein. Das ist nicht das Problem - das ist der Beleg. Eine Plattform, die diese Frage nicht beantwortet, ist nicht die Antwort.

Schritt 2: drei Strategie-Ziele auf den Tisch

Notieren Sie die drei Strategie-Ziele, an denen Ihr Unternehmen in den nächsten 24 Monaten gemessen wird. Pro Ziel: welche Fähigkeit entscheidet, ob Sie liefern? Das ist die Long-List, aus der die Critical Few entstehen. Wenn die Liste länger als zwanzig Skills wird, ist sie nicht reif für die Plattform-Frage. Sie ist reif für eine methodische Reduktion - intern moderiert oder im Horizon-Workshop.

Schritt 3: Plattform-Demo gegen Critical Few prüfen

Wenn die Critical Few stehen, gehen Sie mit ihnen in die nächste Plattform-Demo. Stellen Sie nicht die Vendor-Frage „was kann Ihre Plattform alles". Stellen Sie die Käufer-Frage: „Was leistet Ihre Plattform für diese sechs Skills - in welcher Datenbasis, mit welcher Pflegelast, mit welcher Adoption-Mechanik?" Sie werden präzisere Antworten bekommen, kleinere Konfigurationen sehen und ehrlichere Preise erhalten. Häufig auch: die Erkenntnis, dass die Plattform für diesen Zweck überdimensioniert ist.

Die Critical-Few-Logik ist kein Anti-Plattform-Argument. Sie ist ein Reihenfolge-Argument. Bersin sagt es so: „This work is part of a bigger shift, away from rigidly defined jobs to roles focused on work. It's ok to take the time to do this carefully. It's ok to set up governance, experiment with different tools, and fall in love with the problem one step at a time."

Achthundert Skills sind kein Strategie-Inventar. Sie sind ein Datenpflege-Auftrag. Strategie sind die fünf bis acht, an denen die nächsten 24 Monate hängen.

Michael von Hirschfeld

Co-Geschäftsführer HireWorks GmbH · HIHB-Workshop-Moderator · 200+ Mandate · Pre-Recruiting-Pionier

Verantwortet die HIHB-Methodik bei HireWorks. Moderiert seit 2018 Workshops mit Gründer:innen, Geschäftsführungen, Recruiting und Hiring-Manager:innen im DACH-Mittelstand, in Konzernen und Start-ups. Entwickelt mit HIHB Horizon die Skill-Architektur-Methode für strategische Capability-Entscheidungen.