@SURTITRE:EVALUATION DE PERFORMANCES

@TITRE:Comment faire (ou pas)

du benchmarking

@CHAPO:Sans en attendre des miracles ni sous-estimer ses coûts, les DSI ont intérêt à pratiquer le benchmaking. Au moins quand elles veulent faire changer le choses.

@TEXTE:Le mot benchmarking ne se traduit pas. D'autant moins que les anglo-saxons lui ont donné un sens éloigné de ses origines (banc d'essai) pour en faire une méthode de comparaison des entreprises entre elles. Une méthode féconde consiste en un regroupement, sous l'autorité d'un intervenant extérieur, de plusieurs firmes désireuses d'améliorer leurs performances en matière informatique. Chacune se décrit suivant un système plus ou moins formalisé de mesures et d'indicateurs. L'intervenant fait la synthèse des résultats, et chacun peut se comparer au groupe, au meilleur suivant tel critère, etc.

Les définitions continuent d'évoluer, traduisant parfois des ambitions excessives, comme "approche structurée pour apprendre des autres et appliquer leur savoir faire" (Ford). On voit d'emblée les limites de la méthode: l'entreprise qui se sait performante ne donnera aucune indication qui pourrait favoriser ses concurrents. Soit elle ne communique pas. Soit, pire, elle fournit des données fausses, en général par excès d'optimisme.

@INTER:Et pourtant, il faut le faire!

@TEXTE:Et pourtant, la démarche s'impose parfois. D'abord parce que la fourchette performances/non-performances s'ouvre toujours plus largement. Il y a dix ans, pour une fonction informatique donnée, 80% des entreprises s'écartaient de plus ou moins 30% par rapport à la moyenne, avec un écart d'un facteur 2 entre les valeurs extrêmes. Aujourd'hui, ce facteur est passé à 4, voire bien au-delà en matière de développement. Il y a donc de fortes chances qu'un benchmarking mette le doigt sur des domaines où l'on peut espérer des améliorations très sensibles ("dramatic" dirait un gourou américain).

D'autre part les responsables informatiques ne communiquent pas assez entre eux. Ils se rencontrent dans des séminaires, lisent des reportages dans la presse spécialisée, participent à des clubs animés par les constructeurs ou à des associations comme le Cigref. Mais les orientations qu'ils y trouvent ne se prêtent pas directement à une mise en oeuvre précise. Alors qu'un benchmarking bien piloté cernera de près les problèmes concrets des participants.

@INTER:De la mesure à la communication

Le benchmarking est lourd et cher. Le premier dure environ six mois, et consomme du temps en interne et par appel aux spécialistes externes: définition d'objectifs, sensibilisation, collecte, corrections. Une opération trop rapide ne fournit que des résultats "fades", imprécis. Bref, il faut y aller carrément ou pas.

Les principaux critères à définir sont le périmètre (fonctions étudiées), la notion d'iso-service (niveau de qualité d'une fonction), le prestataire externe, la composition du groupe (parfois, la comparaison avec les résultats d'une SSII performante donnent des résultats suffisants, par exemple).

Il s'agit moins de savoir que d'agir. Le DSI doit s'impliquer dans la recherche des informations. Bien plus que la note obtenue par tel autre membre du groupe ou par "l'entreprise de référence", il est intéressant de connaître les solutions mises en place ailleurs.

Le benchmarking évalue l'opportunité d'un changement important, et permet alors de le justifier, vis à vis des "clients internes" aussi bien que des équipes concernées ou des contrôleurs financier. Il conduit souvent à une sous-traitance. Si elle reste partielle, la DSI s'en trouvera renforcée par un contrat bien négocié. L'opération protège aussi la DSI contre des sous-traitances négociées directement par une direction utilisatrice avec une SSII externe, qu'il s'agisse de développement ou d'exploitation.

Les résultats obtenus nourrissent donc, tout naturellement, le "magazine interne" que toute DSI devrait publier au sein de son entreprise. Outil de mesure et de diagnostic, orientation pour l'action, le benchmarking découche donc sur la communication. Ce n'est pas son moindre mérite. @SIGNATURE:PIERRE LAIGLE et MARTINE VINCOTTE, KLC

@ENCADRE TITRE:LES INDICATEURS CLASSIQUES

@ENCADRE TEXTE:

- Satisfaction client. Très à la mode dans les SSII. Cet indicateur exige des documents définissant le niveau de service contractuel, un système de notation régulièr par les utilisateurs, un système de mesure automatique et non subjectif de la qualité fournie, une procédure d'explication aux utilisateurs des écarts de qualité constatés.

- Tarifs unitaires par unité d'oeuvre utilisateur. Vraiment pertinents, ces indicateurs donnent par exemple le coût de traitement d'une facture, d'une transaction. Ils doivent s'appliquer à des services ayant le même niveau de fonctionnalités.

- Tarifs unitaires par unité d'oeuvre technique. Ce pis-aller reste utile quand les indicateurs précédents ne sont pas disponibles. Exemples: coût d'une journée d'étude, coût de la gestion d'un poste de travail, coût d'unités techniques stables (Mips en central, giga-octets sur disques, pages éditées).

- Qualité, notamment de l'accueil et du support.

- Flexibilité. Capacité à prendre en compte rapidement des demandes d'évolution.

- Standards: réversibilité, non dépendance.