El ERP (Enterprise Resource Planning) es, en la mayoría de las empresas medianas, el sistema más crítico que existe. Sostiene operación, inventarios, facturación, contabilidad, compras y, frecuentemente, reportería regulatoria. Cualquier proyecto que toque el ERP implica un riesgo desproporcionado al del resto de los sistemas.
Cuando el proveedor del ERP desaparece, cambia de modelo de negocio o deja de dar soporte adecuado, las empresas enfrentan una decisión difícil: retomar el sistema actual, migrar a otro o vivir con el problema. Este artículo describe el protocolo para retomar o migrar un ERP sin perder datos ni interrumpir la operación.
Por qué el ERP es distinto
Un ERP tiene características que lo diferencian de otros sistemas:
- Compleja lógica acumulada: años de reglas de negocio, personalizaciones y excepciones.
- Datos críticos: pérdidas no se recuperan; corrupción causa incidentes regulatorios.
- Integraciones múltiples: con sistemas bancarios, impuestos, proveedores, facturación electrónica.
- Usuarios numerosos: decenas o cientos de personas que lo usan diariamente.
- Regulación: reportes a DIAN, Supersociedades, entidades sectoriales.
- Ciclo financiero: no se puede "pausar" el ERP durante cierres contables.
Todo esto implica que un proyecto de retoma o migración de ERP no tolera improvisación.
Las tres rutas posibles
Ruta 1: Retoma del ERP actual
Un nuevo equipo asume el sistema existente, lo documenta, lo estabiliza y lo mantiene. Se recomienda cuando:
- El ERP actual cubre bien los procesos del negocio.
- El código fuente está disponible (o se puede recuperar legalmente).
- La tecnología base, aunque vieja, aún tiene soporte.
- El costo de reemplazo sería significativamente mayor.
Es la ruta de menor riesgo y costo en la mayoría de los casos.
Ruta 2: Migración a un ERP comercial
Se reemplaza por SAP Business One, Oracle NetSuite, Microsoft Dynamics 365, Odoo, Siesa o similar. Se recomienda cuando:
- El ERP actual no cubre procesos nuevos que el negocio necesita.
- La personalización del ERP actual es baja y un producto estándar sirve.
- Hay presupuesto significativo (USD 150.000 a USD 1M+ según tamaño).
- El equipo puede dedicar 12-24 meses a la migración.
Ruta 3: Retoma + modernización progresiva
Se retoma el núcleo, se moderniza progresivamente. Se construyen interfaces modernas sobre el ERP actual y se migran módulos específicos en el tiempo. Es la ruta híbrida que mejor balance ofrece.
Protocolo paso a paso para una retoma
Fase 1: Diagnóstico intensivo (3-5 semanas)
El diagnóstico de un ERP es más profundo que el de otros sistemas:
- Inventario completo de módulos y su uso real (qué se usa, qué no).
- Mapeo de todas las integraciones (bancos, DIAN, facturación electrónica, nómina, e-commerce).
- Revisión de personalizaciones (cuáles son críticas, cuáles son legado innecesario).
- Entrevistas con usuarios de cada módulo.
- Análisis del modelo de datos.
- Evaluación del estado del código: calidad, documentación, tests.
- Validación de respaldos y capacidad de recuperación.
El entregable es un diagnóstico con priorización: qué atender primero, qué puede esperar, qué representa riesgo alto.
Fase 2: Estabilización en caliente (4-8 semanas)
Antes de emprender proyectos de mejora, se resuelven los problemas que están haciendo daño activo:
- Vulnerabilidades críticas de seguridad.
- Bugs que impactan operación o contabilidad.
- Integraciones rotas o frágiles.
- Respaldos deficientes.
Esta fase entrega tranquilidad operativa y legitima el proyecto ante usuarios.
Fase 3: Documentación (continua)
Se documenta el sistema a medida que se trabaja: arquitectura, módulos, flujos críticos, personalizaciones. La meta es que cualquier desarrollador nuevo pueda onboardearse en 2-3 semanas, no en 6 meses.
Fase 4: Gobernanza de cambios (inmediata y continua)
Un ERP sin gobernanza de cambios acumula personalizaciones salvajes. Desde el día uno se establece:
- Ambiente de desarrollo, pruebas y producción separados.
- Procedimiento formal de solicitudes y aprobaciones.
- Ventanas de mantenimiento programadas.
- Ciclo de pruebas obligatorio antes de producción.
Fase 5: Modernización progresiva (6-18 meses)
Con el sistema estabilizado, se abordan módulos específicos para modernizar: reportería, interfaces de usuario, integraciones adicionales, dashboards de BI. Cada módulo es un proyecto acotado.
Migración de datos: el punto más crítico
Si la decisión es migrar a un ERP nuevo (ruta 2), la migración de datos es el riesgo principal. Un protocolo probado:
1. Inventario de datos
Identificar todos los tipos de datos a migrar: maestros (clientes, productos, proveedores), transaccionales (facturas, órdenes, pagos), históricos, configuraciones.
2. Limpieza previa
Antes de migrar, limpiar el dato actual: duplicados, registros obsoletos, datos mal tipados. Migrar basura genera sistema nuevo con basura.
3. Mapeo de estructuras
Cada campo del origen debe mapearse a uno del destino. Campos sin mapa directo requieren lógica de transformación.
4. Migración de prueba (3-5 ciclos)
Migrar primero a un ambiente de pruebas. Validar con usuarios. Ajustar. Repetir hasta que los resultados sean consistentes.
5. Plan de corte
Definir el momento exacto de corte: cierre del sistema viejo, migración de datos finales, apertura del sistema nuevo. Típicamente un fin de semana.
6. Migración en caliente
Para empresas que no pueden parar, se mantienen ambos sistemas en paralelo por un período, con sincronización automática. Es complejo pero a veces necesario.
7. Validación post-migración
Auditoría de totales: saldos contables, cantidades de inventario, totales de cartera. Si los números no cuadran, hay problemas.
Errores comunes
Subestimar las personalizaciones
"Solo tenemos unas pequeñas modificaciones" suele traducirse a 400 horas de desarrollo al descubrirlas todas. Inventariar es crítico.
No involucrar a los usuarios clave
Los usuarios avanzados conocen el sistema mejor que el equipo de TI. Sin su participación, se pierden reglas implícitas.
Migrar en un cierre contable
Migraciones en períodos de cierre son recetas para desastre. Planificar en ventanas operativas estables (típicamente después de un cierre anual).
Sin plan de rollback
¿Qué pasa si la migración falla? Debe haber plan de regreso al sistema anterior hasta la próxima ventana. Sin esto, los equipos toman decisiones precipitadas.
No comunicar suficientemente
Los usuarios del ERP necesitan saber con anticipación qué cambia, cuándo y cómo. Capacitación, manuales, soporte en los primeros días: todos necesarios.
Conclusión
Un proyecto sobre el ERP es siempre de alto impacto y alto riesgo. Hacerlo bien requiere diagnóstico profundo, estabilización previa, gobernanza disciplinada y, si hay migración de datos, un protocolo muy detallado. No hay atajos.
En IT Efectivos hemos liderado retomas y migraciones de ERP en sectores como manufactura, logística, salud y servicios. Si tu ERP está en una situación crítica o estás pensando en una migración, una conversación inicial puede evitar errores costosos. Escríbenos.