Entradas etiquetadas: DEPENDENCIA

Un ERP puede llevar años funcionando bien y, al mismo tiempo, haberse vuelto difícil de mantener.

Es bastante lógico. Durante una implementación se desarrollan soluciones para necesidades concretas. Después cambian procesos, aparecen regulaciones, se conectan otros sistemas y llegan nuevos requerimientos. Con los años, el ERP termina siendo bastante distinto del que se implementó originalmente.

Parte de esa complejidad tiene un costo. Deloitte estima que la deuda técnica puede representar entre el 21% y el 40% del gasto tecnológico de una organización. Y el impacto puede llegar hasta las decisiones de inversión: según la encuesta tecnológica 2026 de KPMG en Estados Unidos, el 56% de las organizaciones afirma que el costo de corregir deuda técnica les impide invertir en nuevos programas tecnológicos.

En un sistema que concentra procesos críticos y lleva años acumulando desarrollos e integraciones, vale la pena mirar qué está pasando. Especialmente cuando la complejidad empieza a afectar cuestiones concretas: cuánto cuesta hacer un cambio, cuánto tarda, qué riesgo implica y quién tiene el conocimiento para hacerlo.

Cuando conocer el ERP significa conocer su historia

Después de diez o quince años, entender un ERP implica conocer bastante de lo que pasó durante ese tiempo: por qué se desarrolló una funcionalidad, qué proceso necesitaba resolver, con qué otros componentes se conecta y qué puede verse afectado si se modifica.

La documentación, el acceso al código, las integraciones y las decisiones de arquitectura forman parte de ese conocimiento.

Hay algunas situaciones que permiten detectar rápido cuando está demasiado concentrado:

👉Para estimar un cambio hay que consultar siempre a las mismas personas.

👉Existen desarrollos cuyo funcionamiento conoce únicamente el partner.

👉La organización no tiene acceso o control suficiente sobre los activos de la solución.

👉Nadie puede explicar con claridad cómo se relacionan todas las piezas.

En ese punto el ERP empieza a comportarse como una caja negra. Funciona, pero entender qué hay detrás depende cada vez más de las personas o proveedores que trabajan sobre él.

Y si el conocimiento queda concentrado en un proveedor, también queda condicionada la capacidad de la empresa para decidir cómo evolucionar su plataforma.

“Eso mejor no lo toquemos”

Las actualizaciones suelen dejar esta situación bastante expuesta.

Los ERP cloud evolucionan de manera continua. Llegan nuevas versiones, funcionalidades y cambios que tienen que convivir con lo que cada empresa fue desarrollando.

Por eso prácticas como Application Lifecycle Management (ALM), control de versiones y pruebas de regresión son importantes para mantener una solución en el tiempo.

Dynamics 365 permite verlo de manera concreta. Microsoft mantiene una cadencia de dos grandes release waves por año: una entre abril y septiembre y otra entre octubre y marzo. Además de esas olas principales, existen otras actualizaciones de servicio durante el año.

Cuando existen demasiadas dependencias, una actualización puede exigir revisar desarrollos, validar integraciones y volver a probar procesos críticos. Lo que debería acompañar la evolución normal de la plataforma termina convirtiéndose en un proyecto. 

Y aparece una frase bastante conocida en sistemas con muchos años encima: “eso mejor no lo toquemos”.

¿Y si mañana cambia el partner?

Cambiar de proveedor siempre supone una curva de aprendizaje. La diferencia está en cuánto tiene que aprender el nuevo equipo y cuánto tiene que descubrir.

Una solución bien gobernada debería dejar una base transferible: documentación de arquitectura, acceso a los activos, inventario de extensiones e integraciones, código versionado y decisiones funcionales relevantes registradas.

Con esa información, otro equipo tiene desde dónde empezar. Sin ella, primero hay que reconstruir decisiones, revisar desarrollos y descubrir dependencias. El costo técnico de cambiar de partner empieza entonces a pesar sobre una decisión que también debería ser comercial.

Una forma bastante simple de medir esa dependencia es pensar cuánto esfuerzo requeriría hoy que otro equipo continuara trabajando sobre la plataforma.

No puede terminar todo en un desarrollo

Con el tiempo también puede instalarse otra dinámica: cada nuevo requerimiento termina en un desarrollo. A veces es necesario. Pero cuando se vuelve la respuesta habitual, conviene revisar cuánto se está aprovechando de la plataforma y cuánto se está agregando por encima.

Las plataformas, sin embargo, siguen evolucionando. Automatización, analítica, herramientas low-code y, más recientemente, copilotos y agentes permiten resolver hoy necesidades que hace algunos años requerían código.

La decisión está en dónde esa extensión aporta valor y dónde simplemente agrega otra capa de complejidad.

En AW solemos mirar esa decisión desde tres posibilidades:

✅Usar capacidades estándar, cuando la plataforma ya permite resolver la necesidad.

✅Extender, cuando existe un requerimiento del negocio que realmente lo justifica y puede construirse de manera mantenible.

✅Resolver fuera del ERP, utilizando capacidades como Power Platform, Azure, IA u otras aplicaciones cuando no tiene sentido llevar toda la lógica al core.

El ERP sigue siendo central para muchos procesos, pero no necesita concentrar cada nueva capacidad que incorpora la organización. Y una personalización que fue necesaria hace cinco años puede merecer una segunda mirada hoy.

Un partner debería aportar conocimiento, no dependencia

Una arquitectura sostenible permite entender qué existe, por qué existe y cómo puede evolucionar.

También le permite al cliente tomar decisiones sobre su plataforma: incorporar una nueva funcionalidad, reemplazar un desarrollo, sumar otro proveedor o aprovechar capacidades que el fabricante incorpore en futuras versiones.

Ese nivel de autonomía también habla de la calidad de una implementación. El vínculo con un partner tecnológico debería sostenerse por el conocimiento que aporta, por su capacidad para acompañar el negocio y por el valor que genera en cada nueva etapa.

En AW trabajamos bajo esa lógica. Buscamos entender primero qué necesita el proceso, aprovechar las capacidades de la plataforma y extender cuando existe una razón para hacerlo. Y cada decisión contempla cómo se mantendrá, cómo se documentará y qué conocimiento necesita quedar dentro de la organización.

Para nosotros, una buena implementación debería dejar una arquitectura preparada para evolucionar, conocimiento dentro de la organización y libertad para decidir cómo seguir.

En un mundo de cambio tecnológico permanente, es importante que el cliente trabaje con su partner porque es un socio de evolución confiable y no porque su plataforma quedó técnicamente atada a él.