navigation

Human Interaction Management 20 août, 2008

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

Quel titre ambitieux ! La gestion des interactions humaines… ça sent le bingo bullshit à plein nez !

Le courant de l’HIM (Humain Interaction Management) est né fraîchement, dans les années 2005. Vous vouliez du moderne, alors vous êtes servis ! Il s’agit d’un ensemble d’assertions, qui considère que le service rendu à un tiers ne se réduit pas à sa simple réalisation et/ou exécution, mais s’étends plus largement au travers d’un réseau d’interactions humaines. Fortement associé aux approches BPM (Business Process Modelling) pour ceux qui ont déjà mis un pied dans le monde de la SOA, l’HIM cherche à rendre ce réseau efficace, et à améliorer les articulations humaines dans ces processus. L’HIM s’articule autour de 5 principes fondateurs :

  1. Rendre visibles toutes les connections : pour travailler en équipe, vous devez savoir qui sont vos partenaires, leurs capacités, leurs responsabilités .
    « You need Role and User objects, both instances and types, each with its own properties and responsibilities. »
  2. Structurer les échanges d’informations : pour permettre l’interactivité complète, la communication doit être standardisé et « goal-directed » (j’arrive pas à traduire… franc ? direct ? sans fioriture ?)
    « You need Interaction objects in which there are multiple asynchronous channels, each for a different purpose. »
  3. Matérialiser l’intellect : les organisations doivent gérer le temps et les efforts intellectuels que les équipes investissent dans la recherche, la comparaison, la décision, et tout ce qui transforme une connaissance en idée.
    « You need Entity objects that can be created, versioned and shared in a structured way. »
  4. Préférer une gestion des activités a posteriori : les collaborateurs n’enchaînent pas leurs actions comme des automates, mais il y a une cohérence au travail humain, qui peut être analysée et améliorée.
    « You need State objects that can both enable and validate Activity objects, along with the Roles that contain them. »
  5. Formaliser les processus qui s’autogèrent (« processes changes processes« ) : les activités humaines sont structurées par de processus propres, que ce soit création, résolution, décision ou action pure. Quelquefois même on se pose la question du comment avant du quoi !
    You must be able to manipulate not only objects but also user interfaces and integration mechanisms via the process that contains them.

Bon, ça c’est pour la théorie. Je crois que j’en ai perdu déjà pas mal en cours en route. Accrochez vous, relisez autant de fois que nécessaire ! Ce sont juste les 5 principes qui caractérisent « le travail en équipe »… ce concept très vague a enfin une définition intéressante.

En plus de ces principes assez « trendy », l’HIM nous offre une méthodologie pour mettre cela en pratique : GOOD, Goal-Oriented Organisation Design, qui combine différentes approches.

En d’autre termes,  ces trois approches peuvent être vues comme des manières différentes d’aborder une même problèmatique. La première, adoptée par une direction, sera très théorique, idéaliste et volontaire. La troisième, plus opérationnelle, sera plus concrète, pragmatique et sceptique. C’est la divergence de ces deux approches qui mène parfois à des incompréhensions mutuelles. La base estimant que la direction sous estime les problèmes, dans leur tour d’ivoire. La direction estimant que la base voit toujorus le coté négatif, frein au changement.

Au milieu, un niveau de controle, assurant la prise en compte de la stratégie, la façon de la mettre en oeuvre et son suivi.

Aujourd’hui, dans ma société, c’est cette séparation des responsabilités du middle management qui fait cruellement défaut. Il y a toujours un pan des contrôles qui tombe en friche au profit des deux autres. Par exemple, c’est le cas quand les objectifs ne sont pas clairement définis, que le flou règne dans les responsabilités de chacun (no Strategic). De même, c’est le cas quand les processus projets ne sont pas explicités, que personne n’a de vue d’ensemble sur les projets qui peut permettre la capitalisation et l’accélération des intercations humaines (no Executive). Enfin, c’est le cas si la direction n’est plus disponible, faute de temps, pour aller sur le terrain et néglige les problématiques opérationnelles (no Management).

Pour mieux cerner la méthodologie GOOD, voici quelques grandes lignes :

  1. En amont, dessinez une architecture de processus, pour identifier la cible métier à atteindre. C’est une pré condition incontournable, sinon vous construisez un édifice sur du sable. Connaître ses objectifs est la seule vraie fondation stable pour pouvoir démarrer une activité, le profit en est simplement un catalyseur – définir des objectifs n’implique pas forcément objectiver sur les résultats.
  2. Evaluez les processus de votre architecture pour identifier ceux qui sont stratégiques , tactiques ou opérationnels.
  3. Sur cette base, redéfinir votre architecture pour représenter votre organisation en objectifs long-, moyen- et court-termes.
  4. Utiliser les concept des 3 niveaux de contrôle (Strategic, Executive, Management) pour assigner les responsabilités et gagner l’engagement des bonnes personnes.
  5. Evaluez les interactions entre les processus dans cette nouvelle architecture pour décider lesquels peuvent être délégués, voire externalisés.
  6. Pour les processus internes, appliquez les 5 principes fondateurs de l’HIM, pour bénéficier du meilleur de chaque acteur, à tous les niveaux de votre organisation – non pas pour réduire le nombre d’intervenants, mais pour mieux utiliser les compétences de chacun.
  7. Utilisez des pratiques BPM, des techniques de workflow (qui ne nécessitent pas forcément d’utilsier des softwares) pour augmenter la performance des tâches automatisées – mais gardez conscience que l’outil ne résoudra pas la complexité (« no magic bullet » !)
  8. Alors, et seulement à ce moment là, analysez les processus que vous avez définis, à la fois humains ou automatisés, et demandez vous lesquels sont des services à valeur ajoutée ? Alors, ces services doivent être développés au sein de votre organisation – et ce ne sont pas toujours ceux que les directions techniques souhaitaient mettre en place…
  9. Pour assister la mise en oeuvre des processus, mettez en place des outils de gouvernance pour les piloter, majoritairement par du reporting sur les activités.
  10. Enfin, assurez vous que vos processus sont continuement améliorés, que ses métriques et ses indicateurs de performance ne sont pas juste garants du simple fonctionnement mais de son efficacité.

Tout cela est bien joli… mais sommes nous vraiment concernés ? Ces approches dans la mouvance BPM et SOA… est ce que vraiment ça nous concerne ? Quelques exemple de secteurs identifiés :

Si l’on regarde le scope large revendiqué, en effet, les sociétés de services en informatique sont en plein dans le mile. Car les savoirs et compétences des équipes, et l’imagination des hommes, sont au coeur des processus de réalisation.

Seulement voilà. C’est un travail de longue haleine, et dont la nécessité organisationnelle ne s’est pas encore imposée à tous. Mais globalement, les choses sont déjà là, sous jacentes : nous en parlons déjà lorsque nous évoquons le besoin de structurer nos projets au forfait, de rationnaliser nos processus, de devenir efficaces, puis productifs… puis rentables. Dernièrement, il a été désigné un « référant méthodologique ». Je trouverai que ça serait un signe fort et motivant qu’on donne à ce « référant » une définition conforme à cet HIM. C’est une piste à peine masquée que je lui lance.

Pour en savoir plus :

http://www.human-interaction-management.info/

http://humanedj.com/him.html

Trop de qualité 19 août, 2008

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

C’est une critique que j’ai entendu plusieurs fois venant de la direction. Nous ferions « trop de qualité ». Mais peut on reprocher de faire trop de qualité.. au dépend de quoi d’autre ? Tentative de décryptage d’une incompréhension réciproque…

Le B.A.BA de la gestion de projet nous a appris qu’il existe 4 objectifs principaux : le respect du délai, la couverture du périmètre, le contrôle du budget, et le niveau de qualité. Si vous augmentez l’un de ces paramètres, mécaniquement, les 3 autres se dégradent. Souvent, ce principe est illustré par un carré, et le but du chef de projet est de maintenir le curseur du projet au centre de ce carré pour une satisfaction totale de tous les acteurs.

Trop de qualité dans budget projetpqdc

Il y a des représentations alternatives. Un projet au forfait présente la caractéristique d’être un engagement de résultat, et le curseur périmètre étant fixe, il disparait : on représente le triangle des objectif délais-coûts-qualité.

projetqdc dans efficacite

Selon certains points de vue, les délais étant contraints par des pénalités de retards, économiquement, on préfère alors n’avoir qu’un seul segment de marge de manoeuvre qualité/coût.

projetqc dans objectif

Autre cas de figure, sur un projet en mode agile, la qualité n’est pas négociable et c’est elle qui disparait du carré, on préfère alors jouer sur l’axe du périmètre, en rajoutant des itérations pour affiner le produit. Chaque itération est une rallonge sur le budget et sur le délai de livraison finale du produit. Sur un projet agile on évite au maximum le changement de l’équipe. Avec un coût quasi fixe par itération, les coûts deviennent proportionnels aux délais.

projetpdc

Parmi tous ces modèles vous devinez lequel s’applique aux projets au forfait. Il s’agit du plus simple, le segment Qualité/Coûts. On pourrait croire qu’il reste une marge de manoeuvre laissée au chef de projet, celle de se positionner sur ce segment.  Il peut par exemple, faire du quick&durty, efficacité économique absolue. Ou alors faire de la qualité, avec l’engagement de réversibilité.

Ce choix n’est finallement pas de son ressort, mais du contexte commercial. En particulier dans le cadre du groupe dans lequel je travaille, l’activité n’a pas assez de volume en entrée, et les directions commerciales préfèrent donner une bonne image au client, pour pouvoir construire de belles références, et pourquoi pas, récidiver chez le même client. Dès lors, le curseur est explicitement mis vers la qualité dès la réunion de lancement du projet. On parle d’engagement de réversibilité, de niveau de documentation, de qualité du code…

Mais lorsque j’entends qu’on fait « trop de qualité » sur les projets au forfait, c’est un autre discours que j’écoute, celui qu’on n’est pas assez bon en gestion des coûts. Ce discours apparait toujours au moment du bilan économique. Et les dépassements sont majoritairement imputés à la faible productivité ; c’est bien entendu le cas, notamment pour tout projet qui démarre avec une équipe exclusivement de jeunes diplomés.

« Trop de qualité »… Nous passerions donc notre temps à demander et/ou faire des choses à moyen terme, de beaux modèles logiciels qui peuvent tout faire, au lieu de nous prioriser sur le strict besoin immédiatement exprimé. Les opportunités de capitalisation permettront à moyen terme de gagner du temps et de l’argent, mais la réutilisabilité est sans doute une utopie, une perte de temps. Nous devrions nous prioriser sur les réponses immédiates et, pourquoi pas, privilégier le quick&durty. Le php revient parfois sur la table.

En ce qui me concerne, un objectif de rentabilité demandé au plateau est une bonne chose. Car il faut responsabiliser les chefs de projet sur le choix de placer le curseur sur ce segment qualité/coûts. Mais, a contrario, il faut alors que tout le monde assume les conséquences d’une stratégie quick&durty. Or vu le faible niveau d’activité des projets au forfait, il est peut être plus stratégique de se construire de belles références et conserver une image de sérieux et… de qualité.

J’ai parlé d’objectif de rentabilité générale, je n’ai pas parlé d’objectiver les chefs de projet à la rentabilité de leurs projet, qui, par contre, induit beaucoup plus d’effets pervers. En effet, le reflexe de chaque objectivé, serait de ne se préoccuper que de son projet, comme une bulle, et de ne pas investir sur la qualité pour les autres. Mais les projets sont inégaux en difficultés et en criticité, et nous risquerions de soulever des débat stériles sur les injustices d’affectations. Et nous pourrions envisager des conflits nouveaux autour d’une refacturation de composants réutilisables entre projets. Bref, une compétition concurentielle au lieu d’une compétitivité collective. Une idée intéressante serait d’objectiver les chefs de projet sur la rentabilité générale des projets au forfait, répartis ensuite au proratta du temps passé. Cela les inciterait alors à communiquer, à s’informer, et à s’entraider. Ces objectifs collectifs seraient plus efficaces que des objectifs individuels. Selon les opportunités, les chefs de projets pourraient suggérer d’accentuer la qualité sur un projet, ou de faire moins cher sur un autre, dans une stratégie globale et non cloisonnée.

Il existe deux visions de la direction de projet qui semblent s’opposer : une équipe de chefs de projets qui monte en responsabilités, ou un directeur nominatif, qui fait appliquer ses décisions par les chefs de projets. J’ai déjà présentée, dans un précédent article, la définition de ce que j’appelle management2.0 . Les subordonnés sont force de propositions et d’initiatives, et le manager coordonne et assume les choix collectifs. C’est ce manager qui consolide l’ensemble qui est garant de la rentabilité générale, les chefs de projet se redistribuant les curseurs qualité/coûts. Le directeur de projet n’est pas un super-chef-de-projet, il a un autre rôle bien identifié. Finallement, c’est ni plus ni moins que la fusion des deux approches qui tendaient à s’opposer.
« Trop de qualité », cela n’a finallement de sens que si on définit à partir de quand on dépasse le raisonnable.  Si la rentabilité générale définit une taille de gâteau, les projets opportunistes – avenants, réutilisation, … - auraient une petite part, les projets investissants- stratégiques, innovants… – auraient une plus grosse part. Les projets sont tous différents, la définition du seuil « trop de qualité » ne peut se faire qu’au cas par cas.

Reporting 8 août, 2008

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

 Reporting dans communication manager01

manager02b dans efficacite

manager03 dans encadrement 

 

Manger un manager 7 août, 2008

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

Je fais souvent la faute de frappe « manger » au lieu de « manager »… voilà pourquoi ! 

Manger un manager dans efficacite manager2

Refaire la roue carrée 25 juillet, 2008

Posté par dailymanager dans : efficacite,innovation , ajouter un commentaire

L’organisation peut perdre un temps phénomal, et insoupçonné, dans les micro-opérations quotidiennes récurentes. Ces petites actions, que chacun faits et refaits à sa manière, individuellement, chacun de son coté… ça s’appelle refaire la roue.

Et il n’y a que les paons qui aiment ça.

Naturellement, les opérations pénibles opérées par la même personne font l’objet d’un traitement d’amélioration, pour augmenter leur productivité, et surtout réduire leur pénibilité. C’est chiant à refaire, donc je vais m’arranger pour le faire une seule fois pour toutes. Si tant est que quelqu’un s’en apperçoive un jour, on flattera les mérites de son effficacité personnelle. « Il sait s’organiser dans son travail », « Il a une bonne méthodo »…

Je parle ici de ces petites actions quotidiennes, comme alimenter en papier une imprimante, se procurer un nouveau crayon, receptionner un colis. Je vous en ai cité des administratives, parce qu’elles sont déjà tombées dans le bon sens commun des « services généraux ». Dans toutes les organisations, qui se définissent comme telles, la gestion des fournitures de bureau fait l’objet d’une logistique de pointe, qui permet au collaborateur qui cherche un nouveau crayon, de savoir où le chercher, et d’assurer qu’il en reste en stock. Et puis il y a tout le reste, non pris en charge, ces opérations qui nécessitent « juste » de l’huile de coude.

Je vous donne un exemple concret. Imaginez que au cours de votre boulot, vous ayez besoin d’un bon bouquin de référence. Imaginez qu’un système de bridage du réseau vous empêche de le trouver en versoin electronique. .. et vous vous souvenez avoir vu un bouquin papier trainer :

Premier reflexe logique, est ce que le bouquin n’est pas dans le coin ? ça se traduit en général par un regard circulaire, et si vous êtes vraiment motivé, vous vous levez et vous faites un rapide tour de tables. S’il n’y a pas ce que vous cherchez, déjà, vous pourriez abandonner… Et puis vous vous dites que si, quand même, ça vous dit quelquechose cette couverture… Vous allez donc vers cette armoire poussièreuse, et fouillez dans les grimoires tout aussi allergisants les uns que les autres, entre « Flex in action », à « La sécurité informatique », en passant par « Apprendre Java 1.0 en 10 minutes », via un grimoire digne de Harry Potter. Et là, vous pouvez perdre un temps fou à lire et relire les noms sur les tranches, comme quand vous cherchez ce fameux camembert Président caché dans le rayon de fromage : vous passez devant 10 fois devant sans le voir !

En début d’année, j’ai entrepris de classer la bibliothèque de la boîte. Oh on ne m’a rien demandé, bien entendu. C’était juste pas géré, et j’en ai eu marre.

Les collaborateurs qui avaient par le passé commandé des livres se plaignaient qu’ils disparaissent, et justifiaient ainsi leur découragement : « de toute façon, ils se font piquer, alors ça sert à rien d’acheter des livres… en plus ceux qui disparaissent c’est les meilleurs ». Première tâche, donc, les faire tamponner par le tampo de la boîte. Et puis on m’a signalé que « de toute façon, on ne sait pas qui les emprunte, alors ça sert à rien de les tamponner ». Vous noterez au passage, que quand une phrase commence par « de toute façon », c’est jamais très bon signe. Deuxième tâche, donc, trouver un système d’emprunt.

Je ne suis pas très procédure papier, et l’idée de tenir un livre de bibliothèque, en demandant aux emprunteurs de donner leur nom… ça m’a pas super enthousiasmé. ça revenait à rendre moins pénible l’opération de recherche, mais plus pénible l’opération d’emprunt, mais à tout reporter sur le bibliothécaire. Or évidemment, ça ne pouvait être que moi, et hors de question de me faire pourrir la vie en temps réél à chaque emprunt ou retour de livre…

Coté support technique, j’ai trouvé une solution qui m’a semblé pas trop mal, l’utilisation d’un logiciel qui existait déjà, Jira pour ceux qui connaissent, bref, c’est anecdotique. J’ai donc configué l’outil, renseigné tous les bouquins, et assigné les livres en cours d’emprunts aux bons collaborateurs. Dans la lancée, j’ai rajouté des fonctions de suggestions, de reservations, de commentaires… et j’ai même rédigé un support de communication, livré « prêt à marcher » aux responsables de la communication interne, pour faire une annonce élargie à tous les collaborateurs de la boîte. Je n’avais rien d’autere à faire ? Si, si , rassurez vous, ça m’ a pris 2 mois, à petites touches quand j’avais le temps.

Voilà un bon exemple d’une opération pénible récurente, que quelqu’un a spontannément améliorée. Maintenant, tous les collaborateurs devraient savoir que les livres sont référencés, et peuvent même savoir qui l’a emprunté. Seulement voilà, en dehors de cette personne courageuse (je m’envoie des fleurs !) , qui sait vraiment que cela existe ?

Il m’a manqué un élèment décisif pour finir ce travail : la communication. L’annonce « prête à envoyée » que j’avais réalisée n’a jamais été diffusée. S’arrêter si prêt du but, quel échec… Il n’y a pas eu le cerclage final, j’ai vaguement l’impression d’avoir réinventé une roue carrée.

 

123

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