Ideas clave
- Puntúe el producto, el despliegue y el país concretos, no el marketing general del proveedor.
- Utilice puertas de elegibilidad antes de la puntuación ponderada.
- Exija a los proveedores que demuestren tanto los flujos habituales como los casos excepcionales.
- Exija evidencia de las API, la seguridad, la localización, la migración y los resultados.
- Mantenga separado el estado de la evidencia pública de la verificación final de la compra.
1. Forme el equipo de decisión y defina el alcance
La selección del DMS afecta a ventas, vehículos de ocasión, taller, recambios, finanzas, TI, privacidad y reporting de grupo. Cree un equipo de decisión con responsables operativos, no solo representantes. Designe un patrocinador ejecutivo, un responsable de producto, un responsable de datos, un responsable de integración, un responsable de seguridad/privacidad, un controller financiero y un responsable del cambio. Defina quién recomienda, quién aprueba y quién puede rechazar por un requisito obligatorio.
Documente las entidades legales, las sedes, las marcas, los países, los idiomas, los usuarios, los volúmenes de transacciones y los periodos críticos. Separe el alcance actual de una hoja de ruta plausible a tres años. Exigir un requisito para cada mercado futuro hipotético puede distorsionar la decisión, mientras que ignorar una expansión probable puede provocar otra sustitución.
2. Convierta las necesidades en requisitos comprobables
Un requisito debe indicar el actor, el desencadenante, los datos, la acción, el resultado y el criterio de aceptación. Sustituya «un CRM potente» por «una consulta web, de OEM o telefónica se empareja o se crea, se registra el consentimiento, el lead se dirige por marca y zona geográfica, se muestran un responsable y un SLA, se captura la comunicación y un acuerdo completado devuelve el estado sin duplicar el cliente».
Elabore una matriz de países y OEM. Para cada celda, registre los requisitos de contabilidad, fiscalidad, facturación, pago, matriculación, garantía, recambios, campañas, informes, identidad e idioma. El contexto europeo varía sustancialmente. Los datos de Eurostat sobre turismos muestran grandes diferencias por país en la antigüedad del parque y el tipo de propulsión, mientras que las normas de la UE sobre privacidad, acceso a datos y facturación electrónica siguen exigiendo una implementación local.[1]
3. Utilice puertas, criterios ponderados y niveles de evidencia
Las puertas de elegibilidad evitan que una puntuación total alta oculte una carencia fatal. Algunos ejemplos son el soporte en producción para un país requerido, una interfaz con un OEM concreto, la salida contable exigida por la ley, un límite de residencia de datos o una fecha límite de migración. Una puerta fallida solo puede resolverse mediante una remediación aprobada, con fecha, responsable, coste y compromiso contractual.
| Dimensión | Peso ilustrativo | Evidencia requerida |
|---|---|---|
| Flujos de trabajo funcionales de principio a fin | 25% | Demostración guionizada en el producto propuesto |
| Adecuación al país y al OEM | 15% | Referencias de producción concretas y especificaciones |
| Datos, API y ecosistema | 15% | Catálogo, entorno de pruebas, límites, propiedad, política de cambios |
| Migración e implementación | 15% | Plan, recursos, aceptación, reversión, referencias |
| Seguridad, privacidad y resiliencia | 10% | Informes, arquitectura, DPA, prueba de recuperación ante desastres y controles |
| Experiencia de usuario y adopción | 10% | Pruebas de tareas por rol y plan de formación |
| TCO a cinco años y contrato | 10% | Modelo de precios, indexación, cambios, soporte y salida |
4. Exija demostraciones guionizadas en lugar de presentaciones genéricas del producto
Aporte datos representativos pero seguros y guiones fijos. Pida al proveedor que muestre un lead a través del presupuesto, la tasación de un vehículo de parte de pago y el pedido; un vehículo de ocasión a través de la tasación, la inspección, la preparación, los medios, la publicación, el precio y la venta; una orden de reparación a través de la reserva, el trabajo del técnico, los recambios, la aprobación adicional y la factura; y un cierre de periodo o un informe de gestión.
Añada excepciones: cliente duplicado, VIN incorrecto, operación cancelada, recambio no disponible, interfaz caída, inspección sin conexión, factura rectificativa y usuario que abandona el proceso a medias. Cuente los sistemas, los clics, los valores reintroducidos, las exportaciones manuales y las dependencias invisibles en segundo plano. Registre la versión y el mercado demostrados.
Los estándares pueden mejorar la interoperabilidad, pero no sustituyen a una demostración. STAR publica API de leads, operaciones y entrega al detalle en automoción, además de un modelo de dominio de retail.[2] Pregunte si el proveedor implementa los estándares pertinentes y cómo lo hace, y después pruebe la interfaz realmente propuesta.
5. Valide las afirmaciones sobre la nube, la API, la seguridad y los datos
Para la nube, identifique si se trata de SaaS, alojamiento dedicado o arquitectura heredada alojada. Solicite las definiciones de disponibilidad, el historial de incidentes, el RPO, el RTO, la evidencia de las pruebas de copia de seguridad y recuperación, las normas de mantenimiento y el modelo de capacidad. Para las API, solicite los objetos, los campos, los eventos, las operaciones de escritura, la autenticación, el entorno de pruebas, los límites de solicitudes, los excesos, el versionado, la monitorización y los derechos de exportación de datos.
En cuanto a la privacidad y la seguridad, evalúe los roles, el privilegio mínimo, la autenticación multifactor, el registro de actividad, el cifrado, la gestión de vulnerabilidades, los subencargados, el mecanismo de transferencia, la conservación, la eliminación, la notificación de incidentes y la garantía independiente. El RGPD exige controles proporcionados al riesgo y privacidad desde el diseño, pero una certificación o un proveedor cloud no hacen que el concesionario cumpla automáticamente.[3] La guía de ENISA puede estructurar las solicitudes de evidencia, aunque el alcance de la NIS2 debe evaluarse por separado.[4]
6. Aplique estados justos de evidencia pública
| Producto/mercado concreto | Evidencia de apertura/API | Evidencia de seguridad | Interpretación |
|---|---|---|---|
| Nextlane Platform, Europa | Confirmado: posicionamiento oficial de API abierta | Confirmado: transformación en AWS y objetivo declarado de residencia en la UE | El DMS exacto y el estado de la migración requieren validación en la propuesta |
| Plataforma Pinewood, global/Europa | Confirmado: declaración de API del DMS y una integración concreta | Confirmado: declaraciones públicas de ISO | El alcance, los informes y el acceso comercial a la API requieren validación |
| Tekion ARC, Reino Unido | Confirmado: existe un acuerdo de API | Confirmado: el portal de confianza indica certificaciones y cifrado | Madurez en la Europa continental No evaluado |
| Omnetic, sitio público europeo | No confirmado públicamente: sin catálogo técnico revisado | No confirmado públicamente: sin matriz revisada de certificaciones/residencia | Solicite evidencia en la propuesta; no infiera ausencia |
| bee2link OpenFlex, Europa | No confirmado públicamente: sin catálogo general revisado | No confirmado públicamente | Se requiere una diligencia debida específica del producto |
El estado público es una herramienta de orientación. La evidencia recabada durante la compra puede modificarlo. Debe invitarse al proveedor a corregir errores factuales y a aportar pruebas confidenciales actuales mediante un proceso adecuado.
7. Termine con la implementación, las referencias y el contrato
Las llamadas de referencia deben corresponder al país, al tamaño del concesionario, a la complejidad del OEM y al alcance. Pregunte qué cambió tras la firma del contrato, qué requirió soluciones alternativas, qué datos fallaron, cuánto tardó la adopción, cómo se gestionaron los incidentes y qué haría la referencia de otra manera. No se limite a preguntar si a los usuarios les gusta el producto.
Convierta los criterios de aceptación en cláusulas contractuales. Cubra la integridad y conciliación de los datos, los flujos críticos, las integraciones, el rendimiento, la seguridad, la formación, el corte de servicio y el soporte. Tarifique las iteraciones de migración, los entornos, el uso de la API, los mensajes, el almacenamiento, el trabajo de informes, los desplazamientos, la indexación y las solicitudes de cambio. Defina los niveles de servicio, la escalada, la exportación de salida, el apoyo en la transición, la eliminación y el acceso conservado a los registros exigidos por la ley.
8. Dónde encaja Omnetic
Omnetic debería entrar en la lista corta cuando el RFP valore un contexto compartido de cliente y vehículo, un CRM de ventas y posventa, profundidad en el ciclo de vida del vehículo de ocasión, acciones sobre precio y stock, e inspección móvil estructurada. Su diferencia defendible es la continuidad desde el hallazgo o la evidencia hasta una acción operativa asumida.
Una propuesta justa de Omnetic debe demostrar igualmente cada puerta para los países, los OEM y los módulos concretos. Las afirmaciones públicas como la escala, las certificaciones y el número de módulos nativos necesitan definiciones actuales. La evidencia de seguridad, arquitectura, API, SLA y migración debe evaluarse con el mismo criterio aplicado a todos los proveedores.
Limitaciones
Los pesos son ilustrativos y no deben copiarse sin las prioridades propias del concesionario. La comparación pública es selectiva y no puntúa la calidad de la implementación. «No confirmado públicamente» nunca significa ausente. Los requisitos legales, de seguridad, fiscales y contables necesitan validación especializada.