Quel est le rapport entre l'agilité et les anciens systèmes SAP ?

Les paysages SAP qui se sont développés au fil du temps ressemblent souvent à de lourds pétroliers qui ne peuvent changer de cap qu'avec un grand retard. Cela est moins dû à la taille des navires qu'au poids de leur cargaison. L'inertie de ce dernier empêche les changements de direction rapides, même si le gouvernail est arraché.

Comme les pétroliers, les systèmes SAP et autres transportent une lourde cargaison : des données et des documents dont seule une petite partie est nécessaire dans le travail quotidien. Quel que soit le degré d'agilité et de flexibilité que les responsables informatiques ajoutent au niveau des systèmes et des applications, il est compensé par la stabilité requise par l'entreprise et la législation au niveau des données et des documents. Ce problème général se pose dans les scénarios les plus divers.

Fusions et acquisitions

Lorsque des achats d'entreprises sont scellés, la joie est grande - pour le management. Mais à peine l'encre des contrats est-elle sèche et le champagne bu que le travail commence dans l'informatique.

En effet, l'acheteur ne reprend pas seulement des marchés, des collaborateurs et des clients, mais aussi des systèmes informatiques dont le nombre se compte rapidement en centaines, surtout dans les grandes entreprises, dont une multitude de systèmes SAP de différentes versions.

Il est bien sûr économiquement absurde de continuer à exploiter tous ces systèmes. Mais les éteindre ne semble pas non plus être une option. En effet, ils contiennent des données et des documents précieux, qui représentent de l'argent liquide pour l'acheteur.

Elles sont en outre soumises aux obligations et aux délais de conservation les plus divers. Même après l'achat, les informations doivent être conservées pendant de nombreuses années, parfois des décennies, et mises à disposition si nécessaire, jusqu'à leur suppression contrôlée et documentée, comme l'exige notamment le règlement général européen sur la protection des données (RGPD).

Les rachats d'entreprises impliquent donc toujours des projets d'intégration et de migration complexes pour les départements informatiques. Il faut décider quelles applications doivent être reprises par l'entreprise rachetée, car elles présentent des avantages par rapport aux siennes, et lesquelles ne sont plus nécessaires. La question de savoir quelles données et quels documents doivent être migrés vers les systèmes en direct est directement liée à cette décision.

Lors d'une migration, la structure des données et des documents migrés est généralement modifiée dans un tel projet. Les auditeurs internes ou externes n'auraient donc pas confiance dans le fait que les informations migrées correspondent exactement à l'original.

Par conséquent, même si les données et les documents ne sont que partiellement migrés à partir de ceux repris lors de l'achat, les systèmes informatiques devront continuer à être exploités et mis à jour pour répondre aux nouvelles obligations telles que le RGPD de l'UE.

Cette dernière exigence en particulier n'est plus du tout possible techniquement pour de nombreux anciens systèmes ou n'est réalisable qu'au prix de très gros efforts. Or, cela implique dans tous les cas des coûts élevés.

Traitement des banques

La crise financière de 2008 n'est toujours pas surmontée. De nombreuses banques continuent de souffrir de crédits douteux qui peuvent à tout moment menacer leur existence. A cela s'ajoutent des réglementations toujours plus nombreuses et plus strictes, censées réduire le risque pour le système financier dans son ensemble en raison des difficultés de certaines banques. Même si elles partent d'une bonne intention, elles pèsent parfois lourdement sur la capacité bénéficiaire des banques.

Les banques qui ne veulent ou ne peuvent plus faire face aux charges liées à la conformité et les établissements qui ne sont pas viables sont vendus ou liquidés dans des sociétés de défaisance.

Que les clients soient repris ou que l'activité soit totalement arrêtée, les acheteurs ou les successeurs sont tenus de conserver toutes les informations relatives aux clients pendant dix ans ou plus.

Or, comme c'est souvent le cas dans les banques, ces données sont réparties sur une multitude de systèmes : Parmi eux, on trouve des développements propres aux banques et des systèmes SAP, mais aussi des solutions commerciales de messagerie électronique, des systèmes de gestion de documents ou de gestion de contenu d'entreprise, ainsi que des archives audio dans lesquelles les entretiens de conseil avec les clients sont stockés sous forme d'enregistrements numériques.

Pour pouvoir continuer à accéder aux anciennes données et documents, tous les anciens systèmes doivent être repris par la société successeur et continuer à être exploités.

L'accès aux informations sur les clients est nécessaire en permanence pour deux raisons. D'une part, les avocats ou les autorités fiscales, qu'elles soient nationales ou étrangères, ont le droit de demander l'autorisation de consulter les données bancaires.

Il en va de même pour les anciens clients des établissements vendus ou liquidés, qui ont besoin de copies pour les relevés de compte perdus, par exemple pour les déclarations d'impôts.

Bien que le nombre pur de ces demandes devrait rester gérable, l'ensemble de l'environnement informatique repris doit être géré et entretenu, mis à niveau au fil du temps et éventuellement même faire l'objet d'une nouvelle licence.

Migration vers S/4 Hana

En 2025, ce sera le cas. Les attentes des clients existants de SAP sont élevées : ils associent la nouvelle génération de logiciels à l'espoir d'un environnement applicatif agile qui leur permettra de relever les défis de la numérisation.

Mais ils savent aussi que le plus grand défi de cette nouvelle mise en œuvre, tant en termes de complexité que de temps, réside dans la migration des données et des documents dans le nouvel environnement.

Les clients SAP existants sont rapidement confrontés à une charge de travail de plusieurs milliers de jours-homme pour les grandes installations SAP avec plusieurs téraoctets de volume de données. De plus, le stock de données contient inévitablement de nombreux enregistrements erronés qui se sont accumulés au fil des années.

Une migration vers S/4 et Hana, au cours de laquelle toutes les données et tous les documents des systèmes existants sont transférés dans le nouveau monde et les anciens systèmes doivent continuer à fonctionner parallèlement à la nouvelle génération de logiciels, n'a aucun sens du point de vue de l'entreprise.

Enfin, la poursuite de l'exploitation des anciens systèmes dans les entreprises est l'une des principales raisons pour lesquelles 80% du budget informatique total est généralement consacré à la seule exploitation.

Les dépenses liées aux anciens systèmes représentent souvent à elles seules 70 pour cent de cette somme. L'idéal serait en revanche une répartition de 60 pour cent pour l'exploitation informatique et de 40 pour cent pour les innovations, et ce de manière durable.

Un obstacle au moins aussi important sur la voie d'un avenir agile est le manque de qualité des données après une migration. Il n'est pas exagéré d'affirmer que le succès de la numérisation en dépend.

En effet, si les données ne sont pas correctes, les processus hautement automatisés entre les hommes et les machines, mais aussi entre les machines elles-mêmes, ne fonctionnent que de manière limitée et sont sujets à des erreurs.

Les évaluations dans des bases de données erronées conduisent à des conclusions erronées qui, dans certaines circonstances, peuvent avoir des conséquences fatales sur l'évolution des modèles commerciaux.

La bonne approche

Même s'il s'agit de scénarios très différents, ils partagent le même problème de temps, de coûts et de complexité. Les clients SAP existants peuvent le résoudre s'ils adoptent une nouvelle approche architecturale : séparer les données et documents existants des apps agiles du futur.

Les anciens systèmes peuvent ainsi être désactivés, condition sine qua non pour que l'informatique devienne aussi agile que les scénarios d'entreprise l'exigent. L'élément clé de cette nouvelle architecture est un environnement distinct, indépendant du système, pour les données et documents existants et leur contexte commercial.

C'est précisément pour ce type d'architecture et de scénarios commerciaux agiles que la société suisse Data Migration Services AG a développé des paquets de solutions spécifiques, notamment pour le traitement des banques, pour les achats et les ventes d'entreprises ainsi que pour la migration efficace vers S/4 Hana.

Ces solutions reposent sur la plate-forme de gestion de l'information JiVS. Celle-ci offre en standard un grand nombre d'interfaces vers les systèmes existants des fabricants les plus divers. Outre SAP, on y trouve notamment BaaN, JD Edwards, Infor, Microsoft, Oracle EBS, Peoplesoft, etc. Vraiment toutes les informations des anciens systèmes sont saisies et migrées, chaque étape est documentée de manière exhaustive.

Il ne s'agit toutefois pas d'archivage classique, mais d'historisation : ni les utilisateurs spécialisés, ni l'audit interne, ni les auditeurs externes n'ont accès aux champs des tableaux.

Ils recherchent plutôt, par exemple, tous les relevés de compte concernant un client au cours d'une période donnée ou l'enregistrement d'un entretien de conseil qui a précédé la conclusion d'un contrat donné. C'est pourquoi JiVS stocke les informations avec leur contexte commercial.

Un cryptage solide et des mises à jour de sécurité régulières assurent la sécurité nécessaire à une époque où le cyberespionnage et la cybercriminalité sont omniprésents. Le nettoyage des enregistrements erronés ou redondants optimise la qualité des données.

Les données et les documents peuvent être supprimés de manière ciblée au niveau des enregistrements individuels. Les autorisations peuvent être clairement définies. Bien entendu, JiVS répond aux exigences non seulement de la protection européenne des données, mais aussi des commissaires aux comptes. Et pour ceux qui souhaitent externaliser les différents paquets de solutions, les fonctionnalités peuvent être utilisées dans différents modèles de livraison - hébergement, service géré, SaaS.

Moins, c'est plus

Les clients SAP existants économisent jusqu'à 80% - voire plus dans certains cas - sur les coûts opérationnels par rapport aux coûts liés à la poursuite de l'exploitation des systèmes mis hors service. En même temps, ils réduisent l'ampleur et la complexité des projets de migration à réaliser, car seules les données et les documents réellement nécessaires doivent être transférés dans les systèmes en direct ou y être laissés. En règle générale, cela ne représente que 20 à 25 %. Comme dans la vie réelle, cela vaut aussi pour les entreprises agiles : Moins, c'est souvent plus.