Quien elabora un pliego de requisitos para seleccionar un ERP o un CRM suele enfrentarse a una plantilla en blanco. De varios procesos de selección reales por los que hemos pasado como proveedor se desprende una estructura que aparece una y otra vez en la práctica, con independencia del sector y del tamaño de la empresa.
1. Desglosar de forma concreta el modelo de licencias y usuarios
No solo cuenta el número total de usuarios: muchos pliegos exigen (o deberían exigir) un desglose por roles, por ejemplo personal de oficina, equipo comercial de campo, formadores o contabilidad, porque en las soluciones SaaS modernas el coste de las licencias se calcula a menudo precisamente así. Quien olvida este desglose en el pliego recibe después ofertas poco adecuadas o innecesariamente caras.
2. Cobertura de módulos en tabla, no en texto corrido
Ha demostrado su eficacia una tabla de requisitos con criterios obligatorios y opcionales por módulo, por ejemplo CRM, gestión de pedidos, gestión de inventario, contabilidad y planificación de recursos. Así los proveedores pueden responder de forma estructurada y los clientes pueden comparar directamente varias ofertas, en lugar de tener que comparar largos textos.
3. Nombrar las interfaces de forma concreta, no limitarse a pedir «capacidad de API»
«API REST abierta», por sí sola, dice poco. Lo relevante es qué sistemas de destino concretos hay que conectar: la contabilidad financiera existente, los socios EDI, una tienda online ya en funcionamiento o una plataforma de formación (LMS). Precisamente esto decide si basta con una integración estándar o si hace falta un desarrollo a medida costoso.
4. No olvidar los requisitos de cumplimiento normativo y conservación
Sobre todo en los datos de facturación y contabilidad se pide con frecuencia un almacenamiento inalterable y conforme a las GoBD (las normas alemanas de llevanza de libros), con plazos de conservación concretos: a menudo diez años para libros contables, inventarios y cuentas anuales. Según nuestra experiencia, este punto falta con frecuencia en los primeros borradores del pliego y provoca retrasos cuando hay que añadirlo a posteriori.
5. Exigir la seguridad como documento independiente, no como un párrafo
En varios procesos se exigió un documento de seguridad independiente —ubicación del alojamiento, concepto de copias de seguridad, derechos de acceso, cifrado— en lugar de una breve mención en la oferta principal. Esto facilita a los clientes comparar las ofertas por su nivel de seguridad sin mezclarlo con las respuestas funcionales.
6. Programar una sesión fija de preguntas
En nuestra experiencia, los pliegos que obtuvieron las mejores ofertas casi siempre preveían un taller o una sesión de preguntas antes de la entrega final de las ofertas: esto reduce considerablemente los malentendidos por ambas partes y evita que los proveedores calculen sobre suposiciones erróneas.
Checklist para llevar
- Roles de usuario y estructura de licencias claramente definidos
- Módulos en una tabla de criterios obligatorios/opcionales, no en texto corrido
- Sistemas de destino concretos indicados para las interfaces
- Requisitos de conservación y cumplimiento definidos
- Requisitos de seguridad solicitados como documento independiente
- Sesión de preguntas programada antes de la entrega final de ofertas
Preguntas frecuentes
¿Cuál es la diferencia entre un pliego de requisitos y una especificación técnica?
El pliego de requisitos describe, desde el punto de vista del cliente, qué se necesita. La especificación técnica describe, desde el punto de vista del proveedor, cómo se implementarán concretamente esos requisitos. Más información en nuestro glosario sobre licitaciones, pliego de requisitos, especificación técnica y RFP.
¿Qué nivel de detalle debe tener un pliego de requisitos?
El suficiente para definir criterios obligatorios claros, pero lo bastante abierto como para dejar a los proveedores margen en la implementación técnica. Unas especificaciones técnicas demasiado rígidas suelen excluir innecesariamente buenas soluciones estándar.
¿Conviene elaborar el pliego con o sin asesoramiento externo?
En entornos de sistemas más complejos, el asesoramiento externo ayuda a evitar puntos ciegos; para requisitos bien delimitados, a menudo basta con un análisis interno estructurado.
¿Estás elaborando un pliego de requisitos para seleccionar un ERP/CRM? Estaremos encantados de hablar sin compromiso sobre la estructura de tus requisitos, aunque todavía no hayas elegido proveedor.
Ponte en contacto con nosotros