¿Cuánto tiempo lleva implementar un ERP? Cronogramas realistas

Una respuesta fase por fase sobre cuánto dura un proyecto de ERP, los factores que lo extienden y un cronograma alternativo para un núcleo contable que se integra mediante una API.

Una empresa pequeña que migra a un ERP en la nube con módulos estándar suele necesitar entre tres y seis meses desde la firma hasta la puesta en marcha (go-live). Una empresa mediana con varias entidades, flujos de trabajo personalizados e integraciones suele requerir de seis a doce meses. El despliegue en una gran multinacional toma entre uno y tres años, a menudo por fases según la región o la unidad de negocio. Estos rangos coinciden con lo que publican los socios de implementación y lo que reportan los equipos financieros; no provienen de una encuesta y un proyecto específico puede salirse de ellos en cualquier dirección.

El número único que la gente busca no existe, porque la "implementación" consta de nueve trabajos independientes, y la duración de cada uno depende de las decisiones que el comprador tome antes de que comience el proyecto. Este artículo divide el cronograma en dichas partes, muestra qué alarga cada una y luego describe un calendario diferente: el que se obtiene cuando el núcleo contable es una API con la que se comunica su propio software, en lugar de un sistema que debe configurar.

Las nueve fases y qué impulsa a cada una

Fase	Duración típica	Factores que determinan la duración
Selección	1–3 meses	Cantidad de proveedores preseleccionados, rondas de demostración, llamadas de referencia, normas de compras
Diseño	2–8 semanas	Cuántos procesos se deben mapear, si el equipo coincide en ellos, qué tanto se acepta el flujo estándar del proveedor tal cual
Migración de datos	4–16 semanas	Calidad de los datos maestros (master data), cuántos años de historial se transfieren, cantidad de sistemas de origen
Configuración	4–12 semanas	Cantidad de entidades, planes de cuentas (charts of accounts), países, regímenes fiscales, flujos de aprobación
Integración	4–20 semanas	Cantidad de sistemas a conectar (banco, nómina, comercio electrónico, CRM, almacén), calidad de la API de cada lado
Pruebas	3–8 semanas	Cantidad de escenarios de extremo a extremo, si los datos de prueba son realistas, cuántos defectos encuentra la primera pasada
Capacitación	2–6 semanas	Cantidad de empleados, diversidad de roles, qué tan diferente es el nuevo proceso en comparación con el anterior
Puesta en marcha (Go-live)	1–2 semanas	Método de transición (big-bang o por fases), sincronización con el cierre de periodo
Soporte intensivo (Hypercare)	4–12 semanas	Cantidad de defectos abiertos al momento del lanzamiento, primer cierre de fin de mes, primera declaración de IVA desde el nuevo sistema

Las fases se superponen en la práctica. La integración comienza mientras la configuración aún está en marcha; la capacitación a menudo se cruza con las pruebas. Un plan realista no es la suma de la columna, pero la ruta crítica suele pasar por la migración de datos y la integración, y esos dos aspectos concentran la mayoría de los retrasos.

Lo que alarga el proyecto

Personalización. Cada cambio en el comportamiento estándar del proveedor debe especificarse, construirse, probarse, documentarse y volver a probarse en cada futura actualización. Un proyecto que acepta el proceso estándar para el 90% de los flujos y personaliza el resto suele terminar; un proyecto que comienza replicando las pantallas del sistema anterior tiende a no hacerlo.

Datos maestros deficientes. Clientes duplicados, proveedores con tres grafías distintas, artículos sin unidad de medida, un plan de cuentas que creció por acumulación durante una década. La migración no puede ser más rápida que la limpieza, y la limpieza la realizan personas que también tienen sus trabajos habituales. Esta es la causa más común de retraso en la fecha de lanzamiento y la menos visible en el plan original.

Múltiples entidades. Cada entidad legal necesita su propio plan contable, numeración, registro de IVA, cuentas bancarias y cierre de periodo. Los flujos intercompañía entre ellas requieren su propio diseño. Multiplique la fase de configuración por la cantidad de entidades y añada el diseño de consolidación por encima.

Impuestos multinacionales. Una empresa que vende a varios Estados miembros de la UE debe configurar correctamente en el nuevo sistema las reglas de lugar de entrega, la inversión del sujeto pasivo (reverse charge), la declaración OSS y los formatos de presentación locales antes de que venza la primera declaración. Si la localización que ofrece el proveedor para un país ha sido desarrollada por un socio y no es nativa, la disponibilidad de dicho socio pasa a formar parte de la ruta crítica.

Integraciones con API débiles. Un ERP que solo expone importaciones basadas en archivos obliga a cada sistema conectado a trabajar mediante lotes (batch), y cada patrón de lotes requiere una lógica de conciliación que alguien debe escribir y probar.

Una fecha de lanzamiento fijada antes de definir el alcance. Cuando la fecha se establece por motivos políticos y el alcance se descubre más tarde, el proyecto recorta las pruebas o pospone la fecha. Ambas opciones resultan costosas.

Lo que acorta el proyecto

Aceptar los procesos estándar del proveedor en las áreas donde el negocio no presenta diferencias reales.
Limpiar los datos maestros antes de que comience el proyecto, no durante este.
Migrar saldos iniciales y partidas abiertas en lugar de todo el historial, manteniendo el sistema anterior accesible para consultas.
Elegir una fecha de transición que coincida con el cierre de un periodo, con un balance de comprobación (trial balance) cerrado y conciliado.
Designar a un único responsable por módulo con la autoridad para tomar decisiones.
Realizar pruebas con documentos reales de los últimos doce meses, no con muestras inventadas.
Elegir un sistema cuya API permita construir y probar las integraciones en paralelo con la configuración, en lugar de hacerlo después.

Un calendario diferente: el núcleo contable con API primero (API-first)

Los cronogramas anteriores describen un sistema que los usuarios configuran mediante pantallas y luego operan a través de pantallas. Existe otra tipología de proyecto que responde a un reloj diferente. Cuando el núcleo contable es una API de contabilidad, el trabajo de integración se adelanta y la mayor parte de la fase de configuración desaparece porque hay mucho menos que configurar: el plan contable, las reglas fiscales y los formatos de presentación ya vienen integrados en el producto.

Así es como funciona con Nordlet, descrito según las capacidades actuales del producto y no como una promesa:

Día uno: una empresa en entorno de pruebas (sandbox). Se crea una empresa de pruebas desde la aplicación o mediante una llamada a la API. Se comporta exactamente igual que una empresa real, con los mismos módulos y los mismos puntos de acceso (endpoints), y puede crear tantas como necesite. La guía de inicio (getting-started guide) detalla los primeros llamados.

Del día uno al cinco: el primer flujo operativo. Crear un socio, crear una factura, emitirla, recibir un pago, leer el asiento contable (journal entry) generado por la emisión. Cada operación es una solicitud POST /v1/{module}/{resource}/{action} con un cuerpo en JSON, y existen SDKs tipados para nueve lenguajes, por lo que el primer flujo requiere apenas unas pocas líneas de código. Los reintentos son seguros porque el encabezado Idempotency-Key reproduce la respuesta almacenada en lugar de crear una segunda factura.

Semana dos: historial. El importador de migración (migration importer) toma el plan de cuentas, los socios, los artículos, los saldos iniciales o todo el historial de asientos, las facturas abiertas de clientes y proveedores, los activos fijos con su depreciación acumulada y el inventario disponible, y los registra en una sola transacción de base de datos. El punto de acceso de solo validación (migration/books/validate) ejecuta todas las comprobaciones sin modificar nada, lo que permite iterar sobre el paquete hasta que no arroje errores, para luego ejecutar migration/books/import una sola vez. Si alguna fila falla, no se almacena nada.

Semanas de la dos a la cuatro: el resto de la integración. Canales bancarios (bank feeds) mediante conexiones PSD2, importación de extractos en formato camt.053, exportaciones de Stripe, webhooks como sale_invoice.paid para que su sistema reaccione a los eventos en lugar de consultar constantemente (polling). Cada pieza es un punto de acceso independiente y puede ser desarrollada por un programador distinto en paralelo.

Cumplimiento normativo: ya registrado. El tratamiento de IVA para una venta transfronteriza se resuelve mediante el motor de IVA de la UE (EU VAT engine), y el calendario de declaraciones del país de la empresa se completa a partir de reglas integradas. La tabla de soporte de declaraciones (filing support table) detalla, para los 30 países, qué plazos presenta directamente Nordlet, para cuáles genera un archivo y cuáles deben introducirse de forma manual. Nada de esto constituye trabajo de proyecto.

El cierre de periodo como prueba. El primer cierre de fin de mes es donde un proyecto de ERP descubre si realmente funcionó. Con un libro mayor inmutable y el bloqueo de periodos (period locking), cualquier asiento fechado en un mes bloqueado se rechaza con un código 409; de este modo, el cierre se impone por diseño del sistema y no por disciplina de los usuarios, y los errores de integración que habrían aparecido durante el soporte intensivo (hypercare) emergen antes en el entorno de pruebas.

Límites honestos de este calendario: cubre el núcleo contable, fiscal y de presentaciones. Si su proyecto también requiere gestión de almacenes, programación de fabricación o un CRM, estos elementos se implementan como módulos de Nordlet que se integran de la misma manera (inventario, producción, pedidos de comercio electrónico, clientes potenciales) o como sistemas independientes, y el trabajo de integración para estos últimos sigue corriendo por su cuenta. Nordlet es además un producto joven, en acceso temprano en 2026 e incorporando socios de diseño, lo cual constituye un factor a considerar en cualquier decisión de proveedor.

Cómo estimar su propio proyecto

Cuente las entidades, los países y los registros de IVA. Cada uno representa trabajo de configuración en un ERP tradicional y un registro de empresa en uno basado en API.
Cuente las integraciones y verifique la API de cada sistema antes de firmar. Una interfaz basada únicamente en archivos duplica aproximadamente la estimación de integración.
Decida qué cantidad de historial migrar. Los saldos iniciales más las partidas abiertas toman semanas; todo el historial de varios años toma meses.
Establezca la fecha de transición a partir del calendario de periodos, y no al revés. Un cierre de año o de trimestre con un balance de comprobación conciliado constituye la transición más económica posible.
Asuma que el primer cierre tardará el doble que uno normal y reserve presupuesto de soporte intensivo para la primera declaración de IVA y la primera ejecución de nóminas desde el nuevo sistema.
Redacte la prueba de aceptación antes de que comience el proyecto: la lista de documentos, informes y declaraciones que el nuevo sistema debe emitir correctamente para el primer mes cerrado. El plan de pruebas de preproducción (pre-production test plan) sirve como plantilla para la parte contable.

FAQ

¿Puede una implementación de ERP tomar menos de tres meses?

Sí, para una empresa de una sola entidad que acepta procesos estándar, migra únicamente saldos iniciales y cuenta con una o dos integraciones. Con un núcleo contable basado en API, el primer flujo de trabajo operativo se mide en días, y el elemento pendiente más largo suele ser el paquete de migración de datos.

¿Qué fase se retrasa con mayor frecuencia?

La migración de datos, seguida de la integración. Ambas dependen del estado de sistemas que el proveedor no controla: la calidad de sus datos actuales y las API de los sistemas que conecta.

¿Debemos migrar todo el historial o solo los saldos iniciales?

Los saldos iniciales y las partidas abiertas bastan para que el nuevo sistema esté completo a partir de la fecha de transición, y consumen una fracción del tiempo. Todo el historial resulta útil cuando se necesitan datos comparativos dentro del nuevo sistema o cuando el sistema anterior se va a desconectar por completo. El importador de Nordlet acepta ambas opciones.

¿Es un despliegue por fases más rápido que una transición de golpe (big-bang)?

Los despliegues por fases toman más tiempo en total, pero conllevan menos riesgo en cada paso y permiten que el equipo aprenda de la primera entidad antes de pasar a la siguiente. El enfoque big-bang es más corto cuando la organización es lo suficientemente pequeña como para que un fin de semana de transición cubra todo.

¿En qué se diferencia la "implementación" en un producto con API primero?

No hay un proyecto de configuración pantalla por pantalla. El trabajo consiste en la integración y la migración, realizado por desarrolladores frente a un entorno de pruebas, y la capa de cumplimiento normativo (reglas de IVA, formatos de presentación, calendarios) viene incluida con el producto. La contrapartida es que alguien de su equipo debe escribir código.