navigation

Le stocké, le disponible, le connu et le besoin 30 juillet, 2010

Posté par dailymanager dans : communication,qualite , ajouter un commentaire

Le stocké, le disponible, le connu et le besoin dans communication informationentreprise

Le dilemne des invitations 2 juin, 2010

Posté par dailymanager dans : communication,encadrement,equipe,operations , ajouter un commentaire

Qui ne s’est jamais demandé s’il fallait ou non inviter telle ou telle personne ? Motif relationnel ou hiérarchique, toutes les raisons peuvent mener à se retrouver à des réunions zoos… et à en perdre le contrôle.

On reconnait trois grand types de réunions (note : typage non exclusif, par exemple, un comité de pilotage recouvre les trois domaines)

Chaque réunion est un cas particulier mais voici quelques point à considérer :

1 ) Inviter seulement les personnes qui peuvent contribuer à l’ordre du jour de la réunion. La multiplicité des spectateurs enlisent le processus de prise de décision ou agissent en dispersion dans les réunions d’analyse. Si trop de personnes peuvent contribuer à des points différents, il faut songer à splitter l’ordre du jour en plusieurs réunions.

2 ) Évitez de truster l’audience de la réunion avec vos alliés, comme une démonstration de force. Cette intimidation votre « adversaire » peut entraîner des contre-attaques, des représailles, ou une fausse coopération.

3 ) Évitez l’affect, l’invitation de personnes des gens parce qu’ils se sentiraient offensés si vous les laissiez de côté. Une réunion est une activité professionnelle, ce n’est pas une boom party. Vous pouvez toujours présenter à la personne que ce n’aurait pas été intéressant pour elle de regarder les autres discuter et travailler.

4 ) Assurez-vous d’inviter les parties prenantes, c’est à dire les personnes qui sont propriétaire de la question. Cette personne est une ressource précieuse pour trouver des solutions… et surtout pour conclure avec une décision.

5 ) Assurez-vous que les contradicteurs aux questions assistent à vos réunions. S’ils peuvent vous aider à trouver des solutions équitables, ils vous appuieront. Sans eux, tout résultat que vous développerez sera potentiellement refusé.

6 ) Inviter les participants ponctuels avec des petits rôles à la seule partie de la réunion où ils peuvent contribuer. Pour cela, il est indispensable de maitriser l’horaire et l’ordre du jour. Sur de grandes réunions, la reprise après une pause est le bon moment d’intervention pour un nouveau participant.

7 ) Inviter les spectateurs pour de bonnes raisons. Par exemple, vous pouvez inviter un nouvel employé pour qu’il puisse se renseigner sur une question, ou vous pouvez inclure des membres d’autres organisations pour gagner de l’empathie pour vos besoins, ou encore inviter un étranger pour stimuler la réflexion créatrice.

8 ) En général, les réunions d’analyse  fonctionnent mieux lorsqu’il y a 8 à 12 personnes. A contrario, les réunions de décision nécessitent un nombre plus restreint, entre 4 et 6 personnes, à moins que les rôles de décision soient clairement connus de chacun (responsabilité, hiérarchie, subject owner…)

9 ) Distinguer les présences obligatoires et facultatives. surtout lorsqu’il s’agit de réunion récurrentes, que chaque participant sache s’organiser et vérifier chaque fois qu’un ordre du jour le concerne.

10 ) Adaptez vous à la culture d’entreprise. Certaines personnes attendent d’être invitées parce qu’elles le sont toujours en tant que représentant d’une partie prenante. Dans certains cas, les réunions d’informations élargies sont nécessaires avant de prendre une décision au cours d’une autre réunion plus rapprochée mais dans d’autres contexte, la décision est prise avant la réunion d’information.

11 ) Ne confondez pas invitation et diffusion du compte rendu de réunion. Ce dernier peut être élargi à d’autres intervenants, absents ou débordés. La rigueur du compte rendu vous permettra alors de négocier certaines invitations si vous êtes en carence de place disponible, notamment pour les réunions d’information.

 

En savoir plus : http://www.squidoo.com/OneGreatMeeting/

Meeting invitations 23 mai, 2010

Posté par dailymanager dans : communication,contexte,operations , ajouter un commentaire

Un sujet intéressant, abordé par le toujours très bon Geek&Poke :

Meeting invitations dans communication 6a00d8341d3df553ef013480ca7e4e970c800wi

Le risque est relatif 28 avril, 2010

Posté par dailymanager dans : objectif,operations,risques , ajouter un commentaire

Le risque est relatif dans objectif 6a00d8341d3df553ef0120a6a2488d970b800wi

From Geek&Poke

Le traitement des alertes 20 avril, 2010

Posté par dailymanager dans : communication,operations,reporting,risques , ajouter un commentaire

Les processus d’escalades formalisent le chemin à suivre pour le traitement des crises et la gestion des alertes. Comme l’illustre la métaphore de l’échelle, l’information va remonter du bas vers le haut d’une organisation hiérarchique. Les barreaux de l’échelle constituent des paliers de traitement.

Dans la majorité des cas, les processus d’escalades sont déclenchés par des collaborateurs de terrain, qui souhaitent sensibiliser sur les impacts opérationnels d’une prise de décision.

Une alerte attend une réponse.

Il est contre productif de ne pas traiter les alertes remontées par ses équipes. Faute de quoi, un manager peut perdre toute la confiance de ses subordonnés, puis peu à peu perdre le contact avec les opérations. Le traitement doit être à minima une notification de prise en compte.

Comme un non-traitement déresponsabilise l’opérationnel, ouvrant la voie à la fameuse sentence « j’avais prévenu », en conséquence, le jeu revient à submerger son manager de toutes les alertes possibles, comme autant de bouteilles à la mer. En d’autres termes, alors qu’on voulait peut être la faire taire, la source devient intarissable et incontrôlable.

Une alerte peut aider à identifier un risque.

Pour leur traitement, on peut associer la remontée d’alertes et l’identification des risques. Le traitement de l’alerte consiste alors à l’inclure, formalisée, dans un tableau de suivi des risques. Ayant généré une entrée tracée, l’alerte peut être considérée comme traitée. Ce traitement administratif peut faire gagner du temps à un manager, mais à terme, il peut s’avérer plus frustrant qu’autre chose. Surtout si le risque n’est pas traité à son tour, et qu’il est systématiquement accepté… ou minimisé.

Par ce principe simple, un manager signale à ses équipes qu’il prend en compte leurs alertes, mais qu’il les filtre et les regroupe selon sa propre compréhension de la situation. Il peut notamment exister des risques plus globaux, qui ne sont pas du ressort du manager, en particulier les problématiques organisationnelles, ou bien des risques qui cachent des suggestions d’amélioration d’une pratique ou d’un processus.

Dans le cas des alertes difficilement associables à des actions préventives et/ou des actions correctives, si le risque identifié n’est pas accepté ou acceptable, une alerte vers un échelon supérieur de la hiérarchie nécessite d’être levé à son tour.

Une alerte ne se transfère pas.

Les barreaux du processus d’escalade constituent des paliers de traitement. Et non pas de transfert. Lorsque l’on traite une alerte d’un subordonné pour saisir sa propre hiérarchie, il est fondamental de se l’approprier et d’enrichir le sujet. Il y a quelque chose de darwinien : si un acteur n’apporte pas de valeur ajoutée, à terme, il est court-circuité. On peut par exemple à cette occasion synthétiser les alertes qui vont dans le même sens, ou souligner celles qui sont des causes principales et non des conséquences.

Comme un journaliste ne révèle jamais ses sources, la manager doit penser à protéger sa propre équipe et devenir l’interface d’une crise potentiellement déclenchée. A proscrire, donc, les alertes de type « intel m’a dit que ». Le principe est le même qu’en journalisme : en exposant une source d’information, on perd sa confiance puis on la tarit. Je pense en particulier aux opérationnels, qui peuvent soulever une alerte sans disposer du temps de formalisation et de négociation nécessaire à sa résolution. Si l’alerte redescend en bas de l’échelle… l’effet boomerang est forcément pavlovien. Un reflexe à proscrire : le mail forwardé…

Une alerte se formalise.

Si les coups de fils spontanés peuvent apporter une résolution rapide, ne pas se priver, mais dans ce cas, il s’agira plus d’une confirmation que d’une vraie alerte nécessitant réflexion et décision. Les cas assez complexes peuvent par contre amener plus de confusion qu’autre chose. Si le coup de fil est nécessaire pour sensibiliser un interlocuteur, il doit ensuite donner lieu à une formalisation écrite.

Trois principes de base doivent alors être respectés :

  1. Rester factuel : pas de bouffée de pessimisme ou de découragement, pas de jugement de valeur.
  2. Etre force de proposition : donner des pistes de résolution, et si possible une matrice SWOT.
  3. Formaliser votre attente : demandez un arbitrage, une prise de décision dans un délai raisonnable.

Si le sujet reste très pointu, et que vous ne pouvez pas en maitriser les tenants et aboutissants, vous pouvez demander à votre source de participer à la formalisation et aux débats. En reprenant l’exemple du journalisme, le seul cas envisageable d’une exposition de la source, c’est pour mettre en avant un profil d’expertise, apportant légitimité et fiabilité à l’information. Mais dans ce cas, l’exposition a nécessité un accord préalable.

Une alerte reste rare.

Une remontée trop fréquente d’alertes peut mener une hiérarchie à considérer que la situation est mal gérée et hors de tout contrôle.

Le processus d’escalade doit être utilisé avec parcimonie : il mobilise du temps de la hiérarchie et doit se justifier. Par exemple, s’il s’avère qu’une alerte est moteur d’amélioration continue, il est préférable de la mentionner au cours des comités de pilotage ou du retour d’expérience.
D’un point de vue opérationnel, attention à l’autre extrême, qui consiste à officialiser un bureau des pleurs : toute alerte ne doit pas déclencher une action, mais au minimum une notification de compréhension. Notamment quand une alerte rejoint un risque déjà identifié et couvert, il faut l’expliquer et communiquer. Un manager peut aussi expliquer à ses équipes les limites de sa marge de manoeuvre, car il y a parfois les contraintes qu’il faut bien finir par accepter !

L’interprétation des indicateurs 16 février, 2010

Posté par dailymanager dans : communication,efficacite,reporting , ajouter un commentaire

Même les meilleurs indicateurs restent dépendants d’une bonne analyse.

L'interprétation des indicateurs dans communication geluck1225880648

Quels indicateurs d’efficience d’un SI ? 11 février, 2010

Posté par dailymanager dans : communication,efficacite,objectif,reporting , ajouter un commentaire

Pour s’y retrouver dans une jungle de chiffres qui peuvent tous donner lieu à des interpretations contradictoires et des débats sans fin, tâchons de les catégoriser par grand domaine de valeur ajoutée d’un Système d’Informations

1- La première catégorie regroupe les tableaux de bord de la fonction système d’information, au sens de l’alignement avec les métiers. Il s’agit d’indicateurs portant sur l’avancement des grands projets, mais aussi la contribution de la DSI à l’innovation, à la gestion des risques, au management des processus, à la relation avec les fournisseurs. Bref, tout ce qui est relatif à un Plan d’Action Stratégique Systèmes d’Information.

2- Le second groupe cible les tableaux de bord de l’IT, au sens des exigences technique. Ils concernent les indicateurs opérationnels liés au fonctionnement et à la continuité du service. Il s’agit par exemple de la disponibilité des applications, les temps de réponse, le nombre d’incidents et leur répartition, les délais moyens de résolution, les mises en production refusées pour non-conformité.

3- En troisième lieu viennent les tableaux de la DSI, au sens de la fonction organisationnelle. On y retrouvera des indicateurs tels que ceux relatifs aux ressources humaines. Ils comprennent en outre les indicateurs liés à la formation et l’expertise des collaborateurs ainsi que la communication avec les utilisateurs à travers les récurrentes enquêtes de satisfaction.

4- Pour finir, nous avons les tableaux de bord de suivi des budgets, au sens du bilan financier. Ils vont du suivi de la facturation jusqu’au recouvrement des prestations, de la maîtrise et de la linéarité des budgets.

(librement inspiré de la méthode Gimsi, qui sépare Stratégie, Technologie, Hommes et Structure)

Selon chaque culture d’entreprise, de par la relation établie entre les métiers et la DSI, certains domaines sont plus surveillés que d’autres. Au cours de mes missions, j’ai pu observer un attachement classique aux exigences techniques (2) via une faible tolérance aux incidents de la part des métiers (justifiée ou non). J’ai également constaté que dans certains cas, la présence d’une justification de type stratégique (1) suffisait à masquer tous les autres indicateurs financiers (4). Enfin, la fonction organisationnelle (3) est souvent le parent pauvre des indicateurs. Des jeux de pondération qu’il convient de manier avec prudence et qui ne durent pas bien longtemps.

Mais celui que ne pilote que par les indicateurs, fussent-ils prospectifs, risque de rencontrer quelques déboires. La crise peut être considérée comme une opportunité par les DSIs pour accélérer leur repositionnement en mettant en valeur leur apport potentiel à la valeur ajoutée par le biais d’exemples précis et parlants. Réussir dans cette démarche est complexe, car cela implique  transparence et relation équilibrée dans une logique de collaboration entre métiers et DSI.  Ce que ne cherchent pas toujours les autres directions qui peuvent préférer privilégier un niveau de  domination à travers leur rôle de commanditaire reléguant de facto la fonction SI à un centre de coûts.

Jean-Pierre Corniou [ex-DSI de Renault] décrivait très bien ce phénomène à travers une formule lapidaire : « Individualiser les coûts [sur la DSI] mais collectiviser les gains [du côté des métiers] »

La recherche des bons indicateurs est donc une quête du Graal qui va suivre un nouveau chapitre du fait de la tension des exigences dans un contexte de crise. L’efficience du SI passe à nouveau à la loupe.

Le ROI déchu ? 7 février, 2010

Posté par dailymanager dans : objectif,projet , ajouter un commentaire

Le retour sur investissement (ROI) est un des indicateurs clefs permettant aux décideurs et investisseurs de savoir si un projet en vaut la chandelle.

Purement financier, il est calculé à partir de la moyenne pondérée du coût des capitaux propres et de l’endettement net relatif au projet, soit l’investissement, auquel s’ajoutent les gains attendus, soit la trésorerie nette dégagée annuellement. Le ROI vise à s’assurer de la rentabilité financière d’un projet.

Il faut dire que d’un point de vue financier, l’indicateur est séduisant, reléguant ainsi la décision et son risque dans une formule de calcul. Mais si le ROI a séduit les directions générales et les DSI qui l’intègrent explicitement dans leurs contrats de prestation de services, en informatique, son calcul est plus discutable, tenant autant aux spécificités métiers des systèmes d’informations qu’à des difficultés de communication.
L’informatique reste un support au service des autres département, et dans cette dépendance, des coûts et des bénéfices cachés sont déjà difficile à percevoir, alors quant à chiffrer… Ces masques dépendent de chaque spécificité métier, par exemple, des coûts d’appréhension des utilisateurs, ou des bénéfices de satisfaction client et d’image… et de la qualité, l’évolutivité, cette notion difficile à chiffrer au delà du strict coût financier de maintenance d’un système.

Signe des temps, alors que l’indicateur a été mis en avant pour la promotion des nouvelles technologies et de l’e-commerce en particulier, le ROI est maintenant désaffecté par les Directions des Services Informatiques. Les experts y voient une difficulté de communication, car si l’on voit facilement l’investissement, le coté gain peine à être chiffrer quand il ne s’agit pas d’une prise de nouveau marché. Si le vrai retour sur investissement est à trouver coté utilisateurs, la DSI ne dispose pas toujours de toutes les données financières lui permettant de calculer le retour sur investissement, comme le coût du personnel et la valeur des amortissements.

Sans rentrer dans les cas particuliers, la typologie des projets influence beaucoup le mode de calcul, à tel point qu’il est rapidement impossible de comparer deux indicateurs ROI entre eux. Projets réglementaires, projets stratégiques, projets innovants… alors que de l’autre coté, projets techniques ou projets de processus se prêtent bien au jeu du calcul car on maîtrise l’ensemble des paramètres.

Autre facteur de limitation du ROI, son absence de pertinence en dehors du strict contexte d’une entreprise. La dépense correspond à ce que la DSI met en oeuvre, les écarts entre différentes cultures d’entreprise rendent la comparaison inutile : l’unité d’oeuvre n’est pas sécable du processus de gestion auquel elle est associée. En d’autres termes, on peut arrivre à la conclusion qu’une projet n’est pas viable alors que c’est la gestion de projet qui fait défaut qui coûte trop cher.

En avant vente ou en pré étude, si le calcul du ROI est déjà très discutable, il faut aussi reconnaître que son calcul à posteriori n’a guère plus de valeur. Le retour d’expérience constate souvent son incapacité à dissocier  l’ensemble des paramètres impactés par un nouveau produit informatique. En cas de progression des ventes après la mise en place d’une nouvelle application, il est difficile de mettre en avant le système d’information : la réussite sera attribuée aux vendeurs… et ce débat peut devenir très vite conflictuel au sein d’un comité de direction.

Force est de constater que le ROI ne permet pas de saisir réellement ce que le système d’information apporte aux métiers. Il reste un indicateur, mais au sens péjoratif du terme… si tant est qu’on considère par exemple un vrai KPI mesurable comme un indicateur « noble ».

Le ROI déchu ? dans objectif roi

Dorénavant, comme toute gouvernance et toute communication repose sur la présence d’indicateur fiables, le ROI est de plus en plus substitué par de multiples indicateurs qualitatifs, notamment sur des projets spécifiques où l’informatique s’inscrit dans un chantier plus vaste.

Pour prendre en compte les coûts et les bénéfices cachés, il convient en effet d’élargir la vision de l’indicateur purement financier à un aspect plus large, capable de prendre en compte la valeur ajoutée que le projet informatique va apporter à l’entreprise. Il faut pour cela travailler main dans la main avec les directions métiers : études de satisfaction, niveau de prestation de service, et surtout, maintenabilité et agilité du système. (*)

L’objectif est dans la majorité des cas, de rester agile malgré la croissance des systèmes. Une impulsion pour des usines de développement rapide d’applications, de gestion de projets et de métrologie.

D’où l’importance de normer, d’apprécier le coût de l’outillage informatique des processus métier, et de mesurer l’évolution de ce coût dans le temps. Mais force est de constater que nos dirigeants raisonnent beaucoup en terme de business unit et hiérarchie fonctionnelle, et ont encore du mal à entrer dans une logique orientée processus, plus transverse.

 

En savoir plus : http://fr.wikipedia.org/wiki/Retour_sur_investissement

http://solutionspme.lemondeinformatique.fr/articles/lire-le-retour-sur-investissement-est-plus-qu-un-simple-calcul-90.html

 

(*) Une stratégie se déclinant en objectifs et parfois en intéressement, pour favoriser le maintien des performances, les ingénieurs d’Orange bénéficient d’une une part variable indexée sur les résultats ainsi relevés. La supervision de la qualité de service repose un suivi de la performance informatique des systèmes, comme un temps de réponse en fonction de la criticité d’un bogue, combiné à des sondages réalisés auprès des clients finaux.

1968 : Loi de Conway 23 novembre, 2009

Posté par dailymanager dans : amelioration,changement,histoire,risques , ajouter un commentaire

Loi de Conway est un adage du nom de programmeur informatique Melvin Conway, qui a introduit l’idée en 1968:

« Les organisations qui conçoivent les systèmes … sont contraintes de produire des modèles qui sont des copies de leur propre structure de communication »

La droit de Conway peut être illustrée et simplifiée comme suit : deux modules logiciels A et B ne peuvent pas correctement s’interface l’un avec l’autre, à moins que le concepteur de l’implémentation de A communique avec le concepteur et exécutant de B. Ainsi, la structure d’un système logiciel en tant que qu’intégration de composants va se montrer révélateur de la structure sociale de l’organisation qui l’a produit.

Exemples de loi de Conway
Considérer un grand système S que le gouvernement veut construire. Le gouvernement engage la société X pour construire le système S. La société X possède trois groupes d’ingénierie, E1, E2 et E3, qui participent au projet. La loi de  Conway donne à penser qu’il est probable que le système se composera de 3 principaux sous-systèmes (S1, S2, S3), chacun construit par l’un des groupes d’ingénierie. Plus important encore, les interfaces qui en résultent entre les sous-systèmes (S1-S2, S1-S3, etc) reflète la qualité et la nature de la communication interpersonnelle entre les groupes d’ingénierie respectives (E1-E2, E1-E3, etc.)

Un autre exemple: soit une équipe de deux personnes d’ingénieurs logiciels, A et B. Supposons que A conçoive et développe une classe de logiciels X. Plus tard, l’équipe découvre que la classe X a besoin de quelques nouvelles fonctionnalités. Si A ajoute les fonctionnalités, A est susceptible d’étendre simplement X pour inclure les nouvelles fonctionnalités. Si B ajoute les nouvelles fonctionnalités, B ne prendra pas de risque de régression sur X, et donc à la place va créer une nouvelle classe X2 dérivée de X, héritant de caractéristiques X, et portera les nouvelles fonctionnalités dans X2. Donc, dans cet exemple, le plan final est le reflet de l’organisation opérationnelle qui a mis en œuvre la fonctionnalité.

 

1968 : Loi de Conway dans amelioration climateorbiterbrowse

Mars Climate Orbiter s’est écrasé parce que l’équipe a utilisé des unités des États-Unis d’usage (par exemple, pouces, pieds et livres) tandis que d’autres unités de mesure ont été utilisées par une équipe sur des composants périphériques. Cette information était essentielle pour les manœuvres de placement de la sonde sur son orbite de Mars. «Les gens font parfois des erreurs», a déclaré le Dr Edward Weiler, administrateur associé de la NASA pour les sciences spatiales. «Le problème ici n’est pas l’erreur, il a été l’échec de l’ingénierie des systèmes de la NASA, ainsi que les contrôles dans nos processus afin de détecter l’erreur. C’est pourquoi nous avons perdu le vaisseau spatial.»

 

Il existe des preuves de la loi de Conway qui ont été publiées par une équipe de chercheurs de Harvard Business School. Leur étude révèle des différences significatives dans la modularité des architectures : les équipes distribuées ont tendance à développer plus de produits modulaires.

Cette loi peut être interprétée comme humoristique, dans la mesure où les organisations rigides qui ne sont pas disposés à se ré-organiser pour produire une conception optimale, peuvent finir par produire un sous-design standard qui ne fait que refléter l’organisation pré-existante. Mais l’essence de la loi de Conway s’applique aussi aux organisations flexibles qui sont prêts à ré-organiser pour produire une conception optimale.

Par exemple, considérons une entreprise flexible qui est chargé de concevoir une voiture, et l’entreprise ne dispose pas encore d’organisation d’une voiture de conception. La conception de la nouvelle organisation sera vraisemblablement composée de groupes qui correspondent aux principales composantes d’une voiture: moteur, le corps, la transmission, intérieur, électriques, etc.
L’essence du droit de Conway s’applique même à cette réorganisation: les composants et les interfaces de la voiture qui en résultent reflètent les groupes d’ingénierie et de leurs interfaces.

Et, fait significatif, tout manquement aux relations interpersonnelles entre les groupes d’ingénierie, se manifestera d’une lacune de la conception qui en résultent.

En savoir plus : http://en.wikipedia.org/wiki/Conway%27s_Law

Quels KPIs ? 21 novembre, 2009

Posté par dailymanager dans : demarche,objectif,reporting , ajouter un commentaire

On peut douter de l’existence d’indicateurs de performance clés parfait. Voici une liste qui peut aider à évaluer la qualité de la mise en place de KPIs. 

Un bon KPI doit être :

  1. Stratégique – indiquer un aspect important de la performance de l’organisation
  2. Référent – indiquer certaines pratiques et actions à mener à court terme
  3. Rapide – rapidement indiquer si des mesures ont été couronnés de succès    
  4. Disponible – exige un faible effort pour être recueilli
  5. Accepté – être considéré comme pertinent par consensus entre ceux qui travaillent dans l’organisation
  6. Cohérent – être définie exactement de la même façon par tout le monde qui l’utilise
  7. Indiscutable – ne doit être influencé que le comportement de l’organisation mesurée, et non par autre chose   
  8. Transparent – être sans ambiguïté dans la manière dont il a été rapporté
  9. Sans effets secondaires – l’objectif n’est pas d’améliorer la mesure  
  10. Sous réserve – sous réserve de validation externe dans le but d’évaluer la performance

 

Quels KPIs ? dans demarche kpi

En savoir plus : http://dailymanager.unblog.fr/2008/12/30/key-performance-indicators/

12345...7

sitehgeo4 |
"L'arbre qui tombe peut fai... |
Dra. Monica Guia |
Unblog.fr | Créer un blog | Annuaire | Signaler un abus | citoyen
| Petite écologie d'un insect...
| SonyaT