Cambiar el ERP (sistema de gestión administrativa-contable) no es una decisión habitual. Se hace cada 8, 10 o 15 años, y cada vez que aparece la conversación interna arrastra sentimientos encontrados: el sistema actual ya no alcanza, pero el miedo al cambio es enorme. Razonable: encarar un cambio de ERP mal gestionado puede detener operaciones durante semanas, generar costos impredecibles y dejar a la empresa trabajando peor que antes durante meses.
Las estadísticas internacionales son duras: entre el 30% y el 50% de los proyectos de ERP en PyMEs no cumplen con el alcance, el costo o el tiempo planificado. Lo interesante es que la mayoría de esos fracasos no tienen que ver con haber elegido el ERP equivocado. Tienen que ver con cómo se condujo la implementación.
Los cinco errores que aparecen todo el tiempo
1. Elegir por el ERP, no por el problema. Muchas empresas empiezan la búsqueda preguntando “¿qué ERP conviene?”. La pregunta correcta es “¿qué problema queremos resolver?”. Sin esa claridad, todos los ERPs se ven parecidos y la decisión se termina tomando por precio, por relación comercial o por intuición.
2. No documentar el estado actual. Sin un inventario honesto de cómo se hacen hoy las cosas (qué datos hay, qué procesos están escritos, qué vive en la cabeza de la gente), el nuevo proveedor va a implementar lo que cree que la empresa hace. Después de la implementación aparecen las sorpresas: “acá calculábamos la comisión de otra manera”, “este dato venía de otra planilla”, “el remito tenía que imprimirse así”.
3. Subestimar la migración de datos. La información histórica (clientes, productos, saldos, facturas pendientes) tiene que pasar al sistema nuevo. Ese trabajo es técnico y laborioso. Muchos proyectos fallan porque el presupuesto de migración fue mínimo y los datos llegan mal, incompletos o con errores que se arrastran durante años.
4. Capacitar poco. El ERP nuevo es una herramienta distinta. La gente que usaba el anterior necesita aprender flujos nuevos, atajos nuevos, formas nuevas de mirar la información. Un día de capacitación antes del arranque no alcanza para equipos grandes o para procesos complejos. El resultado es que se usa mal, se ingresan datos mal, se tarda más que antes.
5. Elegir un arranque “big bang”. Pasar de un sistema al otro de un día para el otro, sin ejecución en paralelo, sin plan de contingencia. Si algo sale mal, no hay red. Los proyectos más exitosos suelen correr los dos sistemas en paralelo durante uno o dos meses, contrastando resultados, antes de apagar el viejo.
Qué hacer antes de empezar a ver proveedores
Tres ejercicios internos, previos a cualquier búsqueda, evitan la mayoría de los problemas:
Documentar los procesos críticos con un nivel de detalle mediano. Cómo se cotiza, cómo se factura, cómo se gestiona el stock, cómo se manejan las cobranzas. Un documento por proceso, con quién interviene, qué datos entran, qué datos salen. Este entregable es el input para que el proveedor cotice algo realista.
Listar los requisitos diferenciadores. No “queremos facturación electrónica” (eso lo tienen todos). Sino “necesitamos manejar tres puntos de venta con stock separado pero cotización unificada”. Son los puntos donde el ERP genérico no va a alcanzar y hay que pedir funcionalidad específica o desarrollo.
Definir los datos a migrar. Clientes, artículos, proveedores, saldos abiertos. Qué volumen, con qué calidad actual, qué va a requerir limpieza. Es el punto donde muchas empresas descubren que sus datos actuales no están en el estado que imaginaban.
Con esos tres documentos, la conversación con posibles proveedores pasa de “muéstreme qué hace su ERP” a “explíqueme cómo su ERP resuelve estos procesos puntuales”.
Qué pedir a los proveedores
Más allá de la demo pulida, conviene exigir:
– Cotización detallada discriminando licencia, implementación, migración de datos, capacitación, soporte post-arranque. No un número total.
– Cronograma realista con hitos. Los ERPs chicos suelen implementarse en 3-6 meses; los medianos, en 6-18 meses. Quien promete 4 semanas está subestimando o mintiendo.
– Casos de referencia en empresas parecidas. Llamar a esas referencias y preguntar cómo fue la implementación, qué problemas aparecieron, si volverían a elegir al mismo proveedor.
– Acceso a los datos. Si mañana se quiere cambiar de proveedor, ¿los datos se pueden exportar en formato abierto? Los ERPs que atan los datos a formato propietario son una trampa de largo plazo.
– Plan de migración con cronograma y responsabilidades.
– Estructura de soporte post-arranque: cuántos días de presencia incluida, cuánto cuesta la hora adicional, tiempos de respuesta.
La fase crítica: los tres primeros meses post-arranque
La implementación no termina cuando el sistema arranca. Los primeros 90 días son los más intensos:
– Aparecen los casos borde que no se habían anticipado.
– La gente descubre que “en el sistema viejo esto se hacía con un click” y quiere el mismo comportamiento.
– Se encuentran errores de migración que impactan en cobranzas, stock, contabilidad.
– Los reportes gerenciales tienen que ajustarse para que los indicadores sean comparables con el histórico.
En esos tres meses hay que tener presupuesto, tiempo y disponibilidad del proveedor. Los proyectos que colapsan en esta fase son los que se quedaron sin plata o sin energía después del arranque inicial.
La decisión de no cambiar
A veces el ejercicio de evaluación termina en una conclusión incómoda: el ERP actual, con sus limitaciones, sigue siendo mejor opción que un cambio que costaría 50.000 o 100.000 dólares y un año de dolor. No es fracaso: es un diagnóstico honesto.
Ese resultado aparece más seguido de lo que uno imagina, sobre todo cuando se documenta bien el costo total del cambio. Puede llevar a decisiones parciales: migrar solo ciertos módulos, agregar una capa de BI encima del ERP viejo, automatizar los puntos débiles sin reemplazar todo.
¿Hay una conversación latente en tu empresa sobre cambiar el sistema de gestión? Antes de empezar a ver demos, vale invertir dos o tres semanas en documentar los procesos actuales y listar los requisitos reales. Ese trabajo interno, que parece aburrido, es lo que separa una implementación exitosa de una pesadilla.
