diagnostic T.I.

Temps estimé pour la lecture de cet article : 10 min

Le diagnostic TI (ou encore diagnostic en technologies de l’information, diagnostic informatique, diagnostic des systèmes d’information) est une activité ponctuelle qui consiste à intervenir pour analyser une situation problématique, identifier les causes fondamentales des problèmes vécus et qui se termine par la préparation et la réalisation/suivi d’un plan d’action.

Après avoir mis en contexte le diagnostic TI, nous ferons, dans ce billet, un survol des activités entourant le diagnostic TI et expliquerons comment celui-ci est une intervention nécessaire dans les opérations TI de toute entreprise.

Vous noterez que le diagnostic TI est souvent associé à un audit de l’infrastructure, de la sécurité et du réseau.  Dans ce billet, nous traitons du diagnostic de situations problématiques au niveau de l’ensemble des technologies de l’information.

 

Un peu de contexte : Le diagnostic TI au niveau des opérations

Le diagnostic TI intervient au niveau des opérations TI d’une entreprise.  À ne pas confondre avec les activités de redressement de projet (applicatif ou autre) – elles ont fait l’objet d’un billet séparé -, il a lieu au niveau des systèmes et processus en cours d’utilisation dans une entreprise.

Il n’est pas important de savoir si l’entreprise utilise les systèmes et processus depuis un mois, trois mois, six mois, une année ou plus.

 

Déclencheurs du diagnostic TILes événements déclencheurs: « Au feu! Au feu! Au feu! »

Les événements amenant une entreprise à déclencher un mandat de diagnostic TI.  Ils peuvent être des observations factuelles ou non-factuelles mais ils se rejoignent tous sur le fait qu’on constate que la situation est intenable et qu’elle doit être redressée.  Des exemples parmi d’autres d’événements déclencheurs:

  • De nombreuses erreur de facturation… Résultant en un nombre élevé de plaintes et forcément de crédits.
  • Un taux anormal de retour sur la marchandise expédiée dû à des erreurs d’expédition.
  • Un temps d’exécution de processus et transactions anormalement long suite à la mise en place d’un nouveau système ou à l’intégration de systèmes.
  • La multiplication d’erreurs lors de la transmission d’informations d’un système à l’autre, à l’intérieur même de l’entreprise.
  • La multiplication d’erreurs lors de la transmission de transactions électroniques (EDI) à un client, fournisseur ou partenaire.
  • Des variations importantes dans un ou plusieurs indicateurs clés de performance (KPI) de l’entreprise.

 

Bref, le diagnostic TI apparaît comme une mesure exceptionnelle et n’est donc normalement pas priorisé dans le plan directeur TI.

 

À qui confie-t-on le diagnostic TI?

Normalement, l’entreprise est en mesure d’effectuer le diagnostic TI avec ses propres effectifs.  Cependant, il peut arriver qu’elle fasse recours à des consultants externes et ce, pour plusieurs raisons:

  • Elle n’a pas assez de personnel pour réaliser un diagnostic complet.
  • Elle désire avoir recours à une expertise externe pour la conduite du mandat.
  • Des querelles internes inter-départementales font en sorte que la haute-direction ne peut avoir l’heure juste sur une situation problématique.

 

Au coeur du diagnostic TI : l’analyse de type PCOS

Une activité de diagnostic TI débute inévitablement par la collecte d’informations factuelles et non-factuelles par le biais de la conduite d’entrevues.  On effectue donc de multiples rencontres avec les personnes-clés pour prendre le pouls de la situation et commencer à se faire une tête sur les causes fondamentales des problèmes vécus.

Une analyse PCOS est progressivement élaborée.  Celle-ci est structurée comme suit:

  • Problèmes.  On énumère d’abord les différents problèmes rencontrés dans les opérations.  On remonte jusqu’aux causes fondamentales des problèmes.  Il peut arriver qu’on doive faire une analyse à plusieurs niveaux, étant donné qu’un effet de cascade arrive fréquemment (un problème en crée un autre, qui en crée d’autres, etc.).
  • Conséquences.  Ensuite, on identifie les conséquences des problèmes observés sur l’organisation et ses opérations.
  • Objectifs.  Puis, on tente de déterminer les objectifs derrière la résolution des problèmes identifiés.
  • Solutions.  Enfin, on établit les solutions envisageables.

 

Il est à noter que les volets « Objectifs » et « Solutions » sont normalement déterminés de concert avec l’entreprise et la haute-direction.  À tout le moins, celle-ci doit confirmer les propositions de l’équipe menant le diagnostic TI.

Maintenant qu’on sait pourquoi on se retrouve dans une telle situation, on prépare ensuite le plan d’action visant à remédier aux problèmes.

 

Plan d'action

Le plan d’action : la résultante finale du diagnostic TI

Le plan d’action constitue un document officiel qui comprend les actions à suivre pour remédier à la situation problématique vécue.  Il est normalement sous la gouverne d’une personne en particulier, bien que les actions qui y sont consignées ont toutes chacun un ou plusieurs responsables.

Le plan d’action comprend au minimum les six éléments suivants:

  • No d’action: Un numéro servant à identifier l’action.
  • Nom de l’action: On donne un bref nom à l’action devant être prise.
  • Description de l’action: Une brève description de l’action.
  • Responsable(s): Le ou les personne(s) responsable(s) de la réalisation/coordination de l’action.
  • Date cible: La date cible fixée pour la mise en place de l’action.
  • Statut: Le statut de l’action (assignée, en cours, complétée, fermée).

 

Une fois le plan d’action préparé et accepté, on gère sa mise en place comme tout projet TI: une personne s’occupe de faire le suivi de chacune des actions et prend action au besoin.  Celle-ci fait part de son avancement à la direction TI, de même qu’aux unités d’affaires impliquées.

Il peut arriver qu’on doive escalader certaines situations à un niveau hiérarchique supérieur.

 

Des exemples puisés à même mon expériences de conseil en TI

J’ai moi-même réalisé plusieurs mandats de diagnostic TI durant ma carrière.  Je vous présente ici deux exemples concrets.  Cela vous donnera une idée de la nature et de l’ampleur des interventions.

 

Implantation d’un ERP chez un manufacturier d’équipements de salle de bain

D’abord, j’ai effectué il y a plusieurs années un mandat de diagnostic TI chez un grand manufacturier d’équipements de salle de bain.  En effet, à la suite de la mise en production d’un nouvel ERP, les opérations de l’entreprise se sont détériorées (erreurs de facturation, ralentissement de la cadence manufacturière, etc.).  Pris de cours, le Vice-Président TI, localisé au siège social de l’entreprise (300 km plus loin), nous a mandatés pour une activité de diagnostic.

J’ai réalisé l’analyse PCOS et préparé le plan d’action en moins de deux semaines.  Le plan d’action comprenait différentes activités de mise à niveau de l’ERP (patches), mais également plusieurs activités de modification des processus de l’entreprise, ainsi que certaines tâches de documentation essentielle.  Vous pouvez d’ailleurs consulter le billet que j’ai écrit au sujet du mythe de la documentation dans les projets ERP.

À la suite de cette intervention, on a exécuté le plan d’action sur une période d’environ six semaines.  Il est à noter que suite à la préparation du plan d’action, mon intervention n’était que sporadique, essentiellement afin de réaliser le suivi des actions.

 

Intégration d’établissements à l’ERP d’un manufacturier dans les matériaux de base

Aussi, un autre exemple de diagnostic TI est celui que j’ai réalisé chez cette grande multinationale suite à l’intégration rapide d’un ERP avec certains de ses établissements.  L’entreprise avait réalisé l’intégration EDI plutôt rapidement (ce n’était pas considéré critique lors de l’implantation).  On m’a donc mandaté pour analyser la situation et monter puis suivre un plan d’action avec l’équipe en place.

La réalisation de l’analyse et du plan d’action a nécessité environ cinq semaines.  En effet, le domaine étant très technique et nécessitant le recours à un fournisseur externe – qu’on contrôle très peu -, des délais étaient donc inévitables.

D’autre part, on a échelonné la réalisation du plan d’action sur plusieurs mois (près de six), considérant le fait qu’on devait modifier de multiples systèmes, incluant ceux des partenaires EDI.  Évidemment, ce n’était pas pour moi une implication à temps plein.

C’était donc deux exemples parmi d’autres.  Il est à noter que les mandats de diagnostic peuvent être bien différents et plus ciblés: on pourrait par exemple réaliser une analyse de performance de site web.

 

Bénéfices du diagnostic TILes bénéfices derrière l’activité de diagnostic

Le diagnostic de situations problématiques apporte de nombreux avantages à l’organisation qui l’utilise.  Parmi les plus importants bénéfices, on note entre autres:

  1. La correction des enjeux identifiés, suite à la réalisation du plan d’action.
  2. Une certaine forme de discussion amenant vers un consensus sur les problématiques impliquées.  Cela amène l’entreprise davantage vers une culture d’ouverture et de transparence.
  3. Il imprime dans la tête des gens que l’organisation des TI a une certaine culture d’amélioration continue et retire l’impression que « rien ne va changer ».

 

Conclusion : Le diagnostic TI, un outil de plus pour une saine gestion des TI

Bref, le diagnostic TI est une activité essentielle pour maintenir une saine gestion des opérations TI dans une entreprise.  On intervient afin de redresser une situation TI problématique, peu importe si les applications, les processus, les employé(e)s impliqués ou une combinaison de ceux-ci causent la situation.

Enfin, que ce soit dans une PME ou dans une grande entreprise, le diagnostic TI est un outil de plus pour une saine gestion des TI.  Il est donc possible d’adapter sa profondeur et sa durée en fonction des contraintes budgétaires associées à sa réalisation.

 

Lectures additionnelles

On retrouvera sur le web plusieurs sites reliés au diagnostic TI.  Dans la majorité des cas, celui-ci est davantage un audit de l’infrastructure, de la sécurité ou de la performance des systèmes.  Je vous invite à consulter les sites suivants qui se sont avérés des références lors de la préparation et la rédaction de ce billet :

Simon Chamberland
Simon oeuvre dans le milieu des technologies de l'information depuis 1995. Il possède une quinzaine années d'expérience de conseil en technologies de l'information et gestion. Il a débuté sa pratique de consultant indépendant en 2007 et a fondé Brome Conseil en 2009. Il est Président et Conseiller senior au sein de l'entreprise. Simon réside à Sutton, dans la région de Brome-Missisquoi.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

*