Ir al contenido

Cómo evitar que tu equipo vuelva a Excel después de implementar un ERP

El verdadero hito de la Gestion de Cambio.
31 de agosto de 2026 por
Cómo evitar que tu equipo vuelva a Excel después de implementar un ERP
Andrea Lopez
| Todavía no hay comentarios

El sistema puede estar configurado, los datos migrados y la fecha de salida en vivo definida. Aun así, durante las primeras semanas puede ocurrir algo que pone en riesgo el proyecto: las personas vuelven a Excel, al sistema anterior o a sus controles manuales.

No suele ser un problema exclusivamente técnico. Cuando alguien no sabe resolver una excepción, no confía en la información o siente que el proceso nuevo le quita tiempo, vuelve al método que conoce.

El resultado es una operación paralela: una parte de la información queda en el ERP, otra en planillas y otra depende de personas clave. Eso genera retrabajo, poca visibilidad y decisiones tardías.

El error: creer que la adopción empieza con la capacitación

La adopción no empieza con una capacitación final ni se resuelve entregando un manual genérico.

Un manual puede ser un apoyo, pero no reemplaza la práctica ni la comprensión del proceso. Además, los procedimientos específicos de cada empresa deberían ser construidos por el propio cliente: deben reflejar sus flujos reales, excepciones, responsables y terminología interna.

La consultora debe capacitar, guiar los flujos, resolver brechas y acompañar la transición. El cliente, en cambio, debe asumir el conocimiento de su operación y convertirlo en procedimientos internos que su equipo pueda utilizar y mantener.

Antes del Go-Live, conviene separar tres conceptos:

  • Requisito: lo mínimo para operar. Por ejemplo, que quienes facturan o aprueban sepan realizar sus tareas, hayan probado sus flujos y tengan un canal para resolver dudas.

  • Deseo: que todo el equipo domine el sistema desde el primer día y no manifieste resistencia.

  • Supuesto: aquello que nadie verificó, pero todos dan por hecho: “un manual bastará”, “se adaptarán rápido” o “ya saben que viene el cambio”.

El proyecto debe asegurar los requisitos y detectar los supuestos. Esperar una adopción perfecta desde el primer día no es un plan.

Dónde está el riesgo real

La pregunta clave no es si el ERP es intuitivo. Es qué ocurre hoy fuera del sistema oficial.

Ahí suelen aparecer planillas paralelas, aprobaciones informales, controles personales o conocimiento concentrado en una sola persona. No siempre son malas prácticas por falta de voluntad: a veces son soluciones que el equipo creó para compensar procesos poco claros o herramientas que ya no acompañaban la operación.

También conviene preguntarse:

  • ¿Cómo se enteró el equipo de que cambiará de sistema?

  • ¿Quiénes son los usuarios más impactados?

  • ¿Qué procesos son críticos para no detener la operación?

  • ¿Qué pasó la última vez que la empresa cambió una herramienta o proceso?

  • ¿Qué tareas hoy dependen de una persona o de una planilla?

  • ¿Quién será responsable de documentar y mantener los procedimientos internos?

Estas respuestas permiten anticipar resistencia y planificar el acompañamiento antes de que el equipo busque caminos alternativos.

Cuatro acciones para lograr adopción

1. Entiende el proceso antes de configurarlo

No automatices un proceso que todavía está mal definido. Antes de parametrizar, valida con los usuarios cómo funciona realmente el trabajo: tareas manuales, excepciones, aprobaciones y decisiones que hoy ocurren fuera de cualquier sistema.

La configuración debe responder a procesos acordados, no a supuestos.

2. Involucra a los usuarios desde el inicio

La adopción se construye durante el proyecto, no después del Go-Live.

Involucrar a quienes usarán el sistema permite detectar hábitos, brechas y dudas reales. Además, evita que la capacitación sea genérica: quien factura, aprueba, controla inventario o revisa información de gestión necesita practicar el flujo que le corresponde.

El SPOC y los usuarios clave no deberían limitarse a asistir a sesiones. Deben probar los procesos, validar resultados y participar en la construcción de sus procedimientos internos. No se trata de duplicar la documentación estándar de Odoo, sino de dejar claro cómo opera la empresa dentro del sistema.

El objetivo no es que todos conozcan cada función, sino que cada rol pueda operar correctamente su parte del proceso y sepa dónde acudir ante una excepción.

3. Prepara las primeras semanas de operación

Durante la salida en vivo aparecerán dudas. Si no existe una forma clara de resolverlas, las personas buscarán el método anterior para no frenar su trabajo.

Por eso, el Go-Live debe incluir un canal de escalamiento y acompañamiento funcional por un período acordado. Esto no elimina toda resistencia, pero permite resolver brechas operativas antes de que se conviertan en una nueva rutina paralela.

También es importante verificar que el equipo esté usando el sistema después de los primeros días. A veces las personas vuelven a sus herramientas anteriores por frustración, temor o costumbre, incluso cuando el nuevo flujo ya está disponible.

4. Prioriza el estándar antes de personalizar

No todos los requerimientos requieren desarrollo a medida.

La configuración ajusta Odoo a procesos definidos. El cambio de proceso ordena actividades antes manuales o descentralizadas. Una integración conecta sistemas externos cuando es necesario mantener la continuidad operativa. Un desarrollo debe evaluarse solo si existe una necesidad concreta que no puede resolverse adecuadamente con funcionalidad estándar, configuración o ajustes de proceso.

Personalizar sin ese análisis aumenta complejidad, puede dificultar actualizaciones futuras y crear dependencia tecnológica. La decisión responsable es mantener el núcleo del sistema lo más cercano posible al estándar y justificar cada excepción.

Cuándo revisar el caso con mayor profundidad

Una capacitación adicional no basta cuando la empresa depende de personas clave, mantiene múltiples planillas paralelas, no tiene procesos claros o enfrenta un cambio importante en su manera de operar.

En esos casos, la gestión del cambio debe comenzar en el levantamiento: identificar usuarios afectados, validar procesos reales, priorizar flujos críticos y anticipar los puntos de resistencia. También debe definirse quién será responsable, del lado del cliente, de mantener los procedimientos internos actualizados después de la salida en vivo.

Un ERP puede funcionar técnicamente y, aun así, no estar listo para ser adoptado por la organización.

El éxito empieza cuando las personas dejan de necesitar el camino paralelo

Implementar un ERP no es solo reemplazar una herramienta. Es cambiar cómo la empresa registra, coordina, controla y toma decisiones.

El éxito no ocurre cuando el sistema queda configurado. Ocurre cuando las personas pueden trabajar dentro del nuevo flujo sin necesitar Excel, controles manuales o el sistema anterior.

Antes del Go-Live, comparte este artículo con tu equipo y revisen una pregunta: ¿qué tendría que pasar para que alguien prefiera volver a su planilla?

La respuesta probablemente mostrará el riesgo que aún falta abordar.

CTA: Antes de salir en vivo, revisa procesos críticos, perfiles de usuario, responsables internos y el canal de soporte para las primeras semanas. Asegúrate de que el SPOC y los usuarios clave hayan probado los flujos que operarán y sepan cómo documentar sus procedimientos internos.

Preguntas frecuentes

¿Es normal que el equipo extrañe el sistema anterior?

Sí. La familiaridad genera seguridad, aunque el sistema anterior tenga limitaciones. Lo importante es anticipar esa resistencia, escuchar sus causas y acompañar al equipo en el uso de los nuevos flujos.

¿Basta con un manual para asegurar la adopción?

No. Un manual no reemplaza la práctica, las pruebas ni el acompañamiento posterior al Go-Live.

Además, los procedimientos específicos de la empresa deberían ser elaborados y mantenidos por el cliente, porque necesitan reflejar sus procesos y terminología interna. La consultora puede facilitar capacitación, criterios funcionales y recursos estándar; el cliente debe apropiarse del conocimiento operativo.

¿Siempre hay que desarrollar funcionalidades para lograr adopción?

No. Primero deben evaluarse las capacidades estándar, la configuración y los ajustes de proceso. El desarrollo es una excepción, no el punto de partida.

Nota de precisión: No se puede prometer ausencia de resistencia ni un plazo exacto de adopción. Depende de los procesos actuales, las personas impactadas y los hábitos operativos de cada empresa.



Iniciar sesión dejar un comentario
Odoo después del Go-Live: implementación vs. Mesa de Soporte
Entiende qué ocurre con los pendientes, incidencias y nuevos requerimientos de Odoo después del Go-Live y quién debe gestionarlos.