Soporte de ERP tras el go-live: no depender de una persona

La mayoría de las implantaciones de ERP tienen un plan bien definido hasta el go-live y casi nada definido después de él. El contrato del partner de implantación termina, el equipo de proyecto se disuelve y el soporte pasa discretamente a ser responsabilidad de la persona interna que más implicada estuvo durante el proyecto — normalmente porque era quien mejor entendía el sistema, no porque alguien decidiera deliberadamente que debía asumir su soporte en adelante.

Esto funciona durante un tiempo, porque esa persona conoce realmente bien el sistema. Deja de funcionar en el momento en que coge una baja prolongada, cambia de puesto o se marcha de la empresa, y es entonces cuando la organización descubre que una cantidad sustancial de conocimiento operativo existía únicamente en la cabeza de una persona, nunca se documentó y no tiene plan de sucesión. Es un fallo completamente predecible, y es predecible precisamente porque es habitual — la mayoría de las empresas mid-market con las que trabajamos han pasado por alguna versión de esta situación, normalmente más de una vez.

Este artículo trata de construir un modelo de soporte de forma deliberada, antes del go-live y no después de que la carencia se haga visible.

Por qué esto importa

El coste inmediato de un soporte no documentado y dependiente de una sola persona es la fragilidad operativa: una pregunta que debería responderse en una hora tarda días porque la única persona que podría contestarla no está disponible, y todos los demás están reconstruyendo la lógica desde cero.

El coste acumulado es peor. Cada mejora, cambio de configuración y solución provisional que esa persona hace de manera informal, sin documentación, se convierte en deuda técnica indistinguible del problema de acumulación de personalización que se trata en otro artículo de esta serie — con la diferencia de que aquí se acumula en la memoria institucional y no en el código, lo que probablemente sea más difícil de recuperar, porque no hay registro que auditar ni código que leer. Cuando esa persona finalmente se va, la organización no solo pierde a una persona: pierde un mapa no documentado de su propio sistema.

Hay además una dimensión de gobierno del dato. Un sistema cuyo funcionamiento depende del conocimiento tácito de un único individuo constituye una debilidad de control que se hace visible en el peor momento posible — durante una auditoría, durante la ausencia de esa persona o durante un proyecto posterior que necesita entender la configuración actual y no puede, porque nadie la escribió.

De un vistazo: los componentes del modelo de soporte

Todas las filas de esta tabla existen durante una implantación bien llevada, aportadas por el partner como parte del proyecto. El fallo no es que estas cosas sean difíciles de hacer — es que nadie decide deliberadamente quién las hace cuando termina el contrato del partner.

Qué funciona y sobre qué hay que ser honesto

Qué funciona:

Decidir el modelo de soporte antes del go-live, no después. Debería ser un entregable concreto del proyecto de implantación y no una ocurrencia tardía — quién atiende cada nivel de incidencia, con qué recurso interno, escalando a qué recurso externo, documentado antes de que termine el contrato del partner en lugar de negociado con prisas después.

La documentación como artefacto vivo, no como una entrega puntual. La documentación de implantación describe el sistema tal como se construyó. Un modelo de soporte necesita documentación que describa el sistema tal como está ahora, actualizada cada vez que cambia — la misma disciplina que el registro de personalizaciones que se trata en otro artículo de esta serie, aplicada a la configuración en general y no solo a la personalización.

Propiedad nominada, distinta del conocimiento más profundo. La persona que conoce mejor el sistema es un recurso que hay que proteger y apoyar, no automáticamente la propietaria de su gobierno continuado. Separar estos papeles — un propietario responsable que garantiza que existan documentación, sucesión y proceso, apoyado por quien tenga el conocimiento técnico más profundo — reduce la dependencia de una sola persona incluso antes de que esa persona se vaya.

Una relación mantenida y de menor intensidad con la experiencia de implantación. No necesariamente con el partner original, y no a intensidad de proyecto, pero sí algún acceso continuado a experiencia para dudas de configuración genuinamente difíciles, evaluación del impacto de actualizaciones y revisiones periódicas de salud del sistema. Las empresas que cortan esto por completo tienden bien a infrautilizar la capacidad del sistema, bien a acumular una deriva de configuración que nadie detecta.

Una cadencia deliberada para revisar las actualizaciones del fabricante. Alguien debería tener asignada la tarea de revisar las notas de release, valorar el impacto sobre su configuración y sus personalizaciones concretas y probar antes de aplicar las actualizaciones — en lugar de aplicarlas a ciegas o posponerlas indefinidamente por miedo.

Sobre qué hay que ser honesto:

Esto cuesta dinero real y recurrente, y compite con otras prioridades posteriores al go-live. Un modelo de soporte con una disciplina documental adecuada, propiedad nominada y acceso mantenido a experiencia no es gratis, y las empresas mid-market invierten aquí menos de lo debido con frecuencia, porque el coste es visible y el riesgo que mitiga no lo es, hasta que se materializa.

La disciplina documental se degrada sin mantenimiento activo. Un modelo de soporte que empieza bien documentado y deja de actualizarse a los seis meses no es apreciablemente mejor que no tener documentación, porque una documentación obsoleta que contradice el estado real del sistema suele ser peor que una ausencia honesta de documentación — induce activamente a error.

La dependencia de una sola persona a menudo sirve a los intereses de esa persona, aunque sea sin intención. Ser el único que entiende el sistema es una fuente de seguridad laboral e influencia, y puede haber una resistencia silenciosa a transferir realmente ese conocimiento. Esto hay que gestionarlo como un problema de incentivos, no solo como un problema de documentación — reconozca y valore explícitamente a quien posee el conocimiento, en lugar de tratar la transferencia como algo que se le impone.

Las relaciones mantenidas con el partner necesitan un alcance real, o resultan caras sin ser útiles. Un contrato de retainer abierto y sin alcance definido tiende a infrautilizarse hasta que llega una crisis, y entonces se depende excesivamente de él. Una revisión periódica de salud con alcance definido, más disponibilidad para las dudas genuinamente difíciles, suele ser más útil que cualquiera de los dos extremos.

Marco de decisión: construir o arreglar el modelo de soporte

Ejecútelo en orden. Deténgase en la primera coincidencia.

1. ¿Su modelo de soporte actual depende del conocimiento de un individuo concreto, sin documentación?
Si es así, esta es la prioridad al margen de todo lo demás — empiece a documentar ahora la configuración y la lógica actuales, no como un proyecto sino como una disciplina continuada, comenzando por lo que esa persona considere más crítico o más frágil.

2. ¿Tiene una estructura de soporte por niveles definida — quién atiende cada nivel de incidencia?
Si no, defínala ahora. No necesita ser elaborada en una empresa mid-market, pero sí necesita existir y ser conocida, en lugar de recaer informalmente en quien esté disponible.

3. ¿Hay una persona nominada que responda del gobierno continuado del sistema, distinta de quien tiene el conocimiento técnico más profundo?
Si no, asígnelo explícitamente. Los dos papeles sirven a propósitos distintos y confundirlos recrea la dependencia de una sola persona que este marco existe para evitar.

4. ¿Hay un proceso de control de cambios para las modificaciones de configuración hechas después del go-live?
Si no, establezca uno, proporcionado a su escala — incluso un simple registro de qué cambió, por qué y quién lo aprobó evita que la deriva de configuración se vuelva imposible de rastrear.

5. ¿Tiene algún acceso mantenido a experiencia de nivel de implantación más allá de su equipo interno?
Si no, y su capacidad interna es genuinamente suficiente, puede estar bien — pero confírmelo deliberadamente en lugar de descubrir la carencia durante una actualización difícil o un requisito nuevo y complejo.

6. ¿Hay alguien asignado a revisar y valorar las actualizaciones del fabricante antes de aplicarlas?
Si no, asígnelo. Aplicar actualizaciones a ciegas y posponerlas indefinidamente son ambas cosas peores que un proceso de revisión deliberado y probado, y esto con frecuencia no es responsabilidad explícita de nadie.

7. Todo lo anterior está en su sitio — ¿se está manteniendo la documentación realmente al día?
Audítelo periódicamente. Un modelo de soporte con la estructura correcta pero con documentación en degradación fallará en silencio, y la única defensa es comprobarlo, no suponerlo.

Coste y esfuerzo indicativos

Solicite un presupuesto para un diseño de modelo de soporte con alcance definido o una revisión de salud.

Preguntas frecuentes

¿Deberíamos mantener a nuestro partner de implantación en retainer después del go-live?
No necesariamente el mismo partner, y no necesariamente con la misma intensidad, pero alguna forma de acceso mantenido a experiencia más allá de su equipo interno suele valer la pena al menos durante el primer año o los dos primeros, cuando es más probable que las dudas de configuración y los impactos de las actualizaciones excedan la capacidad interna.

¿Cómo conseguimos que nuestro experto del sistema documente su conocimiento sin que lo sienta como una amenaza para su puesto?
Plantéelo explícitamente como proteger y valorar lo que sabe, no como sustituirlo — la documentación convierte su conocimiento en un activo de la organización en lugar de una carga personal que soporta en solitario, y ese planteamiento, hecho con sinceridad y no como una frase para apaciguar resistencias, importa más que cualquier plantilla de documentación concreta.

¿Cuál es el modelo de soporte mínimo viable para una empresa mid-market pequeña?
Una estructura por niveles (aunque los niveles dos y tres apunten al mismo pequeño equipo interno), un documento vivo de la configuración actual y de las soluciones provisionales conocidas, un propietario responsable nominado distinto del experto técnico más profundo si la plantilla lo permite, y alguna vía definida hacia experiencia externa para todo lo que exceda la capacidad interna. No se requieren herramientas elaboradas; sí se requiere la asignación deliberada de estas responsabilidades.

¿Con qué frecuencia debería revisarse el propio modelo de soporte?
Anualmente es razonable para la mayoría de las empresas mid-market, y además siempre que haya un cambio significativo de personas, una actualización importante del sistema o un nuevo módulo o integración — cada uno de estos es un momento en el que es más probable que los supuestos del modelo necesiten revisarse.

Estamos en plena implantación. ¿Es demasiado pronto para pensar en esto?
Es el momento ideal. El diseño del modelo de soporte es mucho más barato y más eficaz cuando se incorpora al plan de implantación como entregable que cuando se añade después, y aborda directamente el patrón de fallo de formación y transferencia de conocimiento del que se habla en el artículo sobre implantaciones de NetSuite en otra parte de esta serie.

Cierre — Siguientes pasos

La distancia entre el go-live y un modelo de soporte sostenible rara vez es un problema técnico. Es una decisión no tomada — nadie eligió explícitamente quién sería propietario del sistema, lo documentaría y daría continuidad cuando la persona que mejor lo conoce no esté disponible — y las decisiones no tomadas recaen por defecto en quien estuviera más cerca, lo que es un cimiento frágil para algo de lo que el negocio ya depende a diario.

Si ya ha pasado el go-live y no tiene claro en qué punto está: pregunte a la persona que mejor conoce el sistema qué ocurre si está inaccesible durante un mes. Su respuesta honesta es el diagnóstico más directo disponible, y normalmente revela exactamente por dónde tiene que empezar el modelo de soporte.

Sobre el autor

Bruno Galo es el fundador de Atypical Tech, una consultora de NetSuite que presta servicio a clientes mid-market en toda la península ibérica. Está especializado en conectar sistemas CRM y ERP para lograr flujos order-to-cash sin fricciones, construyendo 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 enrutado de excepciones, el procesamiento de documentos y la conciliación — convirtiendo flujos de pedidos fragmentados en sistemas fiables y capaces de vigilarse a sí mismos.

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

Fuentes

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

• Oracle NetSuite, documentación de administración y soporte — https://docs.oracle.com/en/cloud/saas/netsuite/
• ITIL (Axelos), marco de gestión de servicios — principios de niveles de soporte y control de cambios — https://www.axelos.com
• Experiencia de proyectos de Atypical Tech, modelos de soporte de ERP mid-market en la península ibérica