El tiempo de los faros ha terminado

Como parte de un trabajo de estudiante en 1998, pregunté ingenuamente al administrador de SAP Basis cómo podía acceder a este SAP desde mi aplicación de Visual Basic.

En aquella época, los usuarios tenían que copiar y pegar los datos de los materiales desde la interfaz gráfica de SAP a la aplicación externa de almacén. Sin mediar palabra, me puso en la mano un libro gris impreso de tapa blanda:

"Mastering SAP Remote Function Call in C/C++". En retrospectiva, probablemente era su forma de decir: No lo hagas.

Han pasado casi 20 años desde entonces y mucha agua ha corrido por el Leimbach pasando por delante de la sede de SAP en Walldorf. Las preguntas sobre los beneficios empresariales y el enfoque técnico adecuado siguen siendo pertinentes.

Integración de datos y procesos

Cuando se trata de interfaces SAP, distinguimos básicamente dos grandes áreas: Integración de datos e integración de procesos.

La integración de datos implica generalmente el transporte de grandes volúmenes de datos estructurados. Su finalidad se observa en ámbitos relacionados con el análisis de datos.

Esto puede ir desde simples gráficos para el nivel directivo hasta análisis predictivos y minería de datos con ayuda de inteligencia artificial. En cualquier caso, esta área debe considerarse aguas abajo de las transacciones empresariales clásicas que suelen estar cubiertas por SAP ERP.

Si se quedara completamente en el mundo SAP, cubriría los requisitos de análisis de datos de la forma clásica con BW, Hana y las herramientas front-end de BO.

La segunda gran área es la integración de procesos. Aquí es donde la transferencia de datos se desglosa en transacciones individuales. Un proceso puede iniciarse en SAP y transferirse a un subsistema.

Un buen ejemplo de ello sería un presupuesto de cliente creado en SAP SD y enriquecido posteriormente con datos adicionales, imágenes y dibujos fuera de SAP.

La dirección opuesta es igualmente concebible. La información sobre un nuevo registro de datos maestros de materiales que se va a crear se recopila de varios departamentos a través de un flujo de trabajo ajeno a SAP. Esto implica a gestión de productos, compras y posiblemente a colegas de logística.

Sólo cuando toda la información está completa y es coherente se transfieren los datos y el proceso de inversión a SAP MM. Prácticamente todas las interfaces de SAP pueden dividirse en estas dos categorías de integración de procesos y datos, cada una de las cuales es técnicamente completamente diferente.

Puntos de ruptura predeterminados

Antes de examinar los aspectos técnicos, deberíamos plantearnos la pregunta del porqué. Con su gama casi inabarcable de productos y módulos, SAP cubre teóricamente todas las necesidades de casi todos los clientes SAP existentes.

Cada interfaz entre sistemas o fabricantes suele verse como una especie de punto de ruptura predeterminado que resulta especialmente molesto cuando no funciona. Y, por supuesto, la culpa suele ser de la otra parte. Y sin embargo, hay argumentos que ahogan estas preocupaciones.

Los usuarios piden a menudo un mayor rendimiento. Me gustaría defenderme expresamente de la acusación generalizada de que SAP es lento, pero sin embargo es casi una tradición en la empresa de Walldorf desde su fundación diseñar su software de tal forma que el hardware disponible siempre resulte un poco demasiado lento para las aplicaciones.

Durante mucho tiempo, esto fue especialmente cierto en el caso de SAP BW. Sin duda, el uso de Hana ha relativizado un poco las cosas, pero era el área de análisis de datos en particular la que ponía a prueba la paciencia de los usuarios hasta el límite y más allá.

Por tanto, es lógico que muchos clientes actuales de SAP encuentren una relación significativamente mejor entre costes y rendimiento en los subsistemas externos.

Otro argumento importante es la mezcla con datos ajenos a SAP, ya sea en la integración de datos o de procesos. Mantener los datos de la empresa completamente dentro del software de un fabricante solo funciona de forma generalizada en los folletos brillantes, pero nunca en la vida real.

Y sí, por supuesto que SAP ERP y SAP BW ofrecen la opción de cargar datos externos en SAP y procesarlos allí, pero no se trata en absoluto de un procedimiento realista y asequible.

Si necesita datos SAP y no SAP al mismo tiempo, tendrá que buscar un lugar fuera de SAP o tendrá que dedicarle mucho tiempo y un gran presupuesto.

Especificaciones de proporciones bíblicas

Todo el mundo habla de digitalización. Los medios de comunicación, los políticos y los jefes de empresa interpretan todo lo posible y lo imposible con este término. También proporciona nuestro tercer argumento, que en realidad es mucho más antiguo que el propio término digitalización: La agilidad.

Sin duda, debido a la antigüedad y larga historia de SAP, es frecuente encontrar ciertos patrones en la gestión de proyectos: Al inicio de un proyecto, el consultor entra en la sala de reuniones, saca punta al lápiz y escucha lo que le gustaría al futuro usuario.

El pliego de condiciones -a menudo más grueso que la Biblia- se pone en práctica y, tras largos meses o incluso años de agonía, tiene lugar el lanzamiento de la producción.

Por desgracia, el mundo ya ha dado tres vueltas y ni siquiera el usuario empresarial de la reunión inicial es un clarividente. Sin embargo, así es como suelen configurarse los procesos gestionados por SAP, que es exactamente lo contrario de la agilidad.

Sin embargo, si transferimos los datos a un subsistema adecuado a través de una interfaz elegante, podemos garantizar técnica y organizativamente que los ciclos de iteración en los proyectos se reduzcan de meses a días y que la adaptabilidad se dispare. Eso es agilidad.

Por cierto, uno de los principales pioneros de esta forma de pensar es el Self Service BI, que no significa otra cosa que admitir oficialmente que, al crear una fuente de datos de análisis, aún no se sabe exactamente a qué preguntas se va a responder con el conjunto de datos.

Quien piense que los usuarios se sentarán delante de sus ordenadores con los ojos húmedos y las manos temblorosas de emoción se equivoca. De todas formas, los usuarios siempre lo han hecho así, con Excel.

Ya hemos aprendido los tres argumentos más importantes: rendimiento, combinación con datos no SAP y agilidad. Hay muchísimos más, pero en los últimos veinte años y a lo largo de casi 2.500 proyectos de interfaz, estos tres son la destilación de lo que mueve a los clientes actuales de SAP en este tema. Curiosamente, casi nada ha cambiado con el tiempo.

Tecnología para la transferencia de datos

Veamos primero los aspectos técnicos de la integración de datos, una subdisciplina típica de la inteligencia empresarial. Completamente independiente del fabricante, esta parte la realiza una capa que llamamos ETL (Extract, Transform, Load) o ELT (Extract, Load, Transform).

A menudo, los datos deben convertirse a un formato que permita su análisis, por ejemplo, mediante controles de calidad y coherencia. Dependiendo de si esta transformación se realiza durante el transporte o tras la llegada al sistema de destino, se denomina ETL o ELT.

En todo tipo de sistema de análisis o almacén de datos, este tipo de capa puede encontrarse de diversas formas.

ETL y SQL

Uno de los escenarios más comunes, por ejemplo, sería el almacenamiento de datos en un Microsoft SQL Server. De la parte ETL se encargaría SQL Server Integration Services (SSIS).

Una herramienta que se entrega junto con el servidor SQL. Los flujos de datos se modelan gráficamente y luego se automatizan. Funciona tan bien y de forma tan económica que incluso clientes sin conocimientos de Microsoft utilizan ocasionalmente SSIS para transportar datos a sistemas externos (por ejemplo, un almacén de datos Oracle).

Las transformaciones deseadas se realizan siempre durante el transporte. Además de otros proveedores de ETL como Alteryx, una alternativa sería dejar los datos originales de los sistemas ascendentes tal cual, almacenarlos primero y luego refinarlos en sentido descendente desde una capa de puesta en escena, es decir, ELT.

Este enfoque también funciona muy bien con todos los objetivos de datos comunes: SQL Server, Oracle, aplicaciones Hadoop, Amazon Redshift. La lista es interminable y depende de los gustos del cliente.

Una vez preparados los datos para el análisis, se abre un abanico prácticamente infinito de opciones de análisis. Desde el clásico Excel y Power BI hasta proveedores como Board o Tableau, todos los cuales establecen estándares en términos de experiencia de usuario.

Aunque en teoría SAP es sólo uno de los muchos proveedores de datos en un entorno de este tipo, la experiencia ha demostrado que ocupa una posición especial. Esto se debe principalmente a que la conexión de SAP es técnicamente más compleja que la de otros y puede convertirse rápidamente en un pozo de dinero si se utilizan las herramientas equivocadas.

Si consideramos SAP ERP como un proveedor de datos, una serie de objetos fuente son adecuados como punto de partida. En el caso más sencillo, las tablas. Si bien es cierto que el número de tablas SAP se sitúa en torno a las seis cifras en función de la versión y el módulo, la experiencia ha demostrado que las realmente relevantes son fáciles de encontrar y resultan un problema manejable en la práctica.

A muchos clientes también les gusta utilizar consultas. Aunque se trata de una tecnología impresionantemente antigua, los clientes de SAP con una larga trayectoria en particular pueden recurrir a los artefactos existentes sin tener que reinventar la rueda.

Si los volúmenes de datos aumentan, hay que tener en cuenta, por supuesto, la carga incremental. La opción más sencilla consiste en utilizar fuentes de datos OLTP clásicas del mismo modo que suministrarían datos a un BW.

Por cierto, SAP está renovando actualmente este tipo de transferencia de datos y sustituyéndolo por el más elegante y robusto ODP. Por lo tanto, no es previsible que este tipo de transferencia de datos sea víctima de una hoja de ruta de Hana en un futuro próximo.

SAP BW y el peaje denominado licencia hub

Un aspecto importante es el papel de SAP BW. La experiencia demuestra que dos tercios de los clientes acceden a los datos desde SAP ERP y un tercio desde BW. En el caso más sencillo, pueden utilizarse consultas BEx clásicas para acceder a los datos a través de BW.

Cuando los volúmenes de datos aumentan, las fuentes de datos de exportación pueden garantizar la transferencia incremental de datos desde el objeto BW correspondiente a un sistema posterior.

En este punto hay que mencionar un punto muy importante: Si los datos no se transportan directamente desde el ERP sino desde BW a un almacén de datos externo, dependiendo de las condiciones de la licencia y del contrato, habrá que pagar a Walldorf un peaje con el nombre de Licencia Open Hub.

Desde el punto de vista político, es obvio que con ello se pretende disuadir a los clientes de SAP de seguir este camino. En mi experiencia, sin embargo, esto tiende a tener el efecto contrario. Les anima financieramente a eliminar por completo el BW existente del flujo de datos.

Las razones para transportar primero los datos a través de un BW y luego a un DataMart son más bien tenues y a menudo tienen más que ver con la política y la historia que con una necesidad técnica.

Integración de procesos

La tecnología detrás de la integración de procesos es fundamentalmente diferente a la integración de datos de la sección anterior. Se trata fundamentalmente de devolver una única transacción, ya sea de SAP al exterior o del exterior a SAP.

Los sistemas de flujo de trabajo se utilizan a menudo en el lado externo. Puede tratarse de Nintex, K2 o Microsoft Flow, por ejemplo. En cada caso técnicamente incrustado en un SharePoint o sin.

Si no se trata de una aplicación de flujo de trabajo, a menudo encontramos aplicaciones de Office (muy probablemente Excel) en el lado no SAP hasta consumidores de máquinas como un sistema transportador u otras máquinas de producción, que también dependen de datos SAP.

En el caso de Excel, un caso de uso típico podría ser transferir datos de SAP a una hoja de Excel (por ejemplo, de la dirección del cliente al número de cliente) y/o importarlos desde allí (por ejemplo, actualizar las listas de materiales). Las aplicaciones son diversas y suelen suponer una gran ganancia de eficiencia para el usuario final.

No tienen que abandonar sus entornos familiares (Excel, SharePoint u otro software de terceros). En el pasado, SAP y Microsoft han hecho varios intentos con Duet para adoptar este enfoque.

Esto apenas se vio coronado por el éxito y, al final, las buenas ideas quedaron reducidas a polvo por una aplicación técnica errónea y demasiada política. Por parte de SAP, el punto de partida es prácticamente siempre un módulo de funciones. Puede tratarse de una BAPI estándar existente o de un módulo Z de desarrollo propio.

Otras tecnologías, como los registradores de transacciones o similares, han demostrado ser menos flexibles. También debe considerarse cuidadosamente el uso de una pasarela SAP. En última instancia, la pasarela SAP no es más que una capa adicional que traduce el módulo de funciones a OData.

Esto tiene dos serias desventajas: La capa adicional reduce el rendimiento y la capacidad de respuesta; además, sólo algunas transacciones de negocio pueden exprimirse en esta forma de pensar de OData orientada a tablas.

Los casos de uso en los que los datos son muy jerárquicos y no tienen forma de tabla (por ejemplo, una lista de piezas o datos maestros de materiales complejos) se vuelven muy rápidamente feos y confusos en Gateway, lo que no sólo limita la agilidad del proceso de desarrollo, sino que a menudo lo paraliza por completo.

La práctica ha demostrado que el acceso con el menor número de capas posible funciona mejor, es más fácil y rápido: acceder al módulo o al BA directamente desde el sistema externo a través de RFC.

Ya sea mediante unas pocas líneas de código que se programan internamente o mediante herramientas inteligentes que encapsulan la programación en un editor gráfico. Aunque esto suene un poco a mangas de camisa, en la práctica casi siempre ha demostrado ser superior a las pasarelas y las IP de este mundo.

Conclusión

Aquí nos hemos familiarizado con los aspectos más importantes de las interfaces SAP. En primer lugar, interviene la cuestión de si el cliente desea transportar datos masivos (integración de datos) o conectar procesos y transacciones dentro de SAP con el mundo exterior.

Las razones más importantes para ello son el buen rendimiento y el acercamiento de los datos SAP y no SAP. Otra razón es la necesidad de construir entornos de sistemas y flujos de información de tal forma que ya estén preparados para futuros cambios, es decir, que sean ágiles.

Desde un punto de vista técnico, muchos objetos de SAP pueden considerarse proveedores de datos: Tablas, consultas, fuentes OLTP, consultas BW, etc. A la hora de integrar transacciones, se recomienda al cliente existente que omita las capas intermedias en la medida de lo posible.

Aunque los que quieren vender las capas intermedias naturalmente ven las cosas de otra manera. Las ventajas se ven compensadas por un mejor rendimiento y agilidad. En conclusión, en general es aconsejable adoptar un enfoque más pragmático y ciclos cortos de retroalimentación e iteración.

Se acabó la época de los grandes proyectos faro que resuelven todos los problemas de integración. Al fin y al cabo, las cosas tienen que funcionar de forma estable en el mundo real y no sobre papel satinado.