Esta guía ayuda a responder una pregunta cara antes de firmar: ¿este sistema de gestión empresarial resolverá nuestros problemas o los congelará dentro de la herramienta? El principio de fondo es sencillo: el software no crea orden; lo requiere.
Para qué sirve
Un ERP, un CRM, un MES o un sistema de almacén codifica procesos, datos, responsabilidades y decisiones. Si esos elementos están claros y son estables, la herramienta puede acelerarlos. Si son ambiguos, la implantación obligará a decidir bajo presión o fijará la confusión en el sistema.
“Prematuro” no significa que la empresa no merezca la herramienta. Significa que comprarla ahora puede costar más que esperar, porque parte del precio se pagará como desorden codificado.
Cuándo usarla
Úsela cuando se esté evaluando un ERP, CRM, MES o sistema de almacén, idealmente antes de las demostraciones de proveedores.
Úsela cuando el argumento sea “necesitamos orden y el sistema nos lo dará”. Esa frase invierte la secuencia correcta.
Úsela también cuando un sistema ya implantado no ha cumplido las expectativas. A veces el problema no fue solo el proveedor, sino una implantación prematura.
Antes de empezar
El test solo funciona si “todavía no” es un resultado aceptable. Si la decisión ya está tomada y solo se busca validación, el análisis molestará.
Ponga sobre la mesa el coste completo: licencias, implantación, personalizaciones y tiempo interno. Este último rara vez aparece bien en la oferta y puede igualar el coste externo.
Secuencia operativa
Paso 1 — Escriba los problemas sin nombrar el sistema.
Una frase por problema: “no conocemos el margen por pedido”, “los pedidos se pierden entre comercial y producción”, “el almacén no cuadra”.
Si la lista no puede escribirse y solo aparece “necesitamos estar más estructurados”, deténgase: quizá se está comprando un símbolo de orden, no una herramienta.
Paso 2 — Haga la prueba del proceso.
Para cada problema pregunte: ¿el proceso existe en una sola versión? ¿Las responsabilidades en los traspasos están claras? ¿El proceso es estable o está cambiando?
Si comercial y producción describen flujos distintos, el sistema tendrá que escoger uno o adaptarse a varios. Si la RACI es confusa, los datos nacerán sucios. Si el proceso está cambiando, codificarlo ahora significa pagar dos veces.
Paso 3 — Haga la prueba del dato.
El ERP vive de datos maestros: artículos, listas de materiales, tarifas, clientes, proveedores, rutas y centros de coste.
Pregunta directa: ¿esos datos existen, están limpios y tienen responsable? Si la respuesta es “los limpiaremos durante la implantación”, traduzca: meses de trabajo no presupuestado o arranque con datos sucios.
Paso 4 — Compruebe si el problema es realmente de herramienta.
“ No sabemos márgenes” puede significar que el sistema actual no los calcula, o que nadie registra horas y costes reales.
“Los pedidos se pierden” puede significar herramienta débil, o un traspaso sin responsable.
La prueba útil: ¿podríamos resolver este problema mañana con una hoja compartida y una regla? Si sí, el problema no es principalmente tecnológico.
Paso 5 — Resuma en tres listas.
Verde: problemas con proceso único, responsabilidades claras y datos preparados.
Amarilla: problemas con requisitos previos solucionables en 60–90 días.
Roja: problemas con procesos inestables, gobernanza no resuelta o propiedad de datos confusa. Aquí el sistema es prematuro.
Paso 6 — Si se sigue adelante, empiece pequeño y en secuencia.
Empiece por el perímetro verde. Tome las decisiones de proceso antes de que llegue el implantador. El proveedor debe configurar decisiones ya tomadas, no tomarlas por cansancio.
Trate las personalizaciones con sospecha. A veces son confusiones de proceso compradas a alto precio.
Resultado esperado
El resultado esperado son las tres listas, sobre todo la roja: qué no implantar todavía y por qué hacerlo ahora costaría más que esperar.
Normalmente también aparece un plan de 60–90 días: mapas de proceso, RACI, limpieza de datos y pilotos con herramientas actuales.
Errores que evitar
Comprar el sistema para comprar orden.
Permitir que el implantador decida procesos no resueltos.
Empezar con una implantación total.
Dejar la limpieza de datos para la implantación.
Personalizar por defecto.
Usar esta guía como excusa para aplazar siempre.
Ejemplo
Una empresa metalmecánica de 45 personas está a punto de firmar un ERP por 140.000 euros más implantación. Los dolores son márgenes desconocidos, pedidos perdidos entre comercial y producción y almacén poco fiable.
El test previo cambia la decisión. Los márgenes son amarillo-rojo: nadie registra horas porque nadie responde de ello. Los pedidos perdidos son rojo: hay tres versiones del flujo de pedido. El almacén es verde: datos decentes, proceso estable y responsable claro.
La decisión final reduce el alcance inicial: almacén y ciclo de compras primero; el resto espera a requisitos verificados.
Conexión MARTRO
En la lectura MARTRO, la secuencia es un principio. Primero legibilidad: proceso único, responsabilidades claras, datos con propietario. Después codificación.
El software amplifica lo que encuentra. Si encuentra claridad, la escala. Si encuentra ambigüedad, la vuelve más rígida y cara.
Paso siguiente
Si el test queda en amarillo por flujos y responsabilidades, continúe con mapa de proceso y RACI.
Si la herramienta automatiza decisiones, revise derechos de decisión y arquitectura de decisiones.
Preguntas frecuentes
¿Qué significa que un ERP sea prematuro? Que quizá será necesario, pero procesos, responsabilidades o datos aún no están listos para codificarse.
¿Puede un ERP imponer disciplina? Puede exigir campos y flujos, pero no resolver por sí solo propiedad, secuencia y gobernanza.
¿Hay que esperar a tenerlo todo perfecto? No. Hay que empezar por el perímetro preparado y preparar el resto.
¿Cuál es la alerta más común? “Limpiaremos los datos durante la implantación”.
¿Una hoja compartida puede ser un piloto serio? Sí. Prueba si la organización puede sostener el comportamiento antes de pagar por un sistema completo.
Licencia
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International. Atribuci?n requerida: Fuente: MARTRO Observatory, "Cómo evaluar si un ERP es prematuro", https://www.martrosystems.eu/es/knowledge/come-valutare-se-un-erp-e-prematuro.
CLEW
Si la aplicaci?n interna se bloquea, el problema ya no es solo documental: requiere verificaci?n multi-rol.
Explorar CLEW