This website uses cookies

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

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.

Hay una sensación que solo conoce quien ha trabajado cerca de Tesorería. No es el miedo a que algo falle. Es el miedo a que algo funcione demasiado bien.

Me llamo Inés, soy consultora FI, y esta historia ocurrió el último viernes de julio en una conservera del norte. Cuatro plantas, unos ochocientos proveedores activos y una tesorería que funcionaba como un reloj. Un reloj antiguo, eso sí, de los que hay que darles cuerda a mano.

El último viernes de julio no es un viernes cualquiera en una empresa española. Es el día en que media plantilla tiene ya la cabeza en la playa y la otra media intenta cerrar todo lo pendiente para que agosto no se convierta en un campo de minas. En Tesorería es, además, el día de la última propuesta de pagos antes del verano. Si a un proveedor no le pagas ese viernes, no le pagas hasta septiembre. Y un proveedor de latas, de aceite o de transporte refrigerado al que no pagas en agosto es un proveedor que el lunes te llama, el martes te llama más fuerte y el miércoles deja de servirte.

Ramón, el tesorero, lo sabía mejor que nadie. Veintidós años en la casa y el último hombre del edificio que todavía imprimía la propuesta de pagos para repasarla con un rotulador fosforito. Ese viernes tenía prisa por un motivo que nos había contado toda la semana. Su hija se casaba al día siguiente en Comillas. Llevaba la corbata en la mochila y un ojo permanentemente puesto en el reloj del ordenador.

—Hoy no me falláis, ¿eh? —nos dijo a primera hora, medio en broma—. Que mañana me toca llorar por otros motivos.

El equipo de soporte SAP éramos tres. Yo, de guardia funcional esa semana. Sergio, el de Basis, que había avisado de que a las tres cogía el coche hacia Cádiz. Y Álvaro, que llevaba once días en el proyecto, venía de hacer prácticas en otra consultora y tenía ese entusiasmo de las primeras semanas en el que uno cree que todo tiene solución en menos de diez minutos.

La propuesta se lanzó en la F110 a las diez de la mañana. Cuatrocientas doce transferencias, un millón ochocientos setenta mil euros. Ramón la revisó línea por línea con su fosforito, bloqueó tres facturas de un proveedor con el que había una reclamación abierta, y a las doce y cuarto dio el visto bueno para la ejecución real.

La ejecución terminó sin errores. Quedaba el último paso, el que de verdad mueve el dinero. Generar el soporte de pago, el fichero SEPA que va al banco, y de paso imprimir los avisos de pago para los proveedores. El job dejaba el fichero en una carpeta del servidor, y un proceso del middleware lo recogía cada quince minutos y lo enviaba al banco por el canal seguro. Nadie tocaba nada a mano. Era la parte del proceso de la que todo el mundo estaba más orgulloso. Cero intervención humana.

Ramón lanzó el soporte de datos y la impresión a las doce y veinticinco y se fue a comer con su mujer, que había venido a buscarle para cerrar no sé qué de las flores del banquete.

A la una y diez, Álvaro se acercó a mi mesa con el portátil en la mano.

—Inés, el job de los pagos ha cancelado.

Lo miré en la SM37. En rojo. Cancelado. Entré al log y el error venía de la impresión de los avisos, un problema con el dispositivo de salida. Esa impresora llevaba dando guerra desde el lunes. La habían cambiado de planta y nadie había actualizado la configuración en SAP.

Y aquí viene la parte de la que más me arrepiento. No porque hiciera algo especialmente estúpido, sino porque hice algo completamente razonable con una información que me faltaba.

—Vale —le dije—. Cambia el dispositivo de salida por la impresora de Tesorería de la planta dos y relánzalo desde la F110. Ramón tiene prisa y el banco tiene corte a las dos y media.

Álvaro lo relanzó. Al hacerlo, SAP le sacó un mensaje. Algo sobre que para esa ejecución ya existían soportes de pago. Álvaro, once días en el proyecto, con su tutora diciéndole que había prisa y un aviso amarillo que no bloqueaba nada, hizo lo que hemos hecho todos alguna vez. Leyó por encima, entendió "aviso", y le dio a continuar. No me dijo nada porque no le pareció importante. Yo tampoco se lo pregunté porque el job terminó en verde y los avisos salieron por la impresora correcta.

Le escribí a Ramón que había habido un problema con la impresora pero que estaba resuelto, que se fuera tranquilo a su boda. Me contestó con un pulgar hacia arriba y una foto de un centro de flores blancas.

Sergio cogió el coche a las tres. Yo me fui a las cuatro. Álvaro se quedó un rato más repasando unas notas de formación.

Nadie miró la carpeta del servidor.

El lunes a las ocho y cuarto me sonó el móvil. Era Celia, la técnica de Tesorería que se quedaba sola en agosto.

—Inés, ¿tú sabes por qué tenemos casi dos millones menos en la cuenta de lo que debería?

Le dije que la llamaba en diez minutos. Tardé cuarenta.

Abrí la FDTA, donde se gestionan los ficheros de pago que genera SAP. Para la ejecución del viernes no había un fichero.

Había dos.

El primero, de las doce y treinta y uno. El segundo, de las trece y catorce. Mismas transferencias. Mismo importe. Mismos proveedores. Distinto identificador de mensaje.

Me quedé mirando la pantalla con la sensación de que alguien me había vaciado el estómago con una cuchara.

Lo que había pasado era tan simple como cruel. El job del viernes no había cancelado por el fichero. Había cancelado por la impresora. Y dentro del job, el fichero se generaba antes que la impresión de los avisos. Cuando el job murió, el fichero ya estaba escrito y en la carpeta. A las doce y cuarenta y cinco, puntual, el middleware lo recogió y lo mandó al banco.

Cuando Álvaro relanzó, SAP avisó de que ya había soportes generados. Aceptado el aviso, hizo exactamente lo que se le pedía. Un fichero nuevo, completo, impecable, con un identificador distinto. A las trece y quince, el middleware lo recogió y lo mandó también.

El banco tenía control de duplicados, pero por identificador de mensaje. Dos ficheros con identificadores distintos, válidos, firmados por el canal autorizado de la empresa, eran para el banco dos órdenes legítimas. Y las ejecutó las dos.

Cuatrocientos doce proveedores habían cobrado dos veces el último viernes de julio.

Llamé a Celia. Llamé al director financiero, que estaba en Menorca. Llamé a mi responsable. Y luego hice la llamada que más me costó, la de Ramón, que estaba en un hotel de Comillas con la camisa del banquete todavía colgada en la puerta del armario.

Se quedó callado unos segundos. Luego preguntó una sola cosa.

—¿El fichero se generó antes o después de que cancelara el job?

—Antes.

—Ya —dijo—. Voy para allá.

Llegó a las tres de la tarde, sin afeitar, con su mujer esperando en el coche, porque volvían a casa de todas formas y ella no pensaba dejar que se comiera esto solo.

Lo primero fue hablar con el banco. Con las transferencias SEPA se puede pedir la devolución de un pago enviado por duplicado, pero no es un botón mágico. El banco de cada proveedor tiene que tramitarlo, y en muchos casos hace falta que el propio proveedor dé su conformidad. Traducido, había que convencer a cuatrocientos doce proveedores, uno a uno, de que devolvieran voluntariamente un dinero que ya tenían en la cuenta. En agosto.

Montamos una sala con cuatro teléfonos, una hoja de cálculo compartida y la lista de proveedores ordenada por importe. Ramón llamaba a los grandes, a los que conocía desde hacía veinte años. Celia y dos personas de Compras se repartían el resto. Yo sacaba de SAP los listados, las partidas y la documentación que pedía el banco para cada solicitud. Álvaro, que no había dormido bien desde el lunes, se ofreció a hacer lo que hiciera falta, desde llamar a proveedores hasta traer cafés.

Los primeros días fueron rápidos. Las empresas grandes, con administración seria, habían visto el duplicado y lo devolvieron casi sin preguntar. Algunas incluso nos habían llamado ellas antes. Un proveedor de cartón de Burgos lo devolvió el mismo lunes con un correo de una sola línea: "esto os habréis dado cuenta, ¿no?".

Luego llegaron los difíciles. El transportista autónomo que no cogía el teléfono porque estaba en ruta por Portugal. La pequeña empresa de etiquetas cerrada por vacaciones hasta el veinte de agosto. El proveedor de aceite que no pensaba devolver nada hasta que le pagáramos una factura antigua que tenía en disputa con Compras desde marzo. Ramón se pasó una tarde entera negociando con él, con la voz tranquila y el fosforito apretado en la mano como si fuera a partirlo.

Y luego estaban los casi imposibles. Dos proveedores que estaban en concurso de acreedores. Ese dinero ya no dependía de ellos sino de la administración concursal, y recuperarlo iba a ser cuestión de abogados y de meses.

A finales de septiembre se había recuperado casi todo. Faltaban unos ciento treinta mil euros, la mayor parte atrapados en esos dos concursos y en un par de proveedores extranjeros con los que la comunicación era, por decirlo suave, lenta. El director financiero, ya de vuelta de Menorca, lo resumió en una reunión con una frase que me sigue sonando cada vez que abro la F110.

—No hemos perdido ciento treinta mil euros. Hemos perdido agosto.

Porque eso fue lo que realmente costó. Un departamento entero, en el mes en que se suponía que iba a estar tranquilo, persiguiendo dinero propio. Un tesorero que pasó de padre de la novia a gestor de crisis en menos de cuarenta y ocho horas. Una empresa con la caja tensionada en plena campaña de verano, retrasando pagos legítimos porque había pagado dos veces los del mes anterior.

En la revisión posterior salieron más cosas. El middleware comprobaba que el fichero fuera válido, pero no comparaba importes ni beneficiarios con el anterior. El procedimiento de Tesorería no decía qué hacer si el job de pagos cancelaba, porque en seis años nunca había cancelado. Y la impresora que lo empezó todo seguía mal configurada porque el ticket del cambio de planta estaba asignado a un técnico que se había ido de la empresa en junio.

Pero si soy honesta, ninguna de esas cosas fue la causa real.

La causa real fue que un job en rojo me pareció un job que no había hecho nada. Y no es lo mismo. Un job cancelado no te dice que no haya pasado nada. Te dice que no ha terminado. Lo que hizo antes de morir sigue ahí, esperando a que alguien lo recoja. A veces lo recoge un proceso automático que funciona exactamente como lo diseñaste. Y entonces el problema no es que algo falle. Es que todo funciona perfectamente, dos veces.

Álvaro me lo preguntó un día de septiembre, tomando un café en la máquina de la planta dos, justo al lado de la famosa impresora.

—¿Tú crees que fue culpa mía?

Le dije la verdad. Que él aceptó un aviso que nadie le había enseñado a leer. Que yo le mandé relanzar sin mirar qué había dejado hecho el primer intento. Y que la respuesta estaba a una transacción de distancia, en la FDTA, a la que nadie miró porque teníamos prisa, porque era viernes, porque era julio y porque había una boda en Comillas.

Ramón se jubiló dos años después. En su despedida, delante de todo el departamento, sacó de la mochila un fosforito gastado y me lo regaló.

—Para que repases los ficheros —dijo—. Y los avisos amarillos.

MORALEJA

  1. Un job cancelado no es un job que no ha hecho nada. Antes de relanzar cualquier proceso que mueve dinero, comprueba qué dejó hecho antes de morir. En pagos, la FDTA está a un clic.

  2. Un aviso que no bloquea sigue siendo un aviso. Si nadie le explica a la persona que lo lee qué significa, ese aviso no protege nada.

  3. Los procesos automáticos no tienen sentido común. Si algo envía al banco todo lo que encuentra en una carpeta, necesita control de duplicados por importe, fecha y beneficiario, no solo por identificador.

  4. El procedimiento que nunca se escribe es el del día que falla. Seis años sin incidencias no son una garantía. Son la razón por la que nadie sabe qué hacer cuando por fin pasa.

¿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

Ver más
caret-right