Implementaciones de NetSuite que se retrasan: 7 patrones

Una implementación de NetSuite en el mid-market suele dimensionarse en cuatro a siete meses. Según nuestra experiencia con clientes ibéricos, las que se retrasan no se retrasan dos semanas: se retrasan un trimestre o más, y lo hacen por un número reducido de causas que se repiten con una constancia casi tediosa.

Esa constancia es la parte útil. Si el fracaso fuera aleatorio, la única defensa sería un presupuesto de contingencia. No es aleatorio. En los proyectos que hemos heredado de otros partners a mitad de camino, los mismos siete patrones explican la gran mayoría de la desviación, y en todos los casos el patrón era detectable en el primer mes —normalmente en la primera quincena— por alguien que supiera qué buscar.

Este artículo es esa lista. Está escrito para usarse como diagnóstico sobre un proyecto ya en marcha, no solo como lista de comprobación para uno que se está planificando.

Por qué importa

El coste de una desviación en un ERP no son los honorarios de consultoría adicionales, aunque sean la parte que aparece en el informe al consejo. El coste real se acumula y es en gran medida invisible.

Un proyecto que se retrasa dos trimestres obliga al equipo financiero a mantener dos sistemas en paralelo durante dos cierres adicionales. Quema la credibilidad del sponsor interno, que es el recurso que el proyecto más necesita en su último tercio. Y empuja el go-live a un periodo que nadie eligió: el momento del go-live importa, porque arrancar un ERP nuevo tres semanas antes de un plazo de reporting obligatorio o en plena temporada alta convierte una transición gestionable en una crisis.

Lo más determinante es que cambia lo que la organización cree. Una empresa que ha vivido un mal proyecto de ERP pospondrá años el siguiente cambio necesario, y lo abordará con un aparato de gobierno tan pesado que el segundo intento será más lento que el primero. La desviación es cara; la cicatriz institucional lo es más.

De un vistazo: los siete patrones

La columna que importa es la segunda. Todas las señales son observables mucho antes de la fase en la que aterriza el coste.

Los siete patrones en detalle

1. Requisitos recogidos como lista de funcionalidades en lugar de como proceso.
El modo de fallo es un documento de requisitos que se lee como una lista de cosas que el sistema debe poder hacer, sin descripción de los flujos de extremo a extremo a los que esas capacidades tienen que dar servicio. El sistema se construye contra la lista, pasa una verificación funcional contra la lista y luego no supera la aceptación de usuario porque nadie puede completar en él una jornada real de trabajo. La solución no tiene glamour: documente los ocho a doce procesos de extremo a extremo que importan —order-to-cash, compra a pago, registro a reporte, devoluciones, cierre— como flujos con responsables y traspasos, y diseñe contra ellos.

2. Ausencia de un único decisor con autoridad.
El diseño de un ERP genera cientos de decisiones, muchas de ellas transversales y algunas genuinamente de suma cero entre departamentos. Si no hay una persona que pueda zanjar esas decisiones sin convocar un comité, el proyecto no fracasa de forma ruidosa: acumula una cola de puntos abiertos que discretamente se convierte en el camino crítico. La señal es fácil de leer: mire cuánto tiempo permanecen sin resolver las decisiones de diseño en la semana cuatro. Si la respuesta es más de unos pocos días, el proyecto se retrasará y ningún esfuerzo de ejecución lo evitará.

3. Calidad del dato descubierta tarde.
Todo plan de implementación contiene una fase de migración. Muy pocos contienen una fase de perfilado, que es donde uno descubre que el 30 % de los registros de clientes son duplicados, que los artículos históricos tienen unidades de medida inconsistentes, que los datos bancarios de los proveedores existen en tres formatos y que los saldos de apertura no cuadran. Descubrir esto durante la migración implica renegociar el calendario en el peor momento posible. Perfile en el primer mes, mientras el hallazgo sigue siendo barato.

4. La personalización como respuesta por defecto a cada carencia.
Cada personalización individual es defendible. Lo que mata es el agregado: una instancia muy scriptada es más lenta de probar, más difícil de soportar, más arriesgada en las actualizaciones y —la parte que sorprende a los clientes— más lenta de cambiar después, que era normalmente la razón para implementar en primer lugar. La disciplina consiste en exigir, para cada personalización propuesta, una respuesta explícita a "¿qué se rompe si adoptamos el proceso estándar en su lugar?". A veces la respuesta es real. A menudo la respuesta honesta es que alguien prefiere la forma antigua, y eso no es un requisito.

5. La integración tratada como tarea posterior.
En la mayoría de los proyectos con problemas que vemos, la integración se dimensiona después de la configuración base, y es ahí donde se va realmente el calendario. La razón es que la integración es el punto en el que las hipótesis de dos sistemas sobre un mismo objeto —un cliente, un pedido, un precio— deben conciliarse, y esas hipótesis suelen ser incompatibles de maneras que fuerzan cambios de diseño de vuelta en la construcción base. El diseño de la integración pertenece a la misma fase que el diseño base, no a una posterior.

6. Operaciones no representada en el diseño.
Finanzas patrocina los proyectos de ERP, así que finanzas acude a los talleres. El almacén, el equipo comercial y atención al cliente con frecuencia no acuden, o envían a alguien sin autoridad. El resultado es un sistema que cierra los libros de forma impecable y hace que preparar un pedido, presupuestar o atender una llamada de un cliente sea sensiblemente más lento que antes. La resistencia operativa en el go-live es casi siempre un fallo de diseño disfrazado de gestión del cambio.

7. Formación planificada como última actividad.
La formación se comprime porque está al final de un plan que ya ha consumido su margen. La consecuencia visible son dos primeros meses lentos y propensos al error. La invisible es duradera: los usuarios que aprendieron un sistema bajo presión de tiempo desarrollan atajos, y esos atajos se convierten en el proceso permanente de la organización. Designe un responsable de formación y fije las fechas al inicio del proyecto, y protéjalas.

Sobre qué conviene ser honesto

Parte del retraso es legítima. Un proyecto que se extiende porque el negocio ha cambiado de verdad —una adquisición, un nuevo canal, un cambio normativo— no está fracasando. Confundir el cambio de alcance con el fracaso produce un equipo de proyecto que oculta los nuevos requisitos, lo cual es peor.

No todos los patrones son culpa de la consultora, ni todos del cliente. Los patrones 1, 4 y 5 recaen normalmente en el partner de implementación. Los patrones 2, 6 y 7 recaen normalmente en el cliente. El patrón 3 es compartido. Un partner que culpa al cliente de los siete no es un partner que convenga mantener, y un cliente que culpa al partner de los siete tendrá el mismo proyecto dos veces.

Corregir un patrón a mitad de camino cuesta más que prevenirlo, y sigue mereciendo la pena. El instinto cuando un proyecto va tarde es apretar más en la ejecución. Si la causa de fondo es el patrón 2 o el 3, apretar más empeora la desviación, porque se está construyendo más rápido sobre decisiones que no están zanjadas o datos que no están limpios.

Una implementación limpia no garantiza la adopción. Estos patrones predicen si se arranca en plazo y en presupuesto. Si el sistema se usa realmente bien es un problema distinto con una respuesta distinta, relacionada sobre todo con la propiedad y la medición después del go-live.

Marco de decisión: diagnosticar un proyecto en marcha

Recórralo en orden. Deténgase en la primera coincidencia: ese es su problema principal, y los puntos posteriores no se resolverán hasta que se resuelva ese.

1. ¿Hay decisiones de diseño sin resolver desde hace más de una semana?
Arregle el gobierno antes que nada. Designe un único decisor con autoridad sobre el diseño transversal, dele una franja fija en la agenda y establezca la regla de que un punto no decidido pasa por defecto al comportamiento estándar del sistema tras un plazo fijo. Nada más de esta lista puede arreglarse mientras las decisiones estén atascadas.

2. ¿Ha perfilado alguien los datos reales?
Si no, pare y perfile ahora: recuentos de registros, duplicados, completitud de los campos obligatorios, integridad referencial y si los saldos de apertura cuadran. Una semana invertida aquí vuelve a valorar honestamente el resto del plan.

3. ¿La documentación de requisitos describe los procesos de extremo a extremo?
Si es una lista de funcionalidades, reconstrúyala como flujos antes de seguir configurando. Puede hacerlo en talleres a lo largo de dos semanas y sacará a la luz las carencias que de otro modo aparecerían en UAT.

4. ¿Se ha diseñado la integración, o solo se ha enumerado?
Si solo se ha enumerado, incorpórela al diseño de inmediato y especifique, por cada objeto integrado, el sistema de referencia, la dirección del flujo, la regla de resolución de conflictos y el requisito de latencia. Hágalo antes de seguir con la configuración base, porque las respuestas cambian la base.

5. ¿Está creciendo el número de personalizaciones sprint tras sprint?
Si es así, instaure una puerta de personalización: cada solicitud necesita una consecuencia de negocio concreta por adoptar el estándar en su lugar. Espere rechazar un tercio de ellas, y espere que resulte incómodo.

6. ¿Han validado el almacén, ventas y atención al cliente sus propios procesos?
Si no, celebre esos talleres antes del UAT en lugar de descubrir la carencia durante él.

7. ¿Tiene la formación un responsable designado y fechas protegidas?
Si no, asigne ambos ahora, y trate esas fechas como inamovibles y no como el margen del proyecto.

Coste y esfuerzo indicativos

Los rangos suponen una única instancia de NetSuite, de una a cinco entidades y un perfil transaccional de mid-market. Los entornos multiinstancia, las operaciones de M&A simultáneas o un proyecto ya pasado el UAT cambian esto de forma sustancial. Solicite un presupuesto para una evaluación dimensionada a su proyecto.

Preguntas frecuentes

Nuestro proyecto ya va tarde. ¿Movemos la fecha de go-live o apretamos al equipo?
Diagnostique primero. Si la causa son decisiones atascadas, datos sucios o una integración sin diseñar, apretar al equipo aumenta el coste final porque se está construyendo sobre cimientos inestables. Si la construcción es realmente sólida y lo que queda es volumen, un empujón puede funcionar. Establecer la diferencia lleva aproximadamente una semana y es la semana de mayor valor de la que dispone.

¿Cómo sabemos si el problema es nuestro partner de implementación?
Mire qué patrones están presentes. Un partner responsable de un documento de requisitos en formato lista de funcionalidades, de un número de personalizaciones sin gestionar y de una integración sin dimensionar no está entregando con el nivel exigible. Un partner que se enfrenta a decisiones del cliente atascadas, a responsables operativos ausentes y a la falta de un responsable de formación está siendo impedido de entregar. Ambas situaciones son recuperables; requieren respuestas opuestas.

¿Podemos arrancar por fases para reducir el riesgo?
A menudo sí, y para grupos multientidad suele ser lo correcto. Pero la fasificación tiene un coste: un periodo con dos sistemas en marcha y conciliación entre ambos. Fasifique por fronteras donde la conciliación sea barata —por entidad legal o por geografía, raramente por función—, porque partir el order-to-cash entre dos sistemas crea precisamente la carga de conciliación que el proyecto debía eliminar.

¿Cuánta contingencia debe llevar un proyecto de ERP en el mid-market?
En lugar de un porcentaje, sitúe la contingencia donde está realmente la incertidumbre: el saneamiento de datos y la integración, que es donde se concentran las desviaciones. Un plan con un 15 % repartido de forma uniforme es menos útil que uno con rangos realistas en esos dos flujos de trabajo y estimaciones ajustadas en el resto.

Todavía no hemos empezado. ¿Qué es lo más valioso que podemos hacer primero?
Perfilar sus datos y designar a su decisor. Ambas cosas cuestan casi nada, ambas se omiten habitualmente y entre las dos cubren los dos patrones que generan las mayores desviaciones.

Cierre — Próximos pasos

Ninguno de estos siete patrones es exótico y ninguno requiere herramientas especializadas para detectarse. Lo que requieren es alguien dispuesto a buscarlos pronto, cuando el hallazgo resulta incómodo y no catastrófico, que es precisamente cuando nadie quiere oírlo, porque el proyecto sigue nominalmente en plazo.

Si su implementación está en marcha, el diagnóstico anterior lleva una mañana. Recórralo en orden y deténgase en la primera coincidencia. Si todavía está en planificación, las dos pólizas de seguro más baratas a su alcance son un perfilado de datos y un decisor designado, y ninguna de las dos necesita una partida presupuestaria.

Sobre el autor

Bruno Galo es el fundador de Atypical Tech, una consultora de NetSuite que trabaja con clientes del mid-market en toda Iberia. Está especializado en conectar sistemas CRM y ERP para lograr flujos de order-to-cash sin fricciones, construyendo pipelines automatizados de gestión de pedidos que eliminan la introducción manual de datos entre los equipos comerciales y financieros. Como partner oficial de implementación de Stacksync, Bruno diseña y despliega agentes de IA sobre plataformas de integración para gestionar el enrutado de excepciones, el procesamiento de documentos y la conciliación, convirtiendo flujos de pedidos fragmentados en sistemas fiables y con autosupervisión.

LinkedIn: https://www.linkedin.com/in/brunogd

Fuentes

Las URL son a nivel de editor y deben verificarse antes de la publicación.

• Oracle NetSuite, documentación de implementación y buenas prácticas — https://docs.oracle.com/en/cloud/saas/netsuite/
• APQC, Open Standards Benchmarking (indicadores de rendimiento de proyectos de ERP y TI) — https://www.apqc.org
• Panorama Consulting Group, ERP Report anual (datos de duración, presupuesto y realización de beneficios de los proyectos) — https://www.panorama-consulting.com
• Standish Group, CHAOS Report (investigación sobre resultados de proyectos de TI) — https://www.standishgroup.com
• Experiencia de Atypical Tech en proyectos de implementación de NetSuite en el mid-market ibérico