Catégorie Divers

Bataille d’experts – le retour : Savoir trancher un sujet technique lorsqu’on est DSI

Fleid 4 commentaires

Dans un précédent article je vous donnais quelques conseils pour fournir les bons arguments à son DSI afin qu’il tranche sur des sujets techniques. J’inverse les rôles aujourd’hui, pour m’adresser à nos CIO, nos CTO, ou encore nos DSI / RSI, en somme à nos patrons de l’informatique.

Et là le conseil va être beaucoup plus simple : si vous en êtes à trancher des sujets techniques, c’est que vous avez raté le coche dans votre organisation. Vous avez un background technique ? C’est une très bonne chose. Mais si vous êtes le chef il faut bien se dire que ce n’est pas grâce à votre compétence technique, soyons honnêtes. Ne croyez donc pas que votre avis vaut mieux que celui de vos troupes, sur le terrain, qui elles développent encore plus de 6 heures par jour.

Un DSI n’est pas nommé pour répondre lui même au débat technique. Il est nommé pour constituer une équipe de confiance, capable de le faire pour lui. Le job d’un exécutif c’est plein de choses passionnantes, mais ça n’inclut pas de prendre des décisions opérationnelles.

Donc si un sujet technique est escaladé jusqu’à vous (quel ETL utiliser pour le prochain projet, quelle modélisation choisir pour son datawarehouse…), sachez reconnaître le problème organisationnel sous-jacent, et réagir en fonction.

Pour ça, voici les grandes étapes à suivre :

  • D’abord, constituez-vous un état-major d’experts en qui vous avez confiance. Qu’ils soient internes (c’est mieux) ou externes, identifiez des individus qui savent vous dire non, qui savent vous dire quand vos décisions sont mauvaises, quelle que soit leur place dans la hiérarchie. N’hésitez d’ailleurs pas à tester la capacité à la franchise de cet état-major de temps en temps : demandez des avis externes, croisez le retour de plusieurs personnes, posez des questions théoriques douloureuses dont vous savez les réponses, auditez le résultat de vos audits… Car en effet, la confiance n’exclut pas le contrôle.
  • Une fois ces référents identifiés, appuyez-vous sur eux pour vous conseiller dans la décision. Non pas pour vous expliquer le sujet technique, mais plutôt pour vous clarifier les intérêts et conflits d’intérêts de chacun, et comprendre pourquoi votre organisation n’a pas su répondre au problème. Vous n’êtes pas là pour trancher le choix de l’éditeur de l’ETL, vous êtes là pour comprendre pourquoi votre architecte décisionnel n’a pas réussi à faire appliquer ses recommandations.
  • Enfin, n’ayez pas peur de prendre et d’assumer des décisions qui ne font pas de compromis. Si un sujet escalade jusqu’à vous, il sera forcément chargé émotionnellement et votre décision fera obligatoirement des malheureux. N’essayez donc pas de satisfaire tout le monde, vous n’arriverez qu’à des demi-mesures qui feront trainer la situation dans le temps. Mieux vaut une vraie tristesse, qu’une fausse joie (dixit les experts). Soit les recommandations de votre architecte sont mauvaises, alors il vous faudra l’accompagner dans la mise à jour de sa compétence ; soit l’équipe projet est trop arrogante pour reconnaître la sagesse de l’architecte, et un effort de management doit être fait pour remettre les choses à plat.

Le résultat c’est que vous ne choisissez pas à la place de vos équipes, vous corrigez votre organisation pour qu’elle réponde elle-même à la question, et aux prochaines du même acabit.

Si sur le papier ça a l’air simple, il est clair que dans la vie de tous les jours c’est plus complexe. On a tous une tendance à vouloir jouer les superhéros, à sauter dans l’action et sauver les situations. Une caractéristique d’ailleurs encore plus présente chez les individus ayant réussi à se hisser dans les fonctions exécutives. Mais il faut savoir déléguer les décisions au bon niveau de responsabilité (le terrain), et respecter ces décisions. Pour un collaborateur, il n’y a rien de pire qu’un désaveu de la part de sa hiérarchie, surtout si de son point de vue il faisait le nécessaire pour protéger l’entreprise. Il est également important d’éviter le micro-management, car intervenir sur toutes les décisions c’est encourager vos équipes à vous masquer les problèmes afin de conserver leur autonomie.

Enfin, et je conclue peut-être avec le message le plus important de cet article : en cas de problème ne blâmez pas une personne, blâmez plutôt les processus et/ou l’organisation. Cette règle est à la base du Lean IT, dont un des piliers est le respect de la personne. Elle est essentielle au bon fonctionnement du groupe. Au-delà de la considération à avoir pour son prochain, c’est également un excellent coup de pouce à la transparence, puisque l’apparition d’un défaut dans l’organisation sera l’occasion d’améliorer les conditions de travail des équipes.

Consultants Juniors, Confirmés, Séniors, quels critères pour quantifier l’expérience?

Fleid 6 commentaires

On avait déjà évoqué ensemble les différents choix de carrière pour un consultant décisionnel – ou plus généralement pour n’importe qui travaillant dans l’IT – et j’étais passé assez rapidement sur la montée en séniorité.

Je reviens donc sur le sujet, pour clarifier ma vision de ces différents sous-titres qui ornent nos cartes de visite.

Petit consultant deviendra grand…

Par niveau, je vois les choses comme ça :

> Débutant / Stagiaire

  • 0 expérience
  • En cours d’apprentissage
  • Contre-productif, coûte du temps sans en rapporter avant 3 mois d’activité

> Junior

  • 1 à 2 ans d’expérience
  • Est capable d’exécuter le travail unitaire qui lui est demandé
  • Quasiment aucune autonomie, doit être piloté quotidiennement

> Confirmé

  • 3 à 4 ans d’expérience
  • Est autonome dans son propre travail de bout en bout
  • Nécessite un point de référence quand les choses se corsent

> Sénior

  • 5 à 10 ans
  • Pilote les travaux unitaires des autres pour l’élaboration d’une solution complète
  • Connaît à l’avance les points durs et sait les contourner

> Vieux de la vieille

  • 10 ans et +
  • Plutôt rares, en général on évolue vers du management, de la direction ou on change de domaine d’activité (séniors multi domaines)
  • Il ne craint personne, on ne la lui fait plus, mais attention à ne pas trop s’aigrir!

Combien d’XP pour le prochain niveau?

Notez que pour moi l’expérience se calcule à la mode Joel Spolsky, et que la durée nécessaire varie évidemment d’une personne à l’autre. Pour les anglophobes, les critères du père Spolsky sont les suivants :

  • On compte toutes les activités de développement, le design d’interface, le QA (les testeurs), les taches d’administration et production…
  • Pour les fonctions méta, le management, le marketing et la vente, on les compte si elles sont précisément dans le secteur que l’on veut qualifier (édition, décisionnel, webdev…)
  • On ne compte pas ce qu’il se passe pendant l’école. Exception de mon côté pour les apprentis dont je compte à 50% le temps passé en entreprise.
  • Pénalité sur les tâches répétitives qui sont ramenées à 1 année (3 ans en régie à faire la même chose ce n’est pas 3 ans d’expérience mais 3 fois la même unique année).
  • J’ajoute également un facteur sur la qualité de la veille technologique du collaborateur. Un développeur abonné à des flux RSS de bloggeurs, ou bloggeur lui-même, qui participe à la communauté, gagnera forcément un bonus par rapport à celui qui subit sa carrière.

Notez également qu’au-dessus de Sénior je ne mets pas Manageur. En effet Manageur est un type d’activité, dans lequel on peut être junior, confirmé ou sénior (confère encore les carrières).

Ce message s’adresse en partie aux consultants, pour savoir se situer en dehors de la surenchère des SSII dont c’est un levier pour faire grimper le taux de facturation (ainsi que compenser l’absence d’augmentation de salaire), mais également aux clients.

Pour ces derniers, ne vous attendez pas à ce qu’un consultant avec 2 ans d’expérience vous implémente une solution de bout en bout s’il est laissé tout seul sans encadrement. Soyez dubitatifs si c’est un confirmé qui est sensé encadrer 2 développeurs juniors. A force de vouloir tirer les prix vers le bas, vous voilà sous-équipés pour réussir.

La Dream Team, Basketball USA aux Jeux Olympiques de 1992

A vous de savoir assembler la dream team (ça ne nous rajeunit pas) !

Si votre projet est relativement simple, vous pourrez complétement vous appuyer sur des confirmés à la tête bien faite. Mais si le périmètre est suffisamment large pour nécessiter le déploiement de juniors, ou si le sujet fonctionnel est reconnu comme complexe, vous ne pourrez pas vous passer d’un sénior.

Même si ça paraît cher, il vaudra toujours mieux intégrer un sénior au 2/5ème à votre dispositif plutôt que prendre 6 mois de retard et livrer une solution de mauvaise qualité qui ne satisfera pas le besoin.

4 liens pour la semaine (2012-41)

Fleid 2 commentaires

Je triche et j’en mets 5 au lieu de 4 😉

  1. Une grosse discussion chez Kalzumeus sur le pricing des produits et du service. Plein de bons arguments pour augmenter ses prix.
  2. Dans la même veine, on continue sur le service avec un article de Sebastian Marshall qui rappelle qu’un consultant servile ne sert pas vraiment son client.
  3. Encore Sebastien Marshall, avec une excellente remarque sur la documentation interne à l’entreprise: si elle est pénible à lire, c’est qu’elle est ratée!
  4. Seth Godin avec une métaphore pleine de piquants.
  5. Enfin, le point de vue Lean d’Evolving Excellence sur le management de l’innovation.

______________________

<< Semaine Précédente – Semaine Suivante >>

Tendances ERP – Retour d’un consultant décisionnel sur l’avenir de l’ERP

Fleid 2 commentaires

Cette semaine je me suis rendu aux « Salons Solutions », au CNIT, le centre de conférences de la Défense. En gros c’est un salon qui parle ERP (Entreprise Resource Planning), CRM (Customer Relationship Management), Décisionnel et de tout un tas d’autres solutions informatiques comme la dématérialisation ou la gestion informatique de la supply chain.

Je me suis déplacé car j’ai reçu une invitation de Jean-François Ruiz, cofondateur de l’agence de webmarketing PowerOn, pour assister à la conférence « Tendances ERP » ayant lieu lors dudit salon. Le thème est assez facile à deviner, je vous économise l’explication de texte.

On peut se demander pourquoi un consultant décisionnel peut avoir envie d’assister à une conférence sur les ERP ? D’autant que vous le savez, je suis assez partisan du courant lean, courant qui rejette assez fortement la notion même d’ERP (tout du moins leur implémentation actuelle).

Les réponses sont plutôt simples : d’abord parce que Jean-François Ruiz a fait un super boulot de wording sur son invitation, il a su me donner envie. Ensuite parce que cela fait partie de mon job de consultant de faire de la veille sur les briques technologiques adjacentes à la mienne. Enfin pour voir si nos petits collègues du monde ERP subissent les mêmes buzzwords que nous autres professionnels de la base de données. Je n’ai pas été déçu 🙂

Dans la foule beaucoup de consultants ERP, beaucoup d’indépendants d’ailleurs, un consultant CRM et un BI (coucou), quelques clients, des universitaires, des recruteurs (qui viennent acquérir un background technique pour être meilleurs en entretien, respect), des ingénieurs d’affaires (qui viennent polir leur discours sur les nouveautés, respect aussi), et pas mal de représentants d’éditeurs (petits et gros, d’ERP ou de solutions connexes). Un panel plutôt représentatif en somme.

La conférence débute par un petit mot de Christine Coudert, directrice marketing chez SAP, sur la volonté qui anime en ce moment l’éditeur de créer une communauté web dédiée à l’ERP (et pas seulement à SAP), dont les premiers gestes forts sont cette conférence et la publication d’un livre blanc en mode collaboratif. Etant pas mal impliqué dans la communauté décisionnelle Microsoft, je ne peux qu’être positif face à cette initiative. Je leur souhaite bien du courage, et les encourage à maintenir leur effort dans la durée. Je fais juste une petite remarque en passant, Mme Coudert si vous voulez monter une communauté web, soyez sûre de disposer au minimum d’un profil linkedin et viadeo à jour, voire d’un twitter, ça rend la tâche aux bloggeurs beaucoup plus facile pour vous relayer.

Pour le contenu de la conférence, je vous fais un petit débriefe par orateur, dans l’ordre d’apparition. Il est à noter qu’un participant a demandé au premier orateur de présenter son expérience vis-à-vis des projets d’ERP (de justifier sa crédibilité quelque part), et qu’au final tous les orateurs s’y sont pliés, c’est bien.

Emmanuel Laignelet (twitter – linkedin) – Directeur Technique chez Astek

  • 12 tendances identifiées :
    • Consolidation de l’offre: peu de très gros éditeurs, mais de plus en plus d’acteurs de niche
    • Verticalisation : la technique devient commodité, l’offre se spécialise et se package par métier
    • Virtualisation : cloud (côté back office) et mobilité (portabilité des environnements)
    • Modernisation : il est venu le temps de payer les dettes techniques
    • Collaboration : les interfaces doivent intégrer des fonctionnalités de type réseaux sociaux
    • Externalisation de la gestion des référentiels : c’est un sujet trop politique, le MDM, pour des projets déjà trop politiques, les ERP
    • Évolution de la mise en œuvre : les clients sont désormais matures, ils savent ce qu’ils veulent et ne tombent plus dans le panneau des discours marketing des éditeurs et consultants. Également un focus sur la modélisation, maintenant que le software est au niveau des attentes, on arrive au fond du panier et on affronte les vrais problèmes, les métiers, qui ne trouvent des réponses qu’à travers une modélisation élégante des processus de l’entreprise. Enfin, une mention sur la conduite du changement, peu importe la solution, si elle n’est pas correctement présentée elle sera rejetée.
    • Montée en puissance du paramétrage…
    • … et diminution du spécifique. Avec un deuxième objectif : la fin des langages propriétaires pour contribuer à faire de la technique une commodité.
    • Facilité de l’intégration : tant en terme technique (gestion des uptades) que du licencing. Manifestement c’est un cauchemar côté ERP, on ne connait pas ça côté BI (tout du moins dans le monde Microsoft)
    • Facilité d’usage en termes d’interface utilisateur
    • Raccourcissement du ROI, l’époque des projets ERP en 2 ans est terminée, maintenant il faut prouver sa valeur à court terme.
  • De ses 12 tendances chacun doit tirer une conclusion : les éditeurs doivent offrir des solutions verticales en SaaS, les intégrateurs doivent développer des offres métiers décorrélées des technos et justement fournir de l’aide au choix.
  • Mon avis : Tendances ou envies, on a du mal à faire la différence, mais rien n’est à jeter dans cette liste. J’ai beaucoup aimé son discours, plein de bon sens et d’enseignements à tirer pour la BI.

Benjamin Drieux (linkedin) – DSI en client final

  • Les tendances identifiées : on ne parle plus vraiment d’ERP mais de SI intégré. Avant un ERP c’était un avantage compétitif, maintenant une entreprise ne peut plus fonctionner sans avoir un SI intégré, dont les briques communiquent nativement entre elles. L’ERP devient une commodité sur le plan technique, la complexité bascule côté métier. Les DSI doivent donc se staffer de chefs de projet métier, à l’expertise fonctionnelle, et ne plus se soucier d’une brique technique devenue standardisée. Un bon éditeur sera alors celui qui aura le meilleur réseau d’intégrateur, capable d’assurer la traduction fonctionnelle/technique, et d’utiliser la bonne brique packagée au bon moment.
  • Mon avis : Je suis assez d’accord qu’une entreprise ne peut plus vivre en 2012 avec des applications en silo, qui ne communiquent pas entre elles. Enfin elle peut, mais c’est terrifiant d’inefficacité. D’ailleurs un des premiers rôles du décisionnel c’est effectivement de brasser des données de domaines applicatifs distincts. C’est la première étape dans la vie du SI de l’entreprise, mais c’est clair que ce n’est pas suffisant. Il faut que ce brassage se fasse à l’intérieur même des flux métiers. Quant à sa définition de l’ERP comme un SI intégré, c’est jouer sur les mots. Sauf si par là il veut dire que des briques logicielles spécifiques par métier, orchestrées par un EAI et un MDM, sont considérées comme un ERP ? Alors là on va être copains! Mais ce sont les éditeurs d’ERP qui risquent de ne pas être contents 😉

Jean-Louis Tomas (viadeo) – Consultant expert et auteur

  • Surement plein de choses intéressantes sur la gestion de projet ERP, c’est un monsieur qui m’a l’air très savant. Mais sa présentation était à mon sens complétement hors sujet par rapport au thème de la conférence. Ou alors je n’ai rien compris.

François Bonnet (viadeo) – Responsable marketing chez un petit éditeur

  • Honnêtement j’ai décroché. Il est très sympathique et m’a l’air plein de bonne volonté, mais il n’a fait que vendre son produit et personnellement je n’étais pas là pour acheter un ERP de niche.

Jacques Gorre (linkedin) – Au titre un peu incompréhensible chez SAP

  • 4 tendances identifiées : Mobilité (lieux et types de terminaux), collaboratif, temps réel et montée en volumétrie point de vue data (même non structurée, conséquence des 3 premières tendances)
  • Pour répondre à ces tendances, nécessité des éditeurs de penser en plateforme, de rechercher une certaine neutralité technique pour répondre à tous les usages et terminaux. Egalement pour répondre rapidement aux besoins, penser en approche itérative (livrer par petits incréments plutôt qu’en big bang) à travers la standardisation verticale de l’offre (un module RH, un module finance d’entreprise…) et la diminution du spécifique. Passer du développement au paramétrage en somme.
  • Et la réponse de SAP à tout ça ? Le in-memory… et là, tout s’écroule. Autant les visions qu’il dégage sont intéressantes, autant venir parler d’in-memory à ce moment n’a aucun sens. C’est comme parler de l’urbanisation de nos villes et de la réflexion sur l’optimisation des moyens de transport, pour conclure sur le fait que l’injection électronique des moteurs diesel va tout révolutionner. Ok le gros de la force de frappe marketing de SAP est sur l’in-memory en ce moment, mais quel rapport avec la choucroute? Dommage, ça décrédibilise le reste du message qui était pourtant très intéressant.
  • Mon avis : très bonne idée de voir l’ERP comme une plateforme d’entreprise. Pourquoi ne pas aller plus loin et l’imaginer à la facebook ou twitter, et offrir des API ouvertes sur des langages standards aux intégrateurs et développeurs pour qu’ils construisent les 5% de spécifique qui sauront faire la différence auprès des utilisateurs finaux ? Cool non ? Mais je ne sais pas si SAP, notoirement connu pour l’aspect verrouillé de sa technologie (langages spécifiques, obscuration technique, verrou à l’extraction des données… corrigez-moi si je me trompe), est prêt à faire le grand saut dans cette direction.

Les grands absents à mon sens : l’Agilité (la vraie, avec un A majuscule) et le Lean IT. Pourtant dans le salon j’ai vu des éditeurs d’ERP qui en faisaient les éléments différenciant de leur offre. Autre chose : la volonté du tout packagé me fait personnellement un peu peur. Plusieurs essayent en BI, mais rien de bien concluant. Aujourd’hui on parle plutôt de BI self-service, soit confier l’élaboration du spécifique directement à l’utilisateur final. Je ne sais pas si le cas d’usage est applicable dans le monde de l’ERP, mais ça n’a pas non plus été évoqué. Enfin, notez comme on a réussi à parler de Big Data sans utiliser le mot. Je ne sais pas trop pourquoi il n’a pas été employé, mais c’est rafraichissant de ne pas le voir mis à toutes les sauces comme c’est le cas en décisionnel.

Un dernier mot concernant l’animation de la conférence en elle-même. Là aussi Jean-François Ruiz a fait un super taff, c’était fluide et sans temps mort, beau boulot. Merci aussi aux sponsors et organisateurs : SAP et PowerOn.

En conclusion vous l’avez compris, je ne regrette pas de m’être déplacé. Trois très bonnes interventions, plein de bonnes idées transposables à la BI, et puis c’est toujours rassurant de voir que quel que soit la stack IT, on a tous les mêmes problèmes 😉

4 liens rapides pour la semaine (2012-37)

Fleid 6 commentaires

4 liens pour une semaine de rentrée qui s’annonce bien chargée !

  1. Le lien à lire absolument cette semaine, sur l’état de notre économie. Absolument. Via BoingBoing.
  2. 37signals qui achète des parts de la société The Starter League (anciennement Code Academy). Ça c’est de l’investissement tel qu’il devrait l’être.
  3. Vous sauriez expliquer la différence entre les probabilités et les statistiques ? Maintenant oui !
  4. Enfin, un article long mais fascinant sur la confiance en soi.

______________________

<< Semaine Précédente – Semaine Suivante >>

Bataille d’experts : fournir les bons arguments à son DSI pour trancher sur des sujets techniques

Fleid 7 commentaires

Avec la fonction d’architecte, et plus globalement la séniorité (autrement dit la vieillesse, oui, merci…), vient la responsabilité un peu particulière d’arbitrer les désaccords sur des sujets techniques. Si la plupart du temps l’expérience permet de trancher immédiatement une discussion, il apparaît régulièrement des débats où une théorie vaut l’autre. Soit ça, soit un des acteurs fait preuve d’un dévouement sans faille à son idée et refuse la sagesse de ses aînés. Très saine attitude soit dit en passant.

Quand il y a peu d’enjeu, ou que ces débats ont lieu assez tôt dans le projet, on réalise des prototypes, on teste, et si le perdant est un gentleman, toute l’opération prend une tournure sympathique. C’est d’ailleurs plutôt sain de laisser s’exprimer tous les avis, et de tester effectivement où se situe la vérité. Tout le monde apprend énormément, on disperse les mythes issus du culte du cargo, les tensions s’apaisent et j’irais même jusqu’à dire que le respect nait entre les participants.

A l’autre extrême se situent les batailles d’experts sur des sujets ultra pointus, avec toute la direction en arbitrage, des centaines de K€ de facturation dans la balance et des relations client/fournisseur au bord du gouffre, et là on rigole beaucoup moins.

Tableau "Les Sabines" par Jacques-Louis David - Une bataille de l'antiquité avec des gens tout nus

Depuis les consultants portent des costumes, et c’est quand même moins gênant.

J’ai vécu ce type d’escalade plusieurs fois dans ma carrière, et l’une d’elles est suffisamment éloignée dans le temps pour que je puisse en parler sans fâcher personne, surtout qu’aujourd’hui je commence à croire que j’avais tort – je vais y venir.

J’étais donc employé chez un grand nom du BTP, en interne et non comme consultant, et j’étais en charge du pôle de développement pour la plateforme décisionnelle des ressources humaines. En gros je gérais une petite équipe de développeurs en mode projet sur le domaine RH, en tant que manager et chef de projet, et dans mes objectifs j’avais également pour fonction d’assurer la qualité, la maintenabilité et l’évolutivité des applications de mon périmètre.

Une des plus grosses applications de ce dit périmètre était évidemment la plateforme de reporting aux 1’500 responsables de paye du groupe (en SSRS), appuyé sur un datawarehouse (SQL Server) d’un beau gabarit pour suivre les 70’000 collaborateurs du groupe.

L'armée de Terracotta

Heureusement, on ne modélise plus les datawarehouses en 1:1

Il est à noter que cette application m’avait précédée dans la société, elle avait été réalisée par un prestataire que je ne nommerai pas. Moi j’étais arrivé à peu près au moment du passage au lot 2 sur 8, avec un lot 1 globalement validé et déployé en production.

Vous vous doutez bien que si le DSI avait décidé d’internaliser les chefs de projet (moi côté réalisation, un très bon camarade côté étude), c’est que ça coinçait dans son rapport avec le prestataire. Les consultants ayant complétement séduit leur client – la DRH – ils se permettaient des comportements inexcusables vis-à-vis des acteurs de la DSI.

Notre rôle était donc de restaurer l’équilibre dans le projet en apportant la compétence décisionnelle côté DSI. Je n’ai jamais eu le détail du plan de bataille du DSI, mais rétrospectivement je pense que l’objectif était de prouver que la solution n’était pas très propre techniquement, pour décrédibiliser le prestataire auprès de la MOA (la DRH) et le remplacer. Aujourd’hui j’ai appris ma leçon : vouloir régler des problèmes politiques avec des arguments techniques, ça ne marche pas. A l’époque j’étais encore utopiste, donc je me suis lancé.

Un soldat qui utilise une guitare à la place d'un fusil

Bien choisir ses armes, c’est important.

Et sur le plan technique, il y avait beaucoup à dire sur cette solution. Modélisation dimensionnelle déplorable (200+ dimensions, en flocon et en étoile en même temps, SCD implémentés dans la table de fait…), ETL en procédures stockées (100+), plus de 150 tables d’agrégats, bugs de sécurité critiques sur SSRS, etc. etc. J’ai monté un dossier de 50 pages sur le sujet et évidemment on a convoqué le directeur technique du prestataire, responsable de l’architecture, pour discuter de tout ça.

Ce qu’il en ressort, c’est qu’avec beaucoup d’assurance, voire d’arrogance, on fait avaler n’importe quelle couleuvre technique à un décideur. Et c’était à prévoir : un DSI comprend des questions de performance, de fonctionnalités, de livraison et de MOA satisfaite. L’élégance du code, la beauté d’une normalisation, le respect des bonnes pratiques, ce n’est pas vraiment son problème tant qu’ils ne s’illustrent pas par des jours-hommes, à travers une facturation qui explose ou des retards incontrôlés. Donc oui, il était d’accord avec nous sur le principe, mais nos arguments techniques ne lui ont jamais permis de gagner l’avis du DRH face à la solution effectivement déployée, effectivement accessible aux utilisateurs et à peu près performante.

Et c’est là que tient la réponse à la question posée par cet article : comment fournir des bons arguments à son DSI pour l’aider à trancher un sujet technique ?

  1. Illustrez vos arguments techniques par des impacts projets forts. Donnez des chiffres (performances, coût de maintenance à N+1, coût des régressions, coût du support, surcharges sur les développements, effondrement du ROI…), rappelez les risques sur l’évolutivité, la difficulté à trouver un prestataire de remplacement qui s’engagera à cause de la spécificité des développements… Et illustrez tout ça, faites des prototypes, calculez les performances, faites des plannings qui prouvent ce que vous avancez. Apportez des éléments concrets qui ont du poids dans le référentiel de valeur de votre décideur.
  2. Et attendez votre heure. Cela ne sert à rien d’avoir raison trop tôt. Choisissez vos batailles, ne partez pas en croisade contre la terre entière, soyez patient. Il vous faudra attendre qu’on vienne vous chercher, qu’on ait besoin de vous, pour avoir un impact quelconque sur la situation. Par contre soyez prêt quand le moment viendra (confère point 1). Attention, je ne dis pas de rester en sous-marin et de ne pas lever d’alertes, au contraire : donnez votre avis franc, honnête et informez votre hiérarchie de ce que vous percevez. Mais sachez accepter votre destin, jusqu’au moment où l’opportunité de faire changer les choses apparaîtra. On ne sait jamais la carrière de qui, là-haut dans la direction, dépend de la réussite ou de l’échec du projet…

Et si vous n’arrivez vraiment plus à supporter votre quotidien, comprenez que c’est vous qui n’êtes pas à la bonne place, et pas l’inverse.

Pour conclure, pourquoi ai-je dit qu’aujourd’hui je pensais avoir eu tort à l’époque? Parce qu’au final : ok le prestataire était 2 fois plus cher que les prix du marché (vraiment fois 2), ok la modélisation était inacceptable, ok la qualité de données n’aurait jamais réussi à dépasser 90% de précision et ok les coûts de maintenance étaient partis pour exploser, mais le reporting sortait et la MOA était satisfaite du deal. Tout est là : je suis parti en croisade avec des arguments purement techniques (point 1) alors qu’à cet instant t, le système donnait satisfaction à ses utilisateurs (point 2), et trop contents d’avoir enfin un vrai reporting automatisé, ils n’étaient absolument pas concernés par le moyen terme. C’était donc perdu d’avance.

Aujourd’hui ce que je me dis c’est qu’il y a suffisamment de gens qui ont besoin d’aide et qui le demandent, pour ne pas vouloir aller aider ceux qui estiment ne pas en avoir besoin. Tout du moins pour un consultant décisionnel hein, si vous êtes médecin ou pompier ce n’est pas la même histoire…

MàJ 16/10/2012 : Si vous avez lu jusqu’à la fin, vous serez surement intéressé de savoir que j’ai écrit depuis l’article symétrique: Savoir trancher un sujet technique lorsqu’on est DSI.

PS : Salut aux camarades tombés pour la cause, ils se reconnaitront 😉