Compras

Compatible no es lo mismo que certificado

Trate la compatibilidad de aplicaciones, la certificación formal y el cumplimiento normativo como evidencias separadas.

Un escritorio con documentos y una calculadora durante la revisión de compras
Foto: Unsplash

Tres preguntas distintas

La compatibilidad pregunta si un dispositivo funciona en una configuración definida. La certificación pregunta si superó un programa del proveedor. El cumplimiento pregunta si cumple los requisitos de acceso al mercado. Ninguna etiqueta sustituye a otra.

Para compras, la pregunta útil es más concreta: qué configuración exacta se probó, por quién, en qué fecha y contra qué versión de software.

Cómo es la evidencia de compatibilidad

La evidencia de compatibilidad es un registro de configuración, no un logo. Debe identificar la revisión del producto, el SO y build, la aplicación y versión, el método de conexión y el firmware probado.

Cuando cambia cualquier elemento, la evidencia queda técnicamente obsoleta. Una configuración probada el año pasado en un SO anterior sigue informando, pero debe revalidarse antes de depender de ella a escala.

  • Producto y revisión de hardware exactos
  • Sistema operativo y build
  • Aplicación de reuniones y versión
  • Método de conexión y cable
  • Versión de firmware y fecha de prueba

Qué exige realmente la certificación

La certificación la otorga un programa del proveedor o normativo y suele constar en un listado, certificado o carta. El propietario del programa, los productos cubiertos y la vigencia forman parte de la evidencia.

Expresiones como certified-ready, certificación pendiente o certified-compatible son estados, no certificación. Si su revisión no figura en el listado, el certificado no la cubre.

El cumplimiento normativo depende del mercado

El cumplimiento depende del mercado objetivo: funciones de radio, alimentación, CEM, embalaje y etiquetado. Un dispositivo conforme en un mercado puede no serlo en otro.

Pida el certificado o declaración que nombre al fabricante legal, el modelo exacto, los mercados cubiertos y la vigencia. Una evidencia regional no se generaliza desde una región asociada.

Pida la cadena de evidencia

Solicite la misma evidencia a cada proveedor para comparar respuestas. Consérvela con el expediente de compra, porque la necesitará en la instalación y en auditorías.

  • Sistemas y versiones de aplicación probados
  • Método de conexión y revisión de hardware
  • Referencia de listado o informe y su propietario
  • Países y configuraciones cubiertos
  • Fechas de prueba y revisión

Mantenga un registro de evidencia vivo

Los equipos de compras deben llevar un registro breve por modelo: afirmación, evidencia, fecha de revisión y próxima fecha. Cuando cambian firmware, hardware, SO o versiones, se reprueban las filas afectadas.

  • Afirmación y referencia de evidencia
  • Fecha de revisión y responsable
  • Próxima revisión prevista
  • Desencadenantes y resultados de reprueba

Errores comunes

La mayoría de los problemas vienen de tratar una etiqueta de marketing como evidencia: un logo como prueba de compatibilidad, una expresión de estado leída como certificación, un listado caducado conservado o una configuración antigua citada como actual.

En general no es un engaño deliberado, sino el resultado de contenido sin revisar. Un registro corto y fechado elimina la ambigüedad.

  • Un logo usado como prueba de una prueba
  • Expresiones de estado presentadas como certificación
  • Listados caducados o sustituidos
  • Evidencia de una región aplicada a otra

Registre honestamente los estados pendientes

Una hoja de ruta pública puede decir que hay una evaluación o prueba en curso. No debe usar expresiones que parezcan certificación antes de que la organización la conceda.

Recursos

Definamos la sala.

Cuéntanos cómo son tus salas y cómo trabaja el equipo. Te ayudaremos a elegir, planificar y estandarizar.