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 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’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

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

Quels indicateurs d’efficience d’un SI ?

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.

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 !

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

1979 : Loi de Hofstadter

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

1234

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