RÉDUCTION DES COÛTS DES PIÈCES JOINTES DE STOCKAGE LORS DE LA MIGRATION VERS S/4 HANA
Dans ce blog, nous verrons comment la gestion des données est affectée par le choix de la base de données et en particulier quelles en sont les conséquences pour les pièces jointes dans SAP. L'un des problèmes qui reste souvent sous-exposé est la manière dont les pièces jointes et les documents générés sont stockés dans SAP. Il n'est pas rare que le stockage des pièces jointes occupe une partie importante de la base de données. Lisez également nos guides pour votre Migration des données SAP et pour Migration vers SAP Hana.
Pour une compréhension générale, découvrez ce que gestion de contenu d'entreprise se trouve et plus particulièrement dans Environnement SAP.
De nombreux utilisateurs de SAP associent des fichiers PC locaux à des documents SAP. Grâce au bouton « Services d'objets génériques », disponible dans presque toutes les transactions SAP standard, par exemple, les fichiers PDF, Word ou Excel peuvent être rendus accessibles via le document SAP sous-jacent. Dans la pratique, par exemple, les fichiers de devis sont liés à des bons de commande ou les commandes d'achat entrantes sont liées à des commandes client. En outre, de nombreux documents, notamment des documents PDF, sont générés par SAP. Pensez par exemple aux bons de commande sortants. Tous ces documents se retrouvent dans la base de données SAP.
Dans ce blog, nous voulons préciser que le stockage de ces pièces jointes est plus efficace et beaucoup moins coûteux en déplaçant le stockage de la base de données vers un référentiel de contenu externe. En particulier, lorsqu'une base de données HANA est introduite dans le paysage SAP, il s'agit davantage d'une exigence d'un point de vue architectural que d'une option. Nous aborderons également brièvement comment ce passage d'une base de données à un référentiel de contenu externe.
Des recherches menées auprès de certains de nos clients montrent que, dans certains cas, le tableau dans lequel les pièces jointes et les documents générés sont stockés (tableau SOFFCONT1) peut occuper à 35 % de la base de données totale. Si l'on considère le coût du stockage dans un environnement SAP HANA, la réduction de la base de données peut permettre de réaliser des économies importantes. Mais lorsque des bases de données traditionnelles sont utilisées, les avantages peuvent également être importants. Pensez aux procédures de sauvegarde ou aux copies du système.
En raison des développements continus que le secteur des TIC a connus au cours des dernières décennies, non seulement les possibilités en termes d'applications informatiques ont augmenté de façon exponentielle, mais également les possibilités de stockage des données. De ce fait, les entreprises ont désormais accès à de grandes quantités de données et ont de plus en plus de possibilités d'analyser et de traiter ces données. Un terme fréquemment utilisé est « Les données sont la nouvelle monnaie » . Ces données sont précieuses et semblent être une fatalité pour tout le monde. Afin d'optimiser et d'accélérer les processus métier, il est de plus en plus nécessaire de disposer des données elles-mêmes, mais également d'y accéder rapidement et de les traiter. L'analyse des données en temps réel figure parmi les priorités de la plupart des responsables, mais elle est souvent entravée par le matériel et les logiciels actuels des entreprises.
Les bases de données dites traditionnelles constituent le facteur limitant le traitement rapide et en temps réel des données. Une base de données traditionnelle ne peut gérer qu'un seul processus de travail à la fois pour une application spécifique. Pour chaque application développée, les données de la base de données sont configurées et optimisées pour cette application. Pour ce faire, les données sont continuellement déplacées et dupliquées pour répondre aux besoins spécifiques de chaque application.
Plus les applications sont utilisées au sein d'une entreprise, plus il devient difficile de donner à chaque application un accès rapide aux données de la base de données. Une solution traditionnelle pour cela est un entrepôt de données. Les données sont agrégées et consolidées de manière à ce que les applications puissent rapidement en rendre compte. Cela a toutefois pour conséquence que les données ne sont plus accessibles en temps réel et que des compromis sont faits en ce qui concerne le niveau de détail des données.
Pour pallier les lacunes des bases de données traditionnelles, SAP a développé une base de données dite en mémoire où les données sont directement accessibles, la base de données SAP HANA. Outre l'accès rapide aux données en mémoire, il existe également un traitement plus rapide, par exemple, des requêtes sur les données. Les données n'ont pas besoin d'être dupliquées pour être traitées ; cela peut se faire directement dans la base de données. Entre autres choses, l'optimisation des performances obtenue grâce à l'introduction d'une base de données HANA élimine le besoin de consolider et d'agréger les données vers, par exemple, des entrepôts de données. Les données sont directement et rapidement accessibles sans compromettre leur niveau de détail.
La base de données SAP HANA est disponible dans le paysage informatique depuis un certain temps (depuis 2010) et peut donc être utilisée avec, par exemple, un système SAP ECC. Cependant, lorsqu'une base de données SAP HANA est facultative pour un système SAP ECC, elle est obligatoire pour un système S/4HANA. De plus en plus d'entreprises optent donc pour une base de données SAP HANA.
Lorsque l'introduction d'une base de données SAP HANA offre des possibilités de traitement des données, certaines préoccupations se posent également. Le stockage des données en mémoire offre des avantages significatifs en termes de performances des applications, mais il s'agit d'une forme de stockage de données plus coûteuse que les bases de données traditionnelles. Les hautes performances d'une base de données traditionnelle sont obtenues grâce à la rapidité de stockage et de traitement (CPU) des serveurs. Cependant, dans SAP HANA, la taille de la mémoire elle-même (en mémoire) devient la ressource la plus importante.
Bien que le stockage des données soit de moins en moins coûteux, cela ne peut pas compenser la croissance continue des données elles-mêmes. De plus, il n'est certainement pas nécessaire de stocker toutes les données en mémoire ; pourquoi rendre les données directement accessibles si elles ne sont jamais demandées ?
Selon les estimations, 85 % en moyenne des données d'une base de données sont des « données froides » et ne sont que rarement, voire jamais, « touchées ». Il ne reste donc que 15 % de « données chaudes », qui sont estimées à l'origine de 90 % des interactions avec la base de données. Pour traiter correctement les données chaudes et froides, on peut choisir de ne stocker qu'une partie des données (chaudes) en mémoire et les autres données (froides) dans d'autres bases de données. Ces données froides sont toujours accessibles, mais ne seront mises en mémoire que sur demande d'une application spécifique.
Les pièces jointes d'un système constituent l'un des types de données pouvant être considérées comme « froides ». Les exemples incluent les bons de commande sortants, les factures sortantes, les factures entrantes, les e-mails, les notes, etc. À titre d'exemple, nous prenons le PDF généré d'un bon de commande envoyé à un fournisseur. Cette pièce jointe PDF est créée une fois, puis imprimée ou envoyée par e-mail au fournisseur et liée au bon de commande dans SAP.
Lorsque tout est livré par le fournisseur et payé, le processus d'achat est pratiquement terminé. Beaucoup de ces documents PDF créés ne seront jamais ou rarement ouverts. Alors pourquoi charger ces documents dans la mémoire à tout moment ? Cela semble absurde et c'est le cas !
Traditionnellement, les pièces jointes et les documents générés dans SAP sont stockés dans la base de données sous-jacente ; il s'agit en quelque sorte du paramètre par défaut dans SAP. Mais même une base de données traditionnelle n'est en principe pas destinée à stocker des documents dits binaires. Ce que nous constatons souvent chez nos clients, c'est qu'il s'agissait autrefois d'une configuration initiale du système et qu'elle le reste involontairement pendant des années.
La configuration système recommandée pour cela est que les données dites « plates » soient stockées dans la base de données et que les documents ou les données « binaires » soient stockés dans un référentiel de contenu externe. Un référentiel de contenu a pour objectif spécifique de stocker des documents et de les récupérer rapidement en cas de besoin. Il est également plus efficace et moins coûteux de stocker ces types de documents dans un référentiel de contenu que dans une base de données ; pensez aux procédures de sauvegarde ou aux copies système.
Intellidocx peut fournir un référentiel de contenu tel qu'Azure Blob Storage et Microsoft O365.
Alors que dans un environnement SAP doté d'une base de données traditionnelle, il était toujours recommandé de stocker les documents dans un référentiel de contenu externe, l'introduction de S/4HANA et de la base de données SAP HANA associée a rendu plus nécessaire le passage d'une base de données SAP à un référentiel de contenu externe. Lors de la migration vers une base de données SAP HANA avec ou sans système S/4HANA, nous vous conseillons de configurer définitivement le flux de documents dans SAP avec Intellidocx Azure Blob Storage et/ou O365.
Sans installation correcte d'un référentiel de contenu externe, tous les documents et pièces jointes sont par défaut stockés dans la base de données HANA sous-jacente ; cela n'est pas nécessaire. Si vous migrez vers un système S/4HANA, nous vous conseillons de migrer d'abord tous les documents vers Azure Blob Storage et/ou O365. De cette façon, il n'est pas nécessaire de migrer la base de données, y compris toutes les pièces jointes existantes ; elles sont déjà stockées dans Azure Blob Storage et/ou O365.
