Zum Inhalt springen

Kompetenzen

Abhängigkeiten · Data Nodes

  • Bezüge zu: Bedarfe (über REQUIRES), Personen (über HAS_COMPETENCE), Wertschöpfung (über ASSESSED_IN), Rollen (über REQUIRES)
  • Wird bezogen von: KI Agenten (über AGENT_USES_COMPETENCE)

Kompetenzen modellieren Fähigkeiten in der Organisation: Was kann jemand? Was erfordert eine Rolle? Wo wird eine Kompetenz bewertet?

Kompetenzen haben eine Kategorie (Technical, Leadership, Social, Methodical, Domain) und ein Level von Novice bis Expert. Kompetenzen können hierarchisch zerlegt werden — z.B. „Programmierung” umfasst „Python”, „JavaScript”, „SQL”. Personen besitzen Kompetenzen, Rollen fordern sie, Wertströme bewerten sie.

Cards mit Kategorie- und Level-Badges. Filter nach Kategorie, Level, Ausstellender Organisation und Gültigkeit.

Listenansicht

Kompetenzen haben das umfangreichste Beziehungsnetz aller Entitätstypen — vier dedizierte Required-RelTypes:

  • REQUIRES (Rolle → Kompetenz) — „erfordert” / „wird erfordert von”
  • HAS_COMPETENCE (Person → Kompetenz) — „besitzt Kompetenz” / „ist Kompetenz von”
  • PART_OF (Kompetenz → Kompetenz) — „ist Teil von” / „umfasst” (Hierarchie)
  • ASSESSED_IN (Kompetenz → Wertstrom) — „wird bewertet in” / „bewertet”

Details: Beziehungstypen.

{
"type": "object",
"properties": {
"category": {
"type": "string",
"title": "Kategorie",
"enum": ["Technical", "Leadership", "Social", "Methodical", "Domain"]
},
"level": {
"type": "string",
"title": "Level",
"enum": ["Novice", "Beginner", "Intermediate", "Advanced", "Expert"]
},
"certificationBody": { "type": "string", "title": "Ausstellende Organisation" },
"validUntil": { "type": "string", "title": "Gültig bis", "format": "date" },
"description": { "type": "string", "title": "Beschreibung" },
"tags": { "type": "array", "items": { "type": "string" }, "title": "Tags" }
}
}

Erweiterungs-Ideen: proficiencyEvidence (Belege), lastAssessed, renewalCycle. Details: JSON-Schema für Entitätstypen.

Die Stufe lebt an der Kante — und die Skala gehört dem Mandanten

Abschnitt betitelt „Die Stufe lebt an der Kante — und die Skala gehört dem Mandanten“

Welche Stufe jemand hat, steht nicht an der Kompetenz, sondern an der Beziehung zwischen Mitglied und Kompetenz (hat Kompetenz, beim KI-Agenten nutzt Kompetenz) — und ebenso an der Beziehung, mit der ein Bedarf sie fordert. Dieselbe Kompetenz kann so von zehn Menschen auf zehn verschiedenen Stufen getragen werden, ohne dass die Kompetenz selbst zehnmal existiert.

Die Skala ist mandanteneigen und beliebig lang: drei Stufen, fünf, zehn, benannt oder nummeriert. Sie steht als Auswahlliste am Beziehungstyp und wird unter Beziehungstypen gepflegt. Verglichen wird rein über die Position in dieser Liste.

Die Reihenfolge zu ändern heißt, die Bedeutung zu ändern. Wer das Enum umsortiert, ändert rückwirkend jede Deckungsaussage im Mandanten — es gibt keinen Verlauf, der den alten Stand bewahrt. Umbenennen ist abgesichert, Umsortieren nicht.

Zwei Regeln, die stille Fehler verhindern:

  • Eine Skala für alle drei Beziehungstypen. Fordern und Haben müssen dieselbe Liste verwenden — sonst würden Positionen aus verschiedenen Skalen verglichen, und das Ergebnis wäre plausibel und falsch.
  • Ein unbekannter Wert heißt „nicht vergleichbar”, nie „niedrigste Stufe”. Sonst erfände die Auswertung eine Aussage.

Im Reports-Tab zeigt eine Karte, wie oft diese Kompetenz in offenen Bedarfen gefordert wird und wie viele Mitglieder sie auf mindestens dieser Stufe haben — der Skill-Gap in einer Karte.

  • Kategorie- und Level-Badge
  • Tags als Chip-Liste
  • Gültigkeitsdatum — das Feld Gültig bis ist ab Werk als Termin gekennzeichnet und erinnert rechtzeitig an die Re-Zertifizierung
  • Personen mit dieser Kompetenz (HAS_COMPETENCE rückwärts)
  • Rollen, die sie fordern (REQUIRES rückwärts)
  • Übergeordnete und untergeordnete Kompetenzen (PART_OF)
  • Bewertungs-Prozesse (ASSESSED_IN)

Detailansicht