navigation

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

Signal d’alerte 21 avril, 2010

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

Signal d'alerte dans operations alertesirenesb

 

Ne pas oublier qu’une alerte émet aussi un signal de fin !

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’importance des indicateurs 16 février, 2010

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

C’est en étroite relation avec mon thème du moment, alors pourquoi se priver ? Une fois de plus, je vous renvoie à un article de l’excellent blog de

http://management.about.com/od/metrics/a/Measure2Manage.htm

Un tableau de bord DSI 11 février, 2010

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

A- Indicateurs financiers et stratégiques

Efficacité des investissements informatiques
- Budget IT / EBE (exédent brut d’exploitation)
- Budget IT / charges d’exploitation
- Budget IT / investissements globaux
- Budget IT / effectif IT
- Budget IT / effectif global
- Salaires IT / masse salariale globale

Répartition du budget IT
- Budgets « matériel », « logiciels », « services », « rémunérations » et « formation » / budget IT
- Budget matériel : part des achats et des locations
- Budget logiciel / budget matériel
- Budgets liés aux consommables

Contrôle de gestion
- Suivi des refacturations des prestations réalisées aux entités « métier »
- Suivi des marges et du résultat d’exploitation IT
- Dépenses par projet
- Calcul de coût de revient des produits informatiques (TCO)
- Calcul du coût des activités (Méthode ABC)

Stratégie
- Suivi du respect du « business plan » de l’entité IT
- Suivi des investissements, capacité d’autofinancement
- Gestion prospective et fidélisation des ressources humaines

B- Support / Maintenance

Help Desk (interne ou externe)
- Coût de l’assistance aux utilisateurs
- Nombre de tickets ouverts / population concernée ou effectif global
- Nombre de tickets / effectif help desk
- Nombre et durée moyenne des appels
- Nombre de questions définitivement traitées / en attente / non résolues

Satisfaction des utilisateurs
- Par questionnaire, enquête, sondage : réactivité, pertinence, délais…
- Identification des besoins en formation

Maintenance – Inventaire et suivi des contrats en cours
- Taux de panne et coût des interventions par utilisateur ou service
- Nombre et durée moyenne des interventions
- Coûts des interventions par type (télé-maintenance, déplacement sur site, nombre de personnes mobilisées)

C- Exploitation

Réseaux et systèmes
- Suivi de la charge
- Temps de réponse
- Disponibilité de la bande passante
- Temps de rétablissement en cas d’incident
- Besoins à venir

Applications
- Disponibilité des applications
- Suivi des erreurs et pannes
- Cycle de vie des applications

D- Gestion de parc

Parc matériel et applicatif
- Suivi de l’inventaire matériel et applicatif
- Suivi de l’obsolescence du parc matériel
- Nombre de postes / effectif global ou par département
- Applications les plus utilisées
- Adéquation logiciels installés / matériel
- Nombre d’imprimantes / département

Sécurité
- Suivi des dispositifs installés (anti-virus, anti-spam, anti-intrusion, etc.)
- Suivi des patchs applicatifs installés ou à venir
- Suivi et hiérarchisation des alertes
- Date du dernier audit de sécurité effectué

E- Gestion de projets

Projets internes
- Etat du portefeuille de projets
- Prévision de la demande de projets
- Respects des processus internes
- Suivi des engagements, en termes de délais, de livrables, de ressources et de coûts
- Comparaison budget/réalisé

Prestataires
- Suivi des objectifs, dates clés, responsabilités et, le cas échéant, des pénalités
- Suivi de la maintenance applicative
- Suivi du reporting

 

En savoir plus : http://www.journaldunet.com/solutions/0409/040924_panorama_indicateurs_dsi.shtml

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.

Nécessité opérationnelle 1 janvier, 2010

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

En prenant les rennes de EADS, on rapporte que Louis Gallois se serait exclamé : « comment une telle organisation peut elle faire voler des avions ? » Il faut dire qu’en matière de pilotage, cette entreprise à deux têtes ressemble plus à un montage politique qu’un attelage opérationnel. Et c’est parce qu’il ne faut donc pas chercher à la tête la lien directe du succès de cette entreprise de haute technologie.

Sur le terrain peut opérer un facteur supplémentaire, souvent caché ou inconscient, qu’on nommera la nécessité opérationnelle. Il s’agit de ce surplus d’énergie et de motivation qu’un membre d’un équipe va soudain déployer pour mener à bien un projet pendant les phases à haut risque, et notamment juste avant qu’il rentre dans le mur.

Cette force n’est pas facile à appréhender d’un point de vue extérieur : quand il faut passer dans le concret, il n’y a que les personnes de terrain, qui, finalement, savent ce qu’il faut faire et comment le faire rapidement. Dans ce cadre, c’est sur le dernier maillon opérationnel qu’on transmet la mission opérationnelle et la charge qui en résulte.

Dès lors, pour ce dernier maillon, qui devient de plus en plus critique, il devient une nécessité que les choses se passent opérationnellement le mieux possible, menant à bien le projet sur les quelques mètres du danger. Sur ces derniers mètres, il y a le livrable et sa qualification, ultime étape du projet : auparavant on aurait pu cacher ou se tromper sur l’avancement, mais dans les derniers mètres, c’est du concret et du factuel. C’est la nécessité opérationnelle qui prend alors le contrôle des opérations. Déploiement d’heures supplémentaires, pilotage direct des équipes, centralisation et reformalisation des informations, ce maillon peut alors court-circuiter certains processus organisationnels s’accaparant alors, par nécessité, certains rôles qui n’étaient pas les siens, avec la charge et la rancoeur qui va avec. Paradoxalement  d’ailleurs dans le domaine professionnel, cette prise de pouvoir est acceptée par l’ensemble des autres acteurs, qui, il faut bien le dire, font ainsi aveu d’impuissance temporaire. Encore faut il s’en rendre compte, car cet aveu est temporaire : la reprise en main et  la négation de cette épisode suivra très rapidement.

Mais comment la nécessité opérationnelle est elle déclenchée ? La question de la motivation est la plus difficile à résoudre. Comment cette ressource critique peut il opérer dans les faits ? Pourquoi ce déploiement volontaire et spontané d’une telle énergie ? Contrairement aux principes de la pyramide de Maslow, ce n’est pas une raison bassement matérielle (pas de prime à miroiter) ou de besoin de sécurité (pas de menace de licenciement) ou de besoins sociaux (pas de promotion au mérite) mais peut être un simple besoin d’estime (légitimité par le respect) ou d’accomplissement personnel (conscience professionnelle). Les managers sont plutôt les premiers surpris et les premiers à freiner : même si,  finalement, ils ne renoncent pas aux objectifs qu’ils ont donnés. De plus, les autruches, qui, temporairement, ont plongé la tête dans le sable le temps que la crise passe, ne tarderont pas à ressortir leur bec. La motivation n’est donc pas un calcul comme un ROI : l’opérationnel impliqué ne se fait, en général, aucune illusion sur la reconnaissance de son travail. C’est pour lui une nécessité et non pas une opportunité. Et si on constate une relative usure, il faut bien reconnaître que à la prochaine crise, il replongera, presque par réflexe : parce qu’il faut bien que quelqu’un fasse ce qu’il faut faire !

1979 : Loi de Hofstadter 23 novembre, 2009

Posté par dailymanager dans : efficacite,encadrement,histoire,operations , ajouter un commentaire

La loi de Hofstadter (ou Loi de glissement de planning) est une loi empirique concernant la difficulté de la planification dans le domaine de la recherche et du développement. Elle est typiquement constatée dans la gestion de développements logiciels.

La loi de Hofstadter déclare que :

« Ça prend toujours plus de temps qu’on croit, même en prenant en compte la loi de Hofstadter. »

Cette loi a été énoncée par l’universitaire américain Douglas Hofstadter dans son oeuvre-phare, Gödel, Escher, Bach, les brins d’une guirlande éternelle (Gödel, Escher, Bach: An Eternal Golden Braid[1]) (1979, Prix Pulitzer en 1980). Derrière une formulation facétieuse, la loi de Hofstadter rend compte d’une difficulté universelle : il est pratiquement impossible de prévoir le temps qui sera nécessaire à l’accomplissement d’une tâche complexe. Cette impossibilité est mise en exergue par le caractère auto-référentiel de la phrase qui se cite elle-même : de ce fait, elle introduit l’imprédicativité ou « raisonnement en boucle ».

Dans les développements informatiques les méthodes agiles prétendent prendre en compte la difficulté évoquée par la loi de Hofstadter.

En savoir plus : http://en.wikipedia.org/wiki/Hofstadter%27s_law

12345

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