Migration 9.2

Pourquoi monter de version ?

La montée de version n’est pas toujours facile à vendre en interne et à ses instances de direction car le ROI n’est pas toujours évident ou du moins facile à calculer.
Néanmoins, de par nos expériences, une montée de version offre de nombreux avantages :
  • Prolongement du support Oracle et accès aux derniers correctifs et évolutions mis à jour
  • Prétexte pour revoir les processus avec le métier dans une optique de simplification
  • Diminuer le niveau de spécifique et ainsi réduire significativement le coût de maintenance (les principaux tickets de TMA sont liés à des spécifiques)
  • Remettre à niveau les key users pour en refaire de forts relais de la DSI
  • Documenter (processus, règles de gestion, spécifications, guides de formation)
  • Modéliser les processus (via les e-one page) pour faciliter la compréhension de l’enchaînement des tâches
  • Accéder à de nouvelles fonctionnalités standards JDE : Rapprochement automatique des factures (9.1), Gestion des locations (9.1), Gestion du stock déporté (9.2), Etats Financiers (9.2), etc.
  • Accéder à une nouvelle technologie full web avec de nombreux axes d’évolution : applications mobiles, reporting intégré (One View Reporting), tableau de bord (watch lists), portail d’entreprise, Internet Of Things, écran multi fenêtres (Café One), …

  • Diminuer les licences d’éditique via BI Publisher (étude amont à mener)
  • Diminuer les outils de query ou de reporting périphériques via les One View Reporting (à moduler en fonction des besoins) et enrichis d’alertes propres à chaque utilisateur (watch list)

Comment conduire un projet de montée de version ?

Les bonnes pratiques de b.workshop :
  • Effectuer une étude amont  afin de correctement évaluer le projet (planning, budget, dispositif). Cette étude qui peut être conduite par b.workshop analysera notamment :
    • Le volume de spécifiques et sa typologie (standard modifié, copie de standard, édition, interface, niveau de complexité, …)
    • Les différences de champ ou de fichiers pouvant impacter la migration des données
    • Les nouvelles fonctionnalités pouvant remplacer des spécifiques ou contribuant à de l’ajout de valeur
  • En amont du projet, il conviendra de commencer à réduire le nombre de spécifiques en challengeant le métier.
  • Sachant que le volume de spécifiques impacte directement le coût et la durée du projet
  • Etudier la capacité de BI Publisher à remplacer vos outils d’éditiques actuels. Ceux-ci font aussi souvent l’objet de monter de version (Optio => Transform, …)
  • Mesurer l’impact de passage en Unicode sur les systèmes connexes et notamment les interfaces
  • Préférer rester iso-périmètre pendant le projet et envisager dans un second temps (lot 2) d’intégrer de nouveaux modules ou de nouvelles grosses fonctionnalités
  • Etudier l’intérêt d’externaliser l’infrastructure JDE vers un partenaire tel que b.workshop (Cloud Privé avec OVH)
  • Définir les principaux risques liés au projet (disponibilités du métier, passage en Unicode, appropriation de la nouvelle interface, …), les partager et identifier les actions et leur responsable
  • Sélectionner l’intégrateur en mettant particulièrement l’emphase sur sa capacité à délivrer (gouvernance projet, taille de l’équipe) et les compétences techniques en interne (CNC, Développement, BI Publisher, Web service si besoin)
  • Préférer un forfait à une régie pour contrôler les délais. Pour rappel, la principale contrainte d’un projet de montée de version est que toute demande d’évolution du métier pendant le projet est quasi gelée (ou risque de développer en double dans l’ancien et le nouveau JDE)
  • Lancer le projet en impliquant dès le départ le métier qui jouera un rôle très important pendant la recette et le démarrage
    Initier très tôt le plan de démarrage et le partager avec le métier dans le cas où des jours ouvrés d’activité seraient fermés le temps des opérations de migration
  • Prévoir à minima 1 run à blanc pour tester le plan de démarrage, les temps associés et ainsi confirmer la date de disponibilité de la nouvelle version JDE
  • Préparer les outils de contrôle de migration des données en vue d’audit des CAC post migration. Ces contrôles sont de plus en plus fréquents et de plus en plus pointus (contrôle des écarts de paramétrage, écarts de données, etc.).

Retour d’expérience de b.workshop : Upgrade de Xe à 9.1

Objectif : réduire le nombre de spécifiques tout en restant iso fonctionnalités
Résultat : 32 spécifiques reportés vs 130 identifiés initialement avec 2 autres intégrateurs JDE du marché. Soit 75% de réduction grâce une collaboration étroite entre le métier les consultants senior b.workshop
Périmètre : Distribution (PO, INV, SO) & Finance (GL, AP, AR, FA)
Durée : 4,5 mois en respectant l’échéance du projet malgré un lancement pendant la période estivale
Challenges : passage de Streamserve à BI Publisher avec un minimum de régressions
Facteur clé de succès : pilotage au forfait avec une équipe Delivery dédiée à ce type de projet et une équipe technique aguerrie
Post by admin

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *