Commençons par dire une chose que de nombreux professionnels du PLM et utilisateurs finaux redoutent peut-être d’entendre : tôt ou tard, vous devrez déplacer votre solution PLM vers le cloud et peut-être même dans une configuration SaaS.
Bien sûr, passer au cloud n’est en réalité pas une mauvaise chose. Cela pourrait même être la stratégie la plus importante actuellement pour préparer votre PLM aux exigences inconnues de la complexité des produits de demain.
Consultez mon article « De-risking Your PLM Should be Your Number One Priority » pour une discussion plus approfondie à ce sujet.
Alors pourquoi ce conflit ? Ceux avec de l’expérience en PLM connaissent la triste vérité : personne ne veut apporter des changements majeurs à son système PLM. Sérieusement, personne. Si ça fonctionne, ne touchez à rien !
Le cœur du problème est que la plupart des solutions PLM à grande échelle ont été conçues et construites il y a des décennies sans les capacités permettant aux clients d’intégrer la logique métier spécifique de l’organisation dans le système.
Ces systèmes sont grands et complexes et, à part quelques fonctionnalités configurables intégrées, n’étaient pas conçus pour prendre en charge les exigences des clients en dehors de la base de code du fournisseur de la solution. L’hypothèse était que la fonctionnalité « out-of-the-box » (OOTB) suffirait et que les clients s’adapteraient.
Personnaliser son PLM, la fausse bonne idée
Malheureusement pour les fournisseurs de PLM, les clients avaient leur propre point de vue sur l’importance d’utiliser leur logique métier spécifique plutôt que la fonctionnalité OOTB du vendeur.
Quelque chose devait être fait, car les exigences métiers changeaient trop rapidement pour que les grandes solutions PLM puissent suivre les nouvelles exigences des clients.
Cette situation a conduit les utilisateurs à personnaliser le système de toutes les manières possibles. Ils ont personnalisé, personnalisé et encore personnalisé, créant de nouveaux niveaux de complexité dans le système ainsi que de nouveaux processus et problèmes de codage dans leur déploiement.
À chaque nouvelle version, il semblait que pour chaque problème résolu par l’organisation IT, deux autres étaient créés.
Cela laissait l’organisation dans un état périlleux – les efforts et les coûts pour mettre à jour vers la dernière version du fournisseur augmentaient considérablement, limitant la capacité du client à profiter des nouvelles fonctionnalités OOTB.
Voir la publication CIMdata « Deferred PLM Modernization Delays Time to Value » pour une excellente analyse de ce point.
Migrer le PLM vers le cloud et le SaaS est inévitable
Bien que les entreprises ne veuillent peut-être pas initier un changement majeur dans leur environnement PLM, l’élan de la migration vers le cloud est devenu trop fort pour être ignoré. (Voir mon blog « The Unstoppable Momentum of PLM SaaS » pour plus d’informations à ce sujet).
À ce stade, il y a tout simplement trop d’initiatives de transformation qui nécessitent non seulement les données de produits numériques actuels, mais un niveau de détail des données produits en croissance rapide et ses données associées provenant de presque tous les systèmes de l’organisation.
Ces initiatives nécessiteront un digital thread robuste pour piloter leurs jumeaux numériques, leur stratégie d’ingénierie numérique et leurs efforts en IA. Elles aideront même à satisfaire de nouvelles exigences de conformité complexes comme le Passeport Numérique des Produits de l’UE.
Les entreprises ont désormais besoin de niveaux de flexibilité, d’évolutivité et de sécurité plus élevés pour naviguer avec succès dans ces efforts. Plus elles déplaceront leur PLM vers le cloud tôt, plus elles seront en avance dans tous ces efforts.
Regardez le webinaire « Let Business Value Drive Cloud PLM Transition », dans lequel Jim Brown, président de Tech-Clarity, et moi-même discutons de la manière d’aligner votre stratégie PLM SaaS avec vos objectifs business et de tirer le maximum de valeur de votre solution cloud.
Pas d’effort, pas de réconfort – 3 pain points de la migration du PLM vers le SaaS et comment Aras les résout
Pourquoi ça fait si mal de déplacer votre PLM vers le cloud et le SaaS ? Cela ne devrait-il pas être facile ? Pouvons-nous revenir à Excel ? Sérieusement.
Dans le contexte de cette conversation, je me concentrerai sur la migration de l’on-premises d’un client (ou peut-être d’une entreprise utilisant l’IaaS) vers la solution SaaS de leur fournisseur de logiciels sur le cloud.
Théoriquement, on pourrait supposer que la migration d’une solution logicielle entre deux méthodologies de déploiement ne devrait pas être trop compliquée. Mais voici plusieurs points à considérer avant de commencer votre migration vers le cloud ou le SaaS :
- Personnalisation et dépersonnalisation – Nous avons discuté des personnalisations plus tôt, et c’est effectivement ce qui tend à créer le plus de complications lors d’une migration (autre que potentiellement la migration des données, que je n’inclurai pas ici puisque ce n’est pas unique à la migration vers le cloud). Tant de douleur que de nombreux fournisseurs de PLM ont abandonné l’idée de permettre des personnalisations avec leur nouvelle offre SaaS. Alors, que se passe-t-il avec les personnalisations existantes ? Les fournisseurs de logiciels ont simplement introduit l’idée de la dépersonnalisation. Pour une raison quelconque, ces fournisseurs estiment que les personnalisations sur lesquelles leurs clients ont passé beaucoup de temps et dépensé beaucoup d’argent ces dernières années ne sont plus nécessaires. La fonctionnalité pourrait devenir disponible dans une version plus récente à laquelle ils ne pouvaient pas mettre à niveau précédemment, mais rien n’est sûr. Certains impacts potentiels de la dépersonnalisation incluent l’introduction de processus métiers nouveaux et de plus en plus complexes, ce qui augmentera le temps de traitement, la gestion du changement supplémentaire et la formation lors de l’introduction du nouveau déploiement SaaS, et le risque de moindre engagement et satisfaction des utilisateurs avec le système. Personne n’aime un utilisateur mécontent.
Ce qui est gagné pour les clients Aras : Lorsqu’une plateforme PLM fournit les mêmes capacités de personnalisation de leur solution on-premises dans leur offre SaaS, l’organisation peut conserver les investissements qu’elle a réalisés dans son système sans perturber l’organisation. De plus, ils peuvent continuer à investir dans la construction de fonctionnalités spécifiques à l’entreprise pour accroître la valeur de leur PLM à l’avenir.
Voir mon blog « PLM Customizations and De-customizations: How SaaS is Changing the Future of PLM » pour une discussion plus détaillée sur la dépersonnalisation.
- Mise à niveau depuis une ancienne version logicielle – Dans le rapport d’analyste « Deferred PLM Modernization Delays Time to Value », CIMdata a conclu qu’il y avait un temps moyen de mise à niveau de 11 à 14 mois pour trois des plus grandes solutions PLM. L’enquête a également indiqué que seulement 32% des utilisateurs de PLM des mêmes trois grands fournisseurs de PLM avaient mis à jour leurs solutions au cours des deux dernières années. Cela laisse beaucoup de solutions PLM fonctionnant sur d’anciennes versions sur le terrain. Cela signifie que lorsqu’un client est prêt à passer au SaaS, la première chose à faire est de payer pour leurs “offenses” passées de négliger leurs mises à jour PLM. Ils doivent mettre à niveau le système vers la dernière version, ce qui peut signifier sauter plusieurs versions à la fois. Bien sûr, ce processus inclura également la dépersonnalisation du système. En d’autres termes, avant que la migration vers le SaaS puisse même commencer, le fournisseur et le client ont une énorme quantité de travail à exécuter.
Ce qui est gagné pour les clients Aras : Le même rapport CIMdata a rapporté que 71% des clients Aras ont mis à jour leur système au cours des deux dernières années. Comme la plupart des clients Aras commencent leur parcours SaaS à partir d’une version logicielle à jour, le processus commence plus rapidement.
- Recherche des connaissances tribales – Vous vous souvenez quand j’ai dit que si rien n’est cassé, on n’y touche pas ? Une fois la migration commencée, des informations techniques détaillées sur l’état actuel sont nécessaires pour créer le nouvel environnement cloud, en particulier lorsqu’il s’agit d’anciennes intégrations, car ces intégrations héritées doivent fonctionner de la même manière que le déploiement on-premises. Sauf que, dans de nombreux cas, ces informations ne sont pas bien documentées, ce qui oblige le département informatique à appeler tout le monde, même le type qui a pris sa retraite il y a trois ans.
Ce qui est gagné pour les clients Aras : Eh bien, il n’y a pas moyen de contourner le fait que l’absence de connaissances tribales critiques est l’une des principales raisons pour lesquelles une migration vers le SaaS peut être retardée. La lueur d’espoir dans ce problème est que, une fois les informations recueillies, les données critiques sont formellement documentées dans le cadre de la mise en œuvre et ne seront plus jamais perdues. Plus besoin de déranger ce programmeur à la retraite qui a construit l’intégration il y a dix ans.
Aras Innovator SaaS – une migration PLM-SaaS sans douleur
Pour ceux qui ont la chance d’être sur Aras Innovator®, la migration vers Aras Innovator SaaS est un processus relativement indolore, et les clients l’ont compris.
Dans une annonce récente, Aras a constaté une croissance de 50% des déploiements SaaS d’Aras Innovator, avec de nombreux clients on-premises existants déployant le SaaS.
Le secret non si secret de la réussite d’Aras est qu’Aras Innovator SaaS a la même capacité de personnalisation que l’abonnement standard on-premises. Cela permet aux clients de conserver toutes leurs personnalisations après leur migration SaaS.
De plus, comme Aras a toujours inclus et exécuté les mises à jour des clients dans le cadre du coût de l’abonnement, les clients existants n’ont jamais pris de retard. Le rapport CIMdata a indiqué que près de la moitié des utilisateurs d’Aras avaient été mis à jour au cours des six derniers mois, et la mise à niveau moyenne n’a pris que trois mois.
Pour plus d’informations sur la migration SaaS d’Aras, lisez le dernier commentaire de CIMdata, « Migrating to Aras Innovator SaaS ».
Un autre excellent document à consulter est le livre blanc de Tech-Clarity « Achieving the Business Value of Cloud PLM ».