Le sens de la Mesure

Dans un commentaire à un billet précédent, un lecteur dénonçait la tendance qu'ont certaines entreprises à vouloir tout mesurer ... A juste titre, car à vouloir tout mesurer, on finit par perdre de vue ce qui est vraiment important, et à mesurer sans fin au lieu d'agir (quand c'est nécessaire). Mesurer serait alors une technique habile de procrastination ...

Le problème est d'ailleurs souvent, depuis la généralisation de l'informatique, au travers des ERP et autres progiciels, que l'on a trop de données, trop de mesures, et qu'on ne distingue plus l'essentiel de l'accessoire.

Alors, que faut-il mesurer ? Quelles mesures doivent être observées ?

Je vous propose une sélection de sites de ressources gratuites en informatique, en français.

En attendant d'avoir plus de temps pour écrire de nouveaux billets, je vous recommande quelques blogs que j'apprécie :

Le blog de Florence Gillet Goinard qui aborde avec une régularité admirable (un article par semaine), les différentes aspects de la qualité (assez orientée ISO cependant) en entreprise.

Le blog très pertinent et plein d'humour de Christian Oyarbide avec des billets assez courts, mais très fréquents, sur le management.

Le blog stimulant d'Alain Fernandez sur la performance (même si le terme est de plus en plus galvaudé) , la gestion de projets, etc.

Et un dernier, celui de Jean-François OILLIC, qui aborde les différents aspect de la gestion d'entreprise et de la comptabilité, par le biais de dossiers et fiches thématiques, à la fois concis et clairs. Personnellement, ce n'est pas mon domaine, et j'apprécie énormément ces informations abordables et dans un langage clair.

Bonne lecture !

Dans mon billet précédent, j'indiquais qu'un bon indicateur devait permettre de prendre une décision. Quitte à passer du temps toutes les semaines, tous le mois, à réunir des données, les vérifier, les compiler et construire des indicateurs, autant faire que ce temps passé (qui est loin d'être négligeable) nous permette d'avoir des indications utiles pour notre activité.

Il n'y a pas que le travail (ou la recherche d'un travail) dans la vie.

Il faut savoir aussi se détendre pour être plus efficace après ... je vous propose de découvrir le blog en BD "l'actu en patates", avec ce clin d'œil sur la pénurie d'essence et la réforme des retraites

Bonne lecture !

Mardi matin (le 5 octobre 2010, précisément), sur Telematin (France 2) - eh, oui étant en déplacement cette semaine, je regarde la télé à l'hôtel - , il y avait un "sujet" sur la forte croissance (+30%) du taux de violence chez les filles. D'ailleurs, fait amusant, le reportage montrait une bagarre dans une cour de lycée, mettant en jeu... des garçons (si le taux de violence chez les filles est aussi important, pourquoi le journaliste n'a-t-il pas réussi à tourner des images avec des filles ?)

Le même jour, un article sur Rue89 relativise tout cela.

Ne connaissant pas le problème, je me garderai bien de prendre position. Cependant, du point de vue de la mesure, nous pourrions remarquer que la mesure annoncée est sans doute juste, mais qu'elle n'est pas démonstrative de la théorie qu'elle prétend démontrer, qui est (je suppose, car cette théorie n'est pas explicitée) que l'insécurité est en forte progression.

Rassuré par l'analyse de l'article de rue89 cité plus haut, je pourrai continuer à côtoyer mes filles ado sans frémir. (en réalité, je n'étais pas vraiment inquiet...)

Comme vous l'avez deviné, ce billet traite de la question suivante :

pourquoi (pour quoi) mesurer, et à quoi cela sert-il ?

pourquoi (pour quoi) mesurer ?

Quelle que soit la technique de mesure utilisée (et il y en a des quantités, dans tous les domaines), pour bien mesurer (c'est à dire que la mesure réaliser va servir à quelque chose) il faut :

1. savoir ce que l'on va mesurer (quelle grandeur)
2. ce que l'on cherche à prouver ou vérifier en mesurant cette grandeur

J'interviens de temps en temps sur des mises à jour ou évolutions de programmes réalisés par d'autres, plusieurs années auparavant. Je tombe souvent sur des programmes bancals, au comportement mal maitrisé (surtout si on a changé de compilateur entretemps).

Voici d'après moi quelques principes fondamentaux, qui facilitent la mise au point du programme, et qui permettent d'obtenir un programme stable et évolutif :

• utiliser les machines d'état pour tous les séquentiels.
• séparer les grandes fonctionnalités dans des boucles spécialisées. Cette séparation découle de l'analyse et de la conception de l'application. On pourra par exemple avoir des boucles séparées pour : la gestion des évènements utilisateurs, la gestion de l'aspect de la face avant, le séquentiel de test, la gestion des erreurs, la communication avec un PC superviseur, etc.
• utiliser une programmation modulaire, avec pour chaque module un VI 'pilote'. On peut s'aider en créant des librairies dont les sous-vis sont
• limiter l'emploi des variables, et utiliser au maximum le flux de données. Personnellement je limite l'utilisation des variables globales à des données de paramétrage, fixées au lancement du programme.

Je reviendrai sans doute sur ces différents points par la suite.

lorsque je voyage, je préfère de loin le train à la voiture. Mais hier, ma fidélité a été mise à rude épreuve. Voici une petite liste de mes (mes)aventures :

• le train Annemasse-Lyon arrive avec 10 minutes de retard (j'avais 13 minutes pour la correspondance), en effet le train était bien plein (c'était un retour de week-end), et on perdait pas mal de temps à chaque arrêt pour laisser monter les nouveaux voyageurs.
• à la gare de Lyon Part-Dieu, impossible de changer de quai : les personnes qui voulaient monter dans mon train (qui repartait dans l'autre sens) empêchaient ceux qui en descendaient de quitter le quai.
• le TGV est parti avec 10 minutes de retard (heureusement pour moi !) car une des rames de TGV avait dû être changée in-extremis pour un problème de motrice. Ceux qui comptaient manger dans le train furent contraints à la diète, car la voiture restaurant n'avait pas pu être approvisionnée.
• A l'arrivée à Paris, on nous a annoncé un retard supplémentaire de dix minutes, pour des "problèmes de circulation"

Les retards étaient faibles, me direz-vous, et le problème rencontré pour la mise en place du TGV m'a permis de ne pas louper ma correspondance...Certes, mais ce sont autant de problèmes révélateurs de processus mal maitrisés... Si on veut vraiment développer les transports en commun (pour différentes raisons, comme les émission en carbone, ou parce que ce sont des emplois non délocalisables), il faut impérativement améliorer et maitriser les processus actuels.

Ce billet est le premier de la catégorie LabVIEW, dont voici l'objectif.

Il ne s'agit pas pour moi de faire un cours sur LabVIEW dans ce blog. Cependant, assez souvent lors des formations que j'anime, des stagiaires m'amènent des problèmes concrets qui les bloquent, et en guise d'illustration, je leur propose une solution possible à partir des concepts vus en cours.

Je me suis dit qu'il pourrait être intéressant de conserver ces exemples (lorsqu'ils ne sont pas confidentiels) et de les mettre à disposition des autres stagiaires. Cette rubrique sera donc destinée à partager des exemples de codes résolvant des problèmes concrets, ainsi que des trucs et astuces utiles. Le code sera disponible au format png, en version LabVIEW 2009 (en attendant la prochaine version...), par exemple :

Pour les lecteurs qui ne connaissement pas LabVIEW, voici une rapide présentation de ce langage de programmation graphique, orienté test et mesure ...