Organigramme du service informatique de De Dietrich Thermique

Les services informatiques

Introduction

De Dietrich Thermique, Remeha et Baxi possèdent leur informatique propre et des méthodes industrielles différentes. Le contexte économique et la stratégie du groupe conduisent à un changement de cap. Nous nous orientons vers l’assemblage de composants en abandonnant peu à peu leur fabrication qui est externalisée (corps de chauffe, électronique, tôle…). Ces méthodes d’assemblage en flux tendu sont peu à peu généralisées dans le groupe. Le rôle de l’informatique devient prépondérant car le dysfonctionnement d’un composant du système d’information peut conduire immédiatement à un arrêt de production et des pertes financières en conséquence (Exemple : 1 heure d’arrêt de production pour l’usine de Mertzwiller représente une perte d’environ 260 000 euros de chiffre d’affaires).

Parc informatique

Le parc informatique de Dietrich Thermique est composé de :
• 1000 PC dont 350 PC portables
• 93 serveurs (sur une infrastructure virtuelle)
• 115 postes téléphoniques en voix sur IP
• 350 imprimantes
• 69 commutateurs
• 20 routeurs
• 200 PDA

Utilisateurs et outils

Le périmètre du projet se limite à De Dietrich Thermique pour l’ensemble des fonctions de support et à Remeha pour le support du progiciel de gestion SAP. Il y a environ 1200 utilisateurs de nos systèmes d’information du côté de De Dietrich Thermique répartis sur 17 sites principalement en France (3 bureaux de représentation en Russie, Espagne et Chine). Pour ces sites la langue de support est le français. Remeha regroupe 550 utilisateurs de SAP, la langue de support est l’anglais.
Nous assurons la gestion de ce parc principalement grâce à des outils de prise de main à distance au travers de liaisons distantes sécurisées. Sur ces 1750 personnes, 400 environ sont des « nomades » disposant d’un PC portable. Ces personnes se connectent au travers de liaisons VPN (Virtual Private Network), ce sont des liens virtuels sécurisés qui passentpar Internet. La majorité des outils utilisés sont en mode client-serveur comme SAP mais nous avons de plus en plus d’outils en mode web, la CRM (Customer Relationship management, ou gestion de la relation client) en est un bon exemple.

Etat des lieux

Introduction

Au départ de ce projet, j’assure la fonction de technicien micro et réseau. Une hotline est en place, elle est constituée uniquement d’un responsable hotline. Cette personne n’a pas un profil de technicien, son rôle est de traiter les problèmes simples (problèmes de mots de passe, problèmes matériels simples…) et de transférer les autres demandes aux autres personnes du service en fonction de leurs compétences. Le responsable de la hotline, un autre technicien micro et réseau et moi-même sommes installés dans le même bureau.
Le fonctionnement de cette hotline est « basique » :
• Les utilisateurs contactent cette hotline au travers d’un numéro unique (le 7777) pour tout problème micro ou réseau (panne matérielle, problème fonctionnel…).
• Les appels ne sont pas saisis, ni dans un logiciel, ni sur papier.
• Tous les appels sont traités directement sans priorisation, aucun traitement n’est différé.
• Si le responsable de la hotline n’arrive pas à résoudre le problème, il transfert la demande à l’une des deux personnes présentes dans le bureau. Tous les appels étant traités directement il est difficile de transférer les appels à d’autres personnes du service (personnes réticentes à la prise en charge des appels, personnes absentes de leur bureau…).
• Le responsable de la hotline assure également la gestion du parc informatique à l’aide du logiciel Kimoce.
Un certain nombre de problèmes sont apparus dans cette organisation, problèmes auxquels j’ai souhaité apporté une réponse au travers de ce projet.

Solution proposée

Introduction

Les différentes problématiques décrites dans la section précédente ont été la cause de tensions et de stress pour les membres de l’équipe informatique et en particulier pour les personnes présentes dans le bureau de la hotline.
En réaction à cet état de fait j’ai réfléchi à des solutions permettant d’améliorer cette situation. Je me suis fixé plusieurs objectifs.
• Améliorer la qualité de service.
• Diminuer les tensions et le stress.
• Répartir d’une manière plus homogène la charge de travail.
• Améliorer la productivité du service informatique en gérant le flux des appels pour que les personnes ayant en charge des projets ou des tâches de maintenance ne soient pas constamment importunées par des appels hotline.
Pour atteindre ces objectifs, il m’a semblé indispensable d’adopter une démarche qualité, d’après Jean-François Pillou dans son ouvrage intitulé « Tout sur les systèmes d’information » : « La qualité peut se définir comme la capacité à atteindre les objectifs opérationnels visés.»
La qualité se décline sous deux formes qui permettent de répondre aux objectifs fixés:
• La qualité externe qui correspond à la satisfaction des clients :

Améliorer la qualité de service

• La qualité interne qui correspond à l’amélioration du fonctionnement interne de l’entreprise :
o Diminuer les tensions et le stress
o Répartir d’une manière plus homogène la charge de travail
o Améliorer la productivité du service informatique en gérant le flux des appels pour que les personnes ayant en charge des projets ou des tâches de maintenance ne soient pas constamment importunées par des appels hotline
L’enjeu principal de la qualité est d’initier un cercle vertueux d’amélioration continue, cette démarche implique la définition des méthodes à mettre en œuvre pour atteindre les objectifs fixés ainsi que l’évaluation du niveau de qualité pour permettre au service informatique de se situer par-rapport à ces exigences.
Je vais aborder dans cette section les critères de choix d’une méthode puis la description de la méthode retenue.

Choix d’une méthode

Deux possibilités s’offraient à moi pour effectuer le choix d’une méthode :
• Définir une nouvelle méthode totalement adaptée à notre contexte.
• Me baser sur un référentiel qualité existant.
La définition d’une nouvelle méthode est la solution la plus souple mais elle a des inconvénients majeurs :
• Plus couteuse en temps car elle doit être définie.
• Plus risquée car il serait présomptueux de penser pouvoir définir une méthode parfaite, il y a donc un risque important de proposer une méthode qui ne répondrait qu’imparfaitement à nos problématiques et qui mettrait un certain temps pour acquérir un niveau de maturité satisfaisant.
Il me semble important de ne pas réinventer la roue mais de me baser sur un existant et de lui apporter toutes les améliorations nécessaires pour atteindre nos objectifs. C’est la raison pour laquelle j’ai choisi de m’orienter préférentiellement vers un référentiel qualité si tant est qu’il en existe un qui réponde à nos attentes. Un référentiel est un guide méthodologique efficace qui me permettra de démontrer que j’ai pris toutes les meilleures dispositions possibles.

Comparaison de ces normes / référentiels

De Dietrich Thermique est certifié ISO 9001, c’est une norme exigée par nos clients pour pouvoir leur vendre nos produits. Elle n’aborde pas les processus propres à la gestion des systèmes d’informations, elle reste plus généraliste. Le principe essentiel qui nous intéresse dans cette norme est la notion d’amélioration continue, qui est reprise dans les différents référentiels / normes de ce comparatif. ISO 20 000 est moins complet qu’ITIL et est actualisé moins régulièrement, l’intérêt principal de cette norme par-rapport au référentiel ITIL est de pouvoir certifier une organisation. Un référentiel ne permet de certifier qu’une personne ; cette certification garantit uniquement qu’une personne à la connaissance des bonnes pratiques. Il y a seulement 150 entreprises certifiées ISO 20 000 en Europe. eSCM se situe « au-dessus du référentiel ITIL », il précise comment une DSI doit bâtir sa stratégie d’externalisation et la façon dont elle doit s’organiser pour mettre en place son externalisation.

Conclusion

Il n’existe à l’heure actuelle qu’un seul référentiel qui décrit d’une manière détaillée les processus qui nous concernent dans le cadre de ce projet, il s’agit d’ITIL. ITIL est complet et détaillé, il est reconnu par les directions des systèmes d’information comme étant le référentiel le plus connu et le plus utilisé par les entreprises pour gérer leurs systèmes d’informations. D’après une enquête menée par les sociétés IDC et Teamup Consulting en2009 [2] sur un panel de 120 grandes entreprises françaises de plus de 500 salariés, 35 %utilisent ITIL.

Etude du projet

Analyse du projet

Documentation

La première étape avant de définir la stratégie a été de se documenter sur les méthodes de mise en œuvre d’ITIL dans un contexte « réel » et d’obtenir des retours d’expérience d’helpdesk en production. Cette phase est assez longue mais ne doit pas être négligée pour éviter de commettre des erreurs et ainsi définir la meilleure stratégie pour assurer le succès et la validation du projet.
Pour ce faire je me suis appuyé sur trois axes :
• Suivi d’une formation « l’état de l’art helpdesk » : formation effectuée par une personne expérimentée ayant mis en place un certain nombre de helpdesk. Cette formation était axée sur les bonnes pratiques pour gérer et mettre en œuvre un helpdesk en s’appuyant sur des exemples concrets.
• Lecture de différents livres et documents traitant du sujet dont bien-sûr le référentiel ITIL.
• Discussion avec des personnes ayant mis en œuvre ou étant en cours de mise en œuvre d’un helpdesk pour obtenir leur retour d’expérience.
• Suivi d’une formation « ITIL v3 : Obtenir la certification Foundation » [7] qui est le premier niveau de la certification ITIL.
J’ai retiré de cette phase de documentation / formation un grand nombre d’informations intéressantes. J’y ferai référence tout au long de ce mémoire pour appuyer mes choix.

Facteurs clés de succès

J’ai identifié un certain nombre de facteurs clés de succès pour la réussite de l’implémentation de notre helpdesk :
• Impliquer le management : « le management doit tenir un rôle actif dans la conception et l’évangélisation de cette nouvelle culture de service » selon C. Dumont.
• Prendre en considération l’importance des métriques comme le soulignent R. Marcella et I. Middelton [8]: « Une fois opérationnel, le service doit être rigoureusement monitoré pour s’assurer de la réalisation des objectifs et le respect des normes » ; métriques qui ont également un rôle important pour maintenir la motivation de l’équipe helpdesk.
• Les appels sont centralisés en un point unique, l’une des difficultés principales étant d’éviter les appels qui ne respectent pas ce cheminement.
• Le management doit convaincre les techniciens du helpdesk de l’utilité de la saisie des appels.
• Le helpdesk doit être défini rigoureusement avec le concours de la direction.
Ces objectifs doivent permettre de construire un helpdesk fédérateur vu comme un service de proximité, qui maintient une bonne qualité de service pour assurer un support de qualité aux utilisateurs avec pour tâche connexe la maintenance du parc informatique, en garantissant sa cohérence.

Périmètre

Le premier objectif est d’assurer la gestion des incidents informatiques pour les 1200 utilisateurs de De Dietrich Thermique sur toutes les applications et matériels gérés. Le deuxième objectif est d’assurer la gestion des incidents sur le progiciel de gestion intégré SAP pour les 550 utilisateurs de Remeha en Hollande. Les langues utilisées seront l’anglais avec le site d’Apeldoorn, l’allemand avec le site d’Emsdetten et le français avec les autres sites.

Montage et planification du projet

Organisation

La structure du projet est une structure avec coordination, ce qui signifie que le chef de projet est directement rattaché à la direction qui coiffe tous les services intervenants. En effet, dans le cadre de ce projet je réponds directement au directeur informatique, mais je reste rattaché à ma hiérarchie habituelle en ce qui concerne mes autres activités.
L’avantage de ce type de structure est sa facilité de mise en œuvre, l’inconvénient majeur est la difficulté du partage des ressources.

Planification

J’ai choisi de réaliser la planification du projet à l’aide du logiciel Microsoft Project. Ce logiciel permet de découper le projet sous forme de tâches et de gérer leur avancement ainsi que la répartition des ressources sous la forme d’un diagramme de Gantt. La visualisation du projet sous cette forme est un atout pour suivre d’une manière rapide et efficace les étapes et tenir les délais. La réalisation d’un planning permet également de structurer, identifier et prioriser les tâches et ainsi optimiser la gestion du projet.

Calcul du dimensionnement

Une étape importante pour lancer le helpdesk consiste à dimensionner le helpdesk, il s’agit ²de définir le nombre de personnes nécessaires au helpdesk correspondant à la charge de travail. Pour effectuer le calcul de dimensionnement je me suis appuyé sur un modèle simple de dimensionnement d’un helpdesk proposé lors de la formation Capgemini.

Nombre d’incidents

Pour définir le nombre d’incidents je me suis appuyé sur l’historique des appels (estimation de 400 appels / mois sans compter les appels qui ne passent pas par la hotline) et sur les retours d’expérience communiqués lors de la formation CapGemini. Les chiffres de cette formation sont dans un contexte industriel d’un appel par utilisateur et par mois en moyenne.
Nous devons assurer le support pour 1200 utilisateurs, je suis parti sur une base intermédiaire de 1000 appels par mois.

Temps moyen de traitement

Selon Claire Noirault dans son livre intitulé « ITIL (version 3) les meilleures pratiques de gestion d’un service informatique » [13] : « le temps moyen de traitement est compris entre 10 et 15 minutes ». Sur la base de l’historique des appels que j’ai journalisés, le temps moyen de traitement est d’environ 20 minutes. J’ai pris le parti d’avoir un helpdesk composé de techniciens confirmés traitant 80 % des appels sans passage au niveau 2 car remonter au niveau 2 coute en moyenne 5 à 7 fois plus cher à l’entreprise . Les problématiques à traiter étant variées et techniques j’ai retenu une base de 20 minutes

Définition du planning

J’ai dû prendre en compte une contrainte supplémentaire pour l’élaboration du planning. Sur les quatre techniciens retenus pour participer au helpdesk, un seul a accepté d’adapter ses horaires, les trois autres souhaitant conserver leurs horaires pour des contraintes familiales. Dans le cadre de la conduite du changement (cf. section III.3.1) j’ai décidé, en accord avec le DSI, d’adapter leur présence en fonction de leurs horaires et des cours d’anglais.

Astreintes

Les nouvelles organisations métier requièrent un fonctionnement sans faille du système  d’information. Pour répondre à ces besoins émergents, l’organisation du service informatique doit être optimisée afin de mieux servir les clients internes et externes, eu égard :
• A la mise en place du module SAP permettant de gérer les emplacements à la logistique qui fonctionne en horaires décalés.
• A l’arrivée imminente de Remeha sur notre système, sachant que cette entité n’a pas les mêmes exigences horaires que DDTH.
La moindre interruption de fonctionnement de notre ERP ou du système d’impression a pour conséquence l’arrêt des lignes de production. Un certain nombre de moyens ont été mis en œuvre pour sécuriser l’infrastructure (serveurs redondants, onduleurs, deuxième salle informatique). Malgré ces dispositions des problèmes fonctionnels ou techniques peuvent survenir : panne de climatisation, espace de stockage plein empêchant l’écriture de nouvelles données… Jusqu’à présent lors d’incidents hors des plages d’ouverture, les personnes constatant un incident tentaient de joindre une à une les personnes du service informatique à leur domicile. Ce mode de fonctionnement ne garantissait ni une intervention, ni une réactivité suffisante.
Pour répondre à ces nouveaux besoins, j’ai proposé de mettre en place un système d’astreinte ; ce dispositif a été négocié avec les techniciens helpdesk, la direction informatique et la direction des ressources humaines.
Pour mettre en œuvre cette gestion, ITIL préconise un outil informatique dédié pour faciliter la saisie et l’exploitation des données. Nous disposons du logiciel Kimoce qui inclut une gestion de parc et une gestion des demandes. Ce produit avait été retenu au service informatique pour en acquérir une maîtrise et ainsi assurer une meilleure assistance aux utilisateurs de ce logiciel. En effet Kimoce est utilisé par les services à la clientèle(Service Après-Vente, assistante aux professionnels et aux particuliers) comme outil de CRM.
Cet outil n’a pas été choisi pour répondre aux besoins du service informatique, il a été rapidement abandonné par le service informatique car ses fonctionnalités ne donnaient pas satisfaction. La seule fonction utilisée était la gestion de parc.
Ne disposant pas de budget pour acquérir une solution plus adaptée à notre contexte (au minimum 50 000 € d’investissement pour un nouveau produit), j’ai décidé de revoir la configuration de ce logiciel, l’objectif étant de couvrir 80% des fonctionnalités attendues. J’ai également étudié les solutions du monde libre (GLPI, OTRS) mais elles ne sont pas au niveau de solutions payantes et ne sont pas meilleures que Kimoce.
Je suis parti du principe que l’outil n’est qu’un moyen, il s’agit de bien définir les processus et d’organiser d’une manière efficace le helpdesk. J’ai constaté à de nombreuses reprises que les outils sont souvent considérés comme étant structurants c’est-à-dire que la mise en œuvre du logiciel va permettre d’organiser les équipes et de gagner du temps. Je pense que ce n’est pas une bonne approche. D’autant plus qu’un outil de saisie des demandes ajoute de la charge de travail et est vu comme un outil de « flicage ». L’un des challenges a été de démontrer l’intérêt de saisir les appels.

Configuration de l’outil

La description des actions ayant été effectuée je suis passé à l’étape de configuration du logiciel Kimoce pour la saisie de ces demandes.
La première étape a été de simplifier l’interface de saisie en enlevant tous les champs inutiles, j’ai ensuite mis en place dans le logiciel la typologie des demandes vue précédemment.
Cette reconfiguration du logiciel Kimoce nous a permis d’obtenir un système de gestion des appels efficace pour démarrer le helpdesk. Ce logiciel nous apporte une aide précieuse pour effectuer le suivi et la gestion des demandes. La technologie n’est pas un but mais un moyen, le plus important a été de définir une organisation et des processus fiables basés sur ITIL. Le logiciel est un moyen pour simplifier et automatiser certaines tâches. Il s’avère que les défauts du logiciel (manque d’ergonomie, pas compatible avec tous les processus ITIL, performance du moteur de recherche) ne sont pas un frein à l’avancement et la réalisation de ce projet.

Base de connaissances

Une base de connaissances est un outil indispensable dans un helpdesk, elle permet d’avoir un accès rapide à des informations permettant de résoudre les demandes. Le helpdesk y gagne une meilleure réactivité et facilite l’intégration de nouveaux arrivants qui ne maîtrisent pas encore notre système d’information. Mais pour être efficace il faut que la base de connaissances réponde à certains critères :
• Accès rapide.
• Moteur de recherche performant.
• Possibilité de classifier et structurer les connaissances.
• Fonction de validation des informations saisies.
• Utilisation simple et ergonomique.
• Processus de création d’un nouvel article rapide.
La base de connaissances proposée dans le logiciel Kimoce n’a jamais été adoptée par les techniciens du helpdesk pour deux raisons :
• Pas de moteur de recherche.
• Ergonomie complexe d’où des difficultés pour ajouter des articles.
Pour répondre à cette problématique j’ai décidé de développer une base de connaissances.
J’ai porté mon choix sur le langage PHP pour proposer une interface web simple d’accès.
J’ai effectué ce développement hors temps de travail, mais j’estime le temps développement à un mois temps plein pour une personne. Cette base s’apparente à une GED (Gestion Electronique de Documents), une multitude d’outils existent sur le marché et un développement en interne ne peut pas atteindre leur niveau. Mais les contraintes budgétaires ne me permettaient pas d’envisager l’acquisition d’un outil de ce type.
Cet outil nous permet tout de même de disposer de toutes les fonctions essentielles et il a rapidement été adopté par tous les techniciens du helpdesk dans un premier temps puis par une partie des membres du service informatique. Grâce à cet outil les informations importantes sont centralisées et facilement accessibles.

Matrice de compétences

Le nombre de membres du service informatique étant en croissance, il devient difficile de connaître précisément les compétences de chacun. Pour répondre à cette problématique, j’ai proposé la réalisation d’une matrice de compétences. J’ai identifié, dans un premier temps, toutes les compétences du service informatique en interrogeant chaque personne. Dans un second temps j’ai demandé à chaque personne de s’auto évaluer sur ses domaines de compétences. Puis j’ai retravaillé ces données avec les responsables du service pour rectifier les évaluations trop « modestes » ainsi que les évaluations trop « ambitieuses ».

Table des matières
I POURQUOI UN HELPDESK ? 
I.1 CONTEXTE DU PROJET
I.1.1 Le groupe BDR Thermea
I.1.2 De Dietrich Thermique
I.1.2.1 Activités de l’entreprise
I.1.2.2 Les principaux clients
I.1.2.3 Implantations
I.1.2.4 Historique
I.1.2.5 Gamme de produits
I.1.2.6 Chiffre d’affaires et répartition des ventes
I.1.2.7 Position dans le groupe
I.1.3 Les services informatiques
I.1.3.1 Introduction
I.1.3.2 Implantations
I.1.3.3 Organigramme du service informatique de De Dietrich Thermique
I.1.3.4 Parc informatique
I.1.3.5 Utilisateurs et outils
I.2 ETAT DES LIEUX
I.2.1 Introduction
I.2.2 Lancement d’une démarche projet
I.2.3 Volumétrie
I.2.4 Coûts de fonctionnement
I.2.5 Problématiques
I.3 SOLUTION PROPOSEE
I.3.1 Introduction
I.3.2 Choix d’une méthode
I.3.3 Comparatif des référentiels qualité
I.3.3.1 Introduction
I.3.3.2 Présentation des normes / référentiels
I.3.3.3 Comparaison de ces normes / référentiels
I.3.3.4 Comparaison d’ITIL et CobiT
I.3.3.5 Conclusion
I.3.4 Que propose concrètement ITIL ?
I.3.5 Caractéristiques d’un helpdesk
I.3.6 Représentation d’un helpdesk dans ITIL
I.3.7 Le helpdesk est-il la réponse à nos besoins ?
I.4 CONCLUSION
II ETUDE DU PROJET 
II.1 ANALYSE DU PROJET
II.1.1 Documentation
II.1.2 Facteurs clés de succès
II.1.3 Définition des objectifs
II.1.4 Périmètre
II.1.1 Ressources
II.1.2 Contraintes budgétaires
II.2 CHOIX D’UNE STRATEGIE
II.2.1 Plan d’action
II.2.1 Calcul du ROI
II.2.1.1 Revenus / économies attendus
II.2.1.2 Dépenses du projet
II.2.1.3 Synthèse
II.2.2 Analyse du risque
II.2.3 Cahier des charges
II.3 MONTAGE ET PLANIFICATION DU PROJET
II.3.1 Organisation
II.3.2 Planification
II.3.3 Organisation des ressources
II.3.1 Réunions de suivi
II.4 CONCLUSION
III MISE EN ŒUVRE DU PROJET 
III.1 INTRODUCTION
III.2 MISE EN ŒUVRE FONCTIONNELLE
III.2.1 Introduction
III.2.2 Définition de l’organisation
III.2.2.1 Ressources
III.2.2.2 Définitions des rôles
III.2.2.3 Définitions des horaires d’ouverture
III.2.2.4 Calcul du dimensionnement
III.2.2.5 Définition du planning
III.2.2.6 Astreintes
III.2.3 Définition des processus
III.2.3.1 Introduction
III.2.3.2 Typologie de demandes
III.2.3.3 Gestion des incidents
III.2.3.4 Gestion de crise
III.2.3.5 Gestion des demandes d’information et de service
III.2.3.6 Configuration de l’outil
III.2.3.7 Base de connaissances
III.2.3.8 Matrice de compétences
III.2.3.9 Gestion des configurations
III.2.4 Rédaction des documents de référence
III.2.4.1 Livret d’accueil
III.2.4.2 Charte helpdesk
III.2.4.3 Conducteur des appels entrants
III.2.4.4 Formations
III.2.1 Conclusion
III.3 MISE EN ŒUVRE TECHNIQUE
III.3.1 Introduction
III.3.2 Réorganisation des bureaux
III.3.1 Equipement des techniciens
III.3.2 Chantier télécom
III.3.3 Budget détaillé
III.3.1 Conclusion
III.4 GESTION DE LA QUALITE
III.4.1 Introduction
III.4.2 La conduite du changement
III.4.3 La communication
III.4.3.1 Article Panorama
III.4.3.2 Sondage
III.4.3.3 Conclusion
III.4.4 Mesurer
III.4.4.1 Introduction
III.4.4.2 Définition des rapports
III.4.5 Satisfaction client
III.4.5.1 Introduction
III.4.5.2 Exemple de SLA
III.4.6 Amélioration continue
III.4.6.1 Introduction
III.4.6.2 Demande sans workflow
III.4.6.3 Demande avec workflow
III.4.6.4 Conclusion

Télécharger le rapport complet