Cuando una implantación de NetSuite sale mal, los errores de implantación de NetSuite suelen acumularse mucho antes del go-live. Decisiones que parecían menores —un alcance definido a medias, una migración de datos sin depurar, una formación recortada por presupuesto— acaban costando tiempo y dinero que nadie había presupuestado. Si estás evaluando NetSuite o ya estás en proceso de implantación, este artículo recorre los cinco problemas que más se repiten en proyectos reales, con señales concretas para identificarlos antes de que sean irreversibles.
El primer taller de requisitos termina, el equipo consultor se lleva sus notas y el proyecto empieza a moverse. Entonces, en la semana cuatro, alguien del departamento de compras menciona que también necesita gestionar pedidos de compra con flujo de aprobación multinivel. Eso no estaba en el alcance. Tampoco lo que pide logística —trazabilidad de lotes— ni el modelo de centros de coste que finanzas acaba de descubrir que no encaja con la estructura de subsidiarias de NetSuite.
Cada requisito descubierto fuera de tiempo tiene un coste multiplicado: hay que rediseñar configuraciones ya entregadas, reabrir migraciones cerradas o añadir módulos que modifican el importe de la licencia.
En NetSuite, los cambios de configuración en las fases finales del proyecto son especialmente costosos porque muchos ajustes de negocio —segmentación contable, clasificaciones de artículos, estructura de subsidiarias— se definen al principio y no son reversibles sin impacto en los datos ya cargados. Un change request de clasificación de artículos a cuatro semanas del go-live puede obligar a recargar el catálogo completo.
La solución no es hacer un análisis de requisitos perfecto —no existe—. Es definir formalmente qué entra y qué no en el alcance desde el inicio, y tratar los nuevos requisitos como lo que son: ampliaciones con coste e impacto en calendario.
La migración de datos es el riesgo más subestimado de cualquier implantación de NetSuite. El patrón que se repite: el cliente exporta sus maestros del ERP anterior, los entrega al equipo consultor y da por cerrado el capítulo. El problema es que esos datos suelen llevar años acumulando duplicados, categorías inconsistentes, cuentas contables desactualizadas y clientes con NIF incorrecto.
En NetSuite, un maestro de artículos mal estructurado afecta simultáneamente a inventario, compras, ventas y contabilidad. Un plan de cuentas importado sin revisar puede generar problemas en los informes financieros y en la generación de los modelos de la AEAT desde el primer mes de operación.
Antes de cargar datos en NetSuite, hay tres categorías que siempre merece la pena depurar:
Un indicador práctico: si la empresa lleva más de cinco años con el mismo ERP sin haber hecho una depuración de datos, hay que presupuestar entre dos y cuatro semanas adicionales solo para la limpieza antes de la migración.
NetSuite es un ERP flexible. Demasiado, en manos equivocadas. La plataforma permite crear SuiteScripts, workflows, custom records, campos personalizados y saved searches casi sin límite. El problema surge cuando, en los primeros meses del proyecto, el cliente decide replicar en NetSuite los procesos exactos de su sistema anterior en lugar de adaptarse a las buenas prácticas que el ERP ya tiene incorporadas.
El resultado típico: un sistema con decenas de scripts que replican lógica que NetSuite resuelve de forma nativa, y que se convierte en un cuello de botella en cada actualización de versión —Oracle publica dos releases anuales, en enero y julio, y el código personalizado debe validarse en cada una.
La regla es clara: primero configura con herramientas nativas —workflows, reglas de automatización, roles, saved searches—, y personaliza con SuiteScript solo cuando el caso de uso no tenga cobertura nativa o cuando el impacto en eficiencia operativa lo justifique claramente.
Un ejemplo concreto: es frecuente ver scripts de SuiteScript 2.0 que calculan comisiones de ventas en tiempo real sobre cada línea de pedido de venta. En muchos casos, esa lógica se puede resolver con una saved search de tipo Summary combinada con un custom field calculado mediante fórmula, sin una sola línea de código. El mantenimiento es nulo y la compatibilidad con versiones futuras de NetSuite está garantizada. La documentación oficial de Oracle NetSuite sobre SuiteScript recoge cuándo cada tipo de script es adecuado y cuáles son las limitaciones de gobernanza que aplican en producción.
Si en la fase de implantación el consultor propone más de tres SuiteScripts para el MVP inicial, es una señal de que algo en el diseño funcional no está bien resuelto.
La formación de usuarios es, en casi todos los proyectos, lo primero que se recorta cuando el presupuesto aprieta o el calendario se retrasa. El razonamiento habitual: "ya lo aprenderán usando el sistema". Lo que ocurre en la práctica: los usuarios aprenden a hacer lo mínimo para salir del paso, consolidan malos hábitos desde el primer día, y el equipo de soporte hereda una deuda de uso que puede tardar años en corregirse.
Cuando los consultores de Flying Lemons éramos usuarios internos de NetSuite, lo más frustrante no era el sistema: era no saber configurar una saved search básica para obtener el informe que necesitabas, y depender de una llamada al consultor externo para algo que, con quince minutos de formación, habrías resuelto por cuenta propia. Ese tiempo de dependencia se acumula, y es dinero que se pierde cada semana.
Un usuario clave bien formado debe ser capaz, como mínimo, de:
La formación no termina el día del go-live. El primer mes de operación real es también formación —con transacciones reales, datos reales y consecuencias reales— y debe estar presupuestado y planificado como tal.
El go-live es el momento en que el equipo consultor cierra el proyecto y la empresa empieza a operar de verdad. Y es exactamente entonces cuando aparecen los problemas reales: transacciones que no cuadran, informes que no reflejan lo esperado, usuarios que no saben gestionar una devolución de cliente, o un asiento contable que se generó mal por un error en la configuración de IVA que nadie detectó durante las pruebas.
Sin un plan de soporte definido para los primeros noventa días, la empresa queda expuesta. El hipercare —un período de soporte intensivo posterior al go-live con tiempos de respuesta garantizados— es un estándar en proyectos bien ejecutados, pero no siempre se incluye de forma explícita en el contrato de implantación. Antes de firmar, conviene preguntar qué cubre exactamente la partida de soporte post go-live y durante cuánto tiempo.
Más allá del hipercare, hay que definir quién se ocupa del mantenimiento evolutivo del sistema: las actualizaciones semestrales de NetSuite, los cambios normativos que afectan a la localización española —SII, Verifactu, modificaciones en los modelos de la AEAT— y los ajustes que inevitablemente piden los usuarios una vez que conocen el sistema y ven lo que podría mejorar.
Si quieres evaluar el estado real de tu NetSuite antes o después de un go-live, en este artículo explicamos cómo hacer un health check de NetSuite en cinco pasos.
¿Cuánto tiempo dura una implantación de NetSuite en España?
Depende del alcance, pero una implantación estándar para una empresa mediana en España —una sola subsidiaria, sin integraciones complejas— suele durar entre cuatro y seis meses. Las implantaciones multisociedad o con integraciones con otros sistemas (CRM, e-commerce, banca electrónica) pueden extenderse a doce meses o más. Oracle NetSuite publica guías de referencia de plazos y metodología en su documentación oficial para implementadores.
¿Qué diferencia hay entre un go-live fallido y uno problemático?
Un go-live fallido implica que la empresa no puede operar: el sistema no registra transacciones correctamente, los datos migrados son inutilizables o la configuración contable produce errores críticos que obligan a parar. Un go-live problemático —mucho más común— es aquel en que el sistema funciona, pero hay fricciones importantes: usuarios que no saben usarlo, informes incorrectos, procesos manuales de compensación que absorben tiempo durante meses.
¿Qué datos hay que limpiar antes de migrar a NetSuite?
Como mínimo: maestro de clientes y proveedores (NIFs, condiciones de pago, segmentaciones), plan de cuentas mapeado al PGC español, maestro de artículos (tipos de IVA, unidades de medida, familias) y saldos de apertura contables. Si la empresa tiene inventario físico gestionado, también el maestro de almacenes y ubicaciones.
¿Cuándo tiene sentido personalizar NetSuite con SuiteScript?
Cuando el caso de uso no tiene cobertura nativa, el volumen de transacciones justifica la automatización y el equipo responsable del sistema puede asumir el mantenimiento del código en cada release semestral. No tiene sentido personalizar para replicar procesos que NetSuite ya resuelve bien con herramientas estándar: workflows, saved searches o reglas de automatización.
¿Cómo sé si mi implantación de NetSuite está en riesgo?
Señales de alerta: el calendario ha sufrido dos o más retrasos, el equipo consultor ha cambiado de miembros a mitad del proyecto, los usuarios clave no han participado en las sesiones de validación funcional, o el alcance ha crecido más de un 20% desde el arranque sin que nadie haya recalculado el presupuesto.
¿Estás evaluando NetSuite para tu empresa o en proceso de implantación y necesitas una segunda opinión? En Flying Lemons acompañamos proyectos de implantación en España con el enfoque de quien ha vivido el sistema desde dentro. Cuéntanos tu caso.
Gratuito
