Comment transmettre des besoins métier ?


Pour une Direction métier, la gestion du système d’information est une affaire plus ou moins opaque confiée à des spécialistes. Généralement, cette activité est qualifiée au travers de quatre indicateurs : efficacité, productivité, rentabilité et alignement stratégique.


En ce qui concerne le premier, une des principales mesures à considérer est l’adéquation du système d’information avec les besoins métiers. Pour se faire, les besoins métiers doivent être connus des acteurs SI, assimilés par ceux-ci et intégrés dans le système d’information.

La communication entre les Directions métier et les acteurs SI est donc un enjeu fondamental pour l’efficacité du système d’information de l’entreprise.


Plusieurs caractéristiques ne favorisent pas la fluidité des échanges : les Directions métier et la DSI évoluent dans des mondes spécifiques (vocabulaire, références,…), poursuivent des objectifs différents, sont dans une relation d’interdépendance dans laquelle l’un est le fournisseur exclusif de l’autre avec toutes les contraintes que cela implique (dépendance opérationnelle, dépendance économique).

La question est donc ouverte : comment transmettre efficacement des besoins métier à une DSI ?


Mes réponses à cette question s'appuient sur un parcours professionnel transverse : j’ai débuté dans la réalisation d’applications, pour, ensuite, me spécialiser dans l’analyse fonctionnelle, évoluer vers le pilotage opérationnel de projet et, enfin, aboutir comme consultant en système d’information. Ce parcours spécifique me permet de maîtriser les us et coutumes des différents intervenants et, ainsi, d’adapter ma communication.


Pour transmettre efficacement des besoins métier à une DSI, je pense qu'une Direction métier doit suivre sept principes :


  • Donner tout le contexte

  • Montrer la réalité opérationnelle

  • Transmettre les demandes

  • Prioriser les demandes

  • Comprendre la solution

  • Suivre le projet

  • Accepter le changement

Donner tout le contexte

Pour assimiler des besoins métier, je crois nécessaire d’appréhender le contexte métier dans lequel ceux-ci sont énoncés :

  • Principales missions de l’entreprise

  • Organisation de l’entreprise

  • Principales missions des entités de l’entreprise

  • Entité(s) concernée(s) par le projet

  • Cartographie des processus métier

  • Processus métier concerné(s) par le projet

  • Activité(s) concernée(s) par le projet

  • Acteur(s) concerné(s) par le projet

La description des quatre premiers points peut paraître inutile pour des interlocuteurs SI appartenant à l’entreprise au motif que ceux-ci doivent connaître ces informations. Toutefois, l’expérience montre que les membres d’une DSI qui s’intéressent aux métiers de leur entreprise, y compris ceux qui font partie de leur périmètre d’intervention, ne sont pas légion.

De même, cette description peut paraître inutile pour des intervenants externes qui s’intéressent avant tout aux questions informatiques et ne montrent pas d’intérêt particulier pour ce genre d’informations contextuelles.

Pourtant, derrière les questions d’organisation, de missions, de liens hiérarchiques et opérationnels se dessine une trame dans laquelle doit s’inscrire le système d’information. Une connaissance, même macroscopique, du contexte métier permet aux interlocuteurs SI de se faire une idée de la dimension de l’outil à réaliser.

| | | Retour d’expérience


Une entreprise gérant des millions de clients a demandé la construction d’un outil de pricing pour gérer un segment de clientèle spécifique.

Le segment de clientèle ne concernait que quelques milliers de clients, mais représentait 45% du chiffre d’affaires. De plus, l’entité en charge de ce segment clientèle se nommait « Domaine individualisé » (par opposition à une autre entité nommée « Domaine standard »).


En tenant compte du nombre de clients concernés et du nom de l’entité, il fallait donc s’attendre à un périmètre fonctionnel réduit, mais très dense, constitué non pas d’un cas nominal et de quelques exceptions, mais plutôt d’un process complètement ouvert laissant une complète liberté aux utilisateurs, utilisateurs qui se sont avérés être des spécialistes pointus et très exigeants.

La connaissance des quatre derniers points est indispensable dans le sens où les processus métier donnent une vision structurée des métiers de l’entreprise :

  • Description : acteurs, périmètre, finalités, enjeux

  • Eléments clés : entrées, sorties, exigences, risques, indicateurs de performance

  • Activités : séquencement, description, entrées, sorties

  • Indicateurs de pilotage

De plus, dans les entreprises se prévalant d’une certification ISO, cette vision est opposable : elle est partie intégrante du référentiel métier.

Montrer la réalité opérationnelle

Il faut bien avoir à l’esprit que les processus métier, même s’ils constituent une référence, ne décrivent pas une réalité opérationnelle. Ils ne constituent que le cadre « légal » (au sens des règles internes de l’entreprise) dans lequel doivent se réaliser les activités.


Pour les acteurs SI, il est indispensable de prendre contact avec la réalité opérationnelle, et ce pour les raisons suivantes :

  • Rien ne vaut une vision de la « vraie vie » pour appréhender toute la portée, explicite ou implicite, d’une demande

  • Prendre contact avec une réalité opérationnelle implique des moments d’échange privilégiés entre les différents interlocuteurs

  • Une plongée dans la réalité opérationnelle permet de confronter les pratiques avec les nouveaux usages informatiques


| | | Retour d’expérience

Une entreprise souhaitait mettre en place une application permettant de recueillir, consolider et valider des données provenant de partenaires étrangers. Ces données étaient des séries temporelles d’une profondeur d’une journée, à des pas horaire et demi-horaire.

Au vue de la description des activités dans le processus métier, le besoin consistait « simplement » à réaliser des calculs arithmétiques (addition, soustraction) et des opérations logiques (comparaisons) sur des séries temporelles, puis à présenter les résultats.


Une immersion dans la réalité opérationnelle a montré que la réalisation de cette activité était séquencée par des « guichets » ouverts nuit et jour, 7 jours sur 7, que les éventuels écarts se réglaient en direct par téléphone avec les partenaires étrangers.

En tant qu’acteur SI, ma projection de la solution à réaliser a pris une nouvelle dimension quand il a fallu interagir à deux heures du matin, en mauvais anglais, avec un interlocuteur germanophone…


Pour partager une réalité opérationnelle, j’incite les interlocuteurs métier à s’investir dans une ou plusieurs des actions suivantes (classées par ordre croissant d’efficacité vu des interlocuteurs SI et d’investissement vu des interlocuteurs métier) :

  • Fournir de la documentation opérationnelle de type « procédure »

  • Présenter les outils utilisés en simulant des situations proches de l’opérationnel

  • Immerger les acteurs SI dans des situations opérationnelles

Transmettre les demandes

Une fois que les interlocuteurs SI ont pris connaissance du contexte métier et de la situation opérationnelle, le contenu fonctionnel doit émerger. Quels que soient la méthode de réalisation et le formalisme inhérent, à un moment ou un autre, les interlocuteurs métier doivent formuler leurs demandes.


Dans ce genre d’exercice, les trois défauts les plus courants sont les suivants :

  • Synthétisation : formulation contractée d’une demande contenant de l’implicite et des sous-entendus

  • Présentation d’une solution : description de ce que l’on souhaite obtenir plutôt que ce dont on a besoin

  • Autocensure : passage de demandes sous silence


| | | Retour d’expérience


Dans un projet de réalisation d’une application SI, une Direction métier souhaitait que tous les écrans, ou presque, de l’application présentent une fonction d’export des données dans des fichiers Excel. En demandant l’utilité d’une telle demande, je me suis vu répondre que c’était le seul moyen pour la Direction métier d’avoir accès à l’intégralité de ses données, ces dernières étant consolidées puis synthétisées « manuellement » afin de réaliser des tableaux de bord opérationnels.

En considérant un besoin de collecter, consolider et restituer des données dans le but d’avoir une vue d’ensemble de l’activité traitée ou d'offrir une aide à la décision, la solution était sûrement à trouver dans un outil d’informatique décisionnelle, et non dans une multitude d’exports spécifiques.


Pour formuler une demande complète, il faut effectuer les actions suivantes :

  • Décrire l’intégralité des pré-requis

  • Lister les acteurs concernés

  • Indiquer les objets métier impliqués

  • Décrire les cas nominaux

  • Décrire les cas d’exception

  • Identifier des résultats métiers, et non SI

Prioriser les demandes

Les acteurs SI dimensionnent l’application à réaliser et déterminent la démarche de réalisation en fonction des demandes. Pour obtenir un résultat optimal, les acteurs SI doivent disposer d’une liste exhaustive et priorisée des demandes.


En effet, la prise en compte de l’intégralité du périmètre fonctionnel permet aux acteurs SI de dimensionner fonctionnellement et techniquement l’application à réaliser.

| | | Retour d’expérience


Une entreprise souhaitait remplacer plusieurs applications partageant un socle de données communes. La démarche de réalisation choisie fut de réaliser une unique application par décommissionnement successifs des applications obsolètes. Dans cette démarche, chaque nouveau périmètre impacte les précédents, provoquant une charge croissante d’études d’impacts et de tests de non-régression.


La prise en compte de l ‘intégralité des demandes m’a permis de considérer le projet non comme la réalisation d’une application, mais plutôt comme la mise en place d’un système d’information composé d’un entrepôt de données partagées sur lequel devait graviter des applicatifs autonomes intégrant des périmètres fonctionnels non adhérents.


Une fois les demandes connues, les acteurs SI doivent déterminer un ordre de livraison. Celui-ci est fonction de critères divers et variés :

  • Priorisation métier

  • Pré-requis fonctionnels et/ou techniques

  • Considérations économiques

  • Etc.

Le premier est bien entendu essentiel pour les acteurs métier. Pour le définir, je conseille d’attribuer deux notes à chaque demande : criticité de la demande, maturité de la demande, puis de les croiser pour déterminer un classement.

Comprendre la solution

Quels que soient la méthode de réalisation et le formalisme inhérent, dans tous les projets, les acteurs SI présentent la solution à leurs interlocuteurs métier avant ou pendant la phase de réalisation.


Pour les acteurs métier, il est indispensable de bien appréhender ce qui leur est présenté, et ce pour les raisons suivantes :

  • C’est la vision portée par les acteurs SI qui va être inscrite dans le futur outil et, de ce fait, impacter directement l’activité opérationnelle des acteurs métier

  • C’est bien souvent l’ultime moment où la prise en compte d’un changement coûte le moins, que ce soit en délai ou en budget :

  • une fois la réalisation terminée, il s’agit de défaire pour refaire

  • après la mise en production, on parle d’évolution avec étude d’impacts

  • Les architectures fonctionnelle et technique de la solution contiennent intrinsèquement, la capacité, ou l’incapacité, de la solution à répondre à de futures évolutions


| | | Retour d’expérience

Une entreprise souhaitait mettre en place une application permettant à une certaine catégorie d’utilisateurs d’exploiter des données de consommation énergétiques (collecte, consultation, modification, projection, export).


Une fois l’application mise en production, il m’a été demandé d’étudier la capacité de l’application d’intégrer une deuxième catégorie d’utilisateurs. Pour le demandeur, cette demande semblait légitime car les données concernées et les fonctionnalités souhaitées étaient quasi-identiques à celles proposées par l‘outil déployé. C’était sans tenir compte des échanges entre les deux populations, échanges qui étaient jusqu‘alors effectués par mail.


Pour intégrer cette demande, l’application aurait du évoluer très fortement en proposant des cycles de vie plus complexes pour ses objets, voire un workflow, ce qui n’était nativement pas envisagé.


Pour comprendre une solution SI, les acteurs métiers font face à trois difficultés majeures :

  • Différences « culturelles » : le vocabulaire et les références SI ne sont pas toujours accessibles aux acteurs métier

  • Divergences de vision : il existe souvent des divergences entre la vision métier et la vision applicative (hébergement de données métiers dans des concepts applicatifs polymorphes, réinterprétation d’algorithmes métier pour factorisation de traitements, etc…)

  • Méconnaissance technique : l'adéquation de la solution avec les besoins métiers actuels et futurs dépend beaucoup de paramètres techniques et technologiques qui sont mal connus des acteurs métier

De mon point de vue, ces difficultés ne peuvent être surmontées que par des acteurs métier « bilingues », c'est-à-dire des représentants métier qui connaissent les langages et les cultures des deux parties.

Suivre le projet

Tous les professionnels du SI sont unanimes pour dénoncer l’effet tunnel, c'est-à-dire les périodes pendant lesquelles le donneur d’ordre reste aveugle quant à la progression du projet. Au premier abord, les acteurs métier peuvent se sentir soulagés d’éviter les tâches ingrates comme le suivi d’indicateurs difficilement interprétables, la prise en compte d’alertes techniques obscures mais sûrement très pertinentes. De même, cet isolement peut être considéré, par les acteurs SI, comme une sanctuarisation de leurs activités favorisant leur productivité. Toutefois, cet isolement implique de découvrir l’intégralité du périmètre réalisé, avec ses éventuelles dérives, en toute fin de phase. Dans ce cas, devant le fait accompli, le donneur d'ordre n’a pas d’autre choix que de tout accepter ou de recommencer. C’est pour éviter cela que je recommande fortement aux acteurs métier de suivre leurs projets.


Aux indicateurs classiques (prévisionnel, consommé, reste à faire) doivent s’ajouter des points d’étape mettant en visibilité :

  • Les grands principes ergonomiques de l’application

  • Des traitements à la complexité croissante ou décroissante selon la stratégie définie

  • Des données réelles, reprises ou créées

  • Une intégration plus ou moins aboutie avec le reste du SI


Quant aux informations techniques, les acteurs métier doivent s’en préoccuper même si elles sortent de leur périmètre de compétence. Les acteurs métier « bilingues » doivent posséder des connaissances techniques suffisantes pour en décrypter les impacts et les conséquences.


Cette démarche permet

  • De construire l’application de manière itérative et non selon un mode « tout ou rien »

  • De considérer la construction de l’application en se basant sur des résultats et non sur des promesses

  • De qualifier le résultat obtenu dans des conditions proches du réel

Accepter le changement

Quasiment tous les projets informatiques (refonte technique, refonte fonctionnelle, outillage d’un nouveau périmètre, etc.), impactent les procédures des Directions métier concernées.


Pour gérer ces impacts, les démarches les plus couramment mises en œuvre par les Directions métier sont les suivantes :

  • Anticiper les impacts en définissant soi-même la solution à développer

  • Identifier les impacts à la livraison de l’application

  • Identifier les impacts en utilisant des points d’étape


La première démarche paraît la plus sécurisante car elle réduit les dépendances. Pourtant, cette démarche n’est pas recommandée. En effet, présenter une solution à des acteurs SI et non un besoin conduit à des malentendus fonctionnels et à des problèmes techniques :

  • Mauvaise utilisation de concepts technico-fonctionnels

  • Conception fonctionnelle minimaliste

  • Méconnaissance de la dimension technique du SI

A trop vouloir sécuriser leurs activités, les acteurs métier risquent d’obtenir une application non opérationnelle.


Les acteurs métier doivent donc accepter qu’un outil conçu et réalisé par leurs interlocuteurs SI fassent évoluer leurs procédures. Toutefois, cette acceptation ne doit pas se transformer en aveuglement. Je déconseille donc d’attendre la livraison de l’application pour se préoccuper de ses impacts opérationnels. Un changement ne s’improvise pas, ni ne se réalise efficacement sous la pression.


Comme vu précédemment, l’implication des acteurs métier dans le suivi d’un projet permet à ceux-ci de considérer l’avancement de la réalisation au travers de points d’étape. Ces points d’étape peuvent aussi être utilisés par les acteurs métier pour anticiper les impacts sur leurs activités. Ainsi le projet de réalisation SI entre en convergence avec la démarche de transformation métier.


#Donnertoutlecontexte #Montrerlaréalitéopérationnelle #Transmettrelesdemandes #Prioriserlesdemandes #Comprendrelasolution #Suivreleprojet #Accepterlechangement

Article à la une
Articles récents
  • LinkedIn - White Circle

crédits photo : © laliejeanne photographie