Apprendre a piloter et manager un projet : performance et benchmarking du systeme d’information

Apprendre à piloter et manager un projet : performance et benchmarking du système d’information

…

4Gestion budgétairemauvaises pratiqueset pièges à éviter

Objectif

L'objectif de ce chapitre est de détailler les mauvaises pratiques en matière de gestion budgétaire. Parmi les mauvaises pratiques qu'il convient de combattre : l'oubli du volet stratégique, la difficulté de concevoir des budgets annuels dans un cadre stratégique nécessairement pluriannuel, le flou dans le calcul du retour sur investissement, les confusions dans les périmètres des budgets, la question du partage des responsabilités... Pour chacune de ces mauvaises pratiques, ce chapitre propose des pistes de solutions.

4.1 L'ÉTAT DES LIEUX

Les temps sont durs. Les DSI doivent, plus que jamais, démontrer leur capacité de gestionnaire. Le temps des augmentations à deux chiffres des budgets informatiques, sans grande justification, semble révolu. Ce qui est vrai pour l'informatique, ne l'est pas forcétnent pour le nutnérique où des budgets conséquents sont alloués. Malheu­reusement, ce n'est pas toujours la DSI qui en hérite, devancée par le Marketing ou autant. Au contraire. Comment réaliser le grand écart entre des ressources souvent attendues en diminution, et des besoins en augmentation ? Un beau dilemme.

Le budget est en général la conséquence d'un processus de planification stratégique qui définit à la fois :

• la vision à moyen-long terme,
• les objectifs,
• les orientations,
• la cible, se traduisant par :

des activités à assurer, des projets,

—       une organisation,

—       des ressources.

La gestion budgétaire est donc l'expression d'un processus d'allocation et de contrôle des moyens financiers mis en oeuvre par une entreprise pour gérer son fonctionnement et piloter ses actions de modernisation.

Au départ, un budget d'entreprise est nécessairement prévisionnel. Il doit être en général équilibré avec une colonne de charges et une colonne de produits. Le budget prévisionnel résulte de la prévision des charges (les dépenses) et des produits (les recettes) pour l'exercice à venir.

Il est généralement établi par exercice comptable. Il traduit en termes financiers l'ensemble des activités de fonctionnement et des projets de l'organisation. Ainsi, on distingue le budget de fonctionnement, qui couvre les charges de fonctionnement liées aux activités récurrentes, du budget d'investissement qui couvre les projets de modernisation de l'entreprise en incluant les évolutions réglementaires.

En matière de gestion budgétaire, la fonction informatique se heurte souvent aux incompréhensions suivantes de la part des décideurs d'entreprise, et plus particulière­ment des directions financières et des contrôles de gestion :

• une augmentation de son budget bien supérieure à la moyenne des autres fonctions de l'entreprise, depuis plusieurs décennies ;
• une incompréhension sur l'utilité de ces nouvelles technologies de l'information et de la communication ;
• une incapacité à mesurer la contribution de l'informatique au fonctionnement et à la modernisation de l'entreprise ;
• une gestion en centre de coûts ;
• l'utilisation abusive de comparatifs sur des ratios de type : dépense informatique sur chiffre d'affaires, dépense informatique par employé, effectifs informatiques comparés aux effectifs totaux, etc.

4.2 LES MAUVAISES PRATIQUES

Au-delà des incompréhensions citées plus haut, plus d'une dizaine de « mauvaises » pratiques peuvent être identifiées en matière de gestion des budgets informatiques.

• L'oubli de la stratégie — Rappelons que le budget n'est pas une fin en soi, mais la conséquence d'un processus de planification stratégique tant pour les activités récurrentes que les nouveaux projets. Aussi, fixer arbitrairement un montant du budget informatique indépendamment des objectifs fixés, c'est ignorer, voire renier, la stratégie de l'entreprise et celle de la fonction informatique.
• Vision annuelle versus pluriannuelle — Découlant de la stratégie, forcément à moyen-long terme, les budgets, qu'ils soient de fonctionnement ou d'investisse­ment, ne peuvent pas être appréhendés sans une vision pluriannuelle.
• L'absence de bénéfices/recettes — Tout budget doit être en général équilibré avec une colonne de charges et une colonne de produits. Après la stratégie, les gains/recettes attendus sont les plus importants à considérer car ils permettent bien souvent de justifier les charges/dépenses pour l'exercice à venir. Ne pas le faire génère inéluctablement une logique de gestion de la fonction informatique en centre de coûts peu pertinente.
• Reconduction budgétaire aménagée — Bien souvent, le budget informatique de l'année n+1 est identique à celui de l'année n, à quelques modifications près correspondant à l'évolution des coûts unitaires et à la croissance de l'organisation. Ceci éclipse largement les aspects stratégiques et économiques, et entraîne bien souvent une cécité managériale sur les vrais enjeux informatiques. D'autres techniques existent telles que le BBZ (Budget à Base Zéro), qui consiste à « partir d'une feuille blanche » pour élaborer un budget. En outre, il a été démontré que la reconduction budgétaire avait une forte tendance à diminuer la part des projets par rapport aux activités de fonctionnement (maintenance, exploitation, service, etc.).
• Absence de corrélation entre budget informatique et budget métier — Les activités et projets informatiques introduisent des changements dans l'organi­sation et les processus métiers, et donc modifient le budget et les ressources nécessaires à ces processus. Leurs impacts sont en général de deux natures : revenus supplémentaires, coûts de gestion inférieurs et/ou apports qualitatifs. Ainsi, une nouvelle application ou un nouveau service va augmenter les coûts au niveau de l'informatique, qu'il s'agisse de coûts des infrastructures, des licences logicielles ou des services associés. Or, cette hausse des coûts est rarement mise en perspective avec les bénéfices apportés au métier. Il n'y a que rarement une vision transversale avec une logique de « vases communicants », ce qui devrait être le propre d'une fonction de support.
• Le périmètre du budget informatique amputé — Celui-ci est souvent réduit au périmètre de la fonction informatique, cc qui est particulièrement réducteur. En particulier dans les moyennes et grandes structures, le budget du département informatique ne représente qu'une partie de la dépense variant de 20 à 80 % selon les cas. N'avoir qu'une vision partielle est souvent la cause d'une gestion hétérogène avec des logiques de gestion non cohérentes globalement au niveau de l'entreprise.

• La non-considération de l'évolution des hypothèses entre la préparation-validation du budget et son exécution — Au départ, un budget est par définition prévisionnel. Particulièrement dans le cadre de la fonction informatique, avec l'évolution des technologies, mais aussi des besoins, il se trouve qu'entre le moment où le budget est préparé, plus d'un an à l'avance en moyenne, et le moment où les ressources sont consommées, le cadre peut changer. Ceci peut engendrer des problèmes au niveau du dimensionnement et de l'adéquation des ressources existantes.
• La confusion entre budget d'exploitation et budget de projet — La distinction « exploitation-projet » sépare les activités récurrentes de l'entreprise de l'en­semble des charges dédiées aux projets. Ceci est une bonne chose car ce sont à la fois des enjeux (récurrent versus nouveau), des périmètres (informatique versus métier) et des responsabilités (DSI, métiers voire DO) différents. Ne pas les distinguer peut s'avérer dangereux. De même, les budgets de projet sont dans une vision pluriannuelle forcément liés aux budgets de fonctionnement. Ainsi, un projet doit être corrélé dans le temps à une augmentation du budget de fonctionnement informatique.
• La confusion entre budget de fonctionnement et budget d'investissement — La notion « fonctionnement-investissement » est une vision comptable, limitant la part des projets à la partie amortissable. On en exclut les pré-études, la formation, l'installation ou la mise en exploitation, qui sont intégrées comptablement dans le budget de fonctionnement. La logique comptable et la logique gestion ne font pas forcément bon ménage.
• Les diminutions arbitraires — Dans le cas de restriction budgétaire, ce sont souvent les projets qui en font les frais. Or, n'oublions pas que les projets repré­sentent l'avenir. Arrêter les projets, c'est geler son processus de modernisation. Quand il s'agit de réduire les activités de fonctionnement, et donc la qualité de service rendu à l'utilisateur, il faut se poser la question si l'improductivité générée au sein de l'organisation (coûts cachés) n'est pas bien supérieure aux économies réalisées (coûts visibles). C'est bien souvent le cas.
• La responsabilité ambiguë des budgets informatiques — Pour ce qui est des infrastructures et autres services, le DSI est forcément responsable et redevable des dépenses. Pour ce qui est des nouveaux projets, à moins qu'il soit explicitement nommé maître d'ouvrage, ce n'est pas à lui d'en assumer la responsabilité globale, et de défendre ces budgets. On pourrait même étendre cette réflexion aux applications si l'on considère qu'elles sont la propriété des métiers.'

• L'utilisation de comparatifs ou benchmarks erronés — Ce sujet sensible amène bien souvent des difficultés et des décisions faussées en l'absence de pratiques rigoureuses et partagées.
• Le contrôle budgétaire — Bien souvent, ce contrôle est lié à la consommation des ressources durant l'année sans pour autant mettre les réalisations en perspective. De plus, il a également du mal à intégrer les évolutions de périmètre et se cantonne aux hypothèses fixées un an auparavant en moyenne. En cela, il est « autiste » et peu pertinent.

4.3 LES PISTES DE SOLUTION

En premier lieu, il faut conserver le lien avec la stratégie et établir la transparence sur l'ensemble des budgets, de manière dynamique : de l'élaboration à l'exécution du budget. Il est vital de considérer la totalité des dépenses informatiques et ne pas se focaliser uniquement sur celles du département informatique, afin d'assurer une unité de gestion. Cette étape ne peut se faire sans considérer la valeur induite au niveau des métiers, sous peine de tomber dans une logique de centre de coûts, forcément réductrice. C'est une condition sine qua non d'équilibre. À minima, les actifs de nature informatique, présents au bilan, devraient être suivis.

Puis, il faut à la fois distinguer à court terme le budget de fonctionnement du budget de projets, même si dans une vision pluriannuelle à moyen-long terme, le lien entre les projets et les dépenses futures de fonctionnement doit être établi.

En résumé

Sans rappeler tous les travers mentionnés plus haut, il est clair qu'une gestion performante des budgets informatiques est caractéristique du niveau de maturité managériale de l'entreprise en matière de systèmes d'information. Aussi, nous recommandons avant toute chose de réaliser une revue ou un diagnostic des bonnes pratiques en matière de gestion budgétaire informatique afin de sensibiliser tous les acteurs de l'organisation sur les véritables enjeux liés aux systèmes d'information, ce qui permettra de mieux utiliser le levier informatique pour améliorer la performance actuelle et future de son entreprise.

5 Principes de constructiondu tableau de bordde la DSI

Objectif

L'objectif de ce chapitre est d'expliquer les principes de construction d'un tableau de bord efficace, en distinguant les propriétés du contenu (le fond) et les propriétés du contenant (la forme). Cinq approches sont détaillées : l'approche « cybernétique », l'approche « systémique », l'approche de l'« administration américaine », l'approche « fonctionnelle » et l'approche de « l'audit ».

5.1 QUE DOIT APPORTER UN BON TABLEAU DE BORD ?

Les bénéfices des tableaux de bord sont nombreux : gérer, contrôler, anticiper. La question n'est pas de justifier leur légitimité, mais plutôt de comprendre pourquoi certaines organisations n'ont pas de bons tableaux de bord ou de piètres copies plus

7.7 proches du rapport d'information que d'un véritable outil de pilotage.

.. P.

li  Il est difficile d'imaginer la fonction managériale sans instrumentation de gestion.

À moins d'avoir une vision très artisanale des activités professionnelles. Cela a

^-2   peut-être un sens dans les domaines artistiques ou individuels, mais pas dans une

C    organisation qui se veut être au service de l'actionnaire ou de la communauté sans

o  oublier ses salariés.

5.2 STRATÉGIE ET PILOTAGE

C'est pourquoi les gourous de la science managériale ont défini les deux seules véritables activités de direction à savoir : la stratégie et le pilotage, matérialisés par le schéma directeur ou business plan, et les tableaux de bord ou le contrôle de gestion (figure 5.1).

Figure 5.1

La stratégie consiste à définir où l'on veut être à moyen et long termes et définit le chemin pour y parvenir au travers des objectifs et des stratégies voire des facteurs clés de succès.

Le pilotage a pour première mission de s'assurer que les objectifs seront bien atteints et qu'aucun problème opérationnel ne vienne entraver ce dessein.

Ne pas avoir de stratégie c'est comme si l'on monte sur un bateau sans savoir où il va. Or comme le disait si bien Sénèque : « Il n'est point de vent favorable pour qui ne connaît pas le port ».

De même, ne pas avoir de « tableau de bord » ou d'indicateurs c'est comme avoir un responsable à la barre sans aucune information.

Qui monterait à bord d'un avion ou d'un bateau sans savoir où il va, qui plus est sans indicateurs et instruments de bord ? Personne !

Il est intéressant de noter que la stratégie est une activité « ponctuelle » qui se fait à un moment précis pour une période donnée variant de 3 ans à 7 ans selon les cas. Elle prend en moyenne de 2 à 6 mois. Une fois validée au plus haut niveau de l'organisation, elle n'est plus modifiée, si ce n'est quelques évolutions ou aménagements en général à chaque exercice budgétaire lorsque l'on prépare les budgets de fonctionnement et surtout d'investissement pour l'année à venir.

En revanche, le pilotage est une activité dite « continue ». Elle doit se faire constamment.

5.2.1 La vraie responsabilité des managers

Quand on devient manager, on vous explique que vous pouvez tout déléguer, sauf votre responsabilité. On oublie de dire qu'il y a autre chose que l'on ne peut pas déléguer et qu'on doit assumer « intuitu personae », c'est la stratégie et le pilotage.

Quel que soit son niveau hiérarchique, un responsable ne peut attendre de son propre management ou de ses collaborateurs qu'ils réfléchissent à sa place sur le futur de l'organisation et sur son système de gestion. C'est en cela que c'est une responsabilité intime du manager qui ne peut se déléguer.

5.2.2 Pilotage stratégique et opérationnel

Il faut absolument clarifier les notions de pilotage stratégique et de pilotage opéra­tionnel. Certains auraient tendance à privilégier le premier. En fait les deux sont indispensables et de même importance.

Le pilotage stratégique a pour mission d'assurer que les objectifs stratégiques issus du schéma directeur sont bien atteints. Ce sont les objectifs à moyen et long termes de l'organisation. Il se concentre donc sur le suivi des projets et actions qui ont été validés par la direction et qui doivent permettre d'atteindre les objectifs stratégiques.

Le pilotage opérationnel consiste à piloter les activités de fonctionnement et les objectifs à court terme de l'organisation. S'assurer que l'organisation fonctionne correctement sans heurts au quotidien.

Ainsi, les tableaux de bord doivent intégrer ces deux dimensions. Par défaut, les indicateurs opérationnels dominent très largement. Ils sont plus naturels. Or ce ne sont pas forcément ceux qui intéressent le plus le haut management ou les actionnaires.

5.3 OBJECTIFS DU TABLEAU DE BORD

En tant qu'instrument privilégié de pilotage, les caractéristiques et apports d'un bon tableau de bord sont divers et variés. Sans forcément être exhaustif, le tableau de bord est le système d'information qui permet au décideur de :

• piloter l'organisation,
• être informé,
• identifier les tendances, les évolutions,
• mesurer l'atteinte des objectifs (prévisionnel/réel),
• analyser les écarts (causes/effets),
• communiquer avec l'ensemble de l'organisation,
• responsabiliser tous les acteurs sur la base d'objectifs clairs,
• développer des axes de progrès et s'améliorer.

En cela c'est un véritable outil de management qui doit constituer le référentiel par excellence de gestion/décision des responsables.

5.4 LE KAIZEN

On peut constater que dans la liste, toutes les caractéristiques sont importantes. « piloter » et être « informé » constituent la base de la gestion et du rôle du manager.

• « Identifier les tendances, les évolutions », « mesurer l'atteinte des objectifs » et « analyser les écarts » permettent de mieux maîtriser les éléments et d'assurer que les objectifs seront atteints.
• « Communiquer » est essentiel pour partager les indicateurs avec les autres acteurs et éviter un management autiste.
• « Responsabiliser » pour impliquer les acteurs sur leur rôle et devoir respectifs vis-à-vis de l'organisation.

Et enfin pour finir « développer des axes de progrès et s'améliorer ». Ce dernier point nous semble fondamental car il constitue ni plus ni moins, la finalité des tableaux de bord.

C'est important. Car souvent l'on voit des tableaux de bord qui quand on pose la question clé : « qu'en faites-vous réellement avec ? » La réponse est : « je communique à mes clients et à la direction générale ». « Et ensuite ? » « Et bien je prépare la version suivante... »

Et là, le diagnostic tombe lourdement : « Vous appelez cela un tableau de bord », « ça a effectivement le nom de tableau de bord », « ça ressemble à un tableau de bord », « c'est fait comme un tableau de bord », mais ce n'est pas un « tableau de bord » ! C'est ce qu'on appelle le syndrome « Canada Dry ».

Alors qu'est-ce, si ce n'est pas un tableau de bord ? Et bien tout simplement un « rapport ou un bilan d'activité ». C'est bien, car ça permet d'être transparent, mais ce n'est pas un tableau de bord. Car dans ce dernier cas la finalité est de prendre des décisions pour s'améliorer, progresser, etc. C'est toute la différence entre tableau de bord qui « pilote » et rapport d'activités qui « informe ».

Évidemment on ne peut pas parler d'amélioration sans évoquer le fameux « Kai­zen » cher à l'école TQM du « Total Quality Management » fondée par Juran et Deming. Cette école résumée dans le fameux cercle vertueux de la qualité (figure 5.2) : « Plan ­Do — Check — Act » symbolise à merveille le mécanisme de tout système de pilotage réussi.

C'est cette philosophie qui a permis à l'industrie japonaise ravagée par la guerre, de devenir en peu de temps la référence en matière de productivité amenant le pays à la deuxième place mondiale des pays les plus riches. Certes à la base, ça manquait un peu d'innovation et l'on singeait le modèle « copié-collé ». Aujourd'hui il a fait ses preuves et nombre de ténors occidentaux, après avoir vu leur produit copié ont commencé à s'inquiéter après avoir constaté que les prix de leurs homologues japonais étaient bien inférieurs à leur propre coût de production. Ceci a été obtenu au bout de quelques voire de nombreuses itérations, mais c'est une démarche imparable à terme.

Qui plus est, elle repose sur certains concepts proches de philosophies orientales propres à Sun Tzu et à Confucius comme :

Figure 5.2

• La perfection n'existe pas mais on peut toujours s'améliorer.
• Le but est de ne jamais s'arrêter.
• Il faut toujours se remettre en question en fixant des objectifs toujours plus ambitieux.
• Rapprocher la planification et le contrôle de gestion, la stratégie et le pilotage.
• Progresser harmonieusement en équipe avec toutes ses individualités pour en faire un projet d'entreprise.

En résumé

Les bénéfices des tableaux de bord sont nombreux pour gérer, contrôler et anticiper. La stratégie consiste à définir où l'on veut être à moyen et long termes et définit le chemin pour y parvenir au travers des objectifs et des stratégies voire des facteurs clés de succès. Le tableau de bord est un véritable outil de management qui doit constituer le référentiel privilégié de gestion/décision des responsables. On peut s'inspirer utilement de l'approche « Kaizen » développée par les Japonais.

6 Les principes de constructiondes indicateursde performance

Objectif

L'objectif de ce chapitre n'est pas de vendre une méthode en particulier, mais de montrer la multitude et la diversité des approches, preuve s'il en est de la complexité du pilotage. Bien entendu, le théorème de la variété requise d'Ashby est la pierre angulaire théorique de tout système de pilotage et doit être gardé précieusement en mémoire. Grâce à l'école de la cybernétique, de Norbert Wiener à Stafford Beer, nous possédons à présent une règle conditionnant de manière structurelle tout système de pilotage par rapport au système piloté. Le pilotage ne doit pas être vu comme une discipline à part, mais bien comme le reflet du système à piloter. Ainsi, système pilotant et système piloté doivent être en symbiose.

^-5 6.1 UNE NOUVELLE APPROCHE DU PILOTAGE L

Comme nous l'avons vu précédemment, le défaut majeur du tableau de bord infor­matique est qu'il repose sur des indicateurs trop techniques dont la plupart des informations sont inexploitables voire erronées, et sur la comptabilité classique dont les fondements anciens ne correspondent plus aux enjeux actuels de gestion.

Qui plus est, la dimension système d'information est totalement obérée alors que la grande majorité des directions informatiques (DI) sont passées, au cours de la dernière décennie, de DI à DSI (Directions système d'information). Pourtant, les systèmes de pilotage n'ont jamais intégré cette nouvelle dimension, à croire que « système d'information » n'est qu'un synonyme plus à la mode qu'« informatique », et que les périmètres de légitimité de la fonction n'ont pas évolué. Que dire encore du vocable « numérique » qui semble mélanger allégrement les notions informatiques et systèmes d'information ?

Sur la base des indicateurs actuels, il est ainsi difficile de répondre à des questions aussi essentielles pour les dirigeants d'entreprise que :

• Quels sont mes informations et systèmes d'information stratégiques ?
• Quelle est la contribution des technologies de l'information à mes différents métiers et à la performance globale de mon entreprise ?
• Quel est le capital informatique et informationnel de mon entreprise ?
• Quels départements possèdent quelles informations ?
• Sont-elles correctement protégées ?
• Combien me coûtent mon informatique au total, mes informations, mon système d'information ?
• Qui consomme les ressources informatiques ?
• Quels sont mes fournisseurs, mes prestataires de service les plus critiques ⁷
• Quelles sont mes compétences informatiques les plus sensibles ?
• Suis-je compétitif par rapport à mes concurrents et aux différents fournisseurs ?
• Quelles sont les informations utiles à mon entreprise présentes à l'extérieur ?
• Quel est mon niveau de maturité en matière de gouvernance informatique ?
• Suis-je bien protégé par rapport à toutes les malveillances potentielles ?
• Quels sont les avantages à utiliser le « cloud computing » ou le « big data » voire faire du « byod » ?
• Les réseaux sociaux représentent-ils une opportunité ou un risque pour notre entreprise ?

Que ce soit pour élaborer le système de pilotage du « système informatique » ou du « système d'information », il est important de s'appuyer sur des méthodes et principes éprouvés qui soient à même d'intégrer la complexité inhérente à l'informatique et aux systèmes d'information. C'est bien toute la difficulté d'autant plus que les sciences de gestion sont somme toute récentes.

Nous allons donc dans ce chapitre aborder tout ce qu'il faut savoir pour élaborer ses propres tableaux de bord et indicateurs de performance.

6.2 LE THÉORÈME DE LA VARIÉTÉ REQUISE D'ASHBY

La pierre angulaire de la construction de tout système de pilotage se trouve dans les travaux des cybernéticiens, en particulier de Ross Ashby.

Ross Ashby est un psychiatre anglais né en 1903 qui a été l'un des pionniers de la cybernétique, la théorie des systèmes et de l'étude des systèmes complexes, au même titre que le mathématicien Norbert Wiener². Ce dernier a introduit le terme de cybernétique en 1947 en s'inspirant des termes grecs « kubernetes » qui signifie

• « pilote » et « kubernesis » qui évoque l'action de diriger ou de gouverner. Avec le verbe
• « gubernare », ces trois terminologies ont engendré plus tard les termes de « gouverner »,
• « gouvernement » et « gouvernance ».

Aujourd'hui, la cybernétique est définie par Wikipedia comme : « La science constituée par l'ensemble des théories sur les processus de commande et de communication et leur régulation chez l'être vivant, dans les machines et dans les systèmes sociologiques et économiques ».

Elle a pour objet principal l'étude des interactions entre « systèmes gouvernants » (ou systèmes de contrôle) et « systèmes gouvernés » (ou systèmes opérationnels), régis par des processus de rétroaction ou feed-back. C'est en cela que cette science est fondamentale pour toute réflexion sur le pilotage de la performance quel que soit le domaine d'application.

Dans son célèbre ouvrage : « An Introduction to Cybernetics », Ashby a formulé sa fameuse « Loi de la Variété Requise ». Il émit le postulat que la « variété absorbe la variété » définissant ainsi le nombre minimal d'états nécessaires pour maîtriser un nombre donné d'états. Cette loi peut s'appliquer à tout système quel qu'il soit.

Dans la continuité d'Ashby, Roger Conant a élaboré en 1970 ce qu'il appelle un système parfaitement régulé (« Good Regulator theorem »)³ affirmant que chaque régulateur d'un système doit être un modèle de ce système.

Stafford Beer⁴ utilisa ces travaux pour fonder la cybernétique managériale à la fin des années 1950 qui concerne plus précisément le management et les organisations. Stafford Beer a donc été le premier chercheur à appliquer la cybernétique à la gestion en définissant la cybernétique comme la science des organisations performantes. Il a aussi développé le Modèle du système viable qui diagnostique les erreurs dans tout système organisationnel.

Ainsi, sur la base des travaux des cybernéticiens Ashby, Conant et Beer on peut énoncer la loi fondamentale de tout système de pilotage ou encore le système optimal voire idéal de gestion :

 « Tout bon système de pilotage d'un système doit être un modèle de ce système : tout système de pilotage, à la fois réussi et le plus simple possible, doit être isomorphe au système à piloter. »

Cette règle, connue sous le nom de « Théorème de la variété requise d'Ashby », est parfaitement transposable au domaine de la gestion. Ce théorème exprime alors que la variété ou la complexité, c'est-à-dire le nombre d'états, de dimensions ou de paramètres critiques du système pilotant, doit être équivalent à la variété du système piloté. Cette règle est finalement assez intuitive. Mieux, elle constitue LA condition sine qua non de pertinence et de véracité des systèmes de pilotage.

Ainsi, un système de pilotage comportant plus de dimensions que le système à piloter possédera des indicateurs non différenciateurs qui n'apporteront pas forcément de valeur ajoutée aux décideurs. On peut alors se poser la question de leur pertinence eu égard aux coûts engendrés pour les obtenir. De plus, ils auront tendance à noyer les indicateurs « légitimes », en créant une forme de « bruit », dans une logique ou « trop d'indicateurs tuent les indicateurs ».

De même, si un indicateur critique est occulté, alors comme l'indiquait Ross Ashby, il y a de fortes chances que cet indicateur dérive sans que personne ne s'en aperçoive.

Par conséquent, tout l'art de la construction d'un bon système de pilotage est d'identifier toutes les dimensions critiques du système au sens d'Ashby et de les mettre « sous tension » afin de pouvoir disposer de toutes les informations pour maîtriser le système.

Or, dans le cadre de la fonction informatique, la variété ne se réduit en aucun cas aux composantes technique et économique. D'autres dimensions interviennent aussi et sont donc à considérer, comme par exemple, les facteurs stratégiques, organisationnels, informationnels et humains.

Que penser aussi des tableaux de bord qui se réduisent à la simple dimension bud­gétaire ? Ils donnent l'impression qu'un bon manager est celui qui dépense exactement la somme qui a été prévue au départ. Cette école qui se veut du domaine de la gestion, a fondé la discipline du contrôle budgétaire. Elle est malheureusement encore très présente. En particulier au niveau des grandes structures où le contrôle de gestion central réduit son activité à consolider les budgets et suivre leur consommation.

Or, quoi de plus réducteur que de juger une organisation ou son responsable sur la seule consommation des ressources ? Je peux être un piètre manager, faisant échouer la plupart des projets sous ma responsabilité, tout en ayant une mauvaise qualité de services avec de nombreux dysfonctionnements, et pourtant être irréprochable à l'aulne de la consommation budgétaire. C'est bien cela que suggère Ashby, ne pas réduire la complexité d'un système à une dimension ou quelques dimensions, créant une forme d'autisme généralisé au sein de nos organisations. C'est ce que nous qualifions de « paupérisation managériale

Pour pallier à toutes ces faiblesses, un tableau de bord informatique efficace doit reposer sur un ensemble d'informations représentatif de la fonction informatique dans le contexte de l'entreprise. Il en est évidemment de même pour un tableau de bord des systèmes d'information.

6.3 LES PRINCIPES DE CONSTRUCTION D'UN TABLEAU DE BORD EFFICACE

Tout tableau de bord est soumis fondamentalement à des contraintes sur son contenu et sur son contenant. Les propriétés du contenu lui imposent de posséder une variété équivalente à celle de la fonction informatique dans son environnement selon le théorème d'Ashby. Les propriétés du contenant ou encore de la forme énoncent les caractéristiques à respecter afin qu'autour des informations du tableau de bord, un consensus puisse être établi.

• Les propriétés du contenu (le fond) — Nous présentons dans le tableau 6.1 une typologie possible de propriétés ou de dimensions que peut ou doit intégrer tout système de pilotage. Celle-ci n'est bien évidemment pas unique, mais elle possède l'avantage de pouvoir identifier les forces et faiblesses d'un tableau de bord existant. De même, et comme nous le verrons dans le chapitre suivant, elle peut être utilisée pour la conception de tout nouveau tableau de bord.
• Les propriétés du contenant (la forme) — Parallèlement au contenu, le contenant a aussi son importance. À nouveau, le tableau 6.2, sans être exhaustif et unique, permet très rapidement d'évaluer si tous les paramètres de définition et de caractérisation des indicateurs ont bien été considérés. Les propriétés du contenant ont pour objectif principal de créer le consensus sur l'interprétation des données en améliorant la qualité des informations présentées.