Me crucé con mi primer Workflow de SAP hace casi 15 años. Había que hacer unos ajustes en un Workflow que ya estaba funcionando y me enviaron sin formación ni conocimientos para que hiciese lo que pudiese… Intenté no entrar en pánico, leí en Google todo lo que pude, me enteré de la décima parte, me remangué y después de muchas vueltas aquello quedó más o menos apañado. Salvé el pellejo y a otra cosa. Ahora con perspectiva, me da la impresión de que el 80% de los consultores que dicen que saben algo de Workflows simplemente han pasado por una experiencia parecida. He hecho muchas entrevistas y cada vez que un programador me dice que sabe un poco de Workflow me suena a aquello de inglés nivel medio…

Unos meses después, mientras andaba con temas de BW, me dijeron que «en mis ratos libres» fuera montando los Workflows para una nueva implantación de SAP ECC. Ojiplático me quedé! Aunque la verdad es que estuve tan a gusto con mi SAPALL. Hice lo que pude… pero ahora con perspectiva es un facepalm en toda regla… El proyecto arrancó con los Workflows corriendo con mi usuario en lugar del usuario WF-BATCH en el destino lógico, como no sabía leer correctamente las tablas de SAP monté el log haciendo previamente grabaciones en tablas Z, los WorkItems se quedaban colgados por no tratar correctamente los eventos de modificación o borrado. Vamos, lo que yo mismo me he ido encontrando en varios clientes y he ido arreglando, pero esa vez el culpable fui yo.

El caso es que sin pretenderlo, sin formación, y sin más bagaje que mi propia experiencia, con el tiempo  me convertí en «el experto en Workflows». Etiqueta que nunca me ha gustado porque la realidad es que hay muchísimas cosas que sigo sin saber. Como diría Antonio de Ancos, lo que si he ido desarrollando es un cierto sentido común. Sé qué cosas hay que tener en cuenta (me lo diga o no el cliente) y se qué cosas van a ir pasando con el tiempo. Hablaremos de esto en una próxima entrada: «Como definir y cómo construir un Workflow».

En esos inicios, un compañero me dijo que para que me molestaba en aprender Workflows, que eso lo iban a quitar ya. No tenía yo ninguna visión de lo que planeaba o no planeaba SAP, tan solo intentaba digerir todo lo que me iban poniendo en el plato. En cualquier caso, me parece que mi compañero se equivocó. En pleno 2020 se puede decir que el Workflow de SAP sigue muy muy vivo, y me refiero al Workflow Builder de SAP.

Como alternativa, por el camino me crucé con los Guided Procedures en Netweaver. Existir siguen existiendo, pero tuvieron el mismo éxito que las Web Dynpro Java de su generación. Un producto complicado y aislado.

Ya metido en SRM y el resto de productos de la Business Suite (CRM, PPM, MDG, GRC, etc) me encontré con los Workflows basados en BRF, Business Rule Framework, disponibles desde la versión 7.1 de SAP NetWeaver. Sin duda son una herramienta muy potente y muy flexible. Pero claro, todo tiene un precio. Son muy difíciles de configurar y luego el mantenimiento también resulta bastante complicado. Por no hablar de montar un log dinámico de proceso. Además están encapsulados en la capa Netweaver. Como concepto y tecnología, los BRF o su evolución BRF+ siguen sobreviviendo, estando presentes en PI/PO, S/4 o como servicio independiente en SCP. Pero su vinculación con los Workflows no ha tenido un gran éxito. Pero ojo, funcionar funcionan y muy bien.

Ya en S/4 HANA siguen estando presentes los tradicionales Workflows con el Workflow Builder pero con una vuelta de tuerca adicional: los Workflow Scenario. Y creo que aquí si que SAP ha encontrado un buen punto de equilibrio. Una herramienta fácil de usar, fácil de mantener y muy potente. Un experto en procesos de negocio puede configurar fácilmente el escenario deseado para su caso de negocio. SAP nos ha preparado para ello una aplicación FIORI muy sencilla e intuitiva. Esto reajusta por detrás el Workflow el cual se puede después modificar con las transacciones habituales (bueno, en lugar de SWDD tenemos SWDD_SCENARIO). Aquí puede entrar el consultor con un perfil más técnico a hacer los ajustes necesarios. En el siguiente post de esta serie de Workflow veremos con algo de detalle un caso práctico de implantación de un Workflow con esta tecnología en el caso de la gestión de cuentas bancarias BAM en S/4 HANA.

Siguiendo la línea temporal nos encontramos con los Workflows en SAP Cloud Platform. Mi opinión personal la tengo clara: me encantan. Gracias a ellos conseguí mi entrada gratis para el SAP TECHED de Barcelona 2019. Sin embargo, si hay futuro no lo veo nada claro. Para empezar no solo es imprescindible el SCP sino que solo tiene verdadero sentido en empresas que estén realmente asentadas con la plataforma, que son muy muy pocas. Además no basta con que tengamos el típico escenario en SCP como portal para mostrar contenido de nuestro SAP,  para que el Workflow tenga realmente sentido tendrá que haber varios sistemas (SAP o no SAP) involucrados. Pero si estamos ahí, en un escenario con procesos de aprobación o flujos de trabajo con varios sistemas involucrados con SCP como piedra angular de la arquitecta, aquí el Workflow de SCP es un cañón. Eso sí, a desarrollar a mano en SAPUI5, gestionar APIs, etc, que esa es otra…

Veremos como evolucionan las cosas pero lo que está claro es que los Workflows siempre van a estar ahí. Irá variando la tecnología que los soporta. También varía lo que se le pide al Workflow puesto que según avanza la automatización cada vez tendrá que hacer más cosas, no sólo aprobar o rechazar, sino que además queremos acceder a nuestros elementos de aprobación desde cualquier sitio, con cualquier dispositivo, hacia todo nuestros sistemas, etc. Pero siempre las compañías necesitarán gestionar sus flujos de trabajo entre sistemas y personas. Sin duda le recomendaría aprender Workflows a cualquier técnico de SAP.