Cómo implementar un módulo SaaS
sin que el proyecto se alargue 18 meses

Por qué los proyectos de software se atrasan

Cuando un proyecto de implementación de software se retrasa, el diagnóstico habitual es técnico: el proveedor tardó más de lo previsto, hubo problemas de integración con el ERP, los servidores no estaban listos. Estos factores reales explican una fracción del retraso. La causa raíz en la mayoría de los casos es más prosaica: el alcance del proyecto no estaba bien definido desde el inicio, y cada semana alguien en la empresa cliente descubre un requerimiento nuevo que no estaba en el contrato original.

Un estudio del Standish Group muestra que el 66% de los proyectos de software se entregan tarde o fuera de presupuesto. La tasa es consistente entre industrias y tamaños de empresa. Lo que sí varía significativamente es la causa: en proyectos de desarrollo a la medida, el problema es casi siempre el alcance cambiante. En proyectos de implementación de SaaS, el problema es casi siempre la falta de preparación del lado del cliente: datos sucios, decisiones de proceso sin tomar, o personas clave que no están disponibles cuando el proveedor las necesita.

La buena noticia es que ambas causas son prevenibles con un proceso de implementación bien estructurado. La diferencia entre un proyecto que va a producción en 8 semanas y uno que se extiende 18 meses no es el presupuesto ni el proveedor: es el método.

Las 4 fases de una implementación SaaS exitosa

Una implementación de módulo SaaS conectado a ERP tiene cuatro fases distintas, y comprimir o saltar cualquiera de ellas es la causa más frecuente de retrasos. No son etapas opcionales: son checkpoints que, si no se completan correctamente, generan retrabajo en la fase siguiente.

1. Fase 1 — Diagnóstico y definición de alcance (1-2 semanas). El objetivo de esta fase no es entender el software: es entender el proceso de negocio que el software va a soportar. ¿Cómo funciona el proceso hoy? ¿Quiénes son los usuarios? ¿Qué datos vienen del ERP y cuáles se generan en el módulo nuevo? El resultado de esta fase es un documento de alcance firmado por el patrocinador del proyecto.
2. Fase 2 — Configuración y conexión al ERP (2-3 semanas). En esta fase el proveedor configura el módulo según el alcance definido y establece la conexión API con el ERP. El equipo de TI del cliente tiene que estar disponible para proporcionar credenciales, aprobar reglas de firewall y validar que los flujos de datos son correctos. Los retrasos en esta fase casi siempre ocurren porque el equipo de TI del cliente no tiene tiempo asignado para el proyecto.
3. Fase 3 — Pruebas y capacitación (1-2 semanas). Las pruebas las hacen los usuarios finales, no el equipo de TI. Un error común es que TI pruebe el sistema técnicamente y lo declare "listo" sin que los operadores del proceso lo hayan usado. Los errores que solo se descubren en producción son los más costosos. La capacitación debe ser práctica: los usuarios deben completar los flujos de trabajo reales, no ver demostraciones.
4. Fase 4 — Go-live y estabilización (2 semanas). Las primeras dos semanas en producción son críticas. Deben existir canales de soporte prioritario, sesiones diarias de revisión de incidencias, y el proveedor debe tener capacidad de respuesta en menos de 4 horas para problemas bloqueantes. Después de dos semanas de producción estable, el proyecto puede considerarse entregado.

Lo que el equipo interno debe aportar

El éxito de una implementación SaaS no depende exclusivamente del proveedor. El equipo interno de la empresa tiene responsabilidades específicas que, si no se cumplen, bloquean el proyecto independientemente de qué tan bueno sea el software o el proveedor. La más importante es designar un dueño del proyecto: una persona con autoridad para tomar decisiones de proceso, disponibilidad de al menos 4 horas semanales para el proyecto, y capacidad para escalar cuando necesita una decisión que no puede tomar ella sola.

La segunda responsabilidad crítica del equipo interno es la preparación de datos. Si el módulo nuevo va a importar datos históricos del ERP —clientes, proveedores, órdenes de compra, productos— esos datos deben limpiarse antes de la implementación, no durante. Un proyecto que descubre durante la fase de configuración que tiene 4,000 registros de proveedores duplicados en el ERP va a retrasarse entre 3 y 6 semanas mientras se limpia la base.

"Tuvimos dos intentos fallidos con otros proveedores. El problema nunca fue el software: era que nosotros no teníamos clara la decisión de cuál proceso seguiríamos. En la tercera vez, el proveedor nos obligó a documentar el proceso antes de mostrar siquiera el sistema. Fue la clave." — Directora de Operaciones, empresa de servicios financieros, Ciudad de México, 140 empleados

Configuración vs. implementación a medida: la diferencia que más importa

Un módulo SaaS bien diseñado tiene opciones de configuración suficientes para adaptarse a los procesos de la mayoría de las empresas sin necesidad de desarrollo adicional. La diferencia entre configurar y desarrollar a medida es fundamental: la configuración ocurre en la interfaz del sistema usando parámetros predefinidos, mientras que el desarrollo a medida implica escribir código nuevo que el proveedor tiene que mantener y que puede no ser compatible con futuras versiones.

El error más frecuente en implementaciones SaaS es pedir desarrollo a medida para requerimientos que podrían resolverse con configuración, o que en realidad no son necesarios: el equipo está acostumbrado a un proceso específico en Excel y quiere replicarlo exactamente, incluyendo las ineficiencias. Un buen proveedor debe ser capaz de distinguir entre requerimientos de negocio reales y preferencias de uso, y debe defender la configuración estándar cuando el requerimiento no justifica el desarrollo.

Indicadores de go-live: cómo saber si la implementación fue exitosa

Un proyecto de implementación exitoso no se mide solo por si el sistema está técnicamente funcionando. Se mide por indicadores de adopción y de impacto en el proceso de negocio. Los indicadores que deben medirse durante las primeras cuatro semanas en producción incluyen: porcentaje de transacciones procesadas en el sistema nuevo vs. el proceso anterior, tiempo promedio de procesamiento por transacción, número de tickets de soporte por usuario activo, y porcentaje de usuarios que acceden al sistema al menos tres veces por semana.

Si alguno de estos indicadores está por debajo de lo esperado, hay que diagnosticar la causa antes de que se convierta en un problema de adopción de largo plazo. Los problemas de adopción en las primeras semanas casi siempre tienen una causa específica: una parte del proceso que no funciona como los usuarios esperaban, una integración con el ERP que no entrega los datos correctos, o un flujo de trabajo que requiere más pasos de los necesarios. Todos son solucionables en días si se identifican a tiempo.

Cómo evitar el proyecto de 18 meses

El proyecto de 18 meses tiene siempre las mismas características: alcance mal definido al inicio, decisiones de proceso que se posponen semana a semana, un equipo interno sobreocupado que no tiene tiempo para el proyecto, y un proveedor que acepta cambios de alcance sin actualizar el contrato ni el cronograma. La solución no es técnica: es de gestión de proyecto.

Las tres reglas que separan los proyectos de 8 semanas de los de 18 meses son simples: primero, ningún requerimiento nuevo entra al alcance después de la firma del documento de alcance sin una decisión explícita de posponer o reemplazar un requerimiento existente. Segundo, el patrocinador del proyecto tiene que tomar decisiones en menos de 48 horas: los proyectos que esperan semanas para obtener una decisión interna terminan siempre fuera de cronograma. Tercero, las fechas del proyecto son compromisos bilaterales: si el proveedor no entrega a tiempo, el cliente puede reclamar. Si el cliente no tiene los datos listos o el personal disponible, el proveedor puede ajustar las fechas sin penalización.