Cómo redactar el pliego de requisitos de un ERP (con modelo)

Un pliego de requisitos ERP es el documento que describe, de forma ordenada y verificable, qué debe hacer el sistema que su empresa va a implantar, con qué datos, con qué integraciones y bajo qué condiciones se evaluará a los proveedores. En México añade una capa propia: la obligación de emitir y recibir comprobantes fiscales digitales, la contabilidad electrónica y la relación con el SAT condicionan casi cada decisión de diseño.

Esta guía explica para qué sirve el pliego, cómo se distingue de la expresión de necesidades y del RFP, cuál es el plan tipo y, al final, ofrece un modelo de pliego de requisitos ERP que puede copiar y adaptar. No hay cifras de referencia porque cada proyecto es distinto: lo que importa es que su documento sea claro, completo y comparable.

Para qué sirve un pliego de requisitos ERP

El pliego cumple cuatro funciones que se refuerzan entre sí.

• Obliga a la empresa a ponerse de acuerdo. Escribir los procesos revela las diferencias entre áreas antes de que se conviertan en discusiones durante la implantación.
• Hace comparables las propuestas. Si todos los proveedores responden al mismo documento, las diferencias de alcance, precio y plazo se ven de inmediato.
• Reduce el riesgo de desviaciones. Lo que no está escrito se interpreta; lo que se interpreta se negocia; y lo que se negocia a mitad del proyecto cuesta tiempo y dinero.
• Sirve de base contractual. El alcance firmado se apoya en el pliego y en la respuesta del proveedor, y de ahí se derivan las pruebas de aceptación.

Muchos de los fracasos que describe la guía sobre errores frecuentes en un proyecto ERP nacen de un alcance mal definido. El pliego es la primera defensa contra ese problema.

Pliego, expresión de necesidades y RFP: tres documentos distintos

Estos términos se usan a menudo como sinónimos, pero cada uno responde a una etapa del proceso.

En la práctica puede reunirlos en un solo archivo: una primera parte con la expresión de necesidades, una segunda con los requisitos detallados y una tercera con las instrucciones para responder. Lo importante es que cada parte esté identificada.

Antes de redactar: prepare el terreno

Escribir sin preparación produce documentos largos y poco útiles. Antes de abrir el editor conviene resolver estos puntos.

Fije los objetivos del proyecto

Un ERP no es un fin en sí mismo. Pregúntese qué debe mejorar: el cierre contable, el control de inventarios, la trazabilidad de compras, la facturación, la visibilidad de márgenes, la consolidación entre empresas del grupo. Dos o tres objetivos claros orientan todas las decisiones posteriores.

Nombre un responsable y un comité

Debe haber una persona con autoridad y tiempo para dirigir el proyecto, y un comité reducido con representantes de finanzas, operaciones, ventas, compras, logística, recursos humanos y sistemas. Sin patrocinio de la dirección, los requisitos se multiplican y nadie decide.

Documente los procesos actuales

Haga un inventario sencillo: quién hace qué, con qué herramienta (hojas de cálculo, sistema contable, sistemas locales), qué documentos genera y dónde se producen los errores. No hace falta un modelado formal; basta con descripciones de una o dos páginas por proceso y los formatos reales de pedidos, facturas y reportes.

Distinga lo indispensable de lo deseable

Cada requisito debe clasificarse: obligatorio, importante o deseable. Esta clasificación es la que permite, más adelante, puntuar las respuestas y negociar el alcance de una primera fase.

Plan tipo de un pliego de requisitos ERP

Este es el esquema que recomendamos, con el propósito de cada bloque.

Cómo redactar cada bloque

Presentación de la empresa

Dedique unos párrafos a explicar quién es su empresa: sector, productos o servicios, número aproximado de sedes y entidades, tipo de clientes, canales de venta y particularidades. No hace falta incluir cifras exactas en este bloque si prefiere mantener la confidencialidad; el proveedor puede pedirlas después de firmar un acuerdo de confidencialidad.

Indique también el sistema actual y por qué ya no basta. Un proveedor que entiende el punto de partida propone mejor.

Objetivos y alcance

Enumere los objetivos de negocio y delimite el alcance con tres listas: lo que entra (módulos, entidades, sedes, usuarios), lo que queda fuera y lo que se pospone a una segunda fase. Un alcance explícito evita el efecto de «ya que estamos, también…».

Procesos de negocio

Describa los procesos principales de principio a fin, por ejemplo de la cotización al cobro, de la requisición al pago, de la orden de producción a la entrega. Para cada uno indique los actores, los documentos, las aprobaciones y los casos especiales. Un buen método es redactar historias breves: «Cuando un cliente confirma un pedido con anticipo, el sistema debe…».

Requisitos funcionales por módulo

Aquí se concentra el volumen del documento. Escriba cada requisito como una frase verificable, con un identificador único y una prioridad. Evite fórmulas vagas como «debe ser flexible» o «debe ser intuitivo»; prefiera «el usuario de compras puede convertir una requisición aprobada en orden de compra sin recapturar datos».

Los módulos más habituales son finanzas y contabilidad, compras, ventas y facturación, inventarios y almacén, producción o manufactura, proyectos o servicios, recursos humanos y nómina, relación con clientes y reportes. Solo incluya los que forman parte de su alcance. Si necesita orientación por giro, consulte las páginas dedicadas a ERP para la industria o ERP para distribución.

Requisitos fiscales y de cumplimiento en México

Es el bloque que distingue un pliego mexicano de uno genérico. Especifique, como mínimo:

• emisión de comprobantes fiscales digitales con timbrado a través de un proveedor autorizado, incluidos los complementos que use su operación (pagos, carta porte, nómina, comercio exterior);
• recepción y validación de comprobantes de proveedores, y conciliación con las cuentas por pagar;
• contabilidad electrónica y generación de los archivos que exige la autoridad;
• cálculo y control de impuestos como el IVA, retenciones y la relación con la declaración informativa de operaciones con terceros;
• tratamiento de moneda extranjera y tipo de cambio, con revaluación al cierre;
• conservación de documentos y trazabilidad para auditorías.

La guía sobre ERP y facturación electrónica detalla cómo plantear estos puntos para que el proveedor responda con precisión y no con generalidades.

Requisitos técnicos

Indique si prefiere una solución en la nube, local o híbrida, y qué restricciones tiene su empresa (políticas de seguridad, conectividad de las sedes, regulación sectorial). La decisión se explica en ERP en la nube o local. Pida respuestas sobre autenticación y control de accesos, respaldos y recuperación, disponibilidad, registro de auditoría, interfaces de programación para integraciones y entornos de prueba.

Enumere las integraciones necesarias: bancos, proveedor de timbrado, comercio electrónico, punto de venta, paqueterías, sistemas de producción, herramientas de inteligencia de negocio, correo y firma electrónica.

Reprogramación y migración de datos

Precise qué datos se migrarán (catálogo de clientes, proveedores, artículos, saldos iniciales, históricos), en qué formato están hoy, qué calidad tienen y quién será responsable de depurarlos. Aclare si se requiere histórico contable o solo saldos. Para este tema, la guía de migración de ERP ofrece un método detallado.

Gestión del proyecto

Pida al proveedor que describa su metodología, la composición del equipo, el rol que espera de su empresa, el plan de capacitación, la estrategia de pruebas y el acompañamiento tras el arranque. Es útil conocer también cómo se gestionan los cambios de alcance y qué soporte se ofrece después de la puesta en marcha. El proceso general se describe en la guía de implantación de un ERP.

Calendario y presupuesto

Sin dar cifras artificiales, indique las restricciones reales: cierres fiscales o de ejercicio que no deben coincidir con el arranque, temporadas altas, auditorías previstas. En el presupuesto, fije el marco en pesos mexicanos y pida un desglose por licencias o suscripciones, servicios de implantación, desarrollos, capacitación y mantenimiento. Para entender qué conceptos conforman el costo, lea cuánto cuesta un ERP.

Criterios de selección

Defina de antemano cómo evaluará. Una matriz con criterios y ponderaciones evita decisiones basadas en la mejor presentación. Los criterios habituales son cobertura funcional, cumplimiento fiscal, calidad de la metodología, experiencia en su sector, costo total, referencias verificables y capacidad de soporte local.

Modelo de pliego de requisitos ERP para copiar

Copie la estructura siguiente, sustituya los textos entre corchetes y elimine lo que no aplique. Cada requisito lleva un identificador, una descripción verificable y una prioridad (obligatorio, importante o deseable).

Parte A. Presentación

Empresa: [razón social y nombre comercial] Giro de actividad: [descripción breve] Estructura: [entidades legales, sedes, almacenes, plantas] Sistema actual: [herramientas utilizadas y limitaciones] Motivo del proyecto: [problemas que se quieren resolver] Responsable del proyecto: [nombre y cargo] Comité de proyecto: [áreas representadas]

Parte B. Objetivos y alcance

• Objetivos de negocio: [lista de dos a cinco objetivos medibles de forma cualitativa]
• Módulos incluidos: [lista]
• Entidades, sedes y áreas incluidas: [lista]
• Excluido del alcance: [lista]
• Posible segunda fase: [lista]
• Perfiles de usuarios: [dirección, finanzas, compras, ventas, almacén, producción, consulta]

Parte C. Procesos de negocio

Parte D. Requisitos funcionales

Utilice una tabla por módulo, con esta estructura:

Replique el formato para cada módulo incluido: finanzas, compras, ventas, inventarios, producción, proyectos, recursos humanos, relación con clientes y reportes.

Parte E. Requisitos fiscales y de cumplimiento

Parte F. Requisitos técnicos

• Modalidad de despliegue deseada: [nube / local / híbrida] y justificación.
• Seguridad: autenticación, doble factor, perfiles y segregación de funciones, registro de auditoría.
• Continuidad: respaldos, plan de recuperación ante desastres, disponibilidad esperada.
• Rendimiento: volumen de transacciones previsto y número de usuarios simultáneos [a completar por la empresa].
• Integraciones: [bancos, timbrado, comercio electrónico, punto de venta, paqueterías, inteligencia de negocio].
• Entornos: pruebas, capacitación y producción.
• Idioma, formatos y moneda: español de México, MXN y otras monedas requeridas.
• Protección de datos personales: cumplimiento de la ley aplicable y condiciones de tratamiento por parte del proveedor.

Parte G. Reprogramación y migración de datos

Pida al proveedor que describa su método de carga, el número de ensayos previstos de migración y el criterio de aceptación de los datos.

Parte H. Gestión del proyecto

• Metodología propuesta y fases.
• Composición del equipo del proveedor y perfiles de cada rol.
• Roles y dedicación que se esperan de su empresa.
• Plan de capacitación por perfil de usuario.
• Estrategia de pruebas: unitarias, integrales y de aceptación por parte de los usuarios.
• Plan de arranque, acompañamiento y soporte posterior.
• Gestión de cambios de alcance y de riesgos.

Parte I. Calendario

• Fecha deseada de arranque y de puesta en producción: [a completar].
• Periodos que deben evitarse: [cierre de ejercicio, temporada alta, auditorías].
• Hitos solicitados: [diseño aprobado, migración de prueba, pruebas de aceptación, arranque].

Parte J. Presupuesto

• Marco presupuestal: [monto de referencia en MXN, si decide comunicarlo].
• Desglose solicitado: licencias o suscripciones, implantación, desarrollos, migración, capacitación, soporte y mantenimiento.
• Supuestos de la oferta: número de usuarios, horas por actividad, gastos de viaje, impuestos.
• Condiciones de pago y vigencia de la oferta.

Parte K. Criterios de selección

Parte L. Instrucciones de respuesta

• Fecha límite de recepción y medio de envío.
• Contacto único para dudas, con calendario de preguntas y respuestas compartidas con todos los participantes.
• Formato obligatorio: responder en la misma tabla de requisitos, indicando para cada uno si se cubre de forma estándar, con configuración, con desarrollo o con una herramienta de terceros.
• Documentos a adjuntar: propuesta técnica, propuesta económica, plan de trabajo, referencias y condiciones contractuales.
• Etapas siguientes: demostraciones guiadas con sus propios casos de uso y reunión de aclaraciones.
• Confidencialidad: el contenido del documento no puede compartirse fuera del equipo del proveedor.

Cómo usar el pliego para comparar editores

Un buen pliego es neutral: no menciona una marca y describe necesidades, no productos. Al recibir las respuestas, el mismo documento sirve para comparar soluciones muy distintas, por ejemplo Odoo, SAP Business One, Oracle NetSuite, Microsoft Dynamics 365 Business Central o una solución de origen local como CONTPAQi.

Cada solución cubre ciertos requisitos de forma estándar, otros con configuración y otros mediante módulos de terceros o desarrollo. Lo que cambia entre propuestas no es solo el producto, sino también el integrador que lo implanta, su experiencia con su sector y su capacidad para resolver los requisitos fiscales mexicanos. Por eso conviene exigir la columna «cobertura del proveedor» y pedir demostraciones con casos reales.

Si desea una visión comparada ya preparada, consulte el comparativo de ERP para pymes y la guía para elegir un ERP.

Errores frecuentes al redactar el pliego

• Describir soluciones en lugar de necesidades. Pedir «un módulo con tal pantalla» limita la creatividad del proveedor; pida el resultado que necesita.
• Documento demasiado largo y sin prioridades. Si todo es obligatorio, nada lo es. Clasifique cada requisito.
• Olvidar la parte fiscal. Dejar el cumplimiento para «más adelante» es una de las causas más habituales de sobrecostos.
• Ignorar los datos. La calidad de la información de origen condiciona el calendario más que cualquier otra variable.
• Redactarlo solo desde sistemas o solo desde finanzas. Los usuarios que operan el día a día deben validar los procesos.
• No definir los criterios de evaluación antes de recibir las ofertas. Cambiar la regla al ver los resultados daña la credibilidad del proceso.
• No reservar tiempo para las aclaraciones. Las preguntas de los proveedores son una señal valiosa de qué tan bien han entendido su negocio.

Siguientes pasos

Una vez redactado el pliego, el reto es enviarlo a los interlocutores adecuados. Elegir proveedores con experiencia en su sector y en la normativa mexicana exige tiempo, y por eso muchas empresas prefieren apoyarse en una mise en contact previa. En cómo funciona nuestro servicio explicamos cómo recibir propuestas de integradores adaptados a su proyecto, sin costo para usted. Para evaluar a quien responda, la guía para elegir un integrador ERP propone preguntas y señales de alerta.

Un pliego bien trabajado no garantiza por sí solo un proyecto exitoso, pero sin él es muy difícil que lo sea. Dedique el tiempo necesario a escribirlo con su equipo: cada hora invertida aquí se ahorra con creces durante la implantación.

Los nombres de software mencionados son marcas de sus respectivos editores y se citan únicamente a título informativo. Este sitio es independiente y no está afiliado a ningún editor.