Introduction
Comme dit en introduction, les besoins sont des choses que l’on désire mais que l’on ne possède pas. Néanmoins, il faut distinguer deux sortes de besoins différents, ceux bien spécifique à une entreprise et ceux qui sont les désirs des utilisateurs de la solution.
Répondre à un besoin n’est pas toujours aisé. Beaucoup de besoins s’expriment très facilement en affirmant que l’on a vraiment besoin de ceci pour réaliser une tâche afin d’obtenir le résultat final. Mais répondre à un besoin n’est peut-être pas la meilleure des solutions. En cherchant le vrai besoin, il sera peut-être possible d’obtenir directement le résultat final sans répondre au besoin initial.
SA (Strategy Analysis)
la SA est la section concernant l’analyse des besoins de l’entreprise comme vue par le BABOK.
Elle permet de mieux comprendre les besoins de l’entreprise pour mieux atteindre son but.
Un PDF joint à cette publication, sous forme de flux de données, résume toutes les tâches, leurs descriptions, les outils, les parties prenantes impliquées, ainsi que des techniques mnémoniques. Il a été réalisé dans un but pédagogique.
Définir les besoins des entreprises (Business needs)
Les besoins des entreprises, appelé en anglais les “Business needs”, sont les principaux objets pour lequels on va créer un projet. Les besoins d’une entreprise ne sont pas le désir du patron. Ils sont décrits sur ce que l’entreprise essaie d’accomplir, pour avoir une vision la plus claire possible.
Pour trouver les besoins d’une entreprise, il faut poser des questions. Voici quelques exemples :
- Pourquoi désirez-vous cela ?
- Pourquoi pensez-vous le faire comme cela ?
- Quelles produits voulez-vous offrir ?
- Que bénéficieront les clients de la solution ?
Il est aussi possible de découvrir les besoins de l’entreprise en analysant l’entreprise elle-même. Par exemple :
- Quelle est la mission principale de l’entreprise ?
- Qu’est-ce qui motive l’entreprise au changement ? Est-ce monétisable ?
- Qu’est-ce que l’entreprise essaie d’accomplir ?
- Quelle est la vision de l’entreprise à court terme ?
- Quel est le problème que l’entreprise essaie de régler ?
- Existe-t-il des concurrents sur le marché ?
- Est-ce que les clients sont contents du produit ou du service offert par l’entreprise ?
- Quels sont les principales échéances ?
- Existe-t-il des contraintes légales, de temps, de budget (cash-flow), opérationnels ?
- Pourquoi pensez-vous que l’état actuel de vos processus n’est pas suffisant ou optimal ?
- Actuellement, travaillez-vous à perte ?
- Avez-vous penser aux risques ?
- Êtes-vous prêt à abandonner un produit, plutôt que de le maintenir à tout prix ?
- Faut-il construire une nouvelle usine ?
- Faut-il engager du personnel supplémentaire ?
Il faut toujours se poser la question cruciale de savoir si le besoin est en phase avec la vision principale de l’entreprise. Si l’entreprise vend des voitures, il y a peu de chance que le besoin principale de l’entreprise soit de trouver un fournisseur en produits pétroliers. Même si la voiture a besoin d’essence pour fonctionner, le besoin principale de l’entreprise n’est pas de fournir le carburant.
Trouver les vrais besoins d’une entreprise est une tâche vraiment critique car il va en découler les exigences du projet.
Résoudre les besoins d’une entreprise
Une fois le problème cerné, il faut identifier ses caractéristiques en se posant certaines questions comme par exemple :
- L’entreprise est-elle obligée de respecter certaines exigences ?
- Est-ce que le besoin va-t-il améliorer globalement l’entreprise ?
- Est-ce que l’entreprise est financièrement saine ?
- Est-ce que les finances vont-elles s’améliorer ou stagner ?
- Est-ce que l’entreprise est prête au changement ?
- Existe-t-il des choses surprenantes ou contradictoires ?
Définir les besoins des utilisateurs (Stakeholders needs)
Au contraire des besoins de l’entreprise, les besoins des utilisateurs, appelé en anglais les “Stakeholders needs” sont exprimés pour :
- Améliorer un processus de travail.
- Faciliter le travail.
- Gagner du temps sur la réalisation.
- Améliorer l’opérationnel entre les différents groupes.
- Éviter la redondance des opérations entre les différents secteurs ou départements de l’entreprise.
Il est primordial de se poser certaines questions avant d’aller éliciter les collaborateurs, comme par exemple :
- Identifier les principaux acteurs, les principaux départements.
- Est-ce que le produit est conforme a ce que l’on attend ?
- Est-ce que le but est atteint ?
- Peut-on l’améliorer ?
- Y’a-t-il des étapes importantes dans le flux de production ?
- Existe-t-il des processus de travail à suivre ? Sont-ils suivis ?
- Y’a-t-il des logiciels ? Lesquels ? Sont-ils adéquats ?
- Y’a-t-il des rapports journaliers ?
- Comment est-ce que les différents acteurs communiquent-ils entre-eux ?
Définir le problème principale (root cause)
Le vrai problème ou opportunité que l’entreprise recherche à résoudre s’appelle en anglais la “root cause”, ou problème principale. Même quand le problème semble clair comme du cristal, il n’est pas facile d’en déduire que l’on a mit le doigt sur la vérité. Dans la réalité, les parties prenantes ont souvent tendances à exprimer des symptômes, plutôt que la véritable cause. Le meilleur conseil pour éviter de confondre les symptômes et la cause est de poser la question “pourquoi ?” plusieurs fois, jusqu’à ce que le problème semble être une cause.
Vouloir acheter des vêtements est un besoin, mais la vraie nature du problème est de vouloir combattre le froid. La solution pourrait en effet être l’achat de vêtements, mais aussi d’acheter une couverture ou d’augmenter la température du chauffage. Analyser un besoin pour en ressortir le problème principale peut demander du temps et du tact.
Eliciter les parties prenantes
Comme dit ci-dessus, il n’est pas si facile de faire la différence entre ce qu’un collaborateur désire et ce dont il a besoin. On peut trouver les besoins des utilisateurs en posant différentes questions qui commence souvent par le mot “pourquoi”, comme par exemple :
- Pourquoi une telle demande ?
- Pourquoi demandez-vous ceci ? Quel est le but de la demande ?
- Pourquoi le demandez-vous seulement maintenant ? Cela ne fonctionne pas, ne fonctionne plus ?
- Est-ce qu’il y a eu des changements récents dans la procédure, le flux de fabrication, le service ?
- Que ferez-vous si la demande est mise en place ? Ou si elle est refusée ?
Choisir les bons problèmes (Prioriser)
On entend par bons problèmes, un problème qui vaut la peine qu’on s’y attarde pour lui trouver une solution. On peut se poser différentes questions, comme par exemple :
- Est-ce un problème qui touche les fonctions principales de l’entreprise (core business) ?
- Est-ce qu’il survient souvent ?
- Est-ce qu’il affecte la chaîne de production, la logistique ? Est-ce qu’il ralentit la production ?
- Combien de personnes sont impactés par ce problème ?
- Est-ce que la solution envisageable a un impact globale sur l’entreprise ?
- Existe-t-il déjà des solutions au problème ?
- Quel est le niveau de confort des utilisateurs ? Est-ce qu’il est urgent de corriger le problème ?
- Quelle est la motivation des collaborateurs à vouloir modifier les choses ?
Établir les coûts et les bénéfices
L’argent est toujours le nerf de la guerre. Et celui-ci ne fait pas défaut quand on établit une liste des différents problèmes ou opportunités. On peut se poser quelques questions qui ont du sens, comme par exemple :
- La solution, une fois mise en place, fera-t-elle une vraie différence ?
- Est-on prêt à payer pour cela ?
Le coup ne se calcule pas seulement en le réglant. Il faut également prévoir un budget pour le temps d’adaptation des nouveaux processus mis en place.
Créer un énoncé du problème (Problem Statement)
Une fois que l’entreprise a décidé que le problème valait la peine d’être résolu, il faut créer un énoncé du problème en y mentionnant les quatre éléments suivants :
- Le problème principale (root cause).
- Les utilisateurs impactés.
- l’Impact et les enjeux.
- Les effets que la solution doit impérativement contenir.
Phrase exemple :
Le problème des [énoncé du problème] touche [utilisateurs], qui [relation avec l’utilisateur], lequel impacte [exposé du problème, coût, …]. Une solution idéale serait de [bénéfice important qui vont résoudre le problème].
Enoncé du problème :
Le problème des clients qui fument dans nos chambres touche d’autres clients, qui n’apprécient pas la fumée de cigarettes et son odeur, ainsi que notre personnel d’entretien, qui passe plus de temps à nettoyer les chambres, lequel impacte la satisfaction générale des clients, réduit les réservations et augmente les coûts. Une solution idéale serait d’interdire de fumer dans nos chambres et de réévaluer les effets dans quelques semaines.
Créer le positionnement de la solution de l’énoncé.
Une bonne raison de créer un positionnement de la solution de l’énoncé est d’expliquer la solution avec d’autres mots, plus simples, de façon à résumé tous les points de manière claire et précise.
Il sert aussi à aligner toutes les parties prenantes sur les objectifs.
Phrase exemple :
Pour [audience cible] qui [énoncé du besoin ou de l’opportunité], le [nom du nouveau produit ou service] est une [solution ou catégorie de service], ce qui [énoncé du bénéfice – la raison convaincante d’utiliser la solution ou de travailler avec vous].
Énoncé de la solution :
Pour nos visiteurs qui n’apprécient pas la fumée, l’odeur de la fumée, ou les dégâts causés par les fumeurs, le réglement non-fumeur est une nouvelle loi qui interdit la cigarette dans toutes nos chambres pour améliorer l’expérience utilisateur et la baisse de nos réservations, ce qui éliminera l’impact de la cigarette, fournira un environnement plus sain et améliorera la satisfaction de nos clients.
Définir si une solution est bonne
Une solution n’est pas réalisé pour le plaisir. Elle est créé parce qu’elle apporte une vraie plus value. Il faut que les parties prenantes puisse en voir l’impact, l’apprécier et qu’ils sont prêt à payer pour l’obtenir.
Voici quelques questions qu’il faudrait soumettre à l’énoncé du problème.
- Supporte le besoin de l’entreprise ? En d’autres termes, est-ce que le besoin de l’entreprise est résolu ?
- Fonctionne vraiment ?
- Réduit ou permet d’éviter le problème ?
- Donne le résultat escompté ?
- Apporte des valeurs supplémentaires que pourraient apprécier l’audience afin de répondre à ses besoins ?
Évaluer si une solution est bonne
Une fois que le problème a été identifié, clarifié, que ses critères ont été clairement définis et que la solution apporte une réelle plus value, il ne reste plus qu’à la faire évaluer par les parties prenantes.
Voici quelques questions à leur soumettre :
- Qu’est-ce qui va changer si on implémente la solution ?
- Qu’attendez-vous de la solution ?
- Pensez-vous que la solution va vous apporter une plus value ?
- Que pensez-vous réaliser avec la solution que vous ne pouvez pas faire actuellement ?
- Pensez-vous que la solution va fonctionner ? Que signifie fonctionner pour vous ?
Être SMART
Toute solution implantée devrait être SMART. SMART est un acronyme anglais qui signifie :
- Specific : L’objectif de la solution est clair. Elle couvre ce que l’on attend d’elle.
- Measurable : La solution est évaluable par rapport aux attentes de l’objectif.
- Attainable : La solution est réalisable et réaliste.
- Relevant : La solution doit rendre service à l’entreprise.
- Time-bound : La solution doit être réalisable dans une certaine fenêtre de temps réaliste.
Le temps de la réflexion
Une fois l’énoncé du problème ou de l’opportunité écrite avec des mots simples, qu’une solution se détache et peut être recommandée, que celle-ci ajoute une plus value à l’entreprise, qu’elle est financièrement intéressante et bien entendu, qu’elle couvre le besoin principale, il est toujours bon de prendre un peu de recul et de se reposer quelques questions.
Réfléchir avant d’acheter un produit COTS (Cost out of the shell)
- Est-ce que le prix comprend toutes les licences, le coût de maintenance ?
- Est-ce que le produit va-t-il couvrir tous mes besoins ?
- Est-ce que le produit est fonctionnel et intuitif ?
- A-t-il été suffisamment testé ?
- A la distribution et à l’installation de ce produit au niveau technique.
- A la formation des collaborateurs.
- Au matériel à acquérir pour utiliser ce logiciel. On pense souvent au serveur, mais pas aux postes de travail qu’il va falloir remplacer.
- Au coût à la demande. Certains services sont facturés au volume de données ou au nombre de pièces.
A toute excitation de la nouveauté fait place la frustration, le désintérêt, puis la récupération de la confiance
Conclusion
La découverte des besoins est essentielle pour bien cerner le problème principale de l’entreprise ainsi que ceux des parties prenantes. L’analyse peu prendre beaucoup de temps à questionner ces derniers, mais le jeu en vaut la chandelle. L’élicitation est d’ailleurs une des plus grande tâche qui incombe au business analyste.
Le prochain chapitre va donner quelques bons conseils pour livrer le business case.
Et si vous passez la rampe lors de la séance d’approbation, vous pourrez alors vous attelez au prochain sujet qui va s’articuler autour de la création et la maintenance du champ d’application d’un projet, appelé aussi cadrage du projet.
