L’auteur : Thierry Julien, PDG du groupe TJC
Au fil du temps, Les systèmes ERP et informatiques sont de plus en plus volumineux. Plus les données générées sont nombreuses, plus le système a besoin de mémoire. Cet article de blog explique pourquoi les coûts de mémoire n’augmentent pas de façon linéaire et illustre la croissance de la mémoire d’une base de données SAP à l’aide d’un exemple mathématique.
Les chiffres en contexte
Pour commencer, partageons quelques valeurs historiques dont les professionnels chevronnés de l’informatique se souviennent peut-être.
- À l’époque de R/2, sur l’ordinateur central, avant la méthode d’accès au stockage virtuel (VSAM), la limite matérielle de la base de données était de 2 Go. Oui, 2 Go, pas 2 To, et de grandes entreprises utilisaient des systèmes SAP…
- À l’époque, une mémoire de disque de 20 Go nécessitait un volume de 35 pieds cubes (1 mètre cube). Et elle coûtait cher, environ 200 000 dollars pour 20 Go en 1990.
- Avec le système R/3, il y a 20 ans, faire fonctionner un système de 500 Go relevait de l’exploit, même pour les constructeurs automobiles.
- Il y a 15 ans, il était normal d’exploiter un système SAP d’une capacité d’un To, mais cela atteignait les limites de la base de données si vous utilisiez la base de données Microsoft SQL.
- Aujourd’hui, faire fonctionner un système de 2 To n’est plus considéré comme un exploit, et de nombreuses entreprises font fonctionner des systèmes SAP sur une base de données HANA de 10 To (même avec une base de données compressée, basée sur des colonnes)
Ensuite, les raisons professionnelles de l’augmentation des données
Dans les années 1960, c’est la production qui était au centre des préoccupations, et non la vente. Les fabricants produisaient, chargeaient les camions et les confiaient aux revendeurs. Le nombre de camions était considéré comme l’unité de mesure. Aujourd’hui, une entreprise de vente au détail suit chaque produit individuellement. Cela représente un volume de données beaucoup plus important pour le même produit vendu. Et nous pouvons nous attendre à toute une série de changements à venir :
- Certaines entreprises souhaitent retracer chaque produit vendu jusqu’au client qui l’a acheté : qui a acheté la glace, quand, à quel prix, etc. Unilever en a fait la démonstration avec SAP CDP (Customer Data Platform) : https://www.youtube.com/watch?v=RzzENGY4TZg
- De même, certaines personnes retracent l’heure et le lieu exacts où chaque pilule ou médicament a été pris, les smartphones ou les montres Apple sont liés à une personne, et le patient identifie son smartphone ou sa montre Apple.
- De même, les fabricants de tabac tracent les emballages de cigarettes afin que les gouvernements puissent suivre le trafic illégal de cigarettes.
Comme vous pouvez le constater, du suivi des camions au suivi individuel, du suivi des produits au suivi de la consommation, tout se résume à une augmentation significative du volume de données dans les systèmes ERP.
Pourquoi la croissance plate est encore sous-estimée
Imaginons un instant que la croissance de la base de données soit stable – supposons qu’elle soit de 1 To par an. Imaginons qu’une partie du paiement soit effectuée annuellement en fonction du volume – c’est le cas pour la base de données SAP HANA et le dimensionnement de S/4HANA.
- Au cours de la première année, vous atteindrez 1 TB
- Au cours de la deuxième année, vous atteindrez 2 To, soit un total de 3 To sur deux ans.
- La troisième année, vous atteindrez 3 To, soit un total de 6 To sur 3 ans.
*Voir l’annexe pour les calculs complets
La formule est donc la suivante : au cours de l’année n, vous atteignez n To, ce qui donne un total de n(n+1)/2 To sur n années.
Si nous partons du principe que la plupart des systèmes ERP ont une durée de vie d’environ 15 ans, vous atteindrez 15 To au cours de la 15e année, ce qui représente un total de 120 To sur 15 ans.
Cela signifie qu’en moyenne, sur une période de 15 ans, vous aurez besoin d’une moyenne annuelle de 120/18 = 8 To.
Ainsi, avec une croissance plate (0% d’augmentation de la croissance), vous paierez 8 fois la croissance annuelle. Avec un prix typique de 150k$ par an et par TB, cela représente 1,2 million par an. C’est probablement plus que ce à quoi vous vous attendiez, n’est-ce pas ?
Si tout va bien, l’archivage SAP avec les logiciels et les conseils de TJC Group vous offrira une excellente opportunité de retour sur investissement. Assurez une réduction continue du volume et de l’utilisation de la mémoire grâce à l’archivage automatisé des données SAP. Vous pouvez en savoir plus sur cet article de blog : 6 raisons d’adopter l’archivage régulier des données dans les systèmes SAP
Annexe
Pour ceux qui aiment les mathématiques… Prouvons l’argument ci-dessus :
Avec la méthode du parage. Considérez la somme :
S=1+2+3+…+n
Nous pouvons également écrire la somme dans l’ordre inverse :
S=n+(n-1)+(n-2)+…+1
Maintenant, additionnez ces deux équations, terme par terme, en remarquant que la somme de chacune des n paires est égale à n+1 :
2S=(n+1)+(n+1)+(n+1)+…+(n+1)
Donc
2S=n(n+1)
Et nous atteignons notre point que
S=n(n+1)/2
Vous pouvez trouver une autre méthode pour obtenir le même résultat. Par exemple, la preuve par induction mathématique, étape par étape. Amusez-vous bien !
