This website uses cookies

Read our Privacy policy and Terms of use for more information.

¿Quieres enviar a firmar contratos y documentos de RRHH sin tener que salir de SAP?

En GROUPmee hemos creado un Conector que integra Signaturit en tu ERP SAP para acelerar los procesos de firma de documentos y contratos con una solución legal.

Hemos optimizado todo el proceso, para que el envío de documentos y contratos a empleados, se haga de forma automática y con un solo click.

SAPOCALYPSIS NOW 21

Nunca olvidaré aquella llamada a las 3:47 de la madrugada. El vibrar del móvil me arrancó de un sueño profundo, y vi en la pantalla el nombre que todo consultor SAP teme ver fuera del horario laboral: "Diego Martínez - Director de Producción".

—María, necesito que vengas a la planta. Ahora. (Su voz temblaba). Esto... esto no puede estar pasando.

Veinte minutos después, conducía por las calles desiertas hacia la fábrica de componentes automotrices de tamaño medio en las afueras de Valladolid. Las farolas proyectaban sombras inquietantes mientras mi mente repasaba los peores escenarios posibles. ¿Un error en la última actualización? ¿Datos corruptos? ¿Un bug crítico?

Nada me preparó para lo que encontré.

El Descubrimiento

Diego me esperaba en la sala de control, con ojeras profundas y una taza de café temblando en sus manos. A su lado estaban Javier y Sofía, mis compañeros consultores, con expresiones que jamás les había visto: pánico absoluto.

—Muéstrale —susurró Diego.

Sofía giró el monitor hacia mí. Era la transacción MD04. Lo que vi me heló la sangre.

Órdenes de aprovisionamiento. Miles. Todas creadas en las últimas cuatro horas por el MRP automático. Componentes que normalmente se pedían por unidades ahora aparecían en cantidades astronómicas:

  • 84,700 tornillos especiales (stock normal: 200)

  • 23,400 juntas de goma (consumo mensual: 80)

  • 156,000 arandelas (valor: 420,000 euros)

—Dios mío... —susurré—. ¿Cuántas órdenes de compra se han enviado ya?

Javier, normalmente el más calmado del equipo, apenas podía hablar:

—Ciento veintitrés. EDI automático. Los proveedores ya las tienen. Algunos han confirmado. Hay dos que ya están fabricando.

El silencio que siguió era ensordecedor. Solo se escuchaba el zumbido de los servidores y el latido acelerado de mi corazón.

La Carrera Contra el Reloj

—Canceladlas. Todas. Ahora —ordené, aunque sabía que era imposible.

Diego negó con la cabeza, su rostro descompuesto:

—Ya he recibido cuatro llamadas de proveedores confirmando arranque de producción. Los contratos penalizan las cancelaciones con el 40% del valor. Estamos hablando de... —tragó saliva— ...casi tres millones de euros en penalizaciones. Para una empresa de nuestro tamaño, eso es... el cierre.

Miré el reloj: 4:23 AM. En tres horas, los equipos de compras de toda Europa empezarían a trabajar. Más confirmaciones. Más pedidos en camino. Más dinero hundiéndose en un agujero negro.

—Necesito acceso root al sistema. Ahora —dije, con una calma que no sentía.

Sofía ya estaba tecleando. Mientras tanto, entré en SM50 para verificar los procesos activos. Lo que encontré me produjo un escalofrío:

El job "MRP_AUTO_RUN" seguía ejecutándose. Como un corazón mecánico latiendo sin parar, generando más y más locura en cada ciclo.

—Javi, detén ese job. ¡YA!

Pero cuando intentó cancelarlo, apareció un mensaje que jamás había visto:

"Job protegido por dependencia circular. Cancelación bloqueada."

—¿Qué diablos...? —murmuró Javi, intentándolo de nuevo. Y otra vez. Y otra.

El job no moría. Era como si tuviera vida propia.

El Origen del Horror

—Necesitamos ir a la raíz —dije, abriendo SE38—. Sofía, ¿cuándo fue la última modificación en el MRP automático?

Sus dedos volaron sobre el teclado. Se detuvo. Su cara palideció.

—No puede ser...

—¿Qué?

—Hace tres semanas. Un ajuste menor en el programa ZPPS_MRP_CUSTOM. Lo hizo... —revisó el log de transporte— ...Ramiro.

Ramiro. El consultor junior que había salido de la empresa hacía dos semanas. Una salida tensa, llena de reproches.

Abrí el código fuente. Línea por línea, busqué la modificación. Y allí, escondida entre cientos de líneas de lógica compleja, encontré la pesadilla:

*Ajuste temporal para testing - ELIMINAR ANTES DE PRODUCCIÓN
IF sy-datum >= '20241215'.
  lv_multiplier = lv_multiplier * 1000.
  "TODO: Revertir multiplicador
ENDIF.

Era 15 de diciembre. El código había esperado pacientemente, como una bomba de relojería, hasta esta fecha exacta. Entonces, comenzó a multiplicar todas las necesidades de material por mil.

—Ese hijo de... —Javi no pudo terminar la frase.

Mi mente corría. ¿Cómo era posible que esto hubiera llegado a producción?

—Diego, ¿quién aprobó este transporte?

Diego revisó sus emails con manos temblorosas:

—Fue... fue una orden urgente. Ramiro dijo que era un hotfix crítico para un error en el cálculo del lote económico. Llegó un viernes a las 18:30. Yo estaba saliendo para el fin de semana, mi hija tenía una función de teatro... Lo aprobé sin revisar el código en detalle. Confié en él.

Sentí un nudo en el estómago. Conocía esa historia. La presión del viernes tarde, las prisas, la confianza ciega.

—¿Y la revisión de código? ¿El proceso de QA? —pregunté, aunque ya sabía la respuesta.

Sofía intervino, con la voz quebrada:

—Ese fin de semana era el cierre de mes. Yo estaba hasta arriba con los informes ejecutivos. Vi el transporte en mi bandeja, vi que Diego ya lo había aprobado, y... simplemente le di al OK. No abrí el código. Pensé que si Diego lo había visto...

—Y yo estaba de baja por paternidad —añadió Javi—. Ni me enteré hasta que volví.

Era la tormenta perfecta. Un viernes tarde. Presión. Confianza. Procesos saltados "solo esta vez". Y un consultor resentido que sabía exactamente cómo explotar esas grietas.

La Solución Desesperada

—Escuchadme bien —dije, tragándome la rabia—. No hay tiempo para culpas. Sofía, tú vas a crear un programa de emergencia para eliminar todas las órdenes de aprovisionamiento creadas después de las 23:00 de ayer, pero solo las que superen el 500% del stock de seguridad. Javi, necesito que contactes con los tres proveedores principales. Inventa lo que sea: fallo del sistema, ataque informático, lo que sea. Gana tiempo. Diego, prepara un protocolo de crisis para la dirección. Esto llegará a la prensa si no lo manejamos bien.

—¿Y tú? —preguntó Diego.

—Voy a matar ese job aunque tenga que apagar el sistema completo. Y luego voy a comentar esa maldita línea de código y sacar un transporte de emergencia.

Me sumergí en el código del kernel. Cada segundo que pasaba, el MRP fantasma generaba más órdenes. Podía verlas multiplicarse en tiempo real en otro monitor: 1,243... 1,247... 1,252...

Entonces lo vi. El job estaba enlazado a una tabla personalizada Z que tenía un trigger recursivo. Cada vez que intentabas cancelarlo, el trigger lo relanzaba. Elegante. Diabólico.

Necesitaba romper esa dependencia desde la base de datos.

—Sofía, dame acceso a SE14. Voy a necesitar modificar la estructura de ZTABLE_MRP_LOCK en caliente.

—¿Estás loca? ¡Eso puede tumbar el sistema entero!

—Si no lo hacemos, la empresa cae de todas formas.

Con manos temblorosas, modifiqué el trigger, lo desactivé temporalmente y ejecuté el cambio. Durante cinco segundos eternos, el sistema pareció congelarse.

Entonces, el job desapareció de SM50.

Silencio.

—Lo conseguiste —susurró Javi.

—Aún no hemos terminado.

Abrí SE38 de nuevo. Localicé la línea maldita. Con dedos que apenas me respondían, añadí el asterisco al principio de las tres líneas fatídicas, convirtiéndolas en comentarios inofensivos:

**Ajuste temporal para testing - ELIMINADO POR EMERGENCIA 15/12/2024
*IF sy-datum >= '20241215'.
*  lv_multiplier = lv_multiplier * 1000.
*  "TODO: Revertir multiplicador
*ENDIF.

Guardé. Generé el transporte de emergencia. Y con Sofía y Diego como testigos, lo liberé directamente a producción.

Las 5:47 AM. Acabábamos de romper todos los protocolos de cambio. Pero habíamos detenido la hemorragia.

El Amanecer

A las 7:15 AM, cuando los primeros rayos de sol iluminaban la sala de control, habíamos:

  • Eliminado 1,847 órdenes de aprovisionamiento erróneas

  • Salvado 98 que ya estaban en proceso y no podían cancelarse (pérdidas controladas: 340,000 euros)

  • Contactado personalmente con 11 proveedores clave

  • Restaurado los parámetros correctos del MRP

  • Implementado un sistema de alertas para detectar anomalías

Diego lloraba de alivio. Sofía temblaba por la adrenalina. Javi reía nerviosamente mientras bebía su séptimo café.

Yo solo podía pensar en que habíamos estado a 37 minutos de una catástrofe de tres millones de euros.

Diego tomó la palabra, con voz temblorosa pero firme:

—Yo fui quien aprobó ese transporte sin revisar el código. Confié ciegamente. Tenía prisa. Y casi destruyo la empresa. Asumo toda la responsabilidad.

—Yo también —añadió Sofía—. Yo di el segundo OK. Vi que Diego lo había aprobado y asumí que estaba bien. No hice mi trabajo.

La directora general nos miró a todos en silencio. Luego dijo algo que jamás olvidaré:

—Los procesos existen precisamente porque no podemos confiar solo en las personas. Las personas tienen días malos, distracciones, presiones. Por eso necesitamos sistemas que nos protejan de nosotros mismos. Esto no fue culpa de una persona. Fue un fallo sistémico.

Pero la verdadera lección la escribí en mi diario esa noche:

"En SAP, como en la vida, los fantasmas más peligrosos no son los que gritan. Son los que esperan en silencio, escondidos en una línea de código, contando los días hasta que llegue su momento de despertar. Y cuando lo hacen, solo tienes minutos para decidir si eres la heroína o la víctima de tu propia historia.

Pero lo más aterrador no fue el código malicioso. Fue darme cuenta de lo fácil que es saltarse los procesos 'solo esta vez'. Porque 'solo esta vez' es exactamente lo que los monstruos esperan."

Nunca volví a aprobar un transporte sin leer cada línea modificada.

Y nunca, jamás, volví a aceptar un "es urgente, confía en mí" sin verificarlo personalmente.

Ramiro fue demandado por la empresa. En el juicio, alegó que había sido "solo un recordatorio para sí mismo" que olvidó eliminar, y que esperaba que el proceso de revisión de código lo detectara. El juez no estuvo de acuerdo. Tuvo que pagar 180,000 euros en compensación y quedó inhabilitado para trabajar como consultor SAP durante cinco años.

La empresa implementó una herramienta automática de análisis de código que escanea todos los transportes buscando patrones sospechosos: fechas futuras en condicionales, multiplicadores extraordinarios, comentarios con palabras clave como "TODO", "TEMPORAL", "ELIMINAR", "TESTING".

Yo seguí trabajando como consultora SAP. Ahora soy la responsable de aprobar todos los cambios críticos. Y he rechazado 47 transportes en dos años.

Cada uno de ellos tenía una "buena razón" para saltarse el proceso.

Cada uno de ellos podría haber sido la próxima pesadilla.

Porque en el mundo de SAP, los verdaderos monstruos no están bajo la cama.

Están en la línea 1,247 de un programa ABAP que dos personas aprobaron sin leer "porque había prisa".

La Moraleja

Un mes después, en la reunión post-mortem con la dirección, presenté las nuevas medidas de seguridad:

  1. Revisión de código obligatoria en pares para TODOS los cambios en programas críticos. Ningún transporte puede aprobarse por una sola persona.

  2. Prohibición absoluta de comentarios temporales en código productivo. Si dice "TODO" o "TEMPORAL", el sistema rechaza el transporte automáticamente.

  3. Ventana de transportes: No se permiten liberaciones a producción los viernes después de las 15:00 ni en períodos de cierre.

  4. Auditoría automática de multiplicadores y factores de escala en cálculos de MRP.

  5. Límites de sensatez en el MRP: cualquier orden que supere el 300% del histórico requiere aprobación humana.

  6. Proceso de offboarding riguroso: Revisión completa de todos los transportes de un empleado saliente en los últimos 60 días.

  7. Log detallado de aprobaciones: Quién aprobó qué, cuándo y si revisó el código (checkbox obligatorio con timestamp).Y así termina este nuevo episodio de SAPOCALYPSIS NOW

Gracias por acompañarme en esta historia donde el error no estaba en un dump, ni en una conexión RFC caída, ni siquiera en un bug del sistema… sino en algo mucho más humano: un viernes tarde con prisas, una confianza ciega… y una revisión de código que nadie hizo.

Porque a veces los sustos no vienen de sistemas caídos. No generan pantallazos rojos. No lanzan excepciones inmediatas.

A veces vienen escondidos en una línea de código. De alguien que aprueba lo correcto… sin leer lo que realmente hay dentro.

De un transporte que parece urgente e inocente… hasta que despierta semanas después como una bomba de relojería.

De un comentario que dice "TODO: ELIMINAR" que nadie eliminó.

Espero que hayas vivido esta historia tan intensamente como yo al escribirla. Que hayas sentido ese momento incómodo en el que descubres la trampa… demasiado tarde. Y que te hayas hecho la misma pregunta que muchos nos hemos hecho alguna vez:

"¿Seguro que leí cada línea de ese código antes de aprobarlo?"

Recuerda: cada 2 jueves a las 20:10… una nueva historia saldrá de las sombras del sistema.

Hasta entonces, revisa bien tus transportes, lee cada línea modificada… y no des por hecho que "urgente" significa "seguro".

👋 Nos vemos en el próximo episodio.

Y recuerda: los fantasmas más peligrosos no gritan. Esperan en silencio… en la línea 1,247 de un programa que aprobaste sin leer.

¿Te ha gustado esta historia?
¿Quieres enviar la tuya (real o ficticia)?
Envíame un correo a [email protected]

Comentarios

Avatar

or to participate

Otras publicaciones