Dans le blog précédent de cette série, j’ai abordé le sujet des clients qui attendent d’une société qu’elle gère leurs données, en particulier dans un contexte d’accès « Invité ». Quand ces données seront-elles supprimées définitivement ?
Qui y aura accès avant leur suppression ? Quel est le niveau de sécurité des données stockées ?
Les données de commande « Invité » sont un exemple de la « dette de confidentialité » qui réside dans la plupart des systèmes ERP. Il s’agit de données dont la persistance ne repose clairement sur aucun fondement juridique et qui n’ont en général pas été supprimées en raison de la complexité du nettoyage du système ERP. Cela pourrait également s’appliquer aux systèmes CRM ; mais dans la plupart des cas, ces systèmes ont été conçus en tenant compte du fait que certaines données seront transitoires et incluent des mécanismes de suppression des données qui ne sont plus utiles.
Les principes de base des systèmes ERP, et certainement de SAP ERP, sont en fait à l’opposé : intégration complète et traçabilité de toutes les données à tout moment. J’ai fait une publication à ce sujet lors de la présentation du RGPD et sur les défis qu’il posait pour le « droit à l’oubli ». Cela signifie que la plupart des sociétés qui exécutent SAP se retrouvent avec des données dont elles ne peuvent justifier la présence dans leurs systèmes.
Il existe bien sûr d’autres exemples de « dette de confidentialité », comme les employés qui ont quitté l’organisation depuis longtemps. Plus la relation avec l’employé est libre, plus la période de conservation des données est courte. Il peut s’agir par exemple de travailleurs saisonniers dans les systèmes de distribution qui reviendraient ou non l’année suivante, ou de contractants employés pour un projet à court terme spécifique.
Les employés/clients/fournisseurs qui font partie d’une entreprise qui a été liquidée depuis longtemps constituent un autre exemple commun pour les industries où les acquisitions et les cessions sont courantes. Ou encore des données présentes dans un système qui a été repris lors d’une acquisition, mais qui n’a jamais fait partie de l’activité achetée. Il y a dix ans, la confidentialité des données n’était pas prise en compte lors des acquisitions. Le transfert des systèmes et des données nécessaires à l’exécution de l’activité était le seul objectif du projet technique et si quelques données supplémentaires étaient incluses, qui s’en souciait ? Aujourd’hui, les projets de fusions et acquisitions doivent prendre la confidentialité des données très au sérieux, comme pour tout autre projet -
« Par défaut et par conception ».
La suppression des données des systèmes ERP et en particulier de SAP présente deux défis majeurs :
Que serait un blog SAP sans la mention de S/4HANA ? Eh bien, lors de la réflexion ou de la préparation d’une migration S/4HANA, le nettoyage et l’archivage des données sont en général discutés. À ne pas confondre avec la gestion de la dette de confidentialité. Le nettoyage des données concerne rarement celle des données non requises, à moins qu’il s’agisse d’un projet de construction dans lequel cette dette en attente peut simplement être laissée de côté. Typiquement, il s’agit du processus ICF (Intégration client/fournisseur) et la déduplication des fiches utilisateur ou la correction des erreurs de formatage. L’archivage est pris en compte dans les projets Brownfield pour réduire la taille potentielle de la future base de données du système, la majorité des gains d’espace étant archivée en retirant d’importants volumes de données de transaction plutôt que de données de base historiques.
Si le nettoyage complet de la dette de confidentialité ne génère pas de gain d’espace majeur, et que le processus créé davantage de difficultés en supprimant potentiellement des données non sensibles de valeur comme la couverture géographique des clients, la fonction de reporting de genres sur les employés historiques, il existe surement un meilleur moyen ? Le problème avec le fait de laisser l’entreprise simplement modifier les données pour supprimer les valeurs identifiables est que la modification en elle-même fait l’objet d’un suivi. Si nous préférons aller directement au niveau de la table pour remplacer des données sensibles ou d’identification, nous pouvons le faire dès le début de l’existence des données et non en tant que modification, comme c’est le cas actuellement.
Mais toutes les informations connexes qui peuvent toujours être utiles pour le reporting peuvent être conservées. Et toute dépendance de relations de clé étrangère dans les données transaction, ou même les références de données de base liées (par exemple, adresses, données d’OTP, contacts) seront toujours intactes.
Ici, vous voyez le même fournisseur que tout à l’heure, mais maintenant, nous avons rédacté les données sensibles dans LFA1, LFB1, ADRC au niveau du programme.
Avec tous les documents de modification supprimés (puisque les valeurs d’origine peuvent s’y trouver).
Dans cet exemple, les données de base de KNA1, ADRC, etc. qui sont gérées via XD02 sont visibles dans la transaction Commandes clients (VA03) en raison du lien dans la table VPBA. Nous n’avons pas besoin d’apporter de modifications à la commande dans cet exemple. Toutes les données personnelles sont retirées. Donc les modifications, similaires à ce que nous avons fait dans le premier exemple pour le fournisseur, et maintenant dans la fiche client, garantissent aussi que les commandes pour ce client ne présentent plus de données personnelles.
Dans le blog précédent, je m’étais concentré sur le sujet des adresses personnalisées ou sur mesure, comme faisant partie d’un processus d’achat « Invité » ou dans lequel l’adresse héritée de l’enregistrement de données de base a été adaptée pour cette commande particulière. Maintenant, nous voyons un enregistrement d’adresse différent lié à la commande dans VPBA et avons à la place effacé les données dans ADRC au niveau du programme.
Le défi avec la configuration de vos propres programmes de «rédaction» est le nombre d’emplacements dans lesquels les données peuvent aussi résider. Il n’est pas impossible de tous les trouver, mais c’est quelque chose qui doit aussi être vérifié si les processus de gestion changent et lors d’une future mise à niveau de SAP. Voici quelques exemples :
Nous avons développé un logiciel qui peut être exploité directement par les organisations pour réaliser leur propre «rédaction», soit en réaction aux demandes individuelles, soit dans le cadre de l’application périodique automatique d’une période de conservation. Nous proposons également des services et des conseils pour aider à gérer le nettoyage initial majeur de la dette de confidentialité.
Contactez-nous pour obtenir l’aide de nos experts.
Activité minimale pour satisfaire les exigences de minimisation des données historiques pour la conformité.