Parametrización de un ERP

Este artículo explica, con calma y sin tecnicismos innecesarios, qué es la parametrización, dónde encaja dentro de la implantación y qué decisiones marcan la diferencia para evitar sustos en el go-live.

Qué llamamos “parametrización”

Piensa en un ERP como un edificio bien diseñado: la estructura (módulos estándar, buenas prácticas de proceso) ya existe; lo que ajustas en la parametrización son las puertas, pasillos y carteles que te permiten moverte por ese edificio a tu manera. No tiras paredes, no levantas un ala nueva; decides cómo circula la información, qué reglas se aplican y quién puede hacer qué.

En la práctica, parametrizar significa:

• Definir datos maestros con cabeza: cómo quedarán tus catálogos de clientes y proveedores, artículos y familias, formas de pago, impuestos, bancos, almacenes, series de facturación. Son la columna vertebral del sistema: si empiezan torcidos, todo se inclina.

• Ajustar reglas de negocio: tipos de IVA, retenciones, divisas, numeraciones, calendarios y periodos, condiciones comerciales, políticas de precios y descuentos, tolerancias de recepción/expedición, umbrales de stock, centros de coste, etc.

• Dibujar el flujo de trabajo: aprobaciones, estados, notificaciones, qué dispara qué (por ejemplo, un pedido confirmado genera reserva de stock), y qué documentos se crean en cada paso.

• Configurar roles y permisos: no es “dar acceso a todo por si acaso”; es cuidar la segregación de funciones y la trazabilidad de cada acción.

• Alinear la experiencia de uso: campos obligatorios, plantillas de documentos, formatos de impresión, idiomas, monedas, nomenclaturas.

Una confusión habitual es parametrización vs. personalización. La primera no toca código (o lo hace mínimamente, con extensiones estándar); la segunda implica desarrollos a medida. Personalizar no es malo per se, pero conviene agotarlo todo con parámetros antes de abrir el editor: lo que está dentro del “raíl estándar” se mantiene mejor en el tiempo y sufre menos en las actualizaciones.

Dónde encaja dentro de la implantación (y por qué manda el orden)

La parametrización no es el primer paso de una implantación ni el último; es el corazón del proyecto. Llega después de entender el negocio y antes de entrenar a la gente para pilotar el sistema nuevo.

Un esquema sano suele seguir este ritmo natural:

1. Descubrimiento y análisis: fotografiar procesos tal como son, identificar fricciones y decidir qué se conserva, qué se simplifica y qué se estandariza. Es el momento de separar “lo imprescindible” de “lo que siempre hemos hecho”.

2. Diseño de solución: traducir ese análisis a decisiones de configuración. Aquí se documenta qué parámetros se tocarán, por qué y con qué valores iniciales.

3. Parametrización: aplicar esas decisiones en un entorno de pruebas. Nada de tocar producción “para ir más rápido”.

4. Migración de datos maestros (piloto): cargar catálogos limpios y coherentes. Si los datos llegan con duplicados, formatos raros o códigos inconsistentes, el ERP no “entiende” lo que le dices.

5. Pruebas con usuarios (UAT): simular el día a día con casos reales. ¿El pedido correcto genera la reserva correcta? ¿La factura sale con la serie, el impuesto y el pie legal correctos? ¿El stock y las cuentas cuadran?

6. Formación y manuales vivos: enseñar el “cómo” y el “por qué”. Si la gente entiende la lógica detrás de la parametrización, usa el sistema con criterio.

7. Arranque (go-live) con plan de reversión: pasar a producción con guardarraíles. Mejor un arranque medido que un salto al vacío.

8. Estabilización y mejoras: medir incidencias, cerrar brechas y afinar. La buena parametrización se nota porque desaparecen los apaños.

El orden importa. Parametrizar con datos sucios o sin diseño previo es como colgar cuadros antes de levantar las paredes: puede parecer que avanzas, pero luego todo toca rehacerse.

Lo importante de verdad: decisiones que evitan incidencias tras el go-live

Más allá del listado de pantallas, hay cinco decisiones que separan una puesta en marcha tranquila de un vía crucis de tickets.

1) Datos maestros con criterio (y propiedad clara)
Nadie disfruta “limpiando” catálogos, pero es el mayor acelerador de valor. Definir códigos, jerarquías y reglas de unicidad evita el clásico “tengo cinco veces el mismo cliente con nombres distintos”. Establece quién es dueño de clientes, artículos y bancos, y cómo se crean/cambian. Un dato maestro sin dueño se estropea solo.

2) Reglas fiscales y legales cerradas antes de probar
Tipos de IVA, recargos, series de facturas, retenciones y textos legales en documentos. Decidirlo después de las pruebas es invitar al caos: cada rectificación borra confianza y tiempo.

3) Roles, permisos y segregación de funciones
No es desconfianza, es control sano. Separar quién crea, quién aprueba y quién cobra reduce errores y acelera auditorías. Todo cambio relevante debería dejar huella (quién, cuándo y por qué).

4) Workflows realistas (sin overspec)
Intentar que el ERP reproduzca cada rareza del proceso actual suele sobrar. La pregunta clave es: “¿Cuál es la forma más simple que mantiene el control y la información que necesito?” Menos bifurcaciones → menos mantenimiento → más fiabilidad.

5) UAT serio, con casos “de verdad”
Probar solo el camino feliz es un clásico que se paga caro. Las pruebas deben incluir devoluciones, cambios de tarifa, cierres, ajustes de stock, incidencias de logística y cualquier situación que en tu día a día ocurra dos veces por semana. Si algo no se prueba, no está listo.

Errores frecuentes

• Parametrizar copiando “otra empresa”. Cada organización tiene su mezcla particular de impuestos, roles, catálogo y flujos. Lo que funcionó en un sitio puede torcerte a ti una contabilidad entera. La alternativa: partir de plantillas, sí, pero revisar una a una las hipótesis.

• Ir a producción con “ya lo afinamos luego”. Se afina siempre, pero hay mínimos no negociables: fiscalidad, numeraciones, permisos y catálogo deben llegar cerrados. Las prisas en esos cuatro frentes se pagan con dobles trabajos y asientos raros.

• Dar acceso “temporal” a todo el mundo. Lo temporal se queda para siempre. Mejor roles ajustados desde el principio y un proceso rápido para pedir ampliaciones.

• No documentar por qué un parámetro tiene ese valor. Tres meses después nadie recuerda qué llevó a esa decisión y el sistema se vuelve una caja negra. Documentar es agilizar, no burocratizar.

• Confundir personalización con comodidad. Programar una excepción porque alguien lo pidió una vez multiplica mantenimiento y riesgo en actualizaciones. Si se puede modelar con parámetros, hazlo con parámetros.

Qué puedes esperar en tiempos y beneficios

Cada empresa es un mundo, pero hay patrones razonables cuando la parametrización se encauza bien:

• Time-to-value más corto porque las cosas críticas se deciden antes de tocar producción. Una puesta en marcha escalonada (por módulos o por sedes) suele funcionar mejor que el “todo a la vez”.

• Menos tickets post-arranque. Los más habituales (facturas con series incorrectas, impuestos mal definidos, permisos demasiado amplios, inventarios desalineados) desaparecen cuando el diseño y la UAT toman en serio esos puntos.

• Cierres contables más rápidos: numeraciones limpias, reglas fiscales coherentes y catálogos ordenados hacen que la contabilidad “respire”.

• Escalabilidad: abrir un nuevo canal, añadir un almacén o incorporar otra sociedad deja de ser una odisea si la base de parámetros está pensada para crecer.

Una última idea: la parametrización no es un evento. Es un activo vivo. Cada cambio relevante (nueva línea de negocio, nueva política de precios, cambio fiscal) merece una mini-ronda de diseño → cambio controlado → prueba → despliegue.