El conocimiento SAP que se jubila con sus consultores

Artículo de opinión. Lo firma Javier Saeta, consultor técnico SAP HCM y creador de SaetaIA, y se publicó originalmente en la comunidad oficial de SAP. Lo traemos aquí en español porque el problema que plantea le suena a cualquiera que haya tocado un sistema con quince años encima.

Hay una pregunta que reaparece cada vez que se abre un sistema antiguo de un cliente: ¿por qué se hizo esto así?

A veces hay documentación. A veces hay comentarios en el código. Pero bastante a menudo la respuesta real es más sencilla y más frágil: alguien se acuerda. Esa persona configuró el proceso hace diez o quince años, sabe exactamente qué enhancement le afecta y recuerda la decisión de negocio que llevó hasta la solución actual.

Y muchas de esas personas están cada vez más cerca de jubilarse.

El matiz: no falta documentación de SAP

Aquí está lo interesante del planteamiento, porque va contra el diagnóstico habitual. El problema no es que falte conocimiento de SAP. Existen SAP Help, SAP Community, contenido formativo, certificaciones y, cada vez más, herramientas como Joule for Consultants que dan acceso al conocimiento de producto mucho más rápido.

Lo difícil es todo lo que es específico de un cliente concreto. Por qué este proceso de nómina se comporta distinto aquí. Por qué existe ese user exit. Por qué nadie debe tocar esa pieza de customizing aunque, a primera vista, parezca mal.

Ese conocimiento no está en la documentación de SAP porque no es conocimiento de SAP: es conocimiento sobre ese sistema SAP. Y cuando se van las personas que entienden esas decisiones, se va con ellas una parte de la historia del sistema.

Por qué "documentad más" no funciona

La respuesta obvia suele ser pedir más documentación. En consultoría eso es más fácil de decir que de hacer: hay proyectos, incidencias, plazos y horas facturables. Cuando por fin se resuelve un ticket, la prioridad normal es cerrarlo y pasar al siguiente, no dedicar treinta minutos más a explicar la historia que hay detrás de la solución.

De ahí sale la premisa que sostiene todo lo demás:

Si capturar el conocimiento exige que los consultores senior paren lo que están haciendo y generen documentación como tarea adicional, probablemente no escale.

La pregunta útil, entonces, es otra: cómo capturar parte de ese conocimiento mientras el trabajo ya está ocurriendo.

Cuatro propuestas concretas

1. Convertir el cierre del ticket en el punto de captura. Cada incidencia resuelta ya contiene conocimiento sobre el sistema del cliente. En lugar de pedir documentación aparte, un asistente podría lanzar dos o tres preguntas muy concretas al cerrar: por qué se eligió esta solución, qué hay específico de este cliente que otro consultor debería saber, y qué podría verse afectado si se revierte el cambio. Con esas respuestas se genera una entrada pequeña, enlazada a la transacción, programa, infotipo, enhancement u objeto de configuración correspondiente. La clave es que el consultor no sale del flujo que ya estaba usando.

2. Hacer visible la dependencia de personas concretas. Casi todas las empresas intuyen que hay clientes que dependen demasiado de un consultor en particular. Pero saberlo de forma informal y medirlo son cosas muy distintas. El histórico de tickets permitiría identificar las cuentas donde las incidencias complejas las resuelve repetidamente la misma persona, y construir una métrica simple: cuánta gente podría hacerse cargo de verdad de ese cliente. Eso convierte la pérdida de conocimiento en algo mucho más fácil de discutir: un riesgo de continuidad de negocio.

3. Entrevistar alrededor de objetos técnicos reales. En lugar de sesiones genéricas de traspaso —"cuéntanos todo lo que sabes de Nómina"—, partir del sistema real del cliente. Programas Z, enhancements, interfaces, áreas de configuración, procesos poco habituales y objetos detectados en un assessment de S/4HANA pueden ser la agenda del traspaso. Mirar un objeto concreto tiene muchas más probabilidades de disparar el contexto útil: "ah, esto existe porque en 2014 el cliente cambió…". Justo el tipo de información que después es muy difícil de recuperar.

4. Que los juniors aprendan con tickets reales. Los programas formales de mentoría sirven, pero consumen tiempo. Una vía más ligera es dar a los consultores junior visibilidad sobre los tickets de aquellos clientes donde el conocimiento está concentrado en muy pocas personas. No hace falta que sean los responsables de la incidencia: seguir la investigación, la solución y el razonamiento ya traspasa una parte del conocimiento sin añadir otra reunión al calendario de nadie.

Una conversación abierta, no una receta

El artículo no se presenta como una metodología cerrada, y esa honestidad es parte de su valor. Está escrito desde la perspectiva de una consultora de tamaño medio, donde montar un programa dedicado de gestión del conocimiento no siempre es realista.

Termina, de hecho, con preguntas: ¿alguien ha integrado la captura de conocimiento directamente en su proceso de ticketing? ¿Se ha usado IA para analizar código a medida, configuración o histórico de tickets antes de que se marche un consultor senior? ¿Hay alguna otra vía práctica para preservar lo que nunca llegó a la documentación?

Si trabajas en un equipo SAP y te has hecho alguna de esas preguntas, el sitio para responderlas es el hilo original.

Leer el artículo original en SAP Community