Le Blog du DSI

L'environnement et la sauvegarde de la planète sont des sujets particulièrement en vogue en ce moment. Difficile d'ouvrir une revue spécialisée sur le management ou plus simplement les pages économie de votre quotidien préféré sans que la responsabilité sociétale des entreprise (RSE), le développement durable ou les impacts du Grenelle de l'environnement ne soient évoqués au détour d'un article.

Bien évidemment, les DSI se doivent d'accompagner les entreprises dans leurs démarches. Mais quelles peuvent bien être leurs contributions ? Pour tenter de répondre à cette question, j'ai assisté récemment à deux conférences sur le sujet : le Forum Green IT France organisée par CIO et Le monde Informatique le 15 octobre 2008 au musée de l'informatique, sur le toit de la grande Arche de la Défense et la Conférence IDC Green business organisée par IDC France le 18 novembre 2008.

Cet article vous livre les enseignements pratiques que je retire de ces deux journées et de les présenter projet par projet. A ce jour, je n'ai pas identifié de projets menés par des entreprises ou proposés aux entreprises par le marché qui soient complètement altruistes envers la planète. Tous les projets présentés comme « green » ont ceci en commun qu'ils peuvent faire sens d'un point de vue business. Voilà qui est plutôt rassurant.

Tout d'abord, il faut distinguer deux grandes familles de projets :

• L'informatique dans son ensemble est responsable d'environ 2% des rejets de CO2 dans l'atmosphère, soit autant que l'aviation. La DSI peut mener des projets qui réduisent son empreinte sur l'environnement.
• D'autres projets peuvent être menés pour mieux contrôler et réduire les 98% restants.

Réduire l'empreinte environnementale de la DSI.

A ce jour, j'ai identifié trois sujets ou enjeux principaux qui semblent récurrents dans la plupart des initiatives : la consommation d'énergie, la consommation de papier et le recyclage du matériel.

Il est remarquable de noter que sur chacun de ces sujets, il peut y avoir une communauté d'intérêt entre les approches économiques et écologiques.

• Toute réduction de la consommation d'énergie se traduit par une baisse des coûts en parallèle à la réduction des émissions de carbone.

• La consommation de papier est un domaine relativement peu optimisé dans la plupart des entreprises. Il recèle donc d'importants gisements de gain. Hors le papier est à la fois coûteux financièrement et écologiquement. Là encore, on fait coup double. Si on y ajoute le coût des encres et autres toners, qui s'apparentent à de véritables produits de luxe avec un prix au litre supérieur à celui du parfum, on peut même imaginer toucher le jackpot.

• Sur le plan du recyclage du matériel, le législatif est passé par là. La loi sur les DEEE (Déchets d'Equipements Electriques et Electroniques) a créé des obligations aux entreprises pour gérer la fin de vie des équipements. Les sanctions auxquelles s'exposeraient les mandataires de sociétés par trop laxistes sont suffisantes pour que le sujet vaille la peine d'être traité sérieusement. Comme de plus, la loi fait globalement porter la responsabilité du recyclage sur les producteurs, la mise en place d'une gestion rigoureuse semble aller de soi.

Différents projets sont régulièrement cités comme porteur de ces enjeux :

• La virtualisation des serveurs
• Les nouveaux centres de traitement (Datacenter)
• La virtualisation des postes de travail
• La modification des critères d'achat
• Le déploiement d'imprimantes multifonctions
• La dématérialisation des échanges
• Le ré-engineering des états

Virtualisation des serveurs

Dès que l'on parle de Green IT, le premier projet cité est la virtualisation des serveurs. Le postulat de départ est que nos serveurs sont largement sous-utilisés. En moyenne, ils sont utilisés entre 5% et 15%, le reste du temps, ils attendent du boulot. Hors, pendant ce temps, ils consomment jusqu'aux deux tiers de leur consommation nominale. La virtualisation permet de regrouper plusieurs serveurs sur une même machine et d'atteindre ainsi des taux d'utilisation bien supérieur. Ainsi, diviser la consommation électrique par un facteur quatre semble un objectif raisonnable.

Les projets de virtualisation ne se limitent pas à l'économie d'énergie. Ils permettent de diminuer les coûts d'acquisition et de maintenance. Ils apportent une plus grande souplesse dans l'optimisation des ressources et dans leur administration. Ils favorisent la réactivité en cas d'incident et permettent de réduire le temps de reprise d'activité. La qualité des tests avant mise en production peut également être améliorée car le futur environnement peut être complètement testé avant d'être activé en production.

Tous ces avantages ne sont évidemment pas gratuits. Le principal inconvénient, est l'augmentation de la criticité des serveurs physiques. En effet, en cas de panne matérielle, c'est l'ensemble des serveurs virtualisés qui s'arrêtent.

Les nouveaux centres de traitement des données

La conception même des centres informatiques est en train de changer.

Il faut savoir que les dépenses énergétiques d'un centre informatique peuvent se répartir en trois parts sensiblement équivalentes :

• L'énergie nécessaire au matériel informatique proprement dit.
• L'énergie nécessaire au refroidissement de ce matériel.
• Le reste est l'énergie nécessaire au fonctionnement technique du site : sécurisation de l'alimentation, éclairage, humidité, etc.

L'évolution des infrastructures s'oriente vers des architectures dites à haute densité. Concrètement, un rack supporte aujourd'hui plus de serveurs qu'autrefois, consomme donc plus de courant et dissipe plus de chaleur. En concentrant et en confinant les zones de chaleur, on peut concentrer l'action du refroidissement, ce qui permet une amélioration spectaculaire des rendements. Cerise sur le gâteau, la chaleur ainsi récupérée est plus facilement réutilisable, par exemple pour le chauffage du bâtiment.

Combiné aux projets de virtualisation, le résultat est plus de puissance sur moins d'espace et avec moins d'énergie, mieux exploitée. Ici encore, on joue sur plusieurs tableaux. On réduit la facture énergétique mais aussi la facture immobilière (les mètres carrés occupés).

La virtualisation des postes de travail

Encore de la virtualisation. Mais cette fois-ci au niveau des postes de travail.

Les gains générés par ces projets sont spectaculaires : réduction des coûts d'administration et de maintenance, sécurisation des données individuelles, meilleure réactivité, optimisation des ressources et j'en passe.

Sur le plan énergétique, les gains sont également impressionnants. En remplaçant les PC traditionnels par des terminaux légers on peut diminuer la consommation de chaque poste de travail d'un facteur dix.

Tout comme pour la virtualisation des serveurs, ces gains ont pour contrepartie un accroissement de la criticité des installations. En cas de panne matérielle, c'est tout un groupe d'utilisateurs qui sera impacté au lieu d'un seul.

Modifier les critères d'achat

Ce n'est pas tous les jours que l'on peut se payer un nouveau centre de traitement ou mobiliser les énergies et les finances nécessaires à un projet de virtualisation.

Par contre, nous pouvons étoffer nos cahiers des charges lors de la sélection de matériel. Les principaux critères à introduire sont la consommation électrique et les conditions de recyclage. Ceux-ci viennent se rajouter aux habituels critères de prix, de fonctionnalités, de performances, de qualité et de service.

Comparer la consommation électrique des équipements que nous nous apprêtons à acquérir devrait être facile. Il devrait suffire de consulter la fiche technique et de se référer à la bonne rubrique. Eh bien non ! Pas du tout ! Les fabricants s'ingénient à noyer le poisson, il n'y en a pas deux pour mesurer la consommation de la même manière. Pire encore, les consommations ne sont pas indiquées de façon homogène pour un même fournisseur.

Je suppose que nous allons tous mettre la pression sur nos fournisseurs pour obtenir cette information de façon systématique et claire, si possible normée. Face à la demande croissante de leurs clients, on peut espérer que ce sera bientôt de l'histoire ancienne.

En attendant, la solution consiste à faire un test de mesure avant toute acquisition. Une autre approche consiste à se reposer sur des labels comme, par exemple, Energy Star.

Sans forcément rechercher le meilleur de l'optimum, il est déjà possible de s'assurer d'une diminution sensible en sélectionnant des machines équipées de processeurs à basse consommation.

Du point de vue du recyclage, il y a deux dimensions à regarder :

• Quel sont les matériaux utilisés pour la production du matériel ? Le fabriquant est-il allé au-delà de la règlementation ?
• Quel est le processus de gestion de fin de vie proposé par le fournisseur ? Est-il compatible avec les nôtres ?

Là encore, nous manquons de mesures normées pour pouvoir comparer les offres. L'évaluation est donc en partie subjective.

Globalement, la tendance semble être à l'allongement de la durée de vie du matériel. On s'était habitué à renouveler le matériel à l'issue des durées d'amortissement. Dans bien des cas, il peut-être conservé plus longtemps sans dégradation du niveau de service.

Déployer des imprimantes multifonctions

Un projet couramment cité pour diminuer les impressions est le déploiement d'imprimantes partagées et multifonctions : imprimante, photocopieuse, scanneur, fax. Celui-ci va de pair avec une suppression des imprimantes individuelles.

En soi, ce déploiement ne fait pas automatiquement diminuer la quantité d'impression et je confesse quelques doutes quant à l'efficacité de ce projet sur ce plan. C'est, néanmoins,  l'occasion de mettre en place un certain nombre de bonnes pratiques :

• Imprimer recto/verso. Cette fonction divise par deux le nombre de feuilles. Elle peut être paramétrée par défaut.
• Dématérialiser chaque fois que possible. Ainsi, la photocopieuse peut envoyer directement le document scanné vers l'email du destinataire plutôt que de l'imprimer.
• N'imprimer les documents qu'à la demande. Près de 10% des pages imprimées finissent directement à la corbeille à côté de l'imprimante, personne n'étant venu les chercher. Un code utilisateur demandé avant l'impression permet d'éviter ces impressions inutiles.
• Mettre en place des statistiques d'impression sur les volumes et les coûts puis les communiquer. Cette démarche permet à chacun de prendre conscience de sa contribution personnelle.

La dématérialisation des échanges

Les contraintes environnementales apportent de l'eau au moulin des divers projets de dématérialisation : dématérialisation de la facture, échanges EDI, etc.

Je ne m'étendrai pas sur ces projets dont beaucoup d'entreprises avaient identifié l'intérêt bien avant Grenelle et pour d'autres motifs.

Et si on revoyait nos états ?

Nos systèmes d'information impriment de nombreux états et rapports. Nombre de ceux-ci sont produits par des programmes qui nous sont spécifiques, sur lesquels nous avons la main. Il est dès lors possible de réanalyser ces états dans une optique de réduction des volumes d'impressions.

Je ne résiste pas à relater à ce sujet deux exemples qui ont été présentés par Marie-Claude Poelman, DSI de Nature & Découvertes, à l'occasion de la conférence IDC du 18 novembre.

• En réduisant la longueur du ticket de caisse par l'élimination de lignes blanches inutiles, les gains obtenus par Nature & Découverte se chiffrent en tonnes de rouleaux de caisse !
• Parmi les états les plus imprimés, l'un était consacré à fournir les chiffres du jour. C'est une information qui intéresse beaucoup de monde mais qui à une durée de vie courte. En offrant une version SMS de cette information pour tous les managers qui s'y abonnent, N&D à non seulement diminué le volume de papier imprimé mais également amélioré son niveau de service. Le SMS peut être reçu à l'autre bout du monde, sans avoir à passer par la case imprimante.

La DSI contribue à des projets ayant un impact positif.

Comme indiqué en début d'article, l'informatique représente de l'ordre de 2% des émissions de carbone dans le monde. J'ai essayé ci-dessus de dresser une liste des projets les plus souvent cités qui permettent de réduire cet impact.

Mais les technologies et l'informatique peuvent également apporter des outils qui aident à s'attaquer aux 98% restants. Les paragraphes qui suivent présentent quelques exemples d'initiatives ou de projets auxquels l'informatique peut contribuer.

Refonte de la chaîne logistique.

Un projet de refonte de la chaîne logistique, avec pour objectif une optimisation des kilomètres parcourus, peut contribuer à baisser l'impact carbone d'une enseigne de distribution. La recherche d'optimisation conduit naturellement à varier les modes de transports en introduisant le fluvial comme Monoprix ou le ferroutage comme Nature & Découvertes. Soit dit en passant, ce même projet peut également contribuer à réduire les coûts.

Pour mener un tel projet, il est nécessaire d'adapter le système d'information pour prendre en compte de nouveaux délais, de nouvelles logiques de cadencement ou de remplissage, de nouvelles étapes, etc.

Les immeubles à énergie positive.

Dans la construction de bâtiments, un concept actuellement en vogue est celui d'immeuble à énergie positive. Cette appellation désigne des bâtiments conçu pour produire plus d'énergie qu'ils n'en consomment.

Dans ces bâtiments, l'informatique est largement utilisée pour réguler les différents systèmes de gestion de l'énergie. C'est ainsi que la DOSI de Bouygues Immobilier contribue directement au projet Green Office à Meudon.

Téléconférence.

Dans une entreprise multi-sites, les déplacements nécessaires à la participation à diverses réunions constituent un poste significatif d'émission de CO2.

Les solutions de téléconférence ou mieux encore de téléprésence, sont largement citées comme des outils permettant de réduire les déplacements tout en favorisant la communication. Elles permettent en effet de multiplier les réunions tout en évitant les déplacements.

Ces projets nécessitent toutefois quelques remarques :

• Il ne faut pas lésiner sur la qualité des solutions mises en place pour que les échanges soient efficaces.
• Ces solutions ne permettent pas de supprimer totalement les déplacements. La relation entre les personnes se construit aussi autour du partage d'un repas ou d'un café. Ces échanges ne peuvent avoir lieu que dans le monde physique.
• Les outils ne suffisent pas. Une véritable gestion du changement est nécessaire pour lever les freins à leur utilisation. Par exemple, il est peu probable que les grands voyageurs, qui bénéficient à titre personnel des avantages que leur procure l'accumulation des miles sur leur programme de fidélité, limitent d'eux-mêmes leurs déplacements.

La comptabilité CO2

C'est bien connu, on ne peut agir que sur ce que l'on mesure.

La comptabilité carbone consiste à ramener tous les processus de l'entreprise à des émissions exprimées en équivalent carbone. Une méthodologie a été développée par l'ADEME (Agence De l'Environnement et de la Maîtrise de l'Energie) : le Bilan Carbone. Ce bilan carbone pourrait très bien jeter les bases d'une future taxe carbone.

La tenue permanente d'une comptabilité carbone est un outil de mesure pour une entreprise qui souhaite s'engager dans une démarche d'amélioration continue sur le plan environnemental en se fixant des objectifs chaque année.

Dans une telle approche, cette comptabilité aurait tout intérêt à s'intégrer au système d'information de l'entreprise.

Pour aller plus loin

Nous arrivons au bout de ce tour d'horizon sur les démarches qualifiées de « Green IT ».

Pour ceux qui souhaitent approfondir le sujet, je recommande la visite des sites suivants :

* Le monde Informatique : zone consacrée au green : http://greenit.lemondeinformatique.fr
* Le monde Informatique : Blog d'Emmanuelle Delsol http://blog2.lemondeinformatique.fr
* Le Blog de Stéphane Parpinelli, Fred Bordage et François Letellier : www.greenit.fr
* Le site de l'ADEME : http://www.ademe.fr
* Tapez « Green IT » dans Google.

Qui d'entre-nous n'a été confronté un jour ou l'autre au choix d'indicateurs clés ? Le développement de l'informatique et l'avènement de la "business intelligence" a mis à la disposition des entreprises quantité de données permettant de générer un nombre toujours plus impressionnant d'indicateurs.

Nombre de professionnels et de consultants se sont attelés à la constitution de tableaux de bord, ont théorisé la démarche et ont produit de nombreuses méthodes. Une des plus célèbres et des plus en vogue ces dernières années est la "balanced scorecard" de Robert Kaplan et David Norton mais elle loin d'être la seule.

La théorie semble donc aujourd'hui bien maîtrisée. Pourquoi alors y-a-t-il encore tant de difficultés à réaliser des tableaux de bord qui améliorent efficacement le pilotage de l'entreprise ? En fait, tout le problème est d'exploiter une théorie riche et complexe d'une façon pragmatique, simple et compréhensible par chacun, ... et de faire oublier la théorie.

Voila une recommandation plus facile à énoncer qu'à mettre en pratique. Pour l'illustrer, je vais dans la suite de cet article me référer à la définition des indicateurs clés permettant de suivre l'activité dans le contexte du commerce grand public (B2C ou retail). Cet exemple offre pour moi un double avantage. D'une part, je le connais bien et d'autre part il est facile à appréhender car chacun d'entre-nous y participe en tant que client.

Pour choisir les indicateurs clés, il faut partir d'une vision macro du modèle économique de l'entreprise et ensuite le décliner.

Dans ce modèle, la création de valeur pour l'entreprise présente quatre grandes étapes :

1. Les points de ventes sont fréquentés par un certain nombre de visiteurs.
2. Certains de ces visiteurs achètent et passent à la caisse, ils sont devenus des clients
3. Les ventes ainsi réalisées génèrent le chiffre d'affaires.
4. Après déduction des coûts, il reste la marge, résultat de l'activité.

Ce modèle est linéaire. L'amélioration du trafic et de chacune des transitions génère une amélioration du résultat de l'entreprise ce qui est un objectif premier.

Le schéma que voici résume ce qui précède :

Ce modèle est archi simple, il doit même sembler simpliste à tous les commerçants. C'est justement cette simplicité qui facilite l'interprétation des indicateurs qui en découlent. Ces sept indicateurs, à la signification évidente et dont les corrélations sont intuitives, permettent d'embrasser d'un seul regard la chaîne de création de valeur de l'entreprise.

Mais creusons un peu...

Pour définir un indicateur de la fréquentation, on part de la mesure du nombre de visiteurs. Dans un magasin, celle-ci peut être obtenue grâce à un dispositif de comptage à l'entrée. Il est important de bien définir le résultat de ce comptage. Deux parents qui visitent le magasin accompagnés de leurs trois enfants représentent un groupe de cinq personnes mais ne représentent l'opportunité que d'un seul passage en caisse. Certains dispositifs sont capables de faire la distinction entre un groupe et un visiteur isolé, d'autre pas. Il faut donc définir l'indicateur de fréquentation en fonction du dispositif utilisé. Sur Internet, la plupart des outils fournissent le nombre de visiteur du site. Ce qui est important, c'est d'éviter de compter plusieurs fois le même visiteur, de s'approcher du nombre d'opportunités de vente et de rendre compte fidèlement des variations de trafic.

La fréquentation ainsi obtenue va servir à évaluer l'impact des actions et événements susceptibles de l'influencer : communication, promotions, changement d'image ou positionnement, modification de la zone de chalandise, événements climatiques, etc.

Le nombre de passages en caisse est facile à obtenir que ce soit sur Internet ou dans un magasin. L'intérêt de cet indicateur est qu'il est directement factuel et qu'il donne accès au taux de transformation.

Le taux de transformation est le ratio entre le nombre de passages en caisse et le nombre de visites, exprimé en pourcent. Il va servir à évaluer l'impact des actions et des situations qui peuvent influencer le déclenchement des actes d'achat : animations, promotions, modifications tarifaires, merchandising, réduction des temps d'attente, disponibilité des vendeurs, etc.

Le panier moyen est le ratio entre le total des ventes et le nombre de passages en caisse. Il peut s'exprimer soit en Euros, soit en volume. C'est l'indicateur qui permet d'évaluer la plupart des actions d'optimisation du processus de vente.

J'utilise ici le terme chiffre d'affaires de façon un peu abusive. Pour moi, il s'exprime aussi bien en quantités qu'en Euros. Les volumes vendus deviennent aussi intéressants que la valeur pour l'analyse des ventes et de la performance produit par produit.

Un indicateur des coûts est forcément un agrégat de multiples mesures et estimations. Il faut donc être très clair sur les coûts inclus et exclus de l'indicateur. Quelques soient les choix faits, la totalité des coûts variables devrait être incluse. Comme, en matière de gestion, la tendance actuelle est de chercher à transformer les coûts fixes en coûts variables, il est souhaitable d'inclure également un maximum de coûts fixes. Ceci permet de conserver dans le temps le périmètre de l'indicateur et de permettre les comparaisons d'une période sur l'autre. Même si au niveau des tableaux de bord de pilotage, l'indicateur coûts est agrégé, ceci ne dispense pas de disposer du détail pour analyse.

Pour finir, la marge est la différence entre le chiffre d'affaires et les coûts. Elle s'exprime en valeur et en pourcentage du chiffre d'affaires.

Rester cohérent entre les axes d'analyse...

Les indicateurs doivent pouvoir être décliné selon divers axes d'analyses. Les axes les plus courants sont le lieu, le temps, le produit et le client.

Le lieu peut se décliner du monde entier au point de vente en passant par les régions et les pays. Habituellement, le point de vente est le magasin mais dans certain cas, on peut vouloir descendre au rayon ou au linéaire.

Le seul problème posé par l'axe du temps est la notion de périodes comparables. Ainsi, pour rendre comparable une journée d'activité à la même journée de l'année précédente, il vaut souvent mieux comparer un lundi à un autre lundi plutôt qu'à un samedi.

L'axe produit est défini par la segmentation. A noter qu'il existe souvent plusieurs segmentations différentes : par nature, par usage, par fournisseur, par lieu de production, etc. Chacune des segmentations peut donner lieu à un axe produit différent.
Traditionnellement, l'axe client était peu utilisé par les commerçants. Il est évident que lorsque les clients sont anonymes, ils ne peuvent faire l'objet d'une analyse. Mais depuis plusieurs années, beaucoup de commerçants ont mis en place des programmes de fidélisation ou des services spécifiques leur permettant d'identifier et de mieux connaître tout ou partie de leur clientèle. Là encore, il peut en résulter plusieurs segmentations différentes pouvant chacune donner lieu à un axe d'analyse particulier.

Pour que les indicateurs restent pertinents et faciles à interpréter, il faut que leur définition reste stable et consistante quel que soit le périmètre défini en fonction des différents axes. Ceci suppose de respecter en permanence l'équation de base :

Ce principe pose quelques difficultés...

Les visiteurs peuvent généralement être comptés mais ils sont rarement identifiés. Ceci signifie que la fréquentation et le taux de transformation disparaissent souvent de l'équation lors des analyses selon l'axe client. Les nouvelles technologies combinées aux approches marketing one to one nous permettrons probablement bientôt de résoudre ce problème. Déjà sur Internet, les cookies permettent, dans une certaine mesure, de suivre la fréquentation d'un client particulier. Dans les magasins, les puces électroniques RFID ou les interactions avec les téléphones des visiteurs pourraient devenir une source d'information suffisante.

Toujours au sujet de la fréquentation, il faut comprendre que c'est un indicateur qui ne varie pas sur l'axe produit. Tant que l'acte d'achat n'a pas eu lieu, un visiteur du magasin est un client potentiel pour chacun des produits. Si je veux affiner, il faut agir sur l'axe lieu et m'intéresser aux rayons ou aux linéaires. Il est assez rare de procéder à ces mesures en magasin mais cela devient nettement plus pertinent sur le web où je peux mesurer le trafic sur chacune des pages.

Un autre problème qui peut se présenter est le cas où il existe un décalage dans le temps entre la transformation et la réalisation du chiffre d'affaire. C'est le cas de tous les commerçants qui prennent des commandes de leurs clients. Les règles comptables imposent de constater le chiffre d'affaires au moment de la livraison, d'où un décalage. Là encore, c'est un problème de vocabulaire. Le chiffre d'affaires dont il est question ici ne répond pas à la définition comptable mais au chiffre constaté à l'occasion du passage en caisse. On parle d'ailleurs parfois de chiffre d'affaires en sortie de caisse ou de chiffre d'affaires en prise de commande.

Je pourrais continuer comme cela à énumérer les sujets qui peuvent poser problème. Il est toutefois peu probable d'atteindre l'exhaustivité. Mon but est ailleurs. Il s'agit d'illustrer que le fait de chercher à construire les tableaux de bord sur la base d'un jeu d'indicateurs simples à comprendre est générateur de complexité dans leur élaboration.

En guise de conclusion...

Et c'est là toute la leçon que je voudrais tirer de ce long discours.

• Pour assurer un pilotage efficace, il faut définir un jeu d'indicateurs simple et cohérent qui rend compte du modèle économique de l'entreprise.
• Pour obtenir ces indicateurs, aussi simples soient-ils, il y a toujours des difficultés à surmonter, des apparentes impossibilités à résoudre. La seule exploitation des données directement disponibles, aussi riches soient-elles, est rarement satisfaisante. Il faut mettre de l'intelligence dans la construction des tableaux de bord.

Enfin, le système le mieux conçu au monde ne vaut que par la qualité de ses données. C'est particulièrement vrai dans le cas des tableaux de bord. Un contrôle qualité permanent est donc largement souhaitable bien que rarement mis en place.

On m’a demandé récemment comment je structurais les différents outils informatiques et comment je les corrélais au système d’information de l’entreprise.

Comme le montre le schéma ci-dessous, je classe les applications informatiques en cinq grandes familles :

• Au cœur de tout, il y a les données de l’entreprise. Je classe dans cette catégorie les gestionnaires de bases de données, les outils de sauvegarde, etc. Par extension, j’y range également tous les outils qui permettent aux informaticiens d’administrer l’informatique de l’entreprise.

• Ensuite vient l’informatique de gestion. Pour faire vite, j’y loge l’ensemble des applications de gestion : gestion de l’activité et des ressources (ERP), gestion de la relation client (CRM), gestion des relations fournisseurs (SRM), gestion du cycle de vie des produits (PLM), gestion des processus (BPM), etc.

• J’appelle le niveau suivant informatique personnelle et collaborative. Le terme informatique personnelle désigne ici l’ensemble des outils de productivité dont les plus répandus sont les outils bureautiques comme Word, Excel ou Powerpoint. Le terme informatique collaborative désigne les outils informatiques qui permettent aux utilisateurs de communiquer entre eux ou avec l’extérieur de l’entreprise. On y trouve, bien sur, la messagerie mais aussi, par exemple, des outils de partage de documents à distance ou de video-conférence. C’est également dans cette famille que je classe les outils spécifiquement destinés aux utilisateurs nomades.

• Le quatrième niveau est l’informatique scientifique et industrielle. On y retrouve des outils d’engineering comme la CAO, les outils de modélisation ou les outils de calcul pour ce qui est de l’informatique scientifique. L’informatique industrielle recouvre quant à elle les outils informatiques intégrés à l’outil de production. Le plus souvent, il s’agit d’outils informatiques servant au pilotage des outils ou à enregistrer et traiter des données de contrôle.

• Finalement, viennent les applications informatiques qui vont faire partie intégrante du produit vendu par l’entreprise à ses clients. L’exemple type est celui du programme de l’ordinateur de bord de votre voiture mais l’essor des cartes électroniques programmables généralise ce cas de figure à de plus en plus de produits. Un autre cas de figure est l’intégration de données de gestion au produit sous forme d’étiquettes, codes barres ou puces RFID.

La raison d’être de cette segmentation des outils informatiques est que les modes de gestion de ces familles sont différents. Elles ne subissent pas les mêmes contraintes. Les éditeurs et les intégrateurs sont souvent différents. Elles font appel à des technologies spécifiques. Elles nécessitent des compétences particulières. Etc.

Le système d’information de l’entreprise est un ensemble de processus et ressources organisés pour collecter, stocker, traiter et communiquer les informations. Il dépasse donc très largement les seuls outils informatiques qu’il exploite puisqu’il intègre également des personnes et une organisation. A contrario, il ne comprend pas forcément tous les outils informatiques présents dans l’entreprise puisque une application qui a une autre finalité (comme un automate de production) ou qui est utilisée en dehors d’un processus organisé de traitement de l’information n’en fait pas partie stricto-sensu.

A la fin du siècle dernier, je considérais que le système d’information s’appuyait principalement sur l’informatique de gestion dont la finalité est justement de gérer l’information nécessaire aux différents processus.

Aujourd’hui, même si c’est encore vrai, les autres familles interviennent de plus en plus dans le système d’information. Les outils de gestion de la relation client ou fournisseur intègrent de plus en plus souvent la messagerie comme moyen de communication. Bien des processus s’appuient sur de simples tableaux Excel. L’ordinateur de bord de votre voiture transmet des informations très utiles à votre garagiste. Des outils de contrôles alimentent les statistiques sur la qualité. La liste de ces exemples pourrait ainsi continuer encore longtemps.

Autrefois, il était possible d’assurer une gestion séparée des différentes familles informatiques. Aujourd’hui que le système d’information intègre de plus en plus les différentes familles d’outils, la question de leur compatibilité ou de leur interopérabilité se pose de plus en plus souvent. C’est pourquoi je considère qu’il devient de plus en plus opportun d’en regrouper la gestion.

Un des visiteurs de ce Blog m’a interrogé sur ma vision sur les outils Web 2.0 et leur utilisation en entreprise.

La réponse n’est pas simple. Tout d’abord, l’appellation « Web 2.0 » ne désigne pas une fonctionnalité particulière mais plutôt une évolution dans la manière d’utiliser les réseaux. Ensuite, l’évolution que représentent les applications Web 2.0 est tout autant sociale que technologique.

Il faut d’abord s’entendre sur ce que l’on appelle une application Web 2.0. Une définition complète peut être trouvée sur Wikipedia. Toutefois, ce qu’il faut en retenir dans le cours de cet article tient en trois points :

• C’est une application Web, accessible par un navigateur.
• L’information y est produite par les utilisateurs.
• Elle cherche à tirer parti de la puissance des liens sociaux.

Partant de cette définition, la plupart des applications transactionnelles d’entreprise (ERP, SCM, CRM, …) pourraient apparaître comme Web 2.0 pour autant qu’elles reposent sur les technologies Web. Certains éditeurs n’hésitent d’ailleurs pas à le proclamer. Ce sont bien les utilisateurs qui introduisent des données et une transaction complète est le résultat de la collaboration de plusieurs personnes tout au long de la chaîne. Toutefois, sans vouloir entrer dans un débat sémantique et philosophique sur le Web 2.0, je ne veux pas m’intéresser ici à ce type d’applications. Ce qui m’intéresse, ce sont les nouvelles possibilités, les nouveaux services qui peuvent être offert grâce à cette approche et je vais m'intéresser à deux d'entre-eux.

Le premier domaine d’application qui me semble intéressant en entreprise est la gestion des connaissances. L’exemple type sur la toile est Wikipedia.

Dans ce domaine, l’approche traditionnelle en entreprise consiste à constituer une base de connaissance à travers un processus rigoureux de révision, de validation et d’approbation qui permet de s’assurer de l’exactitude des connaissances et de leur formalisation avant de les enfermer dans une espèce de coffre-fort. On retrouve cette approche dans des applications traditionnelles de gestion documentaire ou de gestion des processus dans le cadre de la certification qualité.

Cette approche est relativement lourde et non propice à l’évolution à cause du verrouillage lié à la validation par les experts et à l’approbation hiérarchique.

Les applications Web 2.0 abordent autrement le problème de la validation. Chacun est libre de compléter et de corriger le contenu. Le système peut devenir très efficace s’il y a suffisamment d’utilisateurs impliqués dans le contenu et si les erreurs sont effectivement rapidement corrigées.

Ainsi, si j’utilise une application Wiki pour documenter les processus d’entreprise je peux obtenir des résultats spectaculaires si je réunis quelques conditions :

• Pour éviter le syndrome de la page blanche, il faut fournir un contenu initial. Celui-ci doit permettre de structurer la connaissance que l’on souhaite formaliser et de fournir des exemples aux utilisateurs.
• Il faut mettre en place, dans la politique RH, un système de reconnaissance. Je préconise d’intégrer à l’évaluation du travail des collaborateurs, leur contribution à la base de connaissances : Est-ce que je l’utilise régulièrement ? Est-ce que je détecte les erreurs et est-ce que je les corrige ? Est-ce que j’ai produit du contenu ? Tout ceci peut être évalué de façon assez factuelle grâce aux statistiques d’utilisation.
• Il faut corréler recherche et contenu. Lorsque les outils de recherche ne permettent pas de trouver de réponse, il faut appeler des contributions pour couvrir le manque détecté.

Ce qui est extraordinaire, c’est de constater le peu d’erreurs générées et la rapidité de leur correction. Je suis intimement persuadé que le fait de collaborer à une œuvre commune et de voir sa production personnelle étalée aux yeux de tous, pousse les gens vers l’excellence. C’est un apport direct de la pression sociale.

Un autre domaine assez évident est celui de la communication qu’elle soit interne ou externe, mais je vais faire ici un zoom sur la communication interne. Les outils web 2.0 par excellence sont les blogs et la syndication d’information (fils RSS).

Traditionnellement, parmi les « best practices » de la communication interne, on va retrouver les journaux d’entreprise, les boîtes à suggestion, les enquêtes, les notes de services, les mémorandums, etc. Tous ces outils ont pour vocation soit de diffuser de l’information, soit de capter de l’information.

Les approches traditionnelles font apparaître deux obstacles structurels :

• Elles sont totalement dépendantes de la qualité personnelle des quelques personnes en charge de la communication. Celles-ci constituent, en effet, un point de passage quasiment obligé du processus de communication.
• Elles subissent les contraintes temporelles. Difficile de faire paraître mensuellement un journal d’entreprise. Les enquêtes doivent être préparées et dépouillées. Quand relever une boîte à suggestion ? Cette note de service diffusée il y a trois semaines est-elle toujours d’application ?

La combinaison des outils de type blogs et de la syndication peut révolutionner la pratique de la communication interne. Elle permet de lever les deux obstacles aux approches traditionnelles :

• Potentiellement, chacun devient communicant. Les professionnels deviennent plus des animateurs et des organisateurs des flux de communication dans l’entreprise que des points de passage et de contrôle.
• La communication devient instantanée. Au moment même ou un message est terminé, il devient accessible par tous. Pour une enquête, un système de votes implanté dans un blog prend en compte les réponses au fil de l’eau. Les résultats sont consultables immédiatement. C’est un atout extraordinaire en termes de réactivité. C’est aussi l’occasion de faire des bourdes monumentales.

On touche là au principal frein à l’utilisation des outils Web 2.0 en entreprise. Ces outils induisent de repenser au rôle et à la responsabilité des individus au sein de l’organisation. L’évolution va dans le sens d’une plus grande liberté d’action des individus. Les dirigeants voient là une perte de contrôle qui fait apparaître des risques dont l’évaluation est délicate.

Selon moi, cette crainte est légitime et doit être adressée dans les projets Web 2.0 en entreprise. Les démarches Web 2.0 ne fonctionnent que si la pression sociale fonctionne et dans le bon sens. J’ai pu constater à plusieurs reprises que quand les choses ont été faites avec soin et que les conditions ont été réunies pour s’assurer de la participation de tous, tout se passe bien. En fait, une communauté soudée ne fait pas plus d’erreurs que des dirigeants isolés et probablement moins. C’est un phénomène que j’ai pu observer mais que je suis bien en peine d’expliquer ou de démontrer. Si quelqu’un dispose d’une explication scientifique, ça m’intéresse fortement.

Je suis tombé aujourd’hui sur une question particulièrement intéressante postée dans un forum et que je vous livre à l’identique ainsi que la réponse que j’ai faite sur ce forum dans la foulée.

...
Quels sont les risques (ou freins ou difficultés) qui peuvent compromettre l'implantation du management par projet dans un organisme ?

Par exemple :
il y a risque que la Direction ne soit pas totalement impliquée dans la démarche.
il y a risque le personnel ne soit pas formé au management et à la gestion de projet.
il y a risque que l'organisme n'est pas la maturité nécessaire en projet.
il y a risque que l'effort de l'implantation ne soit pas constant.
il y a risque que les bons comportements ne soient pas compris et admis.
etc.
...

Sans prétendre avoir une vue exhaustive des problèmes que l’on peut rencontrer dans une démarche d’implantation d’une gestion par projets, voici quelques-uns des écueils que j’ai pu identifier.

Le premier est la volonté d’aller trop vite. Comme dans tout changement, il faut respecter quelques étapes pour fédérer les équipes autour du projet. Le premier temps est celui du diagnostique. Tant qu’un relatif consensus n’est pas atteint, il reste trop de place pour des réactions du type : « Pourquoi changer ? On n’est pas si mauvais. ». Le second temps est celui de l’information. Il permet de faire découvrir aux équipes ce qu’est le management par projet, comment il fonctionne et de montrer en quoi il peut répondre au diagnostique. Ce n’est qu’ensuite que peuvent venir le temps de la préparation, de la formation et du déploiement. Là encore, il faut y aller progressivement. Il faut commencer quelques pilotes, avec des objectifs raisonnables, en commençant par quelques processus de base et en complétant au fur et à mesure. Et quand tout est en place, il faut continuer les efforts pour arriver au temps de l’institutionnalisation, le temps où l’on ne se rappelle plus comment on faisait avant. Le temps ne respecte pas ce qui ce fait sans lui. Si on brûle des étapes, l’implantation du management par projet risque de retomber comme un soufflé, avec beaucoup de désorganisation au passage.

Le second risque est une maladie que j’appelle la « méthodologite aigüe ». Elle conduit tout droit à la déresponsabilisation et à la grève de l’intelligence. Elle se déclenche de façon insidieuse à l’occasion des premiers projets. Les équipes, en pleine phase d’apprentissage des nouvelles méthodes, se laissent conduire par les processus plutôt que de conduire les processus du projet. Ce faisant, elles laissent au vestiaire une part de leur capacité de jugement sur l’utilité des tâches qu’elles accomplissent. Le symptôme absolu de la maladie est lorsque quelqu’un accomplit une tâche « parce que c’est dans la méthode ». La formation et le coaching des projets doivent intégrer la lutte contre cette maladie. Les méthodes sont nécessaires mais doivent rester un moyen, non une fin.

Le troisième risque survient lorsque l’on va au bout de la logique du management par projet et que l’on dédie les ressources humaines au projet en les détachant de leur structure dans l’organisation. J’ai souvent pu observer dans cette situation que des personnes dont la participation au projet paraissait aller de soi et qui pourtant refusaient d’y participer. En fait, ces personnes avaient simplement peur de quitter leur position dans l’organigramme. Le problème est qu’elles n’avaient aucune confiance dans la capacité ou la volonté de l’entreprise de les réintégrer à l’issue du projet à une place qui leur donne satisfaction. Ce risque, à lui seul, peut faire échouer la mise en place d’un management par projet. Pour y parer, il faut mettre en place des règles claires et des engagements précis sur ce sujet et aborder la question de façon franche avec les personnes concernées. Même ainsi, si l’entreprise ne bénéficie pas d’un capital de confiance suffisant aux yeux de ses employés, cette résistance peut poser des problèmes.

Le quatrième risque est la montée du stress. Le management par projet rend l’activité des personnes très mesurable. La planification des tâches met un coup de projecteur sur l’activité et sur la productivité individuelle. La production systématique de livrables rend également les résultats de ces activités très visibles en quantité et en qualité. Pour beaucoup de personnes, c’est une situation anxiogène, génératrice de mauvais stress. Pour éviter, ou du moins limiter la montée de ce stress, la direction et le management se doit d’adopter une certaine retenue dans l’utilisation des nouveaux indicateurs pour l’évaluation des collaborateurs et dans son niveau d’exigences. Il faut absolument démontrer que les indicateurs servent avant tout à mesurer et éventuellement à remettre en cause les processus et non les individus. Ceci ne peut en aucun cas être un discours, auquel personne ne croirait, il faut que la pratique en fasse rapidement la démonstration.

Ce sont selon moi les risques majeurs qui mettent en péril le déploiement d’un management par projets ou d’une gestion de projet. Après, il faut rentrer dans les détails de chacun des processus du PMBoK ou du moins de ceux que l’on aura décidé d’implanter. Selon la maturité de l’entreprise et le niveau de ses collaborateurs, les risques de dysfonctionnement pendant la période d’apprentissage existent plus ou moins. Il faut donc les évaluer au cas par cas et évaluer dans quelle mesure ils pourraient mettre en péril l’atteinte des résultats visés.

Je pense être loin d’avoir épuisé le sujet. Aussi, tous vos commentaires ou retours d’expériences seront les bienvenus. Je ne serais pas étonné que ce thème vive plusieurs années sans jamais trouver une conclusion définitive.

Cela faisait pas mal de temps que je ne m’étais plus posé de questions au sujet du modèle français d’organisation des projets autour d’une maîtrise d’œuvre et d’une maîtrise d’ouvrage.

Pour rappel, ce modèle d’organisation, emprunté au secteur du bâtiment, fait partie de l’exception culturelle française. Tous ceux qui, comme moi, ont utilisé ces termes pour présenter leur parcours professionnel dans leur CV ont dû s’en rendre compte au moment de la traduction en anglais. La traduction est impossible, le concept n’existe même pas. Il faut donc rédiger autrement la version anglaise. (Note: Pour ceux qui souhaitent aller plus loin dans cette problématique de traduction vers l'anglais, je recommande de suivre le lien suivant qui est, et de loin, ce que j'ai rencontré de mieux sur ce sujet: http://anglais-pratique.fr/rubriques/gestion-projets/92-maitre-ouvrage-oeuvre).

Deux épisodes récents m’ont amené à réfléchir à nouveau sur ce sujet.

Le premier d’entre eux était un article dans un forum. Celui-ci relatait les difficultés rencontrées par un projet. L’équipe de maîtrise d’ouvrage avait réalisé des spécifications détaillées à l’aide d’un AGL et il avait fallu énormément de temps aux développeurs pour prendre en main ces spécifications et arriver à travailler en bonne intelligence avec la maîtrise d’ouvrage.

Le second épisode est la lecture d’un article sur un site anglo-saxon qui est une pépite en matière de gestion de projet : « The Project Management Hut ». Cet article est intitulé « The Yin and Yang Of Project Management and Business Analysis ». Dans cet article, l’auteur présente deux rôles complémentaires, souvent attribués à une même personne : le chef de projet et l’analyste métier. Il reconnait le bien fondé de cette approche pour de petits projets mais regrette la confusion ainsi créée. Selon lui, il s’agit de métiers distincts même s’ils demandent de nombreuses compétences communes. Il plaide donc pour la séparation de ces rôles. L’analyste métier réalise alors un certain nombre de tâches et produit un certain nombre de livrables qui doivent faire partie du plan de projet géré par le chef de projet. A ce titre, l’analyste métier répond au chef de projet et lui rend compte de son activité. Tout ceci est parfaitement en ligne avec les meilleures pratiques anglo-saxonnes.

Ces deux épisodes m’ont rappelé plusieurs éléments fondamentaux pour que notre système français fonctionne bien.

Tout d’abord, pour que le modèle fonctionne, les responsabilités doivent être clairement identifiées et attribuées à chacune des équipes. La maîtrise d’ouvrage est en charge des besoins et des exigences du métier vis-à-vis du produit. Elle est centrée sur l’atteinte des résultats qui ont été définis et sur l’utilisation du produit. La maîtrise d’œuvre est centrée sur le produit. Elle en fait les spécifications, la conception et la réalisation. Elle s’assure également d’en assurer la qualité.

Ensuite, les tâches de maîtrise d’ouvrage peuvent-elles être dissociées des activités du projet ? Bien sur que non ! Une gestion de projet efficace doit donc prendre en considération l’ensemble des tâches. Sur ce point, je suis parfaitement en phase avec nos amis anglo-saxons. Non seulement les tâches de maîtrise d’ouvrage et de maîtrise d’œuvre se doivent d’être intégrées dans un unique plan de projet, mais je prétends en plus qu’elles ne sont pas séquentielles mais concourantes. Elles se déroulent en même temps et s’influencent mutuellement.

Le problème est que trop souvent, chaque équipe souhaite gérer son propre prisme du projet et à sa manière. C’est ainsi que l’on voit surgir des notions bizarres de chef de projet utilisateur et de chef de projet de maîtrise d’œuvre. Un projet, deux chefs, cherchez l’erreur ! On peut comprendre un intégrateur qui nomme un chef de projet pour gérer ses équipes et ses engagements sur le projet de son client. Mais qu’elle est la valeur de ce plan de projet pour le client ? Et si j’ai plus d’un intégrateur ? Décidément, le chef de projet doit embrasser l’ensemble de l’équipe projet, maîtrise d’ouvrage et maîtrise d’œuvre confondue. Le chef de projet n’est donc pas le maître d’œuvre.

Les notions de maîtrise d’œuvre et de maîtrise d’ouvrage ont le mérite de permettre l’attribution de rôles précis réclamant des compétences distinctes. Il est seulement regrettable que, parfois, on veuille les mettre dans une relation client-fournisseur là où une relation de collaboration est tellement plus efficace.

Au vu de ces quelques réflexions, y a-t-il encore un problème pour un analyste métier de rendre compte de ses activités sur un projet au … chef de projet ? Peut-on également s’étonner qu’un dossier de spécifications détaillées, réalisé par la maîtrise d’ouvrage, pose d’énormes problèmes de prise en charge par les développeurs. Un simple cahier des charges, précisant les besoins et les attentes aurait été plus simple à produire et aurait probablement abouti à une solution plus simple, moins couteuse et peut-être même livrée dans les temps.

Finalement, vu comme cela, notre exception française n’est en rien incompatible avec les meilleures pratiques qui sont bien souvent, n’en déplaise à certains, anglo-saxonnes. Il s’agit juste d’une contribution additionnelle : The French Touch.

Dans un forum auquel je participe avec d'autres DSI, je suis tombé récemment sur la question suivante:

...
On nous en demande toujours plus avec moins de ressources, c'est une tendance normale mais qui a ses limites. Mon problème est cette limite, comment estimer la taille normale d'un service informatique ?
Je trouve peu d'informations sur le sujet, telles que taille du service par rapport à la taille de l'entreprise, son chiffre d'affaire, le nombre de postes, le nombre d'utilisateurs, le nombre ou le type d'applications en exploitation, les accès réseau, ou que sais-je encore.
...

Comme c’est effectivement un sujet récurrent, j'ai décidé de placer ici une copie de la réponse que je lui ai fournie.

A la base, c’est un problème de dosage des efforts que doit consacrer l’entreprise à son système d’information.

Une entreprise qui investit insuffisamment dans ce domaine se déforce face ses concurrents. Elle ne profite pas des gains de productivité que permet l’informatique, entre autre grâce à une meilleure circulation des informations. L’enrichissement des informations permet une gestion plus précise et des prises de décision plus pointues, plus pertinentes. Prendre du retard sur ce terrain face à ses concurrents est forcément un handicap lourd au niveau de la compétition. Des outils informatiques qui deviennent obsolètes ringardisent l’entreprise aux yeux de ses employés et de ses cadres. Ceci se traduit par une augmentation du turnover.

A contrario, l’entreprise ne doit pas investir au delà de ses moyens. Il y a un niveau de coûts informatiques à partir duquel l’impact sur les prix de revient et sur les marges devient trop sensible.

Les coûts informatiques devraient donc se situer dans une fourchette. Celle-ci est à évaluer avec la direction générale et la direction financière et est un préalable à tout cadrage budgétaire. Pour ma part, je considère que les coûts informatiques devraient généralement se situer entre 1,5% et 3% du chiffre d’affaires, en dehors de situations particulières. L’idéal est de pouvoir se comparer aux entreprises du secteur.

Dans cette fourchette, le poids relatif des différentes ressources est éminemment variable en fonction de la nature de l’entreprise et des choix qu’elle a effectués au fil des années. Par exemple, une entreprise qui mise sur des logiciels spécifiques ou libres investira plus sur les ressources humaines. Une entreprise qui mise sur les progiciels dépensera proportionnellement plus en frais de licences. Une entreprise répartie sur de nombreux sites aura des frais de réseau élevés. Mais dans tous les cas, la fourchette doit contraindre le dimensionnement des moyens informatiques.

Sur le plan des ressources humaines, il y a un autre facteur important dans le dimensionnement. C’est le ratio entre les ressources internes et externes. Selon moi, ce ratio doit tourner autour de 50/50 plus ou moins 15%, soit entre 35/65 et 65/35. Les ressources internes connaissent bien l’entreprise. Elles sont nécessaires pour garder le contrôle et la maîtrise du système d’information et de son évolution en alignement avec la stratégie de l’entreprise. Les ressources externes apportent la flexibilité nécessaire lorsqu’il faut faire varier la couverture du service en termes de lieux, d’horaires ou de compétences.

Au détour d'un blog, je suis tombé récemment sur une question concernant la structure et la gestion du budget d'une DSI et je veux reprendre ici la réponse que je lui ai faite.

Sur ce thème, dans un contexte français, je considère les travaux du CIGREF comme la référence en la matière. Je m’y réfère très régulièrement. 

Je peux toutefois essayer de résumer ce que je considère comme les fondamentaux du budget d’une DSI.

Tout d’abord, il faut adopter une triple présentation du budget : une approche par nature budgétaire, une approche comptable ou compte de résultat et une approche par client.

L’approche par nature sert à l’élaboration et la présentation générale du budget. Cette approche permet de bien appréhender les éléments constitutifs des coûts informatiques (Coûts de personnel, licences et maintenances logicielles, acquisition et maintenance du matériel, télécommunications, électricité, frais généraux, etc. ). C’est l’approche de base pour les estimations des coûts (projets) et pour les prévisions budgétaires. Dans cette approche, on garde complètement séparé les coûts récurrents et les coûts de projet. Les coûts récurrents proviennent des solutions et des contrats en place. Les coûts de projets sont estimés également par nature mais restent ventilé projet par projet. Ils sont constitués de coûts d’investissement mais également générateurs de coûts récurrents pour l’avenir.

L’approche « compte de résultat » permet de projeter les dépenses informatiques dans la comptabilité générale. Le passage d’une structure analytique par nature à une structure comptable est l’occasion de poser un certain nombre de choix de gestion : personnel interne ou externe ? Matériel acheté ou loué ? Amortissement des coûts de projet ou pas ? Ces choix de gestion sont à faire en commun avec la direction financière. Ils impactent directement l’intégration des coûts informatiques dans le compte de résultat de l’entreprise.

L’approche client consiste à ventiler les coûts informatiques entre les différents donneurs d’ordre. C’est l’approche qui permet de valider les priorités. Elle permet à chacun des donneurs d’ordre de savoir ce que coûte les systèmes d’information qu’il utilise ou les projets qu’il demande et, le cas échéant, de faire des arbitrages. Il permet également à la direction générale de vérifier que les efforts informatiques servent la création de valeur. Pour effectuer cette ventilation, on cherche à ramener les coûts à un petit nombre d’unité d’œuvres qui font sens pour le métier : Coût total d’une solution par utilisateur, par site, par société, par client, etc. Ici encore, la séparation entre les coûts récurrents (coûts de possession ou TCO) et les coûts de projet, ces derniers pouvant être rayés d’un trait de plume si on décide de ne pas lancer le projet.

La gestion du budget de la DSI s’inscrit dans le cycle budgétaire de l’entreprise. Il s’agit d’un cycle annuel dont le fonctionnement peut différer d’une entreprise à l’autre. Les deux approches sont une approche descendante qui part des objectifs de l’entreprise et qui les distribue de proche en proche dans ses différentes entités et une approche ascendante qui part des prévisions des différentes entités et qui les consolide. A ma connaissance, la démarche de la plupart des entreprises est un mixte de ces deux approches. Au niveau de la DSI, je fonctionne de la même façon avec les différents services opérationnels. En général, la phase d’élaboration budgétaire commence trois à quatre mois avant le début de l’exercice et doit être bouclée en grande partie en un mois.

Le suivi du budget est effectué à plusieurs niveaux. Les engagements sont suivis au fil de l’eau. Chaque clôture comptable (mensuelle, trimestrielle, annuelle) donne lieu à un suivi du compte de résultat. Le dernier ou les deux derniers trimestres peuvent faire l’objet d’une prévision d’atterrissage.

Le suivi des engagements au fil de l’eau consiste simplement à s’assurer de disposer du budget nécessaire avant de passer une commande. A la base, il est du ressort des responsables des différents services opérationnels de la DSI et des chefs de projet.

A chaque clôture comptable, on compare le compte de résultat de la DSI à un prévisionnel mensualisé du budget (voir plus haut le paragraphe su l’approche comptable). Les écarts sont expliqués et d’éventuelles actions correctives sont décidées.

La prévision d’atterrissage consiste à reprendre complètement l’ensemble des données prévisionnelles du budget de l’exercice à la lumière des résultats déjà engrangés pour prévoir au plus fin la situation à la fin de l’exercice. Le cas échéant, cela peut être l’occasion d’arbitrages supplémentaires. Dans les sociétés pour lesquelles j’ai travaillé, la prévision d’atterrissage de l’année en cours était synchronisée avec l’élaboration du budget de l’exercice suivant, ce qui est souhaitable car il s’agit d’un processus lourd.

L’ère de l’artisanat en matière de système d’information semble bel et bien révolue. On assiste aujourd’hui à un foisonnement de normes, recueils de meilleures pratiques et autre méthodologies qui, toutes, se concentre sur les processus SI. Le problème pour le DSI est de s’y retrouver et de savoir comment s’en servir pour organiser le travail de ses équipes et fonctionner avec ses clients. Aujourd’hui, je vous livre l’état de mes réflexions en la matière.

Je ferai un premier paquet avec les normes de management et les recueils de meilleures pratiques. Je les considère comme un socle de connaissances et de pratiques reconnues par les (vrais) professionnels du domaine. Ils sont riches en recommandations et objectifs pour l’activité de la DSI. Ils fournissent une référence pour évaluer « où on en est » sur le domaine considéré, la « maturité » de nos équipes et de notre entreprise.

Ce socle est toutefois loin de fournir des processus complets, de bout en bout, nécessaire à l’industrialisation des activités liées aux systèmes d’information. Pour trouver ce type de processus, il est nécessaire de se tourner vers les méthodes ou méthodologies. Pour autant que l’on choisisse des méthodes conformes aux normes auxquelles on souhaite se conformer, celles-ci fournissent des processus génériques pour mener les opérations.

Les méthodes ne sont toutefois pas utilisables telle quelles. Parce qu’elles se veulent universelles, elles utilisent un jargon qui n’est pas celui de l’entreprise. Elles traitent également des situations qui ne peuvent pas survenir dans un contexte particulier. A contrario, certaines spécificités propres à l’entreprise peuvent ne pas être traitées.

Pour disposer de processus réellement utilisables, il faut compléter les méthodes par des règles et des procédures internes propres à l’entreprise.

Enfin, lorsque l’on veut évaluer ses processus, ce qui compte, ce sont les activités réelles, pas la description du processus. Je résume ces différents points dans le dessin ci-dessous :

Les normes et les référentiels sont nombreux. Je me base quant à moi sur les suivants, ce qui n’a rien de très original :

• Pour la gouvernance du SI : COBIT.
• Pour la livraison des services : ITIL. A noter que ITIL est maintenant intégré dans la norme ISO 20 000.
• Pour la conception et la réalisation des solutions : CMMI
• Pour la gestion de projet : PMBOK (PMI).

Enfin, l’ensemble méthodologique auquel je me réfère est le Macroscope. Les dix années pendant lesquelles j’ai participé (bien modestement) à l’implantation et à l’amélioration de ces méthodes m’ont vacciné à vie. Cet ensemble méthodologique a été conçu à l’origine par DMR qui a depuis été intégré au sein du groupe Fujitsu.

Maintenant, que l’on parle de normes, de référentiels de bonnes pratiques ou de méthodes, il s’agit toujours d’une compilation et d’une généralisation d’une somme considérable de retours d’expériences et de connaissances. En matière d’informatique comme pour d’autres disciplines, le résultat d’un tel processus est toujours complexe. Souvenez-vous de vos cours de maths, de sciences d’économie ou de philo...

C’est la critique la plus courante des professionnels de l’informatique : « Tout cela est trop lourd ! ». A nous de leur faire comprendre qu’il s’agit là de connaissances qu’il leur faut intégrer pour développer leur compétence. Les processus appliqués dans l’entreprise se doivent d’être simples, compris et acceptés. J’ai trop souvent entendu des remarques du style : « Je fais des revues de projet parce que c’est dans la méthode. » C’est toujours le signal que quelque chose n’est pas au point. Il faut que chacun comprenne la raison d'être de ce qu'il fait, sa valeur ajoutée en quelque sorte.

La connaissance des normes et des méthodes doit être intégrée à la formation continue des professionnels de l’informatique et des systèmes d’information. Elle fait partie de nos fondamentaux. Ensuite, cette connaissance doit être exploitée dans les processus d’amélioration continue de nos façons de faire.

La gestion et le pilotage des systèmes d'information est une discipline à la croisée des chemins entre la gestion de l'entreprise et le marché de l'informatique.

De cette rencontre, sont nés et naissent chaque jour, de nouveaux concepts, de nouveaux jargons, de nouvelles pratiques mariant avec plus ou moins de bonheur les apports des uns et des autres.

Le résultat est souvent perçu comme hermétique, voire ésotérique, tant aux décideurs qu'aux professionnels. Il constitue pourtant un vaste champ de connaissances instituant nos fondamentaux en matière de systèmes d'information.

Fort de plus de 25 ans d'expérience consacrés à mettre les systèmes et les technologies de l'information au service de l'entreprise et de sa performance, j'ai construit et développé ce site pour promouvoir une approche qui exploite toute la richesse disponible tout en restant basée sur la simplicité, le pragmatisme,  la cohérence et la recherche de résultats tangibles.

Au fil des articles de ce blog, je vous livre mes clés, telles que je les utilise dans ma vie professionnelle. J'ai l'espoir qu'elles pourront être utiles à d'autres ou qu'elles feront réagir certains afin de les enrichir du point de vue d'autres experts.