Lista de evaluación de proveedores de plataformas de lotería: documento RFP práctico

Prepare requisitos verificables de plataforma, compare respuestas y pruebas de proveedores, y mantenga visibles las carencias obligatorias hasta la aceptación.

Una solicitud de propuesta (RFP) de plataforma de lotería debe describir los flujos de trabajo del operador, las integraciones, el acceso a datos, los controles, las responsabilidades de entrega y las pruebas de aceptación. Separe los requisitos obligatorios de lanzamiento de las preferencias, pregunte a cada proveedor cómo se entregarán y pruebe los escenarios difíciles antes de comprometerse. El resultado debe ser un documento de requisitos versionado que se mantenga en el contrato y el plan de implementación.

Esta lista ayuda a un equipo comprador a preparar ese documento y comparar respuestas. No clasifica proveedores ni supone que una plataforma concreta ya admita las capacidades enumeradas. Cada punto es un requisito que investigar y verificar.

1. Defina el alcance operativo antes de solicitar una demostración

Empiece por las decisiones ya tomadas en su proyecto, las suposiciones aún abiertas y las personas autorizadas para resolverlas. Registre:

• Productos previstos: boletos de sorteos externos, sorteos propios, Keno, juegos personalizados o la combinación concreta que necesite.
• Mercados de clientes, marcas, idiomas, monedas, dispositivos y canales de distribución previstos.
• Entidades y partes que se espera que operen la marca, proporcionen la plataforma y gestionen cada servicio externo.
• Fases de lanzamiento, volúmenes estimados de transacciones, periodos punta previstos y pruebas que sustentan esas estimaciones.
• Sistemas o datos existentes que deban conectarse, conservarse o migrarse.
• Restricciones y requisitos operativos facilitados por los asesores cualificados del operador y las contrapartes pertinentes.
• Suposiciones presupuestarias, responsables de decisión y dependencias que puedan afectar a las fechas de entrega.

Una entrada no resuelta debe tener un responsable y una fecha de decisión. Registrarla como suposición es más útil que pedir a un proveedor un presupuesto para un alcance aparentemente completo que cambiará durante la implementación.

Seleccionar una plataforma no resuelve permisos de mercado, licencias ni cuestiones fiscales. Haga que los asesores adecuados definan esos requisitos y después tradúzcalos a flujos de trabajo, controles de sistema y pruebas que deba cubrir la RFP.

2. Redacte los requisitos como flujos de trabajo y pruebas de aceptación

El nombre de una función rara vez explica el resultado que necesita. Por ejemplo, «monedero» no indica a un proveedor cómo deben comportarse saldos, liquidaciones, reversiones y transacciones disputadas.

Utilice una matriz de requisitos que conecte el recorrido con las pruebas que aceptará:

Asigne a cada requisito un identificador, prioridad, responsable de aceptación y dependencia. Añada una breve explicación de su importancia. Los responsables de producto, finanzas, seguridad, cumplimiento y atención al cliente deben poder revisar sus secciones sin inferir el flujo previsto a partir de una lista de nombres de módulos.

Para requisitos específicos de pagos, utilice la guía de la arquitectura de pagos de lotería junto con esta matriz.

3. Haga comparables las respuestas de proveedores

Pida a todos los proveedores preseleccionados que utilicen las mismas categorías de respuesta. Describen la vía de entrega propuesta, no una puntuación de calidad.

Para cada fila, solicite responsable de entrega, suposición, referencia de pruebas, tratamiento comercial y dependencia temporal. Mantenga visibles las preguntas sin respuesta. Una declaración de hoja de ruta no debe registrarse como capacidad entregada.

Cuando intervenga más de una parte, identifique a la persona o equipo que coordinará el recorrido completo. De lo contrario, una integración técnicamente válida puede dejar al operador sin responsable de excepciones o incidentes.

4. Incluya datos, integraciones y requisitos de salida desde el principio

El acceso a datos es un requisito operativo, además de una cuestión de salida. Especifique qué registros necesita, quién puede acceder a ellos, los identificadores que los conectan y cómo se entregarán las exportaciones.

Límites de integración

Para cada conexión necesaria, documente los sistemas de ambos lados, los datos intercambiados, los tiempos de eventos, el enfoque de autenticación, el versionado, la monitorización y la responsabilidad de soporte. Describa qué debe ocurrir tras un tiempo de espera agotado, un mensaje retrasado, una notificación duplicada o un socio no disponible.

Solicite documentación representativa de interfaces y datos de prueba. Un logotipo de integración o una demostración comercial satisfactoria no establece el comportamiento del flujo completo que pretende utilizar.

Propiedad, acceso y portabilidad

Solicite un inventario de registros de jugadores, pedidos, transacciones, resultados, soporte y auditoría. Defina campos necesarios para cada función operativa, formatos de exportación, frecuencia, volumen previsto y tratamiento de correcciones. Registre el acceso durante las operaciones normales, la implementación, un incidente y la terminación.

Separe propiedad contractual, acceso práctico y responsabilidades de tratamiento de datos. Haga que las partes responsables evalúen los requisitos de conservación, acceso y transferencia según sus circunstancias. La guía de propiedad de datos de jugadores ofrece preguntas adicionales de adquisición.

Ejemplo: las compras funcionan, pero no puede exportarse el historial de transacciones

En esta evaluación hipotética, una demostración completa registro, depósito y compra de boleto. El proveedor aún no puede generar una exportación completa de transacciones con identificadores estables que vinculen registros de jugador, pedido, pago y liquidación.

Pida al proveedor que demuestre la exportación con volúmenes representativos y explique campos, tiempos, limitaciones y trabajo adicional. Finanzas y operaciones deben comprobar si el resultado satisface sus necesidades de conciliación e investigación. Si persiste la carencia, decida si una alternativa probada puede cumplir el requisito o si la propuesta debe quedar fuera de la preselección.

Trátelo como una dependencia operativa actual, no como una pregunta que posponer hasta que la migración sea urgente.

5. Especifique expectativas de seguridad, rendimiento y servicio

Anote los resultados de seguridad y operación que necesita el proyecto: permisos administrativos, registro de acceso, monitorización, copias de seguridad, recuperación, escalada de soporte y gestión de cambios. Incluya medición de disponibilidad y rendimiento, suposiciones de capacidad, accesibilidad y requisitos de localización.

Pregunte qué se medirá, durante qué periodo, por quién y con qué exclusiones. Documente los objetivos de recuperación y las pruebas esperadas de un ejercicio de recuperación. No trate un porcentaje de disponibilidad o un distintivo de seguridad como sustituto de comprender el alcance propuesto y sus dependencias.

El Marco de Ciberseguridad del NIST es una referencia primaria para estructurar conversaciones sobre riesgo de ciberseguridad. Úselo para organizar preguntas y pruebas solicitadas; esta guía no afirma que un proveedor haya sido evaluado conforme a él.

Para datos de tarjetas de pago, los recursos PCI DSS del PCI Security Standards Council describen requisitos de seguridad técnicos y operativos. Pida a los especialistas pertinentes de pagos y seguridad que identifiquen el alcance, las responsabilidades y las pruebas de validación aplicables a la arquitectura propuesta. Una integración de pagos externa, por sí sola, no responde a esas preguntas.

6. Guionice la demostración en torno a las excepciones

Entregue a los proveedores los mismos escenarios antes de la sesión de evaluación. Incluya un recorrido satisfactorio y casos que revelen traspasos entre sistemas:

• Un caso de verificación que requiera información adicional y una respuesta clara de soporte.
• Una notificación de pago que llegue tarde o más de una vez.
• Una compra intentada cerca del cierre de ventas configurado.
• Un resultado externo corregido o no disponible.
• Una cuenta restringida que intente una transacción pertinente.
• Un ajuste manual que requiera un usuario autorizado y un registro trazable.
• Un informe o exportación que finanzas deba conciliar con los registros de la plataforma.

Registre la versión del producto, las suposiciones, el comportamiento observado y las preguntas sin resolver. Si no puede demostrarse un escenario, acuerde qué pruebas adicionales hacen falta en lugar de marcarlo como aceptado.

7. Utilice una matriz de decisión que mantenga visibles las carencias obligatorias

Fije sus prioridades antes de revisar propuestas. Un registro de decisión sugerido es:

Puntúe las preferencias por separado si el equipo comprador lo considera útil. No permita que una puntuación alta en diseño o funciones opcionales oculte un requisito obligatorio ausente. Mantenga la calidad de las pruebas y las suposiciones pendientes junto a cualquier puntuación.

8. Apruebe una línea base de requisitos numerada

Tras las aclaraciones, congele una versión que enumere los elementos obligatorios, aplazados y rechazados, además de las suposiciones aún abiertas. Utilice los mismos identificadores de requisitos en la propuesta, el alcance contractual acordado, el trabajo de implementación y el registro de aceptación.

Para cada cambio, registre el efecto en coste, plazos, dependencias y controles. Defina quién puede aprobarlo y quién probará el resultado. Así se evita que un requisito operativo importante desaparezca entre un taller, una propuesta comercial y la lista de verificación de versión.

Aplica requisitos obligatorios antes de puntuar proveedores

Una puntuación ponderada solo sirve después de cumplir requisitos irrenunciables. Define condiciones obligatorias antes de las demostraciones y acuerda pesos para los demás criterios según riesgos operativos y prioridades comerciales. No otorgues puntos a promesas sin respaldo.

• Registra requisitos obligatorios como cumplidos, incumplidos o pendientes, con evidencia necesaria y responsable de la decisión.
• Incumplir una condición obligatoria detiene la evaluación; un diseño atractivo o precio bajo no lo compensa.
• Define la escala de puntuación y distingue capacidad demostrada, compromiso escrito de entrega y falta de evidencia.
• Registra supuestos, exclusiones y responsables junto a cada puntuación para que todos evalúen el mismo alcance propuesto.

Compara totales ponderados solo entre proveedores aptos. Utiliza el modelo de coste total para supuestos comparables y la lista de seguridad y SLA para verificar evidencias, manteniendo una evaluación auditable sin inventar resultados de proveedores.

Antes de enviar la RFP

• Confirme las entradas de producto, mercado, canal y modelo operativo, identificando claramente lo pendiente.
• Asigne identificador, prioridad, requisito de pruebas y responsable de aceptación a cada flujo.
• Solicite a todos los proveedores una respuesta común sobre el estado de entrega.
• Incluya excepciones de integración, informes, acceso a datos, seguridad y soporte.
• Pida el alcance comercial completo y las dependencias detrás de las fechas de entrega.
• Facilite escenarios guionizados de demostración y registre las pruebas observadas.
• Resuelva las carencias obligatorias antes de considerar una propuesta lista para selección.
• Traslade la línea base aprobada a la implementación y a la lista de lanzamiento.

Utilice la guía de precios y TCO del software de lotería para aclarar definiciones de tarifas antes de comparar respuestas comerciales.

Analice sus requisitos de plataforma con WhiteLotto

Lleve el alcance de producto, flujos necesarios, integraciones, necesidades de datos y dependencias pendientes a una conversación de definición del alcance de plataforma. Pregunte qué elementos están disponibles en el alcance propuesto, cuáles requieren configuración u otro trabajo y cuáles dependen de partes externas.

Contacte con WhiteLotto sobre el alcance de plataforma.

Las decisiones de licencias, jurídicas y fiscales deben tratarlas los asesores cualificados adecuados. Una conversación de definición del alcance de plataforma no establece autorización de mercado ni sustituye su asesoramiento.