Vue d’ensemble
Je travaille actuellement sur un projet d’implémentation SAP qui vient tout juste de commencer sa phase de réalisation. L’une de mes premières tâches, en tant que membre de l’équipe de mise en œuvre technique, consiste à réviser les documents de spécifications fonctionnelles complétés pour les objets RICEF. Ces documents, rédigés par des experts fonctionnels en la matière, sont censés détailler les exigences commerciales qui comblent les lacunes et qui doivent être intégrées au système en cours de mise en œuvre. Le but de l’examen est de s’assurer que les documents de spécifications fonctionnelles sont complets, exacts et contiennent les signatures d’approbation requises pour passer à la phase de conception technique.
Au cours de ma carrière, j’ai eu le plaisir de travailler avec des analystes fonctionnels de premier ordre qui savent rédiger un excellent document de spécification fonctionnelle dans les meilleurs délais. C’est ce type de performance qui permet de faire avancer un projet dans la bonne direction, dans les délais et dans les limites du budget. De même, j’ai eu la tâche peu agréable de travailler avec des analystes fonctionnels pas si excellents, qui rédigeaient des documents de spécifications fonctionnelles peu clairs, inexacts et incomplets. Les risques se manifestent en fin de compte sous la forme de retards dans les projets et de dépassements de coûts.
Le bon…
Un très bon document de spécification fonctionnelle contient suffisamment d’informations détaillées sur le processus métier pour permettre à un concepteur technique de l’utiliser comme base pour rédiger un document de conception technique complet et précis. Le document de spécification fonctionnelle ne doit pas seulement souligner la présence d’une lacune, mais doit également démontrer comment le processus métier, accompagné d’une automatisation, comblera cette lacune. Ce document doit également indiquer les exigences de traitement anormal : que doit-il se passer lorsque ce rapport ou cette interface ne s’exécute pas, quelles sont les étapes de récupération, comment les employés clés sont-ils informés du problème, etc. Le contenu d’un document de spécification fonctionnelle doit être adapté à la saveur de l’objet RICEF qu’il décrit. Puisqu’ils effectuent des tâches très différentes, un document de spécification de rapport doit être très différent d’un document de spécification fonctionnelle d’interface, de conversion, d’amélioration ou de formulaire. L’utilisation de modèles de spécifications fonctionnelles permet de garantir le contenu approprié pour chaque type d’objet RICEF.
… et les moins bons.
Je suis parfois étonné par la rareté du contenu qui est réellement proposé à l’examen. « Nous avons besoin d’un rapport » ne m’apprend pas grand-chose sur le processus métier que je suis censé automatiser. Il ne fait même pas allusion à l’objectif du rapport, à son contenu, à sa mise en page, à son interface utilisateur, à son mode d’exécution, aux exigences d’autorisation ou à la gestion des erreurs. Et de même, « Construisez-moi une interface » ne commence même pas à décrire la direction, le contenu de la charge utile, le mappage, la fréquence, la gestion des erreurs et les étapes de récupération. Ce serait une erreur de ma part de tenter de conception technique sur des définitions fonctionnelles aussi maigres. L’un de mes dessins animés préférés montre un responsable du développement debout devant des rangées de programmeurs disant : « Vous, les gars, commencez à coder. Je vais aller découvrir ce qu’ils veulent ».
Je suis en outre étonné par :
a) les chefs de projet qui font pression pour accepter des documents de spécifications fonctionnelles inexacts et incomplets, pour donner l’impression que le projet avance réellement et fait des progrès significatifs.Mais lorsque le test manuel échoue, je leur rappelle simplement que je ne peux pas automatiser un processus métier interrompu ou inexistant.
b) les analystes fonctionnels qui se plaignent sans cesse lorsque leur dérisoire document de spécification fonctionnelle n’est pas accepté.
Un document de spécification fonctionnelle qui ne répond pas aux attentes doit être mis à niveau jusqu’à ce qu’il le soit. Mais faire rebondir un document de spécification fonctionnelle comme une balle de ping-pong entre l’équipe fonctionnelle et un réviseur technique est inefficace et inutile. Je trouve que le meilleur moyen de consolider rapidement un document de spécification fonctionnelle faible est de rechercher minutieusement tous les problèmes que j’ai trouvés dans le document, de formuler des propositions de solutions lorsque cela est possible, puis de planifier une réunion de collaboration face à face avec l’analyste fonctionnel et le(s) propriétaire(s) du processus métier. Ce type de collaboration peut vous faire gagner des heures, des jours, voire des semaines, en postures de ping-pong inutiles, et c’est toujours le meilleur résultat pour le projet.
Ressources techniques offshore
Ce scénario de résolution rapide en face-à-face ne peut généralement pas se produire si vous disposez d’un contingent technique offshore en jeu. Dans ce cas, il est absolument impératif que le document de spécification fonctionnelle soit le plus précis et le plus complet possible pour limiter le risque de perte de temps excessive. Pourquoi donc?
Les ressources offshore sont parfois décalées de huit heures ou plus par rapport à l’endroit où se situe le projet. Si un document de spécification fonctionnelle est publié pour examen, il ne sera pas analysé avant notre départ pour la journée. Si l’examinateur offshore a des questions ou soulève des problèmes, nous ne verrons ces questions ou problèmes que le lendemain, lorsque nous arriverons sur le site du projet. Lorsque nous répondons aux questions ou aux problèmes, l’équipe offshore ne verra notre réponse qu’après notre départ pour la journée. Et ainsi de suite.
Dans ces conditions, il faut des jours plutôt que des heures pour résoudre un document de spécification fonctionnelle mal rédigé et présentant des problèmes. Cela entraîne des retards inutiles dans les projets et des dépassements de coûts.
Quand on est vraiment plusieurs
Cette interface 3PL, qui a été définie et planifiée par les propriétaires de processus métier en tant qu’objet RICEF unique nommé « l’interface 3PL » ; et pour lequel un seul document de spécification fonctionnelle d’interface est écrit, contient en réalité plusieurs objets RICEF. Nous devons déplacer les bons de commande, les réceptions d’inventaire, les préavis d’expédition, les prélèvements d’inventaire et les inventaires tournants entre les deux partenaires d’interface. Chacun d’entre eux représente une charge utile différente, un mappage différent, est déclenché par un point différent du processus métier, possède des procédures de gestion des erreurs et de récupération distinctes et nécessite un objet de développement RICEF distinct.
Ce document de spécification fonctionnelle d’amélioration unique, qui traite de l’ensemble de la tarification SD, a le potentiel de s’étendre à de nombreuses sorties utilisateur différentes. Je viens de terminer le codage d’un proxy ABAP qui a été fonctionnellement spécifié comme une seule interface. En fait, il était quatre heures. L’exigence était de rechercher dans la base de données les données de ventes et de factures commençant par un numéro de facture, un numéro de commande client, le nom du client ou le nom de l’entreprise. Chacune de ces techniques de recherche a nécessité le développement d’une méthode distincte. Les seuls éléments de code partagés entre les quatre techniques de recherche étaient les paramètres d’entrée et la table de retour de sortie.
Le but ici est de s’assurer que les planificateurs du projet comprennent la complexité et les efforts réels requis du côté du développement, et de s’assurer que le plan et le budget du projet reflètent ces mesures plus réalistes. Cela contribue grandement à empêcher tout le monde de se demander : « Ce n’est qu’une seule interface ! Qu’est-ce qui prend autant de temps à développer ?
De grandes attentes”
Alors, qu’est-ce qu’un ensemble raisonnable d’attentes pour un très bon document de spécifications fonctionnelles ? Que demandons-nous à l’analyste d’affaires de faire ?
Tout d’abord, permettez-moi de décrire ce à quoi je ne m’attends pas. Je ne m’attends pas à ce qu’un analyste commercial écrive du code, construise des tables, conçoive des extractions de bases de données efficaces ou décide qu’un BAPI, un module fonction, une classe ou un IDOC est meilleur qu’un autre.
Voici ce à quoi je m’attends :
Une définition claire d’un processus métier reproductible et qui fonctionne réellement. En tant que test de pré-automatisation pour les conversions de données, j’exige toujours que l’analyste fonctionnel en saisisse manuellement un, en utilisant la transaction SAP standard pour laquelle un programme de conversion doit être construit. Souvent, ils ne le peuvent pas parce que le système n’est pas configuré correctement, que les données de support ne sont pas présentes ou pour toute autre raison provoquant l’échec de la transaction. Une observation intéressante est qu’il y a beaucoup de souffles et d’indignations au cours de ce processus de « test » de saisie manuelle. Mais lorsque le test manuel échoue, je leur rappelle simplement que je ne peux pas automatiser un processus métier interrompu ou inexistant.
Une définition claire de ce qui devrait se produire en cas de circonstances anormales ou de défaillance. Cela doit inclure les étapes de gestion des erreurs, de notification, de récupération et de retraitement.
Un processus métier qui peut être automatisé efficacement. Exiger une recherche dans le texte de l’en-tête de la commande client pour l’expression « Ceci est une commande rouge » est une très mauvaise conception à des fins d’automatisation. Bien qu’une telle conception soit techniquement possible à construire, elle sera certainement inefficace au moment de l’exécution et ne produira pas toujours tous les ordres rouges. En effet, la valeur clé est une phrase de forme libre qui peut et sera mal orthographiée et abrégée, ainsi que d’innombrables autres mutilations de la phrase clé « Ceci est un ordre rouge ». Il existe des processus métier et des implémentations techniques bien meilleurs qui permettront de trouver plus efficacement et plus précisément toutes les commandes rouges dans votre système.
Une explication du besoin de développement. Quelle est exactement l’écart, et comment l’automatisation des processus métiers permettra-t-elle de combler l’écart ?
Captures d’écran de transactions SAP illustrant les données qui doivent être récupérées ou stockées. À partir de la capture d’écran de la transaction, je peux généralement déterminer la table et le champ exacts dans la base de données SAP. Notez que certains analystes commerciaux sont très habiles à identifier le nom réel de la table et du champ sous-jacents.
Détails clairs et concis concernant les mappages de données, les formules, les transformations de données, le traitement conditionnel, etc. Si j’arrive à une intersection et que je ne sais pas si je dois continuer tout droit, tourner à gauche ou à droite, le document de spécification fonctionnelle a besoin d’être un peu plus détaillé.
Comment assurer la cohérence dans l’examen des documents de spécifications fonctionnelles
Concevez une liste de contrôle d’examen des documents de spécifications fonctionnelles distincte pour chaque version de l’objet RICEF. Distribuez ces listes de contrôle aux rédacteurs des spécifications fonctionnelles afin qu’ils sachent quelles sont les attentes. L’utilisation d’une liste de contrôle vous aidera à garantir que votre processus d’examen est cohérent et précis. Améliorez ces listes de contrôle au fil du temps. Le document de liste de contrôle des spécifications fonctionnelles de My Form comprend désormais la vérification suivante :
Est-il physiquement possible d’imprimer le contenu spécifié sur le formulaire spécifié en utilisant le style et la taille de police spécifiés ? Une véritable maquette imprimée a-t-elle été fournie comme preuve ?
– mais seulement après avoir reçu une spécification fonctionnelle pour un formulaire qui nécessitait quatre pouces de contenu imprimé sur une étiquette d’un pouce. Et d’une manière ou d’une autre, l’analyste commercial qui a rédigé cette demande particulière a pensé à tort que c’était mon problème à résoudre. Après tout, écrire du code est magique ! N’est-ce pas ? Dans ce cas, j’ai repoussé et insisté pour qu’une véritable maquette imprimée soit produite – une maquette que j’accepterais ensuite d’automatiser.
Résumé
Un bon document de spécifications fonctionnelles aidera énormément à faire avancer un projet dans la bonne direction avec un coût et un risque minimes. Un mauvais document de spécifications fonctionnelles peut sérieusement entraîner des retards dans le projet, ainsi que des dépassements de calendrier et de coûts. Le meilleur objectif du projet est de parvenir à un bon document de spécifications fonctionnelles, par tous les moyens nécessaires.