En tant que DSI, vous pouvez obtenir des conseils sur la manière d'être plus efficace auprès d'un grand nombre de sources. La plupart des textes que vous lirez énumèrent ce qui devrait être les principales priorités d'un DSI. Et flotte souvent l'impression qu'ils ont été écrits par Captain Obvious. Ce qui ne les rend pas faux pour autant. Juste répétitifs. Voici sept péchés capitaux du management IT qui sortent (davantage) des sentiers battus, par le consultant et blogueur Bob Lewis, régulièrement invité dans les colonnes de CIO.

1. Trop de gestion, pas assez de leadership

Loin d'être quelque chose que vous n'avez jamais lu auparavant, gérer au lieu de diriger est, au contraire, quelque chose que vous avez beaucoup trop lu. Une vieille blague parle d'un chien sans pattes. Chaque matin, son propriétaire le traînait pour l'emmener se promener. Le leadership, c'est justement ce qui fait la différence entre traîner les employés et les faire avancer d'eux-mêmes dans la bonne direction.

2. Trop de leadership, pas assez de gestion

Vous êtes payé pour faire avancer le travail qui vous est confié. Or, c'est la raison d'être de la gestion : s'assurer que le travail de l'entreprise dont vous êtes responsable est effectué.
Le leadership est un outil utile pour y parvenir (cf le chien ci-dessus). Mais c'est loin d'être le seul outil. Les technologies de l'information en sont un exemple évident, tout comme les initiatives d'optimisation des processus d'entreprise - et si l'on met trop l'accent sur le leadership, les managers peuvent consacrer tellement d'efforts à être une source d'inspiration qu'ils perdent de vue ce pour quoi ils sont payés.

3. Pinailler sur les refacturations

Les refacturations relèvent de l'épure. La théorie veut qu'en facturant aux responsables des centres de coûts les ressources informatiques qu'ils utilisent, leurs décisions quant à ce qu'ils doivent demander à l'informatique seront plus prudentes.

Sauf qu'il y un "mais". Un mais qui se matérialise lorsque les services informatiques expliquent les montants qu'ils facturent. En effet, la DSI dispose de deux méthodes pour calculer les montants facturés. Elle peut le faire de manière simple, par exemple en allouant le budget informatique aux responsables de centres de coûts sur la base d'une mesure facile à comprendre : le pourcentage de l'effectif total de l'entreprise ou le pourcentage du budget total de l'entreprise contrôlé par le responsable du centre de coûts. La DSI peut aussi entrer dans une démarche plus granulaire, en calculant les coûts unitaires pour chaque type de ressource informatique, en surveillant la consommation de ces ressources et en multipliant la consommation par les coûts unitaires.

Oubliez l'approche simple. Ce qui la rend attrayante - sa simplicité - la rend également inutile : comme il n'y a aucun moyen pour un responsable métier de réduire ses coûts de refacturation en réduisant sa consommation informatique, cette approche met à plat la théorie. Quant à l'approche granulaire et précise, si vous vous engagez dans cette voie, vous pouvez vous attendre à ce qu'une large partie de votre temps soit dévoré par des discussions sur le bien-fondé de votre modèle de refacturation.

Parce que cette approche est complexe, vous pouvez vous attendre à ce qu'elle soit le résultat de nombreuses hypothèses non vérifiables. En outre, quel que soit le vainqueur des arguties sur la pertinence du modèle entre les métiers et la DSI, le temps perdu par les deux parties se traduit par des coûts bien réels, pour une discussion qui revient à trancher de quelle poche sortira le même argent.

4. Se donner une coloration 100% business, au détriment de la technologie

Vous avez lu ce conseil, encore et encore et encore. Le comble du ridicule a été atteint dans les entreprises qui ont adopté le titre de CTO pour la personne responsable de l'informatique, ce qui a donné lieu à l'affirmation singulière que la personne la plus haut placée ayant "technologie" dans son intitulé de poste ne devait pas être spécialiste... de la technologie.

Si vous suivez cette voie, sachez que vous ne serez pas pris au sérieux. Tout d'abord, être un décideur business est plus facile que d'être en charge de la technologie. Deuxièmement, à moins que vous ne pensiez que le directeur financier de l'entreprise devrait être un homme d'affaires et non un financier, et que le directeur du marketing devrait être un homme d'affaires et non un spécialiste du marketing, ce débat ne vaut pas la peine que vous y consacriez du temps et de l'attention.

Finalement, les DSI qui essaient d'être des businessmen au lieu d'être des spécialistes de technologies sont comme les exclus du lycée, qui essaient désespérément de rejoindre le club des enfants cools. Ils seront toujours exclus, mais ils ont maintenant ajouté le pathétique à leur déficit de coolitude.

5. Conjuguer 'designer' à tous les temps

Ce n'est que mon opinion, mais je ne pense pas que le verbe "designer" dise quelque chose de plus utile sur ce que vous vous apprêtez à faire qu'un verbe qui serait dérivé d'ingénieur. Souvent, lorsque j'entends "Nous devons designer une solution", je vois quelqu'un qui, n'ayant pas réussi à rejoindre le club des enfants cool du monde des affaires, a décidé de rejoindre le club des enfants cool du monde de la technologie.

6. Employer 'best practices' à tout bout de champ

Oui, c'est une bataille perdue d'avance. S'insurger contre quelqu'un qui prétend que quelque chose est une « meilleure pratique » alors qu'il s'agit simplement d'une pratique éprouvée ou de la norme minimale du professionnalisme de base est une cause aussi perdue que de se plaindre parce que quelqu'un a commencé sa phrase par "Au final" alors qu'il voulait dire "Finalement". Puisque c'est une cause perdue, passons tout de suite au numéro sept :

7. Passer de la gestion de projet à la gestion de produit

La gestion de projet est la manière dont les organisations font en sorte que demain soit différent d'hier, de manière planifiée et intentionnelle. La gestion de produits est la discipline commerciale qui consiste à gérer l'évolution d'un produit ou d'une gamme de produits d'une entreprise afin de maintenir et d'améliorer son attrait sur le marché.

La gestion des produits informatiques est issue des démarches agiles et n'a, au mieux, qu'un lien distant avec la gestion des produits métiers. En effet, si l'amélioration de l'attrait d'une partie du portefeuille de technologies ou d'applications d'une entreprise présente un intérêt limité, elle ne devrait pas faire l'objet d'une gestion de produits. En réalité, il s'agit plutôt d'établir la responsabilité et l'autorité décisionnelle. Est-ce suffisamment différent, voire supérieur à la gestion de projet, pour que cela soit intéressant ? Probablement pas. Il s'agit en réalité plutôt d'une fausse opposition que d'une révélation.