RFP para RFID y ESL: estructura para pedir propuestas claras

Una RFP es una herramienta de comparación

La solicitud de propuesta (RFP) es el documento formal del proceso: fija reglas, secciones y formato de respuesta para que varios proveedores contesten lo mismo y usted pueda compararlos. No es el paquete de datos del proyecto (eso es lo que se entrega para cotizar), ni la matriz con la que se puntúan las respuestas. Para RFID y ESL conviene una estructura base común y ramas por escenario, porque un proyecto de recepción en bodega y uno de etiquetas de precio tienen riesgos distintos.

No es un texto legal: las cláusulas contractuales deben revisarlas sus asesores.

Secciones comunes a toda RFP

1. Contexto y objetivo: quién es la organización, qué problema se quiere resolver y cómo se medirá el éxito.
2. Alcance: sitios, procesos, volúmenes estimados (marcados como estimaciones) y lo que queda fuera.
3. Requisitos: divididos en obligatorios y deseables, redactados como comportamientos comprobables.
4. Formato de respuesta: hoja de precios con partidas separadas, lista de supuestos, plan de trabajo por dependencias.
5. Evidencia solicitada: pruebas, referencias verificables, documentación técnica.
6. Criterios de evaluación: dimensiones y pesos definidos antes de recibir respuestas.
7. Soporte y garantía: alcance, canales, responsabilidades entre fabricante e integrador.
8. Aceptación: cómo se probará cada requisito.
9. Cumplimiento y seguridad: documentación regulatoria del equipo, política de datos, accesos.
10. Reglas del proceso: calendario, preguntas, confidencialidad, derecho a declinar.

Rama A: RFID en bodega o activos

Entregables que la respuesta debe incluir en la rama RFID:

• Esquema de codificación propuesto y un ejemplo de etiqueta codificada con las claves del cliente; el EPC y su estándar de datos de etiqueta los describe GS1, pero la propuesta puede usar otro esquema válido si lo justifica.
• Estándares que siguen lectores y etiquetas. La RAIN RFID Alliance indica que no realiza pruebas de cumplimiento, así que se debe exigir la evidencia que respalde cualquier declaración.
• Diseño de lectura (zonas, antenas, lectores portátiles) y método para separar lecturas de objetos cercanos.
• Definición de cada métrica antes de dar cifras: tasa de lectura sobre universo conocido, no solo conteo de lecturas, y cómo se evitan duplicados contados como artículos distintos.
• Procedimiento de aplicación, codificación y verificación de etiquetas.

Rama B: ESL en tienda

Entregables de la rama ESL:

• Diagrama de arquitectura: etiquetas, gateways o puntos de acceso, servidor o nube de gestión y conexión con la fuente de precios. Como ejemplo del nivel de detalle, la documentación de Cisco Meraki con Vusion lista modelos compatibles, firmware, puertos de salida y funciones excluyentes de una combinación concreta.
• Procedimiento de conciliación: qué estado reporta el sistema, cómo se detectan etiquetas sin sincronizar y qué hace el personal ante una falla. Que el valor visible coincida con el esperado no prueba una sincronización exitosa.
• Gestión de asociación etiqueta-SKU, permisos de usuario y comportamiento si cae la conexión a internet.

Rama C: PDA y lectores

Si el proyecto incluye dispositivos móviles, pida el plan de soporte del sistema operativo: el programa Android Enterprise Recommended solicita que el fabricante publique la fecha final de actualizaciones de seguridad, y es razonable pedir esa fecha para cada modelo aunque no esté en el programa. Pida la estrategia de gestión de dispositivos (un sistema de gestión no garantiza seguridad; debe describir qué políticas se aplicarán) y el plan de sanitización al final de la vida útil, que puede basarse en guías como NIST SP 800-88 Rev. 2.

Tabla de respuesta que debe exigirse

Anexos que conviene incluir

Además del cuerpo de la RFP, adjunte anexos que reduzcan preguntas: un plano de los sitios con las zonas de interés, una muestra del maestro de datos con campos reales anonimizados si hace falta, un diagrama de los sistemas con los que debe integrarse y el formato de hoja de precios. Si hay artículos difíciles (superficies metálicas, líquidos, empaques especiales), ofrezca muestras para pruebas y deje claro quién cubre su envío y devolución.

Incluya también un anexo de definiciones: qué se entiende por «lectura», «artículo único», «etiqueta sincronizada» o «incidente». Quien responde debe usar sus definiciones y no las propias, porque la diferencia entre ambas es la fuente más frecuente de comparaciones engañosas.

Reglas del proceso y errores comunes

Fije fechas de preguntas y comparta las respuestas con todos los participantes. Aclare si habrá demostraciones o pruebas de concepto antes de adjudicar y quién cubre sus costos. Indique que las respuestas formarán parte de lo comprometido, o no, según lo que decida su asesor.

Los errores comunes son pedir demasiados requisitos «obligatorios» sin priorizar, mezclar RFID y ESL en una misma lista sin ramas, y no definir cómo se evaluará, lo que lleva a decidir por precio por defecto. Una RFP corta con requisitos claros suele producir mejores propuestas que otra extensa y ambigua.

Siguiente paso

Elija la rama que corresponde a su proyecto, complete las secciones comunes y revise el borrador con un compañero de operaciones y otro de TI antes de enviarlo.

Si desea contrastar su caso con ARKCOM, puede escribir desde garkcom.com/contact.