Cómo una empresa industrial eliminó el papel de sus aprobaciones de compras en SAP

Una compañía industrial gestionaba en SAP MM la aprobación de contratos, solicitudes y pedidos de compra a través de procesos manuales.

Con nuestra solución, los documentos se envían automáticamente a firma en el momento en que se generan, SAP se actualiza en tiempo real tras cada aprobación y los responsables disponen de un monitor nativo para consultar el estado de cualquier flujo sin salir del ERP

Aclaración importante: Los personajes, empresas y eventos de esta historia son enteramente ficticios. Si algún nombre coincide con la realidad, es pura casualidad. No se basa en hechos reales.

Julio de 2001. Cerca de Barcelona. Una importante empresa del sector metalúrgico había contratado la empresa de consultoría SAP en la que trabajábamos para la implementación de SAP. Por aquél entonces, ya hacía unos meses que se había arrancado y nos pidieron una automatización nueva: la báscula.

Nuestro protagonista, Jaume, era programador ABAP de la misma consultora SAP que yo y tenía 4 años de experiencia, llevaba ya más de 2 años trabajando en el cliente, había estado involucrado en todos los desarrollos a medida y era el cerebro de la idea del servidor RFC en C para la báscula. Era alegre, cercano, voluntarista y muy trabajador. Pero nunca había programado algo que no fuera ABAP.

El requerimiento inicial

El cliente compraba chatarra, y la báscula de camiones era el instrumento para controlar el peso de cada camión antes y después de descargar.

Al lado de la báscula, había una garita con el display del peso, un operario y un ordenador. El operario leía el peso del display y lo introducía manualmente en una transacción Z de SAP que le hizo Jaume.

El requerimiento consistía en automatizar la lectura desde SAP. Para ello, se planeó generar con el asistente de la SE37 un servidor RFC en C que correría en otro PC viejo conectado a la red y a la báscula por puerto serie RS232.

Jaume generó el código C, consiguió un compilador, generó el binario, lo arrancó, puso un botón en la transacción Z para leer peso que llamaba al módulo de funciones remoto contra el destino RFC del servidor de báscula y funcionó a la primera.

El problema

Eso estuvo funcionando un tiempo, pero enseguida detectaron que esta solución tenía una carencia importante y era que no gestionaba la estabilización de la báscula. Es decir, cuando entra un camión en la báscula y para, durante unos segundos la lectura del peso oscila, y el operador tenía que seguir mirando el display para cuando él consideraba que se había estabilizado, darle al click en el botón de la transacción Z para leer el peso.

Como esta estabilización podía tardar entre 10 y 40 segundos según diversos factores (peso total, dureza suspensiones, presiones neumáticos, viento, reparto peso...) el operario muchas veces se distraía y perdía algunos segundos más empeorando más aún el tiempo del proceso.

Así que la solución a este defecto pasaba por o bien lanzar lecturas a cada segundo desde SAP lo cual es muy anti-sistema ya que privatizas el proceso de trabajo de diálogo durante todas esas esperas hasta que terminas y perjudicas al resto de usuarios, o bien que desde SAP se pidiera la lectura y el programa en C devolviera un peso medio acumulado y el margen de error denotando que todavía no era estable.

En aquel entonces no era sencillo ni rápido conseguir un programador de C, especialmente en el ámbito de una empresa que se respalda en una única empresa de consultoría SAP y que quizá en toda la consultora de unos 80 empleados, solo 1 o 2 había tocado algo de C o los demás se lo callaban.

Así que en lugar de tocarlo un programador C, lo tocó nuestro programador ABAP optimista. A fin de cuentas, él había generado el código C, llevaba funcionando días y sin saber nada de C. ¿Qué podía salir mal? Ese optimismo y que fuera un programador exclusivamente ABAP fue clave para la tragedia que vino después.

En SAP, un programador que quiere modificar un programa ABAP, abre la SE38 si es un report, busca el programa, le da a modificar, y si después de un rato ve que lo que ha hecho es un destrozo lo regresa a la versión anterior y cuando lo tiene corregido y probado lo transporta al siguiente sistema para pruebas y producción. Esto lo tenemos clarísimo todos en SAP.

Además ocurre otro problema. Y es que, báscula solo hay una. Por lo tanto, las pruebas y las correcciones pertinentes del programa en C se van a tener que efectuar in-situ, entre camión y camión. Con el operario al lado, la transacción Z de pesaje abierta para ir introduciendo los pesos manualmente sin pasar por el programa en C si está fallando en ese momento...

La tragedia

Así que tenemos los siguientes ingredientes para la tragedia: un programador que no ha tocado nada más que ABAP y no sabe C, un código en C generado con un asistente que nadie se molestó en entender porque funcionó a la primera y que habría que reestructurar casi completamente, una única báscula donde desarrollar, probar, corregir mientras van pasando camiones a razón de uno por minuto y, por si fuera poco, un espacio físico de trabajo muy limitado que implicaría turnarse con el operario para trabajar entre camión y camión.

Pero ninguno de esos factores causó un solo rasguño en el optimismo y la alegría de Jaume. Así que a media mañana, se fue para la garita a pleno Sol y se puso a modificar el programa, a mover bloques de código de aquí para allá, nuevas funciones, más variables, más bucles, para calcular el peso medio acumulado, el margen de error, leer a cada segundo... recordemos, 2001, ni Claude, ni Stackoverflow, ni Google... solo Jaume, el operario, la garita, el Sol y camiones, más y más camiones, .. calor, gente nerviosa, un lenguaje con una sintaxis muy distinta al único lenguaje que conoces, ninguna ayuda del exterior... y levantándose a cada minuto para intentar ir haciendo pasar los camiones. Después de más de una hora, Jaume consiguió que el programa compilara, lo probó pero ahora no funcionaba ni siquiera la lectura desde SAP. Algo había dejado mal y no se ejecutaba nada cuando se pulsaba el botón desde la transacción Z. Tampoco podía saberlo a ciencia cierta, ya que el código no generaba logs.

Dejarlo a medias no era una opción, se habían acumulado tantos camiones que ni siquiera poniendo el operario a full introduciendo los pesos manualmente terminaban en todo el día.

Cuando Jaume pensó en la opción de abortar un sudor frío recorrió su frente.... No, no era posible... No pensó en guardar una copia de seguridad del código ni del binario. Ahora solo podía seguir adelante, intentar recomponer y dejar el código como estaba antes de empezar. La situación era crítica, y el operario ya no se atrevió a hacerlo levantar de la silla.

La cola de camiones llegó a la autopista. Eso provocó la visita inesperada de la guardia civil en la misma garita puesto que era donde terminaba la cola. Ahora Jaume, tenía un "poco" más de presión, con dos guardia civiles metidos en esa diminuta garita, hablando por radio para informar de la situación y respirandole en el cogote para que desatascara la báscula.

Finalmente, Jaume en un instante de lucidez, cayó en la cuenta que el código que generó con la SE37 funcionó a la primera, así que lo regeneró, lo compiló y lo montó y se produjo el milagro. Poco a poco se fue reduciendo la cola de camiones pero las retenciones en la autopista duraron todo el día.

Cualquier programador no SAP habría empezado con una copia de seguridad de los ficheros del código y del binario. Cualquier programador que conozca dos o más lenguajes conoce los riesgos de tocar código en un lenguaje desconocido. Y quiero pensar que si alguien le hubiera leído los riesgos a Jaume ni con todo su optimismo se hubiese atrevido a seguir adelante. 

La solución

El cliente aprendió una lección importante ese día, y ante la escasez de programadores en C, solicitó un programador en Visual Basic que había más oferta para rehacer el servidor de báscula con la prohibición explícita de usar el asistente. Conmigo se sentó todo un referente del sector IT hoy en día para ver como implementaba todas y cada una de las especificaciones: totalmente configurable, logs con nivel de traza, panel de control, servicio de Windows, monitorizable desde su plataforma... Lo que hiciera falta para que nunca más se repitiera la cadena de sucesos anterior. 

Ah, por cierto, no supe nada de lo ocurrido anteriormente hasta después de ponerlo en producción en esa misma garita. Y lo agradecí, ya conocía los riesgos, no me hacía falta conocer el antecedente.