Implantación ERP por fases o big bang: cómo decidir

Decide qué cambia en cada puesta en marcha

Una implantación ERP por fases no consiste simplemente en activar menos pantallas. La primera decisión es definir la unidad de cambio: un proceso completo, un grupo de módulos, una sociedad, una sede o un conjunto de usuarios. Microsoft recomienda que la estrategia de publicación responda a los objetivos del negocio, la tolerancia al riesgo, los recursos y el tiempo disponibles. Sin esa definición, la palabra fase solo divide el calendario y no reduce necesariamente el impacto.

El mapa debe seguir procesos de extremo a extremo. Un pedido puede comenzar en ventas, reservar existencias, generar preparación, expedición, factura y asiento. Separar ventas de almacén parece modular, pero puede obligar a construir una conexión temporal y a decidir qué sistema confirma el stock. Lo mismo ocurre con clientes, proveedores, tarifas, lotes, impuestos o autorizaciones. Una fase solo es autónoma cuando sus entradas, salidas y responsables están identificados.

También se documenta qué obliga a retirar el sistema anterior. Puede existir una fecha contractual, una versión sin soporte, un cierre contable o una limitación técnica que impida convivir durante meses. En otros casos, mantener temporalmente el legado permite comparar resultados. La estrategia no se elige por preferencia del proveedor: se contrasta con la ventana real de cambio, las dependencias externas, la capacidad del equipo y el coste de operar la transición.

Cada puesta en marcha necesita un alcance aceptable. Se separa lo imprescindible para trabajar desde el primer día de las mejoras que pueden llegar después. Se anotan usuarios, procesos, datos, integraciones, permisos, informes y formación incluidos, junto con criterios observables: registrar un pedido, conciliar los saldos, cerrar una expedición o emitir una factura. Una lista de funciones terminadas no demuestra que el proceso empresarial pueda completarse.

Compara big bang, fases y operación paralela

En un despliegue big bang, la solución completa entra en producción y el sistema anterior se retira para todos los usuarios en una misma fecha. La transición puede ser más corta y requiere menos interfaces temporales. A cambio, concentra la formación, la migración, el soporte y el riesgo operativo en una sola ventana. Microsoft lo plantea como una opción posible para implantaciones pequeñas y sencillas, cuando la organización puede asumir un cambio amplio y ha preparado continuidad y soporte.

El despliegue por fases reparte las puestas en marcha por módulos, prioridades, unidades de negocio o ubicaciones. Limita el alcance de un fallo inicial y permite incorporar lo aprendido a las siguientes etapas. Sin embargo, multiplica los cortes, alarga el periodo de cambio y hace más compleja la migración escalonada. Puede exigir conexiones entre el ERP nuevo y el legado, además de equipos que sostengan una fase en producción mientras preparan la siguiente.

La operación paralela mantiene durante un tiempo el sistema anterior y el nuevo. Microsoft la describe sobre todo como una técnica de validación: permite aprender y comparar, pero no elimina la necesidad de decidir cuál manda. Si los dos aceptan pedidos o modifican maestros sin reglas de sincronización, la supuesta seguridad crea datos divergentes. Deben fijarse el proceso comparado, el periodo, el responsable de resolver diferencias y la condición que permite apagar el sistema anterior.

En la práctica puede combinarse más de un modelo. Una empresa puede realizar arranques concentrados por sede o por cadena de procesos, en vez de activar un único módulo aislado o cambiar toda la organización a la vez. Esa combinación es una inferencia de las alternativas descritas por Microsoft, no una receta universal. Lo importante es que cada corte tenga valor de negocio, dependencias controlables y un límite claro para la convivencia.

La comparación debe incluir trabajo temporal, no solo la fecha final. Un plan por fases puede reducir el impacto de cada arranque y a la vez consumir más esfuerzo en interfaces, conciliaciones y soporte repetido. Un big bang puede ahorrar esa convivencia y exigir más capacidad simultánea para pruebas, formación y atención posterior. La propuesta debe mostrar ambos efectos para que dirección elija riesgo y recursos de forma consciente.

Cuenta la complejidad temporal de datos e integraciones

La coexistencia empieza con una matriz de datos. Para clientes, artículos, proveedores, tarifas, existencias, pedidos, facturas, saldos y documentos se indica qué sistema crea, modifica y consulta durante cada fase. También se decide cómo viajan los cambios y qué ocurre si la sincronización falla. Dos bases actualizadas por usuarios distintos no forman una copia de seguridad: forman dos versiones de la realidad que después habrá que conciliar.

Las interfaces temporales requieren contrato, monitorización y retirada. Se documentan campos, frecuencia, identificadores, tratamiento de duplicados, reintentos, errores y responsable. Una integración que solo existe durante la transición puede ser igual de crítica que una definitiva, porque conecta el proceso precisamente cuando el equipo trabaja bajo presión. Su fecha de baja y la prueba que permite eliminarla deben estar en el plan desde el principio.

La migración tampoco se reduce a importar maestros. SAP incluye en el cutover las transacciones abiertas, los saldos iniciales y la conciliación contable antes de cerrar el legado. Según el proceso pueden existir pedidos parcialmente servidos, anticipos, lotes, series, reservas, devoluciones o documentos pendientes. La guía de migración de datos a un ERP explica cómo preparar ensayos, recuentos y conciliaciones; la estrategia de despliegue decide en qué corte se ejecuta cada uno.

El esfuerzo de una fase incluye preparar datos, probar, formar, comunicar, cortar, validar y dar soporte. Si hay cuatro puestas en marcha, parte de ese trabajo se repite cuatro veces. También puede prolongarse el mantenimiento de licencias, infraestructura o conocimiento del sistema anterior. No se inventa una cifra universal: el presupuesto debe separar construcción definitiva, trabajo de transición y soporte de cada arranque para poder comparar modelos equivalentes.

Antes de elegir, conviene responder preguntas concretas: ¿qué proceso puede terminar de principio a fin en la primera fase?, ¿qué maestros comparten ambos sistemas?, ¿qué transacciones pueden quedar abiertas?, ¿qué integraciones temporales son necesarias?, ¿quién concilia las diferencias y cuándo?, ¿qué equipo atiende producción mientras continúa el proyecto? Si estas respuestas no existen, dividir el alcance puede desplazar el riesgo en lugar de reducirlo.

Prepara cada cutover como una decisión reversible

Cada salida a producción necesita pruebas de integración, rendimiento y aceptación de usuarios con datos representativos. La lista de Microsoft añade revisión del alcance, roles correctos, migración, dependencias externas, formación y preparación del soporte. Los resultados deben cumplir criterios de salida firmados por responsables de negocio. Un usuario que ha visto una demostración no equivale a un proceso validado con sus excepciones y permisos reales.

El plan de cutover ordena tareas, tiempos, titular y sustituto, instrucciones, herramientas, verificaciones y aprobaciones. Incluye una reversión. Microsoft recomienda ensayarlo en un entorno de prueba con datos, personas y tiempos lo más cercanos posible al cambio real, corrigiendo el documento después de cada simulacro. El objetivo no es representar una ceremonia, sino demostrar que la ventana basta y que el equipo sabe cómo actuar cuando una tarea falla.

La reunión go/no-go utiliza condiciones escritas. Se comprueba que las pruebas han terminado, que los problemas críticos están resueltos o aceptados, que las migraciones se han ensayado, que producción está preparada y que existen recursos disponibles. Si una condición no se cumple, la decisión debe indicar si bloquea, si activa una alternativa o si se acepta con propietario y fecha. La presión del calendario no convierte una incidencia desconocida en un riesgo controlado.

La reversión define hasta qué punto puede volver el sistema anterior y cómo se tratarán los datos creados después del corte. En un despliegue por fases puede significar retirar una unidad concreta; en un big bang puede afectar a toda la organización. Copiar una base antes del cambio no basta si nadie conoce el tiempo de restauración, las dependencias o las transacciones que se perderían. El punto de no retorno debe ser visible para dirección y para quienes ejecutan el plan.

Tras cada puesta en marcha se activa un periodo de soporte reforzado con responsables, canales, prioridades y monitorización. Se revisan errores, integraciones, rendimiento, adopción y conciliaciones antes de cerrar la fase. El sistema anterior, sus accesos y las conexiones temporales se retiran cuando se cumplen las condiciones acordadas, no cuando termina la reunión de lanzamiento. La aceptación final incluye la capacidad de operar, mantener y recuperar el nuevo entorno.

Élite Solutions Tech puede ayudar desde Murcia a comparar una implantación ERP por fases con un arranque concentrado a partir de procesos, datos e integraciones reales. El servicio de ERP y CRM a medida concreta alcance, pruebas y entregables; las licencias, el producto elegido y los trabajos de terceros se valoran aparte. Para una primera reunión puedes indicar sedes, usuarios, procesos críticos y sistemas actuales en el formulario de contacto, sin enviar credenciales ni bases de datos.