En la sexta parte analizamos por qué fracasan los proyectos ERP: un proceso sin definir, un responsable ausente, datos sucios, un lanzamiento precipitado y un equipo no preparado para el cambio. Ahora convertimos esas lecciones en un plan de ejecución. Elegir el sistema es una decisión de un día; implementarlo es un proyecto de meses, y es ahí donde realmente se decide el resultado. En esta séptima parte recorremos las fases de la implementación en orden: del descubrimiento y el mapa de procesos a la migración de datos, a las pruebas, a la puesta en marcha y el hypercare, y luego el lado humano, donde se estancan la mayoría de los proyectos.

Descubrimiento y mapa de procesos: dibuje antes de construir

Una implementación exitosa empieza con una fase de descubrimiento, no con una instalación. Se sienta con cada departamento y traza cómo trabaja realmente hoy —no cómo se supone que trabaja sobre el papel— y después acuerda la única forma en que el sistema ejecutará cada proceso. El resultado de esta fase es un solo documento: el mapa de procesos que define cada proceso, quién es su responsable y dónde empieza y termina.

Este mapa es la constitución del proyecto. Cada disputa se resuelve volviendo a él, y cada personalización se sopesa frente a él. Los proyectos que se saltan el descubrimiento y pasan directamente a la pantalla descubren las carencias después de la puesta en marcha, cuando corregirlas cuesta varias veces más.

Migración de datos: limpie antes de mover

Sus datos antiguos viven en hojas de cálculo y sistemas dispersos acumulados durante años, y son lo más peligroso que puede trasladar al nuevo sistema. Una migración exitosa es una fase por derecho propio, no copiar y pegar:

  • Limpie antes de mover: nombres duplicados, saldos que no cuadran, artículos sin categoría. Límpielos en el origen antes de que entren en el sistema, porque los datos sucios que entran en un sistema limpio siguen sucios y minan la confianza en las cifras desde el primer día.
  • Mapee y verifique: haga corresponder los campos de su sistema antiguo con los del nuevo, migre primero un lote de prueba y luego compruebe que los saldos y totales cuadran con el origen antes de confiar en él.
  • El historial que lleva consigo: decida qué migrar y qué archivar. No todo registro antiguo merece sobrecargar el nuevo sistema.

La regla: primero limpiar, después migrar, en tercer lugar verificar. Ese orden marca la diferencia entre un sistema que arranca con confianza y uno que arranca con dudas.

Pruebas y aceptación antes de la puesta en marcha

Antes de que nadie toque el sistema en el trabajo real, debe superar una prueba con sus datos, no con los datos de demostración del proveedor. Construya escenarios a partir de su negocio real —una factura completa, un ciclo de compras, un cierre de mes— y ejecútelos en el sistema para comprobar que produce el resultado correcto.

Después llegan las pruebas de aceptación: su propio equipo ejecuta las operaciones que realizará a diario y firma que funcionan como deben. Las pruebas de aceptación no son una formalidad; son la última oportunidad de detectar una carencia antes de que se convierta en una crisis delante de un cliente real.

Puesta en marcha y hypercare: gradual, no un salto

En la puesta en marcha se enfrenta a dos decisiones:

  • Por fases o big-bang: un lanzamiento big-bang lo activa todo en un solo día, multiplicando el riesgo y convirtiendo cualquier error en una crisis de toda la empresa. Un despliegue por fases —un módulo o una sucursal cada vez— contiene el error y genera confianza paso a paso. En la mayoría de los casos, ir por fases es más seguro; el salto único solo conviene a pequeñas empresas con operaciones sencillas.
  • Hypercare: las primeras semanas tras la puesta en marcha son la fase más delicada. Mantenga un soporte intensivo cerca del equipo para detectar errores y responder dudas de inmediato, hasta que el sistema se estabilice y la gente confíe en él. La puesta en marcha no es la línea de meta, sino el inicio de la fase más sensible.

El lado humano: responsable, patrocinio y cambio

Aquí es donde se estancan la mayoría de los proyectos, no en la tecnología. La implementación necesita tres pilares humanos: un único responsable interno con autoridad y tiempo dedicado que lidere desde su lado, no un empleado al que se le añade el proyecto como algo marginal; un patrocinio directivo que dé al proyecto una prioridad real y resuelva lo que cruza departamentos; y una gestión del cambio consciente que prepare al equipo antes de la puesta en marcha, no después.

Gestionar el cambio significa implicar a las personas pronto para que se sientan parte de la decisión y no su víctima, explicar por qué cambiamos y no solo cómo, y hacer que la formación sea continua en lugar de un evento único. Un sistema que la gente adopta tiene éxito aunque sea más sencillo; uno impuesto encuentra una resistencia silenciosa aunque sea más potente.

La visión de Origami

Somos una empresa tecnológica, pero para nosotros la implementación es un proyecto organizado, no la instalación de un software. Empezamos con el descubrimiento y el mapa de procesos antes de tocar una pantalla, tratamos la migración de datos como una fase que limpia y verifica en lugar de copiar, insistimos en unas pruebas de aceptación que firma su equipo y lanzamos por fases con un hypercare cercano. Además, hacemos que el responsable interno, el patrocinio directivo y la gestión del cambio formen parte del plan desde el primer día. Nuestro objetivo es un sistema que siga vivo después de la puesta en marcha, no uno que funcione el día de la entrega y se abandone después.

Conclusión

Una implementación de ERP exitosa no es un evento, sino un proyecto por fases: un descubrimiento que traza los procesos, una migración que limpia antes de mover, unas pruebas de aceptación firmadas por quienes lo usarán, una puesta en marcha por fases seguida de hypercare y, por encima de todo, un responsable presente, un patrocinio directivo y un equipo preparado para el cambio. Quien recorre estas fases en orden gestiona un sistema que vive; quien se las salta gestiona una crisis aplazada. Y a lo largo de todas estas fases hay una condición que no se puede aplazar en Arabia Saudí: el cumplimiento normativo. En la octava parte veremos qué debe exigir a cualquier sistema antes de firmar —facturación electrónica, IVA y localización completa al árabe— como requisitos imprescindibles, no como complementos.

Fuentes

  • Autoridad de Zakat, Impuestos y Aduanas (ZATCA) — La facturación electrónica (Fatoora) como obligación que hay que tener en cuenta en las pruebas y la puesta en marcha: https://zatca.gov.sa
  • Autoridad Saudí de Datos e Inteligencia Artificial (SDAIA) — la Ley de Protección de Datos Personales (PDPL) y los controles sobre los datos durante la migración: https://sdaia.gov.sa
  • Visión Saudí 2030 — transformación digital y apoyo a las pequeñas y medianas empresas: https://www.vision2030.gov.sa