🧨 SAPocalypsis Now Episodio 18

¿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.

Nuestra protagonista de hoy es consultora de servicios, de esas que no venden tecnología pero dependen de ella más de lo que les gustaría admitir, una empresa lo suficientemente grande como para tener SAP como columna vertebral de su negocio y lo suficientemente cercana como para que cada cliente importase de verdad. No desarrollaban por desarrollar, cada proceso tenía un impacto real, cada documento salía fuera del sistema y llegaba a alguien y en ese equilibrio entre negocio y tecnología, entre confianza y automatización, fue donde empezó a gestarse un error tan pequeño que parecía inofensivo… y tan real que acabaría saliendo del sistema para convertirse en algo mucho más difícil de controlar.

Había algo en aquella empresa que siempre se respiraba aunque nadie lo dijera en voz alta y es que no eran una consultora tecnológica al uso, no vendían código, no vivían de desarrollos complejos ni de arquitecturas imposibles, vivían de sus clientes, de su confianza, de la cercanía y del servicio, SAP era simplemente la herramienta que utilizaban para sostener todo eso y precisamente por eso cada pequeño detalle tenía un impacto mucho mayor del que parecía, porque cuando algo fallaba no era solo un error técnico, era algo que el cliente veía, sentía y recordaba.

Álvaro llevaba ya un tiempo allí, lo suficiente como para sentirse parte del equipo pero no tanto como para haber vivido una situación realmente crítica, era de esos perfiles híbridos que entienden el negocio pero no tienen problema en meterse en código cuando hace falta, resolutivo, implicado, con ganas de hacerlo bien y aquel proyecto en el que estaba trabajando le motivaba especialmente porque no era un simple ajuste ni un pequeño cambio, estaban construyendo un flujo nuevo dentro del proceso de facturación de ventas que buscaba dar un salto en calidad, algo más cuidado, más automático, más profesional, querían que cuando una factura se generase no fuese solo un documento más, sino una comunicación completa hacia el cliente, con un correo bien estructurado, un texto claro, un PDF adjunto perfectamente presentado y todo ello enviado de forma automática sin intervención manual.

Durante semanas el equipo trabajó en ese flujo, afinando detalles, ajustando plantillas, revisando condiciones, probando distintos escenarios y como ocurre casi siempre en estos casos, empezaron utilizando datos ficticios, luego datos más cercanos a la realidad y finalmente datos completamente reales, clientes reales, importes reales, conceptos reales, porque en el fondo todos sabemos que si no pruebas con datos reales siempre hay algo que se escapa cuando llegas a producción y esa fue precisamente la trampa en la que cayeron, no el hecho de usar datos reales, sino el hecho de hacerlos indistinguibles de la realidad.

Una tarde cualquiera, de esas en las que el tiempo pasa más rápido de lo que debería y en las que uno quiere dejar algo bien cerrado antes de terminar, Álvaro decidió ejecutar una prueba completa del flujo, no quería validar solo una parte, quería verlo todo funcionando de principio a fin, generó varias facturas en el entorno de TEST, lanzó el proceso automático y observó cómo el sistema hacía su trabajo, los documentos se generaban, el correo se construía, el PDF se adjuntaba y todo terminaba en la SOST, donde como era habitual los correos quedaban encolados sin salir al exterior, como debía ser, como siempre había sido y ese pequeño detalle le dio una tranquilidad que en ese momento parecía lógica pero que en realidad era engañosa.

Al día siguiente Marta, la funcional de ventas, quiso hacer sus propias pruebas, ella tenía otra forma de validar las cosas, no le bastaba con ver que el proceso funcionaba en SAP, necesitaba verlo como lo vería el cliente, en su bandeja de entrada, en Outlook, con el formato final, con el impacto real, así que entró en la SOST, revisó los correos generados, seleccionó varios y decidió forzar el envío manual, algo que sabía que se podía hacer y que en otras ocasiones se había hecho sin mayor problema, el gesto fue rápido, natural, casi automático, seleccionó varias líneas y ejecutó el envío, revisó su correo, vio que todo llegaba correctamente, que el formato era bueno, que el texto era claro, que el PDF se veía perfecto y con esa sensación de trabajo bien hecho continuó con su día sin darse cuenta de que en aquella selección había una línea más, una única línea que no correspondía a un correo de pruebas, una línea que contenía la dirección de un cliente real.

Ese cliente no era cualquiera, era un cliente recurrente, de los que confían, de los que llevan tiempo trabajando contigo y no cuestionan cada documento porque la relación ya está consolidada y además daba la casualidad de que hacía poco había solicitado unos servicios muy similares a los que aparecían en aquella factura de prueba, cuando recibió el correo no tuvo ningún motivo para dudar, el asunto era correcto, el contenido era profesional, el documento adjunto tenía el formato habitual y el importe encajaba perfectamente con lo que esperaba, no había ninguna marca de agua, ninguna indicación de que aquello fuese una prueba, ningún detalle que lo diferenciase de una factura real, así que hizo lo que cualquier cliente haría en esa situación, procedió al pago.

Pasaron varios días sin que nadie en la empresa sospechara nada, el proyecto continuaba, se seguían haciendo ajustes, se afinaban detalles y el flujo parecía cada vez más sólido, hasta que una mañana en el departamento financiero alguien comentó que un cliente afirmaba haber pagado una factura que no aparecía en el sistema, en ese momento empezó esa sensación incómoda que aparece cuando algo no encaja, revisaron los datos, buscaron la factura en producción y no existía, comprobaron los registros, los documentos, los movimientos y no había rastro de ella, sin embargo el cliente había enviado un comprobante de pago junto con un PDF que parecía completamente válido, fue entonces cuando alguien decidió mirar en el entorno de TEST y ahí estaba, la factura de prueba, generada días atrás, enviada desde la SOST y convertida sin querer en una factura “real” a ojos del cliente.

El momento en el que todo encajó fue silencioso, incómodo, nadie levantó la voz pero todos entendieron la gravedad de lo ocurrido, no había sido un fallo técnico complejo ni un bug del sistema, había sido una combinación de decisiones aparentemente inofensivas, datos demasiado reales, ausencia de identificadores de prueba y un envío manual ejecutado sin revisar todos los destinatarios, cuando hablaron con el cliente la conversación fue complicada porque desde su punto de vista él había recibido una factura perfectamente válida y había actuado en consecuencia, la explicación de que se trataba de una prueba no cambiaba el hecho de que el documento no se distinguía en absoluto de una factura real, la situación se resolvió económicamente con ajustes y compensaciones, pero el daño no estaba en los números, estaba en la percepción.

Con el tiempo el cliente fue reduciendo su volumen de trabajo con la consultora, no de forma brusca, no de un día para otro, pero sí de manera progresiva, menos solicitudes, menos proyectos, menos confianza, hasta que finalmente decidió trabajar con otro partner y aunque nadie dentro de la empresa señaló aquel incidente como la única causa, todos sabían que había sido un punto de inflexión, una grieta en una relación que hasta entonces parecía sólida.

El proyecto, a pesar de todo, siguió adelante, se corrigieron los procesos, se crearon datos de prueba específicos, se implementaron correos ficticios, se añadieron marcas de agua en los documentos, se limitaron los envíos manuales y se establecieron controles más estrictos, semanas después el flujo se puso en producción y funcionó correctamente, sin errores, sin incidentes, exactamente como se había diseñado desde el principio, pero para Álvaro aquel proyecto ya no era solo un desarrollo bien ejecutado, era un recordatorio constante de lo que puede pasar cuando algo aparentemente pequeño se escapa de control.

A nivel profesional, aquel episodio le marcó más de lo que esperaba, durante un tiempo dudó más de la cuenta, revisaba todo dos veces, incluso tres, no solo el código o la lógica sino detalles mucho más simples como los destinatarios, los datos, los textos, aprendió a desconfiar de las pruebas demasiado perfectas y a cuestionar aquello que “parece correcto” sin evidencias claras, con el tiempo ganó seguridad de nuevo, pero ya no era el mismo, había entendido algo que no se aprende en cursos ni en manuales, que en SAP los errores más peligrosos no son los que rompen el sistema, sino los que funcionan exactamente como deberían en el contexto equivocado y desde entonces cada vez que lanza un proceso que implica comunicación hacia fuera, se detiene un segundo más de lo habitual, respira y revisa, porque sabe que en ese pequeño gesto puede estar la diferencia entre una simple prueba… y un SAPOCALYPSIS real.

Cuando en SAP algo sale del sistema, deja de ser una prueba y se convierte en realidad y si los datos parecen reales pero no lo son, el error ya no está en el código… está en la confianza que se rompe sin posibilidad de hacer rollback.