Actualités : analyse de données, Business Intelligence, Data Science, Big Data


Analyse des besoins en contexte BI : des besoins différents et des techniques appropriées


Rédigé par Manon G. Guillemette, Université de Sherbrooke le 13 Février 2012

L’identification des besoins est critique pour le succès de tout projet TI. Des études ont démontré que les deux tiers des échecs des projets étaient attribuables à des besoins non définis ou mal définis. Les erreurs non découvertes avant l’implantation peuvent faire augmenter le coût du projet de manière exponentielle. Cependant, on remarque depuis un certain temps que cet aspect des projets est pris plus au sérieux. L’analyse des besoins prend de plus en plus d’importance et des regroupements de professionnels approfondissent des méthodes et des techniques dans le but de mieux outiller les analystes d’affaires. D’où l’expansion de l’IIBA® et la publication du guide « Business Analysis Body of Knowledge (BABOK®) ».



Manon G. Guillemette, Professeure agrégée à l'Université de Sherbrooke (Photo Copyright Salon BI)
Manon G. Guillemette, Professeure agrégée à l'Université de Sherbrooke (Photo Copyright Salon BI)
Traditionnellement, un besoin ou une exigence d’affaires est défini comme « quelque chose que le produit doit faire ou une qualité que le produit doit avoir ». Mais encore faut-il qu’il puisse ajouter de la valeur et être utile à ses utilisateurs.

En contexte d’intelligence d’affaires (ou le BI pour business intelligence), l’analyse des besoins prend un tout autre sens. Penser que la définition des besoins en intelligence d’affaires se fait de la même façon que pour les projets TI traditionnels est une méprise encore fréquente et dommageable. Tel que démontré dans le billet précédent intitulé Y a-t-il vraiment une différence entre les projets BI et les projets TI ?, l’intelligence d’affaires est beaucoup plus orientée sur les affaires que sur la technologie. Les environnements d’intelligence d’affaires sont motivés et justifiés par les occasions d’affaires et non pas par des besoins d’opérationnalisation ou d’automatisation. Dans ce contexte, il est surprenant de voir que certains analystes veulent encore aujourd’hui utiliser les mêmes méthodologies ou techniques de la même façon.

Les spécialistes BI s’accordent pour dire qu’il est bien plus difficile de recueillir les besoins en intelligence d’affaires qu’en TI parce que la nature du travail d’un décideur est plus intuitive et difficile à cerner. Les besoins sont souvent peu précis, confus, non-connus ou volatiles. Cela force les analystes d’affaires BI à concentrer leur attention sur l’identification de l’information nécessaire au gestionnaire, et sur les meilleures façons de leur présenter celle-ci. Pour y arriver, ils ont recours à des méthodologies et des techniques bien adaptées à ces besoins changeants qui évoluent souvent très rapidement.

C’est sur cette prémisse que nous avons réalisé une étude de l’efficacité des techniques de définition des besoins en contexte d’intelligence d’affaires. Ainsi, la définition des besoins se fait à l’intérieur d’un processus évolutif et itératif, qui s’appuie sur des techniques mieux adaptées à ce contexte. La découverte, l’analyse et la validation des besoins sont les trois étapes d’un processus itératif ou chaque itération sert à définir les besoins ou faire ressortir de nouveaux besoins, tout en tenant compte des niveaux organisationnels impliqués. En effet, les besoins en intelligence d’affaires se définissent à trois niveaux : stratégiques, organisationnels et applicatifs. Ainsi, au niveau stratégique, les analystes définissent la vision des hauts dirigeants et identifient les objectifs stratégiques de l’entreprise. Le niveau organisationnel permet aux différents gestionnaires d’uniformiser leur compréhension de la nature des données et d’harmoniser les besoins transversaux aux unités d’affaires. Finalement, le niveau applicatif est celui qui se rapproche le plus des besoins particuliers à chaque unité d’affaires. C’est à ce niveau que gestionnaires et experts d’affaires procéderont à la validation de la disponibilité et de la qualité des données afin de confirmer la faisabilité du projet. Il est toujours utile de rappeler que la qualité et la compréhension des données sont primordiales à la qualité de la solution.

Chaque itération du processus de définition des besoins devra être rapide. Attendre trop longtemps avant de revenir vers l’utilisateur risque de briser le rythme, sans compter que le besoin risque d’avoir changé. Chaque itération pourra nécessiter également un ensemble de techniques différentes. Chose certaine, l’utilisation d’un support visuel est primordiale en intelligence d’affaires. C'est pourquoi la technique du prototypage sera grandement utilisée et efficace lors de la validation des besoins au niveau applicatif. Aux niveaux stratégique et organisationnel des maquettes ou des exemples de tableaux de bord seront très utiles pour la compréhension et la stimulation des idées.

Certains diront qu’une technique est bonne autant en intelligence d’affaires qu’en TI. Certes, mais ce n’est pas toujours le cas! De plus, son utilité et son efficacité différeront grandement selon le contexte. Comme les dirigeants ont besoin d’information pour identifier les problèmes et identifier des opportunités, les méthodes et techniques de définition des besoins doivent être orientées vers les données (information) plutôt que sur les processus d’affaires. Certaines techniques sont nettement mieux adaptées à ceci que d’autres.

Alors que l’utilité et l’efficacité des techniques de cartographie de processus, des scénarios et cas d’utilisation et d’observation ne sont plus à vanter en contexte transactionnel, elles s'avèrent souvent inefficaces et peu utiles en intelligence d’affaires. Les techniques vraiment efficaces en BI sont celles orientées sur la modélisation de données, l’identification des indicateurs de performance (KPI), les approches orientées vers les buts (goal modeling), la définition d’une grille stratégique (strategic mapping) et le prototypage. Quant à l’observation, c’est une technique plutôt complexe à utiliser en intelligence d’affaires. Ne vous méprenez pas, observer un gestionnaire est plus facile à dire qu’à faire et n’est pas nécessairement efficace puisque c’est souvent bien trop long. D’un autre côté, les techniques de groupes telles que le remue-méninge (brainstorming), les ateliers (requirements workshops), et la conception d’application conjointe (JAD) ,où l’échange d’idées et la créativité sont préconisés, s’avèrent très efficaces pour l’analyse des besoins en intelligence d’affaires.

Encore une fois, les professionnels TI et les analystes d’affaires qui évoluent en BI se doivent de revoir leurs méthodes pour les adapter au contexte d’intelligence d’affaires. Tout comme nous, vous avez manifesté un intérêt marqué pour la définition des besoins en BI lors de notre sondage sur la formation. Ceci nous a permis au Salon BI 2011 de vous offrir une journée complète de formation sur le sujet.

Sylvie Fréchette, M.Sc., Conseillère en intelligence d’affaires, Services conseils SF, Membre du comité organisateur du Salon BI 2011
Manon G. Guillemette, Ph.D., professeure agrégée à l’Université de Sherbrooke et directrice du Pôle de recherche en intelligence stratégique et multidimensionnelle d'entreprise (PRISME).

Rejoignez sur LinkedIn le groupe animé par Manon G. Guillemette : Stratégie de l'Intelligence d'Affaires




Commentaires

1.Posté par Alain GUERCIO le 29/02/2012 11:44
Bonjour Manon,

En France, la profession utilise plus souvent le terme de Maître d'Ouvrage de SI (MOA) que l'appellation Business Analyst (BA). C'est un héritage de la Méthode Merise (1980), un concurrent de méthodes anglo-saxonnes comme SADT … Notez qu'à cette époque, la polémique existait déjà entre les pratiquants qui privilégiaient les données et les autres qui privilégiaient les traitements ;-)

Je suis d'accord avec vous pour dire que la compréhension et la qualité des données sont les premières priorités du BI. Vous avez aussi raison de dire qu'il est plus simple de formaliser un processus que d'assurer l'adéquation entre la présentation des informations et les représentations mentales de chaque décideur.

Si on ne peut pas utiliser les mêmes techniques de modélisation de la même façon, il me semble opportun de ne pas (trop) opposer le BI et l'analyse des processus pour au moins trois raisons.

La première est que l'étude des données reste souvent nécessaire pour le BA, y compris dans le contexte d'un progiciel (de type SAP) et notamment lors des analyses de processus transverses à plusieurs métiers.

La seconde raison provient du constat qu'une masse importante (en volume et en diversité) des informations manipulées par le BI provient des SI opérationnels conçus par le BA. La qualité de la formalisation du BA influe significativement sur la compréhension et la qualité des données sources, donc sur la performance du BI. Nous parlons bien de capital immatériel et de transfert de connaissances BA/BI.

Enfin, l'approche systémique des organisations distingue – pour mieux les relier - le système opérant et le système de décision. Les décisions prises grâce au BI ne doivent-elles pas avoir un impact sur l'exécution des processus ? Comment met-on en œuvre cette boucle vertueuse de rétroaction ? N'est-ce pas l'objectif ultime d'une organisation agile ? Je reste à votre disposition pour en parler.

L'appellation Business Analyst et les bonnes pratiques du BABOK sont encore peu pratiquées en France. Au sein d'IIBA-France, nous sommes convaincus que la professionnalisation des MOA passe aujourd'hui par des échanges plus larges sur leurs pratiques avec leurs pairs, en local et à l'international. Venez donc nous rejoindre !

Alain Guercio
Consultant-Associé d'e-media management et membre d'IIBA-France

Nouveau commentaire :
Twitter

Vous pouvez commenter ou apporter un complément d’information à tous les articles de ce site. Les commentaires sont libres et ouverts à tous. Néanmoins, nous nous réservons le droit de supprimer, sans explication ni préavis, tout commentaire qui ne serait pas conforme à nos règles internes de fonctionnement, c'est-à-dire tout commentaire diffamatoire ou sans rapport avec le sujet de l’article. Par ailleurs, les commentaires anonymes sont systématiquement supprimés s’ils sont trop négatifs ou trop positifs. Ayez des opinions, partagez les avec les autres, mais assumez les ! Merci d’avance. Merci de noter également que les commentaires ne sont pas automatiquement envoyés aux rédacteurs de chaque article. Si vous souhaitez poser une question au rédacteur d'un article, contactez-le directement, n'utilisez pas les commentaires.


Twitter
Rss
LinkedIn
Facebook
Apple Podcast
App Store
Google Play Store