L'efficacité d'un service informatique se mesure à la fois à la qualité de sa structure et à celle de son mode de fonctionnement. Amené à se transformer face à l'évolution rapide du secteur, il lui faut adopter une vision moins technique de sa fonction, plus politique et plus humaine.
LYNNE MARKUS
Quel est le rôle du service informatique ? Aider les entreprises à utiliser et gérer efficacement l'information et la technologie de l'information (TI). L'efficacité du service lui-même dépend, d'une part, de sa constitution (son organi- sation, sa position et ses politiques ou ce que l'on pourrait appeler le « hardware ») et, d'autre part, de son mode de fonctionnement (ses procédures, sa culture et ses ressources humaines ou le « software »). Pour que le service soit performant, il faut que le « hardware » et le « software » soient en ligne avec les stratégies et la culture de l'entreprise.
* Le « hardware » qu'il faut : le cas de BICC Cables
L'un des premiers défis posés par la gestion des technologies de l'information dans l'entreprise est de mettre en place un service capable d'assurer cette fonction et de le faire correctement pour garantir son efficacité. Mais cette mise en place exige aussi, avant tout, une gestion de l'information extrêmement performante. De plus, les éléments d'un service informatique bien structuré risquent d'évoluer au fil du temps en fonction des besoins stratégiques de l'entreprise et de l'avancée de la technologie.
Ainsi, pendant des années, BICC Cables a confié à ses unités locales une grande partie du pouvoir de décision sur ses activités internationales. En règle générale, ses clients effectuaient leurs achats localement ; et la société pensait que les directeurs des unités opérationnelles locales prendraient de meilleures décisions s'ils avaient la responsabilité de l'ensemble des facteurs influant sur la rentabilité - y compris les TI. Deux problèmes devaient cependant conduire BICC Cables à revoir sa stratégie de gestion de la TI.
En premier lieu, les dirigeants prévoyaient que les clients évolueraient de plus en plus vers une politique d'achat à l'échelle internationale, une tendance qui exigeait une plus grande interdépendance entre les entités locales. En second lieu, ils se rendaient compte que certaines innovations informatiques semblaient requérir une approche différente en termes de gestion. Jusqu'au jour où le comité chargé des budgets d'investissement se retrouva confronté simultanément aux requêtes de deux unités opérationnelles distinctes qui souhaitaient remplacer leurs systèmes d'information vieillissants par une solution logicielle. Toutes deux avaient procédé à une évaluation complète afin d'identifier les meilleurs progiciels susceptibles de répondre à leurs besoins et avaient opté pour deux solutions différentes.
Les membres du comité furent donc amenés à s'interroger sur plusieurs points : les deux unités ne faisaient-elles pas grosso modo le même travail ? Si oui, pourquoi arrivait-on à deux solutions différentes supposées être chacune la meilleure ? Quels seraient les coûts liés à l'adoption de différentes solutions dans les différentes divisions de l'entreprise ? Et une telle initiative ne serait-elle pas un obstacle face aux nouvelles tendances commerciales ? Les recherches préliminaires effectuées montrèrent qu'une approche centralisée de l'acquisition de progiciels reviendrait moins cher à la société que le schéma inverse.
Bien évidemment, toutes ces questions avaient permis de mettre le doigt sur un certain nombre de difficultés. Comment les unités locales réagiraient-elles à cette nouvelle centralisation de la gestion des TI ? Cette décision risquait-elle réellement de porter atteinte à l'autonomie nécessaire aux directeurs opérationnels pour contrôler la rentabilité ? La situation suscitait donc de sérieux problèmes qu'il fallait prendre en considération.
Le comité plaça les deux requêtes en attente afin d'analyser l'intérêt de systèmes communs, et Andrew Cox, le directeur financier de la firme, recruta son premier directeur des systèmes d'information, Alan Harrison. Pour éviter la crainte de la « construction d'un empire informatique », Harrison représenta pendant plusieurs années « un service à lui seul ». Il constitua un groupe de travail à l'échelle de l'entreprise qui établit les schémas des principaux processus dans l'une des unités locales. Chaque site fut ensuite invité à étudier ces schémas et à noter les différences locales. En fin de compte, les résultats étaient formels : les processus des différentes exploitations présentaient bien plus de points communs que de différences. L'entreprise pouvait donc choisir un seul progiciel représentant ce qu'il y avait de mieux pour la société dans son ensemble.
L'étape suivante consistait à former un groupe de travail chargé de sélectionner des progiciels à l'échelle de l'entreprise. Celui-ci devait évaluer plusieurs options possibles, y compris les deux premières défendues par les unités locales. Les critères d'évaluation étaient rigoureusement définis à l'avance, afin d'anticiper toute critique de la part des « perdants ». Quand le comité eut fini sa sélection, Harrison négocia un contrat pour toute l'entreprise avec un fournisseur de progiciels.
Mais ce contrat d'achat n'était pas une fin en soi. Il fallait encore sélectionner les unités qui les adopteraient, déterminer la part qui serait laissée à l'autonomie locale dans leur configuration et définir la façon de gérer la mise en oeuvre et l'assistance. Pour impliquer les unités locales dans l'installation et la mise en oeuvre de ces progiciels, celles-ci devaient demander un financement au comité chargé des budgets d'investissement. Si leur demande devait être justifiée, elles avaient néanmoins toute liberté de le faire en s'appuyant sur leurs spécificités locales. Certaines firent valoir les avantages commerciaux tels que la diminution des stocks et d'autres la réduction des coûts informatiques.
Pour avoir une attitude homogène face à ses futurs clients, BICC Cables décida de développer un modèle commun à toute l'entreprise. Les unités locales pouvaient demander des changements, mais ceux-ci devaient être apportés au stade du modèle général et non de la mise en oeuvre. De plus, celles-ci étaient tenues de procéder elles-mêmes à l'installation des progiciels avec les conseils et l'assistance du fournisseur ainsi que du service informatique, toujours restreint (mais plus limité à un seul homme). Etant donné que les progiciels supposent une fidélité à long terme à la gamme de produits d'un fournisseur (et donc des mises à niveau à l'avenir), l'idée était que ces unités devaient avoir la capacité de gérer localement cette implémentation.
Le cas de BICC Cables est un bon exemple d'amélioration de l'efficacité d'un service informatique. En premier lieu, les décisions sur le « hardware » (taille, structure, mission et fonctions du service informatique, y compris les activités à sous-traiter) sont des décisions stratégiques. En second lieu, celles-ci doivent être revues de temps à autre pour suivre les changements intervenant dans l'activité de l'entreprise ou les opportunités et les défis posés par la technologie de l'information. En troisième lieu, ces décisions varient en fonction des sociétés, mais elles dépendent systématiquement de facteurs tels que leur secteur d'activité, leur taille, leur structure et leurs stratégies commerciales spécifiques, sans oublier leur culture propre.
* La question du « software » : un état d'esprit
Le second critère d'efficacité d'un service informatique est la façon dont il exécute sa mission. Dans le sens entendu dans cet article, le « software » englobe les attitudes, les compétences et les comportements des spécialistes de l'informatique dans leur interaction à la fois avec les directeurs opérationnels et les utilisateurs de cette informatique. Même avec un « hardware » satisfaisant, l'efficacité avec laquelle la société gère et utilise l'information et la technologie doit beaucoup à la philosophie et aux processus du service informatique.
Malheureusement, dans de nombreuses entreprises, il y a très peu de relations entre le service informatique et l'opérationnel. A un certain niveau, cela n'a rien de surprenant. Les conflits entre fonctionnels et opérationnels dans l'entreprise ont toujours existé. Comme dans le cas de BICC, il y a toujours le risque que les opérationnels considèrent les activités des services fonctionnels comme des limites à leur liberté d'action plutôt que comme des conseils d'expert.
Pourtant, la façon dont les services et les professionnels de l'informatique exécutent leur travail peut faire toute la différence dans la qualité des relations entre commerciaux et informaticiens ; et la qualité de cette relation peut, à son tour, faire toute la différence dans la rentabilité des investissements informatiques de l'entreprise.
En tant qu'unité fonctionnelle, le service informatique ne peut légitimement prendre de décisions commerciales, même sur le plan de la technologie de l'information. La prise de décision est la fonction des opérationnels. Il en résulte que le service informatique a essentiellement un rôle consultatif. Cependant, tout le monde sait que la relation entre un conseiller et son client est une relation difficile sur le plan psychologique pour chacune des parties.
Le client risque d'être embarrassé par son ignorance sur le sujet ou de surestimer sa propre expertise. Généralement, il n'aime pas dépendre des experts ni être contraint à abandonner son rôle légitime dans la prise de décision. Parfois, il éprouve un malin plaisir à indiquer au conseiller ce qu'il faut faire. De leur côté, les conseillers peuvent douter de leur capacité à satisfaire les besoins de leurs clients et ont tendance à se protéger derrière leur jargon de spécialiste. Ils font parfois preuve d'arrogance en mettant en exergue leur propre expertise et en soulignant l'ignorance du client. Ils risquent aussi de ne pas écouter leur client ou de décider autoritairement pour lui. Et pire encore, ils peuvent en arriver à recommander des solutions en phase avec leurs propres préférences, convenances et goûts esthétiques, et non avec les besoins du client. Par conséquent, dans de multiples circonstances, on assiste à un « dysfonctionnement » des relations entre les conseillers et leurs clients, ce qui empêche la société d'utiliser efficacement l'information et la technologie.
Les différences fondamentales entre les points de vue des opérationnels, des informaticiens et des utilisateurs de l'informatique aggravent encore la situation. Les informaticiens ont une mentalité d'ingénieur qui n'est guère partagée par ceux avec lesquels ils travaillent. Lors d'une présentation que nous avions faite ensemble, l'un de mes collègues (Michael Ginzberg de la Case Western Reverse University) avait interrogé les directeurs des systèmes d'information sur leurs pouvoirs et leurs politiques sur le plan de l'organisation. L'un d'eux avait répondu : « La plupart des professionnels cde l'informatiques... sont des gens introvertis, obnubilés par la technologie et quasiment binaires sur la `bonne façon'd'agir. Généralement, ils essaient d'éviter tout ce qui est politique, car ils estiment que la politique n'est pas une bonne chose et qu'elle n'arrange rien. »
A contrario, les managers ayant un état d'esprit tourné vers l'action et rompu aux réalités politiques privilégient l'opportunisme par rapport à l'excellence technique. Dans cette optique, la rationalité des spécialistes de l'informatique leur semble généralement aberrante. Les dessins humoristiques ci-dessus, tirés de « CIO Magazine », montrent que les étudiants des grandes écoles/universités américaines perçoivent les professionnels de l'informatique comme des imbéciles asociaux. On se doute bien que ces illustrations reflètent aussi l'opinion de nombreux managers. Naturellement, toutes ces divergences favorisent le manque de communication et les conflits.
La meilleure solution pour y remédier est la compréhension mutuelle. Mais, ceci n'est pas sans contrepartie, car le changement ne peut être à un sens unique. Il faut que les opérationnels comprennent et sachent évaluer les questions techniques et les personnes qui les gèrent. De leur côté, les spécialistes de l'informatique doivent connaître les limites de l'approche technique. Faire évoluer la mentalité technique ne se fera pas sans mal. L'état d'esprit « quasiment binaire » de nombreux spécialistes de l'informatique est lié en partie à leur inné et en partie à leur acquis et à leur ouverture aux autres sur le plan professionnel. Bien qu'il soit généralement admis que le travail des spécialistes de l'informatique porte autant sur les hommes que sur la technologie, la formation des informaticiens et des spécialistes en gestion de systèmes d'information est fortement orientée sur les sujets techniques.
Les questions « soft » (non techniques) sont généralement considérées comme hors sujet. La formation sur le terrain renforce encore ce biais. Certains étudiants embauchés à temps plein comme professionnels de l'informatique m'ont avoué qu'on leur avait demandé de développer des systèmes en les invitant expressément « à éviter d'ennuyer les utilisateurs ».
Après des années de formation et d'endoctrinement techniques, nombre de professionnels sont incapables de reconnaître l'origine des problèmes dans leur travail et de prendre les mesures adéquates pour y remédier. Il suffit de lire les propos d'un développeur expérimenté de logiciels japonais, travaillant pour une société de produits électroniques destinés au marché grand public, après que celui-ci ait suivi une formation axée sur les aspects organisationnels et sociaux du travail informatique : « Il y a peu de temps encore, je participais à de nombreux projets de développement de systèmes d'information en tant qu'ingénieur logiciel, mais je rencontrais beaucoup d'échecs... La difficulté n'était pas tant de coder les programmes pour les utilisateurs. Mais pour des raisons inconnues, les projets partaient à vau-l'eau. Les utilisateurs se plaignaient souvent de notre travail... Et je pensais qu'il fallait améliorer la productivité pour réussir. Je suis sûr que, si nous avions terminé notre travail plus rapidement d'une manière ou d'une autre, les projets n'auraient pas échoué... Je pense que j'ai finalement trouvé le secret du succès dans le développement des systèmes d'information.
« Un conférenciers a évoqué un jour devant moi la `qualité des relations client-système d'information'. Une expression qui m'a fortement frappé. En tant que fournisseur, la qualité est primordiale chez nous. Et ma société m'a appris qu'elle doit toujours être notre première priorité si nous voulons satisfaire le client. Mais ce qu'elle entend par qualité, c'est la qualité des produits. Personne ne m'avait jamais parlé de la `qualité des relations client-système d'information'. Pour moi, c'était un concept totalement nouveau.
« Maintenant, je me souviens que j'avais énormément de difficultés dans les transactions avec les clients parce que je n'avais jamais envisagé ce type de relations... A ce moment-là, je pensais que la situation était due à nos faibles compétences en matière de développement, c'est-à-dire à la piètre qualité de nos produits. Mais, en réalité, elle résultait de la médiocrité de nos talents de négociateur, c'est-à-dire à la mauvaise qualité de nos relations client-système d'information. »
L'intérêt de cet exemple, c'est qu'il montre que l'on peut souvent remédier à la médiocrité de la relation client-système d'information. Il est possible de changer les mentalités par des programmes de formation soigneusement conçus soit dans les établissements d'enseignement soit dans le cadre de l'entreprise. Et ces changements sont possibles dès lors que le service informatique procède à une auto-évaluation et admet la nécessité de se « transformer ». Reprogrammer le « software » du service informatique est peut-être un défi, mais il n'est pas impossible.
Dans la plupart des cas, le changement de « software » découle naturellement des modifications du « hardware » destinées à permettre au service informatique de mieux réagir aux besoins commerciaux. A titre d'exemple, on peut citer la décentralisation de la responsabilité des applications informatiques et/ou du support pour la confier aux services opérationnels ou encore la réduction des fonctions de contrôle du service informatique lui-même. L'entreprise peut, par exemple, dessaisir le service informatique de son pouvoir d'approbation des projets informatiques pour le confier au comité chargé des budgets d'investissement.
Si le changement structurel semble inadéquat, les interventions peuvent porter directement sur la mentalité ou la culture informatique. Le premier pas indispensable pour les spécialistes de l'informatique, c'est d'admettre la nécessité de changer. Et c'est là que les opérationnels peuvent être utiles en leur montrant de façon constructive quelles peuvent être les répercussions de leur comportement de spécialiste ainsi qu'en gérant patiemment toutes leurs réactions défensives par rapport à ces informations. Ils pourront également aider le service informatique à identifier les stratégies à améliorer.
En travaillant avec des spécialistes de la technologie de l'information, j'ai constaté que les programmes de formation pouvaient réussir à changer les attitudes et à développer des capacités de « gestion des relations ». Bien conçus, ceux-ci permettent aux spécialistes de l'informatique de pratiquer des jeux de rôle qui les placent dans des situations délicates par rapport au client (qui est mécontent ou réclame une solution différente) et d'observer la réaction des autres. Ce type d'exercices permet de développer la souplesse de comportement indispensable dès lors que les interlocuteurs ont des visions et des besoins différents. *
Lynne Markus
Lynne Markus est professeur de gestion et de science de l'information à la Peter F. Graduate School of Management (université Claremont Graduate). Ses recherches portent sur l'application et l'administration des systèmes d'entreprise, des data warehouse et des technologies de gestion de la connaissance.
LYNNE MARKUS
Quel est le rôle du service informatique ? Aider les entreprises à utiliser et gérer efficacement l'information et la technologie de l'information (TI). L'efficacité du service lui-même dépend, d'une part, de sa constitution (son organi- sation, sa position et ses politiques ou ce que l'on pourrait appeler le « hardware ») et, d'autre part, de son mode de fonctionnement (ses procédures, sa culture et ses ressources humaines ou le « software »). Pour que le service soit performant, il faut que le « hardware » et le « software » soient en ligne avec les stratégies et la culture de l'entreprise.
* Le « hardware » qu'il faut : le cas de BICC Cables
L'un des premiers défis posés par la gestion des technologies de l'information dans l'entreprise est de mettre en place un service capable d'assurer cette fonction et de le faire correctement pour garantir son efficacité. Mais cette mise en place exige aussi, avant tout, une gestion de l'information extrêmement performante. De plus, les éléments d'un service informatique bien structuré risquent d'évoluer au fil du temps en fonction des besoins stratégiques de l'entreprise et de l'avancée de la technologie.
Ainsi, pendant des années, BICC Cables a confié à ses unités locales une grande partie du pouvoir de décision sur ses activités internationales. En règle générale, ses clients effectuaient leurs achats localement ; et la société pensait que les directeurs des unités opérationnelles locales prendraient de meilleures décisions s'ils avaient la responsabilité de l'ensemble des facteurs influant sur la rentabilité - y compris les TI. Deux problèmes devaient cependant conduire BICC Cables à revoir sa stratégie de gestion de la TI.
En premier lieu, les dirigeants prévoyaient que les clients évolueraient de plus en plus vers une politique d'achat à l'échelle internationale, une tendance qui exigeait une plus grande interdépendance entre les entités locales. En second lieu, ils se rendaient compte que certaines innovations informatiques semblaient requérir une approche différente en termes de gestion. Jusqu'au jour où le comité chargé des budgets d'investissement se retrouva confronté simultanément aux requêtes de deux unités opérationnelles distinctes qui souhaitaient remplacer leurs systèmes d'information vieillissants par une solution logicielle. Toutes deux avaient procédé à une évaluation complète afin d'identifier les meilleurs progiciels susceptibles de répondre à leurs besoins et avaient opté pour deux solutions différentes.
Les membres du comité furent donc amenés à s'interroger sur plusieurs points : les deux unités ne faisaient-elles pas grosso modo le même travail ? Si oui, pourquoi arrivait-on à deux solutions différentes supposées être chacune la meilleure ? Quels seraient les coûts liés à l'adoption de différentes solutions dans les différentes divisions de l'entreprise ? Et une telle initiative ne serait-elle pas un obstacle face aux nouvelles tendances commerciales ? Les recherches préliminaires effectuées montrèrent qu'une approche centralisée de l'acquisition de progiciels reviendrait moins cher à la société que le schéma inverse.
Bien évidemment, toutes ces questions avaient permis de mettre le doigt sur un certain nombre de difficultés. Comment les unités locales réagiraient-elles à cette nouvelle centralisation de la gestion des TI ? Cette décision risquait-elle réellement de porter atteinte à l'autonomie nécessaire aux directeurs opérationnels pour contrôler la rentabilité ? La situation suscitait donc de sérieux problèmes qu'il fallait prendre en considération.
Le comité plaça les deux requêtes en attente afin d'analyser l'intérêt de systèmes communs, et Andrew Cox, le directeur financier de la firme, recruta son premier directeur des systèmes d'information, Alan Harrison. Pour éviter la crainte de la « construction d'un empire informatique », Harrison représenta pendant plusieurs années « un service à lui seul ». Il constitua un groupe de travail à l'échelle de l'entreprise qui établit les schémas des principaux processus dans l'une des unités locales. Chaque site fut ensuite invité à étudier ces schémas et à noter les différences locales. En fin de compte, les résultats étaient formels : les processus des différentes exploitations présentaient bien plus de points communs que de différences. L'entreprise pouvait donc choisir un seul progiciel représentant ce qu'il y avait de mieux pour la société dans son ensemble.
L'étape suivante consistait à former un groupe de travail chargé de sélectionner des progiciels à l'échelle de l'entreprise. Celui-ci devait évaluer plusieurs options possibles, y compris les deux premières défendues par les unités locales. Les critères d'évaluation étaient rigoureusement définis à l'avance, afin d'anticiper toute critique de la part des « perdants ». Quand le comité eut fini sa sélection, Harrison négocia un contrat pour toute l'entreprise avec un fournisseur de progiciels.
Mais ce contrat d'achat n'était pas une fin en soi. Il fallait encore sélectionner les unités qui les adopteraient, déterminer la part qui serait laissée à l'autonomie locale dans leur configuration et définir la façon de gérer la mise en oeuvre et l'assistance. Pour impliquer les unités locales dans l'installation et la mise en oeuvre de ces progiciels, celles-ci devaient demander un financement au comité chargé des budgets d'investissement. Si leur demande devait être justifiée, elles avaient néanmoins toute liberté de le faire en s'appuyant sur leurs spécificités locales. Certaines firent valoir les avantages commerciaux tels que la diminution des stocks et d'autres la réduction des coûts informatiques.
Pour avoir une attitude homogène face à ses futurs clients, BICC Cables décida de développer un modèle commun à toute l'entreprise. Les unités locales pouvaient demander des changements, mais ceux-ci devaient être apportés au stade du modèle général et non de la mise en oeuvre. De plus, celles-ci étaient tenues de procéder elles-mêmes à l'installation des progiciels avec les conseils et l'assistance du fournisseur ainsi que du service informatique, toujours restreint (mais plus limité à un seul homme). Etant donné que les progiciels supposent une fidélité à long terme à la gamme de produits d'un fournisseur (et donc des mises à niveau à l'avenir), l'idée était que ces unités devaient avoir la capacité de gérer localement cette implémentation.
Le cas de BICC Cables est un bon exemple d'amélioration de l'efficacité d'un service informatique. En premier lieu, les décisions sur le « hardware » (taille, structure, mission et fonctions du service informatique, y compris les activités à sous-traiter) sont des décisions stratégiques. En second lieu, celles-ci doivent être revues de temps à autre pour suivre les changements intervenant dans l'activité de l'entreprise ou les opportunités et les défis posés par la technologie de l'information. En troisième lieu, ces décisions varient en fonction des sociétés, mais elles dépendent systématiquement de facteurs tels que leur secteur d'activité, leur taille, leur structure et leurs stratégies commerciales spécifiques, sans oublier leur culture propre.
* La question du « software » : un état d'esprit
Le second critère d'efficacité d'un service informatique est la façon dont il exécute sa mission. Dans le sens entendu dans cet article, le « software » englobe les attitudes, les compétences et les comportements des spécialistes de l'informatique dans leur interaction à la fois avec les directeurs opérationnels et les utilisateurs de cette informatique. Même avec un « hardware » satisfaisant, l'efficacité avec laquelle la société gère et utilise l'information et la technologie doit beaucoup à la philosophie et aux processus du service informatique.
Malheureusement, dans de nombreuses entreprises, il y a très peu de relations entre le service informatique et l'opérationnel. A un certain niveau, cela n'a rien de surprenant. Les conflits entre fonctionnels et opérationnels dans l'entreprise ont toujours existé. Comme dans le cas de BICC, il y a toujours le risque que les opérationnels considèrent les activités des services fonctionnels comme des limites à leur liberté d'action plutôt que comme des conseils d'expert.
Pourtant, la façon dont les services et les professionnels de l'informatique exécutent leur travail peut faire toute la différence dans la qualité des relations entre commerciaux et informaticiens ; et la qualité de cette relation peut, à son tour, faire toute la différence dans la rentabilité des investissements informatiques de l'entreprise.
En tant qu'unité fonctionnelle, le service informatique ne peut légitimement prendre de décisions commerciales, même sur le plan de la technologie de l'information. La prise de décision est la fonction des opérationnels. Il en résulte que le service informatique a essentiellement un rôle consultatif. Cependant, tout le monde sait que la relation entre un conseiller et son client est une relation difficile sur le plan psychologique pour chacune des parties.
Le client risque d'être embarrassé par son ignorance sur le sujet ou de surestimer sa propre expertise. Généralement, il n'aime pas dépendre des experts ni être contraint à abandonner son rôle légitime dans la prise de décision. Parfois, il éprouve un malin plaisir à indiquer au conseiller ce qu'il faut faire. De leur côté, les conseillers peuvent douter de leur capacité à satisfaire les besoins de leurs clients et ont tendance à se protéger derrière leur jargon de spécialiste. Ils font parfois preuve d'arrogance en mettant en exergue leur propre expertise et en soulignant l'ignorance du client. Ils risquent aussi de ne pas écouter leur client ou de décider autoritairement pour lui. Et pire encore, ils peuvent en arriver à recommander des solutions en phase avec leurs propres préférences, convenances et goûts esthétiques, et non avec les besoins du client. Par conséquent, dans de multiples circonstances, on assiste à un « dysfonctionnement » des relations entre les conseillers et leurs clients, ce qui empêche la société d'utiliser efficacement l'information et la technologie.
Les différences fondamentales entre les points de vue des opérationnels, des informaticiens et des utilisateurs de l'informatique aggravent encore la situation. Les informaticiens ont une mentalité d'ingénieur qui n'est guère partagée par ceux avec lesquels ils travaillent. Lors d'une présentation que nous avions faite ensemble, l'un de mes collègues (Michael Ginzberg de la Case Western Reverse University) avait interrogé les directeurs des systèmes d'information sur leurs pouvoirs et leurs politiques sur le plan de l'organisation. L'un d'eux avait répondu : « La plupart des professionnels cde l'informatiques... sont des gens introvertis, obnubilés par la technologie et quasiment binaires sur la `bonne façon'd'agir. Généralement, ils essaient d'éviter tout ce qui est politique, car ils estiment que la politique n'est pas une bonne chose et qu'elle n'arrange rien. »
A contrario, les managers ayant un état d'esprit tourné vers l'action et rompu aux réalités politiques privilégient l'opportunisme par rapport à l'excellence technique. Dans cette optique, la rationalité des spécialistes de l'informatique leur semble généralement aberrante. Les dessins humoristiques ci-dessus, tirés de « CIO Magazine », montrent que les étudiants des grandes écoles/universités américaines perçoivent les professionnels de l'informatique comme des imbéciles asociaux. On se doute bien que ces illustrations reflètent aussi l'opinion de nombreux managers. Naturellement, toutes ces divergences favorisent le manque de communication et les conflits.
La meilleure solution pour y remédier est la compréhension mutuelle. Mais, ceci n'est pas sans contrepartie, car le changement ne peut être à un sens unique. Il faut que les opérationnels comprennent et sachent évaluer les questions techniques et les personnes qui les gèrent. De leur côté, les spécialistes de l'informatique doivent connaître les limites de l'approche technique. Faire évoluer la mentalité technique ne se fera pas sans mal. L'état d'esprit « quasiment binaire » de nombreux spécialistes de l'informatique est lié en partie à leur inné et en partie à leur acquis et à leur ouverture aux autres sur le plan professionnel. Bien qu'il soit généralement admis que le travail des spécialistes de l'informatique porte autant sur les hommes que sur la technologie, la formation des informaticiens et des spécialistes en gestion de systèmes d'information est fortement orientée sur les sujets techniques.
Les questions « soft » (non techniques) sont généralement considérées comme hors sujet. La formation sur le terrain renforce encore ce biais. Certains étudiants embauchés à temps plein comme professionnels de l'informatique m'ont avoué qu'on leur avait demandé de développer des systèmes en les invitant expressément « à éviter d'ennuyer les utilisateurs ».
Après des années de formation et d'endoctrinement techniques, nombre de professionnels sont incapables de reconnaître l'origine des problèmes dans leur travail et de prendre les mesures adéquates pour y remédier. Il suffit de lire les propos d'un développeur expérimenté de logiciels japonais, travaillant pour une société de produits électroniques destinés au marché grand public, après que celui-ci ait suivi une formation axée sur les aspects organisationnels et sociaux du travail informatique : « Il y a peu de temps encore, je participais à de nombreux projets de développement de systèmes d'information en tant qu'ingénieur logiciel, mais je rencontrais beaucoup d'échecs... La difficulté n'était pas tant de coder les programmes pour les utilisateurs. Mais pour des raisons inconnues, les projets partaient à vau-l'eau. Les utilisateurs se plaignaient souvent de notre travail... Et je pensais qu'il fallait améliorer la productivité pour réussir. Je suis sûr que, si nous avions terminé notre travail plus rapidement d'une manière ou d'une autre, les projets n'auraient pas échoué... Je pense que j'ai finalement trouvé le secret du succès dans le développement des systèmes d'information.
« Un conférenciers a évoqué un jour devant moi la `qualité des relations client-système d'information'. Une expression qui m'a fortement frappé. En tant que fournisseur, la qualité est primordiale chez nous. Et ma société m'a appris qu'elle doit toujours être notre première priorité si nous voulons satisfaire le client. Mais ce qu'elle entend par qualité, c'est la qualité des produits. Personne ne m'avait jamais parlé de la `qualité des relations client-système d'information'. Pour moi, c'était un concept totalement nouveau.
« Maintenant, je me souviens que j'avais énormément de difficultés dans les transactions avec les clients parce que je n'avais jamais envisagé ce type de relations... A ce moment-là, je pensais que la situation était due à nos faibles compétences en matière de développement, c'est-à-dire à la piètre qualité de nos produits. Mais, en réalité, elle résultait de la médiocrité de nos talents de négociateur, c'est-à-dire à la mauvaise qualité de nos relations client-système d'information. »
L'intérêt de cet exemple, c'est qu'il montre que l'on peut souvent remédier à la médiocrité de la relation client-système d'information. Il est possible de changer les mentalités par des programmes de formation soigneusement conçus soit dans les établissements d'enseignement soit dans le cadre de l'entreprise. Et ces changements sont possibles dès lors que le service informatique procède à une auto-évaluation et admet la nécessité de se « transformer ». Reprogrammer le « software » du service informatique est peut-être un défi, mais il n'est pas impossible.
Dans la plupart des cas, le changement de « software » découle naturellement des modifications du « hardware » destinées à permettre au service informatique de mieux réagir aux besoins commerciaux. A titre d'exemple, on peut citer la décentralisation de la responsabilité des applications informatiques et/ou du support pour la confier aux services opérationnels ou encore la réduction des fonctions de contrôle du service informatique lui-même. L'entreprise peut, par exemple, dessaisir le service informatique de son pouvoir d'approbation des projets informatiques pour le confier au comité chargé des budgets d'investissement.
Si le changement structurel semble inadéquat, les interventions peuvent porter directement sur la mentalité ou la culture informatique. Le premier pas indispensable pour les spécialistes de l'informatique, c'est d'admettre la nécessité de changer. Et c'est là que les opérationnels peuvent être utiles en leur montrant de façon constructive quelles peuvent être les répercussions de leur comportement de spécialiste ainsi qu'en gérant patiemment toutes leurs réactions défensives par rapport à ces informations. Ils pourront également aider le service informatique à identifier les stratégies à améliorer.
En travaillant avec des spécialistes de la technologie de l'information, j'ai constaté que les programmes de formation pouvaient réussir à changer les attitudes et à développer des capacités de « gestion des relations ». Bien conçus, ceux-ci permettent aux spécialistes de l'informatique de pratiquer des jeux de rôle qui les placent dans des situations délicates par rapport au client (qui est mécontent ou réclame une solution différente) et d'observer la réaction des autres. Ce type d'exercices permet de développer la souplesse de comportement indispensable dès lors que les interlocuteurs ont des visions et des besoins différents. *
Lynne Markus
Lynne Markus est professeur de gestion et de science de l'information à la Peter F. Graduate School of Management (université Claremont Graduate). Ses recherches portent sur l'application et l'administration des systèmes d'entreprise, des data warehouse et des technologies de gestion de la connaissance.
source: http://www.lesechos.fr
Aucun commentaire:
Enregistrer un commentaire
ajouter votre commentaire: n'oubliez pas votre commentaire nous intéresse