Réduction de moitié des frais de soins


Après avoir donné ce texte à lire à ma femme, je dois maintenant réécrire l'introduction et la faire précéder d'un avertissement.
"Tu te brûles encore les doigts avec ces déclarations".
elle m'a reproché mon style d'écriture.
"Que ton ami Färbinger prenne la tête de tout ça sous le couvert du journalisme".
J'essaie de répondre calmement que le rédacteur en chef de E-3 est déjà suffisamment stressé par ses propres "fausses informations". Et que nous voulons penser et écrire de manière critique et constructive dans l'esprit de la communauté SAP. C'est parti !
Les rumeurs ont circulé de temps à autre, mais voilà que lors de notre première Stammtisch SAP de la nouvelle année, nous avons eu un invité qui nous a parlé de première main d'une réduction miraculeuse des frais de soins annuels :
En tant que prestataire de services d'un partenaire SAP, il travaille pendant neuf mois chez Bombardier dans le domaine de la personnalisation de SolMan et c'est pourquoi il a rejoint l'équipe pour évaluer un concept de maintenance alternatif.
Rimini Street avait fait une offre très alléchante à Bombardier. Au lieu de verser 14 millions de frais de maintenance par an à SAP, Rimini Street pourrait apporter la même chose et plus pour 7,5 millions.
L'affaire s'est terminée comme de nombreux cas similaires auparavant, SAP a réduit massivement les coûts de ses propres frais de soins. Notre table des habitués en a pris note avec satisfaction. Nous connaissons des cas similaires lors du rachat de licences SAP.
Dans ce cas, le revendeur de logiciels d'occasion Axel Susen est toujours d'une grande aide : il présente à chaque fois une contre-offre avec des licences déclassées, à laquelle SAP répond par une réduction de prix d'un pourcentage à deux chiffres. La vieille astuce d'Axel Susen fonctionne donc aussi parfaitement pour les frais de maintenance.
Pourquoi ?
SAP tente de changer un paradigme ERP vieux de quarante ans : A partir de 2025, l'empire SAP ne devrait plus compter que S/4, Hana et Fiori.
Tous les clients existants ne sont pas prêts à assumer ces processus radicaux et disruptifs. La plupart d'entre eux ne connaissent même pas les avantages organisationnels et commerciaux de S/4 et Hana.
Pour tous les utilisateurs de Business Suite 7 sur l'une des bases de données de Microsoft, IBM et Oracle, Rimini Street apparaît désormais comme le dernier recours. Cette tierce maintenance est non seulement moins chère, mais aussi plus complète et plus durable.
En fin de compte, c'est ainsi que l'on peut encore réussir en tant que CIO en 2030 avec S/7 et Oracle - et investir le budget économisé dans la transformation numérique !
Naturellement, SAP combat ce modèle à tous les niveaux, notamment avec la nouvelle version de SolMan - mais c'est une autre histoire. Une autre anecdote intéressante a été racontée ce soir-là à la table des habitués. De plus en plus souvent, les clients existants retirent leurs systèmes non-HR/FI de la maintenance, ce qui résout presque d'office la pénible discussion sur l'utilisation indirecte.
Mais ceux qui ne passent pas à Rimini Street ou qui n'arrêtent pas la maintenance devront probablement planifier le changement de version jusqu'en 2025. Ceux qui lisent régulièrement cette chronique savent probablement que je suis responsable d'un système SAP "plus grand" et, bien sûr, nous sommes déjà intensément engagés dans la planification du projet S/4.
Tout ce que je peux dire à l'heure actuelle : L'échéance de 2025 sera difficile à tenir ! Il y a trop de systèmes SAP dans le monde, trop d'add-ons, de tests, de formations, etc. à planifier et à exécuter.
Ce qui est vrai pour nous l'est aussi pour tout autre client existant. Même les utilisateurs beaucoup plus petits auront des difficultés à mettre à disposition les ressources nécessaires. Il n'y a qu'un nombre limité de partenaires SAP, de conseillers et de programmeurs indépendants qui peuvent apporter leur aide et leurs conseils lors d'un changement de version.
Ce n'est pas une mauvaise nouvelle, mais l'expérience du passé. Walldorf a également dû réviser à plusieurs reprises les calendriers pour le passage de R/2 à R/3 et de R/3 à ECC 6.00. 2025 ne tiendra pas !
De plus, Hana a été tricoté à la va-vite et S/4 n'est pas encore adapté aux masses. La plupart des exemples présentés lors de la keynote par Bernd Leukert, directeur technique de SAP, portent sur de très faibles volumes de données, de sorte que Hana n'est de toute façon pas à la hauteur.
Mais d'un point de vue organisationnel, ces exemples sont également des solutions de niche très intéressantes ou, comme le montre le scénario Boardroom, ne sont adéquates que pour une poignée de conseils d'administration. Jusqu'à présent, S/4 n'a pas encore fait la preuve de son aptitude à être utilisé en masse.
Et Hana présente encore de nombreuses maladies de jeunesse et anomalies - c'est pourquoi SAP insiste sur le strict respect de l'utilisation exclusive de matériel serveur certifié, car il n'y a guère d'installation de S/4 et Hana sans une aide massive de la part du support SAP.
Les choses vont s'améliorer, mais cela prend du temps. Même R/3 n'est pas devenu stable, robuste et mature du jour au lendemain. La communauté n'a été vraiment heureuse qu'avec la version 4.6c et la version R/3 Entreprise (4.7) créée par l'ancien chef de DSAG, Alfons Wahlers.




