Tiempo lectura: 5 minutos
Adopción de software interno: cómo formar a tus empleados en el nuevo ERP
La parte técnica de una implantación de ERP suele salir bien. La parte humana — que los empleados lo usen correctamente y de forma habitual — es donde la mayoría de los proyectos se quedan cortos.
La implantación de un ERP puede durar entre seis meses y dos años. Cuando llega el go-live, la empresa ha invertido en licencias, en consultoría, en configuración y en migración de datos. Lo que con frecuencia no se ha planeado con el mismo rigor es lo que ocurre después: que cada empleado, en su rol, use el sistema de la manera que el proyecto esperaba.
No es un problema de resistencia al cambio en sentido abstracto. Es un problema operativo muy concreto: el empleado recibe formación en el peor momento posible (el día que el sistema se activa), sobre funcionalidades que no necesita todas a la vez, y sin soporte en los días críticos en que los errores son más frecuentes y más caros.
Este artículo describe cómo estructurar la formación de ERP para que la adopción sea real, no solo documentada.
La formación de ERP se suele concentrar en el go-live por razones comprensibles: es cuando el sistema está disponible, cuando el equipo de proyecto tiene más presencia y cuando la presión de entregarlo es más alta. El problema es que es también el peor momento cognitivo para aprender algo nuevo.
En la semana del go-live, el empleado está gestionando al mismo tiempo su trabajo habitual, la incertidumbre sobre si el sistema funciona, y la formación sobre cómo usarlo. El resultado es que la formación se completa pero no se retiene. A las dos semanas, el mismo empleado está preguntando cómo hacer lo que le explicaron el día uno.
Esto no es falta de atención ni de voluntad. Es cómo funciona la memoria bajo carga cognitiva alta. La formación necesita estar distribuida en tres momentos con objetivos distintos.
Antes del go-live: orientación, no procedimiento. En la fase previa, la formación no tiene que enseñar a hacer cosas en el sistema. Tiene que responder a las preguntas que el empleado se está haciendo en silencio: qué va a cambiar en su trabajo, por qué la empresa ha tomado esta decisión, y qué parte del sistema le afecta directamente. Una sesión de orientación de 20 minutos bien diseñada reduce la resistencia en go-live porque elimina la incertidumbre antes de que se convierta en fricción.
En el go-live: procedimientos críticos por rol. Aquí entra la formación técnica, pero acotada. No todos los empleados necesitan saber cómo funciona el módulo de compras y el de recursos humanos y el de tesorería. Cada rol necesita dominar los tres o cuatro procesos que ejecuta habitualmente. La formación genérica que cubre todo el sistema de una vez sobrecarga al empleado y diluye lo que realmente necesita retener.
En los 30-60 días posteriores: refuerzo contextual. Esta es la fase más descuidada y la de mayor impacto. Es cuando los empleados están encontrando los errores reales, descubriendo los casos que la formación no cubrió, y desarrollando atajos que a veces no son los previstos. Un módulo breve que responda a las preguntas más frecuentes de las primeras semanas —diseñado a partir de los tickets de soporte y las consultas al equipo de IT— tiene más retención que cualquier sesión de go-live.
El error más habitual en la estructura del contenido es organizarlo siguiendo la lógica del sistema (módulo de compras, módulo de producción, módulo financiero) en lugar de la lógica del empleado (qué hace el responsable de almacén, qué hace el técnico de operaciones, qué hace el contable).
Un empleado que tiene que aprender tres módulos distintos para entender su propio flujo de trabajo está procesando información que no puede conectar con su realidad cotidiana. La retención cae y la formación se percibe como un trámite.
La formación por rol invierte ese orden: se parte de las tareas reales del puesto y se mapean sobre los procesos del sistema que las soportan. El contenido resultante es más corto, más relevante y, en consecuencia, más efectivo. Este enfoque también simplifica las actualizaciones: cuando el ERP cambia un flujo concreto, se actualiza el módulo del rol que lo ejecuta, sin necesidad de rehacer contenido que no afecta a ese perfil.
Para la parte de producción de esos módulos —y especialmente para mantenerlos actualizados cuando el sistema evoluciona— el artículo sobre cómo documentar el uso del ERP sin grabar pantalla describe cómo hacer ese proceso de forma sostenible.
La métrica habitual para evaluar la formación de ERP es la tasa de completitud: cuántos empleados terminaron los módulos antes del go-live. El problema es que esa métrica mide si la formación se distribuyó, no si funcionó.
Los indicadores que sí reflejan adopción real son distintos: el volumen de tickets de soporte relacionados con uso incorrecto del sistema en las primeras semanas, los errores detectados en los procesos críticos (registros contables, albaranes, pedidos), y el tiempo medio que tarda un empleado en completar las tareas que antes hacía fuera del sistema.
Estos datos no son siempre fáciles de cruzar con la formación, pero cuando lo son, permiten identificar qué perfiles o qué procesos tienen mayor brecha de adopción y dónde tiene sentido reforzar con un módulo adicional. Un sistema de distribución con trazabilidad de completitud —el tipo de registro que los LMS generan mediante SCORM— es útil aquí no solo para compliance sino para identificar qué empleados necesitan acompañamiento adicional antes de que los errores se conviertan en problemas de datos.
La adopción de un ERP se juega en los primeros 60 días después del go-live. La formación que ocurre solo el día de la activación rara vez es suficiente — no porque sea incorrecta, sino porque llega en el momento de mayor sobrecarga cognitiva y sin continuidad posterior.
El modelo que funciona no es más formación: es formación en el momento correcto, acotada al rol, con refuerzo cuando los errores reales ya están ocurriendo. Ese cambio de enfoque no requiere más presupuesto de formación. Requiere tratar la adopción como un proceso de 60 días, no como un evento de un día.
Si quieres hablar de cómo aplicarlo en tu proyecto, escríbenos.
La orientación inicial puede empezar entre cuatro y seis semanas antes del go-live, cuando el sistema ya está configurado y los flujos definitivos son conocidos. Si empieza demasiado pronto, los empleados no tienen el sistema disponible para practicar y la retención es muy baja. La formación técnica por rol debe concentrarse en los días inmediatamente anteriores al go-live y en los primeros días de uso real.
Depende del número de roles distintos y de la complejidad de los procesos que cada uno ejecuta. Un proyecto mediano suele necesitar entre 8 y 15 módulos por rol, más un módulo de orientación general. La tendencia a querer cubrirlo todo en un único módulo largo suele ser contraproducente: la especificidad es lo que hace que la formación sea relevante y, por tanto, retenida.
La tasa de completitud mide si el empleado terminó el módulo. La tasa de adopción mide si está usando el sistema correctamente. Ambas métricas son útiles, pero solo la segunda refleja si la formación funcionó. Las proxies más prácticas de adopción son la reducción de tickets de soporte sobre uso incorrecto, la disminución de errores en procesos críticos y el tiempo que tarda el empleado en completar tareas que antes hacía fuera del sistema.
Las actualizaciones de ERP suelen afectar a procesos concretos, no a todos los módulos a la vez. La clave es tener los módulos organizados por proceso y por rol, de forma que sea posible identificar qué contenido necesita actualizarse sin revisar todo el catálogo. La formación construida sobre documentación editable (en lugar de vídeo grabado) permite hacer esos cambios en horas en lugar de días.
@ 2026 Vidext Inc.
Únete a nuestra newsletter
Descubre todas las noticias y novedades de Vidext
@ 2026 Vidext Inc.
