NetSuite lleva funcionando en tu empresa desde hace uno o dos años. El go-live fue hace tiempo, los consultores ya no están y el equipo interno ha aprendido a moverse por el sistema. Pero algo no acaba de funcionar del todo: los cierres de mes se alargan más de lo necesario, algunas automatizaciones fallan sin que nadie lo reporte, o los informes dan números distintos según quién los ejecute y cuándo. ¿Es normal? ¿O hay algo que revisar?
Un diagnóstico de NetSuite responde exactamente esas preguntas. Este artículo explica cuándo tiene sentido pedirlo, qué áreas cubre y qué suelen encontrar los consultores cuando entran por primera vez a una instancia que lleva años en producción.
Los términos se usan a veces como sinónimos, pero apuntan a cosas distintas.
Un health check es una revisión general del estado de la instancia: configuración de base, roles, módulos activos, parametrización de impuestos, integraciones básicas. Es el punto de partida cuando quieres un mapa de situación antes de contratar soporte continuado. Si te interesa ese enfoque, puedes leer cómo lo estructuramos en cinco pasos.
Un diagnóstico técnico y funcional va más allá. No solo describe lo que hay, sino que identifica por qué el sistema no rinde al nivel esperado: scripts que bloquean procesos en silencio, workflows mal configurados que crean registros duplicados, saved searches que tardan 40 segundos en cargar porque nadie revisó los filtros sobre campos indexados, o integraciones que se ejecutan sin captura de errores. El diagnóstico parte de síntomas concretos y los rastrea hasta su causa.
Una saved search bien configurada sobre la tabla de transacciones con los filtros correctos en campos indexados tarda menos de dos segundos. Si la tuya tarda diez o veinte, hay algo que revisar: filtros sobre campos no indexados, criterios excesivamente amplios o fórmulas en columnas calculadas que NetSuite ejecuta fila a fila. En equipos de más de veinte usuarios, ese tiempo multiplicado por el número de consultas diarias deja de ser una molestia para convertirse en un coste operativo real.
Si en tu instancia hay SuiteScripts desplegados por distintos proyectos a lo largo de los años y ninguno lleva comentarios, changelog ni propietario claro, tienes deuda técnica acumulada. Oracle actualiza la plataforma dos veces al año. Algunos scripts dejan de funcionar sin aviso, especialmente los desarrollados en SuiteScript 1.0, cuyo modelo de ejecución difiere significativamente del de las versiones 2.0 y 2.1. Según la documentación oficial de SuiteScript, cada script debe declarar explícitamente la versión de API con la que fue desarrollado. Un script en 1.0 que nadie ha revisado desde 2022 es una tarea pendiente para la próxima actualización de versión.
"Más o menos" en una integración significa que hay errores silenciosos. Pedidos que no llegan, facturas que se duplican, sincronizaciones que se saltan registros por un fallo de validación que nadie captura. Si tu integración no tiene logs activos y alertas configuradas, no sabes si está funcionando: simplemente no has recibido quejas todavía. La diferencia entre un sistema que notifica sus propios fallos y uno que no es, en la práctica, la diferencia entre gestionar problemas antes de que lleguen al cliente o después.
Esto ocurre cuando los roles tienen acceso a filtros distintos y los informes no llevan anclados los criterios relevantes, o cuando hay registros en estados intermedios —en aprobación, en tránsito, parcialmente completados— que unos usuarios ven y otros no. No es un problema de los datos; es un problema de cómo está configurado el acceso y cómo están diseñados los informes. En entornos financieros esto no es solo una molestia: puede afectar a la fiabilidad de los datos con los que trabaja dirección.
El consultor que implantó el sistema ya no está. El responsable de sistemas que más lo conocía dejó la empresa hace seis meses. El nuevo equipo sabe navegar por NetSuite, pero no entiende por qué hay ciertos campos custom, por qué algunos workflows solo se ejecutan para determinadas subsidiarias, o por qué hay roles duplicados con nombres similares pero permisos distintos. Este escenario es más habitual de lo que parece y es uno de los contextos donde un diagnóstico externo aporta más valor inmediato.
El alcance exacto varía según la situación de partida, pero las áreas que siempre revisamos son estas cuatro.
Inventario completo de SuiteScripts (Client Scripts, User Event Scripts, Scheduled Scripts, RESTlets), estado de deployment, versiones de API, lógica de ejecución y dependencias con otros scripts o campos custom. Identificamos cuáles están activos sin uso aparente y cuáles pueden entrar en conflicto con futuras actualizaciones de la plataforma.
Estado actual de todos los workflows activos: condiciones de inicio, acciones configuradas, ramas de error y comportamiento sobre registros ya existentes. Uno de los problemas más frecuentes es el workflow con una acción de envío de correo apuntando a una dirección que ya no existe, o que se dispara para todos los registros de un tipo cuando solo debería hacerlo para un subconjunto específico.
Revisión de roles activos, permisos asignados frente a permisos necesarios, usuarios con roles de administrador no justificados y configuraciones que pueden suponer un riesgo de integridad de datos o de auditoría interna. La acumulación de roles heredados de versiones anteriores del sistema es uno de los ámbitos donde más se nota el paso del tiempo en una instancia en producción.
Análisis de las saved searches y los informes que más utilizan los equipos de finanzas, operaciones y dirección: campos indexados usados como filtro, uso de fórmulas en columnas calculadas, configuración de resultados por página y criterios de fecha que fuerzan barridos completos de tabla.
Cuando entramos a diagnosticar una instancia que lleva dos o tres años en producción, el patrón se repite con variaciones: entre quince y cuarenta SuiteScripts desplegados, de los cuales entre el 20 % y el 30 % están activos pero sin documentación ni propietario claro. Workflows con ramas de error vacías. Al menos una integración con una dirección de notificación de errores desactualizada. Y casi siempre, roles de administrador asignados a usuarios que llevan meses sin acceder al sistema.
Esto no es una crítica a quien implantó el sistema ni al equipo que lo mantiene. Es lo que ocurre cuando una plataforma viva lleva años en producción y los cambios se acumulan sin una revisión sistemática. Parte de nuestra perspectiva como consultores viene de haber sido usuarios internos de NetSuite antes de ser consultores externos: cuando estás dentro de una empresa viendo el sistema cada día, la presión operativa hace que los ajustes rápidos se acumulen y la documentación quede siempre para después. El diagnóstico no busca culpables; busca el estado real del sistema para poder trabajar desde ahí.
Si ya tienes un contrato de soporte gestionado, este diagnóstico suele ser el punto de partida para priorizar el backlog de mejoras del primer trimestre.
Tiene sentido pedir un diagnóstico cuando:
Esperaría si el sistema lleva menos de seis meses en producción y el go-live fue reciente: aún no ha dado tiempo a acumular deuda técnica significativa. También si el equipo interno conoce bien el sistema y tiene capacidad real de revisar estas áreas: en ese caso, una auditoría interna estructurada puede ser suficiente.
¿Cuánto tiempo lleva hacer un diagnóstico de NetSuite?
Depende del tamaño de la instancia y de cuántas personalizaciones e integraciones haya activas. En instancias de tamaño medio —una o dos subsidiarias, hasta cincuenta usuarios, entre diez y treinta scripts— el diagnóstico inicial completo se lleva entre cinco y diez días de trabajo con acceso de lectura a la instancia de producción.
¿Es necesario detener la operativa durante el diagnóstico?
No. El diagnóstico se realiza en modo lectura sobre la instancia de producción. No modificamos ninguna configuración durante el análisis, y cualquier intervención posterior se planifica y comunica antes de ejecutarla.
¿En qué se diferencia de contratar una implantación nueva?
Un diagnóstico es una revisión de algo que ya existe. No toca la configuración, no migra datos, no introduce cambios. El resultado es un informe con hallazgos priorizados y recomendaciones. Lo que se haga con ese informe —si es que se hace algo— es una decisión posterior e independiente.
¿Qué pasa después del diagnóstico? ¿Hay algún compromiso de contratación?
Ninguno. Si los hallazgos son menores, puede que no sea necesaria ninguna intervención adicional. Si hay problemas relevantes, el diagnóstico sirve como base para priorizar un plan de mejora, ya sea mediante un proyecto puntual o dentro de un contrato de mantenimiento evolutivo. La decisión es del cliente.
Si los síntomas que describe este artículo te resultan familiares, tiene sentido hacer una primera conversación antes de que la deuda técnica siga creciendo. Habla con nuestro equipo y cuéntanos qué estáis viendo en vuestra instancia.
Gratuito
