Il y a « spécifique » et « spécifique », « bon » spécifique et « mauvais » spécifique, un peu comme le bon chasseur et le mauvais chasseur. Mais comment les distinguer ?
Il y a plusieurs axes à prendre en compte :
- Le fond
- La forme
La forme
Dans la forme, commençons par la documentation.
C’est généralement le GROS point faible des équipes de développement, LE truc rébarbatif insurmontable pour l’amateur de code, l’étape qui est repoussée au dernier moment … ou « après la livraison » … voire à un peu plus tard … ce qui finit assez fréquemment en jamais.
Pourtant, réaliser un développement spécifique sans documentation, c’est … ne pas aimer son prochain … ne souhaiter aucun avenir à l’humanité … ne pas s’aimer sois-même !
Sans documentation :
- Comment comprendre un code dont on n’a pas été à l’origine sans devoir repasser des heures à tout re-détricoter ?
- Comment appréhender la logique de développement qui a régit l’écriture du code ?
- Comment avoir la connaissance du contexte qui a poussé tel ou tel choix de programmation ?
- Ces problématiques seront rencontrées par le développeur initial lui-même lorsqu’il remettra les mains dans son code après quelques mois (voire semaines … voire quelques jours seulement).
Dans la forme, il y a également la méthode
Autrement dit, comment on répond techniquement à la demande. Des outils comme SAP ont cette image de rigidité mais en réalité peuvent être personnalisés beaucoup plus qu’on ne le croit et de nombreuses façons. SAP prévoit des points d’entrées pour permettre à ses clients de prendre la main afin d’adapter le fonctionnement pour prendre en compte leurs spécificités (on parle de User-Exit, BadI, Points d’extension, …). Le tout, en complément des capacités intrinsèques liées au paramétrage de l’outil.
Les points d’entrées de type BadI d’encapsuler une touche de développement en respectant le standard.
Le paramétrage (dans les espaces autorisées) vous permettent de respecter le standard.
Il faut une analyse fine, souvent facilitée par une connaissance étendue du standard de l’outil, afin de déterminer le plus judicieusement possible l’emplacement du code à ajouter. Ajoutez le directement au sein du code SAP et vous gagnerez le droit de le gérer à chaque montée de version avec un risque de perte de votre code ou d’incompatibilité avec celui de SAP.
Et s’il n’existe pas de point d’entrée disponible, étudiez la possibilité d’un complément au standard SAP plutôt que l’altération de son standard (en développement un report supplémentaire, en créant un « programme chapeau » qui va exécuter le report standard et exploiter son résultat pour les reformater/compléter selon vos exigences), de sorte que les mises à jour du standard n’impacteront pas directement vos ajouts.
Enfin, dans la forme, il y a la manière
Celle avec laquelle on répond à la demande :
- Basique ; elle fait ce qu’on lui a demandé, peut paraitre simple et efficace mais sans capacité d’évolution. Sera moins cher au départ mais se révèlera plus couteux à l’arrivée
- Réfléchie ; un peu plus lente à sortir de terre, un peu moins « droit au but » mais dans laquelle on a pris soin d’identifier différents cas de figure, d’ouvrir des possibilités de modulation. Un peu moins dans l’immédiateté et un peu plus chère, mais sera le juste compromis.
- Too much ; celle de celui qui s’est emballé et qui a sorti l’artillerie lourde pour envisager tous les cas qui ne se produiront jamais, prévoit trop de possibilité de modulation. Elle répondra au besoin mais sa configuration et sa maintenance restera à jamais un casse-tête pour quiconque devra remettre les mains dedans.
Je n’aborderai pas les sujets de qualité du code, son optimisation, … mais ça compte aussi.
Le fond
J’entends par « fond » la motivation et la justification de la demande initiale qui a abouti au développement spécifique. Est-ce que le jeu en vaut la chandelle ? Est-ce que l’absence de la fonctionnalité ou la fonctionnalité en l’état est réellement pénalisante à l’usage.
Un autre des travers des développeurs passionnés sera de ne jamais dire non et ne pas chercher à en savoir plus. Galvanisés par le challenge que sera la perspective de la victoire de l’Homme sur la Machine, la création d’un nouvel être numérique, ils se jetteront sur leur éditeur de code favori et ceci avant même que l’utilisateur n’ait eu le temps de finir l’expression de son besoin. Et ce n’est généralement pas le demandeur qui tempèrera, impatient qu’il est d’obtenir ce nouveau bouton magique dans son formulaire ou son menu.
Mais nous sommes-nous posés les bonnes questions en amont :
- Quelle charge de travail induit l’absence du développement ? On parle là d’une charge mesurée, quantifiée et qualifiée, pas un simple « c’est trop long à faire à la main ».
- A quelle fréquence aurons-nous besoin de ladite fonctionnalité ? Il n’est pas rare qu’en creusant un peu, on s’aperçoive que le besoin décrit ne se produise que 1 fois ou 2 fois dans l’année ou peut être même s’est-il seulement posé dans le passé. D’ailleurs, est-on certain qu’il se reproduira ?
- Quelle technicité est requise pour réaliser la tâche sans le développement ? Faut-il faire appel à un hybride de Thomas PESQUET et Stephen HAWKING pour pouvoir réaliser cette suivante savante de calculs ou une bête formule Excel fait le job ?
- Quelle est la criticité de cette fonctionnalité ? Est-ce qu’elle porte le poids de tout le calcul de la paie ou ne s’agit-il que de cosmétique ?
- Quel sera l’impact sur le fonctionnement de base de l’outil ? Est-on sûr qu’on ne va pas induire un risque, un faille dans l’outil en ajoutant le développement spécifique ?
Loin de moi vouloir tomber dans la caricature du « expliquez moi votre besoin et je vous dirai comment vous en passer » mais toutes ces questions sont légitimes, doivent être posées et doivent être confrontées au coût total du développement en tenant compte de toutes ses composantes :
- Coût initial = Le temps passé à développer.
- Coût additionnel de la maintenance = La solution demandera-t-elle une maintenance particulière post go-live?
- Coût de l’impact sur les process = Est-ce que la mise en place de la nouvelle fonctionnalité ne provoquera pas un alourdissement d’autres process simplement pour garantir son bon fonctionnement ? Si pour gagner un peu de temps sur une fonctionnalité A, vous augmentez le temps ou les contraintes sur la fonctionnalité B, est-ce que la balance est positive?
Et le truand ?
Le truand … c’est le consultant qui semble oeuvrer pour votre bien, qui dira « oui on peut » à toute demande, exauçant vos rêves les plus fous, certains seront qualifiés de « créatifs », d’autres de « génies ». Comment ne pas les aimer, on leur pose une question, ils ont déjà livré un « p’tit développement » pour « gérer ça »dépanner ».
Pourtant, petit à petit, ils auront transformé votre outil en un amoncellement de briques, un véritable Jenga où la moindre intervention va requérir du tact, du sang froid et une bonne dose de chance pour conserver le tout en équilibre.
(Le pire dans tout ça, c’est que vous leur aurez fourni vous-même chacune des briques empilées)
Pour éviter cela, appuyez-vous sur des experts avec une double compétence fonctionnelle et technique pour faire la jonction entre vos équipes de développement et vos utilisateurs. HRisingIT propose ce type de service aussi bien dans des contextes de maintenance que dans des actions d’accompagnement pour de l’expertise, du diagnostic ou de l’aide à la rédaction de spécifications. Nous pourrons alors aider à qualifier les demandes et cadrer les réponses à apporter notamment en maximisant le recours au capacité du standard.
A retenir
La documentation est essentielle pour comprendre le code, sa logique de développement, et le contexte des choix de programmation. Sans elle, même le développeur original peut avoir du mal à comprendre ou modifier le code plus tard.
SAP propose des points d’entrée comme les User-Exits, BAdIs, et Points d’extension, qui permettent d’ajouter des fonctionnalités spécifiques tout en respectant le standard et en minimisant les risques d’incompatibilité lors des mises à jour.
Modifier directement le code standard peut entraîner des problèmes de compatibilité lors des mises à jour de SAP, un risque accru de bugs, et une maintenance plus complexe et coûteuse.
Il est conseillé d’utiliser les points d’entrée prévus par SAP et de créer des compléments au standard plutôt que de l’altérer. Cela peut inclure le développement de rapports supplémentaires ou de programmes « chapeau » qui exploitent les résultats des rapports standards.
Il est important de se demander si l’absence de la fonctionnalité est réellement pénalisante, à quelle fréquence la fonctionnalité sera utilisée, la technicité requise pour la réaliser sans développement spécifique, la criticité de la fonctionnalité, et l’impact potentiel sur le système.
Les coûts incluent le développement initial, la maintenance additionnelle, et l’impact potentiel sur d’autres processus. Il est crucial de considérer tous ces coûts avant de décider d’un développement spécifique.
HRisingIT propose des services d’expertise, de diagnostic, et d’aide à la rédaction de spécifications, ainsi que des actions d’accompagnement pour la maintenance et l’optimisation des développements spécifiques dans SAP.