Une rentrée bien silencieuse…

S’il est vrai que mon rythme de publication a bien ralenti dernièrement, ne vous inquiétez pas, c’est pour de saines raisons !

J’en avais déjà parlé, et vous l’avez certainement vu à travers mes récentes lectures, je travaille à fond sur ma veille technologique. Avec David nous avons la chance de disposer d’un peu de bande passante pour la R&D, on ne pourra pas nous reprocher de n’avoir su en profiter :

  • Big Data avec Pig et Hive sur HDInsight (Hadoop sur Azure, le cloud Microsoft). David présente même une session sur le sujet au SQLSat ce samedi
  • Passage de la certification ScrumMaster. Alors oui le plus gros critère de notation c’est la présence à la formation payante, mais bon… C’est qui les patrons de la BI Agile maintenant ? 😉
  • Et surtout un gros focus sur Machine Learning à travers : la formation Coursera de Stanford (spéciale dédicace à notre camarade de classe Geoffrey), 10 semaines de cours sur la théorie et son application dans Octave (un dérivé Open Source de MatLab). Et là on enchaine sur le parcours certifiant de Data Scientist de l’Université Johns Hopkins, toujours sur Coursera, 10 modules de 4 semaines, cette fois en employant R.

Maintenant je peux le dire : franchement, le Machine Learning, ça déchire.

Je vais bien sûr vous faire découvrir (ou dépoussiérer) la discipline prochainement via une série d’articles, mais je voulais avant cela bien digérer le tout. En effet une des premières leçons qui m’a été transmise est la suivante (via Drew Conway) :

Diagramme des compétences requises en Data SciencePetit jeu: saurez-vous placer le spécialiste BI là-dessus ?

  • Hacking Skills (capacité technique) : Check !
  • Expertise métier ? Derrière une bonne modélisation dimensionnelle se cache une belle compréhension du métier : Check !
  • Math et Stats : bof bof…

Vous l’avez deviné, en plein dans la Danger Zone !

Archer et Lana, quote Danger Zone

Je vous laisse lire l’article qui va avec pour creuser, mais vous comprendrez donc que j’avance prudemment sur le sujet. Parce qu’il ne faudrait pas que sous prétexte d’occuper le terrain, je vous enduise d’erreurs 😉

 

La BI ça vous gagne : Audience au 20/05/2013

Un mois de retard pour cette 6ème revue de l’audience de La BI ça vous gagne!

Rappel des éditions précédentes:

Abonnements :

  • RSS : 26 – autant qu’il y a 7 mois, un effet de la mort annoncée de Reader?
  • Twitter : 110 (précédemment : 64)
  • WordPress : 22 (précédemment : 9) , beaucoup de bloggeurs, c’est chouette d’être reconnu par ses pairs 🙂
  • Mail : 13 (idem)

Le total passe de 112 à 171, +50% en 7 mois, joli!

Statistiques WordPress :

Audience LBCG 2013-05-17

La moyenne des visites semble se stabiliser entre 3500 et 4000 visites par mois, soit un peu moins de 2000 visiteurs uniques. On peut noter que j’ai un peu ralenti mon rythme d’écriture en ce début d’année, et que donc ces articles font plus de visites.

Top 10 des articles :

Chiffre des 3 derniers mois :

Title Views
Gestion de Projet Décisionnel – Méthodes Agiles ou Cycle en V ? 1,515
Les différentes carrières du consultant décisionnel 618
Modèle d’organisation de la DSI, ce qu’il ne faut pas faire. 522
Petit Rappel Consulting: Forfait, Régie, Régie forfaitée… 413
Consultants Juniors, Confirmés, Séniors, quels critères pour quantifier l’expérience? 343
Rapide revue de Tibco Spotfire face à Tableau 342
Modélisation dimensionnelle à éviter : La table de faits universelle 329
Décisionnel Agile : Réaliser son Datawarehouse en itérations agiles 284
Modélisation Dimensionnelle : Les Fondements du Datawarehouse (webcast) 273
Projet décisionnel : choisir la bonne technologie dans l’offre Microsoft SQL Server 204

Une belle montée des « carrières » et des articles orientés consulting. Encore une grosse présence des articles sur l’Agilité, ça me fait plaisir. La surprise c’est la revue Tibco/Tableau qui semble avoir trouvé son public en mars/avril.

Top 10 des référents

Chiffre des 3 derniers mois :

Referrer Views
Search Engines 5,000+
Twitter 65
Netvibes 48
Facebook 23
blog.djeepy1.net 21
viadeo.com 19
fjehl.wordpress.com 15
fr.wordpress.com 14
perceptualedge.com 13
linkedin.com 12

Pas de surprise, le gros de la troupe vient de Google. Mais à mon sens le « vrai » trafic, celui qui compte, a plutôt tendance de venir des suivants. Un bisou en passant à Jean-Pierre et François 😉

Conclusion

Après bientôt 3 ans et 300 articles, je suis plutôt satisfait du résultat. J’ai plein de choses à raconter sur mon aventure de manageur (désormais nous sommes 13!), mais évidemment c’est encore trop tôt. Et de votre côté, satisfaits également? Toujours intéressés?

La BI ça vous gagne : Le Best-Of 2012 !

Comme l’année dernière, et comme vu à la télé, il est venu le temps des best-of de fin d’année 🙂

Voici donc une sélection de vos et mes articles préférés de La BI ça vous gagne en 2012, dans le désordre :

Consulting

Décisionnel / IT

Stratégie / Management

Hors sujet

J’encourage vivement tous mes copains de blogroll à faire de même, au boulot les gars !

Et pour finir, je vous souhaite à tous une très bonne année 2013 😉

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

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 😉

Au revoir 2011, et bonne année 2012 :)

Tout comme en 2010, je me livre à l’exercice réglementaire de fin d’année de la revue des accomplissements professionnels.

Pour moi 2011 ça a été :

En tant que « chef de projet / architecte » : Reprise en main d’un centre de service qui partait à l’abandon. Des anomalies critiques de plus de 3 mois, aucune évolution livrée en 6 mois, les tickets mantis qui s’accumulaient… Cela a pris du temps, mais j’ai réussi à monter une équipe de feu qui a su remettre la plateforme décisionnelle sur les rails. Ma principale réussite sur ce sujet c’est le recrutement. C’est définitivement une des plus belles équipes avec lesquelles j’ai pu bosser. Merci à eux!

En tant que développeur je suis également satisfait, puisqu’en 50 jours j’ai livré une solution pointue qui ravit ses utilisateurs, qui brasse 30 millions de lignes par jour et qui n’a connue aucune anomalie en 9 mois. Ouais je frime 😉

Je suis évidemment très content de la tournure que prend ce blog. Voir grandir la tribu qui gravite autour de La BI ça vous gagne est une grande satisfaction, merci à vous! Cela dit j’aurai pu faire mieux en terme de rythme, je manque de rigueur…

Les Journées SQL Server! Ça aussi je suis très fier d’y avoir participé. J’avais l’habitude de présenter des sujets devant des salles de classe, là c’était mon premier grand amphi et je me suis éclaté! C’est beaucoup de boulot mais ça le vaut vraiment.

Et plus personnellement, en 2011 j’ai vraiment essayé d’apporter le « bien » autour de moi, de contribuer aux gens qui m’entourent, aux tribus auxquelles j’appartiens, et de faire que tous se sentent bien. Là ce n’est pas à moi à dire si ça a marché, n’hésitez pas à me faire votre retour 🙂

Et 2012 alors?
Deux grands thèmes pour 2012 : la communauté – au sens large mais aussi la communauté proche – et SQL Server 2012. Cela peut paraître trivial mais ce nouveau produit va générer beaucoup d’opportunités, beaucoup de mouvement, la résistance au changement va baisser et c’est à ce moment là que les belles choses peuvent se produire.

Et pour vous? 2011 ça a été quoi?