Dejen de pedirme que vuelva a escribir mi CV

Del CV como documento al CV como dato

Actualmente estoy buscando activamente mi próximo reto profesional.

Eso significa que cada semana dedico una cantidad importante de tiempo a leer ofertas, adaptar mi CV, preparar cartas de motivación, completar formularios y tratar de entender cómo quiere cada empresa recibir mi información profesional.

Y hay algo que no puedo dejar de observar.

Muchas empresas me piden que suba mi CV y, justo después, me obligan a volver a introducir manualmente la misma información: cargos, empresas, fechas, ubicaciones, formación, certificaciones, idiomas y, en algunos casos, incluso responsabilidades.

Como persona profundamente orientada a la eficiencia, la excelencia operativa y la mejora de procesos, me cuesta mucho ignorarlo.

No solo porque sea molesto.

Sino porque es desperdicio.

Es retrabajo.

Es sobreprocesamiento.

Es mala fluidez del proceso.

Es una transferencia deficiente entre un documento pensado para humanos y un sistema que necesita datos estructurados.

Y una vez que lo ves, ya no puedes dejar de verlo.

El problema del CV no es realmente el CV

La mayoría de empresas no quieren solo un CV.

Quieren datos estructurados.

Quieren saber quién es el candidato, qué roles ha desempeñado, en qué empresas, durante qué periodos, en qué ubicaciones, con qué competencias, certificaciones y logros relevantes.

Pero en lugar de pedir datos profesionales estructurados, normalmente piden un PDF o un documento Word.

Después, un ATS o un parser de CV intenta transformar ese documento en campos de base de datos.

A veces funciona.

Muchas veces, no.

Y esto no debería sorprender a nadie. Un CV suele estar diseñado como un documento visual para personas. Un ATS necesita información estructurada para máquinas. El problema aparece precisamente en la brecha entre esos dos mundos.

Además, el mercado ya conoce la dirección. JSON Resume, por ejemplo, se define como una iniciativa open-source para crear un estándar de CV basado en JSON. Europass también promueve la interoperabilidad del perfil para que los usuarios puedan almacenar información e importarla a otras plataformas, y viceversa.

Por tanto, el problema no es que estructurar la información profesional sea imposible.

El problema es que el proceso de selección sigue empujando demasiada corrección manual hacia el candidato.

El coste oculto de un mal proceso de candidatura

Cuando aplicas a una oferta de vez en cuando, este problema parece una pequeña molestia.

Cuando estás en búsqueda activa, se convierte en un proceso repetido.

Y toda fricción repetida merece ser medida.

Usemos un ejemplo conservador.

Esto no pretende ser un modelo científico.

Es una forma sencilla de hacer visible el desperdicio.

Y el coste real probablemente sea mayor: abandono de candidatos, frustración del recruiter, retrasos en el shortlisting, mal matching, comunicación duplicada, problemas de calidad de datos y daño a la marca empleadora ni siquiera están incluidos.

Desde una perspectiva de Operational Excellence, esto no es un pequeño problema de UX.

Es un problema de diseño de proceso.

¿Por qué ocurre?

Hay varias causas raíz.

Primero, el CV se ha tratado históricamente como un documento, no como un producto de datos.

Segundo, cada ATS tiene sus propios formularios, campos, reglas y lógica de parsing.

Tercero, los candidatos optimizan sus CVs para narrativa, legibilidad y presentación, mientras que los sistemas necesitan consistencia, etiquetas, fechas, jerarquía y claridad semántica.

Cuarto, no existe un estándar ampliamente adoptado y controlado por el candidato que permita mantener un único perfil profesional estructurado y reutilizarlo de forma fiable entre plataformas.

Y quinto, la carga de la corrección se traslada al candidato.

La empresa compra el sistema.

El sistema no extrae correctamente la información.

El candidato paga el coste en tiempo.

Eso no es buena propiedad del proceso.

El atajo de LinkedIn ayuda, pero no es la respuesta

Algunas empresas intentan reducir esta fricción permitiendo aplicar con LinkedIn o rellenar parcialmente formularios usando el perfil de LinkedIn.

Es un paso en la dirección correcta.

LinkedIn explica que Apply with LinkedIn usa datos del perfil para pre-rellenar partes del formulario de candidatura, sin compartir el perfil completo con el empleador. LinkedIn Apply también puede alojar la experiencia de candidatura dentro de LinkedIn y enviar los datos al ATS de la empresa.

Eso es mejor que empezar desde cero cada vez.

Pero sigue sin resolver el problema de fondo.

Porque LinkedIn no es mi CV.

LinkedIn es una representación de mi perfil profesional dentro de una plataforma privada.

Es útil. Es visible. Es comercialmente poderosa.

Pero no es un estándar neutral de datos profesionales propiedad del candidato.

Y eso importa.

Si los procesos de selección dependen de LinkedIn como puente principal de datos, el candidato sigue sin tener control total sobre su información profesional. La dependencia simplemente se desplaza desde el parser del ATS hacia otra plataforma de terceros.

Hoy la integración puede funcionar.

Hoy puede parecer gratuita para el candidato.

Hoy puede pre-rellenar suficientes campos para reducir parte del dolor.

Pero ¿qué ocurre mañana si cambian las condiciones de acceso, se restringen permisos de API, se modifican integraciones o un candidato no quiere depender de una única red profesional para representar su carrera?

Los propios términos de API de LinkedIn hacen referencia a límites de llamadas y señalan que una aplicación no debería depender del acceso a las APIs de LinkedIn como aspecto fundamental de su negocio.

Eso basta para dejar clara una idea:

LinkedIn puede ser un canal de entrada.

No debería ser la fuente de verdad.

No necesitamos partir de cero

Ya existen piezas serias del puzzle.

HR Open Standards ha trabajado en el intercambio de datos de CV y resumé para comunicar formación, experiencia laboral, licencias, certificaciones y otras experiencias relevantes entre sistemas de selección.

JSON Resume ofrece una estructura práctica de CV basada en JSON.

Europass apoya la interoperabilidad de perfiles, CVs, oportunidades y cualificaciones.

ESCO funciona como un diccionario que identifica y clasifica ocupaciones y competencias relevantes para el mercado laboral europeo, haciendo que esos conceptos puedan ser entendidos por sistemas electrónicos.

Por tanto, la propuesta no consiste en inventar una fantasía desde cero.

La propuesta consiste en conectar las piezas.

Del CV como documento al CV como dato

Lo que me gustaría ver es conceptualmente sencillo:

Un candidato debería ser propietario de un único perfil profesional estructurado.

Desde esa fuente, debería poder generar:

• Un PDF legible para humanos.
• Un DOCX amigable para ATS.
• Una versión JSON Resume.
• Una versión compatible con Europass.
• Un resumen preparado para LinkedIn.
• Un perfil ejecutivo para recruiters.
• Un paquete machine-readable para sistemas ATS.

Una única fuente de verdad.

Múltiples salidas.

Sin entrada manual repetida.

Sin retrabajo innecesario.

Sin tener que confiar en que el parser entienda que “Smart Factory and Innovation Leader” era un cargo y no una habilidad.

Un ejemplo práctico: mi propio CV como dato estructurado

En lugar de obligar a un parser a adivinar mi perfil desde un PDF maquetado, mi información profesional podría expresarse así:

candidate:
  name: "Francisco Requena"
  headline: "Operational Excellence, Asset Management and Smart Factory Leader"
  location:
    country: "Spain"
    region: "Barcelona area"
  professional_summary: >
    Industrial transformation leader with extensive experience in operational excellence,
    Lean Manufacturing, Smart Factory, maintenance, asset management, process improvement,
    data-driven decision-making and AI applied to industrial environments.
  target_roles:
    - "Operational Excellence Director"
    - "Maintenance and Reliability Director"
    - "Asset Management Manager"
    - "Industrial Transformation Leader"

Esto ya es más claro que una cabecera decorativa.

Le dice a la máquina qué significa cada campo.

La misma lógica puede aplicarse a la experiencia profesional:

experience:
  - company: "SEAT / Volkswagen Group"
    role: "Smart Factory and Innovation Leader"
    location: "Barcelona, Spain"
    sector: "Automotive manufacturing"
    scope:
      - "Industrial innovation"
      - "Smart Factory"
      - "Operational excellence"
      - "Cross-functional transformation"
    responsibilities:
      - "Led digital transformation and innovation initiatives across industrial areas."
      - "Created and governed an innovation funnel involving production, quality, IT, controlling, purchasing, legal and HR."
      - "Connected internal industrial needs with startups, universities and technology partners."
    achievements:
      - "Helped position the factory as a reference in digital industrial innovation."
      - "Established governance mechanisms between business, IT and controlling."
      - "Promoted internal innovation through hackathons, open innovation initiatives and internal knowledge-sharing events."
    skills:
      - "Lean Manufacturing"
      - "Smart Factory"
      - "Digital Transformation"
      - "Innovation Management"
      - "Stakeholder Management"
      - "Industrial Data"

Esto no solo es más fácil para un ATS.

También es más claro para un recruiter.

Y permite que el candidato demuestre valor sin depender de trucos de formato.

Las certificaciones podrían seguir la misma lógica:

certifications:
  - name: "Project Management Professional"
    abbreviation: "PMP"
    issuer: "Project Management Institute"
  - name: "Certified Maintenance & Reliability Professional"
    abbreviation: "CMRP"
    issuer: "SMRP"
  - name: "IAM Diploma"
    issuer: "Institute of Asset Management"
    distinction: true
  - name: "Lean Six Sigma Black Belt"
  - name: "Certified Business Process Associate"
    abbreviation: "CBPA"
  - name: "Certified Supply Chain Professional"
    abbreviation: "CSCP"

Un parser no debería tener que inferir todo esto desde un icono, una insignia, una maquetación a dos columnas o un PDF visualmente atractivo.

El dato debería estar ya estructurado.

La capa que falta: un estándar de CV para humanos y máquinas

La solución no es prohibir los CVs bonitos.

La solución es separar contenido y presentación.

Primero, datos profesionales.

Después, diseño del documento.

Un estándar profesional de CV-as-data debería incluir, al menos:

standard_sections:
  - identity
  - contact
  - professional_summary
  - target_roles
  - work_experience
  - projects
  - education
  - certifications
  - skills
  - languages
  - publications
  - preferences
  - work_authorisation
  - mobility

Cada sección debería tener campos estables, etiquetas controladas y formatos de fecha consistentes.

Las habilidades no deberían ser solo una lista de palabras de moda.

Deberían conectarse con evidencias:

skills:
  - name: "Lean Manufacturing"
    category: "Operational Excellence"
    evidence:
      - "Applied Lean and production-system principles in automotive and naval environments."
      - "Led operational transformation initiatives involving production, quality and maintenance."
  - name: "Asset Management"
    category: "Maintenance and Reliability"
    evidence:
      - "IAM Diploma with Distinction."
      - "CMRP certification."
      - "Experience connecting maintenance, reliability, lifecycle decisions and business performance."
  - name: "AI applied to operations"
    category: "Industrial Intelligence"
    evidence:
      - "Postgraduate training in AI and Data Science with Python."
      - "Applied AI concepts to process improvement, decision support and industrial use cases."

Esto permitiría un matching mucho mejor que simplemente buscar “Lean”, “AI” o “maintenance”.

Qué ganarían las empresas

Esto no solo sería bueno para los candidatos.

También sería bueno para las empresas.

Un estándar estructurado de CV reduciría:

• Entrada manual de datos.
• Errores de parsing.
• Frustración del candidato.
• Candidaturas incompletas.
• Tiempo de corrección del recruiter.
• Mal matching causado por mala calidad de datos.
• Ruido en las bases de talento.
• Pérdida de buenos candidatos que abandonan formularios deficientes.

También mejoraría:

• Experiencia del candidato.
• Calidad de los datos.
• Capacidad de búsqueda.
• Comparación interna entre perfiles.
• Skills-based hiring.
• Auditabilidad.
• Interoperabilidad entre plataformas.

Para los recruiters, el beneficio no es automatización por automatización.

El beneficio es input data más limpio.

Y una buena calidad de datos es la base de cualquier proceso digital serio.

Una propuesta concreta

Las plataformas de selección deberían permitir a los candidatos subir no solo un documento CV, sino también un archivo estructurado de datos profesionales.

Algo como:

cv.yaml
cv.json
jsonresume.json
europass-compatible-profile.json

La plataforma podría entonces:

1. Leer directamente el archivo estructurado.
2. Mostrar una vista previa al candidato.
3. Preguntar solo la información que falte o que sea específica de la empresa.
4. Conservar el CV original para revisión humana.
5. Guardar datos profesionales estructurados sin obligar a duplicar manualmente la entrada.

El candidato mantendría el control de la información.

El recruiter recibiría datos más limpios.

El ATS dejaría de fingir que cualquier PDF bonito es una base de datos fiable.

Y la empresa eliminaría desperdicio desde la primera interacción con el talento.

Reflexión final

Cuando una empresa me pide mi CV y después me obliga a volver a escribir el mismo CV, no veo solo un proceso de candidatura frustrante.

Veo una oportunidad de mejora de proceso.

Quizá sea mi sesgo profesional.

Pero también es mi Kaizen personal.

Buscar trabajo no es solo una transición profesional.

También es una exposición diaria a cómo las empresas diseñan procesos, gestionan datos, tratan a los usuarios y administran desperdicio.

Si somos capaces de construir fábricas digitales, sistemas de mantenimiento predictivo, soluciones de decisión asistida por IA, plataformas de process mining y workflows automatizados, también deberíamos ser capaces de resolver algo tan básico como esto:

La historia profesional de una persona debería escribirse una vez, pertenecer al candidato, ser legible para humanos y reutilizable por máquinas.

Ese sería un mejor proceso de selección.

Y, francamente, uno mucho más respetuoso.

#Recruitment #CandidateExperience #OperationalExcellence #Lean #ProcessImprovement #HRTech #ATS #DigitalTransformation #CV #DataQuality