ES
Red modular de tuberías armada sobre una bandeja con piezas clasificadas por tipo.

Una lista de skills no es una arquitectura

Un catálogo responde qué skills existen y cómo encontrarlas. Una arquitectura añade las relaciones necesarias para interpretar expectativas, evaluar evidencia, orientar desarrollo y reconocer rutas entre roles.

PRYSMAP5 min de lectura

La diferencia no depende del tamaño. Una organización puede mantener cientos de términos bien definidos y seguir sin saber qué significan dentro de un rol. También puede comenzar con pocas skills y construir relaciones suficientes para sostener decisiones reales.

Lo que una lista hace bien

Los catálogos resuelven problemas concretos. Reducen sinónimos, asignan identificadores, agrupan conceptos y facilitan búsquedas. Sin esa base, cada área termina nombrando capacidades semejantes de formas distintas.

ESCO, la clasificación europea de skills y ocupaciones, se presenta como un diccionario multilingüe. Sus conceptos tienen términos, descripciones y relaciones que permiten utilizarlos en servicios de empleo, formación y análisis. Su utilidad pública muestra dos capas diferentes: clasificar entidades y conectarlas para que otras decisiones sean posibles. Comisión Europea, “What is ESCO?”

Una empresa no necesita copiar esa escala. Sí necesita reconocer el límite de una fila aislada. El nombre “gestión de riesgos” puede estar correctamente definido y categorizado. Todavía no indica qué profundidad requiere un rol, qué evidencia demostraría dominio ni cuánto de esa capacidad podría reutilizarse en otro contexto.

Dos modelos que parecen similares desde lejos

En el modelo de inventario, cada skill ocupa una fila. Puede tener descripción, categoría y etiquetas. Cuando aparece un nuevo rol, la respuesta habitual consiste en asignarle un conjunto de filas. Si se necesita mayor precisión, se crean variantes: gestión de riesgos junior, senior, estratégica o especializada.

Ese camino parece directo. También fragmenta con facilidad una misma capacidad. Las diferencias propias del trabajo quedan escondidas dentro de nombres nuevos. Comparar roles se vuelve difícil porque una progresión termina representada como si fueran skills independientes.

El modelo relacional conserva un conjunto común cuando corresponde y sitúa las diferencias en otro lugar. Conecta la skill con niveles, manifestaciones observables, tracks, roles, expectativas y evidencia. Las preguntas cambian:

  • ¿Qué se mantiene igual entre dos roles?
  • ¿Qué nivel, autonomía o alcance exige cada uno?
  • ¿Qué observaciones permiten sostener esa diferencia?
  • ¿Qué relación habilita una decisión de desarrollo o movilidad?

El nivel adquiere sentido dentro de una relación

SFIA combina skills profesionales con siete niveles de responsabilidad. Sus niveles describen cambios en responsabilidad, rendición de cuentas e impacto, y sirven como base para mapear estructuras y trayectorias. El marco insiste en que la competencia se demuestra en situaciones reales de trabajo, no solo mediante conocimiento teórico. SFIA, “How SFIA works”

El ejemplo no debe convertirse en una regla universal. SFIA nació en ámbitos digitales y utiliza su propia arquitectura. Su aporte para esta discusión está en mostrar que el nivel no es un adjetivo añadido al nombre de la skill. Es una relación con el tipo de responsabilidad ejercida.

Dentro de un track, varios roles pueden compartir exactamente las mismas skills. Sus diferencias aparecen en la profundidad, autonomía, complejidad, alcance, liderazgo, impacto y evidencia esperada. Así se evita crear un catálogo distinto para cada cargo y se conserva una trayectoria comprensible.

Fuera del track, la arquitectura necesita otra clase de relación. Algunas skills serán compartidas; otras, nuevas. Entre ambas existe una zona menos cómoda: capacidades demostradas que requieren adaptación antes de trasladarse a otro contexto. Una lista suele mostrar coincidencia. La arquitectura debe representar también la distancia.

Las relaciones contienen supuestos

Conectar una skill con un rol no demuestra que la persona la domine. Vincularla con una categoría tampoco explica cómo evaluarla. Asignar un nivel esperado no prescribe un plan de desarrollo.

Cada relación responde una pregunta y deja otras abiertas. La categoría mejora navegación. El nivel distingue grados de desempeño. La expectativa sitúa ese grado dentro de una contribución. La evidencia sostiene una conclusión sobre una persona. La transferibilidad estima qué podría conservarse al cambiar de contexto. Cuando el modelo confunde esas funciones, las decisiones heredan el error. Un sistema puede inferir una brecha porque faltó evidencia. Puede recomendar formación cuando el límite real era falta de autoridad. Puede declarar a dos roles “cercanos” porque comparten palabras, aunque las condiciones de aplicación sean incompatibles.

La arquitectura no elimina esos riesgos. Los vuelve visibles y asigna un lugar donde discutirlos.

Pista modular de madera que forma un circuito con desvíos y un puente, con un vagón sobre un tramo.

Retirar una relación permite probar su utilidad

Hay una forma práctica de examinar una arquitectura: retirar mentalmente cada conexión y observar qué decisión deja de sostenerse.

Sin categorías, el mantenimiento y la navegación se degradan. Sin manifestaciones observables, la skill conserva nombre, pero pierde un objeto evaluable. Sin niveles, resulta difícil distinguir progresión. Sin expectativas por rol, un score queda sin referencia. Sin evidencia, el dominio se convierte en una afirmación. Sin relaciones entre roles y tracks, movilidad y sucesión dependen de semejanzas superficiales.

La prueba también evita construir complejidad innecesaria. Una relación merece mantenerse cuando aclara una interpretación, evita una inconsistencia o sostiene una decisión relevante. Si nadie puede explicar qué cambia al retirarla, quizá el modelo solo esté acumulando estructura.

Una arquitectura útil no es la que contiene más nodos y conexiones. Es la que permite recorrer, sin saltos ocultos, desde una definición hasta una decisión. Mantener esa utilidad exige distinguir qué señales justifican una corrección y cuáles una revisión estructural.

  4. Portada de Sorting Things Out sobre una mesa de madera, junto a una pequeña caja de papel.

    Sorting Things Out: toda taxonomía describe y también decide

    El libro Sorting Things Out examina cómo categorías y estándares organizan el mundo mientras distribuyen visibilidad, trabajo y consecuencias. Leerlo desde una arquitectura de skills amplía la pregunta hacia las decisiones que una taxonomía hace posibles.