Quoi de neuf docteur ? (Mai 2014)

Ceci est un article RTV, « Raconte Ta Vie » comme disent les jeunes, n’hésitez donc pas à passer si mon autobiographie n’a que peu de valeur pour vous, je le comprends complétement 😉

Alors il paraît qu’en mai, on fait ce qu’il nous plait? Bin cette année pour moi c’est fait !

D’abord je change de job. J’abandonne, non sans un pincement au cœur, une équipe de consultants fantastiques – et un client génial d’ailleurs – ils se reconnaitront, pour monter une nouvelle équipe chez Cellenza: le pôle Data & Analytics.

I love you

Excellente fin de saison soit dit en passant!

A mes potes qui ne bossent pas dans le secteur, je leur dis juste que je vais faire la même chose en mieux payé. Mais à vous je peux en dire plus !

Cellenza est sur un modèle pur-player Microsoft, je retrouve donc des experts et des vrais développeurs, disponibles en interne pour construire des offres commerciales complètes. De l’autre côté je perds la facilitation de la veille concurrentielle venant de l’aspect cross-techno de ma précédente société (IBM Cognos, QlikView, Tableau…). On ne peut pas tout avoir !

Cellenza est spécialiste de l’Agilité et de l’ALM, et ça ça me va très bien. Il faut dire que Cellenza est la petite sœur de Xebia, qui pour ceux qui ne connaissent pas est un concurrent direct d’Octo ou Valtech, toutes œuvrant principalement dans le monde Java, et qui est une référence de l’Agilité et… du Big Data, puisqu’ils sont le partenaire exclusif de Cloudera pour le training en France.

Et c’est de là que vient le plus gros changement sur mon poste, car si j’ai considérablement réduit la voilure en termes de collaborateurs managés, c’est pour libérer de la bande passante et concentrer mes efforts sur l’adoption des nouvelles technos, que ce soit du Cloud, du Big Data ou de la Data Science, à travers des démarches Leans et Agiles.

Je commence le 2 juin, souhaitez-moi bonne chance 😉

Congratulations

Également au programme à court terme, une véritable tournée européenne (genre) avec :

  • Le 28 juin, une session présentée à Cologne en Allemagne avec Jordan (avec qui j’avais déjà fait une session aux JSS2013) au SQL Saturday Rheinland sur la BI Agile, justement. Avec nous JP et David avec une session sur SSIS vs Power Query
  • Le 19 juillet, au SQLBits en Angleterre, David et moi on ira supporter JP pour présenter un sujet sur le Data Stewardship
  • Le 13 septembre, de retour en France pour le SQL Saturday Paris 2014

Enfin, si vous avez aimez mon petit article sur Kimono + Power Query, sachez que je présente le truc en webcast la semaine prochaine via le GUSS.

Et sinon je suis en vacances, mais j’ai l’impression de bosser toute la journée. C’est normal ? 😉

 

4 liens pour la semaine (2014-16)

De quoi lire et réfléchir pour ce long week-end 😉

  1. Bill Waddell, qui reprend l’idée qu’il est temps de repenser le service des Ressources Humaines. Il est vrai que c’est une fonction qui traverse une vraie crise existentielle aujourd’hui, entre les vrais humanistes qui perdent la foi à force d’avoir à appliquer les règlements internes abscons, et les gestionnaires qui ne sont là que pour protéger la société de ses propres collaborateurs.
  2. Rebekah Campbell du New York Times sur les coûts cachés des petits mensonges dans la vie professionnelle. Humilité, franchise et transparence, définitivement des caractéristiques communes aux meilleurs professionnels que je côtoie. Et oui, ce n’est pas toujours facile, mais c’est toujours gagnant à long terme.
  3. Une belle dataviz de Bloomberg sur les causes de mortalités aux USA, avec des gros morceaux de story-telling dedans. Notez comme on accède très facilement à chaque source de données sous-jacente, ça c’est une bonne pratique. Et les bonnes pratiques pour manipuler des données de population, issues de recensements, elles sont là.
  4. Dave Thomas, l’un des co-signataires du manifeste Agile, avec un petit électrochoc sur ce qu’est devenu l’Agilité, et son destin (via HN). Un bon rappel que l’Agilité c’est avant tout une intention, et pas des outils logiciels ni des carcans de processus.

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

Le retour des spécifications dans un projet décisionnel lean

Au risque de me faire encore conspuer par nos camarades agilistes militants, je vais vous raconter comment j’ai contribué à la sortie d’un des projets auxquels je participe du mode Agile/Lean. Car oui, je l’avoue, j’ai fait du lobbying pour le retour du cycle en V…

Tout commence par un projet de migration Cognos vers SQL Server, avec une petite équipe de développeurs experts et un client qui fait confiance. Aucun frein à la productivité, les résultats sont immédiats et visibles à travers les premiers états livrés après seulement quelques semaines de travail. Point de vue gestion de projet, l’équipe fonctionne alors en mode cowboy, juste quelques todo lists priorisées, une réunion de suivi hebdomadaire, et tout le monde est bien content.

Les choses s’accélèrent, la migration avance à bon rythme, et le succès rencontré par la production des premiers rapports déclenche la demande de nouveaux rapports. Le client trouve sa place en tant qu’évangéliste de la solution, il identifie des utilisateurs potentiels, vend sa solution en interne et génère encore plus de besoins.

On avance de 6 mois, et… la migration n’est toujours pas terminée. En effet la recette des rapports est décalée en permanence car chaque revue déclenche une flopée d’évolutions. Les nouvelles demandes s’entassent et parfois même disparaissent puisqu’elles ne sont pas suivie d’une manière centralisée (pas de réel backlog) et que la priorité est attribuée aux derniers utilisateurs venus se plaindre dans l’open-space. Il n’y a ni planning, ni suivi du consommé, ni documentation, et même l’architecture technique commence à en souffrir (effet de bord d’une autre décision qui n’est pas le sujet du jour).

Le problème est identifié et c’est à ce moment-là que je rentre en scène. Ma mission est évidemment de remettre de l’ordre dans tout ça. Je reprends donc la longue liste des demandes, je clarifie les items, génère un backlog unique et accroche au mur un beau Kanban tout neuf.

 Dilbert - Méthodes Agiles

Pourquoi un Kanban ?

  • L’équipe fonctionne en livraison continue, sans itération, point positif à conserver
  • On lui reproche un manque de visibilité sur son activité en cours, il faut y remédier
  • Les priorités changent tous les 2 jours, il faut pouvoir s’adapter
  • L’équipe travaille sur trop de sujets à la fois, il faut rationnaliser

On est donc dans le cadre d’application idéal pour cette technique.

Et hasard des réorganisations, c’est justement le moment où un des utilisateurs principaux de la solution, directement en provenance du métier, passe officiellement business owner à temps plein.

S’en suivent 2 mois plutôt positifs, où une fois les process mis en place, le business owner et les utilisateurs constatent une amélioration du delivery en terme de rythme, de réactivité et de visibilité sur l’activité (par ce que oui, un développeur qui ne fait pas de réunion et qui n’envoie pas de mail c’est bien un développeur qui travaille, et pas le contraire). Le reproche éternel de la capacité à s’engager sur des dates est évidemment toujours dans l’air, mais on atteint une visibilité à 3/4 semaines qui à mon sens est la seule période vraiment réaliste.

Et là, c’est le drame…

Devant le regain de productivité de l’équipe, les demandes explosent à nouveau. Les développeurs reçoivent plus de 5 mails par jour des utilisateurs, avec ou sans le business owner en copie. Les règles de gestion évoluent sans cesse, les couleurs dans les rapports aussi, les sources de données changent considérablement, et la mauvaise habitude de donner la priorité au dernier qui a parlé réapparaît. A nouveau l’équipe s’enlise et la satisfaction des utilisateurs sombre.

Pour moi le problème est clair : l’équipe est en sous-capacité. Si nous étions capables de dépiler plus vite les tickets, nous arriverions à retrouver un flux optimal. Mais dans notre cas, même avec l’ajout d’un développeur, la situation persiste. Le delta entre besoin et capacité de production est vraiment trop important. Pas possible d’ajouter plus de ressources, d’un point de vue budget et praticité, nous sommes au maximum.

 Dilbert - Product Owner vs Développeur

Alors j’ai pratiqué ce que je prêche, et j’ai demandé au business owner, qu’on considérera désormais comme un chef de projet MOA, de commencer à écrire des spécifications fonctionnelles. Chaque demande d’évolution doit mettre à jour la spécification correspondante, chaque nouveau besoin doit être pensé et écrit dans le dur.

Mon objectif est clairement d’introduire une contrainte au niveau métier, pour stabiliser la génération des besoins (le rythme est sincèrement démesuré) et ainsi faire basculer au niveau MOA le goulet d’étranglement du flux.

Car à être trop disponible et réactive, l’équipe de développement était devenue une extension du cerveau du business owner, et de certains utilisateurs trop exigeants. Chacune de leurs pensées à demi digérée était rapidement écrite dans un mail et transmise en priorité 1, trop souvent en totale contradiction avec l’info précédante. J’espère que le fait d’avoir à se poser pour penser et écrire concentrera leurs idées et diminuera les changements d’avis. Le travail de réconciliation et d’harmonisation fonctionnelle doit définitivement être réalisé par le business owner, pardon, le chef de projet MOA.

Evidemment c’est une étape temporaire, une astuce qui donnera également à l’équipe le temps de souffler un peu et traiter les vraies priorités. Je compte bien retourner à nouveau dans un mode plus lean une fois l’orage passé. Et je provoque en parlant du retour du cycle en V, puisqu’on conserve bien la livraison continue et le fonctionnement en mode pull. J’impose juste une contrainte de documentation plus lourde côté utilisateur avant d’accepter les activités dans le backlog.

On en reparle dans quelques mois, pour voir si l’expérience porte ses fruits !

PS : Evidemment toute cette histoire se vit dans un contexte d’entreprise plus global, sur fond de guerre politique entre services, de rachat de sociétés et d’avancement de carrière des internes, qui expliquent beaucoup plus mais que je ne peux évidemment pas raconter ici 😉

Savoir rester lean dans son projet décisionnel

Vous vous demandiez peut-être à quoi je passais mon début d’année (plutôt que de vous écrire des articles de 3 pages de long) ? Et bien en dehors de ma récente promotion (une fois nos expérimentations d’organisation stabilisées je vous en parlerai, soyez patients), je le consacre à la finalisation d’un projet de plusieurs mois, réalisé par un padawan de talent et supervisé par mes soins.

Padawans en tenue

Sont pas beaux mes padawans? Tenue obligatoire en clientèle!

Entre 2 anomalies à corriger, nous rédigeons la documentation et préparons le voyage de l’application de l’environnement de développement, et de notre responsabilité, à celui de production, et à la responsabilité de l’exploitation. Au passage c’est toujours pendant ce genre de transition que l’idée du devops revient me faire des yeux doux. Ou encore le concept de livraison continue. Malheureusement ici je n’ai pas réussi à convaincre le métier et l’IT de bosser en mode Agile. Mais ce n’est pas le sujet du jour, revenons à nos moutons !

La documentation technique terminée, elle est relue par le directeur d’étude (respect, ce n’est pas souvent que ça arrive). Et ce dernier s’étonne : quasiment pas de règles de gestion, un schéma en étoile simpliste, un cube à la DSV vide, des dimensions sans surprises techniques. Ok on trouve bien quelques calculs MDX, et ok la partie ETL fait pas loin d’une centaine de packages, mais ce n’est que parce qu’on a fait un bon travail et bien tout découpé en flux de données unitaires. En dehors de ça la solution semble étonnement vide pour 3 mois de développement.

Un tout petit plat gastronomique dans une grande assiette

Minimaliste mais plein de goût, comme au resto gastronomique!

Et bien pour tout vous dire, j’en suis assez fier. Parce que pour arriver à cette apparente simplicité, ce « vide » dans la solution, cela nous a demandé des efforts considérables. Un projet informatique est soumis à une certaine forme d’entropie. Plus on avance, plus des éléments viennent se rajouter, des fonctionnalités, des données, des exceptions, des contournements, et si on n’y fait pas attention, sans rien toucher au périmètre initial de l’application, la solution est tout de même devenue un plat de spaghettis indémêlables avant même la livraison du lot 1.

Lutter contre cette tendance demande un effort constant. Dès qu’on se relâche, on se retrouve avec des règles de gestion implémentées dans des vues (ou pire, dans la DSV du cube), parce que c’est rapide, plutôt que de faire les choses proprement et d’ouvrir une énième fois l’ETL, modifier les métadonnées, les flux, et tout re-tester après.

Mais il ne faut pas se leurrer : tout ça c’est de la dette technique, et rien de pire pour une solution informatique de commencer sa vie encore plus endettée qu’un étudiant américain ! Alors ne relâchez pas la lutte, pensez marathon plutôt que sprint (rien à voir avec SCRUM ;)), pensez Lean, et faîtes un cadeau au vous de dans 6 mois qui devra bosser sur le lot 2 ou corriger une anomalie: laissez-lui une solution toute propre, il vous remerciera!

Gestion de Projet Décisionnel – Méthodes Agiles ou Cycle en V ?

Après le choix de la technologie, je continue sur la réflexion lancée plus tôt autour du projet décisionnel. Cette fois-ci j’aimerais aborder la question de l’organisation du projet décisionnel, quelle méthodologie choisir, quel mode d’engagement, pour se garantir de réussir son datawarehouse (ou au minimum d’échouer avec élégance).

Avant de commencer, on peut se demander ce qui distingue un projet décisionnel d’un projet informatique classique. La réponse se limite en fait à un seul élément : la dépendance à une ou plusieurs sources de données externes. Cela peut paraître trivial mais c’est fondamental, car cela implique qu’un élément au cœur du projet n’est pas maîtrisé par les intervenants. Comment garantir un résultat, comment se prononcer sur des deadlines, quand un élément critique du projet n’est pas dans le domaine de responsabilité ? C’est la question qui doit rester dans la tête du chef de projet décisionnel quand il va choisir son organisation projet.

Au-delà de cette dépendance externe, il n’existe pas vraiment de différence avec un projet informatique classique. C’est un mythe qui a la peau dure, on aime tous se sentir un peu spéciaux, mais ça reste un mythe. En décisionnel on voit beaucoup les utilisateurs pour le design du reporting ? C’est pareil sur les applications qui disposent d’une interface – soient quasiment toutes. En décisionnel on gère de la complexité métier dans la modélisation ? C’est pareil pour les applications qui gèrent la production des flux métiers. En décisionnel on est déployé en petites équipes ? Ça arrive tout autant côté applicatif. En décisionnel on gère les sujets transverses de l’entreprise, ce qui est très politique ? Même combat au niveau des ERP, des CRM, du MDM… Non vraiment il n’existe pas vraiment d’autre différence.

Pour en revenir au sujet du jour, l’organisation du projet décisionnel, je vais tenter de faire court et organiser la réflexion autour de 3 questions :

  • Méthodes agiles ou Cycle en V… Comment arriver au but ?
  • Faire ou faire faire, faut-il appeler les consultants ?
  • Forfait ou régie, quel type de garantie fournir?

Pour ce premier article nous allons commencer par le choix de la méthode de gestion de projet : Méthodes agiles ou Cycle en V ?

La différence élémentaire entre les 2 vous la connaissez :

  • Les méthodes agiles sont itératives et participatives, on développe des petits morceaux d’application qui apportent de la valeur, qu’on fait valider par l’utilisateur avant de passer aux suivants. C’est l’utilisateur qui pilote au fur et à mesure le développement  à travers le choix des fonctionnalités qu’il souhaite voir développer. Un cycle de développement, une itération, prend 1 à 3 semaines.

Cycle de développement Agile

  • Le cycle en V repose lui sur un développement de bout en bout, c’est donc une délégation totale de la fabrication de l’application jusqu’à la livraison finale (lever de rideau !). Je veux un résultat, peu m’importe la route pour y arriver. Un cycle de développement prend plusieurs mois.Cycle de développement en V

Jusqu’à présent je pensais que cette dichotomie représentait bien l’écart entre les deux philosophies. Pourtant quand on y pense, et si on se concentre sur l’organisation projet et pas les valeurs que véhicule l’Agilité, une itération agile n’est rien d’autre qu’un mini cycle en V non ? On a une mini-spécification – la description de la fonctionnalité attendue – et toutes les phases classiques du cycle en V (conception, réalisation, recette, livraison). La différence entre les 2, encore une fois si on retire les valeurs de l’Agilité de l’équation, ne serait donc qu’un niveau de zoom sur l’échelle temporelle ?

Cette réflexion, et la réponse à cette question, m’est venue suite à la lecture de cet article d’un designer de 37 Signals : le dilemme de la documentation. L’idée principale de ce monsieur c’est que la volonté de créer, de changer, est un flux d’idées qui s’écoule comme une rivière. Si la productivité est suffisante, si la capacité à réaliser les idées est adaptée au volume du flux d’idées, tout va bien, la rivière s’écoule correctement. Par contre si la productivité est insuffisante, un goulet d’étranglement se forme, un lac de stockage apparaît.

Un océan de spécifications!

Deux possibilités existent alors :

  1. Soit on arrive à faire coïncider le volume du flux d’idées et la capacité de production pour retrouver un équilibre,
  2. Soit on stocke les idées sous la forme de documentation, de spécifications, dans l’attente de l’allocation de moyens de production.

Avec les méthodes agiles, on est dans la première possibilité. Le cycle en V correspond à la seconde.

Par rapport à votre projet, la vraie réflexion à avoir est donc : vais-je avoir une adéquation entre le flux de besoin et la capacité de production ?

Autrement dit : Mes utilisateurs sont-ils prêts à participer de manière active et régulière à mon projet ? Avec cette question on retombe sur nos pattes par rapport aux prérequis classiques de l’agilité. Les réponses :

  • Oui, je suis dans le cas 1, je peux faire de l’itération rapide sur le besoin > Méthode Agile
  • Non, je suis dans le cas 2, je vais devoir documenter mon besoin pour ne pas le perdre > Cycle en V

Un argument qui revient souvent en faveur du cycle en V, c’est que les spécifications sont un engagement sur le livrable qui permet de contourner le problème de confiance qu’on peut avoir avec l’exécutant. En effet : ne pas avoir confiance dans les moyens de production contribue au goulet d’étranglement, c’est un frein à l’innovation, le flux des besoins ne s’écoule pas correctement : il faut documenter pour stocker les idées.

J’ai déjà entendu que l’absence de maturité des utilisateurs était un obstacle à l’Agilité. Je ne suis pas d’accord, dans cette situation c’est le flux d’idées qui est contraint. J’aurai donc même tendance à penser l’inverse : un flux de besoin faible nécessitera une faible capacité de production, on pourra donc facilement arriver à une adéquation (solution 1). Par contre l’absence de maturité de l’équipe de développement est définitivement un frein à l’Agilité puisqu’on diminue la capacité de production, on rejoint le problème de confiance (solution 2).

Enfin, des sources de données de faible qualité sont un frein majeur à la capacité de production. Si vous savez que les auteurs des sources sont réactifs : privilégiez l’Agilité, dans tous les autres cas, commencez à spécifier…

D’une manière générale, chaque contrainte de votre projet doit être classée entre « frein à l’innovation » ou « frein à la capacité de production ». En fonction de l’équilibre vous saurez quelle méthode choisir.

Wow, j’écris sans trop regarder et je me rends compte que c’est déjà beaucoup trop long… Je coupe donc cet article ici, il me restera quelques points à traiter sur l’Agilité (les valeurs, comment découper son datawarehouse en fonctionnalités unitaires) et le cycle en V (positionnement MOA vs MOE), et on pourra passer aux questions suivantes :

  • Faire ou faire faire, faut-il appeler les consultants ?
  • Forfait ou régie, quel type de garantie fournir?

En attendant j’espère vous avoir donné une clef de lecture actionnable pour que vous puissiez répondre à la question : Cycle en V ou Méthodes Agiles pour mon projet décisionnel?

Modèle d’organisation de la DSI, ce qu’il ne faut pas faire.

Hier j’ai eu une discussion intéressante avec un client qui fait partie des CO (Chief Officers, CEO, CTO, CIO, CFO …) d’un grand groupe international.

Nous parlions de l’organisation de la DSI (Direction des Services Informatiques) et de comment le modèle de fonctionnement en société de prestation interne avait sur le moyen terme détruit l’implication des équipes informatiques dans son entreprise.

Ce n’est pas la première fois que j’entends ou je vis ce genre de situation, je vous avais d’ailleurs déjà passé cet article qui à mon sens résume très bien la problématique. Je vous rapporte ses principaux arguments ci-dessous :

  • Quand la DSI est conduite comme un business, avec des clients (internes) et des contrats (les spécifications), son objectif n’est plus de faire progresser l’entreprise. Pour le management l’objectif devient la minimisation des budgets, pour les équipes de répondre aux cahiers des charges en minimisant les efforts.
  • Dans ce mode de fonctionnement disparaissent les synergies, la collaboration entre les équipes et l’objectif commun de faire progresser l’entreprise… tout ce qui permet de créer un groupe de travail efficace en somme.
  • Quand la DSI fonctionne comme une société indépendante, le reste de l’entreprise la traitera comme un fournisseur. Or les décideurs métiers n’ont en général que très peu confiance en leurs fournisseurs. Difficile de créer de la valeur dans ces conditions.
  • Et que dire des fonctions informatiques transverses comme la qualité, l’architecture ou la sécurité, qui deviennent des verrues qu’aucun client ne veut inclure dans son budget ? Qui donc payera pour ça ? Le premier à développer un nouveau projet ? Tu parles d’une incentive à ne pas faire évoluer ses plateformes. On comprend mieux pourquoi nos outils de travail ont plus de 6 ans.
  • Une fois entrée dans ce mode, la plupart des réunions entre les métiers et les équipes de la DSI deviennent des réunions d’arbitrage, pour décider qui a le moins tord entre des métiers qui ont rédigé des spécifications les plus vagues possibles pour ne pas risquer d’oublier quelque chose, et des techniques qui se sont mis des œillères et ont codé bêtement, sans chercher à comprendre le besoin pour minimiser le temps d’implémentation.

Et là on peut prendre un peu de recul et se rappeler que tout ce beau monde travaille dans la même entreprise. C’est déprimant non ?

Quelles sont les solutions quand on en arrive là ? Personnellement j’en vois 2 :

  • Aller jusqu’au bout du mouvement et externaliser complètement sa DSI. Ainsi la DSI pourra être mise en concurrence avec d’autres prestataires, et pourra à son tour prendre d’autres clients. Ce n’est pas la solution que je retiendrai car à mon sens c’est mettre en danger une fonction « régalienne » de l’entreprise, mais au moins les incentives seront alignées correctement et les collaborateurs pourront travailler efficacement.
  • Faire machine arrière et réintégrer la DSI dans l’entreprise : abolir la notion de client interne et mettre à la poubelle toute la gestion du budget par facturation interne. L’objectif devient alors de visualiser la DSI non plus comme un centre de coût mais comme une boite à outils permettant au métier de mieux remplir ses fonctions.

Elle est bien jolie cette deuxième solution mais comment faire pour la mettre en œuvre quand la DSI est mal organisée, les collaborateurs sont déprimés, le turnover explose, les compétences fuient le bâtiment plus vite que les RH ne savent les trouver, et qu’en prime les métiers détestent la DSI parce que les projets informatiques ne finissent jamais bien ?

Je n’ai pas de recette miracle, chaque DSI répondra différemment à une réorganisation, mais il y a des pistes à suivre, certaines risquées et d’autres moins. Etant donné que l’objectif de la démarche est de changer la manière dont la DSI se perçoit et est perçue, le mieux est de commencer par les domaines où elle est en contact avec le reste de l’entreprise : en premier lieu dans les projets et dans la vie de tous les jours.

La première des pistes, celle qui concerne les projets, c’est évidemment l’Agilité. Il n’y a qu’à aller voir les valeurs de l’Agilité pour voir le lien immédiat avec ce que je raconte ici. Les méthodes de gestion de projet Agile sont à mon sens un des premiers outils à mettre en œuvre pour réussir cette transition. De plus c’est une piste facile à suivre puisqu’elle n’engage qu’un projet et une équipe à la fois. Je ne vais pas détailler ce point maintenant, c’est plus qu’un article à part entière et je le ferai certainement dans les semaines qui viennent si le sujet vous intéresse, je vous laisse consulter ma série d’article dessus: 1, 2, 3. Juste une petite remarque sur le sujet: attention à ne pas tomber dans le culte du cargo qui consisterait à appliquer une énième méthode en en oubliant l’esprit.

La seconde piste, concernant la vie de tous les jours, pourrait concerner la hotline. Pourquoi ne pas remplacer le modèle actuel de call center anonyme, qui marche si bien pour la gestion de la relation client (c’est de l’ironie, évidemment), par ce qui se fait de mieux en social en ce moment : un stack overflow interne ? Dans un call center tout est procéduré, caché dans des applications mal standardisées, sans aucune transparence ni cycle d’amélioration, avec des tonnes de redondances, des acteurs dénués de toute individualité et de tout chemin de progression. Au contraire dans un outil comme stack overflow, chaque hotliner a un profil, une réputation, des domaines d’expertises, les résolutions se font en plein jour, les utilisateurs contribuent au système, les mêmes questions ne sont pas reposées 50 fois par jours… En somme c’est tout l’inverse !
Plutôt que de mettre en place des workflows compliqués qui ne marchent jamais vraiment, il suffit d’utiliser les tags et de mettre en place des abonnements mails. Sur ce genre de plateforme, les rouages redeviennent des gens et retrouvent la fierté de leur travail. Et si c’est le réseau qui plante et que le site est injoignable ? Un mini call center à la Zappos fait très bien l’affaire ! Pour tout dire j’ai hâte de voir ce genre de solution déployée dans une entreprise!

Une remarque en passant : n’imaginez pas mettre en place une variabilisation de la rémunération des hotliners en fonction des statistiques de réponse sur la plateforme, sinon tout le système s’écroulerait

J’aimerais conclure en rappelant qu’au-delà de ces deux premières pistes, le seul vrai porteur de ce changement de mentalité est le directeur des services informatiques (ou équivalent). Sans une volonté sans faille de sa part à faire changer les choses, tous les efforts seront voués à l’échec. Mais si vous avez cette motivation et que vous lisez ce blog, rien ne pourra vous arrêter 😉