Tout à fait d'accord sur la pollution par la notion de client.
Il est vrai qu'il y a des utilisateurs "sangsues" et qui semblent ne
jamais vouloir apprendre. C'est un problème de GRH, pas de l'IT, mais
comme tous les services, l'IT doit faire avec. Ce sont les même qui ne
savent pas régler un bourrage sur une photocopieuse, qui ne font pas le
plein d'essence des voitures, voire qui ne tirent pas la chasse des
toilettes. Tout le monde doit les supporter. Pénaliser tout le monde à
cause des moins brillants de l'ensemble est la solution de facilité.
Le service informatique qui sert de formateur-par-téléphone. Est-ce que
cette situation est jugée normale par la direction ? Si oui, il faut
engager des formateurs en interne, sinon il faut envoyer les gens en
formation. Ce n'est de nouveau pas une raison pour ne pas mettre des
outils sophistiqués entre les mains des gens, surtout s'ils en ont
besoin ou si ces outils sont utiles.
Tout cela sont plus des problèmes de gestion et de management que
d'informatique.
Le 18/03/2008 14:22, Jacques GAIGNARD a écrit :
Je ne trouve l'avis de Louis Naugès ni pertinent ni adulte.
La règle des 3 A proposée (*Accepter, Aider, Accompagner) *ne semble
s'adresser qu'aux DSI.
J'ajouterai volontiers pour l'ensemble des DSI "ET" des utilisateurs le
concept des "plein de A" :
Assistance totale, Alzheimer, Antisocial, Abandonisme, et j'en j'oublie
probablement.
Je reviendrai par ailleurs sur la notion de client qui pollue
considérablement le raisonnement.
Le terrain depuis 20 ans d'informatique m'a montré surtout des
utilisateurs qui ne jouent aucun autre jeu que le leur et surtout
individuellement. Le plus souvent les logiciels ne sont réclamés que
pour eux-même et même les collègues de leur service sont parfois
carrément oubliés.
L'aide et/ou l'accompagnement deviennent très vite (dès que ces "chiens
d'informaticiens" acceptent) une assistance totale, limite secrétariat
en ce qui concerne les outils bureautiques notamment. Aidez quelqu'un à
tracer un camembert et vous vous retrouverez très vite avec la même
question chaque semaine ou chaque mois du même demandeur.
Les recrutements sont par ailleurs faits sans intégration des
contraintes liées aux outils qui seront employés.
Une application de gestion ne s'apprend pas en 5 minutes. Pourtant,
rares sont les périodes de formation aux applications en début de prise
de fonction. Dès lors la hotline de l'entreprise ou ce qui y correspond
devient enseignant au lieu d'être dépanneur.
Les utilisateurs ne savent pas, et pire ils n'apprennent pas. Au
passage, pour palier à ces carences, les services réclament plus de
contrôles. En effet, pour un "débutant", l'application ne doit pas
laisser faire ceci ou cela.
Losqu'une erreur survient, c'est un problème informatique et jamais une
erreur humaine car c'est bien trop proche de l'encadrement entre autres
raisons.
Bon, je pourrais passer des heures sur le caractère envahissant et
coûteux au final de l'utilisateur inadapté à sa structure.
Pour ma part, oui je trouve qu'il est bon de laisser un utilisateur
développer ses propres macro. En effet, c'est le seul moyen que j'ai
trouvé pour faire grandir leurs chefs de services. Quand ils sont bien
envahis de bidules inmaintenables le vrai dialogue peut commencer. En
outre je donne bien souvent raison à ceux qui tentent de se dépatouiller
de ce qu'on leur demande, ils sont aussi là pour cela. Le monde au final
finira bien par s'équilibrer.
L'erreur redoutable que commets à mon sens Louis Naugès, c'est
d'exploiter la notion de client bien au delà des réalités. Si le concept
ITIL parle bien de client, cela entre paradoxe avec l'esprit d'équipe.
Le client c'est celui qui paie. Ce n'est pas l'utilisateur. Au mieux un
contrat de service peut être passé entre la DSI et le chef de service.
Mais quand ça accroche, c'est l'informatique qui est défaillante et pas
le contrat passé dont bien souvent l'utilisateur ignore jusqu'à
l'existence.
De plus un client a le choix de son fournisseur. La réalité montre que
ce n'est pas le cas dans une entreprise face à un service informatique.
Les utilisateurs sont dans la réalité réticents eux mêmes à cette notion
de client quand il faut la mettre en oeuvre. Faites l'essai de renvoyer
l'utilisateur vers la hotline de l'éditeur d'un logiciel pour voir...
Pourtant ils seront considérés comme un client pour le coup. Bien sûr
certains en seront ravis et seront très efficaces, mais combien ? Une
minorité qui se lassera assez vite.
Cette notion d'utilisateur/client est tellement pleine de connotations
que les raisonnements sont faussés et les communications deviennent
ubuesques.
L'utilisateur n'est que très très rarement un client. Un client est
quelqu'un qui sait ou au moins veut savoir ce qu'il achète.
Hou que j'aimerais par exemple que l'utilisateur soit un client.
On lui affecterait personnellement tant d'euros pour son assistance
informatique, et en fin d'année, soit il a dépensé la somme, soit il
l'empoche. Là il se comportera certainement comme un client, celui qui
paie de sa poche.
******
Clause d'exonération de responsabilité :
http://www.cfwb.be/index.php?id=disclaimer
******
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
