10 años de S/4: coche de carreras con el freno de mano API echado


Hemos trabajado estrechamente con nuestros clientes, que están evolucionando en la economía digital, para averiguar dónde los procesos digitalizados pueden aportar el mayor valor añadido", declaró entonces Bernd Leukert, miembro de la Junta Directiva de SAP. Su nombre está más estrechamente asociado a la transición estratégica y tecnológica de SAP Business Suite a S/4 -incluyendo el enfoque en la nube, la tecnología in-memory (Hana) y la experiencia de usuario Fiori- que casi ningún otro. Y continúa: "El resultado es un núcleo completamente rediseñado: SAP S/4 Hana es el primer núcleo digital de la industria para el negocio digital. Con esta solución, las empresas pueden obtener un valor añadido sin precedentes, por ejemplo, a través de casos de uso innovadores en áreas clave como las finanzas y la logística. Se benefician de modelos de datos simplificados y de una experiencia de usuario con capacidad de respuesta."
S/4 obliga a reorganizarse
Mucho ha llovido desde entonces. De hecho, la plataforma ha obligado a los clientes de SAP a replantearse sus procesos. Ha reavivado los debates sobre modelos de datos, automatización y arquitectura empresarial. Y ha desempeñado un papel importante a la hora de garantizar que el departamento de TI ya no actúe como un mero proveedor de servicios, sino como un socio estratégico de la empresa. S/4 Hana también tiene un impacto cultural: la plataforma sienta al negocio y a TI a la misma mesa, o al menos más cerca. Esto está ampliamente reconocido en la comunidad.
Pero, a pesar de todo el reconocimiento, hay un tema que sigue causando ceños fruncidos, quizá incluso dolor de estómago: la todavía limitada disponibilidad de interfaces abiertas y coherentes (API). En un momento en el que la innovación se crea a través de la integración, esto es precisamente lo que actúa como freno. Se podría decir: S/4 Hana podría conducir como un coche de carreras de gran potencia, pero está frenado en las dos primeras marchas. La potencia está ahí, pero no puede desarrollarse libremente. No se trata de una nimiedad. Los modelos de negocio modernos se basan en la modularidad. Sí, SAP suele ser la columna vertebral, pero a su alrededor suelen funcionar docenas de herramientas, plataformas y servicios especializados. La integración de estas soluciones determina la agilidad, la velocidad y la fuerza innovadora.
Las API inexistentes o poco claras no sólo provocan retrasos en los proyectos, sino que restringen la libertad tecnológica de diseño. Y esto es precisamente lo que muchas empresas consideran cada vez más una desventaja competitiva. Esto tiene poco que ver con la promesa de Leukert de "modelos de datos simplificados y una experiencia de usuario receptiva". La pregunta obvia es: ¿por qué una gran empresa con más de 100.000 empleados no controla mejor este problema? Hay muchas razones.
En primer lugar: cuestiones de legado. El mundo SAP ha crecido históricamente, a lo largo de décadas. No todo puede transferirse sin problemas a un paradigma de API moderno sin arriesgarse a conflictos técnicos. En segundo lugar, las prioridades. Durante mucho tiempo, la atención se centró en la migración, la estabilidad y la seguridad de las licencias, y menos en la apertura radical. En tercer lugar: la lógica de la protección. Las API abiertas pueden poner en peligro los modelos de negocio existentes. Quien lo ofrece todo se hace vulnerable. Y en cuarto lugar: la inercia estructural. Los comentarios de la comunidad suelen incorporarse al desarrollo del producto con retraso o de forma selectiva, a pesar de las intensas redes de socios.
Los cimientos están puestos
Diez años después del lanzamiento de S/4, una cosa está clara:
Los cimientos están puestos. Ahora es importante abrir más la arquitectura. Si queremos que SAP esté preparada para el futuro, tenemos que ver las API como una infraestructura estratégica, no como un estilo técnico libre. Sería una pena que el coche de carreras se quedara permanentemente en segunda.
Continúe con la entrada del socio:
