Il y a quelques années, certains cabinets de conseil prônaient le « retour aux normes ». S’il n’était pas standard, il fallait le supprimer : les add-ons et les codes personnalisés devaient disparaître. Non-standard était mal. Certaines personnes, même à ce jour, considèrent le « retour aux normes » comme une action positive, quel qu’en soit le contenu.
La vérité est que la mise en œuvre initiale de SAP a souvent commencé à un moment où la réingénierie des processus métier était «à la mode» et le manque de fonctionnalités mélangées à un tel BPR conduisait souvent à l’intégration de spécifications personnalisées dans le système SAP.
Ensuite, l’entreprise a amélioré ses processus métier, pas toujours pour le mieux, mais la plupart du temps pour de bonnes raisons.
Je peux voir deux raisons pour revenir à la norme et deux raisons pour rester « hors norme ».
Raison 1 – Retour à la norme
Je me souviens d’un projet avec une liste étonnante de 2000 exigences spécifiques. J’ai rejoint en tant qu’expert en intégration à quelques mois de la mise en service. L’ERP de cette entreprise comportait deux processus clés qui faisaient la différence : le transport de manière rentable et les incitations des représentants commerciaux.
Lors du développement personnalisé, seules 3 exigences sur 2000 étaient liées à ces processus clés ! Évidemment, lorsque le développement sur mesure n’ajoute pas de valeur, s’en débarrasser est une amélioration.
Raison 2 – Retour à la norme
Une autre raison évidente du « retour à la norme » est lorsqu’une nouvelle fonctionnalité standard a été développée, rendant les utilisations personnalisées non pertinentes. Lors du passage à S/4, certaines modifications seront obligatoires en fonction de la version de la liste de simplification S/4 HANA . Par exemple, déplacer les données de la banque interne du Customizing vers les données de base. Vous pouvez vous interroger sur les avantages d’un tel processus, mais vous devrez modifier votre processus et vous débarrasser des codes personnalisés potentiels.
Raison 1 – Rester hors norme
Lorsqu’il existe une « proposition de valeur unique » pour ce changement. Lorsque le développement personnalisé est clairement un élément clé de la différenciation de votre entreprise. Ce qui vous rend unique n’est probablement pas une norme logicielle : il n’y a pas de fonctionnalité SAP standard pour Airbnb.
Raison 2 – Rester hors norme
Lorsque vous ne comprenez pas la justification commerciale du développement personnalisé. Améliorer la norme demande du temps et des efforts. Il y a probablement une raison derrière cet investissement. Avant de supprimer une amélioration, je suggérerais une enquête pour savoir qui l’a fait et pourquoi.
La vie des systèmes d’information est un mouvement continu
De mon point de vue, la vie des systèmes d’information n’est pas une démarche de « retour aux normes ». Cela implique un mouvement continu vers la pertinence commerciale, la facilité d’utilisation et la rentabilité. La norme est plus facile à mettre en œuvre et constitue souvent la meilleure option. Mais appliquer le « retour aux normes » à tous les niveaux n’est pas une approche raisonnable. Si vous conduisez une voiture et que vous revenez à la norme, vous finissez par marcher !
Lors d’une implémentation S/4 HANA , vous serez tenté de vous adapter au modèle par défaut de l’entreprise. Mais quand devez-vous revenir au paramètre par défaut ou répliquer votre ancien système ?
SAP a une approche pragmatique : c’est votre décision et vous avez des options. Il sera probablement judicieux d’adopter de nouvelles fonctions, mais vous avez le droit de conserver les fonctionnalités existantes.
Avec une approche fanatique de « retour aux normes », le « passage à de nouvelles normes (S/4) » peut impliquer certains pièges – qui découlent d’un manque de compréhension des processus actuels ; surtout lors de leur retrait.
Supprimer un processus existant est la chose la plus simple à faire : pas besoin de remplacement, de conception ou de réflexion. Personne n’est présent pour défendre le processus commercial existant.
Lorsque vous entendez que « Avec HANA, le volume est considérablement réduit et le vieillissement est un nouveau processus, vous n’avez donc pas besoin d’archivage dans votre nouveau système. » – aussi le remettre en question. Encore une fois, vous devez d’abord comprendre quoi et pourquoi vous n’avez pas besoin d’impliquer un processus d’archivage dans le cadre de la conversion S/4 HANA. Demandez à un expert en la matière de découvrir quels pourraient être les pièges et quels pourraient être les avantages de souscrire d’abord à l’archivage SAP dans le cadre de votre plan de migration.
Bonne route vers S/4 .
Parce que vos données comptent.
Thierry JULIEN, PDG et Fondateur de TJC Group
