🧨 SAPocalypsis Now — Episodio 10

Hoy te traigo una historia tan real, tan peligrosa y tan típicamente SAP que te va a recordar a algún proyecto… quizá uno tuyo… quizá uno de un amigo… quizá uno del que todavía no te has recuperado psicológicamente.

Porque hoy hablamos de Santiago, consultor FI senior, tipo metódico, serio, de los que se saben la FBL3N como la palma de la mano.

Junto a él, su inseparable compañero:
Rafa, programador ABAP top, calmado, resolutivo y actualmente… de vacaciones.

Y por supuesto, aparece en escena:
El programador suplente (sin nombre, porque ya solo mencionar su función da escalofríos).

Clara, key user de Finanzas, validadora compulsiva.

Sí, amigos. Esto promete.

La empresa estaba inmersa en un proyecto llamado:

Proyecto CECOS 3000 “Gestión de Centros de Coste del Futuro”

(Un nombre que claramente algún jefe inventó en una reunión de 20 minutos para que sonara importante).

El objetivo:

Crear ampliaciones Z para automatizar el reasignado de centros de coste dependiendo de reglas internas que ni ellos mismos tenían claras.

Pero bueno, tú ya sabes cómo va esto:
—“Tú prográmalo, y ya veremos”.
—“¿Pero qué condiciones?”
—“Poquita cosa, tú pon if, else, else, else”.
—“¿Y cuándo pasa cada caso?”
—“Ah… eso ya si eso lo vemos”.

El pan de cada día.

Aun así, Santi y Rafa trabajaron semanas dándolo todo.

Validaciones, pruebas, ajustes, infinitos “lo hablamos mañana”, cafés fríos, dumps en QA, más cafés fríos…

El proyecto iba sorprendentemente bien.
Demasiado bien.
Sospechosamente bien.

Porque amigo mío…
Si algo va perfecto en un proyecto SAP… es que todavía falta por llegar algún que otro susto.

Aquí aparece nuestro antagonista:

El usuario USUEMPRESA.

Ese usuario que debería estar prohibido por la Convención de Ginebra.
Un usuario con todos los permisos, usado por todos los programadores y todos los funcionales.

Un usuario que, en el log, parece omnipresente:
—“¿Quién modificó esto?”
—“USUEMPRESA”.
—“¿Quién borró la tabla?”
—“USUEMPRESA”.
—“¿Quién mató a Kennedy?”
—“USUEMPRESA”.

Un mal necesario.
Una bomba de relojería.

Todo debía ser validado por Clara, la key user.
Pero Clara tardó tanto que… bueno… es que Rafa se fue de vacaciones.

Celebraba su aniversario de bodas.
Una semana fuera.
Sin Teams.
Sin SAP.
Sin dumps.
Sin Santi.

Rafa era feliz.
Y no lo sabía, pero pronto iba a ser aún MÁS feliz cuando volviera y viese el desastre.

Santi, mientras tanto, sabía lo que venía:
El programador suplente.
Esa persona con la que se llevaba regular…
Más bien “mal”…
Más bien “solo hablo contigo si no tengo otra opción”.

Un ambiente laboral precioso.

Clara aparece un lunes por la mañana, con un café en la mano y aire triunfal:

“Está todo perfecto. Solo cambiad este valor de 3 decimales a 2. Validado. Podéis pasarlo a producción cuando queráis.”

Y aquí, querido lector, como narrador imparcial debo decirte:

Error nº1: Validar sin tener todos los cambios controlados…. no es validar.
Nunca.
Jamás.
En la vida.

Pero bueno, sigamos.

Santi piensa:

“No quiero hablar con el programador suplente que no le aguanto y no me cae bien…”

“Es un cambio pequeño, fácil. En mis sesiones con Rafa he visto dónde está. Le doy yo, lo cambio, activo y listo.”

ERROR.
En letra grande.
En negrita.
Y subrayado.

Pero lo peor no fue eso.

Lo peor fue que…
lo activó y NO lo transportó a QA.

Porque en ese preciso momento le llaman por videollamada.

Sí, una llamada.
Una hora de reunión.
Y Santi, como cualquier mortal después de una llamada de una hora…
cerró el portátil y dejo de trabajar por hoy.

Sin transportes.
Sin pruebas.
Sin miedo a la vida.

Clara al día siguiente, le escribe:
“¿Cómo va? Necesito esto en producción HOY. Ya he pedido ventana de paso a producción de 11 a 12.”

Santi traga saliva.
“Bueno… solo hay que hablar con el programador suplente. No pasa nada.”

Le escribe un correo:
Formal. Correcto.
Tan seco que si el correo fuese un postre sería una galleta sin azúcar.

El suplente recibe el correo.
Lo lee.
Sonríe.
No de felicidad.
De… “vale, tú también me caes regular”.

Revisa objetos.
Revisa transportes…
Y ve algo raro:
Una versión en DEV distinta a QA.

Lo normal habría sido:
“Oye Santi, revisa esto. No coincide.”
Pero no….

El suplente mira la pantalla, piensa…
Y decide:
“Pues yo lo libero igual.”

Y lo libera.
Con dos narices.

A las 11:00 en punto:
¡ZAS!
Ordenes transportadas.

A las 11:05 Clara llama.
Su voz es puro terror financiero:

“Santi… Santi… HAY UN DUMP… ¡UN DUUUUUMP!”

Se escuchan gritos en Controlling.
Alguien pide un extintor.
Otro reza.
Un junior empieza a actualizar LinkedIn.

Santi revisa.
Cambia de sesión.
Abre ST22.
Abre SM21.
Abre su corazón.

Nada cuadra.
No entiende qué ha explotado.

ppp

Finalmente, tragando orgullo, decide hablar con el programador suplente.

El suplente abre el Transport Organizer.
Mira.
Se queda callado 5 segundos.
Y dice:

“Ah… ya sé lo que ha pasado.”

Se gira mentalmente hacia Santi (porque en videollamada la mirada asesina no funciona igual) y le explica:

“He transportado en el orden incorrecto. Una orden que dependía de otra ha entrado antes. Por eso PROD está intentando usar un objeto incompleto.”

Silencio.

Un silencio que se podía notar en el ascensor del edificio de al lado….

Error…. nunca uses transportes normales… siempre haz transporte de copias… ya que después… tienen que transportarse las ordenes a PRODUCCION en ORDEN… si no los objetos no quedan con la versión correcta..

Y ahora, atención, lector…

Te miramos directamente a ti.

👉 Dime la verdad…
¿No te habías imaginado que el DUMP era culpa del decimal que tocó Santi?
¿A que estabas segurísimo?
¿A que estabas ya preparando el comentario tipo: “Es que nunca toques un desarrollo ajeno, Santi…”?

Pues no.

NO ERA ESO.

El problema no era el desarrollo.
Ni el decimal.
Ni lo que activó Santi.
Ni nada de eso.

El problema fue:

👉 El programador suplente la lió transportando en el orden equivocado.

Y claro…
esa pequeña travesura rompió PROD.

Un clásico del SAPverso.

El programador suplente reorganizó los transportes.
Liberó lo que faltaba.
Transportó.
Ordenó.
Reparó.

Y…

✨ FUNCIONÓ.

NO TODOS LOS SAPOCALYPSIS TIENEN QUE SER APOCALIPTICOS, El de hoy es mas Light

Finanzas respiró.
Santi revivió.
Clara dejó de sudar.
El junior cerró LinkedIn.

Rafa regresa de vacaciones.
Sonriente.
Relajado.
Bronceado.

Abre Teams.
Ve 213 mensajes sin leer.
Suspira.

Lee la historia.

¿Su reacción?

Carcajadas.
Risas.
Alegría pura.

Porque cuando tú NO has sobrevivido a la guerra…
la guerra es divertida.

📚 Moralejas

• Nunca valides sin validar.

• Nunca toques un desarrollo ajeno sin transportarlo luego.

• Nunca uses órdenes que no sean copys para transportar a TEST…

• Nunca confíes en que el suplente ordenará bien las cosas.

• Nunca ignores los protocolos.

• Y sobre todo…
  Si ves algo perfecto en SAP…

🔔 Prepárate.
Algo gordo está a punto de explotar.