pmc America, socio de SAP, camino del steampunk y BTP: el viaje es la recompensa

Con el Presidente y Director General de pmc America Heiko Edelmann llevó al redactor jefe de E3 Peter Färbinger la siguiente entrevista. pmc ofrece soluciones de software integrales que apoyan los principios lean y permiten a las empresas mejorar inmediatamente sus procesos de negocio y obtener ventajas competitivas. pmc maximiza el éxito empresarial mediante una combinación de consultores especializados, metodologías, herramientas SW y una cartera completa de soluciones de software empresarial para las industrias de automoción y fabricación.

Estas ofertas abarcan todas las fases del ciclo de vida de una solución de software, desde la planificación hasta la creación, la personalización y la explotación. Está demostrado que las soluciones y servicios de pmc mejoran la eficacia, rentabilidad y adaptabilidad de las empresas.

Peter M. Färbinger: Señor Edelmann, ¿qué lenguajes y herramientas informáticas ha utilizado en el pasado para llevar a cabo las adaptaciones, ampliaciones y modificaciones necesarias para los clientes de SAP existentes?

Heiko Edelmann, Presidente y Director General de pmc: Hola Sr. Färbinger, gracias de antemano por la oportunidad de compartir nuestros muchos años de experiencia en implementación y desarrollo de SAP en la industria del automóvil con nuestros colegas y sus lectores a través de la revista E3. Dado que nuestro principal objetivo es la industria global de suministro de automoción, hemos desarrollado muchos complementos de alto rendimiento en las áreas de procesos de clientes, lógica de procesos EDI para procesos de clientes, automatización de escaneado por radiofrecuencia, etiquetado y eficacia y optimización para el usuario final, por lo que sólo un puñado de herramientas entran en cuestión. La premisa es siempre la misma: los complementos que se ejecutan directamente en SAP se desarrollan con herramientas estándar de SAP para ofrecer el mejor rendimiento posible y una actualización y mejora sin riesgos, ya que no requieren modificaciones. Por ello, nos hemos especializado en las siguientes herramientas con el fin de implementar la mejor solución posible para los clientes de ECC, on-prem, nube privada y pública: Abap, Abap RAP, es decir, RESTful Application Programming, UI5, es decir, Fiori, PDF e ITS mobile. Estas herramientas pueden cubrir fácilmente el 90% de las necesidades.

FärbingerEsto también dio lugar a muchas modificaciones de Abap en el espacio de nombres Z. Se perderá esta propiedad intelectual durante una conversión a S/4?

Noble: En general, observamos un número relativamente elevado de desarrollos entre nuestros clientes actuales de ERP/ECC que no deberían convertirse. En realidad, muchos de estos desarrollos ya no están actualizados, ya que los procesos empresariales internos han evolucionado o el software SAP ofrece ahora muchas más funcionalidades. Por lo tanto, es extremadamente importante diferenciar qué desarrollos siguen representando realmente propiedad intelectual o son ya código heredado que ya no se desea tener.

Färbinger¿Y qué hay de la verdadera propiedad intelectual?

Noble: Respecto a la pérdida de IP durante una migración: Hay que distinguir entre la nube privada y la nube pública. Cuando se migra de SAP ERP/ECC a la nube privada, en realidad no se pierde ninguna IP: la herramienta de migración de SAP es realmente fantástica y basta con hacer unos pocos cambios en el código para que vuelva a funcionar perfectamente en la nube privada.

Färbinger¿Y en la nube pública?

Noble: La situación es algo distinta con la nube pública, ya que la plataforma de desarrollo subyacente, CAP o RAP, está estructurada de forma bastante diferente. Yo describiría esta migración más bien como una evolución. Estamos tomando todos los conceptos de nuestras soluciones de software y aplicando el modelo de desarrollo Abap RAP, Abap RESTful Application Programming - esto significa que podemos copiar partes del código uno a uno, pero sigue siendo un nuevo desarrollo. Como llevamos más de un año desarrollando en la nube pública, esto se ha convertido en algo natural para nosotros, aunque hay que admitir que fue un gran cambio de paradigma para nosotros. Pero el beneficio final es un futuro sistema ERP que está casi libre de código personalizado y todavía ofrece funciones adicionales - lo que fue muy doloroso para nosotros al principio, pero crea un beneficio a largo plazo para nuestros clientes.

Färbinger¿Cómo llevará a cabo, como socio de SAP, las futuras modificaciones en un sistema S/4? ¿Con qué lenguajes y herramientas?

Noble: Seguiremos fieles a nuestro ADN y utilizaremos principalmente Abap y el nuevo lenguaje Abap, como el mencionado Abap RAP. Es posible reciclar a nuestros actuales ingenieros de software de Abap a Abap RAP, aunque no es lo más fácil. Las nuevas contrataciones tienen principalmente una formación en desarrollo web, lo que facilita la comprensión y aplicación del concepto Abap RAP.

FärbingerEntonces, ¿operan en dos vías?

Noble: Sí, S/4 Hana on-prem y nube privada con Abap y BTP, es decir, Abap clásico, Abap RAP y UI 5; S/4 Hana nube pública con Abap RAP en la nube pública, es decir, Embedded Steampunk y en BTP, Business Technology Platform, con Steampunk. Tenemos un enfoque pragmático para la nube pública: BTP y Steampunk son nuestra plataforma de referencia, para funcionalidades de alto rendimiento tomamos la ruta de Steampunk embebido.

Färbinger¿Cuáles son los retos y tiene que diferenciar entre on-prem y cloud en su trabajo?

Noble: Realmente son dos mundos diferentes, aunque el ERP subyacente tenga funciones y front-ends similares. Dado que en pmc America perseguimos un modelo denominado híbrido -es decir, esperamos que nuestros futuros clientes acaben utilizando un ERP on-prem y otro en la nube pública-, las soluciones de software deben diseñarse de tal manera que puedan funcionar tanto en un modelo híbrido como en una nube pública pura. Ninguno de nuestros clientes aceptará que le ofrezcamos dos soluciones EDI diferentes por el mero hecho de tener un ERP híbrido. Esto significa que reflexionamos mucho y celebramos sesiones de pizarra con ingenieros de software y consultores antes de desarrollar una sola línea de código, lo que confiere al tema del pensamiento de diseño un peso y una importancia completamente diferentes.

FärbingerPregunta: ¿En qué sectores opera y cuáles son las solicitudes de modificación típicas de los clientes de SAP?

Noble: Nuestros clientes proceden principalmente de la industria mundial de suministros de automoción, con especial atención a Norteamérica y Europa. La satisfacción del cliente desempeña un papel extremadamente importante para la industria proveedora. Por eso, la mayoría de las solicitudes de modificación se producen en el ámbito de la cadena de suministro del cliente. ¿Qué queremos decir con esto? Muchos clientes han mejorado sus procesos con la ayuda de las TI para alcanzar cada vez más el objetivo final del "tamaño de lote 1". Para nuestros clientes, esto significa que, aunque los requisitos de los clientes OEM se siguen transmitiendo vía EDI, los procesos subyacentes y los datos maestros se están volviendo tan complejos que existe una necesidad considerable de soluciones de software.

Färbinger¿Dónde se aplican estos retos?

Noble: A continuación, esto se extiende con relativa rapidez a la producción -desde la planificación hasta la ejecución- y a las funciones de escaneado y etiquetado por radiofrecuencia necesarias para ello. Esto puede adquirir tales proporciones que haya diferentes procesos de destinatario de mercancías a destinatario de mercancías. Cada optimización en un cliente OEM da lugar a una necesidad inmediata de desarrollo en los proveedores subyacentes; lo vemos hasta el extremo con los OEM japoneses Honda y Toyota.

Färbinger: ¿Hasta qué punto la especificación SAP de un núcleo limpio es un reto o también una ayuda?

Noble: El Clean Core es sin duda un reto técnico y, al mismo tiempo, una necesidad del cliente si no se quiere abordar un proyecto ERP masivo cada diez o quince años. El reto técnico consiste más o menos en que ya no se puede programar sin más. Comienza con el hecho de que el consultor SAP debe tener un cierto nivel de experiencia para entender los requisitos con precisión y proporcionar al equipo de desarrollo especificaciones precisas. El equipo de desarrollo tiene que descomponer estas especificaciones en pequeños bloques de construcción para que encajen en el nuevo RAP de Abap, es decir, steampunk.

Färbinger¿Un cambio de paradigma?

Noble: Los viejos tiempos de especificaciones imprecisas y de programar al azar con un equipo de desarrolladores a medio formar que sólo "sabe programar" son cosa del pasado. Es necesaria una nueva forma de pensar: la consultoría debe entender el desarrollo y viceversa, es decir, el conjunto de competencias de ambas partes debe cambiar. A esto lo llamamos "consultoría de procesos de negocio": los procesos deben entenderse y replantearse para que tengan sentido para el usuario final y puedan aplicarse en consecuencia.

Färbinger¿Cómo se organiza el acceso a los datos de Hana? ¿Utiliza API, comandos SQL o extensiones del lenguaje SQL de Hana y llamadas a funciones?

Noble: Los datos son la esencia de todo sistema ERP: sin datos, no hay procesos. Por supuesto, este es un tema delicado en un entorno de nube pública, ya que los datos se asocian inmediatamente con la seguridad. Así que es lógico que, por el momento, no sea tan fácil acceder a los datos maestros y de las transacciones. Actualmente utilizamos API liberadas o nuestras propias API para acceder a estos datos para nuestras soluciones de software en la BTP. El número de vistas de CDS liberadas también crece constantemente, lo que nos ofrece otra forma de acceder a los datos pertinentes.

Färbinger¿Existen alternativas?

Noble: Sí, como esto dista mucho de ser suficiente, hemos creado "objetos empresariales personalizados" -es decir, nuestras propias tablas de clientes- como solución alternativa, que contienen datos maestros especiales que se encuentran en tablas que aún no se han liberado. Aunque actualmente esto supone un doble mantenimiento de los datos maestros, si se programan correctamente, pueden modificarse con relativa facilidad más adelante, cuando se liberen las tablas. Yo lo veo como una evolución natural y lo comparo con la situación en R/3 y ERP/ECC, cuando se añadieron muchas tablas y funciones y hubo que cambiar los programas de los clientes en consecuencia. Vuelve al tema anterior de que ya no se puede programar a ciegas.

Färbinger¿Cómo clasificaría subjetivamente la función de SAP Business Technology Platform? ¿Una herramienta para el éxito de S/4 o una estrategia de SAP a largo plazo?

Noble: Tengo una opinión clara al respecto. Sin duda, una estrategia SAP a largo plazo. Sin una herramienta como BTP, el objetivo de Clean Core sería sencillamente inalcanzable. El propio SAP utiliza BTP para soluciones específicas, como los procedimientos de notas de crédito o la gestión de envases. Creo que lo especial de BTP es su integración relativamente sencilla con nubes públicas y privadas. Además, BTP ya no se presenta como un "gato de todos los oficios". Hubo un tiempo en que parecía -al menos a mí- que BTP quería competir con las funciones de Microsoft Azure. Ya no parece ser el caso; utilizamos Azure Logic apps junto con BTP y Public Cloud. El entorno Abap RAP hace el resto para garantizar que BTP proporcione a sus clientes una herramienta de desarrollo muy sólida y fácil de integrar.

Färbinger¿Puede el Abap incrustado - Steampunk - en el BTP tener un éxito similar al Abap bajo R/3 y ECC?

Noble: Llevamos once meses desarrollando con Steampunk y Embedded Steampunk. Como es mi naturaleza, era un poco crítico en cuanto a si todo funcionaría sin problemas. Definitivamente tuvimos nuestras dificultades iniciales - pero como dije antes, estaban más o menos en el lado de la consultoría, presentando los requisitos en pasos de desarrollo claros. Los equipos de desarrollo tuvieron "dificultades" con Abap RAP al principio, ya que es un lenguaje muy restrictivo. Sin embargo, cuanto más convertíamos nuestra cartera de software existente, más fácil resultaba; ahora, tras casi un año de desarrollo, tengo que decir que nuestros equipos se han acostumbrado y, de hecho, ya no hay sorpresas ni se plantean preguntas: ¿Por qué no podemos hacer eso aquí, podemos hacerlo en S/4? Fue sin duda una curva de aprendizaje muy empinada, pero una vez que estás ahí, es "desarrollo como antes".

Färbinger¿Será un éxito similar al de R/3 Abap y ERP/ECC, sinceramente?

Noble: Eso depende al 100% de los socios de SAP, ¡de si están dispuestos a dar el paso que hemos dado nosotros! Empieza con un replanteamiento en el lado de la consultoría; si eso ocurre, mi opinión es: sí, será un éxito similar.

Färbinger¿Puede estimar si BTP será un hogar para las modificaciones de S/4 o la plataforma para un ERP componible, es decir, un sucesor de S/4?

Noble: Es difícil hacer una estimación, pero la bola de cristal de mi oficina dice que no. El tema de los "procesos empresariales ERP holísticos, integrados y automatizados" es sencillamente demasiado complicado para reproducirlo sin más en BTP. Veo BTP como el hogar de la propiedad intelectual personalizada. Los clientes que introducen ERP porque quieren generar valor añadido y diferenciarse de sus competidores pueden construir su IP, su "salsa secreta" como tan bellamente se llama en americano, en BTP, lejos de los ojos de sus competidores, y ampliarla en cualquier momento.

Gracias por la entrevista.

Si desea leer la entrevista en formato pdf, puede descargarla en el siguiente enlace:

PDF (en inglés)