🧨 SAPocalypsis Now Episodio 29

Esta historia combina hechos reales, ampliamente documentados en litigios públicos del sector ERP, con elementos completamente inventados para darle cuerpo narrativo: nombres de empresas, personajes, diálogos, escenas y detalles concretos de esta historia son ficticios. Cualquier similitud con personas, empresas o situaciones reales más allá de los hechos públicamente conocidos es pura coincidencia. Ni el nombre de la empresa cervecera ni el de la consultora aquí utilizados corresponden a los reales, y ningún diálogo reproducido aquí ocurrió tal cual se describe.

Era un lunes cualquiera por la tarde, de esos que se notan en el ambiente de la oficina mucho antes de que el reloj lo confirme. Se mascaban las ganas de cerrar el portátil e irse para casa, esa relajación silenciosa de última hora de la jornada en la que nadie espera ya que pase nada importante. Fue justo en ese momento cuando Javi, mi compañero de Basis, se acercó a mi mesa con una pregunta que, en su momento, sonó de lo más rutinaria.

—¿Es normal que un transporte dure tanto? —me preguntó, refiriéndose al sistema SAP 4.7 de Finanzas Desarrollo.

Entré, fui directo a la SM66 y comprobé que el proceso seguía vivo, procesando.

—Está haciendo cosas, no se ha colgado —le dije, más tranquilo de lo que debería haber estado.

Pero algo no me terminaba de cuadrar. Un import, en desarrollo, un lunes por la tarde, justamente a esa hora en la que todo el mundo estaba de salida.

—¿Esto de quién es? —pregunté.

—Esto me lo mandó una tal Maura, de RMD —contestó Javi—. Dijo que llevaba mucho rato y que si le podíamos decir si estaba colgado.

Miré la hora. Miré el proceso. Y tomé la decisión que, con el paso de los años, todavía me sigue pareciendo la más lógica y la más equivocada al mismo tiempo.

—Bueno, mañana si no ha terminado lo revisamos. ¡Hasta mañana!

Cerré el portátil, cogí la mochila y salí hacia el metro con la conciencia tranquila de quien deja un proceso en marcha que, total, ya se resolverá solo. Caminando hacia la boca de metro, até cabos con algo que había pasado una o dos semanas antes: teníamos constancia de que RMD, una empresa cliente, acababa de arrancar un proyecto de migración de la gestión de gastos de viaje desde el sistema de Recursos Humanos hacia el sistema de Finanzas. El motivo tenía sentido de negocio: HR se actualizaba con muchísima frecuencia, y cada actualización obligaba a probar todo el sistema entero. Cuantos menos añadidos hubiera ahí, mejor. Y de paso, aprovechaban para tener esa funcionalidad en un sistema con una versión más moderna.

Hasta ahí, todo tenía lógica. Lo que me hacía un poco de ruido, mientras bajaba las escaleras del metro, era que la consultora asignada a ese proyecto estuviera importando un transporte tan pesado, tan largo de ejecutar, justo en el entorno de desarrollo de Finanzas. Pensé que quizás en RMD tenían algún tipo de paquetizado especial para esta migración, algo preparado de antemano. Al fin y al cabo, los desarrolladores en desarrollo tienen autorizaciones para hacer prácticamente de todo. Es su entorno de juego. Así están pensados los sistemas de desarrollo.

Con esa explicación medio convenciéndome a mí mismo, me metí en el metro y me olvidé del tema durante el resto de la tarde.

A la mañana siguiente, todo cambió en cuanto puse un pie en la oficina.

Llegué y me encontré a todo el mundo reunido en la mesa de Basis. El responsable de SAP, el responsable de Basis, el responsable funcional de Finanzas. Ese tipo de reunión espontánea, sin convocatoria previa, que solo se forma cuando algo ha ido muy mal durante la noche.

—Buenos días... —dije, notando ya la tensión en el ambiente antes de que nadie me contestara.

—Pedro... ¿te acuerdas del transporte? —dijo Javi, con una cara que no necesitaba más explicación—. Todo Finanzas Desarrollo pega dumpazos. Ni el menú carga.

En ese instante sentí una premonición muy concreta. Un sudor frío me recorrió la frente, ese tipo de sensación física que solo conocen quienes han vivido de cerca una crisis de sistemas de verdad. Fui directo a mirar el log de aquel transporte a nivel de sistema operativo. Le hice un head para ver las primeras líneas, y ahí empezaron a aparecer objetos que arrancaban con "/AMC/...". En todos nuestros sistemas teníamos instalado un software de gestión de jobs de un fabricante llamado AMC. Y ese tipo de objeto, en ese transporte, en ese contexto, sencillamente no tenía ningún sentido que estuviera ahí.

Le hice un wc -l al fichero completo.

Más de ciento cincuenta mil líneas.

—Ayer importaron medio sistema de HR en Finanzas —dije, sin levantar apenas la voz, aunque por dentro la cabeza me iba a mil por hora—. ¿Alguien puede llamar a Maura, de RMD?

Mientras alguien se disponía a hacer esa llamada, otros compañeros se fueron apartando ligeramente de la mesa, móvil en mano, para hacer sus propias llamadas internas. La sala empezó a llenarse de ese murmullo nervioso, fragmentado, de varias conversaciones urgentes solapándose a la vez.

En pocos minutos apareció Maura. Completamente blanca.

—Buenos días —le dije, intentando mantener un tono profesional aunque la situación pedía otra cosa—. Ayer importaste algo en desarrollo de Finanzas. Por favor, ¿podrías decirnos exactamente quién creó ese transporte y qué contenía?

—Buenos días, sí... lo creé yo —contestó—. Es la PR05...

—¿La PR05? ¿La transacción de gastos de viaje?

—Sí... el jefe de proyecto me dijo que este proyecto era muy simple. Que solo tenía que meter la PR05 de HR en un transporte y meterlo en Finanzas...

Sentí que el suelo de la sala se inclinaba ligeramente.

—Pero HR está en 4.6C y Finanzas en 4.7...

Se quedó callada un instante, como si esa frase confirmara algo que ella misma acababa de empezar a entender.

—¿Y cómo incluiste los objetos en la orden? —le pregunté, necesitando reconstruir paso a paso lo que había pasado.

—Ah, creé una orden vacía en HR, incluí objetos, metí la transacción y todas sus dependencias... y luego la transferí al dominio de Finanzas.

—Pero una vez en Finanzas no te dejó importar por versiones de componentes distintas...

—Sí, y entonces lo volví a intentar marcando el flag de ignorar versión de componentes... y funcionó.

—.....("funcionó")...

Esa fue, literalmente, mi respuesta. Un silencio con eco, porque en ese momento entendí exactamente lo que había pasado, y lo que había pasado era mucho peor de lo que cualquiera en aquella sala hubiera imaginado al principio.

La transacción PR05 no es un objeto aislado. Usa ALVs, funciones de conversión de datos, y un ecosistema entero de dependencias técnicas por debajo que, en un sistema HR, forman parte de la columna vertebral del módulo. Al incluir la transacción "y todas sus dependencias" en una orden de transporte, sin ningún tipo de filtro ni criterio de selección, Maura había arrastrado consigo una porción enorme del sistema de Recursos Humanos completo. Y al marcar el flag para ignorar la incompatibilidad de versión de componentes entre el 4.6C de origen y el 4.7 de destino, había desactivado la última barrera de seguridad que SAP pone precisamente para evitar que esto ocurra. Esa validación no está ahí por capricho. Está ahí porque mezclar objetos de dos releases distintos, sin ningún tipo de control, es la receta perfecta para corromper la coherencia interna de un sistema completo.

En aquel momento tuvieron que llevarse a Maura aparte, porque era evidente que no terminaba de comprender la magnitud real del desastre que acababa de provocar. Y era igual de evidente que el resto del equipo, alrededor de aquella mesa, nos habíamos quedado completamente sin palabras.

Nos reunimos internamente para valorar opciones, y la conclusión a la que llegamos era tan clara como incómoda: si queríamos garantizar la consistencia completa del sistema, la única solución técnicamente segura era restaurar a un punto anterior a media tarde del lunes, momento en el que había comenzado el desastre. El problema era que, al tratarse de un entorno de desarrollo, restaurar significaba irnos directamente al backup del domingo. Eso implicaba perder absolutamente todo el trabajo que decenas de desarrolladores habían realizado durante el lunes entero.

El responsable de Finanzas no estaba dispuesto a asumir esa pérdida. Se despidió de la conversación con una frase que resume perfectamente la magnitud del problema desde el punto de vista de negocio:

—Señores, tengo sesenta personas de proyectos paradas.

Y el responsable de SAP, en un intento de aliviar la tensión con algo de humor negro, remató la escena con otra frase que se quedó grabada para siempre en la memoria colectiva del equipo:

—Tendríamos que buscar un rincón para colgar quién la hace más gorda.

A lo que yo, sin poder evitarlo, contesté:

—Han creado un SAP 4.6 y medio.

En ese momento, Maura regresó a la sala acompañada de su jefe de proyecto. Y propuso algo que, viniendo de quien había provocado el desastre apenas una hora antes, sonaba casi a acto de contrición técnica: dijo que no había problema, que si le pasábamos el fichero completo del transporte, ella misma se pondría a importar, uno por uno, cada objeto de test a desarrollo, verificando manualmente que todo quedara correcto.

Dado que la opción de restaurar significaba sacrificar un día entero de trabajo de sesenta personas, esa era, en la práctica, la única alternativa real sobre la mesa. Y aunque suponía un ejercicio manual absolutamente desproporcionado, con el matiz de que todos los objetos implicados eran estándar o de terceros, y que además no se podía tocar nada más en Finanzas Desarrollo mientras durase el proceso, el riesgo de que algo cambiara a mitad del ejercicio era prácticamente nulo.

Era una auténtica aberración de método de trabajo. Pero era, literalmente, lo único que se podía hacer sin sacrificar el trabajo de todo un equipo.

RMD reforzó a Maura con más gente de su propia empresa para acelerar el proceso. Y ese mismo martes por la tarde, el sistema de Finanzas Desarrollo volvía a estar accesible para todo el mundo, como si aquella mañana de pánico colectivo alrededor de la mesa de Basis no hubiera existido nunca.

Han pasado años desde entonces, y sigo pensando en esta historia cada vez que alguien, en cualquier proyecto, me dice que algo "es muy simple". Porque a veces lo simple lo es solo en la cabeza de quien da la instrucción, no en la cabeza de quien tiene que ejecutarla sin entender del todo qué está tocando por debajo. Maura no hizo nada malicioso. Hizo exactamente lo que le pidieron, con las herramientas que tenía a mano, y cuando el sistema le puso una barrera de seguridad delante, encontró la forma de saltársela porque nadie le había explicado por qué esa barrera estaba ahí en primer lugar.

Y así, con un simple flag marcado sin comprender del todo su alcance, media empresa de Recursos Humanos terminó, durante casi veinticuatro horas, viviendo dentro de un sistema de Finanzas que nunca debió recibirla.

Aprendimos la lección de que necesitábamos una mejor gestión de las autorizaciones de los desarrolladores. Debían poder desarrollar, pero solo eso. Retiramos todas las autorizaciones del rol de desarrollador, y más adelante además montamos la Gestión Centralizada de Usuarios (CUA) para tener una visión centralizada de qué cada usuario tenía los roles pertinentes en los sistemas pertinentes y no se nos escapaba ningún super usuario en ningún mandante que pudiera liarla de nuevo.