Vers l'avenir à toute vitesse ou rester sur une voie de garage ?


Le lancement d'un projet de migration de l'ancien et stable SolMan 7.1 vers la nouvelle version 7.2 représente des obstacles dans les entreprises.
Il est difficile d'argumenter pourquoi un budget important doit être utilisé pour remplacer un système stable pour lequel il n'existe encore que peu ou pas de rapports d'expérience pratique.
Les améliorations de la version 7.2 ne sont pas une raison suffisante pour toutes les entreprises pour mettre en œuvre une mise à jour de cette ampleur. Un argument important pour les sciences de la vie en faveur de l'introduction de SolMan 7.2 est la nécessité de se conformer aux exigences réglementaires.
Si des erreurs devaient survenir lors de l'utilisation de la version 7.1 après la fin de la maintenance, si les interfaces ou les modules complémentaires n'étaient plus entretenus ou si les systèmes connectés n'étaient plus pris en charge, le fonctionnement conforme aux GxP ne serait plus garanti.
Un autre argument peut également être utilisé : le début de la migration des systèmes connectés vers S/4 Hana. SAP ne garantit pas un fonctionnement sans faille entre SolMan 7.1 et les systèmes fonctionnant sur S/4 Hana.
Greenfield ou Brownfield ?
Une fois le premier obstacle franchi, la question de la stratégie se pose. Deux variantes se présentent à cet égard. La première (dite Greenfield) se base sur un nouveau système sur lequel tous les processus, tables et données de base sont réimplantés.
L'ancien système doit être arrêté et archivé comme prévu. La deuxième alternative (appelée Brownfield) prévoit également de reconfigurer le système. Toutefois, l'objectif principal est de conserver l'historique du système et de ne pas le diviser en deux systèmes (nouveau et ancien).
La migration initiale représente ici un effort important. Les deux alternatives ont leurs avantages et leurs inconvénients. La variante Greenfield offre l'attrait de mettre en place un nouveau système non sollicité, ce qui entraîne des frais de maintenance moindres. Toutefois, l'ancien système doit continuer à être exploité pour garantir l'accès à l'historique.
L'alternative Brownfield évite l'effort initial de tri des données avant la migration, mais reproduit l'ensemble de l'historique même après le passage à la version 7.2.
Une fois que la gouvernance de projet a été convenue, les interfaces soulèvent des questions. Dans SolMan 7.2, SAP met à disposition son propre éditeur BPML, c'est pourquoi la question se pose de savoir combien de temps l'interface avec les outils de tiers sera maintenue.
La nouvelle suite de tests soulève également la question de savoir si l'interface avec d'autres programmes de test reste utilisable et pendant combien de temps. L'interface avec HP QC n'est plus comprise dans le standard et doit être achetée séparément.
L'exigence critique des sciences de la vie de pouvoir fournir des signatures juridiquement contraignantes pose également problème dans la version 7.2. Cette fonctionnalité complémentaire mise à disposition par SAP pour la 7.1 n'existera plus dans la 7.2.
Ainsi, les exigences d'un processus de signature conforme à la réglementation ne sont plus remplies. Il faut alors trouver des solutions individuelles pour combler les GxP Gaps - de préférence avec un partenaire expérimenté.
Le développement de 7.2 sur des méthodes de projet agiles soulève également une question particulière. Concilier les méthodes de projet agiles et la documentation systématique conforme aux BPx est une entreprise difficile, pour laquelle il manque jusqu'à présent des valeurs empiriques issues d'inspections passées. Dans ce cas, il faut développer de nouvelles solutions ou renoncer à des fonctionnalités pour pouvoir réussir une inspection.
En résumé, l'introduction de SolMan 7.2 représente un grand défi pour les responsables.
Que les entreprises prennent le risque d'exploiter des systèmes SAP (sur Hana) avec SolMan 7.1, qui n'est plus en maintenance, ou qu'elles relèvent le défi de la mise à jour : Le suspense reste entier. Elles devront toutefois prendre une décision tôt ou tard.