Dialoguer avec les directions Métier

Nous rencontrons souvent des DSI qui rencontrent des difficultés à valoriser leurs projets auprès de leurs Directions Métier, par exemple pour l’évolution de la téléphonie. Pour ces dernières, la téléphonie relève d’un utilitaire qui doit fonctionner à moindre coût, un peu comme un robinet d’eau qu’on ouvre et qu’on ferme. C’est de l’eau et voilà tout. Pourtant les communications unifiées enrichissent significativement la téléphonie d’autrefois.

Il en est de même, dans une moindre mesure pour l’informatique.

Dans le cadre de nos missions, nous sommes ainsi amenés à aider les DSI à « vendre » leurs projets aux Directions Métier. Si leur intérêt n’est pas levé, les DSI se retrouvent à devoir faire évoluer leur infrastructure dans le cadre de leur budget en propre, donc souvent a minima, voire à ne pas faire du tout.

Alors voici quelques recommandations pour vous ingénieurs:

Règle 1 : Parlez une langue que les Métiers comprennent : Ne confondez pas Services et Fonctionnalités !

Vous me dites que la téléphonie sur IP permet de traiter les appels en se connectant de n’importe où. C’est surement intéressant, mais pour en faire quoi ? Je n’ai pas plusieurs bureaux, et j’ai mon mobile.

En fait,

cela permettrait de mutualiser les prises d’appels entre des sites différents, par exemple pour qu’une agence ouvre le Samedi pour prendre les appels des clients de la région sans avoir à faire de renvois entre agences. Et pour vous, vous pouvez appeler de votre PC et une connexion Internet même en n’étant pas au bureau, savoir si votre collègue est au bureau, et l’appeler d’un clic.

Est-ce plus concret pour vous ?

Traduire des fonctionnalités en usages pertinents pour le métier avec, si possible, un bénéfice métier chiffrable n’est pas aussi facile qu’il paraît. La fonctionnalité de Téléphonie sur IP n’est ici perçue comme un bénéfice que parce qu’on l’a convertie en services qui correspondent à la problématique du Métier.

Règle 2 : Montrez leur, plutôt que leur demander leurs besoins

Ne demandez pas à l’utilisateur ou au donneur d’ordre ses besoins d’une façon générale (bien sûr posez lui des questions car certains manques sont parfois fortement ressentis), mais montrez lui, et demandez-lui si cela lui rendrait service. Bien souvent, les utilisateurs ne connaissent pas leurs besoins ou ne savent pas les formuler, connaissent pas ou peu ce qui se fait sur le marché. Mais ils savent vous dire si ils aiment ou pas.

C’est le cas par exemple de la téléphonie sur PC, qui supprime quasiment le téléphone (si ce n’est en cas de panne informatique !). Ainsi faire une conférence téléphonique en déplaçant des icônes dans une même fenêtre est un moyen assez sûr de montrer l’intérêt du principe. Mais là encore, réalisez des cas d’usage réels, à tester précisément étape par étape, pour vous assurer que la solution répond bien à vos besoins !

Règle 3 : Ne les lâchez pas !

Impliquez-les dès le début via des groupes de travail sur l’expression de besoin, pour que votre projet soit porté par les enjeux métier. Soyez attractif en termes de bénéfice métier pour qu’ils acceptent de sortir de leur quotidien et participer à ces groupes de travail. Attention, ne les lâchez pas ensuite : Si vous les perdez en route, vous pouvez perdre le projet avec, ou alors le retrouver après quelques mois d’errance…Aussi est-il important de les faire participer aux maquettes d’usage avant le choix de la solution, puis au choix des téléphones, puis aux pilotes bien sûr.

Règle 4 : Ce qui est évident pour vous, ne l’est pas forcément pour eux. Si vous saviez sur quoi on peut buter !

Ne considérez pas que ce qui est facile ou qui va de soi pour vous, va de soi pour un non technicien. Celui-ci  va buter sur des aspects d’utilisation que vous ne voyez même pas car vous avez acquis une culture, des réflexes, et aussi des comportements de recherche de solution que lui n’a pas. En particulier, parce que ce qui vous intéresse ne l’intéresse, lui, pas du tout. Donc bien souvent, il ne cherche pas, ni n’assimile. Cela marche, ou cela ne marche pas comme il s’y prend. Si cela ne marche pas, eh bien il ne s’en sert pas.

Ainsi peut-il en être pour le click to call ! Dans la fiche contact d’Outlook, on peut cliquer dans « Autres » dans le bandeau, puis appel. L’utilisateur cliquera sur le numéro directement et vous dira que cela ne marche pas ! Ne sous-estimez pas le rôle des aides et référents pour transformer l’essai.

Règle 5 : Montrez comme c’est utile

Il est très important que vous puissiez trouver des indicateurs métier représentatifs pour chiffrer les progrès obtenus. La techno pour la techno est difficile à défendre. Pour les Métiers, votre projet peut rentrer en concurrence avec l’investissement dans une nouvelle offre, ou un développement à l’international. On a beau dire, les chiffres finissent toujours par mettre tout le monde d’accord !

Et aussi

  • 12 juillet 2012 ToIP et cablâge catégorie 3 La semaine dernière, Cisco a sorti les premiers éléments techniques correspondant à CUCM v9. Parmi les documents toujours regardés avec attention par les ingénieurs de Setec IS, figure le SRND. Niché dans le chapitre 3-14, Cisco apporte enfin son "support" à la ToIP sur cablâge catégorie 3. Dire que cela fait des mois que nous affirmons que la ToIP est compatible avec un cablâge de […]
  • 28 novembre 2013 Avez-vous des Codes rouges ? et combien ? Dans un des premiers chapitres, le livre The Practice of System and Network Administration indique les étapes pour « sortir du trou » une DSI ou service informatique d’une entreprise, une université ou toute large organisation. Le premier prérequis consiste à mettre en place un système de ticketing pour disposer d’un décompte fiable des évènements et demandes. Comme tout outil logiciel […]
  • 25 avril 2014 Web QoS : l’acronyme manquant qui a de l’avenir Il y a quelques semaines, lors d’une session de travail pour la réalisation d’un schéma directeur télécom, j’ai pu faire le constat que même si les acronymes sont nombreux dans notre domaine, il en manque encore parfois. Nous faisions le constat partagé de problèmes de « qualité » au niveau des réseaux : lorsqu’au sein des flux http, les vidéos YouTube sont dans la même catégorie […]