¿Tu equipo trabaja en SAP Business One… pero sigue invirtiendo
tiempo en tareas manuales?

Con la integración de Dost, desarrollada por GROUPmee, automatizas procesos clave de tu operativa financiera directamente dentro de SAP. Captura e interpreta documentos con inteligencia artificial, concilia automáticamente facturas, pedidos y albaranes, y gestiona aprobaciones sin fricciones.

No es solo gestión documental: es automatización real de procesos,
con trazabilidad y control en tiempo real.

Menos tareas manuales. Más eficiencia. Más control.

Era un martes típico de noviembre en Madrid. Uno de esos días grises donde la ciudad se despierta con la rutina de siempre: atascos en la M-30, cafés apresurados, y la promesa de una jornada laboral normal en Logistic1 S.A., el gigante de distribución y logística que movía el 60% del comercio electrónico de la península ibérica.

Treinta y dos plantas de cristal y acero. Doscientos camiones saliendo cada hora. Cuarenta mil pedidos diarios procesados por un único sistema SAP ECC 6.0 que, ese martes, estaba a punto de enseñarnos la lección más cara de nuestras carreras.

Pero a las 9:00 de la mañana, cuando me serví mi segundo café, aún no lo sabía.

Éramos cinco profesionales trabajando en lo que parecía un proyecto rutinario de seguridad:

Yo, Laura Mendoza, 34 años. Consultora Basis senior con doce años de experiencia. Divorciada hacía seis meses. Mi hija Claudia, de ocho años, era mi motor para seguir adelante. SAP era mi zona de confort, donde todo tenía lógica y estructura. O eso creía.

Roberto Salazar, 52 años. Director de IT de Logistic1. Veinte años en la empresa. A seis meses de su jubilación anticipada. Su hija mayor acababa de ser aceptada en Harvard. Era meticuloso, prudente, de los que nunca saltaban procesos. Hasta ese martes.

Carmen Vega, 29 años. Consultora funcional SD (Sales & Distribution). Brillante, perfeccionista. Llevaba el módulo comercial como si fuera su hijo. Conocía cada configuración, cada peculiaridad del pricing. O eso creíamos todos.

Andrés Ruiz, 41 años. Responsable de Seguridad y Compliance. Ex-militar reconvertido en auditor SAP. Obsesivo con los procedimientos. Si Andrés decía que algo cumplía normativa, era ley. Su palabra era garantía.

Y Tomás Herrera, 26 años. El programador ABAP. Dos años en la empresa. Técnicamente brillante pero aún inseguro. Revisaba su código tres veces antes de activarlo. Meticuloso hasta la paranoia. Lo cual, irónicamente, no fue suficiente.

Martes 14 de noviembre, 08:47 horas.

Roberto nos convocó a una reunión. Nada urgente, simplemente un "tenemos que hablar de un tema de seguridad" enviado por email la noche anterior.

Nos reunimos en la sala de juntas del piso 12. Roberto proyectó un email en la pantalla:

ASUNTO: SAP Security Note 3411547 - Vulnerabilidad de Seguridad

Remitente: SAP Security Response Team
Clasificación: Hot News

"Estimado cliente SAP,

Hemos identificado una vulnerabilidad de seguridad (CVSS 8.6) en el procesamiento de caracteres especiales en pedidos de venta SAP ECC 6.0 y S/4HANA.

SAP Security Note 3411547 corrige esta vulnerabilidad añadiendo validaciones adicionales en el módulo SD.

Se recomienda implementar esta nota durante su próxima ventana de mantenimiento.

Documentación técnica adjunta.

Atentamente,
SAP Security Response Team"

—CVSS 8.6 —dijo Roberto—. No es crítico inmediato, pero es lo suficientemente serio como para no dejarlo pasar. Propongo implementarlo esta semana siguiendo el proceso normal: desarrollo, QA, y si todo va bien, producción el jueves.

—¿Qué componentes afecta? —pregunté.

—Principalmente SD. Procesamiento de pedidos, pricing, validación de campos de texto. Andrés ya revisó el aspecto de compliance. Carmen, necesito que coordines las pruebas funcionales en QA.

Carmen asintió, ya tomando notas.

—¿Complejidad técnica? —preguntó Tomás.

Roberto pasó a la siguiente diapositiva con el resumen de la nota.

—Modificaciones en varios programas ABAP estándar. Principalmente validaciones de input. Según SAP, sin impacto funcional si se implementa correctamente. Tomás, tú te encargas de la parte técnica con Laura supervisando.

Todo sonaba razonable. Rutinario, incluso.

—Muy bien —dije—. Empezamos hoy en desarrollo, mañana miércoles lo pasamos a QA para pruebas, y si Carmen da el OK, el jueves lo liberamos a producción en la ventana de mantenimiento de las 22:00.

—Perfecto —Roberto cerró su portátil—. Proceso estándar. Sin prisas. Hagámoslo bien.

Salimos de la reunión con la tranquilidad de quien tiene un plan sólido.

No sabíamos que el plan era perfecto.

El problema era la ejecución.

Martes 14 de noviembre, 10:30 horas.

Tomás y yo nos instalamos en la sala técnica. Dos monitores cada uno. Café recién hecho. La nota 3411547 abierta en PDF en una pantalla.

—Bien —dije—. Vamos paso a paso. ¿Qué objetos afecta la nota?

Tomás leyó la documentación:

—Principalmente el programa SAPMV45A y el user-exit MV45AFZZ para pricing. También modifica las validaciones en SAPMV45A para campos de texto en cabecera y posiciones de pedido.

—Perfecto. Empecemos descargando la nota al sistema de desarrollo con SNOTE.

Tomás ejecutó la transacción SNOTE (SAP Note Assistant) y cargó la nota 3411547. El sistema mostró la lista de objetos a modificar:

—Ocho objetos en total —dijo Tomás—. Manejable.

Comenzó la implementación. La nota de SAP venía con código ABAP pre-generado que debía insertarse en puntos específicos de los programas estándar.

Yo supervisaba mientras Tomás trabajaba. Primera modificación: añadir validación de caracteres especiales en campos de texto de pedidos.

—Laura, mira esto —Tomás señaló su pantalla—. La nota dice que tengo que modificar el include MV45AFZZ, en la sección USEREXIT_PRICING_PREPARE_TKOMP. Tengo que añadir este código...

Me mostró el fragmento de código ABAP que venía en la documentación de la nota:

—Se ve bien —dije—. Es solo una validación adicional. Copìalo en el user-exit correcto.

Tomás abrió la transacción SE38, navegó al programa MV45AFZZ, y buscó la sección USEREXIT_PRICING_PREPARE_TKOMP.

Y aquí es donde todo empezó a torcerse.

Aunque ninguno de nosotros lo supo hasta 48 horas después.

Martes 14 de noviembre, 11:15 horas.

Tomás pegó el código en el editor ABAP. Lo revisó visualmente. Se veía correcto. Guardó. Activó el programa.

Verde. Sin errores de sintaxis.

—Primera modificación completada —anunció—. Siguiente objeto.

Continuamos con el resto de modificaciones. Todas fluyeron sin problemas. A las 14:30, habíamos completado la implementación en desarrollo.

—Perfecto —dije—. Ahora Carmen tiene que hacer las pruebas funcionales en desarrollo antes de que lo transportemos a QA.

Carmen llegó después de comer. Se sentó en su puesto y empezó las pruebas.

Creó un pedido de venta manual. Cliente de prueba. Material estándar. Cantidad: 10 unidades.

ENTER.

El pedido se grabó correctamente. Número: 8000012345.

—Pricing correcto —confirmó Carmen, revisando los precios—. 125 euros por unidad, 1,250 euros total. Bien.

Probó con descuentos. Con recargos. Con diferentes tipos de clientes. Todo funcionaba.

—Ahora voy a probar con caracteres especiales en los campos de texto, que es lo que valida el parche.

Creó otro pedido. En el campo de "Texto de cabecera" escribió: "Pedido urgente <CLIENTE>"

El sistema mostró un mensaje: "Caracteres especiales detectados en campo de texto. Validación adicional requerida."

—Perfecto —sonrió Carmen—. La validación funciona. Voy a aprobar el texto...

Completó el pedido. Se grabó sin problemas.

—Todo OK en desarrollo —anunció—. Podemos transportar a QA.

Tomás generó el transporte. Orden TR45K900123. Incluyó los ocho objetos modificados. Lo liberó.

Yo lo importé en el sistema de QA esa misma tarde.

—Mañana miércoles Carmen hace las pruebas completas en QA —dije—. Si todo va bien, el jueves por la noche lo pasamos a producción.

Nos fuimos a casa con la satisfacción del trabajo bien hecho.

No teníamos ni idea de lo que habíamos dejado pasar.

Miércoles 15 de noviembre, 09:00 horas.

Carmen llegó temprano, decidida a hacer las pruebas más exhaustivas posible. Era meticulosa por naturaleza, y además, este parche tocaba su módulo. Su reputación estaba en juego.

Abrió un Excel con su checklist de pruebas. Veintitrés escenarios diferentes:

✓ Pedido estándar
✓ Pedido con descuentos
✓ Pedido con múltiples posiciones
✓ Pedido con material configurable
✓ Pedido con pricing especial
✓ Pedido con texto en cabecera
✓ Pedido con caracteres especiales
✓ Pedido con cliente VIP
✓ Pedido con condiciones especiales...

Uno por uno, Carmen fue ejecutando cada escenario. Creaba el pedido manualmente en la transacción VA01. Verificaba los precios. Confirmaba que todo calculaba correctamente.

A las 12:30 había completado 23 de 23 pruebas.

Todas OK.

—Laura —me llamó—. He terminado las pruebas en QA. Todo funciona perfectamente. Ni un solo error. El pricing está intacto, las validaciones de seguridad funcionan, no hay impacto funcional. Podemos pasar a producción.

—¿Probaste todos los escenarios?

—Todos los de mi checklist. Incluso algunos extra por si acaso.

—¿Algún comportamiento extraño?

—Ninguno. El sistema responde exactamente igual que antes, solo que ahora valida los caracteres especiales como debe.

Revisé su documento de pruebas. Estaba impecable. Capturas de pantalla de cada escenario. Resultados documentados. Firmas de aprobación.

—Excelente trabajo, Carmen. Roberto, ¿procedemos con producción mañana jueves?

Roberto revisó la documentación.

—Andrés, ¿algún problema desde compliance?

Andrés había estado supervisando todo el proceso, verificando que siguiéramos los procedimientos SOX.

—Todo correcto. Tres niveles de aprobación: técnica (Laura), funcional (Carmen), y compliance (yo). Documentación completa. Pruebas exhaustivas. Ventana de mantenimiento programada. Plan de rollback preparado. Cero objeciones.

—Entonces está decidido —concluyó Roberto—. Mañana jueves a las 22:00, ventana de mantenimiento. Implementación en producción. Todos en alerta hasta las 02:00 de la madrugada para monitorizar.

Firmamos los documentos de aprobación.

Tres firmas.

Tres profesionales experimentados.

Tres personas que habían seguido el proceso al pie de la letra.

Y los tres completamente ciegos a lo que estaba a punto de pasar.

Jueves 16 de noviembre, 22:00 horas.

La ventana de mantenimiento comenzó puntual. Enviamos notificaciones a todos los usuarios: "Sistema en mantenimiento de 22:00 a 23:00. Funcionalidad reducida durante este periodo."

Tomás importó el transporte en producción. TR45K900123. Los mismos ocho objetos que habíamos probado exhaustivamente en desarrollo y QA.

22:14 - Transporte importado correctamente.
22:15 - Activación de objetos completada.
22:16 - Verificación de sintaxis: OK.
22:17 - Prueba funcional rápida (Carmen creó un pedido de test): OK.
22:20 - Sistema de vuelta a operación normal.

—Implementación exitosa —anuncié—. Ahora monitorizamos durante las próximas horas.

Nos quedamos los cinco en la sala técnica, monitorizando dashboards, revisando logs, verificando que todo fluyera con normalidad.

22:30 - Tráfico de pedidos normal.
23:00 - Sin errores en los logs.
23:30 - Procesamiento batch correcto.
00:00 - Todo estable.

—Creo que podemos respirar tranquilos —dijo Roberto—. Bien hecho, equipo.

Pero mantuvimos la vigilancia hasta las 02:00 como habíamos planeado.

02:00 - Sistema completamente estable. Ni un solo error. Ni una sola anomalía.

—Podemos irnos a casa —dije—. Implementación perfecta.

Nos fuimos con la satisfacción del trabajo impecable.

Habíamos seguido todos los procesos.
Habíamos hecho todas las pruebas.
Habíamos sido diligentes, cuidadosos, profesionales.

Y aún así, habíamos cometido un error.

Uno que descubriríamos 9 horas después.

Yo estaba en mi escritorio, respondiendo emails rutinarios, cuando mi móvil sonó.

Carmen. Su voz sonaba extraña.

—Laura... necesito que vengas al piso 12. Ahora. Hay... hay algo raro con los pedidos.

—¿Qué tipo de raro?

—Precios. Pedidos con precios a cero. Pero solo algunos. Los que entran por EDI.

Sentí un escalofrío recorrerme la espalda.

—Voy para allá.

Tres minutos después estaba en el puesto de Carmen. Ella tenía abiertas varias pantallas de la transacción VA05 (lista de pedidos).

—Mira —me señaló—. Pedidos que entraron esta mañana por la interfaz EDI con Amazon. Todos tienen pricing a cero.

Revisé la pantalla. Pedido 9000045612. Cliente: AMAZON_ES. Quince líneas de material. Precio neto de cada línea: 0,00 EUR.

Abrí otro pedido. 9000045613. Mismo problema.

—¿Cuántos pedidos afectados?

Carmen ya estaba corriendo un reporte.

—Desde las 06:00 de esta mañana... ciento diecisiete pedidos. Todos por interfaz EDI. Todos con precio cero.

—¿Y los pedidos manuales?

—Esos están bien. Solo afecta a EDI.

Mi mente empezó a conectar puntos. La implementación de anoche. El código que modifica pricing. EDI...

—Carmen, ¿probaste escenarios EDI en QA?

Ella me miró con los ojos muy abiertos.

—Yo... probé pedidos manuales. Todos los escenarios de mi checklist son pedidos creados manualmente en VA01. Los pedidos EDI... nunca se me ocurrió probarlos porque no los creamos nosotros, los crean las interfaces automáticamente...

El estómago se me contrajo.

—Tenemos que llamar a Roberto. Ya.

Viernes 16 de noviembre, 11:45 horas.

Roberto convocó reunión de emergencia. Los cinco de nuevo en la sala de juntas.

Carmen proyectó los datos:

—Ciento diecisiete pedidos desde las 06:00 AM. Todos por interfaz EDI. Todos con precio cero. Valor total de mercancía: 1.4 millones de euros. Que ahora mismo estamos a punto de enviar... gratis.

—Dios mío —murmuró Roberto—. ¿Qué ha pasado?

—Tiene que ser el parche de ayer —dije—. Es la única variable que cambió. Tomás, necesito que revises el código que implementamos. Línea por línea.

Tomás ya estaba pálido, abriendo su portátil con manos temblorosas.

—Voy a revisar las modificaciones en el user-exit de pricing...

Silencio tenso mientras Tomás navegaba por el código ABAP en producción.

Abrió el programa MV45AFZZ. Buscó el user-exit USEREXIT_PRICING_PREPARE_TKOMP.

—Aquí está el código que añadí según la nota de SAP...

Y entonces lo vio.

Su cara perdió todo el color.

—No... no puede ser...

—¿Qué? —preguntamos todos al unísono.

—Yo... yo pegué el código en el user-exit equivocado.

Giró su portátil para que todos pudiéramos ver.

La nota de SAP especificaba claramente: "Añadir el siguiente código en USEREXIT_PRICING_PREPARE_TKOMP"

Pero Tomás había pegado el código en USEREXIT_SAVE_DOCUMENT_PREPARE.

Dos user-exits con nombres similares. En el mismo programa. Separados por solo 200 líneas de código.

Uno se ejecuta ANTES del cálculo de precios (el correcto).

El otro se ejecuta DESPUÉS del cálculo de precios, justo antes de grabar el documento (donde Tomás lo puso por error).

—Cuando pegué el código —susurró Tomás, con voz quebrada—, busqué "USEREXIT_PRICING" y aparecieron varios resultados. Elegí el primero que vi. No... no me di cuenta de que había dos user-exits con nombres casi idénticos...

Carmen tomó el hilo:

—Y como el código está en el user-exit de SAVE en lugar del de PRICING, se ejecuta después de que los precios ya se calcularon. Cuando detecta caracteres especiales, llama a la rutina de validación... que en ese punto, por seguridad, limpia ciertas variables. Variables que incluyen... el pricing ya calculado.

—Pero solo en pedidos EDI —añadí, viendo la imagen completa—. Porque los pedidos EDI vienen con referencias externas que tienen caracteres como "<" y ">" en los números de orden de compra del cliente. Los pedidos manuales que creó Carmen en las pruebas no tenían esos caracteres.

Roberto cerró los ojos.

—Por eso todas las pruebas de Carmen pasaron. Porque probó pedidos manuales limpios. Sin caracteres especiales en ningún campo. Los pedidos EDI reales, que vienen con datos del cliente, sí tienen esos caracteres... y disparan la validación en el momento equivocado.

Andrés golpeó la mesa.

—Un error de copiar y pegar. Un maldito error de poner código en el sitio equivocado.

Tomás sollozaba.

—Lo siento... lo siento mucho... yo revisé el código tres veces, verifiqué la sintaxis, funcionó en las pruebas... nunca pensé... nunca se me ocurrió que podía estar en el user-exit equivocado...

Roberto se masajeó las sienes.

—¿Cuál es el daño hasta ahora?

Carmen revisó sus reportes:

—Ciento diecisiete pedidos confirmados a precio cero. Setenta y tres ya están en preparación en almacén. Veintidós ya se enviaron a los clientes. Amazon, El Corte Inglés, Carrefour... todos nuestros clientes principales.

—¿Podemos cancelar los pedidos?

—Los veintidós que ya se enviaron, no. Están en tránsito. Los contratos EDI nos obligan a honrarlos. Los otros cincuenta y uno en almacén... técnicamente podríamos detenerlos, pero tendríamos que dar explicaciones a los clientes. Y los cuarenta y cuatro restantes que aún no se procesaron, esos sí podemos corregirlos.

Roberto hizo cálculos mentales.

—Los veintidós enviados... ¿cuánto es la pérdida?

—Trescientos cuarenta mil euros en mercancía que enviaremos gratis.

Silencio.

—Y si corregimos los pedidos restantes y contactamos con los clientes... ¿podemos contener esto en esos 340K?

—Sí. Pero tenemos que actuar ya. Cada hora que pasa entran más pedidos EDI.

—Bien —Roberto se levantó—. Laura, Tomás: corregid el código AHORA. Pasadlo al user-exit correcto. Carmen: detén todos los pedidos en almacén que aún no se han enviado. Andrés: prepara la comunicación para los clientes. Vamos a tener que admitir un "error técnico temporal" y ofrecer alguna compensación.

—¿Y el transporte? —pregunté—. ¿Hacemos desarrollo-QA-producción otra vez?

Roberto me miró.

—No tenemos tiempo. Los pedidos siguen entrando. Hazlo directamente en producción. Pero esta vez —miró a Tomás con severidad— verifica TRES veces que es el user-exit correcto.

Viernes 16 de noviembre, 12:15 horas.

Tomás y yo nos encerramos en la sala técnica. Abrimos el código en producción con accesos de emergencia.

—Tomás, enséñame exactamente dónde pegaste el código.

Me mostró. Efectivamente, estaba en USEREXIT_SAVE_DOCUMENT_PREPARE en lugar de USEREXIT_PRICING_PREPARE_TKOMP.

—Bien. Vamos a moverlo. Pero primero, copia TODO el user-exit actual a un documento de texto. Backup manual.

Tomás copió el código completo. Lo guardó en un archivo.

—Ahora, borra el código que añadiste en el sitio equivocado.

Borró las líneas añadidas de USEREXIT_SAVE_DOCUMENT_PREPARE.

—Ahora, ve al user-exit correcto. USEREXIT_PRICING_PREPARE_TKOMP. Léeme el nombre en voz alta antes de pegar nada.

—USEREXIT_PRICING_PREPARE_TKOMP —leyó Tomás, letra por letra.

—Correcto. Ahora pega el código AHÍ.

Pegó el código en el lugar correcto. Lo revisamos juntos, línea por línea.

—Guarda. Verifica sintaxis.

Verde. Sin errores.

—Activa el programa.

Activado correctamente.

—Ahora Carmen va a probar con un pedido EDI de test.

Carmen ya estaba lista. Tenía preparada una interfaz EDI de prueba que simulaba un pedido de Amazon con caracteres especiales en la referencia externa.

Lanzó la interfaz.

El pedido se procesó.

Revisamos el precio: 245,50 EUR. Correcto.

—Funciona —exhaló Carmen con alivio.

—Bien —dije—. Ahora necesitamos corregir los pedidos que ya están en el sistema con precio cero.

Carmen ya tenía un programa ABAP preparado para recalcular el pricing de los pedidos afectados.

Lo ejecutamos. Uno por uno, los pedidos se recalcularon.

De los 117 pedidos originales:

—Daño contenido —anunció Carmen a las 13:45—. Pérdida total: 340,000 euros. Podría haber sido mucho peor.

Roberto suspiró.

—340,000 euros por un error de copiar y pegar. Por código en el user-exit equivocado.

Nadie dijo nada.

Todos sabíamos que tenía razón.

Lunes 20 de noviembre, 10:00 horas.

La directora general de Logistic1, Elena Campos, nos convocó a todos. No estaba furiosa. Estaba... decepcionada. Lo cual era peor.

—Trescientos cuarenta mil euros —dijo, con calma glacial—. Esa es nuestra pérdida. No voy a endulzarlo. Es una cantidad significativa. Pero lo que más me preocupa no es el dinero. Es cómo llegamos aquí.

Nos miró uno por uno.

—Revisé todo el proceso. Seguisteis el procedimiento: desarrollo, QA, producción. Tres niveles de aprobación. Pruebas documentadas. Todo según el manual. Y aún así, fracasamos. ¿Alguien puede explicarme cómo?

Tomás levantó la mano temblorosamente.

—Yo... yo cometí el error técnico. Pegué el código en el user-exit equivocado. Es mi responsabilidad.

—¿Por qué pasó eso?

—Porque... porque los nombres de los user-exits son muy similares. USEREXIT_PRICING_PREPARE_TKOMP y USEREXIT_SAVE_DOCUMENT_PREPARE. Cuando busqué "USEREXIT_PRICING", aparecieron varios resultados. Elegí el primero sin leer el nombre completo. Asumí que era el correcto.

—¿Verificaste que era el correcto?

—Verifiqué que el código compilaba sin errores. Que funcionaba en las pruebas de Carmen. Pero no... no verifiqué que estaba exactamente en el user-exit que especificaba la documentación de SAP.

Elena asintió.

—Carmen. Tú hiciste las pruebas. Veintitrés escenarios diferentes. Todos pasaron. ¿Por qué no detectaste el problema?

Carmen respiró hondo.

—Porque todos mis escenarios de prueba eran pedidos manuales. Mi checklist, desarrollada durante años, cubre exhaustivamente todos los casos de negocio que creamos manualmente en VA01. Pero nunca incluí pruebas de pedidos EDI porque... porque asumí que si los pedidos manuales funcionaban, los automáticos también funcionarían.

—¿Por qué asumiste eso?

—Porque siempre ha sido así. En diez años trabajando con SAP, cada vez que probábamos cambios en SD, si los pedidos manuales funcionaban, los EDI también. Nunca nos había dado problemas. Así que... dejó de estar en mi radar.

Elena se volvió hacia mí.

—Laura. Tú supervisaste la implementación técnica. ¿Revisaste el código que Tomás implementó?

—Sí. Revisé que compilara correctamente. Que no tuviera errores de sintaxis. Que siguiera las mejores prácticas de programación ABAP. Pero no... no verifiqué línea por línea que el código estuviera exactamente donde la documentación de SAP decía que debía estar. Confié en que Tomás, siendo tan meticuloso como es, lo había puesto en el sitio correcto.

—Andrés. Tú eres compliance. ¿Tu revisión incluía verificar que el código estaba en el objeto correcto?

Andrés negó con la cabeza.

—Mi checklist de compliance verifica que se sigan los procesos: tres aprobaciones, documentación completa, pruebas ejecutadas, plan de rollback preparado. Pero no incluye revisión técnica línea por línea del código ABAP. Eso se supone que es responsabilidad de Laura y Tomás.

Elena se reclinó en su silla.

—Entonces lo que tenemos aquí es un fallo sistémico. No de una persona, sino de todo el sistema de checks and balances que se supone que debe prevenir exactamente este tipo de errores.

Dejó que eso se hundiera.

—Tomás cometió un error de ejecución. Carmen tenía una brecha en su cobertura de pruebas. Laura confió en lugar de verificar. Andrés tenía un checklist que no cubría este tipo de error. Y Roberto —miró al director de IT— tú coordinaste un proceso que parecía perfecto en papel pero que tenía agujeros que solo se hicieron visibles cuando los atravesó una flecha.

Roberto asintió sombríamente.

—¿Qué va a pasar con nosotros? —preguntó Tomás, con voz temblorosa.

Elena suspiró.

—No voy a despedir a nadie. Primero, porque el error no fue por negligencia o malicia. Fue un error humano en un proceso complejo. Segundo, porque aprender de este error nos va a hacer más fuertes como organización. Pero —su voz se endureció— esto no puede volver a pasar. Así que esto es lo que vamos a hacer...

Elena proyectó un documento en la pantalla:

PROTOCOLO REVISADO DE IMPLEMENTACIÓN DE CAMBIOS EN SAP

1. Verificación de código en pares (OBLIGATORIO)

2. Cobertura de pruebas ampliada (SD)

3. Validación técnica en checklist de compliance

4. Proceso de "buddy check" para implementaciones

5. Post-implementation review obligatorio

—Estas medidas entran en vigor inmediatamente —dijo Elena—. Y cada uno de ustedes va a contribuir a perfeccionarlas. Quiero que cada uno escriba un documento: ¿Qué falló desde mi perspectiva? ¿Qué debería haber hecho diferente? ¿Qué checks adicionales habría prevenido este error?

—Lo haremos —prometió Roberto.

—Bien. Una última cosa —Elena nos miró a todos—. Sé que esto ha sido duro. Sé que os sentís mal. Pero quiero que sepáis algo: los mejores profesionales no son los que nunca cometen errores. Son los que aprenden de ellos y se aseguran de que no se repitan. Vosotros ahora sois más valiosos para esta empresa que antes. Porque habéis pagado 340,000 euros por una lección que jamás olvidaréis.

Febrero, tres meses después del incidente

Estoy en mi apartamento, escribiendo este relato. La ciudad de Madrid brilla afuera, y puedo ver las luces de Logistic1 en la distancia.

Tomás ya no es el programador inseguro que era. Ahora revisa cada línea de código con obsesión casi enfermiza. Y siempre, SIEMPRE tiene un buddy revisor. De hecho, se ha convertido en el mejor revisor de código del departamento. Nadie encuentra errores como él. Porque conoce, íntimamente, cuánto puede costar no encontrarlos.

Carmen actualizó su checklist. Ahora incluye veinte escenarios EDI obligatorios. Y creó una biblioteca de casos de prueba que se ha convertido en el estándar de la empresa. Cada vez que hay un cambio en SD, su checklist es ley.

Andrés expandió su rol de compliance. Ahora hace revisiones técnicas aleatorias. El 10% de todos los transportes a producción son revisados línea por línea por él. Y encontró tres errores en los últimos dos meses que habrían causado problemas. Errores pequeños, pero errores al fin.

Roberto sigue siendo director de IT. Su jubilación se pospuso un año, pero no como castigo. Voluntariamente. Quiere asegurarse de que los nuevos procesos están completamente implementados antes de irse. Su hija está en Harvard. Él trabaja los fines de semana como consultor para pagar la matrícula. Pero me dijo algo que nunca olvidaré: "Prefiero trabajar más años que vivir con el peso de haber arruinado la empresa por tomar atajos."

Y yo... yo aprendí que "confiar pero verificar" no es suficiente. Es "verificar, y luego verificar de nuevo."

Tres meses después del incidente, implementamos otros doce cambios en SAP. Todos siguiendo el nuevo proceso. Todos con verificación en pares. Todos con pruebas EDI incluidas.

Cero errores. Cero pérdidas.

No porque seamos perfectos. Sino porque ahora sabemos que no lo somos.

Y esa, al final, es la única protección real que tenemos.ç

Escribí esto en el nuevo manual de procedimientos de Logistic1:

LECCIÓN APRENDIDA DEL INCIDENTE 3411547

El 16 de noviembre perdimos 340,000 euros. No por malicia. No por incompetencia. Sino por una cadena de pequeñas asunciones razonables que, sumadas, crearon un punto ciego catastrófico.

Asunción 1: "Si el código compila sin errores, está bien implementado."
Realidad: El código puede estar sintácticamente correcto pero en el lugar equivocado.

Asunción 2: "Si las pruebas manuales pasan, las automáticas también pasarán."
Realidad: Los procesos automáticos tienen características únicas que deben probarse específicamente.

Asunción 3: "Si una persona meticulosa hace algo, no necesito verificarlo en detalle."
Realidad: Incluso las personas más cuidadosas cometen errores. La verificación independiente es esencial.

Asunción 4: "Si seguimos el proceso, estamos protegidos."
Realidad: Los procesos solo protegen si cubren los casos reales. Un proceso con agujeros da falsa seguridad.

LA VERDADERA LECCIÓN:

No fue un parche de SAP defectuoso.
No fue un viernes de urgencia.
No fue saltar procesos bajo presión.

Fue un martes normal. Siguiendo el proceso correcto. Con gente competente. Haciendo su mejor esfuerzo.

Y aún así, casi fracasamos.

Porque el diablo está en los detalles. En los nombres de user-exits que se parecen demasiado. En las pruebas que no cubren casos "raros" que resultan ser el 40% del negocio. En la confianza bien intencionada que reemplaza a la verificación rigurosa.

PREGÚNTATE SIEMPRE:

Porque en SAP, como en la vida, los errores más caros no son los obvios.

Son los invisibles. Los que parecen correctos. Los que pasan todas las pruebas... hasta que no lo hacen.