Les différentes carrières du consultant décisionnel

Je vous parlais précédemment du métier de consultant et de la veille technologique associée, et cela m’a lancé sur une réflexion autour des différentes facettes que l’on regroupe sous ce titre.

L’objectif de cet article est plutôt simple : mieux percevoir l’activité du consultant, savoir quelles sont les compétences à travailler pour progresser et également quelles sont les possibilités d’évolutions qui s’ouvrent à ceux qui prennent leur carrière en main.

Cette vision de la chose est issue de mon expérience personnelle. Je suis donc évidemment preneur de votre retour sur le sujet, d’autant plus si vous utilisez une grille de lecture précise qui diffère de celle qui suit.

Pour faire simple je vais découper l’activité du consultant sur 5+2 domaines de compétences, 5 qui s’appliquent en mission, 2 en dehors. Je regrouperai ensuite ces domaines en 8 carrières classiques, ce qui permettra à chacun d’identifier son positionnement et le titre qui lui convient.

Choix de carrière sur les SIMS Social

On commence donc avec les domaines de compétences en mission:

En Mission


Technologies

Activités Connaissance des outils. Capacité à réaliser.
Question associée Comment faire
Progression Par techno, niveau de 1 à 5 : SSIS / SSAS / SSRS / SQL / DAX / MDX …

Théorie du Décisionnel

Activités Capacité à concevoir des solutions. Connaissance des techniques, de la modélisation.
Question associée Quoi faire
Progression Compréhension de l’activité, qualité des modèles, justesse des propositions et remarques…

Fonctionnel

Activités Connaissance des problématiques clients (RH, Finance, Retail, Industrie…).
Question associée Pourquoi le faire
Progression A travers les projets, en diversité, nombre et profondeur…

Gestion de Projet

Activités Faciliter le quotidien, gérer la logistique dans la mission, suivre l’avancement.
Question associée Quand / Combien
Progression Nb et type de projet (forfait / régie), méthodologies (V, Agile), outils planning et budget…

Relation Utilisateur

Activités Recueil du besoin, conduite du changement, assistance à la recette.
Question associée Qui
Progression Aisance générale, qualité des livrables, forme des presentations…

Plus 2 domaines de compétence hors mission:

Hors Mission


Développement du Business

Activités Avant ventes, construction de l’offre, contribution à l’image publique (blog, whitepaper…)
Périmètre Extérieur à l’entreprise
Progression Réussite des A/V, qualité de l’offre, qualité de l’image (appels entrants, canditatures spontanées…)

Management

Activités Gestion du groupe, formation, logistique entre les missions, accompagnement dans la carrière.
Périmètre Dans l’entreprise
Progression Qualité de la vision à long terme, Satisfaction des consultants, faiblesse du turnover, cooptation

Maintenant qu’on a identifié les compétences, on va pouvoir positionner notre premier métier de consultant : le développeur junior, sur la grille.

Les compétences du Développeur Junior

Son premier chemin d’évolution naturel est de monter en compétence sur les technos, de prendre du recul et commencer à penser solution (théorie du décisionnel) et d’apprendre le fonctionnel à travers ses missions. Plus le bleu est sombre et plus la maîtrise est grande.

Compétences des Développeurs

Mais devenir développeur sénior n’est pas sa seule option, il peut choisir d’évoluer vers les autres métiers du décisionnel, qu’on identifiera à partir de leur compétence majeure (bleu foncé):

Métiers du Décisionnel

On peut noter l’absence d’un expert de la relation client, qui à mon sens est en dehors du périmètre du consulting décisionnel et plus dans l’organisationnel. (Update 18/04/2012) David Tang me propose d’inclure le Formateur comme expert de la relation utilisateur, je trouve ça excellent, l’article est mis à jour en conséquence.

Cette liste je la reprends ici:

  • Développeur : Il a déjà de nombreux projets derrière lui, il connaît les produits, les technos, il sait industrialiser les solutions, il développe en solo ou en équipe. Dans tous les cas, dans toutes les situations, il livre.
  • Expert Technique : Il connaît les produits par coeur, toutes les astuces, tous les bugs classiques, toutes les optimisations. C’est lui qu’on appelle pour décoincer une production récalcitrante ou réussir à implémenter cette fonctionnalité qui nous résiste.
  • Architecte : Il voit la solution de bout en bout, fabrique les prototypes, modélise le datawarehouse. C’est lui qui fait la jointure entre la technique et le fonctionnel, le guerrier du « Many to Many », c’est l’évangéliste de Kimball 😉
  • Consultant AMOA – Assistance à Maîtrise d’Ouvrage: Lui sa spécialité c’est les problématiques des clients. Il connaît les métiers (la RH, le retail…), il sait parler aux utilisateurs pour extraire et transmettre les spécificités de leurs besoins aux autres membres de l’équipe.
  • Chef de Projet : J’ai une notion très « Berkunienne » du chef de projet. Pour moi ce n’est pas un manageur, il ne dirige pas des hommes. C’est plutôt un facilitateur, qui fait tout pour que le projet se déroule sans accroc, pour que les autres membres puissent bosser tranquillement. C’est lui qui surveillera les plannings et les rapportera à qui de droit.
  • Formateur : C’est lui qui répand la bonne parole, et les bonnes pratiques, à travers les centres de formation. C’est également lui qui met en place les événements, prépare les présentations et animation, et entretient l’effort de veille technologique au niveau du pôle.
  • Ingénieur Avant Vente : Il accompagne les commerciaux en avant-vente, c’est lui qui gagne les missions et qui prépare l’arrivée de l’équipe projet. Evidemment il connaît le domaine décisionnel puisqu’il répond aux appels d’offres et participe aux chiffrages, qu’il anime des séminaires et qu’il représente l’équipe sur les salons. Il faut l’aimer, puisque c’est lui qui empêche les commerciaux de dire oui à tout 🙂
  • Chef de Pôle : Le vrai manageur de la troupe, il accompagne les consultants dans leur carrière sur la durée.

Évidemment ces rôles ne sont pas exclusifs, on assume tous très souvent plusieurs casquettes en même temps, lorsque le périmètre est petit ou que les compétences manquent. Typiquement: le chef de projet / expert technique, qui encadre les juniors et répond à leurs questions techniques tout en remplissant les plannings quand il a le temps. On a aussi le chef de pôle / ingénieur avant-vente, tant que le pôle fait moins de 20 personnes. Et toutes les autres combinaisons qu’on peut imaginer.

Cela dit, et pour éviter de se diluer, il est bon de donner une orientation majeure à sa carrière, et donc de choisir un titre de prédilection dans la liste. Une fois qu’on a ce point de départ, on peut se projeter et choisir où l’on souhaite se retrouver dans 5 ans.

La progression s’effectue alors sur 2 axes: le premier c’est ajouter du bleu clair dans de nouvelles cases, et donc potentiellement agrandir sa collection de titre comme on collectionne les pokémons. Le second c’est foncer le bleu dans une case, et donc gagner en expertise sur un sujet. De cette manière on retrouve aussi les pokémons, sauf que cette fois ils évoluent:

  • Le développeur s’endurcit, il sait réaliser tous les caprices exprimés dans les spécifications et jongle avec les 35 étapes requises pour la montée en production
  • L’expert technique gagne en reconnaissance: confère Marco Russo, Chris Webb ou François Jehl, pour rester en Europe
  • L’architecte se séniorise, et invente de nouveaux frameworks… Certainement l’évolution la plus casse gueule
  • Le consultant AMOA devient directeur d’étude
  • Le chef de projet devient directeur de projet
  • Le formateur devient évangéliste, que ce soit auprès de l’éditeur ou pour sa société
  • L’ingénieur avant-vente devient responsable commercial
  • Et le chef de pôle grandit avec sa troupe. Diriger 100 personnes ce n’est pas la même chose qu’en diriger 5.

Faîtes le bilan d’où vous en êtes, choisissez votre chemin de progression, et le tour est joué! Vous ne sécherez plus lors du prochain entretien quand on vous demandera « vous vous voyez où dans 5 ans? », votre arbre de compétences sera déjà tout tracé:

Arbre de compétences - World of Warcraft

Apprendre un nouveau langage de programmation ou lire un bouquin de méthodologie? Choisissez l’option qui correspond à votre plan de carrière. On vous propose 2 missions, l’une orientée AMOA et l’autre gestion de projet? Même combat: choisissez la compétence qui est sur votre chemin de croissance. Formez vous en ligne, montrez votre travail à travers un blog ou une contribution Open Source… Soyez actifs, décidez de votre avenir et vous arriverez au but 🙂

Pour conclure sur ce sujet je m’adresse aux chefs de pôle et/ou aux responsables RH. Si vous en utilisez un, je pense qu’il est très bon de coupler le référentiel de compétences avec votre grille de rémunération pour obtenir des salaires distribués de manière objective (cf Joel Spolsky). Rien de tel pour motiver vos collaborateurs à prendre en main leur carrière. Tout le monde est gagnant!

Petite réflexion autour de l’accélération des technologies

En ce moment l’écosystème décisionnel Microsoft est en ébullition. Avec la sortie de SQL Server 2012, c’est tout un camion de nouvelles technologies qui débarque dans notre petit jardin: le DAX, SSAS Tabular, PowerPivot, Power View, Data Explorer, des gros morceaux de SharePoint qui s’incrustent, Windows 8, les évolutions SSIS, le T-SQL version 2012… On a un peu l’impression d’avoir un nouveau langage / environnement à apprendre tous les 3 jours.

Même en dehors de Microsoft le décisionnel bouge beaucoup, et on commence à parler Tableau, Qlikview, SpotFire, qui eux aussi requièrent une certaine expertise voir une expertise certaine.

Et si on revient chez Microsoft mais qu’on sort de la BI, on voit que ça bouge beaucoup, et que ça en fait s’interroger plus d’un !

Oh mon Dieu, du DAX!!!

Oh mon Dieu, du DAX!!!

Alors je crois que c’est le bon moment pour un petit rappel qui nous vient de 2002, de chez Joel Spolsky :

When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can’t fire at you.

Traduit approximativement :

Pendant mon service militaire, un général s’est adressé à nous pour un petit cours de stratégie. Dans les batailles d’infanteries, nous disait-il, il n’y a qu’une stratégie: tirer en mouvement. C’est à dire se déplacer vers l’ennemi tout en tirant dans sa direction. Le fait de tirer lui fait baisser la tête, ce qui permet de se déplacer sans qu’il vous tire dessus.

Qu’il applique à la technologie, quelques paragraphes plus loin:

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.

De nouveau traduit approximativement:

Pensez à l’histoire des protocoles d’accès aux données issus de Microsoft. ODBC, RDP, DAO, ADO, OLEDB, ADO.NET – tous tout neuf ! Etaient-ils technologiquement incontournables ? Ou le résultat de l’incompétence du groupe de design concerné ? Peu importe, le résultat c’est un tir de couverture : pendant que la compétition passe son temps à adapter son code elle n’a pas le temps d’écrire de nouvelles fonctionnalités.

Et nous autres, les utilisateurs de ces technologies, on est pris au milieu de la bataille.

Les juniors sont découragés par le nombre de technos à apprendre, les séniors s’offusquent d’avoir à apprendre encore un nouveau langage.

Tout ça c’est du « Fire & Motion » de l’éditeur, il est important de ne pas y succomber, car ce n’est pas notre guerre. Pour l’éviter : déterminer quel est votre objectif – réaliser des projets ? – et accomplissez le sans vous inquiéter de ne pas maîtriser l’ensemble des technologies de l’offre.

Ce qui est important c’est :

  • d’avoir les bases, la théorie essentielle indépendante de la techno : parler à un client de ses besoins, la modélisation dimensionnelle, de la gestion de projet élémentaire…
  • de maîtriser au moins une technologie, et connaître ses limites,
  • de savoir apprendre les autres, uniquement au moment où vous avez besoin d’elles et uniquement ce dont vous avez besoin
  • de savoir demander à l’aide.

Pour tous ces points, il y a la communauté. Abonnez-vous aux blogs, participez à FrenchConnection.BI et au GUSS, contactez les experts, bref, ne restez pas tout seul dans le noir 😉

Jusqu’à la fin de votre vie, plus vous apprendrez, plus vous réaliserez à quel point vous en savez peu. C’est de la philosophie de bas étage, mais c’est à garder en mémoire devant l’énormité du travail de veille technologique qui attend tout développeur / consultant qui se respecte.

Bon courage ! 🙂

La BI ça vous gagne : Audience au 06/04/2012

C’est en passe de devenir une tradition, c’est reparti pour un tour, levons les jupes de la BI ça vous gagne! 🙂

Rappel des éditions précédentes:

Abonnements:

  • RSS : 20 sur Google Reader, 3 par Feedburner (hors Google Reader)
  • Twitter : 35
  • WordPress : 5
  • Mail : 6

Si on dédoublonne à la louche, ça fait autour de 50 personnes qui suivent le blog régulièrement, c’est top! Et puis je parle quantité, mais ne parlons pas de la qualité! Que des lecteurs/contributeurs de la plus haute valeur 😉

Statistiques WordPress:

On passe désormais au mois, l’historique est enfin suffisant:

Audience de la BI ça vous gagne, 06/04/2012

Ca fait trois mois qu’on fait plus de 1500 vues par mois. Pas mal! Et j’ai du mal à réaliser mais ça va faire 2 ans que ce blog existe. C’est cool 🙂

Top 10 des posts :

Pour le top des posts, j’ai filtré pour ne prendre que les vues sur les 3 derniers mois.

Title   Views
Home page   1,750
Gestion de Projet Décisionnel – Méthodes Agiles ou Cycle en V ?   483
Décisionnel Agile : Réaliser son Datawarehouse en itérations agiles   383
Modèle d’organisation de la DSI, ce qu’il ne faut pas faire.   374
Projet décisionnel : choisir la bonne technologie dans l’offre Microsoft SQL Server   164
Modélisation Dimensionnelle : Les Fondements du Datawarehouse (webcast)   128
Gestion de projet décisionnel – Les valeurs de l’Agilité   125
PowerPivot, BISM, Analysis Services et Marco Russo   118
Gestion des dates en Transact SQL   99
Pour ou contre les clefs étrangères dans le datawarehouse?   95

Je suis assez content de voir que la série d’articles sur l’Agilité ait aussi bien marché. Elle me plait bien cette liste.

Top 10 des référents:

Toujours sur les 3 derniers mois:

Title   Views
Search Engines   1,832
Twitter   93
joubertd.blogspot.com   76
Netvibes (RSS)   76
Google Reader (RSS)   62
bleent.com   47
frenchconnection.bi   27
Facebook   23
sauget-ch.fr   23
Viadeo   18

La grande arrivée des communautés dans la liste, bleent.com et FrenchConnection.bi.

Top 10 des mots clefs:

Encore sur les 3 derniers mois:

Search Views
organisation dsi 85
la bi ça vous gagne 42
organisation d’une dsi 24
apple relation client 16
organisation de la dsi 16
florian eiden 15
débuter un projet décisionnel 13
fleid 12
générateur expression régulière 12
ssis 12

Pour les mots clefs il faudrait que je travaille un peu le dataset, il y a pas mal de redondances et il faudrait prendre en compte les permutations des mots. Ca va finir en projet décisionnel cette histoire!

Conclusion :

On est sur un petit rythme de croisière, ça marche bien, le réseau se met en place, je suis happy 🙂

Si vous voulez quelque chose, ou au contraire que quelque chose vous dérange, c’est le moment de le dire! Il y a quand même de fortes chances que rien ne change, mais au moins ce sera sur le tapis! 😉

4 liens rapides pour la semaine (2012-14)

Je triche, j’en ai mis 5 🙂

  1. Sebastian Marshall, avec la rapide histoire de Mithridate VI, roi de l’antiquité, pleine d’inspiration.
  2. Robert Reich, avec la fable du siècle. C’est politiquement engagé. Je le précise même si c’est difficile à rater!
  3. Via Jason Kottke, un rappel du bon sens : il faut savoir augmenter sa masse salariale pour gagner plus. Découvrir et/ou prouver ça, ça c’est une très belle utilisation du décisionnel.
  4. Via Flowing Data, l’histoire de George Box, devenu statisticien par accident. Deux choses que j’aime beaucoup dans cet article : le focus du Monsieur tout du long de sa carrière sur l’application des théories dans le monde réel; et l’excellente idée du « Monday night beer session » expliquée dans l’avant dernier paragraphe. Il faut définitivement qu’on fasse ça pour la FrenchConnection.bi 🙂
  5. Tout commence avec cet article de blog qui explique pourquoi Apple ne peut pas produire ses iPads aux USA. Qui à mon sens expose un concept fascinant, le « Beer Game », qui est vrai, mais qui n’a rien à voir avec pourquoi Apple et la production d’iPads en Chine. Les contre-arguments chez Hacker News, et chez Evolving Excellence.

______________________

<< Semaine PrécédenteSemaine Suivante >>

BD : xkcd – Recommandations

L’image est peut-être petite, n’hésitez pas à cliquer dessus!

BD : xkcd - Recommandations

Traduction Approximative:

Shopping avant le recommandation sur Internet:

  • Lui : Elle est jolie cette lampe.
  • Elle : Et pas très chère.
  • Lui : On la prend?
  • Elle : Ok!

Shopping maintenant:

  • Lui : Elle est jolie cette lampe.
  • Elle : Sur Amazon elle n’a que 1,5 étoiles. Tous les commentaires disent d’éviter cette marque.
  • Lui : Celle là a de bonnes revues.
  • Elle : Attends, un gars dit que lorsqu’il l’a branché, il a eu un gout métallique dans la bouche et ses chats sont devenus sourds.
  • Lui : Erf… Et pourquoi pas… Non, un commentaire fait remarquer qu’elle ressemble à un utérus.
  • Lui : Ok, j’ai trouvé un artisan suisse qui a des notes parfaites. Ses lampes valent au minimum 1300 Francs, et on peut seulement aller dans sa boutique par télé-siège.
  • Elle : Tu sais, notre chambre est très jolie dans le noir.

Petit Rappel Consulting: Forfait, Régie, Régie forfaitée…

Régie : Engagement de moyen

« Sur ce projet nous allons mettre 3 personnes à temps plein, du 1erjanvier au 12 décembre. »

  • Si on finit avant : Option 1 : les consultants restent jusqu’à la fin. Option 2 : les consultants partent et ne facturent que le consommé.
  • Si on ne finit pas à temps : les consultants s’en vont, à moins de commander une nouvelle prestation.

Particularités

  • Pour le client : pilotage complet de l’activité des consultants sur la période
  • Pour les consultants : Aucun risque sur la facturation

Facturation

  • On négocie un TJ, Taux Journalier, pour chaque consultant. On détermine la date de début et la date de fin de la prestation (nb: les anglosaxons préférent manifestement le taux horaire au taux journalier).
  • On multiplie le TJ par le nombre de jours de présence dans le mois, ça donne une facture mensuelle.
  • On prévoit des conditions de sortie dans le cas où on veut finir avant la date de fin (pénalités, préavis, proposition de remplacement…)

Forfait : Engagement de résultat

« Nous finirons le projet tel que défini dans le cahier des charges, avant le 12 décembre. »

  • Si on finit avant : les consultants s’en vont
  • Si on ne finit pas à temps : les consultants restent à leur frais, voir encourent des pénalités de retard si le contrat le prévoyait

Particularités

  • Pour le client : aucun coût en cas d’échec du projet, les consultants ne sont pas payés
  • Pour les consultants : plus grosse facturation si on finit avant, la compétence est récompensée

Facturation

  • On négocie un coût global et une date de livraison. On définit un périmètre précis.
  • On inclut également un échéancier de paiement (30% au démarrage, 50% à la livraison, 20% post-garantie).

« Régie Forfaitée »

« Sur ce projet nous allons mettre 3 personnes à temps plein, du 1erjanvier au 12 décembre. Sur cette période nous devrons finir le projet tel que défini dans le cahier des charges. »

  • Si on finit avant : Option 1 : les consultants restent jusqu’à la fin. Option 2 : les consultants partent et ne facturent que le consommé.
  • Si on ne finit pas à temps : les consultants restent à leur frais, voir encourent des pénalités de retard si le contrat le prévoyait

Particularités

  • Pour le client : c’est le beurre et l’argent du beurre
  • Pour les consultants : argument de vente massue pour ouvrir un compte capricieux

Facturation

  • Mode régie avant l’instant T
  • Aucune facturation en cas dépassement, voir pénalités.

« Forfait régitisé »

« Nous finirons le projet tel que défini dans le cahier des charges, avant le 12 décembre. Sinon nous mettrons 3 personnes à temps plein jusqu’à ce qu’il soit terminé »

  • Si on finit avant : les consultants s’en vont
  • Si on ne finit pas à temps : on bascule en régie à durée indéterminée

Particularités

  • Pour le client : Les consultants sont motivés pour finir rapidement, et si ça dérape on a un engagement de moyen pour terminer. Ça évite les consultants qui jettent l’éponge et disparaissent en cas d’échec.
  • Pour les consultants : c’est le beurre et l’argent du beurre.

Facturation

  • Mode Forfait avant l’instant T
  • Bascule en mode régie en cas de dépassement, TJ à fixer avant de commencer.

Le nommage des modes mixtes peut varier, voir s’inverser, soyez donc attentif à la formulation de qui doit faire quand ça dérape. J’espère que ça aidera ceux qui nageaient encore avec les définitions 🙂

Notez que pour ceux qui partent sur de l’Agile, le mieux est souvent de travailler en régie. Les itérations provoquant souvent des glissements de périmètre – c’est le but en même temps – une contractualisation au forfait impliquera donc la rédaction de nombreux avenants. Cela devient rapidement pénible et limite le flux de productivité.

Je terminerai en rappelant qu’indépendamment des contrats, vos clients et vos consultants sont des êtres humains qu’il est très facile de démotiver / vexer / fâcher. Une relation de consulting doit être une relation de confiance, sinon aucun travail productif ne sera effectué. Ne gâchez pas cette relation en voulant être trop agressif d’entrée de jeu. Un consultant sous facturé (donc indirectement sous payé / mal valorisé) en régie longue ne fera jamais du très bon travail. Un client qui se sent arnaqué vous allumera toujours au moment de la recette. Sachez rester dans le gagnant-gagnant !

Un dernier conseil pour les clients : demandez une période d’essai, quel que soit le type de prestation. En régie : une période de 15 jours pendant laquelle vous pouvez arrêter la prestation sans frais ; en forfait : un premier mini-projet pour tester la capacité à livrer de l’équipe. Ne vous enfermez pas dans des relations inconfortables au boulot, vous avez votre vie personnelle pour ça… Plus sérieusement, n’ayez pas de scrupules : les bons consultants choisissent leurs clients, alors faites la même chose !