Desfragmentación y atomización
La idea que subyace al deseo de SAP de utilizar únicamente la nube puede describirse como "codicia por el dinero". No hay nada que la nube pública pueda hacer mejor que otras arquitecturas de TI, excepto impulsar los márgenes por encima del 90 por ciento con un enorme efecto de escalado. Ahora bien, ganar dinero no tiene por qué ser una mala cualidad. Pero si la única vara de medir es el tamaño de la cuenta bancaria, entonces la idea ERP de R/3 se pervierte en el 50 aniversario de SAP.
Para los clientes de SAP que ya tienen éxito, R/3 y ECC 6.0 son la base y las modificaciones de Abap el estilo libre. Dado que los sistemas ERP clásicos de SAP pueden desfragmentarse y atomizarse con una arquitectura cliente/servidor, ganan en individualidad, innovación, agilidad y resistencia.
El debate actual no es sobre on-prem o nube, sino sobre individualización frente a estándar. ¿Quién es el proveedor de nube con más éxito? AWS. Los talentosos informáticos de AWS no son muy diferentes de sus colegas de IBM, Microsoft, Alibaba, Google o SAP. El secreto es más bien un efecto de escalado único, basado en estándares fundidos en silicio.
El siguiente comentario puede encontrarse en el sitio web del redactor jefe Färbinger: "La USP de SAP es el sistema ERP totalmente integrado. En principio, a los clientes no les importa si esto se utiliza en la nube pública o privada o en on-prem, siempre que puedan conservar su individualidad. Si SAP quiere mantener esta USP, debe hacer que sus productos relacionados con ERP sean técnica, funcional, integral e internacionalmente utilizables y también ofrecer variantes sectoriales cuando sea necesario."
Muchos miembros de la comunidad SAP comparten la siguiente opinión: SAP no obtendrá una USP ni en el sector de las bases de datos ni en el de la explotación de aplicaciones en la nube; incluso su experiencia en consultoría es intercambiable. SAP es el líder del mercado mundial de sistemas ERP integrados, ricos en funciones y aplicables internacionalmente. Las posibilidades de ampliación y modernización son infinitas: en esto debería centrarse SAP. También lo es el valor añadido que aportan la desfragmentación y la atomización.
En un mundo en el que muchas cosas se están volviendo más estrictas, estandarizadas y conformes, el cliente SAP existente puede labrarse una ventaja competitiva con individualidad e innovación. Sin embargo, los esfuerzos de SAP van en la dirección contraria: con una nube pública y normas estrictas sobre la Plataforma Tecnológica Empresarial, el grupo ERP intenta aumentar aún más su margen bruto.
Los conceptos no-code/low-code son sólo la hoja de parra delante de una arquitectura ERP uniforme. Algo parecido a lo que ocurre con Hana, que solo aparentemente se supone que proporciona más velocidad, pero que en última instancia significa el dominio exclusivo del mercado de bases de datos en la comunidad SAP. AnyDB ahora también está disponible con complementos de computación en memoria, por lo que el rendimiento ya no es un punto de venta único para Hana.
Detrás de todas estas preguntas y críticas se esconde la preocupación por SAP: ¿seguiremos teniendo un ERP alemán líder del mercado mundial dentro de diez años? se preguntan muchos de mis hermanos y hermanas habituales. Cuanto más homogénea y conformista sea la oferta de SAP y más baje el precio de las acciones en los próximos años, más fácil y probable será una adquisición hostil. Un SAP estandarizado con el 90 por ciento de sus clientes actuales en la nube pública y un precio de la acción muy por debajo de los 100 euros es un billete de comida para los hiperescaladores de este mundo.
Sólo una comunidad SAP heterogénea, individual, atomizada y desfragmentada puede saciar el apetito de un hiperescalador hambriento. Lo que se necesita es un espacio de nombres Z 4.0 que funcione on-prem y en la nube híbrida, que permita todo tipo de programación, desde Abap hasta no-code/low-code, que permita una desfragmentación y atomización del ERP que mejore el valor. El éxito de ECC 6.0 radica en la individualización y los cientos de grupos de trabajo DSAG, un concepto CCC de éxito y un panorama de socios SAP muy animado. Cualquier intento, como el de Rise with SAP, de conformar a la comunidad SAP es contraproducente.
1 comentario
Werner Dähn
Ich bin nicht glücklich damit, axiomatisch Public Cloud mit hoher Marge gleichzusetzen, denn es gibt dafür eine wichtige Randbedingung: Die Kosten jedes zusätzlichen Kunden muss Null sein.
Ist das gegeben?
Wenn das e-3 Magazin einen zusätzlichen Leser gewinnt, werden die zusätzlichen Abfragen problemlos über die bestehenden Hardware und Betrieb abgehandelt. Es müsste sich schon die Anzahl der Leser verhundertfachen, um einen kleinen Betrag in einen stärkeren Server zu rechtfertigen.
Wenn SAP einen weiteren S/4Hana Kunden gewinnt, läuft der auf den bestehenden Servern einfach mit? Benötigt er keinerlei Betreuung? Der erzeugt ganz sicher zusätzliche Kosten, zu einem recht großen Anteil sogar. Erschwerend kommt hinzu, eine Public Cloud Software hat eine signifikant höhere Komplexität und damit Kosten. Weiters sind die Kunden nicht bereit das n-fache zu vorher zu bezahlen, nur um den Betrieb der Software abzugeben.
Reduziert auf diesem Aspekt hat SAP also keine Public Cloud, sondern ein Outsourcing Angebot.
Ich bezweifle also, dass SAP bei einer Verdopplung des Cloud Umsatzes eine deutliche Verbesserung der Marge sehen würde.
OnPrem ist da lustigerweise besser! Da wurde Software erstellt, pro Jahr 20% des Listenpreis als Maintenance Kosten einkassiert und die Betriebskosten wurden vom Kunden in Form von Hardware und Personal getragen. Verdoppelt sich in diesem Modell die Kundenanzahl, verdoppelt sich der Umsatz, die Kosten bleiben gleich, die Marge nähert sich den 100%.
Was passiert also mit der Marge wenn man das onPrem Geschäft aufgibt und alle in Richtung SAP Cloud zieht?