ERP estándar o personalizado: cuándo configurar y cuándo no

En algún punto de casi toda implementación de ERP, un taller llega a un momento en el que el sistema estándar hace algo de forma distinta a como lo hace hoy el negocio, y alguien pregunta con toda la razón si se puede cambiar para que coincida. La respuesta es casi siempre sí: los ERP modernos son flexibles y un desarrollador competente puede hacer que el sistema haga prácticamente cualquier cosa. La pregunta que merece la pena hacerse no es si se puede hacer. Es a qué se está comprometiendo al hacerlo.

Una personalización no es un coste puntual. Es un coste recurrente: hay que volver a probarla en cada actualización, cada nueva incorporación al equipo tiene que entenderla, hay que documentarla o se convierte en un misterio, y hay que mantenerla durante todo el tiempo que el sistema esté en uso. Las empresas mid-market que acumulan personalizaciones sin un marco coherente para decidir entre ellas acaban con una instancia de ERP que es caro tocar, lenta de actualizar y, en la práctica, única, algo que suena a flexibilidad y funciona como fragilidad.

Este artículo plantea un marco para tomar esa decisión de forma coherente, porque las decisiones individuales suelen ser razonables y el agregado casi nunca lo es.

Por qué esto importa

El coste directo de una personalización es visible en el momento de construirla y fácil de presupuestar. Los costes que se acumulan después son los que realmente determinan si valió la pena.

Cada personalización amplía el alcance de las pruebas en cada actualización futura: las notas de versión del fabricante no saben nada de su script, así que alguien tiene que comprobarlo manualmente, cada vez. Cada personalización es un fragmento de conocimiento institucional que vive con quien la construyó, y las empresas mid-market no retienen a esa persona indefinidamente; cuando se va, la personalización se convierte o en una caja negra o en una reconstrucción. Y cada personalización complica el trabajo del siguiente partner de implementación, porque ahora da soporte a un sistema que se aparta del que conoce por formación y del que describe la propia documentación del fabricante.

Hay un efecto acumulativo específico del ERP: una instancia muy personalizada se vuelve progresivamente más difícil de cambiar, justo en el momento en que el negocio más necesita que cambie, porque la deuda de personalización se acumula más rápido en las empresas que crecen y evolucionan, precisamente aquellas para las que la flexibilidad importa más.

De un vistazo: el marco de decisión

La última fila es la disciplina que más importa y la que más a menudo se omite. Debería exigirse que toda petición de personalización la responda de forma explícita y por escrito antes de su aprobación.

Qué funciona y sobre qué conviene ser honesto

Qué funciona:

Exigir una respuesta escrita a "qué se rompe si no hacemos esto". No una preferencia, una consecuencia. "Al equipo de almacén le resulta menos cómoda la pantalla de picking estándar" es una preferencia. "No podemos facturar legalmente conforme a los requisitos españoles sin este campo" es una consecuencia. Hacer explícita esta distinción y exigirla por escrito convierte la conversación de defensa de una postura en evidencia.

Un registro de personalizaciones, revisado periódicamente. Cada personalización registrada con su responsable, su justificación de negocio y una fecha de revisión. La mayoría de las empresas mid-market no tienen ese registro, lo que significa que nadie puede responder "por qué el sistema hace esto" para una parte significativa de lo que se ha construido, y nadie vuelve a plantearse nunca si la justificación sigue siendo válida.

Preferir la configuración al scripting, y el scripting a la modificación del núcleo. Cada opción conlleva costes de mantenimiento distintos y riesgos de actualización distintos. Un cambio de configuración suele ser seguro entre actualizaciones. Un script necesita pruebas. Una modificación del núcleo es la categoría de mayor riesgo y debería exigir el umbral de justificación más alto.

Aislar lo que sí debe personalizarse. Cuando la personalización está genuinamente justificada, constrúyala como una adición discreta, bien documentada y débilmente acoplada, en lugar de incrustarla en la configuración del núcleo. Esto reduce de forma material el coste de la siguiente actualización y el coste de eliminarla llegado el caso, si la justificación deja de sostenerse.

Revisar las personalizaciones antiguas, no solo filtrar las nuevas. Una justificación que era correcta hace tres años puede no serlo ahora: la normativa puede haber cambiado, el diferenciador competitivo puede haberse convertido en requisito mínimo del mercado, el equipo que necesitaba el apaño puede haberse marchado. La revisión periódica detecta esto; la mayoría de las empresas nunca mira atrás.

Sobre qué conviene ser honesto:

Rechazar una petición de personalización es una conversación más difícil que aprobarla. Quien la pide suele tener una frustración genuina e inmediata, y "adopte el proceso estándar" puede sonar despectivo incluso cuando es la respuesta correcta. Esto es una habilidad de gobierno del dato y de comunicación tanto como técnica, y requiere alguien con capacidad de decidir dispuesto a mantener la conversación incómoda.

Algunas personalizaciones son genuinamente necesarias, y rechazarlas todas es su propio modo de fallo. Los requisitos legales, los diferenciadores competitivos genuinos y las necesidades de integración son categorías reales. El objetivo es un marco coherente y defendible, no una negativa general.

El marco requiere alguien con autoridad para decir no. Sin una persona con capacidad de decidir y con poder real —el mismo requisito que se comenta en los patrones de fracaso de implementaciones de NetSuite en otro artículo de esta serie—, este marco es un documento que nadie sigue, porque cada petición individual encontrará un defensor y ninguna petición encontrará un evaluador coherente.

Las personalizaciones heredadas son más difíciles de eliminar que las nuevas de prevenir. Una vez que un proceso se ha construido alrededor de una personalización, eliminarla tiene un coste de gestión del cambio independiente de su coste técnico. Esto es un argumento a favor del rigor en el momento de la creación, ya que la prevención es mucho más barata que una eliminación posterior.

Esto no es una decisión puntual. Un marco aplicado una sola vez en la implementación y abandonado después produce la misma acumulación que pretendía evitar. Tiene que ser un proceso de gobierno del dato permanente, con un responsable, durante toda la vida del sistema.

Resumen del marco de decisión: aplicarlo en la práctica

La tabla anterior es el marco. En la práctica, aplíquelo como un proceso permanente:

1. Toda petición de personalización entra en un registro antes de que empiece cualquier desarrollo, y quien la solicita debe responder a la pregunta de justificación por escrito.

2. Una persona designada con capacidad de decidir evalúa contra el marco, no un comité; véase el artículo sobre implementaciones de NetSuite de esta serie para entender por qué esto importa en general.

3. Las personalizaciones aprobadas se construyen aisladas y documentadas, con un responsable y una fecha de revisión registrados.

4. El registro se revisa a intervalos fijos —anualmente es razonable para la mayoría de las empresas mid-market— y la justificación de cada entrada se vuelve a contrastar con las circunstancias actuales, no solo con su aprobación original.

5. Las peticiones rechazadas también se registran, con la alternativa de proceso estándar documentada, para que la misma petición no reaparezca sin memoria institucional de por qué se rechazó.

Coste y esfuerzo indicativos

Solicite un presupuesto para una auditoría de personalizaciones acotada sobre su instancia actual.

Preguntas frecuentes

¿Cómo aplicamos este marco de forma retroactiva a un sistema que ya acumula años de personalización sin documentar?
Empiece por el registro: inventaríe lo que existe, aunque inicialmente sea sin justificación completa, porque el inventario ya tiene valor por sí solo. Priorice la revisión por lo que resulte más arriesgado de actualizar o menos comprendido, en lugar de intentar justificarlo todo a la vez.

¿Qué proporción de peticiones de personalización deberíamos esperar rechazar?
No hay una cifra universal que merezca citarse, y tratar la tasa de rechazo como un objetivo distorsiona el proceso: la meta es un marco coherente aplicado con honestidad, no una cuota. En nuestra experiencia, un marco aplicado con verdadero rigor rechaza una minoría significativa de peticiones que, de otro modo, se habrían aprobado por defecto, pero esto varía enormemente según la empresa y el sector.

¿Este marco se aplica igual a la personalización de informes que a la personalización de procesos?
El principio es el mismo, pero el perfil de riesgo es distinto: un informe personalizado suele ser de menor riesgo que un cambio en la lógica transaccional del núcleo, porque no afecta a cómo se procesan las transacciones, solo a cómo se presentan. Pondere su evaluación en consecuencia; el umbral para la personalización de un informe puede ser razonablemente más bajo que para la personalización de un flujo de trabajo.

¿Quién debería ser la persona con capacidad de decidir en este marco?
La misma persona con autoridad sobre las decisiones de diseño de ERP transversales en general; véase el artículo sobre implementación de esta serie. Si no existe tal persona, establecer ese rol es un requisito previo para que este marco funcione en absoluto.

¿Qué relación tiene esto con una implementación de NetSuite en concreto?
Es la disciplina de gobierno del dato continuada que evita el patrón de fracaso de "la personalización como respuesta por defecto a cada carencia" que se comenta en el artículo sobre implementación. Ese artículo lo aborda durante un proyecto; este lo aborda como disciplina operativa permanente después.

Cierre — Próximos pasos

Las decisiones de personalización se toman de una en una, por personas distintas, bajo presión de tiempo, y el agregado rara vez es lo que nadie pretendía. Un marco coherente —aplicado por una persona designada con capacidad de decidir, que exige una justificación por escrito y se revisa periódicamente— no elimina la personalización. Garantiza que lo que existe está ahí porque se ha ganado su lugar, y que alguien se daría cuenta si dejara de ganárselo.

Si quiere saber en qué punto está hoy: intente construir el registro de personalizaciones de su instancia actual. El ejercicio en sí —descubrir qué se ha construido, quién lo hizo y por qué— suele ser la tarde más informativa a disposición de un equipo que se pregunta por qué su sistema se ha vuelto caro de cambiar.

Sobre el autor

Bruno Galo es el fundador de Atypical Tech, una consultora de NetSuite que presta servicio a clientes mid-market en toda Iberia. Está especializado en conectar sistemas CRM y ERP para flujos order-to-cash sin fricciones, y en construir pipelines automatizados de gestión de pedidos que eliminan la introducción manual de datos entre los equipos de ventas y de finanzas. Como partner oficial de implementación de Stacksync, Bruno diseña y despliega agentes de IA en plataformas de integración para gestionar el enrutamiento de excepciones, el procesamiento de documentos y la conciliación, convirtiendo flujos de pedidos fragmentados en sistemas fiables que se supervisan a sí mismos.

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

Fuentes

Las URL son a nivel de editor y deberían verificarse antes de la publicación.

• Oracle NetSuite, documentación de personalización y SuiteScript — https://docs.oracle.com/en/cloud/saas/netsuite/
• Panorama Consulting Group, ERP Report anual — datos sobre personalización y coste total de propiedad — https://www.panorama-consulting.com
• Experiencia de proyectos de Atypical Tech, implementaciones de NetSuite en el mid-market de Iberia