rhapsodies-hero-le-spleen-du-neo-manager-agile

Le Spleen du neo-manager agile

Le Spleen du neo-manager agile

14 avril 2018

– Lecture de 3 mn

David Couillard

Directeur Transformation Office Management

Avant l’agilité, c’était clair : je disposais d’une série d’outils d’analyse que j’appliquais sur mes projets en fonction des problèmes rencontrés.

Quand un sujet apparaissait, je définissais une démarche de traitement, je l’appliquais ou la faisais appliquer. Je la pilotais. Je rendais compte. Et en cas de besoin je faisais évoluer la démarche. De plus comme j’étais quelqu’un d’attentif au sort de mes congénères, je faisais attention à chacun et je mâtinais nos travaux d’explications, d’entretiens personnalisés, pour vendre, adapter les solutions trouvées à chaque problème. Régulièrement, j’organisais des séminaires pour mobiliser les équipes, organiser les médiations nécessaires avec nos clients, bref faire progresser tout le monde dans le même sens.

Mon principal souci était de faire avancer les dossiers dont mon équipe était chargée. Et je rentrais chez moi le soir, le devoir accompli, ou en passe de l’être. De temps en temps, il y avait bien une crise à résoudre (problème de planning, de résultats, de politique, etc.), mais en général l’écoute, la patience et l’âpreté à chercher une solution en venait à bout.

Mais cela c’était avant l’agilité. Un matin, des « coachs agiles » ont débarqué et m’ont expliqué que ce n’était pas suffisant, qu’on pouvait faire plus :

On m’a envoyé en formation où j’ai expérimenté la nouvelle démarche en jouant aux lego avec des gens que je ne connaissais pas. Ambiance de travail, gamification, bienveillance, empowerment, épanouissement personnel … sont devenus de nouveaux mots d’ordres. Tout manquement à la démarche était pointé du doigt.

Un coach agile est venu m’expliquer que je devais « changer de posture » : là où je m’évertuais à faire le médiateur pour aider (Lassie chienne fidèle !), je devais désormais donner de l’autonomie, changer le référentiel de travail, pour plus d’efficacité, et … accepter moi-même de perdre le contrôle.

Quel drôle d’idée : donner le pouvoir aux autres, leur donner la responsabilité, perdre la mienne, au point d’être challengé moi-même par mes propres équipes … Là résidait le secret de la réussite désormais !

Alors je m’y suis mis : j’ai donné les clés du camion aux collaborateurs, j’ai perdu le pouvoir de décision, mais j’ai mis en place des KPI pour pouvoir quand même suivre ce qui se passait dans les projets. Nous travaillons différemment, nous communiquons plus. Certains n’ont pas réussi franchement à s’y mettre, mais je ne désespère pas. De fait, il y a de l’émulation et des résultats probants.

Finalement, avant je savais à quoi je servais précisément, maintenant c’est un peu plus flou et je ne sais pas si j’aime ça, moi qu’on avait recruté pour ma capacité « à tout piloter ». Rien ne me semble plus jamais achevé. Et à un coach agile à qui j’en faisais part m’a répondu « done is better than perfect ». Il a réponse à tout ! …

Et puis, il y a eu comme un petit miracle, lorsque les collaborateurs ont dû bosser sur les projets, ils se sont finalement tournés vers moi. Loin de jeter le bébé avec l’eau du bain, tous mes outils d’analyse et mon expérience, que j’avais laissés de côté sont redevenus utiles pour aider mes collaborateurs et mes partenaires.

Dès lors j’ai compris, que foncièrement l’agilité offrait l’opportunité d’un regard nouveau. Et que tout nouveau que soit ce regard, j’avais toujours de la valeur ! Mieux, mon expérience, pour peu que je sache attendre le bon moment pour qu’elle soit utile, avait de la valeur pour les autres ! Là où je voyais mon « obsolescence professionnelle » surgir, j’apercevais tout d’un coup un formidable levier pour faire mieux réussir encore mes partenaires.

Lassie chienne fidèle avait retrouvé la maison !

David Couillard

PS : quelqu’un peut-il me dire comment organiser des ateliers d’innovation « on site » avec nos développeurs désormais tous à Bombay ?

agile-processus-etre-transformation-management

Agile et processé : comment être tout cela à la fois ?

Agile et processé : comment être tout cela à la fois ?

10 avril 2018

– 2 minutes de lecture

David Couillard

Directeur Transformation Office Management

Processus, ce terme a fait le buzz en entreprise dans les années 1990 et 2000. La démarche associée promettait de casser les silos organisationnels et y est parvenu dans bien des cas : entreprise horizontale, entreprise en réseau, etc. Aujourd’hui l’approche processus, si elle n’est pas battue complètement en brèche par les démarches agiles, trouve encore une place comme outil d’analyse et de capitalisation de l’organisation.

Les spécialistes de l’agilité portent leurs critiques non sur l’approche processus elle-même, mais surtout sur la façon dont elle est mise en œuvre. En effet c’est bien souvent une démarche centralisée qui est déployée : « nous pensons (les processus) et vous les exécutez». De fait, cela est contraire à l’état d’esprit agile qui cherche à promouvoir la responsabilisation des collaborateurs, à faire rechercher par les équipes des solutions aux problèmes qu’elles rencontrent, etc. Notons bien au passage que dans une telle démarche, le management intermédiaire aussi se trouve dépossédé d’une partie de son leadership. Son rôle est réduit au contrôle de l’exécution des processus.

Quand, dans une organisation basée sur un management par les processus, des modes de management agiles sont déployés sans adapter l’approche processus, on aboutit à des situations schizophrènes, comme l’illustre l’exemple ci-aprèsdans une société de distribution automobile :

La satisfaction client est régie par une série de processus sciemment optimisés à appliquer en fonction des cas. Conscient que c’est insuffisant, la Direction des Ventes demande aussi aux collaborateurs en contact avec les clients de prendre des initiatives lorsque c’est nécessaire. Bien entendu, ces initiatives contreviennent parfois aux consignes prescrites par les processus. Au bout du compte, quand la satisfaction client est bonne (notée par le client via un questionnaire), tout le monde en est gratifié. Cependant, si le client montre une insatisfaction il est reproché au collaborateur soit de n’avoir pas suivi le processus s’il a pris des initiatives, soit d’avoir trop servilement collé au processus …

…c’est bien ce qu’on appelle une situation absurde ! Patatra !

La situation décrite ci-dessus est fréquente et symptomatique des grandes organisations. Il faut être vigilant à ne pas mettre en place des systèmes de management à « injonctions contradictoires », qui conduisent toujours à un retour en arrière (injustice, stress au travail, démobilisation, etc.).

Pour notre part, nous préconisons un usage de la démarche processus qui soit compatible avec les démarches de management agile.

Facilitation graphique – Lean Process

Communication

Digitalisation

L’agilité redessine les contours d’une démarche processus qui soit un outil au service de la performance. Les initiatives de digitalisation sont une formidable opportunité de rebattre les cartes des modes de fonctionnement opérationnels.

David Couillard & Hervé Taboucou

Planifier évolution SI d’entreprise architecture

Planifier l’évolution du SI: un projet d’entreprise

Planifier l’évolution du SI: un projet d’entreprise

6 avril 2018

– 4 min de lecture

David Couillard

Directeur Transformation Office Management

Le plan de transformation pluriannuel du SI est un outil pour aligner le SI sur les ambitions de l’entreprise. Il est constitué d’une une feuille de route pertinente et adaptable aux imprévus qui surviendront à court et à long terme. Son élaboration implique et mobilise tous les acteurs sur lesquels repose sa réussite, c’est un projet managérial pour rendre l’entreprise plus performante.

L’alignement stratégique a remplacé le schéma directeur

Nul doute que les démarches de schémas directeurs que nous connaissions auparavant ont changé. Elles étaient souvent ponctuelles et très longues, voire peu opérationnelles. Le rythme croissant du changement les a finalement disqualifiées.

Pour autant les entreprises restent confrontées peu ou prou aux mêmes grandes questions, suivant leur situation :

Pour y répondre, les managers et les dirigeants -pas seulement la DSI- sont amenés à imaginer le SI de leur entreprise telle qu’elle devrait être demain, soutenu par une trajectoire d’évolution réaliste. Sans cette trajectoire, adossée au présent et ancrée dans la réalité, l’accroissement de performance attendu n’aura pas lieu.

Une fois les réponses trouvées, la réussite de la mise en œuvre tournera en définitive autour d’une seule question « Comment les acteurs feront-ils faire grandir l’entreprise, en intégrant leurs priorités d’évolution définies et leurs propres capacity plannings ? ».

C’est à ces questions de management qu’aboutissent toujours les travaux et qui conduisent à rechercher la mobilisation des parties prenantes dès la phase de conception. En effet chacun s’investira d’autant mieux dans la transformation qu’il aura participé à l’élaboration de la solution et qu’il s’y identifiera.

Mais que doit-on faire pour mobiliser les équipes ? Nous rappelons trois grands principes que l’on ne devrait jamais oublier.

Prendre de la hauteur ensemble

Quotidiennement, les Directions Opérationnelles sont habituées à fonctionner au présent, « au quarter », à engager des projets à court terme. Lors de l’élaboration d’un plan de transformation elles sont appelées à se projeter et à penser le long terme : il ne s’agit pas seulement de traiter des demandes d’évolution en souffrance, mais d’énoncer des enjeux d’évolution, des objectifs à moyen terme,  de repenser des processus, voire d’oser un nouveau « business model ».

C’est pour cela que le sponsor de la transformation doit impulser et maintenir un niveau d’ambition suffisant aux travaux, ménager un délai pour la réflexion, inciter et aider les directions à ajuster leur niveau d’engagement et leurs contributions.

Compte-tenu de la rapidité du cycle de transformation actuel (cf. l’évolution des applications des outils digitaux ou encore des réglementations), la mécanique des travaux doit être rapide, de l’ordre de 3 à 6 mois. Les travaux débouchent sur l’élaboration d’une cible, d’une trajectoire réaliste et d’un portefeuille de projets et d’initiatives transverses qui feront l’objet de révisions régulières. Cette révision sera l’occasion de prendre en compte des inflexions ou des nouveautés dans la stratégie, ou d’approfondir des sujets laissés de côté lors des cycles précédents.

La planification de la transformation, ponctuelle et orientée IT, devient collective et régulière, voire permanente.

Travailler (enfin) en équipe

Tous les acteurs de la transformation doivent être associés : Opérations, SI, Marketing, RH, finance, etc. Un  climat de confiance doit être installé : la transversalité, réclamée à cor et à cri pour construire une entreprise plus performante, repose sur l’interdépendance entre acteurs qui ne peut s’envisager que dans un climat de concertation.

Chacun doit être amené à un état de « dialogue constructif », quelle que soit la situation de départ : pour les uns, abandonner l’obéissance passive, pour les autres, laisser tomber les résistances, pour d’autres encore, apprendre à écouter. Il faut battre en brèche l’idée que l’on va faire un état des lieux et pointer du doigt les fautifs et promouvoir la  coopération.

Il revient au sponsor du plan de transformation, de prévoir un dispositif d’étude favorisant un mode de management bienveillant où les liens de subordination, les conflits trop appuyés, laissent place à plus de solidarité, plus d’échanges mais aussi plus de créativité. Chacun apporte ainsi sa valeur ajoutée à l’édifice commun et en retire plus de motivation en retour.

Faire évoluer le rôle de la DSI et des équipes IT

Enfin, le plan de transformation SI a pour destinataires l’ensemble des directions métiers. L’intrication croissante des prérogatives métiers et de celles de l’IT, notamment avec les démarches de digitalisation, conduit toute l’entreprise à fonctionner en partenariat avec sa DSI.

Pour les entreprises, où la DSI est encore vue comme un fournisseur de moyens, c’est un premier gros changement de culture à engager. Cela ne va pas forcément de soi quand les métiers ont pris d’autres habitudes et que la DSI se comporte comme une Direction Technique. En tout cas, la DSI peut profiter de l’opportunité de la démarche pour poser sur elle-même un autre regard. Bref, faire son marketing.

Finalement, l’élaboration du plan de transformation SI ne serait-il pas la seule occasion d’expérimenter de nouveaux modes de fonctionnement sollicitant toute l’entreprise ? La démarche ne pourrait-elle pas porter un projet d’entreprise à l’heure ou la performance de l’IT est une condition de survie ?

Ce serait alors une opération qui tirerait vers le haut toute l’entreprise et permettrait de se tourner vers le futur avec plein de bonnes intentions managériales : communiquer, faire confiance, responsabiliser, orchestrer, soigner l’ambiance, … dont on sait depuis longtemps qu’elles sont la clé de la motivation, de la performance et d’une bonne adaptation au changement.

Les projets et la trajectoire de transformation en seraient les premiers bénéficiaires. On commence quand ?

photo-1521117184087-0bf82f2385ab

L’Architecte d’Entreprise, artisan des transformations complexes

L’Architecte d’Entreprise, artisan des transformations complexes

14 mars 2018

– Lecture de 3 min

David Couillard

Directeur Transformation Office Management

L’Architecture d’Entreprise est souvent vue de manière négative par les projets : effort coûteux, dé-corrélé de leurs contraintes, etc. Pourtant « sur le papier » cette pratique est très ambitieuse et prometteuse. Examinons les conditions d’un recours efficace à l’Architecture d’Entreprise.

Management de projets : tout change, rien ne change

Dans mon parcours professionnel, j’ai croisé et continue de croiser des « maîtres » qui influencent mes approches et mes convictions. L’un d’entre eux disait « le coût de la correction d’une erreur de conception est multiplié par 10 à chaque fois que l’on franchit une étape dans un projet : 1 au moment du cadrage, 10 en conception, 100 en réalisation / test, 1000 après le déploiement (lorsque c’est une fonctionnalité inadaptée qui a été déployée auprès de centaines d’utilisateurs) ». C’était à la fin des années 1990, et on était encore à l’époque sous le règne (finissant) de la méthode Merise.

Depuis, les technologies, la culture de projet et les compétences en ingénierie informatique se sont développées. Il existe aujourd’hui un grand nombre de  « briques technologiques » utilisables pour assembler un SI comme un lego, sans avoir à développer spécifiquement chacune des pièces.

Cependant, rares sont les projets qui échappent aujourd’hui encore aux difficultés d’hier. On constate toujours une série de « manques » : manque de vision, de temps, de moyens, de savoir-faire, de discipline, de dialogue, d’analyse des besoins, etc. Plus que jamais, l’adage de mes débuts continue de se vérifier. D’ailleurs l’existence de « briques technologiques » de plus en plus élaborées, ne résout pas le problème d’architecture globale. En effet, on peut construire un truc très moche avec des lego très beaux !

Architecture d’Entreprise : l’art de traiter la complexité

Parmi les pratiques qui permettent de concevoir un SI, l’Architecture d’Entreprise est aujourd’hui celle qui apporte le maximum de garantie. Elle préconise l’extension des pratiques d’architecture du SI à l’ensemble des dimensions de l’entreprise. L’objectif poursuivi est d’éviter de ne penser l’architecture qu’en termes « d’architecture de solution informatique », qui est une réflexion trop restrictive car elle réduit le questionnement à la problématique informatique.

Pour compenser cela, les DSI font parfois intervenir sur les projets des maîtres d’ouvrage connaissant les applications, afin de conjuguer réflexion sur le métier et réflexion sur la solution. Cependant cela détourne souvent le maître d’ouvrage de son rôle : étudier l’opportunité et cadrer les besoins. Il arrive encore qu’on démarre des projets sans savoir s’ils sont vraiment souhaitables et faisables, avec pour seul actif une liste de besoins.

L’Architecture d’Entreprise propose un cadre permettant d’assurer une continuité d’analyse entre les différentes phases du projet. Elle couvre aussi l’analyse d’opportunité en amont des projets. Mais alors pourquoi les problèmes ne sont-ils pas déjà résolus ? Sans doute la démarche est-elle perçue comme complexe à déployer et à s’approprier (c’est l’argument le plus souvent entendu). En effet, le déploiement d’une démarche Architecture d’Enterprise appelle une évolution de l’organisation des démarches d’étude et de projet. Elle doit être portée par une ambition managériale et par la mobilisation des équipes. A défaut on verse immédiatement du côté obscur et l’on ne retient de l’approche que ce qu’elle a de plus hermétique : la méthode … inconcevable quand on manque de temps, manque de moyens, manque de savoir-faire, manque de discipline, manque de dialogue, etc. On finit par oublier le parti qu’on pourrait tirer de cette réflexion pour l’analyse.

Ce n’est pas le marteau qui fait bouger la main, mais l’inverse

Quand cet outil d’analyse est utilisé correctement, de  manière pragmatique, on en voit immédiatement la valeur-ajoutée pour les projets. Et ce, sans attendre le déploiement des applications et le verdict des utilisateurs.

Lorsque l’Architecture d’Entreprise est présente dès le point d’ignition du projet (ou avec bonheur, plus en amont encore : lors d’un schéma directeur) elle est à même de porter et fédérer toutes les dimensions de l’analyse et répondre aux attentes des acteurs de la transformation :

En résumé, l’Architecture d’Entreprise fait exister le projet avant qu’il n’existe. Puis elle l’accompagne dans son cycle de vie vers sa réalisation (son accomplissement !). Disposer d’un plan de route pour conduire une transformation est tellement utile lorsque les projets sont stratégiques, transverses et complexes. Faisons-le savoir, comme monsieur Jourdain pour la prose, l’architecte d’entreprise fait du management, sans qu’on le sache ! Mais lui, il le sait.

photo-1475506631979-72412c606f4d-e1527510616573

L’architecture d’entreprise, fruit de l’intelligence collective ?

L’architecture d’entreprise, fruit de l’intelligence collective ?

9 mars 2018

– Lecture de 2 mn

David Couillard

Directeur Transformation Office Management

Une architecture d’entreprise bien conçue est le fruit d’une intelligence collective. Le déploiement des pratiques d’architecture doit aussi être considéré du point de vue humain. Tentative de démonstration en ré-exploitant quelques enseignements de la mobilisation en entreprise.

Pour concevoir et faire évoluer l’architecture du système d’information d’une entreprise, il faut tenir compte de nombreuses préoccupations hétéroclites : métiers, techniques, managériales, financières, réglementaires, etc.

Par leurs efforts, les différents métiers en charge de l’architecture parviennent à définir des architectures cohérentes, alignées avec les différents besoins, à la fois pérennes et évolutives. Une architecture bien conçue est finalement le fruit d’une mobilisation, par laquelle l’intelligence collective opère correctement. Pour aider les architectes d’entreprise, il existe un ensemble de bonnes pratiques permettant de concevoir une architecture adaptée à chaque entreprise, développé depuis plusieurs années. Ces bonnes pratiques sont une extension des pratiques architecturales à l’ensemble de l’entreprise : représenter (modéliser) pour concevoir et partager ; comprendre l’existant pour savoir d’où l’on part ; établir une cible ; établir des bibliothèques d’architectures-types ré-exploitables ; etc.

L’effort d’appropriation de ces bonnes pratiques est souvent focalisé sur la définition des outils de l’architecte (modélisation, patterns, concepts, livrables, etc.). L’appropriation et l’adoption des outils est longue et on la qualifie volontiers « d’évangélisation ». Aussi pertinents ces outils soient-ils, ils ne peuvent pas provoquer la mobilisation de l’intelligence collective à eux seuls. On doit compléter leur déploiement par une série d’initiatives visant à mobiliser les acteurs de l’architecture. Il faut rappeler ce qu’est la mobilisation.

Les différentes formes de la mobilisation

La mobilisation est l’acte intentionnel d’un collaborateur le conduisant à faire des efforts dans le sens d’un travail collectif. D’après Arnaud Bichon, sociologue, on trouve trois formes de comportement de mobilisation, classés par ordre de complexité croissante :

  1. Les conduites relationnelles : ce sont les efforts favorisant la connaissance mutuelle des acteurs et divers types de partage entre eux. C’est le fameux « esprit de corps » des gens du (même) métier qui s’apprécient. Le collaborateur mobilisé est celui qui fait l’effort de tisser des liens, de vivre des expériences avec l’autre. L’inverse, c’est l’individu isolé qui n’engage aucune relation particulière.
  2. Les conduites coopératives : ce sont les efforts spontanés de collaboration, avec des prises d’initiatives dépassant le cadre stricte des obligations. Le collaborateur mobilisé est celui qui travaille délibérément en interaction avec ses collègues et s’implique dans les décisions, qui « partage ». L’inverse c’est la non-collaboration.
  3. Les conduites d’intercompréhension : ce sont les efforts pour construire des représentations communes, comme référence des actions collectives et individuelles.
    Le collaborateur mobilisé est celui qui développe une vision globale de l’activité contribuant à « construire avec autrui ». L’inverse, c’est celui qui veut rester dans son cadre de référence.

La mobilisation est provoquée selon deux modalités de natures très différentes, qui se complètent :

Plus les formes de mobilisation sont complexes (de 1 à 3 dans la liste plus haut), plus elles sont délicates à provoquer, car elles sont discrétionnaires. L’intelligence collective fait partie de celle-ci. Elle fait parfois dire à des patrons d’entreprises que « la collaboration se constate, mais qu’elle ne se mesure pas », comme une déclaration d’impuissance.

Application à l’architecture

Lorsque l’on déploie les outils de l’architecte (modélisation, patterns, concepts, livrables, etc.) on travaille sur une série d’injonctions visant à provoquer l’utilisation de nouveaux outils. A l’opposé d’une démarche par injonctions, pour que l’intelligence opère, il faut agir sur les comportements, afin de créer des réflexes de collaboration. Il s’agit de créer un contexte favorable.

Dans cette perspective, des actions prioritaires sont à mener en parallèle :

  1. Faire reconnaître la pratique de l’architecture dans le cadre de référence RH de l’entreprise. Il paraît difficile de demander au équipes de réaliser des effort sur une discipline qui ne serait pas reconnue comme telle. Cela nécessité une réflexion, car il n’existe pas de cadre de référence publiée sur le sujet. On trouve n variantes sur le sujet « Architecte » dans le domaine SI. C’est dans le cadre de référence RH que l’on pourra définir les fonctions des « Architectes d’Entreprise » et des points de repère pour formuler des objectifs annuels individuels.
  2. Créer une communauté des architectes, pour provoquer les rencontres et les « conduites relationnelles » qui ensuite seront poursuivies dans le cadre des activités courantes.
    Cette communauté peut prendre différentes formes : petits déjeuners débats réguliers, conférences animées par des intervenants internes ou des prestataires, groupes de travail à thème, outils de partage d’information (le « wiki » des architectes), etc.
  3. Développer l’envie de faire de l’architecture, en recherchant et en agissant systématiquement sur les appétences et les freins des acteurs de l’architecture.
    On doit pouvoir établir un plan d’action de changement très pragmatique, impliquant les acteurs et leurs hiérarchies, en complément des habituelles réunions d’information. sur l’architecture.
  4. Développer un réseau favorable à l’architecture en identifiant les alliés sur lesquels on peut compter et en leur confiant des initiatives concourant au déploiement de l’architecture.

Je n’ose pas rappeler qu’un soutien, dans les paroles et les actes, de la Direction des Systèmes d’Information, est indispensable pour que l’opération réussisse.