Blog ENI : Toute la veille numérique !
En raison d'une opération de maintenance, le site Editions ENI sera inaccessible le mardi 10 décembre, en début de journée. Nous vous invitons à anticiper vos achats. Nous nous excusons pour la gêne occasionnée
En raison d'une opération de maintenance, le site Editions ENI sera inaccessible le mardi 10 décembre, en début de journée. Nous vous invitons à anticiper vos achats. Nous nous excusons pour la gêne occasionnée
  1. Livres et vidéos
  2. Business Intelligence : le recueil des besoins
  3. Activités de recueil des besoins
Extrait - Business Intelligence : le recueil des besoins La boîte à outils du business analyst
Extraits du livre
Business Intelligence : le recueil des besoins La boîte à outils du business analyst
1 avis
Revenir à la page d'achat du livre

Activités de recueil des besoins

Introduction

Après avoir vu ce qu’il fallait capturer et sous quelles formes il était possible de le formaliser, voici différentes manières d’organiser le travail avec vos parties prenantes. Nous touchons ici à la partie sociale du recueil des besoins, il n’y a pas de formule magique, tout dépend de votre contexte, des personnes, de leurs expériences, de leur culture… En fonction de l’environnement, il vous faudra choisir la ou les méthodes les plus adaptées. Ce chapitre vous décrira chacune des méthodes avec ses avantages et ses limites. Le tableau comparatif en fin de chapitre permettra de récapituler.

Workshop

Le workshop est la méthode de groupe la plus utilisée. Il est aussi appelé "atelier de travail". Pour être productif, il a cependant besoin d’être préparé en amont.

1. Présentation

Il est souvent perçu comme une réunion participative, mais pour être productif il doit être bien préparé. Il existe plusieurs types de workshops (workshops fonctionnels, techniques, ou basés sur les scénarii fonctionnels).

  • Le workshop fonctionnel a comme objectif de définir un besoin métier. Il est utilisé pour définir des priorités et un scope. Suivant les contextes, le résultat peut être un ou plusieurs scénarii, un process modélisé avec des thermomètres (cf. Méthode des thermomètres), un arbre de buts (cf. L’approche par objectifs). Le groupe est généralement constitué avec une forte dominance fonctionnelle même si quelques experts techniques peuvent être invités pour un avis consultatif.

  • Le workshop technique a pour vocation de résoudre un problème technique avec différentes expertises (architectes, développeurs front-end, back-end, urbanistes, modeleurs, experts en sécurité, équipes de configuration…) Il est alors très pertinent pour envisager des configurations complexes ou des problématiques systémiques. Le groupe est fortement orienté technique, un représentant fonctionnel ou l’analyste peuvent être invités pour donner des précisions.

  • Le workshop basé sur un scénario fonctionnel. À mi-chemin entre les deux précédemment cités, le workshop basé sur un scénario se découpera en trois parties :

  • Les équipes fonctionnelles préparent un scénario fonctionnel à résoudre. Le résultat attendu prendra de la même forme que celui du workshop fonctionnel.

  • Les membres fonctionnels présentent le scénario/business case à résoudre aux membres techniques. Les équipes techniques vont alors envisager différentes solutions techniques....

Interviews

L’interview est la méthode individuelle la plus utilisée. Pour être efficace, elle doit répondre à certains critères. Si vous aimez les investigations policières, le Cluedo et la Grèce antique, cette méthode est pour vous.

1. Présentation

Il s’agit ici d’interviewer les différentes parties prenantes séparément. Ce sont souvent des entretiens en face à face ou par téléphone. Les entretiens peuvent être plus ou moins formels, allant de la conversation naturelle au questionnaire en passant par l’interview dirigée.

L’intervieweur se doit de ne pas influencer les réponses. Il faut alors être à l’écoute et observer l’interviewé. Voici quelques techniques qu’il est possible d’utiliser pour mener un entretien.

a. Les techniques issues des interrogatoires policiers

Un interrogatoire de police se déroule souvent en trois étapes :

  • Le récit libre : le but est alors de laisser la personne parler sans l’interrompre. Elle va alors souvent brosser largement le sujet. Cela permettra de recueillir son point de vue non biaisé, mais aussi ses priorités, les conflits potentiels (elle a peut-être besoin de "vider son sac"). L’intervieweur se doit alors de noter aussi fidèlement que possible le contenu. Cette phase est particulièrement importante en cas de conflit entre les différentes parties prenantes, car elle permet à chacun de se sentir écouté.

  • Les questions ouvertes : cette étape permet à l’intervieweur de poser des questions pour orienter le sujet et de se focaliser sur les parties qui lui semblent prioritaires. Les questions seront du type "pouvez-vous approfondir… ?", "que pensez-vous de ce sujet… ?". Ce sont toujours des questions qui appellent une réponse longue.

  • Les questions spécifiques : le domaine est maintenant bien ciblé, il s’agit de préciser des points de détails. Les questions souvent fermées (dont la réponse est "oui" ou "non" ou appelant à des réponses précises : "quelle définition mettez-vous derrière ce terme métier ?"...

Méthode Delphi

Elle est aussi connue sous le nom de méthode de Delphes. Delphes une ville grecque ou un oracle (la pythie) faisait des prédictions. La méthode a été en réalité inventée par Norman Dalkey et Olaf Helmer aux États-Unis en 1948. Elle peut être fastidieuse, mais donne de très bons résultats.

1. Présentation

Le but de la méthode Delphi est de décorréler l’idée émise de l’émetteur. En procédant ainsi, l’idée pourra être évaluée pour elle-même. Cela élimine les préjugés liés aux personnes, mais également l’utilisation de techniques de manipulation. Cette technique, bien que peu utilisée, est très utile dans les cas d’équipes à distance, de conflits, de tensions, de différences d’influences des parties prenantes. L’utiliser permettra de trouver un consensus sur les thématiques et les priorités.

Elle se constitue de plusieurs étapes :

La première étape va être de choisir le sujet. Il est important de définir précisément le sujet au risque d’induire en erreur les parties prenantes et de rendre le processus confus.

La seconde étape va être de choisir les parties prenantes interrogées et leur qualité (connaissances, impartialité…). Il faut prévoir un nombre assez important d’experts pour pallier les démotivations).

La troisième étape est l’élaboration...

Brainstorm

C’est l’un des buzz word de ces dernières années : il est particulièrement efficace si vous devez faire preuve de créativité.

"Il n’est de fertile que la grande collaboration de l’un à travers l’autre. Et le geste manqué sert le geste qui réussit, et le geste qui réussit montre le but qu’ils poursuivaient ensemble à celui qui a manqué le sien". Citadelle (1948) - Antoine de Saint Exupéry.

1. Présentation

La technique du brainstorm, aussi appelée "remue-méninges", est particulièrement utile dans des circonstances où la créativité est primordiale. Elle peut être utilisée notamment pour la définition de besoins fonctionnels. Il arrive parfois que l’on cherche à mesurer un événement dont la capture informatique est impossible ou peu précise. Le brainstorm peut alors être utilisé pour trouver des solutions de contournement, sortir des sentiers battus. C’est notamment le cas dans l’évaluation du risque, de l’impact social ou environnemental, du sentiment du client et plus généralement dans les mesures dont les processus sont externes à l’entreprise et les sources de données non existantes ou peu fiables.

Une session de brainstorm est généralement composée de plusieurs parties. Après la préparation, la première sert à générer le plus d’idées possible, la seconde à sélectionner les idées.

  • La préparation permet de définir l’objet du brainstorming, de consistuer le groupe, de communiquer pour stimuler la créativité des participants, d’envoyer des éléments inspirants (articles de journaux…), de prévoir un lieu, du matériel (tableau, post-it, feutres…) et de prévoir une date...

Design thinking

Le design thinking est un processus de conception qui se concentre sur les besoins des utilisateurs. L’équipe du projet va tenter de se mettre dans les chaussures des utilisateurs du projet.

1. Présentation

Le design thinking a été inventé par Rolf Faste à l’université de Stanford en 1980. La méthode a été initialement définie en sept étapes : définir, rechercher, imaginer, prototyper, sélectionner, implémenter et apprendre. Elle est maintenant couramment utilisée sous une forme allégée avec quatre étapes : comprendre, définir, développer et livrer, sous le nom du modèle "Double Diamant".

Cette méthode est à mi-chemin entre une démarche analytique et une démarche créative. Elle est représentée par deux diamants. Le premier est consacré au problème, le second à la solution. Chacun de ces diamants comporte une phase divergente pour recueillir des informations, c’est la phase créatrice, et une phase convergente pour se focaliser sur une des informations issues de la phase précédente. Cette phase convergente est la partie analytique de la démarche. 

images/CH5V1.png

Processus de design thinking

Tout d’abord, le premier diamant….

La première étape est "comprendre", il s’agit ici d’interroger les principaux utilisateurs potentiels. Il peut être utile de réviser les techniques d’interviews (cf. Activités de recueil des besoins - Interviews). On tentera ici de comprendre leurs besoins, leur travail...

Méthode des thermomètres

Cette méthode est inspirée des travaux de recherche de l’Université Paris 1 Panthéon Sorbonne. Je l’implémente depuis plusieurs années, elle est ludique et facilement utilisable dans les projets de reporting opérationnel.

1. Présentation

Cette technique peut être employée sur des processus. Elle permet de "prendre la température" de chaque activité du process en définissant des KPI. Chaque activité aura alors un thermomètre externe et interne.

L’analyste travaillera à partir de la modélisation d’un ou plusieurs processus métier. Cette activité ne sera pas décrite ci-dessous, car elle appartient à la définition des processus et des systèmes opérationnels et non à la partie décisionnelle. 

"Les grands progrès résultent de la substitution du quantitatif au qualitatif. Des instruments de mesure comme la balance, le galvanomètre et le thermomètre, ont plus modifié nos pensées et nos conditions d’existence que toutes les dissertations philosophiques." Les incertitudes de l’heure présente - Gustave Le Bon.

  • Les parties prenantes fonctionnelles (métier) définissent quelles sont les activités clés sur processus et si tout ou partie du processus doit être monitoré. Cela peut se faire de différentes façons : le manager du processus peut prendre la décision de manière autocratique, les différents responsables peuvent se regrouper, un comité de pilotage peut se réunir, la méthode Delphi peut être utilisée (cf. la section Méthode Delphi de ce chapitre).

Prenons l’exemple d’un process de connexion d’une ligne de téléphone. Il est défini comme suit par le business :

  • Le client commande une nouvelle ligne.

  • Les équipes opérationnelles installent la ligne de téléphone.

  • La ligne est opérationnelle.

images/CH5V3.png

Process d’installation d’une ligne de téléphone

  • Les parties prenantes techniques et fonctionnelles identifient les systèmes informatiques supportant les activités définies. Il peut s’agir d’une...

Groupe de collaboration

Cette approche prône de remplacer l’organisation hiérarchisée par un mode de travail beaucoup plus organique où la communication est la base. Le parti pris est que l’intelligence collective d’un groupe est toujours plus efficace que la décision d’un manager. Elle ne se préoccupe pas de la qualité des communications, mais vise surtout à multiplier l’échange d’informations pour faire émerger par l’intelligence collective des solutions aux problèmes envisagés.

1. Présentation

Tout d’abord, un petit exemple aviaire. Les oiseaux migrateurs sont un bel exemple de collaboration et d’intelligence collective. Ils parcourent de longues distances, il est donc important de minimiser les dépenses énergétiques. Certains oiseaux utilisent la force du groupe. Ainsi les oies sauvages volent en "V", chaque oiseau utilisant l’aspiration de son prédécesseur. Elles arrivent ainsi à augmenter leur rayon d’action de 70 %. Le prix à payer est la diminution de la vitesse de vol. Un oiseau isolé vole 24 % plus vite qu’une formation. C’est ce que font également les cyclistes.

"Si tu veux aller vite, marche seul, mais su tu veux aller loin, marchons ensemble." - Proverbe africain

Le principe est que des individus sont...

Cas d’utilisation métier et scenarii

Les cas d’utilisation métier et les scenarii vont souvent de pair. Les cas d’utilisation vont décrire le contexte des scenarii.

Ils sont souvent une solution simple à mettre en place, mais peuvent s’avérer risqués et non exhaustifs.

1. Présentation

Comme décrit par Ivar Jacobson en 1987 : "Le cas [d’utilisation] métier est la description des interactions entre un système et l’utilisateur de ce système". Il peut être aussi vu comme une fonctionnalité cohérente et indépendante.

a. Les cas d’utilisation métier

Les cas métier (business use cases) peuvent être utilisés dans différents contextes. Ils permettront, par exemple, de définir les principales parties prenantes, la composition du comité de pilotage, la politique de sécurité des données ou le processus métier à capturer.

Pour formaliser les cas, il faut d’abord effectuer un diagramme de contexte. Ce schéma montrera les interactions entre le système (système informatique, processus…) et les autres "systèmes" (personnes, logiciels, machines, temps…). On placera ensuite les interactions entre le système étudié et son écosystème. Chaque interaction est définie comme un cas d’utilisation et est déclenchée par un "événement déclencheur". On peut aussi considérer les systèmes connexes (humains et machines) comme la ou les raisons d’être du système étudié.

Les business cases peuvent vous aider à définir les parties prenantes fonctionnelles de votre système. Par exemple : "John de la compta se connecte au système…" vous permettra de définir les utilisateurs et leur rôle. Cela peut aussi être : "Le système...

Analyse de protocole et apprentissage

L’analyse de protocole et l’apprentissage sont des techniques de recueil des besoins par immersion. Si on devait transformer cette démarche en émission de télévision, elle se nommerait sûrement "Vis ma vie". Ces deux techniques sont complémentaires, l’une va apporter le point de vue d’un expert et la seconde se focalisera sur les questionnements et les frustrations d’une personne débutant dans le métier.

"Ce que nous devons apprendre à faire, nous l’apprenons en le faisant." - Aristote 

1. Présentation

Il s’agit pour l’analyste en charge du recueil des besoins d’aller sur le terrain pour observer les parties prenantes au travail, voire d’effectuer celui-ci directement.

L’utilisateur du futur système va se mettre dans la position du maître ou de l’expert, tandis que l’analyste incarnera l’apprenti.

L’analyse de protocole

La première étape sera celle de l’observation : l’analyse de protocole. L’analyste passera alors quelques heures à observer le travail de l’utilisateur. Il est essentiel de comprendre comment les décisions sont prises. Quelles informations sont utiles ? Pour quoi ? Dans quel but ? Quelles sont celles qui sont chronophages ? Comment elles sont agrégées, compilées ?

Cette première étape permet de découvrir le métier et les problèmes d’une personne souvent expérimentée dans son domaine. Elle permet d’avoir des détails sur les habitudes des utilisateurs...

Introspection

Cette technique est à la fois simple à mettre en place, elle peut être très performante, mais aussi risquée. On va parler de stars, de siestes, de promenades et de cafés.

1. Présentation

Vous est-il déjà arrivé de trouver une solution sous la douche, au réveil, à la pause-café ? Oui, alors vous avez utilisé cette méthode.

Edisson et Dali l’utilisaient déjà (oui, vous pourrez donc prétendre au génie !). Ils réfléchissaient à un sujet, puis le premier allait dormir sur une chaise avec un boulet de canon dans la main, tandis que le second allait à la sieste avec une clé accrochée à un fil. Lorsque cet objet tombait sur le carrelage, cela les réveillait et ils utilisaient ces idées provenant d’un demi-sommeil pour être créatifs.

Chouette ! C’est la méthode qui prône la sieste, les pauses-café, et les promenades.

Loin d’être juste une utopie, cette méthode est basée sur la neuroscience (tout de suite c’est moins drôle). Le cerveau à plusieurs états, dont deux qui nous intéressent ici : le mode "concentré" (focus en anglais) et le mode diffus.

L’état "concentré" est celui dans lequel vous vous trouvez...

Analyse du domaine technique

L’analyse du domaine technique est l’analyse des applications et systèmes existants. Ils constituent une mine d’informations fiables, mais dans laquelle il est facile de se perdre.

1. Présentation

On parle ici de reengineering, il s’agit de déterminer les règles de gestion de la solution existante en observant les systèmes, les scripts, les SLA, les documentations techniques, la sécurité, les données, les rapports et les exports.

Chacune de ces sources d’informations ne pourra vous en donner que sur la solution existante et chacune d’entre elles disposera d’informations particulières. Une donnée étant (la plupart du temps) la trace numérique d’un process métier (ou d’une absence de process), regarder les informations liées à cette donnée vous informera sur le process métier, mais aussi celui technique supportant le premier.

Les systèmes : en observant et comprenant l’urbanisation des systèmes vous pourrez en déduire des informations telles que la fréquence de rafraîchissement de données, l’heure de disponibilité, les scopes de chaque système, les dépendances en amont et en aval. Une dépendance en amont est un système dont votre solution dépendra. Une dépendance en aval est un système...

Prototypage

Ou plutôt, les prototypes. Il en existe plusieurs sortes et chacune a des usages différents. Ils ont l’avantage d’être visuels et concrets pour les parties prenantes fonctionnelles.

1. Présentation

Une démarche, s’apparentant au reverse-engineering, est utilisée lors d’un prototypage. On part ici d’une solution même simpliste pour créer le cahier des charges.

Cette démarche est particulièrement utile dans plusieurs cas.

  • Si votre solution n’existe pas, qu’il n’y en a pas d’analogue et que vos parties prenantes fonctionnelles peinent à imaginer la solution finale.

  • Si vos parties prenantes n’ont pas d’expérience dans la formalisation de besoins, sont bloquées à certaines étapes.

  • Si vous n’avez pas d’analyste ou qu’il a des difficultés à articuler le besoin, si la faisabilité du projet est en question.

Il est risqué de proposer un prototype lorsque les parties prenantes ont des habitudes très ancrées et que la proposition est éloignée de l’existant. La comparaison de l’existant et de la future solution risque de les déstabiliser.

Il existe quatre types de prototype : le prototype conceptuel, les prototypes basse fidélité, moyenne fidélité et haute-fidélité. Venant de l’anglais, les trois derniers sont aussi appelés : low-fi, medium-fi et high-fi.

Le prototype conceptuel : on parle ici de dessiner un schéma au tableau ou sur papier pendant que la négociation s’établit. Préparer des feutres ou des crayons de couleurs peut être...

Analyse du domaine

L’analyse du domaine est souvent oubliée lors des projets, elle peut être très fructueuse, voire obligatoire dans certains projets. Les besoins issus de cette analyse sont en général de très bonne qualité.

1. Présentation

Il faut d’abord définir "le domaine". Dans le recueil des besoins, il existe plusieurs "mondes" selon les recherches (Meta models for requirements engineering. Matthias Jarke, R.Dömges, S.Jacobs, H.W.Nissen, K.Pohl (RWTH Aachen, Germany, coordinating partner) ; N.Maiden, A.Sutcliffe, C.Taylor, D.Till (City University, London, UK) ; P.Constantopoulos, G.Spanoudakis, Y.Vassiliou (FORTH Heraklion, Greece) ; G.Grosz, V.Plihon, C.Rolland, J.R.Schmitt, S.Schwer, S.Si-Said, C.Souveyet (Universite Paris-Sorbonne, France), J.Bubenko, R.Gustas, P.Holm, P.Johannesson, J.Ljungberg, B.Wangler (SISU Stockholm, Sweden) Informatik V (Information Systems), RWTH-Aachen 52074 Aachen, Germany).

Il existe le monde de l’usage, celui du sujet (ou domaine) et le monde du système.

Commençons par décrire brièvement le monde de l’usage et du système. Le monde du sujet paraîtra alors plus clair.

Le monde de l’usage est le contexte dans lequel la solution étudiée devra s’intégrer. Il prend en compte les acteurs, les parties prenantes, les systèmes connexes, les tâches, les procédures et processus, mais aussi la politique de l’entreprise (temps, budget, ressources). C’est là qu’on tente d’atteindre les objectifs de l’organisation, c’est souvent ce que le reporting va mesurer. On parle ici du besoin fonctionnel, métier et des parties prenantes non techniques. Exemple : les vendeurs, les ventes, les processus métiers…

Le monde du système est le monde des spécifications techniques et du produit qui devra être livré....

Approche par objectifs

L’approche par objectifs ou par buts est l’une des plus adaptées aux projets décisionnels. Elle peut paraître complexe à mettre en place, mais elle permet d’ancrer les besoins, facilite l’alignement du système d’information décisionnel et limite le changement de scope. À noter que ce chapitre est fortement lié aux chapitres "Activités de recueil des besoins - Analyse du domaine" et "Activités de recueil des besoins - Analyse syntaxique et grammaticale".

1. Présentation

Qu’est-ce qu’un but ? D’après Axel van Lamsweerde "l’ingénierie des besoins s’intéresse aux buts à atteindre par le système considéré, à l’opérationnalisation de tels buts comme services et contraintes, à l’assignation des responsabilités aux agents qu’ils soient humains, logiciels ou matériels".

Il existe différentes méthodologies analysant le besoin grâce à l’approche par buts. Ce chapitre expliquera les grandes lignes, la philosophie de la méthode. Certaines méthodologies sont expliquées en détails dans le chapitre Méthodes de modélisation - Approche par objectifs, et Méthodes de modélisation - EKD.

Pour plus de clarté, établissons une convention. Même si les termes "objectif" et "but" peuvent être utilisés indifféremment, dans le cadre de ce chapitre nous utiliserons "but" lorsque nous parlerons du concept de l’approche, sinon nous utiliserons "objectif".

Ces différentes méthodologies ont pour vocation de définir...

Analyse syntaxique et grammaticale

L’analyse syntaxique a pour but de supprimer les ambiguïtés et de vérifier que le besoin est bien compris par tous sans quiproquo.

"Mal nommer les choses c’est ajouter au malheur du monde." - citation apocryphe d’Albert Camus

1. Présentation

Les parties prenantes exprimeront le besoin en langage naturel. Le langage naturel est le moyen de communication habituel entre humains, quelle que soit la langue. Les communications sont alors basées sur une série de suppositions telles que : "le mot que j’emploie a le même sens pour mon interlocuteur", "l’autre comprend le raccourci que je viens de faire, car ce sujet a déjà été abordé", "ai-je la connaissance technique, technologique, métier, etc. nécessaire pour comprendre ce que mon interlocuteur dit ?", "il a perçu l’ironie/l’exaspération dans mon propos".

Voici les bases de nombre de quiproquos : la plupart du temps nous ne nous les relevons même pas, mais dans le recueil des besoins cela peut coûter cher.

Un exemple dans la publicité : vous vous souvenez sûrement de cette publicité pour Canal+ ou deux protagonistes discutent. Le premier décrit le film "La marche de l’empereur" avec plein d’empereurs qui marchent sur la banquise. Les images suivantes représentent les points de vue des deux protagonistes. Le premier décrit des manchots marchant sur la banquise tandis que le second pense à des empereurs Bonaparte.

Un exemple typique serait : "la solution devra présenter le nombre de ventes par type de clients." Qu’est-ce qu’une vente ? Pour le comptable ce sera certainement chacune des lignes sur la facture. Pour le gestionnaire de la relation client, ça sera plusieurs produits, mais un seul client. Le responsable produit verra le nombre de produits vendus, peu importe le nombre de clients… et que dire si le processus implique un paiement différé, si c’est un système d’abonnements…

Le problème est tellement criant qu’il existe dans certains domaines un framework. C’est le cas du SATC, utilisé par la NASA pour valider les besoins.

Cependant il existe donc des moyens...

Pensée systémique

La pensée systémique est applicable à de nombreux stades du projet. Elle ne constitue pas une technique de formalisation des besoins à proprement parler, mais améliorera grandement la qualité de la solution considérée.

"La connaissance progresse en intégrant en elle l’incertitude, non en l’exorcisant." - Edgar Morin

1. Présentation

La pensée systémique est une façon de percevoir la solution envisagée. Il s’agit de penser dans la globalité. On ne considère pas l’environnement et la solution séparément, mais la solution comme faisant partie intégrante d’un tout. L’environnement désigne une agrégation de systèmes avec différentes parties interagissant et avec des fonctionnalités différentes. L’environnement et la solution sont vus dans une interdépendance forte.

Voici plusieurs exemples issus ou non du monde décisionnel permettant de comprendre l’importance de cette démarche.

Prenons un exemple dans la médecine.

L’anatomie est la description de la structure du corps humain, de ses organes et de leur position. Le cerveau et le bras sont perçus comme deux parties différentes avec des caractéristiques séparées. L’approche systémique considérera que le bras n’a pas de raison d’être sans un cerveau pour envoyer les ordres de mouvements et, vice-versa que le cerveau n’a pas de raison d’être sans un membre pour traduire le signal électrique en mouvement.

Un exemple dans la définition des KPI.

Cet exemple provient d’une étude réalisée par le fond monétaire international (IMF Working Paper - "Does ‘Grease Money’ Speed Up the Wheels of Commerce ? - Prepared by Daniel Kaufmann and Shang-Jing Wei - Authorized for distribution...

Brown cow model

Le modèle de la vache brune pour ceux qui sont à cheval (ou à vache) sur le français (et nos amis québécois). C’est un modèle utile pour dissocier le besoin fonctionnel et technique. Il permet de faciliter la conversation entre les différentes parties prenantes dans un projet où la gestion du changement est importante.

1. Présentation

D’accord ! Je vous dois une explication à propos du nom. Il vous manque tout d’abord des informations.

Le modèle Brown Cow dispose de quatre cadrans. Il sépare l’actuel et le futur, le quoi du comment. Cela va permettre assez simplement de différencier les besoins fonctionnels des spécifications techniques, mais aussi va dépolluer les conversations des habitudes passées. Ici on chasse le fameux : "on fait comme ça depuis toujours…" . Ça marche bien pour limiter la reproduction des faiblesses et des incohérences de l’ancien système.

images/CH5V12.png

Brown-Cow Model (Modèle de la vache brune)

L’importance de la séparation entre le QUOI et le COMMENT.

En faisant une distinction claire entre le besoin technique et le fonctionnel, vous laissez la possibilité d’envisager différentes options d’implémentations. Cela sera d’autant plus utile si l’entreprise est très centrée...

Tableau comparatif

Approche collective

Approche individuelle

Complexité de mise en place

Quand choisir cette option

Workshop

X

X

Faire émerger une solution collective Collaboration facile

Interviews

X

X

Collaboration difficile Travail préparatoire Analyste formé

Delphi

X

X

XXX

Collaboration difficile Influence de l’une des parties prenantes (expérience, niveau hiérarchique sexe, culture…)

Brainstorm

X

X

Faire émerger une solution collective Collaboration facile Créativité nécessaire

Design Thinking

X

X

Définition de l’interface Sentiments utilisateurs importants

Thermomètres

X

X

Process métiers bien définis Définition d’une base pour les métriques Indisponibilité des parties prenantes fonctionnelles

Groupe collaboratif

X

XX

Faire émerger une solution collective Collaboration facile Méthodes agiles

Cas d’utilisation métier et scénarii

X

XX

Définitions des process métier Reporting opérationnel.

Analyse de protocole et apprentissage

X

XX

Parties prenantes fonctionnelles peinant à expliciter leur besoin Peu de changement dans les process opérationnels Connaissance tacite

Introspection

X

X

Analyste expert du domaine. En complément avec d’autres méthodes

Analyse du domaine technique

X

XX

Architecture existante déjà en place Structures techniques plutôt organisées et documentées...